Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <5fc9c8ad5d93e2172f03515f8275851af285a895.camel@egauge.net>
Subject: Re: wilc1000 driver
From:   David Mosberger-Tang <davidm@egauge.net>
To:     Ajay.Kathat@microchip.com, linux-wireless@vger.kernel.org
Date:   Tue, 23 Feb 2021 09:23:04 -0700
In-Reply-To: <f3e0540462ed8bcc59787f71e3b1b258945a6142.camel@egauge.net>
References: <e8ed97f214f6087b7ac59298c8efe2d1144f7d55.camel@egauge.net>
         <eb6c6b39-f168-7237-d220-585f99532fd9@microchip.com>
         <f3e0540462ed8bcc59787f71e3b1b258945a6142.camel@egauge.net>
Organization: eGauge Systems LLC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.36.4-0ubuntu1 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

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.