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

[sashiko-bot@kernel.org]

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