linux-kernel - 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: <20180824152740.GD27483@lunn.ch>
Date:   Fri, 24 Aug 2018 17:27:40 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Boris Brezillon <boris.brezillon@...tlin.com>
Cc:     Bartosz Golaszewski <brgl@...ev.pl>,
        Jonathan Corbet <corbet@....net>, Sekhar Nori <nsekhar@...com>,
        Kevin Hilman <khilman@...nel.org>,
        Russell King <linux@...linux.org.uk>,
        Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        David Woodhouse <dwmw2@...radead.org>,
        Brian Norris <computersforpeace@...il.com>,
        Marek Vasut <marek.vasut@...il.com>,
        Richard Weinberger <richard@....at>,
        Grygorii Strashko <grygorii.strashko@...com>,
        "David S . Miller" <davem@...emloft.net>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Naren <naren.kernel@...il.com>,
        Mauro Carvalho Chehab <mchehab+samsung@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Lukas Wunner <lukas@...ner.de>,
        Dan Carpenter <dan.carpenter@...cle.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Ivan Khoronzhuk <ivan.khoronzhuk@...aro.org>,
        Sven Van Asbroeck <svendev@...x.com>,
        Paolo Abeni <pabeni@...hat.com>, Alban Bedel <albeu@...e.fr>,
        Rob Herring <robh@...nel.org>,
        David Lechner <david@...hnology.com>,
        linux-doc@...r.kernel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        linux-mtd@...ts.infradead.org, linux-i2c@...r.kernel.org,
        linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 01/29] nvmem: add support for cell lookups

On Fri, Aug 24, 2018 at 05:08:48PM +0200, Boris Brezillon wrote:
> Hi Bartosz,
> 
> On Fri, 10 Aug 2018 10:04:58 +0200
> Bartosz Golaszewski <brgl@...ev.pl> wrote:
> 
> > +struct nvmem_cell_lookup {
> > +	struct nvmem_cell_info	info;
> > +	struct list_head	list;
> > +	const char		*nvmem_name;
> > +};
> 
> Hm, maybe I don't get it right, but this looks suspicious. Usually the
> consumer lookup table is here to attach device specific names to
> external resources.
> 
> So what I'd expect here is:
> 
> struct nvmem_cell_lookup {
> 	/* The nvmem device name. */
> 	const char *nvmem_name;
> 
> 	/* The nvmem cell name */
> 	const char *nvmem_cell_name;
> 
> 	/*
> 	 * The local resource name. Basically what you have in the
> 	 * nvmem-cell-names prop.
> 	 */
> 	const char *conid;
> };
> 
> struct nvmem_cell_lookup_table {
> 	struct list_head list;
> 
> 	/* ID of the consumer device. */
> 	const char *devid;
> 
> 	/* Array of cell lookup entries. */
> 	unsigned int ncells;
> 	const struct nvmem_cell_lookup *cells;
> };
> 
> Looks like your nvmem_cell_lookup is more something used to attach cells
> to an nvmem device, which is NVMEM provider's responsibility not the
> consumer one.

Hi Boris

There are cases where there is not a clear providier/consumer split. I
have an x86 platform, with a few at24 EEPROMs on it. It uses an off
the shelf Komtron module, placed on a custom carrier board. One of the
EEPROMs contains the hardware variant information. Once i know the
variant, i need to instantiate other I2C, SPI, MDIO devices, all using
platform devices, since this is x86, no DT available.

So the first thing my x86 platform device does is instantiate the
first i2c device for the AT24. Once the EEPROM pops into existence, i
need to add nvmem cells onto it. So at that point, the x86 platform
driver is playing the provider role. Once the cells are added, i can
then use nvmem consumer interfaces to get the contents of the cell,
run a checksum, and instantiate the other devices.

I wish the embedded world was all DT, but the reality is that it is
not :-(

    Andrew