aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2025-05-14rust: drm: gem: Use NonNull for Object::devLyude Paul1-3/+3
There is usually not much of a reason to use a raw pointer in a data struct, so move this to NonNull instead. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Link: https://lore.kernel.org/r/20250513221046.903358-2-lyude@redhat.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-05-13gpu: nova-core: move Firmware to firmware moduleAlexandre Courbot2-36/+43
We will extend the firmware methods, so move it to its own module instead to keep gpu.rs focused. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250507-nova-frts-v3-7-fcb02749754d@nvidia.com [ Don't require a bound device, remove pub visibility from Firmware fields, use FIRMWARE_VERSION consistently. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-05-13gpu: nova-core: fix layout of NV_PMC_BOOT_0Alexandre Courbot2-5/+39
The layout of NV_PMC_BOOT_0 has two small issues: - The "chipset" field, while useful to identify a chip, is actually an aggregate of two distinct fields named "architecture" and "implementation". - The "architecture" field is split, with its MSB being at a different location than the rest of its bits. Redefine the register layout to match its actual definition as provided by OpenRM and expose the fully-constructed "architecture" field through our own "Architecture" type. The "chipset" pseudo-field is also useful to have, so keep providing it. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250507-nova-frts-v3-6-fcb02749754d@nvidia.com [ Use Result from kernel::prelude. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-05-13gpu: nova-core: define registers layout using helper macroAlexandre Courbot4-54/+403
Add the register!() macro, which defines a given register's layout and provide bit-field accessors with a way to convert them to a given type. This macro will allow us to make clear definitions of the registers and manipulate their fields safely. The long-term goal is to eventually move it to the kernel crate so it can be used by other drivers as well, but it was agreed to first land it into nova-core and make it mature there. To illustrate its usage, use it to define the layout for the Boot0 (renamed to NV_PMC_BOOT_0 to match OpenRM's naming scheme) and take advantage of its accessors. Suggested-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250507-nova-frts-v3-5-fcb02749754d@nvidia.com [ Fix typo in commit message. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-05-13gpu: nova-core: take bound device in Gpu::newAlexandre Courbot1-6/+13
We will need to perform things like allocating DMA memory during device creation, so make sure to take the device context that will allow us to perform these actions. This also allows us to use Devres::access to obtain the BAR without holding a RCU lock. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250507-nova-frts-v3-4-fcb02749754d@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-05-13gpu: nova-core: add missing GA100 definitionAlexandre Courbot1-1/+2
linux-firmware contains a directory for GA100, and it is a defined chipset in Nouveau. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250507-nova-frts-v3-3-fcb02749754d@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-05-13gpu: nova-core: derive useful traits for ChipsetAlexandre Courbot1-1/+1
We will commonly need to compare chipset versions, so derive the ordering traits to make that possible. Also derive Copy and Clone since passing Chipset by value will be more efficient than by reference. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250507-nova-frts-v3-2-fcb02749754d@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-05-12drm: nova-drm: add initial driver skeletonDanilo Krummrich12-0/+405
Add the initial nova-drm driver skeleton. nova-drm is connected to nova-core through the auxiliary bus and implements the DRM parts of the nova driver stack. For now, it implements the fundamental DRM abstractions, i.e. creates a DRM device and registers it, exposing a three sample IOCTLs. DRM_IOCTL_NOVA_GETPARAM - provides the PCI bar size from the bar that maps the GPUs VRAM from nova-core DRM_IOCTL_NOVA_GEM_CREATE - creates a new dummy DRM GEM object and returns a handle DRM_IOCTL_NOVA_GEM_INFO - provides metadata for the DRM GEM object behind a given handle I implemented a small userspace test suite [1] that utilizes this interface. Link: https://gitlab.freedesktop.org/dakr/drm-test [1] Reviewed-by: Maxime Ripard <mripard@kernel.org> Acked-by: Dave Airlie <airlied@redhat.com> Link: https://lore.kernel.org/r/20250424160452.8070-3-dakr@kernel.org [ Kconfig: depend on DRM=y rather than just DRM. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-05-12gpu: nova-core: register auxiliary device for nova-drmDanilo Krummrich3-1/+11
Register an auxiliary device for nova-drm. For now always use zero for the auxiliary device's ID; we don't use it yet anyways. However, once it lands, we should switch to XArray. Acked-by: Dave Airlie <airlied@redhat.com> Link: https://lore.kernel.org/r/20250424160452.8070-2-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-05-12rust: devres: fix doctest build under `!CONFIG_PCI`Miguel Ojeda1-0/+1
The doctest requires `CONFIG_PCI`: error[E0432]: unresolved import `kernel::pci` --> rust/doctests_kernel_generated.rs:2689:44 | 2689 | use kernel::{device::Core, devres::Devres, pci}; | ^^^ no `pci` in the root | note: found an item that was configured out --> rust/kernel/lib.rs:96:9 note: the item is gated here --> rust/kernel/lib.rs:95:1 Thus conditionally compile it (which still checks the syntax). Fixes: f301cb978c06 ("rust: devres: implement Devres::access()") Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Link: https://lore.kernel.org/r/20250511182533.1016163-1-ojeda@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-05-04samples: rust: pci: take advantage of Devres::access()Danilo Krummrich1-6/+6
For the I/O operations executed from the probe() method, take advantage of Devres::access(), avoiding the atomic check and RCU read lock required otherwise entirely. Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Link: https://lore.kernel.org/r/20250428140137.468709-4-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-05-04rust: devres: implement Devres::access()Danilo Krummrich1-0/+38
Implement a direct accessor for the data stored within the Devres for cases where we can prove that we own a reference to a Device<Bound> (i.e. a bound device) of the same device that was used to create the corresponding Devres container. Usually, when accessing the data stored within a Devres container, it is not clear whether the data has been revoked already due to the device being unbound and, hence, we have to try whether the access is possible and subsequently keep holding the RCU read lock for the duration of the access. However, when we can prove that we hold a reference to Device<Bound> matching the device the Devres container has been created with, we can guarantee that the device is not unbound for the duration of the lifetime of the Device<Bound> reference and, hence, it is not possible for the data within the Devres container to be revoked. Therefore, in this case, we can bypass the atomic check and the RCU read lock, which is a great optimization and simplification for drivers. Reviewed-by: Christian Schrefl <chrisi.schrefl@gmail.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Link: https://lore.kernel.org/r/20250428140137.468709-3-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-05-04rust: revocable: implement Revocable::access()Danilo Krummrich1-0/+12
Implement an unsafe direct accessor for the data stored within the Revocable. This is useful for cases where we can prove that the data stored within the Revocable is not and cannot be revoked for the duration of the lifetime of the returned reference. Reviewed-by: Christian Schrefl <chrisi.schrefl@gmail.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Acked-by: Miguel Ojeda <ojeda@kernel.org> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Link: https://lore.kernel.org/r/20250428140137.468709-2-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-29rust: device: conditionally expect `dead_code` for `parent()`Miguel Ojeda1-0/+1
When `CONFIG_AUXILIARY_BUS` is disabled, `parent()` is still dead code: error: method `parent` is never used --> rust/kernel/device.rs:71:19 | 64 | impl<Ctx: DeviceContext> Device<Ctx> { | ------------------------------------ method in this implementation ... 71 | pub(crate) fn parent(&self) -> Option<&Self> { | ^^^^^^ | = note: `-D dead-code` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(dead_code)]` Thus reintroduce the `expect`, but now as a conditional one. Do so as `dead_code` since that is narrower. An `allow` would also be possible, but Danilo wants to catch new users in the future [1]. Link: https://lore.kernel.org/rust-for-linux/aBE8qQrpXOfru_K3@pollux/ [1] Fixes: ce735e73dd59 ("rust: auxiliary: add auxiliary device / driver abstractions") Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Link: https://lore.kernel.org/r/20250429210629.513521-1-ojeda@kernel.org [ Adjust commit subject to "rust: device: conditionally expect `dead_code` for `parent()`". - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-28MAINTAINERS: add DRM Rust source files to DRM DRIVERSDanilo Krummrich1-0/+2
Add the DRM Rust source files to the DRM DRIVERS maintainers entry. Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250410235546.43736-9-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-28rust: drm: gem: Add GEM object abstractionAsahi Lina7-2/+351
DRM GEM is the DRM memory management subsystem used by most modern drivers; add a Rust abstraction for DRM GEM. This includes the BaseObject trait, which contains operations shared by all GEM object classes. Signed-off-by: Asahi Lina <lina@asahilina.net> Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250410235546.43736-8-dakr@kernel.org [ Rework of GEM object abstractions * switch to the Opaque<T> type * fix (mutable) references to struct drm_gem_object (which in this context is UB) * drop all custom reference types in favor of AlwaysRefCounted * bunch of minor changes and simplifications (e.g. IntoGEMObject trait) * write and fix safety and invariant comments * remove necessity for and convert 'as' casts * original source archive: https://archive.is/dD5SL - Danilo ] [ Fix missing CONFIG_DRM guards in rust/helpers/drm.c. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-24rust: drm: file: Add File abstractionAsahi Lina5-2/+107
A DRM File is the DRM counterpart to a kernel file structure, representing an open DRM file descriptor. Add a Rust abstraction to allow drivers to implement their own File types that implement the DriverFile trait. Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Asahi Lina <lina@asahilina.net> Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250410235546.43736-7-dakr@kernel.org [ Rework of drm::File * switch to the Opaque<T> type * fix (mutable) references to struct drm_file (which in this context is UB) * restructure and rename functions to align with common kernel schemes * write and fix safety and invariant comments * remove necessity for and convert 'as' casts * original source archive: https://archive.is/GH8oy - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-24rust: drm: add DRM driver registrationAsahi Lina2-1/+60
Implement the DRM driver `Registration`. The `Registration` structure is responsible to register and unregister a DRM driver. It makes use of the `Devres` container in order to allow the `Registration` to be owned by devres, such that it is automatically dropped (and the DRM driver unregistered) once the parent device is unbound. Signed-off-by: Asahi Lina <lina@asahilina.net> Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250410235546.43736-6-dakr@kernel.org [ Rework of drm::Registration * move VTABLE to drm::Device to prevent use-after-free bugs; VTABLE needs to be bound to the lifetime of drm::Device, not the drm::Registration * combine new() and register() to get rid of the registered boolean * remove file_operations * move struct drm_device creation to drm::Device * introduce Devres * original source archive: https://archive.is/Pl9ys - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-24rust: drm: add device abstractionAsahi Lina4-8/+201
Implement the abstraction for a `struct drm_device`. A `drm::Device` creates a static const `struct drm_driver` filled with the data from the `drm::Driver` trait implementation of the actual driver creating the `drm::Device`. Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Asahi Lina <lina@asahilina.net> Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250410235546.43736-5-dakr@kernel.org [ Rewrite of drm::Device * full rewrite of the drm::Device abstraction using the subclassing pattern * original source archive: http://archive.today/5NxBo - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-24rust: drm: add driver abstractionsAsahi Lina3-0/+122
Implement the DRM driver abstractions. The `Driver` trait provides the interface to the actual driver to fill in the driver specific data, such as the `DriverInfo`, driver features and IOCTLs. Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Asahi Lina <lina@asahilina.net> Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250410235546.43736-4-dakr@kernel.org [ MISC changes * remove unnecessary DRM features; make remaining ones crate private * add #[expect(unused)] to avoid warnings * add sealed trait * remove shmem::Object references * original source archive: https://archive.is/Pl9ys - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-24rust: drm: ioctl: Add DRM ioctl abstractionAsahi Lina5-0/+171
DRM drivers need to be able to declare which driver-specific ioctls they support. Add an abstraction implementing the required types and a helper macro to generate the ioctl definition inside the DRM driver. Note that this macro is not usable until further bits of the abstraction are in place (but it will not fail to compile on its own, if not called). Signed-off-by: Asahi Lina <lina@asahilina.net> Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250410235546.43736-3-dakr@kernel.org [ MISC fixes * wrap raw_data in Opaque to avoid UB when creating a reference * fix IOCTL sample declaration * fix safety comment of IOCTL argument * original source archive: https://archive.is/LqHDQ - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-24drm: drv: implement __drm_dev_alloc()Danilo Krummrich2-16/+47
In the Rust DRM device abstraction we need to allocate a struct drm_device. Currently, there are two options, the deprecated drm_dev_alloc() (which does not support subclassing) and devm_drm_dev_alloc(). The latter supports subclassing, but also manages the initial reference through devres for the parent device. In Rust we want to conform with the subclassing pattern, but do not want to get the initial reference managed for us, since Rust has its own, idiomatic ways to properly deal with it. There are two options to achieve this. 1) Allocate the memory ourselves with a KBox. 2) Implement __drm_dev_alloc(), which supports subclassing, but is unmanged. While (1) would be possible, it would be cumbersome, since it would require exporting drm_dev_init() and drmm_add_final_kfree(). Hence, go with option (2) and implement __drm_dev_alloc(). Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250410235546.43736-2-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-22samples: rust: convert PCI rust sample driver to use try_access_with()Alexandre Courbot1-6/+5
This method limits the scope of the revocable guard and is considered safer to use for most cases, so let's showcase it here. Reviewed-by: Benno Lossin <benno.lossin@proton.me> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Miguel Ojeda <ojeda@kernel.org> Link: https://lore.kernel.org/r/20250411-try_with-v4-2-f470ac79e2e2@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-22rust/revocable: add try_access_with() convenience methodAlexandre Courbot1-0/+16
Revocable::try_access() returns a guard through which the wrapped object can be accessed. Code that can sleep is not allowed while the guard is held; thus, it is common for the caller to explicitly drop it before running sleepable code, e.g: let b = bar.try_access()?; let reg = b.readl(...); // Don't forget this or things could go wrong! drop(b); something_that_might_sleep(); let b = bar.try_access()?; let reg2 = b.readl(...); This is arguably error-prone. try_access_with() provides an arguably safer alternative, by taking a closure that is run while the guard is held, and by dropping the guard automatically after the closure completes. This way, code can be organized more clearly around the critical sections and the risk of forgetting to release the guard when needed is considerably reduced: let reg = bar.try_access_with(|b| b.readl(...))?; something_that_might_sleep(); let reg2 = bar.try_access_with(|b| b.readl(...))?; The closure can return nothing, or any value including a Result which is then wrapped inside the Option returned by try_access_with. Error management is driver-specific, so users are encouraged to create their own macros that map and flatten the returned values to something appropriate for the code they are working on. Suggested-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Acked-by: Miguel Ojeda <ojeda@kernel.org> Link: https://lore.kernel.org/r/20250411-try_with-v4-1-f470ac79e2e2@nvidia.com [ Link `None`, `Some`, `Option` in doc-comment. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-19samples: rust: add Rust auxiliary driver sampleDanilo Krummrich4-0/+134
Add a sample Rust auxiliary driver based on a PCI driver for QEMU's "pci-testdev" device. The PCI driver only registers an auxiliary device, in order to make the corresponding auxiliary driver probe. Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250414131934.28418-6-dakr@kernel.org [ Use `ok_or()` when accessing auxiliary::Device::parent(). - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-19rust: auxiliary: add auxiliary registrationDanilo Krummrich1-1/+87
Implement the `auxiliary::Registration` type, which provides an API to create and register new auxiliary devices in the system. Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250414131934.28418-5-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-19rust: auxiliary: add auxiliary device / driver abstractionsDanilo Krummrich7-1/+303
Implement the basic auxiliary abstractions required to implement a driver matching an auxiliary device. The design and implementation is analogous to PCI and platform and is based on the generic device / driver abstractions. Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250414131934.28418-4-dakr@kernel.org [ Fix typos, `let _ =` => `drop()`, use `kernel::ffi`. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-19rust: device: implement Device::parent()Danilo Krummrich1-0/+19
Device::parent() returns a reference to the device' parent device, if any. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250414131934.28418-3-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-19rust: types: add `Opaque::zeroed`Danilo Krummrich1-0/+8
Analogous to `Opaque::uninit` add `Opaque::zeroed`, which sets the corresponding memory to zero. In contrast to `Opaque::uninit`, the corresponding value, depending on its type, may be initialized. Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Miguel Ojeda <ojeda@kernel.org> Link: https://lore.kernel.org/r/20250414131934.28418-2-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-19rust: platform: impl TryFrom<&Device> for &platform::DeviceDanilo Krummrich2-1/+26
Implement TryFrom<&device::Device> for &Device. This allows us to get a &platform::Device from a generic &Device in a safe way; the conversion fails if the device' bus type does not match with the platform bus type. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Link: https://lore.kernel.org/r/20250321214826.140946-4-dakr@kernel.org [ Support device context types, use dev_is_platform() helper. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-19rust: pci: impl TryFrom<&Device> for &pci::DeviceDanilo Krummrich2-1/+26
Implement TryFrom<&device::Device> for &Device. This allows us to get a &pci::Device from a generic &Device in a safe way; the conversion fails if the device' bus type does not match with the PCI bus type. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Link: https://lore.kernel.org/r/20250321214826.140946-3-dakr@kernel.org [ Support device context types, use dev_is_pci() helper. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-17rust: dma: require a bound deviceDanilo Krummrich1-7/+7
Require the Bound device context to be able to create new dma::CoherentAllocation instances. DMA memory allocations are only valid to be created for bound devices. Link: https://lore.kernel.org/r/20250413173758.12068-10-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-17rust: devres: require a bound deviceDanilo Krummrich1-10/+7
Require the Bound device context to be able to a new Devres container. This ensures that we can't register devres callbacks for unbound devices. Link: https://lore.kernel.org/r/20250413173758.12068-9-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-17rust: pci: move iomap_region() to impl Device<Bound>Danilo Krummrich1-0/+2
Require the Bound device context to be able to call iomap_region() and iomap_region_sized(). Creating I/O mapping requires the device to be bound. Reviewed-by: Benno Lossin <benno.lossin@proton.me> Link: https://lore.kernel.org/r/20250413173758.12068-8-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-17rust: device: implement Bound device contextDanilo Krummrich1-1/+15
The Bound device context indicates that a device is bound to a driver. It must be used for APIs that require the device to be bound, such as Devres or dma::CoherentAllocation. Implement Bound and add the corresponding Deref hierarchy, as well as the corresponding ARef conversion for this device context. Reviewed-by: Benno Lossin <benno.lossin@proton.me> Link: https://lore.kernel.org/r/20250413173758.12068-7-dakr@kernel.org [ Add missing `::` prefix in macros. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-17rust: pci: preserve device context in AsRefDanilo Krummrich1-3/+5
Since device::Device has a generic over its context, preserve this device context in AsRef. For instance, when calling pci::Device<Core> the new AsRef implementation returns device::Device<Core>. Reviewed-by: Benno Lossin <benno.lossin@proton.me> Link: https://lore.kernel.org/r/20250413173758.12068-6-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-17rust: platform: preserve device context in AsRefDanilo Krummrich1-3/+3
Since device::Device has a generic over its context, preserve this device context in AsRef. For instance, when calling platform::Device<Core> the new AsRef implementation returns device::Device<Core>. Reviewed-by: Benno Lossin <benno.lossin@proton.me> Link: https://lore.kernel.org/r/20250413173758.12068-5-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-17rust: device: implement device context for DeviceDanilo Krummrich1-2/+9
Analogous to bus specific device, implement the DeviceContext generic for generic devices. This is used for APIs that work with generic devices (such as Devres) to evaluate the device's context. Reviewed-by: Benno Lossin <benno.lossin@proton.me> Link: https://lore.kernel.org/r/20250413173758.12068-4-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-17rust: device: implement impl_device_context_into_aref!Danilo Krummrich3-13/+24
Implement a macro to implement all From conversions of a certain device to ARef<Device>. This avoids unnecessary boiler plate code for every device implementation. Reviewed-by: Benno Lossin <benno.lossin@proton.me> Link: https://lore.kernel.org/r/20250413173758.12068-3-dakr@kernel.org [ Add missing `::` prefix in macros. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-17rust: device: implement impl_device_context_deref!Danilo Krummrich3-27/+50
The Deref hierarchy for device context generics is the same for every (bus specific) device. Implement those with a generic macro to avoid duplicated boiler plate code and ensure the correct Deref hierarchy for every device implementation. Co-developed-by: Benno Lossin <benno.lossin@proton.me> Signed-off-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Christian Schrefl <chrisi.schrefl@gmail.com> Link: https://lore.kernel.org/r/20250413173758.12068-2-dakr@kernel.org [ Add missing `::` prefix in macros. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-07gpu: nova-core: remove completed Vec extentions from task listAndrew Ballance1-10/+0
The requested Vec methods have been implemented thus, remove the completed item from the nova task list. Link: https://lore.kernel.org/r/20250316111644.154602-4-andrewjballance@gmail.com Signed-off-by: Andrew Ballance <andrewjballance@gmail.com> Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-06Linux 6.15-rc1Linus Torvalds1-2/+2
2025-04-06tools/include: make uapi/linux/types.h usable from assemblyThomas Weißschuh1-0/+3
The "real" linux/types.h UAPI header gracefully degrades to a NOOP when included from assembly code. Mirror this behaviour in the tools/ variant. Test for __ASSEMBLER__ over __ASSEMBLY__ as the former is provided by the toolchain automatically. Reported-by: Mark Brown <broonie@kernel.org> Closes: https://lore.kernel.org/lkml/af553c62-ca2f-4956-932c-dd6e3a126f58@sirena.org.uk/ Fixes: c9fbaa879508 ("selftests: vDSO: parse_vdso: Use UAPI headers instead of libc headers") Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Link: https://patch.msgid.link/20250321-uapi-consistency-v1-1-439070118dc0@linutronix.de Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2025-04-06tools/power turbostat: v2025.05.06Len Brown1-1/+1
Support up to 8192 processors Add cpuidle governor debug telemetry, disabled by default Update default output to exclude cpuidle invocation counts Bug fixes Signed-off-by: Len Brown <len.brown@intel.com>
2025-04-06tools/power turbostat: disable "cpuidle" invocation counters, by defaultLen Brown2-13/+33
Create "pct_idle" counter group, the sofware notion of residency so it can now be singled out, independent of other counter groups. Create "cpuidle" group, the cpuidle invocation counts. Disable "cpuidle", by default. Create "swidle" = "cpuidle" + "pct_idle". Undocument "sysfs", the old name for "swidle", but keep it working for backwards compatibilty. Create "hwidle", all the HW idle counters Modify "idle", enabled by default "idle" = "hwidle" + "pct_idle" (and now excludes "cpuidle") Signed-off-by: Len Brown <len.brown@intel.com>
2025-04-06Disable SLUB_TINY for build testingLinus Torvalds2-2/+2
... and don't error out so hard on missing module descriptions. Before commit 6c6c1fc09de3 ("modpost: require a MODULE_DESCRIPTION()") we used to warn about missing module descriptions, but only when building with extra warnigns (ie 'W=1'). After that commit the warning became an unconditional hard error. And it turns out not all modules have been converted despite the claims to the contrary. As reported by Damian Tometzki, the slub KUnit test didn't have a module description, and apparently nobody ever really noticed. The reason nobody noticed seems to be that the slub KUnit tests get disabled by SLUB_TINY, which also ends up disabling a lot of other code, both in tests and in slub itself. And so anybody doing full build tests didn't actually see this failre. So let's disable SLUB_TINY for build-only tests, since it clearly ends up limiting build coverage. Also turn the missing module descriptions error back into a warning, but let's keep it around for non-'W=1' builds. Reported-by: Damian Tometzki <damian@riscv-rocks.de> Link: https://lore.kernel.org/all/01070196099fd059-e8463438-7b1b-4ec8-816d-173874be9966-000000@eu-central-1.amazonses.com/ Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Fixes: 6c6c1fc09de3 ("modpost: require a MODULE_DESCRIPTION()") Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2025-04-06tools/power turbostat: re-factor sysfs codeLen Brown1-10/+21
Probe cpuidle "sysfs" residency and counts separately, since soon we will make one disabled on, and the other disabled off. Clarify that some BIC (build-in-counters) are actually "groups". since we're about to re-name some of those groups. no functional change. Signed-off-by: Len Brown <len.brown@intel.com>
2025-04-06tools/power turbostat: Restore GFX sysfs fflush() callZhang Rui1-0/+1
Do fflush() to discard the buffered data, before each read of the graphics sysfs knobs. Fixes: ba99a4fc8c24 ("tools/power turbostat: Remove unnecessary fflush() call") Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2025-04-06tools/power turbostat: Document GNR UncMHz domain conventionLen Brown1-0/+1
Document that on Intel Granite Rapids Systems, Uncore domains 0-2 are CPU domains, and uncore domains 3-4 are IO domains. Signed-off-by: Len Brown <len.brown@intel.com>
2025-04-06tools/power turbostat: report CoreThr per measurement intervalLen Brown2-1/+3
The CoreThr column displays total thermal throttling events since boot time. Change it to report events during the measurement interval. This is more useful for showing a user the current conditions. Total events since boot time are still available to the user via /sys/devices/system/cpu/cpu*/thermal_throttle/* Document CoreThr on turbostat.8 Fixes: eae97e053fe30 ("turbostat: Support thermal throttle count print") Reported-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com> Cc: Chen Yu <yu.c.chen@intel.com>