* 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