[PATCH 3/4] dt-bindings: phy: airoha: Document support for AN7583 PCIe PHY

[Conor Dooley]

On Tue, Jun 17, 2025 at 03:57:09PM +0200, Christian Marangi wrote:
> On Mon, Jun 09, 2025 at 05:51:10PM +0100, Conor Dooley wrote:
> > On Fri, Jun 06, 2025 at 09:22:04PM +0200, Christian Marangi wrote:
> > > Document support for AN7583 PCIe PHY used to make the Gen3 PCIe port
> > > work. Add the rwquired register to configure the PCIe PHY and provide an
> > > example for it.
> > > 
> > > Signed-off-by: Christian Marangi <ansuelsmth at gmail.com>
> > > ---
> > >  .../bindings/phy/airoha,an7583-pcie-phy.yaml  | 72 +++++++++++++++++++
> > >  1 file changed, 72 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/phy/airoha,an7583-pcie-phy.yaml
> > > 
> > > diff --git a/Documentation/devicetree/bindings/phy/airoha,an7583-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/airoha,an7583-pcie-phy.yaml
> > > new file mode 100644
> > > index 000000000000..93252092c2e3
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/phy/airoha,an7583-pcie-phy.yaml
> > > @@ -0,0 +1,72 @@
> > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/phy/airoha,an7583-pcie-phy.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Airoha AN7583 PCI-Express PHY
> > > +
> > > +maintainers:
> > > +  - Christian Marangi <ansuelsmth at gmail.com>
> > > +
> > > +description:
> > > +  The PCIe PHY supports physical layer functionality for PCIe Gen2/Gen3 port.
> > > +
> > > +properties:
> > > +  compatible:
> > > +    const: airoha,an7583-pcie-phy
> > > +
> > > +  reg:
> > > +    items:
> > > +      - description: PCIE G3 analog base address
> > > +      - description: PCIE G3 PMA base address
> > > +      - description: PCIE QPhy analog base address
> > > +      - description: PCIE QPhy PMA base address
> > > +      - description: PCIE QPhy diagnostic base address
> > > +      - description: PCIE detection time base address
> > > +      - description: PCIE Rx AEQ base address
> > > +
> > > +  reg-names:
> > > +    items:
> > > +      - const: g3-ana
> > > +      - const: g3-pma
> > > +      - const: qp-ana
> > > +      - const: qp-pma
> > > +      - const: qp-dig
> > > +      - const: xr-dtime
> > > +      - const: rx-aeq
> > > +
> > > +  "#phy-cells":
> > > +    const: 0
> > > +
> > > +required:
> > > +  - compatible
> > > +  - reg
> > > +  - reg-names
> > > +  - "#phy-cells"
> > > +
> > > +additionalProperties: false
> > > +
> > > +examples:
> > > +  - |
> > > +    #include <dt-bindings/phy/phy.h>
> > > +
> > > +    soc {
> > > +        #address-cells = <2>;
> > > +        #size-cells = <2>;
> > > +
> > > +        phy at 11e80000 {

Oh also, this address doesn't match the reg property below.

> > > +            compatible = "airoha,an7583-pcie-phy";
> > > +            #phy-cells = <0>;
> > > +            reg = <0x0 0x1fc7f000 0x0 0xfff>,
> > > +                  <0x0 0x1fc7e000 0x0 0xfff>,
> > > +                  <0x0 0x1fa5f000 0x0 0xff>,
> > > +                  <0x0 0x1fa5e000 0x0 0x8ff>,
> > > +                  <0x0 0x1fa5a000 0x0 0x3ff>,
> > > +                  <0x0 0x1fc30044 0x0 0x4>,
> > > +                  <0x0 0x1fc35030 0x0 0x4>;
> > 
> > Can you explain please why you have so many reg regions, some of which
> > are directly beside one another? Why is one (or more) larger region(s)
> > not viable here? Are some of these coming from a syscon that is not
> > modelled or are there other devices sharing in between?
> >
> 
> It's to keep consistency with the documentation and how stuff is
> modelled in the SDK driver. The single region defined reflect real
> register space. In the middle they are invalid register that might cause
> system stall if read/written.

Some of the regions are directly bordering one another, with gaps of
only one byte? e.g. The second region runs from 0x1fc7e000 to 0x1fc7effe
and the next region starts at 0x1fc7ef000. One invalid byte in the
range is not worth splitting it out for. Although, are you sure that
there is exactly invalid byte and you're not propagating a mistake from
the en7581 where 0xfff was used instead of 0x1000 as a misunderstanding
of how to the size field worked?

I would expect, at the very least, that the 0x1fc7xxxx and 0x1fc5xxxx bits
should be grouped. The two 4-byte regions seem pretty suspect and really
do look like some sort of syscon that you're trying to expose only one word
from. Are you sure that there is nothing at addresses 0x1fc30040 and
0x1fc30048, for example? It seems odd to me to put single words at these
addresses (and likewise on the en7581) with nothing at all around them.
Do you have a regmap for this device, or are you mostly working
backwards from some sdk?

> Also this is to keep consistency with the en7581 pcie phy driver.

But your reg regions aren't even the same as with that phy?
It has:
      - description: PCIE analog base address
      - description: PCIE lane0 base address
      - description: PCIE lane1 base address
      - description: PCIE lane0 detection time base address
      - description: PCIE lane1 detection time base address
      - description: PCIE Rx AEQ base address

of which only 3 map 1:1 with yours?

> 
> Is it really that bad ? :(
> 
> > > +            reg-names = "g3-ana", "g3-pma",
> > > +                        "qp-ana", "qp-pma", "qp-dig",
> > > +                        "xr-dtime", "rx-aeq";
> > > +        };
> > > +    };
> > > -- 
> > > 2.48.1
> > > 
> 
> 
> 
> -- 
> 	Ansuel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20250617/8e69abe6/attachment.sig>