From owner-svn-src-all@freebsd.org Tue Jan 23 14:47:42 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 E447EED7433 for ; Tue, 23 Jan 2018 14:47:42 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 72C667F0EF for ; Tue, 23 Jan 2018 14:47:42 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-wm0-x22d.google.com with SMTP id j21so13786256wmh.1 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=kQNvoqO55xmZjqPjbiu1qLEmCcTrqq6eEX22AwaM+tttecarOJ3/eaTvwN3MDSGcml MsajrEV+QlZYK4ICleg6lz8I8hhoci0GCBjbepY9LhprLM8nkXdosPeNtNNUZ9YuJ7NC J+7479VnfihtXFM68OynL776lC9OqFlpLXwf6U3YgUIVEtJDtYX26ZzLm8lidYo5qF6a ga5JRLqkGcO6r2rve5/RRAcb0Ori0T+ulyxGZGzHwi60vi2h/VGZJ8HN2SvFNpURZKcb 6cGv+EikB1t0wlgHCJQdTcWAGrJQRis3/KrvVoMtk3MBAabc6jn021DQLHI0cIkZm8/X q/ag== X-Gm-Message-State: AKwxytdKWXl49Y8A6Bwp9/MZZxjbfcKYA9m5jpatIqYr1jWurDg61/nQ QE142OACVs+RmClW2HsT6LENouUrBWTbRTxxm7uW8Q== 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-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: 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