[i2c] [PATCH 2/5] i2c: Allow preallocation of I2C bus numbers.

David Brownell david-b at pacbell.net
Sat May 19 00:12:32 CEST 2007


On Friday 18 May 2007, Scott Wood wrote:
> David Brownell wrote:
> > On Friday 18 May 2007, Scott Wood wrote:
> >>I'm a little wary of registering devices after legacy drivers 
> >>(potentially sharing the same address) get probed, but in the long term 
> >>(once legacy devices go away), that sounds like a reasonable alternative.
> > 
> > You couldn't register a device that's already in the device tree.
> > 
> > So the only concern is whether your drivers, or configuration,
> > is buggy ... nothing new!
> 
> So is it considered a bug to have drivers turned on that you don't need 
> on this specific target? 

Potentially, especially with legacy drivers.


> Suppose I have a new-style 1374 driver, and an  
> old-style 1307 driver.  They both use address 0x68.  The only way for 
> the 1374 driver to get there before the 1307 driver erroneously claims 
> the device is to preregister.

In all cases, having two drivers that could bind to the
same device is potential trouble.


> >>>i2c_register_board_info(), 
> >>
> >>Ah.  Not exporting that was an oversight.
> > 
> > Was very intentional.
> 
> I meant on my part.

Then there's also all the documentation you'd need to change,
and the associated design tradeoffs to revisit ...

 
> >>How does it not work?
> > 
> > See above.  You're trying to use those functions contrary to spec.
> 
> In other words, it doesn't work the way you want it to work.
 
The framework has to address problems A and B, and it
does so using mechanisms M(A) and M(B).

You've got problem B, and you're trying to address it
using mechanism M(A).

- Dave





More information about the i2c mailing list