Handle probe dependencies and hard errors better#6645
Merged
pelwell merged 3 commits intoraspberrypi:rpi-6.6.yfrom Feb 4, 2025
Merged
Handle probe dependencies and hard errors better#6645pelwell merged 3 commits intoraspberrypi:rpi-6.6.yfrom
pelwell merged 3 commits intoraspberrypi:rpi-6.6.yfrom
Conversation
popcornmix
reviewed
Feb 3, 2025
| platform_set_drvdata(pdev, fw); | ||
| } else { | ||
| kfree(fw); | ||
| platform_set_drvdata(pdev, ERR_PTR(-ENOENT)); |
Collaborator
There was a problem hiding this comment.
We do dereference this in rp1_firmware_remove (without a check).
I'm not sure if that can happen, but looks like a potential pitfall.
Contributor
Author
There was a problem hiding this comment.
Testing the obvious fix has uncovered some deficiencies in the end-of-life code. Thank goodness for runtime overlays.
If the RP1 firmware has reported an error then return that from the PIO probe function, otherwise defer the probing. Link: raspberrypi#6642 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
To avoid pointless retries, let the probe function succeed if the firmware interface is configured correctly but the firmware is incompatible. The value of the private drvdata field holds the outcome. Link: raspberrypi#6642 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The of_xlate method saves the calculated event mask in the con_priv field. It also rejects subsequent attempt to use that channel because the mask is non-zero, which causes a repeated instantiation of a client driver to fail. The of_xlate method is not meant to be a point of resource acquisition. Leave the con_priv initialisation, but drop the test that it was previously zero. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Contributor
Author
|
With the latest updates, the rp1 firmware driver and pio driver can be repeatedly instantiated and removed with no crashes or obvious leaks. |
popcornmix
approved these changes
Feb 4, 2025
popcornmix
added a commit
to raspberrypi/firmware
that referenced
this pull request
Feb 4, 2025
See: raspberrypi/linux#6636 kernel: misc: rp1-pio: SM_CONFIG_XFER32 = larger DMA bufs See: raspberrypi/linux#6640 kernel: Handle probe dependencies and hard errors better See: raspberrypi/linux#6645 kernel: spi: dw: Wait for idle after TX See: raspberrypi/linux#6646 See: raspberrypi/linux#6649
popcornmix
added a commit
to raspberrypi/rpi-firmware
that referenced
this pull request
Feb 4, 2025
See: raspberrypi/linux#6636 kernel: misc: rp1-pio: SM_CONFIG_XFER32 = larger DMA bufs See: raspberrypi/linux#6640 kernel: Handle probe dependencies and hard errors better See: raspberrypi/linux#6645 kernel: spi: dw: Wait for idle after TX See: raspberrypi/linux#6646 See: raspberrypi/linux#6649
why-npc
pushed a commit
to why-npc/rpi-firmware
that referenced
this pull request
Feb 13, 2025
See: raspberrypi/linux#6636 kernel: misc: rp1-pio: SM_CONFIG_XFER32 = larger DMA bufs See: raspberrypi/linux#6640 kernel: Handle probe dependencies and hard errors better See: raspberrypi/linux#6645 kernel: spi: dw: Wait for idle after TX See: raspberrypi/linux#6646 See: raspberrypi/linux#6649
sairon
added a commit
to home-assistant/operating-system
that referenced
this pull request
Mar 26, 2025
One of the reason for failures after update to OS 15.0 was missing support for the kernel PIO driver in EEPROM firmware. Backport upstream patches from raspberrypi/linux#6645 and raspberrypi/linux#6642 that handle this situation more gracefully. These patches could be dropped after the next RPi kernel release. Refs #3943
sairon
added a commit
to home-assistant/operating-system
that referenced
this pull request
Mar 26, 2025
One of the reason for failures after update to OS 15.0 was missing support for the kernel PIO driver in EEPROM firmware. Backport upstream patches from raspberrypi/linux#6645 and raspberrypi/linux#6642 that handle this situation more gracefully. These patches could be dropped after the next RPi kernel release. Refs #3943
mahabubul470
pushed a commit
to my-smart-homes/operating-system
that referenced
this pull request
Dec 23, 2025
…ant#3972) One of the reason for failures after update to OS 15.0 was missing support for the kernel PIO driver in EEPROM firmware. Backport upstream patches from raspberrypi/linux#6645 and raspberrypi/linux#6642 that handle this situation more gracefully. These patches could be dropped after the next RPi kernel release. Refs home-assistant#3943
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
#6642 is a report of intermittent failures for the PIO driver to contact the firmware. These failures can be traced to the failure of PIO driver to distinguish hard errors and transient failures. The commits in this PR fix the PIO driver in this regard, but also improve the firmware driver to avoid pointless retries in the event that the firmware is not compatible.