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

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

[Yang Shi]

An SPD resides on 0x50 of the I2C bus on CN56xx/57xx board,
register this device.

Signed-off-by: Yang Shi <yang.shi-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org>
---
 arch/mips/cavium-octeon/octeon-platform.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/mips/cavium-octeon/octeon-platform.c b/arch/mips/cavium-octeon/octeon-platform.c
index 62ac30e..3138982 100644
--- a/arch/mips/cavium-octeon/octeon-platform.c
+++ b/arch/mips/cavium-octeon/octeon-platform.c
@@ -164,6 +164,9 @@ static struct i2c_board_info __initdata octeon_i2c_devices[] = {
 	{
 		I2C_BOARD_INFO("ds1337", 0x68),
 	},
+	{
+		I2C_BOARD_INFO("spd", 0x50),
+	},
 };
 
 static int __init octeon_i2c_devices_init(void)
-- 
1.6.3.3

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

[Yang Shi]

An SPD resides on 0x50 of the I2C bus on CN56xx/57xx board,
register this device.

Signed-off-by: Yang Shi <yang.shi@windriver.com>
---
 arch/mips/cavium-octeon/octeon-platform.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/mips/cavium-octeon/octeon-platform.c b/arch/mips/cavium-octeon/octeon-platform.c
index 62ac30e..3138982 100644
--- a/arch/mips/cavium-octeon/octeon-platform.c
+++ b/arch/mips/cavium-octeon/octeon-platform.c
@@ -164,6 +164,9 @@ static struct i2c_board_info __initdata octeon_i2c_devices[] = {
 	{
 		I2C_BOARD_INFO("ds1337", 0x68),
 	},
+	{
+		I2C_BOARD_INFO("spd", 0x50),
+	},
 };
 
 static int __init octeon_i2c_devices_init(void)
-- 
1.6.3.3

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

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 503 bytes --]

On Mon, Mar 08, 2010 at 01:29:50PM +0800, Yang Shi wrote:
> An SPD resides on 0x50 of the I2C bus on CN56xx/57xx board,
> register this device.
> 
> Signed-off-by: Yang Shi <yang.shi-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org>

Glad it worked with at24, after all.

Acked-by: Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 452 bytes --]

On Mon, Mar 08, 2010 at 01:29:50PM +0800, Yang Shi wrote:
> An SPD resides on 0x50 of the I2C bus on CN56xx/57xx board,
> register this device.
> 
> Signed-off-by: Yang Shi <yang.shi@windriver.com>

Glad it worked with at24, after all.

Acked-by: Wolfram Sang <w.sang@pengutronix.de>

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Ralf Baechle]

On Mon, Mar 08, 2010 at 01:29:50PM +0800, Yang Shi wrote:

> An SPD resides on 0x50 of the I2C bus on CN56xx/57xx board,
> register this device.

I wonder what the use case for this patch is?  Normally Linux doesn't care
about SPD.

I also wonder how this will work for configurations with multiple memory
modules thus multiple SPD EEPROMS.

  Ralf

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

[Ralf Baechle]

On Mon, Mar 08, 2010 at 01:29:50PM +0800, Yang Shi wrote:

> An SPD resides on 0x50 of the I2C bus on CN56xx/57xx board,
> register this device.

I wonder what the use case for this patch is?  Normally Linux doesn't care
about SPD.

I also wonder how this will work for configurations with multiple memory
modules thus multiple SPD EEPROMS.

  Ralf

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

[Jean Delvare]

Hi Ralf,

On Tue, 16 Mar 2010 19:09:46 +0100, Ralf Baechle wrote:
> On Mon, Mar 08, 2010 at 01:29:50PM +0800, Yang Shi wrote:
> 
> > An SPD resides on 0x50 of the I2C bus on CN56xx/57xx board,
> > register this device.
> 
> I wonder what the use case for this patch is?  Normally Linux doesn't care
> about SPD.

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.

-- 
Jean Delvare

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

[Ralf Baechle]

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?

  Ralf

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

[Jean 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
solution.

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

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

[Jean 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
solution.

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