public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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

      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