From: David Lechner <dlechner@baylibre.com>
Add a spi-buses property to the spi-peripheral-props binding to allow
specifying the SPI bus or buses that a peripheral is connected to in
cases where the SPI controller has more than one physical SPI bus.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
---
Changes in v2:
- New
.../devicetree/bindings/spi/spi-peripheral-props.yaml | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
index 8fc17e16efb2..cfdb55071a08 100644
--- a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
@@ -89,6 +89,16 @@ properties:
description:
Delay, in microseconds, after a write transfer.
+ spi-buses:
+ description:
+ Array of bus numbers that describes which SPI buses of the controller are
+ connected to the peripheral. This only applies to peripherals connected
+ to specialized SPI controllers that have multiple SPI buses on a single
+ controller.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ default: [0]
+
stacked-memories:
description: Several SPI memories can be wired in stacked mode.
This basically means that either a device features several chip
--
2.35.1.1320.gc452695387.dirtyOn 6/16/25 5:00 PM, Sean Anderson wrote: > From: David Lechner <dlechner@baylibre.com> > > Add a spi-buses property to the spi-peripheral-props binding to allow > specifying the SPI bus or buses that a peripheral is connected to in > cases where the SPI controller has more than one physical SPI bus. > > Signed-off-by: David Lechner <dlechner@baylibre.com> > Signed-off-by: Sean Anderson <sean.anderson@linux.dev> > --- > > Changes in v2: > - New > > .../devicetree/bindings/spi/spi-peripheral-props.yaml | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml > index 8fc17e16efb2..cfdb55071a08 100644 > --- a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml > +++ b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml > @@ -89,6 +89,16 @@ properties: > description: > Delay, in microseconds, after a write transfer. > > + spi-buses: > + description: > + Array of bus numbers that describes which SPI buses of the controller are > + connected to the peripheral. This only applies to peripherals connected > + to specialized SPI controllers that have multiple SPI buses on a single > + controller. > + $ref: /schemas/types.yaml#/definitions/uint32-array > + minItems: 1 Finally have some hardware to test this series with using 2 or 4 buses. I found that we also need an absolute max here to make the bindings checker happy. 8 seems sensible since I haven't seen more than that on a peripheral. We can always increase it if we find hardware that requires more buses. maxItems: 8 > + default: [0] > + > stacked-memories: > description: Several SPI memories can be wired in stacked mode. > This basically means that either a device features several chip
On 8/15/25 11:49, David Lechner wrote: > On 6/16/25 5:00 PM, Sean Anderson wrote: >> From: David Lechner <dlechner@baylibre.com> >> >> Add a spi-buses property to the spi-peripheral-props binding to allow >> specifying the SPI bus or buses that a peripheral is connected to in >> cases where the SPI controller has more than one physical SPI bus. >> >> Signed-off-by: David Lechner <dlechner@baylibre.com> >> Signed-off-by: Sean Anderson <sean.anderson@linux.dev> >> --- >> >> Changes in v2: >> - New >> >> .../devicetree/bindings/spi/spi-peripheral-props.yaml | 10 ++++++++++ >> 1 file changed, 10 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml >> index 8fc17e16efb2..cfdb55071a08 100644 >> --- a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml >> +++ b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml >> @@ -89,6 +89,16 @@ properties: >> description: >> Delay, in microseconds, after a write transfer. >> >> + spi-buses: >> + description: >> + Array of bus numbers that describes which SPI buses of the controller are >> + connected to the peripheral. This only applies to peripherals connected >> + to specialized SPI controllers that have multiple SPI buses on a single >> + controller. >> + $ref: /schemas/types.yaml#/definitions/uint32-array >> + minItems: 1 > > Finally have some hardware to test this series with using 2 or 4 buses. > I found that we also need an absolute max here to make the bindings checker > happy. 8 seems sensible since I haven't seen more than that on a peripheral. > We can always increase it if we find hardware that requires more buses. > > maxItems: 8 What is the error you get without this? --Sean
On 8/18/25 9:56 AM, Sean Anderson wrote: > On 8/15/25 11:49, David Lechner wrote: >> On 6/16/25 5:00 PM, Sean Anderson wrote: >>> From: David Lechner <dlechner@baylibre.com> >>> >>> Add a spi-buses property to the spi-peripheral-props binding to allow >>> specifying the SPI bus or buses that a peripheral is connected to in >>> cases where the SPI controller has more than one physical SPI bus. >>> >>> Signed-off-by: David Lechner <dlechner@baylibre.com> >>> Signed-off-by: Sean Anderson <sean.anderson@linux.dev> >>> --- >>> >>> Changes in v2: >>> - New >>> >>> .../devicetree/bindings/spi/spi-peripheral-props.yaml | 10 ++++++++++ >>> 1 file changed, 10 insertions(+) >>> >>> diff --git a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml >>> index 8fc17e16efb2..cfdb55071a08 100644 >>> --- a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml >>> +++ b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml >>> @@ -89,6 +89,16 @@ properties: >>> description: >>> Delay, in microseconds, after a write transfer. >>> >>> + spi-buses: >>> + description: >>> + Array of bus numbers that describes which SPI buses of the controller are >>> + connected to the peripheral. This only applies to peripherals connected >>> + to specialized SPI controllers that have multiple SPI buses on a single >>> + controller. >>> + $ref: /schemas/types.yaml#/definitions/uint32-array >>> + minItems: 1 >> >> Finally have some hardware to test this series with using 2 or 4 buses. >> I found that we also need an absolute max here to make the bindings checker >> happy. 8 seems sensible since I haven't seen more than that on a peripheral. >> We can always increase it if we find hardware that requires more buses. >> >> maxItems: 8 > > What is the error you get without this? > > --Sean > I don't have the terminal output anymore, but it was something along the lines that there were too many items in the array. Like it had an implicit maxItems: 1. Overriding in a separate file didn't help as the checker seems to consider each binding file separately. I.e. sometimes I saw the same error twice.
Hello, >> + spi-buses: >> + description: >> + Array of bus numbers that describes which SPI buses of the controller are >> + connected to the peripheral. This only applies to peripherals connected >> + to specialized SPI controllers that have multiple SPI buses on a single >> + controller. >> + $ref: /schemas/types.yaml#/definitions/uint32-array >> + minItems: 1 > > Finally have some hardware to test this series with using 2 or 4 buses. Out of curiosity, what is the practical use case and intended benefit? Maybe an example of such device and an explanation of how useful this is would be welcome, as it does not seem to fit the initial spi idea (which has been greatly "improved", not saying it is bad, just unusual). Thanks, Miquèl
On 8/18/25 3:28 AM, Miquel Raynal wrote: > Hello, > >>> + spi-buses: >>> + description: >>> + Array of bus numbers that describes which SPI buses of the controller are >>> + connected to the peripheral. This only applies to peripherals connected >>> + to specialized SPI controllers that have multiple SPI buses on a single >>> + controller. >>> + $ref: /schemas/types.yaml#/definitions/uint32-array >>> + minItems: 1 > >> >> Finally have some hardware to test this series with using 2 or 4 buses. > > Out of curiosity, what is the practical use case and intended benefit? > Maybe an example of such device and an explanation of how useful this is > would be welcome, as it does not seem to fit the initial spi idea > (which has been greatly "improved", not saying it is bad, just unusual). > > Thanks, > Miquèl From my side, I am working on supporting complex analog-digital converters. There are many of these that contain multiple converters in a single chip and have multiple serial data lines so that the data from each converter can be read on a separate serial line to speed up throughput. And in some cases multiple chips are also used in parallel to the same effect. I.e. all chips share the same conversion trigger and we want to read back the data from all chips at the same time to get max throughput.
On 8/18/25 04:28, Miquel Raynal wrote: > Hello, > >>> + spi-buses: >>> + description: >>> + Array of bus numbers that describes which SPI buses of the controller are >>> + connected to the peripheral. This only applies to peripherals connected >>> + to specialized SPI controllers that have multiple SPI buses on a single >>> + controller. >>> + $ref: /schemas/types.yaml#/definitions/uint32-array >>> + minItems: 1 > >> >> Finally have some hardware to test this series with using 2 or 4 buses. > > Out of curiosity, what is the practical use case and intended benefit? > Maybe an example of such device and an explanation of how useful this is > would be welcome, as it does not seem to fit the initial spi idea > (which has been greatly "improved", not saying it is bad, just unusual). The idea is to model the case where there are several tightly-integrated busses on a single controller. e.g. sharing registers and maybe even clocks. Some of these allow you to drive both busses at once, reading e.g. the high nibble from one bus and the low nibble from the other. These sorts of things require coordination from the controller, hence a spi-buses property instead of two separate buses. This also makes compatibility easier, since new devicetrees remain more-or-less compatible with old kernels. --Sean
On 6/16/25 5:00 PM, Sean Anderson wrote: > From: David Lechner <dlechner@baylibre.com> > > Add a spi-buses property to the spi-peripheral-props binding to allow > specifying the SPI bus or buses that a peripheral is connected to in > cases where the SPI controller has more than one physical SPI bus. > > Signed-off-by: David Lechner <dlechner@baylibre.com> > Signed-off-by: Sean Anderson <sean.anderson@linux.dev> > --- > FYI, Mark's filters won't pick up `dt-bindings: spi:`, we need to change the subject line to `spi: dt-bindings:` on the next revision.
On 8/14/25 16:55, David Lechner wrote: > On 6/16/25 5:00 PM, Sean Anderson wrote: >> From: David Lechner <dlechner@baylibre.com> >> >> Add a spi-buses property to the spi-peripheral-props binding to allow >> specifying the SPI bus or buses that a peripheral is connected to in >> cases where the SPI controller has more than one physical SPI bus. >> >> Signed-off-by: David Lechner <dlechner@baylibre.com> >> Signed-off-by: Sean Anderson <sean.anderson@linux.dev> >> --- >> > FYI, Mark's filters won't pick up `dt-bindings: spi:`, we need to change > the subject line to `spi: dt-bindings:` on the next revision. > Sounds like he should fix his filter then. --Sean
On Thu, Aug 14, 2025 at 05:15:14PM -0400, Sean Anderson wrote: > On 8/14/25 16:55, David Lechner wrote: > > FYI, Mark's filters won't pick up `dt-bindings: spi:`, we need to change > > the subject line to `spi: dt-bindings:` on the next revision. > Sounds like he should fix his filter then. This is me triaging my inbox by eye, given the amount of irrelevant junk people send to me.
On 8/14/25 4:15 PM, Sean Anderson wrote: > On 8/14/25 16:55, David Lechner wrote: >> On 6/16/25 5:00 PM, Sean Anderson wrote: >>> From: David Lechner <dlechner@baylibre.com> >>> >>> Add a spi-buses property to the spi-peripheral-props binding to allow >>> specifying the SPI bus or buses that a peripheral is connected to in >>> cases where the SPI controller has more than one physical SPI bus. >>> >>> Signed-off-by: David Lechner <dlechner@baylibre.com> >>> Signed-off-by: Sean Anderson <sean.anderson@linux.dev> >>> --- >>> >> FYI, Mark's filters won't pick up `dt-bindings: spi:`, we need to change >> the subject line to `spi: dt-bindings:` on the next revision. >> > > Sounds like he should fix his filter then. > > --Sean No, this is a documented expectation for contributors. [1] says that SPI and a few other subsystems want the subsystem first in the subject. [1]: https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html
On 8/14/25 17:17, David Lechner wrote: > On 8/14/25 4:15 PM, Sean Anderson wrote: >> On 8/14/25 16:55, David Lechner wrote: >>> On 6/16/25 5:00 PM, Sean Anderson wrote: >>>> From: David Lechner <dlechner@baylibre.com> >>>> >>>> Add a spi-buses property to the spi-peripheral-props binding to allow >>>> specifying the SPI bus or buses that a peripheral is connected to in >>>> cases where the SPI controller has more than one physical SPI bus. >>>> >>>> Signed-off-by: David Lechner <dlechner@baylibre.com> >>>> Signed-off-by: Sean Anderson <sean.anderson@linux.dev> >>>> --- >>>> >>> FYI, Mark's filters won't pick up `dt-bindings: spi:`, we need to change >>> the subject line to `spi: dt-bindings:` on the next revision. >>> >> >> Sounds like he should fix his filter then. >> >> --Sean > > No, this is a documented expectation for contributors. [1] says that SPI and > a few other subsystems want the subsystem first in the subject. > > [1]: https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html Hm, this is new to me... --Sean
On 17/06/2025 00:00, Sean Anderson wrote: > From: David Lechner <dlechner@baylibre.com> > > Add a spi-buses property to the spi-peripheral-props binding to allow > specifying the SPI bus or buses that a peripheral is connected to in > cases where the SPI controller has more than one physical SPI bus. > > Signed-off-by: David Lechner <dlechner@baylibre.com> > Signed-off-by: Sean Anderson <sean.anderson@linux.dev> > --- > > Changes in v2: > - New > > .../devicetree/bindings/spi/spi-peripheral-props.yaml | 10 ++++++++++ > 1 file changed, 10 insertions(+) <form letter> Please use scripts/get_maintainers.pl to get a list of necessary people and lists to CC. It might happen, that command when run on an older kernel, gives you outdated entries. Therefore please be sure you base your patches on recent Linux kernel. Tools like b4 or scripts/get_maintainer.pl provide you proper list of people, so fix your workflow. Tools might also fail if you work on some ancient tree (don't, instead use mainline) or work on fork of kernel (don't, instead use mainline). Just use b4 and everything should be fine, although remember about `b4 prep --auto-to-cc` if you added new patches to the patchset. You missed at least devicetree list (maybe more), so this won't be tested by automated tooling. Performing review on untested code might be a waste of time. Please kindly resend and include all necessary To/Cc entries. </form letter> Best regards, Krzysztof
© 2016 - 2025 Red Hat, Inc.