We have a recentish regression in -current that stopped all i2c devices on ports like i386 or amd64 to attach.
The problem is that probing of i2c devcies is a bad idea in general and may be destructive (to the device) or hang the kernel. To avoid this, we have means to do direct config on i2c buses. This works well on machines with Open Firmware which knows about all devices connected to the i2c bus, and machines using FDT (like most modern arm ones). On all other machines we just used to do the (dangerous) indirect config in full scale, that is: the match function of all devices declared at i2c? gets called for each i2c bus. For i386/amd64 this applies to all i2c devices. Sometimes in a OF machine there are additional i2c controllers/buses, about which the firmware does know nothing. We used to use indirect config for those buses. We could, instead, have probed this from userland once and hardcoded a patch to the OF device tree. To avoid this indirect config fallback, Jared disabled this for all i2c controllers FDT knows about, assuming it would be easy to just fix FDT instead. Recently Jason ran into a problem with this (and I am not sure I properly understood it). While fixing things, he also disabled indirect config for wildcard i2c instances. Unfortunately this totally breaks i2c on i386/amd64, and it is not practically possible to hardwire "dbcool* at i2c2" or something in an x86 GENERIC kernel. I don't understand why Jason needed indirect config at all - to me it sounds the proper solution would have been to enhance the FDT for that particular machine and only use direct config. But in general Jason is right: indirect config on i2c *is* dangerous. A possible solution would be to have config flags (or device attributes) per i2c bus, which controll: - whether to use the strict indirect config semantic we have now - not to use any indirect config at all (a bus that has a full description in OF/fdt would set this) - allow arbitrary wildcard parent matches (amd64 GENERIC would use that) It would be nice to move more machines over to direct config (I am not sure how much data ACPI or UEFI provide for that), but still we need working arbitrary indirect config matches for machines with no means of direct config. Martin
