Received-SPF: pass (google.com: domain of linux-wireless+bounces-2348-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Message-ID: <3e496666cf293c97ff92ebea2a86449878beb346.camel@egauge.net>
Subject: Re: RFQ: wifi: wilc1000: make wilc1000-spi bus-probe useful
From: David Mosberger-Tang <davidm@egauge.net>
Date: Mon, 22 Jan 2024 20:44:48 +0000 (UTC)
In-Reply-To: <1776feff-0886-4db8-896c-c542d3e626b0@microchip.com>
References: <90fb762e5840f9d5a6ae46f81692fb947a7796a4.camel@egauge.net>
	 <1776feff-0886-4db8-896c-c542d3e626b0@microchip.com>
Organization: eGauge Systems LLC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.4-0ubuntu2 
Precedence: bulk
MIME-Version: 1.0
To: Ajay.Kathat@microchip.com
Cc: linux-wireless@vger.kernel.org, kvalo@kernel.org

On Mon, 2024-01-22 at 16:57 +0000, Ajay.Kathat@microchip.com 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
> >=20
> > The current version of the wilc1000 driver has a probe function that si=
mply
> > 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 res=
ult 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.
> >=20
> > 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 missin=
g
> > something? Would it make sense to merge something along these lines int=
o
> > mainline?
> >=20
>=20
> 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