The 1st bug is the same as what reported here: https://devtalk.nvidia.com/default/topic/1002582/chip-select-1-stuck-low-on-spi1/ . This problem might only occur when 2 CSs are used. In my case, they are SPI1_CS0 (pin 18) and SPI1_CS1 (pin 16). One SPI slave keeps CS low prevents the other slave from working correctly in timely fashion.
As shown in the attached picture, the 2nd bug is that in SPI mode 3, the respective timing of CS and CLK are wrong most of the time and are drifting with respect to each other so that reading from SPI slave returns incorrect values most of the time and only returns correct values when the drifting happens to make CS and CLK timing matches the standard timing.
In the attached image, upper trace is SPI0_SCK (pin 23) and lower trace is SPI0_CS0 (pin 24). The expected timing in mode 3 is that CS goes low when SCK is high. In the attached picture, during transfer, SCK frequency is 1MHz.
BTW, spidev_test passed in all modes, and I don’t think spidev_test covers the timing.