Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp1672772pxb; Mon, 11 Oct 2021 10:37:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwYjqGEt41+Ku2TLI1vaucfx7rFjvOb5mw4uAF9B4m7O3l+/lBFTutnqFuXny5UcBUt5YQ4 X-Received: by 2002:a17:906:3486:: with SMTP id g6mr27422832ejb.71.1633973863117; Mon, 11 Oct 2021 10:37:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633973863; cv=none; d=google.com; s=arc-20160816; b=P9kUWFr7I6YAa5csUl2rdn/4EIBDABfUTwbpklfSviqy/dh146aPmHQvi+y1wMWN+8 Fz40JQ+LGfOsj6+2wh4W84bsEY7uu2viRtgrjMWR4/TUYOwSnjHPHZJ7h/wklbYh/3ov 7jrI8oGK3GGGHKhmJlPgR29MX7H/SCjXmCv5Slptb6OTC6h3bJtRmRmachd29HX/dojW Dd/p5KWqNYoJ+yJltujX1kCh8nmirzTeqaqHEf8yU/O2iXrIpLuCjHRXIxt7pG82QAli mY7G7YNrhcPk05/xe0pdhHXbNNs3RF+cz8OnAWLnYCzFZTflATbHJYG0y8BNBovAGF5+ fo+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=37FA9CA4jkUipLpx6mASR21lCskkzjZexvQxoi2xAds=; b=Ya0ZZDWfHqEOcBiNqBwqrJ6YF6R9hdN6lHBIe3037gsN1pC7XH2NoX6L6k1atkMQTK c9XvEr0YzomsB0umRBuoRrUDMn/l/HiMBz5JOGYzGtr0CZRMp1M570qRCRvQdJ2jw2ad 2a3szA3JLai3t/XppGFtotwHUSJNQbnsWLqpVCn/Q/nIqCziCiFY7OQVMnGZ0h0rye31 ugXGeE9wkye26dnuRAH/aNbRHTKChfdrHYaAnfBhN+bei7g8VymOLQSjro2ARKnWVAYg AUXZAvMY521oDa93/r5Ko6pvs3fH15+ZSJbzUNFBcKj3UCuyMN4ZYaX72vm0OXkNYGVh 6StA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bewilderbeest.net header.s=thorn header.b=irpmmvZa; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=bewilderbeest.net Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l6si6046265ejb.541.2021.10.11.10.37.19; Mon, 11 Oct 2021 10:37:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@bewilderbeest.net header.s=thorn header.b=irpmmvZa; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=bewilderbeest.net Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232277AbhJKRhM (ORCPT + 99 others); Mon, 11 Oct 2021 13:37:12 -0400 Received: from thorn.bewilderbeest.net ([71.19.156.171]:46583 "EHLO thorn.bewilderbeest.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230268AbhJKRhL (ORCPT ); Mon, 11 Oct 2021 13:37:11 -0400 Received: from hatter.bewilderbeest.net (71-212-29-146.tukw.qwest.net [71.212.29.146]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: zev) by thorn.bewilderbeest.net (Postfix) with ESMTPSA id D272312B; Mon, 11 Oct 2021 10:35:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bewilderbeest.net; s=thorn; t=1633973711; bh=37FA9CA4jkUipLpx6mASR21lCskkzjZexvQxoi2xAds=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=irpmmvZaPGMwlOIi9xZHr3WBV5ncQWV2tnQ7+PODTjtFt/nLyMkYsSujDA1/KBMDH C7Q552FOG8yEcEz8F7jAtrlZ65FGfi3sqnSaQPCcIrfrEa56FbPZ/m6A9dB5SxQlVW BF6O/6HS+yaMjymyFad5ZFyQu2ObOVmlZ5Lr6w+4= Date: Mon, 11 Oct 2021 10:35:05 -0700 From: Zev Weiss To: Frank Rowand Cc: openbmc@lists.ozlabs.org, Greg Kroah-Hartman , Jeremy Kerr , Joel Stanley , Rob Herring , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 6/9] of: add support for 'dynamic' DT property Message-ID: References: <20211007000954.30621-1-zev@bewilderbeest.net> <20211007000954.30621-7-zev@bewilderbeest.net> <7bf5cfce-e84d-f0e8-e6e8-8e6fedffd154@gmail.com> <05e4c31e-db7e-e8f2-fa37-3cdcdf902e19@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <05e4c31e-db7e-e8f2-fa37-3cdcdf902e19@gmail.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >>> --- >>> 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). > > >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