linux-kernel - Re: [PATCH 0/4] serial: 8250: Fixes for Oxford Semiconductor 950 UARTs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 15 Jun 2021 17:52:05 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     "Maciej W. Rozycki" <macro@...am.me.uk>
Cc:     Jiri Slaby <jirislaby@...nel.org>, linux-serial@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/4] serial: 8250: Fixes for Oxford Semiconductor 950
 UARTs

On Tue, Jun 15, 2021 at 04:19:03PM +0200, Maciej W. Rozycki wrote:
> On Tue, 15 Jun 2021, Greg Kroah-Hartman wrote:
> 
> > This patch series causes the following build warning to be added:
> > 
> > drivers/tty/serial/8250/8250_pci.c: In function ‘pci_oxsemi_tornado_setup’:
> > drivers/tty/serial/8250/8250_pci.c:1258:32: warning: unsigned conversion from ‘int’ to ‘unsigned char’ changes value from ‘-129’ to ‘127’ [-Woverflow]
> >  1258 |                 up->mcr_mask = ~UART_MCR_CLKSEL;
> >       |                                ^
> > 
> > 
> > Can you fix this up and resend?
> 
>  I've seen that, but that's not a problem with my change, but rather with 
> <linux/serial_reg.h> making this macro (and the remaining ones from this 
> group) expand to a signed constant (0x80 rather than 0x80u).

As your change causes it to show up, it must have something to do with
it :)

>  I can fix the header, but that would be a separate change, and mind too 
> that this is a user header, so it's not clear to me what the impact might 
> be on user apps making use of it.

You can not change the uapi header, why would you want to?

>  We could use a GCC pragma to suppress the warning temporarily across this 
> piece of code, but it's not clear to me either what our policy has been on 
> such approach.

What pragma?

>  Thoughts?

Why does your change cause this to show up?

>  NB casting UART_MCR_CLKSEL here to an unsigned type does not help as GCC
> still sees the original constant through the cast; I've already tried that 
> of course.
> 
>  Last but not least: do we need to have this warning enabled in the first 
> place?

No idea, but that's a different discussion, with a different group of
people :)

thanks,

greg k-h