meson64: require the PCIe port services on boards that have PCIe - #10739
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (5)
Included review availability: Your plan provides up to 8 included reviews per hour; 5 remain after this review. 📝 WalkthroughWalkthroughThe change enables PCIe port bus support and Advanced Error Reporting in four Meson64 kernel configurations. It also adds a shared board configuration function that enables both options for boards with PCIe device-tree support. ChangesMeson64 PCIe support
Priority: ➖ Normal Estimated code review effort: 1 (Trivial) | ~5 minutes Change: Bug fix Merge Risk: ⚪ Minimal · up to The PCIe options are validly applied and no unresolved production or configuration risk was identified. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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 |
|
✅ This PR has been reviewed and approved — all set for merge! |
EvilOlaf
left a comment
There was a problem hiding this comment.
just a blocker. as per comment
ee925a1 to
01c6974
Compare
Five meson64 boards enable PCIe in their device tree: ODROID-HC4 (root port -> ASM1061 -> two SATA ports, all of the board's storage), Khadas VIM3 and VIM3L (M.2), Banana Pi M2S and CM4IO. Yet the family has built every branch with CONFIG_PCIEPORTBUS off, so on all of them the root port has no driver at all: nothing puts it into D3hot on the way to suspend, and AER goes unserviced even though the port advertises the capability. The option was not dropped on purpose. It was still =y (together with PCIEAER) until ddccaaf in 2018, a wholesale rewrite of the meson64 kernel config titled 'Odroid C2 and Meson64 NEXT configuration cleanup', where it fell out among 2686 changed lines. At that time meson64 meant C2 and Le Potato, SoCs without any PCIe, so nothing was lost. ODROID-HC4, the first meson64 board with a real PCIe, arrived in 2020 and the family kernel config was never revisited. So this turns the option on in both places. The family kernel configs get PCIEPORTBUS=y and PCIEAER=y, which is what actually builds today. The hook in meson64_common.inc is insurance against those files being rewritten wholesale again, as happens now and then: an option that only a few boards depend on is easy to lose in such a diff, and the hook puts it back on the next build. At family level it applies to every meson64 board, so the kernel package stays one for the whole family. Verified on ODROID-HC4: the root port now reports 'pcieport 0000:00:00.0: PME: Signaling with IRQ 24' and 'AER: enabled with IRQ 24', and hot-plugging SATA drives keeps working. The other four boards are not on hand; the change is the same option and the same reason, and it only takes effect where the device tree enables the controller. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
01c6974 to
6c373d8
Compare
|
ah, alright. |
Five meson64 boards enable PCIe in their device tree: ODROID-HC4 (root
port -> ASM1061 -> two SATA ports, all of the board's storage), Khadas
VIM3 and VIM3L (M.2), Banana Pi M2S and CM4IO. Yet the family has built
every branch with
CONFIG_PCIEPORTBUSoff, so on all of them the root porthas no driver at all: nothing puts it into D3hot on the way to suspend,
and AER goes unserviced even though the port advertises the capability.
The option was not dropped on purpose. It was still
=y(together withPCIEAER) untilddccaaf02in 2018, a wholesale rewrite of the meson64kernel config titled "Odroid C2 and Meson64 NEXT configuration cleanup",
where it fell out among 2686 changed lines. At that time meson64 meant C2
and Le Potato, SoCs without any PCIe, so nothing was lost. ODROID-HC4, the
first meson64 board with a real PCIe, arrived in 2020 and the family kernel
config was never revisited.
So this turns the option on in both places. The family kernel configs get
PCIEPORTBUS=yandPCIEAER=y, which is what actually builds today. Thehook in
meson64_common.incis insurance against those files beingrewritten wholesale again, as happens now and then: an option that only a
few boards depend on is easy to lose in such a diff, and the hook puts it
back on the next build. At family level it applies to every meson64 board,
so the kernel package stays one for the whole family.
Verified on ODROID-HC4: the root port now reports
pcieport 0000:00:00.0: PME: Signaling with IRQ 24andAER: enabled with IRQ 24, and hot-plugging SATA drives keeps working.The other four boards are not on hand; the change is the same option and
the same reason, and it only takes effect where the device tree enables the
controller.
Two caveats, measured on HC4 rather than assumed. The root port still stays
in D0 across suspend: ahci keeps the ASM1061 at
control=on, so the genericdw_pcie_suspend_noirqpath never triggers. And when the link does drop, noAER event arrives — the port has AER enabled on IRQ 24, but the controller
reports nothing, so there is no
pcie_do_recoveryto hope for on this SoC.What this change buys is the driver itself, PME signalling and a correctly
configured port; it is a prerequisite for that work, not the fix.
Related work
This one is independent of the suspend series and can be merged on its own.
For context, the rest of it: #10738 (GPIO interrupts as wakeup
sources), #10740 (PCIe suspend/resume, draft) and
#10741 (Wake-on-LAN on HC4).
Summary by CodeRabbit