[PATCH v2 1/7] Introduce the Interconnect Subsystem

[Simon Glass]

Hi Neil,

On Wed, 8 Oct 2025 at 09:31, Neil Armstrong <neil.armstrong at linaro.org> wrote:
>
> Let's introduce the Interconnect subsystem based on the Linux framework
> which is used to vote for bandwidth across multiple SoC busses.
>
> Each bus endpoints are materialised as "nodes" which are linked together,
> and the DT will specify a pair of nodes to enable and set a bandwidth
> on the route between those endpoints.
>
> The hardware resources that provide those nodes and provides the way
> to vote for the bandwidth are called "providers".
>
> The Interconnect uclass code is heavily based on the Linux one, with
> some small differences:
> - nodes are allocated as udevices instead of Linux idr_alloc()
> - tag management is minimal, only normal xlate is supported
> - dynamic IDs is not implemented
> - getting nodes states at probe is not implemented
> - providers are probed on demand while the nodes links are traversed
> - nodes are populated on bind
>
> Fully tested with associated DM test suite.
>
> Signed-off-by: Neil Armstrong <neil.armstrong at linaro.org>
> ---
>  drivers/Kconfig                            |   2 +
>  drivers/Makefile                           |   1 +
>  drivers/interconnect/Kconfig               |  10 +
>  drivers/interconnect/Makefile              |   6 +
>  drivers/interconnect/interconnect-uclass.c | 548 +++++++++++++++++++++++++++++
>  include/dm/uclass-id.h                     |   2 +
>  include/interconnect-uclass.h              |  74 ++++
>  include/interconnect.h                     |  81 +++++
>  8 files changed, 724 insertions(+)

'interconnect' is such a long and vague word :-)

There seems to be a piece missing here. The uclass should have
operations, so that it makes sense for different drivers to implement
the methods. I see some there, but also a lot of direct calls from the
test to sandbox. I see quite a few functions which lack a struct
udevice * - I suspect I am missing something?

We normally have a ..._get_ops() macro in the uclass header. Also we
normally have stub functions which get the ops and call the function.

I see code to remove children, but driver model does this
automatically[1]. Same with bind(). If there is a bug in this, can you
give a few details, or ideally a test case?

Also, please can you add:

- comments to the header file, at least
- something in doc/
- a command to list things / provide information

Great to see the automated tests!

Regards,
Simon

[1] https://docs.u-boot.org/en/latest/develop/driver-model/design.html#removal-stage