khali at linux-fr.org
Mon Feb 23 20:24:20 CET 2004
> 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
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
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.
More information about the lm-sensors