linux-kernel - Re: [PATCH v7 0/2] rust: leds: add led classdev abstractions

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] [day] [month] [year] [list]

Message-ID: <CANiq72nhhji-cz2T2Cg9y5AwUwcc9q1Hd=-6J=6TafaxcHZHeA@mail.gmail.com>
Date: Fri, 31 Oct 2025 14:18:33 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Markus Probst <markus.probst@...teo.de>, Lee Jones <lee@...nel.org>, 
	Pavel Machek <pavel@...nel.org>
Cc: Danilo Krummrich <dakr@...nel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, 
	Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>, 
	"Rafael J. Wysocki" <rafael@...nel.org>, Dave Ertman <david.m.ertman@...el.com>, 
	Ira Weiny <ira.weiny@...el.com>, Leon Romanovsky <leon@...nel.org>, Boqun Feng <boqun.feng@...il.com>, 
	Gary Guo <gary@...yguo.net>, 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>, 
	Bjorn Helgaas <bhelgaas@...gle.com>, Krzysztof Wilczyński <kwilczynski@...nel.org>, 
	rust-for-linux@...r.kernel.org, linux-leds@...r.kernel.org, 
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7 0/2] rust: leds: add led classdev abstractions

On Thu, Oct 30, 2025 at 7:09 PM Markus Probst <markus.probst@...teo.de> wrote:
>
> No there is no MAINTAINERS entry for it, therefore it will covered by
> the "RUST" entry in the file. I have added the led maintainers and the
> "linux-leds" mailing list to every patch sent regarding the led
> bindings and none of the maintainers have commented on it so far.

The global "RUST" entry is generally meant for core abstractions and
infrastructure. The best way forward is to get the C side maintainers
involved, since they are the experts on the subsystem.

Depending on what they want to do (e.g. they may want to maintain the
Rust side themselves, or they may be looking for a co-maintainer, or
they may not want Rust code for the time being, or they may prefer to
leave this to another entry, etc.), we can see what to do.

The first version was posted, I think, earlier this month (please
correct me if I am wrong), so let's give them one kernel cycle at
least to think about it.

Of course, it also depends on what you want to do. For instance, would
you be willing to maintain this code if the maintainers want to have a
"LED SUBSYSTEM [RUST]" subentry?

Thanks!

Cheers,
Miguel