| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAK9=C2WO5vNs0Y_w8Pk9WWMeYe8Kxhaow5b_QxQWfobL5mrZoQ@mail.gmail.com>
Date: Thu, 9 Oct 2025 19:04:22 +0530
From: Anup Patel <apatel@...tanamicro.com>
To: Rob Herring <robh@...nel.org>
Cc: Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
Paul Walmsley <paul.walmsley@...ive.com>, Palmer Dabbelt <palmer@...belt.com>,
Greg KH <gregkh@...uxfoundation.org>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>, Ian Rogers <irogers@...gle.com>,
Alexandre Ghiti <alex@...ti.fr>, Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>,
Namhyung Kim <namhyung@...nel.org>, Mark Rutland <mark.rutland@....com>, Jiri Olsa <jolsa@...nel.org>,
Adrian Hunter <adrian.hunter@...el.com>, Liang Kan <kan.liang@...ux.intel.com>,
Mayuresh Chitale <mchitale@...il.com>, Anup Patel <anup@...infault.org>,
Atish Patra <atish.patra@...ux.dev>, Andrew Jones <ajones@...tanamicro.com>,
Sunil V L <sunilvl@...tanamicro.com>, linux-riscv@...ts.infradead.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/11] dt-bindings: Add RISC-V trace component bindings
Hi Rob,
Apologies for the delayed response ...
On Fri, Oct 3, 2025 at 12:55 AM Rob Herring <robh@...nel.org> wrote:
>
> On Thu, Oct 02, 2025 at 11:37:22AM +0530, Anup Patel wrote:
> > Add device tree bindings for the memory mapped RISC-V trace components
> > which support both the RISC-V efficient trace (E-trace) protocol and
> > the RISC-V Nexus-based trace (N-trace) protocol.
> >
> > The RISC-V trace components are defined by the RISC-V trace control
> > interface specification.
> >
> > Signed-off-by: Anup Patel <apatel@...tanamicro.com>
> > ---
> > .../bindings/riscv/riscv,trace-component.yaml | 110 ++++++++++++++++++
> > 1 file changed, 110 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/riscv/riscv,trace-component.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/riscv/riscv,trace-component.yaml b/Documentation/devicetree/bindings/riscv/riscv,trace-component.yaml
> > new file mode 100644
> > index 000000000000..78a70fe04dfe
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/riscv/riscv,trace-component.yaml
> > @@ -0,0 +1,110 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/riscv/riscv,trace-component.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: RISC-V Trace Component
> > +
> > +maintainers:
> > + - Anup Patel <anup@...infault.org>
> > +
> > +description:
> > + The RISC-V trace control interface specification standard memory mapped
> > + components (or devices) which support both the RISC-V efficient trace
> > + (E-trace) protocol and the RISC-V Nexus-based trace (N-trace) protocol.
> > + The RISC-V trace components have implementation specific directed acyclic
> > + graph style interdependency where output of one component serves as input
> > + to another component and certain components (such as funnel) can take inputs
> > + from multiple components.
> > +
> > +properties:
> > + compatible:
> > + items:
> > + - enum:
> > + - qemu,trace-component
> > + - const: riscv,trace-component
>
> Given the generic-ness of these names, I'm assuming the exact type of
> component is discoverable. I don't like to assume things in bindings, so
> spell that out.
>
> Is the implementer discoverable? If so, you could omit the 1st
> compatible.
The component type and component version is discoverable through
read-only MMIO registers but the implementer of the component
needs to be inferred using implementation specific compatible string.
I will add some text along these lines in the above description.
>
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + cpu:
>
> 'cpus' is the more standard property.
Okay, I will update.
>
> > + description:
> > + phandle to the cpu to which the RISC-V trace component is bound.
> > + $ref: /schemas/types.yaml#/definitions/phandle
>
> which already has a type. So just 'maxItems: 1' here.
Okay, I will update.
>
> > +
> > + in-ports:
> > + $ref: /schemas/graph.yaml#/properties/ports
> > + patternProperties:
> > + '^port(@[0-7])?$':
> > + description: Input connections from RISC-V trace component
> > + $ref: /schemas/graph.yaml#/properties/port
>
> If the N ports are N of the same data (like a mux), then fine. If each
> port is different, then you need to define what each port is.
Yes, the data (aka trace packets) is the same for all input trace ports
even in-case of funnel (aka mux). Same thing also applies to the
output ports.
>
> > +
> > + out-ports:
> > + $ref: /schemas/graph.yaml#/properties/ports
> > + patternProperties:
> > + '^port(@[0-7])?$':
> > + description: Output connections from RISC-V trace component
> > + $ref: /schemas/graph.yaml#/properties/port
> > +
> > +required:
> > + - compatible
> > + - reg
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > + - |
> > + // Example 1 (Per-hart encoder and ramsink components):
> > +
> > + encoder@...0000 {
>
> Perhaps it is time to standardize the node names here. Perhaps 'trace'.
It is better to not fix the node names because this allows users
to infer type of component from node name hence more human
readable.
>
> > + compatible = "qemu,trace-component", "riscv,trace-component";
> > + reg = <0xc000000 0x1000>;
> > + cpu = <&CPU0>;
> > + out-ports {
> > + port {
> > + CPU0_ENCODER_OUTPUT: endpoint {
> > + remote-endpoint = <&CPU0_RAMSINK_INPUT>;
> > + };
> > + };
> > + };
> > + };
> > +
> > + ramsink@...1000 {
> > + compatible = "qemu,trace-component", "riscv,trace-component";
> > + reg = <0xc001000 0x1000>;
> > + cpu = <&CPU0>;
> > + in-ports {
> > + port {
> > + CPU0_RAMSINK_INPUT: endpoint {
> > + };
> > + };
> > + };
> > + };
> > +
> > + encoder@...2000 {
> > + compatible = "qemu,trace-component", "riscv,trace-component";
> > + reg = <0xc002000 0x1000>;
> > + cpu = <&CPU1>;
> > + out-ports {
> > + port {
> > + CPU1_ENCODER_OUTPUT: endpoint {
> > + remote-endpoint = <&CPU1_RAMSINK_INPUT>;
> > + };
> > + };
> > + };
> > + };
> > +
> > + ramsink@...3000 {
> > + compatible = "qemu,trace-component", "riscv,trace-component";
> > + reg = <0xc003000 0x1000>;
> > + cpu = <&CPU1>;
> > + in-ports {
> > + port {
> > + CPU1_RAMSINK_INPUT: endpoint {
> > + };
> > + };
> > + };
> > + };
> > +
> > +...
> > --
> > 2.43.0
> >
Regards,
Anup
Powered by blists - more mailing lists