[PATCH RFC] Specifying default-disabled devices

[Zev Weiss]

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 at 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