From: Daniel Almeida <daniel.almeida@collabora.com>
To: Danilo Krummrich <dakr@kernel.org>
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 1/2] rust: irq: add support for request_irq()
Date: Mon, 2 Jun 2025 11:40:43 -0300 [thread overview]
Message-ID: <1FCFF2CD-9CF1-4716-AFDA-78A5AFAF113F@collabora.com> (raw)
In-Reply-To: <aCXxnUdO8--5y8Zo@pollux>
Danilo,
> On 15 May 2025, at 10:52, Danilo Krummrich <dakr@kernel.org> wrote:
>
> On Thu, May 15, 2025 at 03:45:28PM +0200, Danilo Krummrich wrote:
>> On Thu, May 15, 2025 at 10:16:33AM -0300, Daniel Almeida wrote:
>>>
>>>>>
>>>>> Well, not really, because this impl PinInit can be assigned to something larger
>>>>> that is already pinned, like drm::Device::Data for example, which is (or was)
>>>>> already behind an Arc, or any other private data in other subsystems.
>>>>>
>>>>> IIUC what you proposed has yet another indirection. If we reuse the example
>>>>> from above, that would be an Arc for the drm Data, and another Arc for the
>>>>> handler itself?
>>>>
>>>> Can't you implement Handler for drm::Device::Data and e.g. make Registration
>>>> take an Arc<T: Handler>?
>>>
>>> No, because drivers may need more than one handler. Panthor needs 3, for
>>> example, for 3 different lines.
>>>
>>>>
>>>> The irq::Registration itself doesn't need to be allocated dynamically, so it'd
>>>> still be a single allocation, no?
>>>>
>>>
>>> Right, the registrations don't, but the handlers do.
>>
>> Why does the handler need to be allocated dynamically?
>>
>> What about something like the following?
>>
>> pub struct Registration<T, H: Handler<T>> { ... };
>>
>> pub trait Handler<T> {
>> fn handle_irq(&T) -> IrqReturn;
>> }
>>
>> // Could be `drm::Device::Data`.
>> struct MyData { ... };
>>
>> // Implements `Handler<MyData>`.
>> struct IRQHandler1;
>> struct IRQHandler2;
>>
>> // `data` is `Arc<MyData>`
>> irq::Registration::<IRQHandler1>::new(data, ...);
>> irq::Registration::<IRQHandler2>::new(data, ...);
>>
>> With that you can have as many IRQs as you want without any additional
>> allocation.
>
> Alternatively we could also do the following, which is probably simpler.
>
> pub struct Registration<H: Handler> { ... };
>
> pub trait Handler {
> fn handle_irq(&self) -> IrqReturn;
> }
>
> // Could be `drm::Device::Data`.
> struct MyData { ... };
>
> // Implements `Handler`.
> struct IRQHandler1(Arc<MyData>);
> struct IRQHandler2(Arc<MyData>);
>
> // `data` is `Arc<MyData>`
> let handler1 = IRQHandler1::new(data);
> let handler2 = IRQHandler2::new(data);
>
> irq::Registration::new(handler1, ...);
> irq::Registration::new(handler2, ...);
>
I am trying to implement this, but isn't this what we have already?
I guess the only difference would be removing the handler() accessor, as the
caller is now expected to figure this part out on his own, i.e.:
In your example (IIUC) that would mean accessing the Arc in IRQHandler1
and IRQHandler2 through some other clone and from the actual T:Handler in
the callback.
— Daniel
next prev parent reply other threads:[~2025-06-02 14:41 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 [this message]
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
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=1FCFF2CD-9CF1-4716-AFDA-78A5AFAF113F@collabora.com \
--to=daniel.almeida@collabora.com \
--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=dakr@kernel.org \
--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
all inboxes | Powered by JetHome®