linux-kernel - Re: dmaengine: at_hdmac: Regression regarding rs485 via dma in v5.4

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: <dafe0626-b949-0c04-de50-b74c93b66250@leemhuis.info>
Date:   Mon, 22 May 2023 15:24:22 +0200
From:   Thorsten Leemhuis <regressions@...mhuis.info>
To:     Kristof Havasi <havasiefr@...il.com>
Cc:     Linux kernel regressions list <regressions@...ts.linux.dev>,
        LKML <linux-kernel@...r.kernel.org>,
        Vinod Koul <vkoul@...nel.org>, dmaengine@...r.kernel.org,
        Peter Rosin <peda@...ntia.se>,
        Nicolas Ferre <nicolas.ferre@...rochip.com>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        tudor.ambarus@...rochip.com
Subject: Re: dmaengine: at_hdmac: Regression regarding rs485 via dma in v5.4

On 04.05.23 11:11, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 04.04.23 13:25, Linux regression tracking (Thorsten Leemhuis) wrote:
>> On 29.03.23 16:31, Kristof Havasi wrote:
>>>
>>> I was rebasing the Kernel branch of our SAMA5D35 based board from
>>> v5.4.189 to v5.4.238.
>>> I noticed that after the rebase we could _only send, but not receive_
>>> through our RS485 interface.
>>>
>>> I could bisect the problem to 77b97ef4908aa917e7b68667ec6b344cc5dc5034
>>> in the v5.4.225 release. 
>>
>> FWIW, that's 7176a6a8982d ("dmaengine: at_hdmac: Don't start
>> transactions at tx_submit level") in mainline.
>>
>> Kristof Havasi: would be good to know if this is something that happens
>> with recent mainline as well, because if not it might be something the
>> stable team needs to handle.
> 
> Kristof, any news? Doesn't look like it from here, but maybe I'm missing
> something.
> 
> And did you try what I suggested? Without trying that it looks like
> neither the mainline developers nor the stable team cares enough to look
> into your report, as both sides might assume it's the other sides duty
> to do so.

Hmmm, still no update from . This is unfortunate, as without Kristof's
help the kernel developers are likely unable to get down to this and
provide a fix. That's why I'm dropping it from the tracking now.

#regzbot inconclusive: reporter apparently lost interest

Ciao, Thorsten

>>> If I revert this commit, the tx/rx works just
>>> like before.
>>> Maybe this use-case wasn't considered when this patch was created?
>>> I haven't seen a documentation change regarding this in DT bindings,
>>> but if the config should be something else, please let me know.
>>> Otherwise this commit breaks the RS485 function of atmel_serial at
>>> least in the v5.4.y branch.
>>>
>>> Best Regards,
>>> Kristóf Havasi
>>>
>>> The relevant device tree nodes:
>>>
>>> from sama5d3.dtsi:
>>>
>>> usart1: serial@...20000 {
>>>   compatible = "atmel,at91sam9260-usart";
>>>   reg = <0xf0020000 0x100>;
>>>   interrupts = <13 IRQ_TYPE_LEVEL_HIGH 5>;
>>>   dmas = <&dma0 2 AT91_DMA_CFG_PER_ID(5)>,
>>>   <&dma0 2 (AT91_DMA_CFG_PER_ID(6) | AT91_DMA_CFG_FIFOCFG_ASAP)>;
>>>   dma-names = "tx", "rx";
>>>   pinctrl-names = "default";
>>>   pinctrl-0 = <&pinctrl_usart1>;
>>>   clocks = <&usart1_clk>;
>>>   clock-names = "usart";
>>>   status = "disabled";
>>> };
>>>
>>> pinctrl_usart1: usart1-0 {
>>>   atmel,pins =
>>>   <AT91_PIOB 28 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
>>>    AT91_PIOB 29 AT91_PERIPH_A AT91_PINCTRL_NONE>;
>>> };
>>> pinctrl_usart1_rts_cts: usart1_rts_cts-0 {
>>>   atmel,pins =
>>>   <AT91_PIOB 26 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB26 periph A,
>>> conflicts with GRX7 */
>>>    AT91_PIOB 27 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PB27 periph A,
>>> conflicts with G125CKO */
>>> };
>>>
>>> from our dts:
>>>
>>> &usart1 {
>>>   pinctrl-0 = <&pinctrl_usart1 &pinctrl_usart1_rts_cts>;
>>>   atmel,use-dma-rx;
>>>   atmel,use-dma-tx;
>>>   rs485-rx-during-tx;
>>>   linux,rs485-enabled-at-boot-time;
>>>   status = "okay";
>>> };
>>>
>>> HW:
>>> The SAMA5D3's PB27 is connected to the |RE+DE of the RS485 transceiver
>>> SP3458EN-L
>>
>>
>> Thanks for the report. To be sure the issue doesn't fall through the
>> cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression
>> tracking bot:
>>
>> #regzbot ^introduced 77b97ef4908aa
>> #regzbot title dmaengine: at_hdmac: receiving data through the RS485
>> interface broke
>> #regzbot ignore-activity
>>
>> This isn't a regression? This issue or a fix for it are already
>> discussed somewhere else? It was fixed already? You want to clarify when
>> the regression started to happen? Or point out I got the title or
>> something else totally wrong? Then just reply and tell me -- ideally
>> while also telling regzbot about it, as explained by the page listed in
>> the footer of this mail.
>>
>> Developers: When fixing the issue, remember to add 'Link:' tags pointing
>> to the report (the parent of this mail). See page linked in footer for
>> details.
>>
>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>> --
>> Everything you wanna know about Linux kernel regression tracking:
>> https://linux-regtracking.leemhuis.info/about/#tldr
>> That page also explains what to do if mails like this annoy you.
>>
>>