linux-kernel - RE: ttyRe: [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:
 <DB9PR04MB84291CE5BAAA2E5FDAFB8E6392212@DB9PR04MB8429.eurprd04.prod.outlook.com>
Date: Wed, 20 Nov 2024 03:14:41 +0000
From: Sherry Sun <sherry.sun@....com>
To: Marco Felsch <m.felsch@...gutronix.de>
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: ttyRe: [PATCH 1/2] dt-bindings: net: bluetooth: nxp: add support
 for supply and reset



> -----Original Message-----
> From: Marco Felsch <m.felsch@...gutronix.de>
> Sent: Tuesday, November 19, 2024 8:52 PM
> 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;
> luiz.dentz@...il.com; robh@...nel.org; krzk+dt@...nel.org;
> conor+dt@...nel.org; p.zabel@...gutronix.de; linux-
> bluetooth@...r.kernel.org; devicetree@...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: ttyRe: [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.

Hi Marco, 
I am not sure if this is a real use case for customers, we just thought of this possibility during internal discussions.
Currently our actual use case is to use both wlan & bt at the same time. Thanks for the clarification, now I am okay with this patch set.

Best Regards
Sherry