On Fri, 12 Oct 2018, Bartlomiej Zolnierkiewicz wrote: > On 10/11/2018 07:48 AM, Lee Jones wrote: > > On Wed, 10 Oct 2018, Bartlomiej Zolnierkiewicz wrote: > > > >> 'default n' is the default value for any bool or tristate Kconfig > >> setting so there is no need to write it explicitly. > >> > >> Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO > >> is not set' for visible symbols") the Kconfig behavior is the same > >> regardless of 'default n' being present or not: > >> > >> ... > >> One side effect of (and the main motivation for) this change is making > >> the following two definitions behave exactly the same: > >> > >> config FOO > >> bool > >> > >> config FOO > >> bool > >> default n > >> > >> With this change, neither of these will generate a > >> '# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied). > >> That might make it clearer to people that a bare 'default n' is > >> redundant. > >> ... > >> > >> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com> > >> --- > >> drivers/mfd/Kconfig | 6 ------ > >> 1 file changed, 6 deletions(-) > > > > The change looks okay to me, but I would also like you to include the > > Maintainers/Reviewers for the affected source files. > > Could you please explain in more details what do you mean? > > The only affected source file is drivers/mfd/Kconfig: > > $ ./scripts/get_maintainer.pl -f drivers/mfd/Kconfig > Lee Jones <lee.jo...@linaro.org> (supporter:MULTIFUNCTION DEVICES (MFD)) > linux-kernel@vger.kernel.org (open list)
You need to run get_maintainer.pl on each of the source files this patch affects. > > Also, I assume you are not just submitting these changes to the MFD > > subsystem. My suggesting is to change each subsystem per patch (as > > you have done here), and submit them in one patch-set with each of the > > subsystem Maintainers included, so each of us has some visibility into > > how the general idea is being received. > > The general idea is trivial - remove redundant "default n" from Kconfig > files and as a result cut ~700 LOC kernel wide. I assume that this is so > trivial change that there is no need for longer deliberations. I agree that the patch looks fairly inert. > Also I'm sorry but I simply cannot invest few days straight in preparing > the full patchset. OTOH investing few minutes a day or a week is fine so > this is why I'm doing this change incrementally. However, converting a few subsystems at a time doesn't sound like a great hardship. It allows other Maintainers to see how the idea is being received generally - rather than doing them all independently which disallows shared interest/discussion. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog