All of lore.kernel.org
 help / color / mirror / Atom feed
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 05:28:36 +0000	[thread overview]
Message-ID: <20210910052835.GF17315@packtop> (raw)
In-Reply-To: <1df72fd584f9c54544f9d5fafcd6232e3079ee49.camel@codeconstruct.com.au>

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

  reply	other threads:[~2021-09-10  5:29 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 [this message]
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=20210910052835.GF17315@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.