All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Ricardo Ribalda Delgado <ribalda@kernel.org>
Cc: Vignesh Raghavendra <vigneshr@ti.com>,
	Tudor Ambarus <tudor.ambarus@microchip.com>,
	Richard Weinberger <richard@nod.at>,
	LKML <linux-kernel@vger.kernel.org>,
	Boris Brezillon <boris.brezillon@collabora.com>,
	linux-mtd@lists.infradead.org
Subject: Re: [PATCH v2] mtd: Fix mtd not the same name not registered if nvmem
Date: Mon, 27 Apr 2020 16:22:22 +0200	[thread overview]
Message-ID: <20200427162222.1c2b2c85@xps13> (raw)
In-Reply-To: <CAPybu_34nSmbu4JMK-uA3SWrj_eMUftZ8S6zf1Vpg3Etkz3SPw@mail.gmail.com>

Hi Ricardo,

Ricardo Ribalda Delgado <ribalda@kernel.org> wrote on Tue, 14 Apr 2020
15:47:23 +0200:

> Ping?
> 
> On Thu, Apr 2, 2020 at 8:59 AM Ricardo Ribalda Delgado
> <ribalda@kernel.org> wrote:
> >
> > When the nvmem framework is enabled, a nvmem device is created per mtd
> > device/partition.
> >
> > It is not uncommon that a device can have multiple mtd devices with
> > partitions that have the same name. Eg, when there DT overlay is allowed
> > and the same device with mtd is attached twice.
> >
> > Under that circumstances, the mtd fails to register due to a name
> > duplication on the nvmem framework.
> >
> > With this patch we add a _1, _2, _X to the subsequent names if there is
> > a collition, and throw a warning, instead of not starting the mtd
> > device.
> >
> > [    8.948991] sysfs: cannot create duplicate filename '/bus/nvmem/devices/Production Data'
> > [    8.948992] CPU: 7 PID: 246 Comm: systemd-udevd Not tainted 5.5.0-qtec-standard #13
> > [    8.948993] Hardware name: AMD Dibbler/Dibbler, BIOS 05.22.04.0019 10/26/2019
> > [    8.948994] Call Trace:
> > [    8.948996]  dump_stack+0x50/0x70
> > [    8.948998]  sysfs_warn_dup.cold+0x17/0x2d
> > [    8.949000]  sysfs_do_create_link_sd.isra.0+0xc2/0xd0
> > [    8.949002]  bus_add_device+0x74/0x140
> > [    8.949004]  device_add+0x34b/0x850
> > [    8.949006]  nvmem_register.part.0+0x1bf/0x640
> > ...
> > [    8.948926] mtd mtd8: Failed to register NVMEM device
> >
> > Signed-off-by: Ricardo Ribalda Delgado <ribalda@kernel.org>

Thanks for proposing this change. Indeed we are aware of the problem
and the best solution that we could come up with was to create an
additional "unique_name" field to the mtd_info structure. This new
field would have the form:

    [<parent-unique-name><separator>]<mtd-name>

The separator might be '~' (but I am completely open on that), and that
would give for instance:

    my-controller~my-device~my-part~mysub-part

Then, you might use this mtd->unique_name instead of mtd->name. Would
you give this logic a try?

Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Ricardo Ribalda Delgado <ribalda@kernel.org>
Cc: Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	linux-mtd@lists.infradead.org,
	LKML <linux-kernel@vger.kernel.org>,
	Boris Brezillon <boris.brezillon@collabora.com>,
	Tudor Ambarus <tudor.ambarus@microchip.com>
Subject: Re: [PATCH v2] mtd: Fix mtd not the same name not registered if nvmem
Date: Mon, 27 Apr 2020 16:22:22 +0200	[thread overview]
Message-ID: <20200427162222.1c2b2c85@xps13> (raw)
In-Reply-To: <CAPybu_34nSmbu4JMK-uA3SWrj_eMUftZ8S6zf1Vpg3Etkz3SPw@mail.gmail.com>

