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: <20241028115150.fgvqaem36lwxwvjh@pengutronix.de>
Date: Mon, 28 Oct 2024 12:51:50 +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>
> > 
> > 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.

Regards,
  Marco