Re: [PATCH v5 00/18] mfd: demodularization of non-modular drivers

Lee Jones
2019-03-07T08:25:24Z

On Wed, 06 Mar 2019, Paul Gortmaker wrote:

> [Re: [PATCH v5 00/18] mfd: demodularization of non-modular drivers] On 07/03/2019 (Thu 00:10) Pavel Machek wrote:
>
> > On Wed 2019-01-16 13:24:31, Lee Jones wrote:
> > > [...]
> > >
> > > > Paul Gortmaker (18):
> > > > mfd: aat2870-core: Make it explicitly non-modular
> > > > mfd: adp5520: Make it explicitly non-modular
> > > > mfd: as3711: Make it explicitly non-modular
> > > > mfd: db8500-prcmu: drop unused MODULE_ tags from non-modular code
> > > > mfd: htc-i2cpld: Make it explicitly non-modular
> > > > mfd: max8925-core: drop unused MODULE_ tags from non-modular code
> > > > mfd: rc5t583: Make it explicitly non-modular
> > > > mfd: sta2x11: drop unused MODULE_ tags from non-modular code
> > > > mfd: syscon: Make it explicitly non-modular
> > > > mfd: tps65090: Make it explicitly non-modular
> > > > mfd: tps65910: Make it explicitly non-modular
> > > > mfd: tps80031: Make it explicitly non-modular
> > > > mfd: wm831x-spi: Make it explicitly non-modular
> > > > mfd: wm831x-i2c: Make it explicitly non-modular
> > > > mfd: wm831x-core: drop unused module infrastructure from non-modular code
> > > > mfd: wm8350-i2c: Make it explicitly non-modular
> > > > mfd: wm8350-core: drop unused module infrastructure from non-modular code
> > > > mfd: wm8400-core: Make it explicitly non-modular
> > > >
> > > > drivers/mfd/aat2870-core.c | 40 +++-------------------------------------
> > > > drivers/mfd/adp5520.c | 30 +++++++-----------------------
> > > > drivers/mfd/as3711.c | 14 --------------
> > > > drivers/mfd/db8500-prcmu.c | 10 ++++------
> > > > drivers/mfd/htc-i2cpld.c | 18 +-----------------
> > > > 20 files changed, 41 insertions(+), 332 deletions(-)
> > >
> > > All applied!
> >
> > Is it good idea?
>
> Pavel, I think yes it is good, and I hope you will allow me the chance
> to convince you of the same. It removes dead code, and removes the
> chance that people mistakenly believe any of these drivers were
> currently possible as modules, when they were really NOT at all modular.
>
> > We want distro kernels on ARM, too, which means people will eventually
> > want these as a modules, no?
>
> And at the risk of repeating something I've said a lot already, this
> is fine, and I 100% support people converting drivers to being modular,
> in the case where there is demand, and where people with the hardware
> who are willing to test that the modular use-case actually works.
>
> If people want it to be modular, then this work actually helps. You
> don't have drivers "hiding in the shadows" that pretend to be modules.
> Such drivers do not at all help with the "distro kernels" use case.
>
> If a driver author responds and says they intended to make their driver
> a module, I 100% support them, and will drop the code removal patch and
> also have supported them in making their work tristate. If the choice
> to convert to tristate happens a year or more from now, it is trivial to
> reclaim the unused-but-deleted code from git.
>
> But, again as I have said many times -- I can't know every detail of
> each driver to know if module/tristate makes any sense, as a use-case or
> if even technically possible (such as in DMA/IOMMU or similar low level
> core systems). So the right option is to remove the dead code and not
> impact the existing driver behaviour, and make it clear in the process
> to the authors and users, that the driver was never modular to begin
> with -- and in doing so, give them all a chance to comment and react.
>
> Pavel, I hope this more extended explanation makes sense to you, and
> that you simply have not seen me write these same details in the past.

Blimey. That's a really long winded way of saying:

"Modular-ness is actually broken in these drivers; [Paul]'s patches
make that point clear for all to see. If people (authors/distros)
wish them to be modular, they need to fix them properly."

--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog