From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754037AbbLKXZ0 (ORCPT ); Fri, 11 Dec 2015 18:25:26 -0500 Received: from mail-pa0-f41.google.com ([209.85.220.41]:33580 "EHLO mail-pa0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752335AbbLKXZY (ORCPT ); Fri, 11 Dec 2015 18:25:24 -0500 Date: Fri, 11 Dec 2015 15:25:21 -0800 From: Brian Norris To: Frans Klaver Cc: Heiko Schocher , David Woodhouse , Boris BREZILLON , Pekon Gupta , Roger Quadros , Nicholas Mc Guire , linux-mtd@lists.infradead.org, "linux-kernel@vger.kernel.org" , Stefano Babic , "Stahl Martin (Helbling Technik)" Subject: Re: mtd, nand, omap2: parse cmdline partition fail Message-ID: <20151211232521.GA130567@google.com> References: <56613747.8040907@denx.de> <566151DE.9070706@denx.de> <20151209231901.GA64855@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 10, 2015 at 08:13:15AM +0100, Frans Klaver wrote: > On Thu, Dec 10, 2015 at 12:19 AM, Brian Norris > 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