[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cebad7f8-3f47-4e6a-93b7-32fcf2367874@kernel.org>
Date: Mon, 22 Apr 2024 07:51:52 +0200
From: Jiri Slaby <jirislaby@...nel.org>
To: neil.armstrong@...aro.org, gregkh@...uxfoundation.org
Cc: linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org,
Al Cooper <alcooperx@...il.com>, Alexander Shiyan <shc_work@...l.ru>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
Alexandre Torgue <alexandre.torgue@...s.st.com>,
Alim Akhtar <alim.akhtar@...sung.com>,
Andrew Morton <akpm@...ux-foundation.org>,
"Aneesh Kumar K.V" <aneesh.kumar@...nel.org>,
AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
Baolin Wang <baolin.wang@...ux.alibaba.com>, Baruch Siach
<baruch@...s.co.il>, Bjorn Andersson <andersson@...nel.org>,
Claudiu Beznea <claudiu.beznea@...on.dev>,
"David S. Miller" <davem@...emloft.net>, Fabio Estevam <festevam@...il.com>,
Hammer Hsieh <hammerh0314@...il.com>,
Christian König <christian.koenig@....com>,
Christophe Leroy <christophe.leroy@...roup.eu>,
Chunyan Zhang <zhang.lyra@...il.com>, Jerome Brunet <jbrunet@...libre.com>,
Jonathan Hunter <jonathanh@...dia.com>, Kevin Hilman <khilman@...libre.com>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
Kumaravel Thiagarajan <kumaravel.thiagarajan@...rochip.com>,
Laxman Dewangan <ldewangan@...dia.com>,
linux-arm-kernel@...ts.infradead.org, linux-arm-msm@...r.kernel.org,
"Maciej W. Rozycki" <macro@...am.me.uk>,
Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
Matthias Brugger <matthias.bgg@...il.com>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
Michael Ellerman <mpe@...erman.id.au>, Michal Simek <michal.simek@....com>,
"Naveen N. Rao" <naveen.n.rao@...ux.ibm.com>,
Nicolas Ferre <nicolas.ferre@...rochip.com>,
Nicholas Piggin <npiggin@...il.com>, Orson Zhai <orsonzhai@...il.com>,
Pali Rohár <pali@...nel.org>,
Patrice Chotard <patrice.chotard@...s.st.com>,
Peter Korsgaard <jacmet@...site.dk>,
Richard Genoud <richard.genoud@...il.com>,
Russell King <linux@...linux.org.uk>, Sascha Hauer <s.hauer@...gutronix.de>,
Shawn Guo <shawnguo@...nel.org>, Stefani Seibold <stefani@...bold.net>,
Sumit Semwal <sumit.semwal@...aro.org>,
Taichi Sugaya <sugaya.taichi@...ionext.com>,
Takao Orito <orito.takao@...ionext.com>,
Tharun Kumar P <tharunkumar.pasumarthi@...rochip.com>,
Thierry Reding <thierry.reding@...il.com>, Timur Tabi <timur@...nel.org>,
Vineet Gupta <vgupta@...nel.org>, Marek Szyprowski <m.szyprowski@...sung.com>
Subject: Re: [PATCH 00/15] tty: serial: switch from circ_buf to kfifo
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@...sung.com> do, IMNSHO.
thanks,
--
js
suse labs
Powered by blists - more mailing lists