[PATCH v2 0/2] Support for pmic-glink in SM8475

[PATCH v2 0/2] Support for pmic-glink in SM8475

[Esteban Urrutia via B4 Relay]

This series adds a compatible string for SM8475 for supporting
pmic-glink.
This way, confusion is avoided, because SM8475 takes most
(CPU/GPU/reserved-memory/etc.) things from SM8450 and some (PHY/eUSB)
from SM8550.
Instead of using one or the other, add a different compatible string.

Signed-off-by: Esteban Urrutia <esteuwu@proton.me>
---
Changes in v2:
- Apply suggestions from Krzysztof
- Link to v1: https://patch.msgid.link/20260729-sm8475-pmic-glink-v1-0-c2e1967c04de@proton.me

---
Esteban Urrutia (2):
      dt-bindings: soc: qcom: qcom,pmic-glink: Add compatible string for SM8475
      usb: typec: ucsi: ucsi_glink: Add compatible string for SM8475

 Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml | 1 +
 drivers/usb/typec/ucsi/ucsi_glink.c                             | 1 +
 2 files changed, 2 insertions(+)
---
base-commit: 95d6a9ccef99117115e41e9adb271243bd5e985b
change-id: 20260729-sm8475-pmic-glink-57e56f98d2b3

Best regards,
--  
Esteban Urrutia <esteuwu@proton.me>

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

[Esteban Urrutia via B4 Relay]

From: Esteban Urrutia <esteuwu@proton.me>

Due to a different process design, SM8475 (4 nm) SoC takes things from both
SM8450 (4 LPX) and SM8550 (4 nm) SoCs.
Add a separate compatible string for this SoC to avoid possible confusions.

Signed-off-by: Esteban Urrutia <esteuwu@proton.me>
---
 Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
index 16ad4f5698fc..c80c72411381 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
@@ -30,6 +30,7 @@ properties:
               - qcom,sc8280xp-pmic-glink
               - qcom,sm8350-pmic-glink
               - qcom,sm8450-pmic-glink
+              - qcom,sm8475-pmic-glink
               - qcom,sm8550-pmic-glink
           - const: qcom,pmic-glink
       - items:

-- 
2.55.0

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

[Krzysztof Kozlowski]

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 it
is even "different process design", because how one would know that?

> Add a separate compatible string for this SoC to avoid possible confusions.

No, explain the hardware compatibility.

Add foo bar, which is not compatible with baz because it uses bam bam in
different setup (difference in registers, e.g. XYZ and ABC),

Best regards,
Krzysztof

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

[Esteban Urrutia]

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 it
> 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 confusions.
> 
> No, explain the hardware compatibility.
> 
> Add foo bar, which is not compatible with baz because it uses bam bam in
> 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?

SM8475 is a respin of SM8450 on a different process node, which probably
forced some electrical changes.
Document the SM8475 compatible used to describe the PMIC GLINK on this
platform.

Regards,
Esteban

[1] https://lore.kernel.org/linux-arm-msm/afcbb668-ab9e-4f97-9014-ecbd5170ab92@linaro.org/

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

[Konrad Dybcio]

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 it
>> 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 confusions.
>>
>> No, explain the hardware compatibility.
>>
>> Add foo bar, which is not compatible with baz because it uses bam bam in
>> 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?

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)

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

Konrad

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

[Esteban Urrutia]

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 it
>>> 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 confusions.
>>>
>>> No, explain the hardware compatibility.
>>>
>>> Add foo bar, which is not compatible with baz because it uses bam bam in
>>> 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?
> 
> 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)
> 
> 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

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

[Konrad Dybcio]

On 7/31/26 5:54 PM, Esteban Urrutia wrote:
> 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 it
>>>> 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 confusions.
>>>>
>>>> No, explain the hardware compatibility.
>>>>
>>>> Add foo bar, which is not compatible with baz because it uses bam bam in
>>>> 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?
>>
>> 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)
>>
>> 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.

Somehow I confabulated the generic compatible being present in the
driver... I was trying to explain that 

And yes I didn't notice the 8350/8450 difference. But anyway, the
resolution will be one of:

