From owner-svn-src-all@freebsd.org Mon Jan 22 19:27:06 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 82CB1ED1558 for ; Mon, 22 Jan 2018 19:27:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 4F17F6A4A1 for ; Mon, 22 Jan 2018 19:27:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22b.google.com with SMTP id 196so10971526iti.5 for ; Mon, 22 Jan 2018 11:27:06 -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=ipiFz0MulOIP2+PANkqQ8XBpoe8gU8WWWkanuqJnM14=; b=nEcjiiRt+FmbDPB3tLepIIcZIPOVbHBYWZtLxiq2RQdg+R1AEkQYuVu0iqOMQPd6ZQ IXACdcu5pq3jGH12R7Q24z2t6hbewSv25CewwsIOZ+sZh32fU6t2PwtS76xpeJ4c25Vk sLJcolIc/o9GnXRbkLDv7sw8bBqp/7E5H4UFYeckdgsNMZyLwM16Mn5jKR0NW8BQH1np PNVllAFdBMyh/FHgulYSSEGgwY5jv7RqqMil4F4FD4IuAI7B8mB5DBRqwWhzckLBCb7l yJQyUWqcoeBjYR+8sDYtKZNlgq3Qpv3HCsGtLbmEQ7Ru4qHrb94NH1c9psqGWeTJhdxD pd4w== 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=ipiFz0MulOIP2+PANkqQ8XBpoe8gU8WWWkanuqJnM14=; b=BOpdQZ4Kb6Kc17lz1aJl+8HT+K8PA2iguZ/COU3f24U6KyQdCadh5KRFjHRpPbvwMP L+H59kv1hfXtiuFa1eMg98Ca83BlWm/CEcEtxt+AnYDgIepuerXQ6T8MGSy4o/W1V+LH vs8cQSo08XHpilbfGBrMJK5sqpmQJ4ktDwGlJzsU3M4yGHvdbJNclDkSdoeBM8hd3i7p SgmTfS2nYjYvG3ZBP7PIqdSmYh9xlo1WbAvCIJtd8THwAj/ISehUqi8Is6lE9SCjTupr mLjqIzy2l6Is5M8lBCh4t1IwsYwG0cpMc9OFa2P7VB/5Cbo4ozqGCkzWZFy3sEImhSKZ sBdQ== X-Gm-Message-State: AKwxytcW0djuqx0iQpjr5m9vCXww9KR563h8yfZ3SD1u6h4Hv7UGCEyb 4Z2HYbu4BHhYEwYHoY0p7ldw9ROilxU56qBONYomzA== X-Google-Smtp-Source: AH8x226iDeZF22TXHMslTFz8joZfKWbkqG8VDf0NO3peiPSBPcAxC4SWBHybfCL4nCOPhLpGfYA0TWSFR3ghyqgwzQU= X-Received: by 10.36.104.210 with SMTP id v201mr8925403itb.64.1516649225458; Mon, 22 Jan 2018 11:27:05 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.201.67 with HTTP; Mon, 22 Jan 2018 11:27:04 -0800 (PST) X-Originating-IP: [50.227.106.226] In-Reply-To: <1516648363.42536.134.camel@freebsd.org> References: <201801220710.w0M7AUm9091853@repo.freebsd.org> <88258.1516630050@critter.freebsd.dk> <20180122153003.664e1613bbf70ab49c5c1541@bidouilliste.com> <52374125.OgxafgljNu@ralph.baldwin.cx> <1516648363.42536.134.camel@freebsd.org> From: Warner Losh Date: Mon, 22 Jan 2018 12:27:04 -0700 X-Google-Sender-Auth: TKfqPeGzzRVuitu-QNHRSglzg30 Message-ID: Subject: Re: svn commit: r328257 - in head/sys: arm/broadcom/bcm2835 dts/arm modules To: Ian Lepore Cc: John Baldwin , Emmanuel Vadot , Poul-Henning Kamp , 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: Mon, 22 Jan 2018 19:27:06 -0000 On Mon, Jan 22, 2018 at 12:12 PM, Ian Lepore wrote: > 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.) > Yes. There's several issues here. The first issue is that RPi is the only popular platform[*] that doesn't do pinctl/pinmux per the FDT standards. So hacks here aren't any worse than what's there now, but they will be ripped out with extreme prejudice when pinmux arrives. The next issue is that RPi doesn't have the proper clock management hooked into our clock framework. That needs to be properly fixed. The next issue is that you need to change the state of the device by an overlay. This will allow pinmux to work (well, would if we had a proper pinmux driver). In the FDT world, you'd need to transition between two different states. To do this dynamically at runtime (which we all agree is desirable), we need to create the proper protocols so that if, say, a GPIO is deactivated that any users are notified. This is a lot trickier than you might think because there can be a cascade of dependencies that need to be notified of the change. And that's tough. So this is a lot more complicated case than the old-devices where devctl enable/disable was more than enough to do things. This is a DAG of change, not a single bit flip. Warner