As you can see from the output of command "ip show", the clock used by CAN controller changes between "Before" and "After". It's reported in the last printed line, but the missing separator space between the clock value and the text "numtxqueues" makes it hard to read.
Now, the reason for this clock change is that CAN controller and LTDC display controller are by default on the same PLL output.
The display controller has to modify the divider at the output of the PLL to adapt the clock frequency to the display characteristics.
But CAN framework, in Linux, reads the clock frequency during probe and cache it, considering it immutable.
The clock source is not locked by the CAN driver at probe; it is locked only later on when the CAN interface goes UP. Being the clock not locked, the frequency modification requested by LTDC is allowed by the clock framework!
We can say this is a "limitation" (or a real "bug") of the Linux CAN framework. It should read the clock frequency when the interface goes UP.
So CAN driver is probed first, reads the initial clock frequency and keeps it for the next user configuration. Then display is probed, and it changes the clock frequency. The unbind/bind of CAN cause the CAN driver to read again the clock frequency. This explains the workaround!
You can get the full clock tree with the following command at Linux console:
cat /sys/kernel/debug/clk/clk_summary
How to solve it!
The easier way is to use independent clock sources for CAN and LTDC.
The modification that will be published in next deliveries of OpenSTLinux moves CAN to PLL4_R and left the LTDC on PLL4_Q.
In mean time, you can either use the workaround above (it works fine) or you can anticipate the same modifications of OpenSTLinux as follows.
If you use trusted boot, you have to modify the DT in TF-A code:
sed -i s/CLK_FDCAN_PLL4Q/CLK_FDCAN_PLL4R/ fdts/stm32mp1*
If you use basic boot, you have to modify the DT in U-Boot code:
sed -i s/CLK_FDCAN_PLL4Q/CLK_FDCAN_PLL4R/ arch/arm/dts/stm32mp1*
