On Mon, Sep 4 2023 at 09:53:05 PM +02:00:00, Krzysztof Kozlowski
<krzysztof.kozlowski@xxxxxxxxxx> wrote:
On 04/09/2023 21:48, Martin Botka wrote:
On Mon, Sep 4 2023 at 09:32:44 PM +02:00:00, Krzysztof Kozlowski
<krzysztof.kozlowski@xxxxxxxxxx> wrote:
On 04/09/2023 21:31, Krzysztof Kozlowski wrote:
On 04/09/2023 17:57, Martin Botka wrote:
We need to add compatible for H616 to H6 cpufreq driver
bindings.
Please describe the hardware, not what is needed for drivers.
Also enable opp_supported_hw property that will be needed for
H616.
Signed-off-by: Martin Botka <martin.botka@xxxxxxxxxxxxxx>
---
.../bindings/opp/allwinner,sun50i-h6-operating-points.yaml
| 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml
b/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml
index 51f62c3ae194..2fa1199f2d23 100644
---
a/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml
+++
b/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml
@@ -23,7 +23,10 @@ allOf:
properties:
compatible:
- const: allwinner,sun50i-h6-operating-points
+ contains:
This does not look like part of allOf, so contains is no correct
here.
This must be specific, so drop contains.
BTW, I also do no see it used by the driver at all.
Function sun50i_cpufreq_get_efuse uses it. It checks for H6
compatible
and if that fails we check for H616 compatible.
Such code does no scale. It also does not look reasonable - you cannot
have different compatible there. Device binds to h6 or h616, so you
cannot have OPP table from other devices.
Heya. I checked how qcom nvmem driver does it. And yea this indeed does
not scale. matchlist should have SoC compatible and driver needs to
have single compatible. Thus also dropping this patch :)
Will do in V2. Thanks Krzystof for pointing me to the right way of
doing it :)
Cheers,
Martin
Best regards,
Krzysztof
