From owner-svn-src-all@freebsd.org Mon Jan 22 23:54:22 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5E80CEB8353; Mon, 22 Jan 2018 23:54:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 390D575515; Mon, 22 Jan 2018 23:54:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (astound-66-234-199-215.ca.astound.net [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id D217F10A87D; Mon, 22 Jan 2018 18:54:19 -0500 (EST) From: John Baldwin To: Poul-Henning Kamp Cc: Warner Losh , Ravi Pokala , Emmanuel Vadot , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r328257 - in head/sys: arm/broadcom/bcm2835 dts/arm modules Date: Mon, 22 Jan 2018 15:54:05 -0800 Message-ID: <2987003.eeGRFBb6N8@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <90451.1516663240@critter.freebsd.dk> References: <201801220710.w0M7AUm9091853@repo.freebsd.org> <90451.1516663240@critter.freebsd.dk> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Mon, 22 Jan 2018 18:54:19 -0500 (EST) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 23:54:22 -0000 On Monday, January 22, 2018 11:20:40 PM Poul-Henning Kamp wrote: > -------- > In message > , 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