Re: [PATCH v2 1/2] dt-bindings: devfreq: Document support for Airoha Subsystem Scale

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] dt-bindings: devfreq: airoha: virtual nodes created for software driver instantiation
--

commit d2ff6805653f5553cb072876dd17890e25aca955
Author: Christian Marangi <ansuelsmth@gmail.com>

dt-bindings: devfreq: Document support for Airoha Subsystem Scale

Airoha SoC contains multiple subsystems that are scaled to a
specific OPP taking the CPU clock as reference. Such subsystem
can enter idle or performance state based on the system load
and power consumption conditions.

> diff --git a/Documentation/devicetree/bindings/devfreq/airoha,subsystem-scale.yaml b/Documentation/devicetree/bindings/devfreq/airoha,subsystem-scale.yaml
> new file mode 100644
> index 0000000000000..2cf7f23a926c9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/devfreq/airoha,subsystem-scale.yaml
> @@ -0,0 +1,114 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/devfreq/airoha,subsystem-scale.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Airoha SoC Subsystem Scale Driver

[Severity: Medium]
Does this binding describe a software driver instead of a physical hardware
block?

Devicetree is fundamentally designed to describe physical hardware structure,
not software driver architecture or internal Linux models. The title highlights
a conceptual flaw by explicitly referencing a driver rather than the physical
hardware.

[ ... ]

> +examples:
> +  - |
> +    #include <dt-bindings/clock/en7523-clk.h>

[ ... ]

> +    npu-subsystem {
> +        compatible = "airoha,an7581-subsystem-scale";
> +        operating-points-v2 = <&npu_opp_table>;
> +        clocks = <&scuclk EN7523_CLK_NPU>;
> +    };

[Severity: Medium]
Are these purely virtual hardware nodes functioning solely as a hook to
instantiate and probe a generic devfreq driver?

These nodes lack physical hardware resources, such as reg addresses or
interrupts, and appear to exist only as glue to bind an OPP table to a clock.
Introducing purely virtual nodes into the device tree creates an invalid
hardware description and pollutes the DT ABI with Linux-specific software
abstractions.

Instead of introducing virtual nodes, should the clocks and
operating-points-v2 properties be attached directly to the actual hardware
consumer nodes (e.g., the physical NPU, GSW, or BUS devices)?

The respective drivers for those hardware blocks, or generic frameworks like
PM domains and interconnects, could then be responsible for managing their own
power and performance scaling.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261009073330.18175-1-ansuelsmth@gmail.com?part=1