On Monday 25 August 2008, Jon Smirl wrote:
> On 8/25/08, David Brownell <[EMAIL PROTECTED]> wrote:
> > My own comments on this:
> >
> > - I'd like to see at24.c use something running before
> > device_initcall, so suitably configured system can
> > have drivers calling platform_device_probe() from
> > their own initcalls and yet have access to the config
> > data from the EEPROMs.
> >
> > - Seems to me that "struct at24_iface" should be more
> > generic ... the same notion works for SPI eeproms,
> > NVRAM as found in RTCs, etc.
> >
> > Comments?
>
> Would it make sense to use bus notifiers to track the detection of a
> at24 chip?
Not to me ... but then, I'm no fan of notifiers in such cases.
Some differences associated with these setup callbacks:
- Notifiers would have to poke at the parameters to sort
out (a) BUS_NOTIFY_BOUND_DRIVER (b) with a device bound
to this specific driver, and in fact (c) which specific
devices is involved, maybe platform_data pointer checks;
and then (d) use some API that the driver exports, which
implies (e) link-time dependencies.
- setup() can be chip-specific, eliminating (a,b,c);
- at24_iface just uses function pointers, eliminating (d,e).
Architecturally, the elimination of (d,e) seems significant;
but eliminating (a,b,c) is certainly convenient when writing
code to hook it all up!
- Dave
_______________________________________________
i2c mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/i2c
