lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190708071419.eqhajizbipt24xl3@pengutronix.de>
Date:   Mon, 8 Jul 2019 09:14:19 +0200
From:   Sascha Hauer <s.hauer@...gutronix.de>
To:     Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
Cc:     linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org,
        kernel@...gutronix.de
Subject: Re: nvmem creates multiple devices with the same name

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 |

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