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 15:59:10 +0800	[thread overview]
Message-ID: <857e71679c7d1a421f6cc50896ac7927fe49cd74.camel@codeconstruct.com.au> (raw)
In-Reply-To: <20210910052835.GF17315@packtop>

Hi Zev,

> 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.)

Ah, so you still want the device created, but not bound?

That might not work for status = "reserved" then, and I'm not sure we
want to change the semantics for that.

Just so I'm following along correctly: you still need this described in
the DT (rather than instantiating entirely from userspace), because you
need additional platform data for the new device, is that correct?

Cheers,


Jeremy


  reply	other threads:[~2021-09-10  7:59 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 [this message]
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=857e71679c7d1a421f6cc50896ac7927fe49cd74.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).