[PATCH RFC] Specifying default-disabled devices

Zev Weiss zweiss at equinix.com
Fri Sep 10 15:28:36 AEST 2021


On Thu, Sep 09, 2021 at 09:04:05PM PDT, Jeremy Kerr wrote:
>Hi Zev,
>
>> 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.
>
>I think you should be OK, if you stage it this way:
>
> - add status = "reserved" to your device tree; this will supress the
>   automatic binding right away. With the current code, all it cares
>   about is status = "okay" (or "ok"), so you'll at least keep the
>   device quiesced.
>
>   with that, there won't be an easy way to initiate the driver probe,
>   but maybe that's OK for your use-case if you're doing the bind
>   manually.
>

>From some grepping around it looks like the only check is for
"okay"/"ok", and nothing actually checks for "disabled", so I'd think
any non-OK string (including "reserved") would end up being equivalent
to "disabled", and hence result in the device node not being
instantiated at all.  (A quick test appears to confirm; with status =
"reserved", an attempt to bind via sysfs fails with ENODEV.)


Zev


More information about the openbmc mailing list