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

[Hugo Villeneuve <hugo@hugovil.com>]

On Thu, 1 Oct 2026 12:46:05 +0300 (EEST)
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> wrote:

> 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.

Hi all,
is it at all possible that old is out of bounds in the first place? If
yes, is it something that should be fixed?

> 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.

Then should the "return 0" statement be modified to "return baud", and
possibly the WARN_ON() removed? Then you wouldn't need to increase
max try?


-- 
Hugo Villeneuve