SPI is totally broken on 5.10 / RPi4 #4100
Comments
|
What is the last known working version? |
|
5.4.83-7 arch is working |
|
I can reproduce using the master rpi-update branch, and the stable branch (on 5.4.83) seems fine. I've had an SPI RFID reader working on 5.10, but clearly that's not tickling this particular issue. Sigh. Thanks for the report... |
|
I wonder why reader works. Is there a separate driver? I'll wait for the fix. Let me know if you need anything. |
|
A coffee would be nice. |
|
I'm afraid that the coffee will cool down a little while it will go to you from Russia :) |
pelwell
added a commit
that referenced
this issue
Jan 28, 2021
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: #4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
pelwell
added a commit
that referenced
this issue
Jan 28, 2021
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: #4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
|
Most of the changes between 5.4 and 5.10 look harmless - changing some initialisation and function prototypes, etc. The only ones that stood out were some optimisations that changed Zero-length transfers are tripping up the decision whether to use DMA, interrupts or polling because 0 is not less than the smallest byte_limit value of 0. Reverting to 5.4 shows that zero length transfers are still occurring and not handled optimally, but checking the count at the start of the loop means it exits correctly. The zero length transfer must come from the spidev library - each ioctl() to perform a transfer is followed by a zero-length read on the file handle; I'm not going to dig further. Reverting the above-mentioned commit fixes the problem, but we can do better - the zero-length transfer can be filtered at transfer_one entry point (with a suitable warning the first time). Fixes/workarounds are now in rpi-5.10.y and rpi-5.11.y. |
popcornmix
added a commit
to raspberrypi/firmware
that referenced
this issue
Jan 28, 2021
popcornmix
added a commit
to Hexxeh/rpi-firmware
that referenced
this issue
Jan 28, 2021
|
The fix is also in latest rpi-update kernel. |
|
I confirm that the problem has been fixed. Thank you for sorting this out so quickly, you awesome :) |
popcornmix
pushed a commit
that referenced
this issue
Feb 4, 2021
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: #4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
it-is-a-robot
pushed a commit
to openeuler-mirror/raspberrypi-kernel
that referenced
this issue
Feb 11, 2021
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: raspberrypi/linux#4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
it-is-a-robot
pushed a commit
to openeuler-mirror/raspberrypi-kernel
that referenced
this issue
Feb 11, 2021
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: raspberrypi/linux#4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
Feb 11, 2021
With the introduction of 26751de ("spi: bcm2835: Micro-optimise FIFO loops") it has become apparent that some users might initiate zero-length SPI transfers. A fact the micro-optimization omitted, and which turned out to cause crashes[1]. Instead of changing the micro-optimization itself, use a bigger hammer and skip zero-length transfers altogether for drivers using the default transfer_one_message() implementation. Reported-by: Phil Elwell <[email protected]> Fixes: 26751de ("spi: bcm2835: Micro-optimise FIFO loops") Signed-off-by: Nicolas Saenz Julienne <[email protected]> [1] raspberrypi/linux#4100
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
Feb 14, 2021
With the introduction of 26751de ("spi: bcm2835: Micro-optimise FIFO loops") it has become apparent that some users might initiate zero-length SPI transfers. A fact the micro-optimization omitted, and which turned out to cause crashes[1]. Instead of changing the micro-optimization itself, use a bigger hammer and skip zero-length transfers altogether for drivers using the default transfer_one_message() implementation. Reported-by: Phil Elwell <[email protected]> Fixes: 26751de ("spi: bcm2835: Micro-optimise FIFO loops") Signed-off-by: Nicolas Saenz Julienne <[email protected]> [1] raspberrypi/linux#4100 Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Feb 16, 2021
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: #4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
it-is-a-robot
pushed a commit
to openeuler-mirror/raspberrypi-kernel
that referenced
this issue
Feb 24, 2021
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: raspberrypi/linux#4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops") Signed-off-by: Fang Yafen <[email protected]>
it-is-a-robot
pushed a commit
to openeuler-mirror/raspberrypi-kernel
that referenced
this issue
Feb 25, 2021
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: raspberrypi/linux#4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops") Signed-off-by: Fang Yafen <[email protected]>
it-is-a-robot
pushed a commit
to openeuler-mirror/raspberrypi-kernel
that referenced
this issue
Feb 25, 2021
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: raspberrypi/linux#4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops") Signed-off-by: Fang Yafen <[email protected]>
it-is-a-robot
pushed a commit
to openeuler-mirror/raspberrypi-kernel
that referenced
this issue
Feb 27, 2021
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: raspberrypi/linux#4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops") Signed-off-by: Fang Yafen <[email protected]>
it-is-a-robot
pushed a commit
to openeuler-mirror/raspberrypi-kernel
that referenced
this issue
Feb 27, 2021
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: raspberrypi/linux#4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops") Signed-off-by: Fang Yafen <[email protected]>
nareshkamboju
pushed a commit
to nareshkamboju/linux
that referenced
this issue
Mar 2, 2021
[ Upstream commit b306320 ] With the introduction of 26751de ("spi: bcm2835: Micro-optimise FIFO loops") it has become apparent that some users might initiate zero-length SPI transfers. A fact the micro-optimization omitted, and which turned out to cause crashes[1]. Instead of changing the micro-optimization itself, use a bigger hammer and skip zero-length transfers altogether for drivers using the default transfer_one_message() implementation. Reported-by: Phil Elwell <[email protected]> Fixes: 26751de ("spi: bcm2835: Micro-optimise FIFO loops") Signed-off-by: Nicolas Saenz Julienne <[email protected]> [1] raspberrypi/linux#4100 Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
woodsts
pushed a commit
to woodsts/linux-stable
that referenced
this issue
Mar 4, 2021
[ Upstream commit b306320 ] With the introduction of 26751de ("spi: bcm2835: Micro-optimise FIFO loops") it has become apparent that some users might initiate zero-length SPI transfers. A fact the micro-optimization omitted, and which turned out to cause crashes[1]. Instead of changing the micro-optimization itself, use a bigger hammer and skip zero-length transfers altogether for drivers using the default transfer_one_message() implementation. Reported-by: Phil Elwell <[email protected]> Fixes: 26751de ("spi: bcm2835: Micro-optimise FIFO loops") Signed-off-by: Nicolas Saenz Julienne <[email protected]> [1] raspberrypi/linux#4100 Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
gregkh
pushed a commit
to gregkh/linux
that referenced
this issue
Mar 4, 2021
[ Upstream commit b306320 ] With the introduction of 26751de ("spi: bcm2835: Micro-optimise FIFO loops") it has become apparent that some users might initiate zero-length SPI transfers. A fact the micro-optimization omitted, and which turned out to cause crashes[1]. Instead of changing the micro-optimization itself, use a bigger hammer and skip zero-length transfers altogether for drivers using the default transfer_one_message() implementation. Reported-by: Phil Elwell <[email protected]> Fixes: 26751de ("spi: bcm2835: Micro-optimise FIFO loops") Signed-off-by: Nicolas Saenz Julienne <[email protected]> [1] raspberrypi/linux#4100 Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
it-is-a-robot
pushed a commit
to openeuler-mirror/kernel
that referenced
this issue
Mar 6, 2021
raspberrypi inclusion category: feature bugzilla: 50432 -------------------------------- A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: raspberrypi/linux#4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops") Signed-off-by: Fang Yafen <[email protected]> Signed-off-by: Zheng Zengkai <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Mar 16, 2021
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: #4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
popcornmix
pushed a commit
that referenced
this issue
Mar 10, 2025
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: #4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
popcornmix
pushed a commit
that referenced
this issue
Mar 10, 2025
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: #4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
popcornmix
pushed a commit
that referenced
this issue
Mar 10, 2025
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: #4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
popcornmix
pushed a commit
that referenced
this issue
Mar 10, 2025
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: #4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
popcornmix
pushed a commit
that referenced
this issue
Mar 13, 2025
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: #4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
popcornmix
pushed a commit
that referenced
this issue
Mar 13, 2025
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: #4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
popcornmix
pushed a commit
that referenced
this issue
Mar 17, 2025
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: #4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
popcornmix
pushed a commit
that referenced
this issue
Mar 24, 2025
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: #4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
popcornmix
pushed a commit
that referenced
this issue
Mar 25, 2025
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: #4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
popcornmix
pushed a commit
that referenced
this issue
Mar 25, 2025
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: #4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
popcornmix
pushed a commit
that referenced
this issue
Mar 31, 2025
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: #4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
popcornmix
pushed a commit
that referenced
this issue
Apr 7, 2025
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: #4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
popcornmix
pushed a commit
that referenced
this issue
Apr 7, 2025
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: #4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
popcornmix
pushed a commit
that referenced
this issue
Apr 10, 2025
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: #4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
popcornmix
pushed a commit
that referenced
this issue
Apr 14, 2025
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: #4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
popcornmix
pushed a commit
that referenced
this issue
Apr 14, 2025
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: #4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
popcornmix
pushed a commit
that referenced
this issue
Apr 14, 2025
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: #4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
nmbath
pushed a commit
to victronenergy/linux
that referenced
this issue
Apr 22, 2025
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: raspberrypi/linux#4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
popcornmix
pushed a commit
that referenced
this issue
Apr 24, 2025
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: #4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
popcornmix
pushed a commit
that referenced
this issue
Apr 24, 2025
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: #4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
popcornmix
pushed a commit
that referenced
this issue
Apr 24, 2025
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: #4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
popcornmix
pushed a commit
that referenced
this issue
Apr 28, 2025
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: #4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
popcornmix
pushed a commit
that referenced
this issue
Apr 28, 2025
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: #4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
popcornmix
pushed a commit
that referenced
this issue
May 6, 2025
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: #4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
popcornmix
pushed a commit
that referenced
this issue
May 6, 2025
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: #4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
popcornmix
pushed a commit
that referenced
this issue
May 14, 2025
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: #4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
popcornmix
pushed a commit
that referenced
this issue
May 14, 2025
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: #4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
popcornmix
pushed a commit
that referenced
this issue
May 20, 2025
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: #4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
popcornmix
pushed a commit
that referenced
this issue
May 20, 2025
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: #4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
popcornmix
pushed a commit
that referenced
this issue
May 23, 2025
A relatively recent commit ([1]) contained optimisation for the PIO SPI FIFO-filling functions. The commit message includes the phrase "[t]he blind and counted loops are always called with nonzero count". This is technically true, but it is still possible for count to become zero before the loop is entered - if tfr->len is zero. Moving the loop exit condition to the end of the loop saves a few cycles, but results in a near-infinite loop should the revised count be zero on entry. Strangely, zero-lengthed transfers aren't filtered by the SPI framework and, even more strangely, the Python3 spidev library is triggering them for no obvious reason. Avoid the problem completely by bailing out of the main transfer function early if trf->len is zero, although there may be a case for moving the mitigation into the framework. See: #4100 Signed-off-by: Phil Elwell <[email protected]> [1] 26751de ("spi: bcm2835: Micro-optimise FIFO loops")
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Describe the bug
When trying to use SPI on 5.10, a crash occurs in the kernel:
To reproduce
rpi-update, installpython3-spidev.dtparam=spi=onto/boot/config.txt. Also reproduced withdtoverlay=spi0-1cs(I really need it).System
a5bf70c44ba93e99f955a66530916240a1661132 / Jan 21 2021 16:03:55or Arch,382bdb0bc62235141318b3511ee1ab9a8d7712e4 / Jan 25 2021 18:47:41on Raspbian.Logs
Full dmesg obtained on Arch: dmesg.txt.
The text was updated successfully, but these errors were encountered: