Nicolas, On Tue, 2021-02-23 at 18:58 +0100, Nicolas Ferre wrote: > Hi David, > > On 23/02/2021 at 17:23, David Mosberger-Tang wrote: > > 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. > > One thing that comes off the top of my head is that we use > power-sequencing drivers in the Linux4SAM trees. The use of pwrseq > drivers allow us to adapt the power/sequencing/delays/reset to the > actual board the wilc1000 but moreover the wilc3000 is soldered to. > Indeed the wilc3000 needs special sequence to be up'n running if some > clock signals are connected to the SoC output for instance. > > You can have an example of a pwrseq driver here: > drivers/mmc/core/pwrseq_wilc.c > (https://github.com/linux4sam/linux-at91/blob/master/drivers/mmc/core/pwrseq_wilc.c). > There are other pwrseq drivers for other WiFi chips and boards there. > > True thing is that this sequencing seems dedicated to mmc sub-system and > I don't know if it can be used for SPI-based WiFi connections or if > another mechanism exists. Ah, *that's* where the RESET pins are hiding. Yeah, it wouldn't have occurred to me to like in the MMC subsystem, but I see there is a precedent for another WiFi chip using that place. OK, I things are starting to make sense and I should be able to work on the actual patches I've been meaning to submit. Thanks for the help! --david
