> If not, it may make sense to add a helper function exposing
> __i2c_first_dynamic_bus_num to drivers (something like
> i2c_is_dynamic_bus_num().) After all, i2c_add_numbered_adapter() mostly
> makes sense if static i2c device definitions exist. If not,
> i2c_add_adapter() is just as good. So something like:
>
> if (i2c_is_dynamic_bus_num(i))
> ret = i2c_add_adapter(pch_adap);
> else {
> pch_adap->nr = i;
> ret = i2c_add_numbered_adapter(pch_adap);
> }
>
> may make sense. Unless someone has a better idea.
PASEMI does:
smbus->adapter.nr = PCI_FUNC(dev->devfn);
I am unsure if there is any guarantee in what order PCI_FUNCs are
probed, yet I have the feeling we could try a little harder to get the
numbered adapter. What about this (untested, just to get the idea)?
static inline int i2c_add_adapter_try_numbered(struct i2c_adapter *new_adap)
{
int ret;
struct i2c_adapter *old_adap = i2c_get_adapter(new_adap->nr);
if (old_adap && new_adap->nr >= __i2c_first_dynamic_bus_num) {
i2c_put_adapter(old_adap);
dev_dbg(&new_adap->dev, "Static bus number occupied, trying dynamic number\n");
ret = i2c_add_adapter(new_adap);
} else {
ret = i2c_add_numbered_adapter(new_adap);
}
return ret;
}
I used 'static inline' because I think the drivers needing this should
carry the extra weight. But no major objection to put sth like this also
into the core. The documentation for this function should carry a big
note that this is only a workaround and it should not be used directly.
Thoughts?
Wolfram
Attachment:
signature.asc
Description: PGP signature
