[PATCH RFC] Specifying default-disabled devices

Jeremy Kerr jk at codeconstruct.com.au
Fri Sep 10 14:04:05 AEST 2021


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.

   There might be some bits doing their own DT parsing of the status
   property, but it sounds like you don't need to worry about those for
   now; they'd mainly be about devices' sub-nodes, and not related to
   driver binding.

 - propose a mechanism to trigger an un-reserve (and possibly
   re-reserve?), if you need.

The core code handles this for you, just setting status = "reserved"
will get you 90% there (if I've understood your use-case correctly!).

Cheers,


Jeremy



More information about the openbmc mailing list