On Mon, Apr 26, 2021 at 11:51:39AM +0000, Sherry Sun wrote: > Hi Greg, > > > > > > drivers/tty/serial/fsl_lpuart.c | 3 +++ > > > > > 1 file changed, 3 insertions(+) > > > > > > > > > > diff --git a/drivers/tty/serial/fsl_lpuart.c > > > > > b/drivers/tty/serial/fsl_lpuart.c index 794035041744..777d54b593f8 > > > > > 100644 > > > > > --- a/drivers/tty/serial/fsl_lpuart.c > > > > > +++ b/drivers/tty/serial/fsl_lpuart.c > > > > > @@ -2414,6 +2414,9 @@ lpuart32_console_get_options(struct > > > > > lpuart_port *sport, int *baud, > > > > > > > > > > bd = lpuart32_read(&sport->port, UARTBAUD); > > > > > bd &= UARTBAUD_SBR_MASK; > > > > > + if (!bd) > > > > > + return; > > > > > > > > How can this ever happen? > > > > > > > > Not to say this is a bad check, but it feels like this can't really > > > > happen in real life, what code patch could create this result? > > > > > > > > And have you tested this on real hardware? > > > > > > > > > > Thanks for the reviewing, yes, I have tested the patchset on the real > > hardware. > > > > > > Seems the coverity check is static scan, so cannot judge if UARTBAUD > > Register will be zero. > > > I just found below statement in the uart reference manual: "When SBR is 1 > > - 8191, the baud rate equals "baud clock / ((OSR+1) × SBR)"." > > > Since I am not familiar with uart, do you mean that the value of UARTBAUD > > Register will never be zero, so this case will not happen in real word? > > > > Given that this never has happened with hardware for such an old device, > > perhaps it is impossible. But it would be good to check. > > > > > If yes, I will drop this patch. > > > > Handling "bad data" from hardware is never a bad idea, so I don't > > necessarily want to drop this patch, I just want to try to figure out if this is a > > "incase the hardware is broken/malicious" type of change, vs. > > a "this bug we are seeing in real hardware" type of change. > > > > Yes, you are right, the probability of hardware happen in this case is really low. But we cannot guarantee that it will never happen. > So will this check here be accepted? Thanks! Please resubmit it with a better changelog description summarizing the discussion here to make it more obvious why this change is needed. thanks, greg k-h
