arm64: dts: rockchip: youyeetoo-r1: fix PCIe reset gpio and drop spi0 stub - #530
Conversation
The board enables spi0 on the m3 pin group with a single rockchip,spi_test_bus0_cs1 child, which is the Rockchip EVB debug stub, and the R1 v3 has no SPI NOR fitted. The group muxes GPIO3_D1, and the schematic wires that pad as PCIE20x1_2_PERSTn_M0, the reset line of the mini-PCIe socket. When the PCIe driver claims the reset the pin controller warns with a backtrace and forces the mux back to GPIO, so spi0 is left without its MISO line and cannot work anyway. Drop the node. Signed-off-by: SuperKali <hello@superkali.me>
pcie2x1l1 drives the M.2 M-key socket, and its reset-gpios points at GPIO1_A7. The schematic routes PERST# from connector pin 50 through R211 to GPIO1_B0 on ball H39, while GPIO1_A7 on ball H38 goes to pin 13 of the 30-pin user header. The controller therefore toggles an unrelated header pin on every link training attempt and never drives reset on the card. Point reset-gpios at GPIO1_B0. Signed-off-by: SuperKali <hello@superkali.me>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 2 included reviews per hour; 1 remains after this review. WalkthroughThe RK3588S board device tree changes the Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This localized device-tree change corrects the PCIe reset pin and removes an unused SPI stub; no actionable merge-blocking risk remains after normal checks and review. 🚥 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 |
The Youyeetoo R1 v3 device tree points the M.2 reset line at the wrong pin and enables an spi0 node that only ever instantiated a Rockchip debug stub. Both date back to the initial board submission and neither matches the V3 schematic.
pcie2x1l1 is the controller behind the M.2 M-key socket. Its reset-gpios names GPIO1_A7, but PERST# on connector pin 50 runs through R211 to GPIO1_B0. GPIO1_A7 is the SoC PCIE20X1_1_PERSTN_M2 alternate function pin, which is likely why it was picked, but on this board it is routed to pin 13 of the 30-pin user header instead. The driver has been toggling a header pin on every boot and resume while the card never sees a reset pulse.
The spi0 node claims the m3 pin group, and one of those pads is GPIO3_D1, which the schematic assigns to the mini-PCIe PERST# line. The pin controller settles the clash in favor of the PCIe driver and prints a warning with a backtrace on every boot, leaving spi0 without a MISO line. The board has no SPI NOR fitted and the only child was the EVB test stub, so the node has nothing left to do.
Tested on an R1 v3 with a Patriot P300 NVMe in the M.2 socket. To be clear about scope, this does not change whether the SSD is detected: the link comes up Gen2 x1 either way, because the module releases PERST# on its own at power-up. It is a correctness fix, and it stops the kernel from driving a user header pin. The pin assignments come from the V3 schematic cross checked against the pin tables in rk3588s-pinctrl.dtsi. The mainline device tree for this board carries the same wrong reset pin and I will send that fix separately.