All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Tabrez Ahmed" <tabreztalks@gmail.com>
Cc: linux-hwmon@vger.kernel.org
Subject: Re: [PATCH v3 3/3] hwmon: (ads7871) Use DMA-safe buffer for SPI writes
Date: Sat, 18 Apr 2026 04:56:54 +0000	[thread overview]
Message-ID: <20260418045655.2EB12C19424@smtp.kernel.org> (raw)
In-Reply-To: <20260418034601.90226-4-tabreztalks@gmail.com>

Sashiko AI review found 1 potential issue(s):
- [High] This problem wasn't introduced by this patch, but in `ads7871_read_reg16`, a pointer to a 32-bit `int` (`&reg`) is passed to `spi_write_then_read` to transmit a 1-byte command, which breaks register reads on big-endian architectures.
--

commit 4c76d6fe3d1664a2cf635cd569d8b01aeed70678
Author: Tabrez Ahmed <tabreztalks@gmail.com>

hwmon: (ads7871) Use DMA-safe buffer for SPI writes

This commit migrates the SPI write operations in the ads7871 driver to use a
DMA-safe, cacheline-aligned buffer allocated in the driver's private data
structure instead of using a stack-allocated buffer. It also adjusts the scale
calculation for 14-bit data.

> diff --git a/drivers/hwmon/ads7871.c b/drivers/hwmon/ads7871.c
> --- a/drivers/hwmon/ads7871.c
> +++ b/drivers/hwmon/ads7871.c
> @@ -97,11 +98,12 @@ static int ads7871_read_reg16(struct spi_device *spi, int reg)
>  	return get_unaligned_le16(buf);
>  }

[ ... ]

This wasn't introduced by this patch, but since you are fixing
architecture-specific compatibility issues here, I noticed something in
ads7871_read_reg16() just above this diff.

Does passing a pointer to a 32-bit int (&reg) to spi_write_then_read()
for transmitting a 1-byte command break register reads on big-endian
architectures?

static int ads7871_read_reg16(struct spi_device *spi, int reg)
{
        ...
        reg = reg | INST_READ_BM | INST_16BIT_BM;
        ret = spi_write_then_read(spi, &reg, 1, buf, 2);
        ...
}

On little-endian architectures, this correctly reads the least significant
byte containing the command. On big-endian architectures, wouldn't it read
the most significant byte (0x00) instead, sending an invalid command to
the hardware?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260418034601.90226-1-tabreztalks@gmail.com?part=3

      reply	other threads:[~2026-04-18  4:56 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-18  3:45 [PATCH v3 0/3] hwmon: (ads7871) Modernize and fix DMA safety Tabrez Ahmed
2026-04-18  3:45 ` [PATCH v3 1/3] hwmon: (ads7871) Fix endianness bug in 16-bit register reads Tabrez Ahmed
2026-04-18  4:11   ` sashiko-bot
2026-04-30 18:02     ` Guenter Roeck
2026-04-18  3:46 ` [PATCH v3 2/3] hwmon: (ads7871) Convert to hwmon_device_register_with_info Tabrez Ahmed
2026-04-18  3:46 ` [PATCH v3 3/3] hwmon: (ads7871) Use DMA-safe buffer for SPI writes Tabrez Ahmed
2026-04-18  4:56   ` sashiko-bot [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=20260418045655.2EB12C19424@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=sashiko@lists.linux.dev \
    --cc=tabreztalks@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.