mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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


  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®