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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx/
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@xxxxxxxxxxx> do, IMNSHO.

thanks,
--
js
suse labs





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux