Message ID | CAKd8=GsoKj5eG6VAMkrxMbzNyoBX=JiwafrfXman8xMNK+XU_w@mail.gmail.com (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | SPI regression seen on ARM am335x in kernel 6.12.8 and 6.6.71 | expand |
On Thu, Jan 16, 2025 at 03:21:13PM +0100, Lars Pedersen wrote: > Hi. We have discovered an SPI regression when upgrading from 6.1.99 to > a newer LTS version. Same error on kernel 6.6.71 and 6.12.8. > > I think we have identified the problem down to the reference clock > calculation that seems to end up to zero in the spi-omap2-mcspi > driver. > > Also we think it relates to commit > 4c6ac5446d060f0bf435ccc8bc3aa7b7b5f718ad, where OMAP2_MCSPI_MAX_FREQ > is used as fallback on error. In our case it seems to hit the else > case. > > Snippets for device tree, spi-omap2-mcspi driver and kernel divide by > zero error log with dynamic debug enabled. If you revert the offending commit, does that solve the issue? thanks, greg k-h
On Fri, 17 Jan 2025 at 13:32, Greg KH <gregkh@linuxfoundation.org> wrote: > > On Thu, Jan 16, 2025 at 03:21:13PM +0100, Lars Pedersen wrote: > > Hi. We have discovered an SPI regression when upgrading from 6.1.99 to > > a newer LTS version. Same error on kernel 6.6.71 and 6.12.8. > > > > I think we have identified the problem down to the reference clock > > calculation that seems to end up to zero in the spi-omap2-mcspi > > driver. > > > > Also we think it relates to commit > > 4c6ac5446d060f0bf435ccc8bc3aa7b7b5f718ad, where OMAP2_MCSPI_MAX_FREQ > > is used as fallback on error. In our case it seems to hit the else > > case. > > > > Snippets for device tree, spi-omap2-mcspi driver and kernel divide by > > zero error log with dynamic debug enabled. > > If you revert the offending commit, does that solve the issue? > > thanks, > > greg k-h Hi Greg. No it doesn't solve the issue by reverting the commit. The commit isn't the regression, but it attempts to handle it in the if/else statement. Everything starts to work again if we hard code it to "mcspi->ref_clk_hz = OMAP2_MCSPI_MAX_FREQ;", so it seems like the if else statement isn't 100% foolproof (or we have missed a setting in the device tree). Thanks /Lars Pedersen
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c index 67441b2cd603..8fedfc7db1fa 100644 --- a/drivers/spi/spi-omap2-mcspi.c +++ b/drivers/spi/spi-omap2-mcspi.c @@ -1559,12 +1559,13 @@ static int omap2_mcspi_probe(struct platform_device *pdev) dev_err(&pdev->dev, "Cannot request IRQ"); goto free_ctlr; } - + dev_dbg(&pdev->dev, "DEBUG_EXTRA pre calc\n"); mcspi->ref_clk = devm_clk_get_optional_enabled(&pdev->dev, NULL); if (IS_ERR(mcspi->ref_clk)) mcspi->ref_clk_hz = OMAP2_MCSPI_MAX_FREQ; else mcspi->ref_clk_hz = clk_get_rate(mcspi->ref_clk); + dev_dbg(&pdev->dev, "DEBUG_EXTRA: ref_clk_hz %d\n", mcspi->ref_clk_hz); ctlr->max_speed_hz = mcspi->ref_clk_hz; ctlr->min_speed_hz = mcspi->ref_clk_hz >> 15;