From owner-svn-src-all@freebsd.org Mon Jan 22 19:13:53 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 E26D1ED0C27 for ; Mon, 22 Jan 2018 19:13:53 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C501269B00 for ; Mon, 22 Jan 2018 19:13:53 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 2974b9a3-ffa8-11e7-8486-0934409070aa X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 2974b9a3-ffa8-11e7-8486-0934409070aa; Mon, 22 Jan 2018 19:12:17 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w0MJCh9F004082; Mon, 22 Jan 2018 12:12:43 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1516648363.42536.134.camel@freebsd.org> Subject: Re: svn commit: r328257 - in head/sys: arm/broadcom/bcm2835 dts/arm modules From: Ian Lepore To: John Baldwin , Emmanuel Vadot Cc: Poul-Henning Kamp , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Date: Mon, 22 Jan 2018 12:12:43 -0700 In-Reply-To: <52374125.OgxafgljNu@ralph.baldwin.cx> References: <201801220710.w0M7AUm9091853@repo.freebsd.org> <88258.1516630050@critter.freebsd.dk> <20180122153003.664e1613bbf70ab49c5c1541@bidouilliste.com> <52374125.OgxafgljNu@ralph.baldwin.cx> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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 19:13:54 -0000 On Mon, 2018-01-22 at 10:57 -0800, John Baldwin wrote: > On Monday, January 22, 2018 03:30:03 PM Emmanuel Vadot wrote: > > > > On Mon, 22 Jan 2018 14:07:30 +0000 > > "Poul-Henning Kamp" wrote: > > > > > > > > -------- > > > In message <20180122145117.08173be547f5dd6fef296732@bidouilliste. > > > com>, Emmanuel > > >  Vadot writes: > > > > > > > > > > > Using the same logic as before one could have a script starting > > > > some > > > > pwm stuff (or simply using /etc/sysctl.conf) > > > > Also this is not how DT is suppose to work, if the status == > > > > 'disabled' no driver should attach. > > > That doesn't make *any* UX sense. > > > > > > "disabled" indicates that it can be enabled, and there is > > > absolutely > > > no reason to force users to reboot, when all that stands between > > > them and using their hardware is a random setting in a file. > >  To be more clear, disabled mean that the node should not be used. > >  In a industrial board you will always have every usable node > > enabled, > > in the SBC world where you have a way to plug daughter card and > > exchange them or even use the exposed pins directly there is no way > > to > > know what the user will do so every node not used by the SBC must > > be > > disabled. > >  This is the overlay part of DT that is responsible to enable them > > > > > > > > Explicitly kldload'ing a device-driver is as clear a "Enable it, > > > please" > > > instruction as you can get from the user. > >  But device driver != DT node > I have a suggestion.  In the "hints" world we allow devices to be > disabled > via 'hint.foo.0.disabled=1' and that results in the code that creates > the > device disabling it via 'device_disable(dev)'.  This avoids having to > check > that the device is disabled in every driver.  However, we also > provide the > ability (recentish as in 10.x) to override that setting via 'devctl > enable', > so that you can now choose to enable a device that was disabled by > hints > via 'devctl enable foo0'.  I would suggest that you do something > similar for > FDT.  Create the corresponding device_t but device_disable() it when > there > is a disabled property.  A user can then use 'devctl enable ' > to enable > it before (or even after) loading a device driver. > > To make this work well you probably want to allow devctl to name > devices > via FDT handles as you can currently name them via ACPI handles or > PCI > addresses.  I can give some pointers on how to do that, though I > think the > ACPI code for that is pretty easy to follow. > The status property of an fdt node controls more than just device instantiation.  For example, it also controls whether that device's pinmux setup is done at boot time by the pinmux driver.  That's why this misguided attempt to ignore the rules and conventions for using fdt in freebsd is doomed to failure in the long run.  (It appears to be working now because the driver also incorrectly works around the lack of a proper pinctrl driver for rpi by doing its own incorrect pinctrl stuff.  That house of cards will collapse when someone eventually writes the rpi pinctrl driver.) -- Ian