Hot-plugging non-sensor devices on non-PnP buses (was: Re: entity-manager: SBTSI and hwmontempsensor)

[Zev Weiss]

On Tue, May 09, 2023 at 12:40:26AM PDT, Paul Fertser wrote:
>Hi Zev,
>
>Thank you for answering. A quick additional point inline.
>
>On Mon, May 08, 2023 at 03:46:13PM -0700, Zev Weiss wrote:
>> On Fri, May 05, 2023 at 02:23:06AM PDT, Paul Fertser wrote:
>> > What further complicates situation with leds-pca955x specifically is
>> > that it /needs/ DT or platform data to work, and that makes it try
>> > binding automatically on startup, and probe() fails while the host
>> > system is off, and "new_device" sysfs node can't be used to retry (as
>> > the device is already defined), so either the driver needs to be
>> > modular and reloaded with essentially rmmod/insmod sequence or the
>> > userspace can use sysfs "bind" node to call probe() again (this is
>> > also problematic with entity-manager as $Address template argument
>> > isn't suitable for a string like 5-0019, where 19 is in hex).
>> >
>>
>> This seems like the trickier part to me.  AFAIK the kernel as it stands
>> doesn't really offer any way of specifying any of the additional parameters
>> that DT properties and such can provide when dynamically instantiating
>> devices, so if you need any non-default configuration your only option is a
>> statically-defined device (via a DT node), and if that's not an option
>> because you need dynamic instantiation then you're kind of out of luck
>> unfortunately.
>
>Dynamic instantiation is still possible either by having the
>corresponding kernel driver modular 

True to an extent, though it's rather more of a blunt instrument, since 
it's a per-driver operation instead of per-device (it's a different 
operation that happens to trigger the desired behavior as a side-effect, 
I'd say).

>or by using "bind" and "unbind"
>sysfs nodes.

Ah right, I'd forgotten about that one -- I actually sent some patches 
upstream to try to make that mode work a little more gracefully a while 
back (adding a way of preventing automatic driver-bind on boot so it 
would only be done when explicitly requested), but never arrived at 
anything that all the relevant maintainers approved of.

Also (this is arguably somewhat pedantic, but for the kinds of things we 
might end up dealing with perhaps relevant): while it is at least 
operating at the same per-device granularity, bind/unbind is still 
semantically a distinct operation from true dynamic instantiation 
though.  For a bind operation you need an extant device to attach a 
driver to, whereas the i2c new_device operation actually creates a new 
thing that wasn't previously there.  There are many cases where 
bind/unbind might be sufficient, but in other scenarios it might not be.

>In this specific case we tested having the driver
>built-in, it tries binding on BMC startup, fails if the host is off,
>then at any point of time one can do "echo 5-0019 >
>/sys/bus/i2c/drivers/leds-pca955x/bind" and it'll re-try binding, and
>that works if the host is on at the moment. And of course it can be
>"unbind" later if needed. This could even almost work with current
>entity-manager code if it was listening for host power state events,
>if it wasn't skipping the devices that it already tried exporting, and
>if it had something like $HexAddress for the template arguments.
>

Perhaps that's something worth experimenting with and posting E-M 
patches for?  Though the "bouncing off the guardrails" aspect (the 
futile bind attempt on boot) is a bit unfortunate of course...and it 
might need some additional consideration of what happens if the host 
_does_ happen to be powered on when the BMC boots (and the boot-time 
bind succeeds instead of failing).


Zev