lkml.org 
[lkml]   [2021]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [PATCH v8 19/22] counter: Implement extension*_name sysfs attributes
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?

William Breathitt Gray
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2021-02-26 00:34    [W:0.118 / U:0.448 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site