summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2026-07-31s390/sclp: Allow SCLP Action Qualifiers for Spyre card status reportingNiklas Schnelle1-0/+3
Add SCLP Action Qualifiers used by the Spyre stack for reporting of the card's initialization status, recoverable errors, and telemetry data. Co-developed-by: Andreas Krebbel <krebbel@linux.ibm.com> Signed-off-by: Andreas Krebbel <krebbel@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-07-31s390/ap: Fix queue depth field lengthFinn Callies1-1/+1
The queue depth field is defined as a 5 bit field in the Z architecture instead of a 4 bit field. The queue depth (qd) can be in range 0-31 and is reported in bits 59-63 of the TAPQ response. Currently this has no effect as all CEX generations report a queue depth of 7, which fits into 4 bits. However, future CEX generations reporting a value >15 would not be properly reflected by the ap bus and therefore all user space applications relying on it. Reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Finn Callies <fcallies@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-07-31s390/zcrypt: Fix missing mem scrub at clear key import in cca_clr2cipherkey()Harald Freudenberger1-6/+13
The helper function _ip_cprb_helper() uses internal buffer memory for building and processing CPRBs. After use this buffer was never scrubbed which could lead to leaving for example clear key material in memory which could be exposed via tricky reuse of this same memory. Extend the _ip_cprb_helper() function with another parameter 'scrub' used to steer scrubbing of this buffer. So now the caller has the opportunity to decide if scrubbing is needed or not. Extend the clear key to secure key token import process in function cca_clr2cipherkey() to tell the helper function from above to scrub the cprb buffer when the clear key value is part of the request data. Add explicit scrubbing on return from function cca_clr2cipherkey() for the random EXOR buffer and the cprb buffer. Overall this cleans the internal used buffer in case of clear key import to prevent sensitive data to get exposed. Fixes: 4bc123b18ce6 ("s390/zcrypt: Add low level functions for CCA AES cipher keys") Cc: stable@vger.kernel.org Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-07-31s390/zcrypt: Close speculative mem read possibilityHarald Freudenberger1-0/+2
The domain value is extracted from a given CCA or EP11 ioctl struct when a CPRB is about to be sent. Thus this is a user controlled value. Under some special conditions (custom device node used, administrative load) this value is used as an array index after bounds checking, but without speculation barrier. Add the missing array_index_nospec() call to prevent speculative execution where this domain value is used. Fixes: cfd68b33094e ("s390/zcrypt: Filter admin CPRBs on custom devices") Cc: stable@vger.kernel.org Reported-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Finn Callies <fcallies@linux.ibm.com> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-07-31s390/zcrypt: Fix wrong domain value verification with EP11 CPRBsHarald Freudenberger1-1/+1
There is a wrong upper limit check for the domain value when an EP11 CPRB is processed for sending to a crypto card. This check is only active on custom device nodes but may lead to access heap memory behind perms->adm when an administrative CPRB is sent. Add correct limit (AP_DOMAINS = 256) checking to fix this. Fixes: cfd68b33094e ("s390/zcrypt: Filter admin CPRBs on custom devices") Cc: stable@vger.kernel.org Reviewed-by: Finn Callies <fcallies@linux.ibm.com> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-07-31s390/zcrypt: Fix buffer over-read in cca_cipher2protkeyHarald Freudenberger3-23/+62
Add validation of both the actual key buffer size and token length fields in all the cca_check_sec*token() functions. Additionally check in cca_gencipherkey() for possible underflow with returned key size. The CCA token structures contain user-controlled len fields that were used in operations without proper validation against both the actual buffer size and minimum token structure size. An attacker could set this field larger than the actual buffer size, leading to reading beyond buffer boundaries. This may result in a kernel crash or exposure of memory via sending this as part of a request down to the crypto card. Also an attacker could have used a very small len value and thus enforce a buffer under-run which may produce similar effects as a over-read. So now a key must - key buf length must be at least sizeof the token struct - the key len field inside the token must fit into the range of sizeof key token struct ... key buf length Fixes: 4bc123b18ce6 ("s390/zcrypt: Add low level functions for CCA AES cipher keys") Cc: stable@vger.kernel.org Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-07-31s390/zcrypt: Validate length for CCA ECC private key requestsHolger Dengler1-0/+3
cca_ecc2protkey() derives the copy length for the CPRB parameter block directly from the length field in the key token. Reject the request early if the token length exceeds the available space in the parameter block. Fixes: fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC private keys") Signed-off-by: Holger Dengler <dengler@linux.ibm.com> Cc: stable@vger.kernel.org # 5.10+ Reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-07-31s390/zcrypt: Validate length for CCA AES cipher key requestsHolger Dengler1-0/+3
cca_cipher2protkey() derives the copy length for the CPRB parameter block directly from the length field in the key token. Reject the request early if the token length exceeds the available space in the parameter block. Fixes: 4bc123b18ce6 ("s390/zcrypt: Add low level functions for CCA AES cipher keys") Signed-off-by: Holger Dengler <dengler@linux.ibm.com> Cc: stable@vger.kernel.org # 5.4+ Reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-07-31mei: pull kvfree out of spinlockAlexander Usyskin1-10/+15
The read buffer allocation was changed from kmalloc() to kvmalloc(). This buffer is part of mei_cl_cb structure that can be queued in rd_complete queue protected by spinlock. Releasing the structure leads to errors like below when freeing buffer that allocated non-contiguous: BUG: sleeping function called from invalid context at mm/vmalloc.c:3448 Separate mei_cl_cb structure dequeue and release to perform only dequeue under spinlock and push release out of spinlock. Cc: stable <stable@kernel.org> Fixes: 4adf613e01bf ("mei: use kvmalloc for read buffer") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16359 Reviewed-by: Menachem Adin <menachem.adin@intel.com> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Link: https://patch.msgid.link/20260719-kvfree_out_of_spinlock-v1-1-e07d6333bea7@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-31initramfs_test: use test init/exit hooks to override init fsChristian Brauner1-10/+15
Most initramfs kunit tests interact with initramfs via unpack_to_rootfs() and subsequently init_stat(), init_unlink(), etc. It's cleaner and less error-prone to override current->fs with userspace_init_fs for all initramfs_test_suite tests. Link: https://patch.msgid.link/20260701-work-kunit-nullfs-v1-1-dfa60270434f@kernel.org [1] Link: https://patch.msgid.link/20260729151320.21001-2-ddiss@suse.de # folded into [1] Fixes: 32750c77e811 ("fs: start all kthreads in nullfs") Reported-by: Mark Brown <broonie@kernel.org> Closes: https://lore.kernel.org/r/akOrbOsKUqgZarGw@sirena.org.uk Signed-off-by: David Disseldorp <ddiss@suse.de> Co-developed-by: David Disseldorp <ddiss@suse.de> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-31rust_binder: do not query current thread for all ioctlsAlice Ryhl1-4/+8
The get_current_thread() method is currently called for every ioctl to ensure that a Thread struct exists for the thread calling into the driver. However, not all ioctls require a Thread object, so this means we are unnecessarily creating these objects in cases where we don't need to. If said thread does not invoke BINDER_THREAD_EXIT on exit, Binder's Thread struct stays around until the fd is closed. For long-lived processes the Thread object is effectively leaked. Furthermore, when the BINDER_GET_NODE_DEBUG_INFO ioctl is invoked by libmemunreachable to ensure that objects reachable only through the Binder driver are not considered leaked, this is done from a fork of the process owning the fd, which means that it fails the group_leader check inside get_current_thread(). This results in EINVAL errors for this ioctl, causing libmemunreachable to report a false positive memory leak. Thus, do not invoke get_current_thread() for ioctls that do not require it. Signed-off-by: Alice Ryhl <aliceryhl@google.com> Cc: stable <stable@kernel.org> Fixes: eafedbc7c050 ("rust_binder: add Rust Binder driver") Acked-by: Carlos Llamas <cmllamas@google.com> Link: https://patch.msgid.link/20260727-binder-cur-thread-v1-1-8edf2b64e235@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-31nvmem: layouts: Add fixed-layout driverMathieu Dubois-Briand5-33/+63
Current implementation isn't working well when device tree nodes have a phandle on a fixed-layout nvmem node. As the fixed layout is handled in nvmem core, no driver is ever associated with the layout, and the device consumer driver probe is deferred indefinitely. Remove the specific handling of fixed-layout and add a layout driver. This makes the fixed-layout similar to all other layouts, fixing the whole issue. Fixes: fc29fd821d9a ("nvmem: core: Rework layouts to become regular devices") Cc: stable@vger.kernel.org Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Srinivas Kandagatla <srini@kernel.org> Link: https://patch.msgid.link/20260724223404.629248-3-srini@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-31nvmem: apple-spmi-nvmem: wrap regmap calls to satisfy CFIAelin Reidel1-2/+18
The Apple SPMI NVMEM driver previously cast regmap_bulk_read/write to void * when assigning them to nvmem_config's reg_read/reg_write function pointers. This cast breaks the expected function signature of nvmem_reg_read_t and nvmem_reg_write_t. With CFI enabled, indirect calls through these pointers fail: CFI failure at nvmem_reg_write+0x194/0x1e4 (target: regmap_bulk_write+0x0/0x2c8; expected type: 0x83a189c3) ... Call trace: nvmem_reg_write+0x194/0x1e4 (P) __nvmem_cell_entry_write+0x298/0x2e8 nvmem_cell_write+0x24/0x34 macsmc_reboot_probe+0x1dc/0x454 [macsmc_reboot] ... Introduce thin wrapper functions with the correct nvmem function pointer types to satisfy the CFI checks. Fixes: fe91c24a551c ("nvmem: Add apple-spmi-nvmem driver") Signed-off-by: Aelin Reidel <aelin@mainlining.org> Reported-by: Clayton Craft <craftyguy@postmarketos.org> Tested-by: Clayton Craft <craftyguy@postmarketos.org> Reviewed-by: Sven Peter <sven@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Srinivas Kandagatla <srini@kernel.org> Link: https://patch.msgid.link/20260724223404.629248-2-srini@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-31misc: fastrpc: fix memory leak in fastrpc_channel_ctx_freeEddie Lin1-0/+1
The 'ctx_idr' is initialized but never destroyed when the channel context is freed, leading to a memory leak. Add idr_destroy() to properly clean up the IDR resources. Fixes: f6f9279f2bf0 ("misc: fastrpc: Add Qualcomm fastrpc basic driver model") Cc: stable@vger.kernel.org Signed-off-by: Eddie Lin <eddie.lin@oss.qualcomm.com> Reviewed-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Srinivas Kandagatla <srini@kernel.org> Link: https://patch.msgid.link/20260724223342.629168-6-srini@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-31misc: fastrpc: fix channel ctx ref leak when session alloc failsAnandu Krishnan E1-1/+1
fastrpc_channel_ctx_get() is called in fastrpc_device_open() before fastrpc_session_alloc(). If session alloc fails, the error path returns -EBUSY without calling fastrpc_channel_ctx_put(), leaking the reference. Fix by adding the missing put. Fixes: 278d56f970ae ("misc: fastrpc: Reference count channel context") Cc: stable@kernel.org Signed-off-by: Anandu Krishnan E <anandu.e@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Srinivas Kandagatla <srini@kernel.org> Link: https://patch.msgid.link/20260724223342.629168-5-srini@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-31misc: fastrpc: take fl->lock when moving mmaps on interrupted invokeJunrui Luo1-0/+2
When an invoke is interrupted by a signal, wait_for_completion_interruptible() returns -ERESTARTSYS and fastrpc_internal_invoke() moves every buffer from fl->mmaps onto cctx->invoke_interrupted_mmaps. This list_del()/list_add_tail() walk runs without holding fl->lock, the lock that serialises fl->mmaps in fastrpc_req_mmap() and fastrpc_req_munmap() everywhere else. Take fl->lock around the move, matching every other fl->mmaps accessor. Fixes: 76e8e4ace1ed ("misc: fastrpc: Safekeep mmaps on interrupted invoke") Reported-by: Yuhao Jiang <danisjiang@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo <moonafterrain@outlook.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Srinivas Kandagatla <srini@kernel.org> Link: https://patch.msgid.link/20260724223342.629168-4-srini@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-31misc: fastrpc: Remove buffer from list prior to unmap operationEkansh Gupta1-4/+10
fastrpc_req_munmap_impl() is called to unmap any buffer. The buffer is getting removed from the list after it is unmapped from DSP. This can create potential race conditions if multiple threads invoke unmap concurrently, where one thread may remove the entry from the list while another thread's unmap operation is still ongoing. Fix this by removing the buffer entry from the list before calling the unmap operation. If the unmap fails, the entry is re-added to the list so that userspace can retry the unmap, or alternatively, the buffer will be cleaned up during device release when the DSP process is torn down and all DSP-side mappings are freed along with remaining buffers in the list. Fixes: 2419e55e532de ("misc: fastrpc: add mmap/unmap support") Cc: stable@kernel.org Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com> Signed-off-by: Srinivas Kandagatla <srini@kernel.org> Link: https://patch.msgid.link/20260724223342.629168-3-srini@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-31misc: fastrpc: Fix initial memory allocation for Audio PD memory poolEkansh Gupta1-4/+4
The initial buffer allocated for the Audio PD memory pool is never added to the pool because pageslen is set to 0. As a result, the buffer is not registered with Audio PD and is never used, causing a memory leak. Audio PD immediately falls back to allocating memory from the remote heap since the pool starts out empty. Fix this by setting pageslen to 1 so that the initially allocated buffer is correctly registered and becomes part of the Audio PD memory pool. Fixes: 0871561055e66 ("misc: fastrpc: Add support for audiopd") Cc: stable@kernel.org Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com> Signed-off-by: Srinivas Kandagatla <srini@kernel.org> Link: https://patch.msgid.link/20260724223342.629168-2-srini@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-31gpiolib: Check gc->get_direction() before calling gpiod_get_direction()Christophe Leroy (CS GROUP)1-1/+2
According to 'struct gpio_chip' documentation in linux/gpio/driver.h, implementing .get_direction() is recommended but not mandatory. Most places verify that gc->get_direction() exists before calling gpiod_get_direction(), but gpiolib_dbg_show() doesn't. Until commit 471e998c0e31 ("gpiolib: remove redundant callback check") it was also verified by gpiod_get_direction() itself so calling it at all time from gpiolib_dbg_show() was not an issue. But after the check in gpiod_get_direction() has been removed, calling it inconditionaly leads to a big fat warning in gpiochip_get_direction(). In gpiod_get_direction(), verify that gc->get_direction() exists before calling gpiod_get_direction(). Fixes: 471e998c0e31 ("gpiolib: remove redundant callback check") Signed-off-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org> Link: https://patch.msgid.link/ad89f92f91d004e63dd5599bb58e9581f373a601.1785318183.git.chleroy@kernel.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-07-31pinctrl: qcom: shikra: Fix intr_target_width for summary interrupt routingKomal Bajaj1-0/+1
The intr_target_width field sets the mask width used when writing target processor into interrupt config register and deciding which processor receives summary interrupt for a given GPIO. Without it, pinctrl driver defaults to a 3-bit mask. On Shikra, this field is 4 bits wide, which could corrupt adjacent bits and mis-route interrupts. Set intr_target_width = 4 to match the hardware. Fixes: 9db68ec534c5 ("pinctrl: qcom: Add Shikra pinctrl driver") Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://patch.msgid.link/20260728-shikra-pinctrl-intr-width-v1-1-46583734d808@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-07-31drm/imagination: Reorder some fields in struct pvr_device_featuresAlexandru Dadu1-3/+3
Reorder the fields of struct pvr_device_features so they match the order of the device info enum found in pvr_rogue_fwif_dev_info.h. Signed-off-by: Alexandru Dadu <alexandru.dadu@imgtec.com> Reviewed-by: Alessio Belle <alessio.belle@imgtec.com> Link: https://patch.msgid.link/20260729-b4-pvr-device-features-members-reorder-v1-1-d2e18ed8cd5f@imgtec.com Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
2026-07-31md/raid1: create serial pool adding rdev to array with serialize_policy=1Martin Wilck1-1/+2
The following bug has been observed with kernel 7.1.3 after adding a new rdev to an existing RAID1 array with serialize_policy enabled: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 19639 Comm: ext4lazyinit Not tainted 7.1.3-1-default RIP: _raw_spin_lock_irqsave+0x27/0x50 CR2: 0000000000004960 Call Trace: wait_for_serialization+0xb9/0x260 [raid1] raid1_make_request+0x762/0xaff [raid1] md_handle_request+0x1c9/0x2e0 [md_mod] The raid1.c code calls wait_for_serialization() if the MD_SERIALIZE_POLICY is set, and wait_for_serialization assumes that rdev->serial is initialized. Normally this will be the case for arrays that have the serialize_policy sysfs attribute set to 1. But when a new rdev is added to an existing array in bind_rdev_to_array(), the condition at mddev_create_serial_pool() causes creation of rdev->serial to be skipped. Fix it. Fixes: 69b00b5bb235 ("md: introduce a new struct for IO serialization") Signed-off-by: Martin Wilck <mwilck@suse.com> Reviewed-by: Mykola Marzhan <mykola@meshstor.io> Link: https://patch.msgid.link/20260723112741.1206836-1-mwilck@suse.com Signed-off-by: Yu Kuai <yukuai@fygo.io>
2026-07-31drm/imagination: Set scheduler timeout period higher than Firmware timeoutBrajesh Gupta1-1/+2
Firmware schedules workloads on the GPU and tracks progress. It is also responsible for detecting any lockup and triggering recovery. Update the GPU scheduler timeout to a reasonably high value to avoid premature timeout at the GPU scheduler end. Signed-off-by: Brajesh Gupta <brajesh.gupta@imgtec.com> Reviewed-by: Alessio Belle <alessio.belle@imgtec.com> Link: https://patch.msgid.link/20260729-sched_timeout-v1-1-4adc801b1997@imgtec.com Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
2026-07-31media: renesas: vsp1: Declare index variables in for loop statementLaurent Pinchart12-96/+56
Using loop indices outside of the loop is a source of out-of-bounds accesses and other bugs. It is important to carefully review those usages. To make them stand out, declare all loop index variables that are not used outside of the loop inside the loop statement. No functional change intended. Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://patch.msgid.link/20260511235637.3468558-11-laurent.pinchart+renesas@ideasonboard.com Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-07-31media: renesas: vsp1: Make reset control optional to support platforms ↵Lad Prabhakar1-1/+1
without a reset line Switch the VSP1 driver to use devm_reset_control_get_optional_shared() when requesting its reset control. Some newer Renesas SoCs integrating VSP1 such as RZ/T2H do not provide a reset line for the VSP IP block. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Link: https://patch.msgid.link/20260430100929.1088281-4-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-07-31drm/panthor: fix firmware control interface bounds checksOsama Abdelkader1-6/+13
panthor_init_cs_iface() and panthor_init_csg_iface() validate firmware control interface offsets with 32-bit arithmetic and the size of the host wrapper structures. The offsets are derived from firmware-provided strides, so the arithmetic can wrap before the bounds check, and the host wrapper size is not the size of the firmware control interface being mapped. Use 64-bit arithmetic for the computed offsets and validate against the actual firmware control interface structure sizes with subtraction-based bounds checks. Also validate that the shared section is large enough for the global control interface before using it. Fixes: 2718d91816ee ("drm/panthor: Add the FW logical block") Cc: stable@vger.kernel.org Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260720134435.13377-1-osama.abdelkader@gmail.com Signed-off-by: Steven Price <steven.price@arm.com>
2026-07-31Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6Herbert Xu3-21/+5
Merge crypto tree to pick up the af_alg cbc(paes) patch. In the merge commit add cbc(paes) to the algorithm white-list.
2026-07-31i3c: renesas: Drop unused structure member 'resuming'Claudiu Beznea1-1/+0
The struct renesas_i3c::resuming is a leftover from a rebase. It is not used anywhere within the driver. Drop it. Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260721191618.1850795-1-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31hwmon: spd5118: Add I3C supportAkhil R2-4/+61
Add a regmap config and a probe function to support I3C-based communication with SPD5118 devices. On an I3C bus, SPD5118 devices are enumerated via SETAASA and always require an ACPI or device tree entry. Device matching is hence through the OF match tables only and does not need an I3C class match table. The device identity is verified in the type registers before proceeding to the common probe function. Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Link: https://patch.msgid.link/20260728065955.809445-12-akhilrajeev@nvidia.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31hwmon: spd5118: Remove 16-bit addressingAkhil R1-74/+5
The intent of introducing 16-bit addressing was to support I3C, but it turns out that I3C does not require reading the Legacy Mode register, nor any specific encoding for page translation. The testing of 16-bit code was limited and there are no known users for this feature. Remove the sections that support 16-bit addressing and prepare the driver to support I3C appropriately. Suggested-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Link: https://patch.msgid.link/20260728065955.809445-11-akhilrajeev@nvidia.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: dw-i3c-master: Add ACPI ID for Tegra410Akhil R1-3/+4
Update variable names to generic names and add Tegra410 ACPI ID to support the I3C controller in Tegra410, which is a DesignWare I3C host controller. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Link: https://patch.msgid.link/20260728065955.809445-10-akhilrajeev@nvidia.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: dw-i3c-master: Add ACPI core clock frequency quirkAkhil R1-12/+33
Some ACPI-enumerated devices like Tegra410 do not expose the controller core clock through the clk framework. Unlike device tree, ACPI on Arm does not model clock providers. The hardware is expected to have its clocks enabled by firmware before the OS takes over. Make the core clock optional and allow selected ACPI devices to provide the core clock rate through the "clock-frequency" _DSD property when the core clock is absent. Resolve device quirks before acquiring the core clock so platforms without the ACPI skip-clock quirk still fail probe immediately when the clock is missing, before any MMIO access. Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Link: https://patch.msgid.link/20260728065955.809445-9-akhilrajeev@nvidia.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: dw-i3c-master: Add SETAASA as supported CCCAkhil R1-0/+2
Add SETAASA and SETHID to the supported list of CCC commands for DesignWare I3C host controller. SETAASA is a broadcast command that assigns predefined static addresses to all I3C devices on the bus. SETHID is to stop HID bit flipping by the SPD Hub to which the SPD devices are connected. It is a prerequisite command to be sent before SETAASA as recommended by JESD300-5 and JESD403 sideband bus specifications. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Link: https://patch.msgid.link/20260728065955.809445-8-akhilrajeev@nvidia.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: master: match I3C device through DT and ACPIAkhil R1-1/+19
SETAASA-based devices cannot always be identified by PID or DCR; the standard I3C id_table matching may not be applicable. Allow such devices to match through Device Tree or ACPI. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Link: https://patch.msgid.link/20260728065955.809445-7-akhilrajeev@nvidia.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: master: Add support for devices without PIDAkhil R1-11/+41
Devices using SETAASA for address assignment are not required to have a 48-bit PID according to the I3C specification. Allow such devices to register and use the static address where PID was required. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Link: https://patch.msgid.link/20260728065955.809445-6-akhilrajeev@nvidia.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: master: Add support for devices using SETAASAAkhil R1-3/+111
Add support for devices using SETAASA, such as SPD5118 and SPD5108 attached to DDR5 memory modules that do not support ENTDAA. Follow the guidelines proposed by the MIPI Discovery and Configuration Specification [1] for discovering such devices. SETAASA (Set All Addresses to Static Address) differs from standard I3C address assignment that uses ENTDAA or SETDASA to assign dynamic addresses. Devices using SETAASA assign their pre-defined static addresses as their dynamic addresses during DAA, and it is not mandatory for these devices to implement standard CCC commands like GETPID, GETDCR, or GETBCR. For such devices, it is generally recommended to issue SETHID (specified by JEDEC JESD300) as a prerequisite for SETAASA to stop HID bit flipping. [1] https://www.mipi.org/mipi-disco-for-i3c-download Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Link: https://www.mipi.org/mipi-disco-for-i3c-download Link: https://patch.msgid.link/20260728065955.809445-5-akhilrajeev@nvidia.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: master: Support ACPI enumeration of child devicesAkhil R1-8/+143
Although the existing subsystem allows host controllers to register through the ACPI table, it was not possible to describe I3C or I2C devices when using ACPI. This is because the driver relied on the reg property to retrieve the PID, static address, etc., whereas ACPI uses _ADR or serial resources to describe such devices. Read _ADR and LVR from ACPI resources and extract the data as per the ACPI specification for an I3C bus. Also read mipi-i3c-static-address as per the MIPI DISCO specifications [1] to get the static address to be used. Enable describing I3C or I2C devices in the ACPI table. This is required if the device uses a static address or if it needs device-specific properties. [1] https://www.mipi.org/mipi-disco-for-i3c-download Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Link: https://patch.msgid.link/20260728065955.809445-4-akhilrajeev@nvidia.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: master: Use unified device property interfaceAkhil R1-34/+43
Replace all OF-specific functions with unified device property functions as a prerequisite to support both ACPI and device tree. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Link: https://patch.msgid.link/20260728065955.809445-3-akhilrajeev@nvidia.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: master: require dests for read CCC commandsAdrian Ng Ho Yin1-1/+2
Read CCC commands (rnw set) always need a destination array to store payload data. Extend the existing direct-CCC validation so cmd->dests is guaranteed non-NULL when cmd->rnw is set. Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <error27@gmail.com> Closes: https://lore.kernel.org/r/202607222347.TXH6r6ie-lkp@intel.com/ Signed-off-by: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Acked-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com> Link: https://patch.msgid.link/153608c2ff6504fe29f5f727a23c53c41768a44a.1784796086.git.adrian.ho.yin.ng@altera.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: master: Fix info leak and UAF in device unregister pathAdrian Hunter1-4/+5
i3c_master_unregister_i3c_devs() clears i3cdev->dev->desc before calling device_unregister(). During device_unregister(), device_del() emits a KOBJ_REMOVE uevent and unbinds the driver while the device descriptor is still expected to be valid. As a result, i3c_device_uevent() and a racing modalias_show() can observe a NULL desc and fall back to an uninitialized stack struct i3c_device_info, leaking kernel stack contents in the generated modalias. Driver .remove() callbacks may also encounter an unexpected NULL desc during unbind. Keep desc valid until device_unregister() has completed. Since device_unregister() drops the device reference and may free the device, take an extra reference with get_device() before unregistering. Clear desc afterwards and release the extra reference with put_device(). This preserves the release-time invariant that desc must be NULL while avoiding both the information leak and a potential use-after-free from writing desc after the device has been released. Reported-by: sashiko-bot@kernel.org Link: https://lore.kernel.org/linux-i3c/20260702190003.8BF741F000E9@smtp.kernel.org/ Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Cc: stable@vger.kernel.org Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260723075747.34049-1-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: master: dw: Drop redundant core reset nameShubham Patil1-1/+1
The DesignWare I3C master has a single reset line, so a dedicated reset name is redundant. Look up the reset by index by passing NULL instead of the "core_rst" name. Signed-off-by: Shubham Patil <shubhamsanjay.patil@amd.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com> Link: https://patch.msgid.link/20260720073510.1869623-3-shubhamsanjay.patil@amd.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: master: adi: add OF module alias for autoloadingCan Peng1-0/+1
The Analog Devices I3C master driver can be built as a module and uses adi_i3c_master_of_match as its OF match table, but the table is not exported for module alias generation. Add the MODULE_DEVICE_TABLE(of, ...) entry so modpost can generate OF module aliases for OF based module autoloading. Fixes: a79ac2cdc91d ("i3c: master: Add driver for Analog Devices I3C Controller IP") Signed-off-by: Can Peng <pengcan@kylinos.cn> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260715012949.180245-1-pengcan@kylinos.cn Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: renesas: Add runtime PM supportClaudiu Beznea1-28/+112
On the SoCs where the Renesas I3C driver is enabled (RZ/G3S and RZ/G3E), the clocks of the IP are managed through a clock PM domain. To keep the I3C code simpler, the explicit clock handling was dropped along with the addition of runtime PM support, in favor of the runtime PM APIs. Only the code for getting tclk was preserved, as it is necessary to compute the I3C clock rate. All the APIs provided to the I3C subsystem through struct i3c_master_controller_ops are guarded with runtime PM APIs to enable/disable the controller at runtime. As the Renesas I3C driver implements an asynchronous transmit model by preparing a transfer and waiting for its completion through the ISR, renesas_i3c_abort_xfer() was added to disable interrupts and clear any pending IRQ status bits when there is no completion in the defined timeout. Along with this, renesas_i3c_wait_xfer() return type was changed to unsigned long. Add runtime PM support for the Renesas I3C driver. Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260713130545.568657-18-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: renesas: Drop unnecessary tabClaudiu Beznea1-1/+1
Remove an unnecessary tab to make the code cleaner. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260713130545.568657-17-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: renesas: Use the "dev_name:irq_name" format for the interrupt nameClaudiu Beznea1-1/+8
Use the "dev_name:irq_name" format for the interrupt names. This makes it easier to identify interrupts in systems where multiple devices may request interrupts with the same name. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260713130545.568657-16-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: renesas: Organize structures to avoid unnecessary paddingClaudiu Beznea1-15/+16
Reorder structure members to reduce padding and improve memory layout. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260713130545.568657-15-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: renesas: Update HW registers after SW computations are doneClaudiu Beznea1-14/+14
renesas_i3c_bus_init() performs a number of computations and software cache updates, interleaving them with hardware register writes. While this works today, it makes it harder to minimize the time the controller must remain powered when runtime PM is introduced. Perform all software computations and cache updates first, then update the hardware registers. This prepares for future runtime PM support. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260713130545.568657-14-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: renesas: Drop the explicit memset() callClaudiu Beznea1-1/+0
Drop the explicit memset() call on struct i3c_device_info object, as it is already initialized at declaration through compiler initialization. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260713130545.568657-13-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: renesas: Follow a unified pattern for transfer and command initializationClaudiu Beznea1-11/+11
Follow a unified pattern for transfer and command initialization across the driver. This keeps the code cleaner and easier to follow. Also, in some cases the I3C device was enabled before the transfer data structure was even allocated. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260713130545.568657-12-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: renesas: Return immediately if there is no transferClaudiu Beznea1-3/+3
There is no need to allocate a transfer structure when i2c_nxfers is zero. Return immediately instead of unnecessarily allocating memory. Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260713130545.568657-11-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>