[PATCH RFC] Specifying default-disabled devices

Zev Weiss zweiss at equinix.com
Fri Sep 10 13:49:58 AEST 2021


On Thu, Sep 09, 2021 at 07:33:42PM PDT, Jeremy Kerr wrote:
>Hi Zev,
>
>> I'd like to hear people's thoughts on how to approach specifying that
>> a device is present, but should be left alone by default.
>
>Sounds good!
>
>> The other alternative I've considered (though not actually implemented
>> thus far) is to start using the "reserved" status value defined in the
>> device-tree spec (section 2.3.4, [0]) to mean this
>
>I'd prefer this approach - it seems quite neat, and means we can keep
>the hardware definitions together.
>

Yeah -- I'm still on the command-line approach at the moment basically
just because it was the first thing that occurred to me and has worked
well enough so far for my purposes, but I think I'd agree that the
"reserved" option seems more desirable overall.

However, I think I may have spoken too soon regarding the relative
simplicity of implementing it -- from a quick glance at it, I think I'd
want to take of_device_is_available() and split it into some variants
for strictly-okay and okay-or-reserved (and similarly for
of_get_next_available_child()).  The problem there is that there are
currently circa 200 callers of those functions scattered thoughout the
tree, and auditing each of them individually to determine which of those
semantics is actually appropriate in each case seems...a bit daunting.

>Do you have thoughts about how you'd then un- and re-reserve the device?
>

I hadn't been thinking of being quite that ambitious with it, I figured
it'd basically just get used as a boot-time-only flag like my noautobind
argument, and beyond that it would just remain reserved, leaving it up
to userspace to take it in and out of use via bind/unbind operations.
AFAIK the fdt is (outside of things like DT overlays and such that I
don't think have ever hit mainline) currently an entirely read-only data
structure at runtime, and I'm not sure what ramifications there might be
to introducing runtime mutations...possibly not a big deal though?


Zev


More information about the openbmc mailing list