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

[PATCH 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>
---
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: 78bc8af4affb9a732504eb22eeac7d1e50883853
change-id: 20260729-sm8475-pmic-glink-57e56f98d2b3

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

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

Add compatible string for pmic-glink.

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 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 pmic-glink.

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 2/2] usb: typec: ucsi: ucsi_glink: Add compatible string for SM8475

[sashiko-bot]

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

Pre-existing issues:
- [High] Passing a `struct fwnode_handle *` to the `%pOFn` format specifier causes a type mismatch and potential kernel oops.
- [High] Missing `cancel_work_sync()` in the driver unbind path leads to a use-after-free if `notify_work` or `register_work` runs after the device is removed.
- [High] Integer underflow when checking the response payload length allows an out-of-bounds read if a short message is received.
- [High] Missing payload length validation leads to an out-of-bounds read if a short message is received.
--

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

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

Add compatible string for pmic-glink.

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

[Severity: High]
This isn't a bug introduced by this patch, but while reviewing this file I
noticed a pre-existing issue on the error path in pmic_glink_ucsi_probe():

drivers/usb/typec/ucsi/ucsi_glink.c:pmic_glink_ucsi_probe() {
        ...
        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 fwnode is
a struct fwnode_handle pointer. Does vsprintf misinterpret the pointer and
read invalid memory here, potentially leading to a panic?

[Severity: High]
This is a pre-existing issue, but I also noticed a potential use-after-free
if a work item executes after the device is removed:

drivers/usb/typec/ucsi/ucsi_glink.c:pmic_glink_ucsi_remove() {
        struct pmic_glink_ucsi *ucsi = dev_get_drvdata(&adev->dev);

        /* Unregister first to stop having read & writes */
        ucsi_unregister(ucsi->ucsi);
}

If an asynchronous notification from the PMIC GLINK processor schedules
notify_work or register_work just before or during device removal, the work
could execute after devres frees ucsi. Is a cancel_work_sync() missing here
to prevent the race?

[Severity: High]
This is another pre-existing issue, but I wanted to ask about a potential
integer underflow in pmic_glink_ucsi_read_ack():

drivers/usb/typec/ucsi/ucsi_glink.c:pmic_glink_ucsi_read_ack() {
        ...
        if (buf_len > len - sizeof(struct pmic_glink_hdr) - sizeof(u32))
                buf_len = len - sizeof(struct pmic_glink_hdr) - sizeof(u32);

        memcpy(&ret_code, buf + buf_len, sizeof(u32));
        ...
}

If len is smaller than the combined sizeof headers, would the subtraction
underflow to a large unsigned value because sizeof evaluates to size_t? 

If so, buf_len would remain unmodified, potentially causing an out-of-bounds
read when memcpy reads from buf + buf_len.

[Severity: High]
This is also a pre-existing issue, but does pmic_glink_ucsi_write_ack() miss a
length check?

drivers/usb/typec/ucsi/ucsi_glink.c:pmic_glink_ucsi_write_ack() {
        const struct ucsi_write_buf_resp_msg *resp = data;

        if (resp->ret_code)
                return;
        ...
}

If the PMIC GLINK processor sends a short message where len is less than
sizeof(*resp), we immediately dereference resp->ret_code. Can this lead to an
out-of-bounds read?

>  	{ .compatible = "qcom,sm8550-pmic-glink", .data = &quirk_sm8450, },
>  	{ .compatible = "qcom,x1e80100-pmic-glink", .data = &quirk_x1e80100, },
>  	{}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260729-sm8475-pmic-glink-v1-0-c2e1967c04de@proton.me?part=2