Re: Please backport commit 13e3a512a290 (i2c: smbus: Support up to 8 SPD EEPROMs)

Re: Please backport commit 13e3a512a290 (i2c: smbus: Support up to 8 SPD EEPROMs)

[Paul Menzel]

[Cc: +I2C folks]


Dear Greg,


Am 27.03.24 um 17:52 schrieb Greg KH:
> On Wed, Mar 27, 2024 at 04:13:26PM +0100, Paul Menzel wrote:

>> Please apply commit 13e3a512a290 (i2c: smbus: Support up to 8 SPD EEPROMs)
>> [1] to the stable series to get rid of a warning and to support more SPDs.
>> That commit is present since v6.8-rc1.
> 
> How far back?

I’d say 6.1.

> But isn't this a new feature, why is it needed in older kernels?
> It's not a fix for a regression.
decode-dimm does not work on systems with more than four SPD EEPROMs, so 
I’d say it’s a fix.


Kind regards,

Paul

Re: Please backport commit 13e3a512a290 (i2c: smbus: Support up to 8 SPD EEPROMs)

[Greg KH]

On Wed, Mar 27, 2024 at 09:35:38PM +0100, Paul Menzel wrote:
> 
> [Cc: +I2C folks]
> 
> 
> Dear Greg,
> 
> 
> Am 27.03.24 um 17:52 schrieb Greg KH:
> > On Wed, Mar 27, 2024 at 04:13:26PM +0100, Paul Menzel wrote:
> 
> > > Please apply commit 13e3a512a290 (i2c: smbus: Support up to 8 SPD EEPROMs)
> > > [1] to the stable series to get rid of a warning and to support more SPDs.
> > > That commit is present since v6.8-rc1.
> > 
> > How far back?
> 
> I’d say 6.1.
> 
> > But isn't this a new feature, why is it needed in older kernels?
> > It's not a fix for a regression.
> decode-dimm does not work on systems with more than four SPD EEPROMs, so I’d
> say it’s a fix.

But it's never worked on such systems so it's not a regression fix,
right?

Anyway, I'll defer to the i2c maintainers as to what they want to have
happen here, as they did not originally tag this commit for stable
inclusion.

thanks,

greg k-h

Re: Please backport commit 13e3a512a290 (i2c: smbus: Support up to 8 SPD EEPROMs)

[Jean DELVARE]

Hi Greg, Paul,

On Thu, 2024-03-28 at 07:10 +0100, Greg KH wrote:
> On Wed, Mar 27, 2024 at 09:35:38PM +0100, Paul Menzel wrote:
> > Am 27.03.24 um 17:52 schrieb Greg KH:
> > > On Wed, Mar 27, 2024 at 04:13:26PM +0100, Paul Menzel wrote:
> > 
> > > > Please apply commit 13e3a512a290 (i2c: smbus: Support up to 8
> > > > SPD EEPROMs) [1] to the stable series to get rid of a warning
> > > > and to support more SPDs.
> > > > That commit is present since v6.8-rc1.
> > > 
> > > How far back?
> > 
> > I’d say 6.1.
> > 
> > > But isn't this a new feature, why is it needed in older kernels?
> > > It's not a fix for a regression.
> > decode-dimm does not work on systems with more than four SPD
> > EEPROMs, so I’d say it’s a fix.
>
> But it's never worked on such systems so it's not a regression fix,
> right?

It's hard to qualify whether this is a regression or not.

On the one hand, automatic detection of SPD EEPROMs only ever supported
4 modules maximum (since kernel v5.8):

01590f361e94 ("i2c: i801: Instantiate SPD EEPROMs automatically")
5ace60859e84 ("i2c: smbus: Add a way to instantiate SPD EEPROMs automatically")


OTOH, this was implemented using the at24 driver, which replaced the
legacy eeprom driver. Said legacy driver was removed in kernel v6.7:

0113a99b8a75 ("eeprom: Remove deprecated legacy eeprom driver")

As it would be possible to see up to 8 SPD EEPROMs using the legacy
eeprom driver, and only 4 when using the at24 driver, you could say
that kernel v6.7 suffers from a regression. So backporting commit
13e3a512a290 to 6.7-stable would make sense.

> Anyway, I'll defer to the i2c maintainers as to what they want to
> have happen here, as they did not originally tag this commit for
> stable inclusion.

I'm definitely in favor of backporting 13e3a512a290 to 6.7-stable.

For older kernels, I'm not so sure, as there's a fairly easy
workaround: loading the legacy eeprom driver should let decode-dimms
see all memory modules (modules 1-4 using the at24 driver and modules
5-8 using the eeprom driver). Paul, can you try and confirm that this
does work?

-- 
Jean Delvare
SUSE L3 Support