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: <02af01dbea78$24f01310$6ed03930$@samsung.com>
Date: Tue, 1 Jul 2025 16:36:03 +0530
From: "Shradha Todi" <shradha.t@...sung.com>
To: "'Rob Herring'" <robh@...nel.org>
Cc: <linux-pci@...r.kernel.org>, <devicetree@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>, <linux-samsung-soc@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linux-phy@...ts.infradead.org>,
	<linux-fsd@...la.com>, <mani@...nel.org>, <lpieralisi@...nel.org>,
	<kw@...ux.com>, <bhelgaas@...gle.com>, <jingoohan1@...il.com>,
	<krzk+dt@...nel.org>, <conor+dt@...nel.org>, <alim.akhtar@...sung.com>,
	<vkoul@...nel.org>, <kishon@...nel.org>, <arnd@...db.de>,
	<m.szyprowski@...sung.com>, <jh80.chung@...sung.com>,
	<pankaj.dubey@...sung.com>
Subject: RE: [PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for
 FSD SoC



> -----Original Message-----
> From: Rob Herring <robh@...nel.org>
> Sent: 28 June 2025 02:47
> To: Shradha Todi <shradha.t@...sung.com>
> Cc: linux-pci@...r.kernel.org; devicetree@...r.kernel.org; linux-arm-kernel@...ts.infradead.org;
linux-
> samsung-soc@...r.kernel.org; linux-kernel@...r.kernel.org; linux-phy@...ts.infradead.org; linux-
> fsd@...la.com; manivannan.sadhasivam@...aro.org; lpieralisi@...nel.org; kw@...ux.com;
> bhelgaas@...gle.com; jingoohan1@...il.com; krzk+dt@...nel.org; conor+dt@...nel.org;
> alim.akhtar@...sung.com; vkoul@...nel.org; kishon@...nel.org; arnd@...db.de;
> m.szyprowski@...sung.com; jh80.chung@...sung.com; pankaj.dubey@...sung.com
> Subject: Re: [PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for FSD SoC
> 
> On Wed, Jun 25, 2025 at 10:22:26PM +0530, Shradha Todi wrote:
> > Document PHY device tree bindings for Tesla FSD SoCs.
> >
> > Signed-off-by: Shradha Todi <shradha.t@...sung.com>
> > ---
> >  .../bindings/phy/samsung,exynos-pcie-phy.yaml | 25 +++++++++++++++++--
> >  1 file changed, 23 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
> b/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
> > index 41df8bb08ff7..4dc20156cdde 100644
> > --- a/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
> > +++ b/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
> > @@ -15,10 +15,13 @@ properties:
> >      const: 0
> >
> >    compatible:
> > -    const: samsung,exynos5433-pcie-phy
> > +    enum:
> > +      - samsung,exynos5433-pcie-phy
> > +      - tesla,fsd-pcie-phy
> >
> >    reg:
> > -    maxItems: 1
> > +    minItems: 1
> > +    maxItems: 2
> >
> >    samsung,pmu-syscon:
> >      $ref: /schemas/types.yaml#/definitions/phandle
> > @@ -30,6 +33,24 @@ properties:
> >      description: phandle for FSYS sysreg interface, used to control
> >                   sysreg registers bits for PCIe PHY
> >
> > +allOf:
> > +  - if:
> > +      properties:
> > +        compatible:
> > +          contains:
> > +            enum:
> > +              - tesla,fsd-pcie-phy
> > +    then:
> > +      description:
> > +        The PHY controller nodes are represented in the aliases node
> > +        using the following format 'pciephy{n}'. Depending on whether
> > +        n is 0 or 1, the phy init sequence is chosen.
> 
> What? Don't make up your own aliases.
> 
> If the PHY instances are different, then maybe you need a different
> compatible. If this is just selecting the PHY mode, you can do that in
> PHY cells as the mode depends on the consumer.
> 

FSD PCIe has 2 instances of PHY. Both are the same HW Samsung
PHYs (Therefore share the same register offsets). But the PHY used here
does not support auto adaptation so we need to tune the PHYs
according to the use case (considering channel loss, etc). This is why we
have 2 different SW PHY initialization sequence depending on the instance
number. Do you think having different compatible (something like
tesla,fsd-pcie-phy0 and tesla,fsd-pcie-phy1) and having phy ID as platform data
is okay in this case? I actually took reference from files like:
drivers/usb/phy/phy-am335x-control.c
drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
who use alias to differentiate between register offsets for instances.

> 
> > +      properties:
> > +        reg:
> > +          items:
> > +            - description: PHY
> > +            - description: PCS
> 
> else:
>   properties:
>     reg:
>       maxItems: 1
> 

Will update. Thanks for the review!

> > +
> >  required:
> >    - "#phy-cells"
> >    - compatible
> > --
> > 2.49.0
> >


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