lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <9cde03a7-1748-4644-bb73-90dd986150dc@cherry.de>
Date: Tue, 21 Jan 2025 11:45:04 +0100
From: Quentin Schulz <quentin.schulz@...rry.de>
To: Łukasz Czechowski <lukasz.czechowski@...umatec.com>
Cc: linux-arm-kernel@...ts.infradead.org, robh@...nel.org,
 krzk+dt@...nel.org, conor+dt@...nel.org, heiko@...ech.de,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] arm64: dts: rockchip: Disable DMA for uart5 on
 px30-ringneck

Hi Łukasz,

On 1/21/25 11:28 AM, Łukasz Czechowski wrote:
> Hi Quentin,
> 
>> On 1/21/25 10:41 AM, Quentin Schulz <quentin.schulz@...rry.de> wrote:
>>
>> Hi Lukasz,
>>
>> On 1/21/25 10:22 AM, Lukasz Czechowski wrote:
>>> UART controllers without flow control seem to behave unstable
>>> in case DMA is enabled. The issues were indicated in the message:
>>> https://lore.kernel.org/linux-arm-kernel/CAMdYzYpXtMocCtCpZLU_xuWmOp2Ja_v0Aj0e6YFNRA-yV7u14g@mail.gmail.com/
>>> In case of PX30-uQ7 Ringneck SoM, it was noticed that after couple
>>> of hours of UART communication, the CPU stall was occurring,
>>> leading to the system becoming unresponsive.
>>> After disabling the DMA, extensive UART communication tests for
>>> up to two weeks were performed, and no issues were further
>>> observed.
>>> The flow control pins for uart5 are not available on PX30-uQ7
>>> Ringneck, as configured by pinctrl-0, so the DMA nodes were
>>> removed on SoM dtsi.
>>>
>>
>> Reviewed-by: Quentin Schulz <quentin.schulz@...rry.de>
>>
>> We should backport this to stable releases too, so please follow the
>> instructions from here:
>> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#select-the-recipients-for-your-patch
>>
>> Essentially:
>>
>> Cc: stable@...r.kernel.org
>>
>> in the commit log and we'll need a
>>
>> Fixes: <commit hash>
>>
>> trailer as well with the commit hash of the commit introducing the issue
>> (likely the one defining uart5 for Ringneck for us).
>>
>> Considering that UART0 CTS and RTS are routed to Q7 header but only
>> usable when Haikou exposes UART0 on the DB9 connector (via the SW2
>> switch), which is NOT the default state (and in any case not supported
>> by our current device tree), I believe we should make the same change to
>> the uart0 node in haikou dts for Ringneck. What do you think? Can you
>> send another patch for that one?
> 
> It seems that in case of uart0, that is configured as kernel console, the DMA
> is not used by the kernel:
> https://lore.kernel.org/linux-serial/20200217114016.49856-7-andriy.shevchenko@linux.intel.com/
> Which is likely why the issue was not observed so far. However it might be
> good to do the same change to be on the safe side.
> Should I extend this patch series with the fix for the Haikou device tree then,
> or create a new one?
> 

Ah, I had missed that one, thanks for the heads up. Just a small remark, 
better send links to merged commits rather than mailing list patches, 
it's a bit more difficult to figure out if the patch (and that version 
of the patch) is merged. If there was an interesting discussion on the 
patch and that information got lost when merging, nice to add the ML 
link though!
In the case of the linked patch, it is merged indeed: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/tty/serial/8250/8250_port.c?id=089b6d36549160b535e109cd07ed6d578b81de46

No, no need to send a patch. When Haikou is configured to have UART0 on 
the DB9 connector (and the Device Tree is adapted for it) and not use it 
as kernel console, we should be able to use hardware flow control and 
not have this issue. So we don't need to remove dmas/dma-names when it's 
used as kernel console, and we don't need to remove them when routed to 
DB9 connector either, so all good :)

Cheers,
Quentin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