On Mon, Dec 13, 2010 at 07:21:42PM +0800, Ming Lei wrote:
2010/12/13 Felipe Balbi <balbi@xxxxxx>:
On Mon, Dec 13, 2010 at 01:01:47AM +0800, tom.leiming@xxxxxxxxx wrote:
From: Ming Lei <tom.leiming@xxxxxxxxx>
Since hw glue drivers may depend on musb_hdrc and musb_init will return
failure if no glue device is registered, this patch fixes the issue
by registering musb_hdrc driver first.
don't do that. We want the glue layer to be registered first as it will
setup the platform_device for musb and setup the platform_data, enable
clocks, etc.
NAK
If we want to compile glue layer as module, we must load musb_hdrc
first since glue layers depend on musb_hdrc. (It is a very reasonable
model, that specific/concrete device modules depend on musb core driver,
which is more generic)
I change platform_driver_probe to platform_driver_register, which not
cause .probe of musb_hdrc called until 'musb_hdrc' device is created.
So the patch doesn't change the running order between .probe of glue and
.probe of musb_hdrc, and first is .probe of glue always, musb_hdrc .probe
is second.
So I think the patch is correct, and does make sense.
could be, but ideally, glue layer would not depend on symbols exported
by musb, it would be the other way around. Glue layer sets things up for
musb to use. So any exported symbols from musb used in glue layer should
be studied and converted into a more generic thing. All DBG() calls on
glue layer can be converted into dev_dbg(), for musb_interrupt() we can
add a 'irq' field on musb_platform_ops, similarly for read/write fifo
and the read[bsl]/write[bsl] calls, although those I think should go to
some musb_platform_io structure.
--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
