Re: [PATCH v2 1/2] serial: sh-sci: Avoid divide-by-zero fault

[Geert Uytterhoeven]

Hi Biju,

On Wed, 8 Apr 2026 at 19:25, Biju Das <biju.das.jz@xxxxxxxxxxxxxx> wrote:
> > From: Hugo Villeneuve <hugo@xxxxxxxxxxx>
> > On Wed, 8 Apr 2026 16:35:44 +0000
> > Biju Das <biju.das.jz@xxxxxxxxxxxxxx> wrote:
> > > > From: Hugo Villeneuve <hugo@xxxxxxxxxxx>
> > > > Biju <biju.das.au@xxxxxxxxx> wrote:
> > > > > From: Biju Das <biju.das.jz@xxxxxxxxxxxxxx>
> > > > >
> > > > > uart_update_timeout() computes a timeout value by dividing by the
> > > > > baud rate. If baud is zero — which can occur when the hardware
> > > > > returns an unsupported or invalid rate — this results in a divide-by-zero fault.
> > > >
> > > > baud is returned by uart_get_baud_rate(), so this is not returned by the hardware?
> > >
> > > You are tight, Will update commit description.
> >
> > How can uart_get_baud_rate() return a zero value? If I am not mistaken even for the B0 case, it will
> > return 9600?
>
> As per the comment and code, this API can return 0.
>
> * If the new baud rate is invalid, try the @old termios setting. If it's still
> * invalid, we try 9600 baud. If that is also invalid 0 is returned.
>
> In drives/tty currently only 1 driver is checking the return value
> and it calls panic
>
> https://elixir.bootlin.com/linux/v7.0-rc7/source/drivers/tty/serial/apbuart.c#L214
>
>
> I believe we should call panic, if baud =0, instead of proceeding.
>
> Geert, any thoughts??

IIRC, baud == 0 can (only?) happen when using earlyprintk on a non-DT
system, where the serial console should just keep on using the settings
programmed by the firmware.  So any config register writes should
be skipped.

On DT systems, even earlycon uses the bitrate from chosen/stdout-path.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds