Update all platforms to latest stable Linux 6.12 #3850
Conversation
|
Status/TODO:
|
Upgrade all Rockchip boards to latest 6.12. Patches for M1S can be dropped, its DTS has been merged. Same goes for the Rockchip TRNG, it only had to be enabled in the Green DTS. Patch for broken combphy has been updated for 6.12.y.
Many symbols have been removed between 6.6 and 6.12. Most of them have no use in Rockchip defconfig, or should be set by other kernel fragments anyway. Remove all of them, with the exception of USB_ONBOARD_HUB (which was renamed to USB_ONBOARD_DEV) and FSCACHE (which was changed from tristate to bool).
Removed couple of deprecated/unrelated kernel options.
Cleaned up symbols unrelated/deprecated in 6.12 from defconfig.
The usual defconfigs suspects had to been removed and the regulator patch for ethernet needed a minor update after refactoring in upstream.
Needed defconfig cleanup for 6.12, otherwise no changes.
This way the extra patches directory can be removed too.
sairon
force-pushed
the
linux-6.12-everything
branch
from
2aa5423 to
c84c01e
Compare
The TRNG on RK3566 supposedly [1] has low quality, that's why it's disabled in upstream for this SoC. We had it enabled in the past and without it, the boot is delayed by quite a lot. Enable it again for now and investigate the RNG issues later. [1] https://patchew.org/linux/[email protected]/
|
Build finished without errors for all platforms (just the missing comphy patch and the RNG patch for M1S are missíng there, resulting in partial breakage on M1/M1S), artifacts are available here: https://github.com/home-assistant/operating-system/actions/runs/13074944941 |
📝 WalkthroughWalkthroughThe commit updates multiple board configurations and device tree sources across the kernel and Buildroot environments. Kernel version numbers are upgraded primarily to 6.12.11, and several configuration options have been added, removed, or modified. Notable changes include enabling/disabling hardware features (e.g., USB onboard devices, Bluetooth, TRNG, LED representation, power button, UART/I2C nodes), adjustments to voltage thresholds and reset handlers, and reversion of prior modifications that impacted DMA for UARTs and USB core functions. Additionally, numerous defconfigs and DTS files have been updated to align with mainline requirements. Changes
Sequence Diagram(s)sequenceDiagram
participant RouteLookup as Route Lookup
participant IPv6Config as IPv6 Config
participant RouteEngine as Route Engine
RouteLookup->>IPv6Config: Check forwarding status\nand IPV6_REACHABILITY_PROBE flag
alt Either forwarding disabled or flag enabled
IPv6Config-->>RouteLookup: Approved for probing
RouteLookup->>RouteEngine: Set RT6_LOOKUP_F_REACHABLE flag
else
IPv6Config-->>RouteLookup: Probing not enabled
end
sequenceDiagram
participant Probe as Probe Function
participant RebootHandler as Reboot Handler
participant PMIC as PMIC Ethernet Reset Function
Probe->>RebootHandler: Register reboot handler during probe
RebootHandler->>PMIC: Issue command to turn off Ethernet power
PMIC-->>PMIC: Wait 10ms delay
PMIC->>RebootHandler: Command to turn on Ethernet power
RebootHandler->>Probe: Ethernet power reset complete
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (2)
💤 Files with no reviewable changes (1)
🔇 Additional comments (2)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 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: 0
🔭 Outside diff range comments (1)
buildroot-external/board/asus/tinker/patches/linux/0002-ARM-DTS-rk3288-tinker-Defining-the-SPI-interface.patch (1)
33-37: Use standard SPI device compatible string.The custom compatible string "rockchip,spi_tinker" is non-standard. Consider using the standard "spidev" compatible string if this is for userspace SPI access.
- compatible = "rockchip,spi_tinker"; + compatible = "spidev";
🧹 Nitpick comments (9)
buildroot-external/board/hardkernel/odroid-xu4/patches/linux/0001-ODROID-XU4-regulator-s2mps11-add-ethernet-power-rese.patch (2)
31-80: Define constants for magic numbers and optimize register operations.The function implementation is solid with proper error handling, but could be improved:
- Define constants for magic numbers:
+#define S2MPS11_LDO_ENABLE_MASK 0xFF +#define S2MPS11_LDO_DISABLE_MASK 0x3F +#define S2MPS11_LDO_ON_VALUE 0x72
- The initial register reads (L15CTRL, L17CTRL) store values in
reg_valbut don't use them. Consider removing these reads if they're not necessary for validation.
89-93: Use msleep instead of mdelay for better system responsiveness.While the power cycle sequence is correct, using
mdelayfor a 10ms delay in a probe function can impact system responsiveness. Consider usingmsleepinstead:dev_info(&pdev->dev, "Resetting Ethernet\n"); s2mps11_pmic_ethonoff(pdev, false); - mdelay(10); + msleep(10); s2mps11_pmic_ethonoff(pdev, true);
mdelaybusy-waits and blocks the CPU, whilemsleepallows other tasks to run during the delay.buildroot-external/board/asus/tinker/patches/linux/0008-usb-audio-add-ASUS-TinkerBoard-s-ALC4040.patch (1)
23-29: Improve code style while maintaining functionality.The identification of the onboard ALC4040 CODEC is good, but the code style could be improved.
Consider these style improvements:
- /* Tinker Board ALC4040 CODEC */ - - if(USB_ID_VENDOR(chip->usb_id) == 0x0bda && - USB_ID_PRODUCT(chip->usb_id) == 0x481a) { - strlcat(card->shortname, " OnBoard", sizeof(card->shortname)); - } - + /* Tinker Board ALC4040 CODEC */ + if (USB_ID_VENDOR(chip->usb_id) == 0x0bda && + USB_ID_PRODUCT(chip->usb_id) == 0x481a) { + strlcat(card->shortname, " OnBoard", sizeof(card->shortname)); + }buildroot-external/board/hardkernel/patches/linux/0008-arm64-dts-amlogic-add-uartA-uartC-to-ODROID-C2.patch (1)
19-20: LGTM! Consider adding pin documentation.The UART nodes are well-structured with proper aliases and pin configurations. Consider adding a comment documenting the physical pin assignments for easier hardware integration.
Also applies to: 28-38
buildroot-external/board/hardkernel/patches/linux/0002-arm64-dts-meson-g12b-add-GPIO-fan-support.patch (1)
23-32: Consider making the fan status configurable.While the implementation is correct, having the fan enabled by default (
status = "okay") might not be suitable for all configurations. Consider:
- Making the status configurable through board-specific overlays
- Adding documentation about the binary nature of the control (on/off only)
buildroot-external/board/asus/tinker/patches/linux/0002-ARM-DTS-rk3288-tinker-Defining-the-SPI-interface.patch (1)
34-34: Fix inconsistent register format.The register format is inconsistent between the two SPI device nodes:
- spidev@0 uses
reg = <0x0 0>- spidev@1 uses
reg = <0x1>Use consistent format:
- reg = <0x0 0>; + reg = <0x0>;Also applies to: 41-41
buildroot-external/board/hardkernel/patches/linux/0003-arm64-dts-meson-g12b-odroid-n2-add-fan-as-cooling-de.patch (1)
27-63: LGTM! Well-structured thermal management implementation.The thermal management configuration is well-designed with:
- Proper temperature threshold (65°C) and hysteresis (5°C)
- Progressive cooling strategy using multiple trip points
- Comprehensive cooling maps covering both CPU cores and fan
Consider monitoring thermal throttling events in production to validate these thresholds. You might want to collect metrics on:
- Frequency of fan activation
- Time spent in each thermal zone
- Impact on CPU performance
This data could help fine-tune the thermal policy if needed.buildroot-external/board/asus/tinker/patches/linux/0006-drivers-mmc-dw-mci-rockchip-Handle-ASUS-Tinkerboard-.patch (2)
65-65: Replace debug messages with meaningful logs.The current debug messages ("Meow" and "woeM") should be replaced with descriptive logs that indicate the actual operation being performed.
- printk(KERN_ERR "Meow.\n"); + printk(KERN_INFO "dw_mci_rockchip: Powering off MMC before reboot\n"); - printk(KERN_ERR "woeM.\n"); + printk(KERN_INFO "dw_mci_rockchip: MMC power sequence completed\n");Also applies to: 77-77
43-101: LGTM! Well-implemented reboot handler for SDMMC hardware.The implementation correctly handles the SDMMC power state during reboot:
- Proper machine compatibility check
- Correct power sequencing with delay
- Appropriate voltage settings
Consider adding error handling for regulator operations to make the implementation more robust.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (56)
Documentation/kernel.md(1 hunks)buildroot-external/board/arm-uefi/generic-aarch64/kernel.config(1 hunks)buildroot-external/board/asus/tinker/kernel.config(0 hunks)buildroot-external/board/asus/tinker/patches/linux/0001-Revert-ARM-dts-rockchip-use-DMA-channels-for-UARTs-f.patch(5 hunks)buildroot-external/board/asus/tinker/patches/linux/0002-ARM-DTS-rk3288-tinker-Defining-the-SPI-interface.patch(2 hunks)buildroot-external/board/asus/tinker/patches/linux/0003-ARM-dts-rockchip-enable-I2C1-4-on-rk3288-tinker.patch(2 hunks)buildroot-external/board/asus/tinker/patches/linux/0004-RK3288-DTSI-rk3288.dtsi-Add-missing-SPI2-pinctrl.patch(2 hunks)buildroot-external/board/asus/tinker/patches/linux/0005-ARM-DTSI-rk3288-tinker-Improving-the-CPU-max-voltage.patch(2 hunks)buildroot-external/board/asus/tinker/patches/linux/0006-drivers-mmc-dw-mci-rockchip-Handle-ASUS-Tinkerboard-.patch(4 hunks)buildroot-external/board/asus/tinker/patches/linux/0007-ARM-dts-rockchip-Add-Bluetooth-to-rk3288-tinker.patch(2 hunks)buildroot-external/board/asus/tinker/patches/linux/0008-usb-audio-add-ASUS-TinkerBoard-s-ALC4040.patch(2 hunks)buildroot-external/board/hardkernel/kernel-amlogic.config(0 hunks)buildroot-external/board/hardkernel/odroid-m1s/patches/linux/0001-arm64-dts-rockchip-Enable-Rockchip-TRNG-on-ODROID-M1.patch(1 hunks)buildroot-external/board/hardkernel/odroid-m1s/patches/linux/0001-arm64-dts-rockchip-Import-Hardkernel-ODROID-M1S-boar.patch(0 hunks)buildroot-external/board/hardkernel/odroid-m1s/patches/linux/0002-arm64-dts-clean-up-as-required-for-mainline-linux.patch(0 hunks)buildroot-external/board/hardkernel/odroid-m1s/patches/linux/0003-arm64-dts-fix-vdd_cpu-regulator-for-mainline.patch(0 hunks)buildroot-external/board/hardkernel/odroid-m1s/patches/linux/0005-Remove-deprecated-snps-reset-properties.patch(0 hunks)buildroot-external/board/hardkernel/odroid-xu4/patches/linux/0001-ODROID-XU4-regulator-s2mps11-add-ethernet-power-rese.patch(3 hunks)buildroot-external/board/hardkernel/patches/linux/0001-arm64-dts-meson-g12b-add-power-button-support.patch(2 hunks)buildroot-external/board/hardkernel/patches/linux/0002-arm64-dts-meson-g12b-add-GPIO-fan-support.patch(2 hunks)buildroot-external/board/hardkernel/patches/linux/0003-arm64-dts-meson-g12b-odroid-n2-add-fan-as-cooling-de.patch(2 hunks)buildroot-external/board/hardkernel/patches/linux/0004-arm64-dts-meson-add-uart_A-node.patch(2 hunks)buildroot-external/board/hardkernel/patches/linux/0005-arm64-dts-meson-add-i2c2-node-to-ODROID-N2-N2.patch(2 hunks)buildroot-external/board/hardkernel/patches/linux/0006-ODROID-C4-arm64-dts-add-uart_A-node.patch(3 hunks)buildroot-external/board/hardkernel/patches/linux/0007-ODROID-C4-arm64-dts-add-i2c2-i2c3-node.patch(3 hunks)buildroot-external/board/hardkernel/patches/linux/0008-arm64-dts-amlogic-add-uartA-uartC-to-ODROID-C2.patch(3 hunks)buildroot-external/board/hardkernel/patches/linux/0009-arm64-dts-amlogic-meson-gx-add-missing-pins-for-I2C-.patch(3 hunks)buildroot-external/board/khadas/kernel-vim.config(0 hunks)buildroot-external/board/nabucasa/green/patches/linux/0001-arm64-dts-rockchip-Add-NabuCasa-Green-board.patch(3 hunks)buildroot-external/board/nabucasa/green/patches/linux/0002-drivers-mfd-rk808-set-PWRON_LP_OFF_TIME-12s.patch(3 hunks)buildroot-external/board/nabucasa/green/patches/linux/0003-arch-arm64-dts-green-Remove-spiflash-partitions.patch(2 hunks)buildroot-external/board/nabucasa/green/patches/linux/0004-Input-rk805-pwrkey-reverse-polarity-of-pwrkey.patch(2 hunks)buildroot-external/board/nabucasa/green/patches/linux/0005-green-emmc-use-HS200-mode.patch(2 hunks)buildroot-external/board/nabucasa/green/patches/linux/0006-arch-arm64-dts-green-Improve-LED-representation.patch(2 hunks)buildroot-external/board/pc/patches/linux/0001-iwlwifi-Make-missed-beacon-timeout-configurable.patch(0 hunks)buildroot-external/configs/generic_aarch64_defconfig(2 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(1 hunks)buildroot-external/configs/odroid_c4_defconfig(1 hunks)buildroot-external/configs/odroid_m1_defconfig(1 hunks)buildroot-external/configs/odroid_m1s_defconfig(1 hunks)buildroot-external/configs/odroid_n2_defconfig(1 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/kernel-arm64-rockchip.config(2 hunks)buildroot-external/patches-rockchip/linux/0001-Revert-phy-rockchip-naneng-combphy-fix-phy-reset.patch(2 hunks)buildroot-external/patches-rockchip/linux/0001-hwrng-add-Rockchip-SoC-hwrng-driver.patch(0 hunks)buildroot-external/patches-rockchip/linux/0002-arm64-dts-rockchip-add-DT-entry-for-RNG-to-RK356x.patch(0 hunks)buildroot-external/patches-rockchip/linux/0003-dt-bindings-RNG-Add-Rockchip-RNG-bindings.patch(0 hunks)buildroot-external/patches/linux/6.12.11/0001-ipv6-add-option-to-explicitly-enable-reachability-te.patch(3 hunks)buildroot-external/patches/linux/6.12.11/0002-Revert-USB-core-changes-causing-issues-with-Z-Wave.m.patch(22 hunks)buildroot-external/patches/linux/6.6.73/0001-ipv6-add-option-to-explicitly-enable-reachability-te.patch(0 hunks)buildroot-external/patches/linux/6.6.73/0002-Revert-USB-core-changes-causing-issues-with-Z-Wave.m.patch(0 hunks)
💤 Files with no reviewable changes (13)
- buildroot-external/patches/linux/6.6.73/0001-ipv6-add-option-to-explicitly-enable-reachability-te.patch
- buildroot-external/patches-rockchip/linux/0002-arm64-dts-rockchip-add-DT-entry-for-RNG-to-RK356x.patch
- buildroot-external/patches/linux/6.6.73/0002-Revert-USB-core-changes-causing-issues-with-Z-Wave.m.patch
- buildroot-external/board/hardkernel/odroid-m1s/patches/linux/0001-arm64-dts-rockchip-Import-Hardkernel-ODROID-M1S-boar.patch
- buildroot-external/board/khadas/kernel-vim.config
- buildroot-external/board/pc/patches/linux/0001-iwlwifi-Make-missed-beacon-timeout-configurable.patch
- buildroot-external/patches-rockchip/linux/0003-dt-bindings-RNG-Add-Rockchip-RNG-bindings.patch
- buildroot-external/board/hardkernel/odroid-m1s/patches/linux/0003-arm64-dts-fix-vdd_cpu-regulator-for-mainline.patch
- buildroot-external/patches-rockchip/linux/0001-hwrng-add-Rockchip-SoC-hwrng-driver.patch
- buildroot-external/board/hardkernel/kernel-amlogic.config
- buildroot-external/board/hardkernel/odroid-m1s/patches/linux/0002-arm64-dts-clean-up-as-required-for-mainline-linux.patch
- buildroot-external/board/asus/tinker/kernel.config
- buildroot-external/board/hardkernel/odroid-m1s/patches/linux/0005-Remove-deprecated-snps-reset-properties.patch
🧰 Additional context used
📓 Path-based instructions (1)
Documentation/kernel.md (6)
Pattern */**(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'
Pattern */**(html|markdown|md): - Use bold to mark UI strings.
- If "" are used to mark UI strings, replace them by bold.
Pattern */**(html|markdown|md): - Be brief in your replies and don't add fluff like "thank you for..." and "Please let me know if"
Pattern */**(html|markdown|md): - Use sentence-style capitalization also in headings.
Pattern */**(html|markdown|md): do not comment on HTML used for icons
Pattern */**(html|markdown|md): Avoid flagging inline HTML for embedding videos in future reviews for this repository.
🔇 Additional comments (54)
buildroot-external/board/hardkernel/odroid-xu4/patches/linux/0001-ODROID-XU4-regulator-s2mps11-add-ethernet-power-rese.patch (1)
1-19: LGTM! Well-structured commit message.The commit message clearly explains the problem (Ethernet detection issues on warm boot), the solution (power reset routines), and includes proper attribution with signed-off lines. The update note for Linux 6.11+ compatibility is helpful.
buildroot-external/board/nabucasa/green/patches/linux/0004-Input-rk805-pwrkey-reverse-polarity-of-pwrkey.patch (4)
1-13: Well-structured patch with clear commit message.The commit message effectively communicates:
- The problem: power key is low active
- The impact: involuntary long presses in user space
- The solution: reversing the logic
18-27: Correct implementation of low-active power key behavior in fall handler.The change in
pwrkey_fall_irqproperly reflects the low-active nature of the power key by reporting KEY_POWER as not pressed (0) when a falling edge is detected.
27-36: Correct implementation of low-active power key behavior in rise handler.The change in
pwrkey_rise_irqmaintains symmetry with the fall handler by reporting KEY_POWER as pressed (1) when a rising edge is detected, completing the logical reversal for low-active behavior.
1-36: Verify the power key behavior in the target environment.While the changes are logically correct, it would be beneficial to verify:
- The power key functions as expected on actual hardware
- No unintended side effects on power management features
buildroot-external/patches/linux/6.12.11/0002-Revert-USB-core-changes-causing-issues-with-Z-Wave.m.patch (4)
36-64: Double-check root hub descriptor logic after reversion.These lines revert the previous changes related to fetching and storing device descriptors in
register_root_hub(). Although this patch aims to fix known Z-Wave issues, reverting these commits could potentially restore older handling quirks or race conditions. Please verify that root hub initialization remains stable with different USB speeds and device classes.As a follow-up, you might run a stress test script that repeatedly binds/unbinds a variety of USB devices (including Z-Wave sticks and standard flash drives) to confirm no regressions were reintroduced.
637-648: Consistent function signature forusb_get_device_descriptor.Reverting the signature in
usb.hensures consistency with the revertedmessage.clogic. However, confirm that any external modules or out-of-tree drivers that might have started depending on the changed signature do not break, as userland documentation or external kernel modules are sometimes behind these changes.If you maintain out-of-tree drivers, compile them in a staging environment against this revert to confirm no build or runtime errors occur.
580-633: Ensure revertedusb_get_device_descriptorchanges don’t break descriptor reads elsewhere.Rolling back to the older version of
usb_get_device_descriptorreintroduces a synchronous call that returns the number of bytes received (or an error). This could fix the conflicts with the Z-Wave stick but might cause subtle issues if any other subsystem depended on the updated API’s behavior. Please verify that no other in-tree changes rely on the newer descriptor retrieval approach.A quick codebase check can confirm that no references to the removed return type or signature remain:
✅ Verification successful
USB Descriptor API Reversion Verified
- The search confirms that all updates to the
usb_get_device_descriptorAPI have been localized to the revert patch files.- No other in-tree references expect the newer signature; all call sites now use the reverted, synchronous signature.
- Descriptor reads elsewhere should remain unaffected by this revert.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for references to the new signature to ensure they don’t exist rg -A 3 -B 3 "usb_get_device_descriptor"Length of output: 20867
68-333: Watch for reintroduced concurrency issues or earlier initialization pitfalls inhub.c.This extensive reversion brings back an older approach to reading device descriptors, especially around bMaxPacketSize0 and race handling in
hub_port_init(). While it fixes conflicts with specific hardware (Z-Wave sticks), it may also restore concurrency issues that the previous commits aimed to resolve (e.g., a race in overwritingudev->descriptor). To avoid surprises, consider thoroughly testing hot-plug scenarios, especially with multi-port hubs, high-speed, and SuperSpeed devices.Run a specialized hot-plug script:
Expect to see no kernel panics, no USB enumeration failures, and consistent device descriptor data.
buildroot-external/board/nabucasa/green/patches/linux/0005-green-emmc-use-HS200-mode.patch (1)
17-19: Verify HS200 support and signal integrity.By adding
mmc-hs200-1_8v;, the eMMC interface now operates in HS200 mode. This can significantly boost throughput but also demands that signaling and board-level constraints (voltage rails, line termination, etc.) are properly configured. Verify that the board's design supports HS200 and run stress tests to confirm reliable operation under load.Ensure data integrity in HS200 mode by reading/writing large files repeatedly. Look for potential CRC errors or throughput inconsistencies in dmesg logs.
buildroot-external/board/asus/tinker/patches/linux/0003-ARM-dts-rockchip-enable-I2C1-4-on-rk3288-tinker.patch (2)
21-23: Confirm pin configuration for newly enabled I2C1.Enabling I2C1 is straightforward, but validate that the associated pins are configured in the pinmux to match this “okay” status. If mismatched or missing pinmux settings exist, the bus might remain nonfunctional.
Use an I2C probe tool or attach a known I2C device and confirm it enumerates on bus 1.
29-31: Validate usage of I2C4 from the 40-pin header.Similarly, enabling I2C4 from the expansion header is helpful for add-on boards. Please verify the node definitions and any default pin assignments. Some expansions might require further pull-up resistor configurations.
buildroot-external/board/hardkernel/patches/linux/0009-arm64-dts-amlogic-meson-gx-add-missing-pins-for-I2C-.patch (1)
17-21: LGTM! Good addition of missing I2C pin configurations.The patch properly adds the required pinctrl settings for both I2C A and B interfaces, which is essential for their functionality. The changes are consistent and follow device tree conventions.
Also applies to: 26-30
buildroot-external/board/hardkernel/patches/linux/0006-ODROID-C4-arm64-dts-add-uart_A-node.patch (1)
17-22: LGTM! Well-structured UART enhancement.The patch properly adds support for a second serial interface (UART_A) with appropriate pin configurations while maintaining the existing UART_AO setup. The alias ordering change preserves backward compatibility.
Also applies to: 29-33
buildroot-external/board/asus/tinker/patches/linux/0005-ARM-DTSI-rk3288-tinker-Improving-the-CPU-max-voltage.patch (1)
17-25: Verify implications of increased CPU voltage.While the change is straightforward, increasing the maximum CPU voltage from 1.4V to 1.45V could impact power consumption and thermal characteristics.
Please ensure:
- The voltage increase is necessary and safe for the hardware
- Thermal management can handle the potential increased heat output
- Power supply specifications support the higher voltage requirement
buildroot-external/board/hardkernel/patches/linux/0004-arm64-dts-meson-add-uart_A-node.patch (3)
6-7: LGTM! Well-documented hardware configuration.The commit message clearly documents that UART_A is available through J3 pin 8/10 and is configured as UART by default.
21-23: LGTM! Proper alias configuration.The serial1 alias is correctly added to reference the uart_A node, maintaining consistency with the existing serial0 alias.
30-34: LGTM! Standard UART node configuration.The uart_A node is properly configured with:
- Status set to "okay"
- Pinctrl settings using uart_a_pins
- Default pinctrl-names
buildroot-external/board/asus/tinker/patches/linux/0004-RK3288-DTSI-rk3288.dtsi-Add-missing-SPI2-pinctrl.patch (2)
6-7: LGTM! Clear documentation of the missing pin.The commit message clearly identifies the missing spi2_cs1 pin reference in the SPI2 pinctrl configuration.
24-25: LGTM! Complete SPI2 pinctrl configuration.The patch correctly adds the missing spi2_cs1 pin to the existing pinctrl-0 property, completing the SPI2 pin configuration.
buildroot-external/board/hardkernel/patches/linux/0005-arm64-dts-meson-add-i2c2-node-to-ODROID-N2-N2.patch (2)
6-8: LGTM! Detailed hardware documentation.The commit message provides clear documentation of:
- Pin locations (J2 connector pins 3 and 5)
- GPIO connections (GPIOX_17/18)
- I2C instance selection
23-27: LGTM! Standard I2C node configuration.The i2c2 node is properly configured with:
- Status set to "okay"
- Pinctrl settings using i2c2_sda_x_pins and i2c2_sck_x_pins
- Default pinctrl-names
buildroot-external/board/hardkernel/odroid-m1s/patches/linux/0001-arm64-dts-rockchip-Enable-Rockchip-TRNG-on-ODROID-M1.patch (2)
9-11: LGTM! Clear context for the change.The commit message explains:
- Previous state (RNG disabled in 6.6 kernel)
- Current state (enabled only in rk3568.dtsi)
- Need for enabling on RK3566 ODROID-M1S
26-28: LGTM! Simple RNG node enablement.The rng node is correctly enabled with status set to "okay".
buildroot-external/board/hardkernel/patches/linux/0001-arm64-dts-meson-g12b-add-power-button-support.patch (1)
23-32: LGTM! Well-structured power button implementation.The GPIO configuration and polling setup look correct. The 100ms polling interval provides a good balance between responsiveness and system load.
buildroot-external/patches-rockchip/linux/0001-Revert-phy-rockchip-naneng-combphy-fix-phy-reset.patch (1)
28-29: LGTM! Monitor for upstream fix.The revert is necessary to fix USB3 and PCIe regression. However, we should:
- Track the upstream discussion for a proper fix
- Consider adding a comment in the code about this being a temporary revert
Let's check if there are any related changes in the upstream kernel:
buildroot-external/board/nabucasa/green/patches/linux/0003-arch-arm64-dts-green-Remove-spiflash-partitions.patch (2)
18-21: Verify SPI flash timing changes.The SPI flash frequency is reduced from 100MHz to 25MHz and rx bus width from 4 to 1. While this may improve stability, it could impact performance.
Please confirm:
- The flash chip's specifications support these parameters
- These changes don't significantly impact boot time
- The changes resolve any stability issues
✅ Verification successful
SPI flash timing changes verified.
- The DTS and U-Boot patches consistently reduce the SPI flash frequency to 25MHz and rx bus width to 1, which aligns with a conservative, stable setting for generic JEDEC SPI NOR devices.
- Given that the flash chip’s maximum frequency is typically higher than 25MHz, these parameters are well within its operating range and should not adversely affect boot time.
- The coordinated changes in both Linux and U-Boot support the intention to address stability issues without compromising system boot performance.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for SPI flash chip model/specs in DTS and documentation rg -A 5 "jedec,spi-nor"Length of output: 4634
24-49: Verify partition removal impact.Removing the SPI flash partitions suggests the layout is now managed elsewhere (e.g., U-Boot).
Please confirm:
- The bootloader is properly configured to handle partitioning
- This change doesn't break the boot process
- The filesystem partition is properly handled
✅ Verification successful
Partition Removal Verification: U-Boot Handles the Layout
- The Linux DTS patch removes the SPI flash partition definitions (SPL, U-Boot Env, U-Boot, splash, Filesystem), and corresponding U-Boot patches (e.g. in the nabucasa/green board’s u-boot DTS additions) now reintroduce these definitions.
- U-Boot configuration and meta files (such as the image-spl-spl.cfg and associated patch files) show that the bootloader is correctly configured with the needed partitioning for SPL, U-Boot environment, and filesystem.
- There is no indication from the repository references that the boot process is broken; the partition removal in Linux is intentional as the layout is now solely managed by U-Boot.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for related partition definitions rg -A 5 "SPL|U-Boot|Filesystem"Length of output: 77793
buildroot-external/board/nabucasa/green/patches/linux/0002-drivers-mfd-rk808-set-PWRON_LP_OFF_TIME-12s.patch (1)
31-34: LGTM! Power-off timing configuration looks good.Setting PWRON_LP_OFF_TIME to 12s (maximum available) is a good choice as it provides ample time for clean system shutdown.
buildroot-external/board/nabucasa/green/patches/linux/0006-arch-arm64-dts-green-Improve-LED-representation.patch (1)
19-46: LGTM! LED representation improvements are well-structured.The changes improve clarity through:
- Descriptive node names that match functionality
- Consistent labeling
- Appropriate LED colors for their functions (white for power, green for activity, yellow for user)
buildroot-external/board/asus/tinker/patches/linux/0007-ARM-dts-rockchip-Add-Bluetooth-to-rk3288-tinker.patch (2)
22-34: LGTM! Well-structured GPIO configuration for Bluetooth.The GPIO pin configurations are well-defined with clear naming and proper use of RK_FUNC_GPIO and pcfg_pull_none macros.
41-54: Verify UART0 availability for Bluetooth.The UART and Bluetooth configuration looks correct, following the standard rtl8723bs-bt binding. However, ensure that UART0 isn't being used for other critical functions (e.g., console, debug).
✅ Verification successful
UART0 appears to be available for Bluetooth use.
Based on our repository-wide search in the DTS files:
- There were no additional references indicating that UART0 is used as the console or for debugging.
- The configuration added by the patch follows the standard rtl8723bs-bt binding, with no conflicting usage detected.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for other UART0 uses in device tree files rg -A 5 "uart0|serial0" arch/arm/boot/dts/Length of output: 103
Script:
#!/bin/bash # Re-run the search across the entire repository for any device tree source files (DTS) # that mention "uart0". This will help verify that UART0 isn’t used for critical functions # (e.g., console, debug) beyond the Bluetooth configuration. fd -e dts | xargs grep -H "uart0"Length of output: 33
buildroot-external/patches/linux/6.12.11/0001-ipv6-add-option-to-explicitly-enable-reachability-te.patch (2)
27-34: LGTM! Well-documented Kconfig option.The new option is clearly described with proper help text explaining its purpose and implications.
47-50: Verify impact on IPv6 routing performance.The condition change looks correct, but we should verify the performance impact of enabling reachability probing on router devices.
✅ Verification successful
IPv6 routing performance impact appears negligible.
- The additional conditional check using
IS_ENABLED(CONFIG_IPV6_REACHABILITY_PROBE)is compiled away when the configuration option is disabled, ensuring no runtime overhead.- Similar implementations exist across multiple board configurations (e.g., Raspberry Pi, Hardkernel) without noted performance issues.
- The extra check is a simple boolean evaluation, which is unlikely to affect routing performance significantly on router devices.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for other IPv6 reachability probe references rg "RT6_LOOKUP_F_REACHABLE" net/ipv6/Length of output: 87
Script:
#!/bin/bash # Search the entire repository for IPv6 reachability-related references, # including the flag RT6_LOOKUP_F_REACHABLE and the configuration option. rg "RT6_LOOKUP_F_REACHABLE" rg "CONFIG_IPV6_REACHABILITY_PROBE"Length of output: 1013
buildroot-external/board/asus/tinker/patches/linux/0001-Revert-ARM-dts-rockchip-use-DMA-channels-for-UARTs-f.patch (1)
16-51: Verify UART performance impact without DMA.Removing DMA support from all UARTs could impact performance, especially for high-speed serial communication. Please ensure this doesn't affect critical use cases.
buildroot-external/board/hardkernel/patches/linux/0007-ODROID-C4-arm64-dts-add-i2c2-i2c3-node.patch (2)
27-54: LGTM! Well-configured I2C nodes with clear documentation.The I2C nodes are properly configured with appropriate clock frequencies and clear documentation of pin mappings to the 40-pin header.
56-76: LGTM! Proper pin control configuration.The pin control settings are well-defined with appropriate bias-pull-up and drive strength values for I2C operation.
buildroot-external/configs/khadas_vim3_defconfig (1)
19-19: LGTM! Kernel version update aligns with PR objective.The changes correctly update:
- Kernel version to 6.12.11
- Configuration fragment paths to v6.12.y
Let's verify the kernel version update is consistent across all platform configs:
Also applies to: 22-22
✅ Verification successful
Kernel version update verified consistently across all platform configs.
The script output confirms that every relevant defconfig file in the repository, includingbuildroot-external/configs/khadas_vim3_defconfig, usesBR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="6.12.11".
- Verified platforms: tinker, ova, odroid_xu4, odroid_n2, odroid_c4, odroid_c2, khadas_vim3, green, odroid_m1s, generic_x86_64, odroid_m1, generic_aarch64.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify kernel version consistency across all platform configs echo "Checking kernel version in all platform configs..." rg -l 'BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE' buildroot-external/configs/ | \ xargs rg 'BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="[^"]*"'Length of output: 1385
buildroot-external/configs/odroid_c4_defconfig (1)
19-19: Duplicate comment: See review of khadas_vim3_defconfig.Also applies to: 22-22
buildroot-external/configs/odroid_c2_defconfig (1)
19-19: Verify hardware support in Linux 6.12 for Amlogic GXBB.The kernel update from 6.6 to 6.12 is significant. While the changes look correct, ensure that all hardware features of the Odroid C2 (Amlogic GXBB SoC) are fully supported in Linux 6.12.
Run this script to check for potential hardware support regressions:
Also applies to: 22-22
buildroot-external/configs/tinker_defconfig (1)
21-21: Verify Rockchip RK3288 support in Linux 6.12.The kernel update looks correct. The Tinker Board uses the mature RK3288 SoC, but it's important to verify that all hardware features remain supported in Linux 6.12.
Run this script to check for potential hardware support regressions:
Also applies to: 24-24
✅ Verification successful
RK3288 support in Linux 6.12 confirmed.
The search results show extensive references to "RK3288"—from DTS files (e.g., "rk3288-tinker", "rk3288-tinker-s" in tinker_defconfig) to kernel configuration options and multiple board patches. These indicate that the Linux 6.12 branch continues to include and support the necessary hardware features for the RK3288 SoC on the ASUS Tinker Board.
buildroot-external/configs/tinker_defconfigsets the in-tree DTS names to "rockchip/rk3288-tinker rockchip/rk3288-tinker-s".- Several DTS and config patches explicitly target RK3288 support.
- Kernel config file
buildroot-external/kernel/v6.12.y/kernel-arm64-rockchip.configconfirms that relevant RK3288 options (e.g., CONFIG_SND_SOC_RK3288_HDMI_ANALOG) are in place.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for RK3288 support in Linux 6.12 # Search for RK3288-related changes in kernel config rg -A 5 "ROCKCHIP.*RK3288|ARCH_RK3288" kernel/v6.12.y/ # Check DTS changes for the platform ast-grep --pattern $'rk3288-tinker { $$$ }'Length of output: 159
Script:
#!/bin/bash # Combined search for RK3288 support references in the entire repository echo "Searching for RK3288 references (case-insensitive):" rg -i "RK3288" . echo -e "\nSearching for ROCKCHIP references (case-insensitive):" rg -i "rockchip" . echo -e "\nSearching for DTS files mentioning rk3288:" rg -i "rk3288" --glob="*.dts" .Length of output: 63637
buildroot-external/configs/odroid_xu4_defconfig (1)
20-20: Verify Exynos5422 support and platform-specific features in Linux 6.12.The kernel update looks correct. The Odroid XU4 uses the Exynos5422 SoC and has additional platform-specific kernel configurations. Ensure all hardware features and platform-specific configurations remain compatible with Linux 6.12.
Run this script to check for potential hardware support regressions:
Also applies to: 22-22
buildroot-external/configs/odroid_n2_defconfig (1)
19-19: Verify Amlogic G12B support and platform-specific features in Linux 6.12.The kernel update looks correct. The Odroid N2/N2+ uses the Amlogic G12B SoC and has additional platform-specific kernel configurations. Ensure all hardware features and platform-specific configurations remain compatible with Linux 6.12.
Run this script to check for potential hardware support regressions:
Also applies to: 22-22
✅ Verification successful
Kernel Version and Amlogic G12B Support Verified
- The odroid_n2_defconfig file correctly sets the kernel version to 6.12.11 and includes the DTS names ("amlogic/meson-g12b-odroid-n2 amlogic/meson-g12b-odroid-n2-plus") relevant for the Amlogic G12B SoC.
- Recursive searches confirm that Amlogic references and board-specific DTS patches are in place, and documentation reflects consistent Linux 6.12.11 usage across ODROID boards.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for Amlogic G12B support and N2-specific features in Linux 6.12 # Search for G12B-related changes in kernel config rg -A 5 "MESON_G12B|AMLOGIC.*G12B" kernel/v6.12.y/ # Check platform-specific kernel config cat board/hardkernel/odroid-n2/kernel.config # Check DTS changes for both N2 and N2+ variants ast-grep --pattern $'meson-g12b-odroid-n2 { $$$ }' ast-grep --pattern $'meson-g12b-odroid-n2-plus { $$$ }'Length of output: 341
Script:
#!/bin/bash # New verification script to gather more context on Amlogic G12B support and kernel version usage. # 1. Display the first 30 lines of the odroid_n2_defconfig to verify the kernel version update. echo "=== buildroot-external/configs/odroid_n2_defconfig (first 30 lines) ===" if [ -f buildroot-external/configs/odroid_n2_defconfig ]; then sed -n '1,30p' buildroot-external/configs/odroid_n2_defconfig else echo "File buildroot-external/configs/odroid_n2_defconfig not found." fi # 2. Search recursively for any references to Amlogic in the repository. echo -e "\n=== Searching for 'Amlogic' references ===" rg -i "Amlogic" . # 3. Search recursively for MESON_G12B references. echo -e "\n=== Searching for 'MESON_G12B' references ===" rg -i "MESON_G12B" . # 4. Search for any references indicating Linux kernel version 6.12.11 usage. echo -e "\n=== Searching for '6.12.11' references ===" rg -n "6\.12\.11" . # 5. Additionally, search for odroid related DTS or board configuration files that might mention "odroid" echo -e "\n=== Searching for 'odroid' related DTS or board config files ===" rg -i "odroid" .Length of output: 62021
buildroot-external/configs/odroid_m1_defconfig (1)
19-22: Verify kernel version compatibility with RK3568.The kernel update to 6.12.11 looks good, but let's verify Rockchip RK3568 support in this version.
buildroot-external/configs/odroid_m1s_defconfig (1)
19-22: Verify kernel version compatibility with RK3566.The kernel update to 6.12.11 looks good, but let's verify Rockchip RK3566 support in this version.
✅ Verification successful
RK3566 Support Verified in Kernel 6.12.11
- The
odroid_m1s_defconfigfile explicitly referencesBR2_LINUX_KERNEL_INTREE_DTS_NAME="rockchip/rk3566-odroid-m1s", confirming the board’s device tree configuration.- Multiple patches and configuration files throughout the repository reference and update RK3566-specific device trees (e.g.,
rk3566-odroid-m1s.dtsand U-Boot defconfigs), indicating maintained support.- A comprehensive global search for RK3566 references did not reveal any critical issues or regressions.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check kernel 6.12.11 support for RK3566 # Test: Search for RK3566 support in device tree. Expect: Device tree file present fd "rk3566-odroid-m1s.dts" --exec grep -l "RK3566" # Test: Check for any known regressions. Expect: No critical issues rg -i "rk3566.*\b(bug|regression|break|issue)\b"Length of output: 99
Script:
#!/bin/bash # This script performs a comprehensive search for RK3566 references across the repository. # It will help verify whether kernel 6.12.11 includes the necessary support for RK3566. # # 1. Search for RK3566 in all .dts files (device trees). echo "Searching for RK3566 in .dts files:" fd "\.dts$" --exec grep -i "rk3566" {} \; # 2. Search for RK3566 in configuration files (.config and .defconfig). echo "Searching for RK3566 in configuration files (.config, .defconfig):" fd "\.(config|defconfig)$" --exec grep -i "rk3566" {} \; # 3. Perform a global repository search for any RK3566 reference. echo "Performing a global search for RK3566 references:" rg -i "rk3566" -n .Length of output: 26396
buildroot-external/configs/green_defconfig (1)
19-22: Verify kernel version compatibility with Home Assistant Green.The kernel update to 6.12.11 looks good, but let's verify support for the Green's RK3566-based platform.
buildroot-external/configs/generic_aarch64_defconfig (2)
7-7: Verify impact of removing board-specific patches.The removal of
$(BR2_EXTERNAL_HASSOS_PATH)/board/pc/patchesfromBR2_GLOBAL_PATCH_DIRmight affect platform-specific patches.✅ Verification successful
I'll generate a new shell script to search for any directory named “board/pc/patches” in the repository and to scan for textual references to it. This will help verify if there are any critical board-specific patch files that might have been inadvertently removed.
Please run the above script to gather further details on whether any board-specific patches are still being referenced or stored, which will help in assessing the impact of their removal.
Board-specific patches removal verified as safe.
- The search did not locate any "board/pc/patches" directory.
- No textual references to "board/pc/patches" were found in the repository.
These findings confirm that the removal does not inadvertently exclude any necessary board-specific patches.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any critical patches that might be excluded # Test: Look for patches in the removed directory. Expect: No critical patches fd . "board/pc/patches" -t f --exec echo "Removed patch: {}"Length of output: 164
Script:
#!/bin/bash # Script: Verify the existence of a board-specific patches directory and references to it echo "Checking if a board-specific patches directory exists (e.g., .../board/pc/patches):" find . -type d -path "*/board/pc/patches" -print || echo "No 'board/pc/patches' directory found." echo -e "\nSearching for textual references to 'board/pc/patches' in the repository:" rg "board/pc/patches" --color=never || echo "No references to 'board/pc/patches' found."Length of output: 533
19-21: Verify kernel configuration for generic ARM64.The kernel update to 6.12.11 with arch default config looks good, but let's verify ARM64 support.
✅ Verification successful
ARM64 Kernel Configuration Verified
The defconfig in buildroot-external/configs/generic_aarch64_defconfig correctly enables the arch default configuration for ARM64 (via
BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG=y), ensuring that the necessary ARM64 settings will be inherited from the kernel’s default configuration. The board-specific fragment reference is resolved externally (using$(BR2_EXTERNAL_HASSOS_PATH)), so its absence in the repository root is expected.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check kernel 6.12.11 ARM64 support # Test: Search for ARM64 config options. Expect: Essential ARM64 configs present rg "CONFIG_ARM64=y" "kernel/v6.12.y/" # Test: Check for any known ARM64 regressions. Expect: No critical issues rg -i "arm64.*\b(bug|regression|break|issue)\b"Length of output: 141
Script:
#!/bin/bash echo "Verifying ARM64 kernel configuration support..." # Check the board-specific kernel configuration referenced in the defconfig FILE="board/arm-uefi/generic-aarch64/kernel.config" echo "Checking if $FILE exists..." if [ -f "$FILE" ]; then echo "Found $FILE. Searching for CONFIG_ARM64 setting:" grep -n "CONFIG_ARM64=y" "$FILE" || echo "CONFIG_ARM64=y not found in $FILE." else echo "$FILE not found." fi # Perform a global search for any occurrences of CONFIG_ARM64=y in the repository echo "Performing a global search for CONFIG_ARM64=y:" rg -n "CONFIG_ARM64=y"Length of output: 604
Script:
#!/bin/bash echo "Searching for BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG in buildroot configs..." rg -n "BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG" buildroot-external/configs/Length of output: 342
buildroot-external/configs/generic_x86_64_defconfig (1)
19-19: LGTM: Kernel version update is consistent.The kernel version update to 6.12.11 and corresponding config fragment paths are correctly aligned.
Also applies to: 21-21
buildroot-external/configs/ova_defconfig (1)
19-19: LGTM: Kernel version update is consistent.The kernel version update to 6.12.11 and corresponding config fragment paths are correctly aligned.
Also applies to: 21-21
buildroot-external/board/nabucasa/green/patches/linux/0001-arm64-dts-rockchip-Add-NabuCasa-Green-board.patch (1)
564-566: LGTM: RNG enablement addresses reported issues.Enabling the Rockchip RNG hardware improves system security and addresses the previously reported RNG seed issues mentioned in the PR comments.
Documentation/kernel.md (1)
6-6: LGTM: Documentation accurately reflects kernel version updates.The kernel version updates are consistently documented across all affected boards, maintaining clear version tracking.
Also applies to: 14-24
buildroot-external/board/arm-uefi/generic-aarch64/kernel.config (1)
69-70: Enable USB Onboard Device Support OptionsThe diff now enables both
CONFIG_USB_ONBOARD_DEV=yandCONFIG_USB_ONBOARD_DEV_USB5744=y. This update activates onboard USB support for the generic AArch64 board, aligning with the broader kernel update objectives. Please verify that these options are supported by the Linux 6.12.x kernel on your target hardware and that they do not conflict with other USB configuration settings.buildroot-external/kernel/v6.12.y/kernel-arm64-rockchip.config (1)
3868-3869: Activate FSCACHE to Improve File CachingThe new configuration line
CONFIG_FSCACHE=y(added at line 3868) enables filesystem caching support on the Rockchip platform. This change can help enhance file I/O performance by caching remote data and other filesystem artifacts. Please ensure that this feature has been thoroughly validated on the target hardware, especially regarding any potential memory overhead on resource-constrained systems.
There was a problem hiding this comment.
Besides the location mentioned, buildroot-external/board/raspberrypi/bcmrpi3.config also seems to have CONFIG_CACHEFILES enabled, maybe we get rid of that too? 🤔
It seems there is a unused file in tree at buildroot-external/kernel/v6.6.y/kernel-arm64-rockchip.config (I think all others are used by the Raspberry Pi kernel, but not 100% sure).
Other than that, looks quite good to me.
| @@ -3908,7 +3865,7 @@ CONFIG_CUSE=m | |||
| CONFIG_VIRTIO_FS=m | |||
| CONFIG_OVERLAY_FS=y | |||
| CONFIG_OVERLAY_FS_XINO_AUTO=y | |||
| CONFIG_FSCACHE=m | |||
| CONFIG_FSCACHE=y | |||
| CONFIG_FSCACHE_STATS=y | |||
| CONFIG_CACHEFILES=m | |||
There was a problem hiding this comment.
I guess for consistency this should be deleted here too.
| CONFIG_CACHEFILES=m |
|
Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍 |
It was only enabled for Rockchip and Tinker, and to my knowledge there is no cachefiles daemon or anything other in the userspace that's using it.
Sice we only have 6.6.y for Raspberry Pi now, it doesn't need the Rockchip and wireless PCI fragments.
No such file is tracked in Git, it's maybe something only in your working directory?
Right, I removed it, along with one other unused fragment 👍 |
Whoops, right, something local. |
Update all platforms to 6.12, update kernel configs and patches. Update platforms already migrated in the previous PRs to latest 6.12.11 as well, so extra patch directories can be removed. I suggest going through individual commits rather thank looking at the whole diff when reviewing, as some of the commits introduce too much noise.
Summary by CodeRabbit
Kernel & Build Updates
Hardware Interface Enhancements
Bug Fixes & Reverts
Device Tree & Peripheral Configurations