On Thu Apr 2, 2026 at 10:23 AM CEST, Krzysztof Kozlowski wrote: > On 07/03/2026 16:30, Krzysztof Kozlowski wrote: >>> + >>> +properties: >>> + compatible: >>> + enum: >>> + - qcom,milos-gxclkctl >>> + >>> + power-domains: >>> + description: >>> + Power domains required for the clock controller to operate >>> + items: >>> + - description: GFX power domain >>> + - description: GPUCC(CX) power domain >>> + >>> + '#power-domain-cells': >>> + const: 1 >>> + >>> + reg: >>> + maxItems: 1 >> >> reg should be the second property, like you have it in "required" part. >> I guess you copied it from kaanapali-gxclkctl.yaml, so lesson - qcom >> bindings have acceptable quality, but not good enough to take as correct >> starting point. >> > > OTOH, why this entire binding cannot be squashed in Kaanapali one? > What's the difference?
There's no GMXC power domain on Milos. Apart from that they're compatible from a bindings perspective. However it can re-use include/dt-bindings/clock/qcom,kaanapali-gxclkctl.h because the GX_CLKCTL_GX_GDSC definition would be identical. And also the driver (which can be used as-is) would be identical. In that driver qcom,kaanapali-gxclkctl.h is used so it makes sense to keep with the kaanapali header, or not? Making a qcom,milos-gxclkctl.h with the same definition is not wanted? Regards Luca
