On Thu, Nov 03, 2016 at 06:27:39PM +0200, Andy Shevchenko wrote: > upf_t is a bitwise defined type and any assignment from different, but > compatible, types makes static analyzer unhappy. > > drivers/tty/serial/serial_core.c:793:29: warning: incorrect type in assignment (different base types) > drivers/tty/serial/serial_core.c:793:29: expected int [signed] flags > drivers/tty/serial/serial_core.c:793:29: got restricted upf_t [usertype] flags > drivers/tty/serial/serial_core.c:867:19: warning: incorrect type in assignment (different base types) > drivers/tty/serial/serial_core.c:867:19: expected restricted upf_t [usertype] new_flags > drivers/tty/serial/serial_core.c:867:19: got int [signed] flags > > Enforce corresponding types when upf_t being assigned. > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> > --- > drivers/tty/serial/serial_core.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c > index ff90c8e..80002fe 100644 > --- a/drivers/tty/serial/serial_core.c > +++ b/drivers/tty/serial/serial_core.c > @@ -746,7 +746,7 @@ static int uart_get_info(struct tty_port *port, struct serial_struct *retinfo) > if (HIGH_BITS_OFFSET) > retinfo->port_high = (long) uport->iobase >> HIGH_BITS_OFFSET; > retinfo->irq = uport->irq; > - retinfo->flags = uport->flags; > + retinfo->flags = (__force int)uport->flags; Why not make retinfo->flags be upf_t instead of int? > retinfo->xmit_fifo_size = uport->fifosize; > retinfo->baud_base = uport->uartclk / 16; > retinfo->close_delay = jiffies_to_msecs(port->close_delay) / 10; > @@ -820,7 +820,7 @@ static int uart_set_info(struct tty_struct *tty, struct tty_port *port, > new_info->type != uport->type); > > old_flags = uport->flags; > - new_flags = new_info->flags; > + new_flags = (__force upf_t)new_info->flags; same here, why not fix new_flags? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
