From: Danilo Krummrich <dakr@kernel.org>
To: Daniel Almeida <daniel.almeida@collabora.com>
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org
Subject: Re: [PATCH v3 2/2] rust: platform: add irq accessors
Date: Mon, 2 Jun 2025 19:45:41 +0200 [thread overview]
Message-ID: <aD3jRbuxc0NQt6MC@pollux> (raw)
In-Reply-To: <CA34AB78-D9DC-433A-B6DF-663849A07370@collabora.com>
On Mon, Jun 02, 2025 at 11:56:28AM -0300, Daniel Almeida wrote:
> Hi Danilo,
>
> […]
>
> >> +
> >> + /// Same as [`Self::irq_by_name`] but does not print an error message if an IRQ
> >> + /// cannot be obtained.
> >> + pub fn optional_irq_by_name(&self, name: &CStr) -> Result<u32> {
> >> + // SAFETY: `self.as_raw` returns a valid pointer to a `struct platform_device`.
> >> + let res = unsafe {
> >> + bindings::platform_get_irq_byname_optional(self.as_raw(), name.as_char_ptr())
> >> + };
> >> +
> >> + if res < 0 {
> >> + return Err(Error::from_errno(res));
> >> + }
> >> +
> >> + Ok(res as u32)
> >> + }
> >
> > I don't like the indirection of claiming a u32 representing the IRQ number from
> > a bus device and stuffing it into an irq::Registration.
> >
> > It would be better we we'd make it impossible (or at least harder) for a driver
> > to pass the wrong number to irq::Registration.
> >
> > I see two options:
> >
> > 1) Make the platform::Device accessors themselves return an
> > irq::Registration.
> >
> > 2) Make the platform::Device accessors return some kind of transparent cookie,
> > that drivers can't create themselves that can be fed into the
> > irq::Registration.
> >
> > My preference would be 1) if there's no major ergonomic issue with that.
>
> Isn’t 1 way more cluttered?
I don't think so, your irq::Registration::register() function needs a reference
to the registering device anyways.
And given that, now that I think about it, it even has to be this way.
Otherwise, I could provide irq::Registration::register() an IRQ number that does
not belong to the bus device that is passed into irq::Registration::register().
So, irq::Registration::register() even needs to be unsafe, with the safety
requirement that the IRQ number must belong to the corresponding device and
should be wrapped by bus device abstractions providing the safe driver API.
> That's because the accessors would have to forward all of the arguments (i.e.:
> currently 4) to register().
It's only the additional arguments below, which you can also wrap in an
irq::Args structure to keep things cleaner. :)
+ flags: Flags,
+ name: &'static CStr,
+ handler: T,
prev parent reply other threads:[~2025-06-02 17:45 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-14 19:20 [PATCH v3 0/2] rust: add support for request_irq Daniel Almeida
2025-05-14 19:20 ` [PATCH v3 1/2] rust: irq: add support for request_irq() Daniel Almeida
2025-05-14 20:04 ` Benno Lossin
2025-05-14 20:58 ` Daniel Almeida
2025-05-14 21:03 ` Daniel Almeida
2025-05-15 8:46 ` Benno Lossin
2025-05-15 12:06 ` Daniel Almeida
2025-05-15 12:44 ` Benno Lossin
2025-06-02 15:20 ` Alice Ryhl
2025-06-04 7:36 ` Benno Lossin
2025-06-04 7:48 ` Alice Ryhl
2025-06-04 9:43 ` Benno Lossin
2025-05-14 21:53 ` Danilo Krummrich
2025-05-15 11:54 ` Daniel Almeida
2025-05-15 12:04 ` Danilo Krummrich
2025-05-15 12:27 ` Daniel Almeida
2025-05-15 12:45 ` Danilo Krummrich
2025-05-15 13:16 ` Daniel Almeida
2025-05-15 13:45 ` Danilo Krummrich
2025-05-15 13:52 ` Danilo Krummrich
2025-06-02 14:40 ` Daniel Almeida
2025-06-02 17:35 ` Danilo Krummrich
2025-06-02 16:02 ` Alice Ryhl
2025-05-15 13:28 ` Benno Lossin
2025-06-02 16:19 ` Alice Ryhl
2025-06-02 17:31 ` Danilo Krummrich
2025-06-03 8:28 ` Alice Ryhl
2025-06-03 8:46 ` Danilo Krummrich
2025-06-03 8:54 ` Alice Ryhl
2025-06-03 9:10 ` Danilo Krummrich
2025-06-03 9:18 ` Alice Ryhl
2025-06-03 9:43 ` Danilo Krummrich
2025-06-03 9:57 ` Alice Ryhl
2025-06-03 10:08 ` Danilo Krummrich
2025-06-03 10:16 ` Danilo Krummrich
2025-06-04 18:32 ` Daniel Almeida
2025-06-04 18:57 ` Danilo Krummrich
2025-05-18 13:24 ` Alexandre Courbot
2025-05-18 14:07 ` Benno Lossin
2025-05-14 19:20 ` [PATCH v3 2/2] rust: platform: add irq accessors Daniel Almeida
2025-05-14 20:06 ` Benno Lossin
2025-05-19 10:41 ` Danilo Krummrich
2025-06-02 14:56 ` Daniel Almeida
2025-06-02 17:45 ` Danilo Krummrich [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aD3jRbuxc0NQt6MC@pollux \
--to=dakr@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=daniel.almeida@collabora.com \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=rafael@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=tmgross@umich.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).