>> Am 30.06.24 um 11:15 schrieb Chen-Yu Tsai: >>> On Sun, Jun 30, 2024 at 5:10 PM Jacobe Zang <jacobe.zang@xxxxxxxxxx> wrote: >>>> Hi Stefan, >>>> >>>>>> 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@xxxxxxxxxxxxx/ >>> 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? >> 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
