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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
