* Re: [PATCH V2 0/3] ARM: imx: move cpu code to drivers/soc/imx
From: Shawn Guo @ 2020-05-20 0:56 UTC (permalink / raw)
To: peng.fan
Cc: linux-arm-kernel, abel.vesa, Anson.Huang, ard.biesheuvel,
festevam, s.hauer, linux-kernel, linux-imx, kernel, git,
leonard.crestez, info, allison
In-Reply-To: <1588151843-2133-1-git-send-email-peng.fan@nxp.com>
On Wed, Apr 29, 2020 at 05:17:20PM +0800, peng.fan@nxp.com wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> V2:
> Keep i.MX1/2/3/5 cpu type for completness
> Correct return value in patch 1/3
> use CONFIG_ARM to guard compile soc-imx.c in patch 3/3
>
> V1:
> https://patchwork.kernel.org/cover/11433689/
> RFC version :
> https://patchwork.kernel.org/cover/11336433/
>
> Nothing changed in v1, just rename to formal patches
>
> Shawn,
> The original concern has been eliminated in RFC discussion,
> so this patchset is ready to be in next.
> Thanks.
>
> Follow i.MX8, move the soc device register code to drivers/soc/imx
> to simplify arch/arm/mach-imx/cpu.c
>
> I planned to use similar logic as soc-imx8m.c to restructure soc-imx.c
> and merged the two files into one. But not sure, so still keep
> the logic in cpu.c.
>
> There is one change is the platform devices are not under
> /sys/devices/soc0 after patch 1/4. Actually ARM64 platform
> devices are not under /sys/devices/soc0, such as i.MX8/8M.
> So it should not hurt to let the platform devices under platform dir.
>
> Peng Fan (3):
> ARM: imx: use device_initcall for imx_soc_device_init
> ARM: imx: move cpu definitions into a header
> soc: imx: move cpu code to drivers/soc/imx
Applied all, thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: Implement functions for HAVE_FUNCTION_ARG_ACCESS_API
From: Andrew Jeffery @ 2020-05-20 0:44 UTC (permalink / raw)
To: Russell King; +Cc: oleg, linux-arm-kernel, linux-kernel
In-Reply-To: <20200519150204.GG1551@shell.armlinux.org.uk>
Hi Russell,
On Wed, 20 May 2020, at 00:32, Russell King - ARM Linux admin wrote:
> On Wed, May 20, 2020 at 12:01:32AM +0930, Andrew Jeffery wrote:
> > This allows extraction of kernel function arguments via kprobes on ARM.
> > Based on the arm64 implementation and adapted for the 32-bit AAPCS.
> >
> > Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> > ---
> > The description for HAVE_FUNCTION_ARG_ACCESS_API was pretty vague on what was
> > required. I've implemented enough to enable argument extraction for kprobes; is
> > there anything else needed to satisfy HAVE_FUNCTION_ARG_ACCESS_API?
>
> What about 64-bit arguments? How do they get handled?
>
> regs_get_kernel_argument() talks about 'n' being the argument number,
> and maps this directly to a register. If a function argument
> prototype is:
>
> (something *foo, long long bar, int baz)
>
> The foo is in r0, bar is in r2/r3 on EABI, and baz is on the stack.
>
> n=0 will return foo. n=1 will be undefined. n=2 will return part of
> bar, and n=3 will return the other half. Is this what is expected?
Certainly doesn't feel right, however the broken behaviour seems to be a
compromise accepted in the existing couple of implementations for arm64
and x86. The API prototype doesn't give us any type information, so we're
left to guess.
Here's the commentary from the others:
arch/x86/include/asm/ptrace.h:
```
/**
* regs_get_kernel_argument() - get Nth function argument in kernel
* @regs: pt_regs of that context
* @n: function argument number (start from 0)
*
* regs_get_argument() returns @n th argument of the function call.
* Note that this chooses most probably assignment, in some case
* it can be incorrect.
* This is expected to be called from kprobes or ftrace with regs
* where the top of stack is the return address.
*/
static inline unsigned long regs_get_kernel_argument(struct pt_regs *regs,
unsigned int n)
{
...
```
arch/arm64/include/asm/ptrace.h:
```
/**
* regs_get_kernel_argument() - get Nth function argument in kernel
* @regs: pt_regs of that context
* @n: function argument number (start from 0)
*
* regs_get_argument() returns @n th argument of the function call.
*
* Note that this chooses the most likely register mapping. In very rare
* cases this may not return correct data, for example, if one of the
* function parameters is 16 bytes or bigger. In such cases, we cannot
* get access the parameter correctly and the register assignment of
* subsequent parameters will be shifted.
*/
static inline unsigned long regs_get_kernel_argument(struct pt_regs *regs,
unsigned int n)
{
...
```
As for handling arguments on the stack, arm64 doesn't and I cribbed from
that:
```
static inline unsigned long regs_get_kernel_argument(struct pt_regs *regs,
unsigned int n)
{
#define NR_REG_ARGUMENTS 8
if (n < NR_REG_ARGUMENTS)
return pt_regs_read_reg(regs, n);
return 0;
}
```
Would you accept a v2 that adds stack argument handling but leaves the
¯\_(ツ)_/¯ ABI behaviour? Or will I need to fix the API?
Thanks for the quick response.
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: pass -msoft-float to gcc earlier
From: Nick Desaulniers @ 2020-05-20 0:38 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Szabolcs Nagy, Linus Walleij, Russell King, LKML, Masahiro Yamada,
Linux ARM
In-Reply-To: <CAKwvOdmH6bMJHzxSs2mVN=P5BBYjYrDs13-oq-Qq+S4ykHSYvA@mail.gmail.com>
sorry, hit tab/enter too soon...
On Tue, May 19, 2020 at 5:37 PM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> On Tue, May 19, 2020 at 3:09 PM Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > Szabolcs Nagy ran into a kernel build failure with a custom gcc
> > toochain that sets -mfpu=auto -mfloat-abi=hard:
> >
> > /tmp/ccmNdcdf.s:1898: Error: selected processor does not support `cpsid i' in ARM mode
> >
> > The problem is that $(call cc-option, -march=armv7-a) fails before the
> > kernel overrides the gcc options to also pass -msoft-float.
>
> The call to `$(call cc-option, -march=armv7-a) is th
The call to `$(call cc-option, -march=armv7-a) is the one that fails or...?
>
> >
> > Move the option to the beginning the Makefile, before we call
>
> beginning of the
>
> > cc-option for the first time.
> >
> > Reported-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
> > Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87302
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Moving this looks harmless enough, though it's not clear to me how the
> failure you're describing would occur. I don't see calls to as-instr
> in arch/arm/Makefile. Which object is being built before -msoft-float
> is being set?
... ^
>
> > ---
> > arch/arm/Makefile | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> > index 7d5cd0f85461..e428ea6eb0fa 100644
> > --- a/arch/arm/Makefile
> > +++ b/arch/arm/Makefile
> > @@ -16,6 +16,8 @@ LDFLAGS_vmlinux += --be8
> > KBUILD_LDFLAGS_MODULE += --be8
> > endif
> >
> > +KBUILD_CFLAGS += -msoft-float
> > +
> > ifeq ($(CONFIG_ARM_MODULE_PLTS),y)
> > KBUILD_LDS_MODULE += $(srctree)/arch/arm/kernel/module.lds
> > endif
> > @@ -135,7 +137,7 @@ AFLAGS_ISA :=$(CFLAGS_ISA)
> > endif
> >
> > # Need -Uarm for gcc < 3.x
> > -KBUILD_CFLAGS +=$(CFLAGS_ABI) $(CFLAGS_ISA) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -msoft-float -Uarm
> > +KBUILD_CFLAGS +=$(CFLAGS_ABI) $(CFLAGS_ISA) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -Uarm
> > KBUILD_AFLAGS +=$(CFLAGS_ABI) $(AFLAGS_ISA) $(arch-y) $(tune-y) -include asm/unified.h -msoft-float
> >
> > CHECKFLAGS += -D__arm__
> > --
> > 2.26.2
> >
--
Thanks,
~Nick Desaulniers
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: pass -msoft-float to gcc earlier
From: Nick Desaulniers @ 2020-05-20 0:37 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Szabolcs Nagy, Linus Walleij, Russell King, LKML, Masahiro Yamada,
Linux ARM
In-Reply-To: <20200519220923.1601303-1-arnd@arndb.de>
On Tue, May 19, 2020 at 3:09 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> Szabolcs Nagy ran into a kernel build failure with a custom gcc
> toochain that sets -mfpu=auto -mfloat-abi=hard:
>
> /tmp/ccmNdcdf.s:1898: Error: selected processor does not support `cpsid i' in ARM mode
>
> The problem is that $(call cc-option, -march=armv7-a) fails before the
> kernel overrides the gcc options to also pass -msoft-float.
The call to `$(call cc-option, -march=armv7-a)
>
> Move the option to the beginning the Makefile, before we call
beginning of the
> cc-option for the first time.
>
> Reported-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87302
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Moving this looks harmless enough, though it's not clear to me how the
failure you're describing would occur. I don't see calls to as-instr
in arch/arm/Makefile. Which object is being built before -msoft-float
is being set?
> ---
> arch/arm/Makefile | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index 7d5cd0f85461..e428ea6eb0fa 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -16,6 +16,8 @@ LDFLAGS_vmlinux += --be8
> KBUILD_LDFLAGS_MODULE += --be8
> endif
>
> +KBUILD_CFLAGS += -msoft-float
> +
> ifeq ($(CONFIG_ARM_MODULE_PLTS),y)
> KBUILD_LDS_MODULE += $(srctree)/arch/arm/kernel/module.lds
> endif
> @@ -135,7 +137,7 @@ AFLAGS_ISA :=$(CFLAGS_ISA)
> endif
>
> # Need -Uarm for gcc < 3.x
> -KBUILD_CFLAGS +=$(CFLAGS_ABI) $(CFLAGS_ISA) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -msoft-float -Uarm
> +KBUILD_CFLAGS +=$(CFLAGS_ABI) $(CFLAGS_ISA) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -Uarm
> KBUILD_AFLAGS +=$(CFLAGS_ABI) $(AFLAGS_ISA) $(arch-y) $(tune-y) -include asm/unified.h -msoft-float
>
> CHECKFLAGS += -D__arm__
> --
> 2.26.2
>
--
Thanks,
~Nick Desaulniers
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] dt-bindings: gpio: Convert mxs to json-schema
From: Anson Huang @ 2020-05-20 0:20 UTC (permalink / raw)
To: linus.walleij, bgolaszewski, robh+dt, shawnguo, s.hauer, kernel,
festevam, linux-gpio, devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
Convert the MXS GPIO binding to DT schema format using json-schema.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
.../devicetree/bindings/gpio/gpio-mxs.txt | 88 -------------
.../devicetree/bindings/gpio/gpio-mxs.yaml | 136 +++++++++++++++++++++
2 files changed, 136 insertions(+), 88 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-mxs.txt
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-mxs.yaml
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mxs.txt b/Documentation/devicetree/bindings/gpio/gpio-mxs.txt
deleted file mode 100644
index 1e677a4..0000000
--- a/Documentation/devicetree/bindings/gpio/gpio-mxs.txt
+++ /dev/null
@@ -1,88 +0,0 @@
-* Freescale MXS GPIO controller
-
-The Freescale MXS GPIO controller is part of MXS PIN controller. The
-GPIOs are organized in port/bank. Each port consists of 32 GPIOs.
-
-As the GPIO controller is embedded in the PIN controller and all the
-GPIO ports share the same IO space with PIN controller, the GPIO node
-will be represented as sub-nodes of MXS pinctrl node.
-
-Required properties for GPIO node:
-- compatible : Should be "fsl,<soc>-gpio". The supported SoCs include
- imx23 and imx28.
-- interrupts : Should be the port interrupt shared by all 32 pins.
-- gpio-controller : Marks the device node as a gpio controller.
-- #gpio-cells : Should be two. The first cell is the pin number and
- the second cell is used to specify the gpio polarity:
- 0 = active high
- 1 = active low
-- interrupt-controller: Marks the device node as an interrupt controller.
-- #interrupt-cells : Should be 2. The first cell is the GPIO number.
- The second cell bits[3:0] is used to specify trigger type and level flags:
- 1 = low-to-high edge triggered.
- 2 = high-to-low edge triggered.
- 4 = active high level-sensitive.
- 8 = active low level-sensitive.
-
-Note: Each GPIO port should have an alias correctly numbered in "aliases"
-node.
-
-Examples:
-
-aliases {
- gpio0 = &gpio0;
- gpio1 = &gpio1;
- gpio2 = &gpio2;
- gpio3 = &gpio3;
- gpio4 = &gpio4;
-};
-
-pinctrl@80018000 {
- compatible = "fsl,imx28-pinctrl", "simple-bus";
- reg = <0x80018000 2000>;
-
- gpio0: gpio@0 {
- compatible = "fsl,imx28-gpio";
- interrupts = <127>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpio1: gpio@1 {
- compatible = "fsl,imx28-gpio";
- interrupts = <126>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpio2: gpio@2 {
- compatible = "fsl,imx28-gpio";
- interrupts = <125>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpio3: gpio@3 {
- compatible = "fsl,imx28-gpio";
- interrupts = <124>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpio4: gpio@4 {
- compatible = "fsl,imx28-gpio";
- interrupts = <123>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-};
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mxs.yaml b/Documentation/devicetree/bindings/gpio/gpio-mxs.yaml
new file mode 100644
index 0000000..ccf5b50
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-mxs.yaml
@@ -0,0 +1,136 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/gpio-mxs.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale MXS GPIO controller
+
+maintainers:
+ - Shawn Guo <shawn.guo@linaro.org>
+ - Anson Huang <Anson.Huang@nxp.com>
+
+description: |
+ The Freescale MXS GPIO controller is part of MXS PIN controller.
+ The GPIOs are organized in port/bank, each port consists of 32 GPIOs.
+ As the GPIO controller is embedded in the PIN controller and all the
+ GPIO ports share the same IO space with PIN controller, the GPIO node
+ will be represented as sub-nodes of MXS pinctrl node.
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx23-pinctrl
+ - fsl,imx28-pinctrl
+
+ '#address-cells':
+ const: 1
+ '#size-cells':
+ const: 0
+
+ reg:
+ maxItems: 1
+
+patternProperties:
+ "gpio@[0-9]+$":
+ type: object
+ properties:
+ compatible:
+ enum:
+ - fsl,imx23-gpio
+ - fsl,imx28-gpio
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description: Should be the port interrupt shared by all 32 pins.
+ maxItems: 1
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ "#gpio-cells":
+ const: 2
+
+ gpio-controller: true
+
+ required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - "#interrupt-cells"
+ - "#gpio-cells"
+ - gpio-controller
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - '#address-cells'
+ - '#size-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ pinctrl@80018000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,imx28-pinctrl";
+ reg = <0x80018000 0x2000>;
+
+ gpio@0 {
+ compatible = "fsl,imx28-gpio";
+ reg = <0>;
+ interrupts = <127>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpio@1 {
+ compatible = "fsl,imx28-gpio";
+ reg = <1>;
+ interrupts = <126>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpio@2 {
+ compatible = "fsl,imx28-gpio";
+ reg = <2>;
+ interrupts = <125>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpio@3 {
+ compatible = "fsl,imx28-gpio";
+ reg = <3>;
+ interrupts = <124>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpio@4 {
+ compatible = "fsl,imx28-gpio";
+ reg = <4>;
+ interrupts = <123>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+ };
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH V2] arm64/cpuinfo: Move HWCAP name arrays alongside their bit definitions
From: Anshuman Khandual @ 2020-05-20 0:27 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Suzuki K Poulose, Catalin Marinas, linux-kernel,
Dave Martin, Mark Brown, Ard Biesheuvel, linux-arm-kernel
In-Reply-To: <20200518223506.GA5866@willie-the-truck>
On 05/19/2020 04:05 AM, Will Deacon wrote:
> On Fri, May 15, 2020 at 08:58:05AM +0530, Anshuman Khandual wrote:
>> On 05/14/2020 01:06 PM, Will Deacon wrote:
>>> Why is it a change? We've never reported e.g. "java" on an arm64 kernel, so
>>
>> We already have "java" defined in existing compat_hwcap_str[] array even
>> though it might never get set in compat_elf_hwcap. AFAICS, compat_elf_hwcap
>> will have the following capabilities set (at the most).
>>
>> Via COMPAT_ELF_HWCAP_DEFAULT
>>
>> 01. COMPAT_HWCAP_HALF
>> 02. COMPAT_HWCAP_THUMB
>> 03. COMPAT_HWCAP_FAST_MULT
>> 04. COMPAT_HWCAP_EDSP
>> 05. COMPAT_HWCAP_TLS
>> 06. COMPAT_HWCAP_IDIV
>> 07. COMPAT_HWCAP_LPAE
>>
>> Via setup_elf_hwcaps(compat_elf_hwcaps) <-- setup_cpu_features()
>>
>> 8. COMPAT_HWCAP_NEON
>> 9. COMPAT_HWCAP_VFPv4
>> 10. COMPAT_HWCAP_VFP
>> 11. COMPAT_HWCAP_VFPv3
>>
>> Via arch_timer_set_evtstrm_feature()
>>
>> 12. COMPAT_HWCAP_EVTSTRM
>>
>> The code exists for "java" string to be displayed with /proc/cpuinfo but it
>> may never get triggered as compat_elf_hwcap will never have JAVA capability
>> unless there is a bug as you had rightly mentioned.
>
> Fair enough, but applying this patch causes a *tonne* of warnings from
> aiaiai:
>
> +In file included from arch/arm64/include/asm/cpufeature.h:11,
> + from arch/arm64/include/asm/ptrace.h:11,
> + from arch/arm64/include/asm/irqflags.h:10,
> + from include/linux/irqflags.h:16,
> + from include/linux/spinlock.h:54,
> + from include/linux/seqlock.h:36,
> + from include/linux/time.h:6,
> + from arch/arm64/include/asm/stat.h:12,
> + from include/linux/stat.h:6,
> + from include/linux/module.h:13,
> + from drivers/media/rc/keymaps/rc-imon-mce.mod.c:1:
> +arch/arm64/include/asm/hwcap.h:189:26: warning: ‘compat_hwcap2_str’ defined but not used [-Wunused-const-variable=]
> + 189 | static const char *const compat_hwcap2_str[] = {
> + | ^~~~~~~~~~~~~~~~~
Native default build (defconfig) on arm64 does not throw this warning.
I guess this came up with 'make W=n' or something. Anyways if this is
indeed an issue, we will have to add in helpers for each HWCAP arrays
which will fetch a feature string on index value to be used in c_show
(arch/arm64/kernel/cpuinfo.c). I wanted to avoid this to reduce code.
>
> so I'm dropping this for now.
Sure, will respin this later probably after 5.8-rc1.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/2] arm64: meson-sm1: add support for Hardkernel ODROID-C4
From: Kevin Hilman @ 2020-05-20 0:07 UTC (permalink / raw)
To: Neil Armstrong; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel
In-Reply-To: <20200506080702.6645-1-narmstrong@baylibre.com>
On Wed, 6 May 2020 10:07:00 +0200, Neil Armstrong wrote:
> This serie adds support for the Hardkernel Odroid-C4 single board computer.
>
> The Odroid-C4 is the Odroid-C2 successor with same form factor, but using
> a modern Amlogic S905X3 (SM1) SoC and 4x USB3 ports.
>
> Fully functionnal:
> - USB2+USB3
> - USB2 OTG
> - eMMC
> - SDCard
> - HDMI
> - DVFS
> - Gigabit Ethernet with RTL8211F PHY
> - ADC
> - Debug UART
> - Infrared Receiver
>
> [...]
Applied, thanks!
[1/2] dt-bindings: arm: amlogic: add odroid-c4 bindings
commit: 838f0905aaeefce443eca124b27e6474e6862aa3
[2/2] arm64: dts: meson-sm1: add support for Hardkernel ODROID-C4
commit: 326e57518b0dc8789d78e59563afbb3f4107e6e1
Best regards,
--
Kevin Hilman <khilman@baylibre.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH for-5.8 v1 1/1] ARM: dts: meson8m2: Use the Meson8m2 specific USB2 PHY compatible
From: Kevin Hilman @ 2020-05-20 0:07 UTC (permalink / raw)
To: linux-amlogic, Martin Blumenstingl; +Cc: linux-kernel, linux-arm-kernel
In-Reply-To: <20200515202520.1487514-1-martin.blumenstingl@googlemail.com>
On Fri, 15 May 2020 22:25:20 +0200, Martin Blumenstingl wrote:
> Use the Meson8m2 specific USB2 PHY compatible string. The 3.10 vendor
> kernel has at least one known difference between Meson8 and Meson8m2:
> Meson8m2 sets the ACA_ENABLE bit while Meson8 doesn't.
Applied, thanks!
[1/1] ARM: dts: meson8m2: Use the Meson8m2 specific USB2 PHY compatible
commit: f5a7382d6f176e29e4fd9d733b93d5b93771a7e4
Best regards,
--
Kevin Hilman <khilman@baylibre.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/2] ARM: dts: meson8b/m2: RGMII improvements
From: Kevin Hilman @ 2020-05-20 0:07 UTC (permalink / raw)
To: linux-amlogic, Martin Blumenstingl; +Cc: andrew, linux-kernel, linux-arm-kernel
In-Reply-To: <20200512215148.540322-1-martin.blumenstingl@googlemail.com>
On Tue, 12 May 2020 23:51:46 +0200, Martin Blumenstingl wrote:
> the fist patch in this series connects FCLK_DIV2 to the PRG_ETH
> "additional" registers for the dwmac Ethernet controller.
> Now that we know how RGMII and FCLK_DIV2 are connected we can
> add this dependency to get rid of CLK_IS_CRITICAL for FCLK_DIV2
> at some point.
>
> The second patch fixes the RX and TX delay. The 4ns TX delay which
> we have used so far is incorrect and only worked because we were
> using an unsupported clock divider in the PRG_ETH registers. That
> divider has been fixed with commit bd6f48546b9c ("net: stmmac:
> dwmac-meson8b: Fix the RGMII TX delay on Meson8b/8m2 SoCs").
> Instead of "just" fixing the TX delay we can even do better and
> switch to phy-mode = "rgmii-id" to let the PHY generate the RX
> and TX delay. However, previously we didn't know that there was
> an RX delay applied by the MAC on these boards. Only the additional
> information from Jianxin in the other series [0] made us aware
> of this. Without the other series there will be a 4ns RX delay
> (2ns from the MAC and additional 2ns from the PHY). Due to this
> dependency I did not add a Fixes tag, because backporting these
> .dts patches without their runtime dependency will break stable
> kernels.
>
> [...]
Applied, thanks!
[1/2] ARM: dts: meson: Add the Ethernet "timing-adjustment" clock
commit: b632506c5af22a9a7c63674fc605d24cf94d585b
[2/2] ARM: dts: meson: Switch existing boards with RGMII PHY to "rgmii-id"
commit: 005231128e9e97461e81fa32421957a7664317ca
Best regards,
--
Kevin Hilman <khilman@baylibre.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 0/3] arm64: dts: meson: add dts/bindings for SmartLabs SML-5442TW
From: Kevin Hilman @ 2020-05-20 0:07 UTC (permalink / raw)
To: linux-amlogic, linux-kernel, Rob Herring, linux-arm-kernel,
Mark Rutland, devicetree, Christian Hewitt
In-Reply-To: <20200510124129.31575-1-christianshewitt@gmail.com>
On Sun, 10 May 2020 12:41:26 +0000, Christian Hewitt wrote:
> This series adds new bindings and a device-tree file for the Smartlabs
> SML-5442TW set-top box which is based on the P231 reference design.
>
> As requested, I have reworked the device-tree on the p23x-q20x dtsi. I
> have also re-added the BT device with new bindings that have now been
> merged in bluetooth-next for inclusion in Linux 5.8. See [1].
>
> [...]
Applied, thanks!
[1/3] dt-bindings: add vendor prefix for Smartlabs LLC
commit: bc15895e142396fed5ebf1f60139d9ca9a56a4e4
[2/3] dt-bindings: arm: amlogic: add support for the Smartlabs SML-5442TW
commit: 341e85047bdbc0196c91ccb4612ffab87bae9cfe
[3/3] arm64: dts: meson: add support for the Smartlabs SML-5442TW
commit: 1d6ece87b750cf26fed4eb794ea0b2fc7ff2be10
Best regards,
--
Kevin Hilman <khilman@baylibre.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: meson: add ethernet interrupt to wetek dtsi
From: Kevin Hilman @ 2020-05-20 0:07 UTC (permalink / raw)
To: linux-amlogic, linux-kernel, Rob Herring, linux-arm-kernel,
Mark Rutland, devicetree, Christian Hewitt
In-Reply-To: <20200518025451.16401-1-christianshewitt@gmail.com>
On Mon, 18 May 2020 02:54:51 +0000, Christian Hewitt wrote:
> Add Ethernet interrupt details to the WeTek Hub/Play2 dtsi to resolve
> an issue with Ethernet probing in mainline u-boot.
Applied, thanks!
[1/1] arm64: dts: meson: add ethernet interrupt to wetek dtsi
commit: 647e1643d61312ce08172e466fa1c8d8a5c8fbc8
Best regards,
--
Kevin Hilman <khilman@baylibre.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/4] clk/soc: mediatek: mt6779: Bind clock driver from platform device
From: Chun-Kuang Hu @ 2020-05-19 23:52 UTC (permalink / raw)
To: Matthias Brugger
Cc: Kate Stewart, Chun-Kuang Hu, devicetree, Stephen Boyd,
Greg Kroah-Hartman, Michael Turquette, linux-kernel, Rob Herring,
moderated list:ARM/Mediatek SoC support, Allison Randal,
matthias.bgg, Matthias Brugger, mtk01761, Thomas Gleixner,
linux-clk, Linux ARM
In-Reply-To: <3a8b3846-c399-2193-a203-8707d693dad8@suse.com>
Matthias Brugger <mbrugger@suse.com> 於 2020年5月20日 週三 上午5:26寫道：
>
>
>
> On 19/05/2020 17:10, Chun-Kuang Hu wrote:
> > Hi, Matthias:
> >
> > <matthias.bgg@kernel.org> 於 2020年5月18日 週一 下午7:33寫道：
> >>
> >> From: Matthias Brugger <matthias.bgg@gmail.com>
> >>
> >> The mmsys driver is now the top level entry point for the multimedia
> >> system (mmsys), we bind the clock driver by creating a platform device.
> >> We also bind the MediaTek DRM driver which is not yet implement and
> >> therefor will errror out for now.
> >>
> >> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
> >> ---
> >>
> >> drivers/clk/mediatek/clk-mt6779-mm.c | 9 ++-------
> >> drivers/soc/mediatek/mtk-mmsys.c | 8 ++++++++
> >> 2 files changed, 10 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/clk/mediatek/clk-mt6779-mm.c b/drivers/clk/mediatek/clk-mt6779-mm.c
> >> index fb5fbb8e3e41..059c1a41ac7a 100644
> >> --- a/drivers/clk/mediatek/clk-mt6779-mm.c
> >> +++ b/drivers/clk/mediatek/clk-mt6779-mm.c
> >> @@ -84,15 +84,11 @@ static const struct mtk_gate mm_clks[] = {
> >> GATE_MM1(CLK_MM_DISP_OVL_FBDC, "mm_disp_ovl_fbdc", "mm_sel", 16),
> >> };
> >>
> >> -static const struct of_device_id of_match_clk_mt6779_mm[] = {
> >> - { .compatible = "mediatek,mt6779-mmsys", },
> >> - {}
> >> -};
> >> -
> >> static int clk_mt6779_mm_probe(struct platform_device *pdev)
> >> {
> >> + struct device *dev = &pdev->dev;
> >> + struct device_node *node = dev->parent->of_node;
> >> struct clk_onecell_data *clk_data;
> >> - struct device_node *node = pdev->dev.of_node;
> >>
> >> clk_data = mtk_alloc_clk_data(CLK_MM_NR_CLK);
> >>
> >> @@ -106,7 +102,6 @@ static struct platform_driver clk_mt6779_mm_drv = {
> >> .probe = clk_mt6779_mm_probe,
> >> .driver = {
> >> .name = "clk-mt6779-mm",
> >> - .of_match_table = of_match_clk_mt6779_mm,
> >> },
> >> };
> >>
> >> diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
> >> index fee64c8d3020..dc15808cf3a3 100644
> >> --- a/drivers/soc/mediatek/mtk-mmsys.c
> >> +++ b/drivers/soc/mediatek/mtk-mmsys.c
> >> @@ -88,6 +88,10 @@ static const struct mtk_mmsys_driver_data mt2712_mmsys_driver_data = {
> >> .clk_driver = "clk-mt2712-mm",
> >> };
> >>
> >> +static const struct mtk_mmsys_driver_data mt6779_mmsys_driver_data = {
> >> + .clk_driver = "clk-mt6779-mm",
> >
> > This patch looks good to me, but I've one question: why drm driver
> > just use single "mediatek-drm" for sub driver name, but clock driver
> > has different name for each SoC?
> > Could we just use single name for clock driver such as "mediatek-clk-mm"?
>
> Because the DRM for all SoCs are handled in the same driver, while we have a
> different clock drivers for each SoC. So we need to specify which clock driver
> we want to load.
>
> If we want to change that, we would need to refactor heavily the clock drivers
> for all MediaTek SoCs. I don't think it's worth the effort.
>
OK, so for this patch,
Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
> Regards,
> Matthias
>
> >
> > Regards,
> > Chun-Kuang.
> >
> >> +};
> >> +
> >> static const struct mtk_mmsys_driver_data mt6797_mmsys_driver_data = {
> >> .clk_driver = "clk-mt6797-mm",
> >> };
> >> @@ -343,6 +347,10 @@ static const struct of_device_id of_match_mtk_mmsys[] = {
> >> .compatible = "mediatek,mt2712-mmsys",
> >> .data = &mt2712_mmsys_driver_data,
> >> },
> >> + {
> >> + .compatible = "mediatek,mt6779-mmsys",
> >> + .data = &mt6779_mmsys_driver_data,
> >> + },
> >> {
> >> .compatible = "mediatek,mt6797-mmsys",
> >> .data = &mt6797_mmsys_driver_data,
> >> --
> >> 2.26.2
> >>
> >>
> >> _______________________________________________
> >> Linux-mediatek mailing list
> >> Linux-mediatek@lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/linux-mediatek
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/5] arm64: dts: meson: add W400 dtsi and GT-King/Pro devices
From: Kevin Hilman @ 2020-05-19 23:42 UTC (permalink / raw)
To: Christian Hewitt, Rob Herring, Mark Rutland, devicetree,
linux-arm-kernel, linux-amlogic, linux-kernel
Cc: Christian Hewitt
In-Reply-To: <20200518023404.15166-1-christianshewitt@gmail.com>
Hi Christian,
Christian Hewitt <christianshewitt@gmail.com> writes:
> This series combines patch 2 from [1] which converts the existing Ugoos
> AM6 device-tree to a common W400 dtsi and dts, and then reworks the
> Beelink GT-King/GT-King Pro serries from [2] to use the dtsi, but this
> time without the offending common audio dtsi approach. I've carried
> forwards acks on bindings from Rob as these did not change.
This looks good to me, thank you very much for reworking into a
w400-based include.
Unfortunately, it no longer applies on top of all the other stuff I have
queued for v5.8.
Could you please do a rebase on top of my v5.8/dt64 branch[1], and I'll
queue for v5.8.
Thanks,
Kevin
> v3 - amend author full-name on bindings patch
>
> [1] https://patchwork.kernel.org/patch/11497105/
> [2] https://patchwork.kernel.org/project/linux-amlogic/list/?series=273483
>
> Christian Hewitt (5):
> arm64: dts: meson: convert ugoos-am6 to common w400 dtsi
> dt-bindings: arm: amlogic: add support for the Beelink GT-King
> arm64: dts: meson-g12b-gtking: add initial device-tree
> dt-bindings: arm: amlogic: add support for the Beelink GT-King Pro
> arm64: dts: meson-g12b-gtking-pro: add initial device-tree
>
> .../devicetree/bindings/arm/amlogic.yaml | 2 +
> arch/arm64/boot/dts/amlogic/Makefile | 2 +
> .../dts/amlogic/meson-g12b-gtking-pro.dts | 125 ++++++
> .../boot/dts/amlogic/meson-g12b-gtking.dts | 145 ++++++
> .../boot/dts/amlogic/meson-g12b-ugoos-am6.dts | 410 +----------------
> .../boot/dts/amlogic/meson-g12b-w400.dtsi | 423 ++++++++++++++++++
> 6 files changed, 698 insertions(+), 409 deletions(-)
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12b-gtking-pro.dts
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12b-gtking.dts
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12b-w400.dtsi
>
> --
> 2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH][v2] iommu: arm-smmu-v3: Copy SMMU table for kdump kernel
From: Bjorn Helgaas @ 2020-05-19 23:22 UTC (permalink / raw)
To: Prabhakar Kushwaha
Cc: Kuppuswamy Sathyanarayanan, Ganapatrao Prabhakerrao Kulkarni,
Myron Stowe, Vijay Mohan Pandarathil, Marc Zyngier,
Bhupesh Sharma, kexec mailing list, Robin Murphy, linux-pci,
Prabhakar Kushwaha, Will Deacon, linux-arm-kernel
In-Reply-To: <CAJ2QiJLV3pudhWPSERAz1s+kUj0VyU7c2N3XqXg--_kObK3D=g@mail.gmail.com>
[+cc Sathy, Vijay, Myron]
On Thu, May 14, 2020 at 12:47:02PM +0530, Prabhakar Kushwaha wrote:
> On Wed, May 13, 2020 at 3:33 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Mon, May 11, 2020 at 07:46:06PM -0700, Prabhakar Kushwaha wrote:
> > > An SMMU Stream table is created by the primary kernel. This table is
> > > used by the SMMU to perform address translations for device-originated
> > > transactions. Any crash (if happened) launches the kdump kernel which
> > > re-creates the SMMU Stream table. New transactions will be translated
> > > via this new table..
> > >
> > > There are scenarios, where devices are still having old pending
> > > transactions (configured in the primary kernel). These transactions
> > > come in-between Stream table creation and device-driver probe.
> > > As new stream table does not have entry for older transactions,
> > > it will be aborted by SMMU.
> > >
> > > Similar observations were found with PCIe-Intel 82576 Gigabit
> > > Network card. It sends old Memory Read transaction in kdump kernel.
> > > Transactions configured for older Stream table entries, that do not
> > > exist any longer in the new table, will cause a PCIe Completion Abort.
> >
> > That sounds like exactly what we want, doesn't it?
> >
> > Or do you *want* DMA from the previous kernel to complete? That will
> > read or scribble on something, but maybe that's not terrible as long
> > as it's not memory used by the kdump kernel.
>
> Yes, Abort should happen. But it should happen in context of driver.
> But current abort is happening because of SMMU and no driver/pcie
> setup present at this moment.
I don't understand what you mean by "in context of driver." The whole
problem is that we can't control *when* the abort happens, so it may
happen in *any* context. It may happen when a NIC receives a packet
or at some other unpredictable time.
> Solution of this issue should be at 2 place
> a) SMMU level: I still believe, this patch has potential to overcome
> issue till finally driver's probe takeover.
> b) Device level: Even if something goes wrong. Driver/device should
> able to recover.
>
> > > Returned PCIe completion abort further leads to AER Errors from APEI
> > > Generic Hardware Error Source (GHES) with completion timeout.
> > > A network device hang is observed even after continuous
> > > reset/recovery from driver, Hence device is no more usable.
> >
> > The fact that the device is no longer usable is definitely a problem.
> > But in principle we *should* be able to recover from these errors. If
> > we could recover and reliably use the device after the error, that
> > seems like it would be a more robust solution that having to add
> > special cases in every IOMMU driver.
> >
> > If you have details about this sort of error, I'd like to try to fix
> > it because we want to recover from that sort of error in normal
> > (non-crash) situations as well.
> >
> Completion abort case should be gracefully handled. And device should
> always remain usable.
>
> There are 2 scenario which I am testing with Ethernet card PCIe-Intel
> 82576 Gigabit Network card.
>
> I) Crash testing using kdump root file system: De-facto scenario
> - kdump file system does not have Ethernet driver
> - A lot of AER prints [1], making it impossible to work on shell
> of kdump root file system.
In this case, I think report_error_detected() is deciding that because
the device has no driver, we can't do anything. The flow is like
this:
aer_recover_work_func # aer_recover_work
kfifo_get(aer_recover_ring, entry)
dev = pci_get_domain_bus_and_slot
cper_print_aer(dev, ...)
pci_err("AER: aer_status:")
pci_err("AER: [14] CmpltTO")
pci_err("AER: aer_layer=")
if (AER_NONFATAL)
pcie_do_recovery(dev, pci_channel_io_normal)
status = CAN_RECOVER
pci_walk_bus(report_normal_detected)
report_error_detected
if (!dev->driver)
vote = NO_AER_DRIVER
pci_info("can't recover (no error_detected callback)")
*result = merge_result(*, NO_AER_DRIVER)
# always NO_AER_DRIVER
status is now NO_AER_DRIVER
So pcie_do_recovery() does not call .report_mmio_enabled() or .slot_reset(),
and status is not RECOVERED, so it skips .resume().
I don't remember the history there, but if a device has no driver and
the device generates errors, it seems like we ought to be able to
reset it.
We should be able to field one (or a few) AER errors, reset the
device, and you should be able to use the shell in the kdump kernel.
> - Note kdump shell allows to use makedumpfile, vmcore-dmesg applications.
>
> II) Crash testing using default root file system: Specific case to
> test Ethernet driver in second kernel
> - Default root file system have Ethernet driver
> - AER error comes even before the driver probe starts.
> - Driver does reset Ethernet card as part of probe but no success.
> - AER also tries to recover. but no success. [2]
> - I also tries to remove AER errors by using "pci=noaer" bootargs
> and commenting ghes_handle_aer() from GHES driver..
> than different set of errors come which also never able to recover [3]
>
> As per my understanding, possible solutions are
> - Copy SMMU table i.e. this patch
> OR
> - Doing pci_reset_function() during enumeration phase.
> I also tried clearing "M" bit using pci_clear_master during
> enumeration but it did not help. Because driver re-set M bit causing
> same AER error again.
>
>
> -pk
>
> ---------------------------------------------------------------------------------------------------------------------------
> [1] with bootargs having pci=noaer
>
> [ 22.494648] {4}[Hardware Error]: Hardware error from APEI Generic
> Hardware Error Source: 1
> [ 22.512773] {4}[Hardware Error]: event severity: recoverable
> [ 22.518419] {4}[Hardware Error]: Error 0, type: recoverable
> [ 22.544804] {4}[Hardware Error]: section_type: PCIe error
> [ 22.550363] {4}[Hardware Error]: port_type: 0, PCIe end point
> [ 22.556268] {4}[Hardware Error]: version: 3.0
> [ 22.560785] {4}[Hardware Error]: command: 0x0507, status: 0x4010
> [ 22.576852] {4}[Hardware Error]: device_id: 0000:09:00.1
> [ 22.582323] {4}[Hardware Error]: slot: 0
> [ 22.586406] {4}[Hardware Error]: secondary_bus: 0x00
> [ 22.591530] {4}[Hardware Error]: vendor_id: 0x8086, device_id: 0x10c9
> [ 22.608900] {4}[Hardware Error]: class_code: 000002
> [ 22.613938] {4}[Hardware Error]: serial number: 0xff1b4580, 0x90e2baff
> [ 22.803534] pci 0000:09:00.1: AER: aer_status: 0x00004000,
> aer_mask: 0x00000000
> [ 22.810838] pci 0000:09:00.1: AER: [14] CmpltTO (First)
> [ 22.817613] pci 0000:09:00.1: AER: aer_layer=Transaction Layer,
> aer_agent=Requester ID
> [ 22.847374] pci 0000:09:00.1: AER: aer_uncor_severity: 0x00062011
> [ 22.866161] mpt3sas_cm0: 63 BIT PCI BUS DMA ADDRESSING SUPPORTED,
> total mem (8153768 kB)
> [ 22.946178] pci 0000:09:00.0: AER: can't recover (no error_detected callback)
> [ 22.995142] pci 0000:09:00.1: AER: can't recover (no error_detected callback)
> [ 23.002300] pcieport 0000:00:09.0: AER: device recovery failed
> [ 23.027607] pci 0000:09:00.1: AER: aer_status: 0x00004000,
> aer_mask: 0x00000000
> [ 23.044109] pci 0000:09:00.1: AER: [14] CmpltTO (First)
> [ 23.060713] pci 0000:09:00.1: AER: aer_layer=Transaction Layer,
> aer_agent=Requester ID
> [ 23.068616] pci 0000:09:00.1: AER: aer_uncor_severity: 0x00062011
> [ 23.122056] pci 0000:09:00.0: AER: can't recover (no error_detected callback)
>
>
> ----------------------------------------------------------------------------------------------------------------------------
> [2] Normal bootargs.
>
> [ 54.252454] {6}[Hardware Error]: Hardware error from APEI Generic
> Hardware Error Source: 1
> [ 54.265827] {6}[Hardware Error]: event severity: recoverable
> [ 54.271473] {6}[Hardware Error]: Error 0, type: recoverable
> [ 54.281605] {6}[Hardware Error]: section_type: PCIe error
> [ 54.287163] {6}[Hardware Error]: port_type: 0, PCIe end point
> [ 54.296955] {6}[Hardware Error]: version: 3.0
> [ 54.301471] {6}[Hardware Error]: command: 0x0507, status: 0x4010
> [ 54.312520] {6}[Hardware Error]: device_id: 0000:09:00.1
> [ 54.317991] {6}[Hardware Error]: slot: 0
> [ 54.322074] {6}[Hardware Error]: secondary_bus: 0x00
> [ 54.327197] {6}[Hardware Error]: vendor_id: 0x8086, device_id: 0x10c9
> [ 54.333797] {6}[Hardware Error]: class_code: 000002
> [ 54.351312] {6}[Hardware Error]: serial number: 0xff1b4580, 0x90e2baff
> [ 54.358001] AER: AER recover: Buffer overflow when recovering AER
> for 0000:09:00:1
> [ 54.376852] pcieport 0000:00:09.0: AER: device recovery successful
> [ 54.383034] igb 0000:09:00.1: AER: aer_status: 0x00004000,
> aer_mask: 0x00000000
> [ 54.390348] igb 0000:09:00.1: AER: [14] CmpltTO (First)
> [ 54.397144] igb 0000:09:00.1: AER: aer_layer=Transaction Layer,
> aer_agent=Requester ID
> [ 54.409555] igb 0000:09:00.1: AER: aer_uncor_severity: 0x00062011
> [ 54.551370] AER: AER recover: Buffer overflow when recovering AER
> for 0000:09:00:1
> [ 54.705214] AER: AER recover: Buffer overflow when recovering AER
> for 0000:09:00:1
> [ 54.758703] AER: AER recover: Buffer overflow when recovering AER
> for 0000:09:00:1
> [ 54.865445] AER: AER recover: Buffer overflow when recovering AER
> for 0000:09:00:1
> [ 54.888751] pcieport 0000:00:09.0: AER: device recovery successful
> [ 54.894933] igb 0000:09:00.1: AER: aer_status: 0x00004000,
> aer_mask: 0x00000000
> [ 54.902228] igb 0000:09:00.1: AER: [14] CmpltTO (First)
> [ 54.916059] igb 0000:09:00.1: AER: aer_layer=Transaction Layer,
> aer_agent=Requester ID
> [ 54.923972] igb 0000:09:00.1: AER: aer_uncor_severity: 0x00062011
> [ 55.057272] AER: AER recover: Buffer overflow when recovering AER
> for 0000:09:00:1
> [ 274.571401] AER: AER recover: Buffer overflow when recovering AER
> for 0000:09:00:1
> [ 274.686138] AER: AER recover: Buffer overflow when recovering AER
> for 0000:09:00:1
> [ 274.786134] AER: AER recover: Buffer overflow when recovering AER
> for 0000:09:00:1
> [ 274.886141] AER: AER recover: Buffer overflow when recovering AER
> for 0000:09:00:1
> [ 397.792897] Workqueue: events aer_recover_work_func
> [ 397.797760] Call trace:
> [ 397.800199] __switch_to+0xcc/0x108
> [ 397.803675] __schedule+0x2c0/0x700
> [ 397.807150] schedule+0x58/0xe8
> [ 397.810283] schedule_preempt_disabled+0x18/0x28
> [ 397.810788] AER: AER recover: Buffer overflow when recovering AER
> for 0000:09:00:1
> [ 397.814887] __mutex_lock.isra.9+0x288/0x5c8
> [ 397.814890] __mutex_lock_slowpath+0x1c/0x28
> [ 397.830962] mutex_lock+0x4c/0x68
> [ 397.834264] report_slot_reset+0x30/0xa0
> [ 397.838178] pci_walk_bus+0x68/0xc0
> [ 397.841653] pcie_do_recovery+0xe8/0x248
> [ 397.845562] aer_recover_work_func+0x100/0x138
> [ 397.849995] process_one_work+0x1bc/0x458
> [ 397.853991] worker_thread+0x150/0x500
> [ 397.857727] kthread+0x114/0x118
> [ 397.860945] ret_from_fork+0x10/0x18
> [ 397.864525] INFO: task kworker/223:2:2939 blocked for more than 122 seconds.
> [ 397.871564] Not tainted 5.7.0-rc3+ #68
> [ 397.875819] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
> disables this message.
> [ 397.883638] kworker/223:2 D 0 2939 2 0x00000228
> [ 397.889121] Workqueue: ipv6_addrconf addrconf_verify_work
> [ 397.894505] Call trace:
> [ 397.896940] __switch_to+0xcc/0x108
> [ 397.900419] __schedule+0x2c0/0x700
> [ 397.903894] schedule+0x58/0xe8
> [ 397.907023] schedule_preempt_disabled+0x18/0x28
> [ 397.910798] AER: AER recover: Buffer overflow when recovering AER
> for 0000:09:00:1
> [ 397.911630] __mutex_lock.isra.9+0x288/0x5c8
> [ 397.923440] __mutex_lock_slowpath+0x1c/0x28
> [ 397.927696] mutex_lock+0x4c/0x68
> [ 397.931005] rtnl_lock+0x24/0x30
> [ 397.934220] addrconf_verify_work+0x18/0x30
> [ 397.938394] process_one_work+0x1bc/0x458
> [ 397.942390] worker_thread+0x150/0x500
> [ 397.946126] kthread+0x114/0x118
> [ 397.949345] ret_from_fork+0x10/0x18
>
> ---------------------------------------------------------------------------------------------------------------------------------
> [3] with bootargs as pci=noaer and comment ghes_halder_aer() from AER driver
>
> [ 69.037035] igb 0000:09:00.1 enp9s0f1: Reset adapter
> [ 69.348446] {9}[Hardware Error]: Hardware error from APEI Generic
> Hardware Error Source: 0
> [ 69.356698] {9}[Hardware Error]: It has been corrected by h/w and
> requires no further action
> [ 69.365121] {9}[Hardware Error]: event severity: corrected
> [ 69.370593] {9}[Hardware Error]: Error 0, type: corrected
> [ 69.376064] {9}[Hardware Error]: section_type: PCIe error
> [ 69.381623] {9}[Hardware Error]: port_type: 4, root port
> [ 69.387094] {9}[Hardware Error]: version: 3.0
> [ 69.391611] {9}[Hardware Error]: command: 0x0106, status: 0x4010
> [ 69.397777] {9}[Hardware Error]: device_id: 0000:00:09.0
> [ 69.403248] {9}[Hardware Error]: slot: 0
> [ 69.407331] {9}[Hardware Error]: secondary_bus: 0x09
> [ 69.412455] {9}[Hardware Error]: vendor_id: 0x177d, device_id: 0xaf84
> [ 69.419055] {9}[Hardware Error]: class_code: 000406
> [ 69.424093] {9}[Hardware Error]: bridge: secondary_status:
> 0x6000, control: 0x0002
> [ 72.118132] igb 0000:09:00.1 enp9s0f1: igb: enp9s0f1 NIC Link is Up
> 1000 Mbps Full Duplex, Flow Control: RX
> [ 73.995068] igb 0000:09:00.1: Detected Tx Unit Hang
> [ 73.995068] Tx Queue <2>
> [ 73.995068] TDH <0>
> [ 73.995068] TDT <1>
> [ 73.995068] next_to_use <1>
> [ 73.995068] next_to_clean <0>
> [ 73.995068] buffer_info[next_to_clean]
> [ 73.995068] time_stamp <ffff9c1a>
> [ 73.995068] next_to_watch <0000000097d42934>
> [ 73.995068] jiffies <ffff9cd0>
> [ 73.995068] desc.status <168000>
> [ 75.987323] igb 0000:09:00.1: Detected Tx Unit Hang
> [ 75.987323] Tx Queue <2>
> [ 75.987323] TDH <0>
> [ 75.987323] TDT <1>
> [ 75.987323] next_to_use <1>
> [ 75.987323] next_to_clean <0>
> [ 75.987323] buffer_info[next_to_clean]
> [ 75.987323] time_stamp <ffff9c1a>
> [ 75.987323] next_to_watch <0000000097d42934>
> [ 75.987323] jiffies <ffff9d98>
> [ 75.987323] desc.status <168000>
> [ 77.952661] {10}[Hardware Error]: Hardware error from APEI Generic
> Hardware Error Source: 1
> [ 77.971790] {10}[Hardware Error]: event severity: recoverable
> [ 77.977522] {10}[Hardware Error]: Error 0, type: recoverable
> [ 77.983254] {10}[Hardware Error]: section_type: PCIe error
> [ 77.999930] {10}[Hardware Error]: port_type: 0, PCIe end point
> [ 78.005922] {10}[Hardware Error]: version: 3.0
> [ 78.010526] {10}[Hardware Error]: command: 0x0507, status: 0x4010
> [ 78.016779] {10}[Hardware Error]: device_id: 0000:09:00.1
> [ 78.033107] {10}[Hardware Error]: slot: 0
> [ 78.037276] {10}[Hardware Error]: secondary_bus: 0x00
> [ 78.066253] {10}[Hardware Error]: vendor_id: 0x8086, device_id: 0x10c9
> [ 78.072940] {10}[Hardware Error]: class_code: 000002
> [ 78.078064] {10}[Hardware Error]: serial number: 0xff1b4580, 0x90e2baff
> [ 78.096202] igb 0000:09:00.1: Detected Tx Unit Hang
> [ 78.096202] Tx Queue <2>
> [ 78.096202] TDH <0>
> [ 78.096202] TDT <1>
> [ 78.096202] next_to_use <1>
> [ 78.096202] next_to_clean <0>
> [ 78.096202] buffer_info[next_to_clean]
> [ 78.096202] time_stamp <ffff9c1a>
> [ 78.096202] next_to_watch <0000000097d42934>
> [ 78.096202] jiffies <ffff9e6a>
> [ 78.096202] desc.status <168000>
> [ 79.587406] {11}[Hardware Error]: Hardware error from APEI Generic
> Hardware Error Source: 0
> [ 79.595744] {11}[Hardware Error]: It has been corrected by h/w and
> requires no further action
> [ 79.604254] {11}[Hardware Error]: event severity: corrected
> [ 79.609813] {11}[Hardware Error]: Error 0, type: corrected
> [ 79.615371] {11}[Hardware Error]: section_type: PCIe error
> [ 79.621016] {11}[Hardware Error]: port_type: 4, root port
> [ 79.626574] {11}[Hardware Error]: version: 3.0
> [ 79.631177] {11}[Hardware Error]: command: 0x0106, status: 0x4010
> [ 79.637430] {11}[Hardware Error]: device_id: 0000:00:09.0
> [ 79.642988] {11}[Hardware Error]: slot: 0
> [ 79.647157] {11}[Hardware Error]: secondary_bus: 0x09
> [ 79.652368] {11}[Hardware Error]: vendor_id: 0x177d, device_id: 0xaf84
> [ 79.659055] {11}[Hardware Error]: class_code: 000406
> [ 79.664180] {11}[Hardware Error]: bridge: secondary_status:
> 0x6000, control: 0x0002
> [ 79.987052] igb 0000:09:00.1: Detected Tx Unit Hang
> [ 79.987052] Tx Queue <2>
> [ 79.987052] TDH <0>
> [ 79.987052] TDT <1>
> [ 79.987052] next_to_use <1>
> [ 79.987052] next_to_clean <0>
> [ 79.987052] buffer_info[next_to_clean]
> [ 79.987052] time_stamp <ffff9c1a>
> [ 79.987052] next_to_watch <0000000097d42934>
> [ 79.987052] jiffies <ffff9f28>
> [ 79.987052] desc.status <168000>
> [ 79.987056] igb 0000:09:00.1: Detected Tx Unit Hang
> [ 79.987056] Tx Queue <3>
> [ 79.987056] TDH <0>
> [ 79.987056] TDT <1>
> [ 79.987056] next_to_use <1>
> [ 79.987056] next_to_clean <0>
> [ 79.987056] buffer_info[next_to_clean]
> [ 79.987056] time_stamp <ffff9e43>
> [ 79.987056] next_to_watch <000000008da33deb>
> [ 79.987056] jiffies <ffff9f28>
> [ 79.987056] desc.status <514000>
> [ 81.986688] igb 0000:09:00.1 enp9s0f1: Reset adapter
> [ 81.986842] igb 0000:09:00.1: Detected Tx Unit Hang
> [ 81.986842] Tx Queue <2>
> [ 81.986842] TDH <0>
> [ 81.986842] TDT <1>
> [ 81.986842] next_to_use <1>
> [ 81.986842] next_to_clean <0>
> [ 81.986842] buffer_info[next_to_clean]
> [ 81.986842] time_stamp <ffff9c1a>
> [ 81.986842] next_to_watch <0000000097d42934>
> [ 81.986842] jiffies <ffff9ff0>
> [ 81.986842] desc.status <168000>
> [ 81.986844] igb 0000:09:00.1: Detected Tx Unit Hang
> [ 81.986844] Tx Queue <3>
> [ 81.986844] TDH <0>
> [ 81.986844] TDT <1>
> [ 81.986844] next_to_use <1>
> [ 81.986844] next_to_clean <0>
> [ 81.986844] buffer_info[next_to_clean]
> [ 81.986844] time_stamp <ffff9e43>
> [ 81.986844] next_to_watch <000000008da33deb>
> [ 81.986844] jiffies <ffff9ff0>
> [ 81.986844] desc.status <514000>
> [ 85.346515] {12}[Hardware Error]: Hardware error from APEI Generic
> Hardware Error Source: 0
> [ 85.354854] {12}[Hardware Error]: It has been corrected by h/w and
> requires no further action
> [ 85.363365] {12}[Hardware Error]: event severity: corrected
> [ 85.368924] {12}[Hardware Error]: Error 0, type: corrected
> [ 85.374483] {12}[Hardware Error]: section_type: PCIe error
> [ 85.380129] {12}[Hardware Error]: port_type: 0, PCIe end point
> [ 85.386121] {12}[Hardware Error]: version: 3.0
> [ 85.390725] {12}[Hardware Error]: command: 0x0507, status: 0x0010
> [ 85.396980] {12}[Hardware Error]: device_id: 0000:09:00.0
> [ 85.402540] {12}[Hardware Error]: slot: 0
> [ 85.406710] {12}[Hardware Error]: secondary_bus: 0x00
> [ 85.411921] {12}[Hardware Error]: vendor_id: 0x8086, device_id: 0x10c9
> [ 85.418609] {12}[Hardware Error]: class_code: 000002
> [ 85.423733] {12}[Hardware Error]: serial number: 0xff1b4580, 0x90e2baff
> [ 85.826695] igb 0000:09:00.1 enp9s0f1: igb: enp9s0f1 NIC Link is Up
> 1000 Mbps Full Duplex, Flow Control: RX
>
>
>
>
>
> > > So, If we are in a kdump kernel try to copy SMMU Stream table from
> > > primary/old kernel to preserve the mappings until the device driver
> > > takes over.
> > >
> > > Signed-off-by: Prabhakar Kushwaha <pkushwaha@marvell.com>
> > > ---
> > > Changes for v2: Used memremap in-place of ioremap
> > >
> > > V2 patch has been sanity tested.
> > >
> > > V1 patch has been tested with
> > > A) PCIe-Intel 82576 Gigabit Network card in following
> > > configurations with "no AER error". Each iteration has
> > > been tested on both Suse kdump rfs And default Centos distro rfs.
> > >
> > > 1) with 2 level stream table
> > > ----------------------------------------------------
> > > SMMU | Normal Ping | Flood Ping
> > > -----------------------------------------------------
> > > Default Operation | 100 times | 10 times
> > > -----------------------------------------------------
> > > IOMMU bypass | 41 times | 10 times
> > > -----------------------------------------------------
> > >
> > > 2) with Linear stream table.
> > > -----------------------------------------------------
> > > SMMU | Normal Ping | Flood Ping
> > > ------------------------------------------------------
> > > Default Operation | 100 times | 10 times
> > > ------------------------------------------------------
> > > IOMMU bypass | 55 times | 10 times
> > > -------------------------------------------------------
> > >
> > > B) This patch is also tested with Micron Technology Inc 9200 PRO NVMe
> > > SSD card with 2 level stream table using "fio" in mixed read/write and
> > > only read configurations. It is tested for both Default Operation and
> > > IOMMU bypass mode for minimum 10 iterations across Centos kdump rfs and
> > > default Centos ditstro rfs.
> > >
> > > This patch is not full proof solution. Issue can still come
> > > from the point device is discovered and driver probe called.
> > > This patch has reduced window of scenario from "SMMU Stream table
> > > creation - device-driver" to "device discovery - device-driver".
> > > Usually, device discovery to device-driver is very small time. So
> > > the probability is very low.
> > >
> > > Note: device-discovery will overwrite existing stream table entries
> > > with both SMMU stage as by-pass.
> > >
> > >
> > > drivers/iommu/arm-smmu-v3.c | 36 +++++++++++++++++++++++++++++++++++-
> > > 1 file changed, 35 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> > > index 82508730feb7..d492d92c2dd7 100644
> > > --- a/drivers/iommu/arm-smmu-v3.c
> > > +++ b/drivers/iommu/arm-smmu-v3.c
> > > @@ -1847,7 +1847,13 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid,
> > > break;
> > > case STRTAB_STE_0_CFG_S1_TRANS:
> > > case STRTAB_STE_0_CFG_S2_TRANS:
> > > - ste_live = true;
> > > + /*
> > > + * As kdump kernel copy STE table from previous
> > > + * kernel. It still may have valid stream table entries.
> > > + * Forcing entry as false to allow overwrite.
> > > + */
> > > + if (!is_kdump_kernel())
> > > + ste_live = true;
> > > break;
> > > case STRTAB_STE_0_CFG_ABORT:
> > > BUG_ON(!disable_bypass);
> > > @@ -3264,6 +3270,9 @@ static int arm_smmu_init_l1_strtab(struct arm_smmu_device *smmu)
> > > return -ENOMEM;
> > > }
> > >
> > > + if (is_kdump_kernel())
> > > + return 0;
> > > +
> > > for (i = 0; i < cfg->num_l1_ents; ++i) {
> > > arm_smmu_write_strtab_l1_desc(strtab, &cfg->l1_desc[i]);
> > > strtab += STRTAB_L1_DESC_DWORDS << 3;
> > > @@ -3272,6 +3281,23 @@ static int arm_smmu_init_l1_strtab(struct arm_smmu_device *smmu)
> > > return 0;
> > > }
> > >
> > > +static void arm_smmu_copy_table(struct arm_smmu_device *smmu,
> > > + struct arm_smmu_strtab_cfg *cfg, u32 size)
> > > +{
> > > + struct arm_smmu_strtab_cfg rdcfg;
> > > +
> > > + rdcfg.strtab_dma = readq_relaxed(smmu->base + ARM_SMMU_STRTAB_BASE);
> > > + rdcfg.strtab_base_cfg = readq_relaxed(smmu->base
> > > + + ARM_SMMU_STRTAB_BASE_CFG);
> > > +
> > > + rdcfg.strtab_dma &= STRTAB_BASE_ADDR_MASK;
> > > + rdcfg.strtab = memremap(rdcfg.strtab_dma, size, MEMREMAP_WB);
> > > +
> > > + memcpy_fromio(cfg->strtab, rdcfg.strtab, size);
> > > +
> > > + cfg->strtab_base_cfg = rdcfg.strtab_base_cfg;
> > > +}
> > > +
> > > static int arm_smmu_init_strtab_2lvl(struct arm_smmu_device *smmu)
> > > {
> > > void *strtab;
> > > @@ -3307,6 +3333,9 @@ static int arm_smmu_init_strtab_2lvl(struct arm_smmu_device *smmu)
> > > reg |= FIELD_PREP(STRTAB_BASE_CFG_SPLIT, STRTAB_SPLIT);
> > > cfg->strtab_base_cfg = reg;
> > >
> > > + if (is_kdump_kernel())
> > > + arm_smmu_copy_table(smmu, cfg, l1size);
> > > +
> > > return arm_smmu_init_l1_strtab(smmu);
> > > }
> > >
> > > @@ -3334,6 +3363,11 @@ static int arm_smmu_init_strtab_linear(struct arm_smmu_device *smmu)
> > > reg |= FIELD_PREP(STRTAB_BASE_CFG_LOG2SIZE, smmu->sid_bits);
> > > cfg->strtab_base_cfg = reg;
> > >
> > > + if (is_kdump_kernel()) {
> > > + arm_smmu_copy_table(smmu, cfg, size);
> > > + return 0;
> > > + }
> > > +
> > > arm_smmu_init_bypass_stes(strtab, cfg->num_l1_ents);
> > > return 0;
> > > }
> > > --
> > > 2.18.2
> > >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: dts: meson: add the gadget mode properties to the USB0 controller
From: Kevin Hilman @ 2020-05-19 23:11 UTC (permalink / raw)
To: linux-amlogic, Martin Blumenstingl; +Cc: linux-kernel, linux-arm-kernel
In-Reply-To: <20200504195105.2909711-1-martin.blumenstingl@googlemail.com>
On Mon, 4 May 2020 21:51:05 +0200, Martin Blumenstingl wrote:
> Testing with a USB RNDIS connection and iperf3 gives the following
> results:
> - From the host computer to the device at ~250Mbit/s
> - From the device to the host computer at ~76Mbit/s
Applied, thanks!
[1/1] ARM: dts: meson: add the gadget mode properties to the USB0 controller
commit: 9530dcf1082da23438ee557291c07d475128f63a
Best regards,
--
Kevin Hilman <khilman@baylibre.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/2] arm64: dts: meson-sm1: add thermal nodes
From: Kevin Hilman @ 2020-05-19 23:10 UTC (permalink / raw)
To: Neil Armstrong; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel
In-Reply-To: <20200512093916.19676-1-narmstrong@baylibre.com>
On Tue, 12 May 2020 11:39:14 +0200, Neil Armstrong wrote:
> SM1 Thermal is missing and broken since the G12A/G12B thermal enablement,
> fix this here by moving the g12b thermal nodes to meson-g12b.dtsi
> and adding the proper sm1 thermal nodes.
>
> Neil Armstrong (2):
> arm64: dts: meson-g12b: move G12B thermal nodes to meson-g12b.dtsi
> arm64: dts: meson-sm1: add cpu thermal nodes
>
> [...]
Applied, thanks!
[1/2] arm64: dts: meson-g12b: move G12B thermal nodes to meson-g12b.dtsi
commit: fef8ddfeaef8b7c91175e76bda7e4bd207b2d179
[2/2] arm64: dts: meson-sm1: add cpu thermal nodes
commit: 410763ffbf629eee72f0257501dd448f861e3693
Best regards,
--
Kevin Hilman <khilman@baylibre.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 0/4] meson-ee-pwrc: support for Meson8/8b/8m2 and GX
From: Kevin Hilman @ 2020-05-19 23:07 UTC (permalink / raw)
To: Martin Blumenstingl, linux-amlogic
Cc: devicetree, narmstrong, Martin Blumenstingl, linux-kernel,
robh+dt, linux-arm-kernel
In-Reply-To: <20200515204709.1505498-1-martin.blumenstingl@googlemail.com>
Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
> This series adds support for all "older" SoCs to the meson-ee-pwrc
> driver. I wanted to compare as much as I could between my Meson8b EC-100
> (Endless Mini) and the Le Potato board so I added support for GXBB, GXL
> and GXM as well as for the SoCs that I'm actually working on. I will
> send the ARM64 dts patches once all of this is reviewed and merged.
>
> I successfully tested the Meson8b part on EC-100 where u-boot does not
> initialize the VPU controller. So this the board where I have been
> struggling most.
>
> Kevin, I'm not sure if this can still make it into v5.8. If the
> series as a whole can't make it for some reason then I'd appreciate if
> patches #1 and #2 could end in v5.8 so I can push the .dts patches for
> v5.9.
Queuing for v5.8,
Thanks Martin!
Kevin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: sram: add documentation for reserved-only flag
From: Rob Herring @ 2020-05-19 23:03 UTC (permalink / raw)
To: Stephen Warren
Cc: devicetree, arnd, gregkh, Mian Yousaf Kaukab, linux-kernel,
jonathanh, talho, thierry.reding, linux-tegra, robin.murphy,
afaerber, linux-arm-kernel
In-Reply-To: <efcc6b5e-423c-8ae1-8a46-d6a06c1a1bab@wwwdotorg.org>
On Tue, May 19, 2020 at 10:16:43AM -0600, Stephen Warren wrote:
> On 5/13/20 4:41 AM, Mian Yousaf Kaukab wrote:
> > On Tue, May 12, 2020 at 01:45:28PM -0600, Stephen Warren wrote:
> >> On 5/12/20 8:48 AM, Mian Yousaf Kaukab wrote:
> >>> Add documentation for the new optional flag added for SRAM driver.
> >>
> >>> diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml
> >>
> >>> + reserved-only:
> >>> + description:
> >>> + The flag indicating, that only SRAM reserved regions have to be remapped.
> >>> + remapping type is selected depending upon no-memory-wc as usual.
> >>> + type: boolean
> >>
> >> This feels a bit like a SW flag rather than a HW description, so I'm not
> >> sure it's appropriate to put it into DT.
> >
> > Reserved regions themselves are software descriptions, no? Then we have 'pool'
> > flag which is again a software flag and so on. This flag falls into same
> > category and nothing out of ordinary.
>
> I suppose that's true to some extent. This is indeed a description of
> the system environment presented to the SW that consumes the DT, which
> is a bit more than pure HW description but still a description of
> something imposed externally rather than describing something that's up
> to the discretion of the consuming SW. So, go ahead.
>
> >> Are there any cases where the SW should map all of the SRAM, i.e. where
> >> we wouldn't expect to set reserved-only? [...]
> >
> > Yes, here are a few examples:
> > arch/arm/boot/dts/aspeed-g*.dtsi
> > arch/arm/boot/dts/at91*.dtsi
> > arch/arm/boot/dts/bcm7445.dtsi
> > Then arch/arm/boot/dts/dra7.dtsi is an example where we should map everything
> > except the reserved region.
> >
> >> [...] I'd expect reserved-only to be
> >> the default, and perhaps only, mode of operation for the SRAM driver.
> >
> > It will break compatibility with existing dtbs.
> >
> >> If we can't do that because some SW currently expects to be able to map
> >> arbitrary portions of the SRAM, shouldn't that SW be fixed to tell the
> >> SRAM driver which parts it's using, hence still allowing the driver to
> >> only map in-use portions?
> >
> > User doesn’t need sram driver in that case. It can use genalloc api directly.
>
> This sounds a bit odd. Without a driver for the reserved region, nothing
> should be touching it, since otherwise there's no code that owns an
> manages the region. If any code needs to consume the region, it should
> obtain info about the region from some form of provider code that can
> handle both the allocation and mapping. Anything else sounds like some
> consumer code directly making use of DT nodes it doesn't own. But since
> I'm not familiar enough with the SRAM driver and genalloc code that you
> mention to fully understand the allocation paths I guess I won't object
> for now, although it does still sound fishy.
I'm fine with the concept, but I don't think a single flag is adequate.
If there are reserved regions within the SRAM, then define child nodes
to mark those regions reserved. I don't think you need a new flag. Just
a 'reg' property and nothing else.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] mt76: mt7915: fix a handful of spelling mistakes
From: Colin King @ 2020-05-19 22:48 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Kalle Valo,
David S . Miller, Jakub Kicinski, Matthias Brugger,
linux-wireless, netdev, linux-arm-kernel, linux-mediatek
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
There are some spelling mistakes in some literal strings. Fix these.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/mediatek/mt76/mt7915/debugfs.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7915/debugfs.c b/drivers/net/wireless/mediatek/mt76/mt7915/debugfs.c
index ee0066fedd04..5278bee812f1 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7915/debugfs.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7915/debugfs.c
@@ -173,14 +173,14 @@ mt7915_txbf_stat_read_phy(struct mt7915_phy *phy, struct seq_file *s)
/* Tx Beamformee Rx NDPA & Tx feedback report */
cnt = mt76_rr(dev, MT_ETBF_TX_NDP_BFRP(ext_phy));
- seq_printf(s, "Tx Beamformee sucessful feedback frames: %ld\n",
+ seq_printf(s, "Tx Beamformee successful feedback frames: %ld\n",
FIELD_GET(MT_ETBF_TX_FB_CPL, cnt));
- seq_printf(s, "Tx Beamformee feedback triggerd counts: %ld\n",
+ seq_printf(s, "Tx Beamformee feedback triggered counts: %ld\n",
FIELD_GET(MT_ETBF_TX_FB_TRI, cnt));
/* Tx SU counters */
cnt = mt76_rr(dev, MT_MIB_DR11(ext_phy));
- seq_printf(s, "Tx single-user sucessful MPDU counts: %d\n", cnt);
+ seq_printf(s, "Tx single-user successful MPDU counts: %d\n", cnt);
seq_puts(s, "\n");
}
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 01/11] genirq: Add fasteoi IPI flow
From: Valentin Schneider @ 2020-05-19 22:29 UTC (permalink / raw)
To: Marc Zyngier
Cc: Sumit Garg, kernel-team, Russell King, Jason Cooper,
Catalin Marinas, linux-kernel, Thomas Gleixner, Will Deacon,
linux-arm-kernel
In-Reply-To: <jhj8shnr28o.mognet@arm.com>
On 19/05/20 23:25, Valentin Schneider wrote:
> Tied to the following patch, does that want something like
>
> + if (!irq_settings_is_no_accounting(desc))
> + __kstat_incr_irqs_this_cpu(desc);
> +
And ofc after updating my inbox I see this has already been suggested, oh
well.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 01/11] genirq: Add fasteoi IPI flow
From: Valentin Schneider @ 2020-05-19 22:25 UTC (permalink / raw)
To: Marc Zyngier
Cc: Sumit Garg, kernel-team, Russell King, Jason Cooper,
Catalin Marinas, linux-kernel, Thomas Gleixner, Will Deacon,
linux-arm-kernel
In-Reply-To: <20200519161755.209565-2-maz@kernel.org>
On 19/05/20 17:17, Marc Zyngier wrote:
> For irqchips using the fasteoi flow, IPIs are a bit special.
>
> They need to be EOId early (before calling the handler), as
> funny things may happen in the handler (they do not necessarily
> behave like a normal interrupt), and that the arch code is
> already handling the stats.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> include/linux/irq.h | 1 +
> kernel/irq/chip.c | 26 ++++++++++++++++++++++++++
> 2 files changed, 27 insertions(+)
>
> diff --git a/include/linux/irq.h b/include/linux/irq.h
> index 8d5bc2c237d7..726f94d8b8cc 100644
> --- a/include/linux/irq.h
> +++ b/include/linux/irq.h
> @@ -621,6 +621,7 @@ static inline int irq_set_parent(int irq, int parent_irq)
> */
> extern void handle_level_irq(struct irq_desc *desc);
> extern void handle_fasteoi_irq(struct irq_desc *desc);
> +extern void handle_percpu_devid_fasteoi_ipi(struct irq_desc *desc);
> extern void handle_edge_irq(struct irq_desc *desc);
> extern void handle_edge_eoi_irq(struct irq_desc *desc);
> extern void handle_simple_irq(struct irq_desc *desc);
> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
> index 41e7e37a0928..7b0b789cfed4 100644
> --- a/kernel/irq/chip.c
> +++ b/kernel/irq/chip.c
> @@ -955,6 +955,32 @@ void handle_percpu_devid_irq(struct irq_desc *desc)
> chip->irq_eoi(&desc->irq_data);
> }
>
> +/**
> + * handle_percpu_devid_fasteoi_ipi - Per CPU local IPI handler with per cpu
> + * dev ids
> + * @desc: the interrupt description structure for this irq
> + *
> + * The biggest differences with the IRQ version are that:
> + * - the interrupt is EOIed early, as the IPI could result in a context
> + * switch, and we need to make sure the IPI can fire again
> + * - Stats are usually handled at the architecture level, so we ignore them
> + * here
> + */
> +void handle_percpu_devid_fasteoi_ipi(struct irq_desc *desc)
> +{
> + struct irq_chip *chip = irq_desc_get_chip(desc);
> + struct irqaction *action = desc->action;
> + unsigned int irq = irq_desc_get_irq(desc);
> + irqreturn_t res;
> +
Tied to the following patch, does that want something like
+ if (!irq_settings_is_no_accounting(desc))
+ __kstat_incr_irqs_this_cpu(desc);
+
While I'm at it, now that we would have IPIs as 'normal' interrupts, what
prevents us from getting rid of the arch-side accounting? Is it just that
we are keeping it as long as handle_IPI() lives, or are there more hurdles
hidden around?
> + if (chip->irq_eoi)
> + chip->irq_eoi(&desc->irq_data);
> +
> + trace_irq_handler_entry(irq, action);
> + res = action->handler(irq, raw_cpu_ptr(action->percpu_dev_id));
> + trace_irq_handler_exit(irq, action, res);
> +}
> +
> /**
> * handle_percpu_devid_fasteoi_nmi - Per CPU local NMI handler with per cpu
> * dev ids
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 00/11] arm/arm64: Turning IPIs into normal interrupts
From: Valentin Schneider @ 2020-05-19 22:25 UTC (permalink / raw)
To: Marc Zyngier
Cc: Sumit Garg, kernel-team, Russell King, Jason Cooper,
Catalin Marinas, linux-kernel, Thomas Gleixner, Will Deacon,
linux-arm-kernel
In-Reply-To: <20200519161755.209565-1-maz@kernel.org>
Hi Marc,
On 19/05/20 17:17, Marc Zyngier wrote:
>
> This has been tested on a bunch of 32 and 64bit guests.
>
I gave this a brief spin on Juno and on HiKey960, nothing to report there.
FWIW I'd like to stare a bit at the rest; I already have a rookie question
on the accounting, but the rest will be for after I get some sleep, and
maybe even a mug of coffee :-)
> Marc Zyngier (11):
> genirq: Add fasteoi IPI flow
> genirq: Allow interrupts to be excluded from /proc/interrupts
> arm64: Allow IPIs to be handled as normal interrupts
> ARM: Allow IPIs to be handled as normal interrupts
> irqchip/gic-v3: Describe the SGI range
> irqchip/gic-v3: Configure SGIs as standard interrupts
> irqchip/gic: Refactor SMP configuration
> irqchip/gic: Configure SGIs as standard interrupts
> irqchip/gic-common: Don't enable SGIs by default
> irqchip/bcm2836: Configure mailbox interrupts as standard interrupts
> arm64: Kill __smp_cross_call and co
>
> arch/arm/Kconfig | 1 +
> arch/arm/include/asm/smp.h | 5 +
> arch/arm/kernel/smp.c | 97 +++++++++++---
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/irq_work.h | 4 +-
> arch/arm64/include/asm/smp.h | 6 +-
> arch/arm64/kernel/smp.c | 98 +++++++++++----
> drivers/irqchip/irq-bcm2836.c | 151 ++++++++++++++++++----
> drivers/irqchip/irq-gic-common.c | 3 -
> drivers/irqchip/irq-gic-v3.c | 109 ++++++++++------
> drivers/irqchip/irq-gic.c | 203 ++++++++++++++++++------------
> include/linux/irq.h | 4 +-
> kernel/irq/chip.c | 26 ++++
> kernel/irq/debugfs.c | 1 +
> kernel/irq/proc.c | 2 +-
> kernel/irq/settings.h | 7 ++
> 16 files changed, 515 insertions(+), 203 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 04/11] ARM: Allow IPIs to be handled as normal interrupts
From: Russell King - ARM Linux admin @ 2020-05-19 22:24 UTC (permalink / raw)
To: Marc Zyngier
Cc: Sumit Garg, kernel-team, Jason Cooper, Catalin Marinas,
linux-kernel, Thomas Gleixner, Will Deacon, linux-arm-kernel
In-Reply-To: <20200519161755.209565-5-maz@kernel.org>
On Tue, May 19, 2020 at 05:17:48PM +0100, Marc Zyngier wrote:
> In order to deal with IPIs as normal interrupts, let's add
> a new way to register them with the architecture code.
>
> set_smp_ipi_range() takes a range of interrupts, and allows
> the arch code to request them as if the were normal interrupts.
> A standard handler is then called by the core IRQ code to deal
> with the IPI.
>
> This means that we don't need to call irq_enter/irq_exit, and
> that we don't need to deal with set_irq_regs either. So let's
> move the dispatcher into its own function, and leave handle_IPI()
> as a compatibility function.
>
> On the sending side, let's make use of ipi_send_mask, which
> already exists for this purpose.
You say nothing about the nesting of irq_enter() and irq_exit()
for scheduler_ipi().
Given that lockdep introduced the requirement that hard IRQs can't
be nested, are we sure that calling irq_exit() twice is safe?
Looking at irqtime_account_irq(), it seems that will cause double-
accounting of in-interrupt time, since we will increment
irq_start_time by just over twice the the period spent handling
the IPI.
I think the rest of irq_exit() should be safe, but still, this
behaviour should be documented at the very least, if not avoided.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> arch/arm/Kconfig | 1 +
> arch/arm/include/asm/smp.h | 5 ++
> arch/arm/kernel/smp.c | 97 ++++++++++++++++++++++++++++++++------
> 3 files changed, 88 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index c77c93c485a0..0caaba9bf880 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -48,6 +48,7 @@ config ARM
> select GENERIC_ARCH_TOPOLOGY if ARM_CPU_TOPOLOGY
> select GENERIC_ATOMIC64 if CPU_V7M || CPU_V6 || !CPU_32v6K || !AEABI
> select GENERIC_CLOCKEVENTS_BROADCAST if SMP
> + select GENERIC_IRQ_IPI if SMP
> select GENERIC_CPU_AUTOPROBE
> select GENERIC_EARLY_IOREMAP
> select GENERIC_IDLE_POLL_SETUP
> diff --git a/arch/arm/include/asm/smp.h b/arch/arm/include/asm/smp.h
> index a91f21e3c5b5..0e29730295ca 100644
> --- a/arch/arm/include/asm/smp.h
> +++ b/arch/arm/include/asm/smp.h
> @@ -45,6 +45,11 @@ extern void smp_init_cpus(void);
> */
> extern void set_smp_cross_call(void (*)(const struct cpumask *, unsigned int));
>
> +/*
> + * Register IPI interrupts with the arch SMP code
> + */
> +extern void set_smp_ipi_range(int ipi_base, int nr_ipi);
> +
> /*
> * Called from platform specific assembly code, this is the
> * secondary CPU entry point.
> diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
> index 46e1be9e57a8..618641978a5b 100644
> --- a/arch/arm/kernel/smp.c
> +++ b/arch/arm/kernel/smp.c
> @@ -79,10 +79,19 @@ enum ipi_msg_type {
> */
> };
>
> +static int ipi_irq_base;
> +static int nr_ipi = NR_IPI;
> +static struct irq_desc *ipi_desc[NR_IPI];
> +
> +static void ipi_setup(int cpu);
> +static void ipi_teardown(int cpu);
> +
> static DECLARE_COMPLETION(cpu_running);
>
> static struct smp_operations smp_ops __ro_after_init;
>
> +static void ipi_setup(int cpu);
> +
> void __init smp_set_ops(const struct smp_operations *ops)
> {
> if (ops)
> @@ -308,6 +317,8 @@ void arch_cpu_idle_dead(void)
>
> local_irq_disable();
>
> + ipi_teardown(cpu);
> +
> /*
> * Flush the data out of the L1 cache for this CPU. This must be
> * before the completion to ensure that data is safely written out
> @@ -424,6 +435,8 @@ asmlinkage void secondary_start_kernel(void)
>
> notify_cpu_starting(cpu);
>
> + ipi_setup(cpu);
> +
> calibrate_delay();
>
> smp_store_cpu_info(cpu);
> @@ -629,10 +642,9 @@ asmlinkage void __exception_irq_entry do_IPI(int ipinr, struct pt_regs *regs)
> handle_IPI(ipinr, regs);
> }
>
> -void handle_IPI(int ipinr, struct pt_regs *regs)
> +static void do_handle_IPI(int ipinr)
> {
> unsigned int cpu = smp_processor_id();
> - struct pt_regs *old_regs = set_irq_regs(regs);
>
> if ((unsigned)ipinr < NR_IPI) {
> trace_ipi_entry_rcuidle(ipi_types[ipinr]);
> @@ -645,9 +657,7 @@ void handle_IPI(int ipinr, struct pt_regs *regs)
>
> #ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
> case IPI_TIMER:
> - irq_enter();
> tick_receive_broadcast();
> - irq_exit();
> break;
> #endif
>
> @@ -656,36 +666,26 @@ void handle_IPI(int ipinr, struct pt_regs *regs)
> break;
>
> case IPI_CALL_FUNC:
> - irq_enter();
> generic_smp_call_function_interrupt();
> - irq_exit();
> break;
>
> case IPI_CPU_STOP:
> - irq_enter();
> ipi_cpu_stop(cpu);
> - irq_exit();
> break;
>
> #ifdef CONFIG_IRQ_WORK
> case IPI_IRQ_WORK:
> - irq_enter();
> irq_work_run();
> - irq_exit();
> break;
> #endif
>
> case IPI_COMPLETION:
> - irq_enter();
> ipi_complete(cpu);
> - irq_exit();
> break;
>
> case IPI_CPU_BACKTRACE:
> printk_nmi_enter();
> - irq_enter();
> - nmi_cpu_backtrace(regs);
> - irq_exit();
> + nmi_cpu_backtrace(get_irq_regs());
> printk_nmi_exit();
> break;
>
> @@ -697,9 +697,76 @@ void handle_IPI(int ipinr, struct pt_regs *regs)
>
> if ((unsigned)ipinr < NR_IPI)
> trace_ipi_exit_rcuidle(ipi_types[ipinr]);
> +}
> +
> +/* Legacy version, should go away once all irqchips have been converted */
> +void handle_IPI(int ipinr, struct pt_regs *regs)
> +{
> + struct pt_regs *old_regs = set_irq_regs(regs);
> +
> + irq_enter();
> + do_handle_IPI(ipinr);
> + irq_exit();
> +
> set_irq_regs(old_regs);
> }
>
> +static irqreturn_t ipi_handler(int irq, void *data)
> +{
> + do_handle_IPI(irq - ipi_irq_base);
> + return IRQ_HANDLED;
> +}
> +
> +static void ipi_send(const struct cpumask *target, unsigned int ipi)
> +{
> + __ipi_send_mask(ipi_desc[ipi], target);
> +}
> +
> +static void ipi_setup(int cpu)
> +{
> + if (ipi_irq_base) {
> + int i;
> +
> + for (i = 0; i < nr_ipi; i++)
> + enable_percpu_irq(ipi_irq_base + i, 0);
> + }
> +}
> +
> +static void ipi_teardown(int cpu)
> +{
> + if (ipi_irq_base) {
> + int i;
> +
> + for (i = 0; i < nr_ipi; i++)
> + disable_percpu_irq(ipi_irq_base + i);
> + }
> +}
> +
> +void __init set_smp_ipi_range(int ipi_base, int n)
> +{
> + int i;
> +
> + WARN_ON(n < NR_IPI);
> + nr_ipi = min(n, NR_IPI);
> +
> + for (i = 0; i < nr_ipi; i++) {
> + int err;
> +
> + err = request_percpu_irq(ipi_base + i, ipi_handler,
> + "IPI", &irq_stat);
> + WARN_ON(err);
> +
> + ipi_desc[i] = irq_to_desc(ipi_base + i);
> + irq_set_status_flags(ipi_base + i, IRQ_NO_ACCOUNTING);
> + }
> +
> + ipi_irq_base = ipi_base;
> + set_smp_cross_call(ipi_send);
> +
> + /* Setup the boot CPU immediately */
> + ipi_setup(smp_processor_id());
> +}
> +
> void smp_send_reschedule(int cpu)
> {
> smp_cross_call(cpumask_of(cpu), IPI_RESCHEDULE);
> --
> 2.26.2
>
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1] usb: musb: dsps: set MUSB_DA8XX quirk for AM335x
From: Bin Liu @ 2020-05-19 22:18 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Michael Grzeschik, fercerpav, Greg Kroah-Hartman, linux-usb,
linux-kernel, russell, Pengutronix Kernel Team, linux-arm-kernel
In-Reply-To: <20200327053849.5348-1-o.rempel@pengutronix.de>
Hi,
On Fri, Mar 27, 2020 at 06:38:49AM +0100, Oleksij Rempel wrote:
> Beagle Bone Black has different memory corruptions if kernel is
> configured with USB_TI_CPPI41_DMA=y. This issue is reproducible with
> ath9k-htc driver (ar9271 based wifi usb controller):
>
> root@AccessBox:~ iw dev wlan0 set monitor fcsfail otherbss
> root@AccessBox:~ ip l s dev wlan0 up
> kmemleak: Cannot insert 0xda577e40 into the object search tree (overlaps existing)
> CPU: 0 PID: 176 Comm: ip Not tainted 5.5.0 #7
> Hardware name: Generic AM33XX (Flattened Device Tree)
> [<c0112c14>] (unwind_backtrace) from [<c010dc98>] (show_stack+0x18/0x1c)
> [<c010dc98>] (show_stack) from [<c08c7c2c>] (dump_stack+0x84/0x98)
> [<c08c7c2c>] (dump_stack) from [<c02c75a8>] (create_object+0x2f8/0x324)
> [<c02c75a8>] (create_object) from [<c02b8928>] (kmem_cache_alloc+0x1a8/0x39c)
> [<c02b8928>] (kmem_cache_alloc) from [<c072fb68>] (__alloc_skb+0x60/0x174)
> [<c072fb68>] (__alloc_skb) from [<bf0c5c58>] (ath9k_wmi_cmd+0x50/0x184 [ath9k_htc])
> [<bf0c5c58>] (ath9k_wmi_cmd [ath9k_htc]) from [<bf0cb410>] (ath9k_regwrite_multi+0x54/0x84 [ath9k_htc])
> [<bf0cb410>] (ath9k_regwrite_multi [ath9k_htc]) from [<bf0cb7fc>] (ath9k_regwrite+0xf0/0xfc [ath9k_htc])
> [<bf0cb7fc>] (ath9k_regwrite [ath9k_htc]) from [<bf1aca78>] (ar5008_hw_process_ini+0x280/0x6c0 [ath9k_hw])
> [<bf1aca78>] (ar5008_hw_process_ini [ath9k_hw]) from [<bf1a66ac>] (ath9k_hw_reset+0x270/0x1458 [ath9k_hw])
> [<bf1a66ac>] (ath9k_hw_reset [ath9k_hw]) from [<bf0c9588>] (ath9k_htc_start+0xb0/0x22c [ath9k_htc])
> [<bf0c9588>] (ath9k_htc_start [ath9k_htc]) from [<bf0eb3c0>] (drv_start+0x4c/0x1e8 [mac80211])
> [<bf0eb3c0>] (drv_start [mac80211]) from [<bf104a84>] (ieee80211_do_open+0x480/0x954 [mac80211])
> [<bf104a84>] (ieee80211_do_open [mac80211]) from [<c075127c>] (__dev_open+0xdc/0x160)
> [<c075127c>] (__dev_open) from [<c07516a8>] (__dev_change_flags+0x1a4/0x204)
> [<c07516a8>] (__dev_change_flags) from [<c0751728>] (dev_change_flags+0x20/0x50)
> [<c0751728>] (dev_change_flags) from [<c076971c>] (do_setlink+0x2ac/0x978)
>
> After applying this patch, the system is running in monitor mode without
> noticeable issues.
>
> Suggested-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> ---
> drivers/usb/musb/musb_dsps.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
> index 88923175f71e..c01f9e9e69f5 100644
> --- a/drivers/usb/musb/musb_dsps.c
> +++ b/drivers/usb/musb/musb_dsps.c
> @@ -690,7 +690,7 @@ static void dsps_dma_controller_resume(struct dsps_glue *glue) {}
> #endif /* CONFIG_USB_TI_CPPI41_DMA */
>
> static struct musb_platform_ops dsps_ops = {
> - .quirks = MUSB_DMA_CPPI41 | MUSB_INDEXED_EP,
> + .quirks = MUSB_DMA_CPPI41 | MUSB_INDEXED_EP | MUSB_DA8XX,
The MUSB_DA8XX flag cannot be simply applied to MUSB_DSPS, at least the
teardown and autoreq register offsets are different as show in
cppi41_dma_controller_create().
Do you understand what exactly caused the issue? The kernel trace above
doesn't provide enuough information.
-Bin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: pass -msoft-float to gcc earlier
From: Arnd Bergmann @ 2020-05-19 22:08 UTC (permalink / raw)
To: Russell King
Cc: Arnd Bergmann, Szabolcs Nagy, Linus Walleij, Nick Desaulniers,
linux-kernel, Masahiro Yamada, linux-arm-kernel
Szabolcs Nagy ran into a kernel build failure with a custom gcc
toochain that sets -mfpu=auto -mfloat-abi=hard:
/tmp/ccmNdcdf.s:1898: Error: selected processor does not support `cpsid i' in ARM mode
The problem is that $(call cc-option, -march=armv7-a) fails before the
kernel overrides the gcc options to also pass -msoft-float.
Move the option to the beginning the Makefile, before we call
cc-option for the first time.
Reported-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87302
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/Makefile | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 7d5cd0f85461..e428ea6eb0fa 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -16,6 +16,8 @@ LDFLAGS_vmlinux += --be8
KBUILD_LDFLAGS_MODULE += --be8
endif
+KBUILD_CFLAGS += -msoft-float
+
ifeq ($(CONFIG_ARM_MODULE_PLTS),y)
KBUILD_LDS_MODULE += $(srctree)/arch/arm/kernel/module.lds
endif
@@ -135,7 +137,7 @@ AFLAGS_ISA :=$(CFLAGS_ISA)
endif
# Need -Uarm for gcc < 3.x
-KBUILD_CFLAGS +=$(CFLAGS_ABI) $(CFLAGS_ISA) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -msoft-float -Uarm
+KBUILD_CFLAGS +=$(CFLAGS_ABI) $(CFLAGS_ISA) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -Uarm
KBUILD_AFLAGS +=$(CFLAGS_ABI) $(AFLAGS_ISA) $(arch-y) $(tune-y) -include asm/unified.h -msoft-float
CHECKFLAGS += -D__arm__
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
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