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@xxxxxxxx> 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
