* [PATCH 1/2] KVM: arm/arm64: vgic: Use the appropriate TRACE_INCLUDE_PATH
From: Zenghui Yu @ 2019-09-11 2:33 UTC (permalink / raw)
To: maz, james.morse, julien.thierry.kdev, suzuki.poulose
Cc: linux-kernel, Masahiro Yamada, Zenghui Yu, wanghaibin.wang,
kvmarm, linux-arm-kernel
In-Reply-To: <1568169216-12632-1-git-send-email-yuzenghui@huawei.com>
Commit 49dfe94fe5ad ("KVM: arm/arm64: Fix TRACE_INCLUDE_PATH") fixes
TRACE_INCLUDE_PATH to the correct relative path to the define_trace.h
and explains why did the old one work.
The same fix should be applied to virt/kvm/arm/vgic/trace.h.
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
---
virt/kvm/arm/vgic/trace.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/virt/kvm/arm/vgic/trace.h b/virt/kvm/arm/vgic/trace.h
index 55fed77a9f73..4fd4f6db181b 100644
--- a/virt/kvm/arm/vgic/trace.h
+++ b/virt/kvm/arm/vgic/trace.h
@@ -30,7 +30,7 @@ TRACE_EVENT(vgic_update_irq_pending,
#endif /* _TRACE_VGIC_H */
#undef TRACE_INCLUDE_PATH
-#define TRACE_INCLUDE_PATH ../../../virt/kvm/arm/vgic
+#define TRACE_INCLUDE_PATH ../../virt/kvm/arm/vgic
#undef TRACE_INCLUDE_FILE
#define TRACE_INCLUDE_FILE trace
--
2.19.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 v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
From: Jassi Brar @ 2019-09-11 2:36 UTC (permalink / raw)
To: Andre Przywara
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, Peng Fan,
f.fainelli@gmail.com, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, dl-linux-imx, sudeep.holla@arm.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190909143230.48b1143f@donnerap.cambridge.arm.com>
On Mon, Sep 9, 2019 at 8:32 AM Andre Przywara <andre.przywara@arm.com> wrote:
>
> On Fri, 30 Aug 2019 03:12:29 -0500
> Jassi Brar <jassisinghbrar@gmail.com> wrote:
>
> Hi,
>
> > On Fri, Aug 30, 2019 at 3:07 AM Peng Fan <peng.fan@nxp.com> wrote:
> > >
> > > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM
> > > > SMC/HVC mailbox
> > > >
> > > > On Fri, Aug 30, 2019 at 2:37 AM Peng Fan <peng.fan@nxp.com> wrote:
> > > > >
> > > > > Hi Jassi,
> > > > >
> > > > > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc
> > > > > > for the ARM SMC/HVC mailbox
> > > > > >
> > > > > > On Fri, Aug 30, 2019 at 1:28 AM Peng Fan <peng.fan@nxp.com> wrote:
> > > > > >
> > > > > > > > > +examples:
> > > > > > > > > + - |
> > > > > > > > > + sram@910000 {
> > > > > > > > > + compatible = "mmio-sram";
> > > > > > > > > + reg = <0x0 0x93f000 0x0 0x1000>;
> > > > > > > > > + #address-cells = <1>;
> > > > > > > > > + #size-cells = <1>;
> > > > > > > > > + ranges = <0 0x0 0x93f000 0x1000>;
> > > > > > > > > +
> > > > > > > > > + cpu_scp_lpri: scp-shmem@0 {
> > > > > > > > > + compatible = "arm,scmi-shmem";
> > > > > > > > > + reg = <0x0 0x200>;
> > > > > > > > > + };
> > > > > > > > > +
> > > > > > > > > + cpu_scp_hpri: scp-shmem@200 {
> > > > > > > > > + compatible = "arm,scmi-shmem";
> > > > > > > > > + reg = <0x200 0x200>;
> > > > > > > > > + };
> > > > > > > > > + };
> > > > > > > > > +
> > > > > > > > > + firmware {
> > > > > > > > > + smc_mbox: mailbox {
> > > > > > > > > + #mbox-cells = <1>;
> > > > > > > > > + compatible = "arm,smc-mbox";
> > > > > > > > > + method = "smc";
> > > > > > > > > + arm,num-chans = <0x2>;
> > > > > > > > > + transports = "mem";
> > > > > > > > > + /* Optional */
> > > > > > > > > + arm,func-ids = <0xc20000fe>, <0xc20000ff>;
> > > > > > > > >
> > > > > > > > SMC/HVC is synchronously(block) running in "secure mode", i.e,
> > > > > > > > there can only be one instance running platform wide. Right?
> > > > > > >
> > > > > > > I think there could be channel for TEE, and channel for Linux.
> > > > > > > For virtualization case, there could be dedicated channel for each VM.
> > > > > > >
> > > > > > I am talking from Linux pov. Functions 0xfe and 0xff above, can't
> > > > > > both be active at the same time, right?
> > > > >
> > > > > If I get your point correctly,
> > > > > On UP, both could not be active. On SMP, tx/rx could be both active,
> > > > > anyway this depends on secure firmware and Linux firmware design.
> > > > >
> > > > > Do you have any suggestions about arm,func-ids here?
> > > > >
> > > > I was thinking if this is just an instruction, why can't each channel be
> > > > represented as a controller, i.e, have exactly one func-id per controller node.
> > > > Define as many controllers as you need channels ?
> > >
> > > I am ok, this could make driver code simpler. Something as below?
> > >
> > > smc_tx_mbox: tx_mbox {
> > > #mbox-cells = <0>;
> > > compatible = "arm,smc-mbox";
> > > method = "smc";
> > > transports = "mem";
> > > arm,func-id = <0xc20000fe>;
> > > };
> > >
> > > smc_rx_mbox: rx_mbox {
> > > #mbox-cells = <0>;
> > > compatible = "arm,smc-mbox";
> > > method = "smc";
> > > transports = "mem";
> > > arm,func-id = <0xc20000ff>;
> > > };
> > >
> > > firmware {
> > > scmi {
> > > compatible = "arm,scmi";
> > > mboxes = <&smc_tx_mbox>, <&smc_rx_mbox 1>;
> > > mbox-names = "tx", "rx";
> > > shmem = <&cpu_scp_lpri>, <&cpu_scp_hpri>;
> > > };
> > > };
> > >
> > Yes, the channel part is good.
> > But I am not convinced by the need to have SCMI specific "transport" mode.
>
> Why would this be SCMI specific and what is the problem with having this property?
> By the very nature of the SMC/HVC call you would expect to also pass parameters in registers.
> However this limits the amount of data you can push, so the option of reverting to a
> memory based payload sounds very reasonable.
>
Of course, it is very legit to pass data via mem and many platforms do
that. But as you note in your next post, the 'transport' doesn't seem
necessary doing what it does in the driver.
Cheers!
_______________________________________________
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 v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
From: Jassi Brar @ 2019-09-11 2:44 UTC (permalink / raw)
To: Andre Przywara
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, Peng Fan,
f.fainelli@gmail.com, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, dl-linux-imx, sudeep.holla@arm.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190909164208.6605054e@donnerap.cambridge.arm.com>
On Mon, Sep 9, 2019 at 10:42 AM Andre Przywara <andre.przywara@arm.com> wrote:
>
> On Wed, 28 Aug 2019 03:02:58 +0000
> Peng Fan <peng.fan@nxp.com> wrote:
>
> Hi,
>
> sorry for the late reply, eventually managed to have a closer look on this.
>
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > The ARM SMC/HVC mailbox binding describes a firmware interface to trigger
> > actions in software layers running in the EL2 or EL3 exception levels.
> > The term "ARM" here relates to the SMC instruction as part of the ARM
> > instruction set, not as a standard endorsed by ARM Ltd.
> >
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > ---
> > .../devicetree/bindings/mailbox/arm-smc.yaml | 125 +++++++++++++++++++++
> > 1 file changed, 125 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > new file mode 100644
> > index 000000000000..f8eb28d5e307
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > @@ -0,0 +1,125 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: ARM SMC Mailbox Interface
> > +
> > +maintainers:
> > + - Peng Fan <peng.fan@nxp.com>
> > +
> > +description: |
> > + This mailbox uses the ARM smc (secure monitor call) and hvc (hypervisor
> > + call) instruction to trigger a mailbox-connected activity in firmware,
> > + executing on the very same core as the caller. By nature this operation
> > + is synchronous and this mailbox provides no way for asynchronous messages
> > + to be delivered the other way round, from firmware to the OS, but
> > + asynchronous notification could also be supported. However the value of
> > + r0/w0/x0 the firmware returns after the smc call is delivered as a received
> > + message to the mailbox framework, so a synchronous communication can be
> > + established, for a asynchronous notification, no value will be returned.
> > + The exact meaning of both the action the mailbox triggers as well as the
> > + return value is defined by their users and is not subject to this binding.
> > +
> > + One use case of this mailbox is the SCMI interface, which uses shared memory
> > + to transfer commands and parameters, and a mailbox to trigger a function
> > + call. This allows SoCs without a separate management processor (or when
> > + such a processor is not available or used) to use this standardized
> > + interface anyway.
> > +
> > + This binding describes no hardware, but establishes a firmware interface.
> > + Upon receiving an SMC using one of the described SMC function identifiers,
> > + the firmware is expected to trigger some mailbox connected functionality.
> > + The communication follows the ARM SMC calling convention.
> > + Firmware expects an SMC function identifier in r0 or w0. The supported
> > + identifiers are passed from consumers, or listed in the the arm,func-ids
> > + properties as described below. The firmware can return one value in
> > + the first SMC result register, it is expected to be an error value,
> > + which shall be propagated to the mailbox client.
> > +
> > + Any core which supports the SMC or HVC instruction can be used, as long as
> > + a firmware component running in EL3 or EL2 is handling these calls.
> > +
> > +properties:
> > + compatible:
> > + const: arm,smc-mbox
> > +
> > + "#mbox-cells":
> > + const: 1
> > +
> > + arm,num-chans:
> > + description: The number of channels supported.
> > + items:
> > + minimum: 1
> > + maximum: 4096 # Should be enough?
>
> This maximum sounds rather arbitrary. Why do we need one? In the driver this just allocates more memory, so why not just impose no artificial limit at all?
>
This will be gone, once the driver is converted to 1channel per controller.
> Actually, do we need this property at all? Can't we just rely on the size of arm,func-ids to determine this (using of_property_count_elems_of_size() in the driver)? Having both sounds redundant and brings up the question what to do if they don't match.
>
> > +
> > + method:
> > + - enum:
> > + - smc
> > + - hvc
> > +
> > + transports:
> > + - enum:
> > + - mem
> > + - reg
>
> Shouldn't there be a description on what both mean, exactly?
> For instance I would expect a list of registers to be shown for the "reg" case, and be it by referring to the ARM SMCCC.
>
> Also looking at the driver this brings up more questions:
> - Which memory does mem refer to? If this is really the means of transport, it should be referenced in this *controller* node and populated by the driver. Looking at the example below and the driver code, it actually isn't used that way, instead the memory is used and controlled by the mailbox *client*.
> - What is the actual difference between the two transports? For "mem" we just populate the registers with 0, for "reg" we use the data. Couldn't this be left to the client?
>
> There are more points which makes me think this property is actually redundant, see my comments on patch 2/2.
>
> > +
> > + arm,func-ids:
> > + description: |
> > + An array of 32-bit values specifying the function IDs used by each
> > + mailbox channel. Those function IDs follow the ARM SMC calling
> > + convention standard [1].
> > +
> > + There is one identifier per channel and the number of supported
> > + channels is determined by the length of this array.
>
> I think this makes it obvious that arm,num-chans is not needed.
>
> Also this somewhat contradicts the driver implementation, which allows the array to be shorter, marking this as UINT_MAX and later on using the first data item as a function identifier. This is somewhat surprising and not documented (unless I missed something).
>
> So I would suggest:
> - We drop the transports property, and always put the client provided data in the registers, according to the SMCCC. Document this here.
> A client not needing those could always puts zeros (or garbage) in there, the respective firmware would just ignore the registers.
> - We drop "arm,num-chans", as this is just redundant with the length of the func-ids array.
> - We don't impose an arbitrary limit on the number of channels. From the firmware point of view this is just different function IDs, from Linux' point of view just the size of the memory used. Both don't need to be limited artificially IMHO.
>
Sounds like we are in sync.
> - We mark arm,func-ids as required, as this needs to be fixed, allocated number.
>
I still think func-id can be done without. A client can always pass
the value as it knows what it expects. But I can live with it being
optional.
cheers!
_______________________________________________
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 1/2] KVM: arm/arm64: vgic: Use the appropriate TRACE_INCLUDE_PATH
From: Masahiro Yamada @ 2019-09-11 4:26 UTC (permalink / raw)
To: Zenghui Yu
Cc: suzuki.poulose, maz, Linux Kernel Mailing List, James Morse,
julien.thierry.kdev, wanghaibin.wang, kvmarm, linux-arm-kernel
In-Reply-To: <1568169216-12632-2-git-send-email-yuzenghui@huawei.com>
On Wed, Sep 11, 2019 at 11:35 AM Zenghui Yu <yuzenghui@huawei.com> wrote:
>
> Commit 49dfe94fe5ad ("KVM: arm/arm64: Fix TRACE_INCLUDE_PATH") fixes
> TRACE_INCLUDE_PATH to the correct relative path to the define_trace.h
> and explains why did the old one work.
>
> The same fix should be applied to virt/kvm/arm/vgic/trace.h.
>
> Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Please feel free to replace the Cc: with my:
Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Thanks.
> Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
> ---
> virt/kvm/arm/vgic/trace.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/virt/kvm/arm/vgic/trace.h b/virt/kvm/arm/vgic/trace.h
> index 55fed77a9f73..4fd4f6db181b 100644
> --- a/virt/kvm/arm/vgic/trace.h
> +++ b/virt/kvm/arm/vgic/trace.h
> @@ -30,7 +30,7 @@ TRACE_EVENT(vgic_update_irq_pending,
> #endif /* _TRACE_VGIC_H */
>
> #undef TRACE_INCLUDE_PATH
> -#define TRACE_INCLUDE_PATH ../../../virt/kvm/arm/vgic
> +#define TRACE_INCLUDE_PATH ../../virt/kvm/arm/vgic
> #undef TRACE_INCLUDE_FILE
> #define TRACE_INCLUDE_FILE trace
>
> --
> 2.19.1
>
>
--
Best Regards
Masahiro Yamada
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RFC 1/4] dt-bindings: arm: Initial MStar vendor prefixes and compatible strings
From: Daniel Palmer @ 2019-09-11 4:31 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: Daniel Palmer
This adds a prefix for MStar and thingy.jp and then defines compatible
strings for the first MStar based board.
---
.../devicetree/bindings/arm/mstar.yaml | 22 +++++++++++++++++++
.../devicetree/bindings/vendor-prefixes.yaml | 6 +++--
MAINTAINERS | 6 +++++
3 files changed, 32 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/mstar.yaml
diff --git a/Documentation/devicetree/bindings/arm/mstar.yaml b/Documentation/devicetree/bindings/arm/mstar.yaml
new file mode 100644
index 000000000000..fbb9f8d1c06c
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mstar.yaml
@@ -0,0 +1,22 @@
+# SPDX-License-Identifier: (GPL-2.0+ OR X11)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/mstar.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MStar platforms device tree bindings
+
+maintainers:
+ - Daniel Palmer <daniel@thingy.jp>
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+
+ - description: thingy.jp BreadBee
+ items:
+ - const: thingyjp,breadbee
+ - const: mstar,msc313e
+ - const: mstar,msc313
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 6992bbbbffab..74b8f6566dec 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -599,6 +599,8 @@ patternProperties:
description: Microsemi Corporation
"^msi,.*":
description: Micro-Star International Co. Ltd.
+ "^mstar,.*":
+ description: MStar Semiconductor, Inc.
"^mti,.*":
description: Imagination Technologies Ltd. (formerly MIPS Technologies Inc.)
"^multi-inno,.*":
@@ -921,8 +923,8 @@ patternProperties:
description: Terasic Inc.
"^tfc,.*":
description: Three Five Corp
- "^thine,.*":
- description: THine Electronics, Inc.
+ "^thingyjp,.*":
+ description: thingy.jp
"^ti,.*":
description: Texas Instruments
"^tianma,.*":
diff --git a/MAINTAINERS b/MAINTAINERS
index e7a47b5210fd..252fa7171aea 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1955,6 +1955,12 @@ L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
F: arch/arm/mach-pxa/mioa701.c
S: Maintained
+ARM/MStar SoC support
+M: Daniel Palmer <daniel@thingy.jp>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+F: Documentation/devicetree/bindings/arm/mstar.yaml
+S: Maintained
+
ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT
M: Michael Petchkovsky <mkpetch@internode.on.net>
S: Maintained
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RFC 2/4] ARM: mstar: Add machine for MStar msc313 family SoCs
From: Daniel Palmer @ 2019-09-11 4:31 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: Daniel Palmer
In-Reply-To: <20190911043142.3734-1-daniel@0x0f.com>
Initial support for the MStar msc313 series of Cortex A7 based
IP camera SoCs.
These chips are interesting in that they contain a Cortex A7,
peripherals and system memory in a single tiny QFN package that
can be hand soldered allowing almost anyone to embed Linux
in their projects.
---
MAINTAINERS | 1 +
arch/arm/Kconfig | 2 +
arch/arm/Makefile | 1 +
arch/arm/mach-mstar/Kconfig | 14 ++++++
arch/arm/mach-mstar/Makefile | 1 +
arch/arm/mach-mstar/msc313.c | 96 ++++++++++++++++++++++++++++++++++++
6 files changed, 115 insertions(+)
create mode 100644 arch/arm/mach-mstar/Kconfig
create mode 100644 arch/arm/mach-mstar/Makefile
create mode 100644 arch/arm/mach-mstar/msc313.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 252fa7171aea..b046773af438 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1959,6 +1959,7 @@ ARM/MStar SoC support
M: Daniel Palmer <daniel@thingy.jp>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
F: Documentation/devicetree/bindings/arm/mstar.yaml
+F: arch/arm/mach-mstar/
S: Maintained
ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 24360211534a..c5c6d31e4301 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -760,6 +760,8 @@ source "arch/arm/mach-mmp/Kconfig"
source "arch/arm/mach-moxart/Kconfig"
+source "arch/arm/mach-mstar/Kconfig"
+
source "arch/arm/mach-mv78xx0/Kconfig"
source "arch/arm/mach-mvebu/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index c3624ca6c0bc..581e32505408 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -191,6 +191,7 @@ machine-$(CONFIG_ARCH_MXC) += imx
machine-$(CONFIG_ARCH_MEDIATEK) += mediatek
machine-$(CONFIG_ARCH_MILBEAUT) += milbeaut
machine-$(CONFIG_ARCH_MXS) += mxs
+machine-$(CONFIG_ARCH_MSTAR) += mstar
machine-$(CONFIG_ARCH_NOMADIK) += nomadik
machine-$(CONFIG_ARCH_NPCM) += npcm
machine-$(CONFIG_ARCH_NSPIRE) += nspire
diff --git a/arch/arm/mach-mstar/Kconfig b/arch/arm/mach-mstar/Kconfig
new file mode 100644
index 000000000000..d6b0a515da91
--- /dev/null
+++ b/arch/arm/mach-mstar/Kconfig
@@ -0,0 +1,14 @@
+menuconfig ARCH_MSTAR
+ bool "MStar SoC Support"
+ depends on ARCH_MULTI_V7
+ select ARM_GIC
+ help
+ Support for MStar ARMv7 SoCs
+
+if ARCH_MSTAR
+
+config MACH_MSC313
+ bool "MStar MSC313(d/e) SoC support"
+ default ARCH_MSTAR
+
+endif
diff --git a/arch/arm/mach-mstar/Makefile b/arch/arm/mach-mstar/Makefile
new file mode 100644
index 000000000000..231105cdc872
--- /dev/null
+++ b/arch/arm/mach-mstar/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_MACH_MSC313) += msc313.o
\ No newline at end of file
diff --git a/arch/arm/mach-mstar/msc313.c b/arch/arm/mach-mstar/msc313.c
new file mode 100644
index 000000000000..c104635f39e4
--- /dev/null
+++ b/arch/arm/mach-mstar/msc313.c
@@ -0,0 +1,96 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree support for MStar MSC313 SoCs
+ *
+ * Copyright (c) 2019 thingy.jp
+ * Author: Daniel Palmer <daniel@thingy.jp>
+ */
+
+#include <linux/init.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+#include <linux/of.h>
+#include <asm/io.h>
+
+/*
+ * The IO space is remapped to the same place
+ * the vendor kernel does so that the hardcoded
+ * addresses all over the vendor drivers line up.
+ */
+
+#define MSC313_IO_PHYS 0x1f000000
+#define MSC313_IO_OFFSET 0xde000000
+#define MSC313_IO_VIRT (MSC313_IO_PHYS + MSC313_IO_OFFSET)
+#define MSC313_IO_SIZE 0x00400000
+
+/*
+ * In the u-boot code the area these registers are in is
+ * called "L3 bridge".
+ *
+ * It's not exactly known what is the L3 bridge is but
+ * the vendor code for both u-boot and linux share calls
+ * to "flush the miu pipe". This seems to be to force pending
+ * CPU writes to memory so that the state is right before
+ * DMA capable devices try to read descriptors and data
+ * the CPU has prepared. Without doing this ethernet doesn't
+ * work reliably for example.
+ */
+
+#define MSC313_L3BRIDGE_FLUSH 0x204414
+#define MSC313_L3BRIDGE_STATUS 0x204440
+#define MSC313_L3BRIDGE_FLUSH_TRIGGER BIT(0)
+#define MSC313_L3BRIDGE_STATUS_DONE BIT(12)
+
+static void __iomem *miu_status;
+static void __iomem *miu_flush;
+
+static struct map_desc msc313_io_desc[] __initdata = {
+ {MSC313_IO_VIRT, __phys_to_pfn(MSC313_IO_PHYS),
+ MSC313_IO_SIZE, MT_DEVICE},
+};
+
+static void __init msc313_map_io(void)
+{
+ iotable_init(msc313_io_desc, ARRAY_SIZE(msc313_io_desc));
+ miu_flush = (void __iomem *) (msc313_io_desc[0].virtual
+ + MSC313_L3BRIDGE_FLUSH);
+ miu_status = (void __iomem *) (msc313_io_desc[0].virtual
+ + MSC313_L3BRIDGE_STATUS);
+}
+
+static const char * const msc313_board_dt_compat[] = {
+ "mstar,msc313",
+ NULL,
+};
+
+static DEFINE_SPINLOCK(msc313_mb_lock);
+
+static void msc313_mb(void)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&msc313_mb_lock, flags);
+ /* toggle the flush miu pipe fire bit */
+ writel_relaxed(0, miu_flush);
+ writel_relaxed(MSC313_L3BRIDGE_FLUSH_TRIGGER, miu_flush);
+ while (!(readl_relaxed(miu_status) & MSC313_L3BRIDGE_STATUS_DONE)) {
+ /* wait for flush to complete */
+ }
+ spin_unlock_irqrestore(&msc313_mb_lock, flags);
+}
+
+static void __init msc313_barriers_init(void)
+{
+ soc_mb = msc313_mb;
+}
+
+static void __init msc313_init(void)
+{
+ msc313_barriers_init();
+}
+
+DT_MACHINE_START(MSTAR_DT, "MStar MSC313 (Device Tree)")
+ .dt_compat = msc313_board_dt_compat,
+ .init_machine = msc313_init,
+ .map_io = msc313_map_io,
+MACHINE_END
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RFC 3/4] ARM: mstar: Add msc313 series dtsi
From: Daniel Palmer @ 2019-09-11 4:31 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: Daniel Palmer
In-Reply-To: <20190911043142.3734-1-daniel@0x0f.com>
Adds an initial dtsi for the msc313 SoC family and a dtsi for
the msc313e part.
---
MAINTAINERS | 1 +
arch/arm/boot/dts/msc313.dtsi | 71 ++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/msc313e.dtsi | 14 +++++++
3 files changed, 86 insertions(+)
create mode 100644 arch/arm/boot/dts/msc313.dtsi
create mode 100644 arch/arm/boot/dts/msc313e.dtsi
diff --git a/MAINTAINERS b/MAINTAINERS
index b046773af438..c71c3ec3d43f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1960,6 +1960,7 @@ M: Daniel Palmer <daniel@thingy.jp>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
F: Documentation/devicetree/bindings/arm/mstar.yaml
F: arch/arm/mach-mstar/
+F: arch/arm/boot/dts/msc313*.dtsi
S: Maintained
ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT
diff --git a/arch/arm/boot/dts/msc313.dtsi b/arch/arm/boot/dts/msc313.dtsi
new file mode 100644
index 000000000000..101582f277ff
--- /dev/null
+++ b/arch/arm/boot/dts/msc313.dtsi
@@ -0,0 +1,71 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 thingy.jp.
+ * Author: Daniel Palmer <daniel@thingy.jp>
+ */
+
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupt-parent = <&gic>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x0>;
+ };
+ };
+
+ arch_timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2)
+ | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2)
+ | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2)
+ | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2)
+ | IRQ_TYPE_LEVEL_LOW)>;
+ clock-frequency = <6000000>;
+ };
+
+ pmu {
+ compatible = "arm,cortex-a7-pmu";
+ interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ soc: soc {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ gic: interrupt-controller@0x16001000 {
+ compatible = "arm,cortex-a7-gic";
+ #interrupt-cells = <3>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupt-controller;
+ reg = <0x16001000 0x1000>,
+ <0x16002000 0x1000>;
+ };
+
+ pm_uart: uart@1f221000 {
+ compatible = "ns16550a";
+ reg = <0x1f221000 0x100>;
+ reg-shift = <3>;
+ clock-frequency = <172000000>;
+ status = "disabled";
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/msc313e.dtsi b/arch/arm/boot/dts/msc313e.dtsi
new file mode 100644
index 000000000000..c4842625f6e2
--- /dev/null
+++ b/arch/arm/boot/dts/msc313e.dtsi
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 thingy.jp.
+ * Author: Daniel Palmer <daniel@thingy.jp>
+ */
+
+#include "msc313.dtsi"
+
+/ {
+ memory {
+ device_type = "memory";
+ reg = <0x20000000 0x4000000>;
+ };
+};
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RFC 4/4] ARM: mstar: Add dts for msc313e based BreadBee board
From: Daniel Palmer @ 2019-09-11 4:31 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: Daniel Palmer
In-Reply-To: <20190911043142.3734-1-daniel@0x0f.com>
BreadBee is an opensource development board based on the
MStar msc313e SoC.
Hardware details, schematics and so on can be found at:
https://github.com/breadbee/breadbee
---
MAINTAINERS | 1 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/msc313e-breadbee.dts | 26 ++++++++++++++++++++++++++
3 files changed, 28 insertions(+)
create mode 100644 arch/arm/boot/dts/msc313e-breadbee.dts
diff --git a/MAINTAINERS b/MAINTAINERS
index c71c3ec3d43f..2768d6e07afb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1961,6 +1961,7 @@ L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
F: Documentation/devicetree/bindings/arm/mstar.yaml
F: arch/arm/mach-mstar/
F: arch/arm/boot/dts/msc313*.dtsi
+F: arch/arm/boot/dts/msc313e-*.dts
S: Maintained
ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9159fa2cea90..b4b5f639859a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1265,6 +1265,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
mt8127-moose.dtb \
mt8135-evbp1.dtb
dtb-$(CONFIG_ARCH_MILBEAUT) += milbeaut-m10v-evb.dtb
+dtb-$(CONFIG_ARCH_MSTAR) += msc313e-breadbee.dtb
dtb-$(CONFIG_ARCH_ZX) += zx296702-ad1.dtb
dtb-$(CONFIG_ARCH_ASPEED) += \
aspeed-ast2500-evb.dtb \
diff --git a/arch/arm/boot/dts/msc313e-breadbee.dts b/arch/arm/boot/dts/msc313e-breadbee.dts
new file mode 100644
index 000000000000..470ea5fd94a7
--- /dev/null
+++ b/arch/arm/boot/dts/msc313e-breadbee.dts
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 thingy.jp.
+ * Author: Daniel Palmer <daniel@thingy.jp>
+ */
+
+/dts-v1/;
+#include "msc313e.dtsi"
+
+/ {
+ model = "thingy.jp breadbee";
+ compatible = "thingyjp,breadbee", "mstar,msc313e", "mstar,msc313";
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ bootargs = "console=ttyS0,115200";
+ };
+
+ aliases {
+ console = &pm_uart;
+ };
+};
+
+&pm_uart {
+ status = "okay";
+};
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] ARM: module: Drop 'rel->r_offset < 0' always false statement
From: Austin Kim @ 2019-09-11 4:54 UTC (permalink / raw)
To: linux, allison, info, matthias.schiffer
Cc: austindh.kim, linux-kernel, linux-arm-kernel
Since rel->r_offset is declared as Elf32_Addr,
this value is always non-negative.
typedef struct elf32_rel {
Elf32_Addr r_offset;
Elf32_Word r_info;
} Elf32_Rel;
typedef __u32 Elf32_Addr;
typedef unsigned int __u32;
Drop 'rel->r_offset < 0' statement which is always false.
Signed-off-by: Austin Kim <austindh.kim@gmail.com>
---
arch/arm/kernel/module.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
index deef17f..0921ce7 100644
--- a/arch/arm/kernel/module.c
+++ b/arch/arm/kernel/module.c
@@ -92,7 +92,7 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
sym = ((Elf32_Sym *)symsec->sh_addr) + offset;
symname = strtab + sym->st_name;
- if (rel->r_offset < 0 || rel->r_offset > dstsec->sh_size - sizeof(u32)) {
+ if (rel->r_offset > dstsec->sh_size - sizeof(u32)) {
pr_err("%s: section %u reloc %u sym '%s': out of bounds relocation, offset %d size %u\n",
module->name, relindex, i, symname,
rel->r_offset, dstsec->sh_size);
--
2.6.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
* Re: [PATCH] net: stmmac: socfpga: re-use the `interface` parameter from platform data
From: Ardelean, Alexandru @ 2019-09-11 5:03 UTC (permalink / raw)
To: davem@davemloft.net
Cc: alexandre.torgue@st.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, joabreu@synopsys.com,
mcoquelin.stm32@gmail.com, peppe.cavallaro@st.com,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190910.174653.800353422834551780.davem@davemloft.net>
On Tue, 2019-09-10 at 17:46 +0200, David Miller wrote:
> [External]
>
> From: David Miller <davem@davemloft.net>
> Date: Tue, 10 Sep 2019 17:45:44 +0200 (CEST)
>
> > From: Alexandru Ardelean <alexandru.ardelean@analog.com>
> > Date: Fri, 6 Sep 2019 15:30:54 +0300
> >
> > > The socfpga sub-driver defines an `interface` field in the `socfpga_dwmac`
> > > struct and parses it on init.
> > >
> > > The shared `stmmac_probe_config_dt()` function also parses this from the
> > > device-tree and makes it available on the returned `plat_data` (which is
> > > the same data available via `netdev_priv()`).
> > >
> > > All that's needed now is to dig that information out, via some
> > > `dev_get_drvdata()` && `netdev_priv()` calls and re-use it.
> > >
> > > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> >
> > This doesn't build even on net-next.
>
Right.
My bad.
I think I got confused with multiple/cross-testing and probably this change didn't even get compiled.
Apologies for this.
Will send a good version.
Alex
> Specifically:
>
> drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c: In function ‘socfpga_gen5_set_phy_mode’:
> drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c:264:44: error: ‘phymode’ undeclared (first use in this function);
> did you mean ‘phy_modes’?
> 264 | dev_err(dwmac->dev, "bad phy mode %d\n", phymode);
> | ^~~~~~~
> ./include/linux/device.h:1499:32: note: in definition of macro ‘dev_err’
> 1499 | _dev_err(dev, dev_fmt(fmt), ##__VA_ARGS__)
> | ^~~~~~~~~~~
> drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c:264:44: note: each undeclared identifier is reported only once for
> each function it appears in
> 264 | dev_err(dwmac->dev, "bad phy mode %d\n", phymode);
> | ^~~~~~~
> ./include/linux/device.h:1499:32: note: in definition of macro ‘dev_err’
> 1499 | _dev_err(dev, dev_fmt(fmt), ##__VA_ARGS__)
> | ^~~~~~~~~~~
> drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c: In function ‘socfpga_gen10_set_phy_mode’:
> drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c:340:6: error: ‘phymode’ undeclared (first use in this function);
> did you mean ‘phy_modes’?
> 340 | phymode == PHY_INTERFACE_MODE_MII ||
> | ^~~~~~~
> | phy_modes
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v1 1/1] pinctrl: iproc: Add 'get_direction' support
From: Rayagonda Kokatanur @ 2019-09-11 5:11 UTC (permalink / raw)
To: Linus Walleij, Ray Jui, Scott Branden, bcm-kernel-feedback-list,
linux-gpio, linux-arm-kernel, linux-kernel
Cc: Rayagonda Kokatanur
Add 'get_direction' support to the iProc GPIO driver.
Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
---
drivers/pinctrl/bcm/pinctrl-iproc-gpio.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c b/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
index b70058c..d782d70 100644
--- a/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
+++ b/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
@@ -355,6 +355,15 @@ static int iproc_gpio_direction_output(struct gpio_chip *gc, unsigned gpio,
return 0;
}
+static int iproc_gpio_get_direction(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct iproc_gpio *chip = gpiochip_get_data(gc);
+ unsigned int offset = IPROC_GPIO_REG(gpio, IPROC_GPIO_OUT_EN_OFFSET);
+ unsigned int shift = IPROC_GPIO_SHIFT(gpio);
+
+ return !(readl(chip->base + offset) & BIT(shift));
+}
+
static void iproc_gpio_set(struct gpio_chip *gc, unsigned gpio, int val)
{
struct iproc_gpio *chip = gpiochip_get_data(gc);
@@ -784,6 +793,7 @@ static int iproc_gpio_probe(struct platform_device *pdev)
gc->free = iproc_gpio_free;
gc->direction_input = iproc_gpio_direction_input;
gc->direction_output = iproc_gpio_direction_output;
+ gc->get_direction = iproc_gpio_get_direction;
gc->set = iproc_gpio_set;
gc->get = iproc_gpio_get;
--
1.9.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 v5 2/2] mailbox: introduce ARM SMC based mailbox
From: Peng Fan @ 2019-09-11 5:58 UTC (permalink / raw)
To: Andre Przywara
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
f.fainelli@gmail.com, jassisinghbrar@gmail.com,
linux-kernel@vger.kernel.org, robh+dt@kernel.org, dl-linux-imx,
sudeep.holla@arm.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190909164216.0abe640b@donnerap.cambridge.arm.com>
Hi Andre,
> Subject: Re: [PATCH v5 2/2] mailbox: introduce ARM SMC based mailbox
>
> On Wed, 28 Aug 2019 03:03:02 +0000
> Peng Fan <peng.fan@nxp.com> wrote:
>
> Hi,
>
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > This mailbox driver implements a mailbox which signals transmitted
> > data via an ARM smc (secure monitor call) instruction. The mailbox
> > receiver is implemented in firmware and can synchronously return data
> > when it returns execution to the non-secure world again.
> > An asynchronous receive path is not implemented.
> > This allows the usage of a mailbox to trigger firmware actions on SoCs
> > which either don't have a separate management processor or on which
> > such a core is not available. A user of this mailbox could be the SCP
> > interface.
> >
> > Modified from Andre Przywara's v2 patch
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fpatchwork%2Fpatch%2F812999%2F&data=02%7C01%7
> Cpeng.fa
> >
> n%40nxp.com%7Cce8d04bcbdea4de6a77a08d7353c4e35%7C686ea1d3bc2b
> 4c6fa92cd
> >
> 99c5c301635%7C0%7C0%7C637036405476727893&sdata=y5%2FI%2B
> w%2FPOypEh
> > zh6gWdXAGMGnl677B7gDZsX%2F5zfAQw%3D&reserved=0
> >
> > Cc: Andre Przywara <andre.przywara@arm.com>
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > ---
> > drivers/mailbox/Kconfig | 7 ++
> > drivers/mailbox/Makefile | 2 +
> > drivers/mailbox/arm-smc-mailbox.c | 215
> > ++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 224 insertions(+)
> > create mode 100644 drivers/mailbox/arm-smc-mailbox.c
> >
> > diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index
> > ab4eb750bbdd..7707ee26251a 100644
> > --- a/drivers/mailbox/Kconfig
> > +++ b/drivers/mailbox/Kconfig
> > @@ -16,6 +16,13 @@ config ARM_MHU
> > The controller has 3 mailbox channels, the last of which can be
> > used in Secure mode only.
> >
> > +config ARM_SMC_MBOX
> > + tristate "Generic ARM smc mailbox"
> > + depends on OF && HAVE_ARM_SMCCC
> > + help
> > + Generic mailbox driver which uses ARM smc calls to call into
> > + firmware for triggering mailboxes.
> > +
> > config IMX_MBOX
> > tristate "i.MX Mailbox"
> > depends on ARCH_MXC || COMPILE_TEST
> > diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile index
> > c22fad6f696b..93918a84c91b 100644
> > --- a/drivers/mailbox/Makefile
> > +++ b/drivers/mailbox/Makefile
> > @@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o
> >
> > obj-$(CONFIG_ARM_MHU) += arm_mhu.o
> >
> > +obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
> > +
> > obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
> >
> > obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX) +=
> armada-37xx-rwtm-mailbox.o
> > diff --git a/drivers/mailbox/arm-smc-mailbox.c
> > b/drivers/mailbox/arm-smc-mailbox.c
> > new file mode 100644
> > index 000000000000..76a2ae11ee4d
> > --- /dev/null
> > +++ b/drivers/mailbox/arm-smc-mailbox.c
> > @@ -0,0 +1,215 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2016,2017 ARM Ltd.
> > + * Copyright 2019 NXP
> > + */
> > +
> > +#include <linux/arm-smccc.h>
> > +#include <linux/device.h>
> > +#include <linux/kernel.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/mailbox_controller.h> #include <linux/module.h>
> > +#include <linux/platform_device.h>
> > +
> > +#define ARM_SMC_MBOX_MEM_TRANS BIT(0)
> > +
> > +struct arm_smc_chan_data {
> > + u32 function_id;
> > + u32 chan_id;
> > + u32 flags;
> > +};
> > +
> > +struct arm_smccc_mbox_cmd {
> > + unsigned long a0, a1, a2, a3, a4, a5, a6, a7;
>
> I think this is one or even two registers too long?
> The SMCCC speaks of the function ID in x0/r0 and six arguments, with a
> "client ID" being an optional seventh argument. Looking at the description
> there I believe we cannot use the client ID here for this purpose, as this is
> supposed to be set by a hypervisor before passing on an SMC to EL3 firmware.
> KVM does not allow passing on SMCs in this way.
I'll drop a7.
>
> Also, while using "long" in here seems to make sense from the mailbox and
> SMC point of view, aliasing this to the mailbox client provided data seems
> dangerous to me, as this exposes the difference between arm32 and arm64
> to the client. I think this is not what we want, the client should not be
> architecture specific.
I see.
>
> > +};
> > +
> > +typedef unsigned long (smc_mbox_fn)(unsigned long, unsigned long,
> > + unsigned long, unsigned long,
> > + unsigned long, unsigned long,
> > + unsigned long, unsigned long); static smc_mbox_fn
> > +*invoke_smc_mbox_fn;
> > +
> > +static int arm_smc_send_data(struct mbox_chan *link, void *data) {
> > + struct arm_smc_chan_data *chan_data = link->con_priv;
> > + struct arm_smccc_mbox_cmd *cmd = data;
> > + unsigned long ret;
> > + u32 function_id;
> > + u32 chan_id;
> > +
> > + if (chan_data->flags & ARM_SMC_MBOX_MEM_TRANS) {
> > + if (chan_data->function_id != UINT_MAX)
> > + function_id = chan_data->function_id;
> > + else
> > + function_id = cmd->a0;
>
> This is somewhat surprising, dangerous and undocumented. We should *not*
> allow mailbox clients to specify the function ID. They could end up using PSCI
> function IDs, for instance, that sounds especially scary if a client driver allows
> userland to set parameters of some sort.
So the func id should not be an optional property in dts?
The check here is to not make func id an optional property and allow client driver
pass function id.
> The function ID is presumably allocated and fixed in the firmware, so it should
> not be dynamic. Any dynamic properties should be done within a function ID
> on the protocol level, by using r1/x1, for instance.
>
> > + chan_id = chan_data->chan_id;
>
> Why is this here? Where is this documented? Isn't this redundant with
> function ID? Or is this meant to be a replacement for it when a client provided
> function ID is used (which is not desired, as mentioned above)?
This will be dropped after move to per channel as a controller.
>
> > + ret = invoke_smc_mbox_fn(function_id, chan_id, 0, 0, 0, 0,
> > + 0, 0);
> > + } else {
> > + ret = invoke_smc_mbox_fn(cmd->a0, cmd->a1, cmd->a2, cmd->a3,
> > + cmd->a4, cmd->a5, cmd->a6, cmd->a7);
> > + }
>
> As mentioned in my reply to the binding patch, I don't see this is necessary.
> Instead of ignoring the client provided data, we should just always pass it on.
> If clients and protocols don't use them, the client could zero it as well, letting
> the firmware side ignore it.
Per Jassi's comments, arm,func-id is an optional property.
So I would change to like below:
+ if (func_id)
+ function_id = chan_data->function_id;
+ else
+ function_id = cmd->a0;
+
+ if (data)
+ ret = invoke_smc_mbox_fn(function_id, cmd->args[1], cmd->args[2], cmd->args[3], cmd->args[4], cmd->args[5], cmd->args[6]);
+ else
+ ret = invoke_smc_mbox_fn(function_id, 0, 0, 0, 0, 0, 0);
And need a check if no data from client and no func_id, need return -EINVAL to client.
How do you think?
>
> Also this underlines the problem with using "long" above: For 32-bit and 64-bit
> kernels the layout would be different.
> I think the size of each argument should be determined by the calling
> convention class (bit 30) of the function ID.
> The client doesn't know about that one (it's a controller/firmware property),
> so this driver here should split up the stream of data according to SMC64 vs.
> SMC32.
> Does that make sense?
Got it. Check the bit30 to decide use r[] or use x[] for SMCCC.
>
> > +
> > + mbox_chan_received_data(link, (void *)ret);
>
> Not a mailbox expert, but shouldn't we mark the TX operation as complete
> here? Clearly by returning from the SMC the firmware has received the
> request.
> Whether the requested action has completed, is a protocol / mailbox client
> question.
I do not see any API to mark TX completed. My understanding is send_data
return value means complete finished.
>
> > +
> > + return 0;
> > +}
> > +
> > +static unsigned long __invoke_fn_hvc(unsigned long function_id,
> > + unsigned long arg0, unsigned long arg1,
> > + unsigned long arg2, unsigned long arg3,
> > + unsigned long arg4, unsigned long arg5,
> > + unsigned long arg6)
> > +{
> > + struct arm_smccc_res res;
> > +
> > + arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4,
> > + arg5, arg6, &res);
> > + return res.a0;
> > +}
> > +
> > +static unsigned long __invoke_fn_smc(unsigned long function_id,
> > + unsigned long arg0, unsigned long arg1,
> > + unsigned long arg2, unsigned long arg3,
> > + unsigned long arg4, unsigned long arg5,
> > + unsigned long arg6)
> > +{
> > + struct arm_smccc_res res;
> > +
> > + arm_smccc_smc(function_id, arg0, arg1, arg2, arg3, arg4,
> > + arg5, arg6, &res);
> > + return res.a0;
> > +}
> > +
> > +static const struct mbox_chan_ops arm_smc_mbox_chan_ops = {
> > + .send_data = arm_smc_send_data,
> > +};
> > +
> > +static int arm_smc_mbox_probe(struct platform_device *pdev) {
> > + struct device *dev = &pdev->dev;
> > + struct mbox_controller *mbox;
> > + struct arm_smc_chan_data *chan_data;
> > + const char *method;
> > + bool mem_trans = false;
> > + int ret, i;
> > + u32 val;
> > +
> > + if (!of_property_read_u32(dev->of_node, "arm,num-chans", &val)) {
> > + if (!val) {
> > + dev_err(dev, "invalid arm,num-chans value %u\n", val);
> > + return -EINVAL;
> > + }
> > + } else {
> > + return -EINVAL;
> > + }
>
> As mentioned, this property should be removed, ...
Yes.
>
> > +
> > + if (!of_property_read_string(dev->of_node, "transports", &method)) {
> > + if (!strcmp("mem", method)) {
> > + mem_trans = true;
> > + } else if (!strcmp("reg", method)) {
> > + mem_trans = false;
> > + } else {
> > + dev_warn(dev, "invalid \"transports\" property: %s\n",
> > + method);
> > +
> > + return -EINVAL;
> > + }
> > + } else {
> > + return -EINVAL;
> > + }
>
> ... and this one as well.
Yes.
>
> > +
> > + if (!of_property_read_string(dev->of_node, "method", &method)) {
> > + if (!strcmp("hvc", method)) {
> > + invoke_smc_mbox_fn = __invoke_fn_hvc;
> > + } else if (!strcmp("smc", method)) {
> > + invoke_smc_mbox_fn = __invoke_fn_smc;
> > + } else {
> > + dev_warn(dev, "invalid \"method\" property: %s\n",
> > + method);
>
> Just a nit, but if this is fatal for the driver, it should be dev_err().
Yes.
>
> > +
> > + return -EINVAL;
> > + }
> > + } else {
> > + return -EINVAL;
> > + }
> > +
> > + mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
> > + if (!mbox)
> > + return -ENOMEM;
> > +
> > + mbox->num_chans = val;
>
> This could be replaced with:
> mbox->num_chans =
> of_property_count_elems_of_size(dev_of_node(dev),
> "arm,func-ids", sizeof(u32));
>
> > + mbox->chans = devm_kcalloc(dev, mbox->num_chans,
> sizeof(*mbox->chans),
> > + GFP_KERNEL);
> > + if (!mbox->chans)
> > + return -ENOMEM;
> > +
> > + chan_data = devm_kcalloc(dev, mbox->num_chans, sizeof(*chan_data),
> > + GFP_KERNEL);
> > + if (!chan_data)
> > + return -ENOMEM;
> > +
> > + for (i = 0; i < mbox->num_chans; i++) {
> > + u32 function_id;
> > +
> > + ret = of_property_read_u32_index(dev->of_node,
> > + "arm,func-ids", i,
> > + &function_id);
> > + if (ret)
> > + chan_data[i].function_id = UINT_MAX;
> > +
> > + else
> > + chan_data[i].function_id = function_id;
>
> As mentioned above, this should go. Any non-0 return value should stop the
> driver probing.
But if the func-id as an optional property, we need use the value from client
driver.
Thanks,
Peng.
>
> Cheers,
> Andre.
>
> > +
> > + chan_data[i].chan_id = i;
> > +
> > + if (mem_trans)
> > + chan_data[i].flags |= ARM_SMC_MBOX_MEM_TRANS;
> > + mbox->chans[i].con_priv = &chan_data[i];
> > + }
> > +
> > + mbox->txdone_poll = false;
> > + mbox->txdone_irq = false;
> > + mbox->ops = &arm_smc_mbox_chan_ops;
> > + mbox->dev = dev;
> > +
> > + platform_set_drvdata(pdev, mbox);
> > +
> > + ret = devm_mbox_controller_register(dev, mbox);
> > + if (ret)
> > + return ret;
> > +
> > + dev_info(dev, "ARM SMC mailbox enabled with %d chan%s.\n",
> > + mbox->num_chans, mbox->num_chans == 1 ? "" : "s");
> > +
> > + return ret;
> > +}
> > +
> > +static int arm_smc_mbox_remove(struct platform_device *pdev) {
> > + struct mbox_controller *mbox = platform_get_drvdata(pdev);
> > +
> > + mbox_controller_unregister(mbox);
> > + return 0;
> > +}
> > +
> > +static const struct of_device_id arm_smc_mbox_of_match[] = {
> > + { .compatible = "arm,smc-mbox", },
> > + {},
> > +};
> > +MODULE_DEVICE_TABLE(of, arm_smc_mbox_of_match);
> > +
> > +static struct platform_driver arm_smc_mbox_driver = {
> > + .driver = {
> > + .name = "arm-smc-mbox",
> > + .of_match_table = arm_smc_mbox_of_match,
> > + },
> > + .probe = arm_smc_mbox_probe,
> > + .remove = arm_smc_mbox_remove,
> > +};
> > +module_platform_driver(arm_smc_mbox_driver);
> > +
> > +MODULE_AUTHOR("Andre Przywara <andre.przywara@arm.com>");
> > +MODULE_DESCRIPTION("Generic ARM smc mailbox driver");
> > +MODULE_LICENSE("GPL v2");
_______________________________________________
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: vf610-zii-scu4-aib: Drop "rs485-rts-delay" property
From: Shawn Guo @ 2019-09-11 6:05 UTC (permalink / raw)
To: Andrey Smirnov; +Cc: Fabio Estevam, Chris Healy, linux-arm-kernel, linux-kernel
In-Reply-To: <20190820031301.11172-1-andrew.smirnov@gmail.com>
On Mon, Aug 19, 2019 at 08:13:01PM -0700, Andrey Smirnov wrote:
> LPUART driver does not support specifying "rs485-rts-delay"
> property. Drop it.
>
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Chris Healy <cphealy@gmail.com>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
Applied, thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [xlnx:xilinx_rebase_v4.19 1607/1649] htmldocs: drivers/usb/dwc3/core.h:1228: warning: Function parameter or member 'mask_phy_rst' not described in 'dwc3'
From: kbuild test robot @ 2019-09-11 6:10 UTC (permalink / raw)
To: Anurag Kumar Vulisha; +Cc: Michal Simek, kbuild-all, linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 22620 bytes --]
tree: https://github.com/Xilinx/linux-xlnx xilinx_rebase_v4.19
head: a5be9440aaf62e63f672eebb76d16f2a20df88bb
commit: 89c9dfb4bded8b2a9803f63f421d4787bfdaf1f3 [1607/1649] usb: dwc3: Add support for masking phy reset signal
reproduce: make htmldocs
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
Warning: The Sphinx 'sphinx_rtd_theme' HTML theme was not found. Make sure you have the theme installed to produce pretty HTML output. Falling back to the default theme.
Documentation/sphinx/kfigure.py:174: RemovedInSphinx20Warning: app.verbose() is now deprecated. Use sphinx.util.logging instead.
app.verbose("kfigure: check installed tools ...")
Documentation/sphinx/kfigure.py:182: RemovedInSphinx20Warning: app.warning() is now deprecated. Use sphinx.util.logging instead.
app.warn("dot(1) not found, for better output quality install "
WARNING: dot(1) not found, for better output quality install graphviz from http://www.graphviz.org
Documentation/sphinx/kfigure.py:188: RemovedInSphinx20Warning: app.warning() is now deprecated. Use sphinx.util.logging instead.
"convert(1) not found, for SVG to PDF conversion install "
WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick (https://www.imagemagick.org)
Documentation/sphinx/kerneldoc.py:93: RemovedInSphinx20Warning: app.verbose() is now deprecated. Use sphinx.util.logging instead.
env.app.verbose('calling kernel-doc '%s'' % (" ".join(cmd)))
Documentation/sphinx/kerneldoc.py:125: RemovedInSphinx20Warning: AutodocReporter is now deprecated. Use sphinx.util.docutils.switch_source_input() instead.
self.state.memo.reporter = AutodocReporter(result, self.state.memo.reporter)
include/linux/srcu.h:175: warning: Function parameter or member 'p' not described in 'srcu_dereference_notrace'
include/linux/srcu.h:175: warning: Function parameter or member 'sp' not described in 'srcu_dereference_notrace'
include/linux/gfp.h:1: warning: no structured comments found
include/linux/crypto.h:309: warning: Function parameter or member 'setkeytype' not described in 'blkcipher_alg'
include/net/cfg80211.h:4381: warning: Function parameter or member 'wext.ibss' not described in 'wireless_dev'
include/net/cfg80211.h:4381: warning: Function parameter or member 'wext.connect' not described in 'wireless_dev'
include/net/cfg80211.h:4381: warning: Function parameter or member 'wext.keys' not described in 'wireless_dev'
include/net/cfg80211.h:4381: warning: Function parameter or member 'wext.ie' not described in 'wireless_dev'
include/net/cfg80211.h:4381: warning: Function parameter or member 'wext.ie_len' not described in 'wireless_dev'
include/net/cfg80211.h:4381: warning: Function parameter or member 'wext.bssid' not described in 'wireless_dev'
include/net/cfg80211.h:4381: warning: Function parameter or member 'wext.ssid' not described in 'wireless_dev'
include/net/cfg80211.h:4381: warning: Function parameter or member 'wext.default_key' not described in 'wireless_dev'
include/net/cfg80211.h:4381: warning: Function parameter or member 'wext.default_mgmt_key' not described in 'wireless_dev'
include/net/cfg80211.h:4381: warning: Function parameter or member 'wext.prev_bssid_valid' not described in 'wireless_dev'
include/net/mac80211.h:2328: warning: Function parameter or member 'radiotap_timestamp.units_pos' not described in 'ieee80211_hw'
include/net/mac80211.h:2328: warning: Function parameter or member 'radiotap_timestamp.accuracy' not described in 'ieee80211_hw'
include/net/mac80211.h:977: warning: Function parameter or member 'control.rates' not described in 'ieee80211_tx_info'
include/net/mac80211.h:977: warning: Function parameter or member 'control.rts_cts_rate_idx' not described in 'ieee80211_tx_info'
include/net/mac80211.h:977: warning: Function parameter or member 'control.use_rts' not described in 'ieee80211_tx_info'
include/net/mac80211.h:977: warning: Function parameter or member 'control.use_cts_prot' not described in 'ieee80211_tx_info'
include/net/mac80211.h:977: warning: Function parameter or member 'control.short_preamble' not described in 'ieee80211_tx_info'
include/net/mac80211.h:977: warning: Function parameter or member 'control.skip_table' not described in 'ieee80211_tx_info'
include/net/mac80211.h:977: warning: Function parameter or member 'control.jiffies' not described in 'ieee80211_tx_info'
include/net/mac80211.h:977: warning: Function parameter or member 'control.vif' not described in 'ieee80211_tx_info'
include/net/mac80211.h:977: warning: Function parameter or member 'control.hw_key' not described in 'ieee80211_tx_info'
include/net/mac80211.h:977: warning: Function parameter or member 'control.flags' not described in 'ieee80211_tx_info'
include/net/mac80211.h:977: warning: Function parameter or member 'control.enqueue_time' not described in 'ieee80211_tx_info'
include/net/mac80211.h:977: warning: Function parameter or member 'ack' not described in 'ieee80211_tx_info'
include/net/mac80211.h:977: warning: Function parameter or member 'ack.cookie' not described in 'ieee80211_tx_info'
include/net/mac80211.h:977: warning: Function parameter or member 'status.rates' not described in 'ieee80211_tx_info'
include/net/mac80211.h:977: warning: Function parameter or member 'status.ack_signal' not described in 'ieee80211_tx_info'
include/net/mac80211.h:977: warning: Function parameter or member 'status.ampdu_ack_len' not described in 'ieee80211_tx_info'
include/net/mac80211.h:977: warning: Function parameter or member 'status.ampdu_len' not described in 'ieee80211_tx_info'
include/net/mac80211.h:977: warning: Function parameter or member 'status.antenna' not described in 'ieee80211_tx_info'
include/net/mac80211.h:977: warning: Function parameter or member 'status.tx_time' not described in 'ieee80211_tx_info'
include/net/mac80211.h:977: warning: Function parameter or member 'status.is_valid_ack_signal' not described in 'ieee80211_tx_info'
include/net/mac80211.h:977: warning: Function parameter or member 'status.status_driver_data' not described in 'ieee80211_tx_info'
include/net/mac80211.h:977: warning: Function parameter or member 'driver_rates' not described in 'ieee80211_tx_info'
include/net/mac80211.h:977: warning: Function parameter or member 'pad' not described in 'ieee80211_tx_info'
include/net/mac80211.h:977: warning: Function parameter or member 'rate_driver_data' not described in 'ieee80211_tx_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'rx_stats_avg' not described in 'sta_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'rx_stats_avg.signal' not described in 'sta_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'rx_stats_avg.chain_signal' not described in 'sta_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.filtered' not described in 'sta_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.retry_failed' not described in 'sta_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.retry_count' not described in 'sta_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.lost_packets' not described in 'sta_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.last_tdls_pkt_time' not described in 'sta_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.msdu_retries' not described in 'sta_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.msdu_failed' not described in 'sta_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.last_ack' not described in 'sta_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.last_ack_signal' not described in 'sta_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.ack_signal_filled' not described in 'sta_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.avg_ack_signal' not described in 'sta_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'tx_stats.packets' not described in 'sta_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'tx_stats.bytes' not described in 'sta_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'tx_stats.last_rate' not described in 'sta_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'tx_stats.msdu' not described in 'sta_info'
include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_excl.cb' not described in 'dma_buf'
include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_excl.poll' not described in 'dma_buf'
include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_excl.active' not described in 'dma_buf'
include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_shared.cb' not described in 'dma_buf'
include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_shared.poll' not described in 'dma_buf'
include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_shared.active' not described in 'dma_buf'
include/linux/dma-fence-array.h:54: warning: Function parameter or member 'work' not described in 'dma_fence_array'
include/linux/gpio/driver.h:149: warning: Function parameter or member 'request_key' not described in 'gpio_irq_chip'
include/linux/iio/hw-consumer.h:1: warning: no structured comments found
Error: Cannot open file drivers/uio/uio.c
Error: Cannot open file drivers/uio/uio.c
Documentation/sphinx/kerneldoc.py:103: RemovedInSphinx20Warning: app.warning() is now deprecated. Use sphinx.util.logging instead.
env.app.warn('kernel-doc '%s' failed with return code %d' % (" ".join(cmd), p.returncode))
include/linux/input/sparse-keymap.h:46: warning: Function parameter or member 'sw' not described in 'key_entry'
drivers/pci/pci.c:218: warning: Excess function parameter 'p' description in 'pci_dev_str_match_path'
include/linux/regulator/driver.h:227: warning: Function parameter or member 'resume' not described in 'regulator_ops'
drivers/regulator/core.c:4479: warning: Excess function parameter 'state' description in 'regulator_suspend'
arch/s390/include/asm/cio.h:245: warning: Function parameter or member 'esw.esw0' not described in 'irb'
arch/s390/include/asm/cio.h:245: warning: Function parameter or member 'esw.esw1' not described in 'irb'
arch/s390/include/asm/cio.h:245: warning: Function parameter or member 'esw.esw2' not described in 'irb'
arch/s390/include/asm/cio.h:245: warning: Function parameter or member 'esw.esw3' not described in 'irb'
arch/s390/include/asm/cio.h:245: warning: Function parameter or member 'esw.eadm' not described in 'irb'
drivers/slimbus/stream.c:1: warning: no structured comments found
drivers/target/target_core_device.c:1: warning: no structured comments found
drivers/usb/dwc3/core.h:901: warning: Function parameter or member 'first_trb_index' not described in 'dwc3_request'
drivers/usb/dwc3/core.h:1044: warning: bad line: a hibernation wakeup event
>> drivers/usb/dwc3/core.h:1228: warning: Function parameter or member 'mask_phy_rst' not described in 'dwc3'
drivers/usb/typec/bus.c:1: warning: no structured comments found
drivers/usb/typec/class.c:1: warning: no structured comments found
include/linux/w1.h:281: warning: Function parameter or member 'of_match_table' not described in 'w1_family'
fs/direct-io.c:257: warning: Excess function parameter 'offset' description in 'dio_complete'
fs/file_table.c:1: warning: no structured comments found
fs/libfs.c:477: warning: Excess function parameter 'available' description in 'simple_write_end'
fs/posix_acl.c:646: warning: Function parameter or member 'inode' not described in 'posix_acl_update_mode'
fs/posix_acl.c:646: warning: Function parameter or member 'mode_p' not described in 'posix_acl_update_mode'
fs/posix_acl.c:646: warning: Function parameter or member 'acl' not described in 'posix_acl_update_mode'
drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:183: warning: Function parameter or member 'blockable' not described in 'amdgpu_mn_read_lock'
drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:254: warning: Function parameter or member 'blockable' not described in 'amdgpu_mn_invalidate_range_start_gfx'
drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:302: warning: Function parameter or member 'blockable' not described in 'amdgpu_mn_invalidate_range_start_hsa'
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:3011: warning: Excess function parameter 'dev' description in 'amdgpu_vm_get_task_info'
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:3012: warning: Function parameter or member 'adev' not described in 'amdgpu_vm_get_task_info'
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:3012: warning: Excess function parameter 'dev' description in 'amdgpu_vm_get_task_info'
include/drm/drm_drv.h:610: warning: Function parameter or member 'gem_prime_pin' not described in 'drm_driver'
include/drm/drm_drv.h:610: warning: Function parameter or member 'gem_prime_unpin' not described in 'drm_driver'
include/drm/drm_drv.h:610: warning: Function parameter or member 'gem_prime_res_obj' not described in 'drm_driver'
include/drm/drm_drv.h:610: warning: Function parameter or member 'gem_prime_get_sg_table' not described in 'drm_driver'
include/drm/drm_drv.h:610: warning: Function parameter or member 'gem_prime_import_sg_table' not described in 'drm_driver'
include/drm/drm_drv.h:610: warning: Function parameter or member 'gem_prime_vmap' not described in 'drm_driver'
include/drm/drm_drv.h:610: warning: Function parameter or member 'gem_prime_vunmap' not described in 'drm_driver'
include/drm/drm_drv.h:610: warning: Function parameter or member 'gem_prime_mmap' not described in 'drm_driver'
drivers/gpu/drm/i915/i915_vma.h:49: warning: cannot understand function prototype: 'struct i915_vma '
drivers/gpu/drm/i915/i915_vma.h:1: warning: no structured comments found
drivers/gpu/drm/i915/intel_guc_fwif.h:553: warning: cannot understand function prototype: 'struct guc_log_buffer_state '
drivers/gpu/drm/i915/i915_trace.h:1: warning: no structured comments found
include/media/v4l2-subdev.h:726: warning: Function parameter or member 'get_routing' not described in 'v4l2_subdev_pad_ops'
include/media/v4l2-subdev.h:726: warning: Function parameter or member 'set_routing' not described in 'v4l2_subdev_pad_ops'
include/linux/skbuff.h:860: warning: Function parameter or member 'dev_scratch' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member 'list' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member 'ip_defrag_offset' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member 'skb_mstamp' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member '__cloned_offset' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member 'head_frag' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member '__pkt_type_offset' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member 'encapsulation' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member 'encap_hdr_csum' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member 'csum_valid' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member 'csum_complete_sw' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member 'csum_level' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member 'inner_protocol_type' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member 'remcsum_offload' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member 'offload_fwd_mark' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member 'offload_mr_fwd_mark' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member 'sender_cpu' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member 'reserved_tailroom' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member 'inner_ipproto' not described in 'sk_buff'
include/net/sock.h:238: warning: Function parameter or member 'skc_addrpair' not described in 'sock_common'
include/net/sock.h:238: warning: Function parameter or member 'skc_portpair' not described in 'sock_common'
include/net/sock.h:238: warning: Function parameter or member 'skc_ipv6only' not described in 'sock_common'
include/net/sock.h:238: warning: Function parameter or member 'skc_net_refcnt' not described in 'sock_common'
include/net/sock.h:238: warning: Function parameter or member 'skc_v6_daddr' not described in 'sock_common'
include/net/sock.h:238: warning: Function parameter or member 'skc_v6_rcv_saddr' not described in 'sock_common'
include/net/sock.h:238: warning: Function parameter or member 'skc_cookie' not described in 'sock_common'
include/net/sock.h:238: warning: Function parameter or member 'skc_listener' not described in 'sock_common'
include/net/sock.h:238: warning: Function parameter or member 'skc_tw_dr' not described in 'sock_common'
include/net/sock.h:238: warning: Function parameter or member 'skc_rcv_wnd' not described in 'sock_common'
include/net/sock.h:238: warning: Function parameter or member 'skc_tw_rcv_nxt' not described in 'sock_common'
include/net/sock.h:509: warning: Function parameter or member 'sk_backlog.rmem_alloc' not described in 'sock'
include/net/sock.h:509: warning: Function parameter or member 'sk_backlog.len' not described in 'sock'
include/net/sock.h:509: warning: Function parameter or member 'sk_backlog.head' not described in 'sock'
include/net/sock.h:509: warning: Function parameter or member 'sk_backlog.tail' not described in 'sock'
include/net/sock.h:509: warning: Function parameter or member 'sk_wq_raw' not described in 'sock'
include/net/sock.h:509: warning: Function parameter or member 'tcp_rtx_queue' not described in 'sock'
include/net/sock.h:509: warning: Function parameter or member 'sk_route_forced_caps' not described in 'sock'
include/net/sock.h:509: warning: Function parameter or member 'sk_txtime_report_errors' not described in 'sock'
include/net/sock.h:509: warning: Function parameter or member 'sk_validate_xmit_skb' not described in 'sock'
include/linux/netdevice.h:2021: warning: Function parameter or member 'adj_list.upper' not described in 'net_device'
include/linux/netdevice.h:2021: warning: Function parameter or member 'adj_list.lower' not described in 'net_device'
include/linux/netdevice.h:2021: warning: Function parameter or member 'gso_partial_features' not described in 'net_device'
include/linux/netdevice.h:2021: warning: Function parameter or member 'switchdev_ops' not described in 'net_device'
include/linux/netdevice.h:2021: warning: Function parameter or member 'l3mdev_ops' not described in 'net_device'
include/linux/netdevice.h:2021: warning: Function parameter or member 'xfrmdev_ops' not described in 'net_device'
include/linux/netdevice.h:2021: warning: Function parameter or member 'tlsdev_ops' not described in 'net_device'
include/linux/netdevice.h:2021: warning: Function parameter or member 'name_assign_type' not described in 'net_device'
include/linux/netdevice.h:2021: warning: Function parameter or member 'ieee802154_ptr' not described in 'net_device'
include/linux/netdevice.h:2021: warning: Function parameter or member 'mpls_ptr' not described in 'net_device'
include/linux/netdevice.h:2021: warning: Function parameter or member 'xdp_prog' not described in 'net_device'
include/linux/netdevice.h:2021: warning: Function parameter or member 'gro_flush_timeout' not described in 'net_device'
include/linux/netdevice.h:2021: warning: Function parameter or member 'nf_hooks_ingress' not described in 'net_device'
include/linux/netdevice.h:2021: warning: Function parameter or member '____cacheline_aligned_in_smp' not described in 'net_device'
include/linux/netdevice.h:2021: warning: Function parameter or member 'qdisc_hash' not described in 'net_device'
include/linux/netdevice.h:2021: warning: Function parameter or member 'xps_cpus_map' not described in 'net_device'
include/linux/netdevice.h:2021: warning: Function parameter or member 'xps_rxqs_map' not described in 'net_device'
include/linux/phylink.h:56: warning: Function parameter or member '__ETHTOOL_DECLARE_LINK_MODE_MASK(advertising' not described in 'phylink_link_state'
include/linux/phylink.h:56: warning: Function parameter or member '__ETHTOOL_DECLARE_LINK_MODE_MASK(lp_advertising' not described in 'phylink_link_state'
sound/soc/soc-core.c:2918: warning: Excess function parameter 'legacy_dai_naming' description in 'snd_soc_register_dais'
Documentation/admin-guide/cgroup-v2.rst:1485: WARNING: Block quote ends without a blank line; unexpected unindent.
Documentation/admin-guide/cgroup-v2.rst:1487: WARNING: Block quote ends without a blank line; unexpected unindent.
Documentation/admin-guide/cgroup-v2.rst:1488: WARNING: Block quote ends without a blank line; unexpected unindent.
Documentation/core-api/boot-time-mm.rst:78: WARNING: Error in "kernel-doc" directive:
unknown option: "nodocs".
vim +1228 drivers/usb/dwc3/core.h
72246da40f3719 Felipe Balbi 2011-08-19 @1228
:::::: The code at line 1228 was first introduced by commit
:::::: 72246da40f3719af3bfd104a2365b32537c27d83 usb: Introduce DesignWare USB3 DRD Driver
:::::: TO: Felipe Balbi <balbi@ti.com>
:::::: CC: Greg Kroah-Hartman <gregkh@suse.de>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 6607 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [EXT] Re: [v2] ACPI: support for NXP i2c controller
From: Biwen Li @ 2019-09-11 6:23 UTC (permalink / raw)
To: 'Andy Shevchenko'
Cc: Wolfram Sang, Sascha Hauer, Udit Kumar, Rafael J. Wysocki,
Linux Kernel Mailing List, Leo Li, ACPI Devel Maling List,
Meenakshi Aggarwal, linux-i2c, Chuanhua Han, Rafael J. Wysocki,
Shawn Guo, linux-arm Mailing List
In-Reply-To: <CAHp75Vcz+ruwvq_yu6Oj69XTezsdnne049Ma=oTRPjRXJKnhPQ@mail.gmail.com>
、>
> Caution: EXT Email
>
> On Fri, Sep 6, 2019 at 11:03 AM Biwen Li <biwen.li@nxp.com> wrote:
> >
> > From: Chuanhua Han <chuanhua.han@nxp.com>
> >
> > Enable NXP i2c controller to boot with ACPI
> >
>
> Thanks, the code looks good to me,
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
>
> though...
>
> > Signed-off-by: Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com>
> > Signed-off-by: Udit Kumar <udit.kumar@nxp.com>
> > Signed-off-by: Chuanhua Han <chuanhua.han@nxp.com>
>
> This SoB chain is a bit odd. Who is the author of this? The first SoB in the chain
> usually points to the first (main) author. There is also possible to change that,
> though in that case for the rest we now use Co-developed-by tag rather than
> SoB.
> In any case, if Rafael and Wolfram are okay with this, I have no objections.
Thanks.
>
> > Signed-off-by: Biwen Li <biwen.li@nxp.com>
> > ---
> > Change in v2:
> > - Simplify code
> > - Adjust header file order
> > - Not use ACPI_PTR()
> >
> > drivers/acpi/acpi_apd.c | 7 +++++++
> > drivers/i2c/busses/i2c-imx.c | 17 +++++++++++++----
> > 2 files changed, 20 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/acpi/acpi_apd.c b/drivers/acpi/acpi_apd.c index
> > 7cd0c9ac71ea..71511ae2dfcd 100644
> > --- a/drivers/acpi/acpi_apd.c
> > +++ b/drivers/acpi/acpi_apd.c
> > @@ -160,11 +160,17 @@ static const struct apd_device_desc
> hip08_i2c_desc = {
> > .setup = acpi_apd_setup,
> > .fixed_clk_rate = 250000000,
> > };
> > +
> > static const struct apd_device_desc thunderx2_i2c_desc = {
> > .setup = acpi_apd_setup,
> > .fixed_clk_rate = 125000000,
> > };
> >
> > +static const struct apd_device_desc nxp_i2c_desc = {
> > + .setup = acpi_apd_setup,
> > + .fixed_clk_rate = 350000000,
> > +};
> > +
> > static const struct apd_device_desc hip08_spi_desc = {
> > .setup = acpi_apd_setup,
> > .fixed_clk_rate = 250000000,
> > @@ -238,6 +244,7 @@ static const struct acpi_device_id
> acpi_apd_device_ids[] = {
> > { "HISI02A1", APD_ADDR(hip07_i2c_desc) },
> > { "HISI02A2", APD_ADDR(hip08_i2c_desc) },
> > { "HISI0173", APD_ADDR(hip08_spi_desc) },
> > + { "NXP0001", APD_ADDR(nxp_i2c_desc) },
> > #endif
> > { }
> > };
> > diff --git a/drivers/i2c/busses/i2c-imx.c
> > b/drivers/i2c/busses/i2c-imx.c index 15f6cde6452f..a3b61336fe55 100644
> > --- a/drivers/i2c/busses/i2c-imx.c
> > +++ b/drivers/i2c/busses/i2c-imx.c
> > @@ -20,6 +20,7 @@
> > *
> > */
> >
> > +#include <linux/acpi.h>
> > #include <linux/clk.h>
> > #include <linux/completion.h>
> > #include <linux/delay.h>
> > @@ -255,6 +256,12 @@ static const struct of_device_id i2c_imx_dt_ids[]
> > = { }; MODULE_DEVICE_TABLE(of, i2c_imx_dt_ids);
> >
> > +static const struct acpi_device_id i2c_imx_acpi_ids[] = {
> > + {"NXP0001", .driver_data = (kernel_ulong_t)&vf610_i2c_hwdata},
> > + { }
> > +};
> > +MODULE_DEVICE_TABLE(acpi, i2c_imx_acpi_ids);
> > +
> > static inline int is_imx1_i2c(struct imx_i2c_struct *i2c_imx) {
> > return i2c_imx->hwdata->devtype == IMX1_I2C; @@ -1048,14
> > +1055,13 @@ static const struct i2c_algorithm i2c_imx_algo = {
> >
> > static int i2c_imx_probe(struct platform_device *pdev) {
> > - const struct of_device_id *of_id = of_match_device(i2c_imx_dt_ids,
> > -
> &pdev->dev);
> > struct imx_i2c_struct *i2c_imx;
> > struct resource *res;
> > struct imxi2c_platform_data *pdata =
> dev_get_platdata(&pdev->dev);
> > void __iomem *base;
> > int irq, ret;
> > dma_addr_t phy_addr;
> > + const struct imx_i2c_hwdata *match;
> >
> > dev_dbg(&pdev->dev, "<%s>\n", __func__);
> >
> > @@ -1075,8 +1081,9 @@ static int i2c_imx_probe(struct platform_device
> *pdev)
> > if (!i2c_imx)
> > return -ENOMEM;
> >
> > - if (of_id)
> > - i2c_imx->hwdata = of_id->data;
> > + match = device_get_match_data(&pdev->dev);
> > + if (match)
> > + i2c_imx->hwdata = match;
> > else
> > i2c_imx->hwdata = (struct imx_i2c_hwdata *)
> >
> platform_get_device_id(pdev)->driver_data;
> > @@ -1089,6 +1096,7 @@ static int i2c_imx_probe(struct platform_device
> *pdev)
> > i2c_imx->adapter.nr = pdev->id;
> > i2c_imx->adapter.dev.of_node = pdev->dev.of_node;
> > i2c_imx->base = base;
> > + ACPI_COMPANION_SET(&i2c_imx->adapter.dev,
> ACPI_COMPANION(&pdev->dev));
> >
> > /* Get I2C clock */
> > i2c_imx->clk = devm_clk_get(&pdev->dev, NULL);
> > @@ -1247,6 +1255,7 @@ static struct platform_driver i2c_imx_driver = {
> > .name = DRIVER_NAME,
> > .pm = &i2c_imx_pm_ops,
> > .of_match_table = i2c_imx_dt_ids,
> > + .acpi_match_table = i2c_imx_acpi_ids,
> > },
> > .id_table = imx_i2c_devtype,
> > };
> > --
> > 2.17.1
> >
>
>
> --
> With Best Regards,
> Andy Shevchenko
_______________________________________________
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 3/4] ARM: imx_v6_v7_defconfig: Enable CONFIG_IMX7ULP_WDT by default
From: Shawn Guo @ 2019-09-11 6:24 UTC (permalink / raw)
To: Anson Huang
Cc: mark.rutland, devicetree, leonard.crestez, schnitzeltony,
linux-watchdog, otavio, s.hauer, jan.tuerk, linux, linux-kernel,
robh+dt, linux-arm-kernel, kernel, u.kleine-koenig, wim, festevam,
linux, Linux-imx
In-Reply-To: <1566441463-11911-3-git-send-email-Anson.Huang@nxp.com>
On Wed, Aug 21, 2019 at 10:37:42PM -0400, Anson Huang wrote:
> Select CONFIG_IMX7ULP_WDT by default to support i.MX7ULP watchdog.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Patch #4 and #5 look good to me, and I will pick them up once the first
3 get applied by Guenter.
Shawn
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [v2] ACPI: support for NXP i2c controller
From: Biwen Li @ 2019-09-11 6:25 UTC (permalink / raw)
To: Biwen Li, andy.shevchenko@gmail.com, rafael@kernel.org, Leo Li,
Meenakshi Aggarwal, Udit Kumar, wsa@the-dreams.de,
rjw@rjwysocki.net
Cc: s.hauer@pengutronix.de, linux-kernel@vger.kernel.org,
linux-acpi@vger.kernel.org, linux-i2c@vger.kernel.org,
Chuanhua Han, shawnguo@kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190906075319.21244-1-biwen.li@nxp.com>
Hi rafael, wolfram
Any comments about this?
>
> Enable NXP i2c controller to boot with ACPI
>
> Signed-off-by: Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com>
> Signed-off-by: Udit Kumar <udit.kumar@nxp.com>
> Signed-off-by: Chuanhua Han <chuanhua.han@nxp.com>
> Signed-off-by: Biwen Li <biwen.li@nxp.com>
> ---
> Change in v2:
> - Simplify code
> - Adjust header file order
> - Not use ACPI_PTR()
>
> drivers/acpi/acpi_apd.c | 7 +++++++
> drivers/i2c/busses/i2c-imx.c | 17 +++++++++++++----
> 2 files changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/acpi_apd.c b/drivers/acpi/acpi_apd.c index
> 7cd0c9ac71ea..71511ae2dfcd 100644
> --- a/drivers/acpi/acpi_apd.c
> +++ b/drivers/acpi/acpi_apd.c
> @@ -160,11 +160,17 @@ static const struct apd_device_desc hip08_i2c_desc
> = {
> .setup = acpi_apd_setup,
> .fixed_clk_rate = 250000000,
> };
> +
> static const struct apd_device_desc thunderx2_i2c_desc = {
> .setup = acpi_apd_setup,
> .fixed_clk_rate = 125000000,
> };
>
> +static const struct apd_device_desc nxp_i2c_desc = {
> + .setup = acpi_apd_setup,
> + .fixed_clk_rate = 350000000,
> +};
> +
> static const struct apd_device_desc hip08_spi_desc = {
> .setup = acpi_apd_setup,
> .fixed_clk_rate = 250000000,
> @@ -238,6 +244,7 @@ static const struct acpi_device_id acpi_apd_device_ids[]
> = {
> { "HISI02A1", APD_ADDR(hip07_i2c_desc) },
> { "HISI02A2", APD_ADDR(hip08_i2c_desc) },
> { "HISI0173", APD_ADDR(hip08_spi_desc) },
> + { "NXP0001", APD_ADDR(nxp_i2c_desc) },
> #endif
> { }
> };
> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c index
> 15f6cde6452f..a3b61336fe55 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -20,6 +20,7 @@
> *
> */
>
> +#include <linux/acpi.h>
> #include <linux/clk.h>
> #include <linux/completion.h>
> #include <linux/delay.h>
> @@ -255,6 +256,12 @@ static const struct of_device_id i2c_imx_dt_ids[] =
> { }; MODULE_DEVICE_TABLE(of, i2c_imx_dt_ids);
>
> +static const struct acpi_device_id i2c_imx_acpi_ids[] = {
> + {"NXP0001", .driver_data = (kernel_ulong_t)&vf610_i2c_hwdata},
> + { }
> +};
> +MODULE_DEVICE_TABLE(acpi, i2c_imx_acpi_ids);
> +
> static inline int is_imx1_i2c(struct imx_i2c_struct *i2c_imx) {
> return i2c_imx->hwdata->devtype == IMX1_I2C; @@ -1048,14 +1055,13
> @@ static const struct i2c_algorithm i2c_imx_algo = {
>
> static int i2c_imx_probe(struct platform_device *pdev) {
> - const struct of_device_id *of_id = of_match_device(i2c_imx_dt_ids,
> - &pdev->dev);
> struct imx_i2c_struct *i2c_imx;
> struct resource *res;
> struct imxi2c_platform_data *pdata = dev_get_platdata(&pdev->dev);
> void __iomem *base;
> int irq, ret;
> dma_addr_t phy_addr;
> + const struct imx_i2c_hwdata *match;
>
> dev_dbg(&pdev->dev, "<%s>\n", __func__);
>
> @@ -1075,8 +1081,9 @@ static int i2c_imx_probe(struct platform_device
> *pdev)
> if (!i2c_imx)
> return -ENOMEM;
>
> - if (of_id)
> - i2c_imx->hwdata = of_id->data;
> + match = device_get_match_data(&pdev->dev);
> + if (match)
> + i2c_imx->hwdata = match;
> else
> i2c_imx->hwdata = (struct imx_i2c_hwdata *)
> platform_get_device_id(pdev)->driver_data;
> @@ -1089,6 +1096,7 @@ static int i2c_imx_probe(struct platform_device
> *pdev)
> i2c_imx->adapter.nr = pdev->id;
> i2c_imx->adapter.dev.of_node = pdev->dev.of_node;
> i2c_imx->base = base;
> + ACPI_COMPANION_SET(&i2c_imx->adapter.dev,
> ACPI_COMPANION(&pdev->dev));
>
> /* Get I2C clock */
> i2c_imx->clk = devm_clk_get(&pdev->dev, NULL); @@ -1247,6 +1255,7
> @@ static struct platform_driver i2c_imx_driver = {
> .name = DRIVER_NAME,
> .pm = &i2c_imx_pm_ops,
> .of_match_table = i2c_imx_dt_ids,
> + .acpi_match_table = i2c_imx_acpi_ids,
> },
> .id_table = imx_i2c_devtype,
> };
> --
> 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
* [PATCH v1 1/2] block: bypass blk_set_runtime_active for uninitialized q->dev
From: Stanley Chu @ 2019-09-11 6:32 UTC (permalink / raw)
To: linux-scsi, linux-block, martin.petersen, axboe, jejb,
matthias.bgg
Cc: andy.teng, chun-hung.wu, kuohong.wang, linux-mediatek, peter.wang,
Stanley Chu, linux-arm-kernel
In-Reply-To: <1568183562-18241-1-git-send-email-stanley.chu@mediatek.com>
Some devices may skip blk_pm_runtime_init() and have null pointer
in its request_queue->dev. For example, SCSI devices of UFS Well-Known
LUNs.
Currently the null pointer is checked by the user of
blk_set_runtime_active(), i.e., scsi_dev_type_resume(). It is better to
check it by blk_set_runtime_active() itself instead of by its users.
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
---
block/blk-pm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/block/blk-pm.c b/block/blk-pm.c
index 0a028c189897..56ed94f7a2a3 100644
--- a/block/blk-pm.c
+++ b/block/blk-pm.c
@@ -207,6 +207,9 @@ EXPORT_SYMBOL(blk_post_runtime_resume);
*/
void blk_set_runtime_active(struct request_queue *q)
{
+ if (!q->dev)
+ return;
+
spin_lock_irq(&q->queue_lock);
q->rpm_status = RPM_ACTIVE;
pm_runtime_mark_last_busy(q->dev);
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1] fixup null q->dev checking in both block and scsi layer
From: Stanley Chu @ 2019-09-11 6:32 UTC (permalink / raw)
To: linux-scsi, linux-block, martin.petersen, axboe, jejb,
matthias.bgg
Cc: andy.teng, chun-hung.wu, kuohong.wang, linux-mediatek, peter.wang,
Stanley Chu, linux-arm-kernel
Some devices may skip blk_pm_runtime_init() and have null pointer
in its request_queue->dev. For example, SCSI devices of UFS Well-Known
LUNs.
Currently the null pointer is checked by the user of
blk_set_runtime_active(), i.e., scsi_dev_type_resume(). It is better to
check it by blk_set_runtime_active() itself instead of by its users.
Stanley Chu (2):
block: bypass blk_set_runtime_active for uninitialized q->dev
scsi: core: remove dummy q->dev check
block/blk-pm.c | 3 +++
drivers/scsi/scsi_pm.c | 3 +--
2 files changed, 4 insertions(+), 2 deletions(-)
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v1 2/2] scsi: core: remove dummy q->dev check
From: Stanley Chu @ 2019-09-11 6:32 UTC (permalink / raw)
To: linux-scsi, linux-block, martin.petersen, axboe, jejb,
matthias.bgg
Cc: andy.teng, chun-hung.wu, kuohong.wang, linux-mediatek, peter.wang,
Stanley Chu, linux-arm-kernel
In-Reply-To: <1568183562-18241-1-git-send-email-stanley.chu@mediatek.com>
Currently blk_set_runtime_active() is checking if q->dev is null by
itself, thus remove the same checking in its user: scsi_dev_type_resume().
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
---
drivers/scsi/scsi_pm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/scsi/scsi_pm.c b/drivers/scsi/scsi_pm.c
index 74ded5f3c236..3717eea37ecb 100644
--- a/drivers/scsi/scsi_pm.c
+++ b/drivers/scsi/scsi_pm.c
@@ -94,8 +94,7 @@ static int scsi_dev_type_resume(struct device *dev,
if (!err && scsi_is_sdev_device(dev)) {
struct scsi_device *sdev = to_scsi_device(dev);
- if (sdev->request_queue->dev)
- blk_set_runtime_active(sdev->request_queue);
+ blk_set_runtime_active(sdev->request_queue);
}
}
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] clk: at91: allow 24 Mhz clock as input for PLL
From: Eugen.Hristev @ 2019-09-11 6:39 UTC (permalink / raw)
To: mturquette, sboyd, alexandre.belloni, linux-clk, linux-arm-kernel,
linux-kernel
Cc: Eugen.Hristev
From: Eugen Hristev <eugen.hristev@microchip.com>
The PLL input range needs to be able to allow 24 Mhz crystal as input
Update the range accordingly in plla characteristics struct
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
---
drivers/clk/at91/sama5d2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/at91/sama5d2.c b/drivers/clk/at91/sama5d2.c
index 6509d09..0de1108 100644
--- a/drivers/clk/at91/sama5d2.c
+++ b/drivers/clk/at91/sama5d2.c
@@ -21,7 +21,7 @@ static const struct clk_range plla_outputs[] = {
};
static const struct clk_pll_characteristics plla_characteristics = {
- .input = { .min = 12000000, .max = 12000000 },
+ .input = { .min = 12000000, .max = 24000000 },
.num_output = ARRAY_SIZE(plla_outputs),
.output = plla_outputs,
.icpll = plla_icpll,
--
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
* [PATCH 0/3] USB: host: ohci-at91: tailor power consumption
From: Nicolas Ferre @ 2019-09-11 6:41 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, stern, gregkh
Cc: Boris.Krasnovskiy, Alexandre Belloni, linux-usb,
Ludovic Desroches
Following a set of experiments we found areas of improvement for OHCI power
consumption (and associated USB analog cells).
This enhances the shutdown of residual power consumption in case of Linux
suspend/resume and removal of the driver (when compiled as a module).
Best regards,
Nicolas
Boris Krasnovskiy (2):
USB: host: ohci-at91: completely shutdown the controller in
at91_stop_hc()
USB: host: ohci-at91: resume: balance the clock start call
Nicolas Ferre (1):
USB: host: ohci-at91: suspend: delay needed before to stop clocks
drivers/usb/host/ohci-at91.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--
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
* [PATCH 2/3] USB: host: ohci-at91: suspend: delay needed before to stop clocks
From: Nicolas Ferre @ 2019-09-11 6:41 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, stern, gregkh
Cc: Boris.Krasnovskiy, Alexandre Belloni, linux-usb,
Ludovic Desroches
In-Reply-To: <20190911064154.28633-1-nicolas.ferre@microchip.com>
In order to completely remove marginal power consumption in PM suspend,
we need to let the controller settle down before being stopped.
In ohci_hcd_at91_drv_suspend() function, one additional delay is needed before
to stop the clocks.
Reported-by: Boris Krasnovskiy <Boris.Krasnovskiy@lairdconnect.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
---
drivers/usb/host/ohci-at91.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index cb63bcd5049a..85d67fe42d59 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -628,6 +628,7 @@ ohci_hcd_at91_drv_suspend(struct device *dev)
/* flush the writes */
(void) ohci_readl (ohci, &ohci->regs->control);
+ msleep(1);
at91_stop_clock(ohci_at91);
}
--
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 related
* [PATCH 1/3] USB: host: ohci-at91: completely shutdown the controller in at91_stop_hc()
From: Nicolas Ferre @ 2019-09-11 6:41 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, stern, gregkh
Cc: Boris.Krasnovskiy, Alexandre Belloni, linux-usb,
Ludovic Desroches
In-Reply-To: <20190911064154.28633-1-nicolas.ferre@microchip.com>
From: Boris Krasnovskiy <Boris.Krasnovskiy@lairdconnect.com>
When removing the ohci-at91 module, the fact of not running complete shutdown
of all the ports was keeping additional analog cells consuming power for no
reason.
Doing Reset (OHCI_HCR) to HcCommandStatus register is the way to go, but using
the OHCI controller shutdown procedure is just perfect for this.
Signed-off-by: Boris Krasnovskiy <Boris.Krasnovskiy@lairdconnect.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
---
drivers/usb/host/ohci-at91.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index fc35a7993b7b..cb63bcd5049a 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -123,7 +123,7 @@ static void at91_stop_hc(struct platform_device *pdev)
/*
* Put the USB host controller into reset.
*/
- writel(0, ®s->control);
+ usb_hcd_platform_shutdown(pdev);
/*
* Stop the USB clocks.
--
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 related
* [PATCH 3/3] USB: host: ohci-at91: resume: balance the clock start call
From: Nicolas Ferre @ 2019-09-11 6:41 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, stern, gregkh
Cc: Boris.Krasnovskiy, Alexandre Belloni, linux-usb,
Ludovic Desroches
In-Reply-To: <20190911064154.28633-1-nicolas.ferre@microchip.com>
From: Boris Krasnovskiy <Boris.Krasnovskiy@lairdconnect.com>
There is a clock enable counter run away problem in resume ohci_at91. Code
enables clock that was never disabled in case of non wakeup interface. That
would make clock unstoppable in future.
Use proper alternative to start clocks only if they were stopped before.
Signed-off-by: Boris Krasnovskiy <Boris.Krasnovskiy@lairdconnect.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
---
drivers/usb/host/ohci-at91.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 85d67fe42d59..513e48397743 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -643,8 +643,8 @@ ohci_hcd_at91_drv_resume(struct device *dev)
if (ohci_at91->wakeup)
disable_irq_wake(hcd->irq);
-
- at91_start_clock(ohci_at91);
+ else
+ at91_start_clock(ohci_at91);
ohci_resume(hcd, false);
--
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 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