[Top] [All Lists]

Re: [PATCH V2] MIPS: Octeon: Register EEPROM device on the I2C bus

To: Ralf Baechle <>
Subject: Re: [PATCH V2] MIPS: Octeon: Register EEPROM device on the I2C bus
From: Jean Delvare <>
Date: Thu, 18 Mar 2010 18:48:48 +0100
Cc: Yang Shi <>,,,,
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <20100316200647.3803edf1@hyperion.delvare> <>
Hi Ralf,

On Thu, 18 Mar 2010 18:00:30 +0100, Ralf Baechle wrote:
> On Tue, Mar 16, 2010 at 08:06:47PM +0100, Jean Delvare wrote:
> > The Linux kernel doesn't care, but user-space may. As a matter of fact,
> > there is a script out there (decode-dimms, in the i2c-tools package)
> > decoding the SPD data and presenting it to the user. Some people want
> > to know the details about their memory modules.
> > 
> > > I also wonder how this will work for configurations with multiple memory
> > > modules thus multiple SPD EEPROMS.
> > 
> > The kernel code should instantiate one spd device per memory module
> > (assuming they are all reachable.) Obviously this can't be done in a
> > static way.
> SPD is virtually omnipresent these days so I wonder if maybe there already
> is some probing functionality already available?

Not that I aware of, except for the fact that the "eeprom" driver will
probe all i2c adapters with class bit I2C_CLASS_SPD set for chips at
addresses 0x50-0x57, and it will instantiate a device for each of them.
This will instantiate devices for non-SPD EEPROM, and even non-EEPROMs
living at these addresses, so this can't really be considered a generic

A generic solution would let the platform (not the eeprom driver) probe
for devices at selected I2C addresses (the ones where SPD EEPROMs can
live of the specific platform) and instantiate spd devices (possibly
after integrity checking). This would avoid false positives.

Jean Delvare

<Prev in Thread] Current Thread [Next in Thread>