From owner-svn-src-head@freebsd.org Tue Jan 23 14:47:43 2018 Return-Path: Delivered-To: svn-src-head@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 027A4ED7434 for ; Tue, 23 Jan 2018 14:47:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9726D7F0F1 for ; Tue, 23 Jan 2018 14:47:42 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-wm0-x233.google.com with SMTP id x4so22335388wmc.0 for ; Tue, 23 Jan 2018 06:47:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Ogxy/K+eh/7vFG8vPVHq0vVuc6t5+f+VqwSyhOipMnY=; b=CVBJ7qdoKcwi0naHN3tFWgOx0dwvtfPsCB5nxmXrxTKR+UzDM9S/YxcrSkL7IoJAM9 WUbQIHNBB/2IEfV+g6/PlQ+JkRXq5/wJKf+71n1++6kXet91Hpe5h706AFfKs9GhFqxG zVGPhv3Fi96V/jNuoo6LFcrYwK4kSKw/CjJuMXjDe06qmmd6sLQ0PhOmyVwO21Znp9Ve B19MCeg8mgETEDAeZffxpM4V+tx1kdQuwBLxjwz8CqayJ8UfH4AnctqRVShnq3EZPxMD qMb4ivJE2HtsoNbjBNIerh7K1lIkiL3r+/Av4Esu6sPPpQOnGDEdWEPLcpWP6UX7+wNR r9zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Ogxy/K+eh/7vFG8vPVHq0vVuc6t5+f+VqwSyhOipMnY=; b=H+BiRYmKiNJV7jhXTH71LLDmBfgLiQ9oBzZQgN4dwi5hufCVCCphqZQugE6FzLWn31 6WsOirnufzKykBnVy6+vpuUQpEsCla87veWS9/hU3ruGdJSRyUrIKHz6q/sVmuaV96yj bco2rOsIcPoR4hGn+zbzzbTA5s0ARaq2HE+0jHLK1PxNS8UbNSuus+56Uso4jjIY8X5f hJBnJutXmSK3S5asUJVIs3PMkZAhmDvVpBSh0nuJwmatJQPTbLxRRQqo76WVNHxoyino n7HKaGG7YRgav1salWyGGpB7zvyhNs/KDPQNxwgjYJNFiKwgriP785OzZ25ud3CX9CkS NMSQ== X-Gm-Message-State: AKwxytcZEk2FbRKnJKqwXDW6vXCNRt8nxZ2OkRy+9cD4sjThaKRqbVt/ gmDJ9LYdRgJUAYsxzUc4pZqW+Lhxmg3DK6w6gFmx6w== X-Google-Smtp-Source: AH8x226+++GK6ErxEkVQP1Wdu5A+XnopcUbJT2vcdOc7Kh/2koPwBB4OI/SKZZt4Suo0sMzFr1QMDP9PxL/K5owcRTA= X-Received: by 10.80.217.202 with SMTP id x10mr13747515edj.118.1516718860525; Tue, 23 Jan 2018 06:47:40 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.80.133.195 with HTTP; Tue, 23 Jan 2018 06:47:40 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: <2987003.eeGRFBb6N8@ralph.baldwin.cx> References: <201801220710.w0M7AUm9091853@repo.freebsd.org> <90451.1516663240@critter.freebsd.dk> <2987003.eeGRFBb6N8@ralph.baldwin.cx> From: Warner Losh Date: Tue, 23 Jan 2018 07:47:40 -0700 X-Google-Sender-Auth: cyxzoRthe1T1_Tr_GhSOlyAupQk Message-ID: Subject: Re: svn commit: r328257 - in head/sys: arm/broadcom/bcm2835 dts/arm modules To: John Baldwin Cc: Poul-Henning Kamp , Ravi Pokala , Emmanuel Vadot , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2018 14:47:43 -0000 On Mon, Jan 22, 2018 at 4:54 PM, John Baldwin wrote: > On Monday, January 22, 2018 11:20:40 PM Poul-Henning Kamp wrote: > > -------- > > In message 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. > I'm actually thinking the right thing is to remove the checks everywhere. We then create a couple of new simplebus methods: int ok_for_state(device_t dev, const char *state) which returns 0 if the device should be enabled in this state, or an errno for why not. It's called on boot and if it returns true, the device will be attached. Defaults to something akin to ofw_bus_status_okay. Devices can override this for whatever reasons they may need to. int change_state(device_t dev, const char *old_state, const char *new_state) which tells the device we're entering a new state. The device is expected to cope. The default is to call ok_for_state and return that result. By default, if there's an error in the new state, the device's detach routine will be called. Devices are free to override this. This will allow us to do things like load overlays at runtime that change the status of devices (and maybe pinmux items) and have an ordered way to cope. It will also allow us to implement a policy of 'all devices must be cool with the new state or the overlay is rejected'. If we do that, then devmatch will work like everywhere else. Otherwise you'll have the frustrating situation where you kldload foo, see nothing and have devmatch tell you to load foo... Warner