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:   Wed, 6 Mar 2019 23:18:08 -0500
From:   Paul Gortmaker <paul.gortmaker@...driver.com>
To:     Pavel Machek <pavel@....cz>
CC:     Lee Jones <lee.jones@...aro.org>, <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

[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.

Thanks,
Paul.
--

> 									Pavel
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html