Introduce the Counter character device interface

Changes in v3:
- Remove string data type; there is no need to handle strings via the chrdev interface
- Reimplement COUNTER_DATA_TYPE_ENUM using struct counter_available
- Refactor Count and Signal sysfs number as index offset rather than id value; this should make the naming and paths more consistent
- Implement chrdev_format sysfs attribute; data format of chrdev is configured via sysfs in order to keep data and configuration separate

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-axes 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, ioctl, or something else?

I believe it's good to have the configuration of the data format separate from the actual data, but I'm not sure if that configuration should be exposed via sysfs or some other interface. What interface would be most fitting for such configuration?

2. Should the format of the chrdev_format attribute be more friendly for a human user?

I implemented a minimalistic syntax for the sake of simplifying the parsing code, but we could increase the verbosity a bit to make it easier for humans to understand the format of the chrdev_format attribute.

For example, "C0 C0E3 S1 C1E2" could instead be "Count 0, Count 0 Ceiling, Signal 1, Count 1 Floor"; because extension names are required to be unique, it possible to refer to the extensions directly by their names (i.e. "ceiling" and "floor") rather than their index offset. The downside to this is of course the need for a more complex parser.

3. How should alignment of the character device data be handled?

We might not need to handle this just yet, but I can envision situations where it would be nice for user to specify the alignment of the data in order to match the packing of a structure in a userspace application. How we specify the alignment will naturally depend on the syntax we decide for the chrdev_format attribute. I can see a "padding" option as a possible solution, but it'll be nice to get some feedback if there are any other ideas.

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/ABI/testing/sysfs-bus-counter  |   31 +
 Documentation/driver-api/generic-counter.rst |  280 +++-
 MAINTAINERS                                  |    3 +-
 drivers/counter/104-quad-8.c                 |  474 +++---
 drivers/counter/Makefile                     |    1 +
 drivers/counter/counter-chrdev.c             |  612 +++++++
 drivers/counter/counter-chrdev.h             |   23 +
 drivers/counter/counter-common.h             |   15 +
 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                |   59 +-
 drivers/counter/stm32-lptimer-cnt.c          |  161 +-
 drivers/counter/stm32-timer-cnt.c            |  139 +-
 drivers/counter/ti-eqep.c                    |  211 +--
 include/linux/counter.h                      |  628 ++++----
 include/linux/counter_enum.h                 |   45 -
 include/uapi/linux/counter-types.h           |   34 +
 19 files changed, 2748 insertions(+), 2546 deletions(-)
 create mode 100644 drivers/counter/counter-chrdev.c
 create mode 100644 drivers/counter/counter-chrdev.h
 create mode 100644 drivers/counter/counter-common.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

2.26.2

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, 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 is 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, 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 simple 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.

---
 MAINTAINERS                         |    2 +-
 drivers/counter/104-quad-8.c        |  474 ++++-----
 drivers/counter/Makefile            |    1 +
 drivers/counter/counter-common.h    |   15 +
 drivers/counter/counter-core.c      |  157 +++
 drivers/counter/counter-sysfs.c     |  851 +++++++++++++++
 drivers/counter/counter-sysfs.h     |   14 +
 drivers/counter/counter.c           | 1496 ---------------------------
 drivers/counter/ftm-quaddec.c       |   59 +-
 drivers/counter/stm32-lptimer-cnt.c |  161 +--
 drivers/counter/stm32-timer-cnt.c   |  139 +--
 drivers/counter/ti-eqep.c           |  211 ++--
 include/linux/counter.h             |  618 +++++------
 include/linux/counter_enum.h        |   45 -
 include/uapi/linux/counter-types.h  |   34 +
 15 files changed, 1799 insertions(+), 2478 deletions(-)
 create mode 100644 drivers/counter/counter-common.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

index 510fa7f7c756..7ea12db794be 100644
@@ -4413,7 +4413,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]>

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

new file mode 100644
index 000000000000..a3d0c8e53485
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Counter subsystem common structures
+ * Copyright (C) 2020 William Breathitt Gray
+ */
+#ifndef _COUNTER_COMMON_H_
+#define _COUNTER_COMMON_H_
+
+enum counter_owner_type {
+	COUNTER_OWNER_TYPE_DEVICE,
+	COUNTER_OWNER_TYPE_SIGNAL,
+	COUNTER_OWNER_TYPE_COUNT,
+};
+
+#endif /* _COUNTER_COMMON_H_ */

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_ */

