All of lore.kernel.org
 help / color / mirror / Atom feed
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


WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Cameron <jic23@kernel.org>
To: William Breathitt Gray <vilhelm.gray@gmail.com>
Cc: benjamin.gaignard@linaro.org, alexandre.torgue@st.com,
	linux-iio@vger.kernel.org, patrick.havelange@essensium.com,
	linux-kernel@vger.kernel.org, mcoquelin.stm32@gmail.com,
	fabrice.gasnier@st.com, linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2019-10-12 14:00 UTC|newest]

Thread overview: 14+ 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 ` 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   ` 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   ` William Breathitt Gray
2019-10-06 20:03 ` [PATCH v5 3/3] counter: Fix typo in action_get description William Breathitt Gray
2019-10-06 20:03   ` William Breathitt Gray
2019-10-12 14:00 ` Jonathan Cameron [this message]
2019-10-12 14:00   ` [PATCH v5 0/3] Simplify count_read/count_write/signal_read Jonathan Cameron
2019-10-12 14:51   ` William Breathitt Gray
2019-10-12 14:51     ` William Breathitt Gray
2019-10-17 21:41     ` Jonathan Cameron
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.