On Mon, Apr 06, 2020 at 05:58:03PM +0200, Kamel Bouhara wrote: > Hello everyone, > > This series introduce a basic inkernel API for the counter subsystem and > add a new rotary encoder driver that use a counter interface instead of > the GPIO existing one. > > See commit log in 0001-counter-add-an-inkernel-API.patch for further > details. > > Kamel Bouhara (3): > counter: add an inkernel API > Input: rotary-encoder-counter: add DT bindings > Input: add a rotary encoders based on counter devices > > .../input/rotary-encoder-counter.yaml | 67 ++++++ > drivers/counter/counter.c | 213 ++++++++++++++++++ > drivers/input/misc/Kconfig | 9 + > drivers/input/misc/Makefile | 1 + > drivers/input/misc/rotary_encoder_counter.c | 152 +++++++++++++ > include/linux/counter.h | 27 +++ > 6 files changed, 469 insertions(+) > create mode 100644 Documentation/devicetree/bindings/input/rotary-encoder-counter.yaml > create mode 100644 drivers/input/misc/rotary_encoder_counter.c > > -- > 2.25.0 Hello Kamel, I'm not inherently opposed to adding an in-kernel API for the Counter subsystem, but I'm not sure yet if it's necessary for this particular situation. Is the purpose of this driver to allow users to poll on the rotary encoder position value? If so, perhaps instead of an in-kernel API, the polling functionality should be added as part of the Counter subsystem; I can see this being a useful feature for many counter devices, and it'll keep the code contained to a single subsystem. By the way, I'm going to be submitting a major update to the Counter subsystem code in the next couple weeks that isolates the sysfs code from the rest of the subsystem -- it'll likely affect the interface and code here -- so I'll probably wait to decide for certain until that patch lands; I anticipate it making things easier for you here after it's merged. For now, I want to get a better high-level understanding about how users would interact with this driver to use the device (input_setup_polling is a new call for me). That should help me understand whether an in-kernel API is the best choice here. William Breathitt Gray
Attachment:
signature.asc
Description: PGP signature
