Skip to contentSkip to conversation

Introduce the Counter character device interface

PATCH Superseded William Breathitt Gray 6 participants 19 messages May 16, 2020 – Jun 2, 2020

Subsystems (8)
Documentation IIO Arm STM32 Counter +4 more subsystems

v2 of 17 Superseded Latest is v17 →

lore
Share & tools
lore
#0 lore raw

v2 cover Introduce the Counter character device interface

Changes in v2:
- Use fixed-width data types to represent Counter data types
- Use union of function prototypes to store read/write callbacks
- Eliminate the counter-strings and counter-sysfs-callback files by inlining relevant code
- Reimplement chrdev code to handle read/write calls instead of ioctl
- Remove struct counter_enum (I'm postponing this development until I get the core functionality solid)
- Remove devm_counter_unregister as unnecessary

Over the past couple years we have noticed some shortcomings with the Counter sysfs interface. Although useful in the majority of situations, there are certain use-cases where interacting through sysfs attributes can become cumbersome and inefficient. A desire to support more advanced functionality such as timestamps, multi-axis positioning tables, and other such latency-sensitive applications, has motivated a reevaluation of the Counter subsystem. I believe a character device interface will be helpful for this more niche area of counter device use.

To quell any concerns from the offset: this patchset makes no changes to the existing Counter sysfs userspace interface -- existing userspace applications will continue to work with no modifications necessary. I request that driver maintainers please test their applications to verify that this is true, and report any discrepancies if they arise.

However, this patchset does contain a major reimplementation of the Counter subsystem core and driver API. A reimplementation was necessary in order to separate the sysfs code from the counter device drivers and internalize it as a dedicated component of the core Counter subsystem module. A minor benefit from all of this is that the sysfs interface is now ensured a certain amount of consistency because the translation is performed outside of individual counter device drivers.

Essentially, the reimplementation has enabled counter device drivers to pass and handle data as native C datatypes now rather than the sysfs strings from before. A high-level view of how a count value is passed down from a counter device driver can be exemplified by the following:

                 ----------------------
                / Counter device       \
                +----------------------+
                | Count register: 0x28 |
                +----------------------+
                        |
                 -----------------
                / raw count data /
                -----------------
                        |
                        V
                +----------------------------+
                | Counter device driver      |----------+
                +----------------------------+          |
                | Processes data from device |   -------------------
                |----------------------------|  / driver callbacks /
                | Type: u64                  |  -------------------
                | Value: 42                  |          |
                +----------------------------+          |
                        |                               |
                 ----------                             |
                / u64     /                             |
                ----------                              |
                        |                               |
                        |                               V
                        |               +----------------------+
                        |               | Counter core         |
                        |               +----------------------+
                        |               | Routes device driver |
                        |               | callbacks to the     |
                        |               | userspace interfaces |
                        |               +----------------------+
                        |                       |
                        |                -------------------
                        |               / driver callbacks /
                        |               -------------------
                        |                       |
                +-------+---------------+       |
                |                       |       |
                |               +-------|-------+
                |               |       |
                V               |       V
        +--------------------+  |  +---------------------+
        | Counter sysfs      |<-+->| Counter chrdev      |
        +--------------------+     +---------------------+
        | Translates to the  |     | Translates to the   |
        | standard Counter   |     | standard Counter    |
        | sysfs output       |     | character device    |
        |--------------------|     |---------------------+
        | Type: const char * |     | Type: u64           |
        | Value: "42"        |     | Value: 42           |
        +--------------------+     +---------------------+
                |                               |
         ---------------                 ----------
        / const char * /                / u64     /
        ---------------                 ----------
                |                               |
                |                               V
                |                       +-----------+
                |                       | read      |
                |                       +-----------+
                |                       \ Count: 42 /
                |                        -----------
                |
                V
        +--------------------------------------------------+
        | `/sys/bus/counter/devices/counterX/countY/count` |
        +--------------------------------------------------+
        \ Count: "42"                                      /
         --------------------------------------------------

I am aware that an in-kernel API can simplify the data transfer between counter device drivers and the userspace interfaces, but I want to postpone that development until after the new Counter character device interface is solidified. A userspace ABI is effectively immutable so I want to make sure we get that right before working on an in-kernel API that is more flexible to change. However, when we do develop an in-kernel API, it will likely be housed as part of the Counter core component, through which the userspace interfaces will then communicate.

Interaction with Counter character devices occurs via standard character device read/write operations. This allows userspace applications to access and set counter data using native C datatypes rather than working through string translations.

The following are some questions I have about this patchset:

1. Should the data format of the character device be configured via a sysfs attribute?

In this patchset, the first 196095 bytes of the character device are dedicated as a selection area to choose which Counter components or extensions should be exposed; the subsequent bytes are the actual data for the Counter components and extensions that were selected.

Moving this selection to a sysfs attribute and dedicating the character device to just data transfer might be a better design. If such a design is chosen, should the selection attribute be human-readable or binary?

2. How much space should allotted for strings?

Each Counter component and extension has a respective size allotted for its data (u8 data is allotted 1 byte, u64 data is allotted 8 bytes, etc.); I have arbitrarily chosen to allot 64 bytes for strings. Is this an apt size, or should string data be allotted more or less space?

3. Should the owning component of an extension be handled by the device driver or Counter subsystem?

The Counter subsystem figures out the owner (enum counter_owner_type) for each component/extension in the counter-sysfs and counter-chrdev code. When a callback must be executed, there are various switch statements throughout the code to check whether the respective Device, Signal, or Count version of the callback should be executed; similarly, the appropriate owner type must match for the struct counter_data macros such as COUNTER_DATA_DEVICE_U64, COUNTER_DATA_SIGNAL_U64, COUNTER_DATA_COUNT_U64, etc.

All this complexity in the Counter subsystem code can be eliminated if a single callback type with a void *owner parameter is defined for use with all three owner types (Device, Signal, and Count). The device driver would then be responsible for casting the callback argument to the appropriate owner type; but in theory, this should not be much of a problem since the device driver is responsible for assigning the callbacks to the owning component anyway.

William Breathitt Gray (4):
counter: Internalize sysfs interface code
docs: counter: Update to reflect sysfs internalization
counter: Add character device interface
docs: counter: Document character device interface

 Documentation/driver-api/generic-counter.rst |  275 +++-
 MAINTAINERS                                  |    3 +-
 drivers/counter/104-quad-8.c                 |  547 +++----
 drivers/counter/Makefile                     |    1 +
 drivers/counter/counter-chrdev.c             |  656 ++++++++
 drivers/counter/counter-chrdev.h             |   16 +
 drivers/counter/counter-core.c               |  187 +++
 drivers/counter/counter-sysfs.c              |  881 +++++++++++
 drivers/counter/counter-sysfs.h              |   14 +
 drivers/counter/counter.c                    | 1496 ------------------
 drivers/counter/ftm-quaddec.c                |   89 +-
 drivers/counter/stm32-lptimer-cnt.c          |  161 +-
 drivers/counter/stm32-timer-cnt.c            |  139 +-
 drivers/counter/ti-eqep.c                    |  211 +--
 include/linux/counter.h                      |  626 ++++----
 include/linux/counter_enum.h                 |   45 -
 include/uapi/linux/counter-types.h           |   45 +
 17 files changed, 2826 insertions(+), 2566 deletions(-)
 create mode 100644 drivers/counter/counter-chrdev.c
 create mode 100644 drivers/counter/counter-chrdev.h
 create mode 100644 drivers/counter/counter-core.c
 create mode 100644 drivers/counter/counter-sysfs.c
 create mode 100644 drivers/counter/counter-sysfs.h
 delete mode 100644 drivers/counter/counter.c
 delete mode 100644 include/linux/counter_enum.h
 create mode 100644 include/uapi/linux/counter-types.h
Signature · 1 line
2.26.2
#1 lore raw

PATCH v2 1/4 counter: Internalize sysfs interface code

This is a reimplementation of the Generic Counter driver interface. There are no modifications to the Counter subsystem userspace interface, so existing userspace applications should continue to run seamlessly.

Overview
========

The purpose of this patch is to internalize the sysfs interface code among the various counter drivers into a shared module. Counter drivers pass and take data natively (i.e. u8, u64, char *, etc.) and the shared counter module handles the translation between the sysfs interface. This gurantees a standard userspace interface for all counter drivers, and helps generalize the Generic Counter driver ABI in order to support the Generic Counter chrdev interface (introduced in a subsequent patch) without significant changes to the existing counter drivers.

A high-level view of how a count value is passed down from a counter driver can be exemplified by the following:

                 ----------------------
                / Counter device       \
                +----------------------+
                | Count register: 0x28 |
                +----------------------+
                        |
                 -----------------
                / raw count data /
                -----------------
                        |
                        V
                +----------------------------+
                | Counter device driver      |----------+
                +----------------------------+          |
                | Processes data from device |   -------------------
                |----------------------------|  / driver callbacks /
                | Type: unsigned long        |  -------------------
                | Value: 42                  |          |
                +----------------------------+          |
                        |                               |
                 ----------------                       |
                / unsigned long /                       |
                ----------------                        |
                        |                               |
                        |                               V
                        |               +----------------------+
                        |               | Counter core         |
                        |               +----------------------+
                        |               | Routes device driver |
                        |               | callbacks to the     |
                        |               | userspace interfaces |
                        |               +----------------------+
                        |                       |
                        |                -------------------
                        |               / driver callbacks /
                        |               -------------------
                        |                       |
                +-------+                       |
                |                               |
                |               +---------------+
                |               |
                V               |
        +--------------------+  |
        | Counter sysfs      |<-+
        +--------------------+
        | Translates to the  |
        | standard Counter   |
        | sysfs output       |
        |--------------------|
        | Type: const char * |
        | Value: "42"        |
        +--------------------+
                |
         ---------------
        / const char * /
        ---------------
                |
                V
        +--------------------------------------------------+
        | `/sys/bus/counter/devices/counterX/countY/count` |
        +--------------------------------------------------+
        \ Count: "42"                                      /
         --------------------------------------------------

There are three primary components involved:

Counter device driver
---------------------
Communicates with the hardware device to read/write data; e.g. counter drivers for 104-quad-8, stm32-timer, etc.

Counter core
------------
Registers the counter device driver to the system so that the respective callbacks are called during userspace interaction

Counter sysfs
-------------
Translates counter data to the standard Counter sysfs interface format and vice versa

Driver ABI
==========

This reimplementation entails several changes to the driver ABI. In particular, the device driver callbacks are now expected to handle standard C datatypes rather than translating the sysfs I/O directly.

To that end, the struct counter_data structure is introduced to establish counter extensions for Signals, Synapses, and Counts.

The "type" member specifies the type of high-level data (e.g. BOOL, COUNT_DIRECTION, etc.) handled by this extension. The "*_read" and "*_write" members can then be set by the counter device driver with callbacks to handle that data using native C data types (i.e. u8, u64, char *, etc.).

Convenience macros such as COUNTER_DATA_COUNT_U64 are provided for use by driver authors. In particular, driver authors are expected to use the provided macros for standard Counter subsystem attributes in order to maintain a consistent interface for userspace. For example, a counter device driver may define several standard attributes like so:

struct counter_data count_ext[] = {
COUNTER_DATA_DIRECTION(count_direction_read), COUNTER_DATA_ENABLE(count_enable_read, count_enable_write), COUNTER_DATA_CEILING(count_ceiling_read, count_ceiling_write),
};

This makes it intuitive to see, add, and modify the attributes that are supported by this driver ("direction", "enable", and "ceiling") and to maintain this code without getting lost in a web of struct braces.

Callbacks must match the function type expected for the respective component or extension. These function types are defined in the struct counter_data structure as the "*_read" and "*_write" union members.

The corresponding callback prototypes for the extensions above would be:

int count_direction_read(struct counter_device *counter,

			 struct counter_count *count, u8 *direction);
int count_enable_read(struct counter_device *counter,
		      struct counter_count *count, u8 *enable);
int count_enable_write(struct counter_device *counter,
		       struct counter_count *count, u8 enable);
int count_ceiling_read(struct counter_device *counter,
		       struct counter_count *count, u64 *ceiling);
int count_ceiling_write(struct counter_device *counter,
			struct counter_count *count, u64 ceiling);

In this way, driver authors no longer need to mess with sysfs strings and are instead able to focus on what they actually care about doing -- getting data to/from the devices -- while the Generic Counter interface handles the translation of that data for them between the various userspace interfaces (e.g. sysfs and chardev).

Architecture
============

Counter device registration is the same as before: drivers populate a struct counter_device with components and callbacks, then pass the structure to the devm_counter_register function. However, what's different now is how the Counter subsystem code handles this registration internally.

Whereas before callbacks would interact directly with sysfs data, this interaction is now abstracted and instead callbacks interact with native C data types. The counter_data structure forms the basis for Counter extentions.

The counter-sysfs.c file contains the code to parse through the counter_device structure and register the requested components and extensions. Attributes are created and populated based on type, with respective translation functions to handle the mapping between sysfs and the counter driver callbacks.

The translation performed for each attribute is straightforward: the attribute type and data is parsed from the counter_attribute structure, the respective counter driver read/write callback is called, and sysfs I/O is handled before or after the driver read/write function is called.

Cc Syed Nayyar Waris <[email protected]>
Cc Patrick Havelange <[email protected]>
Cc Fabrice Gasnier <[email protected]>
Cc Maxime Coquelin <[email protected]>
Cc Alexandre Torgue <[email protected]>
Cc David Lechner <[email protected]>
---
 MAINTAINERS                         |    2 +-
 drivers/counter/104-quad-8.c        |  547 +++++-----
 drivers/counter/Makefile            |    1 +
 drivers/counter/counter-core.c      |  157 +++
 drivers/counter/counter-sysfs.c     |  881 ++++++++++++++++
 drivers/counter/counter-sysfs.h     |   14 +
 drivers/counter/counter.c           | 1496 ---------------------------
 drivers/counter/ftm-quaddec.c       |   89 +-
 drivers/counter/stm32-lptimer-cnt.c |  161 +--
 drivers/counter/stm32-timer-cnt.c   |  139 +--
 drivers/counter/ti-eqep.c           |  211 ++--
 include/linux/counter.h             |  610 +++++------
 include/linux/counter_enum.h        |   45 -
 include/uapi/linux/counter-types.h  |   45 +
 14 files changed, 1908 insertions(+), 2490 deletions(-)
 create mode 100644 drivers/counter/counter-core.c
 create mode 100644 drivers/counter/counter-sysfs.c
 create mode 100644 drivers/counter/counter-sysfs.h
 delete mode 100644 drivers/counter/counter.c
 delete mode 100644 include/linux/counter_enum.h
 create mode 100644 include/uapi/linux/counter-types.h
MAINTAINERS +1 -1
index 60ed2963efaa..ef72b5755793 100644
@@ -4365,7 +4365,7 @@ F:	Documentation/ABI/testing/sysfs-bus-counter*
 F:	Documentation/driver-api/generic-counter.rst
 F:	drivers/counter/
 F:	include/linux/counter.h
-F:	include/linux/counter_enum.h
+F:	include/uapi/linux/counter-types.h
 
 CPMAC ETHERNET DRIVER
 M:	Florian Fainelli <[email protected]>
drivers/counter/104-quad-8.c +259 -288

922 lines not on this page · raw message

drivers/counter/Makefile +1 -0
index 55142d1f4c43..f48e337cbd85 100644
@@ -4,6 +4,7 @@
 #
 
 obj-$(CONFIG_COUNTER) += counter.o
+counter-y := counter-core.o counter-sysfs.o
 
 obj-$(CONFIG_104_QUAD_8)	+= 104-quad-8.o
 obj-$(CONFIG_STM32_TIMER_CNT)	+= stm32-timer-cnt.o
drivers/counter/counter-core.c new file +157 -0

157 lines not on this page · raw message

drivers/counter/counter-sysfs.c new file +881 -0

881 lines not on this page · raw message

drivers/counter/counter-sysfs.h new file +14 -0
new file mode 100644
index 000000000000..00e7cd6ea083
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Counter sysfs interface
+ * Copyright (C) 2020 William Breathitt Gray
+ */
+#ifndef _COUNTER_SYSFS_H_
+#define _COUNTER_SYSFS_H_
+
+#include <linux/counter.h>
+
+int counter_sysfs_add(struct counter_device *const counter);
+void counter_sysfs_free(struct counter_device *const counter);
+
+#endif /* _COUNTER_SYSFS_H_ */
drivers/counter/counter.c deleted +0 -1496

1,011 lines not on this page · raw message

drivers/counter/ftm-quaddec.c +51 -38

89 lines not on this page · raw message

drivers/counter/stm32-lptimer-cnt.c +84 -77

161 lines not on this page · raw message

drivers/counter/stm32-timer-cnt.c +53 -86

139 lines not on this page · raw message

drivers/counter/ti-eqep.c +107 -104

211 lines not on this page · raw message

include/linux/counter.h +255 -355

610 lines not on this page · raw message

include/linux/counter_enum.h deleted +0 -45

45 lines not on this page · raw message

include/uapi/linux/counter-types.h new file +45 -0

45 lines not on this page · raw message

The rest of this diff is not shown. View the raw message.

Signature · 1 line
2.26.2

Part of the diff is not shown here. View the raw message.

#2 lore raw

Re: [PATCH v2 1/4] counter: Internalize sysfs interface code

I love your patch! Perhaps something to improve:

Hi William,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v5.7-rc6 next-20200519]
[cannot apply to stm32/stm32-next linux/master]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:    https://github.com/0day-ci/linux/commits/William-Breathitt-Gray/Introduce-the-Counter-character-device-interface/20200517-032530
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 12bf0b632ed090358cbf03e323e5342212d0b2e4
config: arm64-randconfig-r026-20200519 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 135b877874fae96b4372c8a3fbfaa8ff44ff86e3)

reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64

If you fix the issue, kindly add following tag as appropriate

All warnings (new ones prefixed by >>, old ones prefixed by <<):

>> drivers/counter/counter-sysfs.c:850:5: warning: no previous prototype for function 'counter_sysfs_add' [-Wmissing-prototypes]

int counter_sysfs_add(struct counter_device *const counter)
^
drivers/counter/counter-sysfs.c:850:1: note: declare 'static' if the function is not intended to be used outside of this translation unit int counter_sysfs_add(struct counter_device *const counter)
^
static

>> drivers/counter/counter-sysfs.c:876:6: warning: no previous prototype for function 'counter_sysfs_free' [-Wmissing-prototypes]

void counter_sysfs_free(struct counter_device *const counter)
^
drivers/counter/counter-sysfs.c:876:1: note: declare 'static' if the function is not intended to be used outside of this translation unit void counter_sysfs_free(struct counter_device *const counter)
^
static
2 warnings generated.

vim +/counter_sysfs_add +850 drivers/counter/counter-sysfs.c

849

 > 850	int counter_sysfs_add(struct counter_device *const counter)
   851	{
   852		int err;
   853	
   854		/* Initialize Synapse names list */
   855		INIT_LIST_HEAD(&counter->dynamic_names_list);
   856	
   857		/* Prepare device attributes */
   858		err = counter_groups_list_prepare(counter);
   859		if (err)
   860			goto err_free_names;
   861	
   862		/* Organize device attributes to groups and match to device */
   863		err = counter_groups_prepare(counter);
   864		if (err)
   865			goto err_free_groups_list;
   866	
   867		return 0;
   868	
   869	err_free_groups_list:
   870		counter_groups_list_free(counter);
   871	err_free_names:
   872		counter_dynamic_names_free(&counter->dynamic_names_list);
   873		return err;
   874	}
   875	
 > 876	void counter_sysfs_free(struct counter_device *const counter)

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

maintainer
#3 lore raw

Re: [PATCH v2 1/4] counter: Internalize sysfs interface code

In reply to William Breathitt Gray
Quoted 180 lines · On Sat, 16 May 2020 15:19:59 -0400 William Breathitt Gray…

This is a reimplementation of the Generic Counter driver interface. There are no modifications to the Counter subsystem userspace interface, so existing userspace applications should continue to run seamlessly.

Overview
========

The purpose of this patch is to internalize the sysfs interface code among the various counter drivers into a shared module. Counter drivers pass and take data natively (i.e. u8, u64, char *, etc.) and the shared counter module handles the translation between the sysfs interface. This gurantees a standard userspace interface for all counter drivers, and helps generalize the Generic Counter driver ABI in order to support the Generic Counter chrdev interface (introduced in a subsequent patch) without significant changes to the existing counter drivers.

A high-level view of how a count value is passed down from a counter driver can be exemplified by the following:

                 ----------------------
                / Counter device       \
                +----------------------+
                | Count register: 0x28 |
                +----------------------+
                        |
                 -----------------
                / raw count data /
                -----------------
                        |
                        V
                +----------------------------+
                | Counter device driver      |----------+
                +----------------------------+          |
                | Processes data from device |   -------------------
                |----------------------------|  / driver callbacks /
                | Type: unsigned long        |  -------------------
                | Value: 42                  |          |
                +----------------------------+          |
                        |                               |
                 ----------------                       |
                / unsigned long /                       |
                ----------------                        |
                        |                               |
                        |                               V
                        |               +----------------------+
                        |               | Counter core         |
                        |               +----------------------+
                        |               | Routes device driver |
                        |               | callbacks to the     |
                        |               | userspace interfaces |
                        |               +----------------------+
                        |                       |
                        |                -------------------
                        |               / driver callbacks /
                        |               -------------------
                        |                       |
                +-------+                       |
                |                               |
                |               +---------------+
                |               |
                V               |
        +--------------------+  |
        | Counter sysfs      |<-+
        +--------------------+
        | Translates to the  |
        | standard Counter   |
        | sysfs output       |
        |--------------------|
        | Type: const char * |
        | Value: "42"        |
        +--------------------+
                |
         ---------------
        / const char * /
        ---------------
                |
                V
        +--------------------------------------------------+
        | `/sys/bus/counter/devices/counterX/countY/count` |
        +--------------------------------------------------+
        \ Count: "42"                                      /
         --------------------------------------------------

There are three primary components involved:

Counter device driver
---------------------
Communicates with the hardware device to read/write data; e.g. counter drivers for 104-quad-8, stm32-timer, etc.

Counter core
------------
Registers the counter device driver to the system so that the respective callbacks are called during userspace interaction

Counter sysfs
-------------
Translates counter data to the standard Counter sysfs interface format and vice versa

Driver ABI
==========

This reimplementation entails several changes to the driver ABI. In particular, the device driver callbacks are now expected to handle standard C datatypes rather than translating the sysfs I/O directly.

To that end, the struct counter_data structure is introduced to establish counter extensions for Signals, Synapses, and Counts.

The "type" member specifies the type of high-level data (e.g. BOOL, COUNT_DIRECTION, etc.) handled by this extension. The "*_read" and "*_write" members can then be set by the counter device driver with callbacks to handle that data using native C data types (i.e. u8, u64, char *, etc.).

Convenience macros such as COUNTER_DATA_COUNT_U64 are provided for use by driver authors. In particular, driver authors are expected to use the provided macros for standard Counter subsystem attributes in order to maintain a consistent interface for userspace. For example, a counter device driver may define several standard attributes like so:

struct counter_data count_ext[] = {
COUNTER_DATA_DIRECTION(count_direction_read), COUNTER_DATA_ENABLE(count_enable_read, count_enable_write), COUNTER_DATA_CEILING(count_ceiling_read, count_ceiling_write),
};

This makes it intuitive to see, add, and modify the attributes that are supported by this driver ("direction", "enable", and "ceiling") and to maintain this code without getting lost in a web of struct braces.

Callbacks must match the function type expected for the respective component or extension. These function types are defined in the struct counter_data structure as the "*_read" and "*_write" union members.

The corresponding callback prototypes for the extensions above would be:

int count_direction_read(struct counter_device *counter,

			 struct counter_count *count, u8 *direction);
int count_enable_read(struct counter_device *counter,
		      struct counter_count *count, u8 *enable);
int count_enable_write(struct counter_device *counter,
		       struct counter_count *count, u8 enable);
int count_ceiling_read(struct counter_device *counter,
		       struct counter_count *count, u64 *ceiling);
int count_ceiling_write(struct counter_device *counter,
			struct counter_count *count, u64 ceiling);

In this way, driver authors no longer need to mess with sysfs strings and are instead able to focus on what they actually care about doing -- getting data to/from the devices -- while the Generic Counter interface handles the translation of that data for them between the various userspace interfaces (e.g. sysfs and chardev).

Architecture
============

Counter device registration is the same as before: drivers populate a struct counter_device with components and callbacks, then pass the structure to the devm_counter_register function. However, what's different now is how the Counter subsystem code handles this registration internally.

Whereas before callbacks would interact directly with sysfs data, this interaction is now abstracted and instead callbacks interact with native C data types. The counter_data structure forms the basis for Counter extentions.

The counter-sysfs.c file contains the code to parse through the counter_device structure and register the requested components and extensions. Attributes are created and populated based on type, with respective translation functions to handle the mapping between sysfs and the counter driver callbacks.

The translation performed for each attribute is straightforward: the attribute type and data is parsed from the counter_attribute structure, the respective counter driver read/write callback is called, and sysfs I/O is handled before or after the driver read/write function is called.

Quoted 7 lines
Cc Syed Nayyar Waris <[email protected]>
Cc Patrick Havelange <[email protected]>
Cc Fabrice Gasnier <[email protected]>
Cc Maxime Coquelin <[email protected]>
Cc Alexandre Torgue <[email protected]>
Cc David Lechner <[email protected]>

Hi William

I've not been through this in great detail, but from
a read through of 104-quad-8 and the core changes this all looks fairly sensible to me.

Jonathan

Quoted 5,508 lines
---
 MAINTAINERS                         |    2 +-
 drivers/counter/104-quad-8.c        |  547 +++++-----
 drivers/counter/Makefile            |    1 +
 drivers/counter/counter-core.c      |  157 +++
 drivers/counter/counter-sysfs.c     |  881 ++++++++++++++++
 drivers/counter/counter-sysfs.h     |   14 +
 drivers/counter/counter.c           | 1496 ---------------------------
 drivers/counter/ftm-quaddec.c       |   89 +-
 drivers/counter/stm32-lptimer-cnt.c |  161 +--
 drivers/counter/stm32-timer-cnt.c   |  139 +--
 drivers/counter/ti-eqep.c           |  211 ++--
 include/linux/counter.h             |  610 +++++------
 include/linux/counter_enum.h        |   45 -
 include/uapi/linux/counter-types.h  |   45 +
 14 files changed, 1908 insertions(+), 2490 deletions(-)
 create mode 100644 drivers/counter/counter-core.c
 create mode 100644 drivers/counter/counter-sysfs.c
 create mode 100644 drivers/counter/counter-sysfs.h
 delete mode 100644 drivers/counter/counter.c
 delete mode 100644 include/linux/counter_enum.h
 create mode 100644 include/uapi/linux/counter-types.h
MAINTAINERS +1 -1
index 60ed2963efaa..ef72b5755793 100644
@@ -4365,7 +4365,7 @@ F:	Documentation/ABI/testing/sysfs-bus-counter*
 F:	Documentation/driver-api/generic-counter.rst
 F:	drivers/counter/
 F:	include/linux/counter.h
-F:	include/linux/counter_enum.h
+F:	include/uapi/linux/counter-types.h
 
 CPMAC ETHERNET DRIVER
 M:	Florian Fainelli <[email protected]>
drivers/counter/104-quad-8.c +259 -288
index aa13708c2bc3..ff1c8f8d1417 100644
@@ -17,6 +17,7 @@
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/moduleparam.h>
+#include <linux/string.h>
 #include <linux/types.h>
 
 #define QUAD8_EXTENT 32
