All of lore.kernel.org
 help / color / mirror / Atom feed
From: Danilo Krummrich <dakr@kernel.org>
To: Boqun Feng <boqun.feng@gmail.com>
Cc: "Alice Ryhl" <aliceryhl@google.com>,
	"Benno Lossin" <lossin@kernel.org>,
	"Daniel Almeida" <daniel.almeida@collabora.com>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Alex Gaynor" <alex.gaynor@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Krzysztof Wilczy´nski" <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: Tue, 24 Jun 2025 16:56:54 +0200	[thread overview]
Message-ID: <aFq8tiJfU-KshBIN@cassiopeiae> (raw)
In-Reply-To: <aFq5PVhm3ybiw12I@Mac.home>

On Tue, Jun 24, 2025 at 07:42:05AM -0700, Boqun Feng wrote:
> On Tue, Jun 24, 2025 at 07:33:35AM -0700, Boqun Feng wrote:
> > On Tue, Jun 24, 2025 at 02:50:23PM +0100, Alice Ryhl wrote:
> > > On Tue, Jun 24, 2025 at 1:46 PM Benno Lossin <lossin@kernel.org> wrote:
> > > >
> > > > On Tue Jun 24, 2025 at 2:31 PM CEST, Daniel Almeida wrote:
> > > > > On 23 Jun 2025, at 16:28, Benno Lossin <lossin@kernel.org> wrote:
> > > > >> On Mon Jun 23, 2025 at 9:18 PM CEST, Boqun Feng wrote:
> > > > >>>    try_pin_init!(&this in Self {
> > > > >>>        handler,
> > > > >>>        inner: Devres::new(
> > > > >>>            dev,
> > > > >>>            RegistrationInner {
> > > > >>>                // Needs to use `handler` address as cookie, same for
> > > > >>>                // request_irq().
> > > > >>>                cookie: &raw (*(this.as_ptr().cast()).handler),
> > > > >>>                irq: {
> > > > >>>                     to_result(unsafe { bindings::request_irq(...) })?;
> > > > >>>  irq
> > > > >>> }
> > > > >>>             },
> > > > >>>             GFP_KERNEL,
> > > > >>>        )?,
> > > > >>>        _pin: PhantomPinned
> > > > >>>    })
> > > > >>
> > > > >> Well yes and no, with the Devres changes, the `cookie` can just be the
> > > > >> address of the `RegistrationInner` & we can do it this way :)
> > > > >>
> > > > >> ---
> > > > >> Cheers,
> > > > >> Benno
> > > > >
> > > > >
> > > > > No, we need this to be the address of the the whole thing (i.e.
> > > > > Registration<T>), otherwise you can’t access the handler in the irq
> > > > > callback.
> > 
> > You only need the access of `handler` in the irq callback, right? I.e.
> > passing the address of `handler` would suffice (of course you need
> > to change the irq callback as well).
> > 
> > > >
> > > > Gotcha, so you keep the cookie field, but you should still be able to
> > > > use `try_pin_init` & the devres improvements to avoid the use of
> > > > `pin_init_from_closure`.
> > > 
> > > It sounds like this is getting too complicated and that
> > > `pin_init_from_closure` is the simpler way to go.
> > 
> > Even if we use `pin_init_from_closure`, we still need the other
> > `try_pin_init` anyway for `Devres::new()` (or alternatively we can
> > implement a `RegistrationInner::new()`).
> > 
> > Below is what would look like with the Devres changes in mind:
> > 
> > 
> >     try_pin_init!(&this in Self {
> >         handler,
> >         inner: <- Devres::new(
> >             dev,
> >             try_pin_init!( RegistrationInner {
> >                 // Needs to use `handler` address as cookie, same for
> >                 // request_irq().
> >                 cookie: &raw (*(this.as_ptr().cast()).handler),
> > 		// @Benno, would this "this" work here?
> >                 irq: {
> >                      to_result(unsafe { bindings::request_irq(...) })?;
> >                      irq
> > 		}
> >              }),
> >         )?,
> >         _pin: PhantomPinned
> >     })
> > 
> > 
> 
> Never mind, `dev` is a `Device<Bound>` so it cannot be unbounded during
> the call ;-)

We even know that `dev` won't be unbound as long as the returned
`impl PinInit<Self, Error> + 'a` lives. :)

  reply	other threads:[~2025-06-24 14:57 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
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 [this message]
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=aFq8tiJfU-KshBIN@cassiopeiae \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.