linux-kernel - Re: [mtd:spi-mem-ecc 30/30] ld.lld: error: undefined symbol: nand_ecc_unregister_on_host_hw

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 2 Feb 2022 22:31:49 +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 18:04:35 +0000:

> On Wed, Feb 02, 2022 at 06:35:00PM +0100, Miquel Raynal wrote:
> 
> > > 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 ?  
> 
> It doesn't specifically need MTD to be a module so just a straight
> dependency should be fine I guess.
> 
> > 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.  
> 
> Is that something that people actually do - does this controller get
> used without the MTD functionality?  Most of these controllers seem to
> be really bad generic SPI controllers that would rarely get used for
> anything other than MTD devices, if this one is a useful generic
> controller your approach makes more sense although I do worry about
> people getting noticably worse performance if they don't build MTD in.

This one in particular really is a SPI controller, and can really be
used without MTD at all. I don't know how good are the performances
with it but it is sure that there is no performance hit when the MTD
stack is not pulled in.

Also, for the example I mentioned CONFIG_MTD but in fact I simplified a
bit the situation as this driver is actually implying
CONFIG_MTD_NAND_ECC which selects CONFIG_MTD_NAND_CORE.

CONFIG_MTD_NAND_CORE is a subset of MTD. Building this subset
really is not needed when playing with eg. a SPI-NOR. And even with a
SPI-NAND which would require CONFIG_MTD_NAND_CORE anyway, it would not
be necessarily to have CONFIG_MTD_NAND_ECC enabled because most NANDs
have on-die support for it and thus do not need extra code to handle
bitflips.

That is the reason why I felt a bit puzzled in the first place by the
need to pull all MTD in a build which would select this SPI controller
driver.

Thanks,
Miquèl