From: Jonathan Cameron <jic23@kernel.org>
To: William Breathitt Gray <vilhelm.gray@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org,
patrick.havelange@essensium.com, fabrice.gasnier@st.com,
mcoquelin.stm32@gmail.com, alexandre.torgue@st.com,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
benjamin.gaignard@linaro.org, david@lechnology.com
Subject: Re: [PATCH v5 0/3] Simplify count_read/count_write/signal_read
Date: Sat, 12 Oct 2019 15:00:12 +0100 [thread overview]
Message-ID: <20191012150012.5e3399f1@archlinux> (raw)
In-Reply-To: <cover.1570391994.git.vilhelm.gray@gmail.com>
Hi William
What's the status on these? If you are happy that reviews and
testing is complete enough, do you want me to take them after
I pick up the eqep driver (hopefully shortly dependent on
the pull request Greg has from me being fine).
Thanks,
Jonathan
On Sun, 6 Oct 2019 16:03:08 -0400
William Breathitt Gray <vilhelm.gray@gmail.com> wrote:
> Changes in v5:
> - Add changes and additions to generic-counter.rst to clarify theory
> and use of the Generic Counter interface
> - Fix typo in counter.h action_get description comment
>
> The changes in this patchset will not affect the userspace interface.
> Rather, these changes are intended to simplify the kernelspace Counter
> callbacks for counter device driver authors.
>
> The following main changes are proposed:
>
> * Retire the opaque counter_count_read_value/counter_count_write_value
> structures and simply represent count data as an unsigned integer.
>
> * Retire the opaque counter_signal_read_value structure and represent
> Signal data as a counter_signal_value enum.
>
> These changes should reduce some complexity and code in the use and
> implementation of the count_read, count_write, and signal_read
> callbacks.
>
> The opaque structures for Count data and Signal data were introduced
> originally in anticipation of supporting various representations of
> counter data (e.g. arbitrary-precision tallies, floating-point spherical
> coordinate positions, etc). However, with the counter device drivers
> that have appeared, it's become apparent that utilizing opaque
> structures in kernelspace is not the best approach to take.
>
> I believe it is best to let userspace applications decide how to
> interpret the count data they receive. There are a couple of reasons why
> it would be good to do so:
>
> * Users use their devices in unexpected ways.
>
> For example, a quadrature encoder counter device is typically used to
> keep track of the position of a motor, but a user could set the device
> in a pulse-direction mode and instead use it to count sporadic rising
> edges from an arbitrary signal line unrelated to positioning. Users
> should have the freedom to decide what their data represents.
>
> * Most counter devices represent data as unsigned integers anyway.
>
> For example, whether the device is a tally counter or position
> counter, the count data is represented to the user as an unsigned
> integer value. So specifying that one device is representing tallies
> while the other specifies positions does not provide much utility from
> an interface perspective.
>
> For these reasons, the count_read and count_write callbacks have been
> redefined to pass count data directly as unsigned long instead of passed
> via opaque structures:
>
> count_read(struct counter_device *counter,
> struct counter_count *count, unsigned long *val);
> count_write(struct counter_device *counter,
> struct counter_count *count, unsigned long val);
>
> Similarly, the signal_read is redefined to pass Signal data directly as
> a counter_signal_value enum instead of via an opaque structure:
>
> signal_read(struct counter_device *counter,
> struct counter_signal *signal,
> enum counter_signal_value *val);
>
> The counter_signal_value enum is simply the counter_signal_level enum
> redefined to remove the references to the Signal data "level" data type.
>
> William Breathitt Gray (3):
> counter: Simplify the count_read and count_write callbacks
> docs: driver-api: generic-counter: Update Count and Signal data types
> counter: Fix typo in action_get description
>
> Documentation/driver-api/generic-counter.rst | 162 +++++++++++--------
> drivers/counter/104-quad-8.c | 33 ++--
> drivers/counter/counter.c | 101 ++----------
> drivers/counter/ftm-quaddec.c | 14 +-
> drivers/counter/stm32-lptimer-cnt.c | 5 +-
> drivers/counter/stm32-timer-cnt.c | 17 +-
> drivers/counter/ti-eqep.c | 19 +--
> include/linux/counter.h | 76 ++-------
> 8 files changed, 144 insertions(+), 283 deletions(-)
>
>
> base-commit: 0c3aa63a842d84990bd02622f2fa50d2bd33c652
> prerequisite-patch-id: ebe284609b3db8d4130ea2915f7f7b185c743a70
> prerequisite-patch-id: cbe857759f10d875690df125d18bc04f585ac7c9
> prerequisite-patch-id: 21f2660dc88627387ee4666d08044c63dd961dae
next prev parent reply other threads:[~2019-10-12 14:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-06 20:03 [PATCH v5 0/3] Simplify count_read/count_write/signal_read William Breathitt Gray
2019-10-06 20:03 ` [PATCH v5 1/3] counter: Simplify the count_read and count_write callbacks William Breathitt Gray
2019-10-06 20:03 ` [PATCH v5 2/3] docs: driver-api: generic-counter: Update Count and Signal data types William Breathitt Gray
2019-10-06 20:03 ` [PATCH v5 3/3] counter: Fix typo in action_get description William Breathitt Gray
2019-10-12 14:00 ` Jonathan Cameron [this message]
2019-10-12 14:51 ` [PATCH v5 0/3] Simplify count_read/count_write/signal_read William Breathitt Gray
2019-10-17 21:41 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191012150012.5e3399f1@archlinux \
--to=jic23@kernel.org \
--cc=alexandre.torgue@st.com \
--cc=benjamin.gaignard@linaro.org \
--cc=david@lechnology.com \
--cc=fabrice.gasnier@st.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=patrick.havelange@essensium.com \
--cc=vilhelm.gray@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).