[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.
