Hi Greg, > > But couldn't we add a helper function to drivers/base/bus.c that the > > bus drivers can use to at least check was the bus already loaded or > > not? It looks like there are a couple of bus drivers that use the > > struct bus member "p" to check that. > > > > Greg, what do you think? > > I think your design is wrong if you need to worry about this :) This problem is not ulpi specific. We have the same issue with every single bus. With a bus like PCI it's just really unlikely to hit it because PCI bus driver uses postcore_initcall. But if there was a PCI driver that used postcore_initcall itself, maybe a gpio controller driver for example, exactly the same panic would happen that we see happening when a driver tries to register itself with ulpi bus before ulpi bus has been registered. I can appreciate now that fixing the core problem like I2C did is wrong, but I still feel that the driver core should provide something like the helper for checking if the bus was registered already or not. Otherwise all the bus drivers should really have a variable like Sudip suggested for checking it, but that would be boilerplate, no? Thanks, -- heikki -- 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
