From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935816AbcCQL0g (ORCPT ); Thu, 17 Mar 2016 07:26:36 -0400 Received: from mail-wm0-f48.google.com ([74.125.82.48]:33730 "EHLO mail-wm0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935295AbcCQL0b (ORCPT ); Thu, 17 Mar 2016 07:26:31 -0400 Subject: Re: [RESEND RFC 3/3] nvmem: Add 'nvmem-composite' driver To: Andrey Smirnov References: <1456851552-15913-1-git-send-email-andrew.smirnov@gmail.com> <1456851552-15913-4-git-send-email-andrew.smirnov@gmail.com> <56D6F1CA.6020302@linaro.org> Cc: linux-kernel@vger.kernel.org, maxime.ripard@free-electrons.com, Sascha Hauer , Trent Piepho From: Srinivas Kandagatla Message-ID: <56EA9464.4030107@linaro.org> Date: Thu, 17 Mar 2016 11:26:28 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/03/16 18:33, Andrey Smirnov wrote: > On Wed, Mar 2, 2016 at 5:59 AM, Srinivas Kandagatla > wrote: >> >> On 01/03/16 16:59, Andrey Smirnov wrote: >>> >>> Add 'nvmem-composite' driver which allows to combine multiple chunks of >>> various NVMEM cells into a single continuous NVMEM device. >> >> >> My plan on this feature was add support inside the nvmem_cell_get itself, >> this makes the nvmem bindings more inline with bindings like pinctrl. >> Also I still want to keep nvmem simple as it can. > > That's perfectly fine with me, I can change my patch to do that. My > thinking on implementing it as a standalone module was that this seems > to be a very niche functionality which not a lot of people would use, > so the code would be a part of your kernel only if you directly use > this feature. > >> >> DT would look something like this. >> >> nvmem-provider-a { >> cell_a { >> reg = <0 2>; >> }; >> }; >> >> nvmem-provider-b { >> cell_b: cell_c { >> reg = <0 1>; >> }; >> }; >> >> nvmem-provider-c { >> cell_c: cell_c { >> reg = <3 2>; >> } >> }; >> >> a-node { >> nvmem-cells = <&cell_a &cell_b &cell_c> >> nvmem-cell-names = "some-data"; >> }; >> > > It's not very clear to me, possibly to my DT ignorance, how this would > handle the case of multiple variables. Say we have > > a-node { > nvmem-cells = <&cell_a &cell_b>, ????; > nvmem-cell-names = "some-data", "more-data"; > }; > Should have replied you long back :-) > and I want "more-data" to reference only one phandle, how would this be handled? > yes this would fail. The device tree compiler would concatenate all the cells and we have no means to know where did "more-data" starts. sounds like composite driver is the way forward. --srini > Another minor nitpick about his is that if one's goal is to just > byteswap already defined nvmem_cell: > - N, where N is the length of the variable, new nvmem cells would > have to be defined > - All of them would have to use absolute address within the nvmem > provided, instead of referencing a byte relative to the position of > pre-defined cell > > Thanks, > Andrey >