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

[Linux regression tracking (Thorsten Leemhuis)]

[Adding a few pople to the list of recipients that were involved in
developing the culprit; also CCing the regression list, as it should be
in the loop for regressions:
https://docs.kernel.org/admin-guide/reporting-regressions.html]

[TLDR: I'm adding this report to the list of tracked Linux kernel
regressions; the text you find below is based on a few templates
paragraphs you might have encountered already in similar form.
See link in footer if these mails annoy you.]

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.

> 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@f0020000 {
>   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.