Hi David, On 23/02/21 9:53 pm, David Mosberger-Tang wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > 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. > As I understand you are testing with default powersave mode enabled. One approach could be to disable the default powersave mode by compiling with CFG80211_DEFAULT_PS disabled. When its disabled, .set_power_mgmt cb is called with powersave disable. If the powersave mode is enabled, the chip need to be wakeup by following the wakeup sequence. We need to bring in chip_wake() API changes, to set registers specific for WILC1000. I have plans to port these changes to support PSM mode but it will take few weeks. Regards, Ajay > --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. > > >