@@ -621,7 +622,7 @@ static const struct iio_chan_spec quad8_channels[] = {
 };
 
 static int quad8_signal_read(struct counter_device *counter,
-	struct counter_signal *signal, enum counter_signal_value *val)
+			     struct counter_signal *signal, u8 *val)
 {
 	const struct quad8_iio *const priv = counter->priv;
 	unsigned int state;
@@ -639,7 +640,7 @@ static int quad8_signal_read(struct counter_device *counter,
 }
 
 static int quad8_count_read(struct counter_device *counter,
-	struct counter_count *count, unsigned long *val)
+			    struct counter_count *count, u64 *val)
 {
 	struct quad8_iio *const priv = counter->priv;
 	const int base_offset = priv->base + 2 * count->id;
@@ -670,7 +671,7 @@ static int quad8_count_read(struct counter_device *counter,
 }
 
 static int quad8_count_write(struct counter_device *counter,
-	struct counter_count *count, unsigned long val)
+			     struct counter_count *count, u64 val)
 {
 	struct quad8_iio *const priv = counter->priv;
 	const int base_offset = priv->base + 2 * count->id;
@@ -710,22 +711,16 @@ static int quad8_count_write(struct counter_device *counter,
 	return 0;
 }
 
-enum quad8_count_function {
-	QUAD8_COUNT_FUNCTION_PULSE_DIRECTION = 0,
-	QUAD8_COUNT_FUNCTION_QUADRATURE_X1,
-	QUAD8_COUNT_FUNCTION_QUADRATURE_X2,
-	QUAD8_COUNT_FUNCTION_QUADRATURE_X4
-};
 
-static enum counter_count_function quad8_count_functions_list[] = {
-	[QUAD8_COUNT_FUNCTION_PULSE_DIRECTION] = COUNTER_COUNT_FUNCTION_PULSE_DIRECTION,
-	[QUAD8_COUNT_FUNCTION_QUADRATURE_X1] = COUNTER_COUNT_FUNCTION_QUADRATURE_X1_A,
-	[QUAD8_COUNT_FUNCTION_QUADRATURE_X2] = COUNTER_COUNT_FUNCTION_QUADRATURE_X2_A,
-	[QUAD8_COUNT_FUNCTION_QUADRATURE_X4] = COUNTER_COUNT_FUNCTION_QUADRATURE_X4
+static const u8 quad8_count_functions_list[] = {
+	COUNTER_COUNT_FUNCTION_PULSE_DIRECTION,
+	COUNTER_COUNT_FUNCTION_QUADRATURE_X1_A,
+	COUNTER_COUNT_FUNCTION_QUADRATURE_X2_A,
+	COUNTER_COUNT_FUNCTION_QUADRATURE_X4,
 };
 
-static int quad8_function_get(struct counter_device *counter,
-	struct counter_count *count, size_t *function)
+static int quad8_function_read(struct counter_device *counter,
+			       struct counter_count *count, u8 *function)
 {
 	struct quad8_iio *const priv = counter->priv;
 	const int id = count->id;
@@ -735,25 +730,25 @@ static int quad8_function_get(struct counter_device *counter,
 	if (priv->quadrature_mode[id])
 		switch (priv->quadrature_scale[id]) {
 		case 0:
-			*function = QUAD8_COUNT_FUNCTION_QUADRATURE_X1;
+			*function = COUNTER_COUNT_FUNCTION_QUADRATURE_X1_A;
 			break;
 		case 1:
-			*function = QUAD8_COUNT_FUNCTION_QUADRATURE_X2;
+			*function = COUNTER_COUNT_FUNCTION_QUADRATURE_X2_A;
 			break;
 		case 2:
-			*function = QUAD8_COUNT_FUNCTION_QUADRATURE_X4;
+			*function = COUNTER_COUNT_FUNCTION_QUADRATURE_X4;
 			break;
 		}
 	else
-		*function = QUAD8_COUNT_FUNCTION_PULSE_DIRECTION;
+		*function = COUNTER_COUNT_FUNCTION_PULSE_DIRECTION;
 
 	mutex_unlock(&priv->lock);
 
 	return 0;
 }
 
-static int quad8_function_set(struct counter_device *counter,
-	struct counter_count *count, size_t function)
+static int quad8_function_write(struct counter_device *counter,
+				struct counter_count *count, u8 function)
 {
 	struct quad8_iio *const priv = counter->priv;
 	const int id = count->id;
@@ -769,7 +764,7 @@ static int quad8_function_set(struct counter_device *counter,
 	mode_cfg = priv->count_mode[id] << 1;
 	idr_cfg = priv->index_polarity[id] << 1;
 
-	if (function == QUAD8_COUNT_FUNCTION_PULSE_DIRECTION) {
+	if (function == COUNTER_COUNT_FUNCTION_PULSE_DIRECTION) {
 		*quadrature_mode = 0;
 
 		/* Quadrature scaling only available in quadrature mode */
@@ -785,15 +780,15 @@ static int quad8_function_set(struct counter_device *counter,
 		*quadrature_mode = 1;
 
 		switch (function) {
-		case QUAD8_COUNT_FUNCTION_QUADRATURE_X1:
+		case COUNTER_COUNT_FUNCTION_QUADRATURE_X1_A:
 			*scale = 0;
 			mode_cfg |= QUAD8_CMR_QUADRATURE_X1;
 			break;
-		case QUAD8_COUNT_FUNCTION_QUADRATURE_X2:
+		case COUNTER_COUNT_FUNCTION_QUADRATURE_X2_A:
 			*scale = 1;
 			mode_cfg |= QUAD8_CMR_QUADRATURE_X2;
 			break;
-		case QUAD8_COUNT_FUNCTION_QUADRATURE_X4:
+		case COUNTER_COUNT_FUNCTION_QUADRATURE_X4:
 			*scale = 2;
 			mode_cfg |= QUAD8_CMR_QUADRATURE_X4;
 			break;
@@ -808,8 +803,8 @@ static int quad8_function_set(struct counter_device *counter,
 	return 0;
 }
 
-static void quad8_direction_get(struct counter_device *counter,
-	struct counter_count *count, enum counter_count_direction *direction)
+static int quad8_direction_read(struct counter_device *counter,
+				struct counter_count *count, u8 *direction)
 {
 	const struct quad8_iio *const priv = counter->priv;
 	unsigned int ud_flag;
@@ -820,153 +815,155 @@ static void quad8_direction_get(struct counter_device *counter,
 
 	*direction = (ud_flag) ? COUNTER_COUNT_DIRECTION_FORWARD :
 		COUNTER_COUNT_DIRECTION_BACKWARD;
-}
 
-enum quad8_synapse_action {
-	QUAD8_SYNAPSE_ACTION_NONE = 0,
-	QUAD8_SYNAPSE_ACTION_RISING_EDGE,
-	QUAD8_SYNAPSE_ACTION_FALLING_EDGE,
-	QUAD8_SYNAPSE_ACTION_BOTH_EDGES
-};
+	return 0;
+}
 
-static enum counter_synapse_action quad8_index_actions_list[] = {
-	[QUAD8_SYNAPSE_ACTION_NONE] = COUNTER_SYNAPSE_ACTION_NONE,
-	[QUAD8_SYNAPSE_ACTION_RISING_EDGE] = COUNTER_SYNAPSE_ACTION_RISING_EDGE
+static const u8 quad8_index_actions_list[] = {
+	COUNTER_SYNAPSE_ACTION_NONE,
+	COUNTER_SYNAPSE_ACTION_RISING_EDGE,
 };
 
-static enum counter_synapse_action quad8_synapse_actions_list[] = {
-	[QUAD8_SYNAPSE_ACTION_NONE] = COUNTER_SYNAPSE_ACTION_NONE,
-	[QUAD8_SYNAPSE_ACTION_RISING_EDGE] = COUNTER_SYNAPSE_ACTION_RISING_EDGE,
-	[QUAD8_SYNAPSE_ACTION_FALLING_EDGE] = COUNTER_SYNAPSE_ACTION_FALLING_EDGE,
-	[QUAD8_SYNAPSE_ACTION_BOTH_EDGES] = COUNTER_SYNAPSE_ACTION_BOTH_EDGES
+static const u8 quad8_synapse_actions_list[] = {
+	COUNTER_SYNAPSE_ACTION_NONE,
+	COUNTER_SYNAPSE_ACTION_RISING_EDGE,
+	COUNTER_SYNAPSE_ACTION_FALLING_EDGE,
+	COUNTER_SYNAPSE_ACTION_BOTH_EDGES,
 };
 
-static int quad8_action_get(struct counter_device *counter,
-	struct counter_count *count, struct counter_synapse *synapse,
-	size_t *action)
+static int quad8_action_read(struct counter_device *counter,
+			     struct counter_count *count,
+			     struct counter_synapse *synapse, u8 *action)
 {
 	struct quad8_iio *const priv = counter->priv;
 	int err;
-	size_t function = 0;
+	u8 function;
 	const size_t signal_a_id = count->synapses[0].signal->id;
-	enum counter_count_direction direction;
+	u8 direction;
 
 	/* Handle Index signals */
 	if (synapse->signal->id >= 16) {
 		if (priv->preset_enable[count->id])
-			*action = QUAD8_SYNAPSE_ACTION_RISING_EDGE;
+			*action = COUNTER_SYNAPSE_ACTION_RISING_EDGE;
 		else
-			*action = QUAD8_SYNAPSE_ACTION_NONE;
+			*action = COUNTER_SYNAPSE_ACTION_NONE;
 
 		return 0;
 	}
 
-	err = quad8_function_get(counter, count, &function);
+	err = quad8_function_read(counter, count, &function);
 	if (err)
 		return err;
 
 	/* Default action mode */
-	*action = QUAD8_SYNAPSE_ACTION_NONE;
+	*action = COUNTER_SYNAPSE_ACTION_NONE;
 
 	/* Determine action mode based on current count function mode */
 	switch (function) {
-	case QUAD8_COUNT_FUNCTION_PULSE_DIRECTION:
+	case COUNTER_COUNT_FUNCTION_PULSE_DIRECTION:
 		if (synapse->signal->id == signal_a_id)
-			*action = QUAD8_SYNAPSE_ACTION_RISING_EDGE;
+			*action = COUNTER_SYNAPSE_ACTION_RISING_EDGE;
 		break;
-	case QUAD8_COUNT_FUNCTION_QUADRATURE_X1:
+	case COUNTER_COUNT_FUNCTION_QUADRATURE_X1_A:
 		if (synapse->signal->id == signal_a_id) {
-			quad8_direction_get(counter, count, &direction);
+			err = quad8_direction_read(counter, count, &direction);
+			if (err)
+				return err;
 
 			if (direction == COUNTER_COUNT_DIRECTION_FORWARD)
-				*action = QUAD8_SYNAPSE_ACTION_RISING_EDGE;
+				*action = COUNTER_SYNAPSE_ACTION_RISING_EDGE;
 			else
-				*action = QUAD8_SYNAPSE_ACTION_FALLING_EDGE;
+				*action = COUNTER_SYNAPSE_ACTION_FALLING_EDGE;
 		}
 		break;
-	case QUAD8_COUNT_FUNCTION_QUADRATURE_X2:
+	case COUNTER_COUNT_FUNCTION_QUADRATURE_X2_A:
 		if (synapse->signal->id == signal_a_id)
-			*action = QUAD8_SYNAPSE_ACTION_BOTH_EDGES;
+			*action = COUNTER_SYNAPSE_ACTION_BOTH_EDGES;
 		break;
-	case QUAD8_COUNT_FUNCTION_QUADRATURE_X4:
-		*action = QUAD8_SYNAPSE_ACTION_BOTH_EDGES;
+	case COUNTER_COUNT_FUNCTION_QUADRATURE_X4:
+		*action = COUNTER_SYNAPSE_ACTION_BOTH_EDGES;
 		break;
 	}
 
 	return 0;
 }
 
-static const struct counter_ops quad8_ops = {
-	.signal_read = quad8_signal_read,
-	.count_read = quad8_count_read,
-	.count_write = quad8_count_write,
-	.function_get = quad8_function_get,
-	.function_set = quad8_function_set,
-	.action_get = quad8_action_get
-};
-
-static int quad8_index_polarity_get(struct counter_device *counter,
-	struct counter_signal *signal, size_t *index_polarity)
+static ssize_t quad8_index_polarity_read(struct counter_device *counter,
+					 struct counter_signal *signal,
+					 char *buf, size_t size)
 {
 	const struct quad8_iio *const priv = counter->priv;
-	const size_t channel_id = signal->id - 16;
-
-	*index_polarity = priv->index_polarity[channel_id];
+	const size_t index = priv->index_polarity[signal->id - 16];
 
-	return 0;
+	return snprintf(buf, size, "%s\n", quad8_index_polarity_modes[index]);
 }
 
-static int quad8_index_polarity_set(struct counter_device *counter,
-	struct counter_signal *signal, size_t index_polarity)
+static ssize_t quad8_index_polarity_write(struct counter_device *counter,
+					  struct counter_signal *signal,
+					  const char *buf, size_t size)
 {
 	struct quad8_iio *const priv = counter->priv;
 	const size_t channel_id = signal->id - 16;
 	const int base_offset = priv->base + 2 * channel_id + 1;
-	unsigned int idr_cfg = index_polarity << 1;
+	int index_polarity;
+	unsigned int idr_cfg;
 
-	mutex_lock(&priv->lock);
+	index_polarity = sysfs_match_string(quad8_index_polarity_modes, buf);
+	if (index_polarity < 0)
+		return index_polarity;
 
-	idr_cfg |= priv->synchronous_mode[channel_id];
+	mutex_lock(&priv->lock);
 
 	priv->index_polarity[channel_id] = index_polarity;
 
 	/* Load Index Control configuration to Index Control Register */
+	idr_cfg = priv->synchronous_mode[channel_id] | index_polarity << 1;
 	outb(QUAD8_CTR_IDR | idr_cfg, base_offset);
 
 	mutex_unlock(&priv->lock);
 
-	return 0;
+	return size;
 }
 
-static struct counter_signal_enum_ext quad8_index_pol_enum = {
-	.items = quad8_index_polarity_modes,
-	.num_items = ARRAY_SIZE(quad8_index_polarity_modes),
-	.get = quad8_index_polarity_get,
-	.set = quad8_index_polarity_set
-};
+static ssize_t quad8_index_polarity_available_read(
+	struct counter_device *counter, struct counter_signal *signal,
+	char *buf, size_t size)
+{
+	size_t i;
+	size_t len = 0;
 
-static int quad8_synchronous_mode_get(struct counter_device *counter,
-	struct counter_signal *signal, size_t *synchronous_mode)
+	for (i = 0; i < ARRAY_SIZE(quad8_index_polarity_modes) && size > 1; i++)
+		len += scnprintf(buf + len, size - len, "%s\n",
+				 quad8_index_polarity_modes[i]);
+
+	return len;
+}
+
+static ssize_t quad8_synchronous_mode_read(struct counter_device *counter,
+					   struct counter_signal *signal,
+					   char *buf, size_t size)
 {
 	const struct quad8_iio *const priv = counter->priv;
-	const size_t channel_id = signal->id - 16;
-
-	*synchronous_mode = priv->synchronous_mode[channel_id];
+	const size_t index = priv->synchronous_mode[signal->id - 16];
 
-	return 0;
+	return snprintf(buf, size, "%s\n", quad8_synchronous_modes[index]);
 }
 
-static int quad8_synchronous_mode_set(struct counter_device *counter,
-	struct counter_signal *signal, size_t synchronous_mode)
+static ssize_t quad8_synchronous_mode_write(struct counter_device *counter,
+					    struct counter_signal *signal,
+					    const char *buf, size_t size)
 {
 	struct quad8_iio *const priv = counter->priv;
 	const size_t channel_id = signal->id - 16;
 	const int base_offset = priv->base + 2 * channel_id + 1;
-	unsigned int idr_cfg = synchronous_mode;
+	int synchronous_mode;
+	unsigned int idr_cfg;
 
-	mutex_lock(&priv->lock);
+	synchronous_mode = sysfs_match_string(quad8_synchronous_modes, buf);
+	if (synchronous_mode < 0)
+		return synchronous_mode;
 
-	idr_cfg |= priv->index_polarity[channel_id] << 1;
+	mutex_lock(&priv->lock);
 
 	/* Index function must be non-synchronous in non-quadrature mode */
 	if (synchronous_mode && !priv->quadrature_mode[channel_id]) {
@@ -977,29 +974,39 @@ static int quad8_synchronous_mode_set(struct counter_device *counter,
 	priv->synchronous_mode[channel_id] = synchronous_mode;
 
 	/* Load Index Control configuration to Index Control Register */
+	idr_cfg = synchronous_mode | priv->index_polarity[channel_id] << 1;
 	outb(QUAD8_CTR_IDR | idr_cfg, base_offset);
 
 	mutex_unlock(&priv->lock);
 
-	return 0;
+	return size;
 }
 
-static struct counter_signal_enum_ext quad8_syn_mode_enum = {
-	.items = quad8_synchronous_modes,
-	.num_items = ARRAY_SIZE(quad8_synchronous_modes),
-	.get = quad8_synchronous_mode_get,
-	.set = quad8_synchronous_mode_set
-};
+static ssize_t quad8_synchronous_mode_available_read(
+	struct counter_device *counter, struct counter_signal *signal,
+	char *buf, size_t size)
+{
+	size_t i;
+	size_t len = 0;
 
-static ssize_t quad8_count_floor_read(struct counter_device *counter,
-	struct counter_count *count, void *private, char *buf)
+	for (i = 0; i < ARRAY_SIZE(quad8_synchronous_modes) && size > 1; i++)
+		len += scnprintf(buf + len, size - len, "%s\n",
+				 quad8_synchronous_modes[i]);
+
+	return len;
+}
+
+static int quad8_count_floor_read(struct counter_device *counter,
+				  struct counter_count *count, u64 *floor)
 {
 	/* Only a floor of 0 is supported */
-	return sprintf(buf, "0\n");
+	*floor = 0;
+
+	return 0;
 }
 
-static int quad8_count_mode_get(struct counter_device *counter,
-	struct counter_count *count, size_t *cnt_mode)
+static int quad8_count_mode_read(struct counter_device *counter,
+				 struct counter_count *count, u8 *cnt_mode)
 {
 	const struct quad8_iio *const priv = counter->priv;
 
@@ -1022,35 +1029,36 @@ static int quad8_count_mode_get(struct counter_device *counter,
 	return 0;
 }
 
-static int quad8_count_mode_set(struct counter_device *counter,
-	struct counter_count *count, size_t cnt_mode)
+static int quad8_count_mode_write(struct counter_device *counter,
+				  struct counter_count *count, u8 cnt_mode)
 {
 	struct quad8_iio *const priv = counter->priv;
+	unsigned int count_mode;
 	unsigned int mode_cfg;
 	const int base_offset = priv->base + 2 * count->id + 1;
 
 	/* Map Generic Counter count mode to 104-QUAD-8 count mode */
 	switch (cnt_mode) {
 	case COUNTER_COUNT_MODE_NORMAL:
-		cnt_mode = 0;
+		count_mode = 0;
 		break;
 	case COUNTER_COUNT_MODE_RANGE_LIMIT:
-		cnt_mode = 1;
+		count_mode = 1;
 		break;
 	case COUNTER_COUNT_MODE_NON_RECYCLE:
-		cnt_mode = 2;
+		count_mode = 2;
 		break;
 	case COUNTER_COUNT_MODE_MODULO_N:
-		cnt_mode = 3;
+		count_mode = 3;
 		break;
 	}
 
 	mutex_lock(&priv->lock);
 
-	priv->count_mode[count->id] = cnt_mode;
+	priv->count_mode[count->id] = count_mode;
 
 	/* Set count mode configuration value */
-	mode_cfg = cnt_mode << 1;
+	mode_cfg = count_mode << 1;
 
 	/* Add quadrature mode configuration */
 	if (priv->quadrature_mode[count->id])
@@ -1064,85 +1072,86 @@ static int quad8_count_mode_set(struct counter_device *counter,
 	return 0;
 }
 
-static struct counter_count_enum_ext quad8_cnt_mode_enum = {
-	.items = counter_count_mode_str,
-	.num_items = ARRAY_SIZE(counter_count_mode_str),
-	.get = quad8_count_mode_get,
-	.set = quad8_count_mode_set
+static const u8 quad8_cnt_modes[] = {
+	COUNTER_COUNT_MODE_NORMAL,
+	COUNTER_COUNT_MODE_RANGE_LIMIT,
+	COUNTER_COUNT_MODE_NON_RECYCLE,
+	COUNTER_COUNT_MODE_MODULO_N,
 };
 
-static ssize_t quad8_count_direction_read(struct counter_device *counter,
-	struct counter_count *count, void *priv, char *buf)
-{
-	enum counter_count_direction dir;
-
-	quad8_direction_get(counter, count, &dir);
-
-	return sprintf(buf, "%s\n", counter_count_direction_str[dir]);
-}
+static DEFINE_COUNTER_AVAILABLE(quad8_count_mode_available, quad8_cnt_modes);
 
-static ssize_t quad8_count_enable_read(struct counter_device *counter,
-	struct counter_count *count, void *private, char *buf)
+static int quad8_count_enable_read(struct counter_device *counter,
+				   struct counter_count *count, u8 *enable)
 {
 	const struct quad8_iio *const priv = counter->priv;
 
-	return sprintf(buf, "%u\n", priv->ab_enable[count->id]);
+	*enable = priv->ab_enable[count->id];
+
+	return 0;
 }
 
-static ssize_t quad8_count_enable_write(struct counter_device *counter,
-	struct counter_count *count, void *private, const char *buf, size_t len)
+static int quad8_count_enable_write(struct counter_device *counter,
+				    struct counter_count *count, u8 enable)
 {
 	struct quad8_iio *const priv = counter->priv;
 	const int base_offset = priv->base + 2 * count->id;
-	int err;
-	bool ab_enable;
 	unsigned int ior_cfg;
 
-	err = kstrtobool(buf, &ab_enable);
-	if (err)
-		return err;
-
 	mutex_lock(&priv->lock);
 
-	priv->ab_enable[count->id] = ab_enable;
+	priv->ab_enable[count->id] = enable;
 
-	ior_cfg = ab_enable | priv->preset_enable[count->id] << 1;
+	ior_cfg = enable | priv->preset_enable[count->id] << 1;
 
 	/* Load I/O control configuration */
 	outb(QUAD8_CTR_IOR | ior_cfg, base_offset + 1);
 
 	mutex_unlock(&priv->lock);
 
-	return len;
+	return 0;
 }
 
-static int quad8_error_noise_get(struct counter_device *counter,
-	struct counter_count *count, size_t *noise_error)
+static ssize_t quad8_error_noise_read(struct counter_device *counter,
+				      struct counter_count *count, char *buf,
+				      size_t size)
 {
 	const struct quad8_iio *const priv = counter->priv;
 	const int base_offset = priv->base + 2 * count->id + 1;
+	size_t noise_error;
 
-	*noise_error = !!(inb(base_offset) & QUAD8_FLAG_E);
+	noise_error = !!(inb(base_offset) & QUAD8_FLAG_E);
 
-	return 0;
+	return snprintf(buf, size, "%s\n",
+			quad8_noise_error_states[noise_error]);
 }
 
-static struct counter_count_enum_ext quad8_error_noise_enum = {
-	.items = quad8_noise_error_states,
-	.num_items = ARRAY_SIZE(quad8_noise_error_states),
-	.get = quad8_error_noise_get
-};
+static ssize_t quad8_error_noise_available_read(struct counter_device *counter,
+						struct counter_count *count,
+						char *buf, size_t size)
+{
+	size_t i;
+	size_t len = 0;
+
+	for (i = 0; i < ARRAY_SIZE(quad8_noise_error_states) && size > 1; i++)
+		len += scnprintf(buf + len, size - len, "%s\n",
+				 quad8_noise_error_states[i]);
+
+	return len;
+}
 
-static ssize_t quad8_count_preset_read(struct counter_device *counter,
-	struct counter_count *count, void *private, char *buf)
+static int quad8_count_preset_read(struct counter_device *counter,
+				   struct counter_count *count, u64 *preset)
 {
 	const struct quad8_iio *const priv = counter->priv;
 
-	return sprintf(buf, "%u\n", priv->preset[count->id]);
+	*preset = priv->preset[count->id];
+
+	return 0;
 }
 
-static void quad8_preset_register_set(struct quad8_iio *quad8iio, int id,
-		unsigned int preset)
+static void quad8_preset_register_set(struct quad8_iio *const quad8iio,
+				      const int id, const u64 preset)
 {
 	const unsigned int base_offset = quad8iio->base + 2 * id;
 	int i;
@@ -1157,16 +1166,10 @@ static void quad8_preset_register_set(struct quad8_iio *quad8iio, int id,
 		outb(preset >> (8 * i), base_offset);
 }
 
-static ssize_t quad8_count_preset_write(struct counter_device *counter,
-	struct counter_count *count, void *private, const char *buf, size_t len)
+static int quad8_count_preset_write(struct counter_device *counter,
+				    struct counter_count *count, u64 preset)
 {
 	struct quad8_iio *const priv = counter->priv;
-	unsigned int preset;
-	int ret;
-
-	ret = kstrtouint(buf, 0, &preset);
-	if (ret)
-		return ret;
 
 	/* Only 24-bit values are supported */
 	if (preset > 0xFFFFFF)
@@ -1178,11 +1181,11 @@ static ssize_t quad8_count_preset_write(struct counter_device *counter,
 
 	mutex_unlock(&priv->lock);
 
-	return len;
+	return 0;
 }
 
-static ssize_t quad8_count_ceiling_read(struct counter_device *counter,
-	struct counter_count *count, void *private, char *buf)
+static int quad8_count_ceiling_read(struct counter_device *counter,
+				    struct counter_count *count, u64 *ceiling)
 {
 	struct quad8_iio *const priv = counter->priv;
 
@@ -1193,25 +1196,21 @@ static ssize_t quad8_count_ceiling_read(struct counter_device *counter,
 	case 1:
 	case 3:
 		mutex_unlock(&priv->lock);
-		return sprintf(buf, "%u\n", priv->preset[count->id]);
+		return quad8_count_preset_read(counter, count, ceiling);
 	}
 
 	mutex_unlock(&priv->lock);
 
 	/* By default 0x1FFFFFF (25 bits unsigned) is maximum count */
-	return sprintf(buf, "33554431\n");
+	*ceiling = 0x1FFFFFF;
+
+	return 0;
 }
 
-static ssize_t quad8_count_ceiling_write(struct counter_device *counter,
-	struct counter_count *count, void *private, const char *buf, size_t len)
+static int quad8_count_ceiling_write(struct counter_device *counter,
+				     struct counter_count *count, u64 ceiling)
 {
 	struct quad8_iio *const priv = counter->priv;
-	unsigned int ceiling;
-	int ret;
-
-	ret = kstrtouint(buf, 0, &ceiling);
-	if (ret)
-		return ret;
 
 	/* Only 24-bit values are supported */
 	if (ceiling > 0xFFFFFF)
@@ -1223,36 +1222,33 @@ static ssize_t quad8_count_ceiling_write(struct counter_device *counter,
 	switch (priv->count_mode[count->id]) {
 	case 1:
 	case 3:
-		quad8_preset_register_set(priv, count->id, ceiling);
-		break;
+		return quad8_count_preset_write(counter, count, ceiling);
 	}
 
 	mutex_unlock(&priv->lock);
 
-	return len;
+	return -EINVAL;
 }
 
-static ssize_t quad8_count_preset_enable_read(struct counter_device *counter,
-	struct counter_count *count, void *private, char *buf)
+static int quad8_count_preset_enable_read(struct counter_device *counter,
+					  struct counter_count *count,
+					  u8 *preset_enable)
 {
 	const struct quad8_iio *const priv = counter->priv;
 
-	return sprintf(buf, "%u\n", !priv->preset_enable[count->id]);
+	*preset_enable = !priv->preset_enable[count->id];
+
+	return 0;
 }
 
-static ssize_t quad8_count_preset_enable_write(struct counter_device *counter,
-	struct counter_count *count, void *private, const char *buf, size_t len)
+static int quad8_count_preset_enable_write(struct counter_device *counter,
+					   struct counter_count *count,
+					   u8 preset_enable)
 {
 	struct quad8_iio *const priv = counter->priv;
 	const int base_offset = priv->base + 2 * count->id + 1;
-	bool preset_enable;
-	int ret;
 	unsigned int ior_cfg;
 
-	ret = kstrtobool(buf, &preset_enable);
-	if (ret)
-		return ret;
-
 	/* Preset enable is active low in Input/Output Control register */
 	preset_enable = !preset_enable;
 
@@ -1260,25 +1256,24 @@ static ssize_t quad8_count_preset_enable_write(struct counter_device *counter,
 
 	priv->preset_enable[count->id] = preset_enable;
 
-	ior_cfg = priv->ab_enable[count->id] | (unsigned int)preset_enable << 1;
+	ior_cfg = priv->ab_enable[count->id] | preset_enable << 1;
 
 	/* Load I/O control configuration to Input / Output Control Register */
 	outb(QUAD8_CTR_IOR | ior_cfg, base_offset);
 
 	mutex_unlock(&priv->lock);
 
-	return len;
+	return 0;
 }
 
-static ssize_t quad8_signal_cable_fault_read(struct counter_device *counter,
-					     struct counter_signal *signal,
-					     void *private, char *buf)
+static int quad8_signal_cable_fault_read(struct counter_device *counter,
+					 struct counter_signal *signal,
+					 u8 *cable_fault)
 {
 	const struct quad8_iio *const priv = counter->priv;
 	const size_t channel_id = signal->id / 2;
 	const bool disabled = !(priv->cable_fault_enable & BIT(channel_id));
 	unsigned int status;
-	unsigned int fault;
 
 	if (disabled)
 		return -EINVAL;
@@ -1287,36 +1282,31 @@ static ssize_t quad8_signal_cable_fault_read(struct counter_device *counter,
 	status = inb(priv->base + QUAD8_DIFF_ENCODER_CABLE_STATUS);
 
 	/* Mask respective channel and invert logic */
-	fault = !(status & BIT(channel_id));
+	*cable_fault = !(status & BIT(channel_id));
 
-	return sprintf(buf, "%u\n", fault);
+	return 0;
 }
 
-static ssize_t quad8_signal_cable_fault_enable_read(
-	struct counter_device *counter, struct counter_signal *signal,
-	void *private, char *buf)
+static int quad8_signal_cable_fault_enable_read(struct counter_device *counter,
+						struct counter_signal *signal,
+						u8 *enable)
 {
 	const struct quad8_iio *const priv = counter->priv;
 	const size_t channel_id = signal->id / 2;
-	const unsigned int enb = !!(priv->cable_fault_enable & BIT(channel_id));
 
-	return sprintf(buf, "%u\n", enb);
+	*enable = !!(priv->cable_fault_enable & BIT(channel_id));
+
+	return 0;
 }
 
-static ssize_t quad8_signal_cable_fault_enable_write(
-	struct counter_device *counter, struct counter_signal *signal,
-	void *private, const char *buf, size_t len)
+static int quad8_signal_cable_fault_enable_write(struct counter_device *counter,
+						 struct counter_signal *signal,
+						 u8 enable)
 {
 	struct quad8_iio *const priv = counter->priv;
 	const size_t channel_id = signal->id / 2;
-	bool enable;
-	int ret;
 	unsigned int cable_fault_enable;
 
-	ret = kstrtobool(buf, &enable);
-	if (ret)
-		return ret;
-
 	if (enable)
 		priv->cable_fault_enable |= BIT(channel_id);
 	else
@@ -1327,31 +1317,27 @@ static ssize_t quad8_signal_cable_fault_enable_write(
 
 	outb(cable_fault_enable, priv->base + QUAD8_DIFF_ENCODER_CABLE_STATUS);
 
-	return len;
+	return 0;
 }
 
-static ssize_t quad8_signal_fck_prescaler_read(struct counter_device *counter,
-	struct counter_signal *signal, void *private, char *buf)
+static int quad8_signal_fck_prescaler_read(struct counter_device *counter,
+					   struct counter_signal *signal,
+					   u8 *prescaler)
 {
 	const struct quad8_iio *const priv = counter->priv;
-	const size_t channel_id = signal->id / 2;
 
-	return sprintf(buf, "%u\n", priv->fck_prescaler[channel_id]);
+	*prescaler = priv->fck_prescaler[signal->id / 2];
+
+	return 0;
 }
 
-static ssize_t quad8_signal_fck_prescaler_write(struct counter_device *counter,
-	struct counter_signal *signal, void *private, const char *buf,
-	size_t len)
+static int quad8_signal_fck_prescaler_write(struct counter_device *counter,
+					    struct counter_signal *signal,
+					    u8 prescaler)
 {
 	struct quad8_iio *const priv = counter->priv;
 	const size_t channel_id = signal->id / 2;
 	const int base_offset = priv->base + 2 * channel_id;
-	u8 prescaler;
-	int ret;
-
-	ret = kstrtou8(buf, 0, &prescaler);
-	if (ret)
-		return ret;
 
 	priv->fck_prescaler[channel_id] = prescaler;
 
@@ -1363,31 +1349,30 @@ static ssize_t quad8_signal_fck_prescaler_write(struct counter_device *counter,
 	outb(QUAD8_CTR_RLD | QUAD8_RLD_RESET_BP | QUAD8_RLD_PRESET_PSC,
 	     base_offset + 1);
 
-	return len;
+	return 0;
 }
 
-static const struct counter_signal_ext quad8_signal_ext[] = {
-	{
-		.name = "cable_fault",
-		.read = quad8_signal_cable_fault_read
-	},
-	{
-		.name = "cable_fault_enable",
-		.read = quad8_signal_cable_fault_enable_read,
-		.write = quad8_signal_cable_fault_enable_write
-	},
-	{
-		.name = "filter_clock_prescaler",
-		.read = quad8_signal_fck_prescaler_read,
-		.write = quad8_signal_fck_prescaler_write
-	}
+static struct counter_data quad8_signal_ext[] = {
+	COUNTER_DATA_SIGNAL_BOOL("cable_fault", quad8_signal_cable_fault_read,
+				 NULL),
+	COUNTER_DATA_SIGNAL_BOOL("cable_fault_enable",
+				 quad8_signal_cable_fault_enable_read,
+				 quad8_signal_cable_fault_enable_write),
+	COUNTER_DATA_SIGNAL_U8("filter_clock_prescaler",
+			       quad8_signal_fck_prescaler_read,
+			       quad8_signal_fck_prescaler_write)
 };
 
-static const struct counter_signal_ext quad8_index_ext[] = {
-	COUNTER_SIGNAL_ENUM("index_polarity", &quad8_index_pol_enum),
-	COUNTER_SIGNAL_ENUM_AVAILABLE("index_polarity",	&quad8_index_pol_enum),
-	COUNTER_SIGNAL_ENUM("synchronous_mode", &quad8_syn_mode_enum),
-	COUNTER_SIGNAL_ENUM_AVAILABLE("synchronous_mode", &quad8_syn_mode_enum)
+static struct counter_data quad8_index_ext[] = {
+	COUNTER_DATA_SIGNAL_STRING("index_polarity", quad8_index_polarity_read,
+				   quad8_index_polarity_write),
+	COUNTER_DATA_SIGNAL_STRING("index_polarity_available",
+				   quad8_index_polarity_available_read, NULL),
+	COUNTER_DATA_SIGNAL_STRING("synchronous_mode",
+				   quad8_synchronous_mode_read,
+				   quad8_synchronous_mode_write),
+	COUNTER_DATA_SIGNAL_STRING("synchronous_mode_available",
+				   quad8_synchronous_mode_available_read, NULL),
 };
 
 #define QUAD8_QUAD_SIGNAL(_id, _name) {		\
@@ -1456,39 +1441,20 @@ static struct counter_synapse quad8_count_synapses[][3] = {
 	QUAD8_COUNT_SYNAPSES(6), QUAD8_COUNT_SYNAPSES(7)
 };
 
-static const struct counter_count_ext quad8_count_ext[] = {
-	{
-		.name = "ceiling",
-		.read = quad8_count_ceiling_read,
-		.write = quad8_count_ceiling_write
-	},
-	{
-		.name = "floor",
-		.read = quad8_count_floor_read
-	},
-	COUNTER_COUNT_ENUM("count_mode", &quad8_cnt_mode_enum),
-	COUNTER_COUNT_ENUM_AVAILABLE("count_mode", &quad8_cnt_mode_enum),
-	{
-		.name = "direction",
-		.read = quad8_count_direction_read
-	},
-	{
-		.name = "enable",
-		.read = quad8_count_enable_read,
-		.write = quad8_count_enable_write
-	},
-	COUNTER_COUNT_ENUM("error_noise", &quad8_error_noise_enum),
-	COUNTER_COUNT_ENUM_AVAILABLE("error_noise", &quad8_error_noise_enum),
-	{
-		.name = "preset",
-		.read = quad8_count_preset_read,
-		.write = quad8_count_preset_write
-	},
-	{
-		.name = "preset_enable",
-		.read = quad8_count_preset_enable_read,
-		.write = quad8_count_preset_enable_write
-	}
+static struct counter_data quad8_count_ext[] = {
+	COUNTER_DATA_CEILING(quad8_count_ceiling_read,
+			     quad8_count_ceiling_write),
+	COUNTER_DATA_FLOOR(quad8_count_floor_read, NULL),
+	COUNTER_DATA_COUNT_MODE(quad8_count_mode_read, quad8_count_mode_write,
+				quad8_count_mode_available),
+	COUNTER_DATA_DIRECTION(quad8_direction_read),
+	COUNTER_DATA_ENABLE(quad8_count_enable_read, quad8_count_enable_write),
+	COUNTER_DATA_COUNT_STRING("error_noise", quad8_error_noise_read, NULL),
+	COUNTER_DATA_COUNT_STRING("error_noise_available",
+				  quad8_error_noise_available_read, NULL),
+	COUNTER_DATA_PRESET(quad8_count_preset_read, quad8_count_preset_write),
+	COUNTER_DATA_PRESET_ENABLE(quad8_count_preset_enable_read,
+				   quad8_count_preset_enable_write),
 };
 
 #define QUAD8_COUNT(_id, _cntname) {					\
@@ -1544,7 +1510,12 @@ static int quad8_probe(struct device *dev, unsigned int id)
 	quad8iio = iio_priv(indio_dev);
 	quad8iio->counter.name = dev_name(dev);
 	quad8iio->counter.parent = dev;
-	quad8iio->counter.ops = &quad8_ops;
+	quad8iio->counter.signal_read = quad8_signal_read;
+	quad8iio->counter.count_read = quad8_count_read;
+	quad8iio->counter.count_write = quad8_count_write;
+	quad8iio->counter.function_read = quad8_function_read;
+	quad8iio->counter.function_write = quad8_function_write;
+	quad8iio->counter.action_read = quad8_action_read;
 	quad8iio->counter.counts = quad8_counts;
 	quad8iio->counter.num_counts = ARRAY_SIZE(quad8_counts);
 	quad8iio->counter.signals = quad8_signals;
drivers/counter/Makefile +1 -0
index 55142d1f4c43..f48e337cbd85 100644
@@ -4,6 +4,7 @@
 #
 
 obj-$(CONFIG_COUNTER) += counter.o
+counter-y := counter-core.o counter-sysfs.o
 
 obj-$(CONFIG_104_QUAD_8)	+= 104-quad-8.o
 obj-$(CONFIG_STM32_TIMER_CNT)	+= stm32-timer-cnt.o
drivers/counter/counter-core.c new file +157 -0
new file mode 100644
index 000000000000..499664809c75
@@ -0,0 +1,157 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Generic Counter interface
+ * Copyright (C) 2020 William Breathitt Gray
+ */
+#include <linux/counter.h>
+#include <linux/device.h>
+#include <linux/export.h>
+#include <linux/gfp.h>
+#include <linux/idr.h>
+#include <linux/init.h>
+#include <linux/module.h>
+
+#include "counter-sysfs.h"
+
+/* Provides a unique ID for each counter device */
+static DEFINE_IDA(counter_ida);
+
+static void counter_device_release(struct device *dev)
+{
+	struct counter_device *const counter = dev_get_drvdata(dev);
+
+	counter_sysfs_free(counter);
+	ida_simple_remove(&counter_ida, counter->id);
+}
+
+static struct device_type counter_device_type = {
+	.name = "counter_device",
+	.release = counter_device_release
+};
+
+static struct bus_type counter_bus_type = {
+	.name = "counter"
+};
+
+/**
+ * counter_register - register Counter to the system
+ * @counter:	pointer to Counter to register
+ *
+ * This function registers a Counter to the system. A sysfs "counter" directory
+ * will be created and populated with sysfs attributes correlating with the
+ * Counter Signals, Synapses, and Counts respectively.
+ */
+int counter_register(struct counter_device *const counter)
+{
+	struct device *const dev = &counter->dev;
+	int err;
+
+	/* Acquire unique ID */
+	counter->id = ida_simple_get(&counter_ida, 0, 0, GFP_KERNEL);
+	if (counter->id < 0)
+		return counter->id;
+
+	/* Configure device structure for Counter */
+	dev->type = &counter_device_type;
+	dev->bus = &counter_bus_type;
+	if (counter->parent) {
+		dev->parent = counter->parent;
+		dev->of_node = counter->parent->of_node;
+	}
+	dev_set_name(dev, "counter%d", counter->id);
+	device_initialize(dev);
+	dev_set_drvdata(dev, counter);
+
+	/* Add Counter sysfs attributes */
+	err = counter_sysfs_add(counter);
+	if (err)
+		goto err_free_id;
+
+	/* Add device to system */
+	err = device_add(dev);
+	if (err)
+		goto err_free_sysfs;
+
+	return 0;
+
+err_free_sysfs:
+	counter_sysfs_free(counter);
+err_free_id:
+	ida_simple_remove(&counter_ida, counter->id);
+	return err;
+}
+EXPORT_SYMBOL_GPL(counter_register);
+
+/**
+ * counter_unregister - unregister Counter from the system
+ * @counter:	pointer to Counter to unregister
+ *
+ * The Counter is unregistered from the system; all allocated memory is freed.
+ */
+void counter_unregister(struct counter_device *const counter)
+{
+	if (counter) {
+		device_del(&counter->dev);
+		counter_sysfs_free(counter);
+	}
+}
+EXPORT_SYMBOL_GPL(counter_unregister);
+
+static void devm_counter_unreg(struct device *dev, void *res)
+{
+	counter_unregister(*(struct counter_device **)res);
+}
+
+/**
+ * devm_counter_register - Resource-managed counter_register
+ * @dev:	device to allocate counter_device for
+ * @counter:	pointer to Counter to register
+ *
+ * Managed counter_register. The Counter registered with this function is
+ * automatically unregistered on driver detach. This function calls
+ * counter_register internally. Refer to that function for more information.
+ *
+ * If an Counter registered with this function needs to be unregistered
+ * separately, devm_counter_unregister must be used.
+ *
+ * RETURNS:
+ * 0 on success, negative error number on failure.
+ */
+int devm_counter_register(struct device *dev,
+			  struct counter_device *const counter)
+{
+	struct counter_device **ptr;
+	int ret;
+
+	ptr = devres_alloc(devm_counter_unreg, sizeof(*ptr), GFP_KERNEL);
+	if (!ptr)
+		return -ENOMEM;
+
+	ret = counter_register(counter);
+	if (!ret) {
+		*ptr = counter;
+		devres_add(dev, ptr);
+	} else {
+		devres_free(ptr);
+	}
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(devm_counter_register);
+
+static int __init counter_init(void)
+{
+	return bus_register(&counter_bus_type);
+}
+
+static void __exit counter_exit(void)
+{
+	bus_unregister(&counter_bus_type);
+}
+
+subsys_initcall(counter_init);
+module_exit(counter_exit);
+
+MODULE_AUTHOR("William Breathitt Gray <[email protected]>");
+MODULE_DESCRIPTION("Generic Counter interface");
+MODULE_LICENSE("GPL v2");
drivers/counter/counter-sysfs.c new file +881 -0
new file mode 100644
index 000000000000..d30a3239eb41
@@ -0,0 +1,881 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Generic Counter sysfs interface
+ * Copyright (C) 2020 William Breathitt Gray
+ */
+#include <linux/counter.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/gfp.h>
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/sysfs.h>
+#include <linux/types.h>
+
+enum counter_owner_type {
+	COUNTER_OWNER_TYPE_DEVICE,
+	COUNTER_OWNER_TYPE_SIGNAL,
+	COUNTER_OWNER_TYPE_COUNT,
+};
+
+struct counter_attribute {
+	struct device_attribute dev_attr;
+	struct list_head l;
+
+	struct counter_data data;
+	enum counter_owner_type type;
+	void *owner;
+};
+
+#define to_counter_attribute(_dev_attr) \
+	container_of(_dev_attr, struct counter_attribute, dev_attr)
+
+static const char *const counter_count_function_str[] = {
+	[COUNTER_COUNT_FUNCTION_INCREASE] = "increase",
+	[COUNTER_COUNT_FUNCTION_DECREASE] = "decrease",
+	[COUNTER_COUNT_FUNCTION_PULSE_DIRECTION] = "pulse-direction",
+	[COUNTER_COUNT_FUNCTION_QUADRATURE_X1_A] = "quadrature x1 a",
+	[COUNTER_COUNT_FUNCTION_QUADRATURE_X1_B] = "quadrature x1 b",
+	[COUNTER_COUNT_FUNCTION_QUADRATURE_X2_A] = "quadrature x2 a",
+	[COUNTER_COUNT_FUNCTION_QUADRATURE_X2_B] = "quadrature x2 b",
+	[COUNTER_COUNT_FUNCTION_QUADRATURE_X4] = "quadrature x4"
+};
+
+static const char *const counter_signal_value_str[] = {
+	[COUNTER_SIGNAL_LOW] = "low",
+	[COUNTER_SIGNAL_HIGH] = "high"
+};
+
+static const char *const counter_synapse_action_str[] = {
+	[COUNTER_SYNAPSE_ACTION_NONE] = "none",
+	[COUNTER_SYNAPSE_ACTION_RISING_EDGE] = "rising edge",
+	[COUNTER_SYNAPSE_ACTION_FALLING_EDGE] = "falling edge",
+	[COUNTER_SYNAPSE_ACTION_BOTH_EDGES] = "both edges"
+};
+
+static const char *const counter_count_direction_str[] = {
+	[COUNTER_COUNT_DIRECTION_FORWARD] = "forward",
+	[COUNTER_COUNT_DIRECTION_BACKWARD] = "backward"
+};
+
+static const char *const counter_count_mode_str[] = {
+	[COUNTER_COUNT_MODE_NORMAL] = "normal",
+	[COUNTER_COUNT_MODE_RANGE_LIMIT] = "range limit",
+	[COUNTER_COUNT_MODE_NON_RECYCLE] = "non-recycle",
+	[COUNTER_COUNT_MODE_MODULO_N] = "modulo-n"
+};
+
+static ssize_t counter_data_u8_show(struct device *dev,
+				    struct device_attribute *attr, char *buf)
+{
+	const struct counter_attribute *const a = to_counter_attribute(attr);
+	struct counter_device *const counter = dev_get_drvdata(dev);
+	int err;
+	u8 data;
+
+	switch (a->type) {
+	case COUNTER_OWNER_TYPE_DEVICE:
+		err = a->data.device_u8_read(counter, &data);
+		break;
+	case COUNTER_OWNER_TYPE_SIGNAL:
+		err = a->data.signal_u8_read(counter, a->owner, &data);
+		break;
+	case COUNTER_OWNER_TYPE_COUNT:
+		if (a->data.type == COUNTER_DATA_TYPE_SYNAPSE_ACTION)
+			err = a->data.action_read(counter, a->owner,
+						  a->data.priv, &data);
+		else
+			err = a->data.count_u8_read(counter, a->owner, &data);
+		break;
+	default: return -EINVAL;
+	}
+	if (err)
+		return err;
+
+	switch (a->data.type) {
+	case COUNTER_DATA_TYPE_BOOL:
+		return sprintf(buf, "%u\n", (unsigned int)!!data);
+	case COUNTER_DATA_TYPE_COUNT_FUNCTION:
+		return sprintf(buf, "%s\n", counter_count_function_str[data]);
+	case COUNTER_DATA_TYPE_SIGNAL:
+		return sprintf(buf, "%s\n", counter_signal_value_str[data]);
+	case COUNTER_DATA_TYPE_SYNAPSE_ACTION:
+		return sprintf(buf, "%s\n", counter_synapse_action_str[data]);
+	case COUNTER_DATA_TYPE_COUNT_DIRECTION:
+		return sprintf(buf, "%s\n", counter_count_direction_str[data]);
+	case COUNTER_DATA_TYPE_COUNT_MODE:
+		return sprintf(buf, "%s\n", counter_count_mode_str[data]);
+	}
+
+	return sprintf(buf, "%u\n", (unsigned int)data);
+}
+
+static int find_in_string_array(u8 *const item, const u8 *const items,
+				const size_t num_items, const char *const buf,
+				const char *const string_array[])
+{
+	size_t index;
+
+	for (index = 0; index < num_items; index++) {
+		*item = items[index];
+		if (sysfs_streq(buf, string_array[*item]))
+			return 0;
+	}
+
+	return -EINVAL;
+}
+
+static ssize_t counter_data_u8_store(struct device *dev,
+				     struct device_attribute *attr,
+				     const char *buf, size_t len)
+{
+	const struct counter_attribute *const a = to_counter_attribute(attr);
+	struct counter_device *const counter = dev_get_drvdata(dev);
+	struct counter_count *const count = a->owner;
+	struct counter_synapse *const synapse = a->data.priv;
+	const struct counter_available *const available = a->data.priv;
+	int err;
+	bool bool_data;
+	u8 data;
+
+	switch (a->data.type) {
+	case COUNTER_DATA_TYPE_BOOL:
+		err = kstrtobool(buf, &bool_data);
+		data = bool_data;
+		break;
+	case COUNTER_DATA_TYPE_COUNT_FUNCTION:
+		err = find_in_string_array(&data, count->functions_list,
+					   count->num_functions, buf,
+					   counter_count_function_str);
+		break;
+	case COUNTER_DATA_TYPE_SYNAPSE_ACTION:
+		err = find_in_string_array(&data, synapse->actions_list,
+					   synapse->num_actions, buf,
+					   counter_synapse_action_str);
+		break;
+	case COUNTER_DATA_TYPE_COUNT_MODE:
+		err = find_in_string_array(&data, available->items,
+					   available->num_items, buf,
+					   counter_count_mode_str);
+		break;
+	default:
+		err = kstrtou8(buf, 0, &data);
+		break;
+	}
+	if (err)
+		return err;
+
+	switch (a->type) {
+	case COUNTER_OWNER_TYPE_DEVICE:
+		err = a->data.device_u8_write(counter, data);
+		break;
+	case COUNTER_OWNER_TYPE_SIGNAL:
+		err = a->data.signal_u8_write(counter, a->owner, data);
+		break;
+	case COUNTER_OWNER_TYPE_COUNT:
+		if (a->data.type == COUNTER_DATA_TYPE_SYNAPSE_ACTION)
+			err = a->data.action_write(counter, count, synapse,
+						   data);
+		else
+			err = a->data.count_u8_write(counter, count, data);
+		break;
+	}
+	if (err)
+		return err;
+
+	return len;
+}
+
+static ssize_t counter_data_u64_show(struct device *dev,
+				     struct device_attribute *attr, char *buf)
+{
+	const struct counter_attribute *const a = to_counter_attribute(attr);
+	struct counter_device *const counter = dev_get_drvdata(dev);
+	int err;
+	u64 data;
+
+	switch (a->type) {
+	case COUNTER_OWNER_TYPE_DEVICE:
+		err = a->data.device_u64_read(counter, &data);
+		break;
+	case COUNTER_OWNER_TYPE_SIGNAL:
+		err = a->data.signal_u64_read(counter, a->owner, &data);
+		break;
+	case COUNTER_OWNER_TYPE_COUNT:
+		err = a->data.count_u64_read(counter, a->owner, &data);
+		break;
+	default: return -EINVAL;
+	}
+	if (err)
+		return err;
+
+	return sprintf(buf, "%llu\n", (unsigned long long)data);
+}
+
+static ssize_t counter_data_u64_store(struct device *dev,
+				      struct device_attribute *attr,
+				      const char *buf, size_t len)
+{
+	const struct counter_attribute *const a = to_counter_attribute(attr);
+	struct counter_device *const counter = dev_get_drvdata(dev);
+	int err;
+	u64 data;
+
+	err = kstrtou64(buf, 0, &data);
+	if (err)
+		return err;
+
+	switch (a->type) {
+	case COUNTER_OWNER_TYPE_DEVICE:
+		err = a->data.device_u64_write(counter, data);
+		break;
+	case COUNTER_OWNER_TYPE_SIGNAL:
+		err = a->data.signal_u64_write(counter, a->owner, data);
+		break;
+	case COUNTER_OWNER_TYPE_COUNT:
+		err = a->data.count_u64_write(counter, a->owner, data);
+		break;
+	}
+	if (err)
+		return err;
+
+	return len;
+}
+
+static ssize_t counter_data_string_show(struct device *dev,
+					struct device_attribute *attr,
+					char *buf)
+{
+	const struct counter_attribute *const a = to_counter_attribute(attr);
+	struct counter_device *const counter = dev_get_drvdata(dev);
+
+	switch (a->type) {
+	case COUNTER_OWNER_TYPE_DEVICE:
+		return a->data.device_string_read(counter, buf, PAGE_SIZE);
+	case COUNTER_OWNER_TYPE_SIGNAL:
+		return a->data.signal_string_read(counter, a->owner, buf,
+						  PAGE_SIZE);
+	case COUNTER_OWNER_TYPE_COUNT:
+		return a->data.count_string_read(counter, a->owner, buf,
+						 PAGE_SIZE);
+	}
+
+	return -EINVAL;
+}
+
+static ssize_t counter_data_string_store(struct device *dev,
+					 struct device_attribute *attr,
+					 const char *buf, size_t len)
+{
+	const struct counter_attribute *const a = to_counter_attribute(attr);
+	struct counter_device *const counter = dev_get_drvdata(dev);
+
+	switch (a->type) {
+	case COUNTER_OWNER_TYPE_DEVICE:
+		return a->data.device_string_write(counter, buf, len);
+	case COUNTER_OWNER_TYPE_SIGNAL:
+		return a->data.signal_string_write(counter, a->owner, buf, len);
+	case COUNTER_OWNER_TYPE_COUNT:
+		return a->data.count_string_write(counter, a->owner, buf, len);
+	}
+
+	return -EINVAL;
+}
+
+static ssize_t items_available_show(const u8 *const items,
+				    const size_t num_items,
+				    const char *const string_array[], char *buf)
+{
+	size_t len = 0;
+	size_t index;
+
+	for (index = 0; index < num_items; index++)
+		len += sprintf(buf + len, "%s\n", string_array[items[index]]);
+
+	return len;
+}
+
+static ssize_t counter_data_available_show(struct device *dev,
+					   struct device_attribute *attr,
+					   char *buf)
+{
+	const struct counter_attribute *const a = to_counter_attribute(attr);
+	const struct counter_count *const count = a->owner;
+	const struct counter_synapse *const synapse = a->data.priv;
+	const struct counter_available *const available = a->data.priv;
+
+	switch (a->data.type) {
+	case COUNTER_DATA_TYPE_COUNT_FUNCTION:
+		return items_available_show(count->functions_list,
+					    count->num_functions,
+					    counter_count_function_str, buf);
+	case COUNTER_DATA_TYPE_SYNAPSE_ACTION:
+		return items_available_show(synapse->actions_list,
+					    synapse->num_actions,
+					    counter_synapse_action_str, buf);
+	case COUNTER_DATA_TYPE_COUNT_MODE:
+		return items_available_show(available->items,
+					    available->num_items,
+					    counter_count_mode_str, buf);
+	}
+
+	return -EINVAL;
+}
+
+struct counter_dynamic_name {
+	struct list_head l;
+	const char *name;
+};
+
+static int counter_available_attribute_create(
+	struct counter_attribute_group *const group,
+	struct list_head *const names, const struct counter_data *const data,
+	void *const owner)
+{
+	struct counter_attribute *counter_attr;
+	struct device_attribute *dev_attr;
+	struct counter_dynamic_name *dyn_name;
+
+	/* Allocate Counter attribute */
+	counter_attr = kzalloc(sizeof(*counter_attr), GFP_KERNEL);
+	if (!counter_attr)
+		return -ENOMEM;
+	list_add(&counter_attr->l, &group->attr_list);
+	group->num_attr++;
+
+	/* Configure Counter attribute */
+	counter_attr->data = *data;
+	counter_attr->owner = owner;
+
+	/* Initialize sysfs attribute */
+	dev_attr = &counter_attr->dev_attr;
+	sysfs_attr_init(&dev_attr->attr);
+
+	/* Generate dynamic name list item */
+	dyn_name = kmalloc(sizeof(*dyn_name), GFP_KERNEL);
+	if (!dyn_name)
+		return -ENOMEM;
+	list_add(&dyn_name->l, names);
+
+	/* Generate available attribute name */
+	dyn_name->name = kasprintf(GFP_KERNEL, "%s_available", data->name);
+	if (!dyn_name->name)
+		return -ENOMEM;
+
+	/* Configure device attribute */
+	dev_attr->attr.name = dyn_name->name;
+	dev_attr->attr.mode = 0444;
+	dev_attr->show = counter_data_available_show;
+
+	return 0;
+}
+
+static int counter_attribute_create(struct counter_attribute_group *const group,
+				    struct list_head *const names,
+				    const struct counter_data *const data,
+				    const enum counter_owner_type type,
+				    void *const owner)
+{
+	struct counter_attribute *counter_attr;
+	struct device_attribute *dev_attr;
+
+	/* Allocate Counter attribute */
+	counter_attr = kzalloc(sizeof(*counter_attr), GFP_KERNEL);
+	if (!counter_attr)
+		return -ENOMEM;
+	list_add(&counter_attr->l, &group->attr_list);
+	group->num_attr++;
+
+	/* Configure Counter attribute */
+	counter_attr->data = *data;
+	counter_attr->type = type;
+	counter_attr->owner = owner;
+
+	/* Configure device attribute */
+	dev_attr = &counter_attr->dev_attr;
+	sysfs_attr_init(&dev_attr->attr);
+	dev_attr->attr.name = data->name;
+	switch (data->type) {
+	case COUNTER_DATA_TYPE_U8:
+	case COUNTER_DATA_TYPE_BOOL:
+	case COUNTER_DATA_TYPE_SIGNAL:
+	case COUNTER_DATA_TYPE_COUNT_FUNCTION:
+	case COUNTER_DATA_TYPE_SYNAPSE_ACTION:
+	case COUNTER_DATA_TYPE_COUNT_DIRECTION:
+	case COUNTER_DATA_TYPE_COUNT_MODE:
+		if (data->device_u8_read) {
+			dev_attr->attr.mode |= 0444;
+			dev_attr->show = counter_data_u8_show;
+		}
+		if (data->device_u8_write) {
+			dev_attr->attr.mode |= 0200;
+			dev_attr->store = counter_data_u8_store;
+		}
+		break;
+	case COUNTER_DATA_TYPE_U64:
+		if (data->device_u64_read) {
+			dev_attr->attr.mode |= 0444;
+			dev_attr->show = counter_data_u64_show;
+		}
+		if (data->device_u64_write) {
+			dev_attr->attr.mode |= 0200;
+			dev_attr->store = counter_data_u64_store;
+		}
+		break;
+	case COUNTER_DATA_TYPE_STRING:
+		if (data->device_string_read) {
+			dev_attr->attr.mode |= 0444;
+			dev_attr->show = counter_data_string_show;
+		}
+		if (data->device_string_write) {
+			dev_attr->attr.mode |= 0200;
+			dev_attr->store = counter_data_string_store;
+		}
+		break;
+	}
+
+	switch (data->type) {
+	case COUNTER_DATA_TYPE_COUNT_FUNCTION:
+	case COUNTER_DATA_TYPE_SYNAPSE_ACTION:
+	case COUNTER_DATA_TYPE_COUNT_MODE:
+		return counter_available_attribute_create(group, names, data,
+							  owner);
+	}
+
+	return 0;
+}
+
+static struct counter_data counter_signal_data = {
+	.type = COUNTER_DATA_TYPE_SIGNAL,
+	.name = "signal",
+};
+
+static struct counter_data counter_name_data =
+	COUNTER_DATA_DEVICE_STRING("name", NULL, NULL);
+
+static ssize_t counter_signal_name_read(struct counter_device *counter,
+					struct counter_signal *signal,
+					char *buf, size_t size)
+{
+	return snprintf(buf, size, "%s\n", signal->name);
+}
+
+static int counter_signal_attributes_create(
+	struct counter_attribute_group *const group,
+	struct counter_device *const counter,
+	struct counter_signal *const signal)
+{
+	struct list_head *const names = &counter->dynamic_names_list;
+	const enum counter_owner_type type = COUNTER_OWNER_TYPE_SIGNAL;
+	int err;
+	struct counter_data data;
+	size_t i;
+	const struct counter_data *ext;
+
+	/* Create main Signal attribute */
+	data = counter_signal_data;
+	data.signal_u8_read = counter->signal_read;
+	err = counter_attribute_create(group, names, &data, type, signal);
+	if (err)
+		return err;
+
+	/* Create Signal name attribute */
+	data = counter_name_data;
+	data.signal_string_read = counter_signal_name_read;
+	err = counter_attribute_create(group, names, &data, type, signal);
+	if (err)
+		return err;
+
+	/* Create an attribute for each extension */
+	for (i = 0; i < signal->num_ext; i++) {
+		ext = signal->ext + i;
+		err = counter_attribute_create(group, names, ext, type, signal);
+		if (err)
+			return err;
+	}
+
+	return 0;
+}
+
+static int counter_signals_register(
+	struct counter_attribute_group *const groups_list,
+	struct counter_device *const counter)
+{
+	size_t i;
+	struct counter_signal *signal;
+	const char *name;
+	int err;
+
+	/* Register each Signal */
+	for (i = 0; i < counter->num_signals; i++) {
+		signal = counter->signals + i;
+
+		/* Generate Signal attribute directory name */
+		name = kasprintf(GFP_KERNEL, "signal%d", signal->id);
+		if (!name)
+			return -ENOMEM;
+		groups_list[i].attr_group.name = name;
+
+		/* Create all attributes associated with Signal */
+		err = counter_signal_attributes_create(groups_list + i, counter,
+						       signal);
+		if (err)
+			return err;
+	}
+
+	return 0;
+}
+
+static int counter_synapses_register(
+	struct counter_attribute_group *const group,
+	struct counter_device *const counter, struct counter_count *const count)
+{
+	struct list_head *const names = &counter->dynamic_names_list;
+	const enum counter_owner_type type = COUNTER_OWNER_TYPE_COUNT;
+	size_t i;
+	struct counter_synapse *synapse;
+	int id;
+	struct counter_dynamic_name *dyn_name;
+	struct counter_data data;
+	int err;
+
+	/* Register each Synapse */
+	for (i = 0; i < count->num_synapses; i++) {
+		synapse = count->synapses + i;
+		id = synapse->signal->id;
+
+		/* Generate dynamic name list item */
+		dyn_name = kmalloc(sizeof(*dyn_name), GFP_KERNEL);
+		if (!dyn_name)
+			return -ENOMEM;
+		list_add(&dyn_name->l, names);
+
+		/* Generate Synapse action name */
+		dyn_name->name = kasprintf(GFP_KERNEL, "signal%d_action", id);
+		if (!dyn_name->name)
+			return -ENOMEM;
+
+		/* Create action attribute */
+		data.type = COUNTER_DATA_TYPE_SYNAPSE_ACTION;
+		data.name = dyn_name->name;
+		data.action_read = counter->action_read;
+		data.action_write = counter->action_write;
+		data.priv = synapse;
+		err = counter_attribute_create(group, names, &data, type,
+					       count);
+		if (err)
+			return err;
+	}
+
+	return 0;
+}
+
+static struct counter_data counter_count_data =
+	COUNTER_DATA_COUNT_U64("count", NULL, NULL);
+
+static ssize_t counter_count_name_read(struct counter_device *counter,
+				       struct counter_count *count, char *buf,
+				       size_t size)
+{
+	return snprintf(buf, size, "%s\n", count->name);
+}
+
+static struct counter_data counter_count_function_data = {
+	.type = COUNTER_DATA_TYPE_COUNT_FUNCTION,
+	.name = "function",
+};
+
+static int counter_count_attributes_create(
+	struct counter_attribute_group *const group,
+	struct counter_device *const counter,
+	struct counter_count *const count)
+{
+	struct list_head *const names = &counter->dynamic_names_list;
+	const enum counter_owner_type type = COUNTER_OWNER_TYPE_COUNT;
+	int err;
+	struct counter_data data;
+	size_t i;
+	const struct counter_data *ext;
+
+	/* Create main Count attribute */
+	data = counter_count_data;
+	data.count_u64_read = counter->count_read;
+	data.count_u64_write = counter->count_write;
+	err = counter_attribute_create(group, names, &data, type, count);
+	if (err)
+		return err;
+
+	/* Create Count name attribute */
+	data = counter_name_data;
+	data.count_string_read = counter_count_name_read;
+	err = counter_attribute_create(group, names, &data, type, count);
+	if (err)
+		return err;
+
+	/* Create Count function attribute */
+	data = counter_count_function_data;
+	data.count_u8_read = counter->function_read;
+	data.count_u8_write = counter->function_write;
+	err = counter_attribute_create(group, names, &data, type, count);
+	if (err)
+		return err;
+
+	/* Create an attribute for each extension */
+	for (i = 0; i < count->num_ext; i++) {
+		ext = count->ext + i;
+		err = counter_attribute_create(group, names, ext, type, count);
+		if (err)
+			return err;
+	}
+
+	return 0;
+}
+
+static int counter_counts_register(
+	struct counter_attribute_group *const groups_list,
+	struct counter_device *const counter)
+{
+	size_t i;
+	struct counter_count *count;
+	const char *name;
+	int err;
+
+	/* Register each Count */
+	for (i = 0; i < counter->num_counts; i++) {
+		count = counter->counts + i;
+
+		/* Generate Count attribute directory name */
+		name = kasprintf(GFP_KERNEL, "count%d", count->id);
+		if (!name)
+			return -ENOMEM;
+		groups_list[i].attr_group.name = name;
+
+		/* Register the Synapses associated with each Count */
+		err = counter_synapses_register(groups_list + i, counter,
+						count);
+		if (err)
+			return err;
+
+		/* Create all attributes associated with Count */
+		err = counter_count_attributes_create(groups_list + i, counter,
+						      count);
+		if (err)
+			return err;
+	}
+
+	return 0;
+}
+
+static ssize_t counter_name_read(struct counter_device *counter, char *buf,
+				 size_t size)
+{
+	return snprintf(buf, size, "%s\n", counter->name);
+}
+
+static int counter_num_signals_read(struct counter_device *counter, u8 *val)
+{
+	*val = counter->num_signals;
+	return 0;
+}
+
+static int counter_num_counts_read(struct counter_device *counter, u8 *val)
+{
+	*val = counter->num_counts;
+	return 0;
+}
+
+static struct counter_data counter_num_signals_data =
+	COUNTER_DATA_DEVICE_U8("num_signals", counter_num_signals_read, NULL);
+
+static struct counter_data counter_num_counts_data =
+	COUNTER_DATA_DEVICE_U8("num_counts", counter_num_counts_read, NULL);
+
+static void counter_groups_list_free(struct counter_device *const counter)
+{
+	struct counter_attribute_group *group;
+	struct counter_attribute *p, *n;
+
+	/* Loop through all attribute groups (signals, counts, device, etc.) */
+	while (counter->num_groups--) {
+		group = counter->groups_list + counter->num_groups;
+
+		/* Free all attribute group and associated attributes memory */
+		kfree(group->attr_group.name);
+		kfree(group->attr_group.attrs);
+
+		/* Free attribute list */
+		list_for_each_entry_safe(p, n, &group->attr_list, l)
+			kfree(p);
+	}
+
+	kfree(counter->groups_list);
+}
+
+static int counter_device_register(struct counter_attribute_group *group,
+				   struct counter_device *const counter)
+{
+	struct list_head *const names = &counter->dynamic_names_list;
+	const enum counter_owner_type type = COUNTER_OWNER_TYPE_DEVICE;
+	struct counter_data data;
+	int err;
+	size_t i;
+	const struct counter_data *ext;
+
+	/* Register Signals */
+	err = counter_signals_register(group, counter);
+	if (err)
+		goto err_free_groups_list;
+	group += counter->num_signals;
+
+	/* Register Counts and respective Synapses */
+	err = counter_counts_register(group, counter);
+	if (err)
+		goto err_free_groups_list;
+	group += counter->num_counts;
+
+	/* Create name attribute */
+	data = counter_name_data;
+	data.device_string_read = counter_name_read;
+	err = counter_attribute_create(group, names, &data, type, NULL);
+	if (err)
+		goto err_free_groups_list;
+
+	/* Create num_signals attribute */
+	data = counter_num_signals_data;
+	err = counter_attribute_create(group, names, &data, type, NULL);
+	if (err)
+		goto err_free_groups_list;
+
+	/* Create num_counts attribute */
+	data = counter_num_counts_data;
+	err = counter_attribute_create(group, names, &data, type, NULL);
+	if (err)
+		goto err_free_groups_list;
+
+	/* Create an attribute for each extension */
+	for (i = 0; i < counter->num_ext; i++) {
+		ext = counter->ext + i;
+		err = counter_attribute_create(group, names, ext, type, NULL);
+		if (err)
+			goto err_free_groups_list;
+	}
+
+	return 0;
+
+err_free_groups_list:
+	counter_groups_list_free(counter);
+	return err;
+}
+
+static int counter_groups_list_prepare(struct counter_device *const counter)
+{
+	const size_t num_grps = counter->num_signals + counter->num_counts + 1;
+	struct counter_attribute_group *groups_list;
+	size_t i;
+
+	/* Allocate space for attribute groups (signals, counts, and ext) */
+	groups_list = kcalloc(num_grps, sizeof(*groups_list), GFP_KERNEL);
+	if (!groups_list)
+		return -ENOMEM;
+
+	/* Store groups_list in counter structure */
+	counter->groups_list = groups_list;
+	counter->num_groups = num_grps;
+
+	/* Initialize attribute lists */
+	for (i = 0; i < num_grps; i++)
+		INIT_LIST_HEAD(&groups_list[i].attr_list);
+
+	/* Register Counter device attributes */
+	return counter_device_register(groups_list, counter);
+}
+
+static int counter_groups_prepare(struct counter_device *const counter)
+{
+	size_t i, j;
+	struct counter_attribute_group *group;
+	struct attribute **attrs;
+	int err;
+	struct counter_attribute *p;
+
+	/* Allocate attribute groups for association with device */
+	counter->groups = kcalloc(counter->num_groups + 1,
+				  sizeof(*counter->groups), GFP_KERNEL);
+	if (!counter->groups)
+		return -ENOMEM;
+
+	/* Prepare each group of attributes for association */
+	for (i = 0; i < counter->num_groups; i++) {
+		group = counter->groups_list + i;
+
+		/* Allocate space for attribute pointers */
+		attrs = kcalloc(group->num_attr + 1, sizeof(*attrs),
+				GFP_KERNEL);
+		if (!attrs) {
+			err = -ENOMEM;
+			goto err_free_groups;
+		}
+		group->attr_group.attrs = attrs;
+
+		/* Add attribute pointers to attribute group */
+		j = 0;
+		list_for_each_entry(p, &group->attr_list, l)
+			attrs[j++] = &p->dev_attr.attr;
+
+		/* Group attributes in attribute group */
+		counter->groups[i] = &group->attr_group;
+	}
+	/* Associate attributes with device */
+	counter->dev.groups = counter->groups;
+
+	return 0;
+
+err_free_groups:
+	kfree(counter->groups);
+	return err;
+}
+
+static void counter_dynamic_names_free(struct list_head *const names)
+{
+	struct counter_dynamic_name *p, *n;
+
+	list_for_each_entry_safe(p, n, names, l) {
+		kfree(p->name);
+		kfree(p);
+	}
+}
+
+int counter_sysfs_add(struct counter_device *const counter)
+{
+	int err;
+
+	/* Initialize Synapse names list */
+	INIT_LIST_HEAD(&counter->dynamic_names_list);
+
+	/* Prepare device attributes */
+	err = counter_groups_list_prepare(counter);
+	if (err)
+		goto err_free_names;
+
+	/* Organize device attributes to groups and match to device */
+	err = counter_groups_prepare(counter);
+	if (err)
+		goto err_free_groups_list;
+
+	return 0;
+
+err_free_groups_list:
+	counter_groups_list_free(counter);
+err_free_names:
+	counter_dynamic_names_free(&counter->dynamic_names_list);
+	return err;
+}
+
+void counter_sysfs_free(struct counter_device *const counter)
+{
+	kfree(counter->groups);
+	counter_groups_list_free(counter);
+	counter_dynamic_names_free(&counter->dynamic_names_list);
+}
drivers/counter/counter-sysfs.h new file +14 -0
new file mode 100644
index 000000000000..00e7cd6ea083
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Counter sysfs interface
+ * Copyright (C) 2020 William Breathitt Gray
+ */
+#ifndef _COUNTER_SYSFS_H_
+#define _COUNTER_SYSFS_H_
+
+#include <linux/counter.h>
+
+int counter_sysfs_add(struct counter_device *const counter);
+void counter_sysfs_free(struct counter_device *const counter);
+
+#endif /* _COUNTER_SYSFS_H_ */
drivers/counter/counter.c deleted +0 -1496
deleted file mode 100644
index 6a683d086008..000000000000
@@ -1,1496 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * Generic Counter interface
- * Copyright (C) 2018 William Breathitt Gray
- */
-#include <linux/counter.h>
-#include <linux/device.h>
-#include <linux/err.h>
-#include <linux/export.h>
-#include <linux/fs.h>
-#include <linux/gfp.h>
-#include <linux/idr.h>
-#include <linux/init.h>
-#include <linux/kernel.h>
-#include <linux/list.h>
-#include <linux/module.h>
-#include <linux/printk.h>
-#include <linux/slab.h>
-#include <linux/string.h>
-#include <linux/sysfs.h>
-#include <linux/types.h>
-
-const char *const counter_count_direction_str[2] = {
-	[COUNTER_COUNT_DIRECTION_FORWARD] = "forward",
-	[COUNTER_COUNT_DIRECTION_BACKWARD] = "backward"
-};
-EXPORT_SYMBOL_GPL(counter_count_direction_str);
-
-const char *const counter_count_mode_str[4] = {
-	[COUNTER_COUNT_MODE_NORMAL] = "normal",
-	[COUNTER_COUNT_MODE_RANGE_LIMIT] = "range limit",
-	[COUNTER_COUNT_MODE_NON_RECYCLE] = "non-recycle",
-	[COUNTER_COUNT_MODE_MODULO_N] = "modulo-n"
-};
-EXPORT_SYMBOL_GPL(counter_count_mode_str);
-
-ssize_t counter_signal_enum_read(struct counter_device *counter,
-				 struct counter_signal *signal, void *priv,
-				 char *buf)
-{
-	const struct counter_signal_enum_ext *const e = priv;
-	int err;
-	size_t index;
-
-	if (!e->get)
-		return -EINVAL;
-
-	err = e->get(counter, signal, &index);
-	if (err)
-		return err;
-
-	if (index >= e->num_items)
-		return -EINVAL;
-
-	return sprintf(buf, "%s\n", e->items[index]);
-}
-EXPORT_SYMBOL_GPL(counter_signal_enum_read);
-
-ssize_t counter_signal_enum_write(struct counter_device *counter,
-				  struct counter_signal *signal, void *priv,
-				  const char *buf, size_t len)
-{
-	const struct counter_signal_enum_ext *const e = priv;
-	ssize_t index;
-	int err;
-
-	if (!e->set)
-		return -EINVAL;
-
-	index = __sysfs_match_string(e->items, e->num_items, buf);
-	if (index < 0)
-		return index;
-
-	err = e->set(counter, signal, index);
-	if (err)
-		return err;
-
-	return len;
-}
-EXPORT_SYMBOL_GPL(counter_signal_enum_write);
-
-ssize_t counter_signal_enum_available_read(struct counter_device *counter,
-					   struct counter_signal *signal,
-					   void *priv, char *buf)
-{
-	const struct counter_signal_enum_ext *const e = priv;
-	size_t i;
-	size_t len = 0;
-
-	if (!e->num_items)
-		return 0;
-
-	for (i = 0; i < e->num_items; i++)
-		len += sprintf(buf + len, "%s\n", e->items[i]);
-
-	return len;
-}
-EXPORT_SYMBOL_GPL(counter_signal_enum_available_read);
-
-ssize_t counter_count_enum_read(struct counter_device *counter,
-				struct counter_count *count, void *priv,
-				char *buf)
-{
-	const struct counter_count_enum_ext *const e = priv;
-	int err;
-	size_t index;
-
-	if (!e->get)
-		return -EINVAL;
-
-	err = e->get(counter, count, &index);
-	if (err)
-		return err;
-
-	if (index >= e->num_items)
-		return -EINVAL;
-
-	return sprintf(buf, "%s\n", e->items[index]);
-}
-EXPORT_SYMBOL_GPL(counter_count_enum_read);
-
-ssize_t counter_count_enum_write(struct counter_device *counter,
-				 struct counter_count *count, void *priv,
-				 const char *buf, size_t len)
-{
-	const struct counter_count_enum_ext *const e = priv;
-	ssize_t index;
-	int err;
-
-	if (!e->set)
-		return -EINVAL;
-
-	index = __sysfs_match_string(e->items, e->num_items, buf);
-	if (index < 0)
-		return index;
-
-	err = e->set(counter, count, index);
-	if (err)
-		return err;
-
-	return len;
-}
-EXPORT_SYMBOL_GPL(counter_count_enum_write);
-
-ssize_t counter_count_enum_available_read(struct counter_device *counter,
-					  struct counter_count *count,
-					  void *priv, char *buf)
-{
-	const struct counter_count_enum_ext *const e = priv;
-	size_t i;
-	size_t len = 0;
-
-	if (!e->num_items)
-		return 0;
-
-	for (i = 0; i < e->num_items; i++)
-		len += sprintf(buf + len, "%s\n", e->items[i]);
-
-	return len;
-}
-EXPORT_SYMBOL_GPL(counter_count_enum_available_read);
-
-ssize_t counter_device_enum_read(struct counter_device *counter, void *priv,
-				 char *buf)
-{
-	const struct counter_device_enum_ext *const e = priv;
-	int err;
-	size_t index;
-
-	if (!e->get)
-		return -EINVAL;
-
-	err = e->get(counter, &index);
-	if (err)
-		return err;
-
-	if (index >= e->num_items)
-		return -EINVAL;
-
-	return sprintf(buf, "%s\n", e->items[index]);
-}
-EXPORT_SYMBOL_GPL(counter_device_enum_read);
-
-ssize_t counter_device_enum_write(struct counter_device *counter, void *priv,
-				  const char *buf, size_t len)
-{
-	const struct counter_device_enum_ext *const e = priv;
-	ssize_t index;
-	int err;
-
-	if (!e->set)
-		return -EINVAL;
-
-	index = __sysfs_match_string(e->items, e->num_items, buf);
-	if (index < 0)
-		return index;
-
-	err = e->set(counter, index);
-	if (err)
-		return err;
-
-	return len;
-}
-EXPORT_SYMBOL_GPL(counter_device_enum_write);
-
-ssize_t counter_device_enum_available_read(struct counter_device *counter,
-					   void *priv, char *buf)
-{
-	const struct counter_device_enum_ext *const e = priv;
-	size_t i;
-	size_t len = 0;
-
-	if (!e->num_items)
-		return 0;
-
-	for (i = 0; i < e->num_items; i++)
-		len += sprintf(buf + len, "%s\n", e->items[i]);
-
-	return len;
-}
-EXPORT_SYMBOL_GPL(counter_device_enum_available_read);
-
-struct counter_attr_parm {
-	struct counter_device_attr_group *group;
-	const char *prefix;
-	const char *name;
-	ssize_t (*show)(struct device *dev, struct device_attribute *attr,
-			char *buf);
-	ssize_t (*store)(struct device *dev, struct device_attribute *attr,
-			 const char *buf, size_t len);
-	void *component;
-};
-
-struct counter_device_attr {
-	struct device_attribute dev_attr;
-	struct list_head l;
-	void *component;
-};
-
-static int counter_attribute_create(const struct counter_attr_parm *const parm)
-{
-	struct counter_device_attr *counter_attr;
-	struct device_attribute *dev_attr;
-	int err;
-	struct list_head *const attr_list = &parm->group->attr_list;
-
-	/* Allocate a Counter device attribute */
-	counter_attr = kzalloc(sizeof(*counter_attr), GFP_KERNEL);
-	if (!counter_attr)
-		return -ENOMEM;
-	dev_attr = &counter_attr->dev_attr;
-
-	sysfs_attr_init(&dev_attr->attr);
-
-	/* Configure device attribute */
-	dev_attr->attr.name = kasprintf(GFP_KERNEL, "%s%s", parm->prefix,
-					parm->name);
-	if (!dev_attr->attr.name) {
-		err = -ENOMEM;
-		goto err_free_counter_attr;
-	}
-	if (parm->show) {
-		dev_attr->attr.mode |= 0444;
-		dev_attr->show = parm->show;
-	}
-	if (parm->store) {
-		dev_attr->attr.mode |= 0200;
-		dev_attr->store = parm->store;
-	}
-
-	/* Store associated Counter component with attribute */
-	counter_attr->component = parm->component;
-
-	/* Keep track of the attribute for later cleanup */
-	list_add(&counter_attr->l, attr_list);
-	parm->group->num_attr++;
-
-	return 0;
-
-err_free_counter_attr:
-	kfree(counter_attr);
-	return err;
-}
-
-#define to_counter_attr(_dev_attr) \
-	container_of(_dev_attr, struct counter_device_attr, dev_attr)
-
-struct counter_signal_unit {
-	struct counter_signal *signal;
-};
-
-static const char *const counter_signal_value_str[] = {
-	[COUNTER_SIGNAL_LOW] = "low",
-	[COUNTER_SIGNAL_HIGH] = "high"
-};
-
-static ssize_t counter_signal_show(struct device *dev,
-				   struct device_attribute *attr, char *buf)
-{
-	struct counter_device *const counter = dev_get_drvdata(dev);
-	const struct counter_device_attr *const devattr = to_counter_attr(attr);
-	const struct counter_signal_unit *const component = devattr->component;
-	struct counter_signal *const signal = component->signal;
-	int err;
-	enum counter_signal_value val;
-
-	err = counter->ops->signal_read(counter, signal, &val);
-	if (err)
-		return err;
-
-	return sprintf(buf, "%s\n", counter_signal_value_str[val]);
-}
-
-struct counter_name_unit {
-	const char *name;
-};
-
-static ssize_t counter_device_attr_name_show(struct device *dev,
-					     struct device_attribute *attr,
-					     char *buf)
-{
-	const struct counter_name_unit *const comp = to_counter_attr(attr)->component;
-
-	return sprintf(buf, "%s\n", comp->name);
-}
-
-static int counter_name_attribute_create(
-	struct counter_device_attr_group *const group,
-	const char *const name)
-{
-	struct counter_name_unit *name_comp;
-	struct counter_attr_parm parm;
-	int err;
-
-	/* Skip if no name */
-	if (!name)
-		return 0;
-
-	/* Allocate name attribute component */
-	name_comp = kmalloc(sizeof(*name_comp), GFP_KERNEL);
-	if (!name_comp)
-		return -ENOMEM;
-	name_comp->name = name;
-
-	/* Allocate Signal name attribute */
-	parm.group = group;
-	parm.prefix = "";
-	parm.name = "name";
-	parm.show = counter_device_attr_name_show;
-	parm.store = NULL;
-	parm.component = name_comp;
-	err = counter_attribute_create(&parm);
-	if (err)
-		goto err_free_name_comp;
-
-	return 0;
-
-err_free_name_comp:
-	kfree(name_comp);
-	return err;
-}
-
-struct counter_signal_ext_unit {
-	struct counter_signal *signal;
-	const struct counter_signal_ext *ext;
-};
-
-static ssize_t counter_signal_ext_show(struct device *dev,
-				       struct device_attribute *attr, char *buf)
-{
-	const struct counter_device_attr *const devattr = to_counter_attr(attr);
-	const struct counter_signal_ext_unit *const comp = devattr->component;
-	const struct counter_signal_ext *const ext = comp->ext;
-
-	return ext->read(dev_get_drvdata(dev), comp->signal, ext->priv, buf);
-}
-
-static ssize_t counter_signal_ext_store(struct device *dev,
-					struct device_attribute *attr,
-					const char *buf, size_t len)
-{
-	const struct counter_device_attr *const devattr = to_counter_attr(attr);
-	const struct counter_signal_ext_unit *const comp = devattr->component;
-	const struct counter_signal_ext *const ext = comp->ext;
-
-	return ext->write(dev_get_drvdata(dev), comp->signal, ext->priv, buf,
-		len);
-}
-
-static void counter_device_attr_list_free(struct list_head *attr_list)
-{
-	struct counter_device_attr *p, *n;
-
-	list_for_each_entry_safe(p, n, attr_list, l) {
-		/* free attribute name and associated component memory */
-		kfree(p->dev_attr.attr.name);
-		kfree(p->component);
-		list_del(&p->l);
-		kfree(p);
-	}
-}
-
-static int counter_signal_ext_register(
-	struct counter_device_attr_group *const group,
-	struct counter_signal *const signal)
-{
-	const size_t num_ext = signal->num_ext;
-	size_t i;
-	const struct counter_signal_ext *ext;
-	struct counter_signal_ext_unit *signal_ext_comp;
-	struct counter_attr_parm parm;
-	int err;
-
-	/* Create an attribute for each extension */
-	for (i = 0 ; i < num_ext; i++) {
-		ext = signal->ext + i;
-
-		/* Allocate signal_ext attribute component */
-		signal_ext_comp = kmalloc(sizeof(*signal_ext_comp), GFP_KERNEL);
-		if (!signal_ext_comp) {
-			err = -ENOMEM;
-			goto err_free_attr_list;
-		}
-		signal_ext_comp->signal = signal;
-		signal_ext_comp->ext = ext;
-
-		/* Allocate a Counter device attribute */
-		parm.group = group;
-		parm.prefix = "";
-		parm.name = ext->name;
-		parm.show = (ext->read) ? counter_signal_ext_show : NULL;
-		parm.store = (ext->write) ? counter_signal_ext_store : NULL;
-		parm.component = signal_ext_comp;
-		err = counter_attribute_create(&parm);
-		if (err) {
-			kfree(signal_ext_comp);
-			goto err_free_attr_list;
-		}
-	}
-
-	return 0;
-
-err_free_attr_list:
-	counter_device_attr_list_free(&group->attr_list);
-	return err;
-}
-
-static int counter_signal_attributes_create(
-	struct counter_device_attr_group *const group,
-	const struct counter_device *const counter,
-	struct counter_signal *const signal)
-{
-	struct counter_signal_unit *signal_comp;
-	struct counter_attr_parm parm;
-	int err;
-
-	/* Allocate Signal attribute component */
-	signal_comp = kmalloc(sizeof(*signal_comp), GFP_KERNEL);
-	if (!signal_comp)
-		return -ENOMEM;
-	signal_comp->signal = signal;
-
-	/* Create main Signal attribute */
-	parm.group = group;
-	parm.prefix = "";
-	parm.name = "signal";
-	parm.show = (counter->ops->signal_read) ? counter_signal_show : NULL;
-	parm.store = NULL;
-	parm.component = signal_comp;
-	err = counter_attribute_create(&parm);
-	if (err) {
-		kfree(signal_comp);
-		return err;
-	}
-
-	/* Create Signal name attribute */
-	err = counter_name_attribute_create(group, signal->name);
-	if (err)
-		goto err_free_attr_list;
-
-	/* Register Signal extension attributes */
-	err = counter_signal_ext_register(group, signal);
-	if (err)
-		goto err_free_attr_list;
-
-	return 0;
-
-err_free_attr_list:
-	counter_device_attr_list_free(&group->attr_list);
-	return err;
-}
-
-static int counter_signals_register(
-	struct counter_device_attr_group *const groups_list,
-	const struct counter_device *const counter)
-{
-	const size_t num_signals = counter->num_signals;
-	size_t i;
-	struct counter_signal *signal;
-	const char *name;
-	int err;
-
-	/* Register each Signal */
-	for (i = 0; i < num_signals; i++) {
-		signal = counter->signals + i;
-
-		/* Generate Signal attribute directory name */
-		name = kasprintf(GFP_KERNEL, "signal%d", signal->id);
-		if (!name) {
-			err = -ENOMEM;
-			goto err_free_attr_groups;
-		}
-		groups_list[i].attr_group.name = name;
-
-		/* Create all attributes associated with Signal */
-		err = counter_signal_attributes_create(groups_list + i, counter,
-						       signal);
-		if (err)
-			goto err_free_attr_groups;
-	}
-
-	return 0;
-
-err_free_attr_groups:
-	do {
-		kfree(groups_list[i].attr_group.name);
-		counter_device_attr_list_free(&groups_list[i].attr_list);
-	} while (i--);
-	return err;
-}
-
-static const char *const counter_synapse_action_str[] = {
-	[COUNTER_SYNAPSE_ACTION_NONE] = "none",
-	[COUNTER_SYNAPSE_ACTION_RISING_EDGE] = "rising edge",
-	[COUNTER_SYNAPSE_ACTION_FALLING_EDGE] = "falling edge",
-	[COUNTER_SYNAPSE_ACTION_BOTH_EDGES] = "both edges"
-};
-
-struct counter_action_unit {
-	struct counter_synapse *synapse;
-	struct counter_count *count;
-};
-
-static ssize_t counter_action_show(struct device *dev,
-				   struct device_attribute *attr, char *buf)
-{
-	const struct counter_device_attr *const devattr = to_counter_attr(attr);
-	int err;
-	struct counter_device *const counter = dev_get_drvdata(dev);
-	const struct counter_action_unit *const component = devattr->component;
-	struct counter_count *const count = component->count;
-	struct counter_synapse *const synapse = component->synapse;
-	size_t action_index;
-	enum counter_synapse_action action;
-
-	err = counter->ops->action_get(counter, count, synapse, &action_index);
-	if (err)
-		return err;
-
-	synapse->action = action_index;
-
-	action = synapse->actions_list[action_index];
-	return sprintf(buf, "%s\n", counter_synapse_action_str[action]);
-}
-
-static ssize_t counter_action_store(struct device *dev,
-				    struct device_attribute *attr,
-				    const char *buf, size_t len)
-{
-	const struct counter_device_attr *const devattr = to_counter_attr(attr);
-	const struct counter_action_unit *const component = devattr->component;
-	struct counter_synapse *const synapse = component->synapse;
-	size_t action_index;
-	const size_t num_actions = synapse->num_actions;
-	enum counter_synapse_action action;
-	int err;
-	struct counter_device *const counter = dev_get_drvdata(dev);
-	struct counter_count *const count = component->count;
-
-	/* Find requested action mode */
-	for (action_index = 0; action_index < num_actions; action_index++) {
-		action = synapse->actions_list[action_index];
-		if (sysfs_streq(buf, counter_synapse_action_str[action]))
-			break;
-	}
-	/* If requested action mode not found */
-	if (action_index >= num_actions)
-		return -EINVAL;
-
-	err = counter->ops->action_set(counter, count, synapse, action_index);
-	if (err)
-		return err;
-
-	synapse->action = action_index;
-
-	return len;
-}
-
-struct counter_action_avail_unit {
-	const enum counter_synapse_action *actions_list;
-	size_t num_actions;
-};
-
-static ssize_t counter_synapse_action_available_show(struct device *dev,
-	struct device_attribute *attr, char *buf)
-{
-	const struct counter_device_attr *const devattr = to_counter_attr(attr);
-	const struct counter_action_avail_unit *const component = devattr->component;
-	size_t i;
-	enum counter_synapse_action action;
-	ssize_t len = 0;
-
-	for (i = 0; i < component->num_actions; i++) {
-		action = component->actions_list[i];
-		len += sprintf(buf + len, "%s\n",
-			       counter_synapse_action_str[action]);
-	}
-
-	return len;
-}
-
-static int counter_synapses_register(
-	struct counter_device_attr_group *const group,
-	const struct counter_device *const counter,
-	struct counter_count *const count, const char *const count_attr_name)
-{
-	size_t i;
-	struct counter_synapse *synapse;
-	const char *prefix;
-	struct counter_action_unit *action_comp;
-	struct counter_attr_parm parm;
-	int err;
-	struct counter_action_avail_unit *avail_comp;
-
-	/* Register each Synapse */
-	for (i = 0; i < count->num_synapses; i++) {
-		synapse = count->synapses + i;
-
-		/* Generate attribute prefix */
-		prefix = kasprintf(GFP_KERNEL, "signal%d_",
-				   synapse->signal->id);
-		if (!prefix) {
-			err = -ENOMEM;
-			goto err_free_attr_list;
-		}
-
-		/* Allocate action attribute component */
-		action_comp = kmalloc(sizeof(*action_comp), GFP_KERNEL);
-		if (!action_comp) {
-			err = -ENOMEM;
-			goto err_free_prefix;
-		}
-		action_comp->synapse = synapse;
-		action_comp->count = count;
-
-		/* Create action attribute */
-		parm.group = group;
-		parm.prefix = prefix;
-		parm.name = "action";
-		parm.show = (counter->ops->action_get) ? counter_action_show : NULL;
-		parm.store = (counter->ops->action_set) ? counter_action_store : NULL;
-		parm.component = action_comp;
-		err = counter_attribute_create(&parm);
-		if (err) {
-			kfree(action_comp);
-			goto err_free_prefix;
-		}
-
-		/* Allocate action available attribute component */
-		avail_comp = kmalloc(sizeof(*avail_comp), GFP_KERNEL);
-		if (!avail_comp) {
-			err = -ENOMEM;
-			goto err_free_prefix;
-		}
-		avail_comp->actions_list = synapse->actions_list;
-		avail_comp->num_actions = synapse->num_actions;
-
-		/* Create action_available attribute */
-		parm.group = group;
-		parm.prefix = prefix;
-		parm.name = "action_available";
-		parm.show = counter_synapse_action_available_show;
-		parm.store = NULL;
-		parm.component = avail_comp;
-		err = counter_attribute_create(&parm);
-		if (err) {
-			kfree(avail_comp);
-			goto err_free_prefix;
-		}
-
-		kfree(prefix);
-	}
-
-	return 0;
-
-err_free_prefix:
-	kfree(prefix);
-err_free_attr_list:
-	counter_device_attr_list_free(&group->attr_list);
-	return err;
-}
-
-struct counter_count_unit {
-	struct counter_count *count;
-};
-
-static ssize_t counter_count_show(struct device *dev,
-				  struct device_attribute *attr,
-				  char *buf)
-{
-	struct counter_device *const counter = dev_get_drvdata(dev);
-	const struct counter_device_attr *const devattr = to_counter_attr(attr);
-	const struct counter_count_unit *const component = devattr->component;
-	struct counter_count *const count = component->count;
-	int err;
-	unsigned long val;
-
-	err = counter->ops->count_read(counter, count, &val);
-	if (err)
-		return err;
-
-	return sprintf(buf, "%lu\n", val);
-}
-
-static ssize_t counter_count_store(struct device *dev,
-				   struct device_attribute *attr,
-				   const char *buf, size_t len)
-{
-	struct counter_device *const counter = dev_get_drvdata(dev);
-	const struct counter_device_attr *const devattr = to_counter_attr(attr);
-	const struct counter_count_unit *const component = devattr->component;
-	struct counter_count *const count = component->count;
-	int err;
-	unsigned long val;
-
-	err = kstrtoul(buf, 0, &val);
-	if (err)
-		return err;
-
-	err = counter->ops->count_write(counter, count, val);
-	if (err)
-		return err;
-
-	return len;
-}
-
-static const char *const counter_count_function_str[] = {
-	[COUNTER_COUNT_FUNCTION_INCREASE] = "increase",
-	[COUNTER_COUNT_FUNCTION_DECREASE] = "decrease",
-	[COUNTER_COUNT_FUNCTION_PULSE_DIRECTION] = "pulse-direction",
-	[COUNTER_COUNT_FUNCTION_QUADRATURE_X1_A] = "quadrature x1 a",
-	[COUNTER_COUNT_FUNCTION_QUADRATURE_X1_B] = "quadrature x1 b",
-	[COUNTER_COUNT_FUNCTION_QUADRATURE_X2_A] = "quadrature x2 a",
-	[COUNTER_COUNT_FUNCTION_QUADRATURE_X2_B] = "quadrature x2 b",
-	[COUNTER_COUNT_FUNCTION_QUADRATURE_X4] = "quadrature x4"
-};
-
-static ssize_t counter_function_show(struct device *dev,
-				     struct device_attribute *attr, char *buf)
-{
-	int err;
-	struct counter_device *const counter = dev_get_drvdata(dev);
-	const struct counter_device_attr *const devattr = to_counter_attr(attr);
-	const struct counter_count_unit *const component = devattr->component;
-	struct counter_count *const count = component->count;
-	size_t func_index;
-	enum counter_count_function function;
-
-	err = counter->ops->function_get(counter, count, &func_index);
-	if (err)
-		return err;
-
-	count->function = func_index;
-
-	function = count->functions_list[func_index];
-	return sprintf(buf, "%s\n", counter_count_function_str[function]);
-}
-
-static ssize_t counter_function_store(struct device *dev,
-				      struct device_attribute *attr,
-				      const char *buf, size_t len)
-{
-	const struct counter_device_attr *const devattr = to_counter_attr(attr);
-	const struct counter_count_unit *const component = devattr->component;
-	struct counter_count *const count = component->count;
-	const size_t num_functions = count->num_functions;
-	size_t func_index;
-	enum counter_count_function function;
-	int err;
-	struct counter_device *const counter = dev_get_drvdata(dev);
-
-	/* Find requested Count function mode */
-	for (func_index = 0; func_index < num_functions; func_index++) {
-		function = count->functions_list[func_index];
-		if (sysfs_streq(buf, counter_count_function_str[function]))
-			break;
-	}
-	/* Return error if requested Count function mode not found */
-	if (func_index >= num_functions)
-		return -EINVAL;
-
-	err = counter->ops->function_set(counter, count, func_index);
-	if (err)
-		return err;
-
-	count->function = func_index;
-
-	return len;
-}
-
-struct counter_count_ext_unit {
-	struct counter_count *count;
-	const struct counter_count_ext *ext;
-};
-
-static ssize_t counter_count_ext_show(struct device *dev,
-				      struct device_attribute *attr, char *buf)
-{
-	const struct counter_device_attr *const devattr = to_counter_attr(attr);
-	const struct counter_count_ext_unit *const comp = devattr->component;
-	const struct counter_count_ext *const ext = comp->ext;
-
-	return ext->read(dev_get_drvdata(dev), comp->count, ext->priv, buf);
-}
-
-static ssize_t counter_count_ext_store(struct device *dev,
-				       struct device_attribute *attr,
-				       const char *buf, size_t len)
-{
-	const struct counter_device_attr *const devattr = to_counter_attr(attr);
-	const struct counter_count_ext_unit *const comp = devattr->component;
-	const struct counter_count_ext *const ext = comp->ext;
-
-	return ext->write(dev_get_drvdata(dev), comp->count, ext->priv, buf,
-		len);
-}
-
-static int counter_count_ext_register(
-	struct counter_device_attr_group *const group,
-	struct counter_count *const count)
-{
-	size_t i;
-	const struct counter_count_ext *ext;
-	struct counter_count_ext_unit *count_ext_comp;
-	struct counter_attr_parm parm;
-	int err;
-
-	/* Create an attribute for each extension */
-	for (i = 0 ; i < count->num_ext; i++) {
-		ext = count->ext + i;
-
-		/* Allocate count_ext attribute component */
-		count_ext_comp = kmalloc(sizeof(*count_ext_comp), GFP_KERNEL);
-		if (!count_ext_comp) {
-			err = -ENOMEM;
-			goto err_free_attr_list;
-		}
-		count_ext_comp->count = count;
-		count_ext_comp->ext = ext;
-
-		/* Allocate count_ext attribute */
-		parm.group = group;
-		parm.prefix = "";
-		parm.name = ext->name;
-		parm.show = (ext->read) ? counter_count_ext_show : NULL;
-		parm.store = (ext->write) ? counter_count_ext_store : NULL;
-		parm.component = count_ext_comp;
-		err = counter_attribute_create(&parm);
-		if (err) {
-			kfree(count_ext_comp);
-			goto err_free_attr_list;
-		}
-	}
-
-	return 0;
-
-err_free_attr_list:
-	counter_device_attr_list_free(&group->attr_list);
-	return err;
-}
-
-struct counter_func_avail_unit {
-	const enum counter_count_function *functions_list;
-	size_t num_functions;
-};
-
-static ssize_t counter_count_function_available_show(struct device *dev,
-	struct device_attribute *attr, char *buf)
-{
-	const struct counter_device_attr *const devattr = to_counter_attr(attr);
-	const struct counter_func_avail_unit *const component = devattr->component;
-	const enum counter_count_function *const func_list = component->functions_list;
-	const size_t num_functions = component->num_functions;
-	size_t i;
-	enum counter_count_function function;
-	ssize_t len = 0;
-
-	for (i = 0; i < num_functions; i++) {
-		function = func_list[i];
-		len += sprintf(buf + len, "%s\n",
-			       counter_count_function_str[function]);
-	}
-
-	return len;
-}
-
-static int counter_count_attributes_create(
-	struct counter_device_attr_group *const group,
-	const struct counter_device *const counter,
-	struct counter_count *const count)
-{
-	struct counter_count_unit *count_comp;
-	struct counter_attr_parm parm;
-	int err;
-	struct counter_count_unit *func_comp;
-	struct counter_func_avail_unit *avail_comp;
-
-	/* Allocate count attribute component */
-	count_comp = kmalloc(sizeof(*count_comp), GFP_KERNEL);
-	if (!count_comp)
-		return -ENOMEM;
-	count_comp->count = count;
-
-	/* Create main Count attribute */
-	parm.group = group;
-	parm.prefix = "";
-	parm.name = "count";
-	parm.show = (counter->ops->count_read) ? counter_count_show : NULL;
-	parm.store = (counter->ops->count_write) ? counter_count_store : NULL;
-	parm.component = count_comp;
-	err = counter_attribute_create(&parm);
-	if (err) {
-		kfree(count_comp);
-		return err;
-	}
-
-	/* Allocate function attribute component */
-	func_comp = kmalloc(sizeof(*func_comp), GFP_KERNEL);
-	if (!func_comp) {
-		err = -ENOMEM;
-		goto err_free_attr_list;
-	}
-	func_comp->count = count;
-
-	/* Create Count function attribute */
-	parm.group = group;
-	parm.prefix = "";
-	parm.name = "function";
-	parm.show = (counter->ops->function_get) ? counter_function_show : NULL;
-	parm.store = (counter->ops->function_set) ? counter_function_store : NULL;
-	parm.component = func_comp;
-	err = counter_attribute_create(&parm);
-	if (err) {
-		kfree(func_comp);
-		goto err_free_attr_list;
-	}
-
-	/* Allocate function available attribute component */
-	avail_comp = kmalloc(sizeof(*avail_comp), GFP_KERNEL);
-	if (!avail_comp) {
-		err = -ENOMEM;
-		goto err_free_attr_list;
-	}
-	avail_comp->functions_list = count->functions_list;
-	avail_comp->num_functions = count->num_functions;
-
-	/* Create Count function_available attribute */
-	parm.group = group;
-	parm.prefix = "";
-	parm.name = "function_available";
-	parm.show = counter_count_function_available_show;
-	parm.store = NULL;
-	parm.component = avail_comp;
-	err = counter_attribute_create(&parm);
-	if (err) {
-		kfree(avail_comp);
-		goto err_free_attr_list;
-	}
-
-	/* Create Count name attribute */
-	err = counter_name_attribute_create(group, count->name);
-	if (err)
-		goto err_free_attr_list;
-
-	/* Register Count extension attributes */
-	err = counter_count_ext_register(group, count);
-	if (err)
-		goto err_free_attr_list;
-
-	return 0;
-
-err_free_attr_list:
-	counter_device_attr_list_free(&group->attr_list);
-	return err;
-}
-
-static int counter_counts_register(
-	struct counter_device_attr_group *const groups_list,
-	const struct counter_device *const counter)
-{
-	size_t i;
-	struct counter_count *count;
-	const char *name;
-	int err;
-
-	/* Register each Count */
-	for (i = 0; i < counter->num_counts; i++) {
-		count = counter->counts + i;
-
-		/* Generate Count attribute directory name */
-		name = kasprintf(GFP_KERNEL, "count%d", count->id);
[… more lines in the raw message]

Lines of this file are not shown. View the raw message.

drivers/counter/ftm-quaddec.c +51 -38
index c2b3fdfd8b77..ea6cb18c7170 100644

Lines of this file are not shown. View the raw message.

drivers/counter/stm32-lptimer-cnt.c +84 -77
index 8e276eb655f5..4a1ec895717c 100644

Lines of this file are not shown. View the raw message.

drivers/counter/stm32-timer-cnt.c +53 -86
index ef2a974a2f10..502e525836a9 100644

Lines of this file are not shown. View the raw message.

drivers/counter/ti-eqep.c +107 -104
index 1ff07faef27f..7152f0b3c2de 100644

Lines of this file are not shown. View the raw message.

include/linux/counter.h +255 -355
index 9dbd5df4cd34..e8abbaf47a4b 100644

Lines of this file are not shown. View the raw message.

include/linux/counter_enum.h deleted +0 -45
deleted file mode 100644
index 9f917298a88f..000000000000

Lines of this file are not shown. View the raw message.

include/uapi/linux/counter-types.h new file +45 -0
new file mode 100644
index 000000000000..d19616df0e1c

Lines of this file are not shown. View the raw message.

The rest of this diff is not shown. View the raw message.

Part of the diff is not shown here. View the raw message.

#4 lore raw

PATCH v2 2/4 docs: counter: Update to reflect sysfs internalization

In reply to William Breathitt Gray

The Counter subsystem architecture and driver implementations have changed in order to handle Counter sysfs interactions in a more consistent way. This patch updates the Generic Counter interface documentation to reflect the changes.

---
 Documentation/driver-api/generic-counter.rst | 215 +++++++++++++------
 1 file changed, 149 insertions(+), 66 deletions(-)
Documentation/driver-api/generic-counter.rst +149 -66
index e622f8f6e56a..8f85c30dea0b 100644
@@ -250,8 +250,8 @@ for defining a counter device.
 .. kernel-doc:: drivers/counter/counter.c
    :export:
 
-Implementation
-==============
+Driver Implementation
+=====================
 
 To support a counter device, a driver must first allocate the available
 Counter Signals via counter_signal structures. These Signals should
@@ -267,25 +267,58 @@ respective counter_count structure. These counter_count structures are
 set to the counts array member of an allocated counter_device structure
 before the Counter is registered to the system.
 
-Driver callbacks should be provided to the counter_device structure via
-a constant counter_ops structure in order to communicate with the
-device: to read and write various Signals and Counts, and to set and get
-the "action mode" and "function mode" for various Synapses and Counts
-respectively.
+Driver callbacks must be provided to the counter_device structure in
+order to communicate with the device: to read and write various Signals
+and Counts, and to set and get the "action mode" and "function mode" for
+various Synapses and Counts respectively.
 
 A defined counter_device structure may be registered to the system by
 passing it to the counter_register function, and unregistered by passing
 it to the counter_unregister function. Similarly, the
-devm_counter_register and devm_counter_unregister functions may be used
-if device memory-managed registration is desired.
-
-Extension sysfs attributes can be created for auxiliary functionality
-and data by passing in defined counter_device_ext, counter_count_ext,
-and counter_signal_ext structures. In these cases, the
-counter_device_ext structure is used for global/miscellaneous exposure
-and configuration of the respective Counter device, while the
-counter_count_ext and counter_signal_ext structures allow for auxiliary
-exposure and configuration of a specific Count or Signal respectively.
+devm_counter_register function may be used if device memory-managed
+registration is desired.
+
+The struct counter_data structure is used to define counter extensions
+for Signals, Synapses, and Counts.
+
+The "type" member specifies the type of data (e.g. unsigned long,
+boolean, etc.) handled by this extension. The "read" and "write" members
+can then be set by the counter device driver with callbacks to handle
+that data.
+
+Convenience macros such as `COUNTER_DATA_COUNT_U64` are provided for use
+by driver authors. In particular, driver authors are expected to use
+the provided macros for standard Counter subsystem attributes in order
+to maintain a consistent interface for userspace. For example, a counter
+device driver may define several standard attributes like so::
+
+	struct counter_data count_ext[] = {
+		COUNTER_DATA_DIRECTION(count_direction_read),
+		COUNTER_DATA_ENABLE(count_enable_read, count_enable_write),
+		COUNTER_DATA_CEILING(count_ceiling_read, count_ceiling_write),
+	};
+
+This makes it intuitive to see, add, and modify the attributes that are
+supported by this driver ("direction", "enable", and "ceiling") and to
+maintain this code without getting lost in a web of struct braces.
+
+Callbacks must match the function type expected for the respective
+component or extension. These function types are defined in the struct
+counter_data structure as the "`*_read`" and "`*_write`" union members.
+
+The corresponding callback prototypes for the extensions mentioned in
+the previous example above would be::
+
+	int count_direction_read(struct counter_device *counter,
+				 struct counter_count *count, u8 *direction);
+	int count_enable_read(struct counter_device *counter,
+			      struct counter_count *count, u8 *enable);
+	int count_enable_write(struct counter_device *counter,
+			       struct counter_count *count, u8 enable);
+	int count_ceiling_read(struct counter_device *counter,
+			       struct counter_count *count, u64 *ceiling);
+	int count_ceiling_write(struct counter_device *counter,
+				struct counter_count *count, u64 ceiling);
 
 Determining the type of extension to create is a matter of scope.
 
@@ -313,52 +346,102 @@ Determining the type of extension to create is a matter of scope.
   chip overheated via a device extension called "error_overtemp":
   /sys/bus/counter/devices/counterX/error_overtemp
 
-Architecture
-============
-
-When the Generic Counter interface counter module is loaded, the
-counter_init function is called which registers a bus_type named
-"counter" to the system. Subsequently, when the module is unloaded, the
-counter_exit function is called which unregisters the bus_type named
-"counter" from the system.
-
-Counter devices are registered to the system via the counter_register
-function, and later removed via the counter_unregister function. The
-counter_register function establishes a unique ID for the Counter
-device and creates a respective sysfs directory, where X is the
-mentioned unique ID:
-
-    /sys/bus/counter/devices/counterX
-
-Sysfs attributes are created within the counterX directory to expose
-functionality, configurations, and data relating to the Counts, Signals,
-and Synapses of the Counter device, as well as options and information
-for the Counter device itself.
-
-Each Signal has a directory created to house its relevant sysfs
-attributes, where Y is the unique ID of the respective Signal:
-
-    /sys/bus/counter/devices/counterX/signalY
-
-Similarly, each Count has a directory created to house its relevant
-sysfs attributes, where Y is the unique ID of the respective Count:
-
-    /sys/bus/counter/devices/counterX/countY
-
-For a more detailed breakdown of the available Generic Counter interface
-sysfs attributes, please refer to the
-Documentation/ABI/testing/sysfs-bus-counter file.
-
-The Signals and Counts associated with the Counter device are registered
-to the system as well by the counter_register function. The
-signal_read/signal_write driver callbacks are associated with their
-respective Signal attributes, while the count_read/count_write and
-function_get/function_set driver callbacks are associated with their
-respective Count attributes; similarly, the same is true for the
-action_get/action_set driver callbacks and their respective Synapse
-attributes. If a driver callback is left undefined, then the respective
-read/write permission is left disabled for the relevant attributes.
-
-Similarly, extension sysfs attributes are created for the defined
-counter_device_ext, counter_count_ext, and counter_signal_ext
-structures that are passed in.
+Subsystem Architecture
+======================
+
+Counter drivers pass and take data natively (i.e. `u8`, `u64`, `char *`,
+etc.) and the shared counter module handles the translation between the
+sysfs interface. This gurantees a standard userspace interface for all
+counter drivers, and helps generalize the Generic Counter driver ABI in
+order to support the Generic Counter chrdev interface without
+significant changes to the existing counter drivers.
+
+A high-level view of how a count value is passed down from a counter
+driver can be exemplified by the following::
+
+       Count data request:
+       ~~~~~~~~~~~~~~~~~~~
+                 ----------------------
+                / Counter device       \
+                +----------------------+
+                | Count register: 0x28 |
+                +----------------------+
+                        |
+                 -----------------
+                / raw count data /
+                -----------------
+                        |
+                        V
+                +----------------------------+
+                | Counter device driver      |----------+
+                +----------------------------+          |
+                | Processes data from device |   -------------------
+                |----------------------------|  / driver callbacks /
+                | Type: unsigned long        |  -------------------
+                | Value: 42                  |          |
+                +----------------------------+          |
+                        |                               |
+                 ----------------                       |
+                / unsigned long /                       |
+                ----------------                        |
+                        |                               |
+                        |                               V
+                        |               +----------------------+
+                        |               | Counter core         |
+                        |               +----------------------+
+                        |               | Routes device driver |
+                        |               | callbacks to the     |
+                        |               | userspace interfaces |
+                        |               +----------------------+
+                        |                       |
+                        |                -------------------
+                        |               / driver callbacks /
+                        |               -------------------
+                        |                       |
+                +-------+                       |
+                |                               |
+                |               +---------------+
+                |               |
+                V               |
+        +--------------------+  |
+        | Counter sysfs      |<-+
+        +--------------------+
+        | Translates to the  |
+        | standard Counter   |
+        | sysfs output       |
+        |--------------------|
+        | Type: const char * |
+        | Value: "42"        |
+        +--------------------+
+                |
+         ---------------
+        / const char * /
+        ---------------
+                |
+                V
+        +--------------------------------------------------+
+        | `/sys/bus/counter/devices/counterX/countY/count` |
+        +--------------------------------------------------+
+        \ Count: "42"                                      /
+         --------------------------------------------------
+
+There are three primary components involved:
+
+Counter device driver
+---------------------
+Communicates with the hardware device to read/write data; e.g. counter
+drivers for quadrature encoders, timers, etc.
+
+Counter core
+------------
+Registers the counter device driver to the system so that the respective
+callbacks are called during userspace interaction.
+
+Counter sysfs
+-------------
+Translates counter data to the standard Counter sysfs interface format
+and vice versa.
+
+Please refer to the `Documentation/ABI/testing/sysfs-bus-counter` file
+for a detailed breakdown of the available Generic Counter interface
+sysfs attributes.
Signature · 1 line
2.26.2
maintainer
#5 lore raw

Re: [PATCH v2 2/4] docs: counter: Update to reflect sysfs internalization

Quoted 6 lines · On Sat, 16 May 2020 15:20:00 -0400 William Breathitt Gray…

The Counter subsystem architecture and driver implementations have changed in order to handle Counter sysfs interactions in a more consistent way. This patch updates the Generic Counter interface documentation to reflect the changes.

Looks good to me.

Jonathan

Quoted 245 lines
---
 Documentation/driver-api/generic-counter.rst | 215 +++++++++++++------
 1 file changed, 149 insertions(+), 66 deletions(-)
Documentation/driver-api/generic-counter.rst +149 -66
index e622f8f6e56a..8f85c30dea0b 100644
@@ -250,8 +250,8 @@ for defining a counter device.
 .. kernel-doc:: drivers/counter/counter.c
    :export:
 
-Implementation
-==============
+Driver Implementation
+=====================
 
 To support a counter device, a driver must first allocate the available
 Counter Signals via counter_signal structures. These Signals should
@@ -267,25 +267,58 @@ respective counter_count structure. These counter_count structures are
 set to the counts array member of an allocated counter_device structure
 before the Counter is registered to the system.
 
-Driver callbacks should be provided to the counter_device structure via
-a constant counter_ops structure in order to communicate with the
-device: to read and write various Signals and Counts, and to set and get
-the "action mode" and "function mode" for various Synapses and Counts
-respectively.
+Driver callbacks must be provided to the counter_device structure in
+order to communicate with the device: to read and write various Signals
+and Counts, and to set and get the "action mode" and "function mode" for
+various Synapses and Counts respectively.
 
 A defined counter_device structure may be registered to the system by
 passing it to the counter_register function, and unregistered by passing
 it to the counter_unregister function. Similarly, the
-devm_counter_register and devm_counter_unregister functions may be used
-if device memory-managed registration is desired.
-
-Extension sysfs attributes can be created for auxiliary functionality
-and data by passing in defined counter_device_ext, counter_count_ext,
-and counter_signal_ext structures. In these cases, the
-counter_device_ext structure is used for global/miscellaneous exposure
-and configuration of the respective Counter device, while the
-counter_count_ext and counter_signal_ext structures allow for auxiliary
-exposure and configuration of a specific Count or Signal respectively.
+devm_counter_register function may be used if device memory-managed
+registration is desired.
+
+The struct counter_data structure is used to define counter extensions
+for Signals, Synapses, and Counts.
+
+The "type" member specifies the type of data (e.g. unsigned long,
+boolean, etc.) handled by this extension. The "read" and "write" members
+can then be set by the counter device driver with callbacks to handle
+that data.
+
+Convenience macros such as `COUNTER_DATA_COUNT_U64` are provided for use
+by driver authors. In particular, driver authors are expected to use
+the provided macros for standard Counter subsystem attributes in order
+to maintain a consistent interface for userspace. For example, a counter
+device driver may define several standard attributes like so::
+
+	struct counter_data count_ext[] = {
+		COUNTER_DATA_DIRECTION(count_direction_read),
+		COUNTER_DATA_ENABLE(count_enable_read, count_enable_write),
+		COUNTER_DATA_CEILING(count_ceiling_read, count_ceiling_write),
+	};
+
+This makes it intuitive to see, add, and modify the attributes that are
+supported by this driver ("direction", "enable", and "ceiling") and to
+maintain this code without getting lost in a web of struct braces.
+
+Callbacks must match the function type expected for the respective
+component or extension. These function types are defined in the struct
+counter_data structure as the "`*_read`" and "`*_write`" union members.
+
+The corresponding callback prototypes for the extensions mentioned in
+the previous example above would be::
+
+	int count_direction_read(struct counter_device *counter,
+				 struct counter_count *count, u8 *direction);
+	int count_enable_read(struct counter_device *counter,
+			      struct counter_count *count, u8 *enable);
+	int count_enable_write(struct counter_device *counter,
+			       struct counter_count *count, u8 enable);
+	int count_ceiling_read(struct counter_device *counter,
+			       struct counter_count *count, u64 *ceiling);
+	int count_ceiling_write(struct counter_device *counter,
+				struct counter_count *count, u64 ceiling);
 
 Determining the type of extension to create is a matter of scope.
 
@@ -313,52 +346,102 @@ Determining the type of extension to create is a matter of scope.
   chip overheated via a device extension called "error_overtemp":
   /sys/bus/counter/devices/counterX/error_overtemp
 
-Architecture
-============
-
-When the Generic Counter interface counter module is loaded, the
-counter_init function is called which registers a bus_type named
-"counter" to the system. Subsequently, when the module is unloaded, the
-counter_exit function is called which unregisters the bus_type named
-"counter" from the system.
-
-Counter devices are registered to the system via the counter_register
-function, and later removed via the counter_unregister function. The
-counter_register function establishes a unique ID for the Counter
-device and creates a respective sysfs directory, where X is the
-mentioned unique ID:
-
-    /sys/bus/counter/devices/counterX
-
-Sysfs attributes are created within the counterX directory to expose
-functionality, configurations, and data relating to the Counts, Signals,
-and Synapses of the Counter device, as well as options and information
-for the Counter device itself.
-
-Each Signal has a directory created to house its relevant sysfs
-attributes, where Y is the unique ID of the respective Signal:
-
-    /sys/bus/counter/devices/counterX/signalY
-
-Similarly, each Count has a directory created to house its relevant
-sysfs attributes, where Y is the unique ID of the respective Count:
-
-    /sys/bus/counter/devices/counterX/countY
-
-For a more detailed breakdown of the available Generic Counter interface
-sysfs attributes, please refer to the
-Documentation/ABI/testing/sysfs-bus-counter file.
-
-The Signals and Counts associated with the Counter device are registered
-to the system as well by the counter_register function. The
-signal_read/signal_write driver callbacks are associated with their
-respective Signal attributes, while the count_read/count_write and
-function_get/function_set driver callbacks are associated with their
-respective Count attributes; similarly, the same is true for the
-action_get/action_set driver callbacks and their respective Synapse
-attributes. If a driver callback is left undefined, then the respective
-read/write permission is left disabled for the relevant attributes.
-
-Similarly, extension sysfs attributes are created for the defined
-counter_device_ext, counter_count_ext, and counter_signal_ext
-structures that are passed in.
+Subsystem Architecture
+======================
+
+Counter drivers pass and take data natively (i.e. `u8`, `u64`, `char *`,
+etc.) and the shared counter module handles the translation between the
+sysfs interface. This gurantees a standard userspace interface for all
+counter drivers, and helps generalize the Generic Counter driver ABI in
+order to support the Generic Counter chrdev interface without
+significant changes to the existing counter drivers.
+
+A high-level view of how a count value is passed down from a counter
+driver can be exemplified by the following::
+
+       Count data request:
+       ~~~~~~~~~~~~~~~~~~~
+                 ----------------------
+                / Counter device       \
+                +----------------------+
+                | Count register: 0x28 |
+                +----------------------+
+                        |
+                 -----------------
+                / raw count data /
+                -----------------
+                        |
+                        V
+                +----------------------------+
+                | Counter device driver      |----------+
+                +----------------------------+          |
+                | Processes data from device |   -------------------
+                |----------------------------|  / driver callbacks /
+                | Type: unsigned long        |  -------------------
+                | Value: 42                  |          |
+                +----------------------------+          |
+                        |                               |
+                 ----------------                       |
+                / unsigned long /                       |
+                ----------------                        |
+                        |                               |
+                        |                               V
+                        |               +----------------------+
+                        |               | Counter core         |
+                        |               +----------------------+
+                        |               | Routes device driver |
+                        |               | callbacks to the     |
+                        |               | userspace interfaces |
+                        |               +----------------------+
+                        |                       |
+                        |                -------------------
+                        |               / driver callbacks /
+                        |               -------------------
+                        |                       |
+                +-------+                       |
+                |                               |
+                |               +---------------+
+                |               |
+                V               |
+        +--------------------+  |
+        | Counter sysfs      |<-+
+        +--------------------+
+        | Translates to the  |
+        | standard Counter   |
+        | sysfs output       |
+        |--------------------|
+        | Type: const char * |
+        | Value: "42"        |
+        +--------------------+
+                |
+         ---------------
+        / const char * /
+        ---------------
+                |
+                V
+        +--------------------------------------------------+
+        | `/sys/bus/counter/devices/counterX/countY/count` |
+        +--------------------------------------------------+
+        \ Count: "42"                                      /
+         --------------------------------------------------
+
+There are three primary components involved:
+
+Counter device driver
+---------------------
+Communicates with the hardware device to read/write data; e.g. counter
+drivers for quadrature encoders, timers, etc.
+
+Counter core
+------------
+Registers the counter device driver to the system so that the respective
+callbacks are called during userspace interaction.
+
+Counter sysfs
+-------------
+Translates counter data to the standard Counter sysfs interface format
+and vice versa.
+
+Please refer to the `Documentation/ABI/testing/sysfs-bus-counter` file
+for a detailed breakdown of the available Generic Counter interface
+sysfs attributes.
#6 lore raw

PATCH v2 3/4 counter: Add character device interface

In reply to William Breathitt Gray

This patch introduces a character device interface for the Counter subsystem. Device control is exposed through standard character device read and write operations.

The first 196095 bytes of the character device serve as a control selection area where control exposure of desired Counter components and extensions may be selected. Each byte serves as a boolean selection indicator for a respective Counter component or extension. The format of this area is as follows:

* For each device extension, a byte is required.
* For each Signal, a byte is reserved for the Signal component, and a byte is reserved for each Signal extension.
* For each Count, a byte is reserved for the Count component, a byte is reserved for the count function, a byte is reserved for each Synapse action, and byte is reserved for each Count extension.

The selected Counter components and extensions may then be interfaced after the first 196095 bytes via standard character device read/write operations. The number of bytes available for each component or extension is dependent on their respective data type: u8 will have 1 byte available, u64 will have 8 bytes available, strings will have 64 bytes available, etc.

A high-level view of how a count value is passed down from a counter driver can be exemplified by the following:

                 ----------------------
                / Counter device       \
                +----------------------+
                | Count register: 0x28 |
                +----------------------+
                        |
                 -----------------
                / raw count data /
                -----------------
                        |
                        V
                +----------------------------+
                | Counter device driver      |----------+
                +----------------------------+          |
                | Processes data from device |   -------------------
                |----------------------------|  / driver callbacks /
                | Type: u64                  |  -------------------
                | Value: 42                  |          |
                +----------------------------+          |
                        |                               |
                 ----------                             |
                / u64     /                             |
                ----------                              |
                        |                               |
                        |                               V
                        |               +----------------------+
                        |               | Counter core         |
                        |               +----------------------+
                        |               | Routes device driver |
                        |               | callbacks to the     |
                        |               | userspace interfaces |
                        |               +----------------------+
                        |                       |
                        |                -------------------
                        |               / driver callbacks /
                        |               -------------------
                        |                       |
                +-------+---------------+       |
                |                       |       |
                |               +-------|-------+
                |               |       |
                V               |       V
        +--------------------+  |  +---------------------+
        | Counter sysfs      |<-+->| Counter chrdev      |
        +--------------------+     +---------------------+
        | Translates to the  |     | Translates to the   |
        | standard Counter   |     | standard Counter    |
        | sysfs output       |     | character device    |
        |--------------------|     |---------------------+
        | Type: const char * |     | Type: u64           |
        | Value: "42"        |     | Value: 42           |
        +--------------------+     +---------------------+
                |                               |
         ---------------                 ----------
        / const char * /                / u64     /
        ---------------                 ----------
                |                               |
                |                               V
                |                       +-----------+
                |                       | read      |
                |                       +-----------+
                |                       \ Count: 42 /
                |                        -----------
                |
                V
        +--------------------------------------------------+
        | `/sys/bus/counter/devices/counterX/countY/count` |
        +--------------------------------------------------+
        \ Count: "42"                                      /
         --------------------------------------------------
---
 MAINTAINERS                      |   1 +
 drivers/counter/Makefile         |   2 +-
 drivers/counter/counter-chrdev.c | 656 +++++++++++++++++++++++++++++++
 drivers/counter/counter-chrdev.h |  16 +
 drivers/counter/counter-core.c   |  34 +-
 include/linux/counter.h          |  16 +
 6 files changed, 722 insertions(+), 3 deletions(-)
 create mode 100644 drivers/counter/counter-chrdev.c
 create mode 100644 drivers/counter/counter-chrdev.h
MAINTAINERS +1 -0
index ef72b5755793..150ad8a9bb87 100644
@@ -4365,6 +4365,7 @@ F:	Documentation/ABI/testing/sysfs-bus-counter*
 F:	Documentation/driver-api/generic-counter.rst
 F:	drivers/counter/
 F:	include/linux/counter.h
+F:	include/uapi/linux/counter.h
 F:	include/uapi/linux/counter-types.h
 
 CPMAC ETHERNET DRIVER
drivers/counter/Makefile +1 -1
index f48e337cbd85..d219b9c058e7 100644
@@ -4,7 +4,7 @@
 #
 
 obj-$(CONFIG_COUNTER) += counter.o
-counter-y := counter-core.o counter-sysfs.o
+counter-y := counter-core.o counter-sysfs.o counter-chrdev.o
 
 obj-$(CONFIG_104_QUAD_8)	+= 104-quad-8.o
 obj-$(CONFIG_STM32_TIMER_CNT)	+= stm32-timer-cnt.o
drivers/counter/counter-chrdev.c new file +656 -0

656 lines not on this page · raw message

drivers/counter/counter-chrdev.h new file +16 -0
new file mode 100644
index 000000000000..7ab0797d3857
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Counter character device interface
+ * Copyright (C) 2020 William Breathitt Gray
+ */
+#ifndef _COUNTER_CHRDEV_H_
+#define _COUNTER_CHRDEV_H_
+
+#include <linux/counter.h>
+#include <linux/types.h>
+
+int counter_chrdev_add(struct counter_device *const counter,
+		       const dev_t counter_devt);
+void counter_chrdev_free(struct counter_device *const counter);
+
+#endif /* _COUNTER_CHRDEV_H_ */
drivers/counter/counter-core.c +32 -2
index 499664809c75..2d0886648201 100644
@@ -6,11 +6,14 @@
 #include <linux/counter.h>
 #include <linux/device.h>
 #include <linux/export.h>
+#include <linux/fs.h>
 #include <linux/gfp.h>
 #include <linux/idr.h>
 #include <linux/init.h>
 #include <linux/module.h>
+#include <linux/types.h>
 
+#include "counter-chrdev.h"
 #include "counter-sysfs.h"
 
 /* Provides a unique ID for each counter device */
@@ -33,6 +36,8 @@ static struct bus_type counter_bus_type = {
 	.name = "counter"
 };
 
+static dev_t counter_devt;
+
 /**
  * counter_register - register Counter to the system
  * @counter:	pointer to Counter to register
@@ -62,10 +67,15 @@ int counter_register(struct counter_device *const counter)
 	device_initialize(dev);
 	dev_set_drvdata(dev, counter);
 
+	/* Add Counter character device */
+	err = counter_chrdev_add(counter, counter_devt);
+	if (err)
+		goto err_free_id;
+
 	/* Add Counter sysfs attributes */
 	err = counter_sysfs_add(counter);
 	if (err)
-		goto err_free_id;
+		goto err_free_chrdev;
 
 	/* Add device to system */
 	err = device_add(dev);
@@ -76,6 +86,8 @@ int counter_register(struct counter_device *const counter)
 
 err_free_sysfs:
 	counter_sysfs_free(counter);
+err_free_chrdev:
+	counter_chrdev_free(counter);
 err_free_id:
 	ida_simple_remove(&counter_ida, counter->id);
 	return err;
@@ -93,6 +105,7 @@ void counter_unregister(struct counter_device *const counter)
 	if (counter) {
 		device_del(&counter->dev);
 		counter_sysfs_free(counter);
+		counter_chrdev_free(counter);
 	}
 }
 EXPORT_SYMBOL_GPL(counter_unregister);
@@ -139,13 +152,30 @@ int devm_counter_register(struct device *dev,
 }
 EXPORT_SYMBOL_GPL(devm_counter_register);
 
+#define COUNTER_DEV_MAX 256
+
 static int __init counter_init(void)
 {
-	return bus_register(&counter_bus_type);
+	int err;
+
+	err = bus_register(&counter_bus_type);
+	if (err < 0)
+		return err;
+
+	err = alloc_chrdev_region(&counter_devt, 0, COUNTER_DEV_MAX, "counter");
+	if (err < 0)
+		goto err_unregister_bus;
+
+	return 0;
+
+err_unregister_bus:
+	bus_unregister(&counter_bus_type);
+	return err;
 }
 
 static void __exit counter_exit(void)
 {
+	unregister_chrdev_region(counter_devt, COUNTER_DEV_MAX);
 	bus_unregister(&counter_bus_type);
 }
 
include/linux/counter.h +16 -0
index e8abbaf47a4b..22e91d00a880 100644
@@ -6,6 +6,7 @@
 #ifndef _COUNTER_H_
 #define _COUNTER_H_
 
+#include <linux/cdev.h>
 #include <linux/device.h>
 #include <linux/kernel.h>
 #include <linux/list.h>
@@ -170,6 +171,9 @@ struct counter_attribute_group {
  * @priv:		optional private data supplied by driver
  * @id:			unique ID used to identify the Counter
  * @dev:		internal device structure
+ * @chrdev:		internal character device structure
+ * @selection:		Counter character device control selection
+ * @control_list:	Counter character device selected controls
  * @dynamic_names_list:	List for dynamic names
  * @groups_list:	attribute groups list (for Signals, Counts, and ext)
  * @num_groups:		number of attribute groups containers
@@ -208,6 +212,18 @@ struct counter_device {
 
 	int id;
 	struct device dev;
+	struct cdev chrdev;
+
+#define MAX_EXT 255
+#define MAX_SIGNALS 255
+#define MAX_SYNAPSES 255
+#define MAX_COUNTS 255
+#define SIGNALS_SELECTION_SIZE ((1 + MAX_EXT) * MAX_SIGNALS)
+#define COUNTS_SELECTION_SIZE ((1 + 1 + MAX_SYNAPSES + MAX_EXT) * MAX_COUNTS)
+#define COUNTER_SELECTION_SIZE (MAX_EXT + SIGNALS_SELECTION_SIZE + COUNTS_SELECTION_SIZE)
+	u8 selection[COUNTER_SELECTION_SIZE];
+	struct list_head control_list;
+
 	struct list_head dynamic_names_list;
 	struct counter_attribute_group *groups_list;
 	size_t num_groups;
Signature · 1 line
2.26.2
#7 lore raw

Re: [PATCH v2 3/4] counter: Add character device interface

I love your patch! Perhaps something to improve:

Hi William,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v5.7-rc6 next-20200519]
[cannot apply to stm32/stm32-next linux/master]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:    https://github.com/0day-ci/linux/commits/William-Breathitt-Gray/Introduce-the-Counter-character-device-interface/20200517-032530
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 12bf0b632ed090358cbf03e323e5342212d0b2e4
config: arm64-randconfig-r026-20200519 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 135b877874fae96b4372c8a3fbfaa8ff44ff86e3)

reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64

If you fix the issue, kindly add following tag as appropriate

All warnings (new ones prefixed by >>, old ones prefixed by <<):

>> drivers/counter/counter-chrdev.c:632:5: warning: no previous prototype for function 'counter_chrdev_add' [-Wmissing-prototypes]

int counter_chrdev_add(struct counter_device *const counter,
^
drivers/counter/counter-chrdev.c:632:1: note: declare 'static' if the function is not intended to be used outside of this translation unit int counter_chrdev_add(struct counter_device *const counter,
^
static

>> drivers/counter/counter-chrdev.c:652:6: warning: no previous prototype for function 'counter_chrdev_free' [-Wmissing-prototypes]

void counter_chrdev_free(struct counter_device *const counter)
^
drivers/counter/counter-chrdev.c:652:1: note: declare 'static' if the function is not intended to be used outside of this translation unit void counter_chrdev_free(struct counter_device *const counter)
^
static
2 warnings generated.

vim +/counter_chrdev_add +632 drivers/counter/counter-chrdev.c

631

 > 632	int counter_chrdev_add(struct counter_device *const counter,
   633			       const dev_t counter_devt)
   634	{
   635		struct device *const dev = &counter->dev;
   636		struct cdev *const chrdev = &counter->chrdev;
   637	
   638		/* Initialize Counter character device control selection */
   639		memset(counter->selection, 0, sizeof(counter->selection));
   640	
   641		/* Initialize Counter character device selected controls list */
   642		INIT_LIST_HEAD(&counter->control_list);
   643	
   644		/* Initialize character device */
   645		cdev_init(chrdev, &counter_fops);
   646		dev->devt = MKDEV(MAJOR(counter_devt), counter->id);
   647		cdev_set_parent(chrdev, &dev->kobj);
   648	
   649		return cdev_add(chrdev, dev->devt, 1);
   650	}
   651	
 > 652	void counter_chrdev_free(struct counter_device *const counter)

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

#8 lore raw

PATCH v2 4/4 docs: counter: Document character device interface

In reply to William Breathitt Gray

This patch adds high-level documentation about the Counter subsystem character device interface.

---
 Documentation/driver-api/generic-counter.rst | 112 +++++++++++++------
 1 file changed, 76 insertions(+), 36 deletions(-)
Documentation/driver-api/generic-counter.rst +76 -36
index 8f85c30dea0b..58045b33b576 100644
@@ -223,19 +223,6 @@ whether an input line is differential or single-ended) and instead focus
 on the core idea of what the data and process represent (e.g. position
 as interpreted from quadrature encoding data).
 
-Userspace Interface
-===================
-
-Several sysfs attributes are generated by the Generic Counter interface,
-and reside under the /sys/bus/counter/devices/counterX directory, where
-counterX refers to the respective counter device. Please see
-Documentation/ABI/testing/sysfs-bus-counter for detailed
-information on each Generic Counter interface sysfs attribute.
-
-Through these sysfs attributes, programs and scripts may interact with
-the Generic Counter paradigm Counts, Signals, and Synapses of respective
-counter devices.
-
 Driver API
 ==========
 
@@ -377,13 +364,13 @@ driver can be exemplified by the following::
                 +----------------------------+          |
                 | Processes data from device |   -------------------
                 |----------------------------|  / driver callbacks /
-                | Type: unsigned long        |  -------------------
+                | Type: u64                  |  -------------------
                 | Value: 42                  |          |
                 +----------------------------+          |
                         |                               |
-                 ----------------                       |
-                / unsigned long /                       |
-                ----------------                        |
+                 ----------                             |
+                / u64     /                             |
+                ----------                              |
                         |                               |
                         |                               V
                         |               +----------------------+
@@ -398,25 +385,32 @@ driver can be exemplified by the following::
                         |               / driver callbacks /
                         |               -------------------
                         |                       |
-                +-------+                       |
+                +-------+---------------+       |
+                |                       |       |
+                |               +-------|-------+
+                |               |       |
+                V               |       V
+        +--------------------+  |  +---------------------+
+        | Counter sysfs      |<-+->| Counter chrdev      |
+        +--------------------+     +---------------------+
+        | Translates to the  |     | Translates to the   |
+        | standard Counter   |     | standard Counter    |
+        | sysfs output       |     | character device    |
+        |--------------------|     |---------------------+
+        | Type: const char * |     | Type: u64           |
+        | Value: "42"        |     | Value: 42           |
+        +--------------------+     +---------------------+
                 |                               |
-                |               +---------------+
-                |               |
-                V               |
-        +--------------------+  |
-        | Counter sysfs      |<-+
-        +--------------------+
-        | Translates to the  |
-        | standard Counter   |
-        | sysfs output       |
-        |--------------------|
-        | Type: const char * |
-        | Value: "42"        |
-        +--------------------+
-                |
-         ---------------
-        / const char * /
-        ---------------
+         ---------------                 ----------
+        / const char * /                / u64     /
+        ---------------                 ----------
+                |                               |
+                |                               V
+                |                       +-----------+
+                |                       | read      |
+                |                       +-----------+
+                |                       \ Count: 42 /
+                |                        -----------
                 |
                 V
         +--------------------------------------------------+
@@ -425,7 +419,7 @@ driver can be exemplified by the following::
         \ Count: "42"                                      /
          --------------------------------------------------
 
-There are three primary components involved:
+There are four primary components involved:
 
 Counter device driver
 ---------------------
@@ -445,3 +439,49 @@ and vice versa.
 Please refer to the `Documentation/ABI/testing/sysfs-bus-counter` file
 for a detailed breakdown of the available Generic Counter interface
 sysfs attributes.
+
+Counter chrdev
+--------------
+Translates counter data to the standard Counter character device; data
+is transferred via standard character device read/write calls.
+
+Sysfs Interface
+===============
+
+Several sysfs attributes are generated by the Generic Counter interface,
+and reside under the `/sys/bus/counter/devices/counterX` directory,
+where `X` is to the respective counter device id. Please see
+Documentation/ABI/testing/sysfs-bus-counter for detailed information on
+each Generic Counter interface sysfs attribute.
+
+Through these sysfs attributes, programs and scripts may interact with
+the Generic Counter paradigm Counts, Signals, and Synapses of respective
+counter devices.
+
+Counter Character Device
+========================
+
+Counter character device nodes are created under the `/dev` directory as
+`counterX`, where `X` is the respective counter device id. Defines for
+the standard Counter data types are exposed via the userspace
+`include/uapi/linux/counter-types.h` file.
+
+The first 196095 bytes of the character device serve as a control
+selection area where control exposure of desired Counter components and
+extensions may be selected. Each byte serves as a boolean selection
+indicator for a respective Counter component or extension. The format of
+this area is as follows:
+
+* For each device extension, a byte is required.
+* For each Signal, a byte is reserved for the Signal component, and a
+  byte is reserved for each Signal extension.
+* For each Count, a byte is reserved for the Count component, a byte is
+  reserved for the count function, a byte is reserved for each Synapse
+  action, and byte is reserved for each Count extension.
+
+The selected Counter components and extensions may then be interfaced
+after the first 196095 bytes via standard character device read/write
+operations. The number of bytes available for each component or
+extension is dependent on their respective data type: u8 will have 1
+byte available, u64 will have 8 bytes available, strings will have 64
+bytes available, etc.
Signature · 1 line
2.26.2
maintainer
#9 lore raw

Re: [PATCH v2 4/4] docs: counter: Document character device interface

Quoted 150 lines · On Sat, 16 May 2020 15:20:02 -0400 William Breathitt Gray…

This patch adds high-level documentation about the Counter subsystem character device interface.

---
 Documentation/driver-api/generic-counter.rst | 112 +++++++++++++------
 1 file changed, 76 insertions(+), 36 deletions(-)
Documentation/driver-api/generic-counter.rst +66 -36
index 8f85c30dea0b..58045b33b576 100644
@@ -223,19 +223,6 @@ whether an input line is differential or single-ended) and instead focus
 on the core idea of what the data and process represent (e.g. position
 as interpreted from quadrature encoding data).
 
-Userspace Interface
-===================
-
-Several sysfs attributes are generated by the Generic Counter interface,
-and reside under the /sys/bus/counter/devices/counterX directory, where
-counterX refers to the respective counter device. Please see
-Documentation/ABI/testing/sysfs-bus-counter for detailed
-information on each Generic Counter interface sysfs attribute.
-
-Through these sysfs attributes, programs and scripts may interact with
-the Generic Counter paradigm Counts, Signals, and Synapses of respective
-counter devices.
-
 Driver API
 ==========
 
@@ -377,13 +364,13 @@ driver can be exemplified by the following::
                 +----------------------------+          |
                 | Processes data from device |   -------------------
                 |----------------------------|  / driver callbacks /
-                | Type: unsigned long        |  -------------------
+                | Type: u64                  |  -------------------
                 | Value: 42                  |          |
                 +----------------------------+          |
                         |                               |
-                 ----------------                       |
-                / unsigned long /                       |
-                ----------------                        |
+                 ----------                             |
+                / u64     /                             |
+                ----------                              |
                         |                               |
                         |                               V
                         |               +----------------------+
@@ -398,25 +385,32 @@ driver can be exemplified by the following::
                         |               / driver callbacks /
                         |               -------------------
                         |                       |
-                +-------+                       |
+                +-------+---------------+       |
+                |                       |       |
+                |               +-------|-------+
+                |               |       |
+                V               |       V
+        +--------------------+  |  +---------------------+
+        | Counter sysfs      |<-+->| Counter chrdev      |
+        +--------------------+     +---------------------+
+        | Translates to the  |     | Translates to the   |
+        | standard Counter   |     | standard Counter    |
+        | sysfs output       |     | character device    |
+        |--------------------|     |---------------------+
+        | Type: const char * |     | Type: u64           |
+        | Value: "42"        |     | Value: 42           |
+        +--------------------+     +---------------------+
                 |                               |
-                |               +---------------+
-                |               |
-                V               |
-        +--------------------+  |
-        | Counter sysfs      |<-+
-        +--------------------+
-        | Translates to the  |
-        | standard Counter   |
-        | sysfs output       |
-        |--------------------|
-        | Type: const char * |
-        | Value: "42"        |
-        +--------------------+
-                |
-         ---------------
-        / const char * /
-        ---------------
+         ---------------                 ----------
+        / const char * /                / u64     /
+        ---------------                 ----------
+                |                               |
+                |                               V
+                |                       +-----------+
+                |                       | read      |
+                |                       +-----------+
+                |                       \ Count: 42 /
+                |                        -----------
                 |
                 V
         +--------------------------------------------------+
@@ -425,7 +419,7 @@ driver can be exemplified by the following::
         \ Count: "42"                                      /
          --------------------------------------------------
 
-There are three primary components involved:
+There are four primary components involved:
 
 Counter device driver
 ---------------------
@@ -445,3 +439,49 @@ and vice versa.
 Please refer to the `Documentation/ABI/testing/sysfs-bus-counter` file
 for a detailed breakdown of the available Generic Counter interface
 sysfs attributes.
+
+Counter chrdev
+--------------
+Translates counter data to the standard Counter character device; data
+is transferred via standard character device read/write calls.
+
+Sysfs Interface
+===============
+
+Several sysfs attributes are generated by the Generic Counter interface,
+and reside under the `/sys/bus/counter/devices/counterX` directory,
+where `X` is to the respective counter device id. Please see
+Documentation/ABI/testing/sysfs-bus-counter for detailed information on
+each Generic Counter interface sysfs attribute.
+
+Through these sysfs attributes, programs and scripts may interact with
+the Generic Counter paradigm Counts, Signals, and Synapses of respective
+counter devices.
+
+Counter Character Device
+========================
+
+Counter character device nodes are created under the `/dev` directory as
+`counterX`, where `X` is the respective counter device id. Defines for
+the standard Counter data types are exposed via the userspace
+`include/uapi/linux/counter-types.h` file.
+
+The first 196095 bytes of the character device serve as a control
+selection area where control exposure of desired Counter components and
+extensions may be selected. Each byte serves as a boolean selection
+indicator for a respective Counter component or extension. The format of
+this area is as follows:
+
+* For each device extension, a byte is required.
+* For each Signal, a byte is reserved for the Signal component, and a
+  byte is reserved for each Signal extension.

Documentation/driver-api/generic-counter.rst and vice versa. · line 487

Quoted 10 lines
Documentation/driver-api/generic-counter.rst +10 -0
+* For each Count, a byte is reserved for the Count component, a byte is
+  reserved for the count function, a byte is reserved for each Synapse
+  action, and byte is reserved for each Count extension.
+
+The selected Counter components and extensions may then be interfaced
+after the first 196095 bytes via standard character device read/write
+operations. The number of bytes available for each component or
+extension is dependent on their respective data type: u8 will have 1
+byte available, u64 will have 8 bytes available, strings will have 64
+bytes available, etc.

From what I recall of the earlier conversation, I'm not sure this is what was being suggested. I 'think' what people were after was a simple read interface for just the counters (+ timestamps). This would also include the option to use select / poll on the counter.

Simply moving over to a read / write really doesn't help for ease of use. I'm not sure what the right control approach is, or perhaps if we even need one (could just output all counts provided by hardware once the chrdev is opened).

Jonathan

#10 lore raw

Re: [PATCH v2 4/4] docs: counter: Document character device interface

In reply to William Breathitt Gray
Quoted 49 lines · William Breathitt Gray

This patch adds high-level documentation about the Counter subsystem character device interface.

---
 Documentation/driver-api/generic-counter.rst | 112 +++++++++++++------
 1 file changed, 76 insertions(+), 36 deletions(-)
Documentation/driver-api/generic-counter.rst +36 -0
index 8f85c30dea0b..58045b33b576 100644
 
+
+Counter chrdev
+--------------
+Translates counter data to the standard Counter character device; data
+is transferred via standard character device read/write calls.
+
+Sysfs Interface
+===============
+
+Several sysfs attributes are generated by the Generic Counter interface,
+and reside under the `/sys/bus/counter/devices/counterX` directory,
+where `X` is to the respective counter device id. Please see
+Documentation/ABI/testing/sysfs-bus-counter for detailed information on
+each Generic Counter interface sysfs attribute.
+
+Through these sysfs attributes, programs and scripts may interact with
+the Generic Counter paradigm Counts, Signals, and Synapses of respective
+counter devices.
+
+Counter Character Device
+========================
+
+Counter character device nodes are created under the `/dev` directory as
+`counterX`, where `X` is the respective counter device id. Defines for
+the standard Counter data types are exposed via the userspace
+`include/uapi/linux/counter-types.h` file.
+
+The first 196095 bytes of the character device serve as a control
+selection area where control exposure of desired Counter components and
+extensions may be selected. Each byte serves as a boolean selection
+indicator for a respective Counter component or extension. The format of
+this area is as follows:
+
+* For each device extension, a byte is required.
+* For each Signal, a byte is reserved for the Signal component, and a
+  byte is reserved for each Signal extension.

Documentation/driver-api/generic-counter.rst and vice versa. · line 487

Quoted 10 lines
Documentation/driver-api/generic-counter.rst +10 -0
+* For each Count, a byte is reserved for the Count component, a byte is
+  reserved for the count function, a byte is reserved for each Synapse
+  action, and byte is reserved for each Count extension.
+
+The selected Counter components and extensions may then be interfaced
+after the first 196095 bytes via standard character device read/write
+operations. The number of bytes available for each component or
+extension is dependent on their respective data type: u8 will have 1
+byte available, u64 will have 8 bytes available, strings will have 64
+bytes available, etc.

This looks like very, very strange interface, and not described in detail required to understand it.

Could you take a look at input subsystem, /dev/input/event0? Perhaps it is directly usable, and if not something similar should probably be acceptable.

Best regards,
Pavel

#11 lore raw

Re: [PATCH v2 4/4] docs: counter: Document character device interface

Quoted 64 lines · Pavel Machek
Quoted 49 lines · William Breathitt Gray

This patch adds high-level documentation about the Counter subsystem character device interface.

---
 Documentation/driver-api/generic-counter.rst | 112 +++++++++++++------
 1 file changed, 76 insertions(+), 36 deletions(-)
Documentation/driver-api/generic-counter.rst +36 -0
index 8f85c30dea0b..58045b33b576 100644
 
+
+Counter chrdev
+--------------
+Translates counter data to the standard Counter character device; data
+is transferred via standard character device read/write calls.
+
+Sysfs Interface
+===============
+
+Several sysfs attributes are generated by the Generic Counter interface,
+and reside under the `/sys/bus/counter/devices/counterX` directory,
+where `X` is to the respective counter device id. Please see
+Documentation/ABI/testing/sysfs-bus-counter for detailed information on
+each Generic Counter interface sysfs attribute.
+
+Through these sysfs attributes, programs and scripts may interact with
+the Generic Counter paradigm Counts, Signals, and Synapses of respective
+counter devices.
+
+Counter Character Device
+========================
+
+Counter character device nodes are created under the `/dev` directory as
+`counterX`, where `X` is the respective counter device id. Defines for
+the standard Counter data types are exposed via the userspace
+`include/uapi/linux/counter-types.h` file.
+
+The first 196095 bytes of the character device serve as a control
+selection area where control exposure of desired Counter components and
+extensions may be selected. Each byte serves as a boolean selection
+indicator for a respective Counter component or extension. The format of
+this area is as follows:
+
+* For each device extension, a byte is required.
+* For each Signal, a byte is reserved for the Signal component, and a
+  byte is reserved for each Signal extension.

Documentation/driver-api/generic-counter.rst and vice versa. · line 487

Quoted 10 lines
Documentation/driver-api/generic-counter.rst +10 -0
+* For each Count, a byte is reserved for the Count component, a byte is
+  reserved for the count function, a byte is reserved for each Synapse
+  action, and byte is reserved for each Count extension.
+
+The selected Counter components and extensions may then be interfaced
+after the first 196095 bytes via standard character device read/write
+operations. The number of bytes available for each component or
+extension is dependent on their respective data type: u8 will have 1
+byte available, u64 will have 8 bytes available, strings will have 64
+bytes available, etc.

This looks like very, very strange interface, and not described in detail required to understand it.

Quoted 5 lines

Could you take a look at input subsystem, /dev/input/event0? Perhaps it is directly usable, and if not something similar should probably be acceptable.

Best regards,
Pavel

Yes, I don't think this is a good interface afterall. I'm implementing a different design for v3 that should be more intuitive. The input subsystem could be useful for streams of events such as timestamps, so I'll take a look at it as well in case something similar to it could be used.

William Breathitt Gray

maintainer
#12 lore raw
In reply to William Breathitt Gray

...

Quoted 9 lines

The following are some questions I have about this patchset:

1. Should the data format of the character device be configured via a sysfs attribute?

In this patchset, the first 196095 bytes of the character device are dedicated as a selection area to choose which Counter components or extensions should be exposed; the subsequent bytes are the actual data for the Counter components and extensions that were selected.

That sounds like the worst of all possible worlds. Reality is you need to do some magic library so at that point you might as well have ioctl
options to configure it. I wonder if you can keep the data flow
to be a simple 'read' from the chardev but move the control away from that. Either control via some chrdevs but keep them to the 'set / get' if this element is going to turn up in the read or not. You rapidly run into problems though, such as now to see how large a given element is going to be etc. Plus ioctls are rather messier to extend than simply adding a new sysfs file. Various subsystems do complex 'descriptor' type approaches to get around this, or you could do self describing records rather than raw data - like an input ev_dev event.

Quoted 5 lines

Moving this selection to a sysfs attribute and dedicating the character device to just data transfer might be a better design. If such a design is chosen, should the selection attribute be human-readable or binary?

Sysfs basically requires things are more or less human readable. So if you go that way I think it needs to be.

Quoted 8 lines

2. How much space should allotted for strings?

Each Counter component and extension has a respective size allotted for its data (u8 data is allotted 1 byte, u64 data is allotted 8 bytes, etc.); I have arbitrarily chosen to allot 64 bytes for strings. Is this an apt size, or should string data be allotted more or less space?

I'd go with that being big enough, but try to keep the expose interface such that the size can change it it needs to the in the future.

Quoted 13 lines

3. Should the owning component of an extension be handled by the device driver or Counter subsystem?

The Counter subsystem figures out the owner (enum counter_owner_type) for each component/extension in the counter-sysfs and counter-chrdev code. When a callback must be executed, there are various switch statements throughout the code to check whether the respective Device, Signal, or Count version of the callback should be executed; similarly, the appropriate owner type must match for the struct counter_data macros such as COUNTER_DATA_DEVICE_U64, COUNTER_DATA_SIGNAL_U64, COUNTER_DATA_COUNT_U64, etc.

Quoted 7 lines

All this complexity in the Counter subsystem code can be eliminated if a single callback type with a void *owner parameter is defined for use with all three owner types (Device, Signal, and Count). The device driver would then be responsible for casting the callback argument to the appropriate owner type; but in theory, this should not be much of a problem since the device driver is responsible for assigning the callbacks to the owning component anyway.

Whilst its more complex for subsytem I think it's better to keep everything typed if we possibly can. Always a trade off though, so use your discretion.

Jonathan

Quoted 34 lines

William Breathitt Gray (4):
counter: Internalize sysfs interface code
docs: counter: Update to reflect sysfs internalization
counter: Add character device interface
docs: counter: Document character device interface

 Documentation/driver-api/generic-counter.rst |  275 +++-
 MAINTAINERS                                  |    3 +-
 drivers/counter/104-quad-8.c                 |  547 +++----
 drivers/counter/Makefile                     |    1 +
 drivers/counter/counter-chrdev.c             |  656 ++++++++
 drivers/counter/counter-chrdev.h             |   16 +
 drivers/counter/counter-core.c               |  187 +++
 drivers/counter/counter-sysfs.c              |  881 +++++++++++
 drivers/counter/counter-sysfs.h              |   14 +
 drivers/counter/counter.c                    | 1496 ------------------
 drivers/counter/ftm-quaddec.c                |   89 +-
 drivers/counter/stm32-lptimer-cnt.c          |  161 +-
 drivers/counter/stm32-timer-cnt.c            |  139 +-
 drivers/counter/ti-eqep.c                    |  211 +--
 include/linux/counter.h                      |  626 ++++----
 include/linux/counter_enum.h                 |   45 -
 include/uapi/linux/counter-types.h           |   45 +
 17 files changed, 2826 insertions(+), 2566 deletions(-)
 create mode 100644 drivers/counter/counter-chrdev.c
 create mode 100644 drivers/counter/counter-chrdev.h
 create mode 100644 drivers/counter/counter-core.c
 create mode 100644 drivers/counter/counter-sysfs.c
 create mode 100644 drivers/counter/counter-sysfs.h
 delete mode 100644 drivers/counter/counter.c
 delete mode 100644 include/linux/counter_enum.h
 create mode 100644 include/uapi/linux/counter-types.h
#13 lore raw
Quoted 13 lines · Jonathan Cameron

...

Quoted 9 lines

The following are some questions I have about this patchset:

1. Should the data format of the character device be configured via a sysfs attribute?

In this patchset, the first 196095 bytes of the character device are dedicated as a selection area to choose which Counter components or extensions should be exposed; the subsequent bytes are the actual data for the Counter components and extensions that were selected.

Quoted 12 lines

That sounds like the worst of all possible worlds. Reality is you need to do some magic library so at that point you might as well have ioctl
options to configure it. I wonder if you can keep the data flow
to be a simple 'read' from the chardev but move the control away from that. Either control via some chrdevs but keep them to the 'set / get' if this element is going to turn up in the read or not. You rapidly run into problems though, such as now to see how large a given element is going to be etc. Plus ioctls are rather messier to extend than simply adding a new sysfs file. Various subsystems do complex 'descriptor' type approaches to get around this, or you could do self describing records rather than raw data - like an input ev_dev event.

Yes I agree, I don't think combining nondata with data is good design -- it's better if users are able to simply perform read/write on the character device without having to keep track of valid offsets and controls.

After giving this some more thought, I believe human-readable sysfs attributes are the way to go to support configuration of the character device. I am thinking of a system like this:

* Users configure the counter character device via a sysfs attribute such as /sys/bus/counter/devices/counterX/chrdev_format or similar.

* Users may write to this sysfs attribute to select the components they want to interface -- the layout can be determined as well from the order. For example:

  # echo "C0 C3 C2" > /sys/bus/counter/devices/counter0/chrdev_format

This would select Counts 0, 3, and 2 (in that order) to be available in the /dev/counter0 node as a contiguous memory region.

You can select extensions in a similar fashion:

  # echo "C4E2 S1E0" > /sys/bus/counter/devices/counter0/chrdev_format

This would select extension 2 from Count 4, and extension 0 from Signal 1.

* Users may read from this chrdev_format sysfs attribute in order to see the currently configured format of the character device.

* Users may perform read/write operations on the /dev/counterX node directly; the layout of the data is what they user has configured via the chrdev_format sysfs attribute. For example:

  # echo "C0 C1 S0 S1" > /sys/bus/counter/devices/counter0/chrdev_format

Yields the following /dev/counter0 memory layout:

  +-----------------+------------------+----------+----------+
  | Byte 0 - Byte 7 | Byte 8 - Byte 15 | Byte 16  | Byte 17  |
  +-----------------+------------------+----------+----------+
  | Count 0         | Count 1          | Signal 0 | Signal 2 |
  +-----------------+------------------+----------+----------+

* Users may perform select/poll operations on the /dev/counterX node. Users can be notified if data is available or events have occurred.

The benefit of this design is that the format is robust so users can choose the components they want to interface and in the layout they want. For example, if I am writing a userspace application to control a dual-axis positioning table, I can select the two counts I care about for the position axes. This allows me to read just those two values directly from /dev/counterX with a simple read() call, without having to fumble around seeking to an offset and parsing the layout.

Similarly, support for future extensions is simple to implement. When timestamp support is implemented, users can just select the desired timestamp extension and read it directly from the /dev/counterX node; they should also be able to perform a select()/poll() call to be notified on new timestamps.

So what do you think of this sort of design? I think there is a useful robustness to the simplicity of performing a single read/write call on /dev/counterX.

Quoted 12 lines
Quoted 5 lines

Moving this selection to a sysfs attribute and dedicating the character device to just data transfer might be a better design. If such a design is chosen, should the selection attribute be human-readable or binary?

Sysfs basically requires things are more or less human readable. So if you go that way I think it needs to be.

Quoted 3 lines

2. How much space should allotted for strings?

Quoted 8 lines
Quoted 5 lines

Each Counter component and extension has a respective size allotted for its data (u8 data is allotted 1 byte, u64 data is allotted 8 bytes, etc.); I have arbitrarily chosen to allot 64 bytes for strings. Is this an apt size, or should string data be allotted more or less space?

I'd go with that being big enough, but try to keep the expose interface such that the size can change it it needs to the in the future.

Following along with the separation of control vs data as discussed above, we could support a more variable size by exposing it through a sysfs attribute (maybe a chrdev_string_size attribute or similar).

Quoted 22 lines
Quoted 14 lines

3. Should the owning component of an extension be handled by the device driver or Counter subsystem?

The Counter subsystem figures out the owner (enum counter_owner_type) for each component/extension in the counter-sysfs and counter-chrdev code. When a callback must be executed, there are various switch statements throughout the code to check whether the respective Device, Signal, or Count version of the callback should be executed; similarly, the appropriate owner type must match for the struct counter_data macros such as COUNTER_DATA_DEVICE_U64, COUNTER_DATA_SIGNAL_U64, COUNTER_DATA_COUNT_U64, etc.

Quoted 7 lines

All this complexity in the Counter subsystem code can be eliminated if a single callback type with a void *owner parameter is defined for use with all three owner types (Device, Signal, and Count). The device driver would then be responsible for casting the callback argument to the appropriate owner type; but in theory, this should not be much of a problem since the device driver is responsible for assigning the callbacks to the owning component anyway.

Quoted 4 lines

Whilst its more complex for subsytem I think it's better to keep everything typed if we possibly can. Always a trade off though, so use your discretion.

Jonathan

I'm going to keep it all typed for now since I don't want to make too many changes at once. Since this is somewhat unrelated to the purpose of introducing Counter character devices, I'll postpone the discussion to a later date after the Counter character device interface is merged.

William Breathitt Gray

Quoted 37 lines
Quoted 36 lines

William Breathitt Gray (4):
counter: Internalize sysfs interface code
docs: counter: Update to reflect sysfs internalization
counter: Add character device interface
docs: counter: Document character device interface

 Documentation/driver-api/generic-counter.rst |  275 +++-
 MAINTAINERS                                  |    3 +-
 drivers/counter/104-quad-8.c                 |  547 +++----
 drivers/counter/Makefile                     |    1 +
 drivers/counter/counter-chrdev.c             |  656 ++++++++
 drivers/counter/counter-chrdev.h             |   16 +
 drivers/counter/counter-core.c               |  187 +++
 drivers/counter/counter-sysfs.c              |  881 +++++++++++
 drivers/counter/counter-sysfs.h              |   14 +
 drivers/counter/counter.c                    | 1496 ------------------
 drivers/counter/ftm-quaddec.c                |   89 +-
 drivers/counter/stm32-lptimer-cnt.c          |  161 +-
 drivers/counter/stm32-timer-cnt.c            |  139 +-
 drivers/counter/ti-eqep.c                    |  211 +--
 include/linux/counter.h                      |  626 ++++----
 include/linux/counter_enum.h                 |   45 -
 include/uapi/linux/counter-types.h           |   45 +
 17 files changed, 2826 insertions(+), 2566 deletions(-)
 create mode 100644 drivers/counter/counter-chrdev.c
 create mode 100644 drivers/counter/counter-chrdev.h
 create mode 100644 drivers/counter/counter-core.c
 create mode 100644 drivers/counter/counter-sysfs.c
 create mode 100644 drivers/counter/counter-sysfs.h
 delete mode 100644 drivers/counter/counter.c
 delete mode 100644 include/linux/counter_enum.h
 create mode 100644 include/uapi/linux/counter-types.h
maintainer
#14 lore raw
Quoted 36 lines · On Sun, 24 May 2020 13:54:39 -0400 William Breathitt Gray…
Quoted 13 lines · Jonathan Cameron

...

Quoted 9 lines

The following are some questions I have about this patchset:

1. Should the data format of the character device be configured via a sysfs attribute?

In this patchset, the first 196095 bytes of the character device are dedicated as a selection area to choose which Counter components or extensions should be exposed; the subsequent bytes are the actual data for the Counter components and extensions that were selected.

Quoted 12 lines

That sounds like the worst of all possible worlds. Reality is you need to do some magic library so at that point you might as well have ioctl
options to configure it. I wonder if you can keep the data flow
to be a simple 'read' from the chardev but move the control away from that. Either control via some chrdevs but keep them to the 'set / get' if this element is going to turn up in the read or not. You rapidly run into problems though, such as now to see how large a given element is going to be etc. Plus ioctls are rather messier to extend than simply adding a new sysfs file. Various subsystems do complex 'descriptor' type approaches to get around this, or you could do self describing records rather than raw data - like an input ev_dev event.

Yes I agree, I don't think combining nondata with data is good design -- it's better if users are able to simply perform read/write on the character device without having to keep track of valid offsets and controls.

After giving this some more thought, I believe human-readable sysfs attributes are the way to go to support configuration of the character device. I am thinking of a system like this:

Quoted 8 lines

* Users configure the counter character device via a sysfs attribute such as /sys/bus/counter/devices/counterX/chrdev_format or similar.

* Users may write to this sysfs attribute to select the components they want to interface -- the layout can be determined as well from the order. For example:

  # echo "C0 C3 C2" > /sys/bus/counter/devices/counter0/chrdev_format

I guess that 'just' meets the sysfs requirement of one file => one thing.

Quoted 10 lines

This would select Counts 0, 3, and 2 (in that order) to be available in the /dev/counter0 node as a contiguous memory region.

You can select extensions in a similar fashion:

  # echo "C4E2 S1E0" > /sys/bus/counter/devices/counter0/chrdev_format

This would select extension 2 from Count 4, and extension 0 from Signal 1.

I'm not totally clear why we'd want to have a chrdev access to extensions. To be honest I'm not totally sure what an extension is today as it's been a week ;)

Perhaps an example? I see timestamp below. What is that attached to? If we gave multiple counters, do they each have a timestamp?

Quoted 12 lines

* Users may read from this chrdev_format sysfs attribute in order to see the currently configured format of the character device.

* Users may perform read/write operations on the /dev/counterX node directly; the layout of the data is what they user has configured via the chrdev_format sysfs attribute. For example:

  # echo "C0 C1 S0 S1" > /sys/bus/counter/devices/counter0/chrdev_format

Yields the following /dev/counter0 memory layout:

Quoted 8 lines
  +-----------------+------------------+----------+----------+
  | Byte 0 - Byte 7 | Byte 8 - Byte 15 | Byte 16  | Byte 17  |
  +-----------------+------------------+----------+----------+
  | Count 0         | Count 1          | Signal 0 | Signal 2 |
  +-----------------+------------------+----------+----------+

* Users may perform select/poll operations on the /dev/counterX node. Users can be notified if data is available or events have occurred.

One thing to think about early if watermarks. We bolted them on late in IIO and maybe we could have done it better from the start. I'd almost guarantee someone will want one fairly soon - particularly as it's more than possible you'll have a counter device with a hardware fifo. I have some vague recollection that ti-ecap stuff could be presented as a short fifo for starters.

Quoted 8 lines

The benefit of this design is that the format is robust so users can choose the components they want to interface and in the layout they want. For example, if I am writing a userspace application to control a dual-axis positioning table, I can select the two counts I care about for the position axes. This allows me to read just those two values directly from /dev/counterX with a simple read() call, without having to fumble around seeking to an offset and parsing the layout.

I wonder if I'm over thinking things for counters, but you may run into the complexity of different counters having different sampling frequencies. Here you are suggesting a scheme that I think ends up closer to IIO than
input. That makes this case a pain. Input takes the view that it's
fine to have data coming in any order and frequency because every record is self describing. I'm not sure it matters here, but it is a nice layer of flexibility, but you do loose the efficiency of the description being external to the data flow.

Quoted 10 lines

Similarly, support for future extensions is simple to implement. When timestamp support is implemented, users can just select the desired timestamp extension and read it directly from the /dev/counterX node; they should also be able to perform a select()/poll() call to be notified on new timestamps.

So what do you think of this sort of design? I think there is a useful robustness to the simplicity of performing a single read/write call on /dev/counterX.

It seems like a reasonable solution to me. The only blurry boundary to my mind is what level of buffering is behind this. The things you can do are open, non blocking read, blocking read and select.

If we have a counter that is sampled on demand, then
1) Non blocking read - makes not sense, fair enough I guess, could make it the same as a blocking read.
2) Blocking read - reads from the sensor.
3) Select, meaningless as all reads are done on demand - so I guess you hardwire it to return immediately.
4) open. Nothing special

If you have a counter that is self clocking then data gets pushed into some software structure (probably kfifo)
1) Blocking read, question of semantics to resolve
a) Return when 'some' data is available (like a socket)
b) Return when 'requested amount of data is available'?
2) Non blocking read. Return whatever happens to be available.
3) Select. Semantics to be defined.
a) Some data?
b) Watermark based (default watermark is 0 so any data triggers it)
4) Open. Starts up sampling of configured set - (typically turns on the device, enables interrupt output etc.)

So some corners to resolve but should all work.

Quoted 19 lines
Quoted 19 lines
Quoted 6 lines

Moving this selection to a sysfs attribute and dedicating the character device to just data transfer might be a better design. If such a design is chosen, should the selection attribute be human-readable or binary?

Sysfs basically requires things are more or less human readable. So if you go that way I think it needs to be.

Quoted 8 lines

2. How much space should allotted for strings?

Each Counter component and extension has a respective size allotted for its data (u8 data is allotted 1 byte, u64 data is allotted 8 bytes, etc.); I have arbitrarily chosen to allot 64 bytes for strings. Is this an apt size, or should string data be allotted more or less space?

Quoted 6 lines
Quoted 2 lines

I'd go with that being big enough, but try to keep the expose interface such that the size can change it it needs to the in the future.

Following along with the separation of control vs data as discussed above, we could support a more variable size by exposing it through a sysfs attribute (maybe a chrdev_string_size attribute or similar).

I'm unconvinced you'd ever want to return a string via the chardev. People are using the chrdev to get efficiency. String based data flows are rarely that!

Quoted 26 lines
Quoted 26 lines
Quoted 15 lines

3. Should the owning component of an extension be handled by the device driver or Counter subsystem?

The Counter subsystem figures out the owner (enum counter_owner_type) for each component/extension in the counter-sysfs and counter-chrdev code. When a callback must be executed, there are various switch statements throughout the code to check whether the respective Device, Signal, or Count version of the callback should be executed; similarly, the appropriate owner type must match for the struct counter_data macros such as COUNTER_DATA_DEVICE_U64, COUNTER_DATA_SIGNAL_U64, COUNTER_DATA_COUNT_U64, etc.

Quoted 7 lines

All this complexity in the Counter subsystem code can be eliminated if a single callback type with a void *owner parameter is defined for use with all three owner types (Device, Signal, and Count). The device driver would then be responsible for casting the callback argument to the appropriate owner type; but in theory, this should not be much of a problem since the device driver is responsible for assigning the callbacks to the owning component anyway.

Whilst its more complex for subsytem I think it's better to keep everything typed if we possibly can. Always a trade off though, so use your discretion.

Quoted 6 lines
Quoted 1 line

Jonathan

I'm going to keep it all typed for now since I don't want to make too many changes at once. Since this is somewhat unrelated to the purpose of introducing Counter character devices, I'll postpone the discussion to a later date after the Counter character device interface is merged.

Makes sense.

Jonathan

Quoted 40 lines

William Breathitt Gray

Quoted 37 lines
Quoted 36 lines

William Breathitt Gray (4):
counter: Internalize sysfs interface code
docs: counter: Update to reflect sysfs internalization
counter: Add character device interface
docs: counter: Document character device interface

 Documentation/driver-api/generic-counter.rst |  275 +++-
 MAINTAINERS                                  |    3 +-
 drivers/counter/104-quad-8.c                 |  547 +++----
 drivers/counter/Makefile                     |    1 +
 drivers/counter/counter-chrdev.c             |  656 ++++++++
 drivers/counter/counter-chrdev.h             |   16 +
 drivers/counter/counter-core.c               |  187 +++
 drivers/counter/counter-sysfs.c              |  881 +++++++++++
 drivers/counter/counter-sysfs.h              |   14 +
 drivers/counter/counter.c                    | 1496 ------------------
 drivers/counter/ftm-quaddec.c                |   89 +-
 drivers/counter/stm32-lptimer-cnt.c          |  161 +-
 drivers/counter/stm32-timer-cnt.c            |  139 +-
 drivers/counter/ti-eqep.c                    |  211 +--
 include/linux/counter.h                      |  626 ++++----
 include/linux/counter_enum.h                 |   45 -
 include/uapi/linux/counter-types.h           |   45 +
 17 files changed, 2826 insertions(+), 2566 deletions(-)
 create mode 100644 drivers/counter/counter-chrdev.c
 create mode 100644 drivers/counter/counter-chrdev.h
 create mode 100644 drivers/counter/counter-core.c
 create mode 100644 drivers/counter/counter-sysfs.c
 create mode 100644 drivers/counter/counter-sysfs.h
 delete mode 100644 drivers/counter/counter.c
 delete mode 100644 include/linux/counter_enum.h
 create mode 100644 include/uapi/linux/counter-types.h
#15 lore raw
Quoted 9 lines · Jonathan Cameron
Quoted 7 lines · On Sun, 24 May 2020 13:54:39 -0400 William Breathitt Gray…

After giving this some more thought, I believe human-readable sysfs attributes are the way to go to support configuration of the character device. I am thinking of a system like this:

* Users configure the counter character device via a sysfs attribute such as /sys/bus/counter/devices/counterX/chrdev_format or similar.

Quoted 7 lines
Quoted 5 lines

* Users may write to this sysfs attribute to select the components they want to interface -- the layout can be determined as well from the order. For example:

  # echo "C0 C3 C2" > /sys/bus/counter/devices/counter0/chrdev_format

I guess that 'just' meets the sysfs requirement of one file => one thing.

We can massage this further to make it more apt, but the main idea here is that configuration should be separate from our data; and that configuration should be performed via sysfs.

Quoted 5 lines
Quoted 5 lines

This would select Counts 0, 3, and 2 (in that order) to be available in the /dev/counter0 node as a contiguous memory region.

You can select extensions in a similar fashion:

Quoted 8 lines
Quoted 4 lines
  # echo "C4E2 S1E0" > /sys/bus/counter/devices/counter0/chrdev_format

This would select extension 2 from Count 4, and extension 0 from Signal 1.

I'm not totally clear why we'd want to have a chrdev access to extensions. To be honest I'm not totally sure what an extension is today as it's been a week ;)

In the context of the Counter subsystem, an extension is data/control that is not one of the core components of the Counter paradigm (i.e. not a Counter, Signal, nor Synapse). Extensions essentially represent configuration options for the counter device and auxiliary functionality.

The "Implementation" section of the Generic Counter documentation Documentation/driver-api/generic-counter.rst file gives some good examples of extensions, but I'll provide an example here for the sake of this new character device interface.

Suppose we have a robot controlling a laser on a dual-axes positioning table. A counter device is used to track the position of the laser:
Count 0 represents position on the X axis, while Count 1 represents position on the Y axis. Because this machine is moving across two axes at the same time, we want to grab both counts together via the character device subsystem (grabbing them separately via sysfs would be imprecise due to the inherent latency).

The motors are physically able the robot out of the work area, which is not something we want to happen. A common setup in systems like this is to set soft boundaries on the counter device to represent the edge of the work area; when the boundary is passed, a flag is set high on the device to indicate the position is out-of-bounds.

On the Counter subsystem side, this counter device would appear as having four sysfs attributes: count0/count, count0/boundary, count1/count, and count1/boundary. In terms of the character device interface, we could perform a setup like this:

# echo "C0E0 C0 C1E1 C1" > counter0/chrdev_format

Yielding the following /dev/counter0 memory layout:

+------------+-----------------+------------+-------------------+
| Byte 0     | Byte 1 - Byte 8 | Byte 9     | Byte 10 - Byte 17 |
+------------+-----------------+------------+-------------------+
| Boundary 0 | Count 0         | Boundary 1 | Count 1           |
+------------+-----------------+------------+-------------------+

Now a single read() operation can grab the counts together as well as their respective boundary flags to verify whether the current counts are valid. This is a scenario where using sysfs wouldn't be viable to use:
we could check the count0/boundary sysfs attribute first, but by the time we read the count0/count sysfs attribute second, the robot has already moved to a new (possibly invalid) position.

Quoted 2 lines

Perhaps an example? I see timestamp below. What is that attached to? If we gave multiple counters, do they each have a timestamp?

Some counter devices feature "timestamp" functionality. I haven't yet implemented this in the Counter subsystem because it's new functionality and I want to keep this patchset limited to the existing Counter subsystem functionality support.

However, to briefly go into the topic (we'll need to discuss this more in-depth before committing to a Counter subsystem design), some counter devices can keep track of historic counts based on various events; we call these "timestamps", although they may not necessary be tied to a wall-clock time.

For example, quadrature encoders often have an "index" signal in addition to the quadrature A and B lines. This index signal may be used to home a positioning device, or perhaps to indicate that a full revolution -- or some other event -- has occurred. It's common for quadrature counter devices to provide a FIFO buffer that logs these "index" events by saving the current count when that respective index signal goes high. Thus we have a timestamp buffer.

In the context of the Counter subsystem, I believe we will end up implementing these timestamps as Count extensions (or Device extensions if it's a single buffer for the entire device). I'm not sure yet what the sysfs attribute will display, but I'm guessing we'll have a respective /sys/bus/counter/devices/counterX/countX/timestamps sysfs attribute or similar.

The character device implementation should be more straight forward I would imagine. Since it's a memory buffer, I think we can provide access to that buffer directly in the chrdev:

# echo "C0E0 C1E1" > /sys/bus/counter/devices/counter0/chrdev_format

Yielding the following /dev/counter0 memory layout for 32-byte timestamps:

+---------------------+---------------------+
| Byte 0 - Byte 31    | Byte 32 - Byte 63   |
+---------------------+---------------------+
| Timestamps Buffer 0 | Timestamps Buffer 1 |
+---------------------+---------------------+
Quoted 36 lines
Quoted 11 lines

* Users may read from this chrdev_format sysfs attribute in order to see the currently configured format of the character device.

* Users may perform read/write operations on the /dev/counterX node directly; the layout of the data is what they user has configured via the chrdev_format sysfs attribute. For example:

  # echo "C0 C1 S0 S1" > /sys/bus/counter/devices/counter0/chrdev_format

Yields the following /dev/counter0 memory layout:

Quoted 8 lines
  +-----------------+------------------+----------+----------+
  | Byte 0 - Byte 7 | Byte 8 - Byte 15 | Byte 16  | Byte 17  |
  +-----------------+------------------+----------+----------+
  | Count 0         | Count 1          | Signal 0 | Signal 2 |
  +-----------------+------------------+----------+----------+

* Users may perform select/poll operations on the /dev/counterX node. Users can be notified if data is available or events have occurred.

One thing to think about early if watermarks. We bolted them on late in IIO and maybe we could have done it better from the start. I'd almost guarantee someone will want one fairly soon - particularly as it's more than possible you'll have a counter device with a hardware fifo. I have some vague recollection that ti-ecap stuff could be presented as a short fifo for starters.

Quoted 8 lines

The benefit of this design is that the format is robust so users can choose the components they want to interface and in the layout they want. For example, if I am writing a userspace application to control a dual-axis positioning table, I can select the two counts I care about for the position axes. This allows me to read just those two values directly from /dev/counterX with a simple read() call, without having to fumble around seeking to an offset and parsing the layout.

Quoted 8 lines

I wonder if I'm over thinking things for counters, but you may run into the complexity of different counters having different sampling frequencies. Here you are suggesting a scheme that I think ends up closer to IIO than
input. That makes this case a pain. Input takes the view that it's
fine to have data coming in any order and frequency because every record is self describing. I'm not sure it matters here, but it is a nice layer of flexibility, but you do loose the efficiency of the description being external to the data flow.

I think one of the downsides to using a single a single character device node to represent the entire counter device is that the frequency of two individual counts may differ from each other. For example, using the dual-axes positioning scenario from earlier, one axis might change more frequently than the other (e.g. a conveyor belt situation where X is always moving forward, while Y only changes when a part appears within the work area).

In these cases, I think the Input subsystem approach might be better because the user can just wait for events at large and handle each event as it comes in, rather than try to coordinate between them all in a shared memory space. The shortcoming with this approach is that we lose the ability to grab Counts together at the same time, such as we require in the constantly moving robot example earlier.

Perhaps what might work is to implement Counter events (perhaps even timestamps) using the Input subsystem, and leave the Counter character device interface to simple read/write operations. But we'll need to investigate this further because we lack a concept of "events" right now in the Counter subsystem.

Quoted 34 lines
Quoted 9 lines

Similarly, support for future extensions is simple to implement. When timestamp support is implemented, users can just select the desired timestamp extension and read it directly from the /dev/counterX node; they should also be able to perform a select()/poll() call to be notified on new timestamps.

So what do you think of this sort of design? I think there is a useful robustness to the simplicity of performing a single read/write call on /dev/counterX.

It seems like a reasonable solution to me. The only blurry boundary to my mind is what level of buffering is behind this. The things you can do are open, non blocking read, blocking read and select.

If we have a counter that is sampled on demand, then
1) Non blocking read - makes not sense, fair enough I guess, could make it the same as a blocking read.
2) Blocking read - reads from the sensor.
3) Select, meaningless as all reads are done on demand - so I guess you hardwire it to return immediately.
4) open. Nothing special

If you have a counter that is self clocking then data gets pushed into some software structure (probably kfifo)
1) Blocking read, question of semantics to resolve
a) Return when 'some' data is available (like a socket)
b) Return when 'requested amount of data is available'?
2) Non blocking read. Return whatever happens to be available.
3) Select. Semantics to be defined.
a) Some data?
b) Watermark based (default watermark is 0 so any data triggers it)
4) Open. Starts up sampling of configured set - (typically turns on the device, enables interrupt output etc.)

Quoted 1 line

So some corners to resolve but should all work.

I'm not familiar with the "watermark" terminology. Would you be able to explain it bit more for me. Is this simply a flag that indicates if data has changed from the last time it was checked?

Quoted 20 lines
Quoted 20 lines
Quoted 19 lines
Quoted 4 lines

Moving this selection to a sysfs attribute and dedicating the character device to just data transfer might be a better design. If such a design is chosen, should the selection attribute be human-readable or binary?

Sysfs basically requires things are more or less human readable. So if you go that way I think it needs to be.

Quoted 8 lines

2. How much space should allotted for strings?

Each Counter component and extension has a respective size allotted for its data (u8 data is allotted 1 byte, u64 data is allotted 8 bytes, etc.); I have arbitrarily chosen to allot 64 bytes for strings. Is this an apt size, or should string data be allotted more or less space?

I'd go with that being big enough, but try to keep the expose interface such that the size can change it it needs to the in the future.

Quoted 7 lines
Quoted 3 lines

Following along with the separation of control vs data as discussed above, we could support a more variable size by exposing it through a sysfs attribute (maybe a chrdev_string_size attribute or similar).

I'm unconvinced you'd ever want to return a string via the chardev. People are using the chrdev to get efficiency. String based data flows are rarely that!

That's a good point. I don't think there is a situation right now where we need to deliver strings via the character device interface, so I think I'll remove that in v3.

William Breathitt Gray

#16 lore raw
Quoted 76 lines · On Sun, 31 May 2020 13:14:06 -0400 William Breathitt Gray…
Quoted 9 lines · Jonathan Cameron
Quoted 7 lines · On Sun, 24 May 2020 13:54:39 -0400 William Breathitt Gray…

After giving this some more thought, I believe human-readable sysfs attributes are the way to go to support configuration of the character device. I am thinking of a system like this:

* Users configure the counter character device via a sysfs attribute such as /sys/bus/counter/devices/counterX/chrdev_format or similar.

Quoted 7 lines
Quoted 5 lines

* Users may write to this sysfs attribute to select the components they want to interface -- the layout can be determined as well from the order. For example:

  # echo "C0 C3 C2" > /sys/bus/counter/devices/counter0/chrdev_format  

I guess that 'just' meets the sysfs requirement of one file => one thing.

We can massage this further to make it more apt, but the main idea here is that configuration should be separate from our data; and that configuration should be performed via sysfs.

Quoted 5 lines
Quoted 5 lines

This would select Counts 0, 3, and 2 (in that order) to be available in the /dev/counter0 node as a contiguous memory region.

You can select extensions in a similar fashion:

Quoted 8 lines
Quoted 4 lines
  # echo "C4E2 S1E0" > /sys/bus/counter/devices/counter0/chrdev_format

This would select extension 2 from Count 4, and extension 0 from Signal 1.

I'm not totally clear why we'd want to have a chrdev access to extensions. To be honest I'm not totally sure what an extension is today as it's been a week ;)

In the context of the Counter subsystem, an extension is data/control that is not one of the core components of the Counter paradigm (i.e. not a Counter, Signal, nor Synapse). Extensions essentially represent configuration options for the counter device and auxiliary functionality.

The "Implementation" section of the Generic Counter documentation Documentation/driver-api/generic-counter.rst file gives some good examples of extensions, but I'll provide an example here for the sake of this new character device interface.

Suppose we have a robot controlling a laser on a dual-axes positioning table. A counter device is used to track the position of the laser:
Count 0 represents position on the X axis, while Count 1 represents position on the Y axis. Because this machine is moving across two axes at the same time, we want to grab both counts together via the character device subsystem (grabbing them separately via sysfs would be imprecise due to the inherent latency).

The motors are physically able the robot out of the work area, which is not something we want to happen. A common setup in systems like this is to set soft boundaries on the counter device to represent the edge of the work area; when the boundary is passed, a flag is set high on the device to indicate the position is out-of-bounds.

On the Counter subsystem side, this counter device would appear as having four sysfs attributes: count0/count, count0/boundary, count1/count, and count1/boundary. In terms of the character device interface, we could perform a setup like this:

# echo "C0E0 C0 C1E1 C1" > counter0/chrdev_format

Yielding the following /dev/counter0 memory layout:

+------------+-----------------+------------+-------------------+
| Byte 0     | Byte 1 - Byte 8 | Byte 9     | Byte 10 - Byte 17 |
+------------+-----------------+------------+-------------------+
| Boundary 0 | Count 0         | Boundary 1 | Count 1           |
+------------+-----------------+------------+-------------------+
Quoted 6 lines

Now a single read() operation can grab the counts together as well as their respective boundary flags to verify whether the current counts are valid. This is a scenario where using sysfs wouldn't be viable to use:
we could check the count0/boundary sysfs attribute first, but by the time we read the count0/count sysfs attribute second, the robot has already moved to a new (possibly invalid) position.

Ok. So typically something like a condition flag. Data that indeed makes sense to be associated with a set of counter values.

Quoted 15 lines
Quoted 3 lines

Perhaps an example? I see timestamp below. What is that attached to? If we gave multiple counters, do they each have a timestamp?

Some counter devices feature "timestamp" functionality. I haven't yet implemented this in the Counter subsystem because it's new functionality and I want to keep this patchset limited to the existing Counter subsystem functionality support.

However, to briefly go into the topic (we'll need to discuss this more in-depth before committing to a Counter subsystem design), some counter devices can keep track of historic counts based on various events; we call these "timestamps", although they may not necessary be tied to a wall-clock time.

Quoted 7 lines

For example, quadrature encoders often have an "index" signal in addition to the quadrature A and B lines. This index signal may be used to home a positioning device, or perhaps to indicate that a full revolution -- or some other event -- has occurred. It's common for quadrature counter devices to provide a FIFO buffer that logs these "index" events by saving the current count when that respective index signal goes high. Thus we have a timestamp buffer.

That doesn't sound like a timestamp buffer. You are logging counts, not the current time. If they are going through a FIFO you might also capture a freerunning timer though.

Quoted 14 lines

In the context of the Counter subsystem, I believe we will end up implementing these timestamps as Count extensions (or Device extensions if it's a single buffer for the entire device). I'm not sure yet what the sysfs attribute will display, but I'm guessing we'll have a respective /sys/bus/counter/devices/counterX/countX/timestamps sysfs attribute or similar.

The character device implementation should be more straight forward I would imagine. Since it's a memory buffer, I think we can provide access to that buffer directly in the chrdev:

# echo "C0E0 C1E1" > /sys/bus/counter/devices/counter0/chrdev_format
Quoted 8 lines

Yielding the following /dev/counter0 memory layout for 32-byte timestamps:

+---------------------+---------------------+
| Byte 0 - Byte 31    | Byte 32 - Byte 63   |
+---------------------+---------------------+
| Timestamps Buffer 0 | Timestamps Buffer 1 |
+---------------------+---------------------+

As you say, will need more discussion. Lots of fun questions around timestamps such as what the timebase is, how to relate it to system time etc.

Quoted 46 lines
Quoted 37 lines
Quoted 12 lines

* Users may read from this chrdev_format sysfs attribute in order to see the currently configured format of the character device.

* Users may perform read/write operations on the /dev/counterX node directly; the layout of the data is what they user has configured via the chrdev_format sysfs attribute. For example:

  # echo "C0 C1 S0 S1" > /sys/bus/counter/devices/counter0/chrdev_format

Yields the following /dev/counter0 memory layout:

Quoted 8 lines
  +-----------------+------------------+----------+----------+
  | Byte 0 - Byte 7 | Byte 8 - Byte 15 | Byte 16  | Byte 17  |
  +-----------------+------------------+----------+----------+
  | Count 0         | Count 1          | Signal 0 | Signal 2 |
  +-----------------+------------------+----------+----------+

* Users may perform select/poll operations on the /dev/counterX node. Users can be notified if data is available or events have occurred.

One thing to think about early if watermarks. We bolted them on late in IIO and maybe we could have done it better from the start. I'd almost guarantee someone will want one fairly soon - particularly as it's more than possible you'll have a counter device with a hardware fifo. I have some vague recollection that ti-ecap stuff could be presented as a short fifo for starters.

Quoted 8 lines

The benefit of this design is that the format is robust so users can choose the components they want to interface and in the layout they want. For example, if I am writing a userspace application to control a dual-axis positioning table, I can select the two counts I care about for the position axes. This allows me to read just those two values directly from /dev/counterX with a simple read() call, without having to fumble around seeking to an offset and parsing the layout.

Quoted 8 lines

I wonder if I'm over thinking things for counters, but you may run into the complexity of different counters having different sampling frequencies. Here you are suggesting a scheme that I think ends up closer to IIO than
input. That makes this case a pain. Input takes the view that it's
fine to have data coming in any order and frequency because every record is self describing. I'm not sure it matters here, but it is a nice layer of flexibility, but you do loose the efficiency of the description being external to the data flow.

Quoted 7 lines

I think one of the downsides to using a single a single character device node to represent the entire counter device is that the frequency of two individual counts may differ from each other. For example, using the dual-axes positioning scenario from earlier, one axis might change more frequently than the other (e.g. a conveyor belt situation where X is always moving forward, while Y only changes when a part appears within the work area).

One option is to allow for either multiple opening of the chardev, or creation of anon file handles via an IOCTL (like we do for events in IIO). Makes the sysfs interface more complex, but would allow you to handle multiple independent raw data streams.

Quoted 7 lines

In these cases, I think the Input subsystem approach might be better because the user can just wait for events at large and handle each event as it comes in, rather than try to coordinate between them all in a shared memory space. The shortcoming with this approach is that we lose the ability to grab Counts together at the same time, such as we require in the constantly moving robot example earlier.

There are approaches like adding a sequence number to allow multiple self describing records to be associated.

Quoted 41 lines

Perhaps what might work is to implement Counter events (perhaps even timestamps) using the Input subsystem, and leave the Counter character device interface to simple read/write operations. But we'll need to investigate this further because we lack a concept of "events" right now in the Counter subsystem.

Quoted 34 lines
Quoted 9 lines

Similarly, support for future extensions is simple to implement. When timestamp support is implemented, users can just select the desired timestamp extension and read it directly from the /dev/counterX node; they should also be able to perform a select()/poll() call to be notified on new timestamps.

So what do you think of this sort of design? I think there is a useful robustness to the simplicity of performing a single read/write call on /dev/counterX.

It seems like a reasonable solution to me. The only blurry boundary to my mind is what level of buffering is behind this. The things you can do are open, non blocking read, blocking read and select.

If we have a counter that is sampled on demand, then
1) Non blocking read - makes not sense, fair enough I guess, could make it the same as a blocking read.
2) Blocking read - reads from the sensor.
3) Select, meaningless as all reads are done on demand - so I guess you hardwire it to return immediately.
4) open. Nothing special

If you have a counter that is self clocking then data gets pushed into some software structure (probably kfifo)
1) Blocking read, question of semantics to resolve
a) Return when 'some' data is available (like a socket)
b) Return when 'requested amount of data is available'?
2) Non blocking read. Return whatever happens to be available.
3) Select. Semantics to be defined.
a) Some data?
b) Watermark based (default watermark is 0 so any data triggers it)
4) Open. Starts up sampling of configured set - (typically turns on the device, enables interrupt output etc.)

