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. Regards, Marco On 24-10-28, Marco Felsch wrote: > On 24-10-28, Sherry Sun wrote: > > > > > From: Marco Felsch <m.felsch@xxxxxxxxxxxxxx> > > > > > > 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? > > 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
