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

Hi Manivannan,

On Thu, Apr 30, 2026 at 4:26 PM Manivannan Sadhasivam [off-list ref] wrote:

On Wed, Apr 08, 2026 at 07:54:41PM +0100, Lad, Prabhakar wrote:

quoted

Hi All,

On Wed, Mar 25, 2026 at 10:18 AM Claudiu Beznea
[off-list ref] wrote:

quoted

Hi, Prabhakar,

On 3/18/26 14:44, Prabhakar wrote:

quoted

From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

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@bp.renesas.com>
---
  drivers/pci/controller/pcie-rzg3s-host.c | 142 +++++++++++++++++++++++
  1 file changed, 142 insertions(+)

<snip>

quoted

quoted

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.

quoted

  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