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>,
"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>,
"Benno Lossin" <lossin@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
linux-pci@vger.kernel.org
Subject: Re: [PATCH v4 3/6] rust: irq: add support for non-threaded IRQs and handlers
Date: Mon, 9 Jun 2025 13:47:03 +0200 [thread overview]
Message-ID: <aEbJt0YSc3-60OBY@pollux> (raw)
In-Reply-To: <20250608-topics-tyr-request_irq-v4-3-81cb81fb8073@collabora.com>
On Sun, Jun 08, 2025 at 07:51:08PM -0300, Daniel Almeida wrote:
> +/// // This is running in process context.
> +/// fn register_irq(handler: Handler, dev: &platform::Device<Bound>) -> Result<Arc<Registration<Handler>>> {
> +/// let registration = dev.irq_by_index(0, flags::SHARED, c_str!("my-device"), handler)?;
> +///
> +/// // You can have as many references to the registration as you want, so
> +/// // multiple parts of the driver can access it.
> +/// let registration = Arc::pin_init(registration, GFP_KERNEL)?;
> +///
> +/// // The handler may be called immediately after the function above
> +/// // returns, possibly in a different CPU.
> +///
> +/// {
> +/// // The data can be accessed from the process context too.
> +/// registration.handler().0.fetch_add(1, Ordering::Relaxed);
> +/// }
Why the extra scope?
> +///
> +/// Ok(registration)
> +/// }
> +///
> +/// # Ok::<(), Error>(())
> +///```
> +///
> +/// # Invariants
> +///
> +/// * We own an irq handler using `&self` as its private data.
> +///
> +#[pin_data]
> +pub struct Registration<T: Handler + 'static> {
> + inner: Devres<RegistrationInner>,
> +
> + #[pin]
> + handler: T,
> +
> + /// Pinned because we need address stability so that we can pass a pointer
> + /// to the callback.
> + #[pin]
> + _pin: PhantomPinned,
> +}
> +
> +impl<T: Handler + 'static> Registration<T> {
> + /// Registers the IRQ handler with the system for the given IRQ number.
> + pub(crate) fn register<'a>(
I think we should call this Registration::new() instead. Except for
MiscDeviceRegistration, which is representing not *only* a registration, all
other Registration types just use new() and it'd be nice to be consistent.
> + dev: &'a Device<Bound>,
> + irq: u32,
> + flags: Flags,
> + name: &'static CStr,
> + handler: T,
> + ) -> impl PinInit<Self, Error> + 'a {
> + let closure = move |slot: *mut Self| {
> + // SAFETY: The slot passed to pin initializer is valid for writing.
> + unsafe {
> + slot.write(Self {
> + inner: Devres::new(
> + dev,
> + RegistrationInner {
> + irq,
> + cookie: slot.cast(),
> + },
> + GFP_KERNEL,
> + )?,
> + handler,
> + _pin: PhantomPinned,
> + })
> + };
> +
> + // SAFETY:
> + // - The callbacks are valid for use with request_irq.
> + // - If this succeeds, the slot is guaranteed to be valid until the
> + // destructor of Self runs, which will deregister the callbacks
> + // before the memory location becomes invalid.
> + let res = to_result(unsafe {
> + bindings::request_irq(
> + irq,
> + Some(handle_irq_callback::<T>),
> + flags.into_inner() as usize,
> + name.as_char_ptr(),
> + slot.cast(),
> + )
> + });
> +
> + if res.is_err() {
> + // SAFETY: We are returning an error, so we can destroy the slot.
> + unsafe { core::ptr::drop_in_place(&raw mut (*slot).handler) };
> + }
> +
> + res
> + };
> +
> + // SAFETY:
> + // - if this returns Ok, then every field of `slot` is fully
> + // initialized.
> + // - if this returns an error, then the slot does not need to remain
> + // valid.
> + unsafe { pin_init_from_closure(closure) }
Can't we use try_pin_init!() instead, move request_irq() into the initializer of
RegistrationInner and initialize inner last?
> + }
> +
> + /// Returns a reference to the handler that was registered with the system.
> + pub fn handler(&self) -> &T {
> + &self.handler
> + }
> +
> + /// Wait for pending IRQ handlers on other CPUs.
> + ///
> + /// This will attempt to access the inner [`Devres`] container.
> + pub fn try_synchronize(&self) -> Result {
> + let inner = self.inner.try_access().ok_or(ENODEV)?;
> + inner.synchronize();
> + Ok(())
> + }
> +
> + /// Wait for pending IRQ handlers on other CPUs.
> + pub fn synchronize(&self, dev: &Device<Bound>) -> Result {
> + let inner = self.inner.access(dev)?;
> + inner.synchronize();
> + Ok(())
> + }
> +}
> +
> +/// # Safety
> +///
> +/// This function should be only used as the callback in `request_irq`.
> +unsafe extern "C" fn handle_irq_callback<T: Handler>(
> + _irq: i32,
> + ptr: *mut core::ffi::c_void,
> +) -> core::ffi::c_uint {
> + // SAFETY: `ptr` is a pointer to Registration<T> set in `Registration::new`
> + let data = unsafe { &*(ptr as *const Registration<T>) };
> + T::handle_irq(&data.handler).into_inner()
> +}
>
> --
> 2.49.0
>
next prev parent reply other threads:[~2025-06-09 11:47 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-08 22:51 [PATCH v4 0/6] rust: add support for request_irq Daniel Almeida
2025-06-08 22:51 ` [PATCH v4 1/6] rust: irq: add irq module Daniel Almeida
2025-06-08 22:51 ` [PATCH v4 2/6] rust: irq: add flags module Daniel Almeida
2025-06-08 22:51 ` [PATCH v4 3/6] rust: irq: add support for non-threaded IRQs and handlers Daniel Almeida
2025-06-09 11:47 ` Danilo Krummrich [this message]
2025-06-23 15:10 ` Alice Ryhl
2025-06-23 15:23 ` Danilo Krummrich
2025-06-23 15:25 ` Alice Ryhl
2025-06-23 15:26 ` Benno Lossin
2025-06-23 17:31 ` Boqun Feng
2025-06-23 19:18 ` Boqun Feng
2025-06-23 19:28 ` Benno Lossin
2025-06-24 12:31 ` Daniel Almeida
2025-06-24 12:46 ` Benno Lossin
2025-06-24 13:50 ` Alice Ryhl
2025-06-24 14:33 ` Boqun Feng
2025-06-24 14:42 ` Boqun Feng
2025-06-24 14:56 ` Danilo Krummrich
2025-06-24 15:17 ` Benno Lossin
2025-06-23 19:25 ` Benno Lossin
2025-06-23 19:27 ` Benno Lossin
2025-06-08 22:51 ` [PATCH v4 4/6] rust: irq: add support for threaded " Daniel Almeida
2025-06-09 12:27 ` Danilo Krummrich
2025-06-09 16:24 ` Daniel Almeida
2025-06-09 18:13 ` Danilo Krummrich
2025-06-09 18:30 ` Miguel Ojeda
2025-06-16 13:33 ` Alice Ryhl
2025-06-16 13:43 ` Danilo Krummrich
2025-06-16 17:49 ` Danilo Krummrich
2025-06-22 20:53 ` Benno Lossin
2025-06-16 13:48 ` Daniel Almeida
2025-06-16 15:45 ` Danilo Krummrich
2025-06-16 13:52 ` Daniel Almeida
2025-06-08 22:51 ` [PATCH v4 5/6] rust: platform: add irq accessors Daniel Almeida
2025-06-09 12:51 ` Danilo Krummrich
2025-06-08 22:51 ` [PATCH v4 6/6] rust: pci: " Daniel Almeida
2025-06-09 12:53 ` Danilo Krummrich
2025-06-09 23:22 ` kernel test robot
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=aEbJt0YSc3-60OBY@pollux \
--to=dakr@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=bhelgaas@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=daniel.almeida@collabora.com \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=kwilczynski@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lossin@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).