Re: [PATCH v3 0/3] counter: add GPIO-based quadrature encoder driver

[William Breathitt Gray]

On Fri, May 01, 2026 at 10:07:46PM +0200, Wadim Mueller wrote:
> This series adds a new counter subsystem driver that implements
> quadrature encoder position tracking using plain GPIO pins with
> edge-triggered interrupts.
> 
> The driver is intended for low to medium speed rotary encoders where
> hardware counter peripherals (eQEP, FTM, etc.) are unavailable or
> already in use. It targets the same use-cases as interrupt-cnt.c but
> provides full quadrature decoding instead of simple pulse counting.
> 
> Features:
>   - X1, X2, X4 quadrature decoding and pulse-direction mode
>   - Optional index signal for zero-reset
>   - Configurable ceiling (position clamping)
>   - Standard counter subsystem sysfs + chrdev interface
>   - Enable/disable via sysfs with IRQ gating
> 
> Tested on TI AM64x (Cortex-A53) with a motor-driven rotary encoder
> at up to 2 kHz quadrature edge rate.

Hello Wadim,

This is certainly a neat idea! :-) Several times I have wished for a
convenient way to just plug in a quadrature encoder to the GPIO lines of
my system and immediately start reading position data. However, I want
to be sure this makes sense as a Counter subsystem driver before I
proceed with a full review.

If I understand correctly from my brief overview, the core approach in
the gpio-quadrature-encoder module is to take two GPIO lines (A and B),
setup interrupt service routines for them, compare their GPIO values on
each interrupt, and respectively update a persistent count based on the
quadrature relationship.

>From that description, I don't immediately see a need for this to occur
in kernelspace. Couldn't the same design be accomplished effectively in
userspace via the libgpiod API[^1]? I believe that library allows you
to watch for GPIO edge events and request GPIO line values. (I'm CCing
the GPIO subsystem maintainers in case I'm missing something obvious
here.)

Although the Counter subsystem does provide an established user
interface for counter devices, I'm not sure that alone justifies a
kernel driver when the same can be achieved by an equivalent userspace
application. If you can argue for why this should exist in the kernel,
I'll feel more comfortable with accepting the Counter subsystem as the
right home for the gpio-quadrature-encoder module.

> Changes in v3:
>   - Pick up Acked-by: Conor Dooley on the DT binding patch.
>   - No code changes.

As an aside, you don't need to resend the patchset if there are no code
changes, I'll make sure to pick up the tags in the mail threads when the
patches are accepted. This helps reduce the amount the messages we need
to parse on the mailing list.

Thanks,

William Breathitt Gray

[^1] https://libgpiod.readthedocs.io/