Ajay, On Mon, 2021-02-22 at 10:01 +0000, Ajay.Kathat@xxxxxxxxxxxxx wrote: > > On 22/02/21 5:52 am, David Mosberger-Tang wrote: > > So, I'd like to provide some patches for the wilc driver, but I'm > > unclear what the most effective way to go about this is. > > To submit the patches for wilc1000 mainlined driver, please send the > patches to linux-wireless mailing list. Have a look at *submitting > patch* section in wireless wiki to know about the patch submission process. > > Please refer the below link: > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches OK. > > The driver in mainline (driver/net/wireless/microchip/wilc1000) only > > seems to support WILC1000 (not WILC3000) and uses firmware: > > > > atmel/wilc1000_wifi_firmware-1.bin > > > > whereas the linux-at91 driver (driver/staging/wilc1000) supports both > > WILC1000 and WILC3000 and uses firmware > > > > mch/wilc1000_wifi_firmware.bin > > > > (for WILC1000). > > The WILC1000 15.4 firmware(wilc1000_wifi_firmware-1.bin) is available at > linux-firmware repo. > > git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git > > Please use this firmware for your testing. OK, can do. > > For the hardware I have (embedded system with WILC1000/SPI), the > > mainline driver doesn't load, whereas the driver from linux-at91 does > > load and work(mostly). > > What error are you getting during driver loading. Could you please check > if FW file is available at "atmel/wilc1000_wifi_firmware-1.bin" path. OK, the first issue was a trivial one: the mainline driver doesn't appear to support the reset-gpios so, on our platform, the chip remained in RESET and it never responded to anything. Was reset-gpios never supported in the mainline driver or was there a reason to remove that support? Anyhow, I worked around the reset issue. Next problem: from what I can see, wlan.c:chip_allow_sleep() only support SDIO, not SPI. To work around this issue, I just commented out the chip_wakeup()/chip_allow_sleep() calls in acquire_bus() and release_bus() for now. 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. > The mainlined driver only support for WILC1000. WILC3000 chip(Wifi+BT > combo) support needs to be added. Earlier the wilc driver was part of > staging so adding new features were not encouraged but now new features > are welcome. > We need to port different features to the mainlined driver. Recently we > have added the support for WMM[1]. Similarly we need to add other > features(like wilc3000 support) to the mainline driver by following > kernel development guideline. > > 1. https://www.spinics.net/lists/linux-wireless/msg205899.html OK, thanks for the background. That's helpful. --david
