Hi Srinivas,
> On May 26, 2015, at 12:12 , Srinivas Kandagatla <srinivas.kandagatla@xxxxxxxxxx> wrote:
>
> Hi Pantelis,
>
> On 25/05/15 17:51, Pantelis Antoniou wrote:
>> Hi Srinivas,
>>
>>> On May 21, 2015, at 19:42 , Srinivas Kandagatla <srinivas.kandagatla@xxxxxxxxxx> 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.
>>>
>>
>>>
>>
>> [snip]
>>
>> I tried to use the updated patchset with my at24 & beaglebone capemanager patches.
> Thanks for trying it out and migrating at24 to it.
>
Don’t mention 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.
>>
>>> slots {
>>> slot@0 {
>>> eeprom = <&cape0_data>;
>>> };
>>>
>>> slot@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?
>
For now I don’t have any more properties besides the eeprom phandle.
I’ve reworked capemanager to work with the API as it is, but it’s not very intuitive IMHO.
The problem is that I have both the baseboard and the slot eeproms in a single property list.
If more per-slot properties are required, I’ll have to add again the slots node and
then the nvmem eeprom handles would stick out like a sore thumb.
>>
>> 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?
>
Hmm, good idea; I’ll give it a shot.
> We can work on how to get the of_*based once you decide to move to this api.
>
>
OK, thanks a lot for taking the time to think about this Srinivas.
>
> --srini
>>
Regards
— Pantelis
>>> --
>>> 1.9.1
>>>
>>
>> Regards
>>
>> — Pantelis
>>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
