Re: [PATCH v2 2/2] mfd: mxs-lradc: Pass parent IRQs to child drivers

[Andy Shevchenko <andriy.shevchenko@intel.com>]

On Tue, Nov 10, 2026 at 11:19:34AM -0300, Fabio Estevam wrote:
> The MFD driver stores raw DT interrupt indices in IRQ resources but
> registers its child devices without an IRQ domain or IRQ base. The child
> drivers consequently receive the indices as if they were mapped Linux
> IRQ numbers. IRQ index 0 triggers the platform_get_irq_byname() warning:
> 
>   0 is an invalid IRQ number
> 
> The children then try to recover the indices from their resources and
> map them against the parent OF node. Besides duplicating IRQ names in
> the parent and children, this relies on invalid platform IRQ resources
> and fails when IRQ 0 is rejected.
> 
> Resolve the interrupts with platform_get_irq() in the MFD parent and
> store the mapped IRQs in the shared LRADC data. Drop the child IRQ
> resources and duplicated name arrays, and have both child drivers
> request the mapped IRQs directly. Use the MFD memory base support to
> translate a single relative memory resource shared by both cells.
> 
> Tested on an i.MX28 EVK. The mxs-lradc-ts driver probes successfully,
> touch events are reported, and the touch-detect and LRADC channel 7
> interrupt counters increase as expected.
> 
> Cc: stable@vger.kernel.org
> Suggested-by: Lee Jones <lee@kernel.org>
> Closes: https://lore.kernel.org/linux-input/CAOMZO5CgTzo6GuXptD4mFTN=UsJJqpkixDW1Q64gqZGrij8+uQ@mail.gmail.com/

He-he, this rings a bell! I have still a copy of the mbox of this thread
locally to maybe (likely never) look into that. So, I am so glad to see this
being eventually addressed!

> Fixes: a85a6c86c25b ("driver core: platform: Clarify that IRQ 0 is invalid")
> Signed-off-by: Fabio Estevam <festevam@gmail.com>

...

>  	struct device_node *node = dev->parent->of_node;
>  	struct mxs_lradc *lradc = dev_get_drvdata(dev->parent);
>  	struct mxs_lradc_ts *ts;
> -	int ret, irq, virq, i;
> +	int ret, i;
>  	u32 ts_wires = 0, adapt;

Can we, while at it, kinda follow the reversed xmas tree order here?

...

> -	lradc->soc = (kernel_ulong_t)device_get_match_data(&pdev->dev);
> +	data = device_get_match_data(dev);

Is this driver affected by driver_override case? If so, this has to be checked
against NULL and return -ENODATA.

> +	lradc->soc = data->soc;

-- 
With Best Regards,
Andy Shevchenko