From: "Oliver O'Halloran" <oohall@gmail.com>
To: Zev Weiss <zweiss@equinix.com>
Cc: Andrew Jeffery <andrew@aj.id.au>,
Jeremy Kerr <jk@codeconstruct.com.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 14:36:16 +1000 [thread overview]
Message-ID: <CAOSf1CGx_r4B2nfR+G9fRBrspBHT+cM3tT8930F1c5T+0i7FKA@mail.gmail.com> (raw)
In-Reply-To: <20210910022433.GD17315@packtop>
On Fri, Sep 10, 2021 at 1:30 PM Zev Weiss <zweiss@equinix.com> wrote:
>
> 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 -- from the wording in the spec it seems
> like a not-terribly-unreasonable interpretation, and the existing kernel &
> u-boot fdt code don't seem to make any use of it as far as I can see (though I
> don't know what might be out there in device-tree implementations floating
> around in other projects).
Nothing explicitly looks for status = "reserved" because Linux (and
u-boot apparently) ignore the device unless it's marked as okay. I
added the reserved state to the DTS spec since OpenPower platform
firmware was using it to mark devices that are owned by firmware
rather than the OS. I'd say the idea of having a bus device
instantiated for "reserved" devices is largely compatible with that
usage.
The one thing I'd be concerned about is what happens when the bus
itself can modify the device. For example, during PCI device probing
Linux will do some basic device configuration (enabling / disabling
various features in the PCIe caps) so you could have the OS modifying
a "reserved" device even if a driver is never attached to it. That's a
slightly academic problem for PCI since it doesn't even check the
status in the DT node, but it might be an issue for other busses.
Oliver
prev parent reply other threads:[~2021-09-10 4:37 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
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 [this message]
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=CAOSf1CGx_r4B2nfR+G9fRBrspBHT+cM3tT8930F1c5T+0i7FKA@mail.gmail.com \
--to=oohall@gmail.com \
--cc=andrew@aj.id.au \
--cc=eajames@linux.ibm.com \
--cc=jk@codeconstruct.com.au \
--cc=openbmc@lists.ozlabs.org \
--cc=zweiss@equinix.com \
/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).