From: Jean DELVARE <jdelvare@suse.com>
To: Greg KH <gregkh@linuxfoundation.org>,
Paul Menzel <pmenzel@molgen.mpg.de>
Cc: stable@vger.kernel.org, Wolfram Sang <wsa@kernel.org>,
linux-i2c@vger.kernel.org
Subject: Re: Please backport commit 13e3a512a290 (i2c: smbus: Support up to 8 SPD EEPROMs)
Date: Thu, 28 Mar 2024 15:51:35 +0100 [thread overview]
Message-ID: <cf21b9dd6499d3e6fa8d9e8c46d77eb035e9c7b5.camel@suse.com> (raw)
In-Reply-To: <2024032814-colony-observant-4e42@gregkh>
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
prev parent reply other threads:[~2024-03-28 14:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-27 15:13 Please backport commit 13e3a512a290 (i2c: smbus: Support up to 8 SPD EEPROMs) Paul Menzel
2024-03-27 16:52 ` Greg KH
2024-03-27 20:35 ` Paul Menzel
2024-03-28 6:10 ` Greg KH
2024-03-28 14:51 ` Jean DELVARE [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cf21b9dd6499d3e6fa8d9e8c46d77eb035e9c7b5.camel@suse.com \
--to=jdelvare@suse.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-i2c@vger.kernel.org \
--cc=pmenzel@molgen.mpg.de \
--cc=stable@vger.kernel.org \
--cc=wsa@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.