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

[Kyle Evans]

On Mon, Jan 22, 2018 at 1:27 PM, Warner Losh <imp at bsdimp.com> wrote:
> On Mon, Jan 22, 2018 at 12:12 PM, Ian Lepore <ian at 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 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.)
>>
>
> 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.
>

FWIW- The mainline Linux guys are trying to fight this problem by way
of major restriction. My understanding is that as of now, they're
planning to restrict what kind of overlays can be applied at runtime
to things that adhere to a kind of connector protocol, and the
overlays aren't really allowed to access on-board resources beyond
what the connector already provides. Flipping these connectors on or
anything besides attaching to a connector would need to be an overlay
applied at boot time, and those cannot be unapplied.