Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753344AbbEZNF5 (ORCPT ); Tue, 26 May 2015 09:05:57 -0400 Received: from mail-wi0-f173.google.com ([209.85.212.173]:33830 "EHLO mail-wi0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753308AbbEZNFy (ORCPT ); Tue, 26 May 2015 09:05:54 -0400 Message-ID: <556438FF.7020105@linaro.org> Date: Tue, 26 May 2015 10:12:31 +0100 From: Srinivas Kandagatla User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Pantelis Antoniou CC: linux-arm-kernel@lists.infradead.org, Maxime Ripard , Rob Herring , Kumar Gala , Mark Brown , Sascha Hauer , Greg Kroah-Hartman , linux-api@vger.kernel.org, Linux Kernel Mailing List , devicetree , linux-arm-msm@vger.kernel.org, Arnd Bergmann , sboyd@codeaurora.org, Matt Porter Subject: Re: [PATCH v5 00/11] Add simple NVMEM Framework via regmap. References: <1427752492-17039-1-git-send-email-srinivas.kandagatla@linaro.org> <1432226535-8640-1-git-send-email-srinivas.kandagatla@linaro.org> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2012 Lines: 71 Hi Pantelis, On 25/05/15 17:51, Pantelis Antoniou wrote: > Hi Srinivas, > >> On May 21, 2015, at 19:42 , Srinivas Kandagatla 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/