// 8450 is fully compatible
"qcom,sm8475-pmic-glink",
"qcom,sm8450-pmic-glink",
"qcom,pmic-glink"

or

// 8475 is special
"qcom,sm8475-pmic-glink",
"qcom,pmic-glink"

depending on what you believe is more correct. I think the first
one fits better.

Konrad

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

[Esteban Urrutia]

On 7/31/26 12:28 PM, Konrad Dybcio wrote:
> Somehow I confabulated the generic compatible being present in the
> driver... I was trying to explain that
> 
> And yes I didn't notice the 8350/8450 difference. But anyway, the
> resolution will be one of:
> 
> // 8450 is fully compatible
> "qcom,sm8475-pmic-glink",
> "qcom,sm8450-pmic-glink",
> "qcom,pmic-glink"
> 
> or
> 
> // 8475 is special
> "qcom,sm8475-pmic-glink",
> "qcom,pmic-glink"
> 
> depending on what you believe is more correct. I think the first
> one fits better.

Yes, I agree the first case fits better, but I believe there is also a
possible third case:

// 8550 is fully compatible
"qcom,sm8475-pmic-glink",
"qcom,sm8550-pmic-glink",
"qcom,pmic-glink"

The reason why I believe this is that I've found SM8475 to include some
elements such as eUSB or PHY sequences found in more recent SoCs such as
SM8550.
I guess that's the case since SM8475 is a respin, but I'm not sure.

Regards,
Esteban

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

[Konrad Dybcio]

On 7/31/26 6:40 PM, Esteban Urrutia wrote:
> On 7/31/26 12:28 PM, Konrad Dybcio wrote:
>> Somehow I confabulated the generic compatible being present in the
>> driver... I was trying to explain that
>>
>> And yes I didn't notice the 8350/8450 difference. But anyway, the
>> resolution will be one of:
>>
>> // 8450 is fully compatible
>> "qcom,sm8475-pmic-glink",
>> "qcom,sm8450-pmic-glink",
>> "qcom,pmic-glink"
>>
>> or
>>
>> // 8475 is special
>> "qcom,sm8475-pmic-glink",
>> "qcom,pmic-glink"
>>
>> depending on what you believe is more correct. I think the first
>> one fits better.
> 
> Yes, I agree the first case fits better, but I believe there is also a
> possible third case:
> 
> // 8550 is fully compatible
> "qcom,sm8475-pmic-glink",
> "qcom,sm8550-pmic-glink",
> "qcom,pmic-glink"
> 
> The reason why I believe this is that I've found SM8475 to include some
> elements such as eUSB or PHY sequences found in more recent SoCs such as
> SM8550.
> I guess that's the case since SM8475 is a respin, but I'm not sure.

pmic-glink provides three main services:

- UCSI (Type-C)
- altmode pin assignment notifications (also Type-C)
- battmgr (battery/power supply)

In that scope, I believe it's no different to 8450

Konrad

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

[Esteban Urrutia]

On 7/31/26 12:42 PM, Konrad Dybcio wrote:
> pmic-glink provides three main services:
> 
> - UCSI (Type-C)
> - altmode pin assignment notifications (also Type-C)
> - battmgr (battery/power supply)
> 
> In that scope, I believe it's no different to 8450

Alright then. I guess I'll just go for the first resolution in v3.
Thanks for your input, Konrad.

Regards,
Esteban

[PATCH v2 2/2] usb: typec: ucsi: ucsi_glink: Add compatible string for SM8475

[Esteban Urrutia via B4 Relay]

From: Esteban Urrutia <esteuwu@proton.me>

Add compatible string for the PMIC GLINK service running on the coprocessor
found in the SM8475 SoC.

Signed-off-by: Esteban Urrutia <esteuwu@proton.me>
---
 drivers/usb/typec/ucsi/ucsi_glink.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/typec/ucsi/ucsi_glink.c b/drivers/usb/typec/ucsi/ucsi_glink.c
