[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