From: Greg KH <gregkh@linuxfoundation.org>
To: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Cc: linux-kernel@vger.kernel.org,
Wolfram Sang <w.sang@pengutronix.de>,
Anatolij Gustschin <agust@denx.de>,
Frodo Looijaard <frodol@dds.nl>,
Philip Edelbrock <phil@netroedge.com>,
Ben Gardner <bgardner@wabtec.com>,
Ronny Meeus <Ronny.Meeus@gmail.com>
Subject: Re: [RFC] Creating an eeprom class
Date: Mon, 21 Jan 2013 16:14:45 -0800 [thread overview]
Message-ID: <20130122001445.GA4308@kroah.com> (raw)
In-Reply-To: <CAAXf6LXGOzqu=VeSdeuu3kNBjVBcobp-2keDmSZ_JSL-72Uu+Q@mail.gmail.com>
On Mon, Jan 21, 2013 at 08:25:59AM +0100, Thomas De Schampheleire wrote:
> On Sun, Jan 20, 2013 at 11:39 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Sun, Jan 20, 2013 at 07:08:28PM +0100, Thomas De Schampheleire wrote:
> >> [plaintext and fixed address of David Brownell]
> >
> > David passed away a year or so ago, so that's really not going to help :(
>
> So sorry to hear that, I was not aware...
>
> >
> >> Hi,
> >>
> >> Several of the eeprom drivers that live in drivers/misc/eeprom export
> >> a binary sysfs file 'eeprom'. If a userspace program or script wants
> >> to access this file, it needs to know the full path, for example:
> >>
> >> /sys/bus/spi/devices/spi32766.0/eeprom
> >>
> >> The problem with this approach is that it requires knowledge about the
> >> hardware configuration: is the eeprom on the SPI bus, the I2C bus, or
> >> maybe memory mapped?
> >>
> >> It would therefore be more interesting to have a bus-agnostic way to
> >> access this eeprom file, for example:
> >> /sys/class/eeprom/eeprom0/eeprom
> >>
> >> Maybe it'd be even better to use a more generic class name than
> >> 'eeprom', since there are several types of eeprom-like devices that
> >> you could export this way.
> >
> > Does all of the existing "eeprom" devices use the same userspace
> > interface? If so, yes, having a "class" would make sense.
>
> All but one do. That one (eeprom_93cx6.c) exports its read/write
> functions to other kernel code, and is used in several
> wireless/ethernet drivers.
Then it shouldn't be used here, right?
> >> Or should we rather hook the eeprom code into the mtd subsystem?
> >
> > Why mtd?
>
> Because an eeprom is a piece of memory. Maybe mtd is overkill in term
> of the operations supported, but from a high-level perspective an
> eeprom is a memory technology device, right?
Everything is a memory device in the end :)
Feel free to send patches, but I don't think this is really a big deal
that deserves this type of change at the moment. Feel free to prove me
wrong though.
greg k-h
next prev parent reply other threads:[~2013-01-22 0:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-20 18:08 [RFC] Creating an eeprom class Thomas De Schampheleire
2013-01-20 22:39 ` Greg KH
2013-01-21 7:25 ` Thomas De Schampheleire
2013-01-22 0:14 ` Greg KH [this message]
-- strict thread matches above, loose matches on Subject: below --
2014-01-22 13:25 Laszlo Papp
2014-01-22 17:18 ` Curt Brune
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=20130122001445.GA4308@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=Ronny.Meeus@gmail.com \
--cc=agust@denx.de \
--cc=bgardner@wabtec.com \
--cc=frodol@dds.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=patrickdepinguin@gmail.com \
--cc=phil@netroedge.com \
--cc=w.sang@pengutronix.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 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.