Date:   Thu, 3 Mar 2022 08:49:44 +0100
From:   Jiri Slaby <jslaby@...e.cz>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org,
        Richard Genoud <richard.genoud@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Tobias Klauser <tklauser@...tanz.ch>,
        Paul Cercueil <paul@...pouillou.net>,
        Russell King <linux@...linux.org.uk>,
        Vineet Gupta <vgupta@...nel.org>,
        Nicolas Ferre <nicolas.ferre@...rochip.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Ludovic Desroches <ludovic.desroches@...rochip.com>,
        bcm-kernel-feedback-list@...adcom.com,
        Alexander Shiyan <shc_work@...l.ru>,
        Baruch Siach <baruch@...s.co.il>,
        "Maciej W. Rozycki" <macro@...am.me.uk>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        NXP Linux Team <linux-imx@....com>,
        Karol Gugala <kgugala@...micro.com>,
        Mateusz Holenko <mholenko@...micro.com>,
        Vladimir Zapolskiy <vz@...ia.com>,
        Neil Armstrong <narmstrong@...libre.com>,
        Kevin Hilman <khilman@...libre.com>,
        Jerome Brunet <jbrunet@...libre.com>,
        Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
        Taichi Sugaya <sugaya.taichi@...ionext.com>,
        Takao Orito <orito.takao@...ionext.com>,
        Liviu Dudau <liviu.dudau@....com>,
        Sudeep Holla <sudeep.holla@....com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Andreas Färber <afaerber@...e.de>,
        Manivannan Sadhasivam <mani@...nel.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
        Orson Zhai <orsonzhai@...il.com>,
        Baolin Wang <baolin.wang7@...il.com>,
        Chunyan Zhang <zhang.lyra@...il.com>,
        Patrice Chotard <patrice.chotard@...s.st.com>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Alexandre Torgue <alexandre.torgue@...s.st.com>,
        "David S. Miller" <davem@...emloft.net>,
        Peter Korsgaard <peter@...sgaard.com>,
        Michal Simek <michal.simek@...inx.com>
Subject: Re: [PATCH v3] serial: make uart_console_write->putchar()'s character
 an unsigned char

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?

thanks,
-- 
js
suse labs

Powered by blists - more mailing lists