To be able to constify instances of struct attribute it has to be
possible to add them to struct attribute_group. The current type of the
attrs member however is not compatible with that. Introduce a union that
allows registration of both const and non-const attributes to enable a
piecewise transition. As both union member types are compatible no
logic needs to be adapted.
Technically it is now possible register a const struct attribute and
receive it as mutable pointer in the callbacks. This is a soundness
issue. But this same soundness issue already exists today in
sysfs_create_file(). Also the struct definition and callback
implementation are always closely linked and are meant to be moved to
const in lockstep.
Similar to commit 906c508afd ("sysfs: attribute_group: allow
registration of const bin_attribute")
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://patch.msgid.link/20251029-sysfs-const-attr-prep-v5-1-ea7d745acff4@weissschuh.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The rust-next tree contains commit:
3b83f5d5e7 ("rust: replace `CStr` with `core::ffi::CStr`")
which, when merged together with commits:
57c5bd9aee ("rust: i2c: add basic I2C device and driver abstractions")
f3cc26a417 ("rust: i2c: add manual I2C device creation abstractions")
from this tree (driver-core), produces errors like the following:
error[E0599]: no method named `len_with_nul` found for reference `&'static ffi::CStr` in the current scope
--> rust/kernel/i2c.rs:48:16
|
48 | id.len_with_nul() <= Self::I2C_NAME_SIZE,
| ^^^^^^^^^^^^ method not found in `&CStr`
error[E0599]: no method named `as_bytes_with_nul` found for reference `&'static ffi::CStr` in the current scope
--> rust/kernel/i2c.rs:51:22
|
51 | let src = id.as_bytes_with_nul();
| ^^^^^^^^^^^^^^^^^
|
help: there is a method `to_bytes_with_nul` with a similar name
|
51 | let src = id.to_bytes_with_nul();
| ~~~~~~~~~~~~~~~~~
which were detected in linux-next by Stephen [1].
The `i2c` code can be independently prepared to be ready for the change,
thus do so.
The change is similar to the one done by Tamir in commit 657403637f
("rust: acpi: use `core::ffi::CStr` method names").
Link: https://lore.kernel.org/all/20251120181111.65ce75a0@canb.auug.org.au/ [1]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Link: https://patch.msgid.link/20251123163536.1771801-1-ojeda@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
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>
Add a new `rust_i2c_client` sample, showing how to create a new
i2c client using `i2c::Registration`
Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Igor Korotin <igor.korotin.linux@gmail.com>
Link: https://patch.msgid.link/20251116162210.171542-1-igor.korotin.linux@gmail.com
[ * Remove dependency to I2C_CHARDEV, depend on I2C=y.
* Remove unnecessary impl Drop for SampleDriver.
* Rename i2c::Registration, import Devres.
* Fixup module description.
* Add new source file to MAINTAINERS.
- Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Add a new `rust_driver_i2c` sample, showing how to create a new
i2c driver using ACPI/OF/Legacy ID tables.
Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Igor Korotin <igor.korotin.linux@gmail.com>
Link: https://patch.msgid.link/20251116162204.171518-1-igor.korotin.linux@gmail.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
In addition to the basic I2C device support, add rust abstractions
upon `i2c_new_client_device`/`i2c_unregister_device` C functions.
Implement the core abstractions needed for manual creation/deletion
of I2C devices, including:
* `i2c::Registration` — a NonNull pointer created by the function
`i2c_new_client_device`
* `i2c::I2cAdapter` — a ref counted wrapper around `struct i2c_adapter`
* `i2c::I2cBoardInfo` — a safe wrapper around `struct i2c_board_info`
Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Igor Korotin <igor.korotin.linux@gmail.com>
Link: https://patch.msgid.link/20251116162154.171493-1-igor.korotin.linux@gmail.com
[ Remove unnecessary safety comment. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Now that ResourceSize has been moved to kernel::io, import it from the
io module instead of the io::resource sub-module. It makes sense in this
case since the dma_len isn't really related to the Resource type even
though both are sizes of allocations in physical ram.
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20251112-resource-phys-typedefs-v2-3-538307384f82@google.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Resource sizes are a general concept for dealing with physical
addresses, and not specific to the Resource type, which is just one way
to access physical addresses. Thus, move the typedef to the io module.
Still keep a re-export under resource. This avoids this commit from
being a flag-day, but I also think it's a useful re-export in general so
that you can import
use kernel::io::resource::{Resource, ResourceSize};
instead of having to write
use kernel::io::{
resource::Resource,
ResourceSize,
};
in the specific cases where you need ResourceSize because you are using
the Resource type. Therefore I think it makes sense to keep this
re-export indefinitely and it is *not* intended as a temporary re-export
for migration purposes.
Cc: stable@vger.kernel.org # for v6.18 [1]
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20251112-resource-phys-typedefs-v2-2-538307384f82@google.com
Link: https://lore.kernel.org/all/20251112-resource-phys-typedefs-v2-0-538307384f82@google.com/ [1]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
In struct CoherentAllocation, use NonNull<T> instead of a raw *mut T for
the CPU address; the CPU address of a valid CoherentAllocation won't
ever be NULL.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20251103190655.2326191-2-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Using start_ptr() and start_ptr_mut() has the advantage that we inherit
the requirements the a mutable or immutable reference from those
methods.
Hence, use them instead of self.cpu_addr.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20251103190655.2326191-1-dakr@kernel.org
[ Keep using self.cpu_addr in item_from_index(). - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Commit 46f045db5a ("rust: Add read_poll_timeout_atomic function")
initiated the first import change in the I/O module using the agreed
"kernel vertical" import style [1].
For consistency throughout the module, adjust all other imports
accordingly.
While at it, drop unnecessary imports covered by prelude::*.
Link: https://docs.kernel.org/rust/coding-guidelines.html#imports [1]
Reviewed-by: Zhi Wang <zhiw@nvidia.com>
Link: https://patch.msgid.link/20251104133301.59402-1-dakr@kernel.org
[ Use prelude::* in io/poll.rs. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Currently request_irq_by_index() returns
Result<impl PinInit<irq::Registration<T>, Error> + 'a>
which may carry an error in the Result or the initializer; the same is
true for the other IRQ methods.
Use pin_init::pin_init_scope() to get rid of this redundancy.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20251103203053.2348783-2-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Currently request_irq() returns
Result<impl PinInit<irq::Registration<T>, Error> + 'a>
which may carry an error in the Result or the initializer; the same is
true for request_threaded_irq().
Use pin_init::pin_init_scope() to get rid of this redundancy.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20251103203053.2348783-1-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Some older (yet supported) versions of clippy throw a false positive
warning for missing a safety comment when the safety comment is on a
multiline statement.
warning: unsafe block missing a safety comment
--> rust/kernel/auxiliary.rs:351:22
|
351 | Self(unsafe { NonNull::new_unchecked(adev) }),
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: consider adding a safety comment on the preceding line
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#undocumented_unsafe_blocks
= note: requested on the command line with `-W clippy::undocumented-unsafe-blocks`
warning: 1 warning emitted
Fix this by placing the safety comment right on top of the same line
introducing the unsafe block.
Fixes: e4e679c860 ("rust: auxiliary: unregister on parent device unbind")
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://patch.msgid.link/20251103203932.2361660-1-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Extend the rust_debugfs_scoped sample to demonstrate how to export a
large binary object through a ScopedDir.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Matthew Maurer <mmaurer@google.com>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Add support for creating binary debugfs files via ScopedDir. This
mirrors the existing functionality for Dir, but without producing an
owning handle -- files are automatically removed when the associated
Scope is dropped.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Matthew Maurer <mmaurer@google.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Extend the Rust debugfs sample to demonstrate usage of binary file
support. The example now shows how to expose both fixed-size arrays
and dynamically sized vectors as binary blobs in debugfs.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Matthew Maurer <mmaurer@google.com>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Extend Rust debugfs binary support to allow exposing data stored in
common smart pointers and heap-allocated collections.
- Implement BinaryWriter for Box<T>, Pin<Box<T>>, Arc<T>, and Vec<T>.
- Introduce BinaryReaderMut for mutable binary access with outer locks.
- Implement BinaryReaderMut for Box<T>, Vec<T>, and base types.
- Update BinaryReader to delegate to BinaryReaderMut for Mutex<T>,
Box<T>, Pin<Box<T>> and Arc<T>.
This enables debugfs files to directly expose or update data stored
inside heap-allocated, reference-counted, or lock-protected containers
without manual dereferencing or locking.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Matthew Maurer <mmaurer@google.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Introduce support for read-only, write-only, and read-write binary files
in Rust debugfs. This adds:
- BinaryWriter and BinaryReader traits for writing to and reading from
user slices in binary form.
- New Dir methods: read_binary_file(), write_binary_file(),
`read_write_binary_file`.
- Corresponding FileOps implementations: BinaryReadFile,
BinaryWriteFile, BinaryReadWriteFile.
This allows kernel modules to expose arbitrary binary data through
debugfs, with proper support for offsets and partial reads/writes.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Matthew Maurer <mmaurer@google.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Add UserSliceWriter::write_slice_file(), which is the same as
UserSliceWriter::write_slice_partial() but updates the given
file::Offset by the number of bytes written.
This is equivalent to C's `simple_read_from_buffer()` and useful when
dealing with file offsets from file operations.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Miguel Ojeda <ojeda@kernel.org>
[ Replace saturating_add() with the raw operator and a corresponding
OVERFLOW comment. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
The existing write_slice() method is a wrapper around copy_to_user() and
expects the user buffer to be larger than the source buffer.
However, userspace may split up reads in multiple partial operations
providing an offset into the source buffer and a smaller user buffer.
In order to support this common case, provide a helper for partial
writes.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Matthew Maurer <mmaurer@google.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Miguel Ojeda <ojeda@kernel.org>
[ Replace map_or() with let-else; use saturating_add(). - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Add UserSliceReader::read_slice_file(), which is the same as
UserSliceReader::read_slice_partial() but updates the given file::Offset
by the number of bytes read.
This is equivalent to C's `simple_write_to_buffer()` and useful when
dealing with file offsets from file operations.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Miguel Ojeda <ojeda@kernel.org>
[ Replace saturating_add() with the raw operator and a corresponding
OVERFLOW comment. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
The existing read_slice() method is a wrapper around copy_from_user()
and expects the user buffer to be larger than the destination buffer.
However, userspace may split up writes in multiple partial operations
providing an offset into the destination buffer and a smaller user
buffer.
In order to support this common case, provide a helper for partial
reads.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Matthew Maurer <mmaurer@google.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Miguel Ojeda <ojeda@kernel.org>
[ Replace map_or() with let-else; use saturating_add(). - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Add a type alias for file offsets, i.e. bindings::loff_t. Trying to
avoid using raw bindings types, this seems to be the better alternative
compared to just using i64.
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Jan Kara <jack@suse.cz>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Link: https://patch.msgid.link/20251020222722.240473-2-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Add read_poll_timeout_atomic function which polls periodically until a
condition is met, an error occurs, or the attempt limit is reached.
The C's read_poll_timeout_atomic() is used for the similar purpose.
In atomic context the timekeeping infrastructure is unavailable, so
reliable time-based timeouts cannot be implemented. So instead, the
helper accepts a maximum number of attempts and busy-waits (udelay +
cpu_relax) between tries.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Link: https://patch.msgid.link/20251103112958.2961517-3-fujita.tomonori@gmail.com
[ Adjust imports to use "kernel vertical" style. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Add udelay() function, inserts a delay based on microseconds with busy
waiting, in preparation for supporting read_poll_timeout_atomic().
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Acked-by: Andreas Hindborg <a.hindborg@kernel.org>
Link: https://patch.msgid.link/20251103112958.2961517-2-fujita.tomonori@gmail.com
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: 6bbaa93912 ("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>
Illustrate how a parent driver of an auxiliary driver can take advantage
of the device context guarantees given by the auxiliary bus and
subsequently safely derive its device private data.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
In ParentDriver::connect() rename parent to dev, use it for the
dev_info!() call, call pdev.vendor_() directly in the print statement
and remove the unnecessary generic type of Result.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Take advantage of the fact that if the auxiliary device is bound the
parent is guaranteed to be bound as well and implement a separate
parent() method for auxiliary::Device<Bound>.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Currently, the parent method is implemented for any Device<Ctx>, i.e.
any device context and returns a &device::Device<Normal>.
However, a subsequent patch will introduce
impl Device<Bound> {
pub fn parent() -> device::Device<Bound> { ... }
}
which takes advantage of the fact that if the auxiliary device is bound
the parent is guaranteed to be bound as well.
I.e. the behavior we want is that all device contexts that dereference
to Bound, will use the implementation above, whereas the old
implementation should only be implemented for Device<Normal>.
Hence, move the current implementation.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Guarantee that an auxiliary driver will be unbound before its parent is
unbound; there is no point in operating an auxiliary device whose parent
has been unbound.
In practice, this guarantee allows us to assume that for a bound
auxiliary device, also the parent device is bound.
This is useful when an auxiliary driver calls into its parent, since it
allows the parent to directly access device resources and its device
private data due to the guaranteed bound device context.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
An auxiliary device is guaranteed to always have a parent device (both
in C and Rust), hence don't return an Option<&auxiliary::Device> in
auxiliary::Device::parent().
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
In C dev_get_drvdata() has specific requirements under which it is valid
to access the returned pointer. That is, drivers have to ensure that
(1) for the duration the returned pointer is accessed the driver is
bound and remains to be bound to the corresponding device,
(2) the returned void * is treated according to the driver's private
data type, i.e. according to what has been passed to
dev_set_drvdata().
In Rust, (1) can be ensured by simply requiring the Bound device
context, i.e. provide the drvdata() method for Device<Bound> only.
For (2) we would usually make the device type generic over the driver
type, e.g. Device<T: Driver>, where <T as Driver>::Data is the type of
the driver's private data.
However, a device does not have a driver type known at compile time and
may be bound to multiple drivers throughout its lifetime.
Hence, in order to be able to provide a safe accessor for the driver's
device private data, we have to do the type check on runtime.
This is achieved by letting a driver assert the expected type, which is
then compared to a type hash stored in struct device_private when
dev_set_drvdata() is called.
Example:
// `dev` is a `&Device<Bound>`.
let data = dev.drvdata::<SampleDriver>()?;
There are two aspects to note:
(1) Technically, the same check could be achieved by comparing the
struct device_driver pointer of struct device with the struct
device_driver pointer of the driver struct (e.g. struct
pci_driver).
However, this would - in addition the pointer comparison - require
to tie back the private driver data type to the struct
device_driver pointer of the driver struct to prove correctness.
Besides that, accessing the driver struct (stored in the module
structure) isn't trivial and would result into horrible code and
API ergonomics.
(2) Having a direct accessor to the driver's private data is not
commonly required (at least in Rust): Bus callback methods already
provide access to the driver's device private data through a &self
argument, while other driver entry points such as IRQs,
workqueues, timers, IOCTLs, etc. have their own private data with
separate ownership and lifetime.
In other words, a driver's device private data is only relevant
for driver model contexts (such a file private is only relevant
for file contexts).
Having that said, the motivation for accessing the driver's device
private data with Device<Bound>::drvdata() are interactions between
drivers. For instance, when an auxiliary driver calls back into its
parent, the parent has to be capable to derive its private data from the
corresponding device (i.e. the parent of the auxiliary device).
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ * Remove unnecessary `const _: ()` block,
* rename type_id_{store,match}() to {set,match}_type_id(),
* assert size_of::<bindings::driver_type>() >= size_of::<TypeId>(),
* add missing check in case Device::drvdata() is called from probe().
- Danilo ]
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>
Here are some small char/misc/android driver fixes for 6.18-rc3 for
reported issues. Included in here are:
- rust binder fixes for reported issues
- mei device id addition
- mei driver fixes
- comedi bugfix
- most usb driver bugfixes
- fastrpc memory leak fix
All of these have been in linux-next for a while with no reported
issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCaP4lRQ8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ylROwCfXKoJX39yhNjPuNdqVLp5wW4+1LsAn3fd7x0E
9czT0dxL2IipOWrV1ZMj
=Gu5v
-----END PGP SIGNATURE-----
Merge tag 'char-misc-6.18-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc driver fixes from Greg KH:
"Here are some small char/misc/android driver fixes for 6.18-rc3 for
reported issues. Included in here are:
- rust binder fixes for reported issues
- mei device id addition
- mei driver fixes
- comedi bugfix
- most usb driver bugfixes
- fastrpc memory leak fix
All of these have been in linux-next for a while with no reported
issues"
* tag 'char-misc-6.18-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
most: usb: hdm_probe: Fix calling put_device() before device initialization
most: usb: Fix use-after-free in hdm_disconnect
binder: remove "invalid inc weak" check
mei: txe: fix initialization order
comedi: fix divide-by-zero in comedi_buf_munge()
mei: late_bind: Fix -Wincompatible-function-pointer-types-strict
misc: fastrpc: Fix dma_buf object leak in fastrpc_map_lookup
mei: me: add wildcat lake P DID
misc: amd-sbi: Clarify that this is a BMC driver
nvmem: rcar-efuse: add missing MODULE_DEVICE_TABLE
binder: Fix missing kernel-doc entries in binder.c
rust_binder: report freeze notification only when fully frozen
rust_binder: don't delete FreezeListener if there are pending duplicates
rust_binder: freeze_notif_done should resend if wrong state
rust_binder: remove warning about orphan mappings
rust_binder: clean `clippy::mem_replace_with_default` warning
Here are some small staging driver fixes for the gpib subsystem to
resolve some reported issues. Included in here are:
- memory leak fixes
- error code fixes
- proper protocol fixes
All of these have been in linux-next for almost 2 weeks now with no
reported issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCaP4l4g8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ym2zACgq0WPUJl3X/5+M0sWs9rd4afh2TMAn1RlLJZE
1Qj5OIhSn1v5SfkLyqXf
=Wn6c
-----END PGP SIGNATURE-----
Merge tag 'staging-6.18-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
Pull staging driver fixes from Greg KH:
"Here are some small staging driver fixes for the gpib subsystem to
resolve some reported issues. Included in here are:
- memory leak fixes
- error code fixes
- proper protocol fixes
All of these have been in linux-next for almost 2 weeks now with no
reported issues"
* tag 'staging-6.18-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
staging: gpib: Fix device reference leak in fmh_gpib driver
staging: gpib: Return -EINTR on device clear
staging: gpib: Fix sending clear and trigger events
staging: gpib: Fix no EOI on 1 and 2 byte writes
Here are some small tty and serial driver fixes for reported issues.
Included in here are:
- sh-sci serial driver fixes
- 8250_dw and _mtk driver fixes
- sc16is7xx driver bugfix
- new 8250_exar device ids added
All of these have been in linux-next this past week with no reported
issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCaP4mow8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ykXPACfVp7KKDyM+10AxrV/xccYT53iUaAAoMQEWvES
/0acQXalH6XunybjHkOd
=cBYS
-----END PGP SIGNATURE-----
Merge tag 'tty-6.18-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull tty/serial driver fixes from Greg KH:
"Here are some small tty and serial driver fixes for reported issues.
Included in here are:
- sh-sci serial driver fixes
- 8250_dw and _mtk driver fixes
- sc16is7xx driver bugfix
- new 8250_exar device ids added
All of these have been in linux-next this past week with no reported
issues"
* tag 'tty-6.18-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
serial: 8250_mtk: Enable baud clock and manage in runtime PM
serial: 8250_dw: handle reset control deassert error
dt-bindings: serial: sh-sci: Fix r8a78000 interrupts
serial: sc16is7xx: remove useless enable of enhanced features
serial: 8250_exar: add support for Advantech 2 port card with Device ID 0x0018
tty: serial: sh-sci: fix RSCI FIFO overrun handling
Here are some small USB driver fixes and new device ids for 6.18-rc3.
Included in here are:
- new option serial driver device ids added
- dt bindings fixes for numerous platforms
- xhci bugfixes for many reported regressions
- usbio dependency bugfix
- dwc3 driver fix
- raw-gadget bugfix
All of these have been in linux-next this week with no reported issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCaP4nSw8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+yliXgCfZzBRNhHGVV0gQrBy2dz9owzfhLQAoISf3He8
dwzYP7TSYXungxfq9dSL
=NaGG
-----END PGP SIGNATURE-----
Merge tag 'usb-6.18-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB driver fixes from Greg KH:
"Here are some small USB driver fixes and new device ids for 6.18-rc3.
Included in here are:
- new option serial driver device ids added
- dt bindings fixes for numerous platforms
- xhci bugfixes for many reported regressions
- usbio dependency bugfix
- dwc3 driver fix
- raw-gadget bugfix
All of these have been in linux-next this week with no reported issues"
* tag 'usb-6.18-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
USB: serial: option: add Telit FN920C04 ECM compositions
USB: serial: option: add Quectel RG255C
tcpm: switch check for role_sw device with fw_node
usb/core/quirks: Add Huawei ME906S to wakeup quirk
usb: raw-gadget: do not limit transfer length
USB: serial: option: add UNISOC UIS7720
xhci: dbc: enable back DbC in resume if it was enabled before suspend
xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races with stall event
usb: xhci-pci: Fix USB2-only root hub registration
dt-bindings: usb: qcom,snps-dwc3: Fix bindings for X1E80100
usb: misc: Add x86 dependency for Intel USBIO driver
dt-bindings: usb: switch: split out ports definition
usb: dwc3: Don't call clk_bulk_disable_unprepare() twice
dt-bindings: usb: dwc3-imx8mp: dma-range is required only for imx8mp
a Clang build
- Make sure a Retbleed mitigation message is printed only when necessary
- Correct the last Zen1 microcode revision for which Entrysign sha256 check is
needed
- Fix a NULL ptr deref when mounting the resctrl fs on a system which supports
assignable counters but where L3 total and local bandwidth monitoring has
been disabled at boot
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEzv7L6UO9uDPlPSfHEsHwGGHeVUoFAmj+FSYACgkQEsHwGGHe
VUqh5RAAwTAfMsEs57v6gQqnm/rbNjGXoZuNcT9xhk4jbRC7xCcyJrZVyYA+mWIe
5rgGOuSThOsOgqJHwVqn4kdym9yUwLradZS8gn5vHFIlDVXDoMRYJuvm8U7PdTug
UWJv0uw0B393RNb+7yCeEN7Zpe2bvbh25PF66uh/7dQYKmWIaiTVlDhrZ+Ba51IK
mmJzbVb6zqWrSP3heISZRjfV3rv+/SifUb+wIgWcCzcAb36fFIlUKaEYd/g5249R
BBcEY5n/eUUKjMJVOki4vDqJyQdPdJCz9yH3qdZaz661Wh9/FVy/rLCQC/O1ruwt
Ovoi6UJAjleb0OXfi00Hl1LT3v92xH/OwyVCamBAYyaIhTdPaoQS6YADGstt3PTx
RUc/BG5wHyaOWsG94zVEvqK9MElyjW3DPiBH4E+O7OB348WAfhsbrUDnnaveDSym
n2LivNnkiaXi8DpPhWL7XsJJjYAy1fi2piDrh952I5oVfhf5iYeNwFjNdtgAft7G
wNr01qraqdPKfMYHZHdkaqrPH/Qy9DlLuDuTjQqtjGm8lsZK/g+txzQLfeXoDJSe
RtKtRYlq0bVCOnAuA8MN4xi9H2WaKAZNgavJxywZslmaQuQzh21g7ISwxcAFe07n
nevcypF1s/dnCUPK8yuKTmFzkwbg7I2OgrmX0RKZdFxY8uzg4Co=
=EZGc
-----END PGP SIGNATURE-----
Merge tag 'x86_urgent_for_v6.18_rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Borislav Petkov:
- Remove dead code leftovers after a recent mitigations cleanup which
fail a Clang build
- Make sure a Retbleed mitigation message is printed only when
necessary
- Correct the last Zen1 microcode revision for which Entrysign sha256
check is needed
- Fix a NULL ptr deref when mounting the resctrl fs on a system which
supports assignable counters but where L3 total and local bandwidth
monitoring has been disabled at boot
* tag 'x86_urgent_for_v6.18_rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/bugs: Remove dead code which might prevent from building
x86/bugs: Qualify RETBLEED_INTEL_MSG
x86/microcode: Fix Entrysign revision check for Zen1/Naples
x86,fs/resctrl: Fix NULL pointer dereference with events force-disabled in mbm_event mode
