[PATCHv8 4/5] OMAP: I2C: Remove the reset in the init path

[Paul Walmsley]

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

> On 1/11/2012 4:22 PM, Paul Walmsley wrote:
> > On Wed, 11 Jan 2012, Cousson, Benoit wrote:
> > 
> > > 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