[GIT PULL] xen: regression fix for 4.8-rc3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.8b-rc3-tag xen: regression fix for 4.8-rc3 - - Fix a regression in the xenbus device preventing userspace tools from working. Thanks. David arch/arm/xen/enlighten.c | 2 +- arch/x86/xen/enlighten.c | 2 +- drivers/xen/xenbus/xenbus_dev_frontend.c | 2 +- include/xen/xen-ops.h| 4 ++-- 4 files changed, 5 insertions(+), 5 deletions(-) Jan Beulich (1): xenbus: don't look up transaction IDs for ordinary writes Vitaly Kuznetsov (1): xen: change the type of xen_vcpu_id to uint32_t -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJXvdwIAAoJEFxbo/MsZsTR9mAH/1E/8K10KzhYXWy1hS9/Vsfz Kn2l3ymT8RAANRHq3fL/wFMF+6KPKxbJ7A3CSkismPLZTnPA4WuKp/CiLEVBS3vm GONWXLBlcWVttAxfsMd9tFAz9VHP2MsYy2iRzaTeBmmouBrjKb/FygUctHgPhGjI 9793Pw10TfVEc2efmSM06c6Jfy26mcclQ8gisOlT6TyjJbBMiRXhc2LjHDpD9jYy wIKirBwSaL7oN+CM1ua/apu+n7h/bXg+bSsDWqdu7e+vETgVxwrk5kflgcENf+pO bBn5LR8fMeFd6WrQfWkVpSX7gRFBBAH+XkMdYo7C/s5MYuL143dVdq9ZbAlfVr8= =L0YJ -END PGP SIGNATURE-
Re: [PATCH v6 2/2] clocksource: add J-Core timer/clocksource driver
On Wed, Aug 24, 2016 at 06:42:05PM +0200, Daniel Lezcano wrote:
> > diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> > index 5677886..3210ca5 100644
> > --- a/drivers/clocksource/Kconfig
> > +++ b/drivers/clocksource/Kconfig
> > @@ -407,6 +407,15 @@ config SYS_SUPPORTS_SH_TMU
> > config SYS_SUPPORTS_EM_STI
> > bool
> >
> > +config CLKSRC_JCORE_PIT
> > + bool "J-Core PIT timer driver"
> > + depends on OF && (SUPERH || COMPILE_TEST)
>
> Even if this is correct, for the sake of consistency, it is preferable
> to change it to:
>
> bool "J-Core PIT timer driver" if COMPILE_TEST
> depends on SUPERH
> select CLKSRC_OF
Is this functionally equivalent? If so that's non-obvious to me. What
about the dropped OF dependency? The intent is that the option should
always be available for SUPERH targets using OF, otherwise only
available with COMPILE_TEST.
> > +static int jcore_pit_set(unsigned long delta, struct jcore_pit *pit)
> > +{
> > + jcore_pit_disable(pit);
> > + __raw_writel(delta, pit->base + REG_THROT);
> > + __raw_writel(pit->enable_val, pit->base + REG_PITEN);
> > + return 0;
>
> Why do you need to use __raw_writel ?
>
> s/__raw_writel/writel/
I actually tried multiple times to find good resources on policy for
which form to prefer, but didn't have much luck. My understanding is
that __raw_writel/__raw_readl always performs a native-endian
load/store, whereas writel/readl behavior depends on cpu endianness
and whether the arch declares that "pci bus" (that was the term I
found in the source, not relevant here) io is endian-swapped or not.
Can you give me a better explanation of why we might prefer one form
or the other?
> > + freq = DIV_ROUND_CLOSEST(NSEC_PER_SEC, buspd);
> > + pit->periodic_delta = DIV_ROUND_CLOSEST(NSEC_PER_SEC, HZ*buspd);
>
> ---> HZ * buspd
OK.
> > + clockevents_config_and_register(&pit->ced, freq, 1, ULONG_MAX);
> > +
> > + return 0;
> > +}
> > +
> > +static int jcore_pit_local_shutdown(unsigned cpu)
> > +{
> > + return 0;
> > +}
>
> This function is useless I think. AFAIU, cpuhp_setup_state can have a
> NULL function for the cpu teardown.
OK, I wasn't sure if that was permitted.
> > + jcore_cs.name = "jcore_pit_cs";
> > + jcore_cs.rating = 400;
> > + jcore_cs.read = jcore_clocksource_read;
> > + jcore_cs.mult = 1;
> > + jcore_cs.shift = 0;
> > + jcore_cs.mask = CLOCKSOURCE_MASK(32);
> > + jcore_cs.flags = CLOCK_SOURCE_IS_CONTINUOUS;
> > +
> > + err = clocksource_register_hz(&jcore_cs, NSEC_PER_SEC);
> > + if (err) {
> > + pr_err("Error registering clocksource device: %d\n", err);
> > + return err;
> > + }
>
> May be you can consider by replacing the above by:
>
> clocksource_mmio_init(jcore_pit_base, "jcore_pit_cs",
> NSEC_PER_SEC, 32,
> jcore_clocksource_read);
I think you're missing the rating argument. Otherwise it should work,
but is there a good reason to prefer it? The code is slightly simpler;
I'm not sure if using kzalloc vs static storage is better or worse.
> > + sched_clock_register(jcore_sched_clock_read, 32, NSEC_PER_SEC);
> > +
> > + jcore_pit_percpu = alloc_percpu(struct jcore_pit);
> > + if (!jcore_pit_percpu) {
> > + pr_err("Failed to allocate memory for clock event device\n");
> > + return -ENOMEM;
> > + }
> > +
> > + err = request_irq(pit_irq, jcore_timer_interrupt,
> > + IRQF_TIMER | IRQF_PERCPU,
> > + "jcore_pit", jcore_pit_percpu);
> > + if (err) {
> > + pr_err("pit irq request failed: %d\n", err);
> > + return err;
> > + }
>
> That is my major concern. Regarding the description of this timer, it
> appears there is one timer per cpu but we use request_irq instead of
> request_percpu_irq.
>
> IIUC, there is a problem with the interrupt controller where the per irq
> line are not working correctly. Is that correct ?
I don't think that's a correct characterization. Rather the percpu
infrastructure just means something completely different from what you
would expect it to mean. It has nothing to do with the hardware but
rather with kernel-internal choice of whether to do percpu devid
mapping inside the irq infrastructure, and the choice at the
irq-requester side of whether to do this is required to match the
irqchip driver's choice. I explained this better in another email
which I could dig up if necessary, but the essence is that
request_percpu_irq is a misnamed and unusably broken API.
> Regarding Marc Zyngier comments about the irq controller driver being
> almost empty, I'm wondering if something in the irq controller driver
> which shouldn't be added before submitting this timer driver with SMP
> support (eg. irq domain ?).
I don't think so. At most I could make the driver hard-code the percpu
devid model for certain irqs, but that _does n
Re: [PATCH 03/10] reset: lpc18xx: add driver Kconfig option
2016-08-24 22:28 GMT+09:00 Philipp Zabel : > Visible only if COMPILE_TEST is enabled, this allows to include the > driver in build tests. > > Cc: Joachim Eastwood > Signed-off-by: Philipp Zabel Reviewed-by: Masahiro Yamada -- Best Regards Masahiro Yamada
Re: [Xen-devel] [PATCH] xenbus: don't look up transaction IDs for ordinary writes
On 15/08/16 16:02, Jan Beulich wrote: > This should really only be done for XS_TRANSACTION_END messages, or > else at least some of the xenstore-* tools don't work anymore. Applied to for-linus-4.8b, thanks. David
Re: [PATCH 07/10] reset: stm32: add driver Kconfig option
2016-08-24 22:28 GMT+09:00 Philipp Zabel : > Visible only if COMPILE_TEST is enabled, this allows to include the > driver in build tests. > > Cc: Maxime Coquelin > Cc: Gabriel Fernandez > Signed-off-by: Philipp Zabel Reviewed-by: Masahiro Yamada Best Regards Masahiro Yamada
Re: [Xen-devel] [PATCH linux v2] xen: change the type of xen_vcpu_id to uint32_t
On 29/07/16 10:06, Vitaly Kuznetsov wrote: > We pass xen_vcpu_id mapping information to hypercalls which require > uint32_t type so it would be cleaner to have it as uint32_t. The > initializer to -1 can be dropped as we always do the mapping before using > it and we never check the 'not set' value anyway. Applied to for-linus-4.8b, thanks. David
Re: [PATCH 02/10] reset: berlin: add driver Kconfig option
2016-08-24 22:28 GMT+09:00 Philipp Zabel : > Visible only if COMPILE_TEST is enabled, this allows to include the > driver in build tests. > > Cc: Antoine Tenart > Cc: Sebastian Hesselbarth > Signed-off-by: Philipp Zabel Reviewed-by: Masahiro Yamada -- Best Regards Masahiro Yamada
Re: [PATCH] ARM: EXYNOS: Clear OF_POPULATED flag from PMU node in IRQ init callback
On Sun, Aug 21, 2016 at 03:27:45AM -0400, Javier Martinez Canillas wrote:
> The Exynos PMU node is an interrupt, clock and PMU (Power Management Unit)
> controller, and these functionalities are supported by different drivers
> that matches the same compatible strings.
>
> Since commit 15cc2ed6dcf9 ("of/irq: Mark initialised interrupt controllers
> as populated") the OF core flags interrupt controllers registered with the
> IRQCHIP_DECLARE() macro as OF_POPULATED, so platform devices with the same
> compatible string as the interrupt controller will not be registered.
>
> This prevents the PMU platform device to be registered so the Exynos PMU
> driver is never probed. This breaks (among other things) Suspend-to-RAM.
>
> Fix this by clearing the OF_POPULATED flag in the PMU IRQ init callback,
> to allow the Exynos PMU platform driver to be probed. The patch is based
> on Philipp Zabel's "ARM: imx6: mark GPC node as not populated after irq
> init to probe pm domain driver".
>
> Fixes: 15cc2ed6dcf9 ("of/irq: Mark initialised interrupt controllers as
> populated")
> Signed-off-by: Javier Martinez Canillas
>
> ---
>
> This was tested on an Exynos5800 Peach Pi Chromebook with v4.8-rc2 +
> Philipp's patch: https://patchwork.kernel.org/patch/9271361/
>
> arch/arm/mach-exynos/suspend.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
> index 3750575c73c5..06332f626565 100644
> --- a/arch/arm/mach-exynos/suspend.c
> +++ b/arch/arm/mach-exynos/suspend.c
> @@ -255,6 +255,12 @@ static int __init exynos_pmu_irq_init(struct device_node
> *node,
> return -ENOMEM;
> }
>
> + /*
> + * Clear the OF_POPULATED flag set in of_irq_init so that
> + * later the Exynos PMU platform device won't be skipped.
> + */
> + of_node_clear_flag(node, OF_POPULATED);
> +
Looks like a proper workaround (at least till of_irq_init sets this flag
before calling irq_init_cb()) however I have some more doubts:
1. The commit 15cc2ed6dcf9 ("of/irq: Mark initialised interrupt
controllers as populated") might be also applied to clock CLK_OF_DECLARE
and the problem will appear again.
2. We are reusing PMU compatible for irqcip, clock provider and a
platform driver. This is one PMU block with many features thus many
drivers were created. What happens if the Exynos platform driver
(drivers/soc/samsung/exynos-pmu.c) binds before irqchip or clk provider?
Probably we should not reuse the compatible but create a new one for
each type of driver? How does it match DeviceTree?
Javier, Rob, any hints on that? Best practices, suggestions for future?
Best regards,
Krzysztof
Re: [PATCH 06/10] reset: socfpga: add driver Kconfig option
2016-08-24 22:28 GMT+09:00 Philipp Zabel : > Visible only if COMPILE_TEST is enabled, this allows to include the > driver in build tests. > > Cc: Dinh Nguyen > Signed-off-by: Philipp Zabel Reviewed-by: Masahiro Yamada -- Best Regards Masahiro Yamada
Re: [PATCH 04/10] reset: meson: add driver Kconfig option
2016-08-24 22:28 GMT+09:00 Philipp Zabel : > Visible only if COMPILE_TEST is enabled, this allows to include the > driver in build tests. > > Cc: Neil Armstrong > Signed-off-by: Philipp Zabel Reviewed-by: Masahiro Yamada -- Best Regards Masahiro Yamada
Re: [PATCH 05/10] reset: pistachio: add driver Kconfig option
2016-08-24 22:28 GMT+09:00 Philipp Zabel : > Visible only if COMPILE_TEST is enabled, this allows to include the > driver in build tests. > > Cc: Damien Horsley > Cc: James Hartley > Signed-off-by: Philipp Zabel Reviewed-by: Masahiro Yamada -- Best Regards Masahiro Yamada
Re: [Xen-devel] [PATCH v3] xen: Make VPMU init message look less scary
On 02/08/16 08:22, Juergen Gross wrote: > The default for the Xen hypervisor is to not enable VPMU in order to > avoid security issues. In this case the Linux kernel will issue the > message "Could not initialize VPMU for cpu 0, error -95" which looks > more like an error than a normal state. > > Change the message to something less scary in case the hypervisor > returns EOPNOTSUPP or ENOSYS when trying to activate VPMU. Applied to for-linus-4.9, thanks. David
Re: [PATCH 01/10] reset: ath79: add driver Kconfig option
2016-08-24 22:28 GMT+09:00 Philipp Zabel : > Visible only if COMPILE_TEST is enabled, this allows to include the > driver in build tests. > > Cc: Alban Bedel > Signed-off-by: Philipp Zabel Reviewed-by: Masahiro Yamada -- Best Regards Masahiro Yamada
Re: [Xen-devel] [PATCH v2] xen: rename xen_pmu_init() in sys-hypervisor.c
On 02/08/16 07:53, Juergen Gross wrote: > There are two functions with name xen_pmu_init() in the kernel. Rename > the one in drivers/xen/sys-hypervisor.c to avoid shadowing the one in > arch/x86/xen/pmu.c > > To avoid the same problem in future rename some more functions. Applied to for-linus-4.9, thanks. David
Re: [PATCH 04/11] sched,x86: Enable Turbo Boost Max Technology
On Wed, Aug 24, 2016 at 12:18:53PM +0200, Ingo Molnar wrote: > > * Srinivas Pandruvada wrote: > > > From: Tim Chen > > > > On some Intel cores, they can boosted to a higher turbo frequency than > > the other cores on the same die. So we prefer processes to be run on > > them vs other lower frequency ones for extra performance. > > > > We extend the asym packing feature in the scheduler to support packing > > task to the higher frequency core at the core sched domain level. > > > > We set up a core priority metric to abstract the core preferences based > > on the maximum boost frequency. The priority is instantiated such that > > the core with a higher priority is favored over the core with lower > > priority when making scheduling decision using ASYM_PACKING. The smt > > threads that are of higher number are discounted in their priority so > > we will not try to pack tasks onto all the threads of a favored core > > before using other cpu cores. The cpu that's of the highese priority > > in a sched_group is recorded in sched_group->asym_prefer_cpu during > > initialization to save lookup during load balancing. > > > > A sysctl variable /proc/sys/kernel/sched_itmt_enabled is provided so > > the scheduling based on favored core can be turned on or off at run time. > > > +/* > > + * Boolean to control whether we want to move processes to cpu capable > > + * of higher turbo frequency for cpus supporting Intel Turbo Boost Max > > + * Technology 3.0. > > + * > > + * It can be set via /proc/sys/kernel/sched_itmt_enabled > > + */ > > +unsigned int __read_mostly sysctl_sched_itmt_enabled = 0; > > Ugh, no. > > We don't add features to the scheduler in the hope that they might or might > not > help. We either enable a new feature by default (and make damn sure it > helps!), > or don't add the feature at all. > > Thanks, > > Ingo Ingo, This feature will be a clear benefit for client machines and less clear on servers. This feature is most beneficial to single threaded workload running on a single socket that operates in mostly Turbo mode. Client platform like Broadwell High End Desktop is the first one that supports it. Enablng this feature for such platform by default will be a win as it runs single threaded workload much of the time (10%-15% peformance upside). On the other hand, a heavily loaded server that rarely operates in Turbo mode will benefit much less from this feature. There is some overhead incurred by migrating load to the favored cores. Some server folks have asked us to be cautious here and not to turn on ITMT scheduling by default. Even so, when the server is lightly loaded, this feature can still be a win. That said, this is future looking as we don't have any server with this feature today. So if we take the approach to enable this feature by default for only single node system (using that as a criteria for client), will that seem reasonable to you? Thanks. Tim
Re: [PATCH v12 2/4] reset: mediatek: Add MT2701 reset driver
On 08/22, Erin Lo wrote:
> diff --git a/drivers/clk/mediatek/clk-mt2701-hif.c
> b/drivers/clk/mediatek/clk-mt2701-hif.c
> index 18b4ab5..702fd74 100644
> --- a/drivers/clk/mediatek/clk-mt2701-hif.c
> +++ b/drivers/clk/mediatek/clk-mt2701-hif.c
> @@ -52,11 +52,15 @@ static int mtk_hifsys_init(struct device_node *node)
> clk_data);
>
> r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
> - if (r)
> + if (r) {
> pr_err("%s(): could not register clock provider: %d\n",
> __func__, r);
> + return r;
> + }
> +
> + mtk_register_reset_controller(node, 1, 0x34);
The cleanup here isn't great. mtk_register_reset_controller()
should really return an error so that we can properly cleanup if
needed. Fixing that in a later patch would be a good idea.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH v12 1/4] clk: mediatek: Add MT2701 clock support
On 08/22, Erin Lo wrote:
> +
> +static void __init mtk_infrasys_init_early(struct device_node *node)
> +{
> + int r, i;
> +
> + if (!infra_clk_data) {
> + infra_clk_data = mtk_alloc_clk_data(CLK_INFRA_NR);
> +
> + for (i = 0; i < CLK_INFRA_NR; i++)
> + infra_clk_data->clks[i] = ERR_PTR(-EPROBE_DEFER);
> + }
> +
> + mtk_clk_register_factors(infra_fixed_divs, ARRAY_SIZE(infra_fixed_divs),
> + infra_clk_data);
> +
> + r = of_clk_add_provider(node, of_clk_src_onecell_get, infra_clk_data);
> + if (r)
> + pr_err("%s(): could not register clock provider: %d\n",
> + __func__, r);
> +}
> +CLK_OF_DECLARE(mtk_infra, "mediatek,mt2701-infracfg",
> mtk_infrasys_init_early);
This should use CLK_OF_DECLARE_DRIVER? Has this been tested on
latest clk-next? Some recent patches make it so that
CLK_OF_DECLARE() prevents platform devices from being created for
the associated DT nodes that match during of_clk_init().
> +
> +static int mtk_infrasys_init(struct device_node *node)
> +{
> + int r, i;
> +
> + if (!infra_clk_data) {
> + infra_clk_data = mtk_alloc_clk_data(CLK_INFRA_NR);
> + } else {
> + for (i = 0; i < CLK_INFRA_NR; i++) {
> + if (infra_clk_data->clks[i] == ERR_PTR(-EPROBE_DEFER))
> + infra_clk_data->clks[i] = ERR_PTR(-ENOENT);
> + }
> + }
> +
> + mtk_clk_register_gates(node, infra_clks, ARRAY_SIZE(infra_clks),
> + infra_clk_data);
> + mtk_clk_register_factors(infra_fixed_divs, ARRAY_SIZE(infra_fixed_divs),
> + infra_clk_data);
> +
> + r = of_clk_add_provider(node, of_clk_src_onecell_get, infra_clk_data);
> + if (r)
> + pr_err("%s(): could not register clock provider: %d\n",
> + __func__, r);
> +
> + return r;
> +}
> +
> +static const struct mtk_gate_regs peri0_cg_regs = {
> + .set_ofs = 0x0008,
> + .clr_ofs = 0x0010,
> + .sta_ofs = 0x0018,
> +};
> +
> +static const struct mtk_gate_regs peri1_cg_regs = {
> + .set_ofs = 0x000c,
> + .clr_ofs = 0x0014,
> + .sta_ofs = 0x001c,
> +};
> +
> +#define GATE_PERI0(_id, _name, _parent, _shift) {\
> + .id = _id, \
> + .name = _name, \
> + .parent_name = _parent, \
> + .regs = &peri0_cg_regs, \
> + .shift = _shift,\
> + .ops = &mtk_clk_gate_ops_setclr,\
> + }
> +
> +#define GATE_PERI1(_id, _name, _parent, _shift) {\
> + .id = _id, \
> + .name = _name, \
> + .parent_name = _parent, \
> + .regs = &peri1_cg_regs, \
> + .shift = _shift,\
> + .ops = &mtk_clk_gate_ops_setclr,\
> + }
> +
> +static const struct mtk_gate peri_clks[] = {
> + GATE_PERI1(CLK_PERI_USB0_MCU, "usb0_mcu_ck", "axi_sel", 31),
> + GATE_PERI1(CLK_PERI_ETH, "eth_ck", "clk26m", 30),
> + GATE_PERI1(CLK_PERI_SPI0, "spi0_ck", "spi0_sel", 29),
> + GATE_PERI1(CLK_PERI_AUXADC, "auxadc_ck", "clk26m", 28),
> + GATE_PERI0(CLK_PERI_I2C3, "i2c3_ck", "clk26m", 27),
> + GATE_PERI0(CLK_PERI_I2C2, "i2c2_ck", "axi_sel", 26),
> + GATE_PERI0(CLK_PERI_I2C1, "i2c1_ck", "axi_sel", 25),
> + GATE_PERI0(CLK_PERI_I2C0, "i2c0_ck", "axi_sel", 24),
> + GATE_PERI0(CLK_PERI_BTIF, "bitif_ck", "axi_sel", 23),
> + GATE_PERI0(CLK_PERI_UART3, "uart3_ck", "axi_sel", 22),
> + GATE_PERI0(CLK_PERI_UART2, "uart2_ck", "axi_sel", 21),
> + GATE_PERI0(CLK_PERI_UART1, "uart1_ck", "axi_sel", 20),
> + GATE_PERI0(CLK_PERI_UART0, "uart0_ck", "axi_sel", 19),
> + GATE_PERI0(CLK_PERI_NLI, "nli_ck", "axi_sel", 18),
> + GATE_PERI0(CLK_PERI_MSDC50_3, "msdc50_3_ck", "emmc_hclk_sel", 17),
> + GATE_PERI0(CLK_PERI_MSDC30_3, "msdc30_3_ck", "msdc30_3_sel", 16),
> + GATE_PERI0(CLK_PERI_MSDC30_2, "msdc30_2_ck", "msdc30_2_sel", 15),
> + GATE_PERI0(CLK_PERI_MSDC30_1, "msdc30_1_ck", "msdc30_1_sel", 14),
> + GATE_PERI0(CLK_PERI_MSDC30_0, "msdc30_0_ck", "msdc30_0_sel", 13),
> + GATE_PERI0(CLK_PERI_AP_DMA, "ap_dma_ck", "axi_sel", 12),
> + GATE_PERI0(CLK_PERI_USB1, "usb1_ck", "usb20_sel", 11),
> + GATE_PERI0(CLK_PERI_USB0, "usb0_ck", "usb20_sel", 10),
> + GATE_PERI0(CLK_PERI_PWM, "pwm_ck", "axi_sel", 9),
> + GATE_PERI0(CLK_PERI_PWM7, "pwm7_ck", "axi_sel", 8),
> + GATE_PERI0(CLK_PERI_PWM6, "pwm6_ck", "axi_sel", 7),
> + GATE_PERI0(CLK_PERI_PWM5, "pwm5_ck", "axi_sel", 6),
> + GATE_PERI0(CLK_PERI_PWM4, "pwm4_ck", "axi_sel", 5),
> + GATE_PERI0(CLK_PERI_PWM3, "pwm3_ck", "axi_sel", 4),
> +
[PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger
From: Rafał Miłecki This commit adds a new trigger responsible for turning on LED when USB device gets connected to the specified USB port. This can can useful for various home routers that have USB port(s) and a proper LED telling user a device is connected. The trigger gets its documentation file but basically it just requires specifying USB port in a Linux format (e.g. echo 1-1 > new_port). During work on this trigger there was a plan to add DT bindings for it, but there wasn't an agreement on the format yet. This can be worked on later, a sysfs interface is needed anyway for platforms not using DT. Signed-off-by: Rafał Miłecki --- V2: Trying to add DT support, idea postponed as it will take more time to discuss the bindings. V3: Fix typos in commit and Documentation (thanks Jacek!) Use "ports" sysfs file for adding and removing USB ports (thx Jacek) Check if there is USB device connected after adding new USB port Fix memory leak or two V3.5: Fix e-mail address (thanks Matthias) Simplify conditions in usbport_trig_notify (thx Matthias) Make "ports" a subdirectory with file per port, to match one value per file sysfs rule (thanks Greg) As "ports" couldn't be used for adding and removing ports anymore, there are now "new_port" and "remove_port". Having them makes this API also common with e.g. pci and usb buses. The last big missing thing is Documentation update (this is why I'm sending RFC). Greg pointed out we should have some entries in Documentation/ABI, but it seems none of triggers have it. Any idea why is that? Do we need to change it? Or is it required for new code only? If so, should I care about Documentation/leds/ledtrig-usbport.txt at all in this patch? For now I didn't update Documentation/leds/ledtrig-usbport.txt with the new new_port and remove_port API, until I get a clue how to proceed. --- Documentation/leds/ledtrig-usbport.txt | 49 ++ drivers/leds/trigger/Kconfig | 8 + drivers/leds/trigger/Makefile | 1 + drivers/leds/trigger/ledtrig-usbport.c | 309 + 4 files changed, 367 insertions(+) create mode 100644 Documentation/leds/ledtrig-usbport.txt create mode 100644 drivers/leds/trigger/ledtrig-usbport.c diff --git a/Documentation/leds/ledtrig-usbport.txt b/Documentation/leds/ledtrig-usbport.txt new file mode 100644 index 000..fa42227 --- /dev/null +++ b/Documentation/leds/ledtrig-usbport.txt @@ -0,0 +1,49 @@ +USB port LED trigger + + +This LED trigger can be used for signalling to the user a presence of USB device +in a given port. It simply turns on LED when device appears and turns it off +when it disappears. + +It requires specifying a list of USB ports that should be observed. Used format +matches Linux kernel format and consists of a root hub number and a hub port +separated by a dash (e.g. 3-1). + +It is also possible to handle devices with internal hubs (that are always +connected to the root hub). User can simply specify internal hub ports then +(e.g. 1-1.1, 1-1.2, etc.). + +Please note that this trigger allows assigning multiple USB ports to a single +LED. This can be useful in two cases: + +1) Device with single USB LED and few physical ports + +In such a case LED will be turned on as long as there is at least one connected +USB device. + +2) Device with a physical port handled by few controllers + +Some devices have e.g. one controller per PHY standard. E.g. USB 3.0 physical +port may be handled by ohci-platform, ehci-platform and xhci-hcd. If there is +only one LED user will most likely want to assign ports from all 3 hubs. + + +This trigger can be activated from user space on led class devices as shown +below: + + echo usbport > trigger + +This adds the following sysfs attributes to the LED: + + ports - Reading it lists all USB ports assigned to the trigger. Writing USB + port number to it will make this driver start observing it. It's also + possible to remove USB port from observable list by writing it with a + "-" prefix. + +Example use-case: + + echo usbport > trigger + echo 4-1 > ports + echo 2-1 > ports + echo -4-1 > ports + cat ports diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig index 3f9ddb9..bdd6fd2 100644 --- a/drivers/leds/trigger/Kconfig +++ b/drivers/leds/trigger/Kconfig @@ -126,4 +126,12 @@ config LEDS_TRIGGER_PANIC a different trigger. If unsure, say Y. +config LEDS_TRIGGER_USBPORT + tristate "USB port LED trigger" + depends on LEDS_TRIGGERS && USB + help + This allows LEDs to be controlled by USB events. Enabling this option + allows specifying list of USB ports that should turn on LED when some + USB device gets connected. + endif # LEDS_TRIGGERS diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile index a72c43c..56e1741 100644 --- a/drivers/leds/trigger/Makefile +++ b
Direct Cash Loans Specials !!!
Dear Valued Customer, Consolidate your debts with Direct Cash Loan SA for your peace of mind at a fixed interest rate of 3.5%, personal and business loans are also welcome.For details open enclosed documents and file in your applications by sending an email to: cashdirectloans_appld...@webmail.co.za Regards, Lydia Venter +27622539768 Direct Cash Loan Low Rate Offer.docx Description: MS-Word 2007 document
Re: [PATCH v2] PCI: altera: Retrain link in rootport mode only
[+cc Ray, Scott, Jon, bcm-kernel-feedback-list] On Wed, Aug 24, 2016 at 03:07:52PM +0800, Ley Foon Tan wrote: > On Mon, Aug 22, 2016 at 11:47 PM, Bjorn Helgaas wrote: > > On Fri, Aug 19, 2016 at 04:24:38PM +0800, Ley Foon Tan wrote: > >> Altera PCIe IP can be configured as rootport or device and they might have > >> same vendor ID. It will cause the system hang issue if Altera PCIe is in > >> endpoint mode and work with other PCIe rootport that from other vendors. > >> So, add the rootport mode checking in link retrain fixup function. > >> > >> Signed-off-by: Ley Foon Tan > >> --- > >> v2: change to check PCIe type is PCI_EXP_TYPE_ROOT_PORT > >> --- > >> drivers/pci/host/pcie-altera.c | 3 +++ > >> 1 file changed, 3 insertions(+) > >> > >> diff --git a/drivers/pci/host/pcie-altera.c > >> b/drivers/pci/host/pcie-altera.c > >> index 58eef99..33b6968 100644 > >> --- a/drivers/pci/host/pcie-altera.c > >> +++ b/drivers/pci/host/pcie-altera.c > >> @@ -139,6 +139,9 @@ static void altera_pcie_retrain(struct pci_dev *dev) > >> u16 linkcap, linkstat; > >> struct altera_pcie *pcie = dev->bus->sysdata; > >> > >> + if (pci_pcie_type(dev) != PCI_EXP_TYPE_ROOT_PORT) > >> + return; > >> + > >> if (!altera_pcie_link_is_up(pcie)) > >> return; > > > > Instead of making this a PCI fixup, can you make an > > altera_pcie_host_init() function, call it from altera_pcie_probe(), > > and do the link retrain there? Then you wouldn't need to worry about > > whether this is a Root Port or an Endpoint, plus it would make the > > altera driver structure more like the other drivers. > > > > You would call altera_pcie_host_init() before pci_scan_root_bus(), so > > you wouldn't have a pci_dev yet, so you wouldn't be able to use > > pcie_capability_set_word() to set the PCI_EXP_LNKCTL_RL bit. But I > > assume there's some device-dependent way to access it using > > cra_writel()? > We can't use cra_write() to set PCI_EXP_LNKCTL_RL bit. Why not? I don't mean it has to be cra_write(), but isn't there some way you can write that bit before we scan the root bus? It doesn't make sense that we have to scan the bus before we can train the link. We want to be able to tell the PCI core "all the device-specific root complex initialization has been done, here are the config accessors you need, please scan for devices." I want to keep device-specific things like this quirk directly in the driver and out of the enumeration process. > We can use > pci_bus_find_capability() and pci_bus_read_config_word() with struct > pci_bus instead. > But this only can be called after pci_scan_root_bus(). > Found > iproc_pcie_check_link() have similar implementation. You're right, and I don't like iproc_pcie_check_link() either, for the same reasons. The iproc_pcie_check_link() is a little better because it's called before enumeration: pci_create_root_bus() iproc_pcie_check_link() pci_scan_child_bus() But it would be a lot better if iproc_pcie_check_link() were done first, before pci_create_root_bus(). Then it would be more like the structure of other drivers, and we could use pci_scan_root_bus() instead. Comments, iproc folks? Bjorn
[PATCH] phy: request shared IRQ
From: Nathan Sullivan
On hardware with multiple PHY devices hooked up to the same IRQ line, allow
them to share it.
Signed-off-by: Nathan Sullivan
Signed-off-by: Xander Huff
Acked-by: Ben Shelton
Acked-by: Jaeden Amero
---
drivers/net/phy/phy.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index c5dc2c36..0050531 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -722,8 +722,8 @@ phy_err:
int phy_start_interrupts(struct phy_device *phydev)
{
atomic_set(&phydev->irq_disable, 0);
- if (request_irq(phydev->irq, phy_interrupt, 0, "phy_interrupt",
- phydev) < 0) {
+ if (request_irq(phydev->irq, phy_interrupt, IRQF_SHARED,
+ "phy_interrupt", phydev) < 0) {
pr_warn("%s: Can't get IRQ %d (PHY)\n",
phydev->mdio.bus->name, phydev->irq);
phydev->irq = PHY_POLL;
--
1.9.1
Re: [PATCH -next] sound: rockchip: fix build when SPI is not enabled
On 08/22/16 11:32, Randy Dunlap wrote: > From: Randy Dunlap > > Fix build errors found in rt5514 drivers when SPI is not enabled. > > Fixes these build errors: > ERROR: "__spi_register_driver" [sound/soc/codecs/snd-soc-rt5514-spi.ko] > undefined! > ERROR: "spi_sync" [sound/soc/codecs/snd-soc-rt5514-spi.ko] undefined! > > Signed-off-by: Randy Dunlap > Cc: Bard Liao > Cc: Oder Chiou > --- > sound/soc/rockchip/Kconfig |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > This builds without errors, but if you always want to have the SPI > interface available in this driver, change the first "depends" to > include "&& SPI_MASTER". Please drop this patch. The comment above is the correct thing to do and I am sending a patch with that change. > --- linux-next-20160822.orig/sound/soc/rockchip/Kconfig > +++ linux-next-20160822/sound/soc/rockchip/Kconfig > @@ -49,7 +49,7 @@ config SND_SOC_RK3399_GRU_SOUND > select SND_SOC_MAX98357A > select SND_SOC_RT5514 > select SND_SOC_DA7219 > - select SND_SOC_RT5514_SPI > + select SND_SOC_RT5514_SPI if SPI_MASTER > help > Say Y or M here if you want to add support multiple codecs for SoC > audio on Rockchip RK3399 GRU boards. > -- ~Randy
Re: [PATCH 09/10] reset: zynq: add driver Kconfig option
2016-08-24 22:29 GMT+09:00 Philipp Zabel : > Visible only if COMPILE_TEST is enabled, this allows to include the > driver in build tests. > > Cc: Moritz Fischer > Cc: Michal Simek > Cc: Sören Brinkmann > Signed-off-by: Philipp Zabel > --- > drivers/reset/Kconfig | 6 ++ > drivers/reset/Makefile | 2 +- > 2 files changed, 7 insertions(+), 1 deletion(-) > > diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig > index 17030e2..86b49a2 100644 > --- a/drivers/reset/Kconfig > +++ b/drivers/reset/Kconfig > @@ -67,6 +67,12 @@ config RESET_SUNXI > help > This enables the reset driver for Allwinner SoCs. > > +config RESET_ZYNQ > + bool "ZYNQ Reset Driver" if COMPILE_TEST > + default ARCH_ZYNQ > + help > + This enables the reset driver for Xilinx Zynq FPGAs. > + Please move this below RESET_UNIPHIER as I assume you are sorting Kconfig entries alphabetically. Otherwise, Reviewed-by: Masahiro Yamada -- Best Regards Masahiro Yamada
Re: [RFC PATCH v3 0/2] Type-C Port Manager
Hello Heikki, On Wed, Aug 24, 2016 at 5:52 AM, Heikki Krogerus wrote: > Hi Guenter, > > On Tue, Aug 23, 2016 at 02:10:49PM -0700, Guenter Roeck wrote: >> The following series of patches implements a USB Type-C Port Manager >> using the pending USB Type-C class code as basis. The code is still WIP, >> but I think it is important to get feedback from the community at this point. >> >> There are two patches in the series. The first patch implements the Type-C >> Port Manager state machine. The forth patch is an interface between the >> Type-C Port Manager and a TCPCI (Type-C Port Controller Interface) compliant >> USB Type-C Port Controller. >> >> Patch 2/2 (the interface to a TCPCI compliant chip) is currently untested >> since I don't have the necessary hardware available. The port manager code >> was tested connecting to an Embedded Controller on a Chromebook, bypassing >> the Port Manager implementation in the EC. >> >> Both Source and Sink operation was tested with various Type-C chargers, >> docks, >> and connectors. Alternate mode support is partially implemented (Alternate >> mode >> support is requested from the partner), but alternate modes are not actually >> selected. Implementing this will require more thought, since the actual >> alternate mode support has to be implemented elsewhere, such as in a >> dedicated >> Phy driver. It should be possible to implement the interface between phy >> driver >> and Type-C Port Controller driver using extcon, but I have not further >> explored >> the possibilities, and other options might be possible and/or better. >> >> v3: >> - Improve TCPM state machine resiliency if there are spurious CC line changes >> while the state machine is in a transient change (waiting for a timeout) >> - Update current limit after CC voltage level changes on a port which is not >> PD capable. >> - Applies to v6 of "USB Type-C Connector class" patch series. >> >> v2: >> - Class code no longer uses locking, so the patch to remove it is no longer >> necessary. >> - tcpm: Only update polarity if setting it was successful >> If setting the CC line polarity in the driver was not successful, >> don't update the internal polarity state. >> - tcpm: All PD messages are little endian; convert to and from CPU >> endianness. >> - tcpm: Avoid comparisons against NULL. >> - tcpm: Use u8/u16/u32 instead of uint8_t/uint16_t/uint32_t consistently. >> - tcpm/tcpc: Callbacks into tcpm need to be lockless to avoid timing problems >> in low level drivers. >> - tcpm/tcpc: Simplify callbacks; tcpm can request the current state of >> cc/vbus >> when it is ready to use it. >> - Applies to v5 of "USB Type-C Connector class" patch series. > > I have not reviewed these yet completely, but so far the series looks > really good. Nice job! > > There are a lot of things that look generic and not tied to TCPCs, for > example the USB PD message handling. Couldn't those already be > separated from TCPM code or made otherwise available for non-TCPC > PHYs? The struct tcpc_dev looks to me like it would be usable for also > non-TCPC PHYs as is and enough for most cases. > Makes sense, if not for anything else to reduce file size. I'll see if I can separate it. Thanks, Guenter
Re: [PATCH 08/10] reset: sunxi: add driver Kconfig option
2016-08-24 22:29 GMT+09:00 Philipp Zabel : > Visible only if COMPILE_TEST is enabled, this allows to include the > driver in build tests. > > Signed-off-by: Philipp Zabel Reviewed-by: Masahiro Yamada -- Best Regards Masahiro Yamada
[PATCH] ALSA: snd-aoa: enable sound on PowerBook G4 12"
Enable sound on PowerBook G4 12".
Signed-off-by: Aaro Koskinen
---
sound/aoa/fabrics/layout.c | 8
sound/aoa/soundbus/i2sbus/core.c | 2 +-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/sound/aoa/fabrics/layout.c b/sound/aoa/fabrics/layout.c
index 8f71f7e..edc8681 100644
--- a/sound/aoa/fabrics/layout.c
+++ b/sound/aoa/fabrics/layout.c
@@ -112,6 +112,7 @@ MODULE_ALIAS("sound-layout-100");
MODULE_ALIAS("aoa-device-id-14");
MODULE_ALIAS("aoa-device-id-22");
+MODULE_ALIAS("aoa-device-id-31");
MODULE_ALIAS("aoa-device-id-35");
MODULE_ALIAS("aoa-device-id-44");
@@ -362,6 +363,13 @@ static struct layout layouts[] = {
.connections = tas_connections_nolineout,
},
},
+ /* PowerBook6,1 */
+ { .device_id = 31,
+ .codecs[0] = {
+ .name = "tas",
+ .connections = tas_connections_nolineout,
+ },
+ },
/* PowerBook6,5 */
{ .device_id = 44,
.codecs[0] = {
diff --git a/sound/aoa/soundbus/i2sbus/core.c b/sound/aoa/soundbus/i2sbus/core.c
index 1cbf210..000b585 100644
--- a/sound/aoa/soundbus/i2sbus/core.c
+++ b/sound/aoa/soundbus/i2sbus/core.c
@@ -197,7 +197,7 @@ static int i2sbus_add_dev(struct macio_dev *macio,
* so restrict to those we do handle for now.
*/
if (id && (*id == 22 || *id == 14 || *id == 35 ||
- *id == 44)) {
+ *id == 31 || *id == 44)) {
snprintf(dev->sound.modalias, 32,
"aoa-device-id-%d", *id);
ok = 1;
--
2.9.2
Re: [PATCH] ARM: EXYNOS: Clear OF_POPULATED flag from PMU node in IRQ init callback
On Wed, Aug 24, 2016 at 12:44 PM, Krzysztof Kozlowski wrote:
> On Sun, Aug 21, 2016 at 03:27:45AM -0400, Javier Martinez Canillas wrote:
>> The Exynos PMU node is an interrupt, clock and PMU (Power Management Unit)
>> controller, and these functionalities are supported by different drivers
>> that matches the same compatible strings.
>>
>> Since commit 15cc2ed6dcf9 ("of/irq: Mark initialised interrupt controllers
>> as populated") the OF core flags interrupt controllers registered with the
>> IRQCHIP_DECLARE() macro as OF_POPULATED, so platform devices with the same
>> compatible string as the interrupt controller will not be registered.
>>
>> This prevents the PMU platform device to be registered so the Exynos PMU
>> driver is never probed. This breaks (among other things) Suspend-to-RAM.
>>
>> Fix this by clearing the OF_POPULATED flag in the PMU IRQ init callback,
>> to allow the Exynos PMU platform driver to be probed. The patch is based
>> on Philipp Zabel's "ARM: imx6: mark GPC node as not populated after irq
>> init to probe pm domain driver".
>>
>> Fixes: 15cc2ed6dcf9 ("of/irq: Mark initialised interrupt controllers as
>> populated")
>> Signed-off-by: Javier Martinez Canillas
>>
>> ---
>>
>> This was tested on an Exynos5800 Peach Pi Chromebook with v4.8-rc2 +
>> Philipp's patch: https://patchwork.kernel.org/patch/9271361/
>>
>> arch/arm/mach-exynos/suspend.c | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
>> index 3750575c73c5..06332f626565 100644
>> --- a/arch/arm/mach-exynos/suspend.c
>> +++ b/arch/arm/mach-exynos/suspend.c
>> @@ -255,6 +255,12 @@ static int __init exynos_pmu_irq_init(struct
>> device_node *node,
>> return -ENOMEM;
>> }
>>
>> + /*
>> + * Clear the OF_POPULATED flag set in of_irq_init so that
>> + * later the Exynos PMU platform device won't be skipped.
>> + */
>> + of_node_clear_flag(node, OF_POPULATED);
>> +
>
> Looks like a proper workaround (at least till of_irq_init sets this flag
> before calling irq_init_cb()) however I have some more doubts:
>
> 1. The commit 15cc2ed6dcf9 ("of/irq: Mark initialised interrupt
> controllers as populated") might be also applied to clock CLK_OF_DECLARE
> and the problem will appear again.
We now know what to look for...
> 2. We are reusing PMU compatible for irqcip, clock provider and a
> platform driver. This is one PMU block with many features thus many
> drivers were created. What happens if the Exynos platform driver
> (drivers/soc/samsung/exynos-pmu.c) binds before irqchip or clk provider?
It can't. OF_DECLARE calls happen before initcalls*.
*I did find that IOMMU's are during initcalls which in my opinion is
wrong. But I think there is some plan to fix them to support deferred
probe and that should go away.
> Probably we should not reuse the compatible but create a new one for
> each type of driver? How does it match DeviceTree?
No, compatible strings are for h/w blocks, not drivers. Now, if you
need multiple platform drivers, then you should have 1 parent
device/driver that's bound from DT, then it can create any child
devices for specific functions.
Rob
Re: [PATCH 10/10] reset: hi6220: allow to compile test driver on other architectures
2016-08-24 22:29 GMT+09:00 Philipp Zabel : > Also remove the RESET_CONTROLLER dependency, this Kconfig file is > included inside the menuconfig already. > > Cc: Chen Feng > Signed-off-by: Philipp Zabel > --- > drivers/reset/hisilicon/Kconfig | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/reset/hisilicon/Kconfig b/drivers/reset/hisilicon/Kconfig > index 26bf95a..1ff8b0c 100644 > --- a/drivers/reset/hisilicon/Kconfig > +++ b/drivers/reset/hisilicon/Kconfig > @@ -1,5 +1,6 @@ > config COMMON_RESET_HI6220 > tristate "Hi6220 Reset Driver" > - depends on (ARCH_HISI && RESET_CONTROLLER) > + depends on ARCH_HISI || COMPILE_TEST > + default ARCH_HISI > help > Build the Hisilicon Hi6220 reset driver. > -- > 2.8.1 > As you see obj-$(CONFIG_ARCH_HISI) += hisilicon/ in drivers/reset/Makefile, Kbuild can descend into drivers/reset/hisilicon/ only when CONFIG_ARCH_HISI is enabled. So, this patch does not add compile-test'ability. Currently, I only see a single file in drivers/reset/hisilicon/ directory, but perhaps they might be planning to add more reset drivers for other Hisilicon SoCs in the future. Change to obj-y += hisilicon/ or create "config RESET_HISI" as a vendor-common option and obj-$(CONFIG_RESET_HISI) += hisilicon/ ? -- Best Regards Masahiro Yamada
[RFC][PATCH] ASoC: rt5659: Fix incorrect register addresses
According to the datasheets of Realtek ALC5658 (Rev. 0.9) and ALC5659 (Rev. 0.13), the "IRQ Control 4" register is located at MX-00BAh while the "IRQ control 5" register is at MX-00BBh. There is no "IRQ Control 6" register in the datasheets but it is supposed to be behind the "IRQ Control 5" register. So this patch corrects these addresses. Signed-off-by: Nicolin Chen --- Hi Mark, This patch needs the confirmation from Realtek side (hoping that at least Bard or Oder would give an Ack) as the datasheets that I have might not reflect the latest register map. And the datasheets don't seem to be directly downloadable from Realtek website. sound/soc/codecs/rt5659.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/soc/codecs/rt5659.h b/sound/soc/codecs/rt5659.h index d69b0eb..8f1aeef 100644 --- a/sound/soc/codecs/rt5659.h +++ b/sound/soc/codecs/rt5659.h @@ -180,9 +180,9 @@ #define RT5659_IRQ_CTRL_1 0x00b6 #define RT5659_IRQ_CTRL_2 0x00b7 #define RT5659_IRQ_CTRL_3 0x00b8 -#define RT5659_IRQ_CTRL_4 0x00b9 -#define RT5659_IRQ_CTRL_5 0x00ba -#define RT5659_IRQ_CTRL_6 0x00bb +#define RT5659_IRQ_CTRL_4 0x00ba +#define RT5659_IRQ_CTRL_5 0x00bb +#define RT5659_IRQ_CTRL_6 0x00bc #define RT5659_INT_ST_10x00be #define RT5659_INT_ST_20x00bf #define RT5659_GPIO_CTRL_1 0x00c0 -- 2.1.4
Re: [PATCH tip/core/rcu 2/2] documentation: Record reason for rcu_head two-byte alignment
On Tue, Aug 23, 2016 at 07:23:26AM -0700, Paul E. McKenney wrote:
> On Tue, Aug 23, 2016 at 03:45:51PM +0200, Geert Uytterhoeven wrote:
> > Hi Paul,
> >
> > On Tue, Aug 23, 2016 at 3:43 PM, Paul E. McKenney
> > wrote:
> > > On Tue, Aug 23, 2016 at 08:39:18AM +0200, Geert Uytterhoeven wrote:
> > >> On Mon, Aug 22, 2016 at 11:16 PM, Paul E. McKenney
> > >> wrote:
> > >> > On Mon, Aug 22, 2016 at 10:48:57PM +0200, Geert Uytterhoeven wrote:
> > >> >> On Mon, Aug 22, 2016 at 9:54 PM, Paul E. McKenney
> > >> >> wrote:
> > >> >> > On Mon, Aug 22, 2016 at 03:18:54PM -0400, Steven Rostedt wrote:
> > >> >> >> On Mon, 22 Aug 2016 20:56:09 +0200
> > >> >> >> Peter Zijlstra wrote:
> > >> >> >>
> > >> >> >> > > Don't we have __alignof__(void *) to avoid #ifdef CONFIG_M68K
> > >> >> >> > > and
> > >> >> >> > > other new macros ?
> > >> >> >
> > >> >> > Hmmm... Does __alignof__(void *) give two-byte alignment on m68k,
> > >> >> > allowing something like this? Heh!!! It is already there. ;-)
> > >> >> >
> > >> >> > struct callback_head {
> > >> >> > struct callback_head *next;
> > >> >> > void (*func)(struct callback_head *head);
> > >> >> > } __attribute__((aligned(sizeof(void *;
> > >> >>
> > >> >> No, it's aligning to sizeof(void *) (4 on m68k), not __alignof__(void
> > >> >> *).
> > >> >
> > >> > Right you are. Commit 720abae3d68ae from Kirill A. Shutemov in
> > >> > November
> > >> > 2015.
> > >> >
> > >> > Given that you haven't complained, I am guessing that this works for
> > >> > you.
> > >> > If so, I can make the __call_rcu() WARN_ON() more strict.
> > >> > Again, does the current state work for you?
> >
> > >> Yes it does. See also your commit 1146edcbef378922 ("rcu: Loosen
> > >> __call_rcu()'s
> > >> rcu_head alignment constraint").
> > >
> > > Understood!
> > >
> > > But given that all architectures now provide at least four-byte alignment
> > > for the rcu_head structure, isn't it now OK for me to tighten up
> > > __call_rcu()'s
> > > check, for example, to this?
> > >
> > > WARN_ON_ONCE((unsigned long)head & (sizeof(void *) - 1));
> >
> > Yes, I agree with that.
>
> Very good, I have queued the following patch.
>
> Thanx, Paul
>
>
>
> commit 89d39c83d193733ed5fff1c480cd42c9de1da404
> Author: Paul E. McKenney
> Date: Tue Aug 23 06:51:47 2016 -0700
>
> rcu: Tighted up __call_rcu() rcu_head alignment check
>
> Commit 720abae3d68ae ("rcu: force alignment on struct
> callback_head/rcu_head") forced the rcu_head (AKA callback_head)
> structure's alignment to pointer size, that is, to 4-byte boundaries on
> 32-bit systems and to 8-byte boundaries on 64-bit systems. This
> commit therefore checks for this same alignment in __call_rcu(),
> which used to check for two-byte alignment.
>
> Signed-off-by: Paul E. McKenney
> Cc: Geert Uytterhoeven
> Cc: Kirill A. Shutemov
Looks good to me.
Acked-by: Kirill A. Shutemov
--
Kirill A. Shutemov
Applied "ASoC: simple-card-utils: add __printf attribute" to the asoc tree
The patch ASoC: simple-card-utils: add __printf attribute has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From e5668caec5698f14f310fb06bb39595b21d2fe4a Mon Sep 17 00:00:00 2001 From: Nicolas Iooss Date: Tue, 23 Aug 2016 10:51:22 +0200 Subject: [PATCH] ASoC: simple-card-utils: add __printf attribute asoc_simple_card_set_dailink_name() uses devm_kvasprintf() to format some of its arguments. Adding a __printf attribute to this function makes it possible to detect at compile-time errors related to format strings. Signed-off-by: Nicolas Iooss Signed-off-by: Mark Brown --- include/sound/simple_card_utils.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/sound/simple_card_utils.h b/include/sound/simple_card_utils.h index 403ec92164fc..fd6412551145 100644 --- a/include/sound/simple_card_utils.h +++ b/include/sound/simple_card_utils.h @@ -27,6 +27,7 @@ int asoc_simple_card_parse_daifmt(struct device *dev, struct device_node *codec, char *prefix, unsigned int *retfmt); +__printf(3, 4) int asoc_simple_card_set_dailink_name(struct device *dev, struct snd_soc_dai_link *dai_link, const char *fmt, ...); -- 2.8.1
Re: [Regression?] Commit cb4f71c429 deliberately changes order of network interfaces
On Wed, Aug 24, 2016 at 07:10:04PM +0200, Ralph Sennhauser wrote: > And in how many places this discrepancy was documented? You won't be > able to update them all. Mailing lists, blogs, fora posts and what ever > else. I'd say the damage is done and can't be fixed by simply changing > the order now. > > Whether strong rule or not, obviously it went in so bending the rule is > at least accepted. It's not what I have an issue with but with the > reordering at this point. > > I'm clearly not convinced reverting would do more harm than good, > otherwise I wouldn't have brought it up. I would agree, although if you see below I think it maybe something that user space will have to figure out a way to deal with sooner or later anyhow. > It's not about being able to fix the code or documentation but about > having to do so in the first place. > > The nice thing about having the order in the dtb I thought was that it > wont ever change. I wonder, if someone was to build a box with this cpu, and add a PCIe network device, which order would they get probed in? Any chance the PCIe could grab eth0 before the mvneta devices get probed? I also would not count on this not changing in the future potentially by accident. The mmc block devices used to get probed in DTB order, then that changed at some point and reordering the dtb no longer controlled it, rather it was whichever device seemed to finish fastests, and then later that was changed to using the controller's opinion of the device number (which at least made it predicable again, even if not controllable from the dtb). So at the moment the dtb order controls ethernet probe order. Well if other things have stopped doing that, why expect ethernet won't some day stop doing that too? "Fixing" the port numbering by reordering is hence a hack as far as I am concerned and not certain to stay working long term. > Going forward, as we disagree and it's basically a political decision, > whom do we ask to rule here? Linus? -- Len Sorensen
Re: [PATCH 04/11] sched,x86: Enable Turbo Boost Max Technology
* Tim Chen wrote: > Ingo, > > This feature will be a clear benefit for client machines and > less clear on servers. > > This feature is most beneficial to single threaded workload running on > a single socket that operates in mostly Turbo mode. Client platform > like Broadwell High End Desktop is the first one that supports it. > Enablng this feature for such platform by default will be a win as it > runs single threaded workload much of the time (10%-15% peformance > upside). > > On the other hand, a heavily loaded server that rarely operates in Turbo > mode will benefit much less from this feature. There is some overhead > incurred by migrating load to the favored cores. Some server folks > have asked us to be cautious here and not to turn on ITMT scheduling > by default. Even so, when the server is lightly loaded, this feature > can still be a win. That said, this is future looking as we don't have > any server with this feature today. > > So if we take the approach to enable this feature by default for only > single node system (using that as a criteria for client), will that seem > reasonable to you? I suppose that would work. Peter, any objections to such an approach? Thanks, Ingo
Re: [PATCH 06/10] reset: socfpga: add driver Kconfig option
Hi Philipp, just a minor nit: On 08/24/2016 08:28 AM, Philipp Zabel wrote: > Visible only if COMPILE_TEST is enabled, this allows to include the > driver in build tests. > > Cc: Dinh Nguyen > Signed-off-by: Philipp Zabel > --- > drivers/reset/Kconfig | 6 ++ > drivers/reset/Makefile | 2 +- > 2 files changed, 7 insertions(+), 1 deletion(-) > > diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig > index 6ac631e..354e281 100644 > --- a/drivers/reset/Kconfig > +++ b/drivers/reset/Kconfig > @@ -49,6 +49,12 @@ config RESET_PISTACHIO > help > This enables the reset driver for ImgTec Pistachio SoCs. > > +config RESET_SOCFPGA > + bool "SoC FPGA Reset Driver" if COMPILE_TEST Prefer to be "SoCFPGA", no space in between. > + default ARCH_SOCFPGA > + help > + This enables the reset driver for Altera SoC FPGAs. Same here... > + > config TI_SYSCON_RESET > tristate "TI SYSCON Reset Driver" > depends on HAS_IOMEM > diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile > index c796a14..61e4c64 100644 > --- a/drivers/reset/Makefile > +++ b/drivers/reset/Makefile > @@ -1,5 +1,4 @@ > obj-y += core.o > -obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o > obj-$(CONFIG_ARCH_STM32) += reset-stm32.o > obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o > obj-$(CONFIG_ARCH_STI) += sti/ > @@ -11,5 +10,6 @@ obj-$(CONFIG_RESET_LPC18XX) += reset-lpc18xx.o > obj-$(CONFIG_RESET_MESON) += reset-meson.o > obj-$(CONFIG_RESET_OXNAS) += reset-oxnas.o > obj-$(CONFIG_RESET_PISTACHIO) += reset-pistachio.o > +obj-$(CONFIG_RESET_SOCFPGA) += reset-socfpga.o > obj-$(CONFIG_TI_SYSCON_RESET) += reset-ti-syscon.o > obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o > Otherwise, Acked-by: Dinh Nguyen Thanks, Dinh
Re: [Regression?] Commit cb4f71c429 deliberately changes order of network interfaces
Hello, On Wed, 24 Aug 2016 14:07:27 -0400, Lennart Sorensen wrote: > > The nice thing about having the order in the dtb I thought was that it > > wont ever change. > > I wonder, if someone was to build a box with this cpu, and add a PCIe > network device, which order would they get probed in? Any chance the > PCIe could grab eth0 before the mvneta devices get probed? Depends on the network driver I believe. But with an e1000e NIC plugged in a PCIe slot, it indeed gets assigned as eth0, and the internal mvneta devices get eth1, eth2, etc. Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Re: of_clk_add_(hw_)providers multipule times for one node?
(Please trim replies)
On 08/24, Masahiro Yamada wrote:
>
> Looks like the whole of my series was rejected,
> but I was not sure why the following one was rejected.
> https://patchwork.kernel.org/patch/9236563/
>
Replying to that patch would have been better.
>
> Could you explain why -EPROBE_DEFER should be returned
> if both .get_hw and .get are missing.
That's just a bug. Perhaps this patch would be better, and look,
it saves 5 lines.
---8<
drivers/clk/clk.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 71cc56712666..d3d26148cdfb 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -3174,19 +3174,14 @@ __of_clk_get_hw_from_provider(struct of_clk_provider
*provider,
struct of_phandle_args *clkspec)
{
struct clk *clk;
- struct clk_hw *hw = ERR_PTR(-EPROBE_DEFER);
- if (provider->get_hw) {
- hw = provider->get_hw(clkspec, provider->data);
- } else if (provider->get) {
- clk = provider->get(clkspec, provider->data);
- if (!IS_ERR(clk))
- hw = __clk_get_hw(clk);
- else
- hw = ERR_CAST(clk);
- }
+ if (provider->get_hw)
+ return provider->get_hw(clkspec, provider->data);
- return hw;
+ clk = provider->get(clkspec, provider->data);
+ if (IS_ERR(clk))
+ return ERR_CAST(clk);
+ return __clk_get_hw(clk);
}
struct clk *__of_clk_get_from_provider(struct of_phandle_args *clkspec,
>
>
> Is there a way to register an OF clk provider without .get(_hw),
> but fill it later or something?
>
No.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH] scripts: add ksymbolize.py
On Wed, Aug 24, 2016 at 12:37:35PM -0400, Alexander Potapenko wrote: > he script that symbolizes BUG messages and KASAN error reports > by adding file:line information to each stack frame. > The script is a copy of > https://github.com/google/sanitizers/blob/master/address-sanitizer/tools/kasan_symbolize.py > , originally written by Andrey Konovalov. So what's the difference between this script and scripts/decode_stacktrace.sh that already lives upstream? Thanks, Sasha
Re: [PATCH 1/2] arm64: kernel: Add SMC Session ID to results
On Fri 19 Aug 22:51 PDT 2016, Andy Gross wrote:
> This patch adds the SMC Session ID to the results passed back from SMC
> calls. The Qualcomm SMC implementation provides for interrupted SMC
> functions. When this occurs, the SMC call will return a session ID that
> is required to be used when resuming the interrupted SMC call.
>
> Signed-off-by: Andy Gross
This fixes the spurious remoteproc firmware authentication failures I've
seen lately.
Tested-by: Bjorn Andersson
Regards,
Bjorn
> ---
> arch/arm64/kernel/asm-offsets.c | 1 +
> arch/arm64/kernel/smccc-call.S | 1 +
> include/linux/arm-smccc.h | 4 +++-
> 3 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
> index 05070b7..ff38c58 100644
> --- a/arch/arm64/kernel/asm-offsets.c
> +++ b/arch/arm64/kernel/asm-offsets.c
> @@ -141,6 +141,7 @@ int main(void)
> #endif
>DEFINE(ARM_SMCCC_RES_X0_OFFS, offsetof(struct arm_smccc_res, a0));
>DEFINE(ARM_SMCCC_RES_X2_OFFS, offsetof(struct arm_smccc_res, a2));
> + DEFINE(ARM_SMCCC_RES_X6_OFFS, offsetof(struct arm_smccc_res, a6));
>BLANK();
>DEFINE(HIBERN_PBE_ORIG,offsetof(struct pbe, orig_address));
>DEFINE(HIBERN_PBE_ADDR,offsetof(struct pbe, address));
> diff --git a/arch/arm64/kernel/smccc-call.S b/arch/arm64/kernel/smccc-call.S
> index ae0496f..278dc9a 100644
> --- a/arch/arm64/kernel/smccc-call.S
> +++ b/arch/arm64/kernel/smccc-call.S
> @@ -20,6 +20,7 @@
> ldr x4, [sp]
> stp x0, x1, [x4, #ARM_SMCCC_RES_X0_OFFS]
> stp x2, x3, [x4, #ARM_SMCCC_RES_X2_OFFS]
> + str x6, [x4, #ARM_SMCCC_RES_X6_OFFS]
> ret
> .cfi_endproc
> .endm
> diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
> index b5abfda..82d919f 100644
> --- a/include/linux/arm-smccc.h
> +++ b/include/linux/arm-smccc.h
> @@ -63,18 +63,20 @@
> /**
> * struct arm_smccc_res - Result from SMC/HVC call
> * @a0-a3 result values from registers 0 to 3
> + * @a6 Session ID register (optional)
> */
> struct arm_smccc_res {
> unsigned long a0;
> unsigned long a1;
> unsigned long a2;
> unsigned long a3;
> + unsigned long a6;
> };
>
> /**
> * arm_smccc_smc() - make SMC calls
> * @a0-a7: arguments passed in registers 0 to 7
> - * @res: result values from registers 0 to 3
> + * @res: result values from registers 0 to 3 and optional register 6
> *
> * This function is used to make SMC calls following SMC Calling Convention.
> * The content of the supplied param are copied to registers 0 to 7 prior
> --
> 1.9.1
>
Re: [PATCH 01/10] reset: ath79: add driver Kconfig option
Hi Arnd, 2016-08-25 0:51 GMT+09:00 Arnd Bergmann : > On Wednesday, August 24, 2016 3:28:53 PM CEST Philipp Zabel wrote: >> if RESET_CONTROLLER >> >> +config RESET_ATH79 >> + bool "AR71xx Reset Driver" if COMPILE_TEST >> + default ATH79 >> + help >> + This enables the ATH79 reset controller driver that supports the >> + AR71xx SoC reset controller. >> + >> > > Nice series! > > Just note that there is one possible problem with COMPILE_TEST > when the platforms are enabled, as you can then disable a driver > that is normally there, and that can in turn cause problems in > rare cases, e.g. when the driver has a global function that is > called from platform code. I don't know if any of the drivers > do that, but if they do, you'd have to use > > config RESET_ATH79 >bool "AR71xx Reset Driver" if COMPILE_TEST && !ATH79 >default ATH79 > > to ensure that it's impossible to disable the driver on platforms > that require it. Hmm, Can we do this only when we really have to do so? I think we should not care about such a rare case that may not happen. Let's start with only "if COMPILE_TEST", and take a look at it if a build error is detected. Anyway, depending on platform code is a sign of weird implementation. It might be better to find a potential issue rather than hide it. -- Best Regards Masahiro Yamada
Re: [PATCH] MAINTAINERS: add linux-su...@googlegroups.com as list for sunxi arch
Hi, On Thu, Aug 18, 2016 at 02:14:17PM +0200, LABBE Corentin wrote: > All discutions about sunxi architecture is done > on linux-su...@googlegroups.com. > This patch add it as list on drivers for this arch. > > Signed-off-by: LABBE Corentin > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index a306795..6254eb1 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -980,6 +980,7 @@ ARM/Allwinner sunXi SoC support > M: Maxime Ripard > M: Chen-Yu Tsai > L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) > +L: linux-su...@googlegroups.com I don't want a mailing list hosted on google groups to be added to MAINTAINERS. We can ask for one on kernel.org though if people feel like it's relevant. Nobody cared for a few years, so I guess it would be a no, but if others feel like it... Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH 04/11] sched,x86: Enable Turbo Boost Max Technology
On Wed, Aug 24, 2016 at 08:08:54PM +0200, Ingo Molnar wrote: > > > > So if we take the approach to enable this feature by default for only > > single node system (using that as a criteria for client), will that seem > > reasonable to you? > > I suppose that would work. Peter, any objections to such an approach? Works for me. Thanks!
Re: [PATCH] ARM: EXYNOS: Clear OF_POPULATED flag from PMU node in IRQ init callback
On Wed, Aug 24, 2016 at 12:57:29PM -0500, Rob Herring wrote:
> On Wed, Aug 24, 2016 at 12:44 PM, Krzysztof Kozlowski wrote:
> > On Sun, Aug 21, 2016 at 03:27:45AM -0400, Javier Martinez Canillas wrote:
> >> The Exynos PMU node is an interrupt, clock and PMU (Power Management Unit)
> >> controller, and these functionalities are supported by different drivers
> >> that matches the same compatible strings.
> >>
> >> Since commit 15cc2ed6dcf9 ("of/irq: Mark initialised interrupt controllers
> >> as populated") the OF core flags interrupt controllers registered with the
> >> IRQCHIP_DECLARE() macro as OF_POPULATED, so platform devices with the same
> >> compatible string as the interrupt controller will not be registered.
> >>
> >> This prevents the PMU platform device to be registered so the Exynos PMU
> >> driver is never probed. This breaks (among other things) Suspend-to-RAM.
> >>
> >> Fix this by clearing the OF_POPULATED flag in the PMU IRQ init callback,
> >> to allow the Exynos PMU platform driver to be probed. The patch is based
> >> on Philipp Zabel's "ARM: imx6: mark GPC node as not populated after irq
> >> init to probe pm domain driver".
> >>
> >> Fixes: 15cc2ed6dcf9 ("of/irq: Mark initialised interrupt controllers as
> >> populated")
> >> Signed-off-by: Javier Martinez Canillas
> >>
> >> ---
> >>
> >> This was tested on an Exynos5800 Peach Pi Chromebook with v4.8-rc2 +
> >> Philipp's patch: https://patchwork.kernel.org/patch/9271361/
> >>
> >> arch/arm/mach-exynos/suspend.c | 6 ++
> >> 1 file changed, 6 insertions(+)
> >>
> >> diff --git a/arch/arm/mach-exynos/suspend.c
> >> b/arch/arm/mach-exynos/suspend.c
> >> index 3750575c73c5..06332f626565 100644
> >> --- a/arch/arm/mach-exynos/suspend.c
> >> +++ b/arch/arm/mach-exynos/suspend.c
> >> @@ -255,6 +255,12 @@ static int __init exynos_pmu_irq_init(struct
> >> device_node *node,
> >> return -ENOMEM;
> >> }
> >>
> >> + /*
> >> + * Clear the OF_POPULATED flag set in of_irq_init so that
> >> + * later the Exynos PMU platform device won't be skipped.
> >> + */
> >> + of_node_clear_flag(node, OF_POPULATED);
> >> +
> >
> > Looks like a proper workaround (at least till of_irq_init sets this flag
> > before calling irq_init_cb()) however I have some more doubts:
> >
> > 1. The commit 15cc2ed6dcf9 ("of/irq: Mark initialised interrupt
> > controllers as populated") might be also applied to clock CLK_OF_DECLARE
> > and the problem will appear again.
>
> We now know what to look for...
D'oh!
If you gonna apply this to clock providers, please let us know (or apply
workaround to drivers/clk/samsung/clk-exynos-clkout.c).
>
> > 2. We are reusing PMU compatible for irqcip, clock provider and a
> > platform driver. This is one PMU block with many features thus many
> > drivers were created. What happens if the Exynos platform driver
> > (drivers/soc/samsung/exynos-pmu.c) binds before irqchip or clk provider?
>
> It can't. OF_DECLARE calls happen before initcalls*.
>
> *I did find that IOMMU's are during initcalls which in my opinion is
> wrong. But I think there is some plan to fix them to support deferred
> probe and that should go away.
>
> > Probably we should not reuse the compatible but create a new one for
> > each type of driver? How does it match DeviceTree?
>
> No, compatible strings are for h/w blocks, not drivers. Now, if you
> need multiple platform drivers, then you should have 1 parent
> device/driver that's bound from DT, then it can create any child
> devices for specific functions.
Thanks for explanation.
For the Javier's patch itself, applied.
Best regards,
Krzysztof
Re: [PATCH v2] perf/x86/amd: Make HW_CACHE_REFERENCES and HW_CACHE_MISSES measure L2
On Wed, Aug 24, 2016 at 04:55:14PM +0200, Borislav Petkov wrote: > On Wed, Aug 24, 2016 at 02:12:08PM +0100, Matt Fleming wrote: > > While the Intel PMU monitors the LLC when perf enables the > > HW_CACHE_REFERENCES and HW_CACHE_MISSES events, these events monitor > > L1 instruction cache fetches (0x0080) and instruction cache misses > > (0x0081) on the AMD PMU. > > > > This is extremely confusing when monitoring the same workload across > > Intel and AMD machines, since parameters like, > > > > $ perf stat -e cache-references,cache-misses > > > > measure completely different things. > > > > Instead, make the AMD PMU measure instruction/data cache and TLB fill > > requests to the L2 and instruction/data cache and TLB misses in the L2 > > when HW_CACHE_REFERENCES and HW_CACHE_MISSES are enabled, > > respectively. That way the events measure unified caches on both > > platforms. > > I'm still not really sure about this: we can't really compare L3 to L2 > access patterns - it is almost as comparing apples to oranges. Can we > use the Intel L2 events instead? They're not meant to be comparable between machines. I wouldn't even compare the LLC numbers between two different Intel parts. These events are meant to profile a workload on the machine you run them on. Big cache-miss/ref ratios indicate you loose performance because of the memory subsystem and or data structure layout. And afaict AMD parts, even those that have L3, cannot provide L3 numbers on a per task basis, so these L2 numbers are the best we have.
Re: [Regression?] Commit cb4f71c429 deliberately changes order of network interfaces
On Wed, Aug 24, 2016 at 08:14:44PM +0200, Thomas Petazzoni wrote: > Depends on the network driver I believe. But with an e1000e NIC plugged > in a PCIe slot, it indeed gets assigned as eth0, and the internal > mvneta devices get eth1, eth2, etc. Which of course means the change does not actually ensure the port ordering matches the marvell documentation or u-boot. It only handles the relative order of the ports. For now. So since it doesn't actually work, maybe reverting it so it no longer violates the dtb ordeting rule makes sense. Doesn't mean openwrt/lede/etc don't have to deal with the ordering in the future if async probing takes off. -- Len Sorensen
Partnership Cooperation
Dear Friend, Your contact details came to me by recommendation, I am interested in investing in your country and I believe you have the capabilities of providing the needed assistance, solutions and advise in actualizing this, Let me know if you are willing to understake this task for me so we can discuss more. I hope to hear from you soon. Regards, Sheikh Maktoum Hasher Al Maktoum Chairman/Chief Executive Officer Dubai International Holding Company. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[PATCH] clk: rockchip: mark aclk_emmc_noc as a critical clock on rk3399
From: Xing Zheng
We don't have code to handle any of the noc clocks in rk3399 and they're
all just listed as critical clocks. Let's do the same for
aclk_emmc_noc.
Without this clock being marked as critical we have problems around
suspend/resume after commit 20c389e656a8 ("clk: rockchip: fix incorrect
aclk_emmc source gate bits on rk3399"). Before that change we were
presumably not actually gating any of these clocks because we were
setting the wrong gate.
Signed-off-by: Xing Zheng
Signed-off-by: Douglas Anderson
---
drivers/clk/rockchip/clk-rk3399.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/rockchip/clk-rk3399.c
b/drivers/clk/rockchip/clk-rk3399.c
index e445cd64952a..ede6c475b537 100644
--- a/drivers/clk/rockchip/clk-rk3399.c
+++ b/drivers/clk/rockchip/clk-rk3399.c
@@ -1489,6 +1489,7 @@ static const char *const rk3399_cru_critical_clocks[]
__initconst = {
"hclk_perilp1",
"hclk_perilp1_noc",
"aclk_dmac0_perilp",
+ "aclk_emmc_noc",
"gpll_hclk_perilp1_src",
"gpll_aclk_perilp0_src",
"gpll_aclk_perihp_src",
--
2.8.0.rc3.226.g39d4020
[PATCH v2 0/2] KVM: s390: Fine-tuning for kvm_s390_import_bp_data()
From: Markus Elfring Date: Wed, 24 Aug 2016 20:20:02 +0200 A few update suggestions were taken into account from static source code analysis. Markus Elfring (2): Improve determination of sizes Use memdup_user() rather than duplicating code arch/s390/kvm/guestdbg.c | 31 +-- 1 file changed, 13 insertions(+), 18 deletions(-) -- 2.9.3
Re: [PATCH 3/6] x86/dumpstack: make printk_stack_address() more generally useful
On Wed, Aug 24, 2016 at 2:22 PM, Peter Zijlstra wrote: > > I actively disable KASLR on my dev box and feed these hex numbers into > addr2line -ie vmlinux to find where in the function we are. > > Having the option to make %pB generate them works for me. Yeah, considering that this is the only place this is used, changing %pB sounds quite reasonable. We could perhaps make %pB show the hex numbers and address (so pB would expand to "[] symbolname".if (a) not randomizing (so the hex numbers _may_ be useful) (b) kptr_restrict is 0 (so the hex numbers are "safe" in the dmesg) and fall back to just the symbolic name if either of those aren't true? And obviously, if KALLSYMS isn't enabled, you always show hex numbers.. That's already the case (but we might want to add the "[<>}' markers around the hex numbers just to make the user space automation we do have work). Linus
Re: [Regression?] Commit cb4f71c429 deliberately changes order of network interfaces
Hello, On Wed, 24 Aug 2016 19:10:04 +0200, Ralph Sennhauser wrote: > Going forward, as we disagree and it's basically a political decision, > whom do we ask to rule here? Linus? I don't think Linus will care about random issues on a random platform :-) The people who can take this decision are rather the maintainers of the platform itself, or possibly the arm-soc maintainers if you still don't like what the platform maintainers decided. Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Re: [PATCH v2] PCI: altera: Retrain link in rootport mode only
Hi Bjorn, Ray is off this week and will likely have some comments next week. On 16-08-24 10:54 AM, Bjorn Helgaas wrote: [+cc Ray, Scott, Jon, bcm-kernel-feedback-list] On Wed, Aug 24, 2016 at 03:07:52PM +0800, Ley Foon Tan wrote: On Mon, Aug 22, 2016 at 11:47 PM, Bjorn Helgaas wrote: On Fri, Aug 19, 2016 at 04:24:38PM +0800, Ley Foon Tan wrote: Altera PCIe IP can be configured as rootport or device and they might have same vendor ID. It will cause the system hang issue if Altera PCIe is in endpoint mode and work with other PCIe rootport that from other vendors. So, add the rootport mode checking in link retrain fixup function. Signed-off-by: Ley Foon Tan --- v2: change to check PCIe type is PCI_EXP_TYPE_ROOT_PORT --- drivers/pci/host/pcie-altera.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/pci/host/pcie-altera.c b/drivers/pci/host/pcie-altera.c index 58eef99..33b6968 100644 --- a/drivers/pci/host/pcie-altera.c +++ b/drivers/pci/host/pcie-altera.c @@ -139,6 +139,9 @@ static void altera_pcie_retrain(struct pci_dev *dev) u16 linkcap, linkstat; struct altera_pcie *pcie = dev->bus->sysdata; + if (pci_pcie_type(dev) != PCI_EXP_TYPE_ROOT_PORT) + return; + if (!altera_pcie_link_is_up(pcie)) return; Instead of making this a PCI fixup, can you make an altera_pcie_host_init() function, call it from altera_pcie_probe(), and do the link retrain there? Then you wouldn't need to worry about whether this is a Root Port or an Endpoint, plus it would make the altera driver structure more like the other drivers. You would call altera_pcie_host_init() before pci_scan_root_bus(), so you wouldn't have a pci_dev yet, so you wouldn't be able to use pcie_capability_set_word() to set the PCI_EXP_LNKCTL_RL bit. But I assume there's some device-dependent way to access it using cra_writel()? We can't use cra_write() to set PCI_EXP_LNKCTL_RL bit. Why not? I don't mean it has to be cra_write(), but isn't there some way you can write that bit before we scan the root bus? It doesn't make sense that we have to scan the bus before we can train the link. We want to be able to tell the PCI core "all the device-specific root complex initialization has been done, here are the config accessors you need, please scan for devices." I want to keep device-specific things like this quirk directly in the driver and out of the enumeration process. We can use pci_bus_find_capability() and pci_bus_read_config_word() with struct pci_bus instead. But this only can be called after pci_scan_root_bus(). Found iproc_pcie_check_link() have similar implementation. You're right, and I don't like iproc_pcie_check_link() either, for the same reasons. The iproc_pcie_check_link() is a little better because it's called before enumeration: pci_create_root_bus() iproc_pcie_check_link() pci_scan_child_bus() But it would be a lot better if iproc_pcie_check_link() were done first, before pci_create_root_bus(). Then it would be more like the structure of other drivers, and we could use pci_scan_root_bus() instead. Comments, iproc folks? Bjorn Regards, Scott
Re: [RFC PATCH-tip v4 10/10] locking/rwsem: Add a boot parameter to reader spinning threshold
On 08/24/2016 12:00 AM, Davidlohr Bueso wrote: On Thu, 18 Aug 2016, Waiman Long wrote: The default reader spining threshold is current set to 4096. However, the right reader spinning threshold may vary from one system to another and among the different architectures. This patch adds a new kernel boot parameter to modify the threshold value. This enables better tailoring to the needs of different systems as well as for testing purposes. It also means that those systems could very easily be incorrectly tailored. (and worse case scenario: reboot, is obviously a terrible way to get rid of any issues). I very much disagree with exposing this sort of core stuff, it should work well for everyone out of the box, not relying on users to properly configure this. Thanks, Davidlohr I also have some concern about exposing this kernel parameter as it will be hard to tune. That is why I put it at the end to gauge the opinion of others. I will leave this out when I send out the next version. Cheers, Longman
[PATCH 2/2] procfs/tasks: add a simple per-task procfs hidepid= field
This adds a new per-task hidepid= flag that is honored by procfs when
presenting /proc to the user, in addition to the existing hidepid= mount
option. So far, hidepid= was exclusively a per-pidns setting. Locking
down a set of processes so that they cannot see other user's processes
without affecting the rest of the system thus currently requires
creation of a private PID namespace, with all the complexity it brings,
including maintaining a stub init process as PID 1 and losing the
ability to see processes of the same user on the rest of the system.
With this patch all acesss and visibility checks in procfs now
honour two fields:
a) the existing hide_pid field in the PID namespace
b) the new hide_pid in struct task_struct
Access/visibility is only granted if both fields permit it; the more
restrictive one wins. By default the new task_struct hide_pid value
defaults to 0, which means behaviour is not changed from the status quo.
Setting the per-process hide_pid value is done via a new PR_SET_HIDEPID
prctl() option which takes the same three supported values as the
hidepid= mount option. The per-process hide_pid may only be increased,
never decreased, thus ensuring that once applied, processes can never
escape such a hide_pid jail. When a process forks it inherits its
parent's hide_pid value.
Suggested usecase: let's say nginx runs as user "www-data". After
dropping privileges it may now call:
…
prctl(PR_SET_HIDEPID, 2);
…
And from that point on neither nginx itself, nor any of its child
processes may see processes in /proc anymore that belong to a different
user than "www-data". Other services running on the same system remain
unaffected.
This should permit Linux distributions to more comprehensively lock down
their services, as it allows an isolated opt-in for hidepid= for
specific services. Previously hidepid= could only be set system-wide,
and then specific services had to be excluded by group membership,
essentially a more complex concept of opt-out.
Signed-off-by: Lafcadio Wluiki
---
fs/proc/array.c| 4
fs/proc/base.c | 6 --
include/linux/init_task.h | 1 +
include/linux/sched.h | 1 +
include/uapi/linux/prctl.h | 4
kernel/fork.c | 1 +
kernel/sys.c | 10 ++
7 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/fs/proc/array.c b/fs/proc/array.c
index 88c7de1..a0c1151 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -163,6 +163,7 @@ static inline void task_state(struct seq_file *m, struct
pid_namespace *ns,
const struct cred *cred;
pid_t ppid, tpid = 0, tgid, ngid;
unsigned int max_fds = 0;
+ int hide_pid;
rcu_read_lock();
ppid = pid_alive(p) ?
@@ -183,6 +184,7 @@ static inline void task_state(struct seq_file *m, struct
pid_namespace *ns,
task_lock(p);
if (p->files)
max_fds = files_fdtable(p->files)->max_fds;
+ hide_pid = p->hide_pid;
task_unlock(p);
rcu_read_unlock();
@@ -195,6 +197,7 @@ static inline void task_state(struct seq_file *m, struct
pid_namespace *ns,
"TracerPid:\t%d\n"
"Uid:\t%d\t%d\t%d\t%d\n"
"Gid:\t%d\t%d\t%d\t%d\n"
+ "HidePID:\t%i\n"
"FDSize:\t%d\nGroups:\t",
get_task_state(p),
tgid, ngid, pid_nr_ns(pid, ns), ppid, tpid,
@@ -206,6 +209,7 @@ static inline void task_state(struct seq_file *m, struct
pid_namespace *ns,
from_kgid_munged(user_ns, cred->egid),
from_kgid_munged(user_ns, cred->sgid),
from_kgid_munged(user_ns, cred->fsgid),
+ hide_pid,
max_fds);
group_info = cred->group_info;
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 308e9a5..b24675f 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -726,7 +726,8 @@ static bool has_pid_permissions(struct pid_namespace *pid,
struct task_struct *task,
int hide_pid_min)
{
- if (pid->hide_pid < hide_pid_min)
+ if (pid->hide_pid < hide_pid_min &&
+ current->hide_pid < hide_pid_min)
return true;
if (in_group_p(pid->pid_gid))
return true;
@@ -747,7 +748,8 @@ static int proc_pid_permission(struct inode *inode, int
mask)
put_task_struct(task);
if (!has_perms) {
- if (pid->hide_pid == HIDEPID_INVISIBLE) {
+ if (pid->hide_pid == HIDEPID_INVISIBLE ||
+ current->hide_pid == HIDEPID_INVISIBLE) {
/*
* Let's make getdents(), stat(), and open()
* consistent with each other. If a process
diff --git a/include/linux/init_task.h b/include/linux/init_task.h
index f8834f8..abd7a52 100644
--- a/include/linux/init_task.h
+++ b/include/linux/init_
Re: [Xen-devel] [PATCH v2 0/2] Reinstate irq alloc/dealloc locking patch
On 03/08/16 18:22, Boris Ostrovsky wrote: > Original version of that patch (commit a89941816726) had to be reverted > due to Xen allocating irqs in its cpu_up ops. > > The first patch moves allocations into hotplug notifiers and the second > one restores the original patch (with minor adjustments to new hotplug > framework) > > This originally went through tip tree but after a couple of failures > reportedby kbuild robot (due to various combinations of CONFIG_SMP and > CONFIG_XEN_PVH) I decided to take it through Xen tree (with config problems > hopefully finally fixed). Applied to for-linus-4.9, thanks. David
Re: [PATCH 2/4] firmware: qcom: scm: add iommu scm calls for pg table
On 8/19/2016 8:53 AM, Stanimir Varbanov wrote:
Those two scm calls are used to get the size of secure iommu
page table and to pass physical memory address for this page
table. The calls are used by remoteproc venus driver to load
the firmware.
Do we really need these additional scm calls for venus? why can't we
just reuse existing __qcom_scm_pas_mem_setup() call?
Signed-off-by: Stanimir Varbanov
---
drivers/firmware/qcom_scm-64.c | 42 ++
drivers/firmware/qcom_scm.c| 12
drivers/firmware/qcom_scm.h| 11 +++
include/linux/qcom_scm.h | 3 +++
4 files changed, 68 insertions(+)
diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
index 68484ea2aa51..ffcfbb31ae7a 100644
--- a/drivers/firmware/qcom_scm-64.c
+++ b/drivers/firmware/qcom_scm-64.c
@@ -374,3 +374,45 @@ int __qcom_scm_video_set_state(struct device *dev, u32
state, u32 spare)
return ret ? : res.a1;
}
+
+int __qcom_scm_iommu_secure_ptbl_size(struct device *dev, u32 spare,
+ size_t *size)
+{
+ struct qcom_scm_desc desc = {0};
+ struct arm_smccc_res res;
+ int ret;
+
+ desc.args[0] = spare;
+ desc.arginfo = QCOM_SCM_ARGS(1);
+
+ ret = qcom_scm_call(dev, QCOM_SCM_SVC_MP,
+ QCOM_SCM_IOMMU_SECURE_PTBL_SIZE, &desc, &res);
+
+ if (size)
+ *size = res.a1;
+
+ return ret ? : res.a2;
+}
+
+int __qcom_scm_iommu_secure_ptbl_init(struct device *dev, u64 addr, u32 size,
+ u32 spare)
+{
+ struct qcom_scm_desc desc = {0};
+ struct arm_smccc_res res;
+ int ret;
+
+ desc.args[0] = addr;
+ desc.args[1] = size;
+ desc.args[2] = spare;
+ desc.arginfo = QCOM_SCM_ARGS(3, QCOM_SCM_RW, QCOM_SCM_VAL,
+QCOM_SCM_VAL);
+
+ ret = qcom_scm_call(dev, QCOM_SCM_SVC_MP,
+ QCOM_SCM_IOMMU_SECURE_PTBL_INIT, &desc, &res);
+
+ /* the pg table has been initialized already, ignore the error */
+ if (ret == -EPERM)
+ ret = 0;
+
+ return ret;
+}
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 3b0e31c48639..aa77d31b885c 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -333,6 +333,18 @@ int qcom_scm_video_set_state(u32 state, u32 spare)
}
EXPORT_SYMBOL(qcom_scm_video_set_state);
+int qcom_scm_iommu_secure_ptbl_size(u32 spare, size_t *size)
+{
+ return __qcom_scm_iommu_secure_ptbl_size(__scm->dev, spare, size);
+}
+EXPORT_SYMBOL(qcom_scm_iommu_secure_ptbl_size);
+
+int qcom_scm_iommu_secure_ptbl_init(u64 addr, u32 size, u32 spare)
+{
+ return __qcom_scm_iommu_secure_ptbl_init(__scm->dev, addr, size, spare);
+}
+EXPORT_SYMBOL(qcom_scm_iommu_secure_ptbl_init);
+
static int qcom_scm_probe(struct platform_device *pdev)
{
struct qcom_scm *scm;
diff --git a/drivers/firmware/qcom_scm.h b/drivers/firmware/qcom_scm.h
index 4830559b2639..edeb0038e5fc 100644
--- a/drivers/firmware/qcom_scm.h
+++ b/drivers/firmware/qcom_scm.h
@@ -58,8 +58,17 @@ extern int __qcom_scm_pas_auth_and_reset(struct device
*dev, u32 peripheral);
extern int __qcom_scm_pas_shutdown(struct device *dev, u32 peripheral);
extern int __qcom_scm_pas_mss_reset(struct device *dev, bool reset);
+#define QCOM_SCM_SVC_MP 0xc
+#define QCOM_SCM_IOMMU_SECURE_PTBL_SIZE3
+#define QCOM_SCM_IOMMU_SECURE_PTBL_INIT4
+extern int __qcom_scm_iommu_secure_ptbl_size(struct device *dev, u32 spare,
+size_t *size);
+extern int __qcom_scm_iommu_secure_ptbl_init(struct device *dev, u64 addr,
+u32 size, u32 spare);
+
/* common error codes */
#define QCOM_SCM_V2_EBUSY -12
+#define QCOM_SCM_NOT_PERMITTED -8
#define QCOM_SCM_ENOMEM -5
#define QCOM_SCM_EOPNOTSUPP -4
#define QCOM_SCM_EINVAL_ADDR -3
@@ -81,6 +90,8 @@ static inline int qcom_scm_remap_error(int err)
return -ENOMEM;
case QCOM_SCM_V2_EBUSY:
return -EBUSY;
+ case QCOM_SCM_NOT_PERMITTED:
+ return -EPERM;
}
return -EINVAL;
}
diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
index 2ece81a6b078..a8fb98c36cce 100644
--- a/include/linux/qcom_scm.h
+++ b/include/linux/qcom_scm.h
@@ -48,4 +48,7 @@ extern u32 qcom_scm_get_version(void);
extern int qcom_scm_video_set_state(u32 state, u32 spare);
+extern int qcom_scm_iommu_secure_ptbl_size(u32 spare, size_t *size);
+extern int qcom_scm_iommu_secure_ptbl_init(u64 addr, u32 size, u32 spare);
+
#endif
Puja
Re: [PATCH v2 0/6] Intel Integrated Sensor Hub Support (ISH)
On Wed, 2016-08-24 at 12:16 -0400, Grant Likely wrote: > On Tue, Jul 5, 2016 at 8:42 AM, Grant Likely > wrote: > > > > > > On 22/06/16 06:40, Srinivas Pandruvada wrote: > > > > > > > > > Change log > > > v2: > > > - Overview in documentation show analogy with usbhid > > > implementation > > > - sparse errors for statics. Also pointed by Jiri > > > - Clearly marking exported function header file. Clean up all > > > exports > > > unused inteface functions > > > - Changed to tristate from boolean as pointed by Jiri: > > > this required remove/unload functions > > > - Prevent crash when ISH enabled on non supported platform > > > - Break client.c to smaller part by seprating buffer allocations > > > - move bus register/unregister to ishtp module > > > - There is only one config symbol INTEL_ISH_HID, removed silent > > > config for TRANSPORT and IPC > > > > Tested-by: Grant Likely > > > > On an HP Spectre x360 laptop using v4.7-rc5. > > Hey Srinivas. Any progress on this patch series? Unless someone has major objection, they can land up in 4.9. They will go through two different trees, I can ping you once I see all patches in linux-next. Thanks, Srinivas > > g.
Re: [PATCH 3/6] x86/dumpstack: make printk_stack_address() more generally useful
On Wed, Aug 24, 2016 at 10:28:38AM -0700, Joe Perches wrote:
> On Wed, 2016-08-24 at 11:50 -0500, Josh Poimboeuf wrote:
> > Change printk_stack_address() to be useful when called by an unwinder
> > outside the context of dump_trace().
> >
> > Specifically:
> >
> > - printk_stack_address()'s 'data' argument is always used as the log
> > level string. Make that explicit.
>
> If this is true, and I'm not sure it is as I believe
> there are static strings emitted like EOE and IRQ,
> shouldn't this bubble up through the calling tree?
>
> > - Call touch_nmi_watchdog().
> []
> > diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
> []
> > @@ -26,10 +26,11 @@ int kstack_depth_to_print = 3 * STACKSLOTS_PER_LINE;
> > static int die_counter;
> >
> > static void printk_stack_address(unsigned long address, int reliable,
> > - void *data)
> > + char *log_lvl)
> > {
> > + touch_nmi_watchdog();
> > printk("%s [<%p>] %s%pB\n",
> > - (char *)data, (void *)address, reliable ? "" : "? ",
> > + log_lvl, (void *)address, reliable ? "" : "? ",
> > (void *)address);
> > }
> >
> > @@ -148,7 +149,6 @@ static int print_trace_stack(void *data, char *name)
> > */
> > static int print_trace_address(void *data, unsigned long addr, int
> > reliable)
> > {
> > - touch_nmi_watchdog();
> > printk_stack_address(addr, reliable, data);
> > return 0;
> > }
>
> like for data here?
This function needs to keep its 'void *data' argument because it's a
callback for stacktrace_ops, so it has to conform to the callback
interface. 'data' is used for passing a pointer to an opaque data
structure to the callback.
Also this is the only caller of printk_stack_address(), so there's
nowhere else to bubble it up to.
--
Josh
Re: [Regression?] Commit cb4f71c429 deliberately changes order of network interfaces
On Wed, Aug 24, 2016 at 01:10:23PM -0400, Lennart Sorensen wrote: > Well certainly doing udevtrigger -n -v I see no ethernet devices (but > lots of other things). Looking in sysfs it is possible to dereive which > ethX belongs to which port based on the directory names, but that's > probably not the most convinient manner to deal with it. OK, udev DOES work: # udevadm info -p /sys/class/net/eth0 P: /devices/platform/soc/soc:internal-regs/f1034000.ethernet/net/eth0 E: DEVPATH=/devices/platform/soc/soc:internal-regs/f1034000.ethernet/net/eth0 E: IFINDEX=2 E: INTERFACE=eth0 E: SUBSYSTEM=net # udevadm info -p /sys/class/net/eth1 P: /devices/platform/soc/soc:internal-regs/f107.ethernet/net/eth1 E: DEVPATH=/devices/platform/soc/soc:internal-regs/f107.ethernet/net/eth1 E: IFINDEX=3 E: INTERFACE=eth1 E: SUBSYSTEM=net So it isn't hopeless. -- Len Sorensen
[PATCH v2 2/2] KVM: s390: Use memdup_user() rather than duplicating code
From: Markus Elfring
Date: Wed, 24 Aug 2016 20:10:09 +0200
* Reuse existing functionality from memdup_user() instead of keeping
duplicate source code.
This issue was detected by using the Coccinelle software.
* Return directly if this copy operation failed.
Reviewed-by: David Hildenbrand
Signed-off-by: Markus Elfring
---
v2: Rebased on source files from "Linux next-20160824".
arch/s390/kvm/guestdbg.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/arch/s390/kvm/guestdbg.c b/arch/s390/kvm/guestdbg.c
index 70b71ac..d7c6a7f 100644
--- a/arch/s390/kvm/guestdbg.c
+++ b/arch/s390/kvm/guestdbg.c
@@ -216,20 +216,10 @@ int kvm_s390_import_bp_data(struct kvm_vcpu *vcpu,
else if (dbg->arch.nr_hw_bp > MAX_BP_COUNT)
return -EINVAL;
- bp_data = kmalloc_array(dbg->arch.nr_hw_bp,
- sizeof(*bp_data),
- GFP_KERNEL);
- if (!bp_data) {
- ret = -ENOMEM;
- goto error;
- }
-
- if (copy_from_user(bp_data,
- dbg->arch.hw_bp,
- sizeof(*bp_data) * dbg->arch.nr_hw_bp)) {
- ret = -EFAULT;
- goto error;
- }
+ bp_data = memdup_user(dbg->arch.hw_bp,
+ sizeof(*bp_data) * dbg->arch.nr_hw_bp);
+ if (IS_ERR(bp_data))
+ return PTR_ERR(bp_data);
for (i = 0; i < dbg->arch.nr_hw_bp; i++) {
switch (bp_data[i].type) {
--
2.9.3
[PATCH v2 1/2] KVM: s390: Improve determination of sizes in kvm_s390_import_bp_data()
From: Markus Elfring
Date: Wed, 24 Aug 2016 19:45:23 +0200
* A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus reuse the corresponding function "kmalloc_array".
Suggested-by: Paolo Bonzini
This issue was detected also by using the Coccinelle software.
* Replace the specification of data structures by pointer dereferences
to make the corresponding size determination a bit safer according to
the Linux coding style convention.
* Delete the local variable "size" which became unnecessary with
this refactoring.
Signed-off-by: Markus Elfring
---
v2: Rebased on source files from "Linux next-20160824".
Advices were integrated from source code review.
arch/s390/kvm/guestdbg.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/arch/s390/kvm/guestdbg.c b/arch/s390/kvm/guestdbg.c
index d1f8241..70b71ac 100644
--- a/arch/s390/kvm/guestdbg.c
+++ b/arch/s390/kvm/guestdbg.c
@@ -206,7 +206,7 @@ static int __import_wp_info(struct kvm_vcpu *vcpu,
int kvm_s390_import_bp_data(struct kvm_vcpu *vcpu,
struct kvm_guest_debug *dbg)
{
- int ret = 0, nr_wp = 0, nr_bp = 0, i, size;
+ int ret = 0, nr_wp = 0, nr_bp = 0, i;
struct kvm_hw_breakpoint *bp_data = NULL;
struct kvm_hw_wp_info_arch *wp_info = NULL;
struct kvm_hw_bp_info_arch *bp_info = NULL;
@@ -216,14 +216,17 @@ int kvm_s390_import_bp_data(struct kvm_vcpu *vcpu,
else if (dbg->arch.nr_hw_bp > MAX_BP_COUNT)
return -EINVAL;
- size = dbg->arch.nr_hw_bp * sizeof(struct kvm_hw_breakpoint);
- bp_data = kmalloc(size, GFP_KERNEL);
+ bp_data = kmalloc_array(dbg->arch.nr_hw_bp,
+ sizeof(*bp_data),
+ GFP_KERNEL);
if (!bp_data) {
ret = -ENOMEM;
goto error;
}
- if (copy_from_user(bp_data, dbg->arch.hw_bp, size)) {
+ if (copy_from_user(bp_data,
+ dbg->arch.hw_bp,
+ sizeof(*bp_data) * dbg->arch.nr_hw_bp)) {
ret = -EFAULT;
goto error;
}
@@ -241,17 +244,19 @@ int kvm_s390_import_bp_data(struct kvm_vcpu *vcpu,
}
}
- size = nr_wp * sizeof(struct kvm_hw_wp_info_arch);
- if (size > 0) {
- wp_info = kmalloc(size, GFP_KERNEL);
+ if (nr_wp > 0) {
+ wp_info = kmalloc_array(nr_wp,
+ sizeof(*wp_info),
+ GFP_KERNEL);
if (!wp_info) {
ret = -ENOMEM;
goto error;
}
}
- size = nr_bp * sizeof(struct kvm_hw_bp_info_arch);
- if (size > 0) {
- bp_info = kmalloc(size, GFP_KERNEL);
+ if (nr_bp > 0) {
+ bp_info = kmalloc_array(nr_bp,
+ sizeof(*bp_info),
+ GFP_KERNEL);
if (!bp_info) {
ret = -ENOMEM;
goto error;
--
2.9.3
Re: [PATCH] phy: request shared IRQ
Hello.
On 08/24/2016 08:53 PM, Xander Huff wrote:
From: Nathan Sullivan
On hardware with multiple PHY devices hooked up to the same IRQ line, allow
them to share it.
Note that it had been allowed until my (erroneous?) commit
33c133cc7598e60976a069344910d63e56cc4401 ("phy: IRQ cannot be shared"), so I'd
like this commit just reverted instead...
I'm not sure now what was the reason I concluded that the IRQ sharing was
impossible... most probably I thought that the kernel IRQ handling code exited
the loop over the IRQ actions once IRQ_HANDLED was returned -- which is
obviously not so in reality...
Signed-off-by: Nathan Sullivan
Signed-off-by: Xander Huff
Acked-by: Ben Shelton
Acked-by: Jaeden Amero
[...]
MBR, Sergei
Re: [PATCH 3/6] x86/dumpstack: make printk_stack_address() more generally useful
On Wed, Aug 24, 2016 at 02:03:58PM -0400, Linus Torvalds wrote: > > For the non-kallsyms case we _could_ also just make the '%pB' format > add the [<>] markers back in case somebody still uses the user-space > kallsyms script that looks up hex numbers. > > Right now the hex numbers are not only useless in stack dumps (since > you can't look up symbols using them anyway thanks to randomization), > they are noise that makes the stack traces harder to read. So let's > just remove them? I actively disable KASLR on my dev box and feed these hex numbers into addr2line -ie vmlinux to find where in the function we are. Having the option to make %pB generate them works for me.
Re: [PATCH v4 6/7] arm64: dts: add Pine64 support
Hi,
On Mon, Aug 08, 2016 at 06:21:48PM +0100, Andre Przywara wrote:
> The Pine64 is a cost-efficient development board based on the
> Allwinner A64 SoC.
> There are three models: the basic version with Fast Ethernet and
> 512 MB of DRAM (Pine64) and two Pine64+ versions, which both
> feature Gigabit Ethernet and additional connectors for touchscreens
> and a camera. Or as my son put it: "Those are smaller and these are
> missing." ;-)
> The two Pine64+ models just differ in the amount of DRAM
> (1GB vs. 2GB). Since U-Boot will figure out the right size for us and
> patches the DT accordingly we just need to provide one DT for the
> Pine64+.
>
> [Maxime: Removed the common DTSI and include directly the pine64 DTS]
> Signed-off-by: Andre Przywara
> ---
> arch/arm64/boot/dts/Makefile | 1 +
> arch/arm64/boot/dts/allwinner/Makefile | 5 ++
> .../boot/dts/allwinner/sun50i-a64-pine64-plus.dts | 48 ++
> .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 74
> ++
> 4 files changed, 128 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/Makefile
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>
> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
> index 6e199c9..ddcbf5a 100644
> --- a/arch/arm64/boot/dts/Makefile
> +++ b/arch/arm64/boot/dts/Makefile
> @@ -1,4 +1,5 @@
> dts-dirs += al
> +dts-dirs += allwinner
> dts-dirs += altera
> dts-dirs += amd
> dts-dirs += amlogic
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile
> b/arch/arm64/boot/dts/allwinner/Makefile
> new file mode 100644
> index 000..1e29a5a
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -0,0 +1,5 @@
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
> +
> +always := $(dtb-y)
> +subdir-y := $(dts-dirs)
> +clean-files := *.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
> new file mode 100644
> index 000..e369e83
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
> @@ -0,0 +1,48 @@
> +/*
> + * Copyright (c) 2016 ARM Ltd.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include "sun50i-a64-pine64.dts"
> +
> +/ {
> + model = "Pine64+";
> + compatible = "pine64,pine64-plus", "allwinner,sun50i-a64";
> +};
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> new file mode 100644
> index 000..077a56f
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> @@ -0,0 +1,74 @@
> +/*
> + * Copyright (c) 2016 ARM Ltd.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
>
[PATCH] net: macb: Increase DMA buffer size
From: Nathan Sullivan In recent testing with the RT patchset, we have seen cases where the transmit ring can fill even with up to 200 txbds in the ring. Increase the size of the DMA rings to avoid overruns. Signed-off-by: Nathan Sullivan Acked-by: Ben Shelton Acked-by: Jaeden Amero Natinst-ReviewBoard-ID: 83662 --- drivers/net/ethernet/cadence/macb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c index 3256839..86a8e20 100644 --- a/drivers/net/ethernet/cadence/macb.c +++ b/drivers/net/ethernet/cadence/macb.c @@ -35,12 +35,12 @@ #include "macb.h" -#define MACB_RX_BUFFER_SIZE128 +#define MACB_RX_BUFFER_SIZE1536 #define RX_BUFFER_MULTIPLE 64 /* bytes */ #define RX_RING_SIZE 512 /* must be power of 2 */ #define RX_RING_BYTES (sizeof(struct macb_dma_desc) * RX_RING_SIZE) -#define TX_RING_SIZE 128 /* must be power of 2 */ +#define TX_RING_SIZE 512 /* must be power of 2 */ #define TX_RING_BYTES (sizeof(struct macb_dma_desc) * TX_RING_SIZE) /* level of occupied TX descriptors under which we wake up TX process */ -- 1.9.1
[PATCH 1/2] procfs: use an enum for possible hidepid values
Previously, the hidepid parameter was checked by comparing literal
integers 0, 1, 2. Let's add a proper enum for this, to make the checking
more expressive:
0 → HIDEPID_OFF
1 → HIDEPID_NO_ACCESS
2 → HIDEPID_INVISIBLE
This changes the internal labelling only, the userspace-facing interface
remains unmodified, and still works with literal integers 0, 1, 2.
No functional changes.
Signed-off-by: Lafcadio Wluiki
---
fs/proc/base.c| 8
fs/proc/inode.c | 2 +-
fs/proc/root.c| 3 ++-
include/linux/pid_namespace.h | 6 ++
4 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 54e2702..308e9a5 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -743,11 +743,11 @@ static int proc_pid_permission(struct inode *inode, int
mask)
task = get_proc_task(inode);
if (!task)
return -ESRCH;
- has_perms = has_pid_permissions(pid, task, 1);
+ has_perms = has_pid_permissions(pid, task, HIDEPID_NO_ACCESS);
put_task_struct(task);
if (!has_perms) {
- if (pid->hide_pid == 2) {
+ if (pid->hide_pid == HIDEPID_INVISIBLE) {
/*
* Let's make getdents(), stat(), and open()
* consistent with each other. If a process
@@ -1710,7 +1710,7 @@ int pid_getattr(struct vfsmount *mnt, struct dentry
*dentry, struct kstat *stat)
stat->gid = GLOBAL_ROOT_GID;
task = pid_task(proc_pid(inode), PIDTYPE_PID);
if (task) {
- if (!has_pid_permissions(pid, task, 2)) {
+ if (!has_pid_permissions(pid, task, HIDEPID_INVISIBLE)) {
rcu_read_unlock();
/*
* This doesn't prevent learning whether PID exists,
@@ -3151,7 +3151,7 @@ int proc_pid_readdir(struct file *file, struct
dir_context *ctx)
iter.tgid += 1, iter = next_tgid(ns, iter)) {
char name[PROC_NUMBUF];
int len;
- if (!has_pid_permissions(ns, iter.task, 2))
+ if (!has_pid_permissions(ns, iter.task, HIDEPID_INVISIBLE))
continue;
len = snprintf(name, sizeof(name), "%d", iter.tgid);
diff --git a/fs/proc/inode.c b/fs/proc/inode.c
index c1b7238..7b28103 100644
--- a/fs/proc/inode.c
+++ b/fs/proc/inode.c
@@ -107,7 +107,7 @@ static int proc_show_options(struct seq_file *seq, struct
dentry *root)
if (!gid_eq(pid->pid_gid, GLOBAL_ROOT_GID))
seq_printf(seq, ",gid=%u", from_kgid_munged(&init_user_ns,
pid->pid_gid));
- if (pid->hide_pid != 0)
+ if (pid->hide_pid != HIDEPID_OFF)
seq_printf(seq, ",hidepid=%u", pid->hide_pid);
return 0;
diff --git a/fs/proc/root.c b/fs/proc/root.c
index 8d3e484..2989731 100644
--- a/fs/proc/root.c
+++ b/fs/proc/root.c
@@ -58,7 +58,8 @@ int proc_parse_options(char *options, struct pid_namespace
*pid)
case Opt_hidepid:
if (match_int(&args[0], &option))
return 0;
- if (option < 0 || option > 2) {
+ if (option < HIDEPID_OFF ||
+ option > HIDEPID_INVISIBLE) {
pr_err("proc: hidepid value must be between 0
and 2.\n");
return 0;
}
diff --git a/include/linux/pid_namespace.h b/include/linux/pid_namespace.h
index 918b117..a19f211 100644
--- a/include/linux/pid_namespace.h
+++ b/include/linux/pid_namespace.h
@@ -21,6 +21,12 @@ struct pidmap {
struct fs_pin;
+enum { /* definitions for pid_namespace's hide_pid field */
+ HIDEPID_OFF = 0,
+ HIDEPID_NO_ACCESS = 1,
+ HIDEPID_INVISIBLE = 2,
+};
+
struct pid_namespace {
struct kref kref;
struct pidmap pidmap[PIDMAP_ENTRIES];
--
2.7.4
Re: [PATCH v6 2/2] clocksource: add J-Core timer/clocksource driver
On Wed, 24 Aug 2016 13:40:01 -0400 Rich Felker wrote: [...] > > IIUC, there is a problem with the interrupt controller where the per irq > > line are not working correctly. Is that correct ? > > I don't think that's a correct characterization. Rather the percpu > infrastructure just means something completely different from what you > would expect it to mean. It has nothing to do with the hardware but > rather with kernel-internal choice of whether to do percpu devid > mapping inside the irq infrastructure, and the choice at the > irq-requester side of whether to do this is required to match the > irqchip driver's choice. I explained this better in another email > which I could dig up if necessary, but the essence is that > request_percpu_irq is a misnamed and unusably broken API. Or just one that simply doesn't fit your needs, because other architectures have different semantics than the ones you take for granted? > > > Regarding Marc Zyngier comments about the irq controller driver being > > almost empty, I'm wondering if something in the irq controller driver > > which shouldn't be added before submitting this timer driver with SMP > > support (eg. irq domain ?). > > I don't think so. At most I could make the driver hard-code the percpu > devid model for certain irqs, but that _does not reflect_ anything > about the hardware. Rather it just reflects bad kernel internals. It I'd appreciate it if instead of ranting about how broken the kernel is, you'd submit a patch fixing it, since you seem to have spotted something that we haven't in several years of using that code on a couple of ARM-related platforms. Thanks, M. -- Jazz is not dead. It just smells funny.
Re: [PATCH] MAINTAINERS: add linux-su...@googlegroups.com as list for sunxi arch
On 24/08/2016 20:23, Maxime Ripard wrote: > Hi, > > On Thu, Aug 18, 2016 at 02:14:17PM +0200, LABBE Corentin wrote: >> All discutions about sunxi architecture is done >> on linux-su...@googlegroups.com. >> This patch add it as list on drivers for this arch. >> >> Signed-off-by: LABBE Corentin >> --- >> MAINTAINERS | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index a306795..6254eb1 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -980,6 +980,7 @@ ARM/Allwinner sunXi SoC support >> M: Maxime Ripard >> M: Chen-Yu Tsai >> L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) >> +L: linux-su...@googlegroups.com > > I don't want a mailing list hosted on google groups to be added to > MAINTAINERS. Why ? Because I see already: L: xiyoulinuxkernelgr...@googlegroups.com (subscribers-only) L: open-is...@googlegroups.com L: kasan-...@googlegroups.com L: linux-...@googlegroups.com L: rtc-li...@googlegroups.com > > We can ask for one on kernel.org though if people feel like it's > relevant. Nobody cared for a few years, so I guess it would be a no, > but if others feel like it... > I am not against one on kernel.org Regards
[PATCH] ASoC: rt5659: Enable IRQ output for GPIO1 pin
Since it's possible to have an IRQ without enabling JD3, the GPIO1 pin then would remain its default GPIO function which is set as an input direction (seeing from rt5659). Meanwhile, CPU would also listen this connection via its own GPIO input: [input] [input] CPU GPIO <> RT5659 GPIO1 The result for the IRQ on the CPU side will be unexpectable. So this patch enables the IRQ output for GPIO1 pin any way as long as there's an IRQ assigned from platform data or DT: [input] [IRQ output] CPU GPIO << RT5659 GPIO1 Signed-off-by: Nicolin Chen --- sound/soc/codecs/rt5659.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/soc/codecs/rt5659.c b/sound/soc/codecs/rt5659.c index 4c0d2b8..db54550 100644 --- a/sound/soc/codecs/rt5659.c +++ b/sound/soc/codecs/rt5659.c @@ -4189,6 +4189,9 @@ static int rt5659_i2c_probe(struct i2c_client *i2c, if (ret) dev_err(&i2c->dev, "Failed to reguest IRQ: %d\n", ret); + /* Enable IRQ output for GPIO1 pin any way */ + regmap_update_bits(rt5659->regmap, RT5659_GPIO_CTRL_1, + RT5659_GP1_PIN_MASK, RT5659_GP1_PIN_IRQ); } return snd_soc_register_codec(&i2c->dev, &soc_codec_dev_rt5659, -- 2.1.4
Re: [PATCH v3 1/5] ARM: dts: exynos: Enable HDMI for Arndale Octa board
On Wed, Aug 24, 2016 at 10:07:15PM +0900, Milo Kim wrote:
> * GPIO for HDMI hot plug detect
> GPX3_7 is used. The HPD awareness is done when the GPIO is active high and
> single ended.
>
> * Enable HDMI block in Exynos5420
> HDMI VDD and PLL consume 1.0V LDO6 (PVDD_ANAIP_1V0) and HDMI oscillator
> requires 1.8V LDO7 (PVDD_ANAIP_1V8).
>
> * Support HDMI display data channel
> I2C #2 is assigned for the HDMI DDC. It enables the EDID access.
>
> Cc: Kukjin Kim
> Cc: Krzysztof Kozlowski
> Cc: Rob Herring
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Milo Kim
> ---
> arch/arm/boot/dts/exynos5420-arndale-octa.dts | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> index 39a3b81..2fb5708 100644
> --- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> +++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> @@ -70,6 +70,19 @@
> status = "disabled";
> };
>
First of all - it looks like these DTS patches do not depend on DRM
part, do they?
> +&hdmi {
> + hpd-gpios = <&gpx3 7 GPIO_OPEN_SOURCE>;
Are you sure it is open-source type?
> + vdd_osc-supply = <&ldo7_reg>;
> + vdd_pll-supply = <&ldo6_reg>;
> + vdd-supply = <&ldo6_reg>;
> + ddc = <&i2c_2>;
> + status = "okay";
> +};
> +
> +&i2c_2 {
> + status = "okay";
Hm, what is connected here? Please put it in alphabetical order (so
after hsi2c_4).
Best regards,
Krzysztof
[PATCH v6 3/4 RESEND] SCT Write Same / DSM Trim
Correct handling of devices with sector_size other that 512 bytes.
In the case of a 4Kn device sector_size it is possible to describe a much
larger DSM Trim than the current fixed default of 512 bytes.
This patch assumes the minimum descriptor is sector_size and fills out
the descriptor accordingly.
The ACS-2 specification is quite clear that the DSM command payload is
sized as number of 512 byte transfers so a 4Kn device will operate
correctly without this patch.
Signed-off-by: Shaun Tancheff
---
v5:
- Reshuffled descripton.
- Added support for a sector_size descriptor other than 512 bytes.
drivers/ata/libata-scsi.c | 85 +++
1 file changed, 57 insertions(+), 28 deletions(-)
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index ebf1a04..37f456e 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -3283,7 +3283,7 @@ static unsigned int ata_scsi_pass_thru(struct
ata_queued_cmd *qc)
/**
* ata_format_dsm_trim_descr() - SATL Write Same to DSM Trim
* @cmd: SCSI command being translated
- * @num: Maximum number of entries (nominally 64).
+ * @trmax: Maximum number of entries that will fit in sector_size bytes.
* @sector: Starting sector
* @count: Total Range of request in logical sectors
*
@@ -3298,63 +3298,80 @@ static unsigned int ata_scsi_pass_thru(struct
ata_queued_cmd *qc)
* LBA's should be sorted order and not overlap.
*
* NOTE: this is the same format as ADD LBA(S) TO NV CACHE PINNED SET
+ *
+ * Return: Number of bytes copied into sglist.
*/
-static unsigned int ata_format_dsm_trim_descr(struct scsi_cmnd *cmd, u32 num,
- u64 sector, u32 count)
+static size_t ata_format_dsm_trim_descr(struct scsi_cmnd *cmd, u32 trmax,
+ u64 sector, u32 count)
{
- __le64 *buffer;
- u32 i = 0, used_bytes;
+ struct scsi_device *sdp = cmd->device;
+ size_t len = sdp->sector_size;
+ size_t r;
+ __le64 *buf;
+ u32 i = 0;
unsigned long flags;
- BUILD_BUG_ON(512 > ATA_SCSI_RBUF_SIZE);
+ WARN_ON(len > ATA_SCSI_RBUF_SIZE);
+
+ if (len > ATA_SCSI_RBUF_SIZE)
+ len = ATA_SCSI_RBUF_SIZE;
spin_lock_irqsave(&ata_scsi_rbuf_lock, flags);
- buffer = ((void *)ata_scsi_rbuf);
- while (i < num) {
+ buf = ((void *)ata_scsi_rbuf);
+ memset(buf, 0, len);
+ while (i < trmax) {
u64 entry = sector |
((u64)(count > 0x ? 0x : count) << 48);
- buffer[i++] = __cpu_to_le64(entry);
+ buf[i++] = __cpu_to_le64(entry);
if (count <= 0x)
break;
count -= 0x;
sector += 0x;
}
-
- used_bytes = ALIGN(i * 8, 512);
- memset(buffer + i, 0, used_bytes - i * 8);
- sg_copy_from_buffer(scsi_sglist(cmd), scsi_sg_count(cmd), buffer, 512);
+ r = sg_copy_from_buffer(scsi_sglist(cmd), scsi_sg_count(cmd), buf, len);
spin_unlock_irqrestore(&ata_scsi_rbuf_lock, flags);
- return used_bytes;
+ return r;
}
/**
* ata_format_dsm_trim_descr() - SATL Write Same to ATA SCT Write Same
* @cmd: SCSI command being translated
* @lba: Starting sector
- * @num: Number of logical sectors to be zero'd.
+ * @num: Number of sectors to be zero'd.
*
- * Rewrite the WRITE SAME descriptor to be an SCT Write Same formatted
+ * Rewrite the WRITE SAME payload to be an SCT Write Same formatted
* descriptor.
* NOTE: Writes a pattern (0's) in the foreground.
- * Large write-same requents can timeout.
+ *
+ * Return: Number of bytes copied into sglist.
*/
-static void ata_format_sct_write_same(struct scsi_cmnd *cmd, u64 lba, u64 num)
+static size_t ata_format_sct_write_same(struct scsi_cmnd *cmd, u64 lba, u64
num)
{
- u16 *sctpg;
+ struct scsi_device *sdp = cmd->device;
+ size_t len = sdp->sector_size;
+ size_t r;
+ u16 *buf;
unsigned long flags;
spin_lock_irqsave(&ata_scsi_rbuf_lock, flags);
- sctpg = ((void *)ata_scsi_rbuf);
+ buf = ((void *)ata_scsi_rbuf);
+
+ put_unaligned_le16(0x0002, &buf[0]); /* SCT_ACT_WRITE_SAME */
+ put_unaligned_le16(0x0101, &buf[1]); /* WRITE PTRN FG */
+ put_unaligned_le64(lba, &buf[2]);
+ put_unaligned_le64(num, &buf[6]);
+ put_unaligned_le32(0u, &buf[10]); /* pattern */
+
+ WARN_ON(len > ATA_SCSI_RBUF_SIZE);
- put_unaligned_le16(0x0002, &sctpg[0]); /* SCT_ACT_WRITE_SAME */
- put_unaligned_le16(0x0101, &sctpg[1]); /* WRITE PTRN FG */
- put_unaligned_le64(lba, &sctpg[2]);
- put_unaligned_le64(num, &sctpg[6]);
- put_unaligned_le32(0u, &sctpg[10]);
+ if (len > ATA_SCSI_RBUF_SIZE)
+ len = ATA_SCSI_RBUF_SIZE;
- sg_copy_from_buffer(scsi_sglist(cmd), s
Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger
Rafał Miłecki writes: > The last big missing thing is Documentation update (this is why I'm > sending RFC). Greg pointed out we should have some entries in > Documentation/ABI, but it seems none of triggers have it. There's a lot missing, but there is at least one exception: The "inverted" attribute of the gpio and backlight triggers is documented as part of Documentation/ABI/testing/sysfs-class-led > Any idea why is that? Manual enforcement fails from time to time? The requirement was less strict in the early days of sysfs? Does it matter? > Do we need to change it? Or is it required for new code only? The lack of ABI docs is a bug. Don't add new code with known bugs. Old code should be fixed, but there is no immediate *need* to fix it. Bjørn
Re: [PATCH 3/6] x86/dumpstack: make printk_stack_address() more generally useful
On Wed, Aug 24, 2016 at 12:50 PM, Josh Poimboeuf wrote:
> Change printk_stack_address() to be useful when called by an unwinder
> outside the context of dump_trace().
...
> printk("%s [<%p>] %s%pB\n",
> - (char *)data, (void *)address, reliable ? "" : "? ",
> + log_lvl, (void *)address, reliable ? "" : "? ",
> (void *)address);
Side note: we should just remove the "[]" thing entirely, I
think. It's not just redundant, but when people care about kernel
address randomization it ends up spilling the beans on the offset in
warnings (in oopses you can generally find the data in the stack
backtraces, which we probably should remove too as useless).
So it would be just
printk("%s %s%pB\n", log_lvl, reliable ? "" : "? ", (void *)address);
instead.
For the non-kallsyms case we _could_ also just make the '%pB' format
add the [<>] markers back in case somebody still uses the user-space
kallsyms script that looks up hex numbers.
Right now the hex numbers are not only useless in stack dumps (since
you can't look up symbols using them anyway thanks to randomization),
they are noise that makes the stack traces harder to read. So let's
just remove them?
I realize that is entirely orthogonal to this particular patch, but it
happened to touch this file.
No objections to this series other than that comment.
Linus
Re: [PATCH v3 2/5] ARM: dts: exynos: Use 'hpd-gpios' instead of 'hpd-gpio'
On Wed, Aug 24, 2016 at 10:07:16PM +0900, Milo Kim wrote:
> This patch enables getting a HPD GPIO descriptor quickly.
> The exynos-hdmi driver uses "hpd" for HDMI hot plug detection.
>
> static int hdmi_resources_init(struct hdmi_context *hdata)
> {
> ...
> hdata->hpd_gpio = devm_gpiod_get(dev, "hpd", GPIOD_IN);
> ...
> }
>
> This calls 'of_find_gpio()' and it generates the GPIO consumer ID by referring
> GPIO suffix. So 'hpd-gpios' is preferred on getting a GPIO descriptor.
>
> However, if the device tree uses 'hpd-gpio', then the exynos-hdmi driver
> always retries to get a GPIO descriptor because the first GPIO suffix is not
> 'gpio' but 'gpios'. So you always see the debug message below.
>
> of_get_named_gpiod_flags: can't parse 'hpd-gpios' property of node
> '/soc/hdmi@1453[0]'
>
Thanks for fixing this, applied!
BR,
Krzysztof
Re: [PATCH] net: macb: Increase DMA buffer size
Le 24/08/2016 à 20:25, Xander Huff a écrit : > From: Nathan Sullivan > > In recent testing with the RT patchset, we have seen cases where the > transmit ring can fill even with up to 200 txbds in the ring. Increase > the size of the DMA rings to avoid overruns. > > Signed-off-by: Nathan Sullivan > Acked-by: Ben Shelton > Acked-by: Jaeden Amero > Natinst-ReviewBoard-ID: 83662 > --- > drivers/net/ethernet/cadence/macb.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/ethernet/cadence/macb.c > b/drivers/net/ethernet/cadence/macb.c > index 3256839..86a8e20 100644 > --- a/drivers/net/ethernet/cadence/macb.c > +++ b/drivers/net/ethernet/cadence/macb.c > @@ -35,12 +35,12 @@ > > #include "macb.h" > > -#define MACB_RX_BUFFER_SIZE 128 > +#define MACB_RX_BUFFER_SIZE 1536 This change seems not covered by the commit message. Can you please separate the changes in 2 patches or elaborate a bit more the reason for this RX buffer size change. Bye, > #define RX_BUFFER_MULTIPLE 64 /* bytes */ > #define RX_RING_SIZE 512 /* must be power of 2 */ > #define RX_RING_BYTES(sizeof(struct macb_dma_desc) * > RX_RING_SIZE) > > -#define TX_RING_SIZE 128 /* must be power of 2 */ > +#define TX_RING_SIZE 512 /* must be power of 2 */ > #define TX_RING_BYTES(sizeof(struct macb_dma_desc) * > TX_RING_SIZE) > > /* level of occupied TX descriptors under which we wake up TX process */ > -- Nicolas Ferre
Re: [PATCH 3/6] x86/dumpstack: make printk_stack_address() more generally useful
On Wed, 2016-08-24 at 13:43 -0500, Josh Poimboeuf wrote: > On Wed, Aug 24, 2016 at 10:28:38AM -0700, Joe Perches wrote: > > On Wed, 2016-08-24 at 11:50 -0500, Josh Poimboeuf wrote: > > > Change printk_stack_address() to be useful when called by an unwinder > > > outside the context of dump_trace(). > > > > > > Specifically: > > > > > > - printk_stack_address()'s 'data' argument is always used as the log > > > level string. Make that explicit. [] > > If this is true, and I'm not sure it is as I believe > > there are static strings emitted like EOE and IRQ, > > shouldn't this bubble up through the calling tree? > [] > This function needs to keep its 'void *data' argument because it's a > callback for stacktrace_ops, so it has to conform to the callback > interface. 'data' is used for passing a pointer to an opaque data > structure to the callback. > > Also this is the only caller of printk_stack_address(), so there's > nowhere else to bubble it up to. And that shows that print_stack_address(data is not always a log level. ie: walk_stack uses it to print a string not a log level.
Capturing crash with 4.6.0 and above kernel does not work
Hello list, I am wondering if anybody has issue capturing crash dump with the 4.6.0 and above kenrel. I have a system, when booted in 4.5.7 kernel is able to capture crash dump. However, when I boot this system in 4.6.4 and 4.7.2 kernel, crash dump is not able to capture any crash. I am still facing same issue with 4.8.0-rc2+ kernel and from the error at the command prompt, it seems like kexec is ignoring “crashkenrel” parameter. I added below information in https://bugzilla.kernel.org/show_bug.cgi?id=119291. # uname -r 4.8.0-rc2+ # cat /proc/cmdline ro root=/dev/mapper/vg_dut4110-lv_root rd_NO_LUKS KEYBOARDTYPE=pc KEYTABLE=us LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=512M rd_LVM_LV=vg_dut4110/lv_swap rd_LVM_LV=vg_dut4110/lv_root rd_NO_DM rhgb quiet # service kdump status Kdump is not operational # service kdump start Memory for crashkernel is not reserved Please reserve memory by passing "crashkernel=X@Y" parameter to the kernel Starting kdump:[FAILED] message file confirms that kexec was not able to start the service Aug 15 10:41:17 dut4110 kdump: kexec: failed to load kdump kernel Aug 15 10:41:17 dut4110 kdump: failed to start up Note, that same option is able to load kdump service for 4.5.7 kernel. I can provide any details needed to help resolve this issue. Thanks, - Himanshu
Re: [PATCH 7/8] PCI: exynos: make host support explicitly non-modular
On Mon, Aug 22, 2016 at 05:59:47PM -0400, Paul Gortmaker wrote: > The Kconfig currently controlling compilation of this code is: > > drivers/pci/host/Kconfig:config PCI_EXYNOS > drivers/pci/host/Kconfig: bool "Samsung Exynos PCIe controller" > > ...meaning that it currently is not being built as a module by anyone. > > Lets remove the couple traces of modular infrastructure use, so that > when reading the driver there is no doubt it is builtin-only. > > Note that MODULE_DEVICE_TABLE is a no-op for non-modular code. > > We also delete the MODULE_LICENSE tag etc. since all that information > is already contained at the top of the file in the comments. > > Cc: Jingoo Han > Cc: Bjorn Helgaas > Cc: Kukjin Kim > Cc: Krzysztof Kozlowski > Cc: linux-...@vger.kernel.org > Cc: linux-samsung-...@vger.kernel.org > Signed-off-by: Paul Gortmaker > --- > drivers/pci/host/pci-exynos.c | 7 +-- > 1 file changed, 1 insertion(+), 6 deletions(-) > Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH v6 2/2] clocksource: add J-Core timer/clocksource driver
On Wed, Aug 24, 2016 at 08:01:52PM +0100, Marc Zyngier wrote: > On Wed, 24 Aug 2016 13:40:01 -0400 > Rich Felker wrote: > > [...] > > > > IIUC, there is a problem with the interrupt controller where > the per irq > > > line are not working correctly. Is that correct ? > > > > I don't think that's a correct characterization. Rather the percpu > > infrastructure just means something completely different from what you > > would expect it to mean. It has nothing to do with the hardware but > > rather with kernel-internal choice of whether to do percpu devid > > mapping inside the irq infrastructure, and the choice at the > > irq-requester side of whether to do this is required to match the > > irqchip driver's choice. I explained this better in another email > > which I could dig up if necessary, but the essence is that > > request_percpu_irq is a misnamed and unusably broken API. For reference, here's the thread I was referring to: https://lkml.org/lkml/2016/7/15/585 > Or just one that simply doesn't fit your needs, because other > architectures have different semantics than the ones you take for > granted? I don't think so. The choice of whether to have the irq layer or the driver's irq handler be responsible for handling a percpu pointer has nothing to do with the hardware. Perhaps the intent was that the irqchip driver always knows whether a given hwirq[-range] is associated with per-cpu events or global events for which it doesn't matter what cpu they're delivered on. In this case, the situations where you may want percpu dev_id mapping line up with some property of the hardware. However that need not be the case, and it's not when the choice of irq is programmable. > > > Regarding Marc Zyngier comments about the irq controller driver being > > > almost empty, I'm wondering if something in the irq controller driver > > > which shouldn't be added before submitting this timer driver with SMP > > > support (eg. irq domain ?). > > > > I don't think so. At most I could make the driver hard-code the percpu > > devid model for certain irqs, but that _does not reflect_ anything > > about the hardware. Rather it just reflects bad kernel internals. It > > I'd appreciate it if instead of ranting about how broken the kernel is, > you'd submit a patch fixing it, since you seem to have spotted > something that we haven't in several years of using that code on a > couple of ARM-related platforms. I didn't intend for this to be a rant. I'm not demanding that it be changed; I'm only objecting to being asked to make the driver use a framework that it doesn't need and that can't model what needs to be done. But I'm happy to discuss whether you would be open to such a change, and if so, to write and submit a patch. The ideas for what it would involve are in the linked email, quoted here: "... This is because the irq controller driver must, at irqdomain mapping time, decide whether to register the handler as handle_percpu_devid_irq (which interprets dev_id as a __percpu pointer and remaps it for the local cpu before invoking the driver's handler) or one of the other handlers that does not perform any percpu remapping. The right way for this to work would be for handle_irq_event_percpu to be responsible for the remapping, but do it conditionally on whether the irq was requested via request_irq or request_percpu_irq." Do you disagree with this assessment? Rich
Re: [PATCH 3/6] x86/dumpstack: make printk_stack_address() more generally useful
On Wed, Aug 24, 2016 at 12:07:06PM -0700, Joe Perches wrote: > On Wed, 2016-08-24 at 13:43 -0500, Josh Poimboeuf wrote: > > On Wed, Aug 24, 2016 at 10:28:38AM -0700, Joe Perches wrote: > > > On Wed, 2016-08-24 at 11:50 -0500, Josh Poimboeuf wrote: > > > > Change printk_stack_address() to be useful when called by an unwinder > > > > outside the context of dump_trace(). > > > > > > > > Specifically: > > > > > > > > - printk_stack_address()'s 'data' argument is always used as the log > > > > level string. Make that explicit. > [] > > > If this is true, and I'm not sure it is as I believe > > > there are static strings emitted like EOE and IRQ, > > > shouldn't this bubble up through the calling tree? > > > [] > > This function needs to keep its 'void *data' argument because it's a > > callback for stacktrace_ops, so it has to conform to the callback > > interface. 'data' is used for passing a pointer to an opaque data > > structure to the callback. > > > > Also this is the only caller of printk_stack_address(), so there's > > nowhere else to bubble it up to. > > And that shows that print_stack_address(data is not always a log level. > ie: walk_stack uses it to print a string not a log level. Hm, can you be more specific? As far as I can tell, here's the only possible call path to print_trace_address() and printk_stack_address(): show_trace_log_lvl() dump_trace() // ops is print_trace_op print_context_stack() // ops->walk_stack print_trace_address() // ops->address printk_stack_address() So 'data' is a sneaky way to pass 'log_lvl' from show_trace_log_lvl() to print_trace_address(), without dump_trace() and print_context_stack() knowing what it is, because they're used in other places where 'data' means something else. -- Josh
Re: [PATCH 2/2] ARM: dts: sun8i: enable UART1 for iNet D978 Rev2 board
Hi,
On Tue, Aug 23, 2016 at 02:44:51PM +0800, Icenowy Zheng wrote:
> UART1 is connected to the bluetooth part of RTL8723BS WiFi/BT combo card
> on iNet D978 Rev2 board.
>
> Enable the UART1 to make it possible to use the modified hciattach by
> Realtek to drive the BT part of RTL8723BS.
>
> Signed-off-by: Icenowy Zheng
I guess you could fold that patch into the previous one.
> ---
> arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
> b/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
> index 78823d8..3ac22d4 100644
> --- a/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
> +++ b/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
> @@ -48,6 +48,10 @@
> model = "INet-D978 Rev 02";
> compatible = "primux,inet-d978-rev2", "allwinner,sun8i-a33";
>
> + aliases {
> + serial1 = &uart1;
> + };
> +
Is there any other UART in the system?
The alias is not supposed to be about the controller index, but the
index in the board, meaning that if you only have a single UART, that
would be serial0.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
[PATCH] mm, swap: Add swap_cluster_list
From: Huang Ying
This is a code clean up patch without functionality changes. The
swap_cluster_list data structure and its operations are introduced to
provide some better encapsulation for the free cluster and discard
cluster list operations. This avoid some code duplication, improved
the code readability, and reduced the total line number.
Cc: Tim Chen
Cc: Hugh Dickins
Cc: Shaohua Li
Cc: Rik van Riel
Acked-by: Minchan Kim
Signed-off-by: "Huang, Ying"
---
include/linux/swap.h | 11 +++--
mm/swapfile.c| 131 ---
2 files changed, 68 insertions(+), 74 deletions(-)
diff --git a/include/linux/swap.h b/include/linux/swap.h
index b17cc48..ed41bec 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -191,6 +191,11 @@ struct percpu_cluster {
unsigned int next; /* Likely next allocation offset */
};
+struct swap_cluster_list {
+ struct swap_cluster_info head;
+ struct swap_cluster_info tail;
+};
+
/*
* The in-memory structure used to track swap areas.
*/
@@ -203,8 +208,7 @@ struct swap_info_struct {
unsigned intmax;/* extent of the swap_map */
unsigned char *swap_map;/* vmalloc'ed array of usage counts */
struct swap_cluster_info *cluster_info; /* cluster info. Only for SSD */
- struct swap_cluster_info free_cluster_head; /* free cluster list head */
- struct swap_cluster_info free_cluster_tail; /* free cluster list tail */
+ struct swap_cluster_list free_clusters; /* free clusters list */
unsigned int lowest_bit;/* index of first free in swap_map */
unsigned int highest_bit; /* index of last free in swap_map */
unsigned int pages; /* total of usable pages of swap */
@@ -235,8 +239,7 @@ struct swap_info_struct {
* first.
*/
struct work_struct discard_work; /* discard worker */
- struct swap_cluster_info discard_cluster_head; /* list head of discard
clusters */
- struct swap_cluster_info discard_cluster_tail; /* list tail of discard
clusters */
+ struct swap_cluster_list discard_clusters; /* discard clusters list */
};
/* linux/mm/workingset.c */
diff --git a/mm/swapfile.c b/mm/swapfile.c
index 78cfa29..f9892a3 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -257,6 +257,52 @@ static inline void cluster_set_null(struct
swap_cluster_info *info)
info->data = 0;
}
+static inline bool cluster_list_empty(struct swap_cluster_list *list)
+{
+ return cluster_is_null(&list->head);
+}
+
+static inline unsigned int cluster_list_first(struct swap_cluster_list *list)
+{
+ return cluster_next(&list->head);
+}
+
+static void cluster_list_init(struct swap_cluster_list *list)
+{
+ cluster_set_null(&list->head);
+ cluster_set_null(&list->tail);
+}
+
+static void cluster_list_add_tail(struct swap_cluster_list *list,
+ struct swap_cluster_info *ci,
+ unsigned int idx)
+{
+ if (cluster_list_empty(list)) {
+ cluster_set_next_flag(&list->head, idx, 0);
+ cluster_set_next_flag(&list->tail, idx, 0);
+ } else {
+ unsigned int tail = cluster_next(&list->tail);
+ cluster_set_next(&ci[tail], idx);
+ cluster_set_next_flag(&list->tail, idx, 0);
+ }
+}
+
+static unsigned int cluster_list_del_first(struct swap_cluster_list *list,
+ struct swap_cluster_info *ci)
+{
+ unsigned int idx;
+
+ idx = cluster_next(&list->head);
+ if (cluster_next(&list->tail) == idx) {
+ cluster_set_null(&list->head);
+ cluster_set_null(&list->tail);
+ } else
+ cluster_set_next_flag(&list->head,
+ cluster_next(&ci[idx]), 0);
+
+ return idx;
+}
+
/* Add a cluster to discard list and schedule it to do discard */
static void swap_cluster_schedule_discard(struct swap_info_struct *si,
unsigned int idx)
@@ -270,17 +316,7 @@ static void swap_cluster_schedule_discard(struct
swap_info_struct *si,
memset(si->swap_map + idx * SWAPFILE_CLUSTER,
SWAP_MAP_BAD, SWAPFILE_CLUSTER);
- if (cluster_is_null(&si->discard_cluster_head)) {
- cluster_set_next_flag(&si->discard_cluster_head,
- idx, 0);
- cluster_set_next_flag(&si->discard_cluster_tail,
- idx, 0);
- } else {
- unsigned int tail = cluster_next(&si->discard_cluster_tail);
- cluster_set_next(&si->cluster_info[tail], idx);
- cluster_set_next_flag(&si->discard_cluster_tail,
- idx, 0);
- }
+ clu
Re: [PATCH 3/6] x86/dumpstack: make printk_stack_address() more generally useful
On Wed, Aug 24, 2016 at 02:37:21PM -0400, Linus Torvalds wrote: > On Wed, Aug 24, 2016 at 2:22 PM, Peter Zijlstra wrote: > > > > I actively disable KASLR on my dev box and feed these hex numbers into > > addr2line -ie vmlinux to find where in the function we are. > > > > Having the option to make %pB generate them works for me. > > Yeah, considering that this is the only place this is used, changing > %pB sounds quite reasonable. There's now another use of '%pB' in proc_pid_stack() in the tip tree: I changed it to '%pB' from '%pS'. But I think the modified '%pB' would work there as well. > We could perhaps make %pB show the hex numbers and address (so pB > would expand to "[] symbolname".if > > (a) not randomizing (so the hex numbers _may_ be useful) > > (b) kptr_restrict is 0 (so the hex numbers are "safe" in the dmesg) > > and fall back to just the symbolic name if either of those aren't true? Do we really need to check for both? '%pK' only checks kptr_restrict. I'd think we should be consistent with that. And maybe there are some scenarios where the actual text addresses provide useful debug information if KASLR is enabled and kptr_restrict is zero. > And obviously, if KALLSYMS isn't enabled, you always show hex > numbers.. That's already the case (but we might want to add the "[<>}' > markers around the hex numbers just to make the user space automation > we do have work). Even if kptr_restrict is set? -- Josh
Re: [PATCH] ALSA: snd-aoa: enable sound on PowerBook G4 12"
On Wed, 2016-08-24 at 20:57 +0300, Aaro Koskinen wrote:
> Enable sound on PowerBook G4 12".
Looks good to me, I assume you tested it and it works :)
johannes
> Signed-off-by: Aaro Koskinen
> ---
> sound/aoa/fabrics/layout.c | 8
> sound/aoa/soundbus/i2sbus/core.c | 2 +-
> 2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/sound/aoa/fabrics/layout.c b/sound/aoa/fabrics/layout.c
> index 8f71f7e..edc8681 100644
> --- a/sound/aoa/fabrics/layout.c
> +++ b/sound/aoa/fabrics/layout.c
> @@ -112,6 +112,7 @@ MODULE_ALIAS("sound-layout-100");
>
> MODULE_ALIAS("aoa-device-id-14");
> MODULE_ALIAS("aoa-device-id-22");
> +MODULE_ALIAS("aoa-device-id-31");
> MODULE_ALIAS("aoa-device-id-35");
> MODULE_ALIAS("aoa-device-id-44");
>
> @@ -362,6 +363,13 @@ static struct layout layouts[] = {
> .connections = tas_connections_nolineout,
> },
> },
> + /* PowerBook6,1 */
> + { .device_id = 31,
> + .codecs[0] = {
> + .name = "tas",
> + .connections = tas_connections_nolineout,
> + },
> + },
> /* PowerBook6,5 */
> { .device_id = 44,
> .codecs[0] = {
> diff --git a/sound/aoa/soundbus/i2sbus/core.c
> b/sound/aoa/soundbus/i2sbus/core.c
> index 1cbf210..000b585 100644
> --- a/sound/aoa/soundbus/i2sbus/core.c
> +++ b/sound/aoa/soundbus/i2sbus/core.c
> @@ -197,7 +197,7 @@ static int i2sbus_add_dev(struct macio_dev
> *macio,
> * so restrict to those we do handle for
> now.
> */
> if (id && (*id == 22 || *id == 14 || *id ==
> 35 ||
> - *id == 44)) {
> + *id == 31 || *id == 44)) {
> snprintf(dev->sound.modalias, 32,
> "aoa-device-id-%d", *id);
> ok = 1;
[GIT PULL] UBI/UBIFS fixes for 4.8-rc4
Linus, The following changes since commit 7a1dcf6adaa7cc4b8cd93a3883267497a77b1051: Merge tag 'usercopy-v4.8-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux (2016-08-23 14:32:38 -0400) are available in the git repository at: git://git.infradead.org/linux-ubifs.git tags/upstream-4.8-rc4 for you to fetch changes up to 17ce1eb0b64eb27d4f9180daae7495fa022c7b0d: ubifs: Fix xattr generic handler usage (2016-08-23 23:02:52 +0200) This pull requests contains fixes for two issues in UBI and UBIFS: 1. Wrong UBIFS assertion. 2. A UBIFS xattr regression. Richard Weinberger (1): ubifs: Fix xattr generic handler usage Vincent Stehlé (1): ubifs: Fix assertion in layout_in_gaps() fs/ubifs/tnc_commit.c | 2 +- fs/ubifs/xattr.c | 5 - 2 files changed, 5 insertions(+), 2 deletions(-)
Re: [PATCH 0/6] Apple device properties
On Mon, 22 Aug, at 11:58:50AM, Lukas Wunner wrote: > By the way, arch/x86/Kconfig says that "it is not possible to boot a > mixed-mode enabled kernel via the EFI boot stub - a bootloader that > supports the EFI handover protocol must be used". > > Is this still correct? With all the mixed-mode support in head_64.S > and eboot.c, I'm wondering what's missing? Yes, that's still correct. The EFI boot stub technically refers to the feature of having the firmware load the kernel directly, without the use of a boot loader. In that scenario you need the kernel and firmware to agree on a CPU mode since the kernel has no way to figure out if it needs to switch or not. Nor does it have a direct way to figure out what bitness the firmware is. [ Yes, technically we could add code to the EFI stub to detect the current mode and perform the switch, we just don't have anything like that right now ]
Direct cash Loans Offer!!!!
Good News, Direct cash Loans is currently giving out loan at 3.5% interest rate. Kindly forward the following details your ID Number, Full Names, Occupation, Monthly Income, Type of loan , telephone number and email address via email to this email: directcashloans_d...@webmail.co.za View attached document for more information about our special loan offer or call : +27(0)622 539 768 for more information. Commission earners can also apply. Regards, Lydia Smith (Mrs) Loan Application Unit/Risk Supervisor. Direct Cash Loan Low Rate Offer.docx Description: MS-Word 2007 document
Re: [RFC][PATCH 3/3] locking/mutex: Add lock handoff to avoid starvation
On 08/23/2016 04:32 PM, Peter Zijlstra wrote:
On Tue, Aug 23, 2016 at 03:47:53PM -0400, Waiman Long wrote:
On 08/23/2016 08:46 AM, Peter Zijlstra wrote:
N
@@ -573,8 +600,14 @@ __mutex_lock_common(struct mutex *lock,
schedule_preempt_disabled();
spin_lock_mutex(&lock->wait_lock, flags);
+ if (__mutex_owner(lock) == current)
+ break;
+
if (__mutex_trylock(lock))
break;
+
+ if (__mutex_waiter_is_first(lock,&waiter))
+ __mutex_set_flag(lock, MUTEX_FLAG_HANDOFF);
}
__set_task_state(task, TASK_RUNNING);
You may want to think about doing some spinning while the owner is active
instead of going back to sleep again here.
For sure; I just didn't bother pulling in your patches. I didn't want to
sink in more time in case people really hated on 1/3 ;-)
I think there is race in how the handoff is being done.
CPU 0 CPU 1 CPU 2
- - -
__mutex_lock_common:mutex_optimistic_spin:
__mutex_trylock()
mutex_unlock:
if (owner&
MUTEX_FLAG_HANDOFF)
owner&= 0x3;
__mutex_trylock();
owner = CPU2;
__mutex_set_flag(lock,
MUTEX_FLAG_HANDOFF)
__mutex_unlock_slowpath:
__mutex_handoff:
owner = CPU0;
Now both CPUs 1 and 2 think they have the lock. One way to fix that is
to check if the owner is still the original lock holder (CPU 0) before
doing the handoff, like:
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -97,6 +97,8 @@ static void __mutex_handoff(struct mutex *lock, struct
task_st
for (;;) {
unsigned long old, new;
+ if ((owner & ~MUTEX_FLAG_ALL) != current)
+ break;
new = (owner & MUTEX_FLAG_WAITERS);
new |= (unsigned long)task;
I also think that the MUTEX_FLAG_HANDOFF bit needs to be cleared if the list
is empty.
@@ -614,7 +633,7 @@ __mutex_lock_common(struct mutex *lock, long state,
unsigned
mutex_remove_waiter(lock, &waiter, task);
/* set it to 0 if there are no waiters left: */
if (likely(list_empty(&lock->wait_list)))
- __mutex_clear_flag(lock, MUTEX_FLAG_WAITERS);
+ __mutex_clear_flag(lock,
MUTEX_FLAG_WAITERS|MUTEX_FLAG_HANDOFF);
Or we should try to reset the handoff bit after the while loop exit if
the bit is still set.
Cheers,
Longman
Re: [PATCH 1/2] ARM: dts: sun8i: Add dts file for inet-d978_rev2 tablets
Hi,
On Tue, Aug 23, 2016 at 02:44:50PM +0800, Icenowy Zheng wrote:
> The inet-d978_rev2 is a pcb used in generic A33 based tablets. It features
> volume buttons, micro-usb otg, headphone connector and a power button.
>
> On the board a Realtek RTL8723BS SDIO Wi-Fi module are soldered, and there
> is also a accompanied board which has a Goodix GT9271 soldered.
>
> As this board is desired to create tablets with a Home key dealed by
> GT9271, a LED is present at the front panel at the position of the
> Home key.
>
> Signed-off-by: Icenowy Zheng
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts | 87
> ++
> 2 files changed, 88 insertions(+)
> create mode 100644 arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index faacd52..d1812a0 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -782,6 +782,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
> sun8i-a23-q8-tablet.dtb \
> sun8i-a33-et-q8-v1.6.dtb \
> sun8i-a33-ga10h-v1.1.dtb \
> + sun8i-a33-inet-d978-rev2.dtb \
> sun8i-a33-ippo-q8h-v1.2.dtb \
> sun8i-a33-q8-tablet.dtb \
> sun8i-a33-sinlinx-sina33.dtb \
> diff --git a/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
> b/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
> new file mode 100644
> index 000..78823d8
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
> @@ -0,0 +1,87 @@
> +/*
> + * Copyright 2015 Hans de Goede
I guess you are the author too :)
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +#include "sun8i-a33.dtsi"
> +#include "sun8i-reference-design-tablet.dtsi"
> +
> +/ {
> + model = "INet-D978 Rev 02";
> + compatible = "primux,inet-d978-rev2", "allwinner,sun8i-a33";
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <&led_pin_d978>;
> +
> + home {
> + label = "d978:home";
This is not the proper format for the led labels.
It's supposed to be ::
> + gpios = <&r_pio 0 5 GPIO_ACTIVE_HIGH>; /* PL5 */
> + };
> + };
> +};
> +
> +&mmc1_pins_a {
> + allwinner,pull = ;
> +};
> +
> +&mmc1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc1_pins_a>;
> + vmmc-supply = <®_dldo1>;
> + bus-width = <4>;
> + non-removable;
> + status = "okay";
> +
> + rtl8723bs: sdio_wifi@1 {
> + reg = <1>;
> + };
Don't you need an alias to this node to have the MAC address set?
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
Re: [PATCH v2 3/6] dt/bindings: Add bindings for Tegra GMI controller
2016-08-24 17:56 GMT+02:00 Jon Hunter :
+
>> +Example with two SJA1000 CAN controllers connected to the GMI bus. We wrap
>> the
>> +controllers with a simple-bus node since they are all connected to the same
>> +chip-select (CS4), in this example external address decoding is provided:
>> +
>> +gmi@7009 {
>> + compatible = "nvidia,tegra20-gmi";
>> + reg = <0x70009000 0x1000>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + clocks = <&tegra_car TEGRA20_CLK_NOR>;
>> + clock-names = "gmi";
>> + resets = <&tegra_car 42>;
>> + reset-names = "gmi";
>> + ranges = <4 0x4800 0x7ff>;
>> +
>> + status = "disabled";
>> +
>> + bus@4 {
>> + compatible = "simple-bus";
>> + reg = <4>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges = <0 4 0x40100>;
>
> Does this work? I tried to add an example like this and I got ...
>
> Warning (reg_format): "reg" property in /gmi@70009000/bus@4 has invalid
> length (4 bytes) (#address-cells == 1, #size-cells == 1)
Shoot, to get rid of the warning it should be
reg = <4 0 >;
But it works either way.
>
> I am wondering if we should just following the arm,pl172 example and
> have ...
>
> cs4 {
> compatible = "simple-bus";
> #address-cells = <1>;
> #size-cells = <1>;
> ranges;
>
> nvidia,snor-cs = <4>;
> nvidia,snor-mux-mode;
> nvidia,snor-adv-inv;
>
> can@0 {
> reg = <0 0x100>;
> ...
> };
>
> ...
> };
>
That means to go back to V1 really (almost :)). Which I do not mind.
Will give it a test run.
But I am a little hesitant if will be any better/cleaner. In your example above:
can@0 {
reg = <0 0x100>;
...
};
Would this really translate correctly? In the pl172 example they have
multiple ranges and address with "flash@0,0" which a range defined in
parent node. "can@0" does not have valid match in parent node in our
example. So I probably need add some more logic for it to properly
translate.
I have an idea which is following:
gmi@7009 {
status = "okay";
#address-cells = <2>;
#size-cells = <1>;
ranges = <4 0 0x4800 0x0004>;
cs4 {
compatible = "simple-bus";
#address-cells = <2>;
#size-cells = <1>;
ranges;
nvidia,snor-cs = <4>;
nvidia,snor-mux-mode;
nvidia,snor-adv-inv;
can@0 {
compatible = "nxp,sja1000";
reg = <4 0 0x100>;
...
};
can@4 {
compatible = "nxp,sja1000";
reg = <4 0x4 0x100>;
...
};
};
};
Do not know if above will work at all (not able to test at current
location), anyway I will play around with it some more and get back to
you.
Best Regards
Mirza
Re: [PATCH v4 3/3] ARM: dts: sun9i: Initial support for the Sunchip CX-A99 board
On Mon, Aug 22, 2016 at 11:29:59PM +0200, Rask Ingemann Lambertsen wrote:
> On Mon, Aug 22, 2016 at 08:57:45PM +0200, Maxime Ripard wrote:
> > Hi,
> >
> > On Sat, Aug 13, 2016 at 12:03:57AM +0200, Rask Ingemann Lambertsen wrote:
> > > The Suncip CX-A99 board is found in at least four brands of TV boxes.
> > > It features an Allwinner A80 SOC, with either 2 GiB DDR3 DRAM and
> > > 16 GB eMMC or 4 GiB DDR3 DRAM and 32 GB eMMC, as well as several support
> > > chips for Ethernet, wireless networking, video output, SATA and power
> > > management. For details, see the linux-sunxi page about the board
> > > https://linux-sunxi.org/Sunchip_CX-A99>.
> > >
> > > This patch only adds support for the SD and eMMC storage, real-time clock,
> > > USB 2.0 ports (and by extension the SATA port), the UART port and the
> > > LEDs.
> > > All of this relies on the boot loader to leave those parts powered up, as
> > > I'm still working on a driver for the AXP808 PMIC.
> > >
> > > Signed-off-by: Rask Ingemann Lambertsen
> >
> > It looks mostly good, but I have a couple of comments though, see below.
> >
> > > ---
> > >
> > > Although the vendor U-Boot lets you boot the kernel on one of the
> > > Cortex-A15 cores, the kernel gpio-regulator driver currently glitches
> > > the GPIO lines to the OZ80120 regulator such that the system crashes
> > > during startup. This part needs further work to be useful.
> >
> > So it doesn't power the CPU through one of the AXP regulators?
> > Interesting design.
>
> The Cortex-A7 cores are powered by the dcdca regulator on the AXP 808 PMIC.
> Right now, I'm using the AXP 806 driver that Chen-Yu Tsai posted to drive
> the AXP 808 and so far, it looks good.
Ok.
> > > + leds {
> > > + compatible = "gpio-leds";
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&led_pins_cx_a99>;
> > > +
> > > + blue {
> > > + gpios = <&pio 6 10 GPIO_ACTIVE_HIGH>; /* PG10 */
> > > + label = "cx-a99:blue:normal";
> > > + default-state = "on";
> > > + };
> > > +
> > > + red {
> > > + gpios = <&pio 6 11 GPIO_ACTIVE_HIGH>; /* PG11 */
> > > + label = "cx-a99:red:standby";
> >
> > The last part of the label should be the function.
>
> I'm not sure what else to label them. They form a bi-colour LED emitting
> through the front of the device. The stock OS lights the blue LED when
> the device is powered on and lights the red LED when the device is
> suspended. There is no label on the front of the device telling what the
> colours mean. Documentation/devicetree/bindings/leds/common.txt and
> Documentation/devicetree/bindings/leds/leds-gpio.txt don't provide much in
> the way of examples. Suggestions are welcome.
H. status for both then?
> [snip]
> > > +
> > > +/* Each GPIO controls VBUS for a port on the GL850G hub connected to
> > > ehci0;
> > > + * PL7 for port 1, the USB connector closest to the 12 V power
> > > connector, and
> > > + * PL8 for port 2, the USB connector next to the (micro)SD card slot.
> > > + * Note: The regulators are not chained like this in reality, but
> > > + * regulator-fixed doesn't support a gpio list, and
> > > allwinner,sun9i-a80-usb-phy
> > > + * doesn't support more than one supply, so this will have to do (for
> > > now).
> > > + */
> > > +®_usb1_vbus {
> > > + pinctrl-0 = <&usb1_vbus_r_pin_cx_a99>;
> > > + gpio = <&r_pio 0 7 GPIO_ACTIVE_HIGH>; /* PL7 */
> > > + status = "okay";
> > > +};
> > > +
> > > +®_usb2_vbus {
> > > + pinctrl-0 = <&usb2_vbus_r_pin_cx_a99>;
> > > + gpio = <&r_pio 0 8 GPIO_ACTIVE_HIGH>; /* PL8 */
> >
> > I'd really prefer it to be modelled properly, and not attached to the
> > wrong device.
> >
> > I have some work pending to allow multiple regulators in the same
> > property, but that won't be ready soon.
> >
> > For the time being, I would suggest having two usb1 regulators
> > defined, each with their respective GPIOs, and one set to always on
> > (and keep that great comment).
>
> Will do if I don't come up with something better. I gave it a shot to
> describe the hub as a child of ehci0 with a child node for each of the
> two ports, but it didn't work.
>
> Also, using the phy-supply property for the vbus-supply is an ugly hack,
> in the first place, isn't it? Shouldn't it be more like this?
>
> &usbphy1 {
> phy-supply = <®_vcc33_usbh>;
> };
>
> &ehci0 {
> vcc-supply = <®_vdd09_usbh>;
> phy = <&usbphy1>;
>
> hub@1 {
> port@1 {
> vbus-supply = <®_usb1_vbus>;
> }
>
> port@2 {
> vbus-supply = <®_usb2_vbus>;
> }
> };
> };
It looks great to me. I'm not really sure how happy the DT maintainers
are going to be about it, and how easy it would be to support without
breaking the existing users.
> It would generally be great to be able to describe regulators that should
> be
Re: [Regression?] Commit cb4f71c429 deliberately changes order of network interfaces
Hello, On Wed, 24 Aug 2016 14:27:58 -0400, Lennart Sorensen wrote: > On Wed, Aug 24, 2016 at 08:14:44PM +0200, Thomas Petazzoni wrote: > > Depends on the network driver I believe. But with an e1000e NIC plugged > > in a PCIe slot, it indeed gets assigned as eth0, and the internal > > mvneta devices get eth1, eth2, etc. > > Which of course means the change does not actually ensure the port > ordering matches the marvell documentation or u-boot. It only handles > the relative order of the ports. For now. Correct. > So since it doesn't actually work, maybe reverting it so it no longer > violates the dtb ordeting rule makes sense. I'll let the platform maintainers decide what's the least intrusive/problematic option. Both solutions have drawbacks, so it's really a "political" decision to make here. > Doesn't mean openwrt/lede/etc don't have to deal with the ordering in > the future if async probing takes off. Not only async probing, but also PCIe devices, as you mentioned earlier :-) Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
[PATCH 6/6 linux-next] ext4: fix memory leak in ext4_insert_range()
Running xfstests generic/013 with kmemleak gives the following:
unreferenced object 0x8801d3d27de0 (size 96):
comm "fsstress", pid 4941, jiffies 4294860168 (age 53.485s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
backtrace:
[] kmemleak_alloc+0x23/0x40
[] __kmalloc+0xf5/0x1d0
[] ext4_find_extent+0x1ec/0x2f0
[] ext4_insert_range+0x34c/0x4a0
[] ext4_fallocate+0x4e2/0x8b0
[] vfs_fallocate+0x134/0x210
[] SyS_fallocate+0x3f/0x60
[] entry_SYSCALL_64_fastpath+0x13/0x8f
[] 0x
Problem seems mitigated by dropping refs and freeing path
when there's no path[depth].p_ext
Signed-off-by: Fabian Frederick
---
fs/ext4/extents.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index 5b0913d..2774df4 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -5711,6 +5711,9 @@ int ext4_insert_range(struct inode *inode, loff_t offset,
loff_t len)
up_write(&EXT4_I(inode)->i_data_sem);
goto out_stop;
}
+ } else {
+ ext4_ext_drop_refs(path);
+ kfree(path);
}
ret = ext4_es_remove_extent(inode, offset_lblk,
--
2.8.1
[PATCH 3/6 linux-next] ext4: create EXT4_MAX_BLOCKS() macro
Create a macro to calculate length + offset -> maximum blocks
This adds more readability.
Signed-off-by: Fabian Frederick
---
fs/ext4/ext4.h| 3 +++
fs/ext4/extents.c | 15 +++
fs/ext4/file.c| 3 +--
3 files changed, 7 insertions(+), 14 deletions(-)
diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index ea31931..6e98f3f 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -262,6 +262,9 @@ struct ext4_io_submit {
(s)->s_first_ino)
#endif
#define EXT4_BLOCK_ALIGN(size, blkbits)ALIGN((size), (1 <<
(blkbits)))
+#define EXT4_MAX_BLOCKS(size, offset, blkbits) \
+ ((EXT4_BLOCK_ALIGN(size + offset, blkbits) >> blkbits) - (offset >> \
+ blkbits))
/* Translate a block number to a cluster number */
#define EXT4_B2C(sbi, blk) ((blk) >> (sbi)->s_cluster_bits)
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index 4f1cca8..ac54907 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -4960,13 +4960,8 @@ long ext4_fallocate(struct file *file, int mode, loff_t
offset, loff_t len)
trace_ext4_fallocate_enter(inode, offset, len, mode);
lblk = offset >> blkbits;
- /*
-* We can't just convert len to max_blocks because
-* If blocksize = 4096 offset = 3072 and len = 2048
-*/
- max_blocks = (EXT4_BLOCK_ALIGN(len + offset, blkbits) >> blkbits)
- - lblk;
+ max_blocks = EXT4_MAX_BLOCKS(len, offset, blkbits);
flags = EXT4_GET_BLOCKS_CREATE_UNWRIT_EXT;
if (mode & FALLOC_FL_KEEP_SIZE)
flags |= EXT4_GET_BLOCKS_KEEP_SIZE;
@@ -5029,12 +5024,8 @@ int ext4_convert_unwritten_extents(handle_t *handle,
struct inode *inode,
unsigned int credits, blkbits = inode->i_blkbits;
map.m_lblk = offset >> blkbits;
- /*
-* We can't just convert len to max_blocks because
-* If blocksize = 4096 offset = 3072 and len = 2048
-*/
- max_blocks = ((EXT4_BLOCK_ALIGN(len + offset, blkbits) >> blkbits) -
- map.m_lblk);
+ max_blocks = EXT4_MAX_BLOCKS(len, offset, blkbits);
+
/*
* This is somewhat ugly but the idea is clear: When transaction is
* reserved, everything goes into it. Otherwise we rather start several
diff --git a/fs/ext4/file.c b/fs/ext4/file.c
index 261ac37..34acda7 100644
--- a/fs/ext4/file.c
+++ b/fs/ext4/file.c
@@ -144,8 +144,7 @@ ext4_file_write_iter(struct kiocb *iocb, struct iov_iter
*from)
int err, len;
map.m_lblk = pos >> blkbits;
- map.m_len = (EXT4_BLOCK_ALIGN(pos + length, blkbits) >>
blkbits)
- - map.m_lblk;
+ map.m_len = EXT4_MAX_BLOCKS(length, pos, blkbits);
len = map.m_len;
err = ext4_map_blocks(NULL, inode, &map, 0);
--
2.8.1
[PATCH 4/6 linux-next] ext4: use bool for check in ext4_ext_space_()
check is used in 0/1 context.
Also use unsigned int instead of unsigned (checkpatch warning)
Signed-off-by: Fabian Frederick
---
fs/ext4/extents.c | 33 ++---
1 file changed, 18 insertions(+), 15 deletions(-)
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index ac54907..5b0913d 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -241,7 +241,7 @@ ext4_ext_new_meta_block(handle_t *handle, struct inode
*inode,
return newblock;
}
-static inline int ext4_ext_space_block(struct inode *inode, int check)
+static inline int ext4_ext_space_block(struct inode *inode, bool check)
{
int size;
@@ -254,7 +254,7 @@ static inline int ext4_ext_space_block(struct inode *inode,
int check)
return size;
}
-static inline int ext4_ext_space_block_idx(struct inode *inode, int check)
+static inline int ext4_ext_space_block_idx(struct inode *inode, bool check)
{
int size;
@@ -267,7 +267,7 @@ static inline int ext4_ext_space_block_idx(struct inode
*inode, int check)
return size;
}
-static inline int ext4_ext_space_root(struct inode *inode, int check)
+static inline int ext4_ext_space_root(struct inode *inode, bool check)
{
int size;
@@ -363,14 +363,14 @@ ext4_ext_max_entries(struct inode *inode, int depth)
if (depth == ext_depth(inode)) {
if (depth == 0)
- max = ext4_ext_space_root(inode, 1);
+ max = ext4_ext_space_root(inode, true);
else
- max = ext4_ext_space_root_idx(inode, 1);
+ max = ext4_ext_space_root_idx(inode, true);
} else {
if (depth == 0)
- max = ext4_ext_space_block(inode, 1);
+ max = ext4_ext_space_block(inode, true);
else
- max = ext4_ext_space_block_idx(inode, 1);
+ max = ext4_ext_space_block_idx(inode, true);
}
return max;
@@ -864,7 +864,7 @@ int ext4_ext_tree_init(handle_t *handle, struct inode
*inode)
eh->eh_depth = 0;
eh->eh_entries = 0;
eh->eh_magic = EXT4_EXT_MAGIC;
- eh->eh_max = cpu_to_le16(ext4_ext_space_root(inode, 0));
+ eh->eh_max = cpu_to_le16(ext4_ext_space_root(inode, false));
ext4_mark_inode_dirty(handle, inode);
return 0;
}
@@ -1109,7 +1109,7 @@ static int ext4_ext_split(handle_t *handle, struct inode
*inode,
neh = ext_block_hdr(bh);
neh->eh_entries = 0;
- neh->eh_max = cpu_to_le16(ext4_ext_space_block(inode, 0));
+ neh->eh_max = cpu_to_le16(ext4_ext_space_block(inode, false));
neh->eh_magic = EXT4_EXT_MAGIC;
neh->eh_depth = 0;
@@ -1183,7 +1183,8 @@ static int ext4_ext_split(handle_t *handle, struct inode
*inode,
neh = ext_block_hdr(bh);
neh->eh_entries = cpu_to_le16(1);
neh->eh_magic = EXT4_EXT_MAGIC;
- neh->eh_max = cpu_to_le16(ext4_ext_space_block_idx(inode, 0));
+ neh->eh_max = cpu_to_le16(ext4_ext_space_block_idx(inode,
+ false));
neh->eh_depth = cpu_to_le16(depth - i);
fidx = EXT_FIRST_INDEX(neh);
fidx->ei_block = border;
@@ -1310,9 +1311,10 @@ static int ext4_ext_grow_indepth(handle_t *handle,
struct inode *inode,
/* old root could have indexes or leaves
* so calculate e_max right way */
if (ext_depth(inode))
- neh->eh_max = cpu_to_le16(ext4_ext_space_block_idx(inode, 0));
+ neh->eh_max = cpu_to_le16(ext4_ext_space_block_idx(inode,
+ false));
else
- neh->eh_max = cpu_to_le16(ext4_ext_space_block(inode, 0));
+ neh->eh_max = cpu_to_le16(ext4_ext_space_block(inode, false));
neh->eh_magic = EXT4_EXT_MAGIC;
ext4_extent_block_csum_set(inode, neh);
set_buffer_uptodate(bh);
@@ -1328,7 +1330,8 @@ static int ext4_ext_grow_indepth(handle_t *handle, struct
inode *inode,
ext4_idx_store_pblock(EXT_FIRST_INDEX(neh), newblock);
if (neh->eh_depth == 0) {
/* Root extent block becomes index block */
- neh->eh_max = cpu_to_le16(ext4_ext_space_root_idx(inode, 0));
+ neh->eh_max = cpu_to_le16(ext4_ext_space_root_idx(inode,
+ false));
EXT_FIRST_INDEX(neh)->ei_block =
EXT_FIRST_EXTENT(neh)->ee_block;
}
@@ -1816,7 +1819,7 @@ static void ext4_ext_try_to_merge_up(handle_t *handle,
struct ext4_ext_path *path)
{
size_t s;
- unsigned max_root = ext4_ext_space_root(inode, 0);
+ unsigned int max_root = ext4_ext_space_root(inode, false);
ext4_fsblk_
[PATCH 5/6 linux-next] ext4: remove unused definition
MAX_32_NUM isn't used in ext4 Signed-off-by: Fabian Frederick --- fs/ext4/ioctl.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c index 10686fd..5a708c87 100644 --- a/fs/ext4/ioctl.c +++ b/fs/ext4/ioctl.c @@ -19,8 +19,6 @@ #include "ext4_jbd2.h" #include "ext4.h" -#define MAX_32_NUM unsigned long long) 1) << 32) - 1) - /** * Swap memory between @a and @b for @len bytes. * -- 2.8.1
[PATCH 1/6 linux-next] ext4: avoid EXT4_INODE_EXTENTS double checking
ext4_collapse_range() and ext4_insert_range()
already checked inode flag at the beginning of function.
Signed-off-by: Fabian Frederick
---
fs/ext4/extents.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index d7ccb7f..5d9f99a 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -5506,12 +5506,6 @@ int ext4_collapse_range(struct inode *inode, loff_t
offset, loff_t len)
goto out_mutex;
}
- /* Currently just for extent based files */
- if (!ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS)) {
- ret = -EOPNOTSUPP;
- goto out_mutex;
- }
-
/* Wait for existing dio to complete */
ext4_inode_block_unlocked_dio(inode);
inode_dio_wait(inode);
@@ -5643,11 +5637,6 @@ int ext4_insert_range(struct inode *inode, loff_t
offset, loff_t len)
}
inode_lock(inode);
- /* Currently just for extent based files */
- if (!ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS)) {
- ret = -EOPNOTSUPP;
- goto out_mutex;
- }
/* Check for wrap through zero */
if (inode->i_size + len > inode->i_sb->s_maxbytes) {
--
2.8.1
Re: [PATCH v6 2/2] clocksource: add J-Core timer/clocksource driver
On Wednesday, August 24, 2016 1:40:01 PM CEST Rich Felker wrote:
> On Wed, Aug 24, 2016 at 06:42:05PM +0200, Daniel Lezcano wrote:
> > > diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> > > index 5677886..3210ca5 100644
> > > --- a/drivers/clocksource/Kconfig
> > > +++ b/drivers/clocksource/Kconfig
> > > @@ -407,6 +407,15 @@ config SYS_SUPPORTS_SH_TMU
> > > config SYS_SUPPORTS_EM_STI
> > > bool
> > >
> > > +config CLKSRC_JCORE_PIT
> > > + bool "J-Core PIT timer driver"
> > > + depends on OF && (SUPERH || COMPILE_TEST)
> >
> > Even if this is correct, for the sake of consistency, it is preferable
> > to change it to:
> >
> > bool "J-Core PIT timer driver" if COMPILE_TEST
> > depends on SUPERH
> > select CLKSRC_OF
>
> Is this functionally equivalent? If so that's non-obvious to me. What
> about the dropped OF dependency? The intent is that the option should
> always be available for SUPERH targets using OF, otherwise only
> available with COMPILE_TEST.
I think your version is correct here, Daniel made a mistake with the
SUPERH dependency. Another way to write it would be
config CLKSRC_JCORE_PIT
bool "J-Core PIT timer driver" if COMPILE_TEST && !JCORE
depends on OF
default JCORE
to make it impossible to disable when JCORE is set, but
user-visible on all other architectures, SUPERH or otherwise.
> > > +static int jcore_pit_set(unsigned long delta, struct jcore_pit *pit)
> > > +{
> > > + jcore_pit_disable(pit);
> > > + __raw_writel(delta, pit->base + REG_THROT);
> > > + __raw_writel(pit->enable_val, pit->base + REG_PITEN);
> > > + return 0;
> >
> > Why do you need to use __raw_writel ?
> >
> > s/__raw_writel/writel/
>
> I actually tried multiple times to find good resources on policy for
> which form to prefer, but didn't have much luck. My understanding is
> that __raw_writel/__raw_readl always performs a native-endian
> load/store, whereas writel/readl behavior depends on cpu endianness
> and whether the arch declares that "pci bus" (that was the term I
> found in the source, not relevant here) io is endian-swapped or not.
> Can you give me a better explanation of why we might prefer one form
> or the other?
In general, a portable driver should use readl/writel because they
are defined to have the behavior that x86 provides, which is what
most developers understand best. Compared to __raw_readl/__raw_writel,
it guarantees
- correct endianess (in most cases, exceptions see below)
- does not leak out of spinlocks
- accesses are word-sized, the compiler cannot split them into
byte accesses, or merge subsequent accesses into larger words
- ordering against dma_map_*/dma_unmap_*/dma_sync_* is maintained
The __raw_* accessors are used as building blocks for
readl/outl/ioread32/ioread32_be/readl_relaxed/... and they can
usually be used safely on device RAM such as framebuffers but
not much else in portable code. Some architectures also use the
__raw_* accessors for MMIO registers, but that code is generally
not portable.
Endianess is always more complicated than one thinks, and it's
handled differently across architectures, sometimes because of
hardware differences, sometimes for historic reasons that differ
only in the Linux implementation.
A large majority of devices are fixed to little-endian MMIO
registers (as recommended by PCI), so that is a good default.
Exceptions to this are:
* Some architectures (e.g. PowerPC) typically run big-endian code,
and hardware designers decided to make the MMIO registers the
same. In this case, you can generally use ioread32_be/iowrite32_be.
* Some devices have configurable endianess with a device specific
register.
Sometimes those registers are set to match the CPU endianess,
but for Linux it tends to be better to just set them to
little-endian and use readl/writel
* Some drivers are configurable at HW synthesis time, and we have
a mix of devices. If you have this, you usually need to support
both ways in the driver with a helper function that uses ioread32
or ioread32_be depending on the configuration. This can be done
using either compile-time or runtime configuration.
* Some SoCs have boot-time configurable endianess and enforce that
MMIO registers and the CPU always use the same way. We are
inconsistent in handling those, I'd recommend creating a header
file for that SoC that defines vendor specific helper functions.
* Some (usually very old) SoCs have configurable endianess, but
don't actually change the behavior of the SoC or the MMIO devices,
but only flip the address lines on the memory interface.
This is similar to the previous one, but has additional problems
with FIFO registers. You generally cannot use portable drivers
here.
Arnd
[PATCH 0/6 linux-next] ext4: fix extent leaking and clean-up
Last patch of this small patchset fixes an extent path memory leak. The rest is some clean-up. Fabian Frederick (6): ext4: avoid EXT4_INODE_EXTENTS double checking ext4: remove unneeded test in ext4_alloc_file_blocks() ext4: create EXT4_MAX_BLOCKS() macro ext4: use bool for check in ext4_ext_space_() ext4: remove unused definition ext4: fix memory leak in ext4_insert_range() fs/ext4/ext4.h| 3 +++ fs/ext4/extents.c | 70 --- fs/ext4/file.c| 3 +-- fs/ext4/ioctl.c | 2 -- 4 files changed, 29 insertions(+), 49 deletions(-) -- 2.8.1
[GIT PULL] UML fixes for 4.8-rc4
Linus, The following changes since commit 7a1dcf6adaa7cc4b8cd93a3883267497a77b1051: Merge tag 'usercopy-v4.8-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux (2016-08-23 14:32:38 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git for-linus-4.8-rc4 for you to fetch changes up to dad2232844073295c64e9cc2d734a0ade043e0f6: um: Don't discard .text.exit section (2016-08-23 23:16:16 +0200) This pull request contains a fix for a build regression introduced during the merge window. Andrey Ryabinin (1): um: Don't discard .text.exit section arch/um/include/asm/common.lds.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Re: [PATCH 01/10] reset: ath79: add driver Kconfig option
On Thursday, August 25, 2016 3:18:55 AM CEST Masahiro Yamada wrote: > Hi Arnd, > > > 2016-08-25 0:51 GMT+09:00 Arnd Bergmann : > > On Wednesday, August 24, 2016 3:28:53 PM CEST Philipp Zabel wrote: > >> if RESET_CONTROLLER > >> > >> +config RESET_ATH79 > >> + bool "AR71xx Reset Driver" if COMPILE_TEST > >> + default ATH79 > >> + help > >> + This enables the ATH79 reset controller driver that supports the > >> + AR71xx SoC reset controller. > >> + > >> > > > > Nice series! > > > > Just note that there is one possible problem with COMPILE_TEST > > when the platforms are enabled, as you can then disable a driver > > that is normally there, and that can in turn cause problems in > > rare cases, e.g. when the driver has a global function that is > > called from platform code. I don't know if any of the drivers > > do that, but if they do, you'd have to use > > > > config RESET_ATH79 > >bool "AR71xx Reset Driver" if COMPILE_TEST && !ATH79 > >default ATH79 > > > > to ensure that it's impossible to disable the driver on platforms > > that require it. > > Hmm, > Can we do this only when we really have to do so? > I think we should not care about such a rare case that may not happen. > > Let's start with only "if COMPILE_TEST", > and take a look at it if a build error is detected. > > Anyway, depending on platform code is a sign of weird implementation. > > It might be better to find a potential issue rather than hide it. > > > I just checked the object files in an allyesconfig build and found one instance: arch/arm/mach-sunxi/sunxi.c:extern void __init sun6i_reset_init(void); arch/arm/mach-sunxi/sunxi.c:sun6i_reset_init(); drivers/reset/reset-sunxi.c:void __init sun6i_reset_init(void) We should definitely make sure this one is handled right, and maybe check the source code for other instances. Arnd
[PATCH 2/6 linux-next] ext4: remove unneeded test in ext4_alloc_file_blocks()
ext4_alloc_file_blocks() is called from ext4_zero_range() and
ext4_fallocate() both already testing EXT4_INODE_EXTENTS
We can call ext_depth(inode) unconditionnally.
Signed-off-by: Fabian Frederick
---
fs/ext4/extents.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index 5d9f99a..4f1cca8 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -4693,13 +4693,7 @@ static int ext4_alloc_file_blocks(struct file *file,
ext4_lblk_t offset,
* credits to insert 1 extent into extent tree
*/
credits = ext4_chunk_trans_blocks(inode, len);
- /*
-* We can only call ext_depth() on extent based inodes
-*/
- if (ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS))
- depth = ext_depth(inode);
- else
- depth = -1;
+ depth = ext_depth(inode);
retry:
while (ret >= 0 && len) {
--
2.8.1
