openbmc.lists.ozlabs.org archive mirror
 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 21:59:46 +0000	[thread overview]
Message-ID: <20210910215945.GI17315@packtop> (raw)
In-Reply-To: <a2c3598e977a6283a9e65f3f29a74fe55d12ca20.camel@codeconstruct.com.au>

On Fri, Sep 10, 2021 at 02:08:40AM PDT, Jeremy Kerr wrote:
>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.
>

Any particular possible breakage outside of the possibility of busses
that might poke things independently of driver attachment as Oliver
noted?  That aside, if nothing's actually touching the hardware I'd
think the only real difference would be consuming a small amount of
additional memory.

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

The flash node would make more sense, but thus far with my noautobind
argument I've been doing it at the spi1 controller level because I don't
know of a way to do the runtime attach/detach of individual flash
devices behind the controller (the analog of doing the driver bind via
sysfs), and from a glance at the aspeed-smc driver it doesn't look like
there is one (the aspeed_smc_setup_flash() call in the controller's
probe path seems to be the only path to instantiating any child
devices).

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

Ah, right -- I've poked at that particular one for various i2c devices
before, but yeah, it's not quite so easy in the SPI case unfortunately.


Zev

  reply	other threads:[~2021-09-10 22:00 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
2021-09-10 21:59               ` Zev Weiss [this message]
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=20210910215945.GI17315@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 \
    --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).