Prepare 15.1.rc1#3977
Conversation
Bumps [docker/build-push-action](https://github.com/docker/build-push-action) from 6.14.0 to 6.15.0. - [Release notes](https://github.com/docker/build-push-action/releases) - [Commits](docker/build-push-action@v6.14.0...v6.15.0) --- updated-dependencies: - dependency-name: docker/build-push-action dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [docker/setup-buildx-action](https://github.com/docker/setup-buildx-action) from 3.9.0 to 3.10.0. - [Release notes](https://github.com/docker/setup-buildx-action/releases) - [Commits](docker/setup-buildx-action@v3.9.0...v3.10.0) --- updated-dependencies: - dependency-name: docker/setup-buildx-action dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
As discussed in #3885, now that fixed Supervisor is in stable, we can test that no AppArmor denied events are logged during CI tests.
* buildroot 7d5c3b5e70...b079a02a9a (1): > package/rpi-firmware: bump to 1.20250305 with updated firmware binaries Fixes #3911
Update to latest version that fixes start order in haos-agent.service. Without that, OS Agent reports incorrect swappiness after boot.
Use simple shell script to perform device wipe instead of calling OS Agent to do that through the UDisks2 API. While it might have been a good idea to use high level interface for that back then, it turns out it causes more issues than the benefits it could bring. Main problem currently is that the OS Agent needs to read sysctl variables, but those are only set after mounting the overlay partition. But at the same time, the overlay partition can't be mounted if we want to wipe it - this creates a dependency cycle through the haos-agent.service. To get rid of the cycle and simplify things, use a shell script doing basically the same what the OS Agent does. Since the wipe functionality only makes sense to be implemented on HAOS targets (not on Supervised), there's little point of having it in higher layer of abstraction that OS Agent provides. It should be also checked if changes from #1291 are needed anymore, as the driving factor for those have been probably the wipe feature in OS Agent too, but at this point they seem to be harmless.
…3917) * Add test checking journal logs for dependency cycles * Run some test cases to get their output also when full init fails * Remove high timeouts from the times when GHA couldn't use KVM * Enable logging durations for future optimizations
Update to latest version of the driver and matching firmware. The most common application for it - Frigate - currently has 4.19.0 in stable but 4.20.0 is staged in dev. As it's easier to select OS version than a version of the add-on, it makes sense to stay ahead in HAOS. This also means Frigate needs to be updated to the matching version (as staying on an arbitrary older patch revision doesn't make much sense either).
Add missing patch and update for latest runc version to fix losing device permissions when new devices are added in runtime. * buildroot b079a02a9a...3914f8cad5 (2): > package/runc: add patch for extended default allowed devices in v1.2.4 > package/runc: add missing patch to fix device permissions update Fixes #3915
In some cases, the wipe service may be called due to a race condition for the second time during the boot, very likely failing because the filesystems are already mounted. This can not be reproduced on OVA but can be fairly easy triggered e.g. on RPi. As we want the service to be executed exactly only once, we can do what's suggested in [1] and set the RemainAfterExit=yes. That should ensure the unit is not ever started for the second time. [1] https://www.github.com/systemd/systemd/issues/29367
We check that landing page is working when the network is down but we don't check it in the happy path. Add its test to make it more obvious when the just landing page is broken.
Bumps [docker/login-action](https://github.com/docker/login-action) from 3.3.0 to 3.4.0. - [Release notes](https://github.com/docker/login-action/releases) - [Commits](docker/login-action@v3.3.0...v3.4.0) --- updated-dependencies: - dependency-name: docker/login-action dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
) U-Boot update in #3878 changed the layout of patch folders for Hardkernel targets with the goal to make it less confusing. However, it missed adding the top-level hardkernel patches directory to all hardkernel targets and only remove it from some of them in [1]. Revert to state before #3878 by adding the hardkernel folder to c2/c4/n2. In the future, the patches from this folder should be split per target and if any patches remain in it, they should be applied for all hardkernel boards. [1] 2716b56 Fixes #3936
It seems that kernel 6.12 handles device probing less gracefully when these options are not enabled and causes crash on some AMD SoCs, e.g.: *ERROR* Invalid callback to read register 0x58184 Link: https://gitlab.freedesktop.org/drm/amd/-/issues/4050 Refs #3944
) When Intel GPUs are used in passthrough, the i915 is probed too early and fails to load firmware which is in the rootfs mounted later. The CONFIG_DRM_I915=y comes from x86_64_defconfig, by changing it to module (like we do for generic-x86-64), the driver becomes only available after the rootfs is mounted and firmware is loaded correctly. Fixes #3949
Update generic_raw_uart package to the latest sources available coming with direct kernel 6.12.x compatibility dropping the intermediate patches accordingly. In addition, the eq3_char_loop patchset was updated to reflect the same changes performed.
PR #3775 was mistakenly left out of the jump to the 6.12 kernel
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
Firmware change that set initial_turbo to 60 from the previous 0 has broken initialization of some SD cards in U-Boot. Adjust the value in config.txt on OS update if the value is not already set by the user, and put it to the default config.txt. The config.txt also contains a short comment explaining the purpose. The purpose of it is also to make it easier to revert this change in the future if the problem is fixed in the firmware or U-Boot. Fixes #3965
Update Docker and its dependencies to versions packaged in last bugfix release. * buildroot 3914f8cad5...4cd211162d (4): > package/runc: bump version to v1.2.6 > package/docker-cli: bump version to v28.0.4 > package/docker-engine: bump version to v28.0.4 > package/containerd: bump version to v1.7.26
📝 WalkthroughWalkthroughThe pull request makes a series of updates across workflow configurations, documentation, buildroot settings, kernel configurations, and driver patches. It upgrades versions used in GitHub Actions and board documentation, updates the Linux kernel version from 6.12.18 to 6.12.20 in numerous defconfig files, and modifies several kernel configuration files to add support for additional GPU architectures and NICs. Multiple patches adjust error handling and driver logic, and a new test function is added. A conditional block in the boot hook now ensures proper configuration for Raspberry Pi 3 systems. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant BootInstaller as Boot Installer
participant ConfigFile as config.txt
participant System as System
BootInstaller->>System: Call install_boot()
Note right of BootInstaller: Check RAUC_SYSTEM_COMPATIBLE\n("haos-rpi3" or "haos-rpi3-64")
BootInstaller->>ConfigFile: Query for "initial_turbo" setting
alt initial_turbo exists
BootInstaller->>System: Continue boot (nothing to do)
else initial_turbo missing
BootInstaller->>ConfigFile: Check for “[pi3]” section
alt [pi3] section exists
BootInstaller->>ConfigFile: Append "initial_turbo=0"
else [pi3] section missing
BootInstaller->>ConfigFile: Create “[pi3]” section with "initial_turbo=0"\n(Add comment for issue #3965)
end
end
BootInstaller->>System: Complete boot configuration
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (32)
.github/workflows/build.yaml(1 hunks)Documentation/kernel.md(1 hunks)buildroot(1 hunks)buildroot-external/board/pc/generic-x86-64/kernel.config(1 hunks)buildroot-external/board/pc/ova/kernel.config(1 hunks)buildroot-external/board/raspberrypi/config.txt(1 hunks)buildroot-external/board/raspberrypi/patches/linux/0005-misc-rp1-pio-Error-out-on-incompatible-firmware.patch(1 hunks)buildroot-external/board/raspberrypi/patches/linux/0006-firmware-rp1-Linger-on-firmware-failure.patch(1 hunks)buildroot-external/board/raspberrypi/patches/linux/0007-mailbox-rp1-Don-t-claim-channels-in-of_xlate.patch(1 hunks)buildroot-external/board/raspberrypi/patches/linux/0008-misc-rp1-pio-Demote-fw-probe-error-to-warning.patch(1 hunks)buildroot-external/configs/generic_aarch64_defconfig(1 hunks)buildroot-external/configs/generic_x86_64_defconfig(1 hunks)buildroot-external/configs/green_defconfig(1 hunks)buildroot-external/configs/khadas_vim3_defconfig(1 hunks)buildroot-external/configs/odroid_c2_defconfig(2 hunks)buildroot-external/configs/odroid_c4_defconfig(2 hunks)buildroot-external/configs/odroid_m1_defconfig(1 hunks)buildroot-external/configs/odroid_m1s_defconfig(1 hunks)buildroot-external/configs/odroid_n2_defconfig(2 hunks)buildroot-external/configs/odroid_xu4_defconfig(1 hunks)buildroot-external/configs/ova_defconfig(1 hunks)buildroot-external/configs/tinker_defconfig(1 hunks)buildroot-external/kernel/v6.12.y/device-support-pci.config(1 hunks)buildroot-external/meta(1 hunks)buildroot-external/ota/rauc-hook(1 hunks)buildroot-external/package/eq3_char_loop/0004-Fix-eq3_char_loop-driver-build-on-Linux-6.12.patch(1 hunks)buildroot-external/package/generic_raw_uart/0002-Linux-6.12-llseek.patch(0 hunks)buildroot-external/package/generic_raw_uart/0003-Linux-6.11-gpio-data.patch(0 hunks)buildroot-external/package/generic_raw_uart/0004-Linux-6.11-uart_remove.patch(0 hunks)buildroot-external/package/generic_raw_uart/generic_raw_uart.hash(1 hunks)buildroot-external/package/generic_raw_uart/generic_raw_uart.mk(1 hunks)tests/smoke_test/test_basic.py(1 hunks)
💤 Files with no reviewable changes (3)
- buildroot-external/package/generic_raw_uart/0002-Linux-6.12-llseek.patch
- buildroot-external/package/generic_raw_uart/0003-Linux-6.11-gpio-data.patch
- buildroot-external/package/generic_raw_uart/0004-Linux-6.11-uart_remove.patch
🧰 Additional context used
📓 Path-based instructions (6)
`*/**(html|markdown|md)`: - For instructional content in documentation, use a direct and authoritative tone. Avoid expressions of politeness such as 'may' or 'please', and ensure t...
*/**(html|markdown|md): - For instructional content in documentation, use a direct and authoritative tone. Avoid expressions of politeness such as 'may' or 'please', and ensure the goal of the instruction is fronted.
- Apply the Microsoft Style Guide to ensure documentation maintains clarity and conciseness.
- In step-by-step instructions, front the location phrase in the instructional sentence.
- In step-by-step instructions, front the 'goal' in the instructional sentence.
- In step-by-step instructions, if in doubt what to front, front the 'goal' before the location phrase in the instructional sentence.
- do not hyphenate terms like 'top-right' or 'bottom-left' with 'corner'
buildroot-external/metaDocumentation/kernel.md
`*/**(html|markdown|md)`: - Use bold to mark UI strings. - If "" are used to mark UI strings, replace them by bold.
*/**(html|markdown|md): - Use bold to mark UI strings.
- If "" are used to mark UI strings, replace them by bold.
buildroot-external/metaDocumentation/kernel.md
`*/**(html|markdown|md)`: - Be brief in your replies and don't add fluff like "thank you for..." and "Please let me know if"
*/**(html|markdown|md): - Be brief in your replies and don't add fluff like "thank you for..." and "Please let me know if"
buildroot-external/metaDocumentation/kernel.md
`*/**(html|markdown|md)`: - Use sentence-style capitalization also in headings.
*/**(html|markdown|md): - Use sentence-style capitalization also in headings.
buildroot-external/metaDocumentation/kernel.md
`*/**(html|markdown|md)`: do not comment on HTML used for icons
*/**(html|markdown|md): do not comment on HTML used for icons
buildroot-external/metaDocumentation/kernel.md
`*/**(html|markdown|md)`: Avoid flagging inline HTML for embedding videos in future reviews for this repository.
*/**(html|markdown|md): Avoid flagging inline HTML for embedding videos in future reviews for this repository.
buildroot-external/metaDocumentation/kernel.md
🔇 Additional comments (35)
tests/smoke_test/test_basic.py (1)
68-72: LGTM! Good addition to the smoke test suite.The new test function provides a basic check to ensure the landing page is accessible, which is a valuable verification step for the Home Assistant system. It appropriately depends on the initialization test and makes a simple assertion that confirms the page is returning complete HTML content.
For future enhancements, you might consider:
- Adding a more specific check for Home Assistant-related content rather than just HTML closing tag
- Adding a timeout or retry mechanism in case the web server takes longer to respond
- Verifying the HTTP status code is 200 OK
.github/workflows/build.yaml (1)
141-141: Update Docker Login Action VersionThe docker/login-action version has been updated from v3.3.0 to v3.4.0. This update should bring in any new features or bug fixes provided by the action's latest release. Please verify that nothing in the workflow’s behavior or any custom configuration requires further adjustments due to this version change.
buildroot-external/board/pc/generic-x86-64/kernel.config (1)
31-32: Enable Additional AMDGPU Driver SupportThe new configuration options
CONFIG_DRM_AMDGPU_SI=yandCONFIG_DRM_AMDGPU_CIK=yhave been added to enable support for AMD Southern Islands and CIK architectures. This enhances compatibility with a broader range of AMD GPUs. Please ensure that testing on relevant hardware is performed to validate these changes.buildroot (1)
1-1: Commit Reference Update Verification.
The updated subproject commit hash4cd211162de8b74461c2684bd89b89047f0ecb61appears to align with the PR objective of updating to Linux kernel version 6.12.20. Please verify that this new commit indeed includes all the necessary patches and configuration updates (e.g., kernel bump, missing patches, and driver changes) required for the pre-release.buildroot-external/board/pc/ova/kernel.config (1)
93-94: Properly enables i915 driver as a module for VM passthrough.This change sets the Intel i915 graphics driver to be built as a module rather than built into the kernel, which aligns with the PR objective of enabling proper initialization in VM passthrough scenarios.
buildroot-external/meta (1)
2-3: Version bump to 15.1.rc1.The version has been updated from 15.0.rc2 to 15.1.rc1, which aligns with preparing the pre-release version mentioned in the PR objectives.
buildroot-external/package/generic_raw_uart/generic_raw_uart.mk (1)
16-16:Details
✅ Verification successful
Update to latest generic_raw_uart version.
The package version has been updated to a newer commit, which aligns with the PR objective to update generic_raw_uart to its latest version.
🏁 Script executed:
#!/bin/bash # Check if the commit exists and get its date curl -s https://api.github.com/repos/alexreinert/piVCCU/commits/b80aacfb75e9689d14d4e2c94380728816c6313e | jq '.commit.committer.date'Length of output: 157
Commit Verified – Generic Raw UART Version Update Approved
The PR updates
generic_raw_uart.mkto use commitb80aacfb75e9689d14d4e2c94380728816c6313e, which was confirmed to exist and committed on 2025-03-21T13:31:56Z. This update aligns with the PR objective to bring in the latest changes.
- File:
buildroot-external/package/generic_raw_uart/generic_raw_uart.mk(Line 16)- Change: Updated commit hash to the latest version
buildroot-external/configs/green_defconfig (1)
19-19: Kernel update to 6.12.20.The Linux kernel version has been updated from 6.12.18 to 6.12.20, which corresponds to the kernel update mentioned in the PR objectives.
buildroot-external/package/generic_raw_uart/generic_raw_uart.hash (1)
3-3: Package updated to latest versionThe hash and source file have been updated to reference a newer version of the generic_raw_uart package, which aligns with the PR objective to update generic_raw_uart to its latest version.
buildroot-external/configs/ova_defconfig (1)
19-19: Kernel version updated to 6.12.20This change updates the Linux kernel version from 6.12.18 to 6.12.20, which matches the PR objective to update the kernel version. This minor version update likely includes security patches and bug fixes.
buildroot-external/configs/odroid_m1_defconfig (1)
19-19: Kernel version updated to 6.12.20This change updates the Linux kernel version from 6.12.18 to 6.12.20 for the ODROID-M1 board, in line with the kernel updates being applied across all platform configurations in this PR.
buildroot-external/board/raspberrypi/config.txt (1)
74-76: Added Raspberry Pi 3 specific configurationA new section for Raspberry Pi 3 configuration has been added with
initial_turbo=0to disable CPU turbo boost during boot. This directly addresses issue #3965 as mentioned in the PR objectives and may help improve stability for Raspberry Pi 3 devices.buildroot-external/configs/khadas_vim3_defconfig (1)
19-19: Kernel version update to 6.12.20This change updates the Linux kernel version from 6.12.18 to 6.12.20, which aligns with the PR objective to update the operating system for the upcoming 15.1.rc1 release.
buildroot-external/configs/odroid_m1s_defconfig (1)
19-19: Kernel version update to 6.12.20This change updates the Linux kernel version from 6.12.18 to 6.12.20, consistent with other board configurations in this PR.
buildroot-external/board/raspberrypi/patches/linux/0007-mailbox-rp1-Don-t-claim-channels-in-of_xlate.patch (1)
24-32: Remove channel claiming in rp1-mailbox's of_xlate methodThis patch correctly removes the check that prevented reusing mailbox channels. The
of_xlatemethod should only translate device tree entries to channels, not perform resource acquisition. This fix will resolve issues with Raspberry Pi PIO/RP1 firmware probing errors as mentioned in the PR objectives.buildroot-external/configs/generic_x86_64_defconfig (1)
19-19: Kernel version update to 6.12.20This change updates the Linux kernel version from 6.12.18 to 6.12.20, matching the kernel version updates for other board configurations in this PR.
buildroot-external/configs/generic_aarch64_defconfig (1)
19-19: Kernel version updated to 6.12.20This change updates the Linux kernel version from 6.12.18 to 6.12.20, which includes the latest bug fixes and security patches.
buildroot-external/kernel/v6.12.y/device-support-pci.config (1)
29-32: Added support for Mellanox ConnectX-3 NICThis addition properly implements support for Mellanox ConnectX-3 network interface cards, as mentioned in the PR objectives. The configuration enables the MLX4 Ethernet driver as a module, disables debug options, and enables the second generation core driver.
buildroot-external/configs/odroid_xu4_defconfig (1)
20-20: Kernel version updated to 6.12.20This change updates the Linux kernel version from 6.12.18 to 6.12.20 for the ODROID-XU4 board, consistent with the updates in other board configurations.
buildroot-external/configs/tinker_defconfig (1)
21-21: Kernel version updated to 6.12.20This change updates the Linux kernel version from 6.12.18 to 6.12.20 for the Tinker Board, maintaining version consistency across all platform configurations.
buildroot-external/board/raspberrypi/patches/linux/0005-misc-rp1-pio-Error-out-on-incompatible-firmware.patch (2)
23-29: Improved error handling for RP1 firmwareThe change enhances error handling by differentiating between two failure modes:
- When firmware driver is not found (returns
-EPROBE_DEFERto allow retrying later)- When firmware is found but reports an error (returns the actual error code)
This is a good improvement that helps diagnose issues more accurately.
37-41: Added necessary resource cleanup in remove functionThe added cleanup operations properly release resources when the device is removed:
- Destroying the device
- Deleting the character device
- Destroying the device class
- Unregistering the character device region
This prevents resource leaks and follows kernel driver best practices.
buildroot-external/board/raspberrypi/patches/linux/0008-misc-rp1-pio-Demote-fw-probe-error-to-warning.patch (1)
26-31: Appropriate demotion of firmware error to warningThis change converts an error message to a warning when the RP1 firmware cannot be contacted, which aligns with the patch description. For most users, PIO unavailability isn't critical and doesn't need to trigger an alarm-level message.
The code also properly maintains the error code return value while changing only the logging level.
buildroot-external/package/eq3_char_loop/0004-Fix-eq3_char_loop-driver-build-on-Linux-6.12.patch (1)
11-15: Fix for compatibility with Linux kernel 6.12The change correctly updates the
llseekfunction pointer in thefile_operationsstructure to usenoop_llseekfor kernel versions 6.12 and above, while maintaining compatibility with older versions. This aligns with the kernel API changes in version 6.12.The conditional compilation directive ensures the driver works correctly across different kernel versions.
buildroot-external/ota/rauc-hook (1)
56-69: Added fix for Raspberry Pi 3 boot issuesThis change addresses a known issue (#3965) where some Raspberry Pi 3 devices fail to boot from certain SD cards with the default
initial_turbo=60setting. The implementation:
- Only applies to Raspberry Pi 3 systems
- Only makes changes if
initial_turboisn't already set- Handles both cases - existing
[pi3]section or need to create one- Includes helpful comments explaining the purpose of the change
The solution is well-structured, non-invasive, and includes proper error checking.
Documentation/kernel.md (1)
6-6: Kernel version update properly reflected in documentation.The kernel version has been consistently updated from 6.12.18 to 6.12.20 for all non-Raspberry Pi boards, which aligns with the PR objectives.
Also applies to: 14-24
buildroot-external/configs/odroid_c2_defconfig (2)
7-7: Added missing patch directory for ODROID boards.The additional patch directory
$(BR2_EXTERNAL_HASSOS_PATH)/board/hardkernel/patcheshas been included in the global patch directories. This corresponds to the PR objective of fixing ODROID-related issues.
19-19: Kernel version updated to 6.12.20.The Linux kernel version has been updated from 6.12.18 to 6.12.20, which aligns with the PR objective of upgrading the Linux kernel.
buildroot-external/configs/odroid_c4_defconfig (2)
7-7: Added missing patch directory for ODROID boards.The additional patch directory
$(BR2_EXTERNAL_HASSOS_PATH)/board/hardkernel/patcheshas been included in the global patch directories. This corresponds to the PR objective of fixing ODROID-related issues with serial and I2C.
19-19: Kernel version updated to 6.12.20.The Linux kernel version has been updated from 6.12.18 to 6.12.20, which aligns with the PR objective of upgrading the Linux kernel.
buildroot-external/configs/odroid_n2_defconfig (2)
7-7: Added missing patch directory for ODROID boards.The additional patch directory
$(BR2_EXTERNAL_HASSOS_PATH)/board/hardkernel/patcheshas been included in the global patch directories. This corresponds to the PR objective of fixing ODROID-related issues with serial and I2C.
19-19: Kernel version updated to 6.12.20.The Linux kernel version has been updated from 6.12.18 to 6.12.20, which aligns with the PR objective of upgrading the Linux kernel.
buildroot-external/board/raspberrypi/patches/linux/0006-firmware-rp1-Linger-on-firmware-failure.patch (3)
23-28: Prevent invalid reference count operations.
Checking!IS_ERR_OR_NULL(fw)before callingkref_putavoids decrements on erroneous or null firmware pointers. This change prevents potential crashes or undefined behavior.
70-78: Consistent error propagation in devm_rp1_firmware_get.
Propagating an error pointer here aligns with the changes torp1_firmware_get. This is a clean and consistent approach for devm-managed resource acquisition.
82-103:Details
✅ Verification successful
Verify probe return semantics.
By returning 0 on firmware message failure, the device lingers instead of aborting, which aligns with the desired behavior of avoiding repeated probes. However, ensure that no parts of the system expect a non-zero return code to detect firmware incompatibility.You can confirm no code depends on a failing return using:
🏁 Script executed:
#!/bin/bash # Search for rp1_firmware_probe references and display contexts, ensuring no checks for a non-zero return. rg -A 5 'rp1_firmware_probe'Length of output: 816
Firmware Probe Return Semantics Verified
The updated patch now returns 0 on firmware message failure, which avoids repeated probing as intended. I've verified via the grep output that no other parts of the codebase expect a non-zero return code to detect firmware incompatibility. The placement of the
platform_set_drvdata()call has been adjusted accordingly, and the error cleanup viarp1_firmware_put(fw)is correctly handled.
- File Location:
buildroot-external/board/raspberrypi/patches/linux/0006-firmware-rp1-Linger-on-firmware-failure.patch(Lines 82-103)- No evidence was found of other components checking for a non-zero return value from the probe.
| @@ -157,7 +158,7 @@ struct rp1_firmware *rp1_firmware_get(struct device_node *client) | ||
| const char *match = rp1_firmware_of_match[0].compatible; | ||
| struct platform_device *pdev; | ||
| struct device_node *fwnode; | ||
| - struct rp1_firmware *fw; | ||
| + struct rp1_firmware *fw = NULL; | ||
|
|
||
| if (!client) | ||
| return NULL; | ||
| @@ -166,17 +167,17 @@ struct rp1_firmware *rp1_firmware_get(struct device_node *client) | ||
| return NULL; | ||
| if (!of_device_is_compatible(fwnode, match)) { | ||
| of_node_put(fwnode); | ||
| - return NULL; | ||
| + return ERR_PTR(-ENXIO); | ||
| } | ||
|
|
||
| pdev = of_find_device_by_node(fwnode); | ||
| of_node_put(fwnode); | ||
|
|
||
| if (!pdev) | ||
| - goto err_exit; | ||
| + return ERR_PTR(-ENXIO); | ||
|
|
||
| fw = platform_get_drvdata(pdev); | ||
| - if (!fw) | ||
| + if (IS_ERR_OR_NULL(fw)) | ||
| goto err_exit; | ||
|
|
||
| if (!kref_get_unless_zero(&fw->consumers)) | ||
| @@ -188,7 +189,7 @@ struct rp1_firmware *rp1_firmware_get(struct device_node *client) | ||
|
|
||
| err_exit: | ||
| put_device(&pdev->dev); | ||
| - return NULL; | ||
| + return fw; | ||
| } |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Ensure all call sites handle error pointers properly.
Returning ERR_PTR(-ENXIO) instead of NULL makes it easier to distinguish between different error conditions, but be sure to update all callers of rp1_firmware_get so they check for error pointers (using IS_ERR() or similar) rather than just NULL.
You can verify that all callers properly handle error pointers by running:
🏁 Script executed:
#!/bin/bash
# Search for rp1_firmware_get calls in the codebase and display relevant contexts.
rg -A 5 'rp1_firmware_get'Length of output: 7024
Action Required: Update Error Handling in All Callers
The update to rp1_firmware_get now returns an error pointer (ERR_PTR(-ENXIO)) instead of NULL on failure. However, our search shows that some call sites (for example, in the patches under 0008-misc-rp1-pio-Demote-fw-probe-error-to-warning.patch and 0005-misc-rp1-pio-Error-out-on-incompatible-firmware.patch) still first check for a NULL value using if (!fw). Since an error pointer isn’t NULL, these checks won’t catch error conditions properly.
Please update the callers to consistently use error-pointer checks (i.e. using IS_ERR() or IS_ERR_OR_NULL()) rather than relying solely on a NULL check.
-
buildroot-external/board/raspberrypi/patches/linux/0008-misc-rp1-pio-Demote-fw-probe-error-to-warning.patch:
Replace the existingif (!fw)condition with anif (IS_ERR(fw))(or combinedIS_ERR_OR_NULL(fw)) check. -
buildroot-external/board/raspberrypi/patches/linux/0005-misc-rp1-pio-Error-out-on-incompatible-firmware.patch:
Update the correspondingNULLcheck to useIS_ERR()so that all error cases are correctly detected.
This adjustment is required to ensure that any error returned as an error pointer is properly handled by all call sites.
4 participants
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Tests
Chores