linux-kernel - Re: [PATCH 0/2] Add initial interconnect (icc

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANiq72kxcEywL4L6HEqn7AZa-jOBsw08jr+Kvjdwrd+iTOO_uQ@mail.gmail.com>
Date: Wed, 23 Jul 2025 12:22:40 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Konrad Dybcio <konradybcio@...nel.org>
Cc: Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>, 
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, 
	Björn Roy Baron <bjorn3_gh@...tonmail.com>, 
	Benno Lossin <lossin@...nel.org>, Andreas Hindborg <a.hindborg@...nel.org>, 
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>, 
	Danilo Krummrich <dakr@...nel.org>, Georgi Djakov <djakov@...nel.org>, 
	Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>, 
	Bjorn Andersson <bjorn.andersson@....qualcomm.com>, 
	Marijn Suijten <marijn.suijten@...ainline.org>, linux-kernel@...r.kernel.org, 
	rust-for-linux@...r.kernel.org, linux-pm@...r.kernel.org, 
	Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Subject: Re: [PATCH 0/2] Add initial interconnect (icc_path) Rust abstractions

On Tue, Jul 22, 2025 at 11:14 PM Konrad Dybcio <konradybcio@...nel.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