From: William Breathitt Gray <wbg@kernel.org>
To: "Csókás Bence" <csokas.bence@prolan.hu>
Cc: linux-arm-kernel@lists.infradead.org, linux-iio@vger.kernel.org,
linux-kernel@vger.kernel.org,
Kamel Bouhara <kamel.bouhara@bootlin.com>
Subject: Re: [PATCH v6 3/3] counter: microchip-tcb-capture: Add capture extensions for registers RA/RB
Date: Tue, 4 Mar 2025 19:21:35 +0900 [thread overview]
Message-ID: <Z8bULwq70CAAQRSe@ishi> (raw)
In-Reply-To: <1604dce5-7be6-4a95-a51c-0c760a6c9a76@prolan.hu>
[-- Attachment #1: Type: text/plain, Size: 1186 bytes --]
On Tue, Mar 04, 2025 at 11:03:17AM +0100, Csókás Bence wrote:
> On 2025. 03. 04. 8:47, William Breathitt Gray wrote:
> > One final comment: is RA/RB the best way to differentiate these? One of
> > the benefits of abstraction layers is that users won't need to be
> > concerned about the hardware details, and naming the capture values
> > after their respective general register hardware names feels somewhat
> > antithetic to that end.
> >
> > I imagine there are better ways to refer to these that would communicate
> > their relationship better, such as "primary capture" and "secondary
> > capture". However at that point capture0 and capture1 would seem
> > obvious enough, in which case you might not even need to expose these to
> > userspace at all.
>
> Hmm. Well, RA and RB is what it says in the datasheet, and since we don't do
> much processing on their value, I'd say we're still closely coupled to the
> hardware. So, if one wants to understand what they do, they will have to
> read the datasheet anyways in which case I think it's best to be consistent
> with it naming-wise.
All right, let's keep it as RA and RA then.
William Breathitt Gray
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
prev parent reply other threads:[~2025-03-04 10:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-27 14:40 [PATCH v6 0/3] microchip-tcb-capture: Add Capture, Compare, Overflow etc. events Bence Csókás
2025-02-27 14:40 ` [PATCH v6 1/3] include: uapi: counter: Add microchip-tcb-capture.h Bence Csókás
2025-03-04 9:51 ` William Breathitt Gray
2025-03-04 11:14 ` Csókás Bence
2025-03-04 11:54 ` William Breathitt Gray
2025-02-27 14:40 ` [PATCH v6 2/3] counter: microchip-tcb-capture: Add IRQ handling Bence Csókás
2025-03-04 7:02 ` William Breathitt Gray
2025-03-04 9:57 ` Csókás Bence
2025-03-04 10:18 ` William Breathitt Gray
2025-02-27 14:40 ` [PATCH v6 3/3] counter: microchip-tcb-capture: Add capture extensions for registers RA/RB Bence Csókás
2025-03-04 7:47 ` William Breathitt Gray
2025-03-04 10:03 ` Csókás Bence
2025-03-04 10:21 ` William Breathitt Gray [this message]
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=Z8bULwq70CAAQRSe@ishi \
--to=wbg@kernel.org \
--cc=csokas.bence@prolan.hu \
--cc=kamel.bouhara@bootlin.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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.