[PATCH v2 0/5] spi: fix division by zero with a zero transfer speed

[PATCH v2 0/5] spi: fix division by zero with a zero transfer speed

[shao.mingyin]

Five SPI controller drivers compute a clock divider from the transfer
speed without checking that it is non-zero.  A SPI device whose
max_speed_hz is zero (a DT node without spi-max-frequency, or a device
created through the spidev sysfs new_device interface without a speed)
therefore reaches the division with speed_hz == 0.  The SPI core clamps
such a device to the controller limit only when host->max_speed_hz is
set, and none of these five drivers sets it.

The series is organized by driver and is independent patch-by-patch;
each patch can be applied and reviewed on its own, and taking a subset
is fine:

  1/5 spi: sifive: clamp the clock divider to the register range
  2/5 spi: bcm63xx-hsspi: fix division by zero for devices without a max speed
  3/5 spi: bcmbca-hsspi: fix division by zero for devices without a max speed
  4/5 spi: apple: fix division by zero in clock divisor calculation
  5/5 spi: atmel: use the maximum divider for an unspecified speed

1/5 and 5/5 program the slowest clock directly when no speed is supplied;
2/5-4/5 clamp the requested rate to 1 Hz.  The division does not trap on
the SoCs these drivers run on: depending on the architecture it produces
a bogus divider, a zero quotient or an undefined value, so the patches
remove undefined arithmetic rather than a crash.

Changes in v2:
- 1/5: use the maximum SCKDIV for a zero speed and saturate an excessive
  divider instead of masking away the high bits (Mark Brown).
- 5/5: select SCBR=255 directly for a zero speed instead of dividing a
  substituted 1 Hz and then failing the range check (Mark Brown).
- 2/5, 3/5 and 4/5: unchanged.
- This series replaces the two standalone v2 patches posted on 10 Nov for
  1/5 and 5/5.
Link to v1: https://lore.kernel.org/all/20261106234751020Egf42VCVVlsSC_Msov4HO@zte.com.cn/

Shao Mingyin (5):
  spi: sifive: clamp the clock divider to the register range
  spi: bcm63xx-hsspi: fix division by zero for devices without a max speed
  spi: bcmbca-hsspi: fix division by zero for devices without a max speed
  spi: apple: fix division by zero in clock divisor calculation
  spi: atmel: use the maximum divider for an unspecified speed

 drivers/spi/spi-apple.c         | 6 +++++-
 drivers/spi/spi-atmel.c         | 5 ++++-
 drivers/spi/spi-bcm63xx-hsspi.c | 3 +++
 drivers/spi/spi-bcmbca-hsspi.c  | 3 +++
 drivers/spi/spi-sifive.c        | 9 ++++++---
 5 files changed, 21 insertions(+), 5 deletions(-)

---
base-commit: ddfe51b0a0f5dc9e415cc2c8ad8db17532dd426b

[PATCH v2 1/5] spi: sifive: clamp the clock divider to the register range

[shao.mingyin]

From: Shao Mingyin <shao.mingyin@zte.com.cn>

sifive_spi_prep_transfer() divides by t->speed_hz, which can remain
zero when neither the device nor the controller provides a maximum
speed. For a nonzero but very low speed, masking the divider to 12 bits
can also wrap it to a small value and program a much faster clock.

Use the maximum divider when no speed is supplied, and saturate an
out-of-range divider to the same value. Keep the calculation in an
unsigned long until it has been clamped, so it is not truncated to u32
before the range check.

Fixes: 484a9a68d669 ("spi: sifive: Add driver for the SiFive SPI controller")
Suggested-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Shao Mingyin <shao.mingyin@zte.com.cn>
---
v2:
  - use the maximum SCKDIV directly for a zero speed, and saturate an
    excessive divider instead of masking away high bits (Mark Brown)
  - keep the divider wide until after the range check
v1: https://lore.kernel.org/all/20261106234756882V9wUQNCEZAYUGTAbexMSL@zte.com.cn/

