Re: Fwd: [PATCH 2/3] I2C: at24: add kernel interface for reading/writing EEPROM

[David Brownell <david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org>]

On Monday 25 August 2008, Jon Smirl wrote:
> On 8/25/08, David Brownell <david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org> 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
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c