Prepare qcom-next based on tag 'Linux 6.18-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #78
Conversation
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
…MC runtime suspend resume Crypto reprogram all keys is called for each MMC runtime suspend/resume in current upstream design. If this is implemented as a non-interruptible call to TEE for security, the cpu core is blocked for execution while this call executes although the crypto engine already has the keys. For example, glitches in audio/video streaming applications have been observed due to this. Add the flag MMC_CAP2_CRYPTO_NO_REPROG as part of host->caps2 to control reprogramming keys to crypto engine for socs which dont require this feature. Link: https://lore.kernel.org/r/20250718110217.1929526-1-quic_dmukhopa@quicinc.com Signed-off-by: Seshu Madhavi Puppala <quic_spuppala@quicinc.com> Co-developed-by: Ram Prakash Gupta <quic_rampraka@quicinc.com> Signed-off-by: Ram Prakash Gupta <quic_rampraka@quicinc.com> Co-developed-by: Sarthak Garg <quic_sartgarg@quicinc.com> Signed-off-by: Sarthak Garg <quic_sartgarg@quicinc.com> Signed-off-by: Debraj Mukhopadhyay <quic_dmukhopa@quicinc.com>
Document compatible for cpufreq hardware on Qualcomm QCS615 platform. Signed-off-by: Taniya Das <quic_tdas@quicinc.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/linux-arm-msm/20250702-qcs615-mm-cpu-dt-v4-v5-1-df24896cbb26@quicinc.com/ Signed-off-by: Dongfang Zhao <dongfang.zhao@oss.qualcomm.com>
…istently pulled up by hardware If BT_EN is consistently pulled up by hardware, the QCA_SSR_TRIGGERED and QCA_IBS_DISABLED bits cannot be cleared by qca_setup during SSR. This leads to a failure to send commands due to the error state. To address this, clear QCA_SSR_TRIGGERED and QCA_IBS_DISABLED bits after the coredump collection is complete. Also, add a delay to wait for controller to complete SSR. Signed-off-by: Shuai Zhang <quic_shuaz@quicinc.com> Link: https://lore.kernel.org/all/20250825113858.4017780-1-quic_shuaz@quicinc.com/
…enerate one coredump file Multiple triggers of SSR only first generate coredump file, duo to memcoredump_flag no clear. add clear coredump flag when ssr completed. Signed-off-by: Shuai Zhang <quic_shuaz@quicinc.com> Link: https://lore.kernel.org/all/20250825113858.4017780-1-quic_shuaz@quicinc.com/
…e calls EUD_MODE_MANAGER2 register is mapped to a memory region that is marked as read-only for operating system running at EL1, enforcing access restrictions that prohibit direct memory-mapped writes via writel(). Attempts to write to this region from HLOS can result in silent failures or memory access violations, particularly when toggling EUD (Embedded USB Debugger) state. To ensure secure register access, modify the driver to use qcom_scm_io_writel(), which routes the write operation to Qualcomm Secure Channel Monitor (SCM). SCM has the necessary permissions to access protected memory regions, enabling reliable control over EUD state. SC7280, the only user of EUD is also affected, indicating that this could never have worked on a properly fused device. Link: https://lore.kernel.org/r/20250731-eud_mode_manager_secure_access-v8-1-4a5dcbb79f41@oss.qualcomm.com Fixes: 9a1bf58 ("usb: misc: eud: Add driver support for Embedded USB Debugger(EUD)") Signed-off-by: Melody Olvera <quic_molvera@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com> Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
Add prune.config fragment to disable support for non-Qualcomm architectures. This helps reduce boot image size and improves kernel build KPIs by trimming unnecessary configuration options. Signed-off-by: Komal Bajaj <quic_kbajaj@quicinc.com>
Update Adreno 623's dt-binding to remove smmu_clk which is not required for this GMU. Link: https://lore.kernel.org/lkml/20250903-a623-gpu-support-v5-1-5398585e2981@oss.qualcomm.com/ Signed-off-by: Jie Zhang <quic_jiezh@quicinc.com> Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Add the speedbin mappings for Adreno 623 GPU. Link: https://lore.kernel.org/lkml/20250903-a623-gpu-support-v5-2-5398585e2981@oss.qualcomm.com/ Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Haitao Xu <haitxu@qti.qualcomm.com>
Add speedbin mappings for A663 GPU. Link: https://lore.kernel.org/all/20250910-a663-gpu-support-v6-1-5da15827b249@oss.qualcomm.com/ Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Signed-off-by: Haitao Xu <haitxu@qti.qualcomm.com>
Document compatible string for the QFPROM on Lemans platform. Link: https://lore.kernel.org/all/20250910-a663-gpu-support-v6-2-5da15827b249@oss.qualcomm.com/ Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Signed-off-by: Haitao Xu <haitxu@qti.qualcomm.com>
During bringup of a new GPU support, it is convenient to have knob to quickly disable GPU, but keep the display support. This helps to fallback to 'kms_swrast' in case of bootup issues due to GPU. Add a modparam to support this. Link: https://lore.kernel.org/all/20250911-assorted-sept-1-v2-3-a8bf1ee20792@oss.qualcomm.com/ Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Signed-off-by: Puranam V G Tejaswi <quic_pvgtejas@quicinc.com>
Set PINCTRL_SX150X config option as a tristate and add MODULE_DEVICE_TABLE()/MODULE_LICENSE() to export appropriate information. Signed-off-by: Fange Zhang <fange.zhang@oss.qualcomm.com> Link: https://lore.kernel.org/20250818-modularize-sx150x-gpio-expander-v1-1-c2a027200fed@oss.qualcomm.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
List traversals must be synchronized to prevent race conditions and data corruption. The reboot-mode list is not protected by a lock currently, which can lead to concurrent access and race. Introduce a mutex lock to guard all operations on the reboot-mode list and ensure thread-safe access. The change prevents unsafe concurrent access on reboot-mode list. Fixes: 4fcd504 ("power: reset: add reboot mode driver") Fixes: ca3d2ea ("power: reset: reboot-mode: better compatibility with DT (replace ' ,/')") Link: https://lore.kernel.org/r/20250922-arm-psci-system_reset2-vendor-reboots-v15-1-7ce3a08878f1@oss.qualcomm.com Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
…tration The reboot-mode driver does not have a strict requirement for device-based registration. It primarily uses the device's of_node to read mode-<cmd> properties and the device pointer for logging. Remove the dependency on struct device and introduce support for firmware node (fwnode) based registration. This enables drivers that are not associated with a struct device to leverage the reboot-mode framework. Link: https://lore.kernel.org/r/20250922-arm-psci-system_reset2-vendor-reboots-v15-2-7ce3a08878f1@oss.qualcomm.com Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
Current reboot-mode supports a single 32-bit argument for any supported mode. Some reboot-mode based drivers may require passing two independent 32-bit arguments during a reboot sequence, for uses-cases, where a mode requires an additional argument. Such drivers may not be able to use the reboot-mode driver. For example, ARM PSCI vendor-specific resets, need two arguments for its operation – reset_type and cookie, to complete the reset operation. If a driver wants to implement this firmware-based reset, it cannot use reboot-mode framework. Introduce 64-bit magic values in reboot-mode driver to accommodate dual 32-bit arguments when specified via device tree. In cases, where no second argument is passed from device tree, keep the upper 32-bit of magic un-changed(0) to maintain backward compatibility. Update the current drivers using reboot-mode for a 64-bit magic value. Link: https://lore.kernel.org/r/20250922-arm-psci-system_reset2-vendor-reboots-v15-3-7ce3a08878f1@oss.qualcomm.com Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
Add ABI documentation for /sys/class/reboot-mode/*/reboot_modes, a read-only sysfs attribute exposing the list of supported reboot-mode arguments. This file is created by reboot-mode framework and provides a user-readable interface to query available reboot-mode arguments. Link: https://lore.kernel.org/r/20250922-arm-psci-system_reset2-vendor-reboots-v15-4-7ce3a08878f1@oss.qualcomm.com Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
…ot_modes Currently, there is no standardized mechanism for userspace to discover which reboot-modes are supported on a given platform. This limitation forces tools and scripts to rely on hardcoded assumptions about the supported reboot-modes. Create a class 'reboot-mode' and a device under it to expose a sysfs interface to show the available reboot mode arguments to userspace. Use the driver_name field of the struct reboot_mode_driver to create the device. For device-based drivers, configure the device driver name as driver_name. This results in the creation of: /sys/class/reboot-mode/<driver>/reboot_modes This read-only sysfs file will exposes the list of supported reboot modes arguments provided by the driver, enabling userspace to query the list of arguments. Align the clean up path to maintain backward compatibility for existing reboot-mode based drivers. Link: https://lore.kernel.org/r/20250922-arm-psci-system_reset2-vendor-reboots-v15-5-7ce3a08878f1@oss.qualcomm.com Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
…mode SoC vendors have different types of resets which are controlled through various hardware registers. For instance, Qualcomm SoC may have a requirement that reboot with “bootloader” command should reboot the device to bootloader flashing mode and reboot with “edl” should reboot the device into Emergency flashing mode. Setting up such reboots on Qualcomm devices can be inconsistent across SoC platforms and may require setting different HW registers, where some of these registers may not be accessible to HLOS. These knobs evolve over product generations and require more drivers. PSCI spec defines, SYSTEM_RESET2, vendor-specific reset which can help align this requirement. Add support for PSCI SYSTEM_RESET2, vendor-specific resets and align the implementation to allow user-space initiated reboots to trigger these resets. Implement the PSCI vendor-specific resets by registering to the reboot-mode framework. As psci init is done at early kernel init, reboot-mode registration cannot be done at the time of psci init. This is because reboot-mode creates a “reboot-mode” class for exposing sysfs, which can fail at early kernel init. To overcome this, introduce a late_initcall to register PSCI vendor-specific resets as reboot modes. Implement a reboot-mode write function that sets reset_type and cookie values during the reboot notifier callback. Introduce a firmware-based call for SYSTEM_RESET2 vendor-specific reset in the psci_sys_reset path, using reset_type and cookie if supported by secure firmware. Register a panic notifier and clear vendor_reset valid status during panic. This is needed for any kernel panic that occurs post reboot_notifiers. By using the above implementation, userspace will be able to issue such resets using the reboot() system call with the "*arg" parameter as a string based command. The commands can be defined in PSCI device tree node under “reboot-mode” and are based on the reboot-mode based commands. Link: https://lore.kernel.org/r/20250922-arm-psci-system_reset2-vendor-reboots-v15-7-7ce3a08878f1@oss.qualcomm.com Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com> Reviewed-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
Introduce `qcom.config`, a Qualcomm-specific kernel configuration fragment that enables features required by Qualcomm SoCs. It includes CONFIGs not acceptable under the community's common defconfig and ensures essential features and subsystems required by Qualcomm platforms are enbaled. This initial version of `qcom.config` enables DMABUF heap support, including the system heap and default CMA heap. These configurations are essential for buffer sharing across subsystems such as camera, display, and DSP on Qualcomm platforms like qcs6490. Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
…nfig Add Coresight configs to enable Coresight device drivers on mainline. Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
Enable ZRAM defconfig on qcom.config. This empowers users to use the compressed block devices for usecases, eg: swap device on zram. Tested: make ARCH=arm64 menuconfig defconfig qcom.config, booted with this configuration on QEMU and verified if /dev/zram0 is exist. Signed-off-by: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
Enabled key configs for thermal management (CPU_IDLE_THERMAL, IDLE_INJECT), scheduler (SCHED_DEBUG, SCHEDSTATS, TRACE_MMIO_ACCESS), and power control (POWERCAP, UCLAMP_TASK). Also enabled KPROBES, PAN emulation and watchdog pretimeout panic governor for improved instrumentation and security. Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
Enabled various debug-related kernel config options to improve system diagnostics and aid in development and issue analysis. Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
Add a device tree binding for the Toshiba TC9563 PCIe switch, which provides an Ethernet MAC integrated to the 3rd downstream port and two downstream PCIe ports. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20250828-qps615_v4_1-v6-1-985f90a7dd03@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
First controller driver probes, enables link training and scans the bus. When the PCI bridge is found, its child DT nodes will be scanned and pwrctrl devices will be created if needed. By the time pwrctrl driver probe gets called link training is already enabled by controller driver. Certain devices like TC956x which uses PCI pwrctl framework needs to configure the device before PCI link is up. As the controller driver already enables link training as part of its probe, the moment device is powered on, controller and device participates in the link training and link can come up immediately and may not have time to configure the device. So we need to stop the link training by using stop_link() and enable them back after device is configured by using start_link(). Link: https://lore.kernel.org/r/20250828-qps615_v4_1-v6-3-985f90a7dd03@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
…or dwc glue drivers Add host_start_link() and host_stop_link() functions to dwc glue drivers to register with start_link() and stop_link() of pci ops, allowing for better control over the link initialization and shutdown process. Link: https://lore.kernel.org/r/20250828-qps615_v4_1-v6-4-985f90a7dd03@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Implement stop_link() and start_link() function op for dwc drivers. Link: https://lore.kernel.org/r/20250828-qps615_v4_1-v6-5-985f90a7dd03@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
…nk() Add support for host_stop_link() and host_start_link() for switches like TC956x, which require configuration before the PCIe link is established. Assert PERST# and disable LTSSM bit to prevent the PCIe controller from participating in link training during host_stop_link(). De-assert PERST# and enable LTSSM bit during host_start_link(). Introduce ltssm_disable function op to stop link training. For the switches like TC956x, which needs to configure it before the PCIe link is established. Link: https://lore.kernel.org/r/20250828-qps615_v4_1-v6-6-985f90a7dd03@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
…active Add pcie_link_is_active() a common API to check if the PCIe link is active, replacing duplicate code in multiple locations. Signed-off-by: Shawn Anastasio <sanastasio@raptorengineering.com> Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com> Reviewed-by: Lukas Wunner <lukas@wunner.de> Link: https://lore.kernel.org/r/20250828-qps615_v4_1-v6-7-985f90a7dd03@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
TC9563 is a PCIe switch which has one upstream and three downstream ports. To one of the downstream ports integrated ethernet MAC is connected as endpoint device. Other two downstream ports are supposed to connect to external device. One Host can connect to TC9563 by upstream port. TC9563 switch needs to be configured after powering on and before the PCIe link was up. The PCIe controller driver already enables link training at the host side even before this driver probe happens, due to this when driver enables power to the switch it participates in the link training and PCIe link may come up before configuring the switch through i2c. Once the link is up the configuration done through i2c will not have any affect.To prevent the host from participating in link training, disable link training on the host side to ensure the link does not come up before the switch is configured via I2C. Based up on dt property and type of the port, tc9563 is configured through i2c. Reviewed-by: Bjorn Andersson <andersson@kernel.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20250828-qps615_v4_1-v6-8-985f90a7dd03@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
1 similar comment
Adding merge log file and topic_SHA1 file Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
sgaud-quic
force-pushed
the
qcom-next-staging
branch
from
0af7004 to
abd05c6
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
17 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.
Name SHA Commits
tech/bsp/clk fe2e403 1
tech/bsp/soc-infra fb98935 2
tech/bsp/pinctrl 31abea7 1
tech/bsp/remoteproc 8069134 12
tech/bus/pci/pwrctl b2c1ca9 7
tech/debug/eud eb36d9d 1
tech/debug/hwtracing 04dc51a 13
tech/mm/audio/all 5534191 2
tech/mm/drm 69cdd9f 5
tech/mm/fastrpc dba4eb2 3
tech/mm/gpu d62e8b2 5
tech/net/bluetooth b5902f2 2
tech/pm/power dbdf549 6
tech/security/ice 9a1a01d 1
tech/all/dt/qcs6490 90671a1 4
tech/all/dt/qcs9100 b87798a 7
tech/all/dt/qcs8300 80742f3 7
tech/all/dt/qcs615 b879f8a 4
tech/all/config d39f17e 6
tech/overlay/dt a17e50f 1