From: Sam Protsenko <semen.protsenko@linaro.org>
To: Tudor Ambarus <tudor.ambarus@linaro.org>
Cc: Mark Brown <broonie@kernel.org>,
andi.shyti@kernel.org, arnd@arndb.de, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
alim.akhtar@samsung.com, linux-spi@vger.kernel.org,
linux-samsung-soc@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-arch@vger.kernel.org, andre.draszik@linaro.org,
peter.griffin@linaro.org, kernel-team@android.com,
willmcvicker@google.com
Subject: Re: [PATCH v2 09/28] spi: s3c64xx: use bitfield access macros
Date: Fri, 26 Jan 2024 13:55:15 -0600 [thread overview]
Message-ID: <CAPLW+4=pM=gY1bypGNhKmcftLFHWBMUZ7=JitMj_3TaxLF672A@mail.gmail.com> (raw)
In-Reply-To: <ee4107c3-1141-45ab-874c-03474d8ec18d@linaro.org>
On Fri, Jan 26, 2024 at 2:49 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
>
>
> On 1/25/24 19:50, Sam Protsenko wrote:
> > On Thu, Jan 25, 2024 at 8:50 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
> >>
> >> Use the bitfield access macros in order to clean and to make the driver
> >> easier to read.
> >>
> >> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> >> ---
> >> drivers/spi/spi-s3c64xx.c | 196 +++++++++++++++++++-------------------
> >> 1 file changed, 99 insertions(+), 97 deletions(-)
> >>
> >> diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
> >> index 1e44b24f6401..d046810da51f 100644
> >> --- a/drivers/spi/spi-s3c64xx.c
> >> +++ b/drivers/spi/spi-s3c64xx.c
> >> @@ -4,6 +4,7 @@
>
> cut
>
> >> +#define S3C64XX_SPI_PSR_MASK GENMASK(15, 0)
> >
> > But it was 0xff (7:0) originally, and here you extend it up to 15:0.
>
> this is a bug from my side, I'll fix it, thanks!
>
> cut
>
> >> default:
> >> - val |= S3C64XX_SPI_MODE_BUS_TSZ_BYTE;
> >> - val |= S3C64XX_SPI_MODE_CH_TSZ_BYTE;
> >> + val |= FIELD_PREP(S3C64XX_SPI_MODE_BUS_TSZ_MASK,
> >> + S3C64XX_SPI_MODE_BUS_TSZ_BYTE) |
> >> + FIELD_PREP(S3C64XX_SPI_MODE_CH_TSZ_MASK,
> >> + S3C64XX_SPI_MODE_CH_TSZ_BYTE);
> >
> > I don't know. Maybe it's me, but using this FIELD_PREP() macro seems
> > to only making the code harder to read. At least in cases like this. I
> > would vote against its usage, to keep the code compact and easy to
> > read.
>
> I saw Andi complained about this too, maybe Mark can chime in.
>
> To me this is not a matter of taste, it's how it should be done. In this
Sure. But if you think it has to be done, I suggest it's done taking
next things into the account:
1. It shouldn't make code harder to read
2. Preferably stick to canonical ways of doing things
3. IMHO patches like this *must* be tested thoroughly on different
boards with different test-cases, to make sure there are no
regressions. Because the benefits of cleanups are not that great, as I
see it, but we are risking to break some hardware/software combination
unintentionally while doing those cleanups. It's a good idea to
describe how it was tested in commit message or PATCH #0. Just my
$.02.
For (1) and (2): I noticed a lot of drivers are carrying additional
helper functions for read/write operations, to keep things tidy and
functional at the same time. Another mechanism that comes into mind is
regmap, though I'm not sure if it's needed for such low-level entities
as bus drivers. Also I think Andi has a point about FIELD_PREP and how
that can be handled.
> particular case you have more lines when using FIELD_PREP because the
> mask starts from bit 0. If the mask ever changes for new IPs then you'd
> have to hack the code, whereas if using FIELD_PREP you just have to
> update the mask field, something like:
>
> FIELD_PREP(drv_prv_data->whatever_reg.field_mask,
> S3C64XX_SPI_MODE_CH_TSZ_BYTE);
>
> Thus it makes the code generic and more friendly for new IP additions.
> And I have to admit I like it better too. I know from the start that
> we're dealing with register fields and not some internal driver mask.
next prev parent reply other threads:[~2024-01-26 19:55 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-25 14:49 [PATCH v2 00/28] spi: s3c64xx: winter cleanup and gs101 support Tudor Ambarus
2024-01-25 14:49 ` [PATCH v2 01/28] spi: s3c64xx: explicitly include <linux/io.h> Tudor Ambarus
2024-01-25 18:58 ` Sam Protsenko
2024-01-26 14:40 ` Tudor Ambarus
2024-01-25 14:49 ` [PATCH v2 02/28] spi: s3c64xx: explicitly include <linux/bits.h> Tudor Ambarus
2024-01-25 14:49 ` [PATCH v2 03/28] spi: s3c64xx: avoid possible negative array index Tudor Ambarus
2024-01-25 18:50 ` Sam Protsenko
2024-01-25 14:49 ` [PATCH v2 04/28] spi: dt-bindings: samsung: add google,gs101-spi compatible Tudor Ambarus
2024-01-25 14:49 ` [PATCH v2 05/28] spi: dt-bindings: samsung: add samsung,spi-fifosize property Tudor Ambarus
2024-01-25 16:16 ` Mark Brown
2024-01-25 16:38 ` Tudor Ambarus
2024-01-25 17:26 ` Mark Brown
2024-01-25 17:30 ` Tudor Ambarus
2024-01-25 17:45 ` Mark Brown
2024-01-25 19:01 ` Tudor Ambarus
2024-01-30 22:25 ` Rob Herring
2024-02-05 9:42 ` Tudor Ambarus
2024-01-25 14:49 ` [PATCH v2 06/28] spi: s3c64xx: sort headers alphabetically Tudor Ambarus
2024-01-25 14:49 ` [PATCH v2 07/28] spi: s3c64xx: remove unneeded (void *) casts in of_match_table Tudor Ambarus
2024-01-25 19:04 ` Sam Protsenko
2024-01-26 8:24 ` Tudor Ambarus
2024-01-26 19:40 ` Sam Protsenko
2024-01-25 14:49 ` [PATCH v2 08/28] spi: s3c64xx: remove else after return Tudor Ambarus
2024-01-25 14:49 ` [PATCH v2 09/28] spi: s3c64xx: use bitfield access macros Tudor Ambarus
2024-01-25 19:50 ` Sam Protsenko
2024-01-26 8:49 ` Tudor Ambarus
2024-01-26 19:55 ` Sam Protsenko [this message]
2024-01-26 16:01 ` Tudor Ambarus
2024-01-25 14:49 ` [PATCH v2 10/28] spi: s3c64xx: use full mask for {RX, TX}_FIFO_LVL Tudor Ambarus
2024-01-25 20:03 ` Sam Protsenko
2024-01-25 21:48 ` Mark Brown
2024-01-26 8:51 ` Tudor Ambarus
2024-01-26 8:12 ` Tudor Ambarus
2024-01-25 14:49 ` [PATCH v2 11/28] spi: s3c64xx: move common code outside if else Tudor Ambarus
2024-01-25 20:09 ` Sam Protsenko
2024-01-25 14:49 ` [PATCH v2 12/28] spi: s3c64xx: check return code of dmaengine_slave_config() Tudor Ambarus
2024-01-25 20:19 ` Sam Protsenko
2024-01-25 14:49 ` [PATCH v2 13/28] spi: s3c64xx: propagate the dma_submit_error() error code Tudor Ambarus
2024-01-25 20:23 ` Sam Protsenko
2024-01-26 7:42 ` Tudor Ambarus
2024-01-25 14:49 ` [PATCH v2 14/28] spi: s3c64xx: rename prepare_dma() to s3c64xx_prepare_dma() Tudor Ambarus
2024-01-25 20:24 ` Sam Protsenko
2024-01-25 14:49 ` [PATCH v2 15/28] spi: s3c64xx: return ETIMEDOUT for wait_for_completion_timeout() Tudor Ambarus
2024-01-25 20:30 ` Sam Protsenko
2024-01-25 14:49 ` [PATCH v2 16/28] spi: s3c64xx: simplify s3c64xx_wait_for_pio() Tudor Ambarus
2024-01-25 20:43 ` Sam Protsenko
2024-01-26 7:56 ` Tudor Ambarus
2024-01-26 19:31 ` Sam Protsenko
2024-01-25 14:49 ` [PATCH v2 17/28] spi: s3c64xx: drop blank line between declarations Tudor Ambarus
2024-01-25 20:38 ` Sam Protsenko
2024-01-25 14:49 ` [PATCH v2 18/28] spi: s3c64xx: fix typo, s/configuartion/configuration Tudor Ambarus
2024-01-25 20:39 ` Sam Protsenko
2024-01-25 14:49 ` [PATCH v2 19/28] spi: s3c64xx: downgrade dev_warn to dev_dbg for optional dt props Tudor Ambarus
2024-01-25 20:40 ` Sam Protsenko
2024-01-25 14:49 ` [PATCH v2 20/28] spi: s3c64xx: add support for inferring fifosize from the compatible Tudor Ambarus
2024-01-25 14:49 ` [PATCH v2 21/28] spi: s3c64xx: infer " Tudor Ambarus
2024-01-25 17:18 ` Mark Brown
2024-01-25 18:44 ` Tudor Ambarus
2024-01-25 22:28 ` Sam Protsenko
2024-01-26 7:27 ` Tudor Ambarus
2024-01-25 14:50 ` [PATCH v2 22/28] spi: s3c64xx: drop dependency on of_alias where possible Tudor Ambarus
2024-01-25 14:50 ` [PATCH v2 23/28] spi: s3c64xx: retrieve the FIFO size from the device tree Tudor Ambarus
2024-01-25 17:33 ` Mark Brown
2024-01-26 19:23 ` Sam Protsenko
2024-01-26 20:16 ` Arnd Bergmann
2024-01-26 20:20 ` Sam Protsenko
2024-02-05 9:54 ` Tudor Ambarus
2024-01-26 21:19 ` Mark Brown
2024-01-25 14:50 ` [PATCH v2 24/28] spi: s3c64xx: mark fifo_lvl_mask as deprecated Tudor Ambarus
2024-01-25 14:50 ` [PATCH v2 25/28] asm-generic/io.h: add iowrite{8,16}_32 accessors Tudor Ambarus
2024-01-25 17:41 ` Mark Brown
2024-01-25 21:23 ` Arnd Bergmann
2024-01-26 7:21 ` Tudor Ambarus
2024-01-25 14:50 ` [PATCH v2 26/28] spi: s3c64xx: add iowrite{8,16}_32_rep accessors Tudor Ambarus
2024-01-25 14:50 ` [PATCH v2 27/28] spi: s3c64xx: add support for google,gs101-spi Tudor Ambarus
2024-01-25 20:45 ` Sam Protsenko
2024-01-25 14:50 ` [PATCH v2 28/28] MAINTAINERS: add Tudor Ambarus as R for the samsung SPI driver Tudor Ambarus
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='CAPLW+4=pM=gY1bypGNhKmcftLFHWBMUZ7=JitMj_3TaxLF672A@mail.gmail.com' \
--to=semen.protsenko@linaro.org \
--cc=alim.akhtar@samsung.com \
--cc=andi.shyti@kernel.org \
--cc=andre.draszik@linaro.org \
--cc=arnd@arndb.de \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=kernel-team@android.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=peter.griffin@linaro.org \
--cc=robh+dt@kernel.org \
--cc=tudor.ambarus@linaro.org \
--cc=willmcvicker@google.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).