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

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: <5ea33054-8a08-4bb3-81e7-d832c53979dc@kernel.org>
Date: Wed, 2 Jul 2025 22:18:10 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Shradha Todi <shradha.t@...sung.com>, '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

On 01/07/2025 15:35, Shradha Todi wrote:
>>> 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.

I still do not see the difference in hardware explained.

Best regards,
Krzysztof