From: "Mark M. Hoffman" <mhoffman@lightlink.com>
To: Jean Delvare <khali@linux-fr.org>
Cc: sensors@Stimpy.netroedge.com, Deepak Saxena <dsaxena@plexity.net>,
Greg KH <greg@kroah.com>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: checksum in (i2c) eeprom driver
Date: Tue, 14 Dec 2004 19:57:41 -0500 [thread overview]
Message-ID: <20041215005741.GB5489@jupiter.solarsys.private> (raw)
In-Reply-To: <SFhEWFpz.1102668141.6379450.khali@localhost>
Hello:
(summary of some IRC discussions...)
> On 2004-12-10, Mark Studebaker wrote:
> > IMHO the eeprom driver is more of a demonstration driver than one of
> > great and obvious value, so achieving consensus on the value of
> > sub-features (checksum, Vaio) is difficult, and performace concerns are
> > secondary.
In as much as eeprom is a demonstration driver, with very little actual
usefulness except as a test device for us sensors people... I think it
could probably be removed from the kernel altogether if we create a user-
space (w/ i2c-dev interface) replacement for it.
* Jean Delvare <khali@linux-fr.org> [2004-12-10 09:42:21 +0100]:
> This has certainly been true when the driver was first written and then
> maintained as a driver of the lm_sensors project, and was only used for
> memory module EEPROMs. However, we now start seeing more different
> natures of EEPROMs (proprietary on laptops, ethernet devices to name
> only two of them) for which the eeprom driver can be useful. Remember
> that a number of people even asked for write support in the driver (and
> this might as well happen in the future).
If read/write support is needed, IMHO it should be implemented as a proper
char device. The sysfs interface of the current driver makes little sense.
OTOH, note that it would be possible to break RAM modules *permanently* by
misusing such a device. The eeprom itself would still work, but the SIMM
or DIMM that it sits on would be effectively broken. I don't personally
consider that a good argument against an eeprom char device, but some do.
Regards,
--
Mark M. Hoffman
mhoffman@lightlink.com
next prev parent reply other threads:[~2004-12-15 1:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <41B8ED64.9020805@verizon.net>
2004-12-10 8:42 ` Jean Delvare
2004-12-15 0:57 ` Mark M. Hoffman [this message]
2004-12-15 9:17 ` Jean Delvare
[not found] <41B85D43.8070409@verizon.net>
2004-12-09 14:45 ` Jean Delvare
2004-12-09 23:17 ` Greg KH
2004-12-09 12:53 Jean Delvare
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=20041215005741.GB5489@jupiter.solarsys.private \
--to=mhoffman@lightlink.com \
--cc=dsaxena@plexity.net \
--cc=greg@kroah.com \
--cc=khali@linux-fr.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sensors@Stimpy.netroedge.com \
/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
all inboxes | Powered by JetHome®