new file mode 100644
index 000000000000..78cdfefea25a

2.26.2

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

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 | 216 +++++++++++++------
 1 file changed, 150 insertions(+), 66 deletions(-)

index e622f8f6e56a..8aaa6cd37fd4 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,59 @@ 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 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,
+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 simple 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 +347,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`, 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 is 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.

2.26.2

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

A /sys/bus/counter/devices/counterX/chrdev_format sysfs attribute is introduced to expose the character device data format:

* 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 |
  +-----------------+------------------+----------+----------+

The number of bytes allotted for each component or extension is determined by its respective data type: u8 will have 1 byte allotted, u64 will have 8 bytes allotted, etc.

A high-level view of how a count value is passed down from a counter driver is 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 | 612 +++++++++++++++++++++++++++++++
 drivers/counter/counter-chrdev.h |  23 ++
 drivers/counter/counter-core.c   |  34 +-
 drivers/counter/counter-sysfs.c  |  38 +-
 include/linux/counter.h          |  12 +-
 7 files changed, 714 insertions(+), 8 deletions(-)
 create mode 100644 drivers/counter/counter-chrdev.c
 create mode 100644 drivers/counter/counter-chrdev.h

index 7ea12db794be..b4ed407a13f8 100644
@@ -4413,6 +4413,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

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

new file mode 100644
index 000000000000..73af6d236bc8
@@ -0,0 +1,23 @@
+/* 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/device.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);
+
+ssize_t counter_chrdev_format_show(struct device *dev,
+				   struct device_attribute *attr, char *buf);
+ssize_t counter_chrdev_format_store(struct device *dev,
+				    struct device_attribute *attr,
+				    const char *buf, size_t len);
+
+#endif /* _COUNTER_CHRDEV_H_ */

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);
 }
 

index ca69e9d4e833..1279bd8a8af1 100644
@@ -15,6 +15,7 @@
 #include <linux/types.h>
 
 #include "counter-common.h"
+#include "counter-chrdev.h"
 #include "counter-sysfs.h"
 
 struct counter_attribute {

@@ -658,11 +659,29 @@ static int counter_num_counts_read(struct counter_device *counter, u8 *val)
 	return 0;
 }
 
-static struct counter_data counter_num_signals_data =
-	COUNTER_DATA_DEVICE_U8("num_signals", counter_num_signals_read, NULL);
+static int counter_format_attr_create(struct counter_attribute_group *group,
+				      struct counter_device *const counter)
+{
+	struct counter_attribute *counter_attr;
+	struct device_attribute *dev_attr;
 
-static struct counter_data counter_num_counts_data =
-	COUNTER_DATA_DEVICE_U8("num_counts", counter_num_counts_read, NULL);
+	/* 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 device attribute */
+	dev_attr = &counter_attr->dev_attr;
+	sysfs_attr_init(&dev_attr->attr);
+	dev_attr->attr.name = "chrdev_format";
+	dev_attr->attr.mode = 0644;
+	dev_attr->show = counter_chrdev_format_show;
+	dev_attr->store = counter_chrdev_format_store;
+
+	return 0;
+}
 
 static void counter_groups_list_free(struct counter_device *const counter)
 {

@@ -685,6 +704,12 @@ static void counter_groups_list_free(struct counter_device *const counter)
 	kfree(counter->groups_list);
 }
 
+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 int counter_device_register(struct counter_attribute_group *group,
 				   struct counter_device *const counter)
 {

@@ -732,6 +757,11 @@ static int counter_device_register(struct counter_attribute_group *group,
 			goto err_free_groups_list;
 	}
 
+	/* Create chrdev_format attribute */
+	err = counter_format_attr_create(group, counter);
+	if (err)
+		goto err_free_groups_list;
+
 	return 0;
 
 err_free_groups_list:

index 3eb567a5884b..88cc4f32dc2d 100644
@@ -6,9 +6,11 @@
 #ifndef _COUNTER_H_
 #define _COUNTER_H_
 
+#include <linux/cdev.h>
 #include <linux/device.h>
 #include <linux/kernel.h>
 #include <linux/list.h>
+#include <linux/mutex.h>
 #include <linux/types.h>
 #include <uapi/linux/counter-types.h>
 

@@ -21,8 +23,8 @@ enum counter_data_type {
 	COUNTER_DATA_TYPE_U8,
 	COUNTER_DATA_TYPE_U64,
 	COUNTER_DATA_TYPE_BOOL,
-	COUNTER_DATA_TYPE_COUNT_FUNCTION,
 	COUNTER_DATA_TYPE_SIGNAL,
+	COUNTER_DATA_TYPE_COUNT_FUNCTION,
 	COUNTER_DATA_TYPE_SYNAPSE_ACTION,
 	COUNTER_DATA_TYPE_ENUM,
 	COUNTER_DATA_TYPE_COUNT_DIRECTION,

@@ -166,6 +168,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
+ * @control_list:	Counter character device selected controls
+ * @control_lock:	Mutex for 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

@@ -204,6 +209,11 @@ struct counter_device {
 
 	int id;
 	struct device dev;
+	struct cdev chrdev;
+
+	struct list_head control_list;
+	struct mutex control_lock;
+
 	struct list_head dynamic_names_list;
 	struct counter_attribute_group *groups_list;
 	size_t num_groups;

2.26.2

Instead of the proposed character device, I would really rather have one that gives past events instead of the current state.

I have thought about some of the suggestions from previous version of this patch series and I'm starting to think something similar to the input and gpio subsystems would work fairly well.

There would have to be a fixed size event data structure:

struct counter_event {
	/** Best approximation of when event occurred in nanoseconds. */
	__u64 timestamp;
	/**
	 * Description of the synapse that triggered the event and the
	 * signal/counter that the value represents.
	 */
	__u64 descriptor;
	/** The signal/counter value recorded when the synapse fired. */
	__u64 value;
};

The descriptor field would actually probably be a union of __u64 and a struct with its own fields to describe the synapse and signal or count.

If a synapse involves more than one signal or count, then there would be multiple events with identical timestamps.

Userspace programs should be able to enable only the events/synapses they are interested in and then the poll() the character device to wait for events in an efficient way instead of having to constantly read - which could still miss events.

---

Real world use case - measuring the speed of a motor:

At low speeds it is more accurate to measure the time difference between count events. In this case we would want events from two synapses. One triggered by the rising and falling edges of signal A and one triggered by the direction signal. The magnitude of the speed is calculated by taking the difference in timestamps between signal A events and the +/- sign is determined by the direction signal.

At high speeds a different configuration is needed. Assuming the counter has a timer clock signal a synapse would be configured to fire every 10 or 20 milliseconds. This would trigger an event that contains the count. The speed is calculated as the difference in counts divided by the fixed time interval.

Some applications may need to do both and be able to change the configuration at runtime. It may start out in the low speed configuration, but as the speed increases, events triggered by the change in count will need to be disabled to prevent being overwhelmed with too many count events. But if the speed drops low again, the count events will need to be turned back on.

---

Regarding the implementation, the character device can be backed by a kfifo. Interrupts from the counter hardware push events to the kfifo and reading from the character device drains the kfifo.

drivers/gpio/gpiolib.c could be a good example to follow.

If we only want to allow one consumer to open the chardev at a time, then enabling/disabling events via sysfs would probably be fine since we are already sort of doing that anyway to enable/disable counters. But if we need to allow multiple consumers per chardev that would each want different events, then configuring via ioctl would be required so that per-file descriptor configuration could be done (each call to open() would create a new kfifo and ioctl would configure what gets pushed to that kfifo).

Perhaps structuring the interface around events would be a good approach afterall. The way I see it is that we have two types of use cases to
support: those that are sensitive to latency and those that are not. Use cases where latency is not a concern can simply use the existing sysfs interface, so really all we care about in this discussion are the latency-sensitive use cases.

If a user cares about latency, I think it's because their use case involves some sort of realtime deadline. In this kind of situation, I suspect they will not simply be checking the current count in a loop, but rather design their system around interrupts from the counter device to notify their application when some deadline or condition has been met.

Because a latency-conscious user would be waiting on events, the Counter character device interface should be structured around configuring and receiving events with respective data. The user should be able to choose which events they want to receive, as well as the particular data they want when that event occurs.

Synapses simply indicate a change in a Count value; every signal Count value change is not necessarily interesting, so Counter events would likely be defined separately from Synapses. Regardless, users would need the ability to choose the particular data they want associated with a particular event.

For example, in the dual-axes positioning table scenario, a user application would likely want to know the exact X and Y position at the time of a given event -- that means an event should provide two Count values (and possibly associated device flags) when it occurs. I'm not sure yet how the struct counter_event should be defined in order to support this; we will need to indicate the format of data as well as provide the data itself. Perhaps, we can handle this by providing an unique id field so that only a single datum (e.g. a single count value) is provided via the value field, but subsequent struct counter_event items share the same id so that the user knows that a particular datum is part of a larger group of data for a specific event.

William Breathitt Gray

Ah, ok. I understand now that synapse is the wrong term for things like the change in direction event or error events.

The timestamp could act as the "id" to correlate multiple values of a single event.

Okay, I see how that can work. So the /dev/counterX character nodes would return a stream of data structures that look something like this:

struct counter_event {
	/**
	 * Best approximation of when event occurred in nanoseconds.
	 * Same timestamp value indicates data is part of same event.
	 */
	struct timeval time;
	/**
	 * Type of event that triggered. This would correlate with the
	 * IRQ set up for the device.
	 */
	__u16 type;
	/**
	 * Type of data represented by the value member. This enables
	 * the user to extract the right datatype from the value field.
	 */
	__u16 code;
	/** The value recorded when the event fired. */
	__u64 value;
};

In fact, this data structure looks a lot like struct input_event; would it make sense to use that for this? I suppose we can't because we need to support 64-bit value for our use cases.

Userspace also requires a way to enable the events and configure them to report the data it wants. So perhaps the following sysfs attributes would accomplish such:

* /sys/bus/devices/counterX/eventY_enable:
Users can enable/disable event Y.
* /sys/bus/devices/counterX/eventY_config:
Data to get when event Y is triggered (e.g. Counts, extensions, etc.).

Here's another concern for latency-sensitive applications: should we handle writing data to the devices? While we have real-life examples of latency-sensitive read operations, I'm not sure if a user will ever need to write to a counter device within some realtime critical deadline -- I think write operations are primarily done for the purpose of configuring the device for operation rather than during it. So perhaps we don't need to worry about this use case because users can write data via the existing sysfs interface.

William Breathitt Gray

Yes, since counter is its own subsystem, it makes sense to have its own data types.

This is one of the questions I had too that I don't have a good answer to.

If we want to allow the use case of multiple "consumers" for a single chardev where each consumer wants different events (e.g program X opens /dev/counter0 and wants only events A and B while program Y opens the same /dev/counter0 and wants only events A and C) then it would make sense to use an ioctl for configuration of events so that each open file descriptor could be configured differently.

But if we only want to allow one user of a counter, then configuring via sysfs as you have suggested is probably fine.

I think I might make sense to us an ioctl in any case though if we are going to use the same code values to configure the event.

Agreed.

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

---
 Documentation/ABI/testing/sysfs-bus-counter  |  31 +++++
 Documentation/driver-api/generic-counter.rst | 132 ++++++++++++++-----
 2 files changed, 127 insertions(+), 36 deletions(-)

index 566bd99fe0a5..8533a8732544 100644
@@ -193,6 +193,37 @@ Description:
 		both edges:
 			Any state transition.
 
+What:		/sys/bus/counter/devices/counterX/chrdev_format
+KernelVersion:	5.9
+Contact:	[email protected]
+Description:
+		Data format of the respective character device node of the
+		Counter. Reading this attribute returns the current data format
+		of the respective character device node; writing to this
+		attribute sets the current data format of the respective
+		character device node. This attribute interfaces via the
+		following format:
+
+		Components/extensions are specified by a character identifier
+		and an index offset; whitespace serves as delimiters. The
+		following character identifiers are supported:
+
+		C: Count
+		S: Signal
+		E: Extension
+		A: Synapse Action
+		F: Count Function
+
+		Count/Signal extensions may be specified by first specifying the
+		respective owning component then the desired extension
+		immediately following without delimiting whitespace; Synapse
+		Action and Count Function are specified in a similar manner.
+
+		For example, "C4 C2E6 C0F S7E1 C3A4 S5" would specify the
+		following data format: Count 4, Count 2's Extension 6, Count 0's
+		Count Function, Signal 7's Extension 1, Count 3's Synapse Action
+		4, Signal 5.
+
 What:		/sys/bus/counter/devices/counterX/name
 KernelVersion:	5.2
 Contact:	[email protected]

2.26.2