Re: [PATCH v2 1/2] dt-bindings: soc: qcom: qcom,pmic-glink: Add compatible string for SM8475

On 7/31/26 11:30 AM, Konrad Dybcio wrote:
> On 7/31/26 4:44 PM, Esteban Urrutia wrote:
>> On 7/31/26 5:58 AM, Krzysztof Kozlowski wrote:
>>> On Fri, Jul 31, 2026 at 01:00:08AM -0400, Esteban Urrutia wrote:
>>>> Due to a different process design, SM8475 (4 nm) SoC takes things from=
 both
>>>> SM8450 (4 LPX) and SM8550 (4 nm) SoCs.
>>>
>>> What things? This is just unspecific and not useful. And I doubt that i=
t
>>> is even "different process design", because how one would know that?
>>
>>
>> The process design is specified on the corresponding datasheets for
>> these SoCs, which are flying somewhere around the internet.
>> Also [1].
>>
>>>> Add a separate compatible string for this SoC to avoid possible confus=
ions.
>>>
>>> No, explain the hardware compatibility.
>>>
>>> Add foo bar, which is not compatible with baz because it uses bam bam i=
n
>>> different setup (difference in registers, e.g. XYZ and ABC),
>>
>> How does this commit message based on what was said in [1] sound to you?
>=20
> That made more sense because the electrical differences are what made
> the PHY init sequence changes necessary. Here, Krzysztof is trying to
> express that the pmic-glink interface found on SM8475 is likely no
> different than the one found on SM8450 (and SM8350 and so on)
>=20
> Then, since it's the same, it can reuse the same driver match data,
> so patch 2 is unnecessary, since the driver binds said match data
> on the fallback "qcom,pmic-glink" compatible


I don't understand. You're implying that the pmic-glink interface found
on SM8350 and SM8450 is not that different but they both have different
quirks on ucsi_glink.c.
No quirks would be applied on SM8475 if patch 2 is not in place either.

Regards,
Esteban