Re: [PATCH v7 1/2] serial: core: fix baud rate fallback in uart_get_baud_rate()

["Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>]

On Thu, 1 Oct 2026, Greg Kroah-Hartman wrote:

> On Wed, Sep 30, 2026 at 12:59:00PM +0000, Hui Peng wrote:
> > When uart_get_baud_rate() is called with a baud rate exceeding the port's
> > maximum supported speed (port->uartclk / 16), it clips baud to [min,
> > max - 1] and encodes it into termios via tty_termios_encode_baud_rate().
> > 
> > However, because the loop bound is for (try = 0; try < 2; try++), the
> > loop terminates immediately after try == 1 without re-evaluating
> 
> But try == 1 should keep the loop going as it is < 2, right?  What am I
> missing here?  Do I need more coffee?
>
> > baud = tty_termios_baud_rate(termios) for the clipped rate, hitting
> > WARN_ON(1) and returning 0, which then triggers a fatal divide-by-zero
> > (Oops: divide error) in uart_get_divisor():
> > 
> >   WARNING: drivers/tty/serial/serial_core.c:548 at uart_get_baud_rate+0x136/0x260
> >   [ ... ]
> >   divide error: 0000 [#1] PREEMPT SMP KASAN
> > 
> > Increase the retry count in uart_get_baud_rate() from 2 to 3 iterations so
> > that clipped baud rates are re-evaluated in the third iteration.
> 
> What is the magic 2 here, and why turning it into a magic 3 somehow fix
> things?

Hi Greg & Hui,

First of all, I'm withdrawing my Reviewed-by from this!!!

Lets hope the submitter can finally get his/her act together and not make 
unlisted changes between versions or send non-sense.

While the code change is still fine, it seems the submitter (or more 
likely AI) has changed the changelog from what I read when I reviewed 
this. And the new one is way worse than it used to be so not being able 
to follow what's going on is very understandable given the lackluster 
explanation that remains.


What you're missing is that the baud returns happens within the loop, so:

try == 0: use new, if baud is out of bound and old is available, switch to 
          old
try == 1: if old is also out of bounds, there's the last resort rule 
          towards the end of the loop which is applied forcing baud to the 
          accetable range.
try == 2: loop exits => WARN_ON(1) triggers.

What we'd want to happen with try == 2, is for it to use the return baud 
which is within the loop body.


Hui, I suggest keeping the previous versions of the patches available as 
files. And right before sending the next version, go manually throught the 
diff of diffs to make sure there are ZERO unexpected changes from version 
to version (has saved me tons of times from making stupid mistakes).


-- 
 i.