[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 0/2] Support for pmic-glink in SM8475

[Esteban Urrutia]

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

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

[Esteban Urrutia]

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

[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

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

[Esteban Urrutia]

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 1/2] dt-bindings: soc: qcom: qcom,pmic-glink: Add compatible string for SM8475

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The new compatible string `qcom,sm8475-pmic-glink` is missing from driver match tables, which will cause functional failures for UCSI (Type-C PD) and potentially the Battery Manager.
--

--- Patch [1]: [PATCH v2 1/2] dt-bindings: soc: qcom: qcom,pmic-glink: Add compatible string for SM8475 ---
commit 6029f64195b0d5f78f56d1dc22f18faabeb47c53
Author: Esteban Urrutia <esteuwu@proton.me>

dt-bindings: soc: qcom: qcom,pmic-glink: Add compatible string for SM8475

This commit adds a new compatible string for the SM8475 SoC to the pmic-glink
binding. It separates the SM8475 from SM8450 and SM8550 due to process design
differences.

> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
> index 16ad4f5698fc3..c80c724113816 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

[Severity: High]
Should this compatible string also be added to the driver match tables in
drivers/usb/typec/ucsi/ucsi_glink.c and drivers/power/supply/qcom_battmgr.c?

Looking at pmic_glink_ucsi_of_quirks in drivers/usb/typec/ucsi/ucsi_glink.c,
missing this compatible string causes of_match_device to return NULL. Since
both SM8450 and SM8550 require quirk_sm8450 to enable UCSI_DELAY_DEVICE_PDOS,
missing this quirk on SM8475 might lead to USB Type-C Power Delivery
negotiation failures.

Additionally, in qcom_battmgr_of_variants in qcom_battmgr.c, an unlisted
compatible string implicitly falls back to QCOM_BATTMGR_SM8350. Does SM8475
require the QCOM_BATTMGR_SM8550 variant instead, and could this cause battery
manager regressions?

>                - qcom,sm8550-pmic-glink
>            - const: qcom,pmic-glink
>        - items:

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260731-sm8475-pmic-glink-v2-0-28c04928ef22@proton.me?part=1

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The format specifier %pOFn is incorrectly used with a struct fwnode_handle pointer.
--

--- Patch [2]: [PATCH v2 2/2] usb: typec: ucsi: ucsi_glink: Add compatible string for SM8475 ---
commit d37a66c9dfca5e74cbcec6a0c03a891ac3e2d3bd
Author: Esteban Urrutia <esteuwu@proton.me>

usb: typec: ucsi: ucsi_glink: Add compatible string for SM8475

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

> diff --git a/drivers/usb/typec/ucsi/ucsi_glink.c b/drivers/usb/typec/ucsi/ucsi_glink.c
> index 12e07b9fe6228..78a0ea349ed41 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, },
>  	{}

[Severity: High]
This is a pre-existing issue, but does pmic_glink_ucsi_probe() pass the
wrong pointer type to dev_err() when handling a missing property?

drivers/usb/typec/ucsi/ucsi_glink.c:pmic_glink_ucsi_probe() {
    ...
	device_for_each_child_node_scoped(dev, fwnode) {
		struct gpio_desc *desc;
		u32 port;

		ret = fwnode_property_read_u32(fwnode, "reg", &port);
		if (ret < 0) {
			dev_err(dev, "missing reg property of %pOFn\n", fwnode);
			return ret;
		}
    ...
}

The %pOFn format specifier expects a struct device_node pointer, but it is
being passed a struct fwnode_handle pointer here.

When vsnprintf processes %pOFn, it will cast the pointer to struct device_node
and read the name or full_name fields at offsets that do not match struct
fwnode_handle.

Can this exceed the size of the structure and result in reading unrelated kernel
memory, potentially causing a kernel panic due to an invalid memory access if a
child node is missing the reg property?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260731-sm8475-pmic-glink-v2-0-28c04928ef22@proton.me?part=2

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 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 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 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

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 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 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