Quoted 5 lines
Quoted 1 line

So some corners to resolve but should all work.

I'm not familiar with the "watermark" terminology. Would you be able to explain it bit more for me. Is this simply a flag that indicates if data has changed from the last time it was checked?

If you have a FIFO, watermark is the fill level at which you indicate you have data. For a HW FIFO this is usually an interrupt at say 10 elements queued up. The software is then expected to drain at least 10 elements.

For software fifo the concept is the same, but you are expecting userspace to drain N elements on each event.

If you are going to deal with remotely high sampling rates you'll need to support this for both software and hardware FIFOs.

Quoted 25 lines
Quoted 25 lines
Quoted 24 lines
Quoted 12 lines
Quoted 5 lines

Moving this selection to a sysfs attribute and dedicating the character device to just data transfer might be a better design. If such a design is chosen, should the selection attribute be human-readable or binary?

Sysfs basically requires things are more or less human readable. So if you go that way I think it needs to be.

Quoted 3 lines

2. How much space should allotted for strings?

Quoted 8 lines
Quoted 5 lines

Each Counter component and extension has a respective size allotted for its data (u8 data is allotted 1 byte, u64 data is allotted 8 bytes, etc.); I have arbitrarily chosen to allot 64 bytes for strings. Is this an apt size, or should string data be allotted more or less space?

