Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp6463463ybi; Mon, 8 Jul 2019 03:28:55 -0700 (PDT) X-Google-Smtp-Source: APXvYqxqA/7ednW1pRcLZ+Tg5Q3XVTPBEBGsBAW90C0EHMM+qTfDXAiZxzLL0ksgUJRev+edvMil X-Received: by 2002:a17:90a:3344:: with SMTP id m62mr24464331pjb.135.1562581735440; Mon, 08 Jul 2019 03:28:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562581735; cv=none; d=google.com; s=arc-20160816; b=aBXK4EvxjDaZJdiBz+KrCmUfJeDmvk8c8VPlxBdU0azZ/NhdjyJ2JjiImkMSx6Mb0V IfFIEHJXyYAdARFnx+YHJezdp7kVfux0WPhW6gd8oTh7Lbe4WfE8Km5V2tf1T8cMR9j/ RN79SF3IToqz0sDwDxYXA8qSAjhBGxxUGEdt2womMiuV45GmEq3CSB2/u0HxmAHt6oso EM67TgWneahMAR6MbwGaM+NdEzgcusZm115X0sQeuoV/yOMYi2JBSIx2qbWtUkk5iKTl wKictEV5wXkFoADMzn4zK8VJkKnupPekxecqHpkFl/VPz/eYSdjmhbqSH68W2E3iYC7H iTxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=cAqSfRjYNinIWi6EpOYR98VrjFzIqAeeUelclyFjg8I=; b=MZtbGSVIukB/pO8TapHftv3CgkTEUt2S9miqZmVOjE0KAvf+oEggHzAPIgcwXS8HtM WUH6Juqf3ctikYzTnKpmHuyHXMvqJYPv1iA3wg8lyvbV5LKLZl7AkCmDYgFd/E0BcyOa Nb7Yc/Muyj4djkNUlc9vsJozKQWF4CAq2jTh7ErxuX8+YLP1Uu8cQdpqR+33d+rKQoSn GRHKUDpkD0xV/TgY198bYtudIQtAZ05NulOa0bGuG13rp2a4qSZHBzUnn7SjixxDxgD/ efnBDqZifNyx0+F8sWhxwioc7Byn4jBddlFIcHjssSeqicAyxLTPi0JCYoKPXj5vEuJc JtWQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 145si7707853pfb.262.2019.07.08.03.28.40; Mon, 08 Jul 2019 03:28:55 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728979AbfGHHOW (ORCPT + 99 others); Mon, 8 Jul 2019 03:14:22 -0400 Received: from metis.ext.pengutronix.de ([85.220.165.71]:35991 "EHLO metis.ext.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725907AbfGHHOV (ORCPT ); Mon, 8 Jul 2019 03:14:21 -0400 Received: from ptx.hi.pengutronix.de ([2001:67c:670:100:1d::c0]) by metis.ext.pengutronix.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1hkNqt-0000Xy-P7; Mon, 08 Jul 2019 09:14:19 +0200 Received: from sha by ptx.hi.pengutronix.de with local (Exim 4.89) (envelope-from ) id 1hkNqt-0001y2-4P; Mon, 08 Jul 2019 09:14:19 +0200 Date: Mon, 8 Jul 2019 09:14:19 +0200 From: Sascha Hauer To: Srinivas Kandagatla Cc: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, kernel@pengutronix.de Subject: Re: nvmem creates multiple devices with the same name Message-ID: <20190708071419.eqhajizbipt24xl3@pengutronix.de> References: <20190521085641.i6g5aijwa5zbolah@pengutronix.de> <20190521092107.zpdkkhaanzruhqui@pengutronix.de> <20190701080642.4oxmw7c3rmwrt5ee@pengutronix.de> <45d0cfaf-2511-4b1e-f4da-b67fa9f9e867@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45d0cfaf-2511-4b1e-f4da-b67fa9f9e867@linaro.org> X-Sent-From: Pengutronix Hildesheim X-URL: http://www.pengutronix.de/ X-IRC: #ptxdist @freenode X-Accept-Language: de,en X-Accept-Content-Type: text/plain X-Uptime: 09:02:28 up 13:12, 24 users, load average: 0.18, 0.32, 0.32 User-Agent: NeoMutt/20170113 (1.7.2) X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c0 X-SA-Exim-Mail-From: sha@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 02, 2019 at 05:54:54PM +0100, Srinivas Kandagatla wrote: > Hi Sascha, > > On 01/07/2019 09:06, Sascha Hauer wrote: > > Hi Srinivas, > > > > On Tue, May 21, 2019 at 11:21:07AM +0200, Sascha Hauer wrote: > > > On Tue, May 21, 2019 at 10:02:32AM +0100, Srinivas Kandagatla wrote: > > > > > > > > > > > > On 21/05/2019 09:56, Sascha Hauer wrote: > > > > > . Are there any suggestions how to register the nvmem devices > > > > > with a different name? > > > > > > > > struct nvmem_config provides id field for this purpose, this will be used by > > > > nvmem to set the device name space along with name field. > > > > > > There's no way for a caller to know a unique name/id combination. > > > The mtd layer could initialize the id field with the mtd number, but > > > that would still not guarantee that another caller, like an EEPROM > > > driver or such, doesn't use the same name/id combination. > > > > This is still an unresolved issue. Do you have any input how we could > > proceed here? > > Sorry for the delay! > I think simplest solution would be to check if there is already an nvmem > provider with the same name before assigning name to the device and then > append the id in case it exists. > > Let me know if below patch helps the situation so that I can take this in > next cycle! > > ----------------------------------->cut<---------------------------- > nvmem: core: Check nvmem device name before adding the same one > > In some usecases where nvmem names are directly derived from > partition names, its likely that different devices might have > same partition name. > This will be an issue as we will be creating two different > nvmem devices with same name and sysfs will not be very happy with that. > > Simple solution is to check the existance of the nvmem provider with > same name and append an id if it exists before creating the device name. This solution obviously works for me. I am not sure if that's really what we want as the resulting names in sysfs are not predictable in any way. In that case we might be better off using mtdx as Boris suggested. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |