Linux-IIO Archive on lore.kernel.org
 help / color / Atom feed
From: William Breathitt Gray <vilhelm.gray@gmail.com>
To: David Lechner <david@lechnology.com>
Cc: jic23@kernel.org, kamel.bouhara@bootlin.com,
	gwendal@chromium.org, alexandre.belloni@bootlin.com,
	linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org, syednwaris@gmail.com,
	patrick.havelange@essensium.com, fabrice.gasnier@st.com,
	mcoquelin.stm32@gmail.com, alexandre.torgue@st.com
Subject: Re: [PATCH v5 0/5] Introduce the Counter character device interface
Date: Sun, 18 Oct 2020 10:14:01 -0400
Message-ID: <20201018141401.GA231549@shinobu> (raw)
In-Reply-To: <caeeb0b2-6b66-b623-98e3-acdc261ec20e@lechnology.com>


[-- Attachment #1: Type: text/plain, Size: 2571 bytes --]

On Mon, Oct 12, 2020 at 07:35:11PM -0500, David Lechner wrote:
> On 9/26/20 9:18 PM, William Breathitt Gray wrote:
> > The following are some questions I have about this patchset:
> > 
> > 1. Should standard Counter component data types be defined as u8 or u32?
> > 
> >     Many standard Counter component types such COUNTER_COMP_SIGNAL_LEVEL
> >     have standard values defined (e.g. COUNTER_SIGNAL_LEVEL_LOW and
> >     COUNTER_SIGNAL_LEVEL_HIGH). These values are currently handled by the
> >     Counter subsystem code as u8 data types.
> > 
> >     If u32 is used for these values instead, C enum structures could be
> >     used by driver authors to implicit cast these values via the driver
> >     callback parameters; userspace would still use u32 with no issue.
> > 
> >     In theory this can work because GCC will treat enums are having a
> >     32-bit size; but I worry about the possibility of build targets that
> >     have -fshort-enums enabled, resulting in enums having a size less
> >     than 32 bits. Would this be a problem?
> 
> We shouldn't have to worry about userspace programs using -fshort-enums
> since that would break all kernel interfaces that use enums, not just
> these - so no one should be using that compiler flag.
> 
> So I am in favor of using strongly typed enums with u32 as the
> "generic" enum member type.

That reasoning pacifies my worries. I'll test out strongly typed enums
in the next revision of this patchset.

> > 
> > 2. Should I have reserved members in the userspace structures?
> > 
> >     The structures in include/uapi/linux/counter.h are available to
> >     userspace applications. Should I reserve space in these structures
> >     for future additions and usage? Will endianess and packing be a
> >     concern here?
> > 
> Since there doesn't seem to be a large number of counter devices
> this probably isn't critical. Are there any aspects of counter
> devices in general that couldn't be described with the proposed
> structures? For example, could there be components more than two
> levels deep (i.e. it would need id, parent id and grandparent id
> to describe fully)?

I can't think of any devices that would require more depth, so we
probably don't need any additional members added to the userspace
structures. The current structure should be flexible enough for future
expansion, and any additional functionality we come across can be
handled by implementing new extension types as we have for the sysfs
attributes.

William Breathitt Gray

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply index

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-27  2:18 William Breathitt Gray
2020-09-27  2:18 ` [PATCH v5 2/5] docs: counter: Update to reflect sysfs internalization William Breathitt Gray
2020-09-27  2:18 ` [PATCH v5 3/5] counter: Add character device interface William Breathitt Gray
2020-10-14  1:40   ` David Lechner
2020-10-18 16:49     ` William Breathitt Gray
2020-10-20 15:53       ` David Lechner
2020-10-25 12:55         ` William Breathitt Gray
2020-10-25 16:36           ` David Lechner
2020-10-14 17:43   ` David Lechner
2020-10-14 19:05     ` William Breathitt Gray
2020-10-14 22:32       ` David Lechner
2020-10-14 22:40   ` David Lechner
2020-10-18 16:58     ` William Breathitt Gray
2020-10-20 16:06       ` David Lechner
2020-10-25 13:18         ` William Breathitt Gray
2020-10-25 16:34           ` David Lechner
2020-10-25 17:53             ` William Breathitt Gray
2020-09-27  2:18 ` [PATCH v5 4/5] docs: counter: Document " William Breathitt Gray
2020-10-08  8:09   ` Pavel Machek
2020-10-08 12:28     ` William Breathitt Gray
2020-10-12 17:04       ` David Lechner
2020-10-13 18:58         ` William Breathitt Gray
2020-10-13 19:08           ` David Lechner
2020-10-13 19:27             ` William Breathitt Gray
2020-09-27  2:18 ` [PATCH v5 5/5] counter: 104-quad-8: Add IRQ support for the ACCES 104-QUAD-8 William Breathitt Gray
2020-10-14  0:13   ` David Lechner
2020-10-18 14:50     ` William Breathitt Gray
2020-10-13  0:35 ` [PATCH v5 0/5] Introduce the Counter character device interface David Lechner
2020-10-18 14:14   ` William Breathitt Gray [this message]
     [not found] ` <e38f6dc3a08bf2510034334262776a6ed1df8b89.1601170670.git.vilhelm.gray@gmail.com>
2020-10-13  2:15   ` [PATCH v5 1/5] counter: Internalize sysfs interface code David Lechner
2020-10-18 14:49     ` William Breathitt Gray
2020-10-20 15:38       ` David Lechner
2020-10-23 13:12         ` William Breathitt Gray
2020-10-15  1:38   ` David Lechner
2020-10-18 17:00     ` William Breathitt Gray

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=20201018141401.GA231549@shinobu \
    --to=vilhelm.gray@gmail.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=alexandre.torgue@st.com \
    --cc=david@lechnology.com \
    --cc=fabrice.gasnier@st.com \
    --cc=gwendal@chromium.org \
    --cc=jic23@kernel.org \
    --cc=kamel.bouhara@bootlin.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=syednwaris@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

Linux-IIO Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-iio/0 linux-iio/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-iio linux-iio/ https://lore.kernel.org/linux-iio \
		linux-iio@vger.kernel.org
	public-inbox-index linux-iio

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-iio


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git