openbmc.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Frank Rowand <frowand.list@gmail.com>
To: Zev Weiss <zev@bewilderbeest.net>, openbmc@lists.ozlabs.org
Cc: devicetree@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.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 08:58:32 -0500	[thread overview]
Message-ID: <05e4c31e-db7e-e8f2-fa37-3cdcdf902e19@gmail.com> (raw)
In-Reply-To: <7bf5cfce-e84d-f0e8-e6e8-8e6fedffd154@gmail.com>

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.

If we allow one property to be writable via sysfs we open the door for any property to
be writable from sysfs.  This will likely lead to a desire to modify more than one
related property as a single transaction (so that the changes occur as a single
transaction, under a single lock event, with a single notification after all
of the properties are modified).  This is not meant to be an exhaustive list of
the issues that have already been thought through in the context of overlays
(though not all of the issues have been addressed with overlays, at least many
of them, such as one transaction to apply an entire overlay, have been.)

I don't want to make this a long missive, but will at least note the next
issue that popped up in my pondering, which is complications from modifying
the same items in a devicetree via different methods, such as both writing
to sysfs and applying/removing overlays.  If the problems in the previous
paragraph are not sufficient to prevent the sysfs approach then I can
elaborate further on these additional issues.

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

-Frank


> probably belongs in drivers/of/dynamic.c so that it is easier to maintain and keep
> consistent with other dynamic devicetree updates.  If you look at the code there
> that touches deadprops (eg __of_changeset_entry_apply()) you will notice that the
> locking issues are more extensive than what is implemented here.
> 
> I'm still thinking about how this interacts with other forms of dynamic devicetree
> changes (eg drivers/of/dynamic.c and also overlays).
> 
>> +    /*
>> +     * of_update_property_self() doesn't free replaced properties, so
>> +     * rifle through deadprops first to see if there's an equivalent old
>> +     * status property we can reuse instead of allocating a new one.
>> +     */
>> +    mutex_lock(&of_mutex);
>> +    for (deadprev = &np->deadprops; *deadprev; deadprev = &(*deadprev)->next) {
>> +            struct property *deadprop = *deadprev;
>> +            if (!strcmp(deadprop->name, "status") &&
>> +                deadprop->length == strlen(newstatus) + 1 &&
>> +                !strcmp(deadprop->value, newstatus)) {
>> +                    *deadprev = deadprop->next;
>> +                    deadprop->next = NULL;
>> +                    newprop = deadprop;
>> +                    break;
>> +            }
>> +    }
>> +    mutex_unlock(&of_mutex);
>> +
>> +    if (!newprop) {
>> +            newprop = kzalloc(sizeof(*newprop), GFP_KERNEL);
>> +            if (!newprop)
>> +                    return -ENOMEM;
>> +
>> +            newprop->name = oldprop->name;
>> +            newprop->value = newstatus;
>> +            newprop->length = strlen(newstatus) + 1;
>> +    }
>> +
>> +    rc = of_update_property_self(np, newprop, true);
> 
> -Frank
> 
>> +
>> +    return rc ? rc : count;
>> +}
>> +
>>  /* always return newly allocated name, caller must free after use */
>>  static const char *safe_name(struct kobject *kobj, const char *orig_name)
>>  {
>> @@ -79,6 +142,12 @@ int __of_add_property_sysfs(struct device_node *np, struct property *pp)
>>      pp->attr.size = secure ? 0 : pp->length;
>>      pp->attr.read = of_node_property_read;
>>  
>> +    if (!strcmp(pp->name, "status") && of_property_read_bool(np, "dynamic")) {
>> +            pp->attr.attr.mode |= 0200;
>> +            pp->attr.write = of_node_status_write;
>> +            pp->attr.growable = true;
>> +    }
>> +
>>      rc = sysfs_create_bin_file(&np->kobj, &pp->attr);
>>      WARN(rc, "error adding attribute %s to node %pOF\n", pp->name, np);
>>      return rc;
>>

  parent reply	other threads:[~2021-10-11 13:59 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 [this message]
2021-10-11 14:46       ` Frank Rowand
2021-10-11 17:35       ` Zev Weiss
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=05e4c31e-db7e-e8f2-fa37-3cdcdf902e19@gmail.com \
    --to=frowand.list@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --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 \
    --cc=zev@bewilderbeest.net \
    --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).