Re: [PATCH v3] serial: make uart_console_write->putchar()'s character an unsigned char

[Greg KH <gregkh@linuxfoundation.org>]

On Thu, Mar 03, 2022 at 08:49:44AM +0100, Jiri Slaby wrote:
> On 03. 03. 22, 8:45, Greg KH wrote:
> > On Thu, Mar 03, 2022 at 07:32:59AM +0100, Jiri Slaby wrote:
> > > On 02. 03. 22, 8:27, Jiri Slaby wrote:
> > > > Currently, uart_console_write->putchar's second parameter (the
> > > > character) is of type int. It makes little sense, provided uart_console_write()
> > > > accepts the input string as "const char *s" and passes its content -- the
> > > > characters -- to putchar(). So switch the character's type to unsigned
> > > > char.
> > > > 
> > > > We don't use char as that is signed on some platforms. That would cause
> > > > troubles for drivers which (implicitly) cast the char to u16 when
> > > > writing to the device. Sign extension would happen in that case and the
> > > > value written would be completely different to the provided char. DZ is
> > > > an example of such a driver -- on MIPS, it uses u16 for dz_out in
> > > > dz_console_putchar().
> > > > 
> > > > Note we do the char -> uchar conversion implicitly in
> > > > uart_console_write(). Provided we do not change size of the data type,
> > > > sign extension does not happen there, so the problem is void.
> > > > 
> > > > This makes the types consistent and unified with the rest of the uart
> > > > layer, which uses unsigned char in most places already. One exception is
> > > > xmit_buf, but that is going to be converted later.
> > > 
> > > Kbuild seems to serve me this one by one. So this patch is still incomplete:
> > > > drivers/tty/serial/sunplus-uart.c:526:7: error: incompatible function
> > > pointer types passing 'void (struct uart_port *, int)' to parameter of type
> > > 'void (*)(struct uart_port *, unsigned char)'
> > 
> > Let me just add this to my -testing branch, that will give us much
> > quicker kbuild responses and handle stuff like this easier and I can fix
> > the errors up when they are reported.
> 
> Note this was missed as this driver was added only few days ago, so it was
> not covered by kbuild against my tree until then. And to me, it looks like
> kbuild is run on my tree only when it has nothing better to do (which is
> perfectly fine, as even that catches a lot of things).
> 
> Besides that, there are two places in the driver which need update.
> 
> So should I send a v4 or wait?

If you have a v4 now with this fixed, sure, I'll take that and queue
that one up.

thanks,

greg k-h