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

[Lee Jones]

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