[PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for FSD SoC

[Shradha Todi]

> -----Original Message-----
> From: Krzysztof Kozlowski <krzk at kernel.org>
> Sent: 01 July 2025 16:55
> To: Shradha Todi <shradha.t at samsung.com>; 'Rob Herring' <robh at kernel.org>
> Cc: linux-pci at vger.kernel.org; devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> samsung-soc at vger.kernel.org; linux-kernel at vger.kernel.org; linux-phy at lists.infradead.org; linux-
> fsd at tesla.com; mani at kernel.org; lpieralisi at kernel.org; kw at linux.com; bhelgaas at google.com;
> jingoohan1 at gmail.com; krzk+dt at kernel.org; conor+dt at kernel.org; alim.akhtar at samsung.com;
> vkoul at kernel.org; kishon at kernel.org; arnd at arndb.de; m.szyprowski at samsung.com;
> jh80.chung at samsung.com; pankaj.dubey at samsung.com
> Subject: Re: [PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for FSD SoC
> 
> On 01/07/2025 13:06, Shradha Todi wrote:
> >
> >
> >> -----Original Message-----
> >> From: Rob Herring <robh at kernel.org>
> >> Sent: 28 June 2025 02:47
> >> To: Shradha Todi <shradha.t at samsung.com>
> >> Cc: linux-pci at vger.kernel.org; devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> > linux-
> >> samsung-soc at vger.kernel.org; linux-kernel at vger.kernel.org; linux-phy at lists.infradead.org; linux-
> >> fsd at tesla.com; manivannan.sadhasivam at linaro.org; lpieralisi at kernel.org; kw at linux.com;
> >> bhelgaas at google.com; jingoohan1 at gmail.com; krzk+dt at kernel.org; conor+dt at kernel.org;
> >> alim.akhtar at samsung.com; vkoul at kernel.org; kishon at kernel.org; arnd at arndb.de;
> >> m.szyprowski at samsung.com; jh80.chung at samsung.com; pankaj.dubey at samsung.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 at samsung.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
> 
> So same?
> 
> > 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
> 
> So not same? Decide. Either it is same or not, cannot be both.
> 
> If you mean that some wiring is different on the board, then how does it
> differ in soc thus how it is per-soc property? If these are use-cases,
> then how is even suitable for DT?
> 
> I use your Tesla FSD differently and then I exchange DTSI and compatibles?
> 
> You are no describing real problem and both binding and your
> explanations are vague and imprecise. Binding tells nothing about it, so
> it is example of skipping important decisions.
> 
> > 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:
> 
> And in different use case on same soc you are going to reverse
> compatibles or instance IDs?
>

Even though both the PHYs are exactly identical in terms of hardware,
they need to be programmed/initialized/configured differently.

Sorry for my misuse of the word "use-case". To clarify, these configurations
will always remain the same for FSD SoC even if you use it differently.

I will use different compatibles for them as I understand that it is the best
option.
 
> > drivers/usb/phy/phy-am335x-control.c
> 
> So you took 15 years old hardware, code and binding as an example.
> 
> No, don't do that ever.
> 
> Anyway, poor choices even in newer code should not drive your design.
> Design it properly, describe the hardware.
> 
> > drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> > who use alias to differentiate between register offsets for instances.
> 
> 
> 
> Best regards,
> Krzysztof