I'd go with that being big enough, but try to keep the expose interface such that the size can change it it needs to the in the future.

Following along with the separation of control vs data as discussed above, we could support a more variable size by exposing it through a sysfs attribute (maybe a chrdev_string_size attribute or similar).

Quoted 7 lines
Quoted 3 lines

I'm unconvinced you'd ever want to return a string via the chardev. People are using the chrdev to get efficiency. String based data flows are rarely that!

That's a good point. I don't think there is a situation right now where we need to deliver strings via the character device interface, so I think I'll remove that in v3.

Cool. This all seems to be heading in a sensible direction, but as you say lots still to consider.

Jonathan

Quoted 3 lines

William Breathitt Gray

reviewer
#17 lore raw
In reply to William Breathitt Gray
Quoted 7 lines · William Breathitt Gray

Yielding the following /dev/counter0 memory layout:

+------------+-----------------+------------+-------------------+
| Byte 0     | Byte 1 - Byte 8 | Byte 9     | Byte 10 - Byte 17 |
+------------+-----------------+------------+-------------------+
| Boundary 0 | Count 0         | Boundary 1 | Count 1           |
+------------+-----------------+------------+-------------------+

A potential pitfall with this sort of packing is that some platforms do not support unaligned access, so data would have to be "unpacked" before it could be used.

