Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp2946275ybz; Mon, 27 Apr 2020 07:24:31 -0700 (PDT) X-Google-Smtp-Source: APiQypI7Gv4Md4DlYmzuDJEGFsAnUg1o+DmylKtbYFCxAOpSXlhqANviWmPIkfsAV+l5CR8MgaKZ X-Received: by 2002:a17:907:2069:: with SMTP id qp9mr20620316ejb.137.1587997471484; Mon, 27 Apr 2020 07:24:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587997471; cv=none; d=google.com; s=arc-20160816; b=ZiYxTwx/rz/kMpJ4t2WE5EoIywHeoUo5hhkZL9kMCxad9INGDU7DTbX0aYJWoSartl FjrX5rhfG2BvL9HdTgB3g9e8h2ZuNxTkax3h19ekSQ8S0WqC4xcmUOiv4H00QJyCjper 0lWHR46mFoANZVaps6MzB7qiJIIoZa/SW3iPffbsvvOt9Q0Sx91LT06XvMS1uhHI+j5B 56d5rx3Uq5cLIiUPN7IT2FA8FL2v0TXgEncWhXSROpXkX2ZI7mXV0xWosMhi6zPVaSKn Nm5srerdj5FS59nJnFXu3tG++gnwdguB6xQNHyLQobOqetXMXP7/EkxkUU27pUfTfS8m S9uA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=pCk3vA1GdZauLA1ZBu+eWBhpCTuvvBbruIF0wtMn0bU=; b=gjdDTXjjyvlZPDB5Kw4aBvm+4d3kc4ITUlZTtuBQ+BR+RTuLKfhK+O82ezDeEOdDkS TwLWnPgsyPOEnW8EOLh3ZKqCR91PuG+AvZIDDWvCcfS+RU7+iIenVrDVDoBlLJWuz/0j l1EKph8InZbhbzZndKh4vtG1HLbZ9ZX0i3u5QvxjzdYShscSalQqGbFKvtfGYEEEAs2n D0txtKbyaXRbRua8vvcotnOYNbZ6gHqa55o8Rf0hsheq0hPaxuW76KxJlDNAQrzA9ZlB KDtcYXOzE74D2x7bZwmCT4mPXiDUMWzASyLSeZ+WF1xUhUtadbQ4cNChZxWzKGFzpktc XlPA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cb14si8202791edb.529.2020.04.27.07.24.08; Mon, 27 Apr 2020 07:24:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727992AbgD0OWc convert rfc822-to-8bit (ORCPT + 99 others); Mon, 27 Apr 2020 10:22:32 -0400 Received: from relay9-d.mail.gandi.net ([217.70.183.199]:49261 "EHLO relay9-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727073AbgD0OWc (ORCPT ); Mon, 27 Apr 2020 10:22:32 -0400 X-Originating-IP: 91.224.148.103 Received: from xps13 (unknown [91.224.148.103]) (Authenticated sender: miquel.raynal@bootlin.com) by relay9-d.mail.gandi.net (Postfix) with ESMTPSA id AB04AFF810; Mon, 27 Apr 2020 14:22:23 +0000 (UTC) Date: Mon, 27 Apr 2020 16:22:22 +0200 From: Miquel Raynal To: Ricardo Ribalda Delgado Cc: Richard Weinberger , Vignesh Raghavendra , linux-mtd@lists.infradead.org, LKML , Boris Brezillon , Tudor Ambarus Subject: Re: [PATCH v2] mtd: Fix mtd not the same name not registered if nvmem Message-ID: <20200427162222.1c2b2c85@xps13> In-Reply-To: References: <20200401100240.445447-1-ribalda@kernel.org> <20200402065953.9974-1-ribalda@kernel.org> Organization: Bootlin X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Ricardo, Ricardo Ribalda Delgado wrote on Tue, 14 Apr 2020 15:47:23 +0200: > Ping? > > On Thu, Apr 2, 2020 at 8:59 AM Ricardo Ribalda Delgado > 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 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: [] 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