[PATCH v2 7/8] dt-bindings: riscv: Add generic CBQRI controller binding

[Conor Dooley]

On Thu, Jun 25, 2026 at 12:21:52PM -0700, Drew Fustini wrote:
> On Thu, Jun 25, 2026 at 05:19:28PM +0100, Conor Dooley wrote:
> > On Wed, Jun 24, 2026 at 06:38:35PM -0700, Drew Fustini wrote:
> > > Document the generic compatibles for capacity and bandwidth controllers
> > > that implement the RISC-V CBQRI specification. The binding also
> > > describes the common riscv,cbqri-rcid and riscv,cbqri-mcid properties,
> > > and the optional riscv,cbqri-cache phandle that links a capacity
> > > controller to the cache whose capacity it allocates.
> > > 
> > > Assisted-by: Claude:claude-opus-4-8
> > > Co-developed-by: Adrien Ricciardi <aricciardi at baylibre.com>
> > > Signed-off-by: Adrien Ricciardi <aricciardi at baylibre.com>
> > > Signed-off-by: Drew Fustini <fustini at kernel.org>
> > > ---
> > >  .../devicetree/bindings/riscv/riscv,cbqri.yaml     | 97 ++++++++++++++++++++++
> > >  MAINTAINERS                                        |  1 +
> > >  2 files changed, 98 insertions(+)
> 
> Thanks for the review.
> 
> [..]
> > > +properties:
> > > +  compatible:
> > > +    oneOf:
> > > +      - items:
> > > +          - description: Tenstorrent Ascalon Shared Cache
> > > +            const: tenstorrent,ascalon-sc-cbqri
> > > +          - const: riscv,cbqri-capacity-controller
> > > +      - enum:
> > > +          - riscv,cbqri-capacity-controller
> > > +          - riscv,cbqri-bandwidth-controller
> > 
> > Please modify this, as has been done for other riscv spec related
> > bindings, to let people get away without using device-specific
> > compatibles.
> > 
> > In this case, you can just delete the first entry from this enum, since
> > it already has a user and only have to implement this feedback for the
> > second entry.
> 
> Would this work?
> 
> properties:
>   compatible:
>     oneOf:
>       - items:
>           - enum:
>               - tenstorrent,ascalon-sc-cbqri # Tenstorrent Ascalon Shared Cache
>           - const: riscv,cbqri-capacity-controller
>       - items:
>           - {}
>           - const: riscv,cbqri-bandwidth-controller


Should do, yes. I question the need for a comment though, seems pretty
evident from the compatible what it is.

> > > +
> > > +required:
> > > +  - compatible
> > > +  - reg
> > > +
> > > +allOf:
> > > +  - if:
> > > +      properties:
> > > +        compatible:
> > > +          contains:
> > > +            const: tenstorrent,ascalon-sc-cbqri
> > > +    then:
> > > +      required:
> > > +        - riscv,cbqri-rcid
> > > +        - riscv,cbqri-cache
> > > +
> > > +additionalProperties: false
> > > +
> > > +examples:
> > > +  - |
> > > +    l2_cache: l2-cache {
> > > +        compatible = "cache";
> > > +        cache-level = <2>;
> > > +        cache-unified;
> > > +        cache-size = <0xc00000>;
> > > +        cache-sets = <512>;
> > > +        cache-block-size = <64>;
> > > +    };
> > > +
> > > +    cache-controller at a21a00c0 {
> > > +        compatible = "tenstorrent,ascalon-sc-cbqri",
> > > +                     "riscv,cbqri-capacity-controller";
> > 
> > Is this or is this not a cache controller?
> > The compatible and fact that the property points to an actual cache
> > controller suggests that this is not.
> 
> Good point. This nodes represents just the QoS interface (CBQRI) and
> should not use that node name. 'qos-controller' seems like it would be
> more appropriate but that has no precedent. What do you think?

Sure.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20260626/f9b33030/attachment.sig>