Re: [PATCH v8 19/22] counter: Implement extension*_name sysfs attributes

[Jonathan Cameron <jic23@kernel.org>]

On Fri, 26 Feb 2021 08:32:59 +0900
William Breathitt Gray <vilhelm.gray@gmail.com> wrote:

> On Sun, Feb 21, 2021 at 02:05:07PM +0000, Jonathan Cameron wrote:
> > On Fri, 19 Feb 2021 17:51:37 +0900
> > William Breathitt Gray <vilhelm.gray@gmail.com> wrote:
> >   
> > > On Sun, Feb 14, 2021 at 06:09:13PM +0000, Jonathan Cameron wrote:  
> > > > On Fri, 12 Feb 2021 21:13:43 +0900
> > > > William Breathitt Gray <vilhelm.gray@gmail.com> wrote:
> > > >     
> > > > > The Generic Counter chrdev interface expects users to supply extension
> > > > > IDs in order to select extensions for requests. In order for users to
> > > > > know what extension ID belongs to which extension this information must
> > > > > be exposed. The extension*_name attribute provides a way for users to
> > > > > discover what extension ID belongs to which extension by reading the
> > > > > respective extension name for an extension ID.
> > > > > 
> > > > > Cc: David Lechner <david@lechnology.com>
> > > > > Cc: Gwendal Grignou <gwendal@chromium.org>
> > > > > Cc: Dan Carpenter <dan.carpenter@oracle.com>
> > > > > Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
> > > > > ---
> > > > >  Documentation/ABI/testing/sysfs-bus-counter |  9 ++++
> > > > >  drivers/counter/counter-sysfs.c             | 51 +++++++++++++++++----
> > > > >  2 files changed, 50 insertions(+), 10 deletions(-)
> > > > > 
> > > > > diff --git a/Documentation/ABI/testing/sysfs-bus-counter b/Documentation/ABI/testing/sysfs-bus-counter
> > > > > index 6353f0a2f8f8..847e96f19d19 100644
> > > > > --- a/Documentation/ABI/testing/sysfs-bus-counter
> > > > > +++ b/Documentation/ABI/testing/sysfs-bus-counter
> > > > > @@ -100,6 +100,15 @@ Description:
> > > > >  		Read-only attribute that indicates whether excessive noise is
> > > > >  		present at the channel Y counter inputs.
> > > > >  
> > > > > +What:		/sys/bus/counter/devices/counterX/countY/extensionZ_name
> > > > > +What:		/sys/bus/counter/devices/counterX/extensionZ_name
> > > > > +What:		/sys/bus/counter/devices/counterX/signalY/extensionZ_name
> > > > > +KernelVersion:	5.13
> > > > > +Contact:	linux-iio@vger.kernel.org
> > > > > +Description:
> > > > > +		Read-only attribute that indicates the component name of
> > > > > +		Extension Z.    
> > > > 
> > > > Good to say what form this takes.    
> > > 
> > > Do you mean a description like this: "Read-only string attribute that
> > > indicates the component name of Extension Z"?  
> > 
> > My expectation would be that the possible strings are tightly constrained
> > (perhaps via review). So I'd like to see what they are and a brief description
> > of what each one means.
> > 
> > Jonathan  
> 
> Okay I see what you mean now. These names will match the sysfs attribute
> filenames. So for example, if Extension 9 of Count 2 of Counter device
> is /sys/bus/counter/devices/counter4/count2/ceiling, then the attribute
> /sys/bus/counter/devices/counter4/count2/extension9_name will hold a
> value of "ceiling".
> 
> The idea is that the user walks down through each extension*_name to
> find sysfs attribute name for the Extension that they want. When they
> find the desired Extension name in say sysfs attribute extension9_name,
> then they know 9 is the ID number for that Extension.
> 
> There is an alternative design I was considering: instead of
> extension*_name attributes, we could have each Extension sysfs attribute
> have a matching *_extension_id attribute which provides the respective
> Extension ID. So for example, using the same Extension as before:
> /sys/bus/counter/devices/counter4/count2/ceiling_extension_id will hold
> a value of 9.
> 
> Do you think this alternative design would be more intuitive to users?
It feels like the user is going to start from what they want to enable
then get the ID from that.   With the current way around they'll have
to search the extensionX_name files to find it, rather than a direct
look up.  So immediate thought is this second way would be easier to
use, but perhaps others think differently.

Jonathan

> 
> William Breathitt Gray