Re: [RFC] misc/at24: add experimental OF support for the generic eeprom driver

[Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>]

On Thu, Oct 8, 2009 at 2:48 PM, Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
>
>> I think in general, this is the right direction; but I'm not convinced
>> that the right pattern or form has been found yet.  What I don't like
>> on this particular patch is that it still hooks of-specific stuff into
>> an arbitrary point in the probe routine.
>>
>> I'd like to see some pattern for retrieving or populating a
>> platform_data structure when one isn't already provided, and
>> regardless of the data source.
>
> I thought about this, too. I just wondered how many drivers would actually need
> a 'pdata'-preparation routine before probe, and if this would not cause too
> much overhead for those who don't. But as you say OF might not the only case
> where this is needed, then it might be a reasonable choice to have an extra
> call fot setting up pdata. Then again, if we have preparation routines for
> OF,UEFI,... for each and every driver, uh, the bloat :(

It shouldn't be too bad.... I'm toying with the idea of a callable
library function which is passed in a data table of the available
translators.  Can be very simple, and the library function would take
care of pdata allocation and management.  Then the translators can be
kept down to the bare minimum of populating the structure.  If it is
done right, then only the needed translators get compiled in and it
won't add any significant size at all to the drivers.

>> will take a bit of experimentation to come up with the best form for
>> the pdata fetching function, but it will be better contained if it is
>> all at a single place.
>
> I might have a try :)

:-)


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.