SPI loopback tests

SPI loopback tests

[Francesco Dolcini]

Hello all,

I am writing to you SPI, test and DT people with reference to some need
we see in our testing infrastructure.

On our embedded boards we regularly (on mailine linux, on Linux LTS, and
on multiple hardware) run SPI tests, using a loopback connection (SPI
MISO/MOSI are connected together). The HW provide just some pin header
and there is no actual SPI slave device connected.

So far to test this we had some out-of-tree DT overlay abusing the spidev
compatible, however we'd like to move away from this approach and have a
solution that is 100% in mainline.

Manually unbinding/binding the driver in userspace does not seems as an
option, because there is no device node.

One option that I could think of would be to add a new compatible that
to describe this single wire loopback connection (something like
`linux,spi-miso-mosi-loopback`) that would bind to the spidev driver.

I am aware that you all DT maintainers shared in a pretty clear way your
view on the abuse of the spidev multiple times.

What would you be your advice to handle the need of an SPI loopback
test? Am I missing something and there is a solution already available?

Thanks in advance,
Francesco

Re: SPI loopback tests

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 980 bytes --]

On Tue, Mar 10, 2026 at 02:32:54PM +0100, Francesco Dolcini wrote:

> So far to test this we had some out-of-tree DT overlay abusing the spidev
> compatible, however we'd like to move away from this approach and have a
> solution that is 100% in mainline.

> Manually unbinding/binding the driver in userspace does not seems as an
> option, because there is no device node.

> One option that I could think of would be to add a new compatible that
> to describe this single wire loopback connection (something like
> `linux,spi-miso-mosi-loopback`) that would bind to the spidev driver.

> I am aware that you all DT maintainers shared in a pretty clear way your
> view on the abuse of the spidev multiple times.

> What would you be your advice to handle the need of an SPI loopback
> test? Am I missing something and there is a solution already available?

I'm not aware of any idiomatic way to deal with this with DT
unfortunately.  Perhaps the DT people have some ideas here?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: SPI loopback tests

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 1510 bytes --]

On Tue, Mar 10, 2026 at 03:55:51PM +0000, Mark Brown wrote:
> On Tue, Mar 10, 2026 at 02:32:54PM +0100, Francesco Dolcini wrote:
> 
> > So far to test this we had some out-of-tree DT overlay abusing the spidev
> > compatible, however we'd like to move away from this approach and have a
> > solution that is 100% in mainline.
> 
> > Manually unbinding/binding the driver in userspace does not seems as an
> > option, because there is no device node.
> 
> > One option that I could think of would be to add a new compatible that
> > to describe this single wire loopback connection (something like
> > `linux,spi-miso-mosi-loopback`) that would bind to the spidev driver.
> 
> > I am aware that you all DT maintainers shared in a pretty clear way your
> > view on the abuse of the spidev multiple times.
> 
> > What would you be your advice to handle the need of an SPI loopback
> > test? Am I missing something and there is a solution already available?
> 
> I'm not aware of any idiomatic way to deal with this with DT
> unfortunately.  Perhaps the DT people have some ideas here?

I dunno, the suggestion seems fairly reasonable to me. I don't think
it's really abuse of anything, because the compatible would represent a
real hardware configuration. The only think that feels "abusive" is the
fake reg property you'd need.

Not sure that there should be a "linux," vendor prefix though, there's
nothing linux-specific about doing loopback. Probably should be
vendor-less?



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: SPI loopback tests

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1376 bytes --]

On Tue, Mar 10, 2026 at 06:12:38PM +0000, Conor Dooley wrote:
> On Tue, Mar 10, 2026 at 03:55:51PM +0000, Mark Brown wrote:
> > On Tue, Mar 10, 2026 at 02:32:54PM +0100, Francesco Dolcini wrote:

> > > I am aware that you all DT maintainers shared in a pretty clear way your
> > > view on the abuse of the spidev multiple times.

> > > What would you be your advice to handle the need of an SPI loopback
> > > test? Am I missing something and there is a solution already available?

> > I'm not aware of any idiomatic way to deal with this with DT
> > unfortunately.  Perhaps the DT people have some ideas here?

> I dunno, the suggestion seems fairly reasonable to me. I don't think
> it's really abuse of anything, because the compatible would represent a
> real hardware configuration. The only think that feels "abusive" is the
> fake reg property you'd need.

In theory we should have a compatible specifically for loopback usage I
suppose.  Depending on how the device does it's loopbacks there may
actually be a genuine reg (if there's a chip select that's still
selecting.

> Not sure that there should be a "linux," vendor prefix though, there's
> nothing linux-specific about doing loopback. Probably should be
> vendor-less?

I think at this point it's old enough that it's just ABI and adding the
option of having it vendorless would just cause people to ask why.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: SPI loopback tests

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 1835 bytes --]

