On Mon, 2024-01-22 at 16:57 +0000, Ajay.Kathat@xxxxxxxxxxxxx wrote: > On 1/19/24 14:51, David Mosberger-Tang wrote: > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > > > The current version of the wilc1000 driver has a probe function that simply > > assumes the chip is present. It is only later, in wilc_spi_init(), that the > > driver verifies that it can actually communicate with the chip. The result of > > this is that the net device (typically wlan0) is created and remains in place as > > long as the wilc1000-spi driver is loaded, even if the WILC1000 chip is not > > present or not working. > > > > Is there any reason not to detect the chip's present in wilc_bus_probe()? The > > patch below (relative to 5.15.147) works for me, but perhaps I'm missing > > something? Would it make sense to merge something along these lines into > > mainline? > > > > I think it is the WILC driver design that the firmware/chip operations > are executed only when the netdev interface(wlan0) is up. The firmware > is started only after the interface is up. However, it should be okay to > read the register values since the bus interface is up. Yep, I didn't see any issues in my testing. > As I understand, this condition is raised since the auto-load started to > work after the patch[1], now the driver is getting loaded at the boot-up > time. > Actually, the auto-detect(hot-plug) for SPI bus can't be supported like > the SDIO bus where the driver gets loaded/unloaded when the device is > connected/removed. In case of SPI devices, the driver probe will be > called at the boot-up time based on the Device-tree(DT) entry. If the > SPI device is connected after board boot-up, the board reboot is > required for probe function to get called i.e. even wilc_bus_probe() > returns failure for first time then the probe will not get called again. > One way to handle this is by modifying the DT entry of the system to > define whether the SPI device is connected or not. Makes sense. In our system, we don't have the ability to dynamically patch the device tree so we rely on driver probing to confirm that a device actually exists. --david
