quoted

Am 30.06.24 um 11:15 schrieb Chen-Yu Tsai:

quoted

On Sun, Jun 30, 2024 at 5:10 PM Jacobe Zang [off-list ref] wrote:

quoted

Hi Stefan,

quoted

quoted

WiFi modules often require 32kHz clock to function. Add support to
enable the clock to PCIe driver.

the low power clock is independent from the host interface like PCIe. So
the clock handling should move to the common code. Sorry, not i cannot
give a good suggestion, what's the best place for this.

I think the clock is used by the PCIe device so enable it in this file.
Also I checked
use of clock which in spi[0] or sdio[0] device was enabled similarly to this.

[0]
https://lore.kernel.org/all/20210806081229.721731-4-claudiu.beznea@microchip.com/ (local)

You're looking at the wrong driver. For brcmfmac, the lpo clock is toggled
by the MMC pwrseq code. And for the Bluetooth side (where it really matters)
for UARTs, it is in drivers/bluetooth/hci_bcm.c. and documented in the
binding Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml

As ChenYu said, hci_bcm.c has handled for bt clock. But it seemed that clock has
never handled in brcmfmac wifi driver. So I wonder does everyone all enable the
clock in BT node not wifi?

quoted

Thanks for clarifying. So this change handles the PCIe case without
bluetooth. For USB the clock control doesn't make sense.

Sorry for the noise

So someone could end up with both wifi and bt LPO clock defined in DTS
file. Not sure if that can be expressed and validated in device tree, but
at the least there should be a fair warning in both binding files that
there can be only one!

The LPO clock matters to the chip. It is not specific to the BT part. The

I also think that it is necessary to handle the clock in wifi driver, though.

clock is important for the power-up cycle. The timing difference WL_REG_ON
and BT_REG_ON is expressed in LPO clock cycles.

---
Best Regards
Jacobe