From: Francesco Dolcini <francesco.dolcini@toradex.com>
Add a compatible to describe a single wire loopback between SPI MISO and
MOSI signals.
Link: https://lore.kernel.org/all/20260310133254.GA51497@francesco-nb/
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
index a482aeadcd44..2cb973c157f6 100644
--- a/Documentation/devicetree/bindings/trivial-devices.yaml
+++ b/Documentation/devicetree/bindings/trivial-devices.yaml
@@ -432,6 +432,8 @@ properties:
- socionext,uniphier-smpctrl
# SparkFun Qwiic Joystick (COM-15168) with i2c interface
- sparkfun,qwiic-joystick
+ # Single wire loopback between SPI MISO and MOSI signals
+ - spi-miso-mosi-loopback
# STMicroelectronics Hot-swap controller stef48h28
- st,stef48h28
# Sierra Wireless mangOH Green SPI IoT interface
--
2.47.3On 16/03/2026 08:35, Francesco Dolcini wrote: > From: Francesco Dolcini <francesco.dolcini@toradex.com> > > Add a compatible to describe a single wire loopback between SPI MISO and > MOSI signals. > > Link: https://lore.kernel.org/all/20260310133254.GA51497@francesco-nb/ > Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> > --- > Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml > index a482aeadcd44..2cb973c157f6 100644 > --- a/Documentation/devicetree/bindings/trivial-devices.yaml > +++ b/Documentation/devicetree/bindings/trivial-devices.yaml > @@ -432,6 +432,8 @@ properties: > - socionext,uniphier-smpctrl > # SparkFun Qwiic Joystick (COM-15168) with i2c interface > - sparkfun,qwiic-joystick > + # Single wire loopback between SPI MISO and MOSI signals > + - spi-miso-mosi-loopback If you decided to go against my approach, then at least document it in proper place - incomplete-devices - so this won't be ever used in DTS. Best regards, Krzysztof
On 16/03/2026 09:35, Krzysztof Kozlowski wrote: > On 16/03/2026 08:35, Francesco Dolcini wrote: >> From: Francesco Dolcini <francesco.dolcini@toradex.com> >> >> Add a compatible to describe a single wire loopback between SPI MISO and >> MOSI signals. >> >> Link: https://lore.kernel.org/all/20260310133254.GA51497@francesco-nb/ >> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> >> --- >> Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml >> index a482aeadcd44..2cb973c157f6 100644 >> --- a/Documentation/devicetree/bindings/trivial-devices.yaml >> +++ b/Documentation/devicetree/bindings/trivial-devices.yaml >> @@ -432,6 +432,8 @@ properties: >> - socionext,uniphier-smpctrl >> # SparkFun Qwiic Joystick (COM-15168) with i2c interface >> - sparkfun,qwiic-joystick >> + # Single wire loopback between SPI MISO and MOSI signals >> + - spi-miso-mosi-loopback > > If you decided to go against my approach, then at least document it in > proper place - incomplete-devices - so this won't be ever used in DTS. > ... and then you will notice existing linux,spi-loopback-test, so explain the differences and why spi-loopback-test cannot be used for your loopback test. Best regards, Krzysztof
Hello Krzysztof, thanks for taking the time to answer this On Mon, Mar 16, 2026 at 09:36:42AM +0100, Krzysztof Kozlowski wrote: > On 16/03/2026 09:35, Krzysztof Kozlowski wrote: > > On 16/03/2026 08:35, Francesco Dolcini wrote: > >> From: Francesco Dolcini <francesco.dolcini@toradex.com> > >> > >> Add a compatible to describe a single wire loopback between SPI MISO and > >> MOSI signals. > >> > >> Link: https://lore.kernel.org/all/20260310133254.GA51497@francesco-nb/ > >> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> > >> --- > >> Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++ > >> 1 file changed, 2 insertions(+) > >> > >> diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml > >> index a482aeadcd44..2cb973c157f6 100644 > >> --- a/Documentation/devicetree/bindings/trivial-devices.yaml > >> +++ b/Documentation/devicetree/bindings/trivial-devices.yaml > >> @@ -432,6 +432,8 @@ properties: > >> - socionext,uniphier-smpctrl > >> # SparkFun Qwiic Joystick (COM-15168) with i2c interface > >> - sparkfun,qwiic-joystick > >> + # Single wire loopback between SPI MISO and MOSI signals > >> + - spi-miso-mosi-loopback > > > > If you decided to go against my approach, then at least document it in > > proper place - incomplete-devices - so this won't be ever used in DTS. > > > > ... and then you will notice existing linux,spi-loopback-test, so > explain the differences and why spi-loopback-test cannot be used for > your loopback test. Yes, this spi-loopback-test will work. I was not aware of it (no-one mentioned it in the email thread I opened) and I misread your answer as an alternative suggestion, and not as a nack. There is still an open question, I can any driver probe/bind to the actual SPI device? My plan, once this discussion is settled, is to send patches to add dtso file enabling this test, however, according to trivial-devices.yaml, I cannot submit such a DT file using linux,spi-loopback-test as a compatible. On the actual HW I have a pins header and a wire between MISO/MOSI. I am clearly missing something obvious, any advise is appreciated. Thanks, Francesco
On 16/03/2026 09:57, Francesco Dolcini wrote: > Hello Krzysztof, > thanks for taking the time to answer this > > On Mon, Mar 16, 2026 at 09:36:42AM +0100, Krzysztof Kozlowski wrote: >> On 16/03/2026 09:35, Krzysztof Kozlowski wrote: >>> On 16/03/2026 08:35, Francesco Dolcini wrote: >>>> From: Francesco Dolcini <francesco.dolcini@toradex.com> >>>> >>>> Add a compatible to describe a single wire loopback between SPI MISO and >>>> MOSI signals. >>>> >>>> Link: https://lore.kernel.org/all/20260310133254.GA51497@francesco-nb/ >>>> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> >>>> --- >>>> Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++ >>>> 1 file changed, 2 insertions(+) >>>> >>>> diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml >>>> index a482aeadcd44..2cb973c157f6 100644 >>>> --- a/Documentation/devicetree/bindings/trivial-devices.yaml >>>> +++ b/Documentation/devicetree/bindings/trivial-devices.yaml >>>> @@ -432,6 +432,8 @@ properties: >>>> - socionext,uniphier-smpctrl >>>> # SparkFun Qwiic Joystick (COM-15168) with i2c interface >>>> - sparkfun,qwiic-joystick >>>> + # Single wire loopback between SPI MISO and MOSI signals >>>> + - spi-miso-mosi-loopback >>> >>> If you decided to go against my approach, then at least document it in >>> proper place - incomplete-devices - so this won't be ever used in DTS. >>> >> >> ... and then you will notice existing linux,spi-loopback-test, so >> explain the differences and why spi-loopback-test cannot be used for >> your loopback test. > > Yes, this spi-loopback-test will work. > > I was not aware of it (no-one mentioned it in the email thread I opened) > and I misread your answer as an alternative suggestion, and not as a nack. > > There is still an open question, I can any driver probe/bind to the > actual SPI device? My plan, once this discussion is settled, is to send > patches to add dtso file enabling this test, however, according to > trivial-devices.yaml, I cannot submit such a DT file using I think you meant incomplete-devices and then yes, such DT upstream is not allowed. > linux,spi-loopback-test as a compatible. > > On the actual HW I have a pins header and a wire between MISO/MOSI. pins header, if I understood correctly what you are talking about, is a connector. Connecting there a jumper to short circuit there is out of scope, because it is not part of the board. Thus cannot be send upstream DTS, unless it is really embedded in the design like USB-A dongles which could not be removed by end user. Otherwise you could say that every evalkit board can have such device, because they all have pin headers... > > I am clearly missing something obvious, any advise is appreciated. Describe your hardware... Nothing in this patchset helps in understanding it. Best regards, Krzysztof
Hello Krzysztof, On Mon, Mar 16, 2026 at 05:56:02PM +0100, Krzysztof Kozlowski wrote: > On 16/03/2026 09:57, Francesco Dolcini wrote: > > Hello Krzysztof, > > thanks for taking the time to answer this > > > > On Mon, Mar 16, 2026 at 09:36:42AM +0100, Krzysztof Kozlowski wrote: > >> On 16/03/2026 09:35, Krzysztof Kozlowski wrote: > >>> On 16/03/2026 08:35, Francesco Dolcini wrote: > >>>> From: Francesco Dolcini <francesco.dolcini@toradex.com> > >>>> > >>>> Add a compatible to describe a single wire loopback between SPI MISO and > >>>> MOSI signals. > >>>> > >>>> Link: https://lore.kernel.org/all/20260310133254.GA51497@francesco-nb/ > >>>> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> > >>>> --- > >>>> Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++ > >>>> 1 file changed, 2 insertions(+) > >>>> > >>>> diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml > >>>> index a482aeadcd44..2cb973c157f6 100644 > >>>> --- a/Documentation/devicetree/bindings/trivial-devices.yaml > >>>> +++ b/Documentation/devicetree/bindings/trivial-devices.yaml > >>>> @@ -432,6 +432,8 @@ properties: > >>>> - socionext,uniphier-smpctrl > >>>> # SparkFun Qwiic Joystick (COM-15168) with i2c interface > >>>> - sparkfun,qwiic-joystick > >>>> + # Single wire loopback between SPI MISO and MOSI signals > >>>> + - spi-miso-mosi-loopback > >>> > >>> If you decided to go against my approach, then at least document it in > >>> proper place - incomplete-devices - so this won't be ever used in DTS. > >>> > >> > >> ... and then you will notice existing linux,spi-loopback-test, so > >> explain the differences and why spi-loopback-test cannot be used for > >> your loopback test. > > > > Yes, this spi-loopback-test will work. > > > > I was not aware of it (no-one mentioned it in the email thread I opened) > > and I misread your answer as an alternative suggestion, and not as a nack. > > > > There is still an open question, I can any driver probe/bind to the > > actual SPI device? My plan, once this discussion is settled, is to send > > patches to add dtso file enabling this test, however, according to > > trivial-devices.yaml, I cannot submit such a DT file using > > I think you meant incomplete-devices and then yes, such DT upstream is > not allowed. yes, thanks for correcting me. > > linux,spi-loopback-test as a compatible. > > > > On the actual HW I have a pins header and a wire between MISO/MOSI. > > pins header, if I understood correctly what you are talking about, is a > connector. Connecting there a jumper to short circuit there is out of > scope, because it is not part of the board. Thus cannot be send upstream > DTS, unless it is really embedded in the design like USB-A dongles which > could not be removed by end user. > > Otherwise you could say that every evalkit board can have such device, > because they all have pin headers... > > > > > I am clearly missing something obvious, any advise is appreciated. > > Describe your hardware... Nothing in this patchset helps in > understanding it. Let me describe the need first, and after that I'll describe the HW. The need we have is to have a way, with Linux mainline kernel, to test the SPI functionality (subsystem, driver and the actual HW). So far this was done using the spidev out-of-tree and with a loopback between the SPI MOSI and MISO signals. We have a variety of HW that have various signals available on some sort of connector or pins headers [1]. This https://docs.toradex.com/112710-mallow-carrier-board_back.png is just one example, I know you are familiar with this kind of HW, I am writing it here the link just for completness and for everyone else. So yes, your understanding is correct. About the HW, we have various test boards, that plugs into this connector(s), as test fixture, and, with traces on the PCB, they do connect together the SPI MISO and MOSI signals. Here a couple of picture as an example, of the "Aquila Lava HAT", https://gist.github.com/dolcini/33c332f0b2174a9d495baf7c79341abf Francesco [1] https://en.wikipedia.org/wiki/Pin_header
On 18/03/2026 15:14, Francesco Dolcini wrote: > >>> linux,spi-loopback-test as a compatible. >>> >>> On the actual HW I have a pins header and a wire between MISO/MOSI. >> >> pins header, if I understood correctly what you are talking about, is a >> connector. Connecting there a jumper to short circuit there is out of >> scope, because it is not part of the board. Thus cannot be send upstream >> DTS, unless it is really embedded in the design like USB-A dongles which >> could not be removed by end user. >> >> Otherwise you could say that every evalkit board can have such device, >> because they all have pin headers... >> >>> >>> I am clearly missing something obvious, any advise is appreciated. >> >> Describe your hardware... Nothing in this patchset helps in >> understanding it. > > Let me describe the need first, and after that I'll describe the HW. > > The need we have is to have a way, with Linux mainline kernel, to test the SPI > functionality (subsystem, driver and the actual HW). So far this was > done using the spidev out-of-tree and with a loopback between the SPI MOSI and > MISO signals. > > We have a variety of HW that have various signals available on some sort of > connector or pins headers [1]. > > This https://docs.toradex.com/112710-mallow-carrier-board_back.png is just one > example, I know you are familiar with this kind of HW, I am writing it here the > link just for completness and for everyone else. Looks like a specific device (hat), not a jumper connecting two pins on the header. > > So yes, your understanding is correct. > > About the HW, we have various test boards, that plugs into this connector(s), > as test fixture, and, with traces on the PCB, they do connect together the SPI > MISO and MOSI signals. > > Here a couple of picture as an example, of the "Aquila Lava HAT", > https://gist.github.com/dolcini/33c332f0b2174a9d495baf7c79341abf I don't think this is anyhow different than all existing cases of people submitting spidev patches. You can have only two choices: 1. Connector. You cannot send bindings for spidev or loopback claiming it is a connector. 2. Actual device plugged there. You need specific compatible for this actual device. The compatible cannot be used for anything else. Best regards, Krzysztof
© 2016 - 2026 Red Hat, Inc.