summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2026-07-31md: suspend array when sync_action=reshapeChen Cheng1-3/+12
raid10 needs to resize/swap r10bio_pool when reshape changes raid_disks, and, don't let new requests keep allocating r10bio objects from the old pool while that transition is in progress. suspend and lock array before mddev_start_reshape(), and resume it on exit. Other sync_action ops are unchanged. Signed-off-by: Chen Cheng <chencheng@fnnas.com> Link: https://patch.msgid.link/20260711100352.425177-2-chencheng@fnnas.com Signed-off-by: Yu Kuai <yukuai@fygo.io>
2026-07-30soc: qcom: smem: Use 'unsigned int' instead of 'unsigned'Konrad Dybcio1-11/+10
checkpatch.pl reports: WARNING: Prefer 'unsigned int' to bare use of 'unsigned' Convert the SMEM driver to use the less ambiguous type instead. Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260727-topic-smem_dramc-v5-1-66188b3e338d@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30firmware: qcom: scm: Fix tzmem state on probe retryMukesh Ojha1-4/+9
qcom_tzmem_enable() returns -EBUSY if called a second time, but this causes probe retries to fail permanently if a later step in qcom_scm_probe() defers after qcom_tzmem_enable() has already succeeded. Use DO_ONCE() to ensure qcom_tzmem_init() runs exactly once across all calls in a thread-safe manner. qcom_tzmem_dev is set on every call since probe retries use the same device pointer. The result of the first initialisation is cached and returned to every subsequent caller. Fixes: 40289e35ca52 ("firmware: qcom: scm: enable the TZ mem allocator") Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260724094939.613844-4-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30firmware: qcom: scm: Fix reserved memory cleanup on probe failureMukesh Ojha1-6/+14
of_reserved_mem_device_init() adds an entry to a global list with no devres counterpart. If qcom_scm_probe() fails after the call the assignment is never cleaned up. A probe retry would add a duplicate entry, leaking the original one permanently. Add an err_rmem label that calls of_reserved_mem_device_release() and route all error paths after of_reserved_mem_device_init() through it. of_reserved_mem_device_release() is safe to call unconditionally as it simply walks an empty list when nothing was assigned. Fixes: a33b2579c8d3 ("firmware: qcom: scm: add support for SHM bridge memory carveout") Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260724094939.613844-3-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30firmware: qcom: scm: Fix NULL dereference in IRQ handler before __scm is ↵Mukesh Ojha3-14/+12
published In qcom_scm_probe(), devm_request_threaded_irq() is called before smp_store_release(&__scm, scm). Two paths can dereference __scm before it is published, both causing a NULL pointer dereference. The IRQ handler receives scm via its data argument but passes only wq_ctx to qcom_scm_waitq_wakeup() and qcom_scm_get_completion(), which then dereference __scm directly. Thread scm through both functions so the IRQ handler path never touches __scm. Non-atomic SMC calls made during probe (e.g. from qcom_tzmem_init via qcom_scm_shm_bridge_enable) can return WAITQ_SLEEP, causing qcom_scm_wait_for_wq_completion() to run before __scm is published and dereference it. Add platform_set_drvdata(pdev, scm) early in probe and change qcom_scm_wait_for_wq_completion() to take the device pointer and use dev_get_drvdata() to reach scm, removing any dependency on __scm. Fixes: 6bf325992236 ("firmware: qcom: scm: Add wait-queue handling logic") Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260724094939.613844-2-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30firmware: qcom: scm: Allow QSEECOM on Asus Zenbook A16 (UX3607OA)Konrad Dybcio1-0/+1
In line with other Glymur-based machines, the Asus Zenbook A16 (UX3607OA) exposes EFI variables through the "uefisecapp". Add it to the QSEECOM allowlist to enable this access. Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260721-topic-a16_submission-v1-3-8ea213130d05@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30ASoC: Intel: catpt: Code cleanup and renamesMark Brown4-108/+105
Cezary Rojewski <cezary.rojewski@intel.com> says: Direct follow up to the cleanup from June [1] and fixes from May [2]. Patches 4/8 and 5/8 is what I actually started with, several years ago when doing first attempts in addressing the long-standing problem [3]. With these, it is easy for a developer to move between the driver and the firmware repository. A clear example of why naming is imporant. Patches 2-8 carry no functional impact. Patch 1/8 slightly alters the suspend procedure as explained in its commit message. From practical perspective though, 1/8 too has no real impact on the functional flow. Changes found here reduce the code complexity slightly and rename a bunch of functions and variables. [1]: https://lore.kernel.org/all/20260603085827.1964796-1-cezary.rojewski@intel.com/ [2]: https://lore.kernel.org/linux-sound/20260528083444.1439233-1-cezary.rojewski@intel.com/ [3]: https://lore.kernel.org/linux-sound/20260528083444.1439233-2-cezary.rojewski@intel.com/ Link: https://patch.msgid.link/20260729110057.342447-1-cezary.rojewski@intel.com
2026-07-30ASoC: Intel: catpt: Streamline control-variables namingCezary Rojewski1-2/+1
Two naming patterns exist currently in the code: 'kcontrol' and 'kctl'. Pick one and stick with it. Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://patch.msgid.link/20260729110057.342447-9-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-30ASoC: Intel: catpt: Streamline runtime-variables namingCezary Rojewski1-21/+21
Mimic naming pattern commonly found in the ASoC code: - 'rtd' in case of struct snd_soc_pcm_runtime - 'runtime' in case of struct snd_pcm_runtime Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://patch.msgid.link/20260729110057.342447-8-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-30ASoC: Intel: catpt: Streamline wording of offset variablesCezary Rojewski1-26/+22
Two words represent is currently: 'offset' and 'off'. Be cohesive and use one instead. Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://patch.msgid.link/20260729110057.342447-7-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-30ASoC: Intel: catpt: Rename firmware loading functionsCezary Rojewski1-16/+16
To make the firmware loading proceduce easier to understand, especially around restoring DRAM context, rename the following: catpt_load_images -> catpt_request_dma_load_firmware catpt_load_image -> catpt_request_load_firmware catpt_restore_fwimage -> catpt_restore_dram_rodata catpt_restore_memdumps -> catpt_restore_dram_data catpt_store_memdumps -> catpt_store_dram_data For the exact same reason, update a number of comments related to the subject. Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://patch.msgid.link/20260729110057.342447-6-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-30ASoC: Intel: catpt: Rename module header structCezary Rojewski1-8/+8
Goal is to match the name of its equivalent on the firmware side. Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://patch.msgid.link/20260729110057.342447-5-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-30ASoC: Intel: catpt: Drop redundant signature argumentCezary Rojewski1-5/+3
Initial design assumed the mechanism could be reused for loading external modules with signatures differing from the Intel's constant. No users with such characteristics ever appeared rendering the 'signature' argument useless. Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://patch.msgid.link/20260729110057.342447-4-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-30ASoC: Intel: catpt: Drop redundant else-ifCezary Rojewski1-2/+2
If the preceding if-statement ends with return, there is no need for else-if. Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://patch.msgid.link/20260729110057.342447-3-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-30ASoC: Intel: catpt: Wrap the store firmware-context procedureCezary Rojewski3-36/+40
All store/restore firmware operations are located in the loader.c file. All except the "store firmware context" procedure which is manually called during the runtime suspend, device.c file. Adding a wrapper alters functional flow slightly - DMA channel is requested after the DXSTATE IPC rather than before it but this has no real impact on the procedure. At the same time, such approach limits number of symbols exposed in the core.h file and improves code cohesiveness: all catpt_dma_xxx() definitions in dsp.c, all their usages in loader.c. Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://patch.msgid.link/20260729110057.342447-2-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-30clk: qcom: Drop inclusions of <linux/mod_devicetable.h>Uwe Kleine-König (The Capable Hub)4-4/+0
The only used symbol in these four drivers that is provided by <linux/mod_devicetable.h> is of_device_id and this is also provided by <linux/platform_device.h>. So drop the unneeded include which brings us one step closer to removing <linux/mod_devicetable.h>. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Reviewed-by: Brian Masney <bmasney@redhat.com> Link: https://lore.kernel.org/r/7b6441aa3b0dba35112ea486bfea3b3171d8527b.1784225976.git.ukleinek@kernel.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30drm/bridge: ps8640: propagate AUX transfer register errorsPengpeng Hou1-6/+21
ps8640_aux_transfer_msg() programs the AUX address registers, starts the AUX transfer, waits for SWAUX_SEND to clear, and reads the AUX status register. Several of those regmap operations have return values, but the function only checks a stale ret after the status read. Propagate failures from the address write, transfer start, completion poll, and status read. This avoids returning a transfer length when the bridge register transaction or AUX completion wait failed. Fixes: 13afcdd7277e ("drm/bridge: parade-ps8640: Add support for AUX channel") Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20260723103509.2-ps8640-v2-pengpeng@iscas.ac.cn
2026-07-30clk: qcom: gcc-mdm9607: Drop redundant register update during probeStephan Gerhold1-10/+1
GPLL0 is pretty much guaranteed to be already on (and voted) during boot, since it's used by the CPU and also various other components such as UART. We also vote for this bit in the actual GPLL0 definition, which will be set as soon as any driver in the kernel requires using the GPLL0 clock. All in all, this makes separately voting for GPLL0 during probe redundant, especially because the "acpuclock" in the comment is a downstream construct that does not exist in upstream. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-12-745565101869@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30dt-bindings: clock: qcom: gcc-mdm9607: Use proper address in exampleStephan Gerhold1-2/+2
Given that this is a dedicated schema for qcom,gcc-mdm9607, we might as well use the correct memory addresses in the example. This does not affect the validation itself, but will reduce confusion for readers. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-11-745565101869@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30dt-bindings: clock: qcom: gcc-mdm9607: Add missing "clocks" propertyStephan Gerhold1-0/+14
gcc-mdm9607.c uses "fw_name", so it requires specifying the "xo" and "sleep_clk" clock source in the device tree. For some reason, this was never documented in the dt-bindings. Nowadays, qcom,gcc-mdm9607 has a dedicated schema, so we can just add it to the properties without any additional conditionals. Fixes: 6faa7e4ddce6 ("dt-bindings: clock: Add MDM9607 GCC clock bindings") Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-10-745565101869@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30dt-bindings: clock: qcom: gcc-mdm9607: Drop SYSTEM_NOC_BFDCD_CLK_SRCStephan Gerhold1-1/+0
This clock does not exist in the hardware, it has no consumers and reading/writing to the registers fails. Drop it from the bindings. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-9-745565101869@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: gcc-mdm9607: Drop incorrect BIMC PLL and related clocksStephan Gerhold1-124/+1
The gcc-mdm9607 driver was originally based on gcc-msm8916, but a closer match nowadays is gcc-msm8909. Looking at the differences between gcc-mdm9607 and gcc-msm8909, there is quite some confusion around the definitions for the BIMC PLL. It turns out the BIMC PLL on MDM9607 is actually an Alpha PLL just like on MSM8909. We can vote for it using BIT(2), which explains why BIT(3) was used for GPLL2. In practice, the BIMC PLL is exclusively controlled by the RPM firmware and Linux should not touch it. So far, it was defined to model the full clock hierarchy, but even in read-only mode with CLK_GET_RATE_NOCACHE this is problematic since the RPM will silently change the clock parents without notifying Linux about it. The clock framework reads the clock parent only once during boot, so the resulting rates will still be often wrong. Follow the example of more recent SoCs and drop the BIMC PLL and all remaining related clocks to avoid reporting stale status data. This means we cannot determine the rate of these clocks anymore. This is not a big problem in practice, since these are NoC-related clocks that are independently managed through the interconnect subsystem. Cc: stable@vger.kernel.org Fixes: 48b7253264ea ("clk: qcom: Add MDM9607 GCC driver") Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-8-745565101869@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: gcc-mdm9607: Drop incorrect system_noc_bfdcd_clk_srcStephan Gerhold1-13/+0
This clock does not exist on MDM9607. Reading/writing the registers always results in 0. Presumably, this definition was mistakenly copied from gcc-msm8916. On MSM8916, this root clock is used for multimedia subsystems (camera, display, video). MDM9607 has none of that, so this clock was probably omitted in the hardware. There are no users inside gcc-mdm9607, so we can just drop it. Cc: stable@vger.kernel.org Fixes: 48b7253264ea ("clk: qcom: Add MDM9607 GCC driver") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-7-745565101869@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: gcc-mdm9607: Drop incorrect apss_tcu_clk_srcStephan Gerhold1-35/+0
This clock does not exist on the specified address on MDM9607. Reading/writing the registers always results in 0 or crashes. The math in the frequency table is also broken. GPLL2 on MDM9607 runs at 480 MHz, so: - F(155000000, P_GPLL2, 6, 0, 0), // 480 MHz/6 = 80 MHz, not 155 MHz - F(310000000, P_GPLL2, 3, 0, 0), // 480 MHz/3 = 160 MHz, not 310 MHz Presumably, this definition was mistakenly copied as-is from gcc-msm8916 (which uses 930 MHz for GPLL2). There are no branch consumers of this root clock inside gcc-mdm9607 (notably, gcc_apss_tcu_clk has bimc_ddr_clk_src as parent instead of this clock), so we can just drop it. It seems like this clock does exist on this SoC on a different address, but since there is no user and reference code for it, it is still better to drop it. Cc: stable@vger.kernel.org Fixes: 48b7253264ea ("clk: qcom: Add MDM9607 GCC driver") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-6-745565101869@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: gcc-mdm9607: Increase delay for USB PHY resetStephan Gerhold1-1/+1
To conform to the specifications of the USB PHY, the reset signal should be asserted for at least 10us. Guarantee that by increasing the delay for the USB2_HS_PHY_ONLY_BCR reset control similar to commit dcc6c9fb7128 ("clk: qcom: gcc-msm8909: Increase delay for USB PHY reset"). Cc: stable@vger.kernel.org Fixes: 48b7253264ea ("clk: qcom: Add MDM9607 GCC driver") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-5-745565101869@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: gcc-mdm9607: Fix halt_reg for gcc_apss_axi_clkStephan Gerhold1-1/+1
gcc_apss_axi_clk specifies a halt_reg of 0x4601c, but this is already used by gcc_apss_ahb_clk. The correct value according to the downstream driver is 0x46020. Cc: stable@vger.kernel.org Fixes: 48b7253264ea ("clk: qcom: Add MDM9607 GCC driver") Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-4-745565101869@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: gcc-mdm9607: Fix enable_reg for gcc_blsp1_sleep_clkStephan Gerhold1-2/+3
MDM9607 is similar to MSM8909, where the GCC_BLSP1_SLEEP_CBCR register is read-only and only has the CLK_OFF bit to check if the clock is running. This is a shared vote clock, the correct way to enable it is to vote for BLSP1_SLEEP_CLK_ENA (BIT(9)) in GCC_APCS_CLOCK_BRANCH_ENA_VOTE (0x45004). Cc: stable@vger.kernel.org Fixes: 48b7253264ea ("clk: qcom: Add MDM9607 GCC driver") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-3-745565101869@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: gcc-msm8939: Fix enable_reg for gcc_blsp1_sleep_clkStephan Gerhold1-2/+3
MSM8939 is similar to MSM8916, where the GCC_BLSP1_SLEEP_CBCR register is read-only and only has the CLK_OFF bit to check if the clock is running. This is a shared vote clock, the correct way to enable it is to vote for BLSP1_SLEEP_CLK_ENA (BIT(9)) in GCC_APCS_CLOCK_BRANCH_ENA_VOTE (0x45004). Cc: stable@vger.kernel.org Fixes: 1664014e4679 ("clk: qcom: gcc-msm8939: Add MSM8939 Generic Clock Controller") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-2-745565101869@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: gcc-msm8916: Fix enable_reg for gcc_blsp1_sleep_clkStephan Gerhold1-2/+3
According to the APQ8016E TRM, the GCC_BLSP1_SLEEP_CBCR register is read-only and only has the CLK_OFF bit to check if the clock is running. This is a shared vote clock, the correct way to enable it is to vote for BLSP1_SLEEP_CLK_ENA (BIT(9)) in GCC_APCS_CLOCK_BRANCH_ENA_VOTE (0x45004). Cc: stable@vger.kernel.org Fixes: 3966fab8b6ab ("clk: qcom: Add MSM8916 Global Clock Controller support") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-1-745565101869@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30drm/bridge: ti-sn65dsi86: Remove redundant dev_err_probe()Pan Chuang1-1/+1
Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in devm_request_*_irq()"), devm_request_threaded_irq() automatically logs detailed error messages on failure. Remove the now-redundant driver-specific dev_err_probe() call. Signed-off-by: Pan Chuang <panchuang@vivo.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20260723131649.134127-11-panchuang@vivo.com
2026-07-30arm64: dts: qcom: sc8280xp-crd: Fix the pin index for misc_3p3_reg_enKonrad Dybcio1-2/+2
The correct pin is GPIO1. Fix it. Fixes: ccd3517faf18 ("arm64: dts: qcom: sc8280xp: Add reference device") Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260701-topic-8280crd_fixups-v1-2-3fe92ee9636b@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: sc8280xp-crd: Add pmic-glink orientation GPIOsKonrad Dybcio1-0/+2
The PMIC_GLINK USB-C setup on SC8280XP requires that an orientation GPIO is passed for each port, the value of which communicates the normal/reversed state of the plug. Add the missing references to let the OS access that information. Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260701-topic-8280crd_fixups-v1-1-3fe92ee9636b@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30soc: qcom: geni-se: Use HW PROG_RAM_DEPTH to validate firmware sizeViken Dadhaniya2-11/+17
The hardcoded MAX_GENI_CFG_RAMn_CNT limit is not accurate for all SoCs: some targets have less CFG RAM than the constant implies, while others like QCS615 need more entries than the old limit of 455 allowed, causing valid firmware to be rejected at load time. Rather than hardcoding a constant, read PROG_RAM_DEPTH from SE_HW_PARAM_2 at runtime to get the actual CFG RAM depth of the hardware instance and use that as the upper bound for firmware size validation. Fixes: d4bf06592ad6 ("soc: qcom: geni-se: Add support to load QUP SE Firmware via Linux subsystem") Cc: stable@vger.kernel.org Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260702-qup-se-increase-ram-cnt-v3-1-80b363373a5b@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: Rename pci@ nodes to pcie@Konrad Dybcio9-23/+23
PCIe hosts/devices commonly use the 'pcie' for their node name to reflect they're not legacy PCI. Every couple months someone comes around to clean this up because people keep introducing new uses of 'pci@'. Seems like it's my turn now, so do that for RCs and the downstream devices (switches etc.) defined in board files. Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260701-topic-dts_pci_pcie-v1-1-aab8de213b39@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: glymur-crd: Add FocalTech ft3d81 touchscreen supportPradyot Kumar Nayak1-4/+3
The touchscreen module on Glymur/Mahua CRDs is different from the one used on Hamoa CRDs and requires the reset-gpios to be wired to the device. Without this in place the reset line will remain permanently asserted during resume leaving the device offline and causing all I2C transactions to fail with -ENXIO. i2c_hid_of 3-0038: failed to change power setting. i2c_hid_of 3-0038: PM: dpm_run_callback(): i2c_hid_core_pm_resume [i2c_hid] returns -6 i2c_hid_of 3-0038: PM: failed to resume async: error -6 The touchscreen on Glymur/Mahua-CRD is a focaltech ft3d81, which is hardware-compatible with the ft8112. we have added the required change in DT. Fixes: e6bf559f7eb9 ("arm64: dts: qcom: glymur-crd: Enable keyboard, trackpad and touchscreen") Fixes: f64ef325f1d9 ("arm64: dts: glymur-crd: Add reset GPIO to touchscreen node") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Pradyot Kumar Nayak <pradyot.nayak@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260717-add_focaltech_ft3d81_touchscreen_support-v4-2-5dd091e25801@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30rust: driver: remove duplicate ID tableGary Guo1-49/+27
Previously, `IdArray` contains both device ID table and info table so we keep a separate copy for MODULE_DEVICE_TABLE for hotplug (which needs to be just the device ID table). With the info being changed to be carried via pointers, `IdArray` is now layout compatible with raw ID table and hence there is no longer a need to keep the distinction. Deduplicate the code, and remove the redundant copy for hotplug purpose by just giving the `IdArray` instance a proper symbol name. While at it, also update the macro to use `::core::line!()` instead of just `line!()`. Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/20260629-id_info-v2-10-56fccbe9c5ef@garyguo.net Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-07-30rust: driver: remove open-coded matching logicGary Guo9-161/+21
With device ID info now including pointers instead of indices, the open-coded ACPI/OF matching is no longer needed and can be replaced with `device_get_match_data`. With the removal of open-coded matching, the exposed functions and helpers are also removed; this effectively reverts most of commit 2690d071584e ("rust: ACPI: fix missing match data for PRP0001"). Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/20260629-id_info-v2-9-56fccbe9c5ef@garyguo.net [ Consider the serdev code merged in the meantime. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-07-30rust: driver: store pointers in `DeviceId`Gary Guo8-71/+77
The common practice in C drivers is to store pointers into `driver_data` field of device IDs. The Rust code is however currently storing indices into the fields and then carry a side table that maps the index to pointers. It is much simpler to just have `DeviceId` carry the pointer like C code does. However, just doing so naively would cause a "pointers cannot be cast to integers during const eval" error, as kernel_ulong_t does not have provenance while pointers do, and Rust forbids `expose_provenance` during consteval. Work around this limitation by wrapping raw IDs in `MaybeUninit`. `MaybeUninit` is allowed to host arbitrary bytes with or without provenance, so we can just then use `unsafe` to store a pointer with provenance there. This has the same effect as changing the C-side definition to use `void*` instead of `kernel_ulong_t`, but without actually changing the C side. Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/20260629-id_info-v2-8-56fccbe9c5ef@garyguo.net Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-07-30rust: driver: remove `$module_table_name` from `module_device_table`Gary Guo22-46/+17
Wrap the generated code in a `const _: ()` block to avoid symbol conflict. This removes the need of creating a new identifier. Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/20260629-id_info-v2-7-56fccbe9c5ef@garyguo.net [ Consider the serdev code merged in the meantime. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-07-30rust: driver: centralize device ID handlingGary Guo8-55/+46
Move the `IdArray` creation from individual buses to be handled by shared code in `device_id.rs`. Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/20260629-id_info-v2-6-56fccbe9c5ef@garyguo.net Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-07-30soc: qcom: pmic_glink_altmode: Define the TBT extradata properlyKonrad Dybcio1-1/+2
Before the fixes-referenced commit, there was a trailing 'u32 reserved' after the payload array. That commit gobbled it up into the thunderbolt extradata. Push it back where it belongs. There's no functional change, since the outer struct size remains identical - struct usbc_sc8280x_tbt_data and therefore the union it's a part of made up for the difference and the res bytes were ignored anyway. Fixes: 0539c5a6fdef ("soc: qcom: pmic_glink_altmode: Consume TBT3/USB4 mode notifications") Reported-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260717-topic-tbt_extradata_fixup-v1-1-5caa18f1c8d3@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30dt-bindings: soc: qcom,wcnss: Drop redundant $ref of firmware-name propertyKrzysztof Kozlowski1-2/+2
The DT schema core defines the type ($ref) of 'firmware-name' property as string-array, so individual schemas do not need to. They also should not redefine it to a single string, but instead just set number of expected firmware names. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20260712162212.184592-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: gcc-shikra: Add additional frequencies for EMAC RGMII clocksImran Shaik1-0/+2
Add support for 2.5MHz and 25MHz GCC EMAC RGMII clock frequencies required for EMAC 10M and 100M speeds respectively on Qualcomm Shikra SoC. Tested-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260722-b4-shikra-gcc-emac-freqs-v2-1-2e480e2de8de@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: Update spmi-pmic-arb interrupt trigger for shikraRakesh Kota1-1/+1
SPMI interrupts are not working after suspend/resume on Shikra. Update the spmi-pmic-arb top-level interrupt trigger type from IRQ_TYPE_EDGE_RISING to IRQ_TYPE_LEVEL_HIGH, as recommended by the hardware design team. Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260722-fix_shikra_spmi_interrupt_trigger_type-v1-1-1f8a13528cd7@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30io_uring: preserve task restrictions across execKyumin Lee3-2/+8
Per-task restrictions apply to all rings created by a task. Once installed, they should not be dropped across exec. For a task that has used io_uring, the exec cancellation path calls __io_uring_free(). This frees both the task context and the per-task restriction, so a ring created after exec is unrestricted. Split task context cleanup into io_uring_free_tctx(), and use it from the exec cancellation path. Keep __io_uring_free() for final task cleanup, where both the context and restriction are released. Fixes: ed82f35b926b ("io_uring: allow registration of per-task restrictions") Cc: stable@vger.kernel.org # 7.1+ Signed-off-by: Kyumin Lee <fyonglkm@gmail.com> Link: https://patch.msgid.link/20260730192734.459247-1-fyonglkm@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-07-30clk: qcom: gcc-qcm2290: don't park QUP RCGs upon registrationDmitry Baryshkov1-6/+6
The gcc_qupv3_wrap0_s[0-5]_clk_src RCGs feed the QUP serial engines (UART/I2C/SPI). Since shared RCGs are parked to XO at registration time, binding the gcc-qcm2290 driver reprograms these clocks away from the rate configured by the bootloader. For the UART used as the boot console this drops early console output until the serial driver later reconfigures the clock. Switch the QUP wrap0 clock sources over to clk_rcg2_shared_no_init_park_ops so their frequency is left unchanged at registration time, keeping the bootloader-configured console working across the gcc driver probe. Fixes: 01a0a6cc8cfd ("clk: qcom: Park shared RCGs upon registration") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260722-agatti-no-park-v1-1-31ae3a4774e5@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: qcs404: Fix DTBS Check errors in usb controller nodesKrishna Kurapati1-8/+8
The following errors pop up when DTBS check is done for qcs404 based platforms: arch/arm64/boot/dts/qcom/qcs404-evb-4000.dtb: usb@79b8800 (qcom,qcs404- dwc3): interrupt-names:1: 'qusb2_phy' was expected from schema $id: http://devicetree.org/schemas/usb/qcom,dwc3.yaml arch/arm64/boot/dts/qcom/qcs404-evb-4000.dtb: usb@79b8800 (qcom,qcs404- dwc3): interrupt-names:2: 'hs_phy_irq' was expected from schema $id: http://devicetree.org/schemas/usb/qcom,dwc3.yaml arch/arm64/boot/dts/qcom/qcs404-evb-4000.dtb: usb@7678800 (qcom,qcs404- dwc3): interrupt-names:2: 'hs_phy_irq' was expected from schema $id: http://devicetree.org/schemas/usb/qcom,dwc3.yaml arch/arm64/boot/dts/qcom/qcs404-evb-4000.dtb: usb@7678800 (qcom,qcs404- dwc3): interrupt-names:1: 'qusb2_phy' was expected from schema $id: http://devicetree.org/schemas/usb/qcom,dwc3.yaml Modify ordering of hs_phy and qusb2_phy interrupts to fix the errors. Fixes: 927173bf8a0e ("arm64: dts: qcom: Add missing interrupts for qcs404/ipq5332") Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260723-qcs404_dtbs_fix-v1-1-c9ca0dd69f23@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30selinux: reject a class permission count below its inherited commonBryam Vargas1-0/+12
security_get_permissions() maps an inherited common's permissions into an array sized by the class's own permissions.nprim, but class_read() takes that nprim verbatim from the policy image and never checks that it covers the common. A class that inherits a common of N permissions while declaring a smaller nprim is accepted, and on load the common's permissions are written past the class-sized array -- an out-of-bounds heap write. Reject a class whose permission count is below its inherited common's. Well-formed policies, where the class count already includes the inherited permissions, are unaffected. Cc: stable@vger.kernel.org Fixes: 55fcf09b3fe4 ("selinux: add support for querying object classes and permissions from the running policy") Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
2026-07-30selinux: reject a permission value exceeding the class permission countBryam Vargas1-0/+3
perm_read() bounds a permission value by SEL_VEC_MAX but never by the nprim of the owning class or common, which is taken verbatim from the policy image. security_get_permissions() then writes perms[value - 1] into an nprim-sized kcalloc() array, so a class declaring fewer permissions than its largest permission value drives an out-of-bounds heap write. The top-level symbol tables are validated this way; the nested per-class permission table is not. Reject a permission whose value exceeds nprim, which is already set when perm_read() runs. Well-formed policies are unaffected. Cc: stable@vger.kernel.org Fixes: 55fcf09b3fe4 ("selinux: add support for querying object classes and permissions from the running policy") Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com> [PM: tweak comment for line length] Signed-off-by: Paul Moore <paul@paul-moore.com>
2026-07-30drm/i915/hdmi: Poll for 200 msec for TMDS_Scrambler_StatusJerome Tollet3-0/+30
HDMI 2.0 section 6.1.3.1 specifies that after enabling Scrambling_Enable and starting scrambled video transmission, the source should poll Scrambling_Status until it reads 1 or until a timeout of 200 ms expires. Add a polling step after enabling the HDMI port to check the scrambling status when HDMI scrambling is enabled. On some HDMI 2.0 sinks, omitting this check can result in 4K@60Hz (594 MHz) failing to come up correctly because the sink has not yet finished its scrambling setup. In practice, waiting for the scrambling status here fixes such sinks. While this synchronous polling is not itself explicitly required for correct modeset sequencing, HDMI 2.0 section 6.1.3.1 does recommend it as the way for the source to verify that the TMDS link is functioning correctly with scrambling enabled. v3: - Add explicit HDMI 2.0 section reference in code comment - Clarify commit message around the observed sink fix v2: - Poll TMDS_Scrambler_Status for up to 200 ms instead of using a fixed delay Reported-by: Jerome Tollet <jtollet@cisco.com> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6868 Link: https://lore.kernel.org/dri-devel/20251230091037.5603-1-jerome.tollet@gmail.com/ Signed-off-by: Jerome Tollet <jerome.tollet@gmail.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Link: https://patch.msgid.link/20260520022544.3097252-1-ankit.k.nautiyal@intel.com (cherry picked from commit b7d51d65e4f12a48392d260613108ec262bc7774) Fixes: 15953637886d ("drm/i915: enable scrambling") Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
generated by cgit (git 2.54.0.dirty) at 2026-09-30 09:31:29 +0000