Bug#1011091: Systems with more than 4 memory slots not supported yet, not instantiating SPD

[Ben Hutchings]

Control: reassign -1 src:linux 5.17.6-1
Control: forcemerge 1001286 -1
Control: tag -1 upstream

On Mon, 2022-05-16 at 21:55 +0300, Сергей Фёдоров wrote:
> Package: linux-source-5.17
> Version: 5.17.6-1
> Severity: normal
>
> Dear Maintainer,
>
> --------------------------------------------------------------------------------
> Problems:
>
> I already wrote about it 07 Dec 2021 21:15:07 +0000
> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D1001286 ),
> but so far nothing has changed.
[...]

So there's no need to open a new bug report.

Please contact the upstream maintainers about this at
<linu...@vger.kernel.org>.

Ben.

--
Ben Hutchings
Man invented language to satisfy his deep need to complain.
- Lily Tomlin

[Diederik de Haas]

I had made the following draft, which contains some additional info to which
you should send your upstream request (it's a bit more then Ben suggested):

On Monday, 16 May 2022 17:45:08 CEST Сергей Фёдоров wrote:
> ---- I rebuilt the kernel with changing to
> "./linux-source-5.17.6-1/drivers/i2c/i2c-smbus.c"
>
> line 358:
> if (slot_count > 4) {
> dev_warn(&adap->dev,
> "Systems with more than 4 memory slots not
> supported yet, not instantiating SPD\n");
> return;
> }
>
> replaced with
> if (slot_count > 8) {
> dev_warn(&adap->dev,
> "Systems with more than 8 memory slots not
> supported yet, not instantiating SPD\n");
> return;
> }
>

The 4 slot limit was specified in 5ace60859e84113b7a185c117fbf2c429d381b59
(upstream commit ID) and the secondary commit message had this:
"Start with just DDR2, DDR3 and DDR4 on x86 for now, and only for systems with
no more than 4 memory slots. These limitations may be lifted later."

This is an upstream issue and a change to '8' should be discussed there.

~/dev/kernel.org/linux$ ./scripts/get_maintainer.pl drivers/i2c/i2c-smbus.c
Wolfram Sang <w...@kernel.org> (maintainer:I2C SUBSYSTEM)
linu...@vger.kernel.org (open list:I2C SUBSYSTEM)
linux-...@vger.kernel.org (open list)

So I'd suggest to send it to linu...@vger.kernel.org and add the other
2 addresses in the CC and also add "Jean Delvare <jdel...@suse.de>" to the
TO or CC as that was the original author of the aforementioned commit.

Could you 'forward' your issue there and if/when done so, notify the BTS of
where that has taken place? Then we can follow its progress as well.

[Сергей Фёдоров]

I have sent 4 emails to the addresses that you have informed me.
In what format should I inform BTS about this?

[Diederik de Haas]

On Tuesday, 17 May 2022 14:12:45 CEST Сергей Фёдоров wrote:
> I have sent 4 emails to the addresses that you have informed me.
> In what format should I inform BTS about this?

With an URL to a ML post about it, send a message to 101...@bug.debian.org
with all the info on 1 line as the first (or only) line, like this:
Control: forwarded -1 <URL-to-ML-post>

[Diederik de Haas]

Control: forwarded -1 https://www.spinics.net/lists/linux-i2c/msg56885.html

On Thursday, 19 May 2022 18:30:49 CEST Сергей Фёдоров wrote:
> So far I haven't received a response from any of the four:

It sometimes takes a while.

> But if I get an answer, then I still don't understand how I should tell BTS.

The first line of this email informed the BTS of the upstream conversation, so
you don't have to do anything more (wrt that).

> will anyone from BTS read it?

All messages to the BTS are (also) send to the maintainer(s), that's how I
noticed your issue to begin with :)

[Diederik de Haas]

Control: forwarded -1 https://lore.kernel.org/linux-i2c/38376116...@vla1-3991b5027d7d.qloud-c.yandex.net/

On Thursday, 19 May 2022 18:45:04 CEST Diederik de Haas wrote:
> Control: forwarded -1 https://www.spinics.net/lists/linux-i2c/msg56885.html

Updated forwarded to lore.kernel.org address as that's better IMO.