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

[Maciej W. Rozycki]

On Thu, 3 Mar 2022, 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.

 For:

>  drivers/tty/serial/dz.c                    | 2 +-

DECstation DZ serial driver version 1.04
ttyS0 at MMIO 0x1c000000 (irq = 4, base_baud = 0) is a DZ
ttyS1 at MMIO 0x1c000000 (irq = 4, base_baud = 0) is a DZ
ttyS2 at MMIO 0x1c000000 (irq = 4, base_baud = 0) is a DZ
ttyS3 at MMIO 0x1c000000 (irq = 4, base_baud = 0) is a DZ

(I guess I ought to make it report "base_baud = 9600" though there is no 
programmable clock divider there and instead there is simply a 15-way rate 
selector for standard baud rates of up to 9600bps in addition to external 
clocking chosen with the 16th setting), and:

>  drivers/tty/serial/sb1250-duart.c          | 2 +-

duart0 at MMIO 0x10060100 (irq = 8, base_baud = 5000000) is a SB1250 DUART
duart1 at MMIO 0x10060200 (irq = 9, base_baud = 5000000) is a SB1250 DUART

(this does require some TLC though as there's a "refcount_t: saturated; 
leaking memory." warning issued in driver's initialisation) and:

>  drivers/tty/serial/zs.c                    | 2 +-

DECstation Z85C30 serial driver version 0.10
ttyS0 at MMIO 0x1f900008 (irq = 14, base_baud = 460800) is a Z85C30 SCC
ttyS1 at MMIO 0x1f900000 (irq = 14, base_baud = 460800) is a Z85C30 SCC
ttyS2 at MMIO 0x1f980008 (irq = 15, base_baud = 460800) is a Z85C30 SCC
ttyS3 at MMIO 0x1f980000 (irq = 15, base_baud = 460800) is a Z85C30 SCC

Acked-by: Maciej W. Rozycki <macro@xxxxxxxxxxx>
Tested-by: Maciej W. Rozycki <macro@xxxxxxxxxxx>

 However please consider my notes in the branch of discussion with David 
too WRT (not) changing the signedness.

 Myself I'll look into GCC and see why it doen't fold the truncation into
the load operation.  Maybe just a MIPS backend issue, such as a missing 
RTL pattern the lack of which prevents combine from doing its job here.  
Any fix will have to wait a couple of months for upstreaming though as the 
compiler is currently at a stage where regression fixes are accepted only 
for the upcoming GCC 12 release, so no general development is allowed on 
trunk.

 Thank you for working on this!

  Maciej