Re: [PATCH 5/5] PCI: rzg3s-host: Add support for RZ/V2H(P) SoC
From: Lad, Prabhakar
Date: Fri May 01 2026 - 07:14:41 EST
Hi Manivannan,
On Thu, Apr 30, 2026 at 4:26 PM Manivannan Sadhasivam <mani@xxxxxxxxxx> wrote:
>
> On Wed, Apr 08, 2026 at 07:54:41PM +0100, Lad, Prabhakar wrote:
> > Hi All,
> >
> > On Wed, Mar 25, 2026 at 10:18 AM Claudiu Beznea
> > <claudiu.beznea@xxxxxxxxx> wrote:
> > >
> > > Hi, Prabhakar,
> > >
> > > On 3/18/26 14:44, Prabhakar wrote:
> > > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx>
> > > >
> > > > Add support for the RZ/V2H(P) SoC PCIe controller to the rzg3s-host
> > > > driver.
> > > >
> > > > The RZ/V2H(P) SoC features two independent PCIe channels that share
> > > > physical lanes. The hardware supports two configuration modes: single
> > > > x4 mode where one controller uses all four lanes, or dual x2 mode
> > > > where both controllers use two lanes each.
> > > >
> > > > Introduce configure_lanes() function pointer to configure the PCIe
> > > > lanes based on the number of channels enabled. Implement
> > > > rzv2h_pcie_configure_lanes() to detect the active PCIe channels at
> > > > boot time and program the lane mode via the system controller using
> > > > the new RZG3S_SYSC_FUNC_ID_LINK_MASTER function ID.
> > > >
> > > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx>
> > > > ---
> > > > drivers/pci/controller/pcie-rzg3s-host.c | 142 +++++++++++++++++++++++
> > > > 1 file changed, 142 insertions(+)
> > > >
<snip>
> > >
> > > This introduces some limits in the systems with RZ/V2H(P) SoCs with regards to
> > > the usage of linux,pci-domain. I would like the PCIe maintainers take on this.
> > >
> > > As this is necessary to index in the system controller driver specific data (as
> > > there are different SYSC offsets for different PCIe controllers) I see the
> > > following alternatives, if any:
> > >
> > > 1/ add a dedicated DT property for this, e.g. renesas,pcie-controller-id
> > > 2/ Add dedicated DT bindings for RZ/V2H(P) SoC that would be used to specify the
> > > system controller register offset and mask for different functionalities.
> > >
> > > E.g.:
> > > renesas,sysc-l1-allow = <&sysc 0x1020 0x1>;
> > > renesas,sysc-mode = <&sysc 0x1024 0x1>;
> > > renesas,sysc-link-master = <&sysc 0x1060 0x300>;
> > >
> > > And use them in each controller DT node. E.g.:
> > >
> > > pcie0: pcie@add1 {
> > > // ...
> > >
> > > renesas,sysc-l1-allow = <&sysc 0x1020 0x1>;
> > > renesas,sysc-mode = <&sysc 0x1024 0x1>;
> > > renesas,sysc-link-master = <&sysc 0x1060 0x300>;
> > >
> > > // ...
> > > };
> > >
> > > pcie0: pcie@add1 {
> > > // ...
> > >
> > > renesas,sysc-l1-allow = <&sysc 0x1050 0x1>;
> > > renesas,sysc-mode = <&sysc 0x1054 0x1>;
> > > renesas,sysc-link-master = <&sysc 0x1060 0x300>;
> > >
> > > // ...
> > > };
> > >
> > I'd like to get a clearer steer from the PCIe and DT maintainers
> > before investing further in either direction.
> >
> > To recap the two approaches on the table:
> >
> > Option 1: A single renesas,pcie-controller-id property used to look up
> > SYSC offsets in the driver.
> >
>
> Can you explain what is the limitation with 'linux,pci-domain' property?
>
As sashiko pointed out.dev, The linux,pci-domain property is generally
an OS-specific logical property intended to assign a stable PCI domain
number across reboots. Restricting it to [0, 1] would prevent system
integrators from using non-conflicting domain numbers like 2 or 3 if
the board incorporates other PCIe controllers.
> > Option 2: Explicit per-controller DT properties carrying the SYSC
> > phandle, register offset, and mask for each functionality
> > (L1 allow, mode, link-master, etc.).
> >
>
> Are the register offsets going to stay the same across controller instances?
>
> If they are not going to change and you can derive the offsets using the
> controller index, then there is no need to go for individual DT properties.
>
The offsets will remain the same across the controller instances. So
instead of using linux,pci-domain property we could use below is that
OK?
pcie0 {
renesas,sysc = <&sysc 0>;
};
pcie1 {
renesas,sysc = <&sysc 1>;
};
Where 0/1 are the controller instance IDs that the driver will use to
derive the correct offsets.
Cheers,
Prabhakar