From: Mark Brown <broonie@kernel.org>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: kernel test robot <lkp@intel.com>,
llvm@lists.linux.dev, kbuild-all@lists.01.org,
linux-kernel@vger.kernel.org
Subject: Re: [mtd:spi-mem-ecc 30/30] ld.lld: error: undefined symbol: nand_ecc_unregister_on_host_hw_engine
Date: Wed, 2 Feb 2022 18:04:35 +0000 [thread overview]
Message-ID: <YfrHs81VGzUggPC6@sirena.org.uk> (raw)
In-Reply-To: <20220202183500.7e4ef7cb@xps13>
[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]
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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2022-02-02 18:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-01 5:28 [mtd:spi-mem-ecc 30/30] ld.lld: error: undefined symbol: nand_ecc_unregister_on_host_hw_engine kernel test robot
2022-02-02 14:45 ` Miquel Raynal
2022-02-02 15:20 ` Mark Brown
2022-02-02 15:34 ` Miquel Raynal
2022-02-02 16:15 ` Mark Brown
2022-02-02 17:35 ` Miquel Raynal
2022-02-02 18:04 ` Mark Brown [this message]
2022-02-02 21:31 ` Miquel Raynal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YfrHs81VGzUggPC6@sirena.org.uk \
--to=broonie@kernel.org \
--cc=kbuild-all@lists.01.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=llvm@lists.linux.dev \
--cc=miquel.raynal@bootlin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox