Re: CRISv32: ETRAX_SPI_MMC_BOARD

[Paul Bolle]

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@xxxxxxxxxx>
> Signed-off-by: Jesper Nilsson <jesper.nilsson@xxxxxxxx>
> ---
>  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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/