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

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

+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