On Wednesday, September 07, 2016 01:40:56 PM Andriy Gapon wrote: > > Has kldload intpm ever worked? > Ditto for other smbus drivers. > > The reason I am asking is that it doesn't work for me on the latest head. > And it doesn't work because device_probe_and_attach(sc->smbus) fails in > intsmb_attach(). > > With a little help from DTrace I obtained the following output: > CPU ID FUNCTION:NAME > 0 41924 devclass_add_driver:entry devclass = 0xfffff8000675b700, > name > = pci, driver = 0xffffffff832ed058, name = intsmb > > 0 32121 device_probe_child:entry > parent = 0xfffff8000af78100, nameunit = intsmb0, devclass = > 0xfffff8001d955880, > name = intsmb, driver = 0x0, name = <none> > child = 0xfffff8001d933500, nameunit = smbus1, devclass = 0xfffff8001d955780, > name = smbus > > kernel`device_probe+0x9d > kernel`device_probe_and_attach+0x2e > intpm.ko`intsmb_attach+0x651 > kernel`device_attach+0x41d > kernel`pci_driver_added+0xed > kernel`devclass_driver_added+0x7d > kernel`devclass_add_driver+0x144 > kernel`module_register_init+0xb0 > kernel`linker_load_module+0xc88 > kernel`kern_kldload+0xa7 > kernel`sys_kldload+0x5b > kernel`amd64_syscall+0x2db > kernel`0xffffffff80e918ab > > 1 41924 devclass_add_driver:entry devclass = 0xfffff8001d955880, > name > = intsmb, driver = 0xffffffff832ee930, name = smbus > > My interpretation is that intsmb_attach() is called before the smbus driver is > associated with the intsmb devclass. That means that the devclass does not > have > any drivers at all when intsmb_attach() calls device_probe_and_attach() on its > smbus child. It's too late when the smbus driver is added to the intsmb > devclass. > > Okay, writing the above gave me an idea to try to change the order of > DRIVER_MODULE() lines in intpm.c and that fixed the problem. > > But I seem to recall that some years ago kldload intpm worked without the > change. Perhaps the order has changed in the module loading code. > Anyway, this seems to be very subtle and error prone. I wonder if we could > make > it more robust.
You can request a specific ordering via DRIVER_MODULE_ORDERED (you can specify the SI_ORDER to use as an extra argument). The typical practice is to load the "base" driver (the one that attaches highest up the device hierarchy) "last" so that all other drivers are registered once it tries to attach. For example, in xl(4) this is used to to have the PCI attachment register last so that the miibus driver is registered when xl0 attaches: DRIVER_MODULE_ORDERED(xl, pci, xl_driver, xl_devclass, NULL, NULL, SI_ORDER_ANY); DRIVER_MODULE(miibus, xl, miibus_driver, miibus_devclass, NULL, NULL); DRIVER_MODULE() uses SI_ORDER_MIDDLE by default. This probably needs to be fixed in all of the smbus controller drivers. -- John Baldwin _______________________________________________ email@example.com mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"