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 17:08:40 +0800	[thread overview]
Message-ID: <a2c3598e977a6283a9e65f3f29a74fe55d12ca20.camel@codeconstruct.com.au> (raw)
In-Reply-To: <20210910083542.GH17315@packtop>

Hi Zev,

> Sorry, which semantics exactly do you mean we might not want to
> change? It sounded like Oliver thought that interpretation of
> "reserved" should be viable, modulo some possible bus-specific
> caveats...

At the moment (as you've noticed), status = "reserved" does not
instantiate the device. For what you're proposing here, we'd need to
change that: "reserved" would instantiate the device, but suppress the
probe. I'm not sure what might break if were were to make that change.

> Well, I'm aiming to be able to use a dts fragment looking something
> like (on an ast2500):
> 
>   &spi1 {
>         status = "reserved";
>         pinctrl-names = "default";
>         pinctrl-0 = <&pinctrl_spi1_default>;
>         flash@0 {
>                 status = "okay";
>                 label = "bios";
>                 m25p,fast-read;
>         };
>   };

[do you want just the flash node to be reserved, or the entire
controller? I assume the controller is always available...]

> ...but I'm wondering about your mention of "rather than instantiating
> entirely from userspace" -- is there some mechanism for
> runtime-materializing a device ex nihilo that I've remained
> (embarrassingly) unaware of?

It depends on the bus; we can instantiate (and bind) i2c devices with
something like:

 # echo tmp75 0x50 > /sys/bus/i2c/devices/i2c-7/new_device
         ^    ^
	 |    i2c addr
	 |
	 i2c device id

- which requires no DT node at all.

But on a quick check, it looks like there's no equivalent facility for
SPI (which makes sense, as there's likely to be additional platform data
required for most devices..)

Cheers,


Jeremy


  reply	other threads:[~2021-09-10  9:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-10  2:24 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 [this message]
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=a2c3598e977a6283a9e65f3f29a74fe55d12ca20.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 \
    --subject='Re: [PATCH RFC] Specifying default-disabled devices' \
    /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

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