From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Alban <albeu@free.fr>
Cc: linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
Cyrille Pitchen <cyrille.pitchen@atmel.com>,
Richard Weinberger <richard@nod.at>,
Marek Vasut <marek.vasut@gmail.com>,
Brian Norris <computersforpeace@gmail.com>,
David Woodhouse <dwmw2@infradead.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Moritz Fischer <moritz.fischer@ettus.com>
Subject: Re: [RFC 0/3] drivers: Add an API to read device specific config data
Date: Mon, 27 Feb 2017 21:42:30 +0100 [thread overview]
Message-ID: <20170227214230.53f05677@bbrezillon> (raw)
In-Reply-To: <1488227292-18906-1-git-send-email-albeu@free.fr>
+Moritz
Hi Alban,
On Mon, 27 Feb 2017 21:28:09 +0100
Alban <albeu@free.fr> wrote:
> Hi all,
>
> while looking at adding OF support for the ath9k driver I had the problem of
> reading the EEPROM data. On the SoC platforms this data is stored in an SPI
> flash along with a few other things. In OpenWRT/LEDE this data is read from
> the board init code using the fact that the flash is (normaly) readable from
> a memory map. A bit too hackish for my taste.
>
> This is just one example, there is various other similar cases, mostly with
> MAC addresses. I thought it would be nicer if we had a clean API for this,
> similar to the firmware API but per device instance instead of beeing per
> driver. The device driver wouldn't have to care where the data is stored,
> they just request it and the backend take care of reading the EEPROM, MTD
> or whatever is used on the board.
>
> This series implement such an API along with an implementation for MTD
> devices and a use in the ath9k driver. As this is an RFC I didn't yet
> write the OF binding documentation, that will come later if the feedback
> is positive.
What you're looking for already exists and it's called nvmem[1]. Some
work has been done to expose MTD partitions as nvmem cells [2], but
it's never been finished.
Can you please finish Moritz implementation instead of creating a new
API?
Thanks,
Boris
[1]http://lxr.free-electrons.com/source/Documentation/nvmem/nvmem.txt
[2]https://patchwork.ozlabs.org/patch/626460/
next prev parent reply other threads:[~2017-02-27 20:42 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-27 20:28 [RFC 0/3] drivers: Add an API to read device specific config data Alban
2017-02-27 20:28 ` [PATCH 1/3] " Alban
2017-02-27 20:28 ` [PATCH 2/3] mtd: Add support for reading device data out of MTD devices Alban
2017-02-27 20:28 ` [PATCH 3/3] ath9k: ahb: Add OF support Alban
2017-02-27 21:13 ` Rafał Miłecki
2017-02-27 22:48 ` Alban
2017-02-27 22:54 ` Rafał Miłecki
2017-02-27 22:54 ` Rafał Miłecki
2017-02-28 18:03 ` kbuild test robot
2017-02-27 20:42 ` Boris Brezillon [this message]
2017-02-27 22:26 ` [RFC 0/3] drivers: Add an API to read device specific config data Moritz Fischer
2017-02-27 22:41 ` Alban
2017-02-27 20:42 ` Marek Vasut
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=20170227214230.53f05677@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=albeu@free.fr \
--cc=computersforpeace@gmail.com \
--cc=cyrille.pitchen@atmel.com \
--cc=dwmw2@infradead.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=moritz.fischer@ettus.com \
--cc=richard@nod.at \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.