linux-kernel - Re: [PATCH v2 01/13] dt-bindings: pci: apple,pcie: Add t6020 compatible string

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <864izhmkzd.wl-maz@kernel.org>
Date: Tue, 25 Mar 2025 11:02:30 +0000
From: Marc Zyngier <maz@...nel.org>
To: Mark Kettenis <mark.kettenis@...all.nl>
Cc: linux-arm-kernel@...ts.infradead.org,
	linux-pci@...r.kernel.org,
	devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	asahi@...ts.linux.dev,
	alyssa@...enzweig.io,
	j@...nau.net,
	marcan@...can.st,
	sven@...npeter.dev,
	bhelgaas@...gle.com,
	lpieralisi@...nel.org,
	kw@...ux.com,
	manivannan.sadhasivam@...aro.org,
	robh@...nel.org,
	krzk+dt@...nel.org
Subject: Re: [PATCH v2 01/13] dt-bindings: pci: apple,pcie: Add t6020 compatible string

Hi Mark,

On Tue, 25 Mar 2025 10:50:18 +0000,
Mark Kettenis <mark.kettenis@...all.nl> wrote:
> 
> > From: Marc Zyngier <maz@...nel.org>
> > Date: Tue, 25 Mar 2025 10:25:58 +0000
> 
> Hi Marc,
> 
> Sorry for not spotting this in the earlier versions, but:

No worries -- I expected issues in that department.

>
> > From: Alyssa Rosenzweig <alyssa@...enzweig.io>
> > 
> > t6020 adds some register ranges compared to t8103, so requires
> > a new compatible as well as the new PHY registers themselves.
> > 
> > Signed-off-by: Alyssa Rosenzweig <alyssa@...enzweig.io>
> > [maz: added PHY registers]
> > Signed-off-by: Marc Zyngier <maz@...nel.org>
> > ---
> >  Documentation/devicetree/bindings/pci/apple,pcie.yaml | 11 ++++++++++-
> >  1 file changed, 10 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/pci/apple,pcie.yaml b/Documentation/devicetree/bindings/pci/apple,pcie.yaml
> > index c8775f9cb0713..77554899b9420 100644
> > --- a/Documentation/devicetree/bindings/pci/apple,pcie.yaml
> > +++ b/Documentation/devicetree/bindings/pci/apple,pcie.yaml
> > @@ -17,6 +17,10 @@ description: |
> >    implements its root ports.  But the ATU found on most DesignWare
> >    PCIe host bridges is absent.
> >  
> > +  On systems derived from T602x, the PHY registers are in a region
> > +  separate from the port registers. In that case, there is one PHY
> > +  register range per port register range.
> > +
> >    All root ports share a single ECAM space, but separate GPIOs are
> >    used to take the PCI devices on those ports out of reset.  Therefore
> >    the standard "reset-gpios" and "max-link-speed" properties appear on
> > @@ -35,11 +39,12 @@ properties:
> >            - apple,t8103-pcie
> >            - apple,t8112-pcie
> >            - apple,t6000-pcie
> > +          - apple,t6020-pcie
> >        - const: apple,pcie
> 
> Since the T602x PCIe controller has a different register layout, it
> isn't compatible with the others, so it should not include the
> "apple,pcie" compatible.  The "downstream" device trees for
> T602x-based devices do indeed not list "apple,pcie" as a compatible.
> So I think this needs to be written as:
> 
>   compatible:
>     oneOf:
>       - items:
>           - enum:
>               - apple,t8103-pcie
>               - apple,t8112-pcie
>               - apple,t6000-pcie
>           - const: apple,pcie
>       - const: apple,t6020-pcie

Ah, indeed, that's a good point. Thanks for that.

Whilst I have your attention, how about my question below:

>
> >  
> >    reg:
> >      minItems: 3
> > -    maxItems: 6
> > +    maxItems: 10
> >  
> >    reg-names:
> >      minItems: 3
> > @@ -50,6 +55,10 @@ properties:
> >        - const: port1
> >        - const: port2
> >        - const: port3
> > +      - const: phy0
> > +      - const: phy1
> > +      - const: phy2
> > +      - const: phy3

Do we need to make this t6020 specific?

Obviously, separate PHY registers do not make much sense before t6020,
but I couldn't find a way to describe that. I don't even know if
that's a desirable outcome.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.