[RFC PATCH 0/5] hwtracing: rvtrace: Add ACPI support

[Sunil V L]

From: Sunil V L <sunilvl at oss.qualcomm.com>

This is an RFC series to add ACPI support for the RISC-V trace
framework. It is based on Mayuresh's v5 series, "Linux RISC-V trace
framework and drivers" [1].

The RISC-V trace specification is proposed in the RISC-V BRS v1.0.6
document [2], Section 6.5. It uses the Device Graph UUID defined in
Section 3.4 of the DSD Guide [3], similar to the approach used by
other architectures.

When I started looking at ACPI support for the trace graph, the obvious
design was to follow the approach used by other architectures, such as
CoreSight. However, that would mean duplicating the ACPI graph parsing
logic and maintaining separate DT and ACPI paths in the rvtrace driver.

Instead, this series proposes enhancing the existing fwnode_* graph APIs
so that the trace driver can use the same interfaces for both DT and
ACPI. The main idea is to parse the Device Graph UUID defined in _DSD
and create synthetic nodes that match the DT nodes. The ACPI-based
fwnode_* APIs are then enhanced to traverse these synthetic nodes in the
same way as DT. The ACPI fwnode_* APIs already support the
"Hierarchical Data Extension UUID" defined in Section 3.2 of the DSD
Guide [3]. Adding support for another GUID therefore seems natural to
me.

The series adds the ACPI device-graph parsing by creating
synthetic nodes matching the DT nodes, extends the graph parent handling
for in-ports and out-ports, converts the rvtrace platform driver to the
fwnode_* APIs, and adds ACPI matching and CPU binding support. In the
future, other drivers that use the Device Graph UUID, including
CoreSight drivers, can use the same interfaces and avoid duplicating
this logic.

One question that may come up is that the DT schema [5] has not
standardized the in-ports/out-ports. However, the existing OF
interfaces already support in-ports and out-ports. Therefore, I do not
see an issue with providing the same capability through the common
fwnode_* graph APIs.

This is an RFC series, and feedback on the overall design and the API
changes would be very helpful. We have a slot to discuss this in LPC
next week under RISC-V MC track. I hope this series gives better context
before the session and we can have a fruitful discussion next week to
converge on the right approach.

The series was tested on a QEMU virt machine with the required ACPI
namespace changes for the trace graph. These changes are available at
[4].

[1] - https://lore-kernel.gnuweeb.org/linux-riscv/20260810152223.3946743-13-mayuresh.chitale@oss.qualcomm.com/T/
[2] - https://github.com/riscv-non-isa/riscv-brs/releases/download/v1.0.6/brs-v1.0.6-20260928.pdf
[3] - https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.pdf
[4] - https://github.com/vlsunil/qemu/tree/acpi_trace_rfc_v1
[5] - https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/graph.yaml

Sunil V L (5):
  of: property: Add in-ports/out-ports support to
    of_fwnode_graph_get_port_parent()
  ACPI: property: Add ports/in-ports/out-ports support to
    acpi_fwnode_get_parent()
  ACPI: property: Add device graph support
  hwtracing: rvtrace: Move to fwnode_* APIs
  hwtracing: rvtrace: Add ACPI support

 drivers/acpi/property.c                     | 516 +++++++++++++++++++-
 drivers/hwtracing/gtrace/Kconfig            |   4 +-
 drivers/hwtracing/gtrace/rvtrace-platform.c | 191 ++++++--
 drivers/of/property.c                       |   4 +-
 4 files changed, 657 insertions(+), 58 deletions(-)

-- 
2.43.0