From: "Danilo Krummrich" <dakr@kernel.org>
To: "Alice Ryhl" <aliceryhl@google.com>
Cc: <gregkh@linuxfoundation.org>, <rafael@kernel.org>,
<ojeda@kernel.org>, <alex.gaynor@gmail.com>,
<boqun.feng@gmail.com>, <gary@garyguo.net>,
<bjorn3_gh@protonmail.com>, <lossin@kernel.org>,
<a.hindborg@kernel.org>, <tmgross@umich.edu>,
<rust-for-linux@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/3] device: rust: expand documentation for Device
Date: Mon, 21 Jul 2025 14:07:56 +0200 [thread overview]
Message-ID: <DBHPYX0Y0NN5.2NMGLAY6PWBQU@kernel.org> (raw)
In-Reply-To: <aH4juIVmj8euE1CA@google.com>
On Mon Jul 21, 2025 at 1:26 PM CEST, Alice Ryhl wrote:
> On Fri, Jul 18, 2025 at 12:45:38AM +0200, Danilo Krummrich wrote:
>> +/// All [`DeviceContext`] types other than [`Normal`] are intended to be used with
>> +/// [bus devices](#bus-devices) only.
>
> This raises a few questions for me.
>
> The first one is "why"? On other series I have been told that interrupts
> must be registered and deregistered before the device is unbound. Does
> the same not apply to interrupts for an input device such as a USB
> keyboard?
In your example there would be a USB device *and* an input device, where the
former is a bus device and the latter a class device.
Any resources from the "real" device on the bus are on the USB device, not the
input device.
Or in other words, class devices do not own resources of a "real" device and
consequently are never bound to or unbound from a "real" device on the bus.
> The second one is why we use the same `Device` type for both cases?
> Would it not make more sense to have a BusDevice and ClassDevice type?
Not really, the generic struct device isn't one or the other until it's used by
an actual higher level bus or class device implementation.
There isn't really a difference between the two for a base device.
Regarding the device context, a base device can inherit a device context from
the higher level bus or class device. In case of a class device, it's just that
there's nothing to inherit other than Normal.
>> +/// # Implementing Bus Devices
>> +///
>> +/// This section provides a guideline to implement bus specific devices, such as
>> +/// [`pci::Device`](kernel::pci::Device) or [`platform::Device`](kernel::platform::Device).
>> +///
>> +/// A bus specific device should be defined as follows.
>> +///
>> +/// ```ignore
>> +/// #[repr(transparent)]
>> +/// pub struct Device<Ctx: device::DeviceContext = device::Normal>(
>> +/// Opaque<bindings::bus_device_type>,
>> +/// PhantomData<Ctx>,
>> +/// );
>> +/// ```
>> +///
>> +/// Since devices are reference counted, [`AlwaysRefCounted`](kernel::types::AlwaysRefCounted)
>> +/// should be implemented for `Device` (i.e. `Device<Normal>`). Note that
>> +/// [`AlwaysRefCounted`](kernel::types::AlwaysRefCounted) must not be implemented for any other
>> +/// [`DeviceContext`], since all other device context types are only valid in a certain scope.
>
> As a general comment to all three patches, I would suggest separating
> out the link locations.
>
> /// Since devices are reference counted, [`AlwaysRefCounted`] should be
> /// implemented for `Device` (i.e. `Device<Normal>`). Note that
> /// [`AlwaysRefCounted`] must not be implemented for any other
> /// [`DeviceContext`], since all other device context types are only
> /// valid in a certain scope.
>
> and then at the end:
>
> /// [`AlwaysRefCounted`]: kernel::types::AlwaysRefCounted
>
> I think it's a lot easier to read the markdown version when links are
> separated out like this.
That's a good suggestion, thanks!
next prev parent reply other threads:[~2025-07-21 12:08 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-17 22:45 [PATCH 0/3] Documentation for Device / Driver infrastructure Danilo Krummrich
2025-07-17 22:45 ` [PATCH 1/3] device: rust: documentation for DeviceContext Danilo Krummrich
2025-07-18 12:32 ` Alexandre Courbot
2025-07-18 13:14 ` Danilo Krummrich
2025-07-21 13:48 ` Benno Lossin
2025-07-18 13:09 ` Daniel Almeida
2025-07-18 14:16 ` Danilo Krummrich
2025-07-20 15:45 ` Daniel Almeida
2025-07-17 22:45 ` [PATCH 2/3] device: rust: expand documentation for Device Danilo Krummrich
2025-07-20 15:56 ` Daniel Almeida
2025-07-21 11:26 ` Alice Ryhl
2025-07-21 11:42 ` Greg KH
2025-07-21 12:07 ` Alice Ryhl
2025-07-21 12:13 ` Danilo Krummrich
2025-07-21 13:17 ` Greg KH
2025-07-21 13:41 ` Danilo Krummrich
2025-07-21 12:07 ` Danilo Krummrich [this message]
2025-07-17 22:45 ` [PATCH 3/3] driver: rust: expand documentation for driver infrastructure Danilo Krummrich
2025-07-20 15:57 ` Daniel Almeida
2025-07-19 7:56 ` [PATCH 0/3] Documentation for Device / Driver infrastructure Greg KH
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=DBHPYX0Y0NN5.2NMGLAY6PWBQU@kernel.org \
--to=dakr@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=ojeda@kernel.org \
--cc=rafael@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--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).