linux-kernel - [PATCH 0/4] Refactor 104-quad-8 to match device operations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <cover.1679149542.git.william.gray@linaro.org>
Date:   Sat, 18 Mar 2023 10:59:47 -0400
From:   William Breathitt Gray <william.gray@...aro.org>
To:     linux-iio@...r.kernel.org
Cc:     Johannes Berg <johannes.berg@...el.com>,
        Jonathan Cameron <jic23@...nel.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-kernel@...r.kernel.org,
        William Breathitt Gray <william.gray@...aro.org>
Subject: [PATCH 0/4] Refactor 104-quad-8 to match device operations

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. Modifying bitfields is a common code
pattern so a FIELD_MODIFY macro is introduced to facililate such.
Finally some helper functions are introduced to abstract the handling of
the PR, FLAG, and PSC registers.

Modifying a buffer state in-place is a common pattern, so should we also
consider adding a field_replace() function similar to bitmap_replace()?

[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
  bitfield: Introduce the FIELD_MODIFY() macro
  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 | 526 ++++++++++++++++++-----------------
 include/linux/bitfield.h     |  18 +-
 2 files changed, 283 insertions(+), 261 deletions(-)

base-commit: 00f4bc5184c19cb33f468f1ea409d70d19f8f502
-- 
2.39.2