Hi, On Thu, May 01, 2014 at 11:44:03PM +0400, Matwey V. Kornilov wrote: > 01.05.2014 23:40, Felipe Balbi пишет: > >Hi, > > > >On Thu, May 01, 2014 at 11:13:19PM +0400, Matwey V. Kornilov wrote: > >> > >>Hi, > >> > >>With the following configure options, musb_hdrc and tusb6010 make dependency > >>loop: > >> > >>CONFIG_USB_MUSB_HDRC=m > >>CONFIG_USB_MUSB_TUSB6010=m > >>CONFIG_USB_TUSB_OMAP_DMA=y > >> > >>tusb6010.ko provides function `tusb_get_revision` which is used by > >>tusb6010_omap.o which is a part of musb_hdrc.ko > >> > >>In its turn, tusb6010.ko uses much of functions provided by musb_hdrc.ko > >> > >>What could be a solution to this? > > > >don't let tusb6010_omap use any symbols from tusb6010.ko. the _omap > >variant is just an adapter for the private DMA API (should be moved to > >dmaengine, actually) and as such, it shouldn't know details about > >tusb6010 (which doesn't exactly depend on the underlying DMA). > > > > This is possible when `tusb_get_revision` is static inline function. Then we > would have to copies of `tusb_get_revision`: in tusb6010.ko, and in > musb_hdrc.ko (tusb6010_omap.o) I don't think you need that. Have tusb_get_revision() run only one during tusb6010 probe/init function and cache the returned value inside musb->revision or something like that, then remove all other calls to tusb_get_revision() and have tusb6010_omap.c check revision using if (musb->revision >= TUSB_REV30) and your problem is solved. cheers -- balbi
Attachment:
signature.asc
Description: Digital signature
