[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 2 Feb 2022 18:35:00 +0100
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Mark Brown <broonie@...nel.org>
Cc: kernel test robot <lkp@...el.com>, llvm@...ts.linux.dev,
kbuild-all@...ts.01.org, linux-kernel@...r.kernel.org
Subject: Re: [mtd:spi-mem-ecc 30/30] ld.lld: error: undefined symbol:
nand_ecc_unregister_on_host_hw_engine
Hi Mark,
broonie@...nel.org wrote on Wed, 2 Feb 2022 16:15:35 +0000:
> On Wed, Feb 02, 2022 at 04:34:52PM +0100, Miquel Raynal wrote:
> > > On Wed, Feb 02, 2022 at 03:45:04PM +0100, Miquel Raynal wrote:
>
> > > > I've failed to prevent faulty configurations with regular depends
> > > > on/select keywords, so I've come with a new solution which received a
> > > > successful build coverage test from the 0-day robots.
>
> > > > In order to still be able to use the spi controller driver (=y) while
> > > > mtd is =m or =n, I need to add an IS_REACHABLE() check in a couple of
> > > > headers. This way we can just imply the right MTD symbols from the
> > > > SPI_MXIC Kconfig entry.
>
> > > Isn't this just a case where we shouldn't allow MTD to be built modular?
>
> > How would you do that in a nice Kconfig way?
>
> depends on MTD=y if SPI_MXC=y
In this case I believe we should also add
depends on MTD=m if SPI_MXC=m ?
Anyway, this would force building the ECC support (and MTD...) even
though we don't need it in most cases.
My idea was to give people the right to only select SPI_MXIC without
really caring about MTD/ECC support at all because this is IMHO a
valid use case. We would then save a few kiB of extra MTD fat.
What do you think?
Thanks,
Miquèl
Powered by blists - more mailing lists