From: William Breathitt Gray <william.gray@linaro.org>
To: linux-iio@vger.kernel.org
Cc: linux-kernel@vger.kernel.org,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Johannes Berg <johannes.berg@intel.com>,
Jonathan Cameron <jic23@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>,
William Breathitt Gray <william.gray@linaro.org>
Subject: [PATCH v3 0/3] Refactor 104-quad-8 to match device operations
Date: Mon, 10 Apr 2023 10:03:10 -0400 [thread overview]
Message-ID: <cover.1681134558.git.william.gray@linaro.org> (raw)
Changes in v3:
- Add __always_inline attribute for quad8_control_register_update()
Changes in v2:
- Drop FIELD_MODIFY() macro introduction; u8p_replace_bits() is
utilized instead for the same purpose
- Replace FIELD_PREP() and FIELD_GET() with u8_encode_bits() and
u8_get_bits()
- Replace FIELD_MODIFY() with u8p_replace_bits()
- Wrap up control register update in quad8_control_register_update()
- Utilize ioread8_rep() and iowrite8_rep() to read and write counter
data
The 104-quad-8 driver was initially introduced to the IIO subsystem
where it didn't quite fit with the existing paradigm [0]; these
differences eventually led to the creation of the Counter subsystem[1].
As a result of its awkward beginnings, the design of the 104-quad-8
driver was structured around maintaining abstract state buffers that
would eventually be converted to match the actual device registers
states on-the-fly as needed.
The original design approach for the 104-quad-8 driver was neither
efficient nor easy to troubleshoot, but it did allow us to focus on
implementing and supporting necessary APIs for the nascent Counter
subsystem. Now that development for the 104-quad-8 driver has shifted
to maintenance, it is a good time to refactor and clean up the code to
match closer to what is actually happening on the device. This patchset
is an attempt to rectify the situation as such.
The primary change is a transition from maintaining individual
configuration states independently, to storing buffers of the device
register configurations. To that end, the bitfield API is leveraged to
access and retrieve field states. Some helper functions are introduced
as well to abstract the handling of the PR, FLAG, PSC, and control
registers.
[0] https://lore.kernel.org/r/b43e2942b763b87afc85bfa9fe36e5695cba4c44.1475079578.git.vilhelm.gray@gmail.com/
[1] https://lore.kernel.org/r/cover.1554184734.git.vilhelm.gray@gmail.com/
William Breathitt Gray (3):
counter: 104-quad-8: Utilize bitfield access macros
counter: 104-quad-8: Refactor to buffer states for CMR, IOR, and IDR
counter: 104-quad-8: Utilize helper functions to handle PR, FLAG and
PSC
drivers/counter/104-quad-8.c | 537 +++++++++++++++++------------------
1 file changed, 258 insertions(+), 279 deletions(-)
base-commit: 09a9639e56c01c7a00d6c0ca63f4c7c41abe075d
--
2.39.2
next reply other threads:[~2023-04-10 14:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-10 14:03 William Breathitt Gray [this message]
2023-04-10 14:03 ` [PATCH v3 1/3] counter: 104-quad-8: Utilize bitfield access macros William Breathitt Gray
2023-04-10 14:03 ` [PATCH v3 2/3] counter: 104-quad-8: Refactor to buffer states for CMR, IOR, and IDR William Breathitt Gray
2023-04-10 14:03 ` [PATCH v3 3/3] counter: 104-quad-8: Utilize helper functions to handle PR, FLAG and PSC William Breathitt Gray
2023-04-11 13:50 ` Andy Shevchenko
2023-04-11 14:05 ` William Breathitt Gray
2023-04-11 14:43 ` Andy Shevchenko
2023-04-11 14:58 ` 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=cover.1681134558.git.william.gray@linaro.org \
--to=william.gray@linaro.org \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=jic23@kernel.org \
--cc=johannes.berg@intel.com \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=viro@zeniv.linux.org.uk \
/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).