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