Bug 26342

Actually, i2c_ec SMBus driver was removed here:

commit 439a888885c584f7ac8536a43be80475f9eaed71
Author: Len Brown <len.brown@intel.com>
Date:   Thu Mar 22 01:21:05 2007 -0400

    ACPI: sbs: remove i2c_ec.[ch]

which is a few commits after the one above where the
build dependency of the smart battery driver
on I2C was removed.  Before that, the I2C SMBus
hooks in SBS were replaced by standard ACPI EC usage.

The documentation for i801_i2c is stale, of course,
referencing a driver that was deleted from Linux
almost 4 years ago...  My recollection is that the
regular EC driver was sufficient to cover that
functionality -- though I'm non an expert on that area.

Why is i801_i2c needed on this system?

You should be able to permit it to load by using
acpi_enforce_resources=lax but the warning above is
telling you that driver may be fundamentally incompatible
with the firmware on your motherboard.

*** This bug has been marked as a duplicate of bug 12376 ***

BTW, this one also shows the wrong printing of the ACPI resource recently reported by Matthew Wilcox (on irc):

[ 4867.708950] ACPI: resource 0000:00:1f.3 [io  0xe800-0xe80f] conflicts with
ACPI region SM00 [??? 0x0000e800-0x0000e806 flags 0x30]

I attach the fix for it here, so that it does not get lost and it has a bugzilla reference.

Created attachment 43252 [details]
ACPI: fix resource check output

Thanks for the pointer to the outdated documentation. I didn't remember we had this, I'll clean it up.

That being said, I still don't understand why i2c_ec was removed in the first place. Just because the sbs driver no longer needs it, doesn't mean it wasn't useful. i2c_ec could be used to access the SMBus on some systems where this is currently not possible due to the resource conflict that prevents native drivers from being used. The SMBus doesn't only host SBS, it also typically hosts SPD EEPROMs on memory modules and sometimes hardware monitoring ASICs.

As a matter of fact, we already have one driver for one of the possible ACPI implementations of SMBus: see drivers/i2c/busses/i2c-scmi.c. I'm not sure why different implementations were specified by ACPI, but as far as I can see i2c_ec.c was for a completely different implementation. So I would like to see i2c_ec.c revived as drivers/i2c/buses/i2c-acpiec.c, for systems which need it. Len, any objection?

That being said, there is no proof so far that the reporter's system would be supported by the old i2c_ec driver. Please check if "ACPI0001" (or "SMBUS01") appears anywhere in your disassembled DSDT.

Jean,
I have no objection to reviving/implementing I2C driver(s)
to implement the SMBus support in the ACPI spec
if it is useful to deliver the most value from the hardware.

I'd like to know how sbs was able to stop using it,
what the interfaces to it would have, and how devices on the
SMBus get discovered.

Oh. Look at drivers/acpi/sbshc.c. As far as I can see, it's i2c_ec, except that the interface doesn't follow the i2c subsystem standard and is thus never registered as an i2c_adapter. I guess this answers your question as to how the sbs driver gets access to the device.

It would probably be easy to add a standard i2c adapter wrapper on top of sbshc. As I seem to understand that you want to keep the 3 slave addresses dedicated to batteries private, the wrapper could filter out these addresses so that they remain internal.

Now the problem is that I don't think I have access to any system implementing ACPI0001 or ACPI0005 devices. So while I can write the code, I'll need someone else to test it.

To answer your unrelated question of SMBus device discovery, SMBus has an optional feature named ARP which can be used for device discovery, however we don't have support for this in the kernel yet. So for now we do arbitrary probing, which isn't nice but works well enough in practice.

(In reply to comment #5)
> That being said, there is no proof so far that the reporter's system would be
> supported by the old i2c_ec driver. Please check if "ACPI0001" (or "SMBUS01")
> appears anywhere in your disassembled DSDT.

Nope, all I could get are references to SM00 and SMBS But maybe I did it wrong, am I supposed to do:
$ cp /sys/firmware/acpi/tables/DSDT DSDT.dat
$ iasl -d DSDT.dat
$ less DSDT.dsl

Then search inside or am missing something?

(In reply to comment #1)
> Why is i801_i2c needed on this system?
Access to the as99127f chip in order to be able to check temperatures and voltages in the system.

Just as a side note i2c_scmi seems to be not adequate for the system :(

You did the right thing, standard SMBus implementations in ACPI BIOS are unfortunately rare.

On a board old enough to have an AS99127F monitoring chip, I would simply boot with enforce_acpi_resources=no. But better check the DSDT first to make sure the BIOS really doesn't access the I/O ports of the SMBus controller.