[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <E5772084-6CF5-41DE-B68B-073D9F75F0BC@konsulko.com>
Date: Mon, 25 May 2015 19:51:45 +0300
From: Pantelis Antoniou <pantelis.antoniou@...sulko.com>
To: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
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 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.
I have a big problem with the removal of the raw of_* access APIs.
Take for instance the case where you have multiple slot accessing different EEPROMs.
> slots {
> slot@0 {
> eeprom = <&cape0_data>;
> };
>
> slot@1 {
> eeprom = <&cape1_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.
> --
> 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/
Powered by blists - more mailing lists