Hi Marco,
m.felsch@xxxxxxxxxxxxxx wrote on Wed, 22 Nov 2023 23:02:40 +0100:
> Hi Miquel,
>
> thanks a lot for your effort on this. Please see my comments inline.
Thanks for your interesting feedback! I do agree with most of your
comments and will correct them for the next version.
> > +static int onie_tlv_probe(struct nvmem_layout *layout)
> > +{
> > + layout->add_cells = onie_tlv_parse_table;
>
> Nit: the add cells could be done here as well, same for the other
> layout. Would save us one indirection.
I prefer all the handling of the cells to be done in a generic place
like the core. In fact patch 5 adds something to this indirection.
...
> > /**
> > * struct nvmem_layout - NVMEM layout definitions
> > *
> > - * @name: Layout name.
> > - * @of_match_table: Open firmware match table.
> > + * @dev: Device-model layout device.
> > + * @nvmem: The underlying NVMEM device
> > * @add_cells: Will be called if a nvmem device is found which
> > * has this layout. The function will add layout
> > * specific cells with nvmem_add_one_cell().
> > * @fixup_cell_info: Will be called before a cell is added. Can be
> > * used to modify the nvmem_cell_info.
> > - * @owner: Pointer to struct module.
> > - * @node: List node.
> > *
> > * A nvmem device can hold a well defined structure which can just be
> > * evaluated during runtime. For example a TLV list, or a list of "name=val"
> > @@ -170,17 +169,19 @@ struct nvmem_cell_table {
> > * cells.
> > */
> > struct nvmem_layout {
>
> Since this became a device now should we refelct this within the struct
> name, e.g. nvmem_layout_dev, nvmem_ldev, nvm_ldev?
I'd say it is a matter of taste, in general I don't like much the _dev
suffix. We handle nvmem layout drivers and nvmem layouts, like we
have joystick drivers and joysticks, I don't feel the need to suffix
them. I would not oppose if someone would rename this structure though.
> Regards,
> Marco
>
I'm fine with all your other comments and will make my best to address
them.
Thanks,
Miquèl
