Re: [PATCH v8 19/22] counter: Implement extension*_name sysfs attributes
From: William Breathitt Gray <hidden>
Date: 2021-02-25 23:34:13
Also in:
linux-iio, lkml
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 [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? William Breathitt Gray