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

[Poul-Henning Kamp]

--------
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 ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.