mainline: bump edge to 7.0-rc6#9618
Merged
EvilOlaf merged 5 commits intoarmbian:mainfrom Mar 30, 2026
Merged
Conversation
EvilOlaf
requested review from
AGM1968,
ColorfulRhino,
HeyMeco,
JohnTheCoolingFan,
PanderMusubi,
SuperKali,
TheSnowfield,
Tonymac32,
ahoneybun,
amazingfate,
brentr,
catalinii,
chainsx,
chraac,
efectn,
igorpecovnik,
janprunk,
joekhoobyar,
krachlatte,
lanefu,
pyavitz,
rpardini,
schwar3kat,
sgjava and
teknoid
as code owners
Contributor
📝 WalkthroughWalkthroughThis PR updates mainline kernel targeting from rc5 to rc6 and introduces multiple architecture-specific kernel patches for Rockchip (RK3399/RK3528/RK3588), Allwinner, and x86 platforms, adding support for PCIe error handling, audio codecs, USB PHY, I2S clocking, DMA device management, IOMMU, and HID SPI devices. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
github-actions
bot
added
size/medium
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
patch/kernel/archive/rockchip64-7.0/HACK-Ignore-SError-to-enable-rk3399-PCIe-bus-enumera.patch (2)
22-38:⚠️ Potential issue | 🔴 CriticalScope the SError bypass to the actual enumeration window.
Line 24 turns this into a boot-wide mode switch, and Lines 32-37 then return before the normal fatal/non-RAS handling path. That means any later, unrelated SError on any CPU gets silently swallowed, not just the RK3399 enumeration fault. Please gate this around the narrow probe/scan window instead of leaving
do_serror()in permanent "ignore everything" mode.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@patch/kernel/archive/rockchip64-7.0/HACK-Ignore-SError-to-enable-rk3399-PCIe-bus-enumera.patch` around lines 22 - 38, The current boot parameter and global rk3399_pcie_ignore_serror_enabled make do_serror() ignore all SErrors system-wide; instead restrict the bypass to the short RK3399 PCIe enumeration window by replacing the permanent flag with a scoped probe-mode gate: add clearly named enable/disable functions (e.g. rk3399_pcie_serror_probe_enter() and rk3399_pcie_serror_probe_exit()) and call enable just before the RK3399 PCIe probe/scan and call disable immediately after; update setup_rk3399_pcie_serror_handling to only enable probe-mode if the param is present (or register the param to toggle the initial state), and modify do_serror() to check the probe-mode gate (rk3399_pcie_serror_probe_active) so only SErrors occurring during the enumeration window are swallowed.
83-101:⚠️ Potential issue | 🟠 MajorRestore the caller's affinity after pinning probe to CPU4.
Line 88 pins the current task to CPU4 via
set_cpus_allowed_ptr(), but nothing restores the original affinity before the function continues. The task remains pinned to CPU4 for the entire duration of the probe and beyond. If this runs in a deferred-probe or workqueue context, that restriction leaks into subsequent unrelated work. Save the original cpumask before line 88 and restore it after the sensitive section, or narrow the restriction to only the critical enumeration code.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@patch/kernel/archive/rockchip64-7.0/HACK-Ignore-SError-to-enable-rk3399-PCIe-bus-enumera.patch` around lines 83 - 101, Save the task's original CPU affinity before calling set_cpus_allowed_ptr(current, &mask) (e.g., copy the current allowed cpumask into a local variable), then after the critical PCIe enumeration/probing finishes restore the saved affinity by calling set_cpus_allowed_ptr(current, &original_mask); alternatively, restrict the pinning to just the critical section (around the enumeration code) rather than leaving the affinity changed for the rest of the function; reference the existing use of cpu_online(4), struct cpumask mask, and set_cpus_allowed_ptr(current, &mask) to locate where to save and restore the original cpumask.
🧹 Nitpick comments (3)
patch/kernel/archive/rockchip64-7.0/general-rk3588-i2s-mclk-output-gate-4-gate-grf-clocks.patch (1)
108-117: Consider logging a warning on failure for easier debugging.The SYS_GRF registration silently fails if
syscon_regmap_lookup_by_compatibleorkzallocfails. While this is a soft failure (the system boots, but the MCLK-to-IO clocks won't be available), adding apr_warnwould help identify issues on boards where audio doesn't work due to missing DT entries or memory pressure during early init.That said, this follows the typical Rockchip early init pattern and the patch is already in upstream review, so this is purely optional feedback.
🔧 Optional: add warning on failure
/* Register SYS_GRF for I2S MCLK output to IO gate clocks */ sys_grf = syscon_regmap_lookup_by_compatible("rockchip,rk3588-sys-grf"); - if (!IS_ERR(sys_grf)) { + if (IS_ERR(sys_grf)) { + pr_warn("%s: could not find SYS_GRF, I2S MCLK gates unavailable\n", __func__); + } else { sys_grf_e = kzalloc_obj(*sys_grf_e); if (sys_grf_e) { sys_grf_e->grf = sys_grf; sys_grf_e->type = grf_type_sys; hash_add(ctx->aux_grf_table, &sys_grf_e->node, grf_type_sys); + } else { + pr_warn("%s: failed to allocate SYS_GRF entry\n", __func__); } }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@patch/kernel/archive/rockchip64-7.0/general-rk3588-i2s-mclk-output-gate-4-gate-grf-clocks.patch` around lines 108 - 117, The SYS_GRF registration currently fails silently; add warnings when syscon_regmap_lookup_by_compatible("rockchip,rk3588-sys-grf") returns an error and when kzalloc_obj for sys_grf_e fails so failures are visible in dmesg; specifically, after calling syscon_regmap_lookup_by_compatible check IS_ERR(sys_grf) and pr_warn with PTR_ERR_OR_ZERO(sys_grf) or a descriptive message mentioning "sys_grf" and the compatible string, and inside the true branch if kzalloc_obj(*sys_grf_e) returns NULL emit a pr_warn mentioning allocation failure for sys_grf_e (including ctx or grf_type_sys context) before skipping the hash_add to ctx->aux_grf_table.patch/kernel/archive/rockchip64-7.0/net-stmmac-dwmac-motorcomm-fix-eFUSE-MAC-Address-Rea.patch (2)
53-65: Encapsulate the new eFuse settle requirement.
motorcomm_init()plus the 15-20ms sleep is now part of the contract for reading eFuse, but it is open-coded in probe. A small helper and named delay constants would make that sequencing harder to miss if another eFuse read path shows up later.♻️ Possible cleanup
- usleep_range(15000, 20000); + usleep_range(EFUSE_SETTLE_DELAY_MIN_US, EFUSE_SETTLE_DELAY_MAX_US);Add the
EFUSE_SETTLE_DELAY_*defines next to the other eFuse timing constants, or wrap the whole init+settle sequence in a dedicated helper.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@patch/kernel/archive/rockchip64-7.0/net-stmmac-dwmac-motorcomm-fix-eFUSE-MAC-Address-Rea.patch` around lines 53 - 65, The motorcomm_init() + usleep_range(15000, 20000) sequence should be encapsulated into a small helper and use named delay constants; create a helper (e.g., motorcomm_prepare_efuse() or motorcomm_efuse_init_sequence()) that calls motorcomm_init() and then usleep_range(EFUSE_SETTLE_DELAY_MIN, EFUSE_SETTLE_DELAY_MAX), and add EFUSE_SETTLE_DELAY_MIN and EFUSE_SETTLE_DELAY_MAX defines alongside the other eFuse timing constants; replace the inline motorcomm_init() + usleep_range(...) pair in the probe with a single call to the new helper to ensure the contract is clear and reusable.
43-45: Verify that the atomic poll helper is really needed here.This wait still happens on the probe path, and
readl_poll_timeout_atomic()usesudelay()between polls instead of the sleepable helper. Please verify there is a non-sleepable caller that actually needs that behavior; otherwise this can turn a slow or failing eFuse read into CPU spin during probe for no real gain. (codebrowser.dev)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@patch/kernel/archive/rockchip64-7.0/net-stmmac-dwmac-motorcomm-fix-eFUSE-MAC-Address-Rea.patch` around lines 43 - 45, The atomic iopoll call using readl_poll_timeout_atomic(priv->base + EFUSE_OP_CTRL_1, reg, reg & EFUSE_OP_DONE, 2, EFUSE_READ_TIMEOUT_US) is used on probe — verify whether this path can ever be in atomic context; if not, replace with the sleepable readl_poll_timeout variant (or a msleep/yield-backed loop) to avoid busy-waiting during slow/failed eFuse reads, otherwise add a comment justifying why atomic polling is required; identify the call site in the probe code and check surrounding callers/context to choose between readl_poll_timeout and readl_poll_timeout_atomic and update the call and comment accordingly.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@config/sources/mainline-kernel.conf.sh`:
- Around line 31-33: The alert text in the display_alert call (function
display_alert) incorrectly says "missing torvalds tag" while the code sets
KERNELSOURCE to Torvalds; update the message to state that the tag was missing
from the original source and that the script is falling back to Torvalds (e.g.,
"original repo missing tag; falling back to torvalds: Using
KERNELSOURCE='${KERNELSOURCE}' for KERNELBRANCH='${KERNELBRANCH}'") so the log
accurately reflects the fallback action; modify the display_alert invocation
that references KERNELSOURCE and KERNELBRANCH accordingly.
In
`@patch/kernel/archive/rockchip64-7.0/rk3528-14-arm64-dts-rockchip-nanopi-zero2-fix-ethernet-phy-reset.patch`:
- Around line 29-30: The device tree uses the plural property name
"snps,reset-gpios" which should be the singular "snps,reset-gpio"; update the
property name to "snps,reset-gpio" (keeping the value <&gpio4 RK_PC2
GPIO_ACTIVE_LOW> and the associated "snps,reset-delays-us = <0 20000 100000>;")
so the Ethernet controller binding recognizes the reset GPIO; locate and change
the property in the patch where "snps,reset-gpios" appears.
---
Outside diff comments:
In
`@patch/kernel/archive/rockchip64-7.0/HACK-Ignore-SError-to-enable-rk3399-PCIe-bus-enumera.patch`:
- Around line 22-38: The current boot parameter and global
rk3399_pcie_ignore_serror_enabled make do_serror() ignore all SErrors
system-wide; instead restrict the bypass to the short RK3399 PCIe enumeration
window by replacing the permanent flag with a scoped probe-mode gate: add
clearly named enable/disable functions (e.g. rk3399_pcie_serror_probe_enter()
and rk3399_pcie_serror_probe_exit()) and call enable just before the RK3399 PCIe
probe/scan and call disable immediately after; update
setup_rk3399_pcie_serror_handling to only enable probe-mode if the param is
present (or register the param to toggle the initial state), and modify
do_serror() to check the probe-mode gate (rk3399_pcie_serror_probe_active) so
only SErrors occurring during the enumeration window are swallowed.
- Around line 83-101: Save the task's original CPU affinity before calling
set_cpus_allowed_ptr(current, &mask) (e.g., copy the current allowed cpumask
into a local variable), then after the critical PCIe enumeration/probing
finishes restore the saved affinity by calling set_cpus_allowed_ptr(current,
&original_mask); alternatively, restrict the pinning to just the critical
section (around the enumeration code) rather than leaving the affinity changed
for the rest of the function; reference the existing use of cpu_online(4),
struct cpumask mask, and set_cpus_allowed_ptr(current, &mask) to locate where to
save and restore the original cpumask.
---
Nitpick comments:
In
`@patch/kernel/archive/rockchip64-7.0/general-rk3588-i2s-mclk-output-gate-4-gate-grf-clocks.patch`:
- Around line 108-117: The SYS_GRF registration currently fails silently; add
warnings when syscon_regmap_lookup_by_compatible("rockchip,rk3588-sys-grf")
returns an error and when kzalloc_obj for sys_grf_e fails so failures are
visible in dmesg; specifically, after calling syscon_regmap_lookup_by_compatible
check IS_ERR(sys_grf) and pr_warn with PTR_ERR_OR_ZERO(sys_grf) or a descriptive
message mentioning "sys_grf" and the compatible string, and inside the true
branch if kzalloc_obj(*sys_grf_e) returns NULL emit a pr_warn mentioning
allocation failure for sys_grf_e (including ctx or grf_type_sys context) before
skipping the hash_add to ctx->aux_grf_table.
In
`@patch/kernel/archive/rockchip64-7.0/net-stmmac-dwmac-motorcomm-fix-eFUSE-MAC-Address-Rea.patch`:
- Around line 53-65: The motorcomm_init() + usleep_range(15000, 20000) sequence
should be encapsulated into a small helper and use named delay constants; create
a helper (e.g., motorcomm_prepare_efuse() or motorcomm_efuse_init_sequence())
that calls motorcomm_init() and then usleep_range(EFUSE_SETTLE_DELAY_MIN,
EFUSE_SETTLE_DELAY_MAX), and add EFUSE_SETTLE_DELAY_MIN and
EFUSE_SETTLE_DELAY_MAX defines alongside the other eFuse timing constants;
replace the inline motorcomm_init() + usleep_range(...) pair in the probe with a
single call to the new helper to ensure the contract is clear and reusable.
- Around line 43-45: The atomic iopoll call using
readl_poll_timeout_atomic(priv->base + EFUSE_OP_CTRL_1, reg, reg &
EFUSE_OP_DONE, 2, EFUSE_READ_TIMEOUT_US) is used on probe — verify whether this
path can ever be in atomic context; if not, replace with the sleepable
readl_poll_timeout variant (or a msleep/yield-backed loop) to avoid busy-waiting
during slow/failed eFuse reads, otherwise add a comment justifying why atomic
polling is required; identify the call site in the probe code and check
surrounding callers/context to choose between readl_poll_timeout and
readl_poll_timeout_atomic and update the call and comment accordingly.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 642e7fbb-3475-41e2-85e3-833a65439dc5
📒 Files selected for processing (19)
config/sources/mainline-kernel.conf.shpatch/kernel/archive/rockchip64-7.0/HACK-Ignore-SError-to-enable-rk3399-PCIe-bus-enumera.patchpatch/kernel/archive/rockchip64-7.0/general-ASoC-codecs-es8328-allow-sharing-LRCK-for-microphone.patchpatch/kernel/archive/rockchip64-7.0/general-rk3588-i2s-mclk-output-gate-1-bindings.patchpatch/kernel/archive/rockchip64-7.0/general-rk3588-i2s-mclk-output-gate-2-allow-grf-type-sys.patchpatch/kernel/archive/rockchip64-7.0/general-rk3588-i2s-mclk-output-gate-3-grf-header.patchpatch/kernel/archive/rockchip64-7.0/general-rk3588-i2s-mclk-output-gate-4-gate-grf-clocks.patchpatch/kernel/archive/rockchip64-7.0/net-stmmac-dwmac-motorcomm-fix-eFUSE-MAC-Address-Rea.patchpatch/kernel/archive/rockchip64-7.0/rk3399-rp64-pcie-Reimplement-rockchip-PCIe-bus-scan-delay.patchpatch/kernel/archive/rockchip64-7.0/rk3528-10-phy-rockchip-inno-usb2-Add-support-for-RK3528.patchpatch/kernel/archive/rockchip64-7.0/rk3528-11-arm64-dts-rockchip-rk3528-Add-USB-controller-and-PHY-nodes.patchpatch/kernel/archive/rockchip64-7.0/rk3528-12-arm64-dts-rockchip-nanopi-zero2-Enable-USB.patchpatch/kernel/archive/rockchip64-7.0/rk3528-13-phy-rockchip-inno-usb2-fix-otg-timer-cleanup.patchpatch/kernel/archive/rockchip64-7.0/rk3528-14-arm64-dts-rockchip-nanopi-zero2-fix-ethernet-phy-reset.patchpatch/kernel/archive/sunxi-7.0/patches.armbian/drm-gem-dma-support-dedicated-dma-device-for-allocation-and-mapping.patchpatch/kernel/archive/sunxi-7.0/patches.armbian/drm-prime-limit-scatter-list-size-with-dedicated-dma-device.patchpatch/kernel/archive/sunxi-7.0/patches.armbian/drm-sun4i-use-backend-mixer-as-dedicated-dma-device.patchpatch/kernel/archive/sunxi-7.0/patches.armbian/drv-iommu-sunxi-add-iommu-driver.patchpatch/kernel/archive/uefi-x86-7.0/4001-asahi-trackpad.patch
...rchive/rockchip64-7.0/rk3528-14-arm64-dts-rockchip-nanopi-zero2-fix-ethernet-phy-reset.patch
Show resolved
Hide resolved
igorpecovnik
approved these changes
Mar 30, 2026
Contributor
|
✅ This PR has been reviewed and approved — all set for merge! |
rpardini
approved these changes
Mar 30, 2026
Member
That usually indicates the original mbox format is somehow invalid or not understood by the patching system. It could be too many line breaks, a rogue |
Member
Author
|
Go for it :) |
Member
Hmm. Your fix fixed it, somehow -- a rewrite now correctly only strips the |
Member
Author
|
I thought so myself because I did the very same earlier with faba3a4 and an immediate rewrite was successful. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
@rpardini I have issues with three patches (in sunxi) where
rewrite-kernel-patchespersistently removes the original header and replaces it with some archeology stuff. I already tried earlier to restore them with a dedicated commit (faba3a4) in hope that the mechanism would acknowledge but no dice. How to prevent that in future?How Has This Been Tested?
Checklist:
Summary by CodeRabbit
Release Notes
New Features
Bug Fixes
Refactor