Hello folks!
I’ve been working on a custom
PCIe-to-SATA HAT for an
RK3588-based Single Board Computer (SBC).On this board, the primary M.2 NVMe interface is wired for PCIe 3.0 x4. However, my SATA HAT application
only requires 2 lanes. To bridge the SBC and the HAT, I'm using a custom M.2 redriver board.
As per the RK3588 TRM, the chip features two internal PCIe 3.0 PHY blocks: PHY0 (controlling Lane 0 and Lane 1) and PHY1 (controlling Lane 2 and Lane 3).

Due to specific hardware routing constraints on our setup,
my application explicitly utilizes the latter set of lanes (Lanes 2 & 3 via PHY1). Currently, the PCIe-to-SATA bridge IC is not being detected at all.
While digging into the Rockchip Linux PCIe Development Guide, I noticed that their reference example for
2Lane + 2Lane (PHY_MODE_PCIE_NANBNB) assigns independent reset-gpios to each controller (pcie3x4 / fe150000 for Port 0 and pcie3x2 / fe160000 for Port 1).

Here is my issue: our SBC hardware only routes a single physical PERST# GPIO line to the M.2 slot (which was originally intended for the x4 configuration). Since my HAT routes signals through PHY1, I attempted to assign that single physical PERST# GPIO directly to the pcie3x2 (fe160000) controller in the Device Tree, while completely removing the reset-gpios property from pcie3x4 (fe150000).
However, checking dmesg shows that fe150000 reaches LTSSM 0x3 (Polling.Compliance), whereas fe160000 (pcie3x2) remains frozen solid at LTSSM 0x0 (Detect.Quiet) and fails to initialize.


My questions are:
1. Is assigning the main M.2 PERST# GPIO exclusively to the pcie3x2 controller node (while disabling or stripping reset-gpios from pcie3x4) a valid configuration in the Rockchip kernel driver framework, or will fe150000 always hold primary clocking/reset gating over fe160000?
2. Has anyone successfully brought up PCIe 3.0 PHY1 (pcie3x2 / fe160000) standalone on an RK3588 without an active PHY0 link?
Any insights, DTS examples, or debugging tips would be greatly appreciated! Thank you!