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

["Jon Smirl" <jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On 8/26/08, David Brownell <david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org> wrote:
> 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!

Another solution is call_userspace_helper. GregKH convinced me to
change some things like this to small user space apps in the graphics
code. Is is easy to do the read/write from sysfs.

It doesn't say what driver it is that wants this capability. PC based
video and network cards want to do this but in those cases the i2c bus
is located on the card.

The embedded system I'm working could probably use this. The eeprom
holding the MAC address is on the RTC chip. There is no direct way
from the network driver to change the stored MAC address. I just set
it from uboot.

-- 
Jon Smirl
jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c