From: Paul Gortmaker <paul.gortmaker@windriver.com> To: Pavel Machek <pavel@ucw.cz> Cc: Lee Jones <lee.jones@linaro.org>, <linux-kernel@vger.kernel.org>, Alessandro Rubini <rubini@gnudd.com>, Arnd Bergmann <arnd@arndb.de>, Charles Keepax <ckeepax@opensource.cirrus.com>, Cory Maccarrone <darkstar6262@gmail.com>, Davide Ciminaghi <ciminaghi@gnudd.com>, Dong Aisheng <dong.aisheng@linaro.org>, Graeme Gregory <gg@slimlogic.co.uk>, Guennadi Liakhovetski <g.liakhovetski@gmx.de>, Haojian Zhuang <haojian.zhuang@marvell.com>, Jin Park <jinyoungp@nvidia.com>, Jorge Eduardo Candelaria <jedu@slimlogic.co.uk>, Laxman Dewangan <ldewangan@nvidia.com>, Linus Walleij <linus.walleij@linaro.org>, Mark Brown <broonie@opensource.wolfsonmicro.com>, Mattias Nilsson <mattias.i.nilsson@stericsson.com>, Michael Hennerich <michael.hennerich@analog.com>, Tony Lindgren <tony@atomide.com>, Venu Byravarasu <vbyravarasu@nvidia.com>, <linux-omap@vger.kernel.org>, <patches@opensource.cirrus.com> Subject: Re: [PATCH v5 00/18] mfd: demodularization of non-modular drivers Date: Wed, 6 Mar 2019 23:18:08 -0500 [thread overview] Message-ID: <20190307041808.GK26690@windriver.com> (raw) In-Reply-To: <20190306231003.GD7915@amd> [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
WARNING: multiple messages have this Message-ID (diff)
From: Paul Gortmaker <paul.gortmaker@windriver.com> To: Pavel Machek <pavel@ucw.cz> Cc: Lee Jones <lee.jones@linaro.org>, linux-kernel@vger.kernel.org, Alessandro Rubini <rubini@gnudd.com>, Arnd Bergmann <arnd@arndb.de>, Charles Keepax <ckeepax@opensource.cirrus.com>, Cory Maccarrone <darkstar6262@gmail.com>, Davide Ciminaghi <ciminaghi@gnudd.com>, Dong Aisheng <dong.aisheng@linaro.org>, Graeme Gregory <gg@slimlogic.co.uk>, Guennadi Liakhovetski <g.liakhovetski@gmx.de>, Haojian Zhuang <haojian.zhuang@marvell.com>, Jin Park <jinyoungp@nvidia.com>, Jorge Eduardo Candelaria <jedu@slimlogic.co.uk>, Laxman Dewangan <ldewangan@nvidia.com>, Linus Walleij <linus.walleij@linaro.org>, Mark Brown <broonie@opensource.wolfsonmicro.com>, Mattias Nilsson <mattias.i.nilsson@stericsson.com>, Michael Hennerich <michael.hennerich@analog.com>, Tony Subject: Re: [PATCH v5 00/18] mfd: demodularization of non-modular drivers Date: Wed, 6 Mar 2019 23:18:08 -0500 [thread overview] Message-ID: <20190307041808.GK26690@windriver.com> (raw) In-Reply-To: <20190306231003.GD7915@amd> [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
next prev parent reply other threads:[~2019-03-07 4:18 UTC|newest] Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-01-13 18:36 [PATCH v5 00/18] mfd: demodularization of non-modular drivers Paul Gortmaker 2019-01-13 18:36 ` Paul Gortmaker 2019-01-13 18:36 ` [PATCH 01/18] mfd: aat2870-core: Make it explicitly non-modular Paul Gortmaker 2019-01-13 18:36 ` [PATCH 02/18] mfd: adp5520: " Paul Gortmaker 2019-01-13 18:36 ` [PATCH 03/18] mfd: as3711: " Paul Gortmaker 2019-01-13 18:36 ` [PATCH 04/18] mfd: db8500-prcmu: drop unused MODULE_ tags from non-modular code Paul Gortmaker 2019-01-13 18:36 ` [PATCH 05/18] mfd: htc-i2cpld: Make it explicitly non-modular Paul Gortmaker 2019-01-13 18:36 ` [PATCH 06/18] mfd: max8925-core: drop unused MODULE_ tags from non-modular code Paul Gortmaker 2019-01-13 18:36 ` [PATCH 07/18] mfd: rc5t583: Make it explicitly non-modular Paul Gortmaker 2019-01-13 18:36 ` [PATCH 08/18] mfd: sta2x11: drop unused MODULE_ tags from non-modular code Paul Gortmaker 2019-01-13 18:36 ` [PATCH 09/18] mfd: syscon: Make it explicitly non-modular Paul Gortmaker 2019-01-13 18:36 ` [PATCH 10/18] mfd: tps65090: " Paul Gortmaker 2019-01-13 18:36 ` [PATCH 11/18] mfd: tps65910: " Paul Gortmaker 2019-01-13 18:36 ` Paul Gortmaker 2019-01-13 18:36 ` [PATCH 12/18] mfd: tps80031: " Paul Gortmaker 2019-01-13 18:36 ` [PATCH 13/18] mfd: wm831x-spi: " Paul Gortmaker 2019-01-14 11:28 ` Charles Keepax 2019-01-13 18:36 ` [PATCH 14/18] mfd: wm831x-i2c: " Paul Gortmaker 2019-01-13 18:36 ` [PATCH 15/18] mfd: wm831x-core: drop unused module infrastructure from non-modular code Paul Gortmaker 2019-01-13 18:36 ` [PATCH 16/18] mfd: wm8350-i2c: Make it explicitly non-modular Paul Gortmaker 2019-01-13 18:36 ` [PATCH 17/18] mfd: wm8350-core: drop unused module infrastructure from non-modular code Paul Gortmaker 2019-01-13 18:36 ` [PATCH 18/18] mfd: wm8400-core: Make it explicitly non-modular Paul Gortmaker 2019-01-16 13:24 ` [PATCH v5 00/18] mfd: demodularization of non-modular drivers Lee Jones 2019-01-16 13:24 ` Lee Jones 2019-03-06 23:10 ` Pavel Machek 2019-03-06 23:10 ` Pavel Machek 2019-03-07 4:18 ` Paul Gortmaker [this message] 2019-03-07 4:18 ` Paul Gortmaker 2019-03-07 8:25 ` Lee Jones 2019-03-07 8:25 ` Lee Jones 2019-03-07 8:35 ` Pavel Machek 2019-03-07 8:35 ` Pavel Machek 2019-03-07 16:11 ` Tony Lindgren 2019-03-07 16:11 ` Tony Lindgren
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190307041808.GK26690@windriver.com \ --to=paul.gortmaker@windriver.com \ --cc=arnd@arndb.de \ --cc=broonie@opensource.wolfsonmicro.com \ --cc=ciminaghi@gnudd.com \ --cc=ckeepax@opensource.cirrus.com \ --cc=darkstar6262@gmail.com \ --cc=dong.aisheng@linaro.org \ --cc=g.liakhovetski@gmx.de \ --cc=gg@slimlogic.co.uk \ --cc=haojian.zhuang@marvell.com \ --cc=jedu@slimlogic.co.uk \ --cc=jinyoungp@nvidia.com \ --cc=ldewangan@nvidia.com \ --cc=lee.jones@linaro.org \ --cc=linus.walleij@linaro.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-omap@vger.kernel.org \ --cc=mattias.i.nilsson@stericsson.com \ --cc=michael.hennerich@analog.com \ --cc=patches@opensource.cirrus.com \ --cc=pavel@ucw.cz \ --cc=rubini@gnudd.com \ --cc=tony@atomide.com \ --cc=vbyravarasu@nvidia.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.