i2c and indirect vs. direct config

[Martin Husemann <martin%duskware.de@localhost>]

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