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.
Regards,
Marco
