Re: xlinix_can: bug when sending two RTR frames

[Oliver Hartkopp <socketcan@hartkopp.net>]

Hi Michal,

On 2/16/23 16:34, Hartley Sweeten wrote:
> On Thursday, February 16, 2023 4:19 AM, Michal Simek wrote:
>>> On 2/7/23 21:45, Oliver Hartkopp wrote:
>>> Hi xilinx_can maintainers,
>>>>
>>>> Hartley Sweeten reported a bug when sending RTR frames with the
>>>> xilinx_can driver here:
>>>>
>>>> https://github.com/linux-can/can-utils/issues/405#
>>>>
>>>> The problem: When sending a single RTR frame (e.g. with 'cansend can0
>>>> 001#R') nothing happens.
>>>>
>>>> Only after sending a *second* RTR frame with 'cansend can0 001#R' the
>>>> two (pending) RTR-frames are sent directly after each other.
>>>>
>>>> This faulty behavior of RTR frame sending is independent of the time
>>>> gap between the two cansend attempts.
>>
>> I read that thread and I am missing details about Zynq board.
>> Are you using any custom zynq board or any xilinx standard evaluation board?
> 
> The system is a Trenz TE0720 SoM on a custom carrier board.
> 
> CAN0 is routed to EMIO.
> 	Tx -> pin E16 (LVCMOS33)
> 	Rx -> pin F16 (LVCMOS33)
> 
> The CAN implementation on the carrier board is like on the ZC702 (TXS0104 buffer / TJA1040T transceiver).
> 
>> Can you please c&p dt fragment you use?
> 
> All of the can@e0008000 node information is from what is created automatically by PetaLinux.
> 
> This is the node info from 'dtc -I fs /sys/firmware/devicetree/base'
> 
>                  can@e0008000 {
>                          compatible = "xlnx,zynq-can-1.0";
>                          clocks = <0x01 0x13 0x01 0x24>;
>                          tx-fifo-depth = <0x40>;
>                          clock-names = "can_clk\0pclk";
>                          status = "okay";
>                          interrupt-parent = <0x04>;
>                          interrupts = <0x00 0x1c 0x04>;
>                          phandle = <0x1a>;
>                          reg = <0xe0008000 0x1000>;
>                          rx-fifo-depth = <0x40>;
>                  };
> 
>> You are using 5.4 kernel which is quite old. Can you please switch to the latest upstream or 5.15 xilinx?
> 
> Uh.. Difficult.
> 
> I'm using PetaLinux 2020.2 right now and _finally_ have something working with it after spending the last year trying to figure it out.
> 
> I'm a bit nervous about installing a newer version of Vivado/Vitis/PetaLinux right now. And I don't know how to make PetaLinux 2020.2 use a different kernel version.
> 

Thanks for picking up this topic!

I double-checked the code and commits from either

- 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/drivers/net/can/xilinx_can.c?h=linux-5.15.y

- 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/drivers/net/can/xilinx_can.c?h=linux-5.4.y

- 
https://github.com/Xilinx/linux-xlnx/blob/xlnx_rebase_v5.15_LTS/drivers/net/can/xilinx_can.c

- xilinx_can.c from the latest 6.2-rc8

And the code sections relevant for this bug report (in the tx path) - 
especially xcan_write_frame() 
https://github.com/Xilinx/linux-xlnx/blob/xlnx_rebase_v5.15_LTS/drivers/net/can/xilinx_can.c#L569 
- do not differ.

So the bug should show up with all the Linux versions and you should be 
able to see it whatever setup you have on your desk.

Best regards,
Oliver