OK, the problem below is caused by wilc_set_power_mgmt(). If I change that function into a no-op, the driver actually works! Does this make any sense to you? From what I saw so far, it looks like relevant code is pretty much identical to the one in the linux-at91 tree and that one works fine. --david On Mon, 2021-02-22 at 18:49 -0700, David Mosberger-Tang wrote: > > Now the driver loads the firmware and generally seems to be happy. > However, as soon as a packet is received, things go awry. I'm seeing > this: > > WILC_SPI spi1.0 wlan0: ChipID [1003a0] loading firmware > [atmel/wilc1000_wifi_firmware-1.bin] > WILC_SPI spi1.0: Failed cmd response, cmd (ca), resp (09) > > On the SPI bus, I see these commands: > > MOSI: 0xC8 0x00 0x00 0x00 0x00 0x00 0x38 (DMA_EXT_READ addr 0 size 56) > MISO: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xC8 0x88 (command response) > ----- > MOSI: 0x00 > MISO: 0xF3 (DATA header, last packet in this transaction) > ----- > MOSI: 0x00*56 > MISO: xx*56 (56 data bytes that may be a legitimate packet) > > So far so good. I don't know if this matters, but the last 8 bytes of > data all contain 0x09. > > The problem from then on is that no matter what command is sent, the > chip always returns only 0x09 bytes. For example, the first command > after the DMA read is: > > MOSI: 0xca 0x00 0x10 0x6c (SINGLE_READ) > > but the MISO line only returns 0x09, hence the above "Failed cmd > response" error. > > It's as if the chip wants to send much more than 56 data bytes. The > byte-order for the DMA size matches that of the working driver though, > so maybe that's not it.
