On Thu, 7 Jun 2012, Tony Lindgren wrote: > * Paul Walmsley <paul@xxxxxxxxx> [120607 00:44]: > > On Thu, 7 Jun 2012, Tony Lindgren wrote: > > > > > Here too I think driver like features like this should live in the > > > driver init for omap OHCI driver. In the likely case that FS OHCI is > > > not in use on the board, the OHCI glue can just reset it. > > > > What if the driver is not compiled into the kernel, but instead is built > > as a loadable module? > > You can still have a core piece of the driver that's always built in, such > as omap-ohci-common. But it should live under drivers, not in the bus level > code. Or you can insmod/rmmod it to reset things properly. Do you know of any device drivers that do this now, with a core built-in piece separate from a dynamically loadable part? Seems like it would be tricky to avoid linking in the entire driver, due to the symbol dependencies. Either that, or an extra, largely useless, layer of indirection would be needed in the shim layer. - 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
