> -----Original Message----- > From: Marco Felsch <m.felsch@xxxxxxxxxxxxxx> > Sent: Monday, October 28, 2024 7:52 PM > To: Sherry Sun <sherry.sun@xxxxxxx> > Cc: POPESCU Catalin <catalin.popescu@xxxxxxxxxxxxxxxxxxxx>; Amitkumar > Karwar <amitkumar.karwar@xxxxxxx>; Neeraj Sanjay Kale > <neeraj.sanjaykale@xxxxxxx>; marcel@xxxxxxxxxxxx; > luiz.dentz@xxxxxxxxx; robh@xxxxxxxxxx; krzk+dt@xxxxxxxxxx; > conor+dt@xxxxxxxxxx; p.zabel@xxxxxxxxxxxxxx; linux- > bluetooth@xxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx; linux- > kernel@xxxxxxxxxxxxxxx; GEO-CHHER-bsp-development <bsp- > development.geo@xxxxxxxxxxxxxxxxxxxx>; Krzysztof Kozlowski > <krzk@xxxxxxxxxx> > 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@xxxxxxxxxxxxxx> > > > > > > Hi, > > > > > > On 24-10-28, Sherry Sun wrote: > > > > > > > > > From: POPESCU Catalin <catalin.popescu@xxxxxxxxxxxxxxxxxxxx> > > > > > > > > > > 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? 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. Best Regards Sherry
