From: Mark Brown <broonie@kernel.org>
To: Dhruva Gole <d-gole@ti.com>
Cc: Nathan Barrett-Morrison <nathan.morrison@timesys.com>,
greg.malysa@timesys.com,
"open list:SPI SUBSYSTEM" <linux-spi@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] spi: cadence-quadspi: Add upper limit safety check to baudrate divisor
Date: Thu, 24 Nov 2022 11:35:51 +0000 [thread overview]
Message-ID: <Y39XFzYJL3EmxSFF@sirena.org.uk> (raw)
In-Reply-To: <9e5264fa-db1a-ed96-5fd8-cbfa4694b8bd@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]
On Thu, Nov 24, 2022 at 12:16:10PM +0530, Dhruva Gole wrote:
> On 24/11/22 02:47, Nathan Barrett-Morrison wrote:
> > + /* Maximum baud divisor */
> > + if (div > CQSPI_REG_CONFIG_BAUD_MASK)
> I don't think comparing "greater than" with a MASK is atall a good idea.
Why - it's checking that the calculated divisor can actually fit in the
relevant register field which seems like a totally normal thing to do?
> Again, I don't fully understand your situation is as in
> what is the peripheral you are using. So please elaborate on that.
As far as I can tell the issue here is that the device is asking for a
rate which requires a larger divisor than the controller can support but
the driver doesn't do any bounds checking so it just writes the
calculated divisor out to the hardware, corrupting any adjacent fields.
In this context the SPI controller is a peripheral within the SoC.
> Importantly, I would suggest that you _NEVER_ compare ANY value to a
> MASK Macro. MASK Macros are meant to MASK bits.
It's very common to also use masks to identify when values have
overflowed the values that can be written to a field.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2022-11-24 11:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-23 21:17 [PATCH] spi: cadence-quadspi: Add upper limit safety check to baudrate divisor Nathan Barrett-Morrison
2022-11-24 6:46 ` Dhruva Gole
2022-11-24 11:35 ` Mark Brown [this message]
2022-11-24 12:27 ` Dhruva Gole
2022-11-24 12:41 ` Mark Brown
2022-11-24 11:40 ` Mark Brown
2022-11-24 11:53 ` Nathan Barrett-Morrison
2022-11-24 12:02 ` Mark Brown
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=Y39XFzYJL3EmxSFF@sirena.org.uk \
--to=broonie@kernel.org \
--cc=d-gole@ti.com \
--cc=greg.malysa@timesys.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=nathan.morrison@timesys.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