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 
SI_ORDER to use as an extra argument).  The typical practice is to load the 
driver (the one that attaches highest up the device hierarchy) "last" so that 
other drivers are registered once it tries to attach.  For example, in xl(4) 
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,
DRIVER_MODULE(miibus, xl, miibus_driver, miibus_devclass, NULL, NULL);


This probably needs to be fixed in all of the smbus controller drivers.

John Baldwin
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to