linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Brian Norris <computersforpeace@gmail.com>
To: Frans Klaver <fransklaver@gmail.com>
Cc: Heiko Schocher <hs@denx.de>,
	David Woodhouse <dwmw2@infradead.org>,
	Boris BREZILLON <boris.brezillon@free-electrons.com>,
	Pekon Gupta <pekon@pek-sem.com>, Roger Quadros <rogerq@ti.com>,
	Nicholas Mc Guire <hofrat@osadl.org>,
	linux-mtd@lists.infradead.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Babic <sbabic@denx.de>,
	"Stahl Martin (Helbling Technik)" <Martin.Stahl@helbling.ch>
Subject: Re: mtd, nand, omap2: parse cmdline partition fail
Date: Fri, 11 Dec 2015 15:25:21 -0800	[thread overview]
Message-ID: <20151211232521.GA130567@google.com> (raw)
In-Reply-To: <CAH6sp9OqYt76FGbOWKxSovvbx8+TjGCKbAvy-V7t5N6FDuO3pQ@mail.gmail.com>

On Thu, Dec 10, 2015 at 08:13:15AM +0100, Frans Klaver wrote:
> On Thu, Dec 10, 2015 at 12:19 AM, Brian Norris
> <computersforpeace@gmail.com> wrote:
> > On Fri, Dec 04, 2015 at 09:42:06AM +0100, Heiko Schocher wrote:
> >> >>But wondering, if there are two or more identical nand chips in the
> >> >>system, they will have the same mtd->name ... which seems buggy to me...
> >> >
> >> >Agree.
> >>
> >> Good, so we must fix it ;-)
> >
> > Yeah, that's a bad problem. Most people only plan for one chip and then
> > realize they need 2 later. nand_base should probably support something
> > to do this easily. Unfortunately, making a change like that could cause
> > some problems with cmdline naming across kernel versions, if we start
> > changing the convention for some drivers...(do we consider the MTD name
> > part of the ABI?)
> 
> I would expect a name to be just a name; something parsable by humans.
> By definition that cannot be an ABI. On the other hand, maybe it has
> grown to become part of the ABI.

So far, we've tried not to break it if possible. Perhaps if we come up
with a better solution for automatically naming/numbering chips attached
to the same device/controller, we can test out whether it hurts to
change.

> > diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> > index 89d811e7b04a..185dc36c687f 100644
> > --- a/drivers/mtd/mtdcore.c
> > +++ b/drivers/mtd/mtdcore.c
> > @@ -592,6 +592,15 @@ int mtd_device_parse_register(struct mtd_info *mtd, const char * const *types,
> >         struct mtd_partitions parsed;
> >         int ret;
> >
> > +       if (mtd->dev.parent) {
> > +               if (!mtd->owner && mtd->dev.parent->driver)
> > +                       mtd->owner = mtd->dev.parent->driver->owner;
> > +               if (!mtd->name)
> > +                       mtd->name = dev_name(mtd->dev.parent);
> > +       } else {
> > +               pr_debug("mtd device won't show a device symlink in sysfs\n");
> > +       }
> > +
> >         memset(&parsed, 0, sizeof(parsed));
> >
> >         ret = parse_mtd_partitions(mtd, types, &parsed, parser_data);
> 
> This was the first thing I thought of when this issue was brought up.
> If you do this, do you still need the chunk of code you copied from in
> add_mtd_device()? Since we fill in these things on the master, I
> wouldn't think we do.

I guess we don't need the code in add_mtd_device().

I'll send a patch against linux-mtd.git shortly (essentially 4.4-rc1).

Brian

      reply	other threads:[~2015-12-11 23:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-04  6:48 mtd, nand, omap2: parse cmdline partition fail Heiko Schocher
2015-12-04  7:17 ` Frans Klaver
2015-12-04  8:42   ` Heiko Schocher
2015-12-09 23:19     ` Brian Norris
2015-12-10  7:13       ` Frans Klaver
2015-12-11 23:25         ` Brian Norris [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=20151211232521.GA130567@google.com \
    --to=computersforpeace@gmail.com \
    --cc=Martin.Stahl@helbling.ch \
    --cc=boris.brezillon@free-electrons.com \
    --cc=dwmw2@infradead.org \
    --cc=fransklaver@gmail.com \
    --cc=hofrat@osadl.org \
    --cc=hs@denx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=pekon@pek-sem.com \
    --cc=rogerq@ti.com \
    --cc=sbabic@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;
as well as URLs for NNTP newsgroup(s).