All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.