Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 22 Jan 2018 10:57:28 -0800
From:      John Baldwin <jhb@freebsd.org>
To:        Emmanuel Vadot <manu@bidouilliste.com>
Cc:        Poul-Henning Kamp <phk@phk.freebsd.dk>, 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:  <52374125.OgxafgljNu@ralph.baldwin.cx>
In-Reply-To: <20180122153003.664e1613bbf70ab49c5c1541@bidouilliste.com>
References:  <201801220710.w0M7AUm9091853@repo.freebsd.org> <88258.1516630050@critter.freebsd.dk> <20180122153003.664e1613bbf70ab49c5c1541@bidouilliste.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52374125.OgxafgljNu>