openbmc.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Zev Weiss <zev@bewilderbeest.net>
To: Frank Rowand <frowand.list@gmail.com>
Cc: devicetree@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	openbmc@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	Rob Herring <robh+dt@kernel.org>,
	Jeremy Kerr <jk@codeconstruct.com.au>
Subject: Re: [PATCH 6/9] of: add support for 'dynamic' DT property
Date: Mon, 11 Oct 2021 10:35:05 -0700	[thread overview]
Message-ID: <YWR1yRmcFU66DnO5@hatter.bewilderbeest.net> (raw)
In-Reply-To: <05e4c31e-db7e-e8f2-fa37-3cdcdf902e19@gmail.com>

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


  parent reply	other threads:[~2021-10-11 17:36 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-07  0:09 [PATCH 0/9] Dynamic DT device nodes Zev Weiss
2021-10-07  0:09 ` [PATCH 1/9] sysfs: add sysfs_remove_bin_file_self() function Zev Weiss
2021-10-07  5:23   ` Greg Kroah-Hartman
2021-10-07  5:58     ` Zev Weiss
2021-10-07  6:12       ` Greg Kroah-Hartman
2021-10-07  6:55         ` Zev Weiss
2021-10-07  0:09 ` [PATCH 2/9] sysfs: add growable flag to struct bin_attribute Zev Weiss
2021-10-07  0:09 ` [PATCH 3/9] lib/string: add sysfs_buf_streq() Zev Weiss
2021-10-07  0:09 ` [PATCH 4/9] of: add self parameter to __of_sysfs_remove_bin_file() Zev Weiss
2021-10-07  5:25   ` Greg Kroah-Hartman
2021-10-07  0:09 ` [PATCH 5/9] of: add self parameter to of_update_property() Zev Weiss
2021-10-07  5:26   ` Greg Kroah-Hartman
2021-10-07  0:09 ` [PATCH 6/9] of: add support for 'dynamic' DT property Zev Weiss
2021-10-08 18:51   ` Frank Rowand
2021-10-08 19:19     ` Frank Rowand
2021-10-11 13:58     ` Frank Rowand
2021-10-11 14:46       ` Frank Rowand
2021-10-11 17:35       ` Zev Weiss [this message]
2021-10-07  0:09 ` [PATCH 7/9] of: make OF_DYNAMIC selectable independently of OF_UNITTEST Zev Weiss
2021-10-08 19:01   ` Frank Rowand
2021-10-07  0:09 ` [PATCH 8/9] dt-bindings: document new 'dynamic' common property Zev Weiss
2021-10-07  5:26   ` Greg Kroah-Hartman
2021-10-07  6:03     ` Zev Weiss
2021-10-07  0:09 ` [PATCH 9/9] ARM: dts: aspeed: Add e3c246d4i BIOS flash device Zev Weiss
2021-10-07  2:46 ` [PATCH 0/9] Dynamic DT device nodes Florian Fainelli
2021-10-07  5:44   ` Zev Weiss
2021-10-07  7:04 ` Andy Shevchenko
2021-10-07  9:05   ` Zev Weiss
2021-10-07 10:31     ` Greg Kroah-Hartman
2021-10-07 15:41       ` Zev Weiss
2021-10-07 20:03         ` Rob Herring
2021-10-08  5:41           ` Greg Kroah-Hartman
2021-10-08 19:43           ` Frank Rowand

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=YWR1yRmcFU66DnO5@hatter.bewilderbeest.net \
    --to=zev@bewilderbeest.net \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jk@codeconstruct.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=openbmc@lists.ozlabs.org \
    --cc=robh+dt@kernel.org \
    --subject='Re: [PATCH 6/9] of: add support for '\''dynamic'\'' DT property' \
    /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).