#18 lore raw
Quoted 9 lines · David Lechner
Quoted 7 lines · William Breathitt Gray

Yielding the following /dev/counter0 memory layout:

+------------+-----------------+------------+-------------------+
| Byte 0     | Byte 1 - Byte 8 | Byte 9     | Byte 10 - Byte 17 |
+------------+-----------------+------------+-------------------+
| Boundary 0 | Count 0         | Boundary 1 | Count 1           |
+------------+-----------------+------------+-------------------+
Quoted 3 lines

A potential pitfall with this sort of packing is that some platforms do not support unaligned access, so data would have to be "unpacked" before it could be used.

Since the user defines the format of this data, they could reorganize it to a more streamline alignment; for example:

# echo "C0 C1 C0E0 C1E0" > counter0/chrdev_format

Yielding the following /dev/counter0 memory layout instead:

+-----------------+------------------+------------+------------+
| Byte 0 - Byte 7 | Byte 8 - Byte 15 | Byte 16    | Byte 17    |
+-----------------+------------------+------------+------------+
| Count 0         | Count 1          | Boundary 0 | Boundary 1 |
+-----------------+------------------+------------+------------+

In the future, we could also define a padding argument to give users more control over the exact offsets:

# echo "C0E0 P7 C0 C1E0 P7 C1" > counter0/chrdev_format

Yielding the following /dev/counter0 memory layout instead:

+------------+-----------------+------------------+------------+
| Byte 0     | Byte 1 - Byte 7 | Byte 8 - Byte 15 | Byte 16    |
+------------+-----------------+------------------+------------+
| Boundary 0 | Padding         | Count 0          | Boundary 1 |
+------------+-----------------+------------------+------------+
+-------------------+-------------------+
| Byte 17 - Byte 23 | Byte 24 - Byte 31 |
+-------------------+-------------------+
| Padding           | Count 1           |
+-------------------+-------------------+

I not sure it's best to introduce padding support with this patchset given how much is already changing, but I don't anticipate packing alignment to be something difficult to support in the future with this interface.

William Breathitt Gray