public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <khali@linux-fr.org>
To: Manish Lachwani <Manish_Lachwani@pmc-sierra.com>
Cc: sensors@Stimpy.netroedge.com, linux-kernel@vger.kernel.org,
	greg@kroah.com
Subject: Re: i2c-yosemite
Date: Mon, 23 Feb 2004 20:24:20 +0100	[thread overview]
Message-ID: <20040223202420.33c25164.khali@linux-fr.org> (raw)
In-Reply-To: <9DFF23E1E33391449FDC324526D1F25902253276@sjc1exm02.pmc_nt.nt.pmc-sierra.bc.ca>

> Couple of things. First of all, I did not have an idea that a driver
> existed for Atmel 24C32 EEPROM.

Actually, I read you a bit fast. I think our driver only supports 24C02
and 24C04, because 24C08 and bigger require 2-byte addressing.

> In case of the Yosemite chip, the MAC address of the Gigabit
> subsystem is stored in the EEPROM. It needs to be fetched by the Gige
> driver using the I2C protocol.

I didn't know about that. Funnily enough, a user reported today about a
strange EEPROM on his I2C bus, and it turns out that it holds a MAC
address (or at least it really looks like that).

> I could not find the driver in the 2.4 tree and hence wrote one for
> the yosemite. I could use the existing driver, which would make
> sense. 

The driver wasn't part of Linux 2.4 itself, because the lm_sensors
drivers were never integrated there. But they are in 2.6.

> The idea was that once the chip is released and the driver tested, it
> could be checked in the generic i2c framework along with the driver
> for the MAX 1619 sensors chip. Now that the drivers already exist, I
> will use them instead.

Aha, I read a bit too fast here too :/ We support the MAX1617(A), not
the MAX1619. That said, I took a look at the datasheet and the chips are
said to be very similar, so extending the driver should be quite
straightforward.

Anyway, the point isn't wether the exact drivers already exist or not.
The point is that using the existing i2c subsystem means that other
people needing support for similar chips will be able to use the same
drivers as you. This also means that all existing user-space tools will
work out-of-the-box, which is a great benefit IMHO.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

  reply	other threads:[~2004-02-23 19:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-23  4:12 i2c-yosemite Manish Lachwani
2004-02-23 19:24 ` Jean Delvare [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-02-22  9:41 i2c-yosemite Jean Delvare
2004-02-22 10:30 ` i2c-yosemite Christoph Hellwig
2004-02-22 13:43   ` i2c-yosemite Michael Hunold

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=20040223202420.33c25164.khali@linux-fr.org \
    --to=khali@linux-fr.org \
    --cc=Manish_Lachwani@pmc-sierra.com \
    --cc=greg@kroah.com \
    --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