| Age | Commit message (Collapse) | Author |
|---|
|
Implement the `AsBusDevice` trait for converting a `Device` reference to a
bus device reference for all bus devices.
The `AsBusDevice` trait allows abstractions to provide the bus device in
class device callbacks. It must not be used by drivers and is intended for
bus and class device abstractions only.
Signed-off-by: Markus Probst <markus.probst@posteo.de>
Link: https://patch.msgid.link/20251027200547.1038967-2-markus.probst@posteo.de
[ * Remove unused import.
* Change visibility of AsBusDevice to public.
* Fix build for USB.
* Add impl for I2cClient.
- Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
A refactoring of Device::drvdata_obtain() broke T::disconnect() in the
USB abstractions.
"""
error[E0599]: no method named `data` found for struct `core::pin::Pin<kbox::Box<T, Kmalloc>>` in the current scope
--> rust/kernel/usb.rs:92:34
|
92 | T::disconnect(intf, data.data());
| ^^^^ method not found in `core::pin::Pin<kbox::Box<T, Kmalloc>>`
error: aborting due to 1 previous error
For more information about this error, try `rustc --explain E0599`.
make[2]: *** [rust/Makefile:553: rust/kernel.o] Error 1
make[1]: *** [/builddir/build/BUILD/kernel-6.18.0-build/kernel-next-20251103/linux-6.18.0-0.0.next.20251103.436.vanilla.fc44.x86_64/Makefile:1316: prepare] Error 2
make: *** [Makefile:256: __sub-make] Error 2
"""
This slipped through, since the USB abstractions are globally disabled.
However, the USB tree recently enabled them, hence it showed up in
linux-next.
Reported-by: Thorsten Leemhuis <linux@leemhuis.info>
Closes: https://lore.kernel.org/all/1c8afbc0-e888-4702-9e4e-fa8aef0f97ae@leemhuis.info/
Fixes: 6bbaa93912bf ("rust: device: narrow the generic of drvdata_obtain()")
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Tested-by: Thorsten Leemhuis <linux@leemhuis.info>
Link: https://patch.msgid.link/20251103110115.1925072-1-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Let T be the actual private driver data type without the surrounding
box, as it leaves less room for potential bugs.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
The driver model defines the lifetime of the private data stored in (and
owned by) a bus device to be valid from when the driver is bound to a
device (i.e. from successful probe()) until the driver is unbound from
the device.
This is already taken care of by the Rust implementation of the driver
model. However, we still ask drivers to return a Result<Pin<KBox<Self>>>
from probe().
Unlike in C, where we do not have the concept of initializers, but
rather deal with uninitialized memory, drivers can just return an
impl PinInit<Self, Error> instead.
This contributes to more clarity to the fact that a driver returns it's
device private data in probe() and the Rust driver model owns the data,
manages the lifetime and - considering the lifetime - provides (safe)
accessors for the driver.
Hence, let probe() functions return an impl PinInit<Self, Error> instead
of Result<Pin<KBox<Self>>>.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
The USB abstractions target to support USB interface drivers.
While internally the abstraction has to deal with the interface's parent
USB device, there shouldn't be a need for users to deal with the parent
USB device directly.
Functions, such as for preparing and sending USB URBs, can be
implemented for the usb::Interface structure directly. Whether this
internal implementation has to deal with the parent USB device can
remain transparent to USB interface drivers.
Hence, keep the usb::Device structure private for now, in order to avoid
confusion for users and to make it less likely to accidentally expose
APIs with unnecessary indirections.
Should we start supporting USB device drivers, or need it for any other
reason we do not foresee yet, it should be trivial to make it public
again.
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Link: https://lore.kernel.org/r/20250925190400.144699-2-dakr@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
When deriving the parent USB device (struct usb_device) from a USB
interface (struct usb_interface), do not retain the device context.
For the Bound context, as pointed out by Alan in [1], it is not
guaranteed that the parent USB device is always bound when the interface
is bound.
The bigger problem, however, is that we can't infer the Core context,
since eventually it indicates that the device lock is held. However,
there is no guarantee that if the device lock of the interface is held,
also the device lock of the parent USB device is held.
Hence, fix this by not inferring any device context information; while
at it, fix up the (affected) safety comments.
Link: https://lore.kernel.org/all/0ff2a825-1115-426a-a6f9-df544cd0c5fc@rowland.harvard.edu/ [1]
Fixes: e7e2296b0ecf ("rust: usb: add basic USB abstractions")
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Link: https://lore.kernel.org/r/20250925190400.144699-1-dakr@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Add basic USB abstractions, consisting of usb::{Device, Interface,
Driver, Adapter, DeviceId} and the module_usb_driver macro. This is the
first step in being able to write USB device drivers, which paves the
way for USB media drivers - for example - among others.
This initial support will then be used by a subsequent sample driver,
which constitutes the only user of the USB abstractions so far.
Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com>
Link: https://lore.kernel.org/r/20250825-b4-usb-v1-1-7aa024de7ae8@collabora.com
[ force USB = y for now - gregkh ]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
