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:
 <AS4PR04MB9692BC235F0DC401BA391BA7E7212@AS4PR04MB9692.eurprd04.prod.outlook.com>
Date: Wed, 20 Nov 2024 04:44:23 +0000
From: Neeraj Sanjay Kale <neeraj.sanjaykale@....com>
To: Sherry Sun <sherry.sun@....com>, Marco Felsch <m.felsch@...gutronix.de>
CC: Bough Chen <haibo.chen@....com>, POPESCU Catalin
	<catalin.popescu@...ca-geosystems.com>, Amitkumar Karwar
	<amitkumar.karwar@....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

Hi Marco, Catalin,

Thank you for the patch.

> >
> > 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

I think the patch series is an improvement. It looks good to me.

Thanks,
Neeraj