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
