[i2c] [PATCH 1/5] Implement module aliasing for i2c to translate

[David Brownell]

If you're going to do this, then scripts/mod/file2alias.c needs
updating to ensure that hotplugging still works.  Each id.name
entry needs to generate a MODULE_ALIAS(...), and there may be some
other recently defined rules to follow.  Ask Kay Sievers what they
are (and see if they'll ever get documented).

And specifically for I2C, the semantics of the new IDs really must
be documented (in Documentation/i2c/writing-clients) along with the
other details of this new MODULE_DEVICE_TABLE() facility.  Right
now it's completely undefined, which is a great formula to create
chaos!  For example:

 - Evidently part numbers are OK -- "ds1307" -- but it seems
   that case is significant ("DS1307" is different).  That's the
   right call, given I18N issues, but it should be documented.
   (Along with advice to use only lower case, IMO.)

 - Is there a relationship to i2c_client.name, which would
   normally be holding part numbers?  If not, why not; if so,
   why isn't that used in driver matching?  Drivers already
   use that string to distinguish variants...

 - Who comes up with strings like "dallas,ds1307" ... and why?
   If that's just OF-related, why is there no way to remove
   those strings on non-OF systems?

 - Why add "rtc-ds1307" as an ID when it's already listed as the
   driver.name field?  That seems like a bug in your patches.
   You're requiring driver changes even in routine cases when
   OF is nowhere in the picture.

The original scheme relied on the "only one driver can use a given
driver name" rule to enforce ID uniqueness.  Busses like PCI and USB
rely on vendor consortia to have assigned manufacturer IDs; variants
of PNP rely on a managed ID space too, as does pretty much everything
I can think of. But for I2C there is no such managed ID space...

Given this change in the I2C framework, what would now be establishing
uniqueness?

The downside I see in this current approach is that it's not just
adding capabilities needed by OF ... it's also breaking stuff that
is currently working.  Every new-style driver will need updating;
it's a "flag day" approach.

Why not add the mechanism in a way that won't break existing code,
and then add OF support in a series of incremental driver patches?

- Dave