Re: [PATCH 00/15] tty: serial: switch from circ_buf to kfifo

[Jiri Slaby <jirislaby@kernel.org>]

Hi,

On 19. 04. 24, 17:12, Neil Armstrong wrote:
> On 05/04/2024 08:08, Jiri Slaby (SUSE) wrote:
>> This series switches tty serial layer to use kfifo instead of circ_buf.
>>
>> The reasoning can be found in the switching patch in this series:
>> """
>> Switch from struct circ_buf to proper kfifo. kfifo provides much better
>> API, esp. when wrap-around of the buffer needs to be taken into account.
>> Look at pl011_dma_tx_refill() or cpm_uart_tx_pump() changes for example.
>>
>> Kfifo API can also fill in scatter-gather DMA structures, so it easier
>> for that use case too. Look at lpuart_dma_tx() for example. Note that
>> not all drivers can be converted to that (like atmel_serial), they
>> handle DMA specially.
>>
>> Note that usb-serial uses kfifo for TX for ages.
>> """
...
> This patchset has at least broken all Amlogic and Qualcomm boards so 
> far, only part of them were fixed in next-

So are there still not fixed problems yet?

> but this serie has been 
> merged in v1

Ugh, are you saying that v1 patches are not worth taking? That doesn't 
fit with my experience.

> with no serious testing

Sadly, everyone had a chance to test the series:
   https://lore.kernel.org/all/20240319095315.27624-1-jirislaby@kernel.org/
for more than two weeks before I sent this version for inclusion. And 
then it took another 5 days till this series appeared in -next. But 
noone with this HW apparently cared enough back then. I'd wish they 
(you) didn't. Maybe next time, people will listen more carefully:
===
This is Request for Testing as I cannot test all the changes
(obviously). So please test your HW's serial properly.
===

> and should've been dropped 
> immediately when the first regressions were reported.

Provided the RFT was mostly ignored (anyone who tested that here, or I 
only wasted my time?), how exactly would dropping help me finding 
potential issues in the series? In the end, noone is running -next in 
production, so glitches are sort of expected, right? And I believe I 
smashed them quickly enough (despite I was sidetracked to handle the 
n_gsm issue). But I might be wrong, as usual.

So no, dropping is not helping moving forward, actions taken by e.g. 
Marek Szyprowski <m.szyprowski@samsung.com> do, IMNSHO.

thanks,
-- 
js
suse labs