[PATCH] dt-bindings: power: Add SiFive Domain Management controllers

[Nick Hu]

On Mon, May 12, 2025 at 6:39 PM Krzysztof Kozlowski <krzk at kernel.org> wrote:
>
> On 12/05/2025 05:20, Nick Hu wrote:
> > On Fri, May 9, 2025 at 2:40 PM Krzysztof Kozlowski <krzk at kernel.org> wrote:
> >>
> >> On Fri, May 09, 2025 at 10:16:04AM GMT, Nick Hu wrote:
> >>> SiFive Domain Management controller includes the following components
> >>> - SiFive Tile Management Controller
> >>> - SiFive Cluster Management Controller
> >>> - SiFive Core Complex Management Controller
> >>>
> >>> These controllers control the clock and power domain of the
> >>> corresponding domain.
> >>>
> >>> Signed-off-by: Nick Hu <nick.hu at sifive.com>
> >>> Reviewed-by: Samuel Holland <samuel.holland at sifive.com>
> >>> ---
> >>>  .../devicetree/bindings/power/sifive,tmc.yaml | 89 +++++++++++++++++++
> >>
> >> Where is a patch with the driver (user of the binding)?
> >>
> > We are hoping the driver can be submitted at a later stage.
> > The driver that handles the MMIO is implemented in OpenSBI and depends
> > on some prerequisite patches [1], so it will follow afterward.
>
> This patch alone makes little sense and brings little benefit. Post this
> with user.
>
Thanks. Will update it with the user.

> ...
>
> >>> +  reg:
> >>> +    maxItems: 1
> >>> +
> >>> +  sifive,feature-level:
> >>> +    description: |
> >>> +      Supported power features. This property is absent if the full set of features
> >>> +      is supported
> >>
> >> Compatible defines this. Drop.
> >>
> > The property depends on how the IP is hooked up to the rest of the SoC.
> > Having this property simplifies the SW and allows us to use a single
> > fallback compatible string, so we prefer to keep it.
>
> And we prefer you to follow standard DT rules, see writing bindings or
> talks on conferences.
>
The CPU also exposes its D-cache size, which could technically be
inferred from the compatible string. However, it chose to specify it
explicitly using the `d-cache-size` property to allow reuse of a
common initialization function across different CPUs.
Similarly, while the `sifive,feature-level` could be inferred from the
compatible string, defining it as a property would enable all
`sifive,tmcX` users to share the same operation code, improving code
reuse and maintainability.

If you still disagree with this approach, we’ll drop the
`sifive,feature-level` property in the next revision.
Looking forward to hearing your input.

Best Regards,
Nick