linux-kernel - Re: [PATCH 1/2] dt-bindings: net: bluetooth: nxp: add support for supply and reset

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241119125131.pb5lkeryldsl7htq@pengutronix.de>
Date: Tue, 19 Nov 2024 13:51:31 +0100
From: Marco Felsch <m.felsch@...gutronix.de>
To: Sherry Sun <sherry.sun@....com>
Cc: Bough Chen <haibo.chen@....com>,
	POPESCU Catalin <catalin.popescu@...ca-geosystems.com>,
	Amitkumar Karwar <amitkumar.karwar@....com>,
	Neeraj Sanjay Kale <neeraj.sanjaykale@....com>,
	"marcel@...tmann.org" <marcel@...tmann.org>,
	"luiz.dentz@...il.com" <luiz.dentz@...il.com>,
	"robh@...nel.org" <robh@...nel.org>,
	"krzk+dt@...nel.org" <krzk+dt@...nel.org>,
	"conor+dt@...nel.org" <conor+dt@...nel.org>,
	"p.zabel@...gutronix.de" <p.zabel@...gutronix.de>,
	"linux-bluetooth@...r.kernel.org" <linux-bluetooth@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	GEO-CHHER-bsp-development <bsp-development.geo@...ca-geosystems.com>,
	Krzysztof Kozlowski <krzk@...nel.org>,
	Shenwei Wang <shenwei.wang@....com>, Jun Li <jun.li@....com>
Subject: Re: [PATCH 1/2] dt-bindings: net: bluetooth: nxp: add support for
 supply and reset

On 24-11-19, Sherry Sun wrote:
> 
> > -----Original Message-----
> > From: Marco Felsch <m.felsch@...gutronix.de>
> > 
> > Hi,
> > 
> > gentle ping on this discussion since I'm still convinced that this the correct
> > approach to add the reset mechanism and handle the power.
> 
> Hi Marco,
> 
> Sorry for the late reply. After internal discussion, we still have
> some confusion regarding this new feature.
> This patch do improve the independent handling of wifi/BT, but with
> the controlling granularity segmentation, many different wifi/BT use
> cases need to be considered.

Sure!

> For the case -- WLAN (SDIO) not used + BT (UART) used:
>
> The ideal behavior of BT should be reset and the standalone BT FW
> should be re-downloaded when unloading and re-loading the BT driver.

To make it clear, I assumed that it's clear that independent
(sub-)device handling require independent firmware (fw) files, which can
be the case. NXP already supplies independent FW files for bt and wifi.
We just need to ensure that the drivers are using these.

That said the bt driver already checks if the fw has to be downloaded.

> However, due to the regulator control and PDn reset control are bound
> to the SDIO bus instead of the WLAN device, the SDIO bus may be ready
> after kernel boot up.

Right, but this is a separate discussion not belonging to these driver
changes. Also it's the common chicken-egg issue. You need to power the
bus and release the device-reset before you can check which device is
connected and to check if there would be a proper driver.

> Although the WLAN is not used(WLAN driver is not loaded and WLAN FW is
> not downloaded), the corresponding regulator count and PDn reset count
> are both incremented by 1 through MMC pwrseq. Then with the BT driver
> remove & re-probe, the PDn reset cannot truly reset the BT chip due to
> the count been +1 by MMC pwrseq.  So the BT will not reset and BT FW
> won't be re-downloaded when re-loading the BT driver, right?

You're aware that the btnxpuart.c driver already has the support for an
independent software based reset? Not sure what this sw-reset does, due
to the lack of missing documentation, but this is the only option to
over-come your above mentioned use-case.

I have to ask, is this really a use-case for someone? Either your device
supports both: WLAN and BT or only one of WLAN/BT. If it would be only
BT or WLAN you just don't need the specify the other one within your
devicetree.

Furthermore, this patchset does not break any current use-case you/NXP
has. You still can use the combined fw version and still can use the not
so user friendly user-space dependency of: "wlan driver _must_ be
loaded" before the "bt driver _can_ be loaded" by just not using the
split power handling. For use-space which wants to use the split version
because there is no such dependecy.

Regards,
  Marco