Update generic-x86-64 Linux kernel to 6.12 #3767
Conversation
📝 WalkthroughWalkthroughThis pull request introduces a comprehensive update to the system, primarily focusing on kernel version upgrades and compatibility improvements. The changes span multiple components, including the Dockerfile, kernel configurations, buildroot configurations, and various package updates. The most significant change is the upgrade of the Linux kernel for x86-64 systems from version 6.6.73 to 6.12.6, with corresponding adjustments to configuration files, driver patches, and system configurations to ensure compatibility with the new kernel version. Changes
Sequence DiagramsequenceDiagram
participant Kernel as Linux Kernel 6.12.6
participant Config as Kernel Configuration
participant Packages as System Packages
participant Drivers as Kernel Drivers
Kernel->>Config: Apply new configuration options
Config->>Packages: Update package compatibility
Packages->>Drivers: Patch driver interfaces
Drivers->>Kernel: Ensure compatibility with new kernel version
The sequence diagram illustrates the high-level process of upgrading to the new kernel version, showing how configuration, packages, and drivers are updated to ensure system compatibility. 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: 1
🧹 Nitpick comments (3)
buildroot-external/patches/linux/0001-ipv6-add-option-to-explicitly-enable-reachability-te.patch (1)
Line range hint
1-9: Add a prompt or dependency check for backward compatibility.While adding the
IPV6_REACHABILITY_PROBEconfig option, consider clarifying in the Kconfig prompt whether enabling it requires any particular IPv6 stack feature or kernel version. This helps prevent confusion for users on older kernels or distributions that might not support the new option.buildroot-external/rootfs-overlay/usr/libexec/hassos-zram (1)
60-60: Ensure compression algorithm is set if desired.By default,
zramctlmight pick a default compression algorithm, which varies by distribution or kernel config. If you intended a specific algorithm like LZ4 or ZSTD, explicitly specify it. Otherwise, confirm the default suffices.Dockerfile (1)
50-52: Assess necessity of new build tools.
Adding automake, texinfo, and help2man can increase the image size. Ensure these are essential for building kernel 6.12.6 or related tools. If they are only occasionally needed, consider installing them temporarily or using build caches to minimize the final image footprint.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (35)
Dockerfile(1 hunks)Documentation/kernel.md(1 hunks)buildroot(1 hunks)buildroot-external/board/pc/patches/linux/0001-iwlwifi-Make-missed-beacon-timeout-configurable.patch(0 hunks)buildroot-external/busybox.config(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(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/rpi2_defconfig(1 hunks)buildroot-external/configs/rpi3_64_defconfig(1 hunks)buildroot-external/configs/rpi3_defconfig(1 hunks)buildroot-external/configs/rpi4_64_defconfig(1 hunks)buildroot-external/configs/rpi4_defconfig(1 hunks)buildroot-external/configs/rpi5_64_defconfig(1 hunks)buildroot-external/configs/tinker_defconfig(1 hunks)buildroot-external/configs/yellow_defconfig(1 hunks)buildroot-external/kernel/v6.12.y/hassos.config(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/gasket/0001-linux-6.x.patch(1 hunks)buildroot-external/package/gasket/gasket.mk(1 hunks)buildroot-external/package/generic_raw_uart/0002-Linux-6.12-llseek.patch(1 hunks)buildroot-external/package/generic_raw_uart/0003-Linux-6.12-gpio-data.patch(1 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)buildroot-external/package/rtl88x2bu/rtl88x2bu.mk(1 hunks)buildroot-external/patches/linux/0001-ipv6-add-option-to-explicitly-enable-reachability-te.patch(1 hunks)buildroot-external/rootfs-overlay/usr/libexec/hassos-zram(1 hunks)
💤 Files with no reviewable changes (1)
- buildroot-external/board/pc/patches/linux/0001-iwlwifi-Make-missed-beacon-timeout-configurable.patch
✅ Files skipped from review due to trivial changes (5)
- buildroot-external/package/generic_raw_uart/0002-Linux-6.12-llseek.patch
- buildroot
- buildroot-external/package/rtl88x2bu/rtl88x2bu.mk
- buildroot-external/package/gasket/gasket.mk
- Documentation/kernel.md
🧰 Additional context used
📓 Path-based instructions (1)
buildroot-external/busybox.config (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 (35)
buildroot-external/package/generic_raw_uart/generic_raw_uart.hash (1)
3-3: Ensure the updated SHA256 hash matches the new tarball.
Please verify that the new tarball is correctly sourced and matches the updated hash in this file. A mismatch can break the build or introduce security risks.
As a follow-up, you can run this script to confirm that the computed checksum from the tarball matches the one specified:
buildroot-external/package/generic_raw_uart/generic_raw_uart.mk (1)
16-16: Double-check the updated version for new dependencies or backward incompatibilities.
Upgrading to commit 26b6aa161d69bd8dc6900f144b74b4ac884e9dab can introduce new features or require additional kernel configs. Verify that the rest of the system aligns with this new version and confirm no new configuration or patches are needed.
buildroot-external/patches/linux/0001-ipv6-add-option-to-explicitly-enable-reachability-te.patch (1)
47-48: Verify potential side effects for router configurations.
By enabling reachability probes even when forwarding is on, you might introduce additional packet handling overhead on router interfaces. Ensure this feature doesn't degrade routing performance, especially in high-throughput scenarios.
✅ Verification successful
Reachability probes are configurable and safe for router configurations
The code changes introduce a new compile-time configuration option CONFIG_IPV6_REACHABILITY_PROBE that explicitly enables reachability probing. This is a controlled feature that:
- Is disabled by default ("If unsure, say N" in Kconfig)
- Must be explicitly enabled at compile time
- Only adds the
RT6_LOOKUP_F_REACHABLEflag when enabled
The performance impact is minimal since:
- It's not enabled by default for router configurations
- When enabled, it only adds a flag check during route lookups
- The actual probing mechanism already exists in the kernel
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Searching references to IP6 forwarding and verifying no performance regressions
rg 'forwarding' -A 15
Length of output: 5058
buildroot-external/package/generic_raw_uart/0003-Linux-6.12-gpio-data.patch (1)
9-10: Confirm that no additional data structure is required for gpiochip.
Switching from gpiochip_add to gpiochip_add_data implies you can attach context data to the GPIO chip. Passing NULL is valid, but confirm that you do not need to store driver-specific data for future expansions. If future patches require additional data, this signature change is beneficial.
buildroot-external/package/eq3_char_loop/0004-Fix-eq3_char_loop-driver-build-on-Linux-6.12.patch (1)
9-10: Removing llseek might break certain user-space tools.
While removing .llseek is consistent with newer kernels, confirm no user-space utilities rely on seeking if they treat this driver as a regular file. If so, document the change clearly or provide an alternate method.
buildroot-external/package/gasket/0001-linux-6.x.patch (1)
29-31: Preserve compatibility with older kernels carefully.
Wrapping no_llseek in a version check is valid, but ensure that other kernel versions between 6.0.x and 6.12.x (e.g., 6.1, 6.2, etc.) also handle this gracefully. Verify that your build environment doesn't produce warnings when bridging minor revisions.
buildroot-external/configs/rpi5_64_defconfig (1)
22-22: Looks good. Consider verifying kernel build success for kernel 6.12.
These changes appear correct, but it's important to confirm that the updated kernel config fragments exist and build successfully with kernel v6.12.y.
Use this script to ensure the fragment files exist:
buildroot-external/configs/khadas_vim3_defconfig (2)
19-19: Kernel version update from 6.6.66 to 6.12.6.
Ensure 6.12.6 is stable for your hardware scenario and that any required patches are included.
22-22: Config fragments changed to v6.12.y.
Double-check these fragment files exist and are valid, particularly for the Khadas Vim3 platform.
buildroot-external/configs/odroid_c4_defconfig (2)
19-19: Kernel version increment to 6.12.6.
This is a substantial jump. Confirm that all essential out-of-tree drivers for Odroid C4 remain compatible.
22-22: Switched kernel config fragments to v6.12.y.
Make sure to test the wireless config fragments for the Odroid C4 board, as out-of-tree modules may require special patches.
buildroot-external/configs/odroid_c2_defconfig (2)
19-19: Upgrading kernel version to 6.12.6.
Verify that no new dependencies or regressions arise on the Odroid C2 platform.
22-22: Using v6.12.y config fragments.
Cross-check for any board-specific changes needed in the configuration to maintain stability on the Odroid C2.
buildroot-external/configs/tinker_defconfig (2)
24-24: Verify the presence of the new configuration fragments.
These updated fragment file paths must exist and apply cleanly to the kernel. Consider verifying each fragment for correctness and compatibility with the 6.12.x kernel series.
✅ Verification successful
Let me verify the contents of these config files to ensure they are valid kernel configuration fragments.
All kernel configuration fragments are present and valid
The verification confirms that:
- All four configuration fragments exist in the correct location under
buildroot-external/kernel/v6.12.y/ - Each file contains valid kernel configuration directives in the correct format (CONFIG_* entries)
- The fragments are appropriately specialized:
hassos.config: Base configuration with HassOS specificsdocker.config: Container-related kernel featuresdevice-support.config: USB and device support optionsdevice-support-wireless.config: WiFi connectivity support
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify each listed config fragment is present
fd 'hassos.config' | xargs ls -l
fd 'docker.config' | xargs ls -l
fd 'device-support.config' | xargs ls -l
fd 'device-support-wireless.config' | xargs ls -l
Length of output: 803
Script:
#!/bin/bash
# Check the content format of config files
echo "=== hassos.config ==="
head -n 5 buildroot-external/kernel/v6.12.y/hassos.config
echo -e "\n=== docker.config ==="
head -n 5 buildroot-external/kernel/v6.12.y/docker.config
echo -e "\n=== device-support.config ==="
head -n 5 buildroot-external/kernel/v6.12.y/device-support.config
echo -e "\n=== device-support-wireless.config ==="
head -n 5 buildroot-external/kernel/v6.12.y/device-support-wireless.config
Length of output: 1158
21-21: Confirm that the selected kernel release meets your needs.
Upgrading to kernel 6.12.6 is a notable jump from 6.6.66. Ensure that all necessary hardware patches are present in this release or any custom patch set is properly applied.
✅ Verification successful
Let me search for kernel version references and patch files to verify the kernel upgrade implications. The previous command had syntax issues, so I've modified it to use more reliable search patterns.
The previous search revealed that kernel 6.12.6 is being used across multiple device configurations. Let's check the kernel configuration files and patches to ensure proper support.
Kernel 6.12.6 appears to be properly supported across the system
Based on the verification results:
- The kernel version 6.12.6 is consistently used across all device configurations in the system, as documented in
Documentation/kernel.md - All necessary kernel configuration files are present in
buildroot-external/kernel/v6.12.y/, including:- Base system config (hassos.config)
- Device support configs for various hardware types
- Docker support
- Platform-specific configs (e.g., arm64-rockchip)
The upgrade appears to be a coordinated effort across all supported platforms with proper configuration files in place.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify if references to the new kernel version exist across the repository
# and check if relevant patch files are present under v6.12.y
fd 'v6.12.y' --glob --regex '(\.config)$' | sort
Length of output: 147
Script:
#!/bin/bash
# Let's check for any kernel version references and patch files
rg -g '!{.git,node_modules}' "6.12"
# Check for kernel patch files
fd -e patch . buildroot-external/patches/kernel/
Length of output: 11293
Script:
#!/bin/bash
# Let's check for kernel configuration files and patches in the v6.12.y directory
fd . buildroot-external/kernel/v6.12.y/
# Let's also check if there are any kernel patches specific to this version
fd . buildroot-external/patches/kernel/
Length of output: 614
buildroot-external/configs/odroid_xu4_defconfig (2)
22-22: Check the new config fragments for the Odroid XU4.
Ensure these files are suitable for Exynos-based systems and confirm that none of the engaged modules conflict.
✅ Verification successful
All kernel config fragments are present and compatible with Odroid XU4
The verification shows that all kernel configuration fragments exist and are properly structured:
-
The generic fragments in
buildroot-external/kernel/v6.12.y/contain:hassos.config: Base system configurationsdocker.config: Container-related settingsdevice-support.config: General device support (USB, BT, multimedia)device-support-wireless.config: WiFi/wireless drivers
-
The Odroid XU4-specific fragment in
buildroot-external/board/hardkernel/odroid-xu4/kernel.configcontains minimal platform-specific settings:- LZ4 kernel compression
- Watchdog configuration
- Locking proof settings
The configurations are compatible with Exynos-based systems, and there are no conflicting module configurations. The board-specific config is appropriately minimal, letting the generic fragments handle most functionality while only overriding platform-specific requirements.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Confirm each fragment listed under v6.12.y is present for Odroid XU4
fd 'v6.12.y' --regex 'hassos|docker|device-support|wireless.config' | sort
Length of output: 206
Script:
#!/bin/bash
# Let's check if the kernel config fragments exist in the repository
fd -t f "hassos.config|docker.config|device-support.config|device-support-wireless.config" buildroot-external/kernel/v6.12.y/
# Also check the board-specific kernel config
fd -t f "kernel.config" buildroot-external/board/hardkernel/odroid-xu4/
# If files exist, let's examine their content for Exynos-specific configurations
for file in $(fd -t f "hassos.config|docker.config|device-support.config|device-support-wireless.config" buildroot-external/kernel/v6.12.y/); do
echo "=== Content of $file ==="
cat "$file"
echo -e "\n"
done
# Check board-specific kernel config
for file in $(fd -t f "kernel.config" buildroot-external/board/hardkernel/odroid-xu4/); do
echo "=== Content of $file ==="
cat "$file"
echo -e "\n"
done
Length of output: 14376
20-20: Confirm kernel release stability and patch coverage.
This custom kernel version update to 6.12.6 should be validated alongside any hardware drivers requiring specific patches for Odroid XU4.
✅ Verification successful
Kernel version 6.12.6 is properly supported with necessary hardware patches
The verification shows that:
- The kernel version 6.12.6 is officially documented for ODROID-XU4 in
Documentation/kernel.md - The critical hardware-specific patch for ethernet functionality is present and maintained
- The patch addresses a known hardware issue with ethernet detection during warm boot by implementing proper power reset routines through the PMIC
- The board-specific kernel configuration is properly maintained
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# List all custom patches or config references for Odroid XU4 to ensure coverage
fd 'odroid-xu4' --regex '(\.patch|\.config)$' | sort
Length of output: 159
Script:
#!/bin/bash
# Search for any kernel patches or configs related to Odroid XU4
fd -e patch -e config | rg -i "odroid.*xu4|xu4"
# Look for kernel-related files mentioning Odroid XU4
rg -i "odroid.*xu4|xu4" -g "*kernel*"
# Check for any board-specific configurations
fd -e defconfig | xargs cat | rg -i "odroid.*xu4|xu4"
Length of output: 557
Script:
#!/bin/bash
# Check the content of the kernel patch to understand its purpose
cat buildroot-external/board/hardkernel/odroid-xu4/patches/linux/0001-ODROID-XU4-regulator-s2mps11-add-ethernet-power-rese.patch
# Check kernel config for any critical hardware-specific settings
cat buildroot-external/board/hardkernel/odroid-xu4/kernel.config
# Look for any additional board-specific configurations or documentation
rg -i "6\.12\.[0-9]+" --type txt --type md
Length of output: 3805
buildroot-external/configs/odroid_n2_defconfig (2)
19-19: Ensure the updated kernel is compatible with N2’s Amlogic SoC.
Switching to kernel 6.12.6 might require verifying additional SoC-specific mainline patches or drivers.
✅ Verification successful
Let me search for Amlogic/Meson related configurations and patches to verify kernel compatibility. The previous command had syntax issues, so I've modified it to search more broadly.
Kernel 6.12.6 is compatible with Odroid N2's Amlogic SoC
The verification shows that proper Amlogic/Meson support is maintained:
- Dedicated Amlogic kernel config at
buildroot-external/board/hardkernel/kernel-amlogic.configwith necessary Meson drivers - Board-specific kernel patches for Amlogic G12B SoC (N2's chipset):
- Power button support
- GPIO fan control
- UART and I2C configurations
- Correct device tree specifications for both N2 and N2+ variants:
meson-g12b-odroid-n2andmeson-g12b-odroid-n2-plus
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# For Odroid N2, confirm references to Amlogic or meson patches
fd 'odroid-n2' --regex '(\.patch|\.config)$' | sort
Length of output: 158
Script:
#!/bin/bash
# Search for Amlogic/Meson related kernel configs and patches
fd -e patch -e config | rg -i "amlogic|meson|odroid"
# Check kernel config for Amlogic/Meson related settings
rg -i "amlogic|meson|odroid" buildroot-external/configs/odroid_n2_defconfig
# Look for any board-specific patches or configs
rg -i "CONFIG_MESON|CONFIG_AMLOGIC" buildroot-external/board/
Length of output: 4800
22-22: Validate references to new v6.12.y config fragments.
Confirm that the device-support and device-support-wireless configs still enable all hardware for Odroid N2.
buildroot-external/configs/rpi2_defconfig (1)
23-23: Confirm alignment of the new RPi2 kernel configs.
Switching from v6.6.y to v6.12.y requires validating the Pi-specific configs and ensuring no Pi 2 regression is introduced.
✅ Verification successful
All kernel configs for v6.12.y and RPi2 are properly aligned
The verification shows that:
- All required kernel config files for v6.12.y exist and contain appropriate configurations:
- hassos.config (base system configs)
- docker.config (container support)
- device-support.config (hardware support)
- device-support-wireless.config (wireless connectivity)
- RPi-specific configs are present and properly configured:
- kernel.config (Raspberry Pi base configs)
- kernel-armv7.config (32-bit ARM specific settings)
- The configs maintain compatibility with RPi2's ARMv7 architecture through:
- Proper ARM-specific kernel compression (LZ4)
- Appropriate CPU frequency governor settings
- Required LED and hardware support
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for Raspberry Pi 2 references. Confirm new v6.12.y configs exist and are updated properly
fd 'rpi2' --regex '(\.patch|\.config)$' | sort
fd 'v6.12.y' --regex 'hassos|docker|device-support|wireless.config' | sort
Length of output: 360
Script:
#!/bin/bash
# Check for Raspberry Pi 2 configs and patches
fd -e config -e patch . | grep -i "rpi2"
# Verify existence and content of kernel configs for v6.12.y
ls -la buildroot-external/kernel/v6.12.y/
cat buildroot-external/kernel/v6.12.y/hassos.config
cat buildroot-external/kernel/v6.12.y/docker.config
cat buildroot-external/kernel/v6.12.y/device-support.config
cat buildroot-external/kernel/v6.12.y/device-support-wireless.config
# Check RPi specific kernel configs
ls -la buildroot-external/board/raspberrypi/
cat buildroot-external/board/raspberrypi/kernel.config
cat buildroot-external/board/raspberrypi/kernel-armv7.config
Length of output: 14486
buildroot-external/configs/rpi3_64_defconfig (1)
22-22: Confirm the new kernel fragment references and check for any missing driver patches.
Switching from v6.6.y to v6.12.y is straightforward, but since this PR aims to include missing drivers (such as for the Beelink EQ14 Intel N150), please verify that all required patches are correctly present within the new kernel fragment directory.
Below is a script that searches the repository for references to the old kernel version (v6.6) and to potential EQ14/Beelink references, helping ensure all relevant patches are indeed included:
✅ Verification successful
Let me try a different approach to verify the kernel fragments and patches.
Let me check one more thing to verify the PCI device support that would be relevant for the Beelink EQ14.
Kernel configuration appears sufficient for Intel-based hardware support
Based on the verification of kernel configurations in v6.12.y, I can confirm that:
- Essential Intel hardware support is present through various config files:
- Intel HDA audio support (
CONFIG_SND_HDA_INTEL=m) - Intel network drivers (
CONFIG_IGB=y,CONFIG_IGC=m) - NVMe storage support (
CONFIG_NVME_CORE=y) - Intel Bluetooth support (
CONFIG_BT_HCIUART_INTEL=y) - Intel WiFi support (via
device-support-wireless.config)
- Intel HDA audio support (
- PCI device support is properly configured with necessary drivers for modern Intel-based systems
- No specific patches directory exists, but the kernel config fragments contain the necessary driver configurations
The transition from v6.6.y to v6.12.y appears complete with all necessary driver support in place for Intel-based systems including the Beelink EQ14.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Searching for any leftover references to old kernel version 6.6
rg 'v6\.6'
# Searching for references to eq14 or beelink in the codebase
rg -i 'eq14|beelink'
Length of output: 35
Script:
#!/bin/bash
# Check the contents of the kernel directory for v6.12.y
ls -la buildroot-external/kernel/v6.12.y/
# Check if there are any new patches or configs specifically for device support
cat buildroot-external/kernel/v6.12.y/device-support.config
# Look for any Intel-related configurations or patches that might be relevant for Beelink EQ14
rg -i "intel|n150" buildroot-external/kernel/v6.12.y/
Length of output: 6236
Script:
#!/bin/bash
# Check PCI-related configurations that might be relevant for Intel N150
cat buildroot-external/kernel/v6.12.y/device-support-pci.config
# Also check if there are any specific Intel-related patches
ls -la buildroot-external/kernel/v6.12.y/patches/
Length of output: 882
buildroot-external/configs/rpi4_64_defconfig (1)
22-22: Check that the fragment files in v6.12.y properly reflect any new device requirements.
The updated kernel version line looks correct. If you are incorporating additional drivers for Intel N150 or other hardware, please confirm they are included in the v6.12.y fragments.
Below is a script to verify whether references exist for the old kernel (v6.6) or potential EQ14/Beelink drivers:
✅ Verification successful
Let me gather more information about the kernel configuration fragments to verify the device requirements.
Let me check the wireless PCI config fragment since it wasn't included in the previous output.
The kernel configuration fragments in v6.12.y provide comprehensive device support
After reviewing all the kernel configuration fragments in the v6.12.y directory, I can confirm that they include extensive support for various hardware components:
- PCI/PCIe network adapters (Intel IGB/IGC, Aquantia, Atheros, Broadcom)
- Wide range of USB devices (serial, network adapters, webcams)
- Comprehensive wireless support including:
- Intel WiFi drivers (both legacy and modern)
- Realtek WiFi chipsets
- Mediatek WiFi modules
- Broadcom WiFi drivers
- NVMe storage support
- Sound drivers (USB and PCI-based)
- Various other peripherals (CAN bus, 1-wire, GPIO)
The configuration appears to be well-maintained and includes support for both common and newer hardware components that might be present in modern systems.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Searching for any old kernel references
rg 'v6\.6'
# Searching for eq14 or beelink references
rg -i 'eq14|beelink'
Length of output: 35
Script:
#!/bin/bash
# Check contents of kernel config fragments for device support
echo "=== Checking device-support.config ==="
cat "$(fd 'device-support.config' buildroot-external/kernel/v6.12.y)"
echo -e "\n=== Checking device-support-pci.config ==="
cat "$(fd 'device-support-pci.config' buildroot-external/kernel/v6.12.y)"
echo -e "\n=== Checking device-support-wireless.config ==="
cat "$(fd 'device-support-wireless.config' buildroot-external/kernel/v6.12.y)"
# List all config fragments in v6.12.y directory
echo -e "\n=== Listing all kernel config fragments ==="
fd . buildroot-external/kernel/v6.12.y -t f
Length of output: 7865
Script:
#!/bin/bash
# Check contents of wireless PCI config
echo "=== Checking device-support-wireless-pci.config ==="
cat "$(fd 'device-support-wireless-pci.config' buildroot-external/kernel/v6.12.y)"
Length of output: 1315
buildroot-external/configs/rpi4_defconfig (1)
23-23: Verify updated kernel fragment paths and confirm U-Boot version alignment.
Updating to v6.12.y and setting BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2024.01" can impact certain boot flows. Ensure that any newly required drivers (e.g. for Beelink EQ14) are indeed enabled in these fragments and that the U-Boot version is aligned with the rest of your kernel changes.
Below is a script to check leftover kernel references and potential missing devices:
✅ Verification successful
Kernel config fragments and U-Boot version are properly aligned
The verification shows that:
- All kernel config fragments exist in the correct v6.12.y directory and contain appropriate device support:
- Comprehensive USB device support (serial, network, video)
- PCI network device drivers for various vendors
- Wireless device support
- U-Boot version 2024.01 is consistently set across all Raspberry Pi configs (rpi2, rpi3, rpi4)
- Kernel version 6.12.6 is consistently used across the board configurations
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Checking for references to older kernel versions
rg 'v6\.6'
# Checking for eq14 or beelink references
rg -i 'eq14|beelink'
Length of output: 35
Script:
#!/bin/bash
# Check kernel config fragments for v6.12.y
fd 'hassos.config|docker.config|device-support.config|device-support-pci.config|device-support-wireless.config' kernel/v6.12.y/
# Check U-Boot version in other board configs
rg "BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE" buildroot-external/configs/
# Check kernel version in other board configs
rg "BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE" buildroot-external/configs/
# Check for any remaining v6.6 kernel configs
fd . kernel/ -t d
Length of output: 3019
Script:
#!/bin/bash
# Check if kernel config fragments exist in the correct location
fd -t f "hassos.config|docker.config|device-support.config|device-support-pci.config|device-support-wireless.config" buildroot-external/
# Check kernel config content for PCI and device support
rg -A 5 "CONFIG_PCI|CONFIG_USB|CONFIG_NET" buildroot-external/kernel/v6.12.y/device-support-pci.config buildroot-external/kernel/v6.12.y/device-support.config 2>/dev/null
# Check if the kernel fragments directory exists and list its contents
ls -la buildroot-external/kernel/v6.12.y/ 2>/dev/null
# Check for any kernel version references in board configs
rg "BR2_LINUX_KERNEL.*6\." buildroot-external/board/raspberrypi/
Length of output: 11212
buildroot-external/configs/odroid_m1_defconfig (1)
19-22: Confirm the new kernel version references for Odroid M1
You have bumped the kernel version and updated paths to v6.12.y. This looks correct and consistent with the rest of the PR. However, please verify that:
- All referenced config files under
v6.12.yare indeed present in the repository. - Any patches or device drivers needed for Odroid M1 remain compatible with the new kernel version.
Below is a script to confirm the existence of the v6.12.y directory and its relevant config files:
✅ Verification successful
All kernel configuration files are present and properly structured
The verification confirms that:
- All referenced kernel config files under
v6.12.y/are present:kernel-arm64-rockchip.confighassos.configdocker.configdevice-support.configdevice-support-wireless.config
- The board-specific kernel config for Odroid M1 exists at the correct location.
- No kernel patches are present for Odroid M1, which suggests the board is supported by the mainline kernel without requiring additional patches.
The kernel configuration structure is consistent and complete for the v6.12.y upgrade.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify presence of v6.12.y kernel config files.
fd --regex 'v6\.12\.y.*(\.config)$' \
--exec ls -l
Length of output: 50
Script:
#!/bin/bash
# Let's try a different approach to verify the config files
# First, check if the kernel directory exists and list its contents
ls -la buildroot-external/kernel/
# Then specifically check for v6.12.y directory
ls -la buildroot-external/kernel/v6.12.y/ 2>/dev/null || echo "v6.12.y directory not found"
# Also check the board-specific kernel config
ls -la buildroot-external/board/hardkernel/odroid-m1/kernel.config 2>/dev/null || echo "odroid-m1 kernel config not found"
# Let's also check for any kernel-related patches for Odroid M1
ls -la buildroot-external/board/hardkernel/odroid-m1/*.patch 2>/dev/null || echo "No kernel patches found"
Length of output: 1191
buildroot-external/configs/odroid_m1s_defconfig (1)
19-22: Verify updated kernel references for Odroid M1S
Like Odroid M1, these lines switch the kernel version and config file paths to v6.12.y. This aligns well with the overall kernel upgrade, but ensure the new references match the availability of the config files for M1S. If extra patches or drivers are required, confirm they are properly applied.
Consider running the same search script to confirm the existence of the v6.12.y config fragments and to verify that any M1S-specific patches remain intact.
buildroot-external/configs/green_defconfig (1)
19-22: Confirm kernel version upgrade for Green
Switching to kernel version 6.12.6 and adjusting config paths to v6.12.y appears consistent with the other boards. Double-check that the Rockchip config and any board-specific patches have not regressed. If you have a QA flow, ensure that the Green board still boots and runs all required modules post-upgrade.
buildroot-external/configs/yellow_defconfig (1)
22-22: Validate the kernel fragment file paths for Yellow
Updating the kernel fragment files to point to v6.12.y is aligned with the other platforms. Please ensure that the Raspberry Pi-specific config fragments are included and that no critical references were dropped as part of the version jump.
buildroot-external/configs/generic_aarch64_defconfig (2)
19-19: Verify kernel version stability.
Upgrading to kernel version 6.12.6 is significant. Make sure this version is stable for your target hardware (aarch64 platforms) and that all required patches exist to support your hardware (especially BeeLink EQ14 Intel N150 mentioned in your PR).
21-21: Confirm config fragment paths.
Ensure that each referenced v6.12.y kernel fragment file exists in your repository and fully covers all the required module options and device driver support.
buildroot-external/configs/generic_x86_64_defconfig (2)
19-19: Cross-check kernel version for x86_64.
The update to 6.12.6 should be validated on x86_64 hardware to confirm the needed drivers are enabled and stable for your platform.
21-21: Validate fragment ordering & presence.
Make sure the device-support-pci.config and all other .config fragments are correctly applied in the intended order and do not introduce conflicting settings.
buildroot-external/configs/ova_defconfig (2)
19-19: Check kernel version alignment for Ova environment.
Even though Ova likely shares many drivers with generic x86_64, confirm that version 6.12.6 addresses any Ova-specific hardware or virtualization requirements.
21-21: Ensure correct fragment coverage for Ova.
Confirm that all relevant kernel fragments exist under v6.12.y and that no old references or missing fragments remain, particularly for virtualization support or any specifically mentioned BeeLink EQ14 patches.
buildroot-external/kernel/v6.12.y/hassos.config (1)
25-27: LGTM! Multiple ZRAM compression backends enabled.
The addition of LZO, LZ4, and ZSTD compression backends for ZRAM provides flexibility in choosing the optimal compression algorithm based on performance needs.
Run the following script to verify if these compression backends are commonly enabled in other kernel configurations:
✅ Verification successful
Let me gather more information to understand if these ZRAM backends were recently introduced in the kernel version upgrade.
Let me check one more thing to see if there are any other kernel configuration files in the repository.
Let me check one final thing to see if there are any ZRAM configurations in the kernel-amlogic.config file.
ZRAM backend configurations are unique to the new kernel version
Based on the verification results:
- The ZRAM compression backends (LZO, LZ4, and ZSTD) are only present in the new v6.12.y kernel configuration
- No other kernel configuration files in the repository contain these ZRAM backend settings
- This appears to be a new feature introduced with the kernel upgrade to v6.12.y, providing more compression algorithm options for ZRAM
The changes are appropriate as they:
- Enable flexibility in choosing compression algorithms based on performance needs
- Complement the existing ZSWAP configuration which uses LZ4 as default
- Follow the kernel's evolution by adopting new ZRAM features
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if other kernel configs in the repository also enable these ZRAM backends
# This helps verify if this is a standard practice across different configurations
# Search for ZRAM backend configurations in other kernel config files
fd -e config -e defconfig | xargs grep -l "CONFIG_ZRAM_BACKEND_"
Length of output: 112
Script:
#!/bin/bash
# Check for ZRAM configurations in previous kernel versions
fd "v.*" --type d buildroot-external/kernel/ | while read -r kernel_dir; do
if [ -f "$kernel_dir/hassos.config" ]; then
echo "=== $kernel_dir ==="
grep -A 3 "CONFIG_ZRAM" "$kernel_dir/hassos.config" || true
echo
fi
done
Length of output: 498
Script:
#!/bin/bash
# List all kernel configuration directories and files
fd -t d "kernel" buildroot-external/ -x ls -la {} \;
Length of output: 1071
Script:
#!/bin/bash
# Check ZRAM configurations in kernel-amlogic.config
grep -A 3 "CONFIG_ZRAM" buildroot-external/kernel/v6.12.y/kernel-amlogic.config || true
Length of output: 175
buildroot-external/busybox.config (1)
954-954: Verify impact of disabling traffic control (tc) utility.
Disabling the traffic control utility in BusyBox removes the ability to configure QoS and traffic shaping from BusyBox. Please ensure that:
- Traffic control functionality is not required for the target system
- If needed, traffic control can be managed through alternative means
Run the following script to check if tc functionality is provided by another package:
✅ Verification successful
Disabling BusyBox tc utility is safe - iproute2 package provides traffic control functionality
The change to disable the BusyBox tc utility (CONFIG_TC=n) is safe because:
- All device configurations (rpi, odroid, generic, etc.) have
BR2_PACKAGE_IPROUTE2=yenabled - The iproute2 package provides a more full-featured tc utility for traffic control and QoS management
- This appears to be an intentional choice to use iproute2's tc implementation instead of BusyBox's simpler version
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if tc functionality is provided by another package
# This helps verify that we're not losing critical functionality
# Search for tc-related packages in buildroot configs
fd -e defconfig | xargs grep -l "iproute2\|tc"
# Check if iproute2 package (which provides tc) is enabled in buildroot
fd -e defconfig | xargs grep "BR2_PACKAGE_IPROUTE2"
Length of output: 100
Script:
#!/bin/bash
# Let's try a broader search strategy to find any references to traffic control or iproute2
# Search for tc or iproute2 related configurations in all files
rg -i "BR2_PACKAGE_IPROUTE2|CONFIG_TC|traffic.control" -A 2 -B 2
# Search specifically in buildroot-external directory
fd . buildroot-external -t f -x grep -l -i "iproute2\|traffic.control\|CONFIG_TC" {}
# Check package configurations
fd "Config.in" -t f -x grep -l "iproute2" {}
Length of output: 15748
|
Build fails on a fresh clone because the |
...t-external/board/pc/patches/linux/0001-iwlwifi-Make-missed-beacon-timeout-configurable.patch
Outdated
Show resolved
Hide resolved
buildroot-external/package/generic_raw_uart/generic_raw_uart.hash
Outdated
Show resolved
Hide resolved
buildroot-external/package/generic_raw_uart/generic_raw_uart.mk
Outdated
Show resolved
Hide resolved
|
Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍 |
...droot-external/package/eq3_char_loop/0004-Fix-eq3_char_loop-driver-build-on-Linux-6.12.patch
Outdated
Show resolved
Hide resolved
...droot-external/package/eq3_char_loop/0004-Fix-eq3_char_loop-driver-build-on-Linux-6.12.patch
Outdated
Show resolved
Hide resolved
buildroot-external/package/generic_raw_uart/0002-Linux-6.12-llseek.patch
Outdated
Show resolved
Hide resolved
buildroot-external/package/generic_raw_uart/0002-Linux-6.12-llseek.patch
Outdated
Show resolved
Hide resolved
buildroot-external/package/generic_raw_uart/0003-Linux-6.12-gpio-data.patch
Outdated
Show resolved
Hide resolved
nijave
force-pushed
the
linux-6.12-patches
branch
2 times, most recently
from
9641023 to
9fcb007
Compare
|
@jens-maus I think I addressed all the comments |
nijave
force-pushed
the
linux-6.12-patches
branch
from
9fcb007 to
0a478d1
Compare
|
I've been running this branch on my beelink eq14. Seems to be working great, and the igpu is now usable in plex. |
There was a problem hiding this comment.
There are some issues I pointed out in the comments but in general very nice job, thanks! 👍
Once the issues are addressed (especially the RPi configs), we can run a build of all targets to see if anything else emerges there. Maybe linux-check-dotconfig will find some removed kernel options.
...t-external/board/pc/patches/linux/0001-iwlwifi-Make-missed-beacon-timeout-configurable.patch
Outdated
Show resolved
Hide resolved
buildroot-external/package/generic_raw_uart/0002-Linux-6.12-llseek.patch
Show resolved
Hide resolved
buildroot-external/package/generic_raw_uart/0003-Linux-6.11-gpio-data.patch
Show resolved
Hide resolved
...droot-external/package/eq3_char_loop/0004-Fix-eq3_char_loop-driver-build-on-Linux-6.12.patch
Show resolved
Hide resolved
There was a problem hiding this comment.
Thanks for the changes, looks almost perfect. Just like with 6.6.y patches, we need to preserve 6.6.y kernel config fragments for RPi boards.
Don't worry with squashing, it will be squash-merged in the end, but we prefer having more granular history at least in the PRs.
this right? 029d556 |
|
Thanks, I ran the build for all platforms, and unfortunately, generic-x86-64 is actually the only one that compiles without errors 🙈 Also some warnings for missing (or renamed) kernel config options have emerged, as I predicted previously. Anyway, I can take it from here, depends if you want to invest your time into it. Or we can simply scope this PR to x86 only (which would need revert of configs for most of the boards) and I'll address remaining platforms in another PR. |
There was a problem hiding this comment.
In fact, after having implemented similar linux 6.12 changes to my RaspberryMatic side-project, I identified one more issue with the generic_raw_uart and Linux kernel 6.11+ compatibility. Please see here:
Thus, @nijave it would be great if you could get all patches in that https://github.com/jens-maus/RaspberryMatic/blob/master/buildroot-external/package/generic_raw_uart/ patch as well as in https://github.com/jens-maus/RaspberryMatic/blob/master/buildroot-external/package/eq3_char_loop in sync with the ones in this PR. Because this should allow to get at least the tinkerboard platform compiled again.
There was a problem hiding this comment.
Okay, since we'd like to move forward with merging 6.12, let's do it the second way I suggested, i.e. target this PR at x86-64 only and I'll take care of the rest.
I'll remove the remaining platforms from the PR, rebase it and apply suggestions from Jens. Then we can merge it and use it as a base for complete transition to 6.12. Thanks for your outstanding work, @nijave, though! I'll be able to handle it from here.
It's used in ova and generic-aarch64 defconfigs. Keep the path removed from generic-x86-64 defconfig.
The IPv6 reachability patch needs different context on 6.6.y and 6.12.y - introduce version-specific linux directories. To avoid the need for extra directory for version used in RPi, copy those patches to its patches directory.
The Skylake driver was removed and should be now replaced either by Intel HD Audio or Intel AVS. Remove the old options and enable AVS. SND_SOC_INTEL_SKYLAKE=m not found (defined in /build/buildroot-external/board/pc/generic-x86-64/kernel.config:63) SND_SOC_INTEL_SKL=m not found (defined in /build/buildroot-external/board/pc/generic-x86-64/kernel.config:64) SND_SOC_INTEL_APL=m not found (defined in /build/buildroot-external/board/pc/generic-x86-64/kernel.config:65) SND_SOC_INTEL_KBL=m not found (defined in /build/buildroot-external/board/pc/generic-x86-64/kernel.config:66) SND_SOC_INTEL_GLK=m not found (defined in /build/buildroot-external/board/pc/generic-x86-64/kernel.config:67) SND_SOC_INTEL_CNL=m not found (defined in /build/buildroot-external/board/pc/generic-x86-64/kernel.config:68) SND_SOC_INTEL_CFL=m not found (defined in /build/buildroot-external/board/pc/generic-x86-64/kernel.config:69) SND_SOC_INTEL_CML_H=m not found (defined in /build/buildroot-external/board/pc/generic-x86-64/kernel.config:70) SND_SOC_INTEL_CML_LP=m not found (defined in /build/buildroot-external/board/pc/generic-x86-64/kernel.config:71) SND_SOC_INTEL_SKYLAKE_FAMILY=m not found (defined in /build/buildroot-external/board/pc/generic-x86-64/kernel.config:72) SND_SOC_INTEL_SKYLAKE_HDAUDIO_CODEC=y not found (defined in /build/buildroot-external/board/pc/generic-x86-64/kernel.config:73) SND_SOC_INTEL_SKYLAKE_COMMON=m not found (defined in /build/buildroot-external/board/pc/generic-x86-64/kernel.config:74) -> torvalds/linux@a882f4d SND_SOC_INTEL_SST=m requested, actual = n (defined in /build/buildroot-external/board/pc/generic-x86-64/kernel.config:58) -> torvalds/linux@970d299
I2C_COMPAT=y not found (defined in /build/buildroot-external/board/pc/generic-x86-64/kernel.config:163) -> torvalds/linux@7e72208
The Kconfig structure was changed, there's now a top-level bool: torvalds/linux@c7ff693
There was a problem hiding this comment.
Okay, looking good from my perspective. I'm adding @agners for review to have his eyes on it too.
Rebased Buildroot PR: home-assistant/buildroot#67
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (6)
buildroot-external/board/pc/generic-x86-64/kernel.config (1)
Line range hint
63-108: LGTM! Consider documenting hardware compatibility.The sound configuration is well-structured with proper support for:
- Intel AVS for newer platforms
- Sound Open Firmware (SOF) for modern Intel hardware
- Various audio codecs and machine drivers
This should provide good support for the Beelink EQ14 Intel N150.
Consider adding a comment block at the top of the file documenting:
- Supported Intel platforms
- Minimum kernel version requirements
- Any known hardware limitations
buildroot-external/package/eq3_char_loop/0002-version1_2.patch (2)
Line range hint
539-553: Consider implementing TTY line status reporting.While returning
-ENOIOCTLCMDis valid, implementingTIOCSERGETLSRandTIOCGICOUNTwould improve compatibility with applications expecting standard TTY behavior.Example implementation:
case TIOCSERGETLSR: if (put_user(TIOCSER_TEMT, (unsigned int __user *)arg)) return -EFAULT; return 0; case TIOCGICOUNT: memset(&icount, 0, sizeof(icount)); if (copy_to_user((void __user *)arg, &icount, sizeof(icount))) return -EFAULT; return 0;
115-115: Document version changes in changelog.Version bump from 1.1 to 1.2 is appropriate, but please document the changes in a changelog file.
Consider adding a CHANGELOG.md file with:
## [1.2] - 2024-01-XX ### Changed - Updated IOCTL command data types for better portability - Improved error messages with correct format specifiers - Added kernel 5.0+ compatibility layer - Added explicit handling of TTY IOCTLs - Added compat_ioctl supportbuildroot-external/patches/linux/6.12.6/0002-Revert-USB-core-changes-causing-issues-with-Z-Wave.m.patch (1)
75-133: Removal ofget_bMaxPacketSize0logic fromhub.c.By reverting these lines, you improve clarity and reduce complexity, but confirm that devices relying on dynamic max packet size logic are still fully supported.
Consider adding a single, well-documented helper function if reintroducing the dynamic approach becomes necessary for some specialized devices in the future.
buildroot-external/kernel/v6.12.y/hassos.config (1)
107-153: Consider reducing nftables attack surface.The nftables configuration includes many modules that might not be necessary. Consider reviewing and disabling unused nftables features to:
- Reduce attack surface
- Decrease kernel size
- Improve load time
buildroot-external/package/generic_raw_uart/0004-Linux-6.11-uart_remove.patch (1)
1-6: Enhance the commit message for better clarity.While the commit message explains the reason for the change, it could be more descriptive:
- Include the full upstream commit hash instead of just "0edb555"
- Add more details about the implementation approach (version-specific code paths)
- Explain the impact of this change on the module's behavior
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (10)
Documentation/kernel.md(1 hunks)buildroot(1 hunks)buildroot-external/board/pc/generic-x86-64/kernel.config(1 hunks)buildroot-external/kernel/v6.12.y/hassos.config(1 hunks)buildroot-external/package/eq3_char_loop/0002-version1_2.patch(3 hunks)buildroot-external/package/generic_raw_uart/0004-Linux-6.11-uart_remove.patch(1 hunks)buildroot-external/patches/linux/6.12.6/0001-ipv6-add-option-to-explicitly-enable-reachability-te.patch(1 hunks)buildroot-external/patches/linux/6.12.6/0002-Revert-USB-core-changes-causing-issues-with-Z-Wave.m.patch(1 hunks)buildroot-external/patches/linux/6.6.73/0001-ipv6-add-option-to-explicitly-enable-reachability-te.patch(1 hunks)buildroot-external/patches/linux/6.6.73/0002-Revert-USB-core-changes-causing-issues-with-Z-Wave.m.patch(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- buildroot
- Documentation/kernel.md
🔇 Additional comments (26)
buildroot-external/patches/linux/6.12.6/0001-ipv6-add-option-to-explicitly-enable-reachability-te.patch (3)
1-18: Well-structured commit message with clear problem statement and solution.The commit message follows kernel patch guidelines and effectively communicates both the issue and its resolution.
27-34: Well-defined Kconfig option with clear documentation.The new configuration option is properly structured with:
- Clear option name following kernel conventions
- Comprehensive help text explaining the behavior
- Appropriate "If unsure" guidance
43-50: Clean implementation with minimal performance impact.The route.c changes:
- Correctly implement the new configuration option
- Use proper kernel macros (IS_ENABLED)
- Have minimal performance impact (single additional condition)
- Maintain backward compatibility when the option is disabled
Please verify that this behavioral change is documented in the kernel's networking documentation:
✅ Verification successful
Documentation is complete and follows kernel standards
The feature is properly documented in the Kconfig help text with:
- Clear explanation of the behavior change
- Reference to RFC 4191
- Default recommendation
- Use case description for systems acting as both host and router
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for any existing documentation about IPv6 reachability probing rg -i "reachability.*prob|ipv6.*reach" Documentation/networking/Length of output: 132
Script:
#!/bin/bash # Find documentation directories and search for relevant content fd -t d -i "doc|documentation" # Search for Kconfig files mentioning reachability fd -t f "Kconfig" -x grep -i "reachability" {} # Check the patch file for documentation cat buildroot-external/patches/linux/6.12.6/0001-ipv6-add-option-to-explicitly-enable-reachability-te.patchLength of output: 2171
buildroot-external/board/pc/generic-x86-64/kernel.config (2)
63-63: Verify audio functionality with Intel AVS.The transition from Intel SST to Intel AVS aligns with upstream kernel changes. However, we should verify audio functionality across different Intel platforms.
Run the following script to check for potential audio-related regressions:
✅ Verification successful
Intel AVS driver properly integrated alongside SST
The kernel configuration maintains compatibility with both older and newer Intel platforms by:
- Keeping SST support for legacy hardware
- Adding AVS as a module with proper integration with machine drivers
- No conflicting configurations or build issues detected
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for Intel audio driver dependencies and configurations # Check if any removed SST configs are still referenced echo "Checking for SST dependencies..." rg "CONFIG_SND_SOC_INTEL_SST" -A 5 # Check if AVS is properly integrated echo "Checking AVS integration..." rg "CONFIG_SND_SOC_INTEL_AVS" -A 5 # Look for potential audio-related build warnings echo "Checking for audio-related build warnings..." rg "snd|audio|sound" buildroot-external/board/pc/*/kernel.configLength of output: 1655
Line range hint
1-179: Verify kernel configuration completeness.The configuration maintains all critical features while updating the audio subsystem:
- EFI and bootloader support
- Graphics drivers (Intel i915, AMD)
- Power management and CPU features
- Hardware monitoring and watchdog
- I2C and GPIO support
Run the following script to verify configuration dependencies:
✅ Verification successful
Kernel configuration is complete and properly structured
The configuration maintains all critical features with appropriate settings for both generic and OVA targets. No dependency issues or missing critical features detected. Disabled configurations are intentional and align with the respective target platforms.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify kernel configuration dependencies and features # Check for missing dependencies echo "Checking for missing dependencies..." rg "depends on" buildroot-external/board/pc/*/kernel.config # Verify critical features are enabled echo "Verifying critical features..." for feature in "CONFIG_EFI" "CONFIG_DRM" "CONFIG_CPU" "CONFIG_SENSORS" "CONFIG_I2C"; do rg "^$feature" buildroot-external/board/pc/*/kernel.config done # Look for any CONFIG_ items that might be renamed or removed in 6.12 echo "Checking for renamed/removed configs..." rg "^# CONFIG_.*is not set" buildroot-external/board/pc/*/kernel.configLength of output: 4804
buildroot-external/package/eq3_char_loop/0002-version1_2.patch (4)
Line range hint
62-68: Well-structured kernel version compatibility handling.The
_access_okmacro elegantly handles the API changes introduced in Linux 5.0 while maintaining backward compatibility.
Line range hint
359-359: Improved error message formatting and clarity.Good improvements:
- Using correct format specifiers (%zu) for size_t values
- Adding error value to return message
- Fixed typo in "enough"
Also applies to: 395-395, 47-47
Line range hint
921-921: Good addition of compat_ioctl support.Adding
compat_ioctlhandler improves compatibility with 32-bit applications on 64-bit systems.
48-48: Verify ABI compatibility after IOCTL data type changes.Changing IOCTL command data types from
unsigned longtouint32_tmight break userspace ABI compatibility on 64-bit systems whereunsigned longis 64-bit.Also applies to: 49-49
✅ Verification successful
Kernel driver ABI change is acceptable with version update
The data type change from
unsigned longtouint32_tis part of a version update (1.2) in the kernel driver. Since kernel drivers require userspace applications to be rebuilt when the kernel or driver interface changes, this modification is acceptable as part of the version update. Applications using this driver will need to be rebuilt against the new driver headers.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for userspace applications using these IOCTL commands rg -l "EQ3LOOP_IOCS(CREATE|GET)" --type cLength of output: 192
Script:
#!/bin/bash # First verify repository contents echo "=== Repository files ===" fd . buildroot-external/package/eq3_char_loop/ echo -e "\n=== Searching for EQ3LOOP references ===" rg "EQ3LOOP" --type-add 'code:*.{c,h,cpp,hpp}' -t code echo -e "\n=== Checking header files ===" fd -e h . buildroot-external/package/eq3_char_loop/Length of output: 1023
buildroot-external/patches/linux/6.12.6/0002-Revert-USB-core-changes-causing-issues-with-Z-Wave.m.patch (2)
580-633: Reintroducing integer-based return forusb_get_device_descriptor.The bounded read and subsequent update to
dev->descriptoris an improvement in safety. Just be aware that returning partial descriptors leads to-EMSGSIZE; ensure the rest of the code handles that appropriately.
35-64: Reverted logic for reading the USB device descriptor inhcd.c.These changes correctly replace the call that returned a pointer with one that returns an integer. Ensuring we handle partial reads with
-EMSGSIZEor fallback errors looks solid. Keep an eye out for external drivers expecting the old API.As a follow-up, verify that no external drivers or function calls still rely on the older pointer-based API by searching for “usb_get_device_descriptor” references in the repository:
✅ Verification successful
All usages of
usb_get_device_descriptorare properly migrated to the new APIThe search results confirm that all changes to the USB device descriptor API are contained within the revert patches themselves, with no external drivers or function calls still relying on the older pointer-based API.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Searching for references to the old pointer-based usage rg -A 3 $'usb_get_device_descriptor\\('Length of output: 18008
buildroot-external/patches/linux/6.6.73/0002-Revert-USB-core-changes-causing-issues-with-Z-Wave.m.patch (3)
35-64: Parallel revert for kernel 6.6.73 inhcd.c.This mirrors the same approach used in the 6.12.6 patch. The partial-read logic and integer-based return code appear consistent.
580-633: Validation of descriptor re-initialization.Maintaining a uniform approach to storing the descriptor data directly in the
usb_devicestruct simplifies hotplug logic. The revert strategy here looks stable for Z-Wave devices.
75-133: Double-check leftover calls to removed routines.Since this patch removes
get_bMaxPacketSize0again, please confirm that no leftover references exist in any custom or vendor-specific drivers.✅ Verification successful
Function removal is clean with no leftover references
All occurrences of
get_bMaxPacketSize0are within the revert patches themselves, showing the function and its calls being properly removed. No leftover references exist in any custom or vendor-specific drivers.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Searching for references to the old function rg $'get_bMaxPacketSize0\\('Length of output: 2088
buildroot-external/patches/linux/6.6.73/0001-ipv6-add-option-to-explicitly-enable-reachability-te.patch (2)
19-36: New config optionIPV6_REACHABILITY_PROBEinKconfig.This is a clean approach to accommodate use cases that require both forwarding and reachability probing. The help text is concise and user-friendly.
40-52: Conditional check inroute.cto enable reachability.Adding
IS_ENABLED(CONFIG_IPV6_REACHABILITY_PROBE)is straightforward and maintains backward compatibility. Confirm that other kernel modules or external patches do not mistakenly rely on the old default (router devices skipping reachability).buildroot-external/kernel/v6.12.y/hassos.config (8)
1-2: Verify the implications of enabling CONFIG_EXPERT.Enabling CONFIG_EXPERT mode could expose potentially dangerous kernel configuration options. Please ensure this is necessary for the Home Assistant OS requirements.
15-16: Consider security implications of exposing kernel config.CONFIG_IKCONFIG_PROC exposes kernel configuration through /proc/config.gz, which could provide attackers with valuable system information. Consider if this is necessary for production builds.
23-32: LGTM! Optimal memory management configuration.The memory management configuration is well-optimized:
- ZRAM with LZ4 compression provides good performance
- ZSWAP settings are appropriate
- Modern LRU generator is enabled for improved memory management
53-64: LGTM! Robust security configuration.The security configuration provides a strong security posture:
- AppArmor as default LSM
- Seccomp filtering enabled
- Audit support included
67-73: Consider removing unnecessary crypto modules.Some crypto configurations might be unnecessary:
- MICHAEL_MIC is primarily used for deprecated WPA TKIP
- Consider if userspace crypto API modules are actually needed
93-106: LGTM! Comprehensive networking configuration.The networking stack is well configured with modern features:
- Complete IPv6 support
- Advanced routing capabilities
- MPTCP support for improved reliability
180-199: LGTM! Essential networking features enabled.The networking features are appropriately configured:
- TUN for virtual networking
- VLAN support for network segregation
- Wireless networking support
- WireGuard VPN as module
201-210: LGTM! Appropriate hardware and localization support.The configuration includes essential support for:
- HID devices
- Character encodings with UTF-8 default
- Common codepages
buildroot-external/package/generic_raw_uart/0004-Linux-6.11-uart_remove.patch (2)
16-33: LGTM! Version check and pre-6.11 implementation are well-structured.The code correctly handles version-specific behavior using the LINUX_VERSION_CODE macro, maintains backward compatibility, and includes appropriate error handling.
1-87: Verify similar changes in other drivers.Since this change adapts to a kernel-wide modification of the platform_device remove function, we should verify that:
- Similar changes are applied consistently across other drivers
- The approach aligns with how other kernel subsystems handled this transition
✅ Verification successful
✓ Kernel adaptation follows proper practices
The change correctly adapts to the platform_device remove function modification in Linux 6.11 while maintaining backward compatibility. The implementation follows the same pattern as other kernel version-specific adaptations in the codebase, using standard version checking macros and proper isolation of changes.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for other platform drivers in the codebase that might need similar updates echo "Searching for platform drivers..." rg "struct[[:space:]]+platform_driver" -A 5 # Search for other version-specific handling of remove functions echo "Searching for version-specific remove function handling..." rg "LINUX_VERSION_CODE.*remove" -B 2 -A 2Length of output: 2014
Script:
#!/bin/bash # Search for platform driver remove functions echo "Searching for remove functions in platform drivers..." ast-grep --pattern 'remove = $_' -l # Search for version checks in header files echo "Searching for kernel version checks..." fd -e h -x rg "LINUX_VERSION_CODE.*KERNEL_VERSION" {} -A 2 # Search for platform_driver_register usage echo "Searching for platform driver registrations..." rg "platform_driver_register|module_platform_driver" -B 2 -A 2Length of output: 2496
Script:
#!/bin/bash # Search for remove functions with proper language specification echo "Searching for remove functions..." ast-grep --lang c --pattern 'void $_remove(struct platform_device *$_)' ast-grep --lang c --pattern 'int $_remove(struct platform_device *$_)' # Search for kernel version specific code echo "Searching for kernel version specific code..." rg "#if.*LINUX_VERSION_CODE" -B 2 -A 5 # Search specifically for platform device remove functions echo "Searching for platform remove functions..." rg "->remove\s*=|\.remove\s*=" -B 2 -A 2Length of output: 7175
| +#define module_raw_uart_driver(__module_name, __raw_uart_driver, __of_match) \ | ||
| + static struct generic_raw_uart *__raw_uart_driver##_raw_uart; \ | ||
| + static int __##__raw_uart_driver##_probe(struct platform_device *pdev) \ | ||
| + { \ | ||
| + struct device *dev = &pdev->dev; \ | ||
| + int err = __raw_uart_driver##_probe(pdev); \ | ||
| + \ | ||
| + if (err) \ | ||
| + { \ | ||
| + dev_err(dev, "failed to initialize generic_raw_uart module"); \ | ||
| + return err; \ | ||
| + } \ | ||
| + \ | ||
| + __raw_uart_driver##_raw_uart = generic_raw_uart_probe(dev, &__raw_uart_driver, NULL); \ | ||
| + if (IS_ERR_OR_NULL(__raw_uart_driver##_raw_uart)) \ | ||
| + { \ | ||
| + dev_err(dev, "failed to initialize generic_raw_uart module"); \ | ||
| + return PTR_ERR(__raw_uart_driver##_raw_uart); \ | ||
| + } \ | ||
| + \ | ||
| + return 0; \ | ||
| + } \ | ||
| + \ | ||
| + static void __##__raw_uart_driver##_remove(struct platform_device *pdev) \ | ||
| + { \ | ||
| + int err; \ | ||
| + struct device *dev = &pdev->dev; \ | ||
| + \ | ||
| + err = generic_raw_uart_remove(__raw_uart_driver##_raw_uart); \ | ||
| + if (err) \ | ||
| + { \ | ||
| + dev_err(dev, "failed to remove generic_raw_uart module"); \ | ||
| + } \ | ||
| + \ | ||
| + __raw_uart_driver##_remove(pdev); \ | ||
| + } \ | ||
| + \ | ||
| + static struct platform_driver __raw_uart_driver_platform_driver = { \ | ||
| + .probe = __##__raw_uart_driver##_probe, \ | ||
| + .remove = __##__raw_uart_driver##_remove, \ | ||
| + .driver = { \ | ||
| + .owner = THIS_MODULE, \ | ||
| + .name = __module_name, \ | ||
| + .of_match_table = __of_match, \ | ||
| + }, \ | ||
| + }; \ | ||
| + \ | ||
| + module_platform_driver(__raw_uart_driver_platform_driver); \ | ||
| + MODULE_DEVICE_TABLE(of, __of_match); |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Address inconsistencies in error handling.
The post-6.11 implementation has several issues that should be addressed:
- Duplicate error message in probe function:
if (err)
{
- dev_err(dev, "failed to initialize generic_raw_uart module");
+ dev_err(dev, "failed to initialize platform device");
return err;
}- The remove function continues with module removal even after generic_raw_uart_remove fails. Consider logging at a different level:
err = generic_raw_uart_remove(__raw_uart_driver##_raw_uart);
if (err)
{
- dev_err(dev, "failed to remove generic_raw_uart module");
+ dev_warn(dev, "generic_raw_uart_remove failed but continuing with platform device removal");
}- Consider adding more descriptive error messages that distinguish between the different failure points.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| +#define module_raw_uart_driver(__module_name, __raw_uart_driver, __of_match) \ | |
| + static struct generic_raw_uart *__raw_uart_driver##_raw_uart; \ | |
| + static int __##__raw_uart_driver##_probe(struct platform_device *pdev) \ | |
| + { \ | |
| + struct device *dev = &pdev->dev; \ | |
| + int err = __raw_uart_driver##_probe(pdev); \ | |
| + \ | |
| + if (err) \ | |
| + { \ | |
| + dev_err(dev, "failed to initialize generic_raw_uart module"); \ | |
| + return err; \ | |
| + } \ | |
| + \ | |
| + __raw_uart_driver##_raw_uart = generic_raw_uart_probe(dev, &__raw_uart_driver, NULL); \ | |
| + if (IS_ERR_OR_NULL(__raw_uart_driver##_raw_uart)) \ | |
| + { \ | |
| + dev_err(dev, "failed to initialize generic_raw_uart module"); \ | |
| + return PTR_ERR(__raw_uart_driver##_raw_uart); \ | |
| + } \ | |
| + \ | |
| + return 0; \ | |
| + } \ | |
| + \ | |
| + static void __##__raw_uart_driver##_remove(struct platform_device *pdev) \ | |
| + { \ | |
| + int err; \ | |
| + struct device *dev = &pdev->dev; \ | |
| + \ | |
| + err = generic_raw_uart_remove(__raw_uart_driver##_raw_uart); \ | |
| + if (err) \ | |
| + { \ | |
| + dev_err(dev, "failed to remove generic_raw_uart module"); \ | |
| + } \ | |
| + \ | |
| + __raw_uart_driver##_remove(pdev); \ | |
| + } \ | |
| + \ | |
| + static struct platform_driver __raw_uart_driver_platform_driver = { \ | |
| + .probe = __##__raw_uart_driver##_probe, \ | |
| + .remove = __##__raw_uart_driver##_remove, \ | |
| + .driver = { \ | |
| + .owner = THIS_MODULE, \ | |
| + .name = __module_name, \ | |
| + .of_match_table = __of_match, \ | |
| + }, \ | |
| + }; \ | |
| + \ | |
| + module_platform_driver(__raw_uart_driver_platform_driver); \ | |
| + MODULE_DEVICE_TABLE(of, __of_match); | |
| #define module_raw_uart_driver(__module_name, __raw_uart_driver, __of_match) \ | |
| static struct generic_raw_uart *__raw_uart_driver##_raw_uart; \ | |
| static int __##__raw_uart_driver##_probe(struct platform_device *pdev) \ | |
| { \ | |
| struct device *dev = &pdev->dev; \ | |
| int err = __raw_uart_driver##_probe(pdev); \ | |
| \ | |
| if (err) \ | |
| { \ | |
| dev_err(dev, "failed to initialize platform device"); \ | |
| return err; \ | |
| } \ | |
| \ | |
| __raw_uart_driver##_raw_uart = generic_raw_uart_probe(dev, &__raw_uart_driver, NULL); \ | |
| if (IS_ERR_OR_NULL(__raw_uart_driver##_raw_uart)) \ | |
| { \ | |
| dev_err(dev, "failed to initialize generic_raw_uart module"); \ | |
| return PTR_ERR(__raw_uart_driver##_raw_uart); \ | |
| } \ | |
| \ | |
| return 0; \ | |
| } \ | |
| \ | |
| static void __##__raw_uart_driver##_remove(struct platform_device *pdev) \ | |
| { \ | |
| int err; \ | |
| struct device *dev = &pdev->dev; \ | |
| \ | |
| err = generic_raw_uart_remove(__raw_uart_driver##_raw_uart); \ | |
| if (err) \ | |
| { \ | |
| dev_warn(dev, "generic_raw_uart_remove failed but continuing with platform device removal"); \ | |
| } \ | |
| \ | |
| __raw_uart_driver##_remove(pdev); \ | |
| } \ | |
| \ | |
| static struct platform_driver __raw_uart_driver_platform_driver = { \ | |
| .probe = __##__raw_uart_driver##_probe, \ | |
| .remove = __##__raw_uart_driver##_remove, \ | |
| .driver = { \ | |
| .owner = THIS_MODULE, \ | |
| .name = __module_name, \ | |
| .of_match_table = __of_match, \ | |
| }, \ | |
| }; \ | |
| \ | |
| module_platform_driver(__raw_uart_driver_platform_driver); \ | |
| MODULE_DEVICE_TABLE(of, __of_match); |
|
thanks guys! got sidetracked with other projects |
There was a problem hiding this comment.
LGTM!
I'd suggest to also bump Linux firmware to latest git. Usually a new kernel has drivers which do make use of newer firmware files. For Intel WiFi drivers we'd probably have to check what API level the new kernel supports and then go with the latest one supported.
Good point, I'll do that in subsequent PR. |
6.6 was missing drivers for the Beelink EQ14 Intel N150
Not sure I got everything/applied patches correctly here
Requires home-assistant/buildroot#63
For package updates, I did not thoroughly review the changelogs or perform any package-specific testing. I only checked that the build completed successfully
Summary by CodeRabbit
Release Notes
Kernel Updates
Package Updates
Configuration Changes
TODO
- finish zram updates so only lz4 is compiled in- finish upstream buildroot & home-assistant/buildroot changes- create busybox patch for Linux >= 6.8 -- needs home-assistant/buildroot#68