Changes in v4:
 - Fix endianness errors by utilizing get_unaligned_le24() and
   put_unaligned_le24()
 - Mention benefits of using regmap in the commit description
 - Use "int ret" for regmap_* return values throughout for consistency
 - Reorganize declaration lists to prioritize longer lines first
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. A migration to the regmap API is added as a follow-up patch
due to its dependence on this patch series.

[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 (4):
  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
  counter: 104-quad-8: Migrate to the regmap API

 drivers/counter/104-quad-8.c | 802 +++++++++++++++++++----------------
 drivers/counter/Kconfig      |   1 +
 2 files changed, 440 insertions(+), 363 deletions(-)


base-commit: 09a9639e56c01c7a00d6c0ca63f4c7c41abe075d
-- 
2.39.2

On Mon, Apr 17, 2023 at 03:50:46PM -0400, William Breathitt Gray wrote:
> Changes in v4:
>  - Fix endianness errors by utilizing get_unaligned_le24() and
>    put_unaligned_le24()
>  - Mention benefits of using regmap in the commit description
>  - Use "int ret" for regmap_* return values throughout for consistency
>  - Reorganize declaration lists to prioritize longer lines first
> 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. A migration to the regmap API is added as a follow-up patch
> due to its dependence on this patch series.
> 
> [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 (4):
>   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
>   counter: 104-quad-8: Migrate to the regmap API
> 
>  drivers/counter/104-quad-8.c | 802 +++++++++++++++++++----------------
>  drivers/counter/Kconfig      |   1 +
>  2 files changed, 440 insertions(+), 363 deletions(-)
> 
> 
> base-commit: 09a9639e56c01c7a00d6c0ca63f4c7c41abe075d
> -- 
> 2.39.2
> 

Queued for counter-next.

William Breathitt Gray