Date: Mon, 22 Jan 2018 12:27:04 -0700 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@freebsd.org> Cc: John Baldwin <jhb@freebsd.org>, Emmanuel Vadot <manu@bidouilliste.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r328257 - in head/sys: arm/broadcom/bcm2835 dts/arm modules Message-ID: <CANCZdfqce1FnuxxUzfVWA0KLz4DpJmJLkA%2BuMtopWMLjR_q1uQ@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 22, 2018 at 12:12 PM, Ian Lepore <ian@freebsd.org> 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" <phk@phk.freebsd.dk> 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 <blah>' > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqce1FnuxxUzfVWA0KLz4DpJmJLkA%2BuMtopWMLjR_q1uQ>