From: Lee Jones <lee.jones@linaro.org>
To: Charles Keepax <ckeepax@opensource.cirrus.com>
Cc: linux-kernel@vger.kernel.org, patches@opensource.cirrus.com
Subject: Re: [PATCH v2 1/2] mfd: mfd-core: Add mechanism for removal of a subset of children
Date: Tue, 16 Jun 2020 14:22:59 +0100 [thread overview]
Message-ID: <20200616132259.GS2608702@dell> (raw)
In-Reply-To: <20200616100625.GT71940@ediswmail.ad.cirrus.com>
On Tue, 16 Jun 2020, Charles Keepax wrote:
> On Tue, Jun 16, 2020 at 10:15:45AM +0100, Lee Jones wrote:
> > On Tue, 16 Jun 2020, Charles Keepax wrote:
> > > On Tue, Jun 16, 2020 at 08:58:34AM +0100, Lee Jones wrote:
> > > > On Mon, 15 Jun 2020, Charles Keepax wrote:
> > > Does this match how you would expect this to be used?
> >
> > No, not at all.
> >
> > > I do have some concerns. The code can't use mfd_get_cell since it
> > > returns a const pointer, although the pointer in platform_device
> > > isn't const so we access that directly, could update mfd_get_cell? We
> > > also don't have access to mfd_dev_type outside of the mfd core so
> > > its hard to check we are actually setting the mfd_cell of actual
> > > MFD children, I guess just checking for mfd_cell being not NULL is
> > > good enough?
> >
> > Hmmm... looks like I missed the fact that you needed additional
> > processing between the removal of each batch of devices. My
> > implementation simply handles the order in which devices are removed
> > (a bit like initcall()s).
> >
> > How about the inclusion of mfd_remove_devices_late(), whereby
> > mfd_remove_devices() will refuse to remove devices tagged with
> > MFD_DEP_LEVEL_HIGH.
> >
>
> Yeah this should work fine for my use-case.
>
> > Not sure why, but I really dislike the idea of device removal by
> > arbitrary value/tag, as I see it spawning all sorts of weird and
> > wonderful implications/hacks/abuse.
> >
>
> Its definitely a spectrum with flexibility covering more
> use-cases but also definitely opening things up to more abuse. If
> you are more comfortable with this approach that is fine with me.
>
> Would you like me to have a crack at coding it up this way? Or
> did you want to do a patch?
Either/or. I don't want to steal your thunder, but I'm happy to draft
if you are.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
next prev parent reply other threads:[~2020-06-16 13:23 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-15 15:07 [PATCH v2 1/2] mfd: mfd-core: Add mechanism for removal of a subset of children Charles Keepax
2020-06-15 15:07 ` [PATCH v2 2/2] mfd: madera: Improve handling of regulator unbinding Charles Keepax
2020-06-16 7:58 ` [PATCH v2 1/2] mfd: mfd-core: Add mechanism for removal of a subset of children Lee Jones
2020-06-16 8:47 ` Charles Keepax
2020-06-16 9:15 ` Lee Jones
2020-06-16 10:06 ` Charles Keepax
2020-06-16 13:22 ` Lee Jones [this message]
2020-06-16 13:30 ` Charles Keepax
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=20200616132259.GS2608702@dell \
--to=lee.jones@linaro.org \
--cc=ckeepax@opensource.cirrus.com \
--cc=linux-kernel@vger.kernel.org \
--cc=patches@opensource.cirrus.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.