netdev - Re: [PATCH v2 01/29] nvmem: add support for cell lookups

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <8cb75723-dc87-f127-2aab-54dd0b08eee8@linaro.org>
Date:   Tue, 28 Aug 2018 11:15:12 +0100
From:   Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
To:     Bartosz Golaszewski <brgl@...ev.pl>,
        Boris Brezillon <boris.brezillon@...tlin.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        linux-doc <linux-doc@...r.kernel.org>,
        Sekhar Nori <nsekhar@...com>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        linux-i2c <linux-i2c@...r.kernel.org>,
        Mauro Carvalho Chehab <mchehab+samsung@...nel.org>,
        Rob Herring <robh@...nel.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        Kevin Hilman <khilman@...nel.org>,
        Richard Weinberger <richard@....at>,
        Russell King <linux@...linux.org.uk>,
        Marek Vasut <marek.vasut@...il.com>,
        Paolo Abeni <pabeni@...hat.com>,
        Dan Carpenter <dan.carpenter@...cle.com>,
        Grygorii Strashko <grygorii.strashko@...com>,
        David Lechner <david@...hnology.com>,
        Arnd Bergmann <arnd@...db.de>,
        Sven Van Asbroeck <svendev@...x.com>,
        "open list:MEMORY TECHNOLOGY..." <linux-mtd@...ts.infradead.org>,
        Linux-OMAP <linux-omap@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Ivan Khoronzhuk <ivan.khoronzhuk@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jonathan Corbet <corbet@....net>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Lukas Wunner <lukas@...ner.de>, Naren <naren.kernel@...il.com>,
        netdev <netdev@...r.kernel.org>, Alban Bedel <albeu@...e.fr>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Brian Norris <computersforpeace@...il.com>,
        David Woodhouse <dwmw2@...radead.org>,
        "David S . Miller" <davem@...emloft.net>
Subject: Re: [PATCH v2 01/29] nvmem: add support for cell lookups


On 27/08/18 14:37, Bartosz Golaszewski wrote:
> I didn't notice it before but there's a global list of nvmem cells

Bit of history here.

The global list of nvmem_cell is to assist non device tree based cell 
lookups. These cell entries come as part of the non-dt providers 
nvmem_config.

All the device tree based cell lookup happen dynamically on 
request/demand, and all the cell definition comes from DT.

As of today NVMEM supports both DT and non DT usecase, this is much simpler.

Non dt cases have various consumer usecases.

1> Consumer is aware of provider name and cell details.
	This is probably simple usecase where it can just use device based apis.

2> Consumer is not aware of provider name, its just aware of cell name.
	This is the case where global list of cells are used.

> with each cell referencing its owner nvmem device. I'm wondering if
> this isn't some kind of inversion of ownership. Shouldn't each nvmem
> device have a separate list of nvmem cells owned by it? What happens
This is mainly done for use case where consumer does not have idea of 
provider name or any details.

First thing non dt user should do is use "NVMEM device based consumer APIs"

ex: First get handle to nvmem device using its nvmem provider name by 
calling nvmem_device_get(); and use nvmem_device_cell_read/write() apis.

Also am not 100% sure how would maintaining cells list per nvmem 
provider would help for the intended purpose of global list?

> if we have two nvmem providers with the same names for cells? I'm
Yes, it would return the first instance.. which is a known issue.
Am not really sure this is a big problem as of today! but am open for 
any better suggestions!


> asking because dev_id based lookup doesn't make sense if internally
> nvmem_cell_get_from_list() doesn't care about any device names (takes
> only the cell_id as argument).

As I said this is for non DT usecase where consumers are not aware of 
provider details.

> 
> This doesn't cause any trouble now since there are no users defining
> cells in nvmem_config - there are only DT users - but this must be
> clarified before I can advance with correctly implementing nvmem
> lookups.
DT users should not be defining this to start with! It's redundant and 
does not make sense!

> 
> BTW: of_nvmem_cell_get() seems to always allocate an nvmem_cell
> instance even if the cell for this node was already added to the nvmem
> device.
I hope you got the reason why of_nvmem_cell_get() always allocates new 
instance for every get!!

thanks,
srini