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;
Date:   Thu, 7 Oct 2021 08:12:37 +0200
From:   Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To:     Zev Weiss <zev@bewilderbeest.net>
Cc:     openbmc@lists.ozlabs.org, Jeremy Kerr <jk@codeconstruct.com.au>,
        Joel Stanley <joel@jms.id.au>,
        Rob Herring <robh+dt@kernel.org>, devicetree@vger.kernel.org,
        "Rafael J. Wysocki" <rafael@kernel.org>,
        Daniel Vetter <daniel.vetter@ffwll.ch>,
        Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= <kw@linux.com>,
        Bjorn Helgaas <bhelgaas@google.com>,
        Heiner Kallweit <hkallweit1@gmail.com>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/9] sysfs: add sysfs_remove_bin_file_self() function
Message-ID: <YV6P1dM6U6sSsefc@kroah.com>
References: <20211007000954.30621-1-zev@bewilderbeest.net>
 <20211007000954.30621-2-zev@bewilderbeest.net>
 <YV6EVcKUQj5DNiXZ@kroah.com>
 <YV6Moz5eCsf6ZZWb@hatter.bewilderbeest.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YV6Moz5eCsf6ZZWb@hatter.bewilderbeest.net>
Precedence: bulk

On Wed, Oct 06, 2021 at 10:58:59PM -0700, Zev Weiss wrote:
> On Wed, Oct 06, 2021 at 10:23:33PM PDT, Greg Kroah-Hartman wrote:
> > On Wed, Oct 06, 2021 at 05:09:46PM -0700, Zev Weiss wrote:
> > > This is simply the bin_attribute analog to sysfs_remove_file_self().
> > 
> > No, no binary sysfs file should be triggering a remove.
> > 
> > binary sysfs files are "pass-through-only" from userspace to hardware,
> > the kernel should not be even knowing what is read/written to them.
> > 
> > What do you think this is needed for?
> > 
> 
> So, I initially set out to be able to activate/deactivate specific DT nodes
> at runtime by using the device-tree "reserved" status as defined in the spec
> (but not currently used anywhere in the kernel) to mean essentially "create
> a device for this but don't bind a driver to it" (leaving it to userspace to
> invoke bind/unbind or similar), and added initial support for the specific
> driver I'm concerned with at the moment (aspeed-smc) -- that was the
> previous patch series linked in the cover letter of this one.
> 
> In the discussion of that series, Rob suggested as an alternate approach:
> 
> > Another possibility is making 'status' writeable from userspace. It is
> > just a sysfs file.
> 
> That seemed sort of appealing to me, and this seemed like the most obvious
> way to go about implementing it.  Given that DT properties are binary
> attributes, I gather you'd consider that a non-starter though?

Why would a text attribute of "status" be a binary sysfs file?  That
feels really wrong as again, binary sysfs files are not supposed to be
parsed or handled by the kernel at all, they are only a pass-through.

thanks,

greg k-h