svn commit: r328257 - in head/sys: arm/broadcom/bcm2835 dts/arm modules

[Ian Lepore]

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 at phk.freebsd.dk> wrote:
> > 
> > > 
> > > --------
> > > In message <20180122145117.08173be547f5dd6fef296732 at 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.)

-- Ian