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

On Thu, Oct 8, 2009 at 2:48 PM, Wolfram Sang [off-list ref] wrote:

quoted

I think in general, this is the right direction; but I'm not convinced
that the right pattern or form has been found yet. =A0What 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 actuall=

y need

a 'pdata'-preparation routine before probe, and if this would not cause t=

oo

much overhead for those who don't. But as you say OF might not the only c=

ase

where this is needed, then it might be a reasonable choice to have an ext=

ra

call fot setting up pdata. Then again, if we have preparation routines fo=

r

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.

quoted

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 :)

:-)


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