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: <20241028150048.qnqjxntns6quy7py@pengutronix.de>
Date: Mon, 28 Oct 2024 16:00:48 +0100
From: Marco Felsch <m.felsch@...gutronix.de>
To: Sherry Sun <sherry.sun@....com>
Cc: 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>
Subject: Re: [PATCH 1/2] dt-bindings: net: bluetooth: nxp: add support for
 supply and reset

On 24-10-28, Sherry Sun wrote:
> 
> > From: Marco Felsch <m.felsch@...gutronix.de>
> > 
> > On 24-10-28, Sherry Sun wrote:
> > >
> > > > From: Marco Felsch <m.felsch@...gutronix.de>
> > > >
> > > > Hi,
> > > >
> > > > On 24-10-28, Sherry Sun wrote:
> > > > >
> > > > > > From: POPESCU Catalin <catalin.popescu@...ca-geosystems.com>
> > > > > >
> > > > > > We use the NXP downstream driver mwifiex which doesn't have
> > > > > > support for regulator or PDn.
> > > > > >
> > > > > > However, regulator is already supported by the MMC core (vmmc-
> > supply).
> > > > > >
> > > > > > For PDn, we use mmc pwrseq simple driver that has been patched
> > > > > > to add support for reset-control.
> > > > >
> > > > > Ok, thanks, the mmc change looks good for me, so there is no
> > > > > problem with the NXP SDIO wifi.
> > > > >
> > > > > But how do you plan to handle the NXP PCIe wifi? We also need to
> > > > > make sure the BT patch won't break the PCIe wifi function.
> > > >
> > > > Can you please elaborate how this could break the PCIe use-case?
> > >
> > > Similar to the SDIO wifi, if no corresponding reset control for the
> > > PDn pin in PCIe wifi driver, the wifi part will be unexpectedly
> > > powered off when removing the BT driver.
> > 
> > Nope it's not that easy for PCIe case since the phy + link layer handling is
> > much more complex compared to the MMC case. For the PCIe case the intial
> > handling is very strict according to the PCIe spec and we can't handle the BT
> > device independently.
> > 
> > _BUT_ this patch doesn't cause any regression for the PCIe use-case since the
> > support added by Catalin is optional which means that the user don't have to
> > use these options.
> > 
> > To sum up:
> > 
> > WLAN (PCIe) used + BT (UART) used -> no independent handling
> >                                      possible. BT depends on WLAN.
> > 
> > WLAN (PCIe) not used + BT (UART) used -> This patchset allow us to
> >                                          handle BT. Without the patchset
> > 					 this is not possible.
> > 
> > WLAN (SDIO) + BT (UART) -> This patchset and the mmc-power-seq patchset
> >                            allow us to handle WLAN and BT independently
> > 			   regardless if BT or WLAN is used or not.
> 
> If we add the reset-gpios property in the BT dts node when using the
> SDIO wifi chip, my concern is for some host platforms, taking
> i.MX95-19x19-EVK as an example, it supports both SDIO and PCIe
> interface wifi chip through the M.2 connector, when customers want to
> plug in the PCIe wifi chip, they have to remove the reset-gpios in the
> BT dts node to avoid the PCIe WLAN been affected by BT, right?

I don't know the i.MX95-19x19-EVK platform since it is not upstream. If
you want to support both:

> > WLAN (PCIe) used + BT (UART) used -> no independent handling
> >                                      possible. BT depends on WLAN.

and

> > WLAN (SDIO) + BT (UART) -> This patchset and the mmc-power-seq patchset
> >                            allow us to handle WLAN and BT independently
> > 			   regardless if BT or WLAN is used or not.

you need to stick with the dependent handling which is no problem once
this patchset get applied if your system support hot-plug. If hot-plug
is not possible you could consider unsing overlays.

However, this patchset does _NOT_ cause any regression neither for the
MMC nor the PCIe use-case, and you don't have to touch your DTS files. It
would be an improvement for platforms (not speaking of NXP EVK
platforms) which utilize the MMC+UART interfaces only.

> And it looks strange that we can only add the reset-gpios BT property
> to the hosts that only support SDIO WLAN, we hope there is a solution
> for the PCIe WLAN too.

"We hope there is a solution" <-- This is not how upstream work.

Also as said: The WLAN PCIe interface must/should be compatible with the
PCIe Spec. There is no way that we can handle both devices
independent since the PCIe spec specifies the power-up-sequence very
strict.

If for example, we do handle it independent and the BT part brings the
device out-of-reset while the PCIe bus is not yet ready, the device's
WLAN PCIe subsystem may get confused.

There are two solution NXP could provide:

 - The PCIe WLAN/BT devices exposes all devices WLAN + BT via PCIe, this
   would eliminate the UART part.
 - All new WLAN/BT devices do have a separate hw reset line for each
   radio the device supports.

Regards,
  Marco