Hi Pantelis,

On 25/05/15 17:51, Pantelis Antoniou wrote:

Hi Srinivas,

quoted

On May 21, 2015, at 19:42 , Srinivas Kandagatla [off-list ref] wrote:

Thankyou all for providing inputs and comments on previous versions of this patchset.
Here is the v5 of the patchset addressing all the issues raised as
part of previous versions review.

quoted

[snip]

I tried to use the updated patchset with my at24 & beaglebone capemanager patches.

Thanks for trying it out and migrating at24 to it.

I have a big problem with the removal of the raw of_* access APIs.

Ok,

Take for instance the case where you have multiple slot accessing different EEPROMs.

quoted

slots {
	slot at 0 {
		eeprom = <&cape0_data>;
	};

	slot at 1 {
		eeprom = <&cape1_data>;
	};
};

Can I ask you why should the slots be in sub-nodes?
Do you expect to have more properties associated with each slot in future?
Or is it just to get hold of eeprom data?

In that case there is no per-device node mapping; it?s a per-sub node.

For now I?m exporting the of_* accessors again, please consider exposing the of_* API again.

Sure, we can export of_nvmem_cell_get symbol for usecases like this.

Having said that, I got one comment on the way the nvmem is used in your 
case. You should try to use nvmem_device_get() and then use 
nvmem_device_read() apis, These apis are for consumers like this one. 
The advantage of this would be you do not need read and store all data 
in the driver and parse them internally. Basically your ee_field_get 
would just do nvmem_device_read(); Does it make sense?

We can work on how to get the of_*based once you decide to move to this api.



--srini

quoted

--
1.9.1

Regards

? Pantelis