Dear Linux folks,
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.
Kind regards,
Paul
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
On Wed, Mar 27, 2024 at 04:13:26PM +0100, Paul Menzel wrote:
Dear Linux folks,
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? But isn't this a new feature, why is it needed in older kernels? It's not a fix for a regression.
thanks,
greg k-h
[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
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
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?
linux-stable-mirror@lists.linaro.org