From: Mark Brown <broonie@kernel.org>
To: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
Artem Bityutskiy <dedekind1@gmail.com>,
oliver@schinagl.nl,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Wolfram Sang <wsa@the-dreams.de>,
linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-i2c@vger.kernel.org, Jean Delvare <khali@linux-fr.org>,
Shawn Guo <shawn.guo@linaro.org>,
David Woodhouse <dwmw2@infradead.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: MTD EEPROM support and driver integration
Date: Tue, 9 Jul 2013 15:55:10 +0100 [thread overview]
Message-ID: <20130709145510.GZ27646@sirena.org.uk> (raw)
In-Reply-To: <20130708202538.GK11243@lukather>
[-- Attachment #1.1: Type: text/plain, Size: 1825 bytes --]
On Mon, Jul 08, 2013 at 10:25:38PM +0200, Maxime Ripard wrote:
> On Mon, Jul 08, 2013 at 09:34:26AM +0100, Mark Brown wrote:
> > I'd really like to see more discussion of this "DT parsing code for
> > regmap" idea... I've missed almost all the context here.
> The context was that I found we lack a way to simply express the need
> for one driver to get a value from an EEPROM-like device, for example to
> get a MAC Address, or a serial number, in a generic way, without having
> to poke directly with some custom function that would be exported by the
> EEPROM driver.
This sort of information is often stored in places like flash partitions
too. Are we sure that regmap is a good place to be hooking in here?
The use case is sane, and being able to use regmap to do some of it
seems sensible (I've seen people use OTP in PMICs for similar purposes)
but perhaps an additional layer of abstraction on top makes sense.
> What we've been discussing so far is that:
> - To have a common framework we could base our work on, we could move
> the EEPROM drivers from drivers/misc/eeprom to MTD
> - To declare the ranges that needed to be used by a driver that was
> needing a value from one of those MTD drivers, we would use regmap
> with a MTD backend
> - And since we actually need to declare which ranges and in which
> device one driver would have to retrieve this value from, we were
> actually in need of DT bindings.
> This is pretty much the only context involved, and we are at the early
> stage of the discussion, so any comment is very welcome :)
If this stuff is being represented in MTD doesn't MTD already have
adequate abstractions for saying "this region in flash". But otherwise
this seems fine, it's not a generic regmap DT binding but instead rather
more specific than that.
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2013-07-09 14:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20130705201118.GM2959@lukather>
[not found] ` <5811519.oHVuMujf0I@wuerfel>
[not found] ` <20130706120112.GA11069@lukather>
2013-07-06 19:06 ` MTD EEPROM support and driver integration Arnd Bergmann
2013-07-06 19:55 ` Jean Delvare
2013-07-07 7:15 ` Maxime Ripard
2013-07-08 8:36 ` Mark Brown
[not found] ` <20130708083614.GP27646-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2013-07-08 21:04 ` Maxime Ripard
2013-07-08 8:34 ` Mark Brown
[not found] ` <20130708083426.GO27646-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2013-07-08 20:25 ` Maxime Ripard
2013-07-09 14:55 ` Mark Brown [this message]
[not found] ` <20130709145510.GZ27646-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2013-07-11 17:05 ` Maxime Ripard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130709145510.GZ27646@sirena.org.uk \
--to=broonie@kernel.org \
--cc=arnd@arndb.de \
--cc=dedekind1@gmail.com \
--cc=dwmw2@infradead.org \
--cc=gregkh@linuxfoundation.org \
--cc=khali@linux-fr.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=maxime.ripard@free-electrons.com \
--cc=oliver@schinagl.nl \
--cc=shawn.guo@linaro.org \
--cc=wsa@the-dreams.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).