linux-kernel - Re: [PATCH v5 00/11] Add simple NVMEM Framework via regmap.

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]

Date:	Tue, 26 May 2015 10:12:31 +0100
From:	Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
To:	Pantelis Antoniou <pantelis.antoniou@...sulko.com>
CC:	linux-arm-kernel@...ts.infradead.org,
	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	Rob Herring <robh+dt@...nel.org>,
	Kumar Gala <galak@...eaurora.org>,
	Mark Brown <broonie@...nel.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-api@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	devicetree <devicetree@...r.kernel.org>,
	linux-arm-msm@...r.kernel.org, Arnd Bergmann <arnd@...db.de>,
	sboyd@...eaurora.org, Matt Porter <mporter@...sulko.com>
Subject: Re: [PATCH v5 00/11] Add simple NVMEM Framework via regmap.

Hi Pantelis,

On 25/05/15 17:51, Pantelis Antoniou wrote:
> Hi Srinivas,
>
>> On May 21, 2015, at 19:42 , Srinivas Kandagatla <srinivas.kandagatla@...aro.org> 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.

>
> 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?

>
> 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
>
>> --
>> 1.9.1
>>
>
> Regards
>
> — Pantelis
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/