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

David Brownell david-b at pacbell.net
Fri May 18 21:09:03 CEST 2007


On Friday 18 May 2007, Scott Wood wrote:
> David Brownell wrote:
> > On Friday 18 May 2007, Scott Wood wrote:
> > 
> >>David Brownell wrote:
> >>
> >>>I confess I don't quite follow the intent of this patch.
> >>>
> >>> ...
> 
> 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!


> >>>   (Or in the OF case, just
> >>>   have the OF glue assign them.)   And it's pointless to
> >>>   export this, given it supports calling a non-exported routine.
> >>
> >>It needs to be exported so that PCI driver modules with on-board I2C can 
> >>use it.  And what non-exported routine are you talking about?
> > 
> > 
> > i2c_register_board_info(), 
> 
> Ah.  Not exporting that was an oversight.

Was very intentional.  It's __init and defined for exclusive use
from __init section code.  Nothing else can plausibly allocate
board-global bus numbers.  Its parameters are __initdata too.


> > which is all about (main)board-specific
> > stuff.  Plus of course, it allocates numbers after the range which
> > would kick in checks for data registered by that call ... while the
> > whole point of this "pre-allocated" thing is to allow its use!
> 
> The call to i2c_register_board_info() changes 
> __i2c_first_dynamic_bus_num, so i2c_scan_static_board_info() still gets 
> called.

That wrongly assumes it could be called, though... and of course,
if you're calling that, there's no real point in the two new routines
defined in this patch.


> >>> - i2c_add_prenumbered_adapter() ... caller should just set
> >>>   adapter->number itself and call i2c_add_numbered_adapter();
> >>>   no need for a new routine.
> >>
> >>No, because it has no guarantee that the number has not been taken.
> > 
> > 
> > That "guarantee" doesn't work as intended though, so there's
> > still no point to this new routine.
> 
> How does it not work?

See above.  You're trying to use those functions contrary to spec.

- Dave




More information about the i2c mailing list