From: Lee Jones <lee@kernel.org>
To: Guangshuo Li <lgs201920130244@gmail.com>
Cc: Linus Walleij <linusw@kernel.org>,
Samuel Ortiz <sameo@linux.intel.com>,
Mattias Wallin <mattias.wallin@stericsson.com>,
Ludovic Barre <ludovic.barre@stericsson.com>,
Alexandre Torgue <alexandre.torgue@st.com>,
Julien Delacou <julien.delacou@stericsson.com>,
linux-arm-kernel@lists.infradead.org, mfd@lists.linux.dev,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] mfd: ab8500: fix child device leaks on probe failure
Date: Tue, 22 Sep 2026 16:06:42 +0100 [thread overview]
Message-ID: <20260922150642.GH3277918@google.com> (raw)
In-Reply-To: <CANUHTR9B84LoCjOtS5N5qGO0KXSXUbZkrKZ3_GFTwXmVoPQ0SA@mail.gmail.com>
On Tue, 22 Sep 2026, Guangshuo Li wrote:
> Hi Lee,
>
> Thanks.
>
> On Tue, 22 Sept 2026 at 15:41, Lee Jones <lee@kernel.org> wrote:
> >
> > On Mon, 21 Sep 2026, Guangshuo Li wrote:
> >
> > > ab8500_probe() registers MFD child devices before completing the
> > > remaining device initialization.
> > >
> > > On AB8540, the main MFD device batch may be registered successfully
> > > before registration of the cut-specific batch fails. In that case,
> > > the probe returns without removing the child devices registered by
> > > the earlier mfd_add_devices() call.
> > >
> > > The same issue occurs when sysfs group creation fails after the MFD
> > > children have been registered. Since the probe returns an error, there
> > > is no later teardown path to unregister those devices.
> > >
> > > Call mfd_remove_devices() on these error paths so that MFD child
> > > devices successfully registered earlier in the probe are properly
> > > unregistered and released.
> > >
> > > The issue was identified by a static analysis tool I developed and
> > > confirmed by manual review.
> > >
> > > Fixes: cca69b67b3ba ("mfd: Export ab8500 chip id to sysfs")
> > > Fixes: 9c717cf3fa16 ("mfd: ab8500-core: Add device for new RTC version for AB8540 cut2")
> > > Cc: stable@vger.kernel.org
> > > Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> > > ---
> > > drivers/mfd/ab8500-core.c | 8 ++++++--
> > > 1 file changed, 6 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/mfd/ab8500-core.c b/drivers/mfd/ab8500-core.c
> > > index f0bc0b5a6f4a..e675223b6023 100644
> > > --- a/drivers/mfd/ab8500-core.c
> > > +++ b/drivers/mfd/ab8500-core.c
> > > @@ -1220,8 +1220,10 @@ static int ab8500_probe(struct platform_device *pdev)
> > > ret = mfd_add_devices(ab8500->dev, 0, ab8500_devs,
> > > ARRAY_SIZE(ab8500_devs), NULL,
> > > 0, ab8500->domain);
> > > - if (ret)
> > > + if (ret) {
> > > + mfd_remove_devices(ab8500->dev);
> >
> > What about switching to devm_*() a.k.a. managed resources?
> >
> > > return ret;
> > > + }
> > >
> > > /* Add battery management devices */
> > > ret = mfd_add_devices(ab8500->dev, 0, ab8500_bm_devs,
> > > @@ -1243,8 +1245,10 @@ static int ab8500_probe(struct platform_device *pdev)
> > > ret = sysfs_create_group(&ab8500->dev->kobj,
> > > &ab8505_attr_group);
> > >
> > > - if (ret)
> > > + if (ret) {
> > > dev_err(ab8500->dev, "error creating sysfs entries\n");
> > > + mfd_remove_devices(ab8500->dev);
> > > + }
> > >
> > > return ret;
> > > }
> > > --
> > > 2.43.0
> > >
> >
> > --
> > Lee Jones
>
> Do you mean converting the MFD registrations in ab8500_probe() to
> devm_mfd_add_devices(), so the children are cleaned up automatically on
> probe failure, e.g.:
>
> - ret = mfd_add_devices(ab8500->dev, 0, ab8540_devs,
> + ret = devm_mfd_add_devices(ab8500->dev, 0, ab8540_devs,
> ARRAY_SIZE(ab8540_devs), NULL,
> 0, ab8500->domain);
>
> ...
>
> - ret = mfd_add_devices(ab8500->dev, 0, ab8500_bm_devs,
> + ret = devm_mfd_add_devices(ab8500->dev, 0, ab8500_bm_devs,
> ARRAY_SIZE(ab8500_bm_devs), NULL,
> 0, ab8500->domain);
>
> and likewise for the other MFD batches?
>
> If so, I'll rework the patch that way for v2.
Yes.
--
Lee Jones
prev parent reply other threads:[~2026-09-22 15:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 11:09 Guangshuo Li
2026-09-22 7:41 ` Lee Jones
2026-09-22 8:29 ` Guangshuo Li
2026-09-22 15:06 ` Lee Jones [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260922150642.GH3277918@google.com \
--to=lee@kernel.org \
--cc=alexandre.torgue@st.com \
--cc=julien.delacou@stericsson.com \
--cc=lgs201920130244@gmail.com \
--cc=linusw@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ludovic.barre@stericsson.com \
--cc=mattias.wallin@stericsson.com \
--cc=mfd@lists.linux.dev \
--cc=sameo@linux.intel.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®