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

[Geert Uytterhoeven]

Hi Manivannan,

On Fri, 1 May 2026 at 16:42, Manivannan Sadhasivam <mani@xxxxxxxxxx> wrote:
> On Fri, May 01, 2026 at 12:13:55PM +0100, Lad, Prabhakar wrote:
> > 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:
> > > > On Wed, Mar 25, 2026 at 10:18 AM Claudiu Beznea
> > > > <claudiu.beznea@xxxxxxxxx> wrote:
> > > > > 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.

Sounds like this overlaps with pciN DT aliases, which are in use on
some (PPC) boards?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds