[PATCH i2c-tools] TODO: add file and describe items for the 4.5 release

[PATCH i2c-tools] TODO: add file and describe items for the 4.5 release

[Wolfram Sang]

We need help, especially with tests, for the next release. To make this
visible, document the planned items and explain where and how people can
participate.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
 TODO | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 TODO

diff --git a/TODO b/TODO
new file mode 100644
index 0000000..290e610
--- /dev/null
+++ b/TODO
@@ -0,0 +1,23 @@
+Items for the 4.5 release
+=========================
+
+[.] make i2c-tools accept bus paths (Brigham Campbell)
+	[x] patches available: https://lore.kernel.org/r/20260530-accept-device-path-v3-0-20c01b8f6726@brighamcampbell.com
+	[ ] reviews and tests needed, please help
+
+[.] add DDR5 support to decode-dimms (Stephen Horvath)
+	[x] patches available: https://lore.kernel.org/r/20260629-ddr5-v3-0-07f45075a51a@outlook.com.au
+	[ ] reviews and tests needed, please help
+
+[.] add document to describe the release process (Jean Delvare)
+	[.] he agreed to the idea and wants to provide it
+
+[ ] print I2C_M flags in PRINT_HEADER (maybe Benoît Monin)
+	Benoît agreed but did not know when he has time. So, if someone else
+	wants to do it, happy hacking!
+
+[ ] utilize CROSS_COMPILE (maybe Wolfram Sang)
+	Guenter Roeck once did it, but his repo is gone. Merges still exist:
+	https://github.com/arche67/i2c-tools/commit/60581c572354dd5dbe98b78e3a0431cbc1167330
+
+	But can be written from scratch, too, of course. Any volunteers?
-- 
2.51.0

Re: [PATCH i2c-tools] TODO: add file and describe items for the 4.5 release

[Brigham Campbell]

On Sun Jul 5, 2026 at 12:10 PM MDT, Wolfram Sang wrote:
> We need help, especially with tests, for the next release. To make this
> visible, document the planned items and explain where and how people can
> participate.

> +[.] make i2c-tools accept bus paths (Brigham Campbell)
> +	[x] patches available: https://lore.kernel.org/r/20260530-accept-device-path-v3-0-20c01b8f6726@brighamcampbell.com
> +	[ ] reviews and tests needed, please help

Noticed a minor conflict after rebasing onto master, so I rolled a v4:
https://lore.kernel.org/r/20260705-accept-device-path-v4-0-c62caa708a9e@brighamcampbell.com

This latest revision includes no functional changes from v3.

> +[.] add DDR5 support to decode-dimms (Stephen Horvath)
> +	[x] patches available: https://lore.kernel.org/r/20260629-ddr5-v3-0-07f45075a51a@outlook.com.au
> +	[ ] reviews and tests needed, please help

Stephen, it looks like your series applies cleanly on top of my v4. I'm
not familiar with decode-dimms, but I do have a laptop with DDR5 memory.
If you can provide some instructions for testing, I'd be happy to
exercise this new code and report back.

In case it's relevant, here's the output of `i2cdetect -l` on my system:

```
i2c-0	i2c       	Synopsys DesignWare I2C adapter 	I2C adapter
i2c-1	i2c       	Synopsys DesignWare I2C adapter 	I2C adapter
i2c-2	i2c       	i915 gmbus dpa                  	I2C adapter
i2c-3	i2c       	i915 gmbus dpb                  	I2C adapter
i2c-4	i2c       	i915 gmbus dpc                  	I2C adapter
i2c-5	i2c       	i915 gmbus dpd                  	I2C adapter
i2c-6	i2c       	i915 gmbus dpe                  	I2C adapter
i2c-7	i2c       	i915 gmbus tc1                  	I2C adapter
i2c-8	i2c       	i915 gmbus tc2                  	I2C adapter
i2c-9	i2c       	i915 gmbus tc3                  	I2C adapter
i2c-10	i2c       	i915 gmbus tc4                  	I2C adapter
i2c-11	i2c       	AUX A/DDI A/PHY A               	I2C adapter
i2c-12	i2c       	AUX USBC1/DDI TC1/PHY TC1       	I2C adapter
i2c-13	i2c       	AUX USBC2/DDI TC2/PHY TC2       	I2C adapter
i2c-14	i2c       	AUX USBC3/DDI TC3/PHY TC3       	I2C adapter
i2c-15	smbus     	SMBus I801 adapter at 0000:00:1f.4	SMBus adapter
i2c-16	i2c       	usbio-i2c.0                     	I2C adapter
i2c-17	i2c       	usbio-i2c.1                     	I2C adapter
```

Thanks,
Brigham

Re: [PATCH i2c-tools] TODO: add file and describe items for the 4.5 release

[Stephen Horvath]

Hi Brigham,

On 6/7/26 14:45, Brigham Campbell wrote:
> Stephen, it looks like your series applies cleanly on top of my v4. I'm
> not familiar with decode-dimms, but I do have a laptop with DDR5 memory.
> If you can provide some instructions for testing, I'd be happy to
> exercise this new code and report back.

If you've got the spd5118 kernel module loaded (which usually happens
automatically), you just have to run `sudo ./decode-dimms`. You can
manually bind spd5118 if it isn't autodetecting, your dimms should be on
your i801 bus (or PIIX4 for AMD), usually with an address between 0x50
to 0x57.

If you're willing to dump the eeprom too, the location is usually at
`/sys/bus/i2c/drivers/spd5118/<fill with bus-addr>/eeprom` and run it
through `hexdump -C` just to make it plain text.

Thanks!
Steve.

Re: [PATCH i2c-tools] TODO: add file and describe items for the 4.5 release

[Brigham Campbell]

On Sun Jul 5, 2026 at 11:19 PM MDT, Stephen Horvath wrote:
> If you've got the spd5118 kernel module loaded (which usually happens
> automatically), you just have to run `sudo ./decode-dimms`. You can
> manually bind spd5118 if it isn't autodetecting, your dimms should be on
> your i801 bus (or PIIX4 for AMD), usually with an address between 0x50
> to 0x57.

No, the spd5118 module doesn't appear to be loaded automatically:

```
$ lsmod | grep spd5118
$ zgrep SENSORS_SPD5118 /proc/config.gz
CONFIG_SENSORS_SPD5118=m
CONFIG_SENSORS_SPD5118_DETECT=y
```

Using `i2cdetect` on the i801 SMBus controller, I see that it reports no
attached i2c devices:

```
$ sudo ./tools/i2cdetect -y /dev/i2c-15
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
$ 
```

Interestingly, I see warnings in dmesg upon running the above i2cdetect
command. Taking a quick look at the kernel code, this appears to be
caused by some transient controller hardware busy state which is
overcome by the kernel's bus arbitration retry logic (See
`drivers/i2c/busses/i2c-i801.c:1552`). It's strange that a bus with no
devices attached would ever become busy...

```
...
[  +0.000009] i801_smbus 0000:00:1f.4: SMBus is busy, can't use it!
[  +0.000010] i801_smbus 0000:00:1f.4: SMBus is busy, can't use it!
[  +0.000010] i801_smbus 0000:00:1f.4: SMBus is busy, can't use it!
[  +0.000009] i801_smbus 0000:00:1f.4: SMBus is busy, can't use it!
[  +0.000010] i801_smbus 0000:00:1f.4: SMBus is busy, can't use it!
...
```

In any case, if I am unable to exercise your code, I would still be glad
to review it.

Cheers,
Brigham

Re: [PATCH i2c-tools] TODO: add file and describe items for the 4.5 release

[Benoît Monin]

Hi Wolfram,

On Sunday, 5 July 2026 at 20:10:42 CEST, Wolfram Sang wrote:
> We need help, especially with tests, for the next release. To make this
> visible, document the planned items and explain where and how people can
> participate.
> 
[...]
> +[ ] print I2C_M flags in PRINT_HEADER (maybe Benoît Monin)
> +	Benoît agreed but did not know when he has time. So, if someone else
> +	wants to do it, happy hacking!
> +
I'll try to send a patch for that today.

Best regards,
-- 
Benoît Monin, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH i2c-tools] TODO: add file and describe items for the 4.5 release

[Wolfram Sang]

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

On Sun, Jul 05, 2026 at 08:10:42PM +0200, Wolfram Sang wrote:
> We need help, especially with tests, for the next release. To make this
> visible, document the planned items and explain where and how people can
> participate.
> 
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>

Guys, thank you! I just had a little hope that this text file might draw
some attention, but still wanted to try nonetheless. You exceeded my
expectations by far and already tackled most of the action items. Really
awesome! I will look at your contributions today. We probably don't need
this TODO file after all. Yay, happy!


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH i2c-tools] TODO: add file and describe items for the 4.5 release

[Wolfram Sang]

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


> Using `i2cdetect` on the i801 SMBus controller, I see that it reports no

You might try busses 0 and 1, too. Some laptops use the Synopsis
controller.

> Interestingly, I see warnings in dmesg upon running the above i2cdetect
> command.

How many? If it is in the 120 range, then every access from i2cdetect
fails with it.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH i2c-tools] TODO: add file and describe items for the 4.5 release

[Brigham Campbell]

On Tue Jul 7, 2026 at 6:16 AM MDT, Wolfram Sang wrote:
> You might try busses 0 and 1, too. Some laptops use the Synopsis
> controller.

No such luck, apparently. Busses 0 and 1 each report no devices
attached.

$ sudo i2cdetect -y 0
Warning: Can't use SMBus Quick Write command, will skip some addresses
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:
10:
20:
30: -- -- -- -- -- -- -- --
40:
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60:
70:

Instructing i2cdetect to instead probe using SMBus receive byte shows
the full range, with no devices on synopsis bus 1, but one device bound
to a driver on synopsis 0:

$ sudo i2cdetect -yr 0
[sudo] password for brigham:
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- UU -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

It looks like it's bound to i2c_hid_acpi. No ddr5 temperature sensors in
sight...

> How many? If it is in the 120 range, then every access from i2cdetect
> fails with it.

When I run i2cdetect on the i801 controller, on one invocation I count
111 repetitions of the "SMBus is busy, can't use it!" error once, then
on another invocation I count 112 repetitions. The error condition
appears to be encountered very frequently, but not quite every time.
When the kernel's i2c bus arbitration retry logic kicks in, it appears
to be able to eventually complete the operation successfully before the
i2c core driver code gives up because otherwise I would expect i2cdetect
to exit prematurely and report an error.

Wolfram, if you or any other kernel developers think this may be
indicative of some underlying issue, I'm happy to investigate further
and report back. I'm using a Dell XPS 14 DA14260 laptop.

Cheers!
-- 
Brigham Campbell
https://brighamcampbell.com

Re: [PATCH i2c-tools] TODO: add file and describe items for the 4.5 release

[Wolfram Sang]

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


@Andy: you know more about laptops and I2C than I do. The initial issue
was reported here:

https://lore.kernel.org/all/DJRA1PB8LKKJ.2RTZWEP2LVRFF@brighamcampbell.com/

It would be great to get that bus working because Brigham likely could
then test the new DDR5 patches for decode-dimms.

> It looks like it's bound to i2c_hid_acpi. No ddr5 temperature sensors in
> sight...

Well, it was worth a try. Thanks.

> > How many? If it is in the 120 range, then every access from i2cdetect
> > fails with it.
> 
> When I run i2cdetect on the i801 controller, on one invocation I count
> 111 repetitions of the "SMBus is busy, can't use it!" error once, then
> on another invocation I count 112 repetitions.

