On Mon, May 11, 2020 at 04:53:32PM +0100, Charles Keepax wrote: > Currently, the only way to remove MFD children is with a call to > mfd_remove_devices, which will remove all the children. Under > some circumstances it is useful to remove only a subset of the > child devices. For example if some additional clean up is required > between removal of certain child devices. > > To accomplish this a tag field is added to mfd_cell, and a > corresponding mfd_remove_devices_by_tag function is added to > remove children with a specific tag. This allows a good amount of > flexibility in which child devices a driver wishes to remove, as a > driver could target specific drivers or a large group. Allowing other > use-cases such as removing drivers for functionality that is no longer > required. > > Some investigation was done of using the mfd_cell name and id fields, > but it is hard to achieve a good level of flexibility there, at least > without significant complexity. Since the id gets modified by the core > and can even by automatically generated. Using the name alone would > work for my usecase but it is not hard to imagine a situation where it > wouldn't. > > Signed-off-by: Charles Keepax <[email protected]> > --- > > Following on from our discussions here: > > https://lore.kernel.org/lkml/[email protected]/#t > > Happy to discuss other approaches as well, but this one was quite > appealing as it was very simple but affords quite a lot of flexibility. > > Thanks, > Charles > > > drivers/mfd/mfd-core.c | 11 +++++++++++ > include/linux/mfd/core.h | 2 ++ > 2 files changed, 13 insertions(+) > > diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c > index f5a73af60dd40..83a57186169de 100644 > --- a/drivers/mfd/mfd-core.c > +++ b/drivers/mfd/mfd-core.c > @@ -287,6 +287,7 @@ static int mfd_remove_devices_fn(struct device *dev, void > *data) > { > struct platform_device *pdev; > const struct mfd_cell *cell; > + int tag = (int)data;
Yeah as the build bot points out should have actually used a pointer here. Will update for that if we don't have any major objections to the approach in general. Thanks, Charles
