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
