From: maxime.ripard@free-electrons.com (Maxime Ripard)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/7] New eFuse subsystem
Date: Wed, 25 Feb 2015 16:15:53 +0100 [thread overview]
Message-ID: <20150225151553.GE5062@lukather> (raw)
In-Reply-To: <72BC0C8BD7BB6F45988A99382E5FBAE5444505E9@hhmail02.hh.imgtec.org>
Hi,
On Wed, Feb 25, 2015 at 01:12:01PM +0000, James Hartley wrote:
> Hi Maxime,
>
> > -----Original Message-----
> > From: Ezequiel Garcia
> > Sent: 25 February 2015 12:30
> > To: Maxime Ripard
> > Cc: Thierry Reding; Stephen Warren; Arnd Bergmann; Andrew Bresticker;
> > James Hartley; linux-arm-kernel at lists.infradead.org; linux-
> > kernel at vger.kernel.org
> > Subject: Re: [PATCH 0/7] New eFuse subsystem
> >
> >
> >
> > On 02/25/2015 09:02 AM, Maxime Ripard wrote:
> > > Hi Ezequiel,
> > >
> > > On Wed, Feb 25, 2015 at 08:45:12AM -0300, Ezequiel Garcia wrote:
> > >> This patchset introduces a new driver subsystem, meant to support
> > >> eFuse (alias OTP, one-time-programmable) devices.
> > >>
> > >> The motivation behind this work is to have a common place for drivers
> > >> that are currently more or less scattered: the tegra efuses are in
> > >> drivers/soc/ and the sunxi efuses in drivers/misc/eeprom.
> > >>
> > >> For now, there's no proposal for a generic efuse API. Instead, we
> > >> simply group the drivers together.
> > >>
> > >> This patchset is the result of the initial submission for IMG
> > >> Pistachio eFuse support [1]. Our first proposal was to follow the
> > >> Tegra efuse, and put the Pistachio efuse in drivers/soc. After some
> > >> discussion we finally agreed [2] to first create an efuse directoy,
> > >> and then put all efuse drivers in it.
> > >>
> > >> As always, all comments are welcome!
> > >>
> > >> [1] http://www.spinics.net/lists/devicetree/msg59246.html
> > >> [2] http://www.spinics.net/lists/arm-kernel/msg389325.html
> > >
> > > Have you looked at the EEPROM framework currently in discussions? The
> > > two seems to be covering pretty much the same use cases.
> > >
>
> Shouldn't this be a PROM framework if it is going to support both
> EEPROM and EFUSE/QFPROM, or am I missing something here (since an
> eFuse is not eraseable)?
Does it really matter? I mean, it's just a name after all.
But feel free to suggest alternatives on the main thread.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150225/f30afb44/attachment.sig>
WARNING: multiple messages have this Message-ID (diff)
From: Maxime Ripard <maxime.ripard@free-electrons.com>
To: James Hartley <James.Hartley@imgtec.com>
Cc: Ezequiel Garcia <Ezequiel.Garcia@imgtec.com>,
Thierry Reding <thierry.reding@gmail.com>,
Stephen Warren <swarren@wwwdotorg.org>,
Arnd Bergmann <arnd@arndb.de>,
Andrew Bresticker <abrestic@chromium.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/7] New eFuse subsystem
Date: Wed, 25 Feb 2015 16:15:53 +0100 [thread overview]
Message-ID: <20150225151553.GE5062@lukather> (raw)
In-Reply-To: <72BC0C8BD7BB6F45988A99382E5FBAE5444505E9@hhmail02.hh.imgtec.org>
[-- Attachment #1: Type: text/plain, Size: 2190 bytes --]
Hi,
On Wed, Feb 25, 2015 at 01:12:01PM +0000, James Hartley wrote:
> Hi Maxime,
>
> > -----Original Message-----
> > From: Ezequiel Garcia
> > Sent: 25 February 2015 12:30
> > To: Maxime Ripard
> > Cc: Thierry Reding; Stephen Warren; Arnd Bergmann; Andrew Bresticker;
> > James Hartley; linux-arm-kernel@lists.infradead.org; linux-
> > kernel@vger.kernel.org
> > Subject: Re: [PATCH 0/7] New eFuse subsystem
> >
> >
> >
> > On 02/25/2015 09:02 AM, Maxime Ripard wrote:
> > > Hi Ezequiel,
> > >
> > > On Wed, Feb 25, 2015 at 08:45:12AM -0300, Ezequiel Garcia wrote:
> > >> This patchset introduces a new driver subsystem, meant to support
> > >> eFuse (alias OTP, one-time-programmable) devices.
> > >>
> > >> The motivation behind this work is to have a common place for drivers
> > >> that are currently more or less scattered: the tegra efuses are in
> > >> drivers/soc/ and the sunxi efuses in drivers/misc/eeprom.
> > >>
> > >> For now, there's no proposal for a generic efuse API. Instead, we
> > >> simply group the drivers together.
> > >>
> > >> This patchset is the result of the initial submission for IMG
> > >> Pistachio eFuse support [1]. Our first proposal was to follow the
> > >> Tegra efuse, and put the Pistachio efuse in drivers/soc. After some
> > >> discussion we finally agreed [2] to first create an efuse directoy,
> > >> and then put all efuse drivers in it.
> > >>
> > >> As always, all comments are welcome!
> > >>
> > >> [1] http://www.spinics.net/lists/devicetree/msg59246.html
> > >> [2] http://www.spinics.net/lists/arm-kernel/msg389325.html
> > >
> > > Have you looked at the EEPROM framework currently in discussions? The
> > > two seems to be covering pretty much the same use cases.
> > >
>
> Shouldn't this be a PROM framework if it is going to support both
> EEPROM and EFUSE/QFPROM, or am I missing something here (since an
> eFuse is not eraseable)?
Does it really matter? I mean, it's just a name after all.
But feel free to suggest alternatives on the main thread.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2015-02-25 15:15 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-25 11:45 [PATCH 0/7] New eFuse subsystem Ezequiel Garcia
2015-02-25 11:45 ` Ezequiel Garcia
2015-02-25 11:45 ` [PATCH 1/7] soc: tegra: Add missing include linux/types.h Ezequiel Garcia
2015-02-25 11:45 ` Ezequiel Garcia
2015-02-25 11:45 ` [PATCH 2/7] soc: tegra: Move the fuse header to a separate directory Ezequiel Garcia
2015-02-25 11:45 ` Ezequiel Garcia
2015-02-25 11:45 ` [PATCH 3/7] drivers: Introduce new eFuse subsystem stub Ezequiel Garcia
2015-02-25 11:45 ` Ezequiel Garcia
2015-02-25 12:29 ` Stefan Wahren
2015-02-25 12:29 ` Stefan Wahren
2015-02-25 12:29 ` Stefan Wahren
2015-02-28 15:45 ` Paul Bolle
2015-02-28 15:45 ` Paul Bolle
2015-02-25 11:45 ` [PATCH 4/7] efuse: Move Tegra efuse driver Ezequiel Garcia
2015-02-25 11:45 ` Ezequiel Garcia
2015-02-28 15:51 ` Paul Bolle
2015-02-28 15:51 ` Paul Bolle
2015-02-25 12:02 ` [PATCH 0/7] New eFuse subsystem Maxime Ripard
2015-02-25 12:02 ` Maxime Ripard
2015-02-25 12:30 ` Ezequiel Garcia
2015-02-25 12:30 ` Ezequiel Garcia
2015-02-25 13:12 ` James Hartley
2015-02-25 13:12 ` James Hartley
2015-02-25 15:15 ` Maxime Ripard [this message]
2015-02-25 15:15 ` 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=20150225151553.GE5062@lukather \
--to=maxime.ripard@free-electrons.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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.