On Tue, Mar 10, 2026 at 06:26:45PM +0000, Mark Brown wrote:
> On Tue, Mar 10, 2026 at 06:12:38PM +0000, Conor Dooley wrote:
> > On Tue, Mar 10, 2026 at 03:55:51PM +0000, Mark Brown wrote:
> > > On Tue, Mar 10, 2026 at 02:32:54PM +0100, Francesco Dolcini wrote:
> 
> > > > I am aware that you all DT maintainers shared in a pretty clear way your
> > > > view on the abuse of the spidev multiple times.
> 
> > > > What would you be your advice to handle the need of an SPI loopback
> > > > test? Am I missing something and there is a solution already available?
> 
> > > I'm not aware of any idiomatic way to deal with this with DT
> > > unfortunately.  Perhaps the DT people have some ideas here?
> 
> > I dunno, the suggestion seems fairly reasonable to me. I don't think
> > it's really abuse of anything, because the compatible would represent a
> > real hardware configuration. The only think that feels "abusive" is the
> > fake reg property you'd need.
> 
> In theory we should have a compatible specifically for loopback usage I
> suppose.  Depending on how the device does it's loopbacks there may
> actually be a genuine reg (if there's a chip select that's still
> selecting.

Okay, fair enough.

> > Not sure that there should be a "linux," vendor prefix though, there's
> > nothing linux-specific about doing loopback. Probably should be
> > vendor-less?
> 
> I think at this point it's old enough that it's just ABI and adding the
> option of having it vendorless would just cause people to ask why.

I'm not sure what you mean by "it's old enough", as this proposed loopback
compatible is new, right? Don't think this is any different to i2c-mux
or regulator-fixed etc etc. Unless you thought that I was saying that
"spidev" should be a compatible? Definitely was not suggesting that!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: SPI loopback tests

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 855 bytes --]

On Wed, Mar 11, 2026 at 10:10:56AM +0000, Conor Dooley wrote:
> On Tue, Mar 10, 2026 at 06:26:45PM +0000, Mark Brown wrote:
> > On Tue, Mar 10, 2026 at 06:12:38PM +0000, Conor Dooley wrote:

> > > Not sure that there should be a "linux," vendor prefix though, there's
> > > nothing linux-specific about doing loopback. Probably should be
> > > vendor-less?

> > I think at this point it's old enough that it's just ABI and adding the
> > option of having it vendorless would just cause people to ask why.

> I'm not sure what you mean by "it's old enough", as this proposed loopback
> compatible is new, right? Don't think this is any different to i2c-mux
> or regulator-fixed etc etc. Unless you thought that I was saying that
> "spidev" should be a compatible? Definitely was not suggesting that!

It sounded like you were suggesting using spidev, yes.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: SPI loopback tests

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 1110 bytes --]

On Wed, Mar 11, 2026 at 11:16:07AM +0000, Mark Brown wrote:
> On Wed, Mar 11, 2026 at 10:10:56AM +0000, Conor Dooley wrote:
> > On Tue, Mar 10, 2026 at 06:26:45PM +0000, Mark Brown wrote:
> > > On Tue, Mar 10, 2026 at 06:12:38PM +0000, Conor Dooley wrote:
> 
> > > > Not sure that there should be a "linux," vendor prefix though, there's
> > > > nothing linux-specific about doing loopback. Probably should be
> > > > vendor-less?
> 
> > > I think at this point it's old enough that it's just ABI and adding the
> > > option of having it vendorless would just cause people to ask why.
> 
> > I'm not sure what you mean by "it's old enough", as this proposed loopback
> > compatible is new, right? Don't think this is any different to i2c-mux
> > or regulator-fixed etc etc. Unless you thought that I was saying that
> > "spidev" should be a compatible? Definitely was not suggesting that!
> 
> It sounded like you were suggesting using spidev, yes.

Ah ye no, not at all. Francesco suggested using "linux,spi-miso-mosi-loopback"
and it was that I think the "linux," should be culled from.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: SPI loopback tests

[Krzysztof Kozlowski]

On 10/03/2026 14:32, Francesco Dolcini wrote:
> Hello all,
> 
> I am writing to you SPI, test and DT people with reference to some need
> we see in our testing infrastructure.
> 
> On our embedded boards we regularly (on mailine linux, on Linux LTS, and
> on multiple hardware) run SPI tests, using a loopback connection (SPI
> MISO/MOSI are connected together). The HW provide just some pin header
> and there is no actual SPI slave device connected.
> 
> So far to test this we had some out-of-tree DT overlay abusing the spidev
> compatible, however we'd like to move away from this approach and have a
> solution that is 100% in mainline.
> 
> Manually unbinding/binding the driver in userspace does not seems as an
> option, because there is no device node.
> 
> One option that I could think of would be to add a new compatible that
> to describe this single wire loopback connection (something like
> `linux,spi-miso-mosi-loopback`) that would bind to the spidev driver.

Or the modern board file way: a module which in initcall creates several
SW nodes and instantiates the spidev. You still would need to insmode it
of course, but that way no DT would be directly involved.

> 
> I am aware that you all DT maintainers shared in a pretty clear way your
> view on the abuse of the spidev multiple times.
> 
> What would you be your advice to handle the need of an SPI loopback
> test? Am I missing something and there is a solution already available?


Best regards,
Krzysztof