Re: [PATCH] mfd: wcd934x: Unroll regmap and irqchip on removal

[David Heidelberg <david@ixit.cz>]

On 10/03/2026 04:53, Bjorn Andersson wrote:
> When the slimbus-up event is handled a new regmap is created, an IRQ
> chip is registered on this regmap and then the MFD devices are added.
> 
> But the regmap is left dangling if either any of those operations are
> failing or if the slimbus-down event ever comes. Which manifest itself
> as an error print from debugfs once the next slimbus-up event happens.
> 
> Likewise, if for some reason a slimbus-down event would be followed by
> a slimbus-up event without the MFD being torn down by the slimbus
> controller inbetween, we're going to have a dangling irq_chip.
> 
> Add cleanup of the registered resources on failure and on removal.
> 
> Fixes: 6ac7e4d7ad70 ("mfd: wcd934x: Add support to wcd9340/wcd9341 codec")
> Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
> ---
>   drivers/mfd/wcd934x.c | 49 ++++++++++++++++++++++++++++++++++++++-----------
>   1 file changed, 38 insertions(+), 11 deletions(-)
> 
What is final thought on this series?

I have feeling Sashiko pointed the problem with devm double registration still 
exist, see below:

[Severity: High]
This is a pre-existing issue, but does the use of managed devres functions in
wcd934x_slim_status_up() cause memory leaks and double registrations?

drivers/mfd/wcd934x.c:wcd934x_slim_status_up() {
     ...
	ret = devm_regmap_add_irq_chip(dev, ddata->regmap, ddata->irq,
				       IRQF_TRIGGER_HIGH, 0,
				       &wcd934x_regmap_irq_chip,
				       &ddata->irq_data);
     ...
}

wcd934x_slim_status_up() is called when the SLIMbus transitions to
SLIM_DEVICE_STATUS_UP. If the bus goes DOWN, mfd_remove_devices() is called,
but the IRQ chip added via devm_regmap_add_irq_chip() is not removed because
devres cleanup only happens on driver unbind, not on bus status changes.

When the bus transitions UP again, wouldn't the driver attempt to re-register
the IRQ chip and fail with -EBUSY, leaving the device in an unusable state?

https://lore.kernel.org/mfd/20260903145651.AC1311F00ACA@smtp.kernel.org/

David