From: Hans Zhang <18255117159@163.com>
To: David Laight <david.laight.linux@gmail.com>
Cc: broonie@kernel.org, sunny.luo@amlogic.com,
xianwei.zhao@amlogic.com, neil.armstrong@linaro.org,
khilman@baylibre.com, han.xu@nxp.com, haibo.chen@nxp.com,
mcoquelin.stm32@gmail.com, alexandre.torgue@foss.st.com,
lhjeff911@gmail.com, hayashi.kunihiko@socionext.com,
mhiramat@kernel.org, jbrunet@baylibre.com,
martin.blumenstingl@googlemail.com, linux-spi@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-amlogic@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev,
linux-stm32@st-md-mailman.stormreply.com
Subject: Re: [PATCH 00/10] spi: Use FIELD_MODIFY() for bitfield operations
Date: Tue, 5 May 2026 12:23:45 +0800 [thread overview]
Message-ID: <9be240fa-ab46-4b58-9240-5e96cab8a097@163.com> (raw)
In-Reply-To: <20260501093050.3f97cd3e@pumpkin>
On 5/1/26 16:30, David Laight wrote:
> On Thu, 30 Apr 2026 23:54:46 +0800
> Hans Zhang <18255117159@163.com> wrote:
>
>> Replace open-coded bitfield modifications with the standard FIELD_MODIFY()
>> macro across multiple SPI controller drivers. This improves readability and
>> adds compile-time checking without functional changes.
>
> I don't think these changes are worth the effort.
> The readability doesn't change much - you need to know what a slightly
> more obscure 'helper' does.
> The extra compile-time checks are pretty unlikely to ever find a problem
> and mostly just slow down the compile.
> The generated code is likely be slightly worse.
> And, with the best will in the world, it is easy to make silly mistakes.
>
> David
Hi David,
FIELD_MODIFY() is a standard kernel helper (bitfield.h), not an obscure
one. My recent power domain series using similar patterns was accepted:
https://patchwork.kernel.org/project/linux-pm/cover/20260430163213.44695-1-18255117159@163.com/
The PCIe maintainer also values this kind of code simplification, which
encouraged me to send these SPI patches.
The macro offers compile-time overflow checks, and I've verified the
generated assembly is identical (GCC/Clang). I believe the trade‑off
favours readability and safety.
If you still prefer to keep the open‑coded versions, I'll drop the
series. Please let me know.
Best regards,
Hans
>
>>
>> Each patch modifies a single driver, allowing independent review and
>> application.
>>
>> Hans Zhang (10):
>> spi: amlogic-spifc-a1: Use FIELD_MODIFY()
>> spi: amlogic-spisg: Use FIELD_MODIFY()
>> spi: cadence-xspi: Use FIELD_MODIFY()
>> spi: meson-spicc: Use FIELD_MODIFY()
>> spi: nxp-xspi: Use FIELD_MODIFY()
>> spi: sn-f-ospi: Use FIELD_MODIFY()
>> spi: stm32-ospi: Use FIELD_MODIFY()
>> spi: stm32-qspi: Use FIELD_MODIFY()
>> spi: sunplus-sp7021: Use FIELD_MODIFY()
>> spi: uniphier: Use FIELD_MODIFY()
>>
>> drivers/spi/spi-amlogic-spifc-a1.c | 5 ++---
>> drivers/spi/spi-amlogic-spisg.c | 13 +++++--------
>> drivers/spi/spi-cadence-xspi.c | 3 +--
>> drivers/spi/spi-meson-spicc.c | 5 ++---
>> drivers/spi/spi-nxp-xspi.c | 12 ++++--------
>> drivers/spi/spi-sn-f-ospi.c | 5 ++---
>> drivers/spi/spi-stm32-ospi.c | 7 +++----
>> drivers/spi/spi-stm32-qspi.c | 5 ++---
>> drivers/spi/spi-sunplus-sp7021.c | 3 +--
>> drivers/spi/spi-uniphier.c | 13 +++++--------
>> 10 files changed, 27 insertions(+), 44 deletions(-)
>>
>>
>> base-commit: 3b3bea6d4b9c162f9e555905d96b8c1da67ecd5b
prev parent reply other threads:[~2026-05-05 4:25 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-30 15:54 [PATCH 00/10] spi: Use FIELD_MODIFY() for bitfield operations Hans Zhang
2026-04-30 15:54 ` [PATCH 01/10] spi: amlogic-spifc-a1: Use FIELD_MODIFY() Hans Zhang
2026-04-30 15:54 ` [PATCH 02/10] spi: amlogic-spisg: " Hans Zhang
2026-04-30 15:54 ` [PATCH 03/10] spi: cadence-xspi: " Hans Zhang
2026-05-01 0:52 ` Mark Brown
2026-04-30 15:54 ` [PATCH 04/10] spi: meson-spicc: " Hans Zhang
2026-04-30 15:54 ` [PATCH 05/10] spi: nxp-xspi: " Hans Zhang
2026-05-05 15:39 ` Frank Li
2026-04-30 15:54 ` [PATCH 06/10] spi: sn-f-ospi: " Hans Zhang
2026-04-30 15:54 ` [PATCH 07/10] spi: stm32-ospi: " Hans Zhang
2026-04-30 15:54 ` [PATCH 08/10] spi: stm32-qspi: " Hans Zhang
2026-04-30 15:54 ` [PATCH 09/10] spi: sunplus-sp7021: " Hans Zhang
2026-04-30 15:54 ` [PATCH 10/10] spi: uniphier: " Hans Zhang
2026-05-01 8:30 ` [PATCH 00/10] spi: Use FIELD_MODIFY() for bitfield operations David Laight
2026-05-05 4:23 ` Hans Zhang [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=9be240fa-ab46-4b58-9240-5e96cab8a097@163.com \
--to=18255117159@163.com \
--cc=alexandre.torgue@foss.st.com \
--cc=broonie@kernel.org \
--cc=david.laight.linux@gmail.com \
--cc=haibo.chen@nxp.com \
--cc=han.xu@nxp.com \
--cc=hayashi.kunihiko@socionext.com \
--cc=imx@lists.linux.dev \
--cc=jbrunet@baylibre.com \
--cc=khilman@baylibre.com \
--cc=lhjeff911@gmail.com \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=martin.blumenstingl@googlemail.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=mhiramat@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=sunny.luo@amlogic.com \
--cc=xianwei.zhao@amlogic.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
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