On 6/4/08, David Brownell <[EMAIL PROTECTED]> wrote:
> On Wednesday 04 June 2008, Jon Smirl wrote:
>
> > On 6/4/08, David Brownell <[EMAIL PROTECTED]> wrote:
> > > > It then looks at that information and decides if it wants to
> > > > bind. Drivers return true/false if they want to bind.
> > >
> > >
> > > Wrong. The probe returns zero if it bound, else negative errno.
> > > Those functions don't return booleans.
> >
> > You guys are so literal. I should have said return 0 or -ENODEV or
> > some other error.
>
>
> You seemed intent on describing some new and never-seen-before
> model for how driver model probing works, though ...
I don't think it is out of the scope of what already exists. The
alternative is to add a new pre-probe() API which does the function of
the original probe and then calls the current probe(). Why don't we
just stick with probe() and use it like it was before we had things
like ACPI?
Now that we've had this discussion it looks to me that the scan
capability should be added to struct i2c_driver instead of being
standalone.
I guess what is a little strange to me is that the pre-probe()
function is like a static driver function and probe() is an instance
function. Are there other examples of static driver functions? Which
way you do it is a style question, they will both work.
Doesn't something like this work? (obviously this isn't complete)
for (address = start; address <= stop;) {
make a new client
for (; address <=stop; address++) {
client->address = address;
res = device_register(&client->dev);
if (res != -ENODEV)
break;
}
}
delete the extra client
Can these driver functions be eliminated?
int (*attach_adapter)(struct i2c_adapter *);
int (*detach_adapter)(struct i2c_adapter *);
int (*detach_client)(struct i2c_client *);
--
Jon Smirl
[EMAIL PROTECTED]
_______________________________________________
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