Okay, as expected, this is more or less one BUSY condition per address
scanned.

> When the kernel's i2c bus arbitration retry logic kicks in, it appears
> to be able to eventually complete the operation successfully before the
> i2c core driver code gives up because otherwise I would expect i2cdetect
> to exit prematurely and report an error.

It would mark that address as "XX" if there was an error. As it prints
"--", it indeed indicates that the retry could have succeeded.

> Wolfram, if you or any other kernel developers think this may be
> indicative of some underlying issue, I'm happy to investigate further
> and report back. I'm using a Dell XPS 14 DA14260 laptop.

Thank you, but sadly I am not the right person to ask. My expertise is
the embedded sector. I don't know much about laptops, ACPI, and how the
management processors play in the game. My assumption would be that the
BUSY state has something to do with the latter. But maybe Andy knows?


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH i2c-tools] TODO: add file and describe items for the 4.5 release

[Andy Shevchenko]

+Cc: Heikki, who is involved in i2c more than me these days.

On Wed, Jul 08, 2026 at 10:38:55AM +0200, Wolfram Sang wrote:
> 
> @Andy: you know more about laptops and I2C than I do. The initial issue
> was reported here:
> 
> https://lore.kernel.org/all/DJRA1PB8LKKJ.2RTZWEP2LVRFF@brighamcampbell.com/

I read the thread in full. Without laptop schematics (and usually this is
the biggest obstacle to understand things clearly) it's just a guesswork.

With information given in the thread I think the actual connection of the
thermal sensors (and I don't believe they are absent or not connected) does
not go to the SoC. It's most likely (taking into account that this is laptop)
connected to EC or other separate MCU on the board.

There is still a quite little chance that they are connected to the SoC pins
but pin muxing done in a way that they are hidden from the host SMBus controller.

Have to state again, without schematics it's a guesswork. One may also reverse
engineer BIOS, but it's quite out of scope of this.

As per I²C HID. You can run

	grep -H 15 /sys/bus/acpi/devices/*/status

and I believe one of them can be touchpad. Also

	cat /proc/interrups

may lead to that device as it's usually the most appearing consumer of GPIO
interrupts and I²C host controller. Hope this helps.

> It would be great to get that bus working because Brigham likely could
> then test the new DDR5 patches for decode-dimms.
> 
> > It looks like it's bound to i2c_hid_acpi. No ddr5 temperature sensors in
> > sight...
> 
> Well, it was worth a try. Thanks.
> 
> > > How many? If it is in the 120 range, then every access from i2cdetect
> > > fails with it.
> > 
> > When I run i2cdetect on the i801 controller, on one invocation I count
> > 111 repetitions of the "SMBus is busy, can't use it!" error once, then
> > on another invocation I count 112 repetitions.
> 
> Okay, as expected, this is more or less one BUSY condition per address
> scanned.
> 
> > When the kernel's i2c bus arbitration retry logic kicks in, it appears
> > to be able to eventually complete the operation successfully before the
> > i2c core driver code gives up because otherwise I would expect i2cdetect
> > to exit prematurely and report an error.
> 
> It would mark that address as "XX" if there was an error. As it prints
> "--", it indeed indicates that the retry could have succeeded.
> 
> > Wolfram, if you or any other kernel developers think this may be
> > indicative of some underlying issue, I'm happy to investigate further
> > and report back. I'm using a Dell XPS 14 DA14260 laptop.
> 
> Thank you, but sadly I am not the right person to ask. My expertise is
> the embedded sector. I don't know much about laptops, ACPI, and how the
> management processors play in the game. My assumption would be that the
> BUSY state has something to do with the latter. But maybe Andy knows?

ACPI should have nothing to do with DDR5 sensors. Otherwise it is something
new to me.

-- 
With Best Regards,
Andy Shevchenko