Hi Ricardo,

Ricardo Ribalda Delgado <ribalda@kernel.org> wrote on Tue, 14 Apr 2020
15:47:23 +0200:

> Ping?
> 
> On Thu, Apr 2, 2020 at 8:59 AM Ricardo Ribalda Delgado
> <ribalda@kernel.org> wrote:
> >
> > When the nvmem framework is enabled, a nvmem device is created per mtd
> > device/partition.
> >
> > It is not uncommon that a device can have multiple mtd devices with
> > partitions that have the same name. Eg, when there DT overlay is allowed
> > and the same device with mtd is attached twice.
> >
> > Under that circumstances, the mtd fails to register due to a name
> > duplication on the nvmem framework.
> >
> > With this patch we add a _1, _2, _X to the subsequent names if there is
> > a collition, and throw a warning, instead of not starting the mtd
> > device.
> >
> > [    8.948991] sysfs: cannot create duplicate filename '/bus/nvmem/devices/Production Data'
> > [    8.948992] CPU: 7 PID: 246 Comm: systemd-udevd Not tainted 5.5.0-qtec-standard #13
> > [    8.948993] Hardware name: AMD Dibbler/Dibbler, BIOS 05.22.04.0019 10/26/2019
> > [    8.948994] Call Trace:
> > [    8.948996]  dump_stack+0x50/0x70
> > [    8.948998]  sysfs_warn_dup.cold+0x17/0x2d
> > [    8.949000]  sysfs_do_create_link_sd.isra.0+0xc2/0xd0
> > [    8.949002]  bus_add_device+0x74/0x140
> > [    8.949004]  device_add+0x34b/0x850
> > [    8.949006]  nvmem_register.part.0+0x1bf/0x640
> > ...
> > [    8.948926] mtd mtd8: Failed to register NVMEM device
> >
> > Signed-off-by: Ricardo Ribalda Delgado <ribalda@kernel.org>

Thanks for proposing this change. Indeed we are aware of the problem
and the best solution that we could come up with was to create an
additional "unique_name" field to the mtd_info structure. This new
field would have the form:

    [<parent-unique-name><separator>]<mtd-name>

The separator might be '~' (but I am completely open on that), and that
would give for instance:

    my-controller~my-device~my-part~mysub-part

Then, you might use this mtd->unique_name instead of mtd->name. Would
you give this logic a try?

Thanks,
Miquèl

  reply	other threads:[~2020-04-27 14:22 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-01 10:02 [PATCH] mtd: Fix mtd not the same name not registered if nvmem Ricardo Ribalda Delgado
2020-04-01 10:02 ` Ricardo Ribalda Delgado
2020-04-02  6:59 ` [PATCH v2] " Ricardo Ribalda Delgado
2020-04-02  6:59   ` Ricardo Ribalda Delgado
2020-04-14 13:47   ` Ricardo Ribalda Delgado
2020-04-14 13:47     ` Ricardo Ribalda Delgado
2020-04-27 14:22     ` Miquel Raynal [this message]
2020-04-27 14:22       ` Miquel Raynal
2020-04-27 14:37       ` Boris Brezillon
2020-04-27 14:37         ` Boris Brezillon
2020-04-27 14:49         ` Miquel Raynal
2020-04-27 14:49           ` Miquel Raynal
2020-04-27 19:10           ` Boris Brezillon
2020-04-27 19:10             ` Boris Brezillon
2020-04-30 12:26             ` Ricardo Ribalda Delgado
2020-04-30 12:26               ` Ricardo Ribalda Delgado
2020-04-30 12:52               ` Boris Brezillon
2020-04-30 12:52                 ` Boris Brezillon

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=20200427162222.1c2b2c85@xps13 \
    --to=miquel.raynal@bootlin.com \
    --cc=boris.brezillon@collabora.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=ribalda@kernel.org \
    --cc=richard@nod.at \
    --cc=tudor.ambarus@microchip.com \
    --cc=vigneshr@ti.com \
    /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.