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

[David Brownell]

On Tuesday 11 December 2007, Jon Smirl wrote:
> I think i2c_client.name should be removed in new drivers, it is
> redundant with the new aliasing code. I was leaving it alone so that
> old style drivers would continue to work.

It's not redundant ... and it's been around forever, as I recall.

Plus, it's the most specific type ID in the i2c_client/device struct;
it's what distinguishes variants of mostly-compatible chips.  New-style
drivers can use it to figure out what options to use.


> >  - 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?
> 
> There is an external committee that sets the names used in open
> firmware. I personally don't like the vendor,device scheme but that's
> what the committee says to use.

So all names with commas should follow those OF rules?
Are there other schemes that Linux drivers would need to
know about?  Regardless, this needs documentation...


> These names are usually in __init sections. We could add macros to
> remove them on other platforms but is it worth the effort?

Huh?  MODULE_DEVICE_TABLE() entries are rarely in init sections.
They have to stick around for binding at runtime.  In the case of
I2C, when an adapter module gets loaded after init sections get
removed, the drivers must stiill be able to work.

 
> >  - 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.
> 
> I'm open to better schemes on implementing this on non-open firmware
> platforms. If we don't do this on powerpc we are stuck with an ever
> expanding table in the powerpc code mapping from of names into kernel
> names.

I don't follow what you're saying here.  It works today on
non-OF systems, so you don't need to change that part.  You
don't need to break that to support OF better.  Think of it
this way:  driver without ID tables work today, and there's
no reason they shouldn't continue to work.


> I think this mapping should go into the individual drivers so 
> that we don't end up with a 1,000 entry table in the powerpc code. The
> name translation problem exists in other subsystems like ALSA.
> 
> When complete this code should allow autoloading of i2c and ALSA
> modules from the powerpc device trees.

And I don't see how that relates to my comment above.  The driver
name is "rtc-ds1307", so why should that need to be listed a second
time in the ID table?

 
> > 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?
> 
> I haven't run into a problem yet. Vendor usually don't use the same
> part numbers as another vendor. It is too confusing when trying to buy
> parts.

But not all the names are part numbers.  So what's preventing one of
the other names from overlapping the part number namespace?  Or vice
versa?

You seem to be arguing for a completely free-form unmanaged mess.
If that's not really what you're thinking, I'd hope you would then
agree that those identifiers are then deeply under-specified...


> > 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.
> 
> There aren't that many new style drivers in the kernel, less than 15.
> It's not hard to update them. I offered to do it as part of this
> series if the series is accepted. I've already fixed five. It only
> takes about ten minutes to update a driver.

There are other out-of-tree drivers, and ones headed into the tree.
And then there's board setup code that sets up the devices so those
divers work right...  Best to make any *required* changes be small,
and make them much less likely to break anything.


> > 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?
> 
> Because i2c should stop using it's own schemes when generic kernel
> solutions exist.

But the thing is:  you're adding an I2C-only scheme.  PCI or USB
can't use this code at all.  So why not add this I2C-only scheme
in a way that won't break existing code?

- Dave