Validation on x86-64 with GCC 13 and UBSAN: the verbatim preparation
function ran with clock/register stubs over all representable SCKDIV
values and the first overflow. A zero speed bypassed division and
programmed 0xfff. A 1 Hz request needing divider 4096 programmed 0xfff
instead of wrapping to zero; a divider exceeding u32 also saturated.
In-range requests retained their original register values.

 drivers/spi/spi-sifive.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/spi-sifive.c b/drivers/spi/spi-sifive.c
index cee4d92e46f437319fa40f6377e5511e692d12c7..ca7b04520a682c3fffb070169ab0e3c485e323de 100644
--- a/drivers/spi/spi-sifive.c
+++ b/drivers/spi/spi-sifive.c
@@ -167,12 +167,15 @@ static int
 sifive_spi_prep_transfer(struct sifive_spi *spi, struct spi_device *device,
 			 struct spi_transfer *t)
 {
+	unsigned long div = SIFIVE_SPI_SCKDIV_DIV_MASK;
 	u32 cr;
 	unsigned int mode;
 
-	/* Calculate and program the clock rate */
-	cr = DIV_ROUND_UP(clk_get_rate(spi->clk) >> 1, t->speed_hz) - 1;
-	cr &= SIFIVE_SPI_SCKDIV_DIV_MASK;
+	/* Use the slowest clock if no speed is specified. */
+	if (t->speed_hz)
+		div = DIV_ROUND_UP(clk_get_rate(spi->clk) >> 1,
+				   t->speed_hz) - 1;
+	cr = min_t(unsigned long, div, SIFIVE_SPI_SCKDIV_DIV_MASK);
 	sifive_spi_write(spi, SIFIVE_SPI_REG_SCKDIV, cr);
 
 	mode = max_t(unsigned int, t->rx_nbits, t->tx_nbits);

[PATCH v2 2/5] spi: bcm63xx-hsspi: fix division by zero for devices without a max speed

[shao.mingyin]

From: Shao Mingyin <shao.mingyin@zte.com.cn>

A SPI device whose max_speed_hz is zero (no spi-max-frequency property,
or created through the spidev sysfs new_device interface without a
speed) leaves the transfer speed at zero.  spi_setup() would only clamp
it if host->max_speed_hz was set, which this driver does not do, so
bcm63xx_hsspi_set_clk() divides by zero in DIV_ROUND_UP().

The division does not trap on MIPS or arm64.  The quotient is undefined
or zero, so the clock control register is programmed with a meaningless
value.

Clamp the requested rate to 1 Hz before computing the divider.

Fixes: 142168eba9dc ("spi: bcm63xx-hsspi: add bcm63xx HSSPI driver")
Signed-off-by: Shao Mingyin <shao.mingyin@zte.com.cn>

---

diff --git a/drivers/spi/spi-bcm63xx-hsspi.c b/drivers/spi/spi-bcm63xx-hsspi.c
index abfbf97faf7b..319951fba387 100644
--- a/drivers/spi/spi-bcm63xx-hsspi.c
+++ b/drivers/spi/spi-bcm63xx-hsspi.c
@@ -469,6 +469,9 @@ static void bcm63xx_hsspi_set_clk(struct bcm63xx_hsspi *bs,
 	unsigned int profile = spi_get_chipselect(spi, 0);
 	u32 reg;
 
+	/* A device with max_speed_hz == 0 must not divide by zero */
+	hz = max_t(int, hz, 1);
+
 	reg = DIV_ROUND_UP(2048, DIV_ROUND_UP(bs->speed_hz, hz));
 	__raw_writel(CLK_CTRL_ACCUM_RST_ON_LOOP | reg,
 		     bs->regs + HSSPI_PROFILE_CLK_CTRL_REG(profile));

[PATCH v2 3/5] spi: bcmbca-hsspi: fix division by zero for devices without a max speed

[shao.mingyin]

From: Shao Mingyin <shao.mingyin@zte.com.cn>

A SPI device whose max_speed_hz is zero (no spi-max-frequency property,
or created through the spidev sysfs new_device interface without a
speed) leaves the transfer speed at zero.  spi_setup() would only clamp
it if host->max_speed_hz was set, which this driver does not do, so
bcmbca_hsspi_set_clk() divides by zero in DIV_ROUND_UP().

On arm64 the division returns zero instead of trapping: the inner
DIV_ROUND_UP() yields zero, which is then used as the divisor of the
outer one, so the clock control register is programmed with a
meaningless value.

Clamp the requested rate to 1 Hz before computing the divider.

Fixes: a38a2233f23b ("spi: bcmbca-hsspi: Add driver for newer HSSPI controller")
Signed-off-by: Shao Mingyin <shao.mingyin@zte.com.cn>

---

diff --git a/drivers/spi/spi-bcmbca-hsspi.c b/drivers/spi/spi-bcmbca-hsspi.c
index 8c01475886e8..84015110557a 100644
--- a/drivers/spi/spi-bcmbca-hsspi.c
+++ b/drivers/spi/spi-bcmbca-hsspi.c
@@ -196,6 +196,9 @@ static void bcmbca_hsspi_set_clk(struct bcmbca_hsspi *bs,
 	unsigned int profile = spi_get_chipselect(spi, 0);
 	u32 reg;
 
+	/* A device with max_speed_hz == 0 must not divide by zero */
+	hz = max_t(int, hz, 1);
+
 	reg = DIV_ROUND_UP(2048, DIV_ROUND_UP(bs->speed_hz, hz));
 	__raw_writel(CLK_CTRL_ACCUM_RST_ON_LOOP | reg,
 		     bs->regs + HSSPI_PROFILE_CLK_CTRL_REG(profile));

[PATCH v2 4/5] spi: apple: fix division by zero in clock divisor calculation

[shao.mingyin]

From: Shao Mingyin <shao.mingyin@zte.com.cn>

A SPI device without a valid speed (no spi-max-frequency property, or
created through the spidev sysfs new_device interface without a speed)
gets max_speed_hz == 0.  spi_setup() only clamps that to the controller
limit when host->max_speed_hz is set, and this driver does not set it, so
the zero reaches apple_spi_prep_transfer() and DIV_ROUND_UP() divides by
it.

On arm64 the divide instruction returns zero instead of trapping, so
CLKDIV is programmed as zero.  That selects the fastest clock and can
exceed the rate the attached device supports.

Clamp the divisor to 1 Hz so the divider calculation is well defined.

Fixes: c36212b2610d ("spi: apple: Add driver for Apple SPI controller")
Signed-off-by: Shao Mingyin <shao.mingyin@zte.com.cn>

---

diff --git a/drivers/spi/spi-apple.c b/drivers/spi/spi-apple.c
index 61eefb08d2a7..8dbf05936db1 100644
--- a/drivers/spi/spi-apple.c
+++ b/drivers/spi/spi-apple.c
@@ -196,9 +196,13 @@ static void apple_spi_set_cs(struct spi_device *device, bool is_high)
 static bool apple_spi_prep_transfer(struct apple_spi *spi, struct spi_transfer *t)
 {
 	u32 cr, fifo_threshold;
+	u32 speed_hz;
+
+	/* A device with max_speed_hz == 0 must not divide by zero */
+	speed_hz = max_t(u32, t->speed_hz, 1);
 
 	/* Calculate and program the clock rate */
-	cr = DIV_ROUND_UP(clk_get_rate(spi->clk), t->speed_hz);
+	cr = DIV_ROUND_UP(clk_get_rate(spi->clk), speed_hz);
 	reg_write(spi, APPLE_SPI_CLKDIV, min_t(u32, cr, APPLE_SPI_CLKDIV_MAX));
 
 	/* Update bits per word */

[PATCH v2 5/5] spi: atmel: use the maximum divider for an unspecified speed

[shao.mingyin]

From: Shao Mingyin <shao.mingyin@zte.com.cn>

atmel_spi_set_xfer_speed() divides by xfer->speed_hz. That speed can
remain zero when neither the device nor the controller supplies a
maximum, allowing a transfer to reach the divider calculation with a
zero divisor.

Select the maximum SCBR value directly when the speed is zero. This
avoids both the division and an out-of-range divider that would be
rejected by the subsequent validation. Keep the existing range checks
for explicitly requested speeds.

Fixes: d3b72c7e6bf3 ("spi: atmel: add support for changing message transfer speed")
Suggested-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Shao Mingyin <shao.mingyin@zte.com.cn>
---
v2:
  - select SCBR=255 directly for a zero speed, avoiding the division
    and the subsequent rejection of an out-of-range divider (Mark Brown)
  - preserve the range checks for nonzero requested speeds
v1: https://lore.kernel.org/all/20261106234803459Z94udUX-Ai29-OfBFRND6@zte.com.cn/

Validation on x86-64 with GCC 13 and UBSAN: the verbatim speed-setting
function ran with clock/register stubs for v1/v2 controllers and native
or GPIO chip selects. Zero speed bypassed division, programmed SCBR=255
and set effective_speed_hz. Nonzero speeds retained the existing
SCBR=0 and SCBR>=256 rejections and the valid-divider register values.

 drivers/spi/spi-atmel.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index ffc896e4621acf2f2abfd33981904fae40b08ff5..333423b3111f8b04fbb314da659fc4ac99a390fa 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -923,7 +923,10 @@ static int atmel_spi_set_xfer_speed(struct atmel_spi *as,
 	 * Calculate the lowest divider that satisfies the
 	 * constraint, assuming div32/fdiv/mbz == 0.
 	 */
-	scbr = DIV_ROUND_UP(bus_hz, xfer->speed_hz);
+	if (xfer->speed_hz)
+		scbr = DIV_ROUND_UP(bus_hz, xfer->speed_hz);
+	else
+		scbr = (1 << SPI_SCBR_SIZE) - 1;
 
 	/*
 	 * If the resulting divider doesn't fit into the

Re: [PATCH v2 0/5] spi: fix division by zero with a zero transfer speed

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 516 bytes --]

On Tue, Nov 10, 2026 at 11:34:50PM +0800, shao.mingyin@zte.com.cn wrote:

>   1/5 spi: sifive: clamp the clock divider to the register range
>   2/5 spi: bcm63xx-hsspi: fix division by zero for devices without a max speed
>   3/5 spi: bcmbca-hsspi: fix division by zero for devices without a max speed
>   4/5 spi: apple: fix division by zero in clock divisor calculation
>   5/5 spi: atmel: use the maximum divider for an unspecified speed

Oh, I see you also sent those v2 patches as part of the series as
normal.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v2 3/5] spi: bcmbca-hsspi: fix division by zero for devices without a max speed

[William Zhang]

[-- Attachment #1: Type: text/plain, Size: 2107 bytes --]

Hi Mingyin,

On Tue, Nov 10, 2026 at 7:35 AM <shao.mingyin@zte.com.cn> wrote:
>
> From: Shao Mingyin <shao.mingyin@zte.com.cn>
>
> A SPI device whose max_speed_hz is zero (no spi-max-frequency property,
> or created through the spidev sysfs new_device interface without a
> speed) leaves the transfer speed at zero.  spi_setup() would only clamp
> it if host->max_speed_hz was set, which this driver does not do, so
> bcmbca_hsspi_set_clk() divides by zero in DIV_ROUND_UP().
>
> On arm64 the division returns zero instead of trapping: the inner
> DIV_ROUND_UP() yields zero, which is then used as the divisor of the
> outer one, so the clock control register is programmed with a
> meaningless value.
>
> Clamp the requested rate to 1 Hz before computing the divider.
>
> Fixes: a38a2233f23b ("spi: bcmbca-hsspi: Add driver for newer HSSPI controller")
> Signed-off-by: Shao Mingyin <shao.mingyin@zte.com.cn>
>
> ---
>
> diff --git a/drivers/spi/spi-bcmbca-hsspi.c b/drivers/spi/spi-bcmbca-hsspi.c
> index 8c01475886e8..84015110557a 100644
> --- a/drivers/spi/spi-bcmbca-hsspi.c
> +++ b/drivers/spi/spi-bcmbca-hsspi.c
> @@ -196,6 +196,9 @@ static void bcmbca_hsspi_set_clk(struct bcmbca_hsspi *bs,
>         unsigned int profile = spi_get_chipselect(spi, 0);
>         u32 reg;
>
> +       /* A device with max_speed_hz == 0 must not divide by zero */
> +       hz = max_t(int, hz, 1);
> +
>         reg = DIV_ROUND_UP(2048, DIV_ROUND_UP(bs->speed_hz, hz));
The bs->speed_hz is typcially 200MHz,  reg(Frequency Control Word)
will be zero when hz clamp to 1.  It is not a valid reg setting.  FCW
must be 1 or larger.
The same applies to bcm63xx-hsspi driver.

However IMHO the upper layer should fail the new SPI device request
when its max_speed_hz is set to zero or maybe the spi core should set
it the max clock that the spi conroller can support rather than having
the controller driver to override with a risky 1Hz clock.

>         __raw_writel(CLK_CTRL_ACCUM_RST_ON_LOOP | reg,
>                      bs->regs + HSSPI_PROFILE_CLK_CTRL_REG(profile));

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5473 bytes --]

Re: [PATCH v2 0/5] spi: fix division by zero with a zero transfer speed

[shao.mingyin]

--------------------------------------------------------------------------------
On Tue, Nov 10, 2026 at 04:14:21PM +0000, Mark Brown wrote:
> Oh, I see you also sent those v2 patches as part of the series as
> normal.

Yes -- the two standalone mails from 22:57 were a mistake and are
superseded.  v2 only changes 1/5 (sifive) and 5/5 (atmel); 2/5–4/5 are
unchanged.  Waiting on your review.

Thanks,
Shao
--------------------------------------------------------------------------------

Re: [PATCH v2 3/5] spi: bcmbca-hsspi: fix division by zero for devices without a max speed

[shao.mingyin]

--------------------------------------------------------------------------------
On Tue, Nov 10, 2026 at 12:30:05PM -0800, William Zhang wrote:
> The bs->speed_hz is typcially 200MHz, reg(Frequency Control Word)
> will be zero when hz clamp to 1.  It is not a valid reg setting.  FCW
> must be 1 or larger.
> The same applies to bcm63xx-hsspi driver.

You're right -- with speed_hz ~200 MHz the clamp yields FCW = 0, and
2/5 (bcm63xx) has the same expression.

> IMHO the upper layer should fail ... rather than having the controller
> driver to override with a risky 1Hz clock.

Agreed; the fix belongs upstream of the driver, not in ->set_clk().
Mark, which do you prefer: reject max_speed_hz == 0 in spi core, or
have these two drivers clamp FCW >= 1?  I'll wait for your call and
won't spin a v3 meanwhile.

Thanks,
Shao
--------------------------------------------------------------------------------

Re: [PATCH v2 0/5] spi: fix division by zero with a zero transfer speed

[Mark Brown]

On Tue, 10 Nov 2026 23:34:50 +0800, shao.mingyin@zte.com.cn wrote:
> spi: fix division by zero with a zero transfer speed
> 
> Five SPI controller drivers compute a clock divider from the transfer
> speed without checking that it is non-zero.  A SPI device whose
> max_speed_hz is zero (a DT node without spi-max-frequency, or a device
> created through the spidev sysfs new_device interface without a speed)
> therefore reaches the division with speed_hz == 0.  The SPI core clamps
> such a device to the controller limit only when host->max_speed_hz is
> set, and none of these five drivers sets it.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-7.5

Thanks!

[1/5] spi: sifive: clamp the clock divider to the register range
      https://git.kernel.org/broonie/spi/c/49071cdbecd3
[2/5] spi: bcm63xx-hsspi: fix division by zero for devices without a max speed
      https://git.kernel.org/broonie/spi/c/82ff536b6049
[3/5] spi: bcmbca-hsspi: fix division by zero for devices without a max speed
      https://git.kernel.org/broonie/spi/c/167fe08d3ba5
[4/5] spi: apple: fix division by zero in clock divisor calculation
      https://git.kernel.org/broonie/spi/c/ee22df21fdf4
[5/5] spi: atmel: use the maximum divider for an unspecified speed
      https://git.kernel.org/broonie/spi/c/51953948d6a8

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

Re: [PATCH v2 0/5] spi: fix division by zero with a zero transfer speed

[William Zhang]

[-- Attachment #1: Type: text/plain, Size: 2509 bytes --]

Hi Mark,

On Fri, Nov 13, 2026 at 4:27 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Tue, 10 Nov 2026 23:34:50 +0800, shao.mingyin@zte.com.cn wrote:
> > spi: fix division by zero with a zero transfer speed
> >
> > Five SPI controller drivers compute a clock divider from the transfer
> > speed without checking that it is non-zero.  A SPI device whose
> > max_speed_hz is zero (a DT node without spi-max-frequency, or a device
> > created through the spidev sysfs new_device interface without a speed)
> > therefore reaches the division with speed_hz == 0.  The SPI core clamps
> > such a device to the controller limit only when host->max_speed_hz is
> > set, and none of these five drivers sets it.
> >
> > [...]
>
> Applied to
>
>    https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-7.5
>
> Thanks!
>
> [1/5] spi: sifive: clamp the clock divider to the register range
>       https://git.kernel.org/broonie/spi/c/49071cdbecd3
> [2/5] spi: bcm63xx-hsspi: fix division by zero for devices without a max speed
>       https://git.kernel.org/broonie/spi/c/82ff536b6049
> [3/5] spi: bcmbca-hsspi: fix division by zero for devices without a max speed
>       https://git.kernel.org/broonie/spi/c/167fe08d3ba5
There are still open disucssion in [PATCH v2 3/5].   If we want to add
a clamp in the controller driver,  patch 2 and 3 require extra fix as
discussed in that thread.

> [4/5] spi: apple: fix division by zero in clock divisor calculation
>       https://git.kernel.org/broonie/spi/c/ee22df21fdf4
> [5/5] spi: atmel: use the maximum divider for an unspecified speed
>       https://git.kernel.org/broonie/spi/c/51953948d6a8
>
> All being well this means that it will be integrated into the linux-next
> tree (usually sometime in the next 24 hours) and sent to Linus during
> the next merge window (or sooner if it is a bug fix), however if
> problems are discovered then the patch may be dropped or reverted.
>
> You may get further e-mails resulting from automated or manual testing
> and review of the tree, please engage with people reporting problems and
> send followup patches addressing any issues that are reported if needed.
>
> If any updates are required or you are submitting further changes they
> should be sent as incremental updates against current git, existing
> patches will not be replaced.
>
> Please add any relevant lists and maintainers to the CCs when replying
> to this mail.
>
> Thanks,
> Mark
>

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5473 bytes --]

Re: [PATCH v2 3/5] spi: bcmbca-hsspi: fix division by zero for devices without a max speed

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 645 bytes --]

On Wed, Nov 11, 2026 at 05:36:37PM +0800, shao.mingyin@zte.com.cn wrote:

> > IMHO the upper layer should fail ... rather than having the controller
> > driver to override with a risky 1Hz clock.

> Agreed; the fix belongs upstream of the driver, not in ->set_clk().
> Mark, which do you prefer: reject max_speed_hz == 0 in spi core, or
> have these two drivers clamp FCW >= 1?  I'll wait for your call and
> won't spin a v3 meanwhile.

Ideally the core should do this but that's quite hard to do due to knock
on effects of handling 0 as a default everywhere, together with having a
bunch of existing drivers that don't provide any information.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2 0/5] spi: fix division by zero with a zero transfer speed

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 655 bytes --]

On Fri, Nov 13, 2026 at 04:39:38PM -0800, William Zhang wrote:

> There are still open disucssion in [PATCH v2 3/5].   If we want to add
> a clamp in the controller driver,  patch 2 and 3 require extra fix as
> discussed in that thread.

Ah, I'd missed that subthread sorry.  It does seem like something that
can be dealt with incrementally, none of this should be triggering
unless the system is already pretty confused.  We could do something
like have the driver round the rate up to whatever it's minimum is?
We could also have a min_speed_hz in the core which would help, I
could've sworn we had something already but I'm not immediately finding
it.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2 0/5] spi: fix division by zero with a zero transfer speed

[William Zhang]

[-- Attachment #1: Type: text/plain, Size: 845 bytes --]

On Fri, Nov 13, 2026 at 4:57 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Fri, Nov 13, 2026 at 04:39:38PM -0800, William Zhang wrote:
>
> > There are still open disucssion in [PATCH v2 3/5].   If we want to add
> > a clamp in the controller driver,  patch 2 and 3 require extra fix as
> > discussed in that thread.
>
> Ah, I'd missed that subthread sorry.  It does seem like something that
> can be dealt with incrementally, none of this should be triggering
> unless the system is already pretty confused.  We could do something
> like have the driver round the rate up to whatever it's minimum is?
> We could also have a min_speed_hz in the core which would help, I
> could've sworn we had something already but I'm not immediately finding
> it.
No worry.  Yeah we can set the minimum FCW to 1,  it just can not be zero.

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5473 bytes --]

Re: [PATCH v2 3/5] spi: bcmbca-hsspi: fix division by zero for devices without a max speed

[William Zhang]

[-- Attachment #1: Type: text/plain, Size: 826 bytes --]

On Fri, Nov 13, 2026 at 4:51 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Wed, Nov 11, 2026 at 05:36:37PM +0800, shao.mingyin@zte.com.cn wrote:
>
> > > IMHO the upper layer should fail ... rather than having the controller
> > > driver to override with a risky 1Hz clock.
>
> > Agreed; the fix belongs upstream of the driver, not in ->set_clk().
> > Mark, which do you prefer: reject max_speed_hz == 0 in spi core, or
> > have these two drivers clamp FCW >= 1?  I'll wait for your call and
> > won't spin a v3 meanwhile.
>
> Ideally the core should do this but that's quite hard to do due to knock
> on effects of handling 0 as a default everywhere, together with having a
> bunch of existing drivers that don't provide any information.
In that case,   Mingyin, please update the patch to ensure FCW >=1

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5473 bytes --]

Re: [PATCH v2 3/5] spi: bcmbca-hsspi: fix division by zero for devices without a max speed

[shao.mingyin]

On Sat, Nov 14, 2026 at 09:13:59AM +0800, William Zhang wrote:
> In that case,   Mingyin, please update the patch to ensure FCW >=1

I need to correct my previous reply: I incorrectly agreed that the clamp
gives FCW = 0 with a 200 MHz base clock.  Sorry for the confusion.

The applied code in both drivers is

	hz = max_t(int, hz, 1);

	reg = DIV_ROUND_UP(2048, DIV_ROUND_UP(bs->speed_hz, hz));

For a zero-speed request, the clamp sets hz to 1.  With the 200 MHz base
clock, the calculation is

	DIV_ROUND_UP(200000000, 1) = 200000000
	FCW = DIV_ROUND_UP(2048, 200000000) = 1

The outer division rounds up, which I missed in my previous reply.
The same calculation gives FCW = 1 for 24 MHz and 400 MHz base clocks.

With the 200 MHz base, FCW = 1 corresponds to about 97.7 kHz
(base / 2048), the minimum rate.  The 1 Hz value is an input to the
divider calculation; it does not mean the SPI bus runs at 1 Hz.
For this case, the applied code already selects the minimum FCW.

Mark, understood about the difficulty of handling zero speeds in the
core.  For the 200 MHz case above, the applied driver code already
selects the minimum FCW; any further adjustment would be incremental.

If you would still like an explicit FCW lower bound in both drivers,
I can prepare an incremental patch on top of the applied commits.

Thanks,
Shao

Re: [PATCH v2 3/5] spi: bcmbca-hsspi: fix division by zero for devices without a max speed

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 262 bytes --]

On Sat, Nov 14, 2026 at 02:07:57PM +0800, shao.mingyin@zte.com.cn wrote:

> If you would still like an explicit FCW lower bound in both drivers,
> I can prepare an incremental patch on top of the applied commits.

It might make it clearer that everything is OK.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]