-----BEGIN PGP SIGNATURE-----
iQJEBAABCAAuFiEEwPw5LcreJtl1+l5K99NY+ylx4KYFAmpRcgYQHGF4Ym9lQGtl
cm5lbC5kawAKCRD301j7KXHgplILD/4pSlngdLhIRuGnzHEXz507ySn8XSim6NEs
gNf89HClYgIwSbMjHOuzPLpp/6FHxKMnyEzxsrJ6Rj3PXSc0sSWbKHMGD5UUwg4X
gYUIwH5WfvzHxU9zJ6tGLgkepTow+vPhoTnJJqtK5qLO2C56I7dSV38fP5S2ucMU
flVzYFRMtO8svWekol9bA278/p3GxR0qXKLCKq/tadTLcLo9AyAz+gEGHAYCNTVE
9Kix7uiAVMg8CtwK5lJDFd6pLSZaYFCkzAI2/H/mxB25ydZRKcfLADmj/uDOboJH
8Q2FezpQSdM6bEWqsjSwA3qhfNaUzyVuCEoFZl2V4vuD/RvEe+y5hSGM9AGW0hwQ
57UwLKgohupTNb6149Mhq5AvmIcD2/FEmxMCyHB0DdSWFp1uHR/8jrHyh/ZQXBHl
VgCeErIIaG5Yruta80WsZp7lagBduU0zndG4a3OONOj76vLA5iilzxEo4K7yFVdu
22Uiw2oIJPzwm9OOmVvpaIozBDNqG8Ims9e2U/me6ODFP4kdcHjqyS6FOnDoRxz2
PiPxW0FHJt4ywjFuHTE05+8N3/eiJivANjaeAnj1mqIIH4UwxzCiCl/raVf4VCtH
HWoGFQQ5R2gg4Q1BGllmOvyG9ZPhV/TJgoRnatyVqGVHXJOBKc+5PQREy3HXZ54J
Z6xq2lobKQ==
=LIqA
-----END PGP SIGNATURE-----
Merge tag 'block-7.2-20260710' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux
Pull block fixes from Jens Axboe:
- Limit blk_hctx_poll() to one jiffy. Prevents buggy drivers from
spinning for too long, hence triggering a stalled RCU read section
warning
- Avoid a potential deadlock on zone revalidation failure, which could
otherwise trigger a lockdep circular locking splat during a SCSI disk
rescan
- Remove a redundant GD_NEED_PART_SCAN set in add_disk_final()
- Make writes to queue/wbt_lat_usec honor the WBT enable state
- ublk fix to snapshot the batch commands before preparing IO, so that
userspace can't change an already processed tag and trip the
WARN_ON_ONCE() in the rollback path
- xen-blkfront fix for a double completion of split requests on resume
- drbd fix to reject data replies with an out-of-range payload size
* tag 'block-7.2-20260710' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
block: remove redundant GD_NEED_PART_SCAN in add_disk_final()
drbd: reject data replies with an out-of-range payload size
xen-blkfront: fix double completion of split requests on resume
ublk: snapshot batch commands before preparing I/O
block: Make WBT latency writes honor enable state
block: avoid potential deadlock on zone revalidation failure
blk-mq: bound blk_hctx_poll() to one jiffy
qcom_ebi2_probe() enables the EBI2 clocks manually and populates child
devices manually. Several later failure paths can then return without
disabling the clocks or without relying on the driver core to undo child
population.
Use devm_clk_get_enabled() for both clocks and
devm_of_platform_populate() for children. This lets the driver core
unwind the resources automatically and removes the hand-written error
labels.
Fixes: 335a127548 ("bus: qcom: add EBI2 driver")
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Link: https://lore.kernel.org/r/20260623015415.26975-1-pengpeng@iscas.ac.cn
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
rpmh_rsc_probe() registers CPU PM or genpd notifiers before populating
child devices. If child population fails, the CPU PM notifier path is not
unwound and the genpd path needs open-coded cleanup.
Use devm_pm_runtime_enable() for the genpd path and
devm_add_action_or_reset() for both notifier registrations. This makes
probe failure and driver detach use the same cleanup model while keeping
devm_of_platform_populate() responsible for child devices.
Fixes: 25092e6100 ("soc: qcom: rpmh-rsc: Attach RSC to cluster PM domain")
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260623015501.31129-1-pengpeng@iscas.ac.cn
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Wire the five tracepoints defined in qcom_scm_trace.h into the SMC
execution path by including the header with CREATE_TRACE_POINTS.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Yuvaraj Ranganathan <yuvaraj.ranganathan@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260522-scm-tracepoints-v2-2-e27cdbe0c585@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The SCM SMC call path is opaque at runtime. Stalls caused by firmware
congestion, QCOM_SCM_WAITQ_SLEEP/RESUME cycles, and EBUSY retry loops
are invisible without recompiling the kernel with temporary printk
statements or attaching a hardware debugger.
Add five TRACE_EVENTs covering the complete lifecycle of an SCM call:
scm_smc_request
Emit before each arm_smccc_smc_quirk() invocation. Records the
SMC function ID, decoded service and command identifiers, argument
count, and up to six register arguments in hex and decimal. Because
the caller loops on QCOM_SCM_INTERRUPTED, this event fires once per
physical SMC instruction including inte
scm_smc_done
Emit after the outer __scm_smc_do() returns, pairing each
request with its final outcome. Records the SMC function ID, the
kernel error code returned to the caller, and the four firmware
result registers a0-a3.
scm_waitq_sleep
Emit when the firmware returns QCOM_SCM_WAITQ_SLEEP. Records
the wait-queue context and the SMC call context handles required
to issue the matching WAITQ_RESUME.
scm_waitq_resume
Emit just before constructing and sending the WAITQ_RESUME
follow-up call. Records the SMC call context handle being resumed.
scm_waitq_get_wq_ctx
Emit after a successful WAITQ_GET_WQ_CTX fast-call. Records
the returned wait-queue context, flags, and more_pending indicator.
These events let ftrace and perf reconstruct the full sequence of
firmware interactions, measure per-call and end-to-end latency, and
attribute waitqueue stalls to specific service/command pairs without
modifying driver source.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Yuvaraj Ranganathan <yuvaraj.ranganathan@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260522-scm-tracepoints-v2-1-e27cdbe0c585@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQJEBAABCAAuFiEEwPw5LcreJtl1+l5K99NY+ylx4KYFAmpRch8QHGF4Ym9lQGtl
cm5lbC5kawAKCRD301j7KXHgpqORD/9xYHpNwkeIXfG+6giRGCF03u0eGlreUsIl
uCGdqfNKjKZqWOw6q7uzNHll7/2SmwOniB32mdo6jpUgXeE3/RJ4U37kZ8ypIyO8
1iOSM5zz5ZNQQuHa/HZMqMRy9mqBa5WIJqRO4CpRk9uaqq6flU2CEq4/y3SdOc0S
9u+UxzVhmoYuL7iQhaLg6xQSrNxtwynVXqIru/bN1Ft01sCo3Yf3w0SmNnmsrr34
jG1tkn0J7QtwkaN81poX8WTqm0D7McFc5xcq8wWM+BDnpvllPxQ+J+J3+zMfvAbN
tbb3FiXkc5SeYTOrBu8FWwPMn8reNpUBgEGjrcZWyRIkHdzxrDhwvC9tyQs85l4w
j93PSsJnlprVPI4LWGfglCaNBZ85hFFKpm83rAFJgJjLuyzRFSF7+/EKrHFP58sK
v8oYq/iXpQunu1YLfBIAjW4OnVkqSYM95Xax4l5yFSgeCS+hNd/naRgvqzrM4puq
tspIH9zjZCyRftRuVebW4V/cxfceSp3kg5cPyW/PRonO9iGZ1Q2scK0bovNO0QKC
gDjax1qancwp/GlT65jgdLp9lAx1TIofPz2gP22lGlZe732bi3gvX5rGPo1bT98v
1NJXrEIqLHOuId308+pzpvl4j4YyJAC3llThVg4L2TZb6jy+S5qYnbBnRkQoNPVi
iMP+XrWPjw==
=vHWI
-----END PGP SIGNATURE-----
Merge tag 'io_uring-7.2-20260710' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux
Pull io_uring fixes from Jens Axboe:
- Restore full RCU read section in io_req_local_work_add(), which was
mistakenly dropped with the DEFER_TASKRUN rework in this merge
window. Revert the commit that grabbed the RCU read lock in
io_ctx_mark_taskrun(), as that's no longer required with the previous
fix.
- Fix a dangling iovec after a provided-buffer bundle grow failure,
also an issue introduced in this merge window.
- Reject IORING_CQE_F_32 flag pass-through in MSG_RING to rings that
weren't setup with CQE32 or CQE_MIXED.
- Return -EINVAL rather than -ENOMEM from get_unmapped_area() when mmap
validation fails, matching io_uring_mmap().
* tag 'io_uring-7.2-20260710' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
Revert "io_uring: grab RCU read lock marking task run"
io_uring: restore RCU read section in io_req_local_work_add()
io_uring: fix dangling iovec after provided-buffer bundle grow failure
io_uring/uring_cmd: fix uring_cmd.c comments
io_uring/msg_ring: reject CQE32 flag pass-through to normal rings
io_uring/memmap: return -EINVAL from get_unmapped_area() on bad mmap
Add an enum as sum type for `Mmio` and `SysMem`. This serves similar
purpose of `iosys_map`. Thanks to Rust's type system, all of projection and
struct read/write can be handled by the generic I/O projection mechanism
(i.e. `io_project!`, `io_read!, `io_write!`) for free, and there is no need
to provide things like `iosys_map_rd_field` or `iosys_map_wr_field`. An
enum type also makes it very easy to construct or destruct.
This could be made more generic by implementing on a general purpose sum
type like `Either`; however this is kept specific unless a need arises that
warrants this to be generic over other I/O backends.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260706-io_projection-v6-20-72cd5d055d54@garyguo.net
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
One feature that was lost from the old `dma_read!` and `dma_write!` when
moving to `io_read!` and `io_write!` was the ability to read/write a large
structs. However, the semantics was unclear to begin with, as there was no
guarantee about their atomicity even for structs that were small enough to
fit in u32. Re-introduce the capability in the form of copying methods.
dma_read!(foo, bar) -> io_project!(foo, bar).copy_read()
dma_write!(foo, bar, baz) -> io_project!(foo, bar).copy_write(baz)
Model these semantics after memcpy so user has clear expectation of lack of
atomicity. As an additional benefit of this change, this now works for MMIO
as well by mapping them to `memcpy_{from,to}io`.
For slices which is DST so the `copy_read` and `copy_write` API above can't
work, add `copy_from_slice` and `copy_to_slice` to copy from/to normal
memory.
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260706-io_projection-v6-19-72cd5d055d54@garyguo.net
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
The primitive read/write use case is covered by the `io_read!` and
`io_write!` macro. The non-primitive use case was finicky; they should
either be achieved using `CoherentBox` or `as_ref()/as_mut()` to assert the
lack of concurrent access, or should be using memcpy-like APIs to express
the non-atomic and tearable nature.
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Link: https://patch.msgid.link/20260706-io_projection-v6-18-72cd5d055d54@garyguo.net
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Use `io_project!` for PTE array and message queues to restore the proper
encapsulation.
The remaining `dma_read!` and `dma_write!` is now only acting on
primitives; thus replace by `io_read!` and `io_write!`.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260706-io_projection-v6-17-72cd5d055d54@garyguo.net
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Provide `read_val` and `write_val` that allow I/O views to be accessed when
they're narrowed down to just views of primitives.
This is used to provide `io_read!` and `io_write!` macros, which are
generalized version of current `dma_read!` and `dma_write!` macro that work
for all types that implement `Io`.
Note though `io_read!` and `io_write!` only works if backend implements
`IoCapable` for the type; which is typically only implemented for
atomically accessible primitives. `dma_read!` and `dma_write!` currently
supports them via `read_volatile` and `write_volatile`; this can be
undesirable for aggregates as LLVM may turn them to multiple instructions
to access parts and re-assemble, even if they could be combined to a single
instruction. Thus, `io_read!()` and `io_write!()` does not fully replace
`dma_read!()` and `dma_write!()` in this scenario. The ability to
read/write aggregates (when atomicity is of no concern) is better served
with copying primitives (e.g. memcpy_{from,to}io).
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Link: https://patch.msgid.link/20260706-io_projection-v6-16-72cd5d055d54@garyguo.net
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Implement a `CoherentView` type which is a view of `Coherent`. To be able
to give out DMA handles, the view type contains both CPU and DMA pointers,
and the projection method projects both at once.
Delegate most of the `Io` implementation to `SysMemBackend`. Provide a
method to erase the DMA handle and give out a `SysMem` view, if the user
does not need the `dma_handle`.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Link: https://patch.msgid.link/20260706-io_projection-v6-15-72cd5d055d54@garyguo.net
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Add `SysMem`, an `Io` trait implementation for kernel virtual address
ranges. It uses volatile accessors to provide safe access to shared
memory that may be concurrently accessed by external hardware. Implement
`IoCapable` for `u8`, `u16`, `u32`, and `u64` (for 64-bit system).
This can be used instead of `Coherent` for cases where a different layer
takes care of mapping the system memory to the device (e.g. dma-buf or
GPUVM).
Signed-off-by: Laura Nao <laura.nao@collabora.com>
[ Rebased and adapted on top of I/O rework. - Gary ]
Co-developed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Link: https://patch.msgid.link/20260706-io_projection-v6-14-72cd5d055d54@garyguo.net
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Add an `io_project!()` macro to allow projection from `Io` to a subview of
it, using the pointer projection mechanism to perform compile-time checks.
For cases where type-casting is required, the `try_cast()` function may be
used where the size and alignment checks are performed at runtime.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Link: https://patch.msgid.link/20260706-io_projection-v6-13-72cd5d055d54@garyguo.net
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
`Io` trait now has a single required method with many more provided
methods. Provided methods may want to rely on their implementations to not
be arbitrarily overridden by implementers for correctness or soundness.
A good example is the `size` method, it may be relied by unsafe code and
thus must be consistent with the metadata obtained from `as_ptr`.
Thus, create a new trait to host `size` method, extract existing provided
methods to the new trait, and provide a blanket implementation. This
pattern is used extensively in userspace Rust libraries e.g. `tokio` where
`AsyncRead` has minimum methods and `AsyncReadExt` is what users mostly
interact with.
To avoid changing all user imports, the base trait is renamed to `IoBase`
and the newly added trait takes the existing `Io` name.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Suggested-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Link: https://patch.msgid.link/20260706-io_projection-v6-12-72cd5d055d54@garyguo.net
[ Add comment explaining the purpose of the Io blanket implementation.
- Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Currently, `io_read` and `io_write` methods require the exact type of `Io`
plus an address. This means that they need to be monomorphized for each
different `Io` instance. This also means that multiple I/O implementors for
the same I/O kind needs to duplicate implementation (e.g. `Mmio` and
`MmioOwned`).
Create a new `IoBackend` trait and define these operations on it instead.
The operations are just going to receive a view type and operate on them.
This has the additional advantage that the invariants can be moved from the
trait (and guaranteed via `unsafe`) to type invariants on the canonical
view types of the backends, so `io_read` and `io_write` can be safe.
Note that a view type is needed; addresses are insufficient in this
design, as they do not carry sufficient information. For example,
`ConfigSpace` needs `&pci::Device` in addition to the address.
`io_addr_assert` and `io_addr` are renamed to `io_view*` to reflect
that they operate on views now, and make them standalone functions so
they cannot be used by users to cast types outside io.rs.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Link: https://patch.msgid.link/20260706-io_projection-v6-9-72cd5d055d54@garyguo.net
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
In order to support I/O projection, we are splitting I/O types into two
categories: owned objects and views. Owned objects have a specific type
that is related to setting up and tearing down, while views can have their
type changed with I/O projection.
Things like `IoMem` or `Bar` are owned objects, which requires setting up
mapping and cleaning up on drop. On the other side, `ConfigSpace` is really
just a view, as the resource is associated with the `pci::Device`.
Remove the `ConfigSpaceKind` bound on `ConfigSpace` and make it a generic
view. This means that `ConfigSpace` object now represents a subregion and
therefore encodes offset (as address of pointers) and size (as metadata of
pointers) itself. The full region case is still supported with offset 0 and
size of `cfg_size`.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Link: https://patch.msgid.link/20260706-io_projection-v6-8-72cd5d055d54@garyguo.net
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Implement `Mmio` as view type and convert `RelaxedMmio` to view type as
well. I/O implementations of `MmioOwned` are changed to delegate to the
`Mmio` view type.
All existing users of `MmioOwned` in the documentation which do not
actually reflect the owning semantics is converted.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Gary Guo <gary@garyguo.net>
Tested-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Link: https://patch.msgid.link/20260706-io_projection-v6-7-72cd5d055d54@garyguo.net
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Conceptually, `MmioRaw` is just `__iomem *`, so it should work for any
types. Update the existing use case where it represents a region of
compile-time known minimum size and run-time known actual size to use the
dynamic-sized type `Region<SIZE>` instead. Rename `maxsize` method to
reflect that it is the actual size (not a bound) of the region.
Implement `Clone` and `Copy` manually, which cannot be derived due to the
generic parameter. The use of raw pointers also cause the `Send` and `Sync`
auto trait implementation to be lost, so add them back by manual
implementation.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Suggested-by: Danilo Krummrich <dakr@kernel.org>
Link: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/Generic.20I.2FO.20backends/near/571198078
Link: https://patch.msgid.link/20260706-io_projection-v6-5-72cd5d055d54@garyguo.net
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Currently, `Io` is implemented on owned I/O objects (e.g. `Bar`). This is
going to change with I/O projections, as then `Io` needs to work both for
owned objects and views of them. Views are themselves reference-like
(however they obviously cannot be references, because they belong to a
different address space).
To facilitate the change, change `Io` to be implemented on reference types
for the owned I/O objects, and make methods take `self` instead of `&self`.
When I/O views are implemented, we can then naturally implement `Io` for
these objects.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Link: https://patch.msgid.link/20260706-io_projection-v6-4-72cd5d055d54@garyguo.net
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Currently the `Io` trait exposes a bunch of untyped IO accesses, but if the
`Io` region itself is typed, then it might be weird to have
let io: Mmio<u32> = /* ... */;
io.read8(1);
while not unsound, it is surely strange. Thus, restrict the untyped methods
and also the register macro to `Region` type only.
Implement it by adding a generic type to `IoLoc` indicating allowed base
types. This also paves the way to add typed register blocks in the future;
for example, we could use this mechanism to block driver A's `register!()`
generated macro from being used on driver B's MMIO. The same mechanism
could be used for relative IO registers. These are future opportunities,
and for now restrict everything to require `IoLoc<Region<SIZE>, _>`.
Suggested-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://lore.kernel.org/rust-for-linux/DHLB3RO3OSF5.2R7F27U99BKLN@nvidia.com/
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Link: https://patch.msgid.link/20260706-io_projection-v6-3-72cd5d055d54@garyguo.net
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
The current safety comment on `io_read`/`io_write` does not cover the topic
about alignment. Add it so it can be relied on by implementor of
`IoCapable`.
Expand the check performed by `Io` by taking `self.addr()` into
consideration when checking if `offset` is aligned. For the compile-time
`io_addr_assert` check, check using the known minimum alignment of
`Io::Target` and the accessed type.
While at it, fix the alignment check to use `align_of` instead of
`size_of`. The values match for all primitives (including u64, given that
we do not provide u64 accessor on 32-bit platforms), but are not
necessarily true for custom types.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Link: https://patch.msgid.link/20260706-io_projection-v6-2-72cd5d055d54@garyguo.net
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Currently many I/O related structs carry a `SIZE` parameter to denote the
minimum size of the I/O region, while they also carry a field indicating
the actual size. Proliferation of the pattern creates a lot of duplicated
code, and makes it hard to create typed views of I/O.
Introduce a `Region` type that carries the `SIZE` parameter. It is a
wrapper of `[u8]`, which makes it dynamically sized with a metadata of
`usize`. This way, pointers to `Region` naturally carry size information.
This type is required to be 4-byte aligned.
Expose the minimum size information via `MIN_SIZE` constant of the
`KnownSize` trait. Similarly, expose the minimum alignment information via
`KnownSize::MIN_ALIGN`.
With these changes, it is possible to add an associated type to `Io` trait
to represent the type of I/O region. For untyped regions, this is the newly
added `Region` type. Remove `IoKnownSize` as it is no longer necessary. Use
the same mechanism to indicate minimum size of PCI config spaces.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Link: https://patch.msgid.link/20260706-io_projection-v6-1-72cd5d055d54@garyguo.net
[ Add brief explanation on MIN_ALIGN. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Replace permanently bouncing email addresses (550 5.1.1 Recipient address
rejected) of Adam Skladowski, Chanho Park, Anusha Rao and Sireesh
Kodali. There are no new messages from them via other email addresses,
so drop them permanently. Add Alim Akhtar to Samsung ExynosAutov9 SoC
clocks, because he looks at other Samsung clock hardware and drivers.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260623073050.36262-2-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Add support for the camera clock controller for camera clients
to be able to request for camcc clocks on Glymur platform.
Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260624-glymur_camcc-v5-2-a321df74b1a1@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Add device tree bindings for the camera clock controller on
Qualcomm Glymur SoC.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260624-glymur_camcc-v5-1-a321df74b1a1@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
QCOM_SCM and QCOM_SPM are user-selectable drivers, thus
ARM_QCOM_SPM_CPUIDLE should rather avoid selecting them but instead
depend to avoid any possible unmet dependencies.
ARM_QCOM_SPM_CPUIDLE does use symbols from SCM and SPM, and since it
cannot be built-in, the dependency must be as built-in.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260711-qcom-soc-kconfig-v2-4-4a907e064281@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The drivers for Qualcomm SoC components are covering a basic or
fundamental SoC blocks. Usually they are required for booting or to
achieve basic expected functionality when running Linux. These drivers
do not represent any sort of buses visible to the board
designers/configurators, thus they should be always enabled, regardless
how SoC is used in the final board.
Kernel configuration should not ask users choice of drivers when that
choice is obvious and known to the developers that answer should be
'yes' or 'module'.
Switch most of the Qualcomm SoC drivers to a default 'yes' or
'module' for ARCH_QCOM, to match existing defconfig usage.
This has no impact on arm64 defconfig, arm qcom_defconfig and arm
multi_v7_defconfig.
multi:
+#define CONFIG_QCOM_PDR_HELPERS_MODULE 1
+#define CONFIG_QCOM_PBS_MODULE 1
+#define CONFIG_QCOM_AOSS_QMP 1
+#define CONFIG_QCOM_APR_MODULE 1
+#define CONFIG_QCOM_LLCC_MODULE 1
qcom:
+#define CONFIG_QCOM_PDR_HELPERS_MODULE 1
+#define CONFIG_QCOM_PBS_MODULE 1
+#define CONFIG_QCOM_AOSS_QMP 1
+#define CONFIG_QCOM_APR_MODULE 1
+#define CONFIG_QCOM_SPM 1
+#define CONFIG_QCOM_LLCC_MODULE 1
The change will however enable by default all drivers for arm or arm64
COMPILE_TEST builds, whenever ARCH_QCOM is selected, which feels
logical: if one selects ARCH_QCOM then probably by default wants to
build test it entirely. Kernels with COMPILE_TEST are not supposed to
be used for booting.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260711-qcom-soc-kconfig-v2-3-4a907e064281@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
There is no point to allow selecting core SoC drivers for Qualcomm ARMv7
SoCs when building ARM64 kernel, and vice versa.
This makes kernel configuration more difficult as many do not remember
the Qualcomm SoCs model names/numbers and their properties like
architecture. No features should be lost because:
1. There won't be a single image for ARMv7 and ARMv8/9 SoCs.
2. Newer ARMv8/9 SoCs won't be running in arm32 emulation mode.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260711-qcom-soc-kconfig-v2-2-4a907e064281@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Switch from a simple menu to menuconfig, so all Qualcomm SoC drivers
will be under one selectable option, allowing to disable them all which
should make kernel configuration easier when preparing a non-Qualcomm
kernel.
This has few benefits (functional impact of this commit):
1. Allow compile testing of QCOM_OCMEM, which previously required
ARCH_QCOM.
2. Hide behind ARCH_QCOM or COMPILE_TEST drivers specific to Qualcomm
which should not be available to other kernel builds:
QCOM_PMIC_PDCHARGER_ULOG, QCOM_PMIC_GLINK, QCOM_SPM and QCOM_PBS.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260711-qcom-soc-kconfig-v2-1-4a907e064281@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
As we plan to add more KLVs to the migration descriptor packet,
to simplify such extensions and avoid coding errors, start using
our KLV helpers for packet preparing and parsing.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
Link: https://patch.msgid.link/20260707220816.677-14-michal.wajdeczko@intel.com
One of our migration data packet (descriptor) is based on the KLV
encoding. Add a simple descriptor initialization test, as we plan
to use new KLV helper functions there.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
Link: https://patch.msgid.link/20260708180921.2715-1-michal.wajdeczko@intel.com
For completeness, add a simple test to exercise the KLV printer
to make sure it doesn't crash at least.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
Link: https://patch.msgid.link/20260711073608.7829-1-michal.wajdeczko@intel.com
We will soon be encoding complex objects as KLVs using our helper
function. Add few simple tests to make sure this helper function
works as expected.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
Link: https://patch.msgid.link/20260710195945.7316-1-michal.wajdeczko@intel.com
Before we start using string to KLV encoding helper, add a simple
test to make sure it works as expected.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> #v1
Link: https://patch.msgid.link/20260708180755.2684-1-michal.wajdeczko@intel.com
We will be making more extensive use of GuC KLV helpers. Add simple
tests to ensure the helpers are working as expected.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
Link: https://patch.msgid.link/20260707220816.677-9-michal.wajdeczko@intel.com
We have already started using few KLV keys from the 0xF000 range
that, as we have agreed with the GuC team, will not be used in any
GuC ABI actions. Add definitions for that reserved range and move
our migration KLVs to new ABI header.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
Link: https://patch.msgid.link/20260710172534.7201-1-michal.wajdeczko@intel.com
We have already introduced a helper to encode larger objects. Now
add helper to parse the KLVs buffer. We will use it shortly.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
Link: https://patch.msgid.link/20260707220816.677-7-michal.wajdeczko@intel.com
We also plan to encode a text data as KLV. Add helper for that too.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
Link: https://patch.msgid.link/20260707220816.677-5-michal.wajdeczko@intel.com
Some future KLVs will be encoded as a group of nested KLVs. Prepare
our KLV printer function to handle such KLVs. List of known group
keys will be updated later, for now just prepare it for testing.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
Link: https://patch.msgid.link/20260707220816.677-3-michal.wajdeczko@intel.com
We can decode and print all KLVs from the buffer, but it might be
helpful also to allow printing just single already decoded KLV.
Extract existing code into new function and make it public.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
Link: https://patch.msgid.link/20260707220816.677-2-michal.wajdeczko@intel.com
__reserve_metadata_snap() increments THIN_SUPERBLOCK_LOCATION in the
metadata space map before shadowing it. When dm_tm_shadow_block()
fails, a reference is leaked in the metadata space map.
Fix by adding the missing dm_sm_dec_block().
Signed-off-by: Genjian Zhang <zhanggenjian@kylinos.cn>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Fixes: cc8394d86f ("dm thin: provide userspace access to pool metadata")
Cc: stable@vger.kernel.org
Starting with Rust 1.99.0 (expected 2026-10-01), under
`CONFIG_RUST_DEBUG_ASSERTIONS=y`, `objtool` may report:
rust/kernel.o: warning: objtool: _R..._6kernel12module_param9set_paramaEB4_()
falls through to next function _R..._6kernel12module_param9set_paramhEB4_()
(and many others) due to calls to the `noreturn` symbol [1]:
core::panicking::panic_null_reference_constructed
Thus add the mangled one to the list so that `objtool` knows it is
actually `noreturn`.
See commit 56d680dd23 ("objtool/rust: list `noreturn` Rust functions")
for more details.
Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs).
Cc: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Petr Pavlu <petr.pavlu@suse.com>
Link: https://github.com/rust-lang/rust/pull/158796 [1]
Reported-by: Alice Ryhl <aliceryhl@google.com>
Closes: https://lore.kernel.org/rust-for-linux/alEBInX9gD1M5NAr@google.com/
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Tested-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260710173252.191781-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
