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

[Hugo Villeneuve <hugo@hugovil.com>]

Hi Biju,

On Wed, 8 Apr 2026 16:35:44 +0000
Biju Das <biju.das.jz@bp.renesas.com> wrote:

> Hi Hugo,
> 
> Thanks for the feedback.
> 
> > -----Original Message-----
> > From: Hugo Villeneuve <hugo@hugovil.com>
> > Sent: 08 April 2026 17:31
> > Subject: Re: [PATCH v2 1/2] serial: sh-sci: Avoid divide-by-zero fault
> > 
> > Hi Biju,
> > 
> > On Wed,  8 Apr 2026 15:20:58 +0100
> > Biju <biju.das.au@gmail.com> wrote:
> > 
> > > From: Biju Das <biju.das.jz@bp.renesas.com>
> > >
> > > 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?

What are other consequences if a zero value is returned apart
from the division by zero fault? Is it ok (or logical) then to proceed
with the rest of the configuration?

> > 
> > 
> > >
> > > Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> > 
> > Missing Fixes tag?
> 
> I will split patch into 2 adding Fixes tag.
> 
> > 
> > 
> > > ---
> > > v2:
> > >  * New patch
> > > ---
> > >  drivers/tty/serial/rsci.c   | 3 ++-
> > >  drivers/tty/serial/sh-sci.c | 3 ++-
> > >  2 files changed, 4 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/tty/serial/rsci.c b/drivers/tty/serial/rsci.c
> > > index b00c9e385169..a0858bab0822 100644
> > > --- a/drivers/tty/serial/rsci.c
> > > +++ b/drivers/tty/serial/rsci.c
> > > @@ -286,7 +286,8 @@ static void rsci_set_termios(struct uart_port *port, struct ktermios *termios,
> > >  	sci_port_enable(s);
> > >  	uart_port_lock_irqsave(port, &flags);
> > >
> > > -	uart_update_timeout(port, termios->c_cflag, baud);
> > > +	if (baud)
> > > +		uart_update_timeout(port, termios->c_cflag, baud);
> > >
> > >  	rsci_serial_out(port, CCR0, ccr0_val);
> > >
> > > diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> > > index 6c819b6b2425..429e89106ee3 100644
> > > --- a/drivers/tty/serial/sh-sci.c
> > > +++ b/drivers/tty/serial/sh-sci.c
> > > @@ -2805,7 +2805,8 @@ static void sci_set_termios(struct uart_port
> > > *port, struct ktermios *termios,
> > >
> > >  	sci_reset(port);
> > >
> > > -	uart_update_timeout(port, termios->c_cflag, baud);
> > > +	if (baud)
> > > +		uart_update_timeout(port, termios->c_cflag, baud);
> > 
> > After this patch, have you re-tested if having baud = 0 produces any other errors? A litle bit later in
> > the same function, there is this
> > code:
> 
> +	/* Avoid divide-by-zero fault in divider operations */
> +	if (!baud)
> +		baud = 100;
> +
> 
> Plan is to update the code with the above change, that will cover
> All divide-by-zero case in this function.

As stated above, does it makes sense to proceed if baud was zero?

> 
> Cheers,
> Biju


-- 
Hugo Villeneuve