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@baylibre.com>
> > Signed-off-by: Adrien Ricciardi <aricciardi@baylibre.com>
> > Signed-off-by: Drew Fustini <fustini@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

> > +
> > +  reg:
> > +    maxItems: 1
> > +    description:
> > +      The CBQRI controller register block.
> > +
> > +  riscv,cbqri-rcid:
> > +    $ref: /schemas/types.yaml#/definitions/uint32
> > +    description:
> > +      The maximum number of RCIDs the controller supports. RCIDs are the
> > +      resource-control IDs that allocation operations target.
> > +
> > +  riscv,cbqri-mcid:
> > +    $ref: /schemas/types.yaml#/definitions/uint32
> > +    description:
> > +      The maximum number of MCIDs the controller supports. MCIDs are the
> > +      monitoring-counter IDs that usage-monitoring operations target. Present
> > +      on controllers that implement monitoring.
> > +
> > +  riscv,cbqri-cache:
> > +    $ref: /schemas/types.yaml#/definitions/phandle
> > +    description:
> > +      Phandle to the cache node whose capacity this controller allocates.
> > +      Applies to capacity controllers that back a CPU cache. The cache level
> > +      and the harts sharing it are taken from that node's cache topology.
> 
> Architecturally, is it impossible for a capacity controller to control
> more than one cache?

Yes, there is only ever a single logical capacity resource per capacity
controller. When that resource is a cache, the controller handles that
one logical cache. The hardware may implement the cache as a collection
of slices, but that stays opaque to CBQRI. So riscv,cbqri-cache stays a
single phandle.

> > +
> > +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@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?

Thanks,
Drew