* [PATCH v2 3/6] clocksource/drivers: atmel-pit: allow unselecting ATMEL_PIT
From: Daniel Lezcano @ 2018-01-08 7:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180107184455.GG5545@piout.net>
On 07/01/2018 19:44, Alexandre Belloni wrote:
> On 07/01/2018 at 19:07:13 +0100, Daniel Lezcano wrote:
>> On 05/01/2018 15:30, Alexandre Belloni wrote:
>>> With the new TCB clocksource driver, atmel platforms are now able to boot
>>> without the PIT driver. Allow unselecting it.
>>>
>>> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>>> ---
>>> drivers/clocksource/Kconfig | 9 ++++++++-
>>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>>> index 5609572e0236..55ccfa0ba63b 100644
>>> --- a/drivers/clocksource/Kconfig
>>> +++ b/drivers/clocksource/Kconfig
>>> @@ -381,7 +381,14 @@ config ARMV7M_SYSTICK
>>>
>>> config ATMEL_PIT
>>> select TIMER_OF if OF
>>> - def_bool SOC_AT91SAM9 || SOC_SAMA5
>>> + bool "Atmel Periodic Interval Timer (PIT)"
>>> + depends on SOC_AT91SAM9 || SOC_SAMA5
>>> + default SOC_AT91SAM9 || SOC_SAMA5
>>> + help
>>> + Select this to get a clocksource based on the Atmel Periodic Interval
>>> + Timer. It has a relatively low resolution and the TC Block clocksource
>>> + should be preferred.
>>> + It also provides a clock event device.
>>
>> Please conform to the format:
>>
>> config ATMEL_PIT
>> bool "Atmel Periodic Interval Timer (PIT)" if COMPILE_TEST
>> select ...
>> help
>> bla bla
>>
>> and select ATMEL_PIT from the platform's Kconfig.
>>
>
> Well, the goal is actually to allow people to unselect it so we don't
> want the platform to select it.
Why do you need people to unselect it?
The goal of the Kconfig here is to be silent except in the case the
COMPILE_TEST option is set for cross-compilation test coverage.
We are migrating all these options to this format. Please make it silent.
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [v2,03/11] arm64: Take into account ID_AA64PFR0_EL1.CSV3
From: Jayachandran C @ 2018-01-08 7:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515157961-20963-4-git-send-email-will.deacon@arm.com>
On Fri, Jan 05, 2018 at 01:12:33PM +0000, Will Deacon wrote:
> For non-KASLR kernels where the KPTI behaviour has not been overridden
> on the command line we can use ID_AA64PFR0_EL1.CSV3 to determine whether
> or not we should unmap the kernel whilst running at EL0.
>
> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm64/include/asm/sysreg.h | 1 +
> arch/arm64/kernel/cpufeature.c | 8 +++++++-
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> index 08cc88574659..ae519bbd3f9e 100644
> --- a/arch/arm64/include/asm/sysreg.h
> +++ b/arch/arm64/include/asm/sysreg.h
> @@ -437,6 +437,7 @@
> #define ID_AA64ISAR1_DPB_SHIFT 0
>
> /* id_aa64pfr0 */
> +#define ID_AA64PFR0_CSV3_SHIFT 60
> #define ID_AA64PFR0_SVE_SHIFT 32
> #define ID_AA64PFR0_GIC_SHIFT 24
> #define ID_AA64PFR0_ASIMD_SHIFT 20
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 9f0545dfe497..d723fc071f39 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -145,6 +145,7 @@ static const struct arm64_ftr_bits ftr_id_aa64isar1[] = {
> };
>
> static const struct arm64_ftr_bits ftr_id_aa64pfr0[] = {
> + ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR0_CSV3_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_SVE_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_GIC_SHIFT, 4, 0),
> S_ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_ASIMD_SHIFT, 4, ID_AA64PFR0_ASIMD_NI),
> @@ -851,6 +852,8 @@ static int __kpti_forced; /* 0: not forced, >0: forced on, <0: forced off */
> static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
> int __unused)
> {
> + u64 pfr0 = read_sanitised_ftr_reg(SYS_ID_AA64PFR0_EL1);
> +
> /* Forced on command line? */
> if (__kpti_forced) {
> pr_info_once("kernel page table isolation forced %s by command line option\n",
> @@ -862,7 +865,9 @@ static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
> if (IS_ENABLED(CONFIG_RANDOMIZE_BASE))
> return true;
>
> - return false;
> + /* Defer to CPU feature registers */
> + return !cpuid_feature_extract_unsigned_field(pfr0,
> + ID_AA64PFR0_CSV3_SHIFT);
If I read this correctly, this enables KPTI on all processors without the CSV3
set (which seems to be a future capability).
Turning on KPTI has a small but significant overhead, so I think we should turn
it off on processors that are not vulnerable to CVE-2017-5754. Can we add something
like this:
--->8
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 19ed09b..202b037 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -862,6 +862,13 @@ static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
return __kpti_forced > 0;
}
+ /* Don't force KPTI for CPUs that are not vulnerable */
+ switch (read_cpuid_id() & MIDR_CPU_MODEL_MASK) {
+ case MIDR_CAVIUM_THUNDERX2:
+ case MIDR_BRCM_VULCAN:
+ return false;
+ }
+
/* Useful for KASLR robustness */
if (IS_ENABLED(CONFIG_RANDOMIZE_BASE))
return true;
--
JC
^ permalink raw reply related
* [PATCH 0/2] pinctrl: meson: use one uniform 'function' name
From: Yixun Lan @ 2018-01-08 7:33 UTC (permalink / raw)
To: linux-arm-kernel
These two patches are general improvement for meson pinctrl driver.
It make the two pinctrl trees (ee/ao) to share one uniform 'function' name for
one hardware block even its pin groups live inside two differet hardware domains,
which for example EE vs AO domain here.
This idea is motivated by Martin's question at [1]
[1]
http://lkml.kernel.org/r/CAFBinCCuQ-NK747+GHDkhZty_UMMgzCYOYFcNTrRDJgU8OM=Gw at mail.gmail.com
Yixun Lan (2):
pinctrl: meson: introduce a macro to have name/groups seperated
pinctrl: meson-axg: correct the pin expansion of UART_AO_B
drivers/pinctrl/meson/pinctrl-meson-axg.c | 4 ++--
drivers/pinctrl/meson/pinctrl-meson.h | 8 +++++---
2 files changed, 7 insertions(+), 5 deletions(-)
--
2.15.1
^ permalink raw reply
* [PATCH 1/2] pinctrl: meson: introduce a macro to have name/groups seperated
From: Yixun Lan @ 2018-01-08 7:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180108073328.205769-1-yixun.lan@amlogic.com>
We introduce a macro FUNCTION_EX here, the main motivation is
trying to have the possibility to expand the macro with the same of the
'.name' number but different multiple '.groups/.num_groups' numbers.
With this change, the meson pinctrl drivr is capable of have one uniform
'function' name but with different pin 'groups', as we face the sitiuation
that two pin groups may live inside different hardware domain (EE vs AO domain),
which mean we couldn't put them in one single group.
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
drivers/pinctrl/meson/pinctrl-meson.h | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/pinctrl/meson/pinctrl-meson.h b/drivers/pinctrl/meson/pinctrl-meson.h
index 12a391109329..d8f705098810 100644
--- a/drivers/pinctrl/meson/pinctrl-meson.h
+++ b/drivers/pinctrl/meson/pinctrl-meson.h
@@ -124,13 +124,15 @@ struct meson_pinctrl {
struct device_node *of_node;
};
-#define FUNCTION(fn) \
+#define FUNCTION_EX(fn, ex) \
{ \
.name = #fn, \
- .groups = fn ## _groups, \
- .num_groups = ARRAY_SIZE(fn ## _groups), \
+ .groups = fn ## ex ## _groups, \
+ .num_groups = ARRAY_SIZE(fn ## ex ## _groups), \
}
+#define FUNCTION(fn) FUNCTION_EX(fn, )
+
#define BANK(n, f, l, fi, li, per, peb, pr, pb, dr, db, or, ob, ir, ib) \
{ \
.name = n, \
--
2.15.1
^ permalink raw reply related
* [PATCH 2/2] pinctrl: meson-axg: correct the pin expansion of UART_AO_B
From: Yixun Lan @ 2018-01-08 7:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180108073328.205769-1-yixun.lan@amlogic.com>
The 'uart_ao_b_groups' for the UART_AO_B pins is already defined which is
living inside the AO domain, for these pins which are routed out from EE domain,
we need to correct them with the 'FUNCTION_EX' macro, otherwise there is
a conflict in the code level.
Also slightly adjust the name to make it short and more consistent.
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
drivers/pinctrl/meson/pinctrl-meson-axg.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/meson/pinctrl-meson-axg.c b/drivers/pinctrl/meson/pinctrl-meson-axg.c
index 1fda9d6c7ea3..308e5433bd04 100644
--- a/drivers/pinctrl/meson/pinctrl-meson-axg.c
+++ b/drivers/pinctrl/meson/pinctrl-meson-axg.c
@@ -716,7 +716,7 @@ static const char * const uart_b_groups[] = {
"uart_tx_b_x", "uart_rx_b_x", "uart_cts_b_x", "uart_rts_b_x",
};
-static const char * const uart_ao_b_gpioz_groups[] = {
+static const char * const uart_ao_b_z_groups[] = {
"uart_ao_tx_b_z", "uart_ao_rx_b_z",
"uart_ao_cts_b_z", "uart_ao_rts_b_z",
};
@@ -855,7 +855,7 @@ static struct meson_pmx_func meson_axg_periphs_functions[] = {
FUNCTION(nand),
FUNCTION(uart_a),
FUNCTION(uart_b),
- FUNCTION(uart_ao_b_gpioz),
+ FUNCTION_EX(uart_ao_b, _z),
FUNCTION(i2c0),
FUNCTION(i2c1),
FUNCTION(i2c2),
--
2.15.1
^ permalink raw reply related
* [PATCH v4 2/6] clk: renesas: rcar-gen3: Add Z2 clock divider support
From: Simon Horman @ 2018-01-08 8:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdWk3ke6GriUdxHp_62r-REYV3P4qNiNGOcGRiCQWCyKAg@mail.gmail.com>
On Fri, Jan 05, 2018 at 03:35:13PM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Fri, Jan 5, 2018 at 3:04 PM, Simon Horman <horms@verge.net.au> wrote:
> > On Wed, Jan 03, 2018 at 01:47:08PM +0100, Geert Uytterhoeven wrote:
> >> On Wed, Jan 3, 2018 at 1:18 PM, Simon Horman <horms+renesas@verge.net.au> wrote:
> >> > From: Takeshi Kihara <takeshi.kihara.df@renesas.com>
> >> >
> >> > This patch adds Z2 clock divider support for R-Car Gen3 SoC.
> >> >
> >> > Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
> >> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>
> >> As the CPG/MSSR driver now has suspend/resume support, do we need
> >> a notifier to restore the Z or Z2 registers? Or is that handled automatically
> >> by cpufreq during system resume, for both the primary and the secondary
> >> CPU cores?
> >
> > I am a bit unsure.
> >
> > When using the A57 cores, which is the default case, the Z clk is queried
> > by CPUFreq on resume. It appears that on my system its already set to the
> > correct value but I assume if it was not then it would be reset. However,
> > this does not cover Z2 clk. So perhaps to be safe we need to register
> > notifiers and make sure they they play nicely with CPUFreq?
>
> Of course the CPU is special: unlike many other devices, it must be running
> when the kernel is reentered upon system resume.
> It may be running using a different frequency setting, though.
> However, following "opp-suspend", the system will always suspend with the
> Z clock running at 1.5GHz, which is the default?
> So Z is probably OK.
>
> It's more interesting to check what happens when the little cores are
> enabled as well (unfortunately that requires different firmware).
> 1. Does cpufreq handle them correctly when they are onlined again during
> system resume?
> 2. What happens if you offline all big cores, and enter system suspend
> running with little cores only?
> Perhaps that's prevented by the "opp-suspend" property as well?
Thanks for clarifying the problem.
I should be able to install updated firmware on:
i* r8a7796 (M3-W) ES1.0 / Salvator-X; and
* r8a7795 (H3) ES2.0 / Salvator-XS.
* But not easily r8a7795 (H3) / Salvator-X
Do you know what the minimal / desired firmware version is to exercise the
scenarios you describe.
^ permalink raw reply
* [PATCH v4 2/6] clk: renesas: rcar-gen3: Add Z2 clock divider support
From: Geert Uytterhoeven @ 2018-01-08 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180108080210.2c4rrijezfsad55k@verge.net.au>
Hi Simon,
On Mon, Jan 8, 2018 at 9:02 AM, Simon Horman <horms@verge.net.au> wrote:
> On Fri, Jan 05, 2018 at 03:35:13PM +0100, Geert Uytterhoeven wrote:
>> On Fri, Jan 5, 2018 at 3:04 PM, Simon Horman <horms@verge.net.au> wrote:
>> > On Wed, Jan 03, 2018 at 01:47:08PM +0100, Geert Uytterhoeven wrote:
>> >> On Wed, Jan 3, 2018 at 1:18 PM, Simon Horman <horms+renesas@verge.net.au> wrote:
>> >> > From: Takeshi Kihara <takeshi.kihara.df@renesas.com>
>> >> >
>> >> > This patch adds Z2 clock divider support for R-Car Gen3 SoC.
>> >> >
>> >> > Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
>> >> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>>
>> >> As the CPG/MSSR driver now has suspend/resume support, do we need
>> >> a notifier to restore the Z or Z2 registers? Or is that handled automatically
>> >> by cpufreq during system resume, for both the primary and the secondary
>> >> CPU cores?
>> >
>> > I am a bit unsure.
>> >
>> > When using the A57 cores, which is the default case, the Z clk is queried
>> > by CPUFreq on resume. It appears that on my system its already set to the
>> > correct value but I assume if it was not then it would be reset. However,
>> > this does not cover Z2 clk. So perhaps to be safe we need to register
>> > notifiers and make sure they they play nicely with CPUFreq?
>>
>> Of course the CPU is special: unlike many other devices, it must be running
>> when the kernel is reentered upon system resume.
>> It may be running using a different frequency setting, though.
>> However, following "opp-suspend", the system will always suspend with the
>> Z clock running at 1.5GHz, which is the default?
>> So Z is probably OK.
>>
>> It's more interesting to check what happens when the little cores are
>> enabled as well (unfortunately that requires different firmware).
>> 1. Does cpufreq handle them correctly when they are onlined again during
>> system resume?
>> 2. What happens if you offline all big cores, and enter system suspend
>> running with little cores only?
>> Perhaps that's prevented by the "opp-suspend" property as well?
>
> Thanks for clarifying the problem.
>
> I should be able to install updated firmware on:
> i* r8a7796 (M3-W) ES1.0 / Salvator-X; and
> * r8a7795 (H3) ES2.0 / Salvator-XS.
> * But not easily r8a7795 (H3) / Salvator-X
>
> Do you know what the minimal / desired firmware version is to exercise the
> scenarios you describe.
There are binaries available for "v2.7.0 8core". Unfortunately I
believe it supports
your "not easily r8a7795 (H3) / Salvator-X" only...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 3/5] ARM: dts: imx28-tx28: Pass unit address and reg to IOMUX node
From: Lothar Waßmann @ 2018-01-08 8:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514383478-32544-3-git-send-email-festevam@gmail.com>
Hi,
On Wed, 27 Dec 2017 12:04:36 -0200 Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> Pass unit address and reg to IOMUX node to fix the following build
> warning with W=1:
>
> arch/arm/boot/dts/imx28-tx28.dtb: Warning (simple_bus_reg): Node /apb at 80000000/apbh at 80000000/pinctrl at 80018000/tx28-edt-ft5x06-pins missing or empty reg/ranges property
> arch/arm/boot/dts/imx28-tx28.dtb: Warning (simple_bus_reg): Node /apb at 80000000/apbh at 80000000/pinctrl at 80018000/tx28-flexcan-xcvr-pins missing or empty reg/ranges property
> arch/arm/boot/dts/imx28-tx28.dtb: Warning (simple_bus_reg): Node /apb at 80000000/apbh at 80000000/pinctrl at 80018000/tx28-lcdif-23bit missing or empty reg/ranges property
> arch/arm/boot/dts/imx28-tx28.dtb: Warning (simple_bus_reg): Node /apb at 80000000/apbh at 80000000/pinctrl at 80018000/tx28-lcdif-ctrl missing or empty reg/ranges property
> arch/arm/boot/dts/imx28-tx28.dtb: Warning (simple_bus_reg): Node /apb at 80000000/apbh at 80000000/pinctrl at 80018000/tx28-mac0-gpio-pins missing or empty reg/ranges property
> arch/arm/boot/dts/imx28-tx28.dtb: Warning (simple_bus_reg): Node /apb at 80000000/apbh at 80000000/pinctrl at 80018000/tx28-pca9554-pins missing or empty reg/ranges property
> arch/arm/boot/dts/imx28-tx28.dtb: Warning (simple_bus_reg): Node /apb at 80000000/apbh at 80000000/pinctrl at 80018000/spi-gpiogrp missing or empty reg/ranges property
> arch/arm/boot/dts/imx28-tx28.dtb: Warning (simple_bus_reg): Node /apb at 80000000/apbh at 80000000/pinctrl at 80018000/tx28-tsc2007-pins missing or empty reg/ranges property
> arch/arm/boot/dts/imx28-tx28.dtb: Warning (simple_bus_reg): Node /apb at 80000000/apbh at 80000000/pinctrl at 80018000/tx28-usbphy0-pins missing or empty reg/ranges property
> arch/arm/boot/dts/imx28-tx28.dtb: Warning (simple_bus_reg): Node /apb at 80000000/apbh at 80000000/pinctrl at 80018000/tx28-usbphy1-pins missing or empty reg/ranges property
>
> Cc: Lothar Wa?mann <LW@KARO-electronics.de>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> arch/arm/boot/dts/imx28-tx28.dts | 30 ++++++++++++++++++++----------
> 1 file changed, 20 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx28-tx28.dts b/arch/arm/boot/dts/imx28-tx28.dts
> index 152621e..8a4f5bc 100644
> --- a/arch/arm/boot/dts/imx28-tx28.dts
> +++ b/arch/arm/boot/dts/imx28-tx28.dts
> @@ -531,7 +531,8 @@
> fsl,pull-up = <MXS_PULL_DISABLE>;
> };
>
> - tx28_edt_ft5x06_pins: tx28-edt-ft5x06-pins {
> + tx28_edt_ft5x06_pins: tx28-edt-ft5x06-pins at 0 {
> + reg = <0>;
> fsl,pinmux-ids = <
> MX28_PAD_SSP0_DATA6__GPIO_2_6 /* RESET */
> MX28_PAD_SSP0_DATA5__GPIO_2_5 /* IRQ */
> @@ -542,7 +543,8 @@
> fsl,pull-up = <MXS_PULL_DISABLE>;
> };
>
> - tx28_flexcan_xcvr_pins: tx28-flexcan-xcvr-pins {
> + tx28_flexcan_xcvr_pins: tx28-flexcan-xcvr-pins at 0 {
> + reg = <0>;
> fsl,pinmux-ids = <
> MX28_PAD_LCD_D00__GPIO_1_0
> >;
> @@ -551,7 +553,8 @@
> fsl,pull-up = <MXS_PULL_DISABLE>;
> };
>
> - tx28_lcdif_23bit_pins: tx28-lcdif-23bit {
> + tx28_lcdif_23bit_pins: tx28-lcdif-23bit at 0 {
> + reg = <0>;
> fsl,pinmux-ids = <
> /* LCD_D00 may be used as Flexcan Transceiver Enable on STK5-V5 */
> MX28_PAD_LCD_D01__LCD_D1
> @@ -583,7 +586,8 @@
> fsl,pull-up = <MXS_PULL_DISABLE>;
> };
>
> - tx28_lcdif_ctrl_pins: tx28-lcdif-ctrl {
> + tx28_lcdif_ctrl_pins: tx28-lcdif-ctrl at 0 {
> + reg = <0>;
> fsl,pinmux-ids = <
> MX28_PAD_LCD_ENABLE__GPIO_1_31 /* Enable */
> MX28_PAD_LCD_RESET__GPIO_3_30 /* Reset */
> @@ -593,7 +597,8 @@
> fsl,pull-up = <MXS_PULL_DISABLE>;
> };
>
> - tx28_mac0_pins_gpio: tx28-mac0-gpio-pins {
> + tx28_mac0_pins_gpio: tx28-mac0-gpio-pins at 0 {
> + reg = <0>;
> fsl,pinmux-ids = <
> MX28_PAD_ENET0_MDC__GPIO_4_0
> MX28_PAD_ENET0_MDIO__GPIO_4_1
> @@ -610,7 +615,8 @@
> fsl,pull-up = <MXS_PULL_DISABLE>;
> };
>
> - tx28_pca9554_pins: tx28-pca9554-pins {
> + tx28_pca9554_pins: tx28-pca9554-pins at 0 {
> + reg = <0>;
> fsl,pinmux-ids = <
> MX28_PAD_PWM3__GPIO_3_28
> >;
> @@ -619,7 +625,8 @@
> fsl,pull-up = <MXS_PULL_DISABLE>;
> };
>
> - tx28_spi_gpio_pins: spi-gpiogrp {
> + tx28_spi_gpio_pins: spi-gpiogrp at 0 {
> + reg = <0>;
> fsl,pinmux-ids = <
> MX28_PAD_AUART2_RX__GPIO_3_8
> MX28_PAD_AUART2_TX__GPIO_3_9
> @@ -633,7 +640,8 @@
> fsl,pull-up = <MXS_PULL_DISABLE>;
> };
>
> - tx28_tsc2007_pins: tx28-tsc2007-pins {
> + tx28_tsc2007_pins: tx28-tsc2007-pins at 0 {
> + reg = <0>;
> fsl,pinmux-ids = <
> MX28_PAD_SAIF0_MCLK__GPIO_3_20 /* TSC2007 IRQ */
> >;
> @@ -643,7 +651,8 @@
> };
>
>
> - tx28_usbphy0_pins: tx28-usbphy0-pins {
> + tx28_usbphy0_pins: tx28-usbphy0-pins at 0 {
> + reg = <0>;
> fsl,pinmux-ids = <
> MX28_PAD_GPMI_CE2N__GPIO_0_18 /* USBOTG_VBUSEN */
> MX28_PAD_GPMI_CE3N__GPIO_0_19 /* USBOTH_OC */
> @@ -653,7 +662,8 @@
> fsl,pull-up = <MXS_PULL_DISABLE>;
> };
>
> - tx28_usbphy1_pins: tx28-usbphy1-pins {
> + tx28_usbphy1_pins: tx28-usbphy1-pins at 0 {
> + reg = <0>;
> fsl,pinmux-ids = <
> MX28_PAD_SPDIF__GPIO_3_27 /* USBH_VBUSEN */
> MX28_PAD_JTAG_RTCK__GPIO_4_20 /* USBH_OC */
Acked-By: Lothar Wa?mann <LW@KARO-electronics.de>
Lothar Wa?mann
^ permalink raw reply
* [PATCH] mtd/nand/atmel: Delete an error message for a failed memory allocation in two functions
From: Boris Brezillon @ 2018-01-08 8:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <09e98604-00ec-64be-665a-a101b31028b1@Microchip.com>
[private message]
Hi Wenyou,
On Mon, 8 Jan 2018 08:58:21 +0800
"Yang, Wenyou" <Wenyou.Yang@Microchip.com> wrote:
> On 2018/1/6 4:55, SF Markus Elfring wrote:
> > From: Markus Elfring <elfring@users.sourceforge.net>
> > Date: Fri, 5 Jan 2018 21:45:04 +0100
> >
> > Omit an extra message for a memory allocation failure in these functions.
> >
> > This issue was detected by using the Coccinelle software.
> >
> > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> > ---
>
> Acked-by: Wenyou Yang <wenyou.yang@microchip.com>
Please don't encourage Markus to send more patches. The MTD maintainers
(like other maintainers) have decided to ignore his contributions.
If you want to know why, just google his name and you should have a
pretty good idea.
Thanks,
Boris
> > drivers/mtd/nand/atmel/nand-controller.c | 8 ++------
> > 1 file changed, 2 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/mtd/nand/atmel/nand-controller.c b/drivers/mtd/nand/atmel/nand-controller.c
> > index 90a71a56bc23..a41b999229c9 100644
> > --- a/drivers/mtd/nand/atmel/nand-controller.c
> > +++ b/drivers/mtd/nand/atmel/nand-controller.c
> > @@ -1612,10 +1612,8 @@ static int atmel_nand_register(struct atmel_nand *nand)
> > mtd->name = devm_kasprintf(nc->dev, GFP_KERNEL,
> > "%s:nand.%d", dev_name(nc->dev),
> > nand->cs[0].id);
> > - if (!mtd->name) {
> > - dev_err(nc->dev, "Failed to allocate mtd->name\n");
> > + if (!mtd->name)
> > return -ENOMEM;
> > - }
> > }
> >
> > ret = nand_scan_tail(mtd);
> > @@ -1654,10 +1652,8 @@ static struct atmel_nand *atmel_nand_create(struct atmel_nand_controller *nc,
> > nand = devm_kzalloc(nc->dev,
> > sizeof(*nand) + (numcs * sizeof(*nand->cs)),
> > GFP_KERNEL);
> > - if (!nand) {
> > - dev_err(nc->dev, "Failed to allocate NAND object\n");
> > + if (!nand)
> > return ERR_PTR(-ENOMEM);
> > - }
> >
> > nand->numcs = numcs;
> >
>
> Best Regards,
> Wenyou Yang
^ permalink raw reply
* [PATCH v2 3/6] clocksource/drivers: atmel-pit: allow unselecting ATMEL_PIT
From: Boris Brezillon @ 2018-01-08 8:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b8c0c142-2a69-648b-1389-a4467a26211b@linaro.org>
On Mon, 8 Jan 2018 08:23:02 +0100
Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
> On 07/01/2018 19:44, Alexandre Belloni wrote:
> > On 07/01/2018 at 19:07:13 +0100, Daniel Lezcano wrote:
> >> On 05/01/2018 15:30, Alexandre Belloni wrote:
> >>> With the new TCB clocksource driver, atmel platforms are now able to boot
> >>> without the PIT driver. Allow unselecting it.
> >>>
> >>> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> >>> ---
> >>> drivers/clocksource/Kconfig | 9 ++++++++-
> >>> 1 file changed, 8 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> >>> index 5609572e0236..55ccfa0ba63b 100644
> >>> --- a/drivers/clocksource/Kconfig
> >>> +++ b/drivers/clocksource/Kconfig
> >>> @@ -381,7 +381,14 @@ config ARMV7M_SYSTICK
> >>>
> >>> config ATMEL_PIT
> >>> select TIMER_OF if OF
> >>> - def_bool SOC_AT91SAM9 || SOC_SAMA5
> >>> + bool "Atmel Periodic Interval Timer (PIT)"
> >>> + depends on SOC_AT91SAM9 || SOC_SAMA5
> >>> + default SOC_AT91SAM9 || SOC_SAMA5
> >>> + help
> >>> + Select this to get a clocksource based on the Atmel Periodic Interval
> >>> + Timer. It has a relatively low resolution and the TC Block clocksource
> >>> + should be preferred.
> >>> + It also provides a clock event device.
> >>
> >> Please conform to the format:
> >>
> >> config ATMEL_PIT
> >> bool "Atmel Periodic Interval Timer (PIT)" if COMPILE_TEST
> >> select ...
> >> help
> >> bla bla
> >>
> >> and select ATMEL_PIT from the platform's Kconfig.
> >>
> >
> > Well, the goal is actually to allow people to unselect it so we don't
> > want the platform to select it.
>
> Why do you need people to unselect it?
Because we have 2 possible clocksource for atmel platforms: the PIT or
the TCB, if the TCB is selected there's no point in compiling the PIT
driver.
>
> The goal of the Kconfig here is to be silent except in the case the
> COMPILE_TEST option is set for cross-compilation test coverage.
>
> We are migrating all these options to this format. Please make it silent.
>
>
^ permalink raw reply
* [PATCH] ARM: dts: sun[47]i: Fix display backend 1 output to TCON0 remote endpoint
From: Chen-Yu Tsai @ 2018-01-08 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180104132752.pcixtjugwfvlshpl@flea.lan>
On Thu, Jan 4, 2018 at 9:27 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Thu, Jan 04, 2018 at 12:31:55AM +0800, Chen-Yu Tsai wrote:
>> There is a copy-paste error in the display pipeline device tree graph.
>> The remote endpoint of the display backend 1's output to TCON0 points
>> to the wrong endpoint. This will result in the driver incorrectly
>> parsing the relationship of the components.
>>
>> Reported-by: Andrea Venturi <ennesimamail.av@gmail.com>
>> Fixes: 0df4cf33a594 ("ARM: dts: sun4i: Add device nodes for display
>> pipelines")
>> Fixes: 5b92b29bed45 ("ARM: dts: sun7i: Add device nodes for display
>> pipelines")
>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>
> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Applied (a few days ago).
This will be sent out in a pull request later.
ChenYu
^ permalink raw reply
* [PATCH] mtd/nand/atmel: Delete an error message for a failed memory allocation in two functions
From: Boris Brezillon @ 2018-01-08 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180108091831.64d54599@bbrezillon>
On Mon, 8 Jan 2018 09:18:31 +0100
Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
> [private message]
Oops, not so private :-).
> Hi Wenyou,
>
> On Mon, 8 Jan 2018 08:58:21 +0800
> "Yang, Wenyou" <Wenyou.Yang@Microchip.com> wrote:
>
> > On 2018/1/6 4:55, SF Markus Elfring wrote:
> > > From: Markus Elfring <elfring@users.sourceforge.net>
> > > Date: Fri, 5 Jan 2018 21:45:04 +0100
> > >
> > > Omit an extra message for a memory allocation failure in these functions.
> > >
> > > This issue was detected by using the Coccinelle software.
> > >
> > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> > > ---
> >
> > Acked-by: Wenyou Yang <wenyou.yang@microchip.com>
>
> Please don't encourage Markus to send more patches. The MTD maintainers
> (like other maintainers) have decided to ignore his contributions.
>
> If you want to know why, just google his name and you should have a
> pretty good idea.
>
> Thanks,
>
> Boris
>
> > > drivers/mtd/nand/atmel/nand-controller.c | 8 ++------
> > > 1 file changed, 2 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/mtd/nand/atmel/nand-controller.c b/drivers/mtd/nand/atmel/nand-controller.c
> > > index 90a71a56bc23..a41b999229c9 100644
> > > --- a/drivers/mtd/nand/atmel/nand-controller.c
> > > +++ b/drivers/mtd/nand/atmel/nand-controller.c
> > > @@ -1612,10 +1612,8 @@ static int atmel_nand_register(struct atmel_nand *nand)
> > > mtd->name = devm_kasprintf(nc->dev, GFP_KERNEL,
> > > "%s:nand.%d", dev_name(nc->dev),
> > > nand->cs[0].id);
> > > - if (!mtd->name) {
> > > - dev_err(nc->dev, "Failed to allocate mtd->name\n");
> > > + if (!mtd->name)
> > > return -ENOMEM;
> > > - }
> > > }
> > >
> > > ret = nand_scan_tail(mtd);
> > > @@ -1654,10 +1652,8 @@ static struct atmel_nand *atmel_nand_create(struct atmel_nand_controller *nc,
> > > nand = devm_kzalloc(nc->dev,
> > > sizeof(*nand) + (numcs * sizeof(*nand->cs)),
> > > GFP_KERNEL);
> > > - if (!nand) {
> > > - dev_err(nc->dev, "Failed to allocate NAND object\n");
> > > + if (!nand)
> > > return ERR_PTR(-ENOMEM);
> > > - }
> > >
> > > nand->numcs = numcs;
> > >
> >
> > Best Regards,
> > Wenyou Yang
>
^ permalink raw reply
* [GIT PULL] Allwinner fixes for 4.15, round 2
From: Chen-Yu Tsai @ 2018-01-08 8:42 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Olof,
Here's another fix for 4.15. The error was introduced in 4.15-rc1,
so we'd really like to see it fixed for this release.
Thanks
ChenYu
The following changes since commit eac6a3639decefcc8eb0941dd3cebe79993670ad:
ARM: dts: sun8i: a711: Reinstate the PMIC compatible (2017-12-19 09:56:57 +0100)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-fixes-for-4.15-2
for you to fetch changes up to bdae44705c0d5b751fbd79bc4a169905b25ed335:
ARM: dts: sun[47]i: Fix display backend 1 output to TCON0 remote endpoint (2018-01-06 11:21:28 +0800)
----------------------------------------------------------------
Allwinner fixes for 4.15, round 2
One fix that fixes the display pipeline description in the device tree
for the A10 and A20 SoCs. This description was introduced in 4.15-rc1
with a mismatch in the graph remote endpoints, which would likely
result in the driver misinterpreting how the individual components fit
together.
----------------------------------------------------------------
Chen-Yu Tsai (1):
ARM: dts: sun[47]i: Fix display backend 1 output to TCON0 remote endpoint
arch/arm/boot/dts/sun4i-a10.dtsi | 2 +-
arch/arm/boot/dts/sun7i-a20.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180108/415a3776/attachment.sig>
^ permalink raw reply
* [PATCH v2 3/5] ARM64: dts: meson-axg: uart: Add the pinctrl info description
From: Jerome Brunet @ 2018-01-08 8:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b2571e30-d543-9288-68cf-1af86bb5f4bc@amlogic.com>
On Mon, 2018-01-08 at 14:07 +0800, Yixun Lan wrote:
> > (the following question just came up while I was looking at this
> > patch, but I guess it's more a question towards the pinctrl driver)
> > the name of the function looks a bit "weird" since below you are also
> > using "uart_ao_b"
>
> you right here, it's a question related to pinctrl subsystem.
> from my point of view, it's even weird from the hardware perspective:
> that, the UART function of AO domain route the pin of EE domain..
>
> > did you choose "uart_ao_b_gpioz" here because we cannot have the same
> > function name for the periphs and AO pinctrl or is there some other
> > reason?
> >
>
> Current there is a conflict in the code level which both two pinctrl
> tree (EE, AO) are using the same macro[1] to expand the definitions, so
> there would be conflict symbol if we name both as 'uart_ao_b'
>
> I think your idea of having an uniform function 'uart_ao_b' for both
> pinctrl subsystem is actually possible/positive..
>
> I will think about your suggestion and come up with a patch later,
> thanks a lot!
>
>
> [1] drivers/pinctrl/meson/pinctrl-meson.h
>
> #define FUNCTION(fn) \
> { \
> .name = #fn, \
> .groups = fn ## _groups, \
> .num_groups = ARRAY_SIZE(fn ## _groups), \
> }
The name feels weird because it should have been uart_ao_b_z ... We missed it in
the initial review. Except for correcting the function name, I don't think this
justify a change a pinctrl
^ permalink raw reply
* [PATCH v6 08/10] pwm: pwm-omap-dmtimer: Adapt driver to utilize dmtimer pdata ops
From: Claudiu Beznea @ 2018-01-08 8:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514887799-24605-9-git-send-email-j-keerthy@ti.com>
On 02.01.2018 12:09, Keerthy wrote:
> Adapt driver to utilize dmtimer pdata ops instead of pdata-quirks.
>
> Signed-off-by: Keerthy <j-keerthy@ti.com>
> Tested-by: Ladislav Michl <ladis@linux-mips.org>
> ---
> drivers/pwm/pwm-omap-dmtimer.c | 39 ++++++++++++++++++++++-----------------
> 1 file changed, 22 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/pwm/pwm-omap-dmtimer.c b/drivers/pwm/pwm-omap-dmtimer.c
> index 5ad42f3..3b27aff 100644
> --- a/drivers/pwm/pwm-omap-dmtimer.c
> +++ b/drivers/pwm/pwm-omap-dmtimer.c
> @@ -23,6 +23,7 @@
> #include <linux/mutex.h>
> #include <linux/of.h>
> #include <linux/of_platform.h>
> +#include <linux/platform_data/dmtimer-omap.h>
> #include <linux/platform_data/pwm_omap_dmtimer.h>
> #include <linux/platform_device.h>
> #include <linux/pm_runtime.h>
> @@ -37,7 +38,7 @@ struct pwm_omap_dmtimer_chip {
> struct pwm_chip chip;
> struct mutex mutex;
> pwm_omap_dmtimer *dm_timer;
> - struct pwm_omap_dmtimer_pdata *pdata;
> + struct omap_dm_timer_ops *pdata;
> struct platform_device *dm_timer_pdev;
> };
>
> @@ -242,19 +243,33 @@ static int pwm_omap_dmtimer_probe(struct platform_device *pdev)
> {
> struct device_node *np = pdev->dev.of_node;
> struct device_node *timer;
> + struct platform_device *timer_pdev;
> struct pwm_omap_dmtimer_chip *omap;
> - struct pwm_omap_dmtimer_pdata *pdata;
> + struct dmtimer_platform_data *timer_pdata;
> + struct omap_dm_timer_ops *pdata;
> pwm_omap_dmtimer *dm_timer;
> u32 v;
> int status;
>
> - pdata = dev_get_platdata(&pdev->dev);
> - if (!pdata) {
> - dev_err(&pdev->dev, "Missing dmtimer platform data\n");
> + timer = of_parse_phandle(np, "ti,timers", 0);
of_node_put() should be called when done with device_node pointer returned
by of_parse_phandle() (you may want to check the return ERROR cases below
regarding this statement):
> + if (!timer)
> + return -ENODEV;
> +
> + timer_pdev = of_find_device_by_node(timer);
> + if (!timer_pdev) {
> + dev_err(&pdev->dev, "Unable to find Timer pdev\n");
here
> + return -ENODEV;
> + }
> +
> + timer_pdata = dev_get_platdata(&timer_pdev->dev);
> + if (!timer_pdata) {
> + dev_err(&pdev->dev, "dmtimer pdata structure NULL\n");
here
> return -EINVAL;
> }
>
> - if (!pdata->request_by_node ||
> + pdata = timer_pdata->timer_ops;
> +
> + if (!pdata || !pdata->request_by_node ||
> !pdata->free ||
> !pdata->enable ||
> !pdata->disable ||
> @@ -270,10 +285,6 @@ static int pwm_omap_dmtimer_probe(struct platform_device *pdev)
> return -EINVAL;
> }
>
> - timer = of_parse_phandle(np, "ti,timers", 0);
> - if (!timer)
> - return -ENODEV;
> -
> if (!of_get_property(timer, "ti,timer-pwm", NULL)) {
here
> dev_err(&pdev->dev, "Missing ti,timer-pwm capability\n");
> return -ENODEV;
> @@ -291,13 +302,7 @@ static int pwm_omap_dmtimer_probe(struct platform_device *pdev)
>
> omap->pdata = pdata;
> omap->dm_timer = dm_timer;
> -
> - omap->dm_timer_pdev = of_find_device_by_node(timer);
> - if (!omap->dm_timer_pdev) {
> - dev_err(&pdev->dev, "Unable to find timer pdev\n");
> - omap->pdata->free(dm_timer);
> - return -EINVAL;
> - }
> + omap->dm_timer_pdev = timer_pdev;
>
> /*
> * Ensure that the timer is stopped before we allow PWM core to call
>
And all the other return instructions from probe function not listed by git diff
^ permalink raw reply
* [PATCH] imx6: fix pcie enumeration
From: Koen Vandeputte @ 2018-01-08 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105171828.GC24933@red-moon>
On 2018-01-05 18:18, Lorenzo Pieralisi wrote:
>>
>> Hi Lorenzo,
>>
>> This is exactly what I'm trying to explain:
>>
>> The host starts of with a (hardcoded today) subord of 1. [bits 16:23]
>>
>> Since commit a20c7f36bd3d, downstream devices cannot assign bus nr's
>> higher than the subord of the upstream device.
>> So in this case, scanning stops after the bridge as soon as bus 1 is
>> assigned .. :)
> There is one thing that I need to understand though. Before the commit
> above, how would enumeration works given that the subordinate bus number
> was set to 1 and that the kernel, AFAICS, does not overwrite it ?
>
> Are you able to send me a log (enumeration with debugging enabled and
> lspci) with the commit above reverted please ?
>
> Thanks,
> Lorenzo
>
Info below as requested:
[??? 0.116729] OF: PCI: host bridge /soc/pcie at 0x01000000 ranges:
[??? 0.116748] OF: PCI:?? No bus range found for /soc/pcie at 0x01000000,
using [bus 00-ff]
[??? 0.116777] OF: PCI:??? IO 0x01f80000..0x01f8ffff -> 0x00000000
[??? 0.116796] OF: PCI:?? MEM 0x01000000..0x01efffff -> 0x01000000
[??? 0.337917] imx6q-pcie 1ffc000.pcie: link up
[??? 0.337934] imx6q-pcie 1ffc000.pcie: Link: Gen2 disabled
[??? 0.337947] imx6q-pcie 1ffc000.pcie: link up
[??? 0.337958] imx6q-pcie 1ffc000.pcie: Link up, Gen1
[??? 0.338197] imx6q-pcie 1ffc000.pcie: PCI host bridge to bus 0000:00
[??? 0.338215] pci_bus 0000:00: root bus resource [bus 00-ff]
[??? 0.338230] pci_bus 0000:00: root bus resource [io 0x0000-0xffff]
[??? 0.338243] pci_bus 0000:00: root bus resource [mem
0x01000000-0x01efffff]
[??? 0.338255] pci_bus 0000:00: scanning bus
[??? 0.338286] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
[??? 0.338311] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
[??? 0.338328] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
[??? 0.338362] pci 0000:00:00.0: calling pci_fixup_ide_bases+0x0/0x4c
[??? 0.338416] pci 0000:00:00.0: supports D1
[??? 0.338425] pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold
[??? 0.338436] pci 0000:00:00.0: PME# disabled
[??? 0.338664] pci_bus 0000:00: fixups for bus
[??? 0.338676] PCI: bus0: Fast back to back transfers disabled
[??? 0.338692] pci 0000:00:00.0: scanning [bus 01-01] behind bridge, pass 0
[??? 0.338822] pci_bus 0000:01: scanning bus
[??? 0.338926] pci 0000:01:00.0: [10b5:8604] type 01 class 0x060400
[??? 0.338969] pci 0000:01:00.0: calling ventana_pciesw_early_fixup+0x0/0xa4
[??? 0.457984] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x0001ffff]
[??? 0.458167] pci 0000:01:00.0: calling pci_fixup_ide_bases+0x0/0x4c
[??? 0.458635] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
[??? 0.458660] pci 0000:01:00.0: PME# disabled
[??? 0.458970] pci_bus 0000:01: fixups for bus
[??? 0.459027] PCI: bus1: Fast back to back transfers disabled
[??? 0.459052] pci 0000:01:00.0: scanning [bus 00-00] behind bridge, pass 0
[??? 0.459060] pci 0000:01:00.0: bridge configuration invalid ([bus
00-00]), reconfiguring
[??? 0.459115] pci 0000:01:00.0: scanning [bus 00-00] behind bridge, pass 1
[??? 0.459443] pci_bus 0000:02: busn_res: can not insert [bus 02-ff]
under [bus 01] (conflicts with (null) [bus 01])
[??? 0.459461] pci_bus 0000:02: scanning bus
[??? 0.459573] pci 0000:02:01.0: [10b5:8604] type 01 class 0x060400
[??? 0.459617] pci 0000:02:01.0: calling ventana_pciesw_early_fixup+0x0/0xa4
[??? 0.459865] pci 0000:02:01.0: calling pci_fixup_ide_bases+0x0/0x4c
[??? 0.460298] pci 0000:02:01.0: PME# supported from D0 D3hot D3cold
[??? 0.460321] pci 0000:02:01.0: PME# disabled
[??? 0.460719] pci 0000:02:04.0: [10b5:8604] type 01 class 0x060400
[??? 0.460760] pci 0000:02:04.0: calling ventana_pciesw_early_fixup+0x0/0xa4
[??? 0.461009] pci 0000:02:04.0: calling pci_fixup_ide_bases+0x0/0x4c
[??? 0.461436] pci 0000:02:04.0: PME# supported from D0 D3hot D3cold
[??? 0.461460] pci 0000:02:04.0: PME# disabled
[??? 0.461841] pci 0000:02:05.0: [10b5:8604] type 01 class 0x060400
[??? 0.461883] pci 0000:02:05.0: calling ventana_pciesw_early_fixup+0x0/0xa4
[??? 0.462128] pci 0000:02:05.0: calling pci_fixup_ide_bases+0x0/0x4c
[??? 0.462553] pci 0000:02:05.0: PME# supported from D0 D3hot D3cold
[??? 0.462578] pci 0000:02:05.0: PME# disabled
[??? 0.463084] pci_bus 0000:02: fixups for bus
[??? 0.463231] PCI: bus2: Fast back to back transfers disabled
[??? 0.463255] pci 0000:02:01.0: scanning [bus 00-00] behind bridge, pass 0
[??? 0.463264] pci 0000:02:01.0: bridge configuration invalid ([bus
00-00]), reconfiguring
[??? 0.463319] pci 0000:02:04.0: scanning [bus 00-00] behind bridge, pass 0
[??? 0.463328] pci 0000:02:04.0: bridge configuration invalid ([bus
00-00]), reconfiguring
[??? 0.463378] pci 0000:02:05.0: scanning [bus 00-00] behind bridge, pass 0
[??? 0.463385] pci 0000:02:05.0: bridge configuration invalid ([bus
00-00]), reconfiguring
[??? 0.463435] pci 0000:02:01.0: scanning [bus 00-00] behind bridge, pass 1
[??? 0.463764] pci_bus 0000:03: scanning bus
[??? 0.463785] pci_bus 0000:03: fixups for bus
[??? 0.463791] PCI: bus3: Fast back to back transfers enabled
[??? 0.463803] pci_bus 0000:03: bus scan returning with max=03
[??? 0.463814] pci_bus 0000:03: busn_res: [bus 03-ff] end is updated to 03
[??? 0.463833] pci_bus 0000:03: [bus 03] partially hidden behind bridge
0000:01 [bus 01]
[??? 0.463862] pci 0000:02:04.0: scanning [bus 00-00] behind bridge, pass 1
[??? 0.464178] pci_bus 0000:04: scanning bus
[??? 0.464197] pci_bus 0000:04: fixups for bus
[??? 0.464202] PCI: bus4: Fast back to back transfers enabled
[??? 0.464214] pci_bus 0000:04: bus scan returning with max=04
[??? 0.464223] pci_bus 0000:04: busn_res: [bus 04-ff] end is updated to 04
[??? 0.464242] pci_bus 0000:04: [bus 04] partially hidden behind bridge
0000:01 [bus 01]
[??? 0.464271] pci 0000:02:05.0: scanning [bus 00-00] behind bridge, pass 1
[??? 0.464586] pci_bus 0000:05: scanning bus
[??? 0.464691] pci 0000:05:00.0: [168c:0033] type 00 class 0x028000
[??? 0.464825] pci 0000:05:00.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit]
[??? 0.465036] pci 0000:05:00.0: reg 0x30: [mem 0x00000000-0x0000ffff pref]
[??? 0.465095] pci 0000:05:00.0: calling pci_fixup_ide_bases+0x0/0x4c
[??? 0.465117] pci 0000:05:00.0: calling quirk_no_bus_reset+0x0/0x20
[??? 0.465489] pci 0000:05:00.0: supports D1
[??? 0.465498] pci 0000:05:00.0: PME# supported from D0 D1 D3hot
[??? 0.465524] pci 0000:05:00.0: PME# disabled
[??? 0.465859] pci_bus 0000:05: fixups for bus
[??? 0.465903] PCI: bus5: Fast back to back transfers disabled
[??? 0.465916] pci_bus 0000:05: bus scan returning with max=05
[??? 0.465926] pci_bus 0000:05: busn_res: [bus 05-ff] end is updated to 05
[??? 0.465946] pci_bus 0000:05: [bus 05] partially hidden behind bridge
0000:01 [bus 01]
[??? 0.465965] pci_bus 0000:02: bus scan returning with max=05
[??? 0.465974] pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 05
[??? 0.465984] pci_bus 0000:02: busn_res: can not insert [bus 02-05]
under [bus 01] (conflicts with (null) [bus 01])
[??? 0.466005] pci_bus 0000:02: [bus 02-05] partially hidden behind
bridge 0000:01 [bus 01]
[??? 0.466026] pci_bus 0000:01: bus scan returning with max=05
[??? 0.466033] pci 0000:00:00.0: bridge has subordinate 01 but max busn 05
[??? 0.466049] pci 0000:00:00.0: scanning [bus 01-01] behind bridge, pass 1
[??? 0.466059] pci_bus 0000:00: bus scan returning with max=01
[??? 0.466186] pci 0000:00:00.0: fixup irq: got 298
[??? 0.466196] pci 0000:00:00.0: assigning IRQ 298
[??? 0.466247] pci 0000:01:00.0: fixup irq: got 298
[??? 0.466254] pci 0000:01:00.0: assigning IRQ 298
[??? 0.466374] pci 0000:02:01.0: fixup irq: got 299
[??? 0.466382] pci 0000:02:01.0: assigning IRQ 299
[??? 0.466436] pci 0000:02:04.0: fixup irq: got 298
[??? 0.466442] pci 0000:02:04.0: assigning IRQ 298
[??? 0.466501] pci 0000:02:05.0: fixup irq: got 299
[??? 0.466509] pci 0000:02:05.0: assigning IRQ 299
[??? 0.466562] pci 0000:05:00.0: fixup irq: got 299
[??? 0.466569] pci 0000:05:00.0: assigning IRQ 299
[??? 0.466807] pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
[??? 0.466825] pci 0000:00:00.0: BAR 8: assigned [mem 0x01100000-0x012fffff]
[??? 0.466843] pci 0000:00:00.0: BAR 6: assigned [mem
0x01300000-0x0130ffff pref]
[??? 0.466862] pci 0000:01:00.0: BAR 8: assigned [mem 0x01100000-0x011fffff]
[??? 0.466875] pci 0000:01:00.0: BAR 0: assigned [mem 0x01200000-0x0121ffff]
[??? 0.466908] pci 0000:02:05.0: BAR 8: assigned [mem 0x01100000-0x011fffff]
[??? 0.466919] pci 0000:02:01.0: PCI bridge to [bus 03]
[??? 0.467001] pci 0000:02:04.0: PCI bridge to [bus 04]
[??? 0.467086] pci 0000:05:00.0: BAR 0: assigned [mem
0x01100000-0x0111ffff 64bit]
[??? 0.467160] pci 0000:05:00.0: BAR 6: assigned [mem
0x01120000-0x0112ffff pref]
[??? 0.467171] pci 0000:02:05.0: PCI bridge to [bus 05]
[??? 0.467206] pci 0000:02:05.0:?? bridge window [mem 0x01100000-0x011fffff]
[??? 0.467262] pci 0000:01:00.0: PCI bridge to [bus 02-05]
[??? 0.467297] pci 0000:01:00.0:?? bridge window [mem 0x01100000-0x011fffff]
[??? 0.467352] pci 0000:00:00.0: PCI bridge to [bus 01]
[??? 0.467364] pci 0000:00:00.0:?? bridge window [mem 0x01100000-0x012fffff]
[??? 0.467627] pcieport 0000:00:00.0: Signaling PME through PCIe PME
interrupt
[??? 0.467643] pci 0000:01:00.0: Signaling PME through PCIe PME interrupt
[??? 0.467653] pci 0000:02:01.0: Signaling PME through PCIe PME interrupt
[??? 0.467662] pci 0000:02:04.0: Signaling PME through PCIe PME interrupt
[??? 0.467671] pci 0000:02:05.0: Signaling PME through PCIe PME interrupt
[??? 0.467680] pci 0000:05:00.0: Signaling PME through PCIe PME interrupt
[??? 0.467694] pcie_pme 0000:00:00.0:pcie001: service driver pcie_pme loaded
[??? 0.468019] pcieport 0000:01:00.0: enabling device (0140 -> 0142)
[??? 0.468147] pcieport 0000:01:00.0: enabling bus mastering
[??? 0.468886] pcieport 0000:02:01.0: enabling bus mastering
[??? 0.469576] pcieport 0000:02:04.0: enabling bus mastering
[??? 0.470165] pcieport 0000:02:05.0: enabling device (0140 -> 0142)
[??? 0.470275] pcieport 0000:02:05.0: enabling bus mastering
[ Node 4 | node-4 ] lspci -v
00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00
[Normal decode])
??? Flags: bus master, fast devsel, latency 0, IRQ 298
??? Memory at 01000000 (32-bit, non-prefetchable) [size=1M]
??? Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
??? I/O behind bridge: None
??? Memory behind bridge: 01100000-012fffff [size=2M]
??? Prefetchable memory behind bridge: None
??? [virtual] Expansion ROM at 01300000 [disabled] [size=64K]
??? Capabilities: [40] Power Management version 3
??? Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
??? Capabilities: [70] Express Root Port (Slot-), MSI 00
??? Capabilities: [100] Advanced Error Reporting
??? Capabilities: [140] Virtual Channel
??? Kernel driver in use: pcieport
lspci: Unable to load libkmod resources: error -12
01:00.0 PCI bridge: PLX Technology, Inc. PEX 8604 4-lane, 4-Port PCI
Express Gen 2 (5.0 GT/s) Switch (rev ba) (prog-if 00 [Normal decode])
??? Flags: bus master, fast devsel, latency 0, IRQ 298
??? Memory at 01200000 (32-bit, non-prefetchable) [size=128K]
??? Bus: primary=01, secondary=02, subordinate=05, sec-latency=0
??? I/O behind bridge: None
??? Memory behind bridge: 01100000-011fffff [size=1M]
??? Prefetchable memory behind bridge: None
??? Capabilities: [40] Power Management version 3
??? Capabilities: [48] MSI: Enable- Count=1/4 Maskable+ 64bit+
??? Capabilities: [68] Express Upstream Port, MSI 00
??? Capabilities: [a4] Subsystem: PLX Technology, Inc. PEX 8604 4-lane,
4-Port PCI Express Gen 2 (5.0 GT/s) Switch
??? Capabilities: [100] Device Serial Number ba-86-01-10-b5-df-0e-00
??? Capabilities: [fb4] Advanced Error Reporting
??? Capabilities: [138] Power Budgeting <?>
??? Capabilities: [148] Virtual Channel
??? Capabilities: [448] Vendor Specific Information: ID=0000 Rev=0
Len=0cc <?>
??? Capabilities: [950] Vendor Specific Information: ID=0001 Rev=0
Len=010 <?>
??? Kernel driver in use: pcieport
02:01.0 PCI bridge: PLX Technology, Inc. PEX 8604 4-lane, 4-Port PCI
Express Gen 2 (5.0 GT/s) Switch (rev ba) (prog-if 00 [Normal decode])
??? Flags: bus master, fast devsel, latency 0, IRQ 299
??? Bus: primary=02, secondary=03, subordinate=03, sec-latency=0
??? I/O behind bridge: None
??? Memory behind bridge: None
??? Prefetchable memory behind bridge: None
??? Capabilities: [40] Power Management version 3
??? Capabilities: [48] MSI: Enable- Count=1/4 Maskable+ 64bit+
??? Capabilities: [68] Express Downstream Port (Slot+), MSI 00
??? Capabilities: [a4] Subsystem: PLX Technology, Inc. PEX 8604 4-lane,
4-Port PCI Express Gen 2 (5.0 GT/s) Switch
??? Capabilities: [100] Device Serial Number ba-86-01-10-b5-df-0e-00
??? Capabilities: [fb4] Advanced Error Reporting
??? Capabilities: [148] Virtual Channel
??? Capabilities: [520] Access Control Services
??? Capabilities: [950] Vendor Specific Information: ID=0001 Rev=0
Len=010 <?>
??? Kernel driver in use: pcieport
02:04.0 PCI bridge: PLX Technology, Inc. PEX 8604 4-lane, 4-Port PCI
Express Gen 2 (5.0 GT/s) Switch (rev ba) (prog-if 00 [Normal decode])
??? Flags: bus master, fast devsel, latency 0, IRQ 298
??? Bus: primary=02, secondary=04, subordinate=04, sec-latency=0
??? I/O behind bridge: None
??? Memory behind bridge: None
??? Prefetchable memory behind bridge: None
??? Capabilities: [40] Power Management version 3
??? Capabilities: [48] MSI: Enable- Count=1/4 Maskable+ 64bit+
??? Capabilities: [68] Express Downstream Port (Slot+), MSI 00
??? Capabilities: [a4] Subsystem: PLX Technology, Inc. PEX 8604 4-lane,
4-Port PCI Express Gen 2 (5.0 GT/s) Switch
??? Capabilities: [100] Device Serial Number ba-86-01-10-b5-df-0e-00
??? Capabilities: [fb4] Advanced Error Reporting
??? Capabilities: [148] Virtual Channel
??? Capabilities: [520] Access Control Services
??? Capabilities: [950] Vendor Specific Information: ID=0001 Rev=0
Len=010 <?>
??? Kernel driver in use: pcieport
02:05.0 PCI bridge: PLX Technology, Inc. PEX 8604 4-lane, 4-Port PCI
Express Gen 2 (5.0 GT/s) Switch (rev ba) (prog-if 00 [Normal decode])
??? Flags: bus master, fast devsel, latency 0, IRQ 299
??? Bus: primary=02, secondary=05, subordinate=05, sec-latency=0
??? I/O behind bridge: None
??? Memory behind bridge: 01100000-011fffff [size=1M]
??? Prefetchable memory behind bridge: None
??? Capabilities: [40] Power Management version 3
??? Capabilities: [48] MSI: Enable- Count=1/4 Maskable+ 64bit+
??? Capabilities: [68] Express Downstream Port (Slot+), MSI 00
??? Capabilities: [a4] Subsystem: PLX Technology, Inc. PEX 8604 4-lane,
4-Port PCI Express Gen 2 (5.0 GT/s) Switch
??? Capabilities: [100] Device Serial Number ba-86-01-10-b5-df-0e-00
??? Capabilities: [fb4] Advanced Error Reporting
??? Capabilities: [148] Virtual Channel
??? Capabilities: [520] Access Control Services
??? Capabilities: [950] Vendor Specific Information: ID=0001 Rev=0
Len=010 <?>
??? Kernel driver in use: pcieport
05:00.0 Network controller: Qualcomm Atheros AR958x 802.11abgn Wireless
Network Adapter (rev 01)
??? Subsystem: Device 19b6:d016
??? Flags: bus master, fast devsel, latency 0, IRQ 299
??? Memory at 01100000 (64-bit, non-prefetchable) [size=128K]
??? [virtual] Expansion ROM at 01120000 [disabled] [size=64K]
??? Capabilities: [40] Power Management version 3
??? Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+
??? Capabilities: [70] Express Endpoint, MSI 00
??? Capabilities: [100] Advanced Error Reporting
??? Capabilities: [140] Virtual Channel
??? Capabilities: [300] Device Serial Number 00-00-00-00-00-00-00-00
??? Kernel driver in use: ath9k
^ permalink raw reply
* [PATCH 0/2] pinctrl: meson: use one uniform 'function' name
From: Jerome Brunet @ 2018-01-08 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180108073328.205769-1-yixun.lan@amlogic.com>
On Mon, 2018-01-08 at 15:33 +0800, Yixun Lan wrote:
> These two patches are general improvement for meson pinctrl driver.
> It make the two pinctrl trees (ee/ao) to share one uniform 'function' name for
> one hardware block even its pin groups live inside two differet hardware domains,
> which for example EE vs AO domain here.
>
> This idea is motivated by Martin's question at [1]
>
> [1]
> http://lkml.kernel.org/r/CAFBinCCuQ-NK747+GHDkhZty_UMMgzCYOYFcNTrRDJgU8OM=Gw at mail.gmail.com
>
>
> Yixun Lan (2):
> pinctrl: meson: introduce a macro to have name/groups seperated
> pinctrl: meson-axg: correct the pin expansion of UART_AO_B
>
> drivers/pinctrl/meson/pinctrl-meson-axg.c | 4 ++--
> drivers/pinctrl/meson/pinctrl-meson.h | 8 +++++---
> 2 files changed, 7 insertions(+), 5 deletions(-)
Hi Yixun,
Honestly, I don't like the idea. I think it adds an unnecessary complexity.
I don't see the point of FUNCTION_EX(uart_ao_b, _z) when you could simply write
FUNCTION(uart_ao_b_z) ... especially when there is just a couple of function per
SoC available on different domains.
A pinctrl driver can already be challenging to understand at first, let's keep
it simple and avoid adding more macros.
Regards
Jerome
^ permalink raw reply
* [PATCH v2 3/6] clocksource/drivers: atmel-pit: allow unselecting ATMEL_PIT
From: Daniel Lezcano @ 2018-01-08 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180108092255.7e0f9f07@bbrezillon>
On 08/01/2018 09:22, Boris Brezillon wrote:
> On Mon, 8 Jan 2018 08:23:02 +0100
> Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
>
>> On 07/01/2018 19:44, Alexandre Belloni wrote:
>>> On 07/01/2018 at 19:07:13 +0100, Daniel Lezcano wrote:
>>>> On 05/01/2018 15:30, Alexandre Belloni wrote:
>>>>> With the new TCB clocksource driver, atmel platforms are now able to boot
>>>>> without the PIT driver. Allow unselecting it.
>>>>>
>>>>> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>>>>> ---
>>>>> drivers/clocksource/Kconfig | 9 ++++++++-
>>>>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>>>>> index 5609572e0236..55ccfa0ba63b 100644
>>>>> --- a/drivers/clocksource/Kconfig
>>>>> +++ b/drivers/clocksource/Kconfig
>>>>> @@ -381,7 +381,14 @@ config ARMV7M_SYSTICK
>>>>>
>>>>> config ATMEL_PIT
>>>>> select TIMER_OF if OF
>>>>> - def_bool SOC_AT91SAM9 || SOC_SAMA5
>>>>> + bool "Atmel Periodic Interval Timer (PIT)"
>>>>> + depends on SOC_AT91SAM9 || SOC_SAMA5
>>>>> + default SOC_AT91SAM9 || SOC_SAMA5
>>>>> + help
>>>>> + Select this to get a clocksource based on the Atmel Periodic Interval
>>>>> + Timer. It has a relatively low resolution and the TC Block clocksource
>>>>> + should be preferred.
>>>>> + It also provides a clock event device.
>>>>
>>>> Please conform to the format:
>>>>
>>>> config ATMEL_PIT
>>>> bool "Atmel Periodic Interval Timer (PIT)" if COMPILE_TEST
>>>> select ...
>>>> help
>>>> bla bla
>>>>
>>>> and select ATMEL_PIT from the platform's Kconfig.
>>>>
>>>
>>> Well, the goal is actually to allow people to unselect it so we don't
>>> want the platform to select it.
>>
>> Why do you need people to unselect it?
>
> Because we have 2 possible clocksource for atmel platforms: the PIT or
> the TCB, if the TCB is selected there's no point in compiling the PIT
> driver.
Why the platform's Kconfig can't do that ?
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH v2 1/5] ARM64: dts: meson: uart: fix address space range
From: Jerome Brunet @ 2018-01-08 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180106001044.108163-2-yixun.lan@amlogic.com>
On Sat, 2018-01-06 at 08:10 +0800, Yixun Lan wrote:
> The address space range is actually 0x18, fixed here.
>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 4 ++--
> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 10 +++++-----
> 2 files changed, 7 insertions(+), 7 deletions(-)
^ permalink raw reply
* [PATCH v2 2/5] ARM64: dts: meson-axg: uart: drop legacy compatible name from EE UART
From: Jerome Brunet @ 2018-01-08 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180106001044.108163-3-yixun.lan@amlogic.com>
On Sat, 2018-01-06 at 08:10 +0800, Yixun Lan wrote:
> When update the clock info for the UART controller in the EE domain,
> the driver explicitly require 'pclk' in order to work properly.
>
> With current logic of the code, the driver will go for the legacy clock probe
> routine[1] if it find current compatible string match to 'amlogic,meson-uart',
> which result in not requesting the 'pclk' clock, thus break the driver in the end.
>
> [1] drivers/tty/serial/meson_uart.c:685
>
> /* Use legacy way until all platforms switch to new bindings */
> if (of_device_is_compatible(pdev->dev.of_node, "amlogic,meson-uart"))
> ret = meson_uart_probe_clocks_legacy(pdev, port);
> else
> ret = meson_uart_probe_clocks(pdev, port);
I don't think you should add this code snip here. Anybody can look at the driver
code to see that
>
> Acked-by: Jerome Brunet <jbrunet@baylibre.com>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
^ permalink raw reply
* [PATCH 2/5] clk: lpc32xx: read-only divider can propagate rate change
From: Jerome Brunet @ 2018-01-08 9:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <54782a8f-9735-a574-d8e1-7ff3e9173229@mleia.com>
On Sat, 2018-01-06 at 16:04 +0200, Vladimir Zapolskiy wrote:
> > I added the fix to LPC32xx because it looks like the generic divider (a lot) and
>
> right, the relevant divider operations were copied, however the difference
> is important, unfortunately there is no simple option to get rid of regmap,
> because System Control Block registers are shared with a number of other
> device drivers.
I have the same issue ;)
>
> > appears to support CLK_DIVIDER_READ_ONLY. If it does not, could you please kill
> > the related code ?
>
> The driver supports CLK_DIVIDER_READ_ONLY clocks, and it should not be
> changed, but all such clocks don't have children with CLK_SET_RATE_PARENT
> property, which invalidates your fix for LPC32xx. Please let me know,
> if I missed something.
You did not miss anything. I understand your choice.
I just have different approach and usually prefer to avoid these particularity
which may catch you later on.
At least, the fact that propagation would stop with CLK_DIVIDER_READ_ONLY on
LPC32xx, even with CLK_SET_RATE_PARENT, is now known.
Adding a comment in the code to make this explicit would be nice though.
Regards
Jerome
^ permalink raw reply
* [PATCH] Revert "ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells"
From: Stefan Wahren @ 2018-01-08 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87incdjp9k.fsf@anholt.net>
Hi Eric,
Am 07.01.2018 um 23:08 schrieb Eric Anholt:
> Stefan Wahren <stefan.wahren@i2se.com> writes:
>
>> This reverts commit 014d6da6cb2525d7f48fb08c705cb130cc7b5f4a.
>>
>> The DT clean up could trigger an endless deferred probe of DWC2 USB driver
>> on the Raspberry Pi 2/3. So revert the change until we fixed the probing
>> issue.
> Why's that? I found that I needed to enable the generic no-op phy
> driver, but other than that it was fine.
in order to avoid this regression. Changing the configuration is not a
solution for the kernelci guys.
Btw
CONFIG_NOP_USB_XCEIV=y
is already enabled in arm64/defconfig and the issue still occured. Do
you mean a different option?
Stefan
^ permalink raw reply
* [linux-sunxi] [PATCH v2 3/6] ARM: sun4i: Convert to CCU
From: Chen-Yu Tsai @ 2018-01-08 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOi56cXTrGg+mx4aJsrMTHcwAV4KLCUZDy9bjpAq1hi1gngKAg@mail.gmail.com>
On Sat, Jan 6, 2018 at 12:10 AM, Kevin Hilman <khilman@baylibre.com> wrote:
> On Wed, Dec 13, 2017 at 11:46 AM, Kevin Hilman <khilman@baylibre.com> wrote:
>> On Wed, Dec 13, 2017 at 9:13 AM, Priit Laes <plaes@plaes.org> wrote:
>>> On Wed, Dec 13, 2017 at 05:09:33PM +0000, Priit Laes wrote:
>>>> On Tue, Dec 12, 2017 at 01:24:52PM -0800, Kevin Hilman wrote:
>>>> > On Tue, Dec 12, 2017 at 9:26 AM, Priit Laes <plaes@plaes.org> wrote:
>>>> > > On Mon, Dec 11, 2017 at 02:22:30PM -0800, Kevin Hilman wrote:
>>>> > >> On Sun, Mar 26, 2017 at 10:20 AM, Priit Laes <plaes@plaes.org> wrote:
>>>> > >> > Convert sun4i-a10.dtsi to new CCU driver.
>>>> > >> >
>>>> > >> > Signed-off-by: Priit Laes <plaes@plaes.org>
>>>> > >>
>>>> > >> I finally got around to bisecting a mainline boot failure on
>>>> > >> sun4i-a10-cubieboard that's been happening for quite a while. Based
>>>> > >> on on kernelci.org, it showed up sometime during the v4.15 merge
>>>> > >> window[1]. It bisected down to this commit (in mainline as commit
>>>> > >> 41193869f2bdb585ce09bfdd16d9482aadd560ad).
>>>> > >>
>>>> > >> When it fails, there is no output on the serial console, so I don't
>>>> > >> know exactly how it's failing, just that it no longer boots.
>>>> > >
>>>> > > We tried out latest 4.15 with various compilers and it works:
>>>> > > - gcc version 7.1.1 20170622 (Red Hat Cross 7.1.1-3) (GCC) - A10 Gemei G9 tablet
>>>> > > - gcc 7.2.0-debian - A10 Cubieboard
>>>> >
>>>> > And you can reproduce the bug with gcc5 or gcc6?
>>>>
>>>> Tried following commits on Gemei G9 (A10 tablet):
>>>> * 4.15.0-rc3-00037-gd39a01eff9af - latest master
>>>> * 4.14.0-rc1-00002-g41193869f2bd - the exact commit, causing the issue.
>>>>
>>>> With the same Linaro toolchain:
>>>> (gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05))
>>>
>>> And I also tried the same dtb and zImage from kernelci page [1] and it works with
>>> that too...
>>>
>>> https://storage.kernelci.org/mainline/master/v4.15-rc3/arm/sunxi_defconfig/
>>
>> Can you share a full boot-log (including all the u-boot output etc.)
>> so I can see exactly how the kernel is being loaded? Especially the
>> u-boot version?
>>
>> As $SUBJECT patch seems to be changing clocks around, perhaps this is
>> an issue where some u-boot dependency is uncovered, and older versions
>> of u-boot don't play well with this change.
>
> Ping.
>
> This is still failing in mainline, but passing int stable <= v4.14
Just did a test with clean builds of v4.15-rc7 with sunxi_defconfig
and U-boot 2018.01-rc3 with Cubieboard_defconfig. It successfully
boots to a prompt. My previous bootloader was U-boot 2017.05 with
some local modifications.
Here is the full boot log: https://wens.tw/cb-boot-log.txt
The boot script is:
setenv bootargs console=tty0 console=ttyS0,115200n8
root=/dev/mmcblk0p1 rootwait panic=10 earlycon=uart,mmio32,0x01c28000
consoleblank=0 drm.debug=0x1e
load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} boot/zImage
load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} boot/${fdtfile}
bootz ${kernel_addr_r} - ${fdt_addr_r}
Regards
ChenYu
^ permalink raw reply
* [linux-sunxi] Re: [PATCH 01/11] clk: sunxi-ng: Don't set k if width is 0 for nkmp plls
From: Chen-Yu Tsai @ 2018-01-08 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3625461.aU9oqMdpo3@jernej-laptop>
On Fri, Jan 5, 2018 at 3:28 AM, Jernej ?krabec <jernej.skrabec@siol.net> wrote:
> Hi,
>
> Dne ?etrtek, 04. januar 2018 ob 15:45:18 CET je Chen-Yu Tsai napisal(a):
>> On Sun, Dec 31, 2017 at 5:01 AM, Jernej Skrabec <jernej.skrabec@siol.net>
> wrote:
>> > For example, A83T have nmp plls which are modelled as nkmp plls. Since k
>> > is not specified, it has offset 0, shift 0 and lowest value 1. This
>> > means that LSB bit is always set to 1, which may change clock rate.
>> >
>> > Fix that by applying k factor only if k width is greater than 0.
>> >
>> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
>> > ---
>> >
>> > drivers/clk/sunxi-ng/ccu_nkmp.c | 21 +++++++++++++--------
>> > 1 file changed, 13 insertions(+), 8 deletions(-)
>> >
>> > diff --git a/drivers/clk/sunxi-ng/ccu_nkmp.c
>> > b/drivers/clk/sunxi-ng/ccu_nkmp.c index e58c95787f94..709f528af2b3 100644
>> > --- a/drivers/clk/sunxi-ng/ccu_nkmp.c
>> > +++ b/drivers/clk/sunxi-ng/ccu_nkmp.c
>> > @@ -81,7 +81,7 @@ static unsigned long ccu_nkmp_recalc_rate(struct clk_hw
>> > *hw,>
>> > unsigned long parent_rate)
>> >
>> > {
>> >
>> > struct ccu_nkmp *nkmp = hw_to_ccu_nkmp(hw);
>> >
>> > - unsigned long n, m, k, p;
>> > + unsigned long n, m, k = 1, p;
>> >
>> > u32 reg;
>> >
>> > reg = readl(nkmp->common.base + nkmp->common.reg);
>> >
>> > @@ -92,11 +92,13 @@ static unsigned long ccu_nkmp_recalc_rate(struct
>> > clk_hw *hw,>
>> > if (!n)
>> >
>> > n++;
>> >
>> > - k = reg >> nkmp->k.shift;
>> > - k &= (1 << nkmp->k.width) - 1;
>> > - k += nkmp->k.offset;
>> > - if (!k)
>> > - k++;
>> > + if (nkmp->k.width) {
>> > + k = reg >> nkmp->k.shift;
>> > + k &= (1 << nkmp->k.width) - 1;
>> > + k += nkmp->k.offset;
>> > + if (!k)
>> > + k++;
>> > + }
>>
>> The conditional shouldn't be necessary. With nkmp->k.width = 0,
>> you'd simply get k & 0, which is 0, which then gets bumped up to 1,
>> unless k.offset > 1, which would be a bug.
>>
>> > m = reg >> nkmp->m.shift;
>> > m &= (1 << nkmp->m.width) - 1;
>> >
>> > @@ -153,12 +155,15 @@ static int ccu_nkmp_set_rate(struct clk_hw *hw,
>> > unsigned long rate,>
>> > reg = readl(nkmp->common.base + nkmp->common.reg);
>> > reg &= ~GENMASK(nkmp->n.width + nkmp->n.shift - 1, nkmp->n.shift);
>> >
>> > - reg &= ~GENMASK(nkmp->k.width + nkmp->k.shift - 1, nkmp->k.shift);
>> > + if (nkmp->k.width)
>> > + reg &= ~GENMASK(nkmp->k.width + nkmp->k.shift - 1,
>> > + nkmp->k.shift);
>> >
>> > reg &= ~GENMASK(nkmp->m.width + nkmp->m.shift - 1, nkmp->m.shift);
>> > reg &= ~GENMASK(nkmp->p.width + nkmp->p.shift - 1, nkmp->p.shift);
>> >
>> > reg |= (_nkmp.n - nkmp->n.offset) << nkmp->n.shift;
>> >
>> > - reg |= (_nkmp.k - nkmp->k.offset) << nkmp->k.shift;
>> > + if (nkmp->k.width)
>> > + reg |= (_nkmp.k - nkmp->k.offset) << nkmp->k.shift;
>>
>> I think a better way would be
>>
>> reg |= ((_nkmp.k - nkmp->k.offset) << nkmp->k.shift) &
>> GENMASK(nkmp->k.width + nkmp->k.shift - 1, nkmp->k.shift);
>>
>> And do this for all the factors, not just k. This pattern is what
>> regmap_update_bits does, which seems much safer. I wonder what
>> GENMASK() with a negative value would do though...
>
> You're right, GENMASK(-1, 0) equals 0 (calculated by hand, not tested). This
> seems much more elegant solution.
>
> Semi-related question: All nmp PLLs have much wider N range than real nkmp
> PLLs. This causes integer overflow when using nkmp formula from datasheet.
> Usually, N is 1-256 for nmp PLLs, which means that for very high N factors, it
> overflows. This also causes issue that M factor is never higher than 1.
Sounds like we can't use u8 for storing the factors. At least the
intermediate values we use to calculate the rates.
>
> I was wondering, if patch would be acceptable which would change this formula:
>
> RATE = (24MHz * N * K) / (M * P)
>
> to this:
>
> RATE ((24MHz / M) * N * K) / P
>
> I checked all M factors and are all in 1-4 or 1-2 range, which means it
> wouldn't have any impact for real nkmp PLLs when parent is 24 MHz clock which
> is probably always.
>
> What do you think?
I think this is acceptable. M is normally the pre-divider, so this
actually fits how the hardware works, including possible rounding
errors.
ChenYu
> I discovered that when I tried to set A83T PLL_VIDEO to 346.5 MHz which is
> possible only when above formula is changed.
>
> Best regards,
> Jernej
>
>>
>> ChenYu
>>
>> > reg |= (_nkmp.m - nkmp->m.offset) << nkmp->m.shift;
>> > reg |= ilog2(_nkmp.p) << nkmp->p.shift;
>> >
>> > --
>> > 2.15.1
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [v2,03/11] arm64: Take into account ID_AA64PFR0_EL1.CSV3
From: Marc Zyngier @ 2018-01-08 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180108072253.GA178830@jc-sabre>
On 08/01/18 07:24, Jayachandran C wrote:
> On Fri, Jan 05, 2018 at 01:12:33PM +0000, Will Deacon wrote:
>> For non-KASLR kernels where the KPTI behaviour has not been overridden
>> on the command line we can use ID_AA64PFR0_EL1.CSV3 to determine whether
>> or not we should unmap the kernel whilst running at EL0.
>>
>> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>> Signed-off-by: Will Deacon <will.deacon@arm.com>
>> ---
>> arch/arm64/include/asm/sysreg.h | 1 +
>> arch/arm64/kernel/cpufeature.c | 8 +++++++-
>> 2 files changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
>> index 08cc88574659..ae519bbd3f9e 100644
>> --- a/arch/arm64/include/asm/sysreg.h
>> +++ b/arch/arm64/include/asm/sysreg.h
>> @@ -437,6 +437,7 @@
>> #define ID_AA64ISAR1_DPB_SHIFT 0
>>
>> /* id_aa64pfr0 */
>> +#define ID_AA64PFR0_CSV3_SHIFT 60
>> #define ID_AA64PFR0_SVE_SHIFT 32
>> #define ID_AA64PFR0_GIC_SHIFT 24
>> #define ID_AA64PFR0_ASIMD_SHIFT 20
>> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
>> index 9f0545dfe497..d723fc071f39 100644
>> --- a/arch/arm64/kernel/cpufeature.c
>> +++ b/arch/arm64/kernel/cpufeature.c
>> @@ -145,6 +145,7 @@ static const struct arm64_ftr_bits ftr_id_aa64isar1[] = {
>> };
>>
>> static const struct arm64_ftr_bits ftr_id_aa64pfr0[] = {
>> + ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR0_CSV3_SHIFT, 4, 0),
>> ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_SVE_SHIFT, 4, 0),
>> ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_GIC_SHIFT, 4, 0),
>> S_ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_ASIMD_SHIFT, 4, ID_AA64PFR0_ASIMD_NI),
>> @@ -851,6 +852,8 @@ static int __kpti_forced; /* 0: not forced, >0: forced on, <0: forced off */
>> static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
>> int __unused)
>> {
>> + u64 pfr0 = read_sanitised_ftr_reg(SYS_ID_AA64PFR0_EL1);
>> +
>> /* Forced on command line? */
>> if (__kpti_forced) {
>> pr_info_once("kernel page table isolation forced %s by command line option\n",
>> @@ -862,7 +865,9 @@ static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
>> if (IS_ENABLED(CONFIG_RANDOMIZE_BASE))
>> return true;
>>
>> - return false;
>> + /* Defer to CPU feature registers */
>> + return !cpuid_feature_extract_unsigned_field(pfr0,
>> + ID_AA64PFR0_CSV3_SHIFT);
>
> If I read this correctly, this enables KPTI on all processors without the CSV3
> set (which seems to be a future capability).
>
> Turning on KPTI has a small but significant overhead, so I think we should turn
> it off on processors that are not vulnerable to CVE-2017-5754. Can we add something
> like this:
>
> --->8
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 19ed09b..202b037 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -862,6 +862,13 @@ static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
> return __kpti_forced > 0;
> }
>
> + /* Don't force KPTI for CPUs that are not vulnerable */
> + switch (read_cpuid_id() & MIDR_CPU_MODEL_MASK) {
> + case MIDR_CAVIUM_THUNDERX2:
> + case MIDR_BRCM_VULCAN:
> + return false;
> + }
> +
> /* Useful for KASLR robustness */
> if (IS_ENABLED(CONFIG_RANDOMIZE_BASE))
> return true;
>
KPTI is also an improvement for KASLR. Why would you deprive a user of
the choice to further secure their system?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox