SPI lock-up with zero-length transfers

SPI lock-up with zero-length transfers

[Phil Elwell]

Hi,

Commit [1] - an optimisation of the PIO transfers loops of spi-bcm2835
- causes lockups if a zero-length transfer is attempted. The commit
message says that "[t]he blind and counted loops are always called
with nonzero count", which is technically true but ignores the fact
that count can be reduced to zero before entering the loop if tfr->len
is zero.

A workaround has been added in the raspberrypi/linux repo that
explicitly checks for zero-length transfers in
bcm2835_spi_transfer_one, but perhaps it would be better to catch this
degenerate case in the common framework code - I'm not an SPI expert.

Regards,

Phil

[1] 26751de25d25 ("spi: bcm2835: Micro-optimise FIFO loops")

Re: SPI lock-up with zero-length transfers

[Nicolas Saenz Julienne]

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

On Thu, 2021-01-28 at 14:26 +0000, Phil Elwell wrote:
> Hi,
> 
> Commit [1] - an optimisation of the PIO transfers loops of spi-bcm2835
> - causes lockups if a zero-length transfer is attempted. The commit
> message says that "[t]he blind and counted loops are always called
> with nonzero count", which is technically true but ignores the fact
> that count can be reduced to zero before entering the loop if tfr->len
> is zero.
> 
> A workaround has been added in the raspberrypi/linux repo that
> explicitly checks for zero-length transfers in
> bcm2835_spi_transfer_one, but perhaps it would be better to catch this
> degenerate case in the common framework code - I'm not an SPI expert.

Me neither to be honest, but I'll have a look at it. Thanks for the heads-up.

Regards,
Nicolas


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: SPI lock-up with zero-length transfers

[Robin Murphy]

On 2021-01-28 14:33, Nicolas Saenz Julienne wrote:
> On Thu, 2021-01-28 at 14:26 +0000, Phil Elwell wrote:
>> Hi,
>>
>> Commit [1] - an optimisation of the PIO transfers loops of spi-bcm2835
>> - causes lockups if a zero-length transfer is attempted. The commit
>> message says that "[t]he blind and counted loops are always called
>> with nonzero count", which is technically true but ignores the fact
>> that count can be reduced to zero before entering the loop if tfr->len
>> is zero.
>>
>> A workaround has been added in the raspberrypi/linux repo that
>> explicitly checks for zero-length transfers in
>> bcm2835_spi_transfer_one, but perhaps it would be better to catch this
>> degenerate case in the common framework code - I'm not an SPI expert.
> 
> Me neither to be honest, but I'll have a look at it. Thanks for the heads-up.

Oops, sorry - I suppose I assumed that zero-length requests make little 
enough sense that they wouldn't be a thing; I also have no practical 
experience with the SPI subsystem.

FWIW those patches were only ever meant as an illustrations of "things 
that already have far, far more impact than an extra bit test and 
conditional return would" from a codegen PoV, and they did come with the 
caveat that I had no means of testing them :)

Cheers,
Robin.