index 12e07b9fe622..78a0ea349ed4 100644
--- a/drivers/usb/typec/ucsi/ucsi_glink.c
+++ b/drivers/usb/typec/ucsi/ucsi_glink.c
@@ -381,6 +381,7 @@ static const struct of_device_id pmic_glink_ucsi_of_quirks[] = {
 	{ .compatible = "qcom,sc8280xp-pmic-glink", .data = &quirk_sc8280xp, },
 	{ .compatible = "qcom,sm8350-pmic-glink", .data = &quirk_sc8180x, },
 	{ .compatible = "qcom,sm8450-pmic-glink", .data = &quirk_sm8450, },
+	{ .compatible = "qcom,sm8475-pmic-glink", .data = &quirk_sm8450, },
 	{ .compatible = "qcom,sm8550-pmic-glink", .data = &quirk_sm8450, },
 	{ .compatible = "qcom,x1e80100-pmic-glink", .data = &quirk_x1e80100, },
 	{}

-- 
2.55.0

Re: [PATCH v2 2/2] usb: typec: ucsi: ucsi_glink: Add compatible string for SM8475

[Esteban Urrutia]

On 7/31/26 1:00 AM, Esteban Urrutia via B4 Relay wrote:
> Add compatible string for the PMIC GLINK service running on the coprocessor
> found in the SM8475 SoC.

Just realized I forgot to change the commit title... Will fix in v3.

Regards,
Esteban

Re: [PATCH v2 2/2] usb: typec: ucsi: ucsi_glink: Add compatible string for SM8475

[Krzysztof Kozlowski]

On Fri, Jul 31, 2026 at 01:00:09AM -0400, Esteban Urrutia wrote:
> Add compatible string for the PMIC GLINK service running on the coprocessor
> found in the SM8475 SoC.
> 
> Signed-off-by: Esteban Urrutia <esteuwu@proton.me>
> ---
>  drivers/usb/typec/ucsi/ucsi_glink.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/usb/typec/ucsi/ucsi_glink.c b/drivers/usb/typec/ucsi/ucsi_glink.c
> index 12e07b9fe622..78a0ea349ed4 100644
> --- a/drivers/usb/typec/ucsi/ucsi_glink.c
> +++ b/drivers/usb/typec/ucsi/ucsi_glink.c
> @@ -381,6 +381,7 @@ static const struct of_device_id pmic_glink_ucsi_of_quirks[] = {
>  	{ .compatible = "qcom,sc8280xp-pmic-glink", .data = &quirk_sc8280xp, },
>  	{ .compatible = "qcom,sm8350-pmic-glink", .data = &quirk_sc8180x, },
>  	{ .compatible = "qcom,sm8450-pmic-glink", .data = &quirk_sm8450, },
> +	{ .compatible = "qcom,sm8475-pmic-glink", .data = &quirk_sm8450, },

Really, you just wrote IT IS DIFFERENT in the bindings, so how can it be the same data?

Best regards,
Krzysztof

Re: [PATCH v2 2/2] usb: typec: ucsi: ucsi_glink: Add compatible string for SM8475

[Esteban Urrutia]

On 7/31/26 5:59 AM, Krzysztof Kozlowski wrote:
> Really, you just wrote IT IS DIFFERENT in the bindings, so how can it be the same data?
No. I said "different process design", not that they were different.
Other SoCs also use older data despite being newer, such as QCM6490
which uses SC8280XP data.

Regards,
Esteban

Re: [PATCH v2 0/2] Support for pmic-glink in SM8475

[Krzysztof Kozlowski]

On 31/07/2026 07:00, Esteban Urrutia via B4 Relay wrote:
> This series adds a compatible string for SM8475 for supporting
> pmic-glink.
> This way, confusion is avoided, because SM8475 takes most
> (CPU/GPU/reserved-memory/etc.) things from SM8450 and some (PHY/eUSB)
> from SM8550.
> Instead of using one or the other, add a different compatible string.
> 
> Signed-off-by: Esteban Urrutia <esteuwu@proton.me>
> ---
> Changes in v2:
> - Apply suggestions from Krzysztof

Which ones? I did not see any improvements. This has to be specific.

Best regards,
Krzysztof