On Thu, 12 Jan 2012, Cousson, Benoit wrote:

On 1/11/2012 4:22 PM, Paul Walmsley wrote:

quoted

On Wed, 11 Jan 2012, Cousson, Benoit wrote:

quoted

Something that puzzle me on that point is most architecture does not use
plateform_device and thus does not have any pdata to hack some custom
function
pointers here an there.
It means that there is probably some better solution to handle that.

PCI and USB have their own bus-level device reset functions that are
exported from bus code that lives under drivers/.  In a similar fashion,
we could export omap_device_reset() from our arch/arm/plat-omap code.
But that would require that arch/arm/plat-omap and arch/arm/mach-omap2
code to be compiled for any ARM build that includes i2c-omap.c.  This
would be good to avoid, under the principle that drivers should be
buildable for any architecture.  (This is also why we wish to remove
omap_{read,write}*() and cpu_is_omap() from any drivers which contain
those.)

The intention a few years ago was to eventually create a a real omap_bus
and omap_device, with the bus/device integration code living under
drivers.  In such a situation, we'd be able to use something like the
PCI/USB approach cleanly, since there wouldn't be dependencies to arch/
code.

For reset, maybe the custom bus is a better approach, since it is something
that is handled by the OMAP core infrastructure.
I was referring more to all the other function pointer we have today in driver
like MMC, DSS that does not necessarily belong to a OMAP core stuff.

Yes, that's right.  In general, cross-device dependencies with no 
infrastructural consequences should be handled by EXPORT_SYMBOL() between 
driver code.


- Paul