On 11/9/20 8:29 AM, Mark Brown wrote: > On Sat, Nov 07, 2020 at 05:13:51PM +0900, Damien Le Moal wrote: > >> The resting state of MOSI is high when nothing is driving it. If we >> drive it low while recieving, it looks like we are transmitting 0x00 >> instead of transmitting nothing. This can confuse slaves (like SD cards) >> which allow new commands to be sent over MOSI while they are returning >> data over MISO. The return of MOSI from 0 to 1 at the end of recieving >> a byte can look like a start bit and a transmission bit to an SD card. > > If client devices are interpreting the transmitted data then I would > expect the drivers for that hardware to be ensuring that whatever we > transmit matches what the device is expecting. We shouldn't be putting > a hack in a particular controller driver to paper over things, that will > mean that the device will break when used with other controllers and if > different devices have different requirements then obviously we can't > satisfy them. There is not meaningfully a general specification for SPI > which says what happens when signals are idle, it's all specific to the > client device. > > In this case it also looks like the controller hardware requires > transmit data and therefore should be setting SPI_MUST_TX and just > removing the in driver default anyway, though that will have no effect > one way or anther on the issue you're seeing. There is a recieve-only mode, but it is not used by this driver. Perhaps it should be. > Please also try to avoid the use of master/slave terminology where > reasonable, controller and device tend to work for SPI (though MOSI/MISO > are going to be harder to shift). Here I use it to draw distinction between the SPI master and the SPI slave, which are both devices in different contexts. --Sean