selftests/remoteproc: Add selftest suite for sysfs interface#743
Open
bibekpatro wants to merge 79 commits into
Open
selftests/remoteproc: Add selftest suite for sysfs interface#743bibekpatro wants to merge 79 commits into
bibekpatro wants to merge 79 commits into
Conversation
…oring Add support for ADC_TM part of PMIC5 Gen3. This is an auxiliary driver under the Gen3 ADC driver, which implements the threshold setting and interrupt generating functionalities of QCOM ADC_TM drivers, used to support thermal trip points. Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Link: https://lore.kernel.org/all/20260209105438.596339-5-jishnu.prakash@oss.qualcomm.com/ Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
Add the "qcom,qcs615-qspi" compatible string to the Qualcomm QSPI device- tree binding to enable QCS615-based platforms to use the existing QSPI controller binding. Link: https://patch.msgid.link/20260324-spi-nor-v1-1-3efe59c1c119@oss.qualcomm.com Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
The QSPI controller has two interconnect paths: 1. qspi-config: CPU to QSPI controller for register access 2. qspi-memory: QSPI controller to memory for DMA operations Currently, the driver only manages the qspi-config path. Add support for the qspi-memory path to ensure proper bandwidth allocation for QSPI data transfers to/from memory. Enable and disable both paths during runtime PM transitions. Link: https://patch.msgid.link/20260324-spi-nor-v1-2-3efe59c1c119@oss.qualcomm.com Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
…oller support Document a DeviceTree property to describe QUP-based I2C controllers that are shared with one or more other system processors. On some Qualcomm platforms, a QUP-based I2C controller may be accessed by multiple system processors (for example, APPS and DSP). In such configurations, the operating system must not assume exclusive ownership of the controller or its associated hardware resources. The new qcom,qup-multi-owner property indicates that the controller is externally shared and that the operating system must avoid operations which rely on sole control of the hardware. Link: https://lore.kernel.org/all/20260331114742.2896317-2-mukesh.savaliya@oss.qualcomm.com/ Signed-off-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com>
…I2C transfers Some platforms use a QUP-based I2C controller in a configuration where the controller is shared with another system processor (described in DT using qcom,qup-multi-owner). In such setups, GPI hardware lock/unlock TREs can be used to serialize access to the controller. Add support to emit lock and unlock TREs around I2C transfers and increase the maximum TRE count to account for the additional elements. Also simplify the client interface by replacing multiple boolean fields (shared flag and message position tracking) with a single lock_action selector (acquire/release/none), as the GPI driver only needs to know whether to emit lock/unlock TREs for a given transfer. Link: https://lore.kernel.org/all/20260331114742.2896317-3-mukesh.savaliya@oss.qualcomm.com/ Signed-off-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com>
…trollers On platforms where a GENI Serial Engine is shared with another system processor, selecting the "sleep" pinctrl state can disrupt ongoing transfers initiated by the other processor. Teach geni_se_resources_off() to skip selecting the pinctrl sleep state when the Serial Engine is marked as shared, while still allowing the rest of the resource shutdown sequence to proceed. This is required for multi-owner configurations (described via DeviceTree with qcom,qup-multi-owner on the protocol controller node). Link: https://lore.kernel.org/all/20260331114742.2896317-4-mukesh.savaliya@oss.qualcomm.com/ Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com>
Some platforms use a QUP-based I2C controller in a configuration where the controller is shared with another system processor. In this setup the operating system must not assume exclusive ownership of the controller or its associated pins. Add support for enabling multi-owner operation when DeviceTree specifies qcom,qup-multi-owner. When enabled, mark the underlying serial engine as shared so the common GENI resource handling avoids selecting the "sleep" pinctrl state, which could disrupt transfers initiated by the other processor. For GPI mode transfers, request lock/unlock TRE sequencing from the GPI driver by setting a single lock_action selector per message, emitting lock before the first message and unlock after the last message (handling the single-message case as well). This serializes access to the shared controller without requiring message-position flags to be passed into the DMA engine layer. Link: https://lore.kernel.org/all/20260331114742.2896317-5-mukesh.savaliya@oss.qualcomm.com/ Signed-off-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com>
When other drivers attempt I2C transfers during early resume phase, the I2C controller is still runtime suspended, causing pm_runtime_get_sync() to fail with -EACCES (-13): [ 101.914202] geni_i2c 980000.i2c: error turning SE resources:-13 The PM runtime core returns -EACCES when runtime PM is disabled (dev->power.disable_depth > 0). This occurs because: 1. During suspend_noirq, I2C driver calls geni_i2c_runtime_suspend() and then pm_runtime_disable() 2. I2C driver's noirq_resume only marks adapter as resumed but doesn't re-enable runtime PM or power up the hardware 3. Other drivers resuming later attempt I2C transfers 4. pm_runtime_get_sync() returns -EACCES because runtime PM is still disabled Fix this by calling pm_runtime_force_resume() in geni_i2c_resume_noirq() to properly resume the hardware and re-enable runtime PM during the noirq phase. This ensures the I2C controller is powered and ready for use when other drivers need it during resume. Upstream-Status: Pending Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com> Signed-off-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com>
…DMA completion IRQ
When uart_flush_buffer() runs before the DMA completion IRQ is delivered,
the following race can occur (all steps serialized by uart_port_lock):
1. DMA starts: tx_remaining = N, kfifo contains N bytes
2. DMA completes in hardware; IRQ is pending but not yet delivered
3. uart_flush_buffer() acquires the port lock and calls kfifo_reset(),
making kfifo_len() = 0 while tx_remaining remains N
4. uart_flush_buffer() releases the port lock
5. DMA IRQ fires; handle_tx_dma() acquires the port lock and calls
uart_xmit_advance(uport, tx_remaining) on an empty kfifo
uart_xmit_advance() increments kfifo->out by tx_remaining. Since
kfifo_reset() already set both in and out to 0, out wraps past in,
causing kfifo_len() to return UART_XMIT_SIZE - tx_remaining. The next
start_tx_dma() call then submits a DMA transfer of stale buffer data.
Fix this by snapshotting kfifo_len() at the start of handle_tx_dma()
and skipping uart_xmit_advance() when fifo_len < tx_remaining, which
indicates the kfifo was reset by a preceding flush.
Link: https://patch.msgid.link/20260506-serial-dma-stale-tx-buf-v1-1-e3ccb360d719@oss.qualcomm.com
Fixes: 2aaa43c ("tty: serial: qcom-geni-serial: add support for serial engine DMA")
Cc: stable@vger.kernel.org
Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
The fdlist is currently part of the meta buffer, computed during put_args. This leads to code duplication when preparing and reading critical meta buffer contents used by the FastRPC driver. Move fdlist to the invoke context structure to improve maintainability and reduce redundancy. This centralizes its handling and simplifies meta buffer preparation and reading logic. Link: https://lore.kernel.org/all/20260215182136.3995111-2-ekansh.gupta@oss.qualcomm.com/ Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
Replace the hardcoded context ID mask (0xFF0) with GENMASK(11, 4) to improve readability and follow kernel bitfield conventions. Use FIELD_PREP and FIELD_GET instead of manual shifts for setting and extracting ctxid values. Link: https://lore.kernel.org/all/20260215182136.3995111-3-ekansh.gupta@oss.qualcomm.com/ Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
…support Current FastRPC context uses a 12-bit mask: [ID(8 bits)][PD type(4 bits)] = GENMASK(11, 4) This works for normal calls but fails for DSP polling mode. Polling mode expects a 16-bit layout: [15:8] = context ID (8 bits) [7:5] = reserved [4] = async mode bit [3:0] = PD type (4 bits) If async bit (bit 4) is set, DSP disables polling. With current mask, odd IDs can set this bit, causing DSP to skip poll updates. Update FASTRPC_CTXID_MASK to GENMASK(15, 8) so IDs occupy upper byte and lower byte is left for DSP flags and PD type. Reserved bits remain unused. This change is compatible with polling mode and does not break non-polling behavior. Bit layout: [15:8] = CCCCCCCC (context ID) [7:5] = xxx (reserved) [4] = A (async mode) [3:0] = PPPP (PD type) Link: https://lore.kernel.org/all/20260215182136.3995111-4-ekansh.gupta@oss.qualcomm.com/ Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
For any remote call to DSP, after sending an invocation message, fastRPC driver waits for glink response and during this time the CPU can go into low power modes. This adds latency to overall fastrpc call as CPU wakeup and scheduling latencies are included. Add polling mode support with which fastRPC driver will poll continuously on a memory after sending a message to remote subsystem which will eliminate CPU wakeup and scheduling latencies and reduce fastRPC overhead. Poll mode can be enabled by user by using FASTRPC_IOCTL_SET_OPTION ioctl request with FASTRPC_POLL_MODE request id. Link: https://lore.kernel.org/all/20260215182136.3995111-5-ekansh.gupta@oss.qualcomm.com/ Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
…cture Add reference counting using kref to the fastrpc_user structure to prevent use-after-free issues when contexts are freed from workqueue after device release. The issue occurs when fastrpc_device_release() frees the user structure while invoke contexts are still pending in the workqueue. When the workqueue later calls fastrpc_context_free(), it attempts to access buf->fl->cctx in fastrpc_buf_free(), leading to a use-after-free: pc : fastrpc_buf_free+0x38/0x80 [fastrpc] lr : fastrpc_context_free+0xa8/0x1b0 [fastrpc] ... fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_put_wq+0x78/0xa0 [fastrpc] process_one_work+0x180/0x450 worker_thread+0x26c/0x388 Implement proper reference counting to fix this: - Initialize kref in fastrpc_device_open() - Take a reference in fastrpc_context_alloc() for each context - Release the reference in fastrpc_context_free() when context is freed - Release the initial reference in fastrpc_device_release() This ensures the user structure remains valid as long as there are contexts holding references to it, preventing the race condition. Link: https://lore.kernel.org/all/20260226151121.818852-1-anandu.e@oss.qualcomm.com/ Signed-off-by: Anandu Krishnan E <anandu.e@oss.qualcomm.com>
…emory pool 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. Link: https://lore.kernel.org/all/20260409062617.1182-2-jianping.li@oss.qualcomm.com/ Fixes: 0871561 ("misc: fastrpc: Add support for audiopd") Cc: stable@kernel.org Co-developed-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
…tion 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 any other thread removes the entry from list while unmap operation is ongoing. Remove the entry before calling unmap operation. Link: https://lore.kernel.org/all/20260409062617.1182-3-jianping.li@oss.qualcomm.com/ Fixes: 2419e55 ("misc: fastrpc: add mmap/unmap support") Cc: stable@kernel.org Co-developed-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
… in probe Allocating and freeing Audio PD memory from userspace is unsafe because the kernel cannot reliably determine when the DSP has finished using the memory. Userspace may free buffers while they are still in use by the DSP, and remote free requests cannot be safely trusted. Allocate the entire Audio PD reserved-memory region upfront during rpmsg probe and tie its lifetime to the rpmsg channel. This avoids userspace- controlled alloc/free and ensures memory is reclaimed only when the DSP shuts down. Link: https://lore.kernel.org/all/20260409062617.1182-4-jianping.li@oss.qualcomm.com/ Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
Make fastrpc_buf_free() a no-op when passed a NULL pointer, allowing callers to avoid open-coded NULL checks. Link: https://lore.kernel.org/all/20260409062617.1182-5-jianping.li@oss.qualcomm.com/ Co-developed-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
…750 PMICs On Glymur, Kaanapali, and SM8750, PMIC info is not being properly populated in qcom_socinfo. Its shows `unknown` as PMIC subtypes are not updated in the socinfo. root@glymur-crd:/sys/kernel/debug/qcom_socinfo# cat pmic_model unknown (92) root@glymur-crd:/sys/kernel/debug/qcom_socinfo# cat pmic_model_array unknown (92) unknown (93) unknown (98) unknown (98) unknown (97) unknown (97) unknown (96) unknown (96) Update the SUBTYPE info for PMICs present on Glymur,Kaanapali and SM8750 boards, to fix this issue. Also, there are some PMIC subtypes present in the socinfo but not present in the spmi header file, add these entries to keep both definitions aligned. Link: https://lore.kernel.org/all/20260507-fury-v1-1-d24e4bb5b774@qti.qualcomm.com/ Signed-off-by: Raj Aryan <raryan@qti.qualcomm.com>
Add macro definitions for virtual channels (combination of ADC channel number and PMIC SID number), to be used in devicetree by clients of ADC5 GEN3 device and in the "reg" property of ADC channels. Link: https://lore.kernel.org/all/20260430-adc5_gen3_dt-v1-1-ab2bb40fd490@oss.qualcomm.com/ Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
Add ADC nodes for the four PMM8654au PMICs (pmm8654au_0 through pmm8654au_3) on the Lemans platform. Each ADC node exposes the following ADC channels: - DIE_TEMP: PMIC die temperature channel - VPH_PWR: Battery/supply voltage channel Also add the io-channels and io-channel-names properties under the temp-alarm nodes so that they can get temperature reading from the ADC die_temp channels. Link: https://lore.kernel.org/all/20260430-adc5_gen3_dt-v1-2-ab2bb40fd490@oss.qualcomm.com/ Signed-off-by: Ayyagari Ushasreevalli <aushasre@qti.qualcomm.com> Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
Add ADC nodes for PMM8620AU PMIC instances (SID 0 and SID 2) present on the Monaco platform. Each ADC node exposes the following ADC channels: - DIE_TEMP: PMIC die temperature channel - VPH_PWR: Battery/supply voltage channel Link: https://lore.kernel.org/all/20260430-adc5_gen3_dt-v1-3-ab2bb40fd490@oss.qualcomm.com/ Signed-off-by: Ayyagari Ushasreevalli <aushasre@qti.qualcomm.com> Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
…rocess abort When a userspace FastRPC client is abruptly terminated, FastRPC cleanup paths can race with device and session teardown. This results in kernel panics in different release paths: - fastrpc_release() when using remote heap, originating from fastrpc_buf_free() - fastrpc_device_release() when using system heap, originating from fastrpc_free_map() In addition, fastrpc_map_put() may trigger refcount use-after-free due to concurrent cleanup without proper synchronization. The root cause is that buffer and map cleanup paths may access map and buf resources after the associated device or session has already been released. Fix this by: - Introducing mutex protection for map and buf lifetime - Serializing buffer and map cleanup against device teardown - Skipping buffer and map operations when the device is already gone These changes ensure cleanup paths are safe against unexpected process aborts and prevent use-after-free and kernel panic scenarios. Link: https://lore.kernel.org/all/20260427105310.4056-1-jianping.li@oss.qualcomm.com/ Fixes: c68cfb7 ("misc: fastrpc: Add support for context Invoke method") Cc: stable@kernel.org Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
…s zero In qcom_geni_serial_handle_rx_dma(), geni_se_rx_dma_unprep() clears port->rx_dma_addr before SE_DMA_RX_LEN_IN is read. If the register is zero, for example when the RX stale counter fires on an idle line, the handler returns without calling geni_se_rx_dma_prep(). The next RX DMA interrupt then hits the !port->rx_dma_addr guard and returns immediately, so the RX DMA buffer is never rearmed and later input is lost. Keep the handler on the rearm path when rx_in is zero. Warn about the unexpected zero-length DMA completion, skip received-data handling, and always call geni_se_rx_dma_prep(). Link: https://lore.kernel.org/all/20260528-serial-rx-0-byte-fix-v1-1-dc4e876c7368@oss.qualcomm.com/ Fixes: 2aaa43c ("tty: serial: qcom-geni-serial: add support for serial engine DMA") Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
Commit b99181c ("spi-geni-qcom: remove manual CS control") introduced automatic CS control via the FRAGMENTATION bit, but missed the case where cs_change is set on the last transfer in a message. For the last transfer, cs_change means that CS should remain asserted after the message completes. Since GENI SPI controls CS through FRAGMENTATION, set FRAGMENTATION for this case as well as for non-last transfers where cs_change is not set. Additionally, setup_gsi_xfer() was storing FRAGMENTATION (BIT(2) = 4) in peripheral.fragmentation, which is a boolean field consumed by gpi_create_spi_tre() via u32_encode_bits(..., TRE_SPI_GO_FRAG). Storing 4 causes u32_encode_bits to mask it to 0, silently disabling the FRAG bit in the GPI TRE regardless of the cs_change logic. Store 1 instead. Without these fixes, TPM TIS SPI transfers deassert CS between single-transfer messages that use cs_change to keep CS asserted across the header, wait-state, and data phases, breaking TCG SPI flow control: tpm_tis_spi: probe of spi11.0 failed with error -110 Update both setup_se_xfer() and setup_gsi_xfer() to handle this condition. Link: https://lore.kernel.org/all/20260529-fix-spi-fragmentation-bit-logic-v1-1-3b30f1a3dd7d@oss.qualcomm.com/ Fixes: b99181c ("spi-geni-qcom: remove manual CS control") Cc: stable@vger.kernel.org Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
…messages On some platforms (e.g. QCS615 Talos), fastrpc may temporarily fail to retrieve DSP attributes during boot, resulting in repeated "Error: dsp information is incorrect" messages printed on the console. These messages are observed continuously during boot when metadata flashing is enabled as part of RC releases, causing unnecessary log noise. Similarly, the absence of reserved DMA memory is a valid configuration and does not represent an error condition. Since these scenarios are expected and do not indicate a failure, downgrade the log level from dev_err/dev_info to dev_dbg to avoid flooding the console. No functional change intended. Link: https://lore.kernel.org/all/20260514062825.50172-1-jianping.li@oss.qualcomm.com/ Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
…ser structure" This reverts commit 94b182f. This change corresponds to the initial (v1) version shared with the upstream community. Revert it to apply the complete v4 revision, which includes additional fixes and updates not present in the earlier version. v4 version contains this changes as well. Signed-off-by: Anandu Krishnan E <anandu.e@oss.qualcomm.com>
…eue context
There is a race between fastrpc_device_release() and the workqueue
that processes DSP responses. When the user closes the file descriptor,
fastrpc_device_release() frees the fastrpc_user structure. Concurrently,
an in-flight DSP invocation can complete and fastrpc_rpmsg_callback()
schedules context cleanup via schedule_work(&ctx->put_work). If the
workqueue runs fastrpc_context_free() in parallel with or after
fastrpc_device_release() has freed the user structure, it dereferences
the freed fastrpc_user. Depending on the state of the context at the
time of the race, any one of the following accesses can be hit:
1. fastrpc_buf_free() calls fastrpc_ipa_to_dma_addr(buf->fl->cctx, ...)
to strip the SID bits from the stored IOVA before passing the
physical address to dma_free_coherent().
2. fastrpc_free_map() reads map->fl->cctx->vmperms[0].vmid to
reconstruct the source permission bitmask needed for the
qcom_scm_assign_mem() call that returns memory from the DSP VM
back to HLOS.
3. fastrpc_free_map() acquires map->fl->lock to safely remove the
map node from the fl->maps list.
The resulting use-after-free manifests as:
pc : fastrpc_buf_free+0x38/0x80 [fastrpc]
lr : fastrpc_context_free+0xa8/0x1b0 [fastrpc]
fastrpc_context_free+0xa8/0x1b0 [fastrpc]
fastrpc_context_put_wq+0x78/0xa0 [fastrpc]
process_one_work+0x180/0x450
worker_thread+0x26c/0x388
Add kref-based reference counting to fastrpc_user. Have each invoke
context take a reference on the user at allocation time and release it
when the context is freed. Release the initial reference in
fastrpc_device_release() at file close. Move the teardown of the user
structure — freeing pending contexts, maps, mmaps, and the channel
context reference — into the kref release callback fastrpc_user_free(),
so that it runs only when the last reference is dropped, regardless of
whether that happens at device close or after the final in-flight
context completes.
Link:https://lore.kernel.org/all/20260518203507.3754994-1-anandu.e@oss.qualcomm.com/
Fixes: 6cffd79 ("misc: fastrpc: Add support for dmabuf exporter")
Cc: stable@kernel.org
Signed-off-by: Anandu Krishnan E <anandu.e@oss.qualcomm.com>
# Conflicts: # arch/arm64/boot/dts/qcom/lemans.dtsi
# Conflicts: # arch/arm64/boot/dts/qcom/monaco.dtsi
# Conflicts: # arch/arm64/boot/dts/qcom/kaanapali.dtsi
# Conflicts: # arch/arm64/configs/defconfig
# Conflicts: # arch/arm64/boot/dts/qcom/Makefile
# Conflicts: # arch/arm64/boot/dts/qcom/qcs8300-ride.dts # drivers/bluetooth/hci_qca.c # drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
# Conflicts: # Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml # drivers/gpu/drm/bridge/lontium-lt9611c.c # drivers/misc/fastrpc.c # drivers/remoteproc/qcom_q6v5_pas.c # drivers/soc/qcom/smem.c # sound/soc/qcom/qdsp6/q6prm.h
Adding glymur-crd to the QSEECOM allowlist causes qcom_scm to fully initialize at early boot, which sets up uefisecapp and registers EFI variable operations. This makes efi_has_tpm2() succeed by reading the LoaderTpm2ActivePcrBanks EFI variable, satisfying ConditionSecurity=tpm2 in systemd. As a result, systemd activates tpm2.target which unconditionally waits for /dev/tpm0 and /dev/tpmrm0. systemd waits the full 90-second timeout for each of the two TPM device units, pushing total boot time beyond 2 minutes. Revert until TPM driver in place and /dev/tpm0 node is created. This reverts commit 87a1698. Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
Adding merge log file and topic_SHA1 file Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
…g/pub/scm/linux/kernel/git/torvalds/linux.git tech/bsp/clk d278a36 18 tech/bsp/devfreq a0c2f21 6 tech/bsp/ec 643c24b 2 tech/bsp/soc-infra 6aff3e6 25 tech/bsp/pinctrl 3f1acf8 1 tech/bsp/remoteproc a7b9b6d 10 tech/bus/peripherals 342d00a 10 tech/bus/pci/all 7650854 26 tech/bus/pci/phy aaf8ef1 4 tech/bus/usb/dwc e929e6d 3 tech/bus/usb/phy 984aa89 36 tech/debug/hwtracing 25c6a74 30 tech/pmic/misc ee32a8c 5 tech/mem/iommu 2831e57 7 tech/mm/audio/all cab3357 10 tech/mm/camss fdc4e57 34 tech/mm/drm 24ebe66 62 tech/mm/fastrpc 7cd5e18 13 tech/mm/video 1bc33f6 166 tech/mm/gpu f67b888 6 tech/net/ath edebe42 20 tech/net/phy a3602e9 1 tech/pm/power 2d42c35 9 tech/pm/thermal 3f033cb 7 tech/security/crypto f030676 14 tech/security/ice c72a252 18 tech/storage/all 6a34168 4 tech/all/dt/qcs6490 abb8a3a 22 tech/all/dt/qcs9100 fe7da88 23 tech/all/dt/qcs8300 c8a238b 23 tech/all/dt/qcs615 277da5d 11 tech/all/dt/agatti c828f10 1 tech/all/dt/hamoa f070434 31 tech/all/dt/glymur 7712b84 35 tech/all/dt/kaanapali 0fa62a7 15 tech/all/dt/pakala d7f29fa 9 tech/all/config a370d20 68 tech/overlay/dt 587d3d5 60 tech/all/workaround f3ee72b 24 tech/mproc/all 0aa90b7 3 tech/noup/debug/all cbdd4bb 26 tech/hwe/unoq b2ea57b 5 early/hwe/shikra/drivers bd708fc 168 early/hwe/shikra/dt 95e145f 107
…y DSF On Shikra, the DDR System Firmware (DSF) configures ECC interrupt routing before the kernel driver probes — it enables Tag/Data RAM interrupts and programs error thresholds in the LLCC interrupt-enable registers. Set irq_configured in shikra_cfg so that qcom_llcc_edac_probe() skips calling qcom_llcc_core_setup(), which would otherwise overwrite the firmware-managed register state with redundant writes. Signed-off-by: Faiyaz Mohammed <faiyazm@qti.qualcomm.com>
…blement The eMMC overlay currently explicitly overrides the vreg_l8a voltage to handle the common VDD rail shared between UFS and eMMC. However, their mutual exclusivity is now managed dynamically via DT-fixup logic. Remove these static entries from the overlay to allow flexible storage configurations. Link: https://lore.kernel.org/all/20260616130347.3096034-1-monish.chunara@oss.qualcomm.com/ Signed-off-by: Monish Chunara <monish.chunara@oss.qualcomm.com>
Add a new selftest suite for the remoteproc framework covering its stable userspace-facing sysfs interface: - /sys/class/remoteproc/remoteprocN/ (sysfs attributes) remoteproc_sysfs covers all sysfs attributes (name, state, firmware, coredump, recovery) with 11 tests: read validity checks, invalid write rejection, read-after-write roundtrips, firmware write while offline, and stop-when-offline noop. The binary uses kselftest_harness.h with FIXTURE/FIXTURE_TEARDOWN to ensure sysfs state (firmware, coredump, recovery) is restored to its original value after each test regardless of pass or fail. The binary skips gracefully with KSFT_SKIP when no remoteproc devices are present, making it safe to run in CI environments without remoteproc hardware. start/stop lifecycle tests and debugfs interfaces are intentionally excluded: the former requires a platform-specific firmware binary that cannot be assumed present in a generic test environment, and the latter is not part of the stable userspace ABI. Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com> Cc: Bjorn Andersson <andersson@kernel.org> Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Cc: Shuah Khan <shuah@kernel.org> Cc: linux-remoteproc@vger.kernel.org Cc: linux-kselftest@vger.kernel.org
|
Merge Check Failed: No CR Numbers Found Error: No Change Request numbers were found. Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
11 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add a new selftest suite for the remoteproc framework covering its stable userspace-facing sysfs interface:
remoteproc_sysfs covers all sysfs attributes (name, state, firmware, coredump, recovery) with 11 tests: read validity checks, invalid write rejection, read-after-write roundtrips, firmware write while offline, and stop-when-offline noop.
The binary uses kselftest_harness.h with FIXTURE/FIXTURE_TEARDOWN to ensure sysfs state (firmware, coredump, recovery) is restored to its original value after each test regardless of pass or fail.
The binary skips gracefully with KSFT_SKIP when no remoteproc devices are present, making it safe to run in CI environments without remoteproc hardware.
start/stop lifecycle tests and debugfs interfaces are intentionally excluded: the former requires a platform-specific firmware binary that cannot be assumed present in a generic test environment, and the latter is not part of the stable userspace ABI.
Cc: Bjorn Andersson andersson@kernel.org
Cc: Mathieu Poirier mathieu.poirier@linaro.org
Cc: Shuah Khan shuah@kernel.org
Cc: linux-remoteproc@vger.kernel.org
Cc: linux-kselftest@vger.kernel.org