On Fri, 26 Feb 2021 08:32:59 +0900
William Breathitt Gray [off-list ref] wrote:

On Sun, Feb 21, 2021 at 02:05:07PM +0000, Jonathan Cameron wrote:

quoted

On Fri, 19 Feb 2021 17:51:37 +0900
William Breathitt Gray [off-list ref] wrote:
  

quoted

On Sun, Feb 14, 2021 at 06:09:13PM +0000, Jonathan Cameron wrote:  

quoted

On Fri, 12 Feb 2021 21:13:43 +0900
William Breathitt Gray [off-list ref] wrote:
    

quoted

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 <redacted>
Cc: Dan Carpenter <redacted>
Signed-off-by: William Breathitt Gray <redacted>
---
 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel