svn commit: r328257 - in head/sys: arm/broadcom/bcm2835 dts/arm modules

John Baldwin jhb at freebsd.org
Mon Jan 22 23:54:22 UTC 2018


On Monday, January 22, 2018 11:20:40 PM Poul-Henning Kamp wrote:
> --------
> In message <CANCZdfpq2QoG4EAj0VW2FF=4VXRv-qQKFfJTJerWH9YOwVoVBA at mail.gmail.com>
> , Warner Losh writes:
> 
> >I think even bootverbose it's insane. Or I don't understand what the real
> >ask is.
> 
> What I think would be a good idea, is when a driver is kldloaded
> the user will be told if there were hardware present which it could
> drive (ie: probe() matches), but for some reason and somehow,
> it as marked as unavailable/conflicting/disabled, so attach() didn't.
> 
> Today you load the device driver and if the hardware is "status=disabled"
> in the FDT, nothing happens, and you get no information about why
> nothing happened, leaving the user to guess...
> 
> I've seen people resort to kldload /boot/kernel/*.ko in an
> attempt to find out if were using the right device driver.
> 
> I suspect moving the boilerplate
> 
> 	if (!ofw_bus_status_okay(dev))
> 		return (ENXIO);
> 
> To the attach() function would do it, but we could avoid that
> boilerplate in all the drivers, if it was done one level up with
> a consistent device_printf() and not calling attach() at all.
> 
> What I don't know is how noisy that would be in practice ?

I think the better solution to this problem is the devmatch stuff Warner
is already working on where one can say "for this given device info
(e.g. PCI IDs or FDT properties), which drivers support this").  There
is enough of that already existing now in HEAD I think it would be better
to extend it to support whatever input mode it needs to handle disabled
devices as input to run through its existing matching engine.

-- 
John Baldwin


More information about the svn-src-all mailing list