On July 30, 2024 11:01:43 AM Krzysztof Kozlowski [off-list ref] wrote:

On 30/07/2024 08:37, Arend Van Spriel wrote:

quoted

+ Linus W

On July 30, 2024 5:31:15 AM Jacobe Zang [off-list ref] wrote:

quoted

Not only AP6275P Wi-Fi device but also all Broadcom wireless devices allow
external low power clock input. In DTS the clock as an optional choice in
the absence of an internal clock.

Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Jacobe Zang <redacted>
---
.../bindings/net/wireless/brcm,bcm4329-fmac.yaml          | 8 ++++++++
1 file changed, 8 insertions(+)

diff --git
a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
index 2c2093c77ec9a..a3607d55ef367 100644

--- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml

@@ -122,6 +122,14 @@ properties:

NVRAM. This would normally be filled in by the bootloader from platform
configuration data.

+  clocks:
+    items:
+      - description: External Low Power Clock input (32.768KHz)
+
+  clock-names:
+    items:
+      - const: lpo
+

We still have an issue that this clock input is also present in the
bindings specification broadcom-bluetooth.yaml (not in bluetooth
subfolder). This clock is actually a chip resource. What happens if both
are defined and both wifi and bt drivers try to enable this clock? Can this
be expressed in yaml or can we only put a textual warning in the property
descriptions?

Just like all clocks, what would happen? It will be enabled.

Oh, wow! Cool stuff. But seriously is it not a problem to have two entities 
controlling one and the same clock? Is this use-case taken into account by 
the clock framework?

Regards,
Arend