From: Zev Weiss <zweiss@equinix.com>
To: Jeremy Kerr <jk@codeconstruct.com.au>
Cc: Andrew Jeffery <andrew@aj.id.au>,
"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
Eddie James <eajames@linux.ibm.com>
Subject: Re: [PATCH RFC] Specifying default-disabled devices
Date: Fri, 10 Sep 2021 03:49:58 +0000 [thread overview]
Message-ID: <20210910034958.GE17315@packtop> (raw)
In-Reply-To: <71375410db4f03bd19c820f97f3a23418b56ecc0.camel@codeconstruct.com.au>
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
next prev parent reply other threads:[~2021-09-10 4:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-10 2:24 [PATCH RFC] Specifying default-disabled devices Zev Weiss
2021-09-10 2:33 ` Jeremy Kerr
2021-09-10 3:49 ` Zev Weiss [this message]
2021-09-10 4:04 ` Jeremy Kerr
2021-09-10 5:28 ` Zev Weiss
2021-09-10 7:59 ` Jeremy Kerr
2021-09-10 8:35 ` Zev Weiss
2021-09-10 9:08 ` Jeremy Kerr
2021-09-10 21:59 ` Zev Weiss
2021-09-21 2:56 ` Zev Weiss
2021-09-10 4:36 ` Oliver O'Halloran
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210910034958.GE17315@packtop \
--to=zweiss@equinix.com \
--cc=andrew@aj.id.au \
--cc=eajames@linux.ibm.com \
--cc=jk@codeconstruct.com.au \
--cc=openbmc@lists.ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).