[PATCH 6/9] of: add support for 'dynamic' DT property

[Zev Weiss]

Hi Frank,

Thanks for the thorough consideration on this.  (More inline below.)

On Mon, Oct 11, 2021 at 06:58:32AM PDT, Frank Rowand wrote:
>Hi Matt, Greg,
>
>On 10/8/21 1:51 PM, Frank Rowand wrote:
>> On 10/6/21 7:09 PM, Zev Weiss wrote:
>>> Nodes marked with this (boolean) property will have a writable status
>>> sysfs file, which can be used to toggle them between "okay" and
>>> "reserved", effectively hot-plugging them.  Note that this will only
>>> be effective for devices on busses that register for OF reconfig
>>> notifications (currently spi, i2c, and platform), and only if
>>> CONFIG_OF_DYNAMIC is enabled.
>>>
>>> Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
>>> ---
>>>  drivers/of/kobj.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++
>>>  1 file changed, 69 insertions(+)
>>>
>>> diff --git a/drivers/of/kobj.c b/drivers/of/kobj.c
>>> index 378cb421aae1..141ae23f3130 100644
>>> --- a/drivers/of/kobj.c
>>> +++ b/drivers/of/kobj.c
>>> @@ -36,6 +36,69 @@ static ssize_t of_node_property_read(struct file *filp, struct kobject *kobj,
>>>      return memory_read_from_buffer(buf, count, &offset, pp->value, pp->length);
>>>  }
>>>
>>> +static ssize_t of_node_status_write(struct file *filp, struct kobject *kobj,
>>> +                                    struct bin_attribute *bin_attr, char *buf,
>>> +                                    loff_t offset, size_t count)
>>> +{
>>> +    int rc;
>>> +    char *newstatus;
>>> +    struct property **deadprev;
>>> +    struct property *newprop = NULL;
>>> +    struct property *oldprop = container_of(bin_attr, struct property, attr);
>>> +    struct device_node *np = container_of(kobj, struct device_node, kobj);
>>> +
>>> +    if (WARN_ON_ONCE(strcmp(oldprop->name, "status")))
>>> +            return -EIO;
>>> +
>>> +    if (offset)
>>> +            return -EINVAL;
>>> +
>>> +    if (sysfs_buf_streq(buf, count, "okay") || sysfs_buf_streq(buf, count, "ok"))
>>> +            newstatus = "okay";
>>> +    else if (sysfs_buf_streq(buf, count, "reserved"))
>>> +            newstatus = "reserved";
>>> +    else if (sysfs_buf_streq(buf, count, "disabled"))
>>> +            newstatus = "disabled";
>>> +    else
>>> +            return -EINVAL;
>>> +
>>> +    if (!strcmp(newstatus, oldprop->value))
>>> +            return count;
>>> +
>>
>> If the general approach of this patch set is the correct way to provide the desired
>> functionality (I'm still pondering that), then a version of the following code
>
>After pondering, this approach does not appear workable to me.
>

Okay -- I had come to a similar conclusion, if for slightly different 
reasons (basically, just that the sets of "things that would avoid 
binary sysfs attr abuse" and "things that would maintain userspace 
compatibility" seemed pretty disjoint).

> <snip>
>
>So another approach is needed.  I have no yet thought this through, but I
>have an alternative.  First, change the new property name from "dynamic"
>to something more descriptive like "ownership_shifts_between_os_and_others"
>(yes, my suggestions is way too verbose and needs to be word smithed, but
>the point is to clearly state the underlying action that occurs), then
>define the result of this variable to be driver specific, where the
>driver is required upon probe to instantiate the device in a manner
>that does not impact the other user(s) of the underlying hardware
>and to use a driver specific method to transfer control of the
>hardware between the os and the other user(s).  I propose the method
>would be via a device specific file (or set of files) in sysfs (Greg's
>input invited on the use of sysfs in this manner - if I recall correctly
>this is the current preferred mechanism).
>

I'm not sure if you've had a chance to take a look at it already, but 
this sounds fairly similar to the approach I took in the semi-prequel 
series that preceded this one: 
https://lore.kernel.org/openbmc/20210929115409.21254-1-zev@bewilderbeest.net/

The general idea there was to start making use of the "reserved" status 
value (defined in the DT spec but thus far not really implemented 
anywhere that I'm aware of) instead of introducing a new property.

The implementation in that series was very driver-specific (probably 
overly so), but I think could be generalized somewhat in a couple 
directions without an enormous amount of additional work.  First 
(top-down), we could have the driver core avoid automatically binding 
drivers for reserved devices.  Second (bottom-up), the machinery 
implemented in the aspeed-smc driver in that series could be lifted into 
the MTD spi-nor framework as suggested by Dhananjay.

Rob, Greg -- do you think another version of that patch series with 
those changes might be a viable strategy?


Thanks,
Zev