openbmc.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Jeremy Kerr <jk@codeconstruct.com.au>
To: Zev Weiss <zweiss@equinix.com>
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 12:04:05 +0800	[thread overview]
Message-ID: <1df72fd584f9c54544f9d5fafcd6232e3079ee49.camel@codeconstruct.com.au> (raw)
In-Reply-To: <20210910034958.GE17315@packtop>

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


  reply	other threads:[~2021-09-10  4:04 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 [this message]
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=1df72fd584f9c54544f9d5fafcd6232e3079ee49.camel@codeconstruct.com.au \
    --to=jk@codeconstruct.com.au \
    --cc=andrew@aj.id.au \
    --cc=eajames@linux.ibm.com \
    --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).