@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?