Re: [PATCH 5/5] PCI: rzg3s-host: Add support for RZ/V2H(P) SoC

[Lad, Prabhakar]

Hi Mani,

On Fri, May 1, 2026 at 3:42 PM Manivannan Sadhasivam <mani@xxxxxxxxxx> wrote:
>
> On Fri, May 01, 2026 at 12:13:55PM +0100, Lad, Prabhakar wrote:
> > 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.
> >
>
> "linux,pci-domain" is supposed to be used in SoC.dtsi, not in board.dts. AFAIK,
> the board designers have no reason to change it.
>
> Yes, the property name implies that it is a Linux specific property and if you
> want, you can propose a generic one (not vendor specific one). Other than that,
> I don't see a blocker in using this property. Many SoCs already do this and
> other DT projects like u-boot do not end up parsing this property.
>
> > > >   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.
> >
>
> What if you have other register blocks using the same pattern in the future?
> You'll end up with renesas,xxx = <xxx, N>. You should stick to
> "linux,pci-domain".
>
As Geert pointed out this overlaps with pciX DT aliases on PPC boards.

Cheers,
Prabhakar