* [PATCH 03/11] arm64: Take into account ID_AA64PFR0_EL1.CSV3
From: Suzuki K Poulose @ 2018-01-05 10:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515078515-13723-4-git-send-email-will.deacon@arm.com>
On 04/01/18 15:08, 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.
>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm64/include/asm/sysreg.h | 1 +
> arch/arm64/kernel/cpufeature.c | 7 ++++++-
> 2 files changed, 7 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..e11c11bb5b02 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);
> }
>
The cpufeature bit changes look good to me. FWIW,
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
^ permalink raw reply
* [PATCH 00/13] replace print_symbol() with printk()-s
From: Sergey Senozhatsky @ 2018-01-05 10:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105102105.GB471@jagdpanzerIV>
On (01/05/18 19:21), Sergey Senozhatsky wrote:
> On (01/05/18 11:03), Petr Mladek wrote:
> [..]
> > Anyway, print_symbol() is an old weird API and it would be nice
> > to eventually get rid of it. I could take this patches into
> > printk.git.
>
> no objections from my side if the patch set will go through the printk tree.
> shall we wait for ACKs or can we move on? do you plan to land it in 4.16?
>
> > Would you mind if I change the commit messages to something like?:
> >
> > print_symbol() is an old weird API. It has been
> > obsoleted by printk() and %pS format specifier.
>
> I wouldn't. let's drop the "weird" part. other than that looks
> good to me.
oh, one more thing. one extra patch, which gets rid of
print_symbol()/__print_symbol().
8< ===
From: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Subject: [PATCH] kallsyms: remove print_symbol() function
No more print_symbol()/__print_symbol() users left, remove these
symbols.
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Suggested-by: Joe Perches <joe@perches.com>
---
Documentation/filesystems/sysfs.txt | 4 ++--
Documentation/translations/zh_CN/filesystems/sysfs.txt | 4 ++--
include/linux/kallsyms.h | 18 ------------------
kernel/kallsyms.c | 11 -----------
4 files changed, 4 insertions(+), 33 deletions(-)
diff --git a/Documentation/filesystems/sysfs.txt b/Documentation/filesystems/sysfs.txt
index 9a3658cc399e..a1426cabcef1 100644
--- a/Documentation/filesystems/sysfs.txt
+++ b/Documentation/filesystems/sysfs.txt
@@ -154,8 +154,8 @@ static ssize_t dev_attr_show(struct kobject *kobj, struct attribute *attr,
if (dev_attr->show)
ret = dev_attr->show(dev, dev_attr, buf);
if (ret >= (ssize_t)PAGE_SIZE) {
- print_symbol("dev_attr_show: %s returned bad count\n",
- (unsigned long)dev_attr->show);
+ printk("dev_attr_show: %pS returned bad count\n",
+ dev_attr->show);
}
return ret;
}
diff --git a/Documentation/translations/zh_CN/filesystems/sysfs.txt b/Documentation/translations/zh_CN/filesystems/sysfs.txt
index 7d3b05edb8ce..452271dda141 100644
--- a/Documentation/translations/zh_CN/filesystems/sysfs.txt
+++ b/Documentation/translations/zh_CN/filesystems/sysfs.txt
@@ -167,8 +167,8 @@ static ssize_t dev_attr_show(struct kobject *kobj, struct attribute *attr,
if (dev_attr->show)
ret = dev_attr->show(dev, dev_attr, buf);
if (ret >= (ssize_t)PAGE_SIZE) {
- print_symbol("dev_attr_show: %s returned bad count\n",
- (unsigned long)dev_attr->show);
+ printk("dev_attr_show: %pS returned bad count\n",
+ dev_attr->show);
}
return ret;
}
diff --git a/include/linux/kallsyms.h b/include/linux/kallsyms.h
index 23190e5c940b..657a83b943f0 100644
--- a/include/linux/kallsyms.h
+++ b/include/linux/kallsyms.h
@@ -94,9 +94,6 @@ extern int sprint_symbol(char *buffer, unsigned long address);
extern int sprint_symbol_no_offset(char *buffer, unsigned long address);
extern int sprint_backtrace(char *buffer, unsigned long address);
-/* Look up a kernel symbol and print it to the kernel messages. */
-extern void __print_symbol(const char *fmt, unsigned long address);
-
int lookup_symbol_name(unsigned long addr, char *symname);
int lookup_symbol_attrs(unsigned long addr, unsigned long *size, unsigned long *offset, char *modname, char *name);
@@ -166,23 +163,8 @@ static inline int kallsyms_show_value(void)
return false;
}
-/* Stupid that this does nothing, but I didn't create this mess. */
-#define __print_symbol(fmt, addr)
#endif /*CONFIG_KALLSYMS*/
-/* This macro allows us to keep printk typechecking */
-static __printf(1, 2)
-void __check_printsym_format(const char *fmt, ...)
-{
-}
-
-static inline void print_symbol(const char *fmt, unsigned long addr)
-{
- __check_printsym_format(fmt, "");
- __print_symbol(fmt, (unsigned long)
- __builtin_extract_return_addr((void *)addr));
-}
-
static inline void print_ip_sym(unsigned long ip)
{
printk("[<%px>] %pS\n", (void *) ip, (void *) ip);
diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index 24f456689f9c..a23e21ada81b 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -429,17 +429,6 @@ int sprint_backtrace(char *buffer, unsigned long address)
return __sprint_symbol(buffer, address, -1, 1);
}
-/* Look up a kernel symbol and print it to the kernel messages. */
-void __print_symbol(const char *fmt, unsigned long address)
-{
- char buffer[KSYM_SYMBOL_LEN];
-
- sprint_symbol(buffer, address);
-
- printk(fmt, buffer);
-}
-EXPORT_SYMBOL(__print_symbol);
-
/* To avoid using get_symbol_offset for every symbol, we carry prefix along. */
struct kallsym_iter {
loff_t pos;
--
2.15.1
^ permalink raw reply related
* [PATCH 6/6] ARM64: dts: meson-axg: enable the UART_A controller
From: Jerome Brunet @ 2018-01-05 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105095621.196472-7-yixun.lan@amlogic.com>
On Fri, 2018-01-05 at 17:56 +0800, Yixun Lan wrote:
> The UART_A is connect to a BT module in the S400 board.
The UART_A is connected to a BT module on the S400 board.
-- --
Apart from this:
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> index 2b79be356996..7e03b8da4856 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> @@ -14,9 +14,16 @@
>
> aliases {
> serial0 = &uart_AO;
> + serial1 = &uart_A;
> };
> };
>
> +&uart_A {
> + status = "okay";
> + pinctrl-0 = <&uart_a_pins>;
> + pinctrl-names = "default";
> +};
> +
> &uart_AO {
> status = "okay";
> pinctrl-0 = <&uart_ao_a_pins>;
^ permalink raw reply
* [PATCH 5/6] arm64: dts: meson-axg: complete the pinctrl info for UART_AO_A
From: Jerome Brunet @ 2018-01-05 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105095621.196472-6-yixun.lan@amlogic.com>
On Fri, 2018-01-05 at 17:56 +0800, Yixun Lan wrote:
> Explictly request the pinctrl info for the UART_AO_A controller,
> otherwise we my rely on bootloader for the initialization.
"we may" ? --^
>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
Please be consistent in the title
s/arm64/ARM64
Otherwise looks good once patch #4 is fixed
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> index 70eca1f8736a..2b79be356996 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> @@ -19,4 +19,6 @@
>
> &uart_AO {
> status = "okay";
> + pinctrl-0 = <&uart_ao_a_pins>;
> + pinctrl-names = "default";
> };
^ permalink raw reply
* [PATCH 4/6] ARM64: dts: meson-axg: uart: Add the pinctrl info description
From: Jerome Brunet @ 2018-01-05 10:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105095621.196472-5-yixun.lan@amlogic.com>
On Fri, 2018-01-05 at 17:56 +0800, Yixun Lan wrote:
> Describe the pinctrl info for the UART controller which
is
> found
> in the Meson-AXG SoCs.
Yixun,
Could you please review this patch again. Some "strings" used here will
obviously not work. I've picked up a few but I'm pretty sure there are other ...
Thanks
>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 96 ++++++++++++++++++++++++++++++
> 1 file changed, 96 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> index f6bf01cfff4b..78bb206e2897 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> @@ -303,6 +303,70 @@
> function = "pwm_d";
> };
> };
> +
> + uart_a_pins: uart_a {
> + mux {
> + groups = "uart_tx_a",
> + "uart_rx_a";
> + function = "uart_a";
> + };
> + };
> +
> + uart_a_cts_rts_pins: uart_a_cts_rts {
> + mux {
> + groups = "uart_ctx_a",
uart_ctx_a does not exist in pinctrl
> + "uart_rts_a";
> + function = "uart_a";
> + };
> + };
> +
> + uart_b_x_pins: uart_b_x {
> + mux {
> + groups = "uart_tx_b_x",
> + "uart_rx_b_x";
> + function = "uart_b";
> + };
> + };
> +
> + uart_b_x_cts_rts_pins: uart_b_x_cts_rts {
> + mux {
> + groups = "uart_cts_b_x",
> + "uart_rts_b_x";
> + function = "uart_b";
> + };
> + };
> +
> + uart_b_z_pins: uart_b_z {
> + mux {
> + groups = "uart_tx_b_z",
> + "uart_rx_b_z";
> + function = "uart_b";
> + };
> + };
> +
> + uart_b_z_cts_rts_pins: uart_b_z_cts_rts {
> + mux {
> + groups = "uart_cts_b_z",
> + "uart_rts_b_z";
> + function = "uart_b";
> + };
> + };
> +
> + uart_ao_b_z_pins: uart_ao_b_z {
> + mux {
> + groups = "uart_ao_tx_b_z",
> + "uart_ao_rx_b_z";
> + function = "uart_ao_b_groupz";
"uart_ao_b_groupz" function does not exist in pinctrl
> + };
> + };
> +
> + uart_ao_b_z_cts_rts_pins: uart_ao_b_z_cts_rts {
> + mux {
> + groups = "uart_ao_cts_b_z",
> + "uart_ao_rts_b_z";
> + function = "uart_ao_b_groupz";
> + };
> + };
> };
> };
>
> @@ -346,6 +410,38 @@
> #gpio-cells = <2>;
> gpio-ranges = <&pinctrl_aobus 0 0 15>;
> };
> +
> + uart_ao_a_pins: uart_ao_a {
> + mux {
> + groups = "uart_ao_tx_a",
> + "uart_ao_rx_a";
> + function = "uart_ao_a";
> + };
> + };
> +
> + uart_ao_a_cts_rts_pins: uart_ao_a_cts_rts {
> + mux {
> + groups = "uart_ao_cts_a",
> + "uart_ao_rts_a";
> + function = "uart_ao_a";
> + };
> + };
> +
> + uart_ao_b_pins: uart_ao_b {
> + mux {
> + groups = "uart_ao_tx_b",
> + "uart_ao_rx_b";
> + function = "uart_ao_b";
> + };
> + };
> +
> + uart_ao_b_cts_rts_pins: uart_ao_b_cts_rts {
> + mux {
> + groups = "uart_ao_cts_b",
> + "uart_ao_rts_b";
> + function = "uart_ao_b";
> + };
> + };
> };
>
> pwm_AO_ab: pwm at 7000 {
^ permalink raw reply
* [PATCH 04/11] arm64: cpufeature: Pass capability structure to ->enable callback
From: Suzuki K Poulose @ 2018-01-05 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515078515-13723-5-git-send-email-will.deacon@arm.com>
On 04/01/18 15:08, Will Deacon wrote:
> In order to invoke the CPU capability ->matches callback from the ->enable
> callback for applying local-CPU workarounds, we need a handle on the
> capability structure.
>
> This patch passes a pointer to the capability structure to the ->enable
> callback.
>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm64/kernel/cpufeature.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index e11c11bb5b02..6133c14b9b01 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -1151,7 +1151,7 @@ void __init enable_cpu_capabilities(const struct arm64_cpu_capabilities *caps)
> * uses an IPI, giving us a PSTATE that disappears when
> * we return.
> */
> - stop_machine(caps->enable, NULL, cpu_online_mask);
> + stop_machine(caps->enable, (void *)caps, cpu_online_mask);
> }
> }
> }
> @@ -1194,7 +1194,7 @@ verify_local_cpu_features(const struct arm64_cpu_capabilities *caps)
> cpu_die_early();
> }
> if (caps->enable)
> - caps->enable(NULL);
> + caps->enable((void *)caps);
> }
> }
>
>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
^ permalink raw reply
* [PATCH 3/6] ARM64: dts: meson-axg: uart: Add the clock info description
From: Jerome Brunet @ 2018-01-05 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105095621.196472-4-yixun.lan@amlogic.com>
On Fri, 2018-01-05 at 17:56 +0800, Yixun Lan wrote:
> Add the clock info description for the EE UART controller.
>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> index 9636a7c5f6ed..f6bf01cfff4b 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> @@ -146,6 +146,8 @@
> reg = <0x0 0x24000 0x0 0x18>;
> interrupts = <GIC_SPI 26 IRQ_TYPE_EDGE_RISING>;
> status = "disabled";
> + clocks = <&xtal>, <&clkc CLKID_UART0>, <&xtal>;
> + clock-names = "xtal", "pclk", "baud";
This should squashed with change #1, where you remove amlogic,meson-uartcompatible.
Otherwise uart is going to be broken between these patches.
> };
>
> uart_B: serial at 23000 {
> @@ -153,6 +155,8 @@
> reg = <0x0 0x23000 0x0 0x18>;
> interrupts = <GIC_SPI 75 IRQ_TYPE_EDGE_RISING>;
> status = "disabled";
> + clocks = <&xtal>, <&clkc CLKID_UART1>, <&xtal>;
> + clock-names = "xtal", "pclk", "baud";
> };
> };
>
^ permalink raw reply
* [PATCH 2/6] ARM64: dts: meson-axg: uart: fix address space range
From: Jerome Brunet @ 2018-01-05 10:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105095621.196472-3-yixun.lan@amlogic.com>
On Fri, 2018-01-05 at 17:56 +0800, Yixun Lan wrote:
> The address space range is actually 0x18, fixed here.
Isn't it the same for other meson SoC ? If they are compatible, it should.
Could you please re-submit this change addressing all the required platforms ?
>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> index 1c6002b3fe34..9636a7c5f6ed 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> @@ -143,14 +143,14 @@
>
> uart_A: serial at 24000 {
> compatible = "amlogic,meson-gx-uart";
> - reg = <0x0 0x24000 0x0 0x14>;
> + reg = <0x0 0x24000 0x0 0x18>;
> interrupts = <GIC_SPI 26 IRQ_TYPE_EDGE_RISING>;
> status = "disabled";
> };
>
> uart_B: serial at 23000 {
> compatible = "amlogic,meson-gx-uart";
> - reg = <0x0 0x23000 0x0 0x14>;
> + reg = <0x0 0x23000 0x0 0x18>;
> interrupts = <GIC_SPI 75 IRQ_TYPE_EDGE_RISING>;
> status = "disabled";
> };
^ permalink raw reply
* [PATCH 1/6] ARM64: dts: meson-axg: uart: drop legacy compatible name from EE UART
From: Jerome Brunet @ 2018-01-05 10:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105095621.196472-2-yixun.lan@amlogic.com>
On Fri, 2018-01-05 at 17:56 +0800, Yixun Lan wrote:
> For the UART controller in EE domain, they require 'pclk' to work.
they ? "the driver" maybe ?
> Current logic of the code will force to go for legacy clock probe
> if it found current compatible string match to 'amlogic,meson-ao-uart'.
did you mean "amlogic,meson-uart" instead ?
Apart from that
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> index e2b8a9c8bf0b..1c6002b3fe34 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> @@ -142,14 +142,14 @@
> };
>
> uart_A: serial at 24000 {
> - compatible = "amlogic,meson-gx-uart", "amlogic,meson-uart";
> + compatible = "amlogic,meson-gx-uart";
> reg = <0x0 0x24000 0x0 0x14>;
> interrupts = <GIC_SPI 26 IRQ_TYPE_EDGE_RISING>;
> status = "disabled";
> };
>
> uart_B: serial at 23000 {
> - compatible = "amlogic,meson-gx-uart", "amlogic,meson-uart";
> + compatible = "amlogic,meson-gx-uart";
> reg = <0x0 0x23000 0x0 0x14>;
> interrupts = <GIC_SPI 75 IRQ_TYPE_EDGE_RISING>;
> status = "disabled";
^ permalink raw reply
* [PATCH v4 6/7] ARM: davinci: convert to common clock framework
From: Sekhar Nori @ 2018-01-05 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a1593cb6-f471-022f-e41a-74146053fff8@lechnology.com>
On Friday 05 January 2018 08:29 AM, David Lechner wrote:
> On 01/04/2018 11:50 AM, David Lechner wrote:
>> On 1/4/18 6:39 AM, Sekhar Nori wrote:
>>> This is a pretty huge patch again and I hope it can be broken down.
>>> Ideally one per SoC converted and then the unused code removal.
>>>
>>
>> Will do.
>
> Well, I can do this, but I don't think it will compile or run. We can't
> have the common clock framework and the legacy davinci clocks enabled at
> the same time.
I see. Can you at least hive off the code removal into a separate patch
for next submission. I will then take a closer look at this.
Thanks,
Sekhar
^ permalink raw reply
* [GIT PULL] Qualcomm ARM64 Defconfig updates for 4.16
From: Arnd Bergmann @ 2018-01-05 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514789609-4133-1-git-send-email-andy.gross@linaro.org>
On Mon, Jan 1, 2018 at 7:53 AM, Andy Gross <andy.gross@linaro.org> wrote:
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git tags/qcom-arm64-defconfig-for-4.16
>
> for you to fetch changes up to d2fa1f37d21bf9729ae9ee79cb6bfc8de1f0a9a4:
>
> arm64: defconfig: remove CONFIG_USB_QCOM_8X16_PHY (2017-12-21 13:28:11 -0600)
>
> ----------------------------------------------------------------
> Qualcomm ARM64 Based defconfig Updates for v4.16
>
> * Remove legacy QCOM config options
>
> ----------------------------------------------------------------
> Alex Elder (3):
> arm64: defconfig: remove CONFIG_USB_EHCI_MSM
> arm64: defconfig: remove CONFIG_USB_MSM_OTG
> arm64: defconfig: remove CONFIG_USB_QCOM_8X16_PHY
Thanks for taking care of this, merged into next/soc.
I wonder what the long-term plan is for the other drivers/usb/phy drivers now
that one more has been removed.
I just checked what's left there and found:
a) many users of usb-nop-xceiv
b) a few drivers in use on actively maintained platforms (ti,am335x-usb-phy,
ti,twl6030-usb, ti,keystone-usbphy, fsl,imx23-usbphy,
nvidia,tegra20-usb-phy)
c) some more drivers used only by very old platforms (fsl-usb2-otg, gpio-vbus,
mv-otg, isp1301, isp1301_omap, omap_otg, tahvo-usb)
I assume nobody is touching the ones in category c) any more, but should
we encourage the ones using category a) and b) to get replaced with
drivers/phy/ drivers like the Qualcomm ones were?
Arnd
^ permalink raw reply
* [GIT PULL] Qualcomm ARM64 DT updates for 4.16
From: Arnd Bergmann @ 2018-01-05 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514789609-4133-2-git-send-email-andy.gross@linaro.org>
On Mon, Jan 1, 2018 at 7:53 AM, Andy Gross <andy.gross@linaro.org> wrote:
> Qualcomm ARM64 Updates for v4.16
>
> * Assorted cleanups for msm8916
> * Fix IPC references for smsm
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [PATCH v5 20/20] cpufreq: scmi: add support for fast frequency switching
From: Sudeep Holla @ 2018-01-05 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALW4P++xNXWUYoAEjV2=zfj-ps+JSD3kkkKRAeED08UF3Gabfw@mail.gmail.com>
On 04/01/18 22:10, Alexey Klimov wrote:
> Hi Sudeep,
>
> On Tue, Jan 2, 2018 at 2:42 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> The cpufreq core provides option for drivers to implement fast_switch
>> callback which is invoked for frequency switching from interrupt context.
>>
>> This patch adds support for fast_switch callback in SCMI cpufreq driver
>> by making use of polling based SCMI transfer. It also sets the flag
>> fast_switch_possible.
>>
>> Cc: linux-pm at vger.kernel.org
>> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>> ---
>> drivers/cpufreq/scmi-cpufreq.c | 15 +++++++++++++++
>> 1 file changed, 15 insertions(+)
>>
>> diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
>> index 0ee9335d0063..d0a82d7c6fd4 100644
>> --- a/drivers/cpufreq/scmi-cpufreq.c
>> +++ b/drivers/cpufreq/scmi-cpufreq.c
>> @@ -64,6 +64,19 @@ scmi_cpufreq_set_target(struct cpufreq_policy *policy, unsigned int index)
>> return perf_ops->freq_set(handle, priv->domain_id, freq, false);
>> }
>>
>> +static unsigned int scmi_cpufreq_fast_switch(struct cpufreq_policy *policy,
>> + unsigned int target_freq)
>> +{
>> + struct scmi_data *priv = policy->driver_data;
>> + struct scmi_perf_ops *perf_ops = handle->perf_ops;
>> +
>> + if (!perf_ops->freq_set(handle, priv->domain_id,
>> + target_freq * 1000, true))
>> + return target_freq;
>> +
>> + return 0;
>> +}
>
> Could you please explain how it's supposed to work for purpose of fast
> frequency switching?
>
> I am trying to track down ->freq_set.
> So it looks like this will fire an scmi perf level set command and
> will poll for this command to complete without asking for firmware to
> send command completion irq.
>
> scmi_perf_level_set() will call the following functions:
>
> scmi_one_xfer_init();
> scmi_do_xfer(handle, t);
> scmi_one_xfer_put(handle, t);
>
>
> The first function in the list calls scmi_one_xfer_get() which has
> this in the description (I guess because of down_timeout()):
> "This function can sleep depending on pending requests already in the system
> for the SCMI entity. Further, this also holds a spinlock to maintain
> integrity of internal data structures."
>
> So it can sleep.
>
Indeed, I can drop the whole semaphore story and expect the caller to
retry in case buffer is full which is very rare condition.
> As far as I see description of fast frequency switching it's required
> for fast_switch to not sleep:
> (file Documentation/cpu-freq/cpu-drivers.txt)
>
> "This function is used for frequency switching from scheduler's context.
> Not all drivers are expected to implement it, as sleeping from within
> this callback isn't allowed. This callback must be highly optimized to
> do switching as fast as possible."
>
>
> The other questions to this implementation of fast switching:
>
> 1) Fast switching callback must be highly optimized. Is it now? I see
> few spinlocks (in scmi mbox client and in the mailbox framework) there
> and polling functionality with udelay(5) inside that will timeout (if
> my calculations are correct) after 0.5 ms.
Do you have any alternate ideas to avoid that and still achieve fast
switching ?
> 2) Is it highly dependent on transport? If mailbox transport
> ->send_data() may sleep or hrtimer-based polling in mailbox framework
> will be used, then this fast switch won't work, right?
>
Yes.
> I am still looking into that: I can be wrong and just trying to
> understand if it is all okay.
>
Thanks for taking a look at this.
--
Regards,
Sudeep
^ permalink raw reply
* [GIT PULL] Qualcomm Device Tree updates for 4.16
From: Arnd Bergmann @ 2018-01-05 10:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514789609-4133-5-git-send-email-andy.gross@linaro.org>
On Mon, Jan 1, 2018 at 7:53 AM, Andy Gross <andy.gross@linaro.org> wrote:
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git tags/qcom-dts-for-4.16
>
> for you to fetch changes up to 6e2797bd80001e7f6ffe6fa95efaa27338a43aae:
>
> ARM: dts: msm8974-FP2: Add uSD slot nodes (2017-12-21 13:06:07 -0600)
>
> ----------------------------------------------------------------
> Qualcomm Device Tree Changes for v4.16
>
> * Add uSD slot nodes on msm8974-FP2 board
>
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] Qualcomm Defconfig updates for 4.16
From: Arnd Bergmann @ 2018-01-05 10:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514789609-4133-3-git-send-email-andy.gross@linaro.org>
On Mon, Jan 1, 2018 at 7:53 AM, Andy Gross <andy.gross@linaro.org> wrote:
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git tags/qcom-defconfig-for-4.16
>
> for you to fetch changes up to b756f49a339aeca053ab71dd089a1868c3932f81:
>
> ARM: qcom_defconfig: Enable Frambuffer console support (2017-12-21 13:28:31 -0600)
>
> ----------------------------------------------------------------
> Qualcomm ARM Based defconfig Updates for v4.16
>
> * Enable framebuffer, IOMMU, and DRM options
Pulled into next/soc, thanks!
Arnd
^ permalink raw reply
* [PATCH][v2] arm64: Allocate elfcorehdr & crashkernel mem before any reservation
From: James Morse @ 2018-01-05 11:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515080048-9154-1-git-send-email-poonam.aggrwal@nxp.com>
Hi Poonam,
On 04/01/18 15:34, Poonam Aggrwal wrote:
> Address for both crashkernel memory and elfcorehdr can be assigned
> statically. For crashkernel memory it is via crashkernel=SIZE at ADDRESS
> and elfcorehdr_addr via by kexec-utils in dump kernel device tree.
There are some crashkernel=SIZE at ADDRESS values that the user can supply that we
must reject. The obvious one is if it overlaps with the kernel text. (this patch
won't spot this). We need to read the hardware's reserved regions from the DT
before we allocate the crashkernel region, for example if the bootloader
reserved a chunk of memory for a frame-buffer, I shouldn't be able to use that
as crashkernel memory.
(you shouldn't need to specify an address, doing so prevents the kernel from
picking memory it can use)
> So memory should be reserved for both the above areas before any
> other memory reservations are done. Otherwise overlaps may happen and
> memory allocations will fail leading to failure in booting the
> dump capture kernel.
> Signed-off-by: Guanhua <guanhua.gao@nxp.com>
The first signed-off-by should be the patch author.
If you want to credit your colleagues you can use 'CC', or they can give
reviewed-by/acked-by to the patch.
> Signed-off-by: Poonam Aggrwal <poonam.aggrwal@nxp.com>
> Signed-off-by: Abhimanyu Saini <abhimanyu.saini@nxp.com>
And the last signed-of-by should be from the person posting to the mailing list.
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 00e7b90..24ce15d 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -453,6 +453,14 @@ void __init arm64_memblock_init(void)
> * Register the kernel text, kernel data, initrd, and initial
> * pagetables with memblock.
> */
Please don't insert this code between 'memblock_reserve(__pa_symbol(_text), _end
- _text);' and the comment that describes it.
> +
> + /* make these the first reservations to avoid chances of
> + * overlap
> + */
Nit: comment style
> + reserve_elfcorehdr();
(Moving reserve_elfcorehdr() makes sense, but..)
> + reserve_crashkernel();
reserve_crashkernel() does the allocation for the crashkernels reserved memory.
I expect this to always fail in the kdump kernel because there isn't enough
memory. (fdt_enforce_memory_region() at the top of this function calls
memblock_cap_memory_range()).
Moving this allocation above the early_init_fdt_scan_reserved_mem() below means
we may allocate memory for the crashdump that is in use by firmware/hardware and
described as reserved in the DT.
> memblock_reserve(__pa_symbol(_text), _end - _text);
> #ifdef CONFIG_BLK_DEV_INITRD
> if (initrd_start) {
> @@ -472,10 +480,6 @@ void __init arm64_memblock_init(void)
> else
> arm64_dma_phys_limit = PHYS_MASK + 1;
>
> - reserve_crashkernel();
> -
> - reserve_elfcorehdr();
> -
> high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
>
> dma_contiguous_reserve(arm64_dma_phys_limit);
>
Thanks,
James
^ permalink raw reply
* [PATCH v2 1/3] drm/sun4i: hdmi: Check for unset best_parent in sun4i_tmds_determine_rate
From: Jonathan Liu @ 2018-01-05 11:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105100314.3j5zm4ushv4tfky5@flea.lan>
Hi Maxime,
On 5 January 2018 at 21:03, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Fri, Jan 05, 2018 at 09:44:39AM +1100, Jonathan Liu wrote:
>> On 5 January 2018 at 06:56, Maxime Ripard
>> <maxime.ripard@free-electrons.com> wrote:
>> > On Tue, Dec 26, 2017 at 10:12:25PM +1100, Jonathan Liu wrote:
>> >> We should check if the best match has been set before comparing it.
>> >>
>> >> Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
>> >> Signed-off-by: Jonathan Liu <net147@gmail.com>
>> >> ---
>> >> drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 2 +-
>> >> 1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
>> >> index dc332ea56f6c..4d235e5ea31c 100644
>> >> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
>> >> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
>> >> @@ -102,7 +102,7 @@ static int sun4i_tmds_determine_rate(struct clk_hw *hw,
>> >> goto out;
>> >> }
>> >>
>> >> - if (abs(rate - rounded / i) <
>> >> + if (!best_parent || abs(rate - rounded / i) <
>> >
>> > Why is that causing any issue?
>> >
>> > If best_parent is set to 0...
>> >
>> >> abs(rate - best_parent / best_div)) {
>> >
>> > ... the value returned here is going to be rate, which is going to be
>> > higher than the first part of the comparison meaning ...
>> >
>> >> best_parent = rounded;
>> >
>> > ... that best_parent is going to be set there.
>>
>> Consider the following:
>> rate = 83500000
>> rounded = ideal * 2
>>
>> It is possible that if "rounded = clk_hw_round_rate(parent, ideal)"
>> gives high enough values that the condition "abs(rate - rounded / i) <
>> abs(rate - best_parent / best_div)" is never met.
>>
>> Then you can end up with:
>> req->rate = 0
>> req->best_parent_rate = 0
>> req->best_parent_hw = ...
>>
>> Also, the sun4i_tmds_calc_divider function has a similar check.
>
> Ok. That explanation must be part of your commit log, or at least
> which problem you're trying to address and in which situation it will
> trigger.
Ok. I have added amended the commit message with explanation for v3.
Regards,
Jonathan
^ permalink raw reply
* [GIT PULL] Qualcomm Driver updates for 4.16 - Redo
From: Arnd Bergmann @ 2018-01-05 11:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515097934-13713-1-git-send-email-andy.gross@linaro.org>
On Thu, Jan 4, 2018 at 9:32 PM, Andy Gross <andy.gross@linaro.org> wrote:
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git tags/qcom-drivers-for-4.16
>
> for you to fetch changes up to 3aa0582fdb824139630298880fbf78d4ac774d3c:
>
> of: platform: populate /firmware/ node from of_platform_default_populate_init() (2018-01-04 14:00:20 -0600)
>
> ----------------------------------------------------------------
> Qualcomm ARM Based Driver Updates for v4.16 - Redo
>
> * Fix error handling code in SMP2P probe
> * Update SMP2P to use ACPS as mailbox client
> * Add QMI support
> * Fixups for Qualcomm SCM
> * Fix licensing on rmtfs_mem
> * Correct SMSM child node lookup
> * Populate firmware nodes during platform init
Pulled into next/drivers, thanks!
Arnd
^ permalink raw reply
* [RESEND PATCH] Wind down ARM/TANGO port
From: Marc Gonzalez @ 2018-01-05 11:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <903c3f29-ecf3-3e13-7d5d-ae40171845da@sigmadesigns.com>
This is the end. Update port status. Change contact address. Add Mans.
Signed-off-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
---
Sigma is being sold. It is unlikely the STB unit will survive.
---
MAINTAINERS | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index a6e86e20761e..96225e1ae5e4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1956,9 +1956,10 @@ N: stm32
F: drivers/clocksource/armv7m_systick.c
ARM/TANGO ARCHITECTURE
-M: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
+M: Marc Gonzalez <marc.w.gonzalez@free.fr>
+M: Mans Rullgard <mans@mansr.com>
L: linux-arm-kernel at lists.infradead.org
-S: Maintained
+S: Odd Fixes
N: tango
ARM/TECHNOLOGIC SYSTEMS TS7250 MACHINE SUPPORT
--
2.15.0
^ permalink raw reply related
* [GIT PULL] Reset controller changes for v4.16
From: Arnd Bergmann @ 2018-01-05 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514884597.5080.3.camel@pengutronix.de>
On Tue, Jan 2, 2018 at 10:16 AM, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> Dear arm-soc maintainers,
>
> Happy New Year! Please consider merging this tag for v4.16. It adds
> Meson-AXG reset support and fixes a few issues with the reset include
> header: device_reset_optional is fixed to be really optional, unused
> headers are pruned, and useless warnings and deprecated API calls are
> removed.
Pulled into next/drivers.
I ended up using a variant of your text above as the changelog, rather than
the bullet list that more or less shows the same things as the shortlog.
Generally speaking, I'd prefer to have that kind of description in full
sentences in the git tag as well. Thanks,
Arnd
^ permalink raw reply
* [PATCH v3] arm64: v8.4: Support for new floating point multiplication instructions
From: Catalin Marinas @ 2018-01-05 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b3431080-4689-e66e-ae0f-d0e263cdd47d@huawei.com>
On Fri, Jan 05, 2018 at 04:22:24PM +0800, gengdongjiu wrote:
> On 2018/1/5 15:57, Greg KH wrote:
> > On Fri, Jan 05, 2018 at 09:22:54AM +0800, gengdongjiu wrote:
> >> Hi will/catalin
> >>
> >> On 2017/12/13 18:09, Suzuki K Poulose wrote:
> >>> On 13/12/17 10:13, Dongjiu Geng wrote:
> >>>> ARM v8.4 extensions add new neon instructions for performing a
> >>>> multiplication of each FP16 element of one vector with the corresponding
> >>>> FP16 element of a second vector, and to add or subtract this without an
> >>>> intermediate rounding to the corresponding FP32 element in a third vector.
> >>>>
> >>>> This patch detects this feature and let the userspace know about it via a
> >>>> HWCAP bit and MRS emulation.
> >>>>
> >>>> Cc: Dave Martin <Dave.Martin@arm.com>
> >>>> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> >>>> Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
> >>>> Reviewed-by: Dave Martin <Dave.Martin@arm.com>
> >>>
> >>> Looks good to me.
> >>>
> >>> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> >>
> >> sorry to disturb you. Reminder, hope this patch can be applied to Linux 4.15-rc7.
> >
> > New features should not be going into 4.15-rc, that should be a 4.16-rc1
> > thing, right?
>
> It is also great if it can be applied to 4.16-rc1. Thanks a lot!
I will queue it for 4.16-rc1.
--
Catalin
^ permalink raw reply
* [GIT PULL] Amlogic 64-bit DT changes for v4.16, round 2
From: Arnd Bergmann @ 2018-01-05 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7hzi5w2ezb.fsf@baylibre.com>
On Tue, Jan 2, 2018 at 9:16 PM, Kevin Hilman <khilman@baylibre.com> wrote:
> Arnd, Olof,
>
> Here's a second round of 64-bit DT changes for v4.16. This branch is on
> top of the previous round (already merged.)
Pulled into next/dt, with this text as the changelog:
> This adds a few more basics (clock, pinctrl, PWM, reset) for the new AXG
> family of Amlogic SoCs.
instead of the text you had in the tag:
> Amlogic 64-bit DT updates for v4.16, round 2
> - clock, pinctrl, PWM and reset nodes for new AXG SoC family
I think the full sentences are nicer to read here. Thanks,
Arnd
^ permalink raw reply
* [PATCH 00/13] replace print_symbol() with printk()-s
From: Petr Mladek @ 2018-01-05 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105102105.GB471@jagdpanzerIV>
On Fri 2018-01-05 19:21:05, Sergey Senozhatsky wrote:
> On (01/05/18 11:03), Petr Mladek wrote:
> [..]
> > Anyway, print_symbol() is an old weird API and it would be nice
> > to eventually get rid of it. I could take this patches into
> > printk.git.
>
> no objections from my side if the patch set will go through the printk tree.
> shall we wait for ACKs or can we move on? do you plan to land it in 4.16?
I am going to add this into for-4.16 branch.
It is a rather cosmetic and trivial change. Therefore I do not think
that we would need to wait for all the ACKs. Anyway, I am going to
proactively check for potential conflicts with linux-next.
> > Would you mind if I change the commit messages to something like?:
> >
> > print_symbol() is an old weird API. It has been
> > obsoleted by printk() and %pS format specifier.
>
> I wouldn't. let's drop the "weird" part. other than that looks
> good to me.
OK.
Best Regards,
Petr
^ permalink raw reply
* [PATCH v5 1/2] PCI: mediatek: Clear IRQ status after IRQ dispatched to avoid reentry
From: Honghui Zhang @ 2018-01-05 11:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <88c84a3e-17ea-08f2-e5fc-4799b41de267@arm.com>
On Thu, 2018-01-04 at 19:04 +0000, Marc Zyngier wrote:
> On 04/01/18 18:40, Lorenzo Pieralisi wrote:
> > [+Marc]
> >
> > On Wed, Dec 27, 2017 at 08:59:53AM +0800, honghui.zhang at mediatek.com wrote:
> >> From: Honghui Zhang <honghui.zhang@mediatek.com>
> >>
> >> There maybe a same IRQ reentry scenario after IRQ received in current
> >> IRQ handle flow:
> >> EP device PCIe host driver EP driver
> >> 1. issue an IRQ
> >> 2. received IRQ
> >> 3. clear IRQ status
> >> 4. dispatch IRQ
> >> 5. clear IRQ source
> >> The IRQ status was not successfully cleared at step 2 since the IRQ
> >> source was not cleared yet. So the PCIe host driver may receive the
> >> same IRQ after step 5. Then there's an IRQ reentry occurred.
> >> Even worse, if the reentry IRQ was not an IRQ that EP driver expected,
> >> it may not handle the IRQ. Then we may run into the infinite loop from
> >> step 2 to step 4.
> >> Clear the IRQ status after IRQ have been dispatched to avoid the IRQ
> >> reentry.
> >> This patch also fix another INTx IRQ issue by initialize the iterate
> >> before the loop. If an INTx IRQ re-occurred while we are dispatching
> >> the INTx IRQ, then iterate may start from PCI_NUM_INTX + INTX_SHIFT
> >> instead of INTX_SHIFT for the second time entering the
> >> for_each_set_bit_from() loop.
> >
> > This looks like two different issues that should be fixed with two
> > patches.
Ok, I split this into two patches and figure out a more reasonable
approach by using irq_chip solution.
> >
> >> Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
> >> Acked-by: Ryder Lee <ryder.lee@mediatek.com>
> >> ---
> >> drivers/pci/host/pcie-mediatek.c | 11 ++++++-----
> >> 1 file changed, 6 insertions(+), 5 deletions(-)
> >
> > For the sake of uniformity, I first want to understand why this
> > driver does not call:
> >
> > chained_irq_enter/exit()
> >
> > in the primary handler (mtk_pcie_intr_handler()).
> >
> > With the GIC as a primary interrupt controller we have not
> > even figured out how current code can actually work without
> > calling the chained_* API.
> >
> > I want to come up with a consistent handling of IRQ domains for
> > all host bridges and any discrepancy should be explained.
>
> That's because this driver is a huge hack, see below:
>
> >
> >> diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
> >> index db93efd..fc29a9a 100644
> >> --- a/drivers/pci/host/pcie-mediatek.c
> >> +++ b/drivers/pci/host/pcie-mediatek.c
> >> @@ -601,15 +601,16 @@ static irqreturn_t mtk_pcie_intr_handler(int irq, void *data)
>
> This function is not a chained irqchip, but an interrupt handler...
>
> >> struct mtk_pcie_port *port = (struct mtk_pcie_port *)data;
> >> unsigned long status;
> >> u32 virq;
> >> - u32 bit = INTX_SHIFT;
> >> + u32 bit;
> >>
> >> while ((status = readl(port->base + PCIE_INT_STATUS)) & INTX_MASK) {
> >> + bit = INTX_SHIFT;
> >> for_each_set_bit_from(bit, &status, PCI_NUM_INTX + INTX_SHIFT) {
> >> - /* Clear the INTx */
> >> - writel(1 << bit, port->base + PCIE_INT_STATUS);
> >> virq = irq_find_mapping(port->irq_domain,
> >> bit - INTX_SHIFT);
> >> generic_handle_irq(virq);
>
> and nonetheless, this calls into generic_handle_irq(). That's a complete
> violation of the interrupt layering. Maybe there is a good reason for
> it, but I'd like to know which one.
>
> Which means that all of the ack/mask has to be done outside of the
> irqchip framework too... Disgusting.
>
> >> + /* Clear the INTx */
> >> + writel(1 << bit, port->base + PCIE_INT_STATUS);
> >
> > I think that these masking/acking should actually be done through
> > the irq_chip hooks (see for instance pci-ftpci100.c) - that would
> > make this kind of bugs much easier to prevent (because the IRQ
> > layer does the sequencing for you).
>
> +1.
>
Thanks for your advice, I need to do some homework to have a better
understanding of the irq_chip approach.
> > Marc (CC'ed) has a more comprehensive view on this than me - I would
> > like to get to a point where all host bridges uses a consistent
> > approach for chained IRQ handling and I hope this bug fix can be
> > a starting point.
>
> +1 again. We definitely need to come up with some form of common
> approach for all these host drivers, and maybe turn that into a library...
>
Well, this is beyond my knowledge now, I guess I can figure out how to
using irq_chip for the first step, then I may following this "common
approach" after we have a solution for that?
thanks.
> Thanks,
>
> M.
^ permalink raw reply
* [PATCH 0/7] use SPDX-License-Identifier for Armada SoCs and boards
From: Gregory CLEMENT @ 2018-01-05 11:53 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
this series follow the recent trend for the license description to use
the SPDX-License-Identifier.
It also fix the wrongly stated X11 to MIT (see details in the commit
logs).
Gregory
Gregory CLEMENT (7):
arm64: dts: marvell: use SPDX-License-Identifier for Armada SoCs
arm64: dts: marvell: armada-3720-db: use SPDX-License-Identifier
arm64: dts: marvell: armada-3720-espressobin: use
SPDX-License-Identifier
arm64: dts: marvell: armada-7040-db: use SPDX-License-Identifier
arm64: dts: marvell: armada-8040-db: use SPDX-License-Identifier
arm64: dts: marvell: armada-8040-mcbin: use SPDX-License-Identifier
arm64: dts: marvell: armada-8080-db: use SPDX-License-Identifier
arch/arm64/boot/dts/marvell/armada-371x.dtsi | 38 +-------------------
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 39 +-------------------
.../boot/dts/marvell/armada-3720-espressobin.dts | 38 +-------------------
arch/arm64/boot/dts/marvell/armada-372x.dtsi | 38 +-------------------
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 38 +-------------------
arch/arm64/boot/dts/marvell/armada-7020.dtsi | 41 +---------------------
arch/arm64/boot/dts/marvell/armada-7040-db.dts | 41 +---------------------
arch/arm64/boot/dts/marvell/armada-7040.dtsi | 41 +---------------------
arch/arm64/boot/dts/marvell/armada-70x0.dtsi | 41 +---------------------
arch/arm64/boot/dts/marvell/armada-8020.dtsi | 41 +---------------------
arch/arm64/boot/dts/marvell/armada-8040-db.dts | 41 +---------------------
arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 41 +---------------------
arch/arm64/boot/dts/marvell/armada-8040.dtsi | 41 +---------------------
arch/arm64/boot/dts/marvell/armada-8080-db.dts | 41 +---------------------
arch/arm64/boot/dts/marvell/armada-8080.dtsi | 41 +---------------------
arch/arm64/boot/dts/marvell/armada-80x0.dtsi | 41 +---------------------
arch/arm64/boot/dts/marvell/armada-ap806-dual.dtsi | 41 +---------------------
arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi | 41 +---------------------
arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 41 +---------------------
.../dts/marvell/armada-ap810-ap0-octa-core.dtsi | 41 +---------------------
arch/arm64/boot/dts/marvell/armada-ap810-ap0.dtsi | 41 +---------------------
arch/arm64/boot/dts/marvell/armada-common.dtsi | 2 +-
arch/arm64/boot/dts/marvell/armada-cp110.dtsi | 6 ++--
23 files changed, 24 insertions(+), 831 deletions(-)
--
2.15.1
^ 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