icc_path is in essence very similar to `struct clk`, so the newly
propsed bindings are understandably based on the corresponding
common_clk module.
This is the interconnect consumer part, with the corresponding ICC
provider changes coming in some near future.

I attached a sample driver making use of these, to ease any testing
or CI work (as the title says, please don't merge it though).

First contribution to kernel-rs, open to any and all suggestions.

Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
Konrad Dybcio (2):
      rust: Add initial interconnect framework abstractions
      [DNM] interconnect: Add a test Rust consumer driver

 MAINTAINERS                     |   1 +
 drivers/interconnect/Makefile   |   1 +
 drivers/interconnect/test.rs    |  47 +++++++++
 rust/bindings/bindings_helper.h |   2 +
 rust/kernel/icc.rs              | 225 ++++++++++++++++++++++++++++++++++++++++
 rust/kernel/lib.rs              |   1 +
 6 files changed, 277 insertions(+)
---
base-commit: 05adbee3ad528100ab0285c15c91100e19e10138
change-id: 20250722-topic-icc_rs-fdbc135c57ae

Best regards,
-- 
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

On Tue, Jul 22, 2025 at 11:14 PM Konrad Dybcio <konradybcio@kernel.org> wrote:
>
> icc_path is in essence very similar to `struct clk`, so the newly
> propsed bindings are understandably based on the corresponding
> common_clk module.
> This is the interconnect consumer part, with the corresponding ICC
> provider changes coming in some near future.
>
> I attached a sample driver making use of these, to ease any testing
> or CI work (as the title says, please don't merge it though).

Thanks!

The usual two main questions for new abstractions are whether the
maintainers of the C side want to see this happen (and how will it be
maintained etc.) and what users of the abstractions are expected
upstream.

For the first part, some subsystems prefer to maintain it themselves,
others prefer to have someone else lead a separate sub-entry in
`MAINTAINERS` (e.g. "... [RUST]"), possibly with its own branch too.

Cheers,
Miguel

On 7/23/25 12:22 PM, Miguel Ojeda wrote:
> On Tue, Jul 22, 2025 at 11:14 PM Konrad Dybcio <konradybcio@kernel.org> wrote:
>>
>> icc_path is in essence very similar to `struct clk`, so the newly
>> propsed bindings are understandably based on the corresponding
>> common_clk module.
>> This is the interconnect consumer part, with the corresponding ICC
>> provider changes coming in some near future.
>>
>> I attached a sample driver making use of these, to ease any testing
>> or CI work (as the title says, please don't merge it though).
> 
> Thanks!
> 
> The usual two main questions for new abstractions are whether the
> maintainers of the C side want to see this happen (and how will it be
> maintained etc.) and what users of the abstractions are expected
> upstream.

I haven't talked to Georgi about this. I can volunteer for
code-janitoring, but as you can tell I'll still need your oversight

Regarding the users, I don't have any specific promises on a consumer
of these abstractions in a short term, although the ICC API is rather
common (especially across the major arm-based SoCs), so it shouldn't be
long before someone needs it.

Konrad

> 
> For the first part, some subsystems prefer to maintain it themselves,
> others prefer to have someone else lead a separate sub-entry in
> `MAINTAINERS` (e.g. "... [RUST]"), possibly with its own branch too.
> 
> Cheers,
> Miguel

On Thu, Jul 24, 2025 at 2:36 PM Konrad Dybcio
<konrad.dybcio@oss.qualcomm.com> wrote:
>
> Regarding the users, I don't have any specific promises on a consumer
> of these abstractions in a short term, although the ICC API is rather
> common (especially across the major arm-based SoCs), so it shouldn't be
> long before someone needs it.

In general, abstractions cannot be added unless there is a known user
that is coming upstream (or developed in-tree over time, like Nova and
Tyr).

There is also the "Rust reference driver" approach/exception to help C
maintainers bootstrap the Rust side, which you may be able to take
advantage of:

    https://rust-for-linux.com/rust-reference-drivers

At the end of the day, it depends on the particular case and the
maintainers, of course.

I hope that helps.

Cheers,
Miguel