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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 7 Mar 2019 08:25:24 +0000
From:   Lee Jones <lee.jones@...aro.org>
To:     Paul Gortmaker <paul.gortmaker@...driver.com>
Cc:     Pavel Machek <pavel@....cz>, linux-kernel@...r.kernel.org,
        Alessandro Rubini <rubini@...dd.com>,
        Arnd Bergmann <arnd@...db.de>,
        Charles Keepax <ckeepax@...nsource.cirrus.com>,
        Cory Maccarrone <darkstar6262@...il.com>,
        Davide Ciminaghi <ciminaghi@...dd.com>,
        Dong Aisheng <dong.aisheng@...aro.org>,
        Graeme Gregory <gg@...mlogic.co.uk>,
        Guennadi Liakhovetski <g.liakhovetski@....de>,
        Haojian Zhuang <haojian.zhuang@...vell.com>,
        Jin Park <jinyoungp@...dia.com>,
        Jorge Eduardo Candelaria <jedu@...mlogic.co.uk>,
        Laxman Dewangan <ldewangan@...dia.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Mark Brown <broonie@...nsource.wolfsonmicro.com>,
        Mattias Nilsson <mattias.i.nilsson@...ricsson.com>,
        Michael Hennerich <michael.hennerich@...log.com>,
        Tony Lindgren <tony@...mide.com>,
        Venu Byravarasu <vbyravarasu@...dia.com>,
        linux-omap@...r.kernel.org, patches@...nsource.cirrus.com
Subject: Re: [PATCH v5 00/18] mfd: demodularization of non-modular drivers

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