From: Miquel Raynal <miquel.raynal@bootlin.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] mtd: nand: let the raw NAND devices be compiled upon selection
Date: Mon, 8 Apr 2019 15:20:11 +0200 [thread overview]
Message-ID: <20190408152011.3c497d82@xps13> (raw)
In-Reply-To: <CAMty3ZBM-g2Omg+RdsEt+2_iWA25FrkanekPRKMujt78i30EUw@mail.gmail.com>
Jagan,
Jagan Teki <jagan@amarulasolutions.com> wrote on Mon, 8 Apr 2019
17:28:18 +0530:
> Hi Miquel,
>
> On Mon, Apr 8, 2019 at 3:22 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Hi Jagan,
> >
> > Miquel Raynal <miquel.raynal@bootlin.com> wrote on Mon, 29 Oct 2018
> > 10:07:28 +0100:
> >
> > > Hi Jagan,
> > >
> > > Jagan Teki <jagan@amarulasolutions.com> wrote on Tue, 23 Oct 2018
> > > 16:40:05 +0530:
> > >
> > > > On Thu, Oct 11, 2018 at 3:05 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > >
> > > > > Today way is to rely on CMD_NAND to be selected and from the root
> > > > > Makefile compile what is in drivers/mtd/nand/raw.
> > > > >
> > > > > While this will work most of the time with decent configurations, it
> > > > > is better to also compile this subsystem upon simple request in the
> > > > > configuration. Otherwise, a user not selecting CMD_NAND but selecting
> > > > > NAND and any of the controller drivers will not see their build. Fix
> > > > > this weird situation by adding a single line in the nand/ directory
> > > > > Kconfig file.
> > > > >
> > > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > > > ---
> > > > > drivers/mtd/nand/Makefile | 1 +
> > > > > 1 file changed, 1 insertion(+)
> > > > >
> > > > > diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
> > > > > index a358bc680e..2c33447995 100644
> > > > > --- a/drivers/mtd/nand/Makefile
> > > > > +++ b/drivers/mtd/nand/Makefile
> > > > > @@ -2,4 +2,5 @@
> > > > >
> > > > > nandcore-objs := core.o bbt.o
> > > > > obj-$(CONFIG_MTD_NAND_CORE) += nandcore.o
> > > > > +obj-$(CONFIG_NAND) += raw/
> > > >
> > > > But we even source raw Kconfig path, isn't it? and also how about
> > > > remove this from root Makefile?
> > >
> > > What do you mean by "we even source raw Kconfig path"? It was not
> > > sourced before this modification unless CMD_NAND was selected.
> > >
> > > I agree we should also remove this link between a path being
> > > compiled and a CMD_* symbol in the root Makefile. It will probably
> > > produce a lot of errors though. I'll try when I'll have some time.
> >
> > Yet another patch you ignored. All these are real fixes, not just some
> > kind of sandbox leisure, please consider this change.
>
> 1) Did I ignore any patches from you?
* [PATCH] mtd: nand: let the raw NAND devices be compiled upon selection
-> 11/10/2018: Sent on the ML
-> 23/10/2018-05/11/2018: you want something cleaner, I tell you I
will do it soon but for now the issue should be fixed.
-> 08/04/2019: Ping from me because the other series is still not
applied, the quick fix neither, the bug is still there.
* [PATCH v4 00/25] MTD defconfigs/Kconfigs/Makefiles heavy cleanup
-> 09/12/2018: v4 sent on the ML with all comments addressed
-> 20/02/2019: Ping from Vignesh
-> 20/02/2019: Ping from me
-> 06/03/2019: Ping from me
-> 17/03/2019: Ping from me
-> 17/03/2019: Ping from Tom
-> 19/03/2019: You answer: "Yes, it's late from my end, will have a
look at and comment asap."
-> 08/04/2019: Ping from me
* [PATCH 1/2] mtd: fix mtd_oobavail() incoherent returned value
* [PATCH 2/2] mtd: fix Coverity integer handling issue
-> 16/10/2018: Coverity issues reported by Tom privately
-> 18/11/2018: Fixes sent on the ML (both for Linux and U-Boot).
For your defense, you were not in Cc of the patches but they are
marked 'New' in Patchwork and assigned to you.
-> 03/12/2018: Fixes applied in Linux
-> 08/04/2018: Ping from me
> 2) This change I just commented before and I think the same is
> handling on your cleanup series, If I'm not wrong?
When there is a bug, the usual handling procedure is:
1/ fix the bug so that users are not bothered,
2/ if the fix is not elegant enough then a rework of the faulty
section is engaged.
History:
We discovered after applying my "SPI-NAND support (third batch)" 13th
version from the 01/10/2018 that under certain circumstances the raw
NAND core could be missing because of the game of the select/depends on
properties. It was a compile-time issue only.
Because I want the selection to be easier for the user, I fixed it
with the current patch. This is the quick fix sent the 11/10/2018
addressing situation 1/.
We agreed that it could be useful to rework the entire Makefile/Kconfig
soup in the MTD layer. So this is why I wrote on my spare time and send
the full cleanup series. This is the deepest rework sent the 29/10/2018
(v2), the 05/12/2018 (v3) and the 09/12/2018 (v4) addressing situation
2/.
Regards,
Miquèl
prev parent reply other threads:[~2019-04-08 13:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-11 9:35 [U-Boot] [PATCH] mtd: nand: let the raw NAND devices be compiled upon selection Miquel Raynal
2018-10-23 11:10 ` Jagan Teki
2018-10-29 9:07 ` Miquel Raynal
2018-11-05 5:02 ` Jagan Teki
2019-04-08 9:52 ` Miquel Raynal
2019-04-08 11:54 ` Tom Rini
2019-04-08 11:58 ` Jagan Teki
2019-04-08 13:20 ` Miquel Raynal [this message]
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=20190408152011.3c497d82@xps13 \
--to=miquel.raynal@bootlin.com \
--cc=u-boot@lists.denx.de \
/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