Re: [PATCH v1 2/5] dt-bindings: mailbox: add binding for Microchip IPC mailbox driver
On Wed, Sep 18, 2024 at 10:35:58AM -0500, Rob Herring wrote: > On Mon, Sep 16, 2024 at 05:31:36PM +0100, Conor Dooley wrote: > > On Thu, Sep 12, 2024 at 04:23:44PM -0500, Samuel Holland wrote: > > > Hi Valentina, > > > > > > On 2024-09-12 12:00 PM, Valentina Fernandez wrote: > > > > Add a dt-binding for the Microchip Inter-Processor Communication (IPC) > > > > mailbox controller. > > > > > > > > Signed-off-by: Valentina Fernandez > > > > > > > > --- > > > > .../bindings/mailbox/microchip,sbi-ipc.yaml | 115 ++ > > > > 1 file changed, 115 insertions(+) > > > > create mode 100644 > > > > Documentation/devicetree/bindings/mailbox/microchip,sbi-ipc.yaml > > > > > > > > diff --git > > > > a/Documentation/devicetree/bindings/mailbox/microchip,sbi-ipc.yaml > > > > b/Documentation/devicetree/bindings/mailbox/microchip,sbi-ipc.yaml > > > > new file mode 100644 > > > > index ..dc2cbd5eb28f > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/mailbox/microchip,sbi-ipc.yaml > > > > @@ -0,0 +1,115 @@ > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > +%YAML 1.2 > > > > +--- > > > > +$id: http://devicetree.org/schemas/mailbox/microchip,sbi-ipc.yaml# > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > + > > > > +title: Microchip Inter-processor communication (IPC) mailbox controller > > > > + > > > > +maintainers: > > > > + - Valentina Fernandez > > > > + > > > > +description: > > > > + The Microchip Inter-processor Communication (IPC) facilitates > > > > + message passing between processors using an interrupt signaling > > > > + mechanism. > > > > + This SBI interface is compatible with the Mi-V Inter-hart > > > > + Communication (IHC) IP. > > > > + The microchip,sbi-ipc compatible string is inteded for use by > > > > software > > > > + running in supervisor privileged mode (s-mode). The SoC-specific > > > > + compatibles are inteded for use by the SBI implementation in machine > > > > + mode (m-mode). > > > > > > There is a lot of conditional logic in this binding for how small it is. > > > Would > > > it make sense to split this into two separate bindings? For example, with > > > the > > > current binding microchip,ihc-chan-disabled-mask is allowed for the SBI > > > interface, but doesn't look like it belongs there. > > > > I dunno. Part of me says that because this is two compatibles for the > > same piece of hardware (the choice depending on which programming model > > you use) they should be documented together. The other part of me is of > > the opinion that they effectively describe different things, given one > > describes the hardware and the other describes a firmware interface that > > may have any sort of hardware backing it. > > > > I suppose it's more of a problem for "us" (that being me/Rob/Krzysztof) > > than for Valentina, and how to handle firmware interfaces to hardware > > like this is one of the topics that's planned for Krzysztof's devicetree > > BoF session at LPC. > > If how the client interacts with the device is fundamentally different, > then I think different compatibles is fine. It wasn't about different compatibles (which I think are non-debatable here) it's whether or not the different compatibles should be in their own binding files. signature.asc Description: PGP signature
Re: [PATCH v1 0/5] Add Microchip IPC mailbox and remoteproc support
On Tue, Sep 17, 2024 at 10:45:02AM +, valentina.fernandezala...@microchip.com wrote: > On 16/09/2024 23:28, Bo Gan wrote: > > Perhaps checking-in > > the microchip SBI extensions to major SBI implementations such as openSBI > > first would be better? It's worth pointing out that the "major SBI implementations" do not support the platform this is currently being used on. signature.asc Description: PGP signature
Re: [PATCH v1 2/5] dt-bindings: mailbox: add binding for Microchip IPC mailbox driver
On Thu, Sep 12, 2024 at 04:23:44PM -0500, Samuel Holland wrote: > Hi Valentina, > > On 2024-09-12 12:00 PM, Valentina Fernandez wrote: > > Add a dt-binding for the Microchip Inter-Processor Communication (IPC) > > mailbox controller. > > > > Signed-off-by: Valentina Fernandez > > --- > > .../bindings/mailbox/microchip,sbi-ipc.yaml | 115 ++ > > 1 file changed, 115 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/mailbox/microchip,sbi-ipc.yaml > > > > diff --git > > a/Documentation/devicetree/bindings/mailbox/microchip,sbi-ipc.yaml > > b/Documentation/devicetree/bindings/mailbox/microchip,sbi-ipc.yaml > > new file mode 100644 > > index ..dc2cbd5eb28f > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/mailbox/microchip,sbi-ipc.yaml > > @@ -0,0 +1,115 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/mailbox/microchip,sbi-ipc.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Microchip Inter-processor communication (IPC) mailbox controller > > + > > +maintainers: > > + - Valentina Fernandez > > + > > +description: > > + The Microchip Inter-processor Communication (IPC) facilitates > > + message passing between processors using an interrupt signaling > > + mechanism. > > + This SBI interface is compatible with the Mi-V Inter-hart > > + Communication (IHC) IP. > > + The microchip,sbi-ipc compatible string is inteded for use by software > > + running in supervisor privileged mode (s-mode). The SoC-specific > > + compatibles are inteded for use by the SBI implementation in machine > > + mode (m-mode). > > There is a lot of conditional logic in this binding for how small it is. Would > it make sense to split this into two separate bindings? For example, with the > current binding microchip,ihc-chan-disabled-mask is allowed for the SBI > interface, but doesn't look like it belongs there. I dunno. Part of me says that because this is two compatibles for the same piece of hardware (the choice depending on which programming model you use) they should be documented together. The other part of me is of the opinion that they effectively describe different things, given one describes the hardware and the other describes a firmware interface that may have any sort of hardware backing it. I suppose it's more of a problem for "us" (that being me/Rob/Krzysztof) than for Valentina, and how to handle firmware interfaces to hardware like this is one of the topics that's planned for Krzysztof's devicetree BoF session at LPC. Cheers, Conor. signature.asc Description: PGP signature
Re: [PATCH v1 1/5] riscv: asm: vendorid_list: Add Microchip Technology to the vendor list
On Thu, Sep 12, 2024 at 06:00:21PM +0100, Valentina Fernandez wrote: > Add Microchip Technology to the RISC-V vendor list. > > Signed-off-by: Valentina Fernandez In $subject "asm" should probably be "sbi", otherwise: Reviewed-by: Conor Dooley > --- > arch/riscv/include/asm/vendorid_list.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/riscv/include/asm/vendorid_list.h > b/arch/riscv/include/asm/vendorid_list.h > index 2f2bb0c84f9a..a5150cdf34d8 100644 > --- a/arch/riscv/include/asm/vendorid_list.h > +++ b/arch/riscv/include/asm/vendorid_list.h > @@ -6,6 +6,7 @@ > #define ASM_VENDOR_LIST_H > > #define ANDES_VENDOR_ID 0x31e > +#define MICROCHIP_VENDOR_ID 0x029 > #define SIFIVE_VENDOR_ID 0x489 > #define THEAD_VENDOR_ID 0x5b7 > > -- > 2.34.1 > signature.asc Description: PGP signature
Re: [PATCH v1 2/5] dt-bindings: mailbox: add binding for Microchip IPC mailbox driver
On Thu, Sep 12, 2024 at 06:00:22PM +0100, Valentina Fernandez wrote:
> Add a dt-binding for the Microchip Inter-Processor Communication (IPC)
> mailbox controller.
Before anyone else gets here, there's an erroneous "driver" in $subject
:)
> Signed-off-by: Valentina Fernandez
> ---
> .../bindings/mailbox/microchip,sbi-ipc.yaml | 115 ++
> 1 file changed, 115 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/mailbox/microchip,sbi-ipc.yaml
>
> diff --git a/Documentation/devicetree/bindings/mailbox/microchip,sbi-ipc.yaml
> b/Documentation/devicetree/bindings/mailbox/microchip,sbi-ipc.yaml
> new file mode 100644
> index ..dc2cbd5eb28f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/microchip,sbi-ipc.yaml
> @@ -0,0 +1,115 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mailbox/microchip,sbi-ipc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Microchip Inter-processor communication (IPC) mailbox controller
> +
> +maintainers:
> + - Valentina Fernandez
> +
> +description:
> + The Microchip Inter-processor Communication (IPC) facilitates
> + message passing between processors using an interrupt signaling
> + mechanism.
> + This SBI interface is compatible with the Mi-V Inter-hart
> + Communication (IHC) IP.
> + The microchip,sbi-ipc compatible string is inteded for use by software
> + running in supervisor privileged mode (s-mode). The SoC-specific
> + compatibles are inteded for use by the SBI implementation in machine
> + mode (m-mode).
And it might be worth me pointing out to the !riscv folks that "SBI
implementation in machine mode" means that the
"microchip,miv-ihc-rtl-v2" compatible is intended for use by firmware
only.
Cheers,
Conor.
> +
> +properties:
> + compatible:
> +enum:
> + - microchip,sbi-ipc
> + - microchip,miv-ihc-rtl-v2
> +
> + reg:
> +maxItems: 1
> +
> + interrupts:
> +minItems: 1
> +maxItems: 5
> +
> + interrupt-names:
> +minItems: 1
> +maxItems: 5
> +
> + "#mbox-cells":
> +description:
> + For the SBI "device", the cell represents the global "logical" channel
> IDs.
> + The meaning of channel IDs are platform firmware dependent. The
> + SoC-specific compatibles are intended for use by the SBI
> implementation,
> + rather than s-mode software. There the cell would represent the
> physical
> + channel and do not vary depending on platform firmware.
> +const: 1
> +
> + microchip,ihc-chan-disabled-mask:
> +description:
> + Represents the enable/disable state of the bi-directional IHC channels
> + within the MIV-IHC IP configuration. The mask is a 16-bit value, but
> only
> + the first 15 bits are utilized.Each of the bits corresponds to
> + one of the 15 IHC channels.
> + A bit set to '1' indicates that the corresponding channel is disabled,
> + and any read or write operations to that channel will return zero.
> + A bit set to '0' indicates that the corresponding channel is enabled
> + and will be accessible through its dedicated address range registers.
> + The remaining bit of the 16-bit mask is reserved and should be ignored.
> + The actual enable/disable state of each channel is determined by the
> + IP block’s configuration.
> +$ref: /schemas/types.yaml#/definitions/uint16
> +default: 0
> +
> +required:
> + - compatible
> + - interrupts
> + - interrupt-names
> + - "#mbox-cells"
> +
> +additionalProperties: false
> +
> +allOf:
> + - if:
> + properties:
> +compatible:
> + contains:
> +const: microchip,sbi-ipc
> +then:
> + properties:
> +reg: false
> +else:
> + required:
> +- reg
> +
> + - if:
> + properties:
> +compatible:
> + contains:
> +const: microchip,miv-ihc-rtl-v2
> +then:
> + properties:
> +interrupt-names:
> + items:
> +pattern: "^hart-[0-5]+$"
> +
> +examples:
> + - |
> +mailbox {
> + compatible = "microchip,sbi-ipc";
> + interrupt-parent = <&plic>;
> + interrupts = <180>, <179>, <178>;
> + interrupt-names = "hart-1", "hart-2", "hart-3";
> + #mbox-cells = <1>;
> +};
> + - |
> +mailbox@5000 {
> + compatible = "microchip,miv-ihc-rtl-v2";
> + microchip,ihc-chan-disabled-mask= /bits/ 16 <0>;
> + reg = <0x5000 0x1C000>;
> + interrupt-parent = <&plic>;
> + interrupts = <180>, <179>, <178>;
> + interrupt-names = "hart-1", "hart-2", "hart-3";
> + #mbox-cells = <1>;
> +};
> --
> 2.34.1
>
signature.asc
Description: PGP signature
Re: [PATCH 06/15] riscv: migrate to the generic rule for built-in DTB
On Thu, Sep 05, 2024 at 08:47:42AM +0900, Masahiro Yamada wrote: > Select GENERIC_BUILTIN_DTB when built-in DTB support is enabled. > > To keep consistency across architectures, this commit also renames > CONFIG_BUILTIN_DTB_SOURCE to CONFIG_BUILTIN_DTB_NAME. > > Signed-off-by: Masahiro Yamada Acked-by: Conor Dooley signature.asc Description: PGP signature
Re: [PATCH] dt-bindings: remoteproc: xlnx,zynqmp-r5fss: add missing "additionalProperties" on child nodes
On Sun, Aug 11, 2024 at 05:34:38PM +0200, Krzysztof Kozlowski wrote:
> All nodes need an explicit additionalProperties or unevaluatedProperties
> unless a $ref has one that's false. Add missing additionalProperties
> to fix dt_binding_check warning:
>
> xlnx,zynqmp-r5fss.yaml: ^r(.*)@[0-9a-f]+$: Missing
> additionalProperties/unevaluatedProperties constraint
>
> Fixes: 9e1b2a0757d0 ("dt-bindings: remoteproc: Add Tightly Coupled Memory
> (TCM) bindings")
> Signed-off-by: Krzysztof Kozlowski
Acked-by: Conor Dooley
signature.asc
Description: PGP signature
Re: [PATCH] dt-bindings: hwlock: sprd-hwspinlock: convert to YAML
On Wed, Jul 03, 2024 at 02:26:32PM +0200, Stanislav Jakubek wrote:
> +examples:
> + - |
> +#include
> +
> +soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + hwlock@4050 {
> +compatible = "sprd,hwspinlock-r3p0";
nit: double space here before the =
> +reg = <0 0x4050 0 0x1000>;
nit: if there's a respin, drop the 0s and use size/address cells of 1.
Reviewed-by: Conor Dooley
Cheers,
Conor.
signature.asc
Description: PGP signature
Re: [PATCH -fixes] riscv: patch: Flush the icache right after patching to avoid illegal insns
On Mon, Jun 24, 2024 at 10:21:41AM +0200, Alexandre Ghiti wrote:
> We cannot delay the icache flush after patching some functions as we may
> have patched a function that will get called before the icache flush.
>
> The only way to completely avoid such scenario is by flushing the icache
> as soon as we patch a function. This will probably be costly as we don't
> batch the icache maintenance anymore.
>
> Fixes: 6ca445d8af0e ("riscv: Fix early ftrace nop patching")
> Reported-by: Conor Dooley
> Closes:
> https://lore.kernel.org/linux-riscv/20240613-lubricant-breath-061192a9489a@wendy/
> Signed-off-by: Alexandre Ghiti
So, I can't even test this right now :/ The issue is annoying enough to
reproduce that same config + compiler + commit isn't enough.
signature.asc
Description: PGP signature
Re: [PATCH v2 1/3] dt-bindings: arm: qcom: Add Sony Xperia Z3 Compact
On Fri, Jun 21, 2024 at 05:26:42PM +0300, Valeriy Klimin wrote: > Add the compatible for this device. > > Signed-off-by: Valeriy Klimin Acked-by: Conor Dooley signature.asc Description: PGP signature
Re: [PATCH] riscv: Fix early ftrace nop patching
On Thu, May 23, 2024 at 01:51:34PM +0200, Alexandre Ghiti wrote:
> Commit c97bf629963e ("riscv: Fix text patching when IPI are used")
> converted ftrace_make_nop() to use patch_insn_write() which does not
> emit any icache flush relying entirely on __ftrace_modify_code() to do
> that.
>
> But we missed that ftrace_make_nop() was called very early directly when
> converting mcount calls into nops (actually on riscv it converts 2B nops
> emitted by the compiler into 4B nops).
>
> This caused crashes on multiple HW as reported by Conor and Björn since
> the booting core could have half-patched instructions in its icache
> which would trigger an illegal instruction trap: fix this by emitting a
> local flush icache when early patching nops.
>
> Fixes: c97bf629963e ("riscv: Fix text patching when IPI are used")
> Signed-off-by: Alexandre Ghiti
> ---
> arch/riscv/include/asm/cacheflush.h | 6 ++
> arch/riscv/kernel/ftrace.c | 3 +++
> 2 files changed, 9 insertions(+)
>
> diff --git a/arch/riscv/include/asm/cacheflush.h
> b/arch/riscv/include/asm/cacheflush.h
> index dd8d07146116..ce79c558a4c8 100644
> --- a/arch/riscv/include/asm/cacheflush.h
> +++ b/arch/riscv/include/asm/cacheflush.h
> @@ -13,6 +13,12 @@ static inline void local_flush_icache_all(void)
> asm volatile ("fence.i" ::: "memory");
> }
>
> +static inline void local_flush_icache_range(unsigned long start,
> + unsigned long end)
> +{
> + local_flush_icache_all();
> +}
> +
> #define PG_dcache_clean PG_arch_1
>
> static inline void flush_dcache_folio(struct folio *folio)
> diff --git a/arch/riscv/kernel/ftrace.c b/arch/riscv/kernel/ftrace.c
> index 4f4987a6d83d..32e7c401dfb4 100644
> --- a/arch/riscv/kernel/ftrace.c
> +++ b/arch/riscv/kernel/ftrace.c
> @@ -120,6 +120,9 @@ int ftrace_init_nop(struct module *mod, struct dyn_ftrace
> *rec)
> out = ftrace_make_nop(mod, rec, MCOUNT_ADDR);
> mutex_unlock(&text_mutex);
So, turns out that this patch is not sufficient. I've seen some more
crashes, seemingly due to initialising nops on this mutex_unlock().
Palmer suggested moving the if (!mod) ... into the lock, which fixed
the problem for me.
>
> + if (!mod)
> + local_flush_icache_range(rec->ip, rec->ip + MCOUNT_INSN_SIZE);
> +
> return out;
> }
>
> --
> 2.39.2
>
signature.asc
Description: PGP signature
Re: [PATCH v2 1/2] rust: add static_key_false
On Mon, Jun 10, 2024 at 02:01:04PM +, Alice Ryhl wrote:
> Add just enough support for static key so that we can use it from
> tracepoints. Tracepoints rely on `static_key_false` even though it is
> deprecated, so we add the same functionality to Rust.
>
> It is not possible to use the existing C implementation of
> arch_static_branch because it passes the argument `key` to inline
> assembly as an 'i' parameter, so any attempt to add a C helper for this
> function will fail to compile because the value of `key` must be known
> at compile-time.
>
> Signed-off-by: Alice Ryhl
> +#[cfg(target_arch = "x86_64")]
> +#[cfg(target_arch = "aarch64")]
This patch breaks the build on riscv (and I assume loongarch):
error[E0432]: unresolved import `_static_key_false`
--> /stuff/linux/rust/kernel/static_key.rs:87:10
|
87 | pub use {_static_key_false, static_key_false};
| ^ no external crate `_static_key_false`
Cheers,
Conor.
signature.asc
Description: PGP signature
Re: [PATCH] riscv: Fix early ftrace nop patching
On Thu, May 23, 2024 at 01:51:34PM +0200, Alexandre Ghiti wrote:
> Commit c97bf629963e ("riscv: Fix text patching when IPI are used")
> converted ftrace_make_nop() to use patch_insn_write() which does not
> emit any icache flush relying entirely on __ftrace_modify_code() to do
> that.
>
> But we missed that ftrace_make_nop() was called very early directly when
> converting mcount calls into nops (actually on riscv it converts 2B nops
> emitted by the compiler into 4B nops).
>
> This caused crashes on multiple HW as reported by Conor and Björn since
> the booting core could have half-patched instructions in its icache
> which would trigger an illegal instruction trap: fix this by emitting a
> local flush icache when early patching nops.
>
> Fixes: c97bf629963e ("riscv: Fix text patching when IPI are used")
> Signed-off-by: Alexandre Ghiti
Reported-by: Conor Dooley
Tested-by: Conor Dooley
Thanks for the quick fix Alex :)
signature.asc
Description: PGP signature
Re: [PATCH v8 1/4] dt-bindings: remoteproc: k3-m4f: Add K3 AM64x SoCs
On Thu, Apr 25, 2024 at 02:03:36PM -0500, Andrew Davis wrote: > On 4/25/24 12:15 PM, Conor Dooley wrote: > > On Wed, Apr 24, 2024 at 03:36:39PM -0500, Rob Herring wrote: > > > > > > On Wed, 24 Apr 2024 14:06:09 -0500, Andrew Davis wrote: > > > > From: Hari Nagalla > > > > > > > > K3 AM64x SoC has a Cortex M4F subsystem in the MCU voltage domain. > > > > The remote processor's life cycle management and IPC mechanisms are > > > > similar across the R5F and M4F cores from remote processor driver > > > > point of view. However, there are subtle differences in image loading > > > > and starting the M4F subsystems. > > > > > > > > The YAML binding document provides the various node properties to be > > > > configured by the consumers of the M4F subsystem. > > > > > > > > Signed-off-by: Martyn Welch > > > > Signed-off-by: Hari Nagalla > > > > Signed-off-by: Andrew Davis > > > > --- > > > > .../bindings/remoteproc/ti,k3-m4f-rproc.yaml | 126 ++ > > > > 1 file changed, 126 insertions(+) > > > > create mode 100644 > > > > Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml > > > > > > > > > > My bot found errors running 'make dt_binding_check' on your patch: > > > > > > yamllint warnings/errors: > > > > > > dtschema/dtc warnings/errors: > > > > > > > > > doc reference errors (make refcheckdocs): > > > Warning: > > > Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml > > > references a file that doesn't exist: > > > Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml > > > Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml: > > > Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml > > > > The file is now in dt-schema: > > https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/reserved-memory/reserved-memory.yaml > > So should I use "reserved-memory/reserved-memory.yaml" here, or just > drop this line completely? The only other example that I could find that didn't reference the text binding (which points to dt-schema) said: "(see reserved-memory/reserved-memory.yaml in dtschema project)" signature.asc Description: PGP signature
Re: [PATCH v8 1/4] dt-bindings: remoteproc: k3-m4f: Add K3 AM64x SoCs
On Wed, Apr 24, 2024 at 02:06:09PM -0500, Andrew Davis wrote: > From: Hari Nagalla > > K3 AM64x SoC has a Cortex M4F subsystem in the MCU voltage domain. > The remote processor's life cycle management and IPC mechanisms are > similar across the R5F and M4F cores from remote processor driver > point of view. However, there are subtle differences in image loading > and starting the M4F subsystems. > > The YAML binding document provides the various node properties to be > configured by the consumers of the M4F subsystem. > > Signed-off-by: Martyn Welch > Signed-off-by: Hari Nagalla > Signed-off-by: Andrew Davis > + mboxes: > +description: | > + memory-region: > +description: | Not sure that either chomping operator is needed here, but that's a nit. With the incorrect link fixed up, Reviewed-by: Conor Dooley Cheers, Conor. signature.asc Description: PGP signature
Re: [PATCH v8 1/4] dt-bindings: remoteproc: k3-m4f: Add K3 AM64x SoCs
On Wed, Apr 24, 2024 at 03:36:39PM -0500, Rob Herring wrote: > > On Wed, 24 Apr 2024 14:06:09 -0500, Andrew Davis wrote: > > From: Hari Nagalla > > > > K3 AM64x SoC has a Cortex M4F subsystem in the MCU voltage domain. > > The remote processor's life cycle management and IPC mechanisms are > > similar across the R5F and M4F cores from remote processor driver > > point of view. However, there are subtle differences in image loading > > and starting the M4F subsystems. > > > > The YAML binding document provides the various node properties to be > > configured by the consumers of the M4F subsystem. > > > > Signed-off-by: Martyn Welch > > Signed-off-by: Hari Nagalla > > Signed-off-by: Andrew Davis > > --- > > .../bindings/remoteproc/ti,k3-m4f-rproc.yaml | 126 ++ > > 1 file changed, 126 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml > > > > My bot found errors running 'make dt_binding_check' on your patch: > > yamllint warnings/errors: > > dtschema/dtc warnings/errors: > > > doc reference errors (make refcheckdocs): > Warning: Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml > references a file that doesn't exist: > Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml > Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml: > Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml The file is now in dt-schema: https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/reserved-memory/reserved-memory.yaml signature.asc Description: PGP signature
Re: [PATCH v7 2/2] arch/riscv: Enable kprobes when CONFIG_MODULES=n
On Tue, Mar 26, 2024 at 03:46:16PM +0200, Jarkko Sakkinen wrote: > Tacing with kprobes while running a monolithic kernel is currently > impossible due the kernel module allocator dependency. > > Address the issue by implementing textmem API for RISC-V. This doesn't compile for nommu: /build/tmp.3xucsBhqDV/arch/riscv/kernel/execmem.c:10:46: error: 'MODULES_VADDR' undeclared (first use in this function) /build/tmp.3xucsBhqDV/arch/riscv/kernel/execmem.c:11:37: error: 'MODULES_END' undeclared (first use in this function) /build/tmp.3xucsBhqDV/arch/riscv/kernel/execmem.c:14:1: error: control reaches end of non-void function [-Werror=return-type] Clang builds also report: ../arch/riscv/kernel/execmem.c:8:56: warning: omitting the parameter name in a function definition is a C2x extension [-Wc2x-extensions] > > Link: https://www.sochub.fi # for power on testing new SoC's with a minimal > stack > Link: > https://lore.kernel.org/all/2022060814.3054333-1-jar...@profian.com/ # > continuation > Signed-off-by: Jarkko Sakkinen > --- > v5-v7: > - No changes. > v4: > - Include linux/execmem.h. > v3: > - Architecture independent parts have been split to separate patches. > - Do not change arch/riscv/kernel/module.c as it is out of scope for > this patch set now. Meta comment. I dunno when v1 was sent, but versions can you please relax with submitting new versions of your patches? There's conversations ongoing on v5 at the moment, while this is a more recent version. v2 seems to have been sent on the 23rd and there's been 5 versions in the last day: https://patchwork.kernel.org/project/linux-riscv/list/?submitter=195059&state=* Could you please also try and use a cover letter for patchsets, ideally with a consistent subject? Otherwise I have to manually mark stuff as superseded. Thanks, Conor. > v2: > - Better late than never right? :-) > - Focus only to RISC-V for now to make the patch more digestable. This > is the arch where I use the patch on a daily basis to help with QA. > - Introduce HAVE_KPROBES_ALLOC flag to help with more gradual migration. signature.asc Description: PGP signature
Re: [PATCH 1/5] dt-bindings: regulator: qcom,usb-vbus-regulator: Add PM7250B compatible
On Fri, Mar 22, 2024 at 09:01:32AM +0100, Luca Weiss wrote: > The VBUS register block on the PM6150 PMIC shares the design with the > PM8150B one. Define corresponding compatible string, having the > qcom,pm8150b-vbus-reg as a fallback. > > Signed-off-by: Luca Weiss Acked-by: Conor Dooley signature.asc Description: PGP signature
Re: [PATCH 2/5] dt-bindings: usb: qcom,pmic-typec: Add support for the PM7250B PMIC
On Fri, Mar 22, 2024 at 09:01:33AM +0100, Luca Weiss wrote: > The PM6150 PMIC has the same Type-C register block as the PM8150B. > Define corresponding compatible string, having the qcom,pm8150b-vbus-reg > as a fallback. > > Signed-off-by: Luca Weiss Acked-by: Conor Dooley Thanks, Conor. > --- > Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml > b/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml > index d9694570c419..0cdc60b76fbd 100644 > --- a/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml > +++ b/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml > @@ -21,6 +21,7 @@ properties: >- items: >- enum: >- qcom,pm6150-typec > + - qcom,pm7250b-typec >- const: qcom,pm8150b-typec >- items: >- enum: > > -- > 2.44.0 > signature.asc Description: PGP signature
Re: [PATCH 1/3] dt-bindings: remoteproc: add Versal platform support
On Sun, Mar 17, 2024 at 02:50:27PM +, Conor Dooley wrote: > On Fri, Mar 15, 2024 at 02:15:31PM -0700, Tanmay Shah wrote: > > AMD-Xilinx Versal platform is successor of ZynqMP platform. Real-time > > Processor Unit R5 cluster IP on Versal is same as of ZynqMP Platform. > > > Only difference is power-domains ID needed by power management firmware. > > Hence, keeping the compatible property same as of zynqmp node. > > No, don't be lazy. Add a compatible with a fallback please. > This doesn't apply to linux-next either FYI. Ordinarily'd I'd not even bother applying a patch like this and I wouldn't notice, but the diff for the versal-net patch is difficult to read without colour-moved enabled and since I can't apply this I'm not going to review that patch. signature.asc Description: PGP signature
Re: [PATCH 1/3] dt-bindings: remoteproc: add Versal platform support
On Fri, Mar 15, 2024 at 02:15:31PM -0700, Tanmay Shah wrote: > AMD-Xilinx Versal platform is successor of ZynqMP platform. Real-time > Processor Unit R5 cluster IP on Versal is same as of ZynqMP Platform. > Only difference is power-domains ID needed by power management firmware. > Hence, keeping the compatible property same as of zynqmp node. No, don't be lazy. Add a compatible with a fallback please. This doesn't apply to linux-next either FYI. signature.asc Description: PGP signature
Re: [PATCH v3 2/2] riscv: Fix text patching when IPI are used
On Tue, Mar 05, 2024 at 08:33:30AM +0530, Anup Patel wrote: > On Tue, Mar 5, 2024 at 1:54 AM Björn Töpel wrote: > > > > Conor Dooley writes: > > > > > On Thu, Feb 29, 2024 at 01:10:56PM +0100, Alexandre Ghiti wrote: > > >> For now, we use stop_machine() to patch the text and when we use IPIs for > > >> remote icache flushes (which is emitted in patch_text_nosync()), the > > >> system > > >> hangs. > > >> > > >> So instead, make sure every CPU executes the stop_machine() patching > > >> function and emit a local icache flush there. > > >> > > >> Co-developed-by: Björn Töpel > > >> Signed-off-by: Björn Töpel > > >> Signed-off-by: Alexandre Ghiti > > >> Reviewed-by: Andrea Parri > > > > > > What commit does this fix? > > > > Hmm. The bug is exposed when the AIA IPI are introduced, and used > > (instead of the firmware-based). > > > > I'm not sure this is something we'd like backported, but rather a > > prerequisite to AIA. > > > > @Anup @Alex WDYT? > > > > The current text patching never considered IPIs being injected > directly in S-mode from hart to another so we are seeing this > issue now with AIA IPIs. > > We certainly don't need to backport this fix since it's more > of a preparatory fix for AIA IPIs. Whether or not this is backportable, if it fixes a bug, it should get a Fixes: tag for the commit that it fixes. Fixes: isn't "the backport" tag, cc: stable is. signature.asc Description: PGP signature
Re: [PATCH v3 2/2] riscv: Fix text patching when IPI are used
On Thu, Feb 29, 2024 at 01:10:56PM +0100, Alexandre Ghiti wrote: > For now, we use stop_machine() to patch the text and when we use IPIs for > remote icache flushes (which is emitted in patch_text_nosync()), the system > hangs. > > So instead, make sure every CPU executes the stop_machine() patching > function and emit a local icache flush there. > > Co-developed-by: Björn Töpel > Signed-off-by: Björn Töpel > Signed-off-by: Alexandre Ghiti > Reviewed-by: Andrea Parri What commit does this fix? signature.asc Description: PGP signature
Re: [PATCH v3 1/2] riscv: Remove superfluous smp_mb()
On Thu, Feb 29, 2024 at 01:10:55PM +0100, Alexandre Ghiti wrote:
> This memory barrier is not needed and not documented so simply remove
> it.
This looks like it should be patch 2 in the series, not patch 1, as it
is cleanup rather than a fix that needs backporting.
>
> Suggested-by: Andrea Parri
> Signed-off-by: Alexandre Ghiti
> Reviewed-by: Andrea Parri
> ---
> arch/riscv/kernel/patch.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/riscv/kernel/patch.c b/arch/riscv/kernel/patch.c
> index 37e87fdcf6a0..0b5c16dfe3f4 100644
> --- a/arch/riscv/kernel/patch.c
> +++ b/arch/riscv/kernel/patch.c
> @@ -239,7 +239,6 @@ static int patch_text_cb(void *data)
> } else {
> while (atomic_read(&patch->cpu_count) <= num_online_cpus())
> cpu_relax();
> - smp_mb();
> }
>
> return ret;
> --
> 2.39.2
>
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
signature.asc
Description: PGP signature
Re: [PATCH v2 1/2] dt-bindings: arm: qcom: Document samsung,milletwifi device
On Thu, Feb 15, 2024 at 06:19:48PM +0100, Bryant Mairs wrote: > Add binding documentation for Samsung Galaxy Tab 4 8.0 Wi-Fi > tablet which is based on Snapdragon 400 (apq8026) SoC. > > Signed-off-by: Bryant Mairs > Acked-by: Linus Walleij Acked-by: Conor Dooley Cheers, Conor. > --- > Documentation/devicetree/bindings/arm/qcom.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml > b/Documentation/devicetree/bindings/arm/qcom.yaml > index 2b993b4c51dc..c11bb2a81643 100644 > --- a/Documentation/devicetree/bindings/arm/qcom.yaml > +++ b/Documentation/devicetree/bindings/arm/qcom.yaml > @@ -104,6 +104,7 @@ properties: >- huawei,sturgeon >- lg,lenok >- samsung,matisse-wifi > + - samsung,milletwifi >- const: qcom,apq8026 > >- items: > -- > 2.43.0 > signature.asc Description: PGP signature
Re: [PATCH] media: dt-bindings: qcom,sc7280-venus: Allow one IOMMU entry
On Mon, Jan 29, 2024 at 08:48:54AM +0100, Luca Weiss wrote: > Some SC7280-based boards crash when providing the "secure_non_pixel" > context bank, so allow only one iommu in the bindings also. > > Signed-off-by: Luca Weiss Do we have any idea why this happens? How is someone supposed to know whether or not their system requires you to only provide one iommu? Yes, a crash might be the obvious answer, but is there a way of knowing without the crashes? Cheers, Conor. > --- > Reference: > https://lore.kernel.org/linux-arm-msm/20231201-sc7280-venus-pas-v3-2-bc132dc5f...@fairphone.com/ > --- > Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml > b/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml > index 8f9b6433aeb8..10c334e6b3dc 100644 > --- a/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml > +++ b/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml > @@ -43,6 +43,7 @@ properties: >- const: vcodec_bus > >iommus: > +minItems: 1 > maxItems: 2 > >interconnects: > > --- > base-commit: 596764183be8ebb13352b281a442a1f1151c9b06 > change-id: 20240129-sc7280-venus-bindings-6e62a99620de > > Best regards, > -- > Luca Weiss > signature.asc Description: PGP signature
Re: [PATCH] dt-bindings: remoteproc: do not override firmware-name $ref
Acked-by: Conor Dooley signature.asc Description: PGP signature
Re: [PATCH v3 2/5] dt-bindings: input/touchscreen: Add compatible for IST3038B
On Sat, Dec 09, 2023 at 10:05:27AM +0100, Karel Balej wrote: > On Mon Dec 4, 2023 at 1:52 PM CET, Conor Dooley wrote: > > On Mon, Dec 04, 2023 at 02:40:44PM +0200, Markuss Broks wrote: > > > On 12/3/23 13:20, Conor Dooley wrote: > > > > On Sat, Dec 02, 2023 at 01:48:33PM +0100, Karel Balej wrote: > > > > > From: Markuss Broks > > > > > > > > > > Imagis IST3038B is a variant (firmware?) of Imagis IST3038 IC, > > > > > add the compatible for it to the IST3038C bindings. > > > > This one is better, but would be well served by mentioning what > > > > specifically is different (register addresses or firmware commands?) > > > > > > I don't think anyone knows this other than Imagis itself. I would guess > > > it's > > > different hardware, since register addresses are indeed different, but on > > > the other hand, there is a possibility that firmware on the MCU could be > > > responding to those commands. I suppose "... IST3038B is a hardware > > > variant > > > of ... IST3038" would be more correct. > > > > Only Imagis might know the specifics, but you (plural) have made driver > > changes so you know what is different in terms of the programming model. > > I'm just asking for you to mention how the programming model varies in > > the commit message. Otherwise I can't know whether you should have added > > a fallback compatible, without going and reading your driver change. The > > commit message for the bindings should stand on its own merit in that > > regard. > > "Variant" alone does not suffice, as many variants of devices have a > > compatible programming model, be that for a subset of features or > > complete compatibility. > > > > > The reason why I think it could be firmware-defined is because we have a > > > lot > > > of variants (30xxA, 30xxB, 30xxC, plain 30xx), and the numbers usually > > > mean > > > feature level/completeness, e.g. some don't support the touch pressure or > > > touchkeys, and we don't know what A/B/C/none means. > > > > Ultimately whether it is due to firmware or the hardware isn't > > particular important, just mention what is incompatibly different. > > I propose to update the commit description as such: > > Imagis IST3038B is a variant (firmware?) of Imagis IST3038 IC > differing from IST3038C in its register interface. Add the > compatible for it to the IST3038C bindings. SGTM. You can add Acked-by: Conor Dooley with that commit message update. Thanks, Conor. signature.asc Description: PGP signature
Re: [PATCH v3 2/5] dt-bindings: input/touchscreen: Add compatible for IST3038B
On Mon, Dec 04, 2023 at 02:40:44PM +0200, Markuss Broks wrote: > On 12/3/23 13:20, Conor Dooley wrote: > > On Sat, Dec 02, 2023 at 01:48:33PM +0100, Karel Balej wrote: > > > From: Markuss Broks > > > > > > Imagis IST3038B is a variant (firmware?) of Imagis IST3038 IC, > > > add the compatible for it to the IST3038C bindings. > > This one is better, but would be well served by mentioning what > > specifically is different (register addresses or firmware commands?) > > I don't think anyone knows this other than Imagis itself. I would guess it's > different hardware, since register addresses are indeed different, but on > the other hand, there is a possibility that firmware on the MCU could be > responding to those commands. I suppose "... IST3038B is a hardware variant > of ... IST3038" would be more correct. Only Imagis might know the specifics, but you (plural) have made driver changes so you know what is different in terms of the programming model. I'm just asking for you to mention how the programming model varies in the commit message. Otherwise I can't know whether you should have added a fallback compatible, without going and reading your driver change. The commit message for the bindings should stand on its own merit in that regard. "Variant" alone does not suffice, as many variants of devices have a compatible programming model, be that for a subset of features or complete compatibility. > The reason why I think it could be firmware-defined is because we have a lot > of variants (30xxA, 30xxB, 30xxC, plain 30xx), and the numbers usually mean > feature level/completeness, e.g. some don't support the touch pressure or > touchkeys, and we don't know what A/B/C/none means. Ultimately whether it is due to firmware or the hardware isn't particular important, just mention what is incompatibly different. Cheers, Conor. > > > Signed-off-by: Markuss Broks > > > Signed-off-by: Karel Balej > > > --- > > > .../devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git > > > a/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml > > > > > > b/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml > > > index 0d6b033fd5fb..b5372c4eae56 100644 > > > --- > > > a/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml > > > +++ > > > b/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml > > > @@ -18,6 +18,7 @@ properties: > > > compatible: > > > enum: > > > + - imagis,ist3038b > > > - imagis,ist3038c > > > reg: > > > -- > > > 2.43.0 > > > > - Markuss signature.asc Description: PGP signature
Re: [PATCH v3 2/5] dt-bindings: input/touchscreen: Add compatible for IST3038B
On Sat, Dec 02, 2023 at 01:48:33PM +0100, Karel Balej wrote: > From: Markuss Broks > > Imagis IST3038B is a variant (firmware?) of Imagis IST3038 IC, > add the compatible for it to the IST3038C bindings. This one is better, but would be well served by mentioning what specifically is different (register addresses or firmware commands?) Cheers, Conor. > > Signed-off-by: Markuss Broks > Signed-off-by: Karel Balej > --- > .../devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git > a/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml > b/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml > index 0d6b033fd5fb..b5372c4eae56 100644 > --- a/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml > +++ b/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml > @@ -18,6 +18,7 @@ properties: > >compatible: > enum: > + - imagis,ist3038b >- imagis,ist3038c > >reg: > -- > 2.43.0 > signature.asc Description: PGP signature
Re: [PATCH v3 4/5] dt-bindings: input/touchscreen: imagis: add compatible for IST3032C
On Sat, Dec 02, 2023 at 01:48:35PM +0100, Karel Balej wrote: > From: Karel Balej > > Document possible usage of the Imagis driver with the IST3032C > touchscreen. Please leave mention of the driver out of the binding patch (we deal only with the hardware here) and instead describe what is incompatibly different between these two devices. Thanks, Conor. > > Signed-off-by: Karel Balej > --- > .../devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git > a/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml > b/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml > index b5372c4eae56..2af71cbcc97d 100644 > --- a/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml > +++ b/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml > @@ -18,6 +18,7 @@ properties: > >compatible: > enum: > + - imagis,ist3032c >- imagis,ist3038b >- imagis,ist3038c > > -- > 2.43.0 > signature.asc Description: PGP signature
Re: [PATCH 1/2] dt-bindings: arm: qcom: Add Huawei Honor 5X / GR5 (2016)
On Sun, Oct 22, 2023 at 01:40:41PM +0200, lukas walter wrote: > >> Acked-by: Krzysztof Kozlowski > > > >How come this v1 has an ack? > > This is supposed to be a v2, but I had problems sending it correctly, > sorry > https://patchwork.kernel.org/project/linux-arm-msm/patch/20230916134147.163764-1-lukas.wal...@aceart.de/ The joys of email, ehh signature.asc Description: PGP signature
Re: [PATCH 1/2] dt-bindings: arm: qcom: Add Huawei Honor 5X / GR5 (2016)
On Sat, Oct 21, 2023 at 04:30:24PM +0200, Lukas Walter wrote: > Add a compatible for Huawei Honor 5X / GR5 (2016). > > Acked-by: Krzysztof Kozlowski How come this v1 has an ack? > Signed-off-by: Lukas Walter > --- > Documentation/devicetree/bindings/arm/qcom.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml > b/Documentation/devicetree/bindings/arm/qcom.yaml > index 7f80f48a0954..20d914b21847 100644 > --- a/Documentation/devicetree/bindings/arm/qcom.yaml > +++ b/Documentation/devicetree/bindings/arm/qcom.yaml > @@ -191,6 +191,7 @@ properties: > >- items: >- enum: > + - huawei,kiwi >- longcheer,l9100 >- samsung,a7 >- sony,kanuti-tulip > -- > 2.42.0 > signature.asc Description: PGP signature
Re: [PATCH v2 1/2] dt-bindings: i2c: qcom-cci: Document SC7280 compatible
On Mon, Oct 02, 2023 at 08:55:30AM +0200, Luca Weiss wrote: > Document the compatible for the CCI block found on SC7280 SoC. > > Reviewed-by: Bryan O'Donoghue > Signed-off-by: Luca Weiss Acked-by: Conor Dooley Thanks, Conor. > --- > Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml > b/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml > index 042d4dc636ee..8386cfe21532 100644 > --- a/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml > +++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml > @@ -25,6 +25,7 @@ properties: > >- items: >- enum: > + - qcom,sc7280-cci >- qcom,sdm845-cci >- qcom,sm6350-cci >- qcom,sm8250-cci > @@ -159,6 +160,7 @@ allOf: > compatible: >contains: > enum: > + - qcom,sc7280-cci >- qcom,sm8250-cci >- qcom,sm8450-cci > then: > > -- > 2.42.0 > signature.asc Description: PGP signature
Re: [PATCH v2 1/2] dt-bindings: mfd: qcom,spmi-pmic: Drop unused labels from examples
On Mon, Oct 02, 2023 at 09:00:11AM +0200, Luca Weiss wrote:
> There's not much point in having unused labels in the binding example,
> so drop them.
>
> This patch was originally motivated by ea25d61b448a ("arm64: dts: qcom:
> Use plural _gpios node label for PMIC gpios") updating all dts files to
> use the plural _gpios label instead of the singular _gpio as label but
> this example wasn't updated. But since we should just drop the label
> alltogether, do that.
>
> Signed-off-by: Luca Weiss
Acked-by: Conor Dooley
Thanks,
Conor.
> ---
> Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
> b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
> index 55e931ba5b47..9fa568603930 100644
> --- a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
> +++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
> @@ -239,13 +239,13 @@ examples:
> interrupt-controller;
> #interrupt-cells = <4>;
>
> -pmi8998_lsid0: pmic@2 {
> +pmic@2 {
> compatible = "qcom,pmi8998", "qcom,spmi-pmic";
> reg = <0x2 SPMI_USID>;
> #address-cells = <1>;
> #size-cells = <0>;
>
> -pmi8998_gpio: gpio@c000 {
> +gpio@c000 {
> compatible = "qcom,pmi8998-gpio", "qcom,spmi-gpio";
> reg = <0xc000>;
> gpio-controller;
> @@ -330,7 +330,7 @@ examples:
> };
> };
>
> -pm6150_gpio: gpio@c000 {
> +gpio@c000 {
> compatible = "qcom,pm6150-gpio", "qcom,spmi-gpio";
> reg = <0xc000>;
> gpio-controller;
>
> --
> 2.42.0
>
signature.asc
Description: PGP signature
Re: [PATCH] dt-bindings: remoteproc: mtk,scp: Add missing additionalProperties on child node schemas
On Tue, Sep 26, 2023 at 11:45:08AM -0500, Rob Herring wrote: > Just as unevaluatedProperties or additionalProperties are required at > the top level of schemas, they should (and will) also be required for > child node schemas. That ensures only documented properties are > present for any node. > > Signed-off-by: Rob Herring > --- Acked-by: Conor Dooley > Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml > b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml > index 895415772d1d..24422fd56e83 100644 > --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml > +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml > @@ -91,6 +91,7 @@ allOf: > > additionalProperties: >type: object > + additionalProperties: false >description: > Subnodes of the SCP represent rpmsg devices. The names of the devices > are not important. The properties of these nodes are defined by the > -- > 2.40.1 > signature.asc Description: PGP signature
