Re: [PATCH v4 5/6] extcon: qcom-spmi-misc: match PM8xxx USB ID platform device

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The probe function silently squashes -EPROBE_DEFER and other error codes from platform_get_irq_byname_optional(), permanently breaking device initialization.
--

commit 1e93c1501595aa2edcd9a08fd1d48d4373aaf0ca
Author: Alexandre MINETTE <contact@alex-min.fr>

extcon: qcom-spmi-misc: match PM8xxx USB ID platform device

The PM8xxx MFD registers the PM8921 USB ID detector as a platform device
named "qcom-pm8xxx-usb-id". This commit adds a platform device ID so the
existing extcon driver can bind to this device.

> diff --git a/drivers/extcon/extcon-qcom-spmi-misc.c b/drivers/extcon/extcon-qcom-spmi-misc.c
> index afaba5685c3dc..e16c109b553e2 100644
> --- a/drivers/extcon/extcon-qcom-spmi-misc.c
> +++ b/drivers/extcon/extcon-qcom-spmi-misc.c
[ ... ]
> @@ -204,8 +204,15 @@ static const struct of_device_id qcom_usb_extcon_dt_match[] = {
>  };
>  MODULE_DEVICE_TABLE(of, qcom_usb_extcon_dt_match);
>  
> +static const struct platform_device_id qcom_usb_extcon_id[] = {
> +	{ "qcom-pm8xxx-usb-id" },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(platform, qcom_usb_extcon_id);
> +
>  static struct platform_driver qcom_usb_extcon_driver = {
>  	.probe		= qcom_usb_extcon_probe,

[Severity: High]
This is a pre-existing issue, but does qcom_usb_extcon_probe() mishandle
deferred probing?

Looking at qcom_usb_extcon_probe(), if platform_get_irq_byname_optional()
returns -EPROBE_DEFER for the IRQs:

drivers/extcon/extcon-qcom-spmi-misc.c:qcom_usb_extcon_probe() {
	...
	info->id_irq = platform_get_irq_byname_optional(pdev, "usb_id");
	if (info->id_irq > 0) {
	...
	info->vbus_irq = platform_get_irq_byname_optional(pdev, "usb_vbus");
	if (info->vbus_irq > 0) {
	...
	if (info->id_irq < 0 && info->vbus_irq < 0) {
		dev_err(dev, "ID and VBUS IRQ not found\n");
		return -EINVAL;
	}
	...
}

If both IRQs defer, the code falls through and returns -EINVAL instead of
propagating -EPROBE_DEFER, which could permanently prevent the device from
initializing.

Additionally, if one IRQ defers while the other is found, the driver simply
skips requesting it.  Could this cause the probe to succeed in a degraded
state without the deferred IRQ?

> +	.id_table	= qcom_usb_extcon_id,
>  	.driver		= {
>  		.name	= "extcon-pm8941-misc",
>  		.pm	= &qcom_usb_extcon_pm_ops,

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260609-mainline-send-v1-sending-v4-0-83768fbf404d@alex-min.fr?part=5