When the 'clock-frequency' property is missing from the device tree,
the driver falls back to DAVINCI_I2C_DEFAULT_BUS_FREQ. However, this
macro is defined in kHz (100), whereas the device tree property is
expected in Hz.

The probe function blindly divided the fallback value by 1000, causing
integer truncation that resulted in dev->bus_freq = 0. This triggered
a deterministic division-by-zero kernel panic when calculating clock
dividers later in the probe sequence.

Fix this by isolating the division so it only applies to the Hz value
read from the device tree, cleanly assigning the kHz default otherwise.

Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260514044726.57297C2BCB7@smtp.kernel.org/
Signed-off-by: Chaitanya Sabnis <chaitanya.msabnis@gmail.com>
---
 drivers/i2c/busses/i2c-davinci.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index a773ba082321..bd0754abdcb7 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -760,9 +760,9 @@ static int davinci_i2c_probe(struct platform_device *pdev)
 
 	r = device_property_read_u32(&pdev->dev, "clock-frequency", &prop);
 	if (r)
-		prop = DAVINCI_I2C_DEFAULT_BUS_FREQ;
-
-	dev->bus_freq = prop / 1000;
+		dev->bus_freq = DAVINCI_I2C_DEFAULT_BUS_FREQ;
+	else
+		dev->bus_freq = prop / 1000;
 
 	dev->has_pfunc = device_property_present(&pdev->dev, "ti,has-pfunc");
 
-- 
2.43.0

On Thu, May 14, 2026 at 04:07:40PM +0530, Chaitanya Sabnis wrote:
> When the 'clock-frequency' property is missing from the device tree,
> the driver falls back to DAVINCI_I2C_DEFAULT_BUS_FREQ. However, this
> macro is defined in kHz (100), whereas the device tree property is
> expected in Hz.
> 
> The probe function blindly divided the fallback value by 1000, causing
> integer truncation that resulted in dev->bus_freq = 0. This triggered
> a deterministic division-by-zero kernel panic when calculating clock
> dividers later in the probe sequence.
> 
> Fix this by isolating the division so it only applies to the Hz value
> read from the device tree, cleanly assigning the kHz default otherwise.

Why not keep the patch simple and just change the value of
DAVINCI_I2C_DEFAULT_BUS_FREQ to Hz?

> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Closes: https://lore.kernel.org/all/20260514044726.57297C2BCB7@smtp.kernel.org/
> Signed-off-by: Chaitanya Sabnis <chaitanya.msabnis@gmail.com>

Please also added a Fixes: tag.

       Andrew

Hi Andrew,

That makes complete sense. Updating the macro to Hz is a much cleaner
approach and aligns perfectly with the expected unit of the device
tree property.

I have track down the original commit for the Fixes: tag and send out a v2.

Thanks for the review!
Chaitanya


On Thu, May 14, 2026 at 5:46 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Thu, May 14, 2026 at 04:07:40PM +0530, Chaitanya Sabnis wrote:
> > When the 'clock-frequency' property is missing from the device tree,
> > the driver falls back to DAVINCI_I2C_DEFAULT_BUS_FREQ. However, this
> > macro is defined in kHz (100), whereas the device tree property is
> > expected in Hz.
> >
> > The probe function blindly divided the fallback value by 1000, causing
> > integer truncation that resulted in dev->bus_freq = 0. This triggered
> > a deterministic division-by-zero kernel panic when calculating clock
> > dividers later in the probe sequence.
> >
> > Fix this by isolating the division so it only applies to the Hz value
> > read from the device tree, cleanly assigning the kHz default otherwise.
>
> Why not keep the patch simple and just change the value of
> DAVINCI_I2C_DEFAULT_BUS_FREQ to Hz?
>
> > Reported-by: Sashiko <sashiko-bot@kernel.org>
> > Closes: https://lore.kernel.org/all/20260514044726.57297C2BCB7@smtp.kernel.org/
> > Signed-off-by: Chaitanya Sabnis <chaitanya.msabnis@gmail.com>
>
> Please also added a Fixes: tag.
>
>        Andrew

On Fri, May 15, 2026 at 02:12:43PM +0530, Chaitanya Sabnis wrote:
> Hi Andrew,
> 
> That makes complete sense. Updating the macro to Hz is a much cleaner
> approach and aligns perfectly with the expected unit of the device
> tree property.
> 
> I have track down the original commit for the Fixes: tag and send out a v2.
> 
> Thanks for the review!

Please don't top post on mailing lists.

       Andrew