Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Sat, 11 Apr 2020 13:22:59 -0400
From:   William Breathitt Gray <vilhelm.gray@gmail.com>
To:     Kamel Bouhara <kamel.bouhara@bootlin.com>
Cc:     Dmitry Torokhov <dmitry.torokhov@gmail.com>,
        Rob Herring <robh+dt@kernel.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Nicolas Ferre <nicolas.ferre@microchip.com>,
        Alexandre Belloni <alexandre.belloni@bootlin.com>,
        Ludovic Desroches <ludovic.desroches@microchip.com>,
        linux-arm-kernel@lists.infradead.org,
        Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
        linux-input@vger.kernel.org, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org
Subject: Re: [PATCH 0/3] Introduce a counter inkernel API
Message-ID: <20200411172259.GB95806@icarus>
References: <20200406155806.1295169-1-kamel.bouhara@bootlin.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="eAbsdosE1cNLO4uF"
Content-Disposition: inline
In-Reply-To: <20200406155806.1295169-1-kamel.bouhara@bootlin.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


--eAbsdosE1cNLO4uF
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 06, 2020 at 05:58:03PM +0200, Kamel Bouhara wrote:
> Hello everyone,
>=20
> 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.
>=20
> See commit log in 0001-counter-add-an-inkernel-API.patch for further
> details.
>=20
> Kamel Bouhara (3):
>   counter: add an inkernel API
>   Input: rotary-encoder-counter: add DT bindings
>   Input: add a rotary encoders based on counter devices
>=20
>  .../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-encode=
r-counter.yaml
>  create mode 100644 drivers/input/misc/rotary_encoder_counter.c
>=20
> --
> 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
=66rom 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

--eAbsdosE1cNLO4uF
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEk5I4PDJ2w1cDf/bghvpINdm7VJIFAl6R/OYACgkQhvpINdm7
VJJULA//cJf3iV5J+NsneoTVZ26SG+cQdVz4UFAUmrQ7lKokM+KB49/vO6JjzUXa
kXebfHwgqvjcnCwiyEmHqvkVR5QDH1Qo9uryOrBzY2Uz/HGmUI7DB8OZXTa0J6Vf
Udy0T/jiwC7iTy2IGKt0svVAauesGdFA052BHCt+1fbarvKjr+ZBwDLQjPEy7rOU
NYcpVoOH4bPtQbgvDLGp01dmw1nvzSmjxrCHF0ARy8funxA7Bng69jQcGWiaWRjm
PAyqb8CBIfQ4clIrEwGh5Hhj/oYUFMIf8pB0fFM5mZ39ISqwKF9nedQZ6hYmvgXH
xNRDOWP63UksmBVXp1vtZjiHUdrH07sF+cRRgrwQkn3bkJfR8sQAA2oRDCBieMA3
hRBWjmw31IGzmI0HtzYjsFLvFUuK1Yoe7F+EGdvdrVmRQmtom3pzZ8AcDdpB6h8R
Hr/v9jKXPc54UKOe66rKhMe7aTx4H/7nG3kxnZSzNKWFhwV+dCjy8D1X9HxEKoZp
WRAfsClBsNGzJBqVSO3ryFrIzRuJuYLtGNbKhBbTJvc0nRpJAuJbSnw0ZRf9kGZg
KJ0nNPdweo26YbxYkT2hyNJantJCYc9GmyLy+FubdgF3skX47nnIusRtpoBYe/hd
AZ/ERtySq9+Tv+dQzk8xrWxAYGdoIVCdub93jaSnWAYoyKZJs7g=
=Rx8J
-----END PGP SIGNATURE-----

--eAbsdosE1cNLO4uF--