* CRISv32: ETRAX_SPI_MMC_BOARD
@ 2014-10-29 8:20 Paul Bolle
2014-10-29 9:33 ` Jesper Nilsson
0 siblings, 1 reply; 3+ messages in thread
From: Paul Bolle @ 2014-10-29 8:20 UTC (permalink / raw)
To: Jesper Nilsson
Cc: Valentin Rothberg, Mikael Starvik, linux-cris-kernel,
linux-kernel
Jesper,
Your commit be64c1ce6e79 ("CRISv32: Drop obsolete file for SPI driver")
landed in today's linux-next (ie, next-20141029). It removes the last
user of the Kconfig symbol ETRAX_SPI_MMC_BOARD. Setting that symbol is
now pointless.
Is the trivial patch to remove the entry for ETRAX_SPI_MMC_BOARD (and
one select statement for it) queued somewhere? If not, should I submit
it?
Paul Bolle
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: CRISv32: ETRAX_SPI_MMC_BOARD 2014-10-29 8:20 CRISv32: ETRAX_SPI_MMC_BOARD Paul Bolle @ 2014-10-29 9:33 ` Jesper Nilsson 2014-10-29 9:56 ` Paul Bolle 0 siblings, 1 reply; 3+ messages in thread From: Jesper Nilsson @ 2014-10-29 9:33 UTC (permalink / raw) To: Paul Bolle Cc: Jesper Nilsson, Valentin Rothberg, Mikael Starvik, linux-cris-kernel, linux-kernel@vger.kernel.org On Wed, Oct 29, 2014 at 09:20:54AM +0100, Paul Bolle wrote: > Jesper, Hi Paul! > Your commit be64c1ce6e79 ("CRISv32: Drop obsolete file for SPI driver") > landed in today's linux-next (ie, next-20141029). It removes the last > user of the Kconfig symbol ETRAX_SPI_MMC_BOARD. Setting that symbol is > now pointless. > > Is the trivial patch to remove the entry for ETRAX_SPI_MMC_BOARD (and > one select statement for it) queued somewhere? If not, should I submit > it? It was not, but it is now: CRISv32: Remove last remnants of ETRAX_SPI_MMC_BOARD There are no users of this symbol left. Reported-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Jesper Nilsson <jesper.nilsson@axis.com> --- arch/cris/arch-v32/drivers/Kconfig | 7 ------- 1 file changed, 7 deletions(-) diff --git a/arch/cris/arch-v32/drivers/Kconfig b/arch/cris/arch-v32/drivers/Kconfig index 6880f94..7068c4b 100644 --- a/arch/cris/arch-v32/drivers/Kconfig +++ b/arch/cris/arch-v32/drivers/Kconfig @@ -361,13 +361,6 @@ config ETRAX_SPI_MMC default MMC select SPI select MMC_SPI - select ETRAX_SPI_MMC_BOARD - -# For the parts that can't be a module (due to restrictions in -# framework elsewhere). -config ETRAX_SPI_MMC_BOARD - boolean - default n # While the board info is MMC_SPI only, the drivers are written to be # independent of MMC_SPI, so we'll keep SPI non-dependent on the -- 1.7.10.4 I'll try to think about unreferenced kconfigs in the future, my suspicion is that all those SPI and MMC related configs are also unused, just circular references keeping them unnoticed. Thanks for the heads up. > Paul Bolle /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nilsson@axis.com ^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: CRISv32: ETRAX_SPI_MMC_BOARD 2014-10-29 9:33 ` Jesper Nilsson @ 2014-10-29 9:56 ` Paul Bolle 0 siblings, 0 replies; 3+ messages in thread From: Paul Bolle @ 2014-10-29 9:56 UTC (permalink / raw) To: Jesper Nilsson Cc: Jesper Nilsson, Valentin Rothberg, Mikael Starvik, linux-cris-kernel, linux-kernel@vger.kernel.org Hi Jesper, On Wed, 2014-10-29 at 10:33 +0100, Jesper Nilsson wrote: > On Wed, Oct 29, 2014 at 09:20:54AM +0100, Paul Bolle wrote: > > Your commit be64c1ce6e79 ("CRISv32: Drop obsolete file for SPI driver") > > landed in today's linux-next (ie, next-20141029). It removes the last > > user of the Kconfig symbol ETRAX_SPI_MMC_BOARD. Setting that symbol is > > now pointless. > > > > Is the trivial patch to remove the entry for ETRAX_SPI_MMC_BOARD (and > > one select statement for it) queued somewhere? If not, should I submit > > it? > > It was not, but it is now: > > CRISv32: Remove last remnants of ETRAX_SPI_MMC_BOARD > > There are no users of this symbol left. > > Reported-by: Paul Bolle <pebolle@tiscali.nl> > Signed-off-by: Jesper Nilsson <jesper.nilsson@axis.com> > --- > arch/cris/arch-v32/drivers/Kconfig | 7 ------- > 1 file changed, 7 deletions(-) > > diff --git a/arch/cris/arch-v32/drivers/Kconfig b/arch/cris/arch-v32/drivers/Kconfig > index 6880f94..7068c4b 100644 > --- a/arch/cris/arch-v32/drivers/Kconfig > +++ b/arch/cris/arch-v32/drivers/Kconfig > @@ -361,13 +361,6 @@ config ETRAX_SPI_MMC > default MMC > select SPI > select MMC_SPI > - select ETRAX_SPI_MMC_BOARD > - > -# For the parts that can't be a module (due to restrictions in > -# framework elsewhere). > -config ETRAX_SPI_MMC_BOARD > - boolean > - default n > > # While the board info is MMC_SPI only, the drivers are written to be > # independent of MMC_SPI, so we'll keep SPI non-dependent on the > -- > 1.7.10.4 > > > I'll try to think about unreferenced kconfigs in the future, I'm hoping that Valentin's project will automate detection of these kind of problems for you (see http://www.linuxplumbersconf.org/2014/ocw/sessions/1863 ). > my suspicion is that all those SPI and MMC related configs are > also unused, just circular references keeping them unnoticed. Would you have an example? (I try to check each linux-next release with a 800 line perl monster. It's just smart enough to detect cases like this. Ie, a Kconfig entry, whose Kconfig macro isn't used anywhere in the tree, that is not selecting anything, but that itself is a _target_ of a select statement. It's not entirely trivial to detect things like that. But perhaps I could still tweak the tests of that this script to detect even more unused Kconfig symbols.) > Thanks for the heads up. You're welcome. And thanks for taking care of this. Experience shows that these cleanups go more smoothly if maintainers, actual users, etc., do them (instead of random contributors, like me, who are not familiar with the subsystem they're touching). Paul Bolle ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-10-29 9:56 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-10-29 8:20 CRISv32: ETRAX_SPI_MMC_BOARD Paul Bolle 2014-10-29 9:33 ` Jesper Nilsson 2014-10-29 9:56 ` Paul Bolle
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox