Re: [PATCH 6/6] mfd: qcom-pm8008: Tolerate missing interrupt

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] mfd: qcom-pm8008: bogus IRQ mappings for child cells when client->irq is 0
--

commit 2c273914596163e5696becde808ceb33d98f0fe8
Author: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

mfd: qcom-pm8008: Tolerate missing interrupt

This commit modifies pm8008_probe() to only register the IRQ infrastructure
if the parent IRQ is present. This is intended to support devices like PM8010
where the interrupt pin is tied to ground.

> diff --git a/drivers/mfd/qcom-pm8008.c b/drivers/mfd/qcom-pm8008.c
> --- a/drivers/mfd/qcom-pm8008.c
> +++ b/drivers/mfd/qcom-pm8008.c
> @@ -233,7 +233,7 @@ static void devm_irq_domain_fwnode_release(void *data)
>  
>  static int pm8008_probe(struct i2c_client *client)
>  {
> -	struct regmap_irq_chip_data *irq_data;
> +	struct regmap_irq_chip_data *irq_data = NULL;
>  	const struct pm8008_match_data *data;

[ ... ]

> -	/* Needed by GPIO driver. */
> -	dev_set_drvdata(dev, regmap_irq_get_domain(irq_data));
> +		/* Needed by GPIO driver. */
> +		dev_set_drvdata(dev, regmap_irq_get_domain(irq_data));
> +	}
>  
>  	return devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, data->mfd_cells,
> -				data->num_mfd_cells, NULL, 0,
> -				regmap_irq_get_domain(irq_data));
> +				    data->num_mfd_cells, NULL, 0,
> +				    regmap_irq_get_domain(irq_data));

[Severity: Medium]
Will this lead to bogus IRQ mappings for child cells when client->irq is 0?

When the device has no IRQ, irq_data remains NULL, and we pass a NULL domain
to devm_mfd_add_devices() with an irq_base of 0.

The MFD cells (such as pm8008_temp_res for qpnp-temp-alarm) specify IRQ
resources using DEFINE_RES_IRQ() with hardcoded offsets, for example:

static const struct resource pm8008_temp_res[] = {
	DEFINE_RES_MEM(PM8008_TEMP_ALARM_ADDR, 0x100),
	DEFINE_RES_IRQ(PM8008_IRQ_TEMP_ALARM),
};

When mfd_add_device() processes these IRQ resources and the domain is NULL,
it falls back to assigning the IRQ as irq_base + start. Since irq_base is 0,
a child device like the temp alarm will be assigned a global physical Linux
IRQ matching its offset (e.g., 0 + 5 = 5).

If a child driver requests this IRQ, could it steal an interrupt from another
hardware device on the system, leading to unexpected behavior or resource
conflicts? Should the driver dynamically strip or adjust the IRQ resources
from the MFD cells when no parent IRQ is present?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260918-pm8010_i2c_support-v1-0-de33d78fad9d@oss.qualcomm.com?part=6