Date: Mon, 22 Jan 2018 15:54:05 -0800 From: John Baldwin <jhb@freebsd.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Warner Losh <imp@bsdimp.com>, Ravi Pokala <rpokala@mac.com>, Emmanuel Vadot <manu@bidouilliste.com>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r328257 - in head/sys: arm/broadcom/bcm2835 dts/arm modules Message-ID: <2987003.eeGRFBb6N8@ralph.baldwin.cx> In-Reply-To: <90451.1516663240@critter.freebsd.dk> References: <201801220710.w0M7AUm9091853@repo.freebsd.org> <CANCZdfpq2QoG4EAj0VW2FF=4VXRv-qQKFfJTJerWH9YOwVoVBA@mail.gmail.com> <90451.1516663240@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, January 22, 2018 11:20:40 PM Poul-Henning Kamp wrote: > -------- > In message <CANCZdfpq2QoG4EAj0VW2FF=4VXRv-qQKFfJTJerWH9YOwVoVBA@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2987003.eeGRFBb6N8>