summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2026-07-30soc: qcom: qcom_stats: Replace CLIENT_VOTES_OFFSET macro with sizeof()Maulik Shah1-3/+1
CLIENT_VOTES_OFFSET (0x20) equals sizeof(struct sleep_stats), since appended_stats immediately follows sleep_stats in the memory layout. Replace the magic constant with sizeof(struct sleep_stats) to make the layout relationship self-documenting and drop the macro. No functional impact. Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-b4b4-removed-unused-macros-v1-2-2883fecb9e6e@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30soc: qcom: qcom_stats: Remove unused macro definitionsMaulik Shah1-5/+0
Remove macros that are defined but never used, as identified by -Wunused-macros: STAT_TYPE_OFFSET, COUNT_OFFSET, LAST_ENTERED_AT_OFFSET, LAST_EXITED_AT_OFFSET, ACCUMULATED_OFFSET No functional impact. Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-b4b4-removed-unused-macros-v1-1-2883fecb9e6e@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30soc: qcom: ubwc: Get HBB from SMEMKonrad Dybcio1-1/+39
To make sure the correct settings for a given DRAM configuration get applied, attempt to retrieve that data from SMEM (which happens to be what the BSP kernel does, albeit with through convoluted means of the bootloader altering the DT with this data). Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260727-topic-smem_dramc-v5-3-66188b3e338d@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30soc: qcom: smem: Expose DDR data from SMEMKonrad Dybcio4-22/+483
Most modern Qualcomm platforms (>= SM8150) expose information about the DDR memory present on the system via SMEM. Details from this information is used in various scenarios, such as multimedia drivers configuring the hardware based on the "Highest Bank address Bit" (hbb), or the list of valid frequencies in validation scenarios... Add support for parsing v3-v7 version of the structs. Unforunately, they are not versioned, so some elbow grease is necessary to determine which one is present. See for reference: ver 3: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/1d11897d2cfcc7b85f28ff74c445018dbbecac7a ver 4: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/f6e9aa549260bbc0bdcb156c2b05f48dc5963203 ver 5: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/617d3297abe8b1b8dd3de3d1dd69c3961e6f343f ver 5 with 6regions: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/d770e009f9bae58d56d926f7490bbfb45af8341f ver 6: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/62659b557fdb1551b20fae8073d1d701dfa8a62e ver 7: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/734d95599c5ebb1ca0d4e1639142e65c590532b7 Reviewed-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/1d11897d2cfcc7b85f28ff74c445018dbbecac7a Link: https://lore.kernel.org/r/20260727-topic-smem_dramc-v5-2-66188b3e338d@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-31power: supply: sc2731_charger: cancel work on removeHongyan Xu1-0/+2
The USB notifier and initial charger detection can schedule info->work. The remove path unregisters the notifier, but does not cancel queued or running work before the devm-allocated driver data is released. Set the platform drvdata used by remove, then cancel the work after unregistering the notifier. This issue was found by a static analysis tool. Fixes: 8ac1091ed18b ("power: supply: sc2731_charger: Add one work to charge/discharge") Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com> Signed-off-by: Hongyan Xu <getshell@seu.edu.cn> Link: https://patch.msgid.link/5d48b827687168cb1b1bfe85f17945566b42829d.1785321763.git.getshell@seu.edu.cn Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-07-31power: supply: isp1704_charger: cancel work on removeHongyan Xu1-0/+1
The USB notifier and initial VBUS detection can schedule isp->work. The remove path unregisters the notifier and power supply, but does not wait for queued or running work before tearing down the power supply state. Cancel the work after unregistering the notifier. Do this before unregistering the power supply. This issue was found by a static analysis tool. Signed-off-by: Hongyan Xu <getshell@seu.edu.cn> Link: https://patch.msgid.link/20260728123423.781-5-getshell@seu.edu.cn Fixes: ec46475f3e31 ("power_supply: Add isp1704 charger detection driver") Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-07-30zloop: set dma_alignment from the backing files for direct I/OKeith Busch1-10/+25
Direct I/O request's use pages handed to the backing files unchanged, so the backing's DMA alignment requirement applies. Track dio_mem_align and advertise it as the device's dma_alignment so we communicate proper limits and misaligned I/O is rejected here instead of reaching the backend. Reviewed-by: Hannes Reinecke <hare@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org> Link: https://patch.msgid.link/20260720201057.1862857-5-kbusch@meta.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-07-30loop: set dma_alignment from the backing file for direct I/OKeith Busch1-8/+38
Direct I/O user pages are forwarded to the backing file unchanged, so the backing's DMA alignment requirement applies to them. Track the backing's dio_mem_align and advertise it as the loop device's dma_alignment so we advertise proper limits and misaligned I/O is rejected here instead of being dispatched to the backend. Reviewed-by: Hannes Reinecke <hare@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org> Link: https://patch.msgid.link/20260720201057.1862857-4-kbusch@meta.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-07-30power: supply: bq25630: Initialize hardware before exposing the power supplyLinmao Li1-7/+5
bq25630_setup() resets the device, disables the watchdog and programs the charge limits from the battery information. It runs at the end of bq25630_probe(), that is after the power supply has been registered, so the device is already exposed to the system while the hardware still holds its power-on defaults. power_supply_desc::init runs during registration, after the driver data and the fwnode are available and before the device is added. Use it for bq25630_setup() and drop the explicit call from bq25630_probe(). The callback is passed the power supply, so take the driver data from it and use it for the battery information as well: data->psy is only assigned once devm_power_supply_register() returns, which is after the callback has run. Signed-off-by: Linmao Li <lilinmao@kylinos.cn> Reviewed-by: Waqar Hameed <waqar.hameed@axis.com> Link: https://patch.msgid.link/20260730011713.3332913-3-lilinmao@kylinos.cn Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-07-30power: supply: bq25630: Scope battery information to bq25630_setup()Linmao Li1-22/+26
data->batinfo is only used by bq25630_setup() to program the initial charge limits, but power_supply_get_battery_info() allocates it on psy->dev, so it stays around for the lifetime of the device. Nothing else in the driver uses it. Get the battery information in bq25630_setup(), just before it is read, and release it on every path out of that function. The driver data no longer has to carry the pointer. Signed-off-by: Linmao Li <lilinmao@kylinos.cn> Reviewed-by: Waqar Hameed <waqar.hameed@axis.com> Link: https://patch.msgid.link/20260730011713.3332913-2-lilinmao@kylinos.cn Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-07-30clk: qcom: gcc-hawi: Add support for global clock controller on MailiTaniya Das1-0/+201
Add support for the global clock controller (GCC) on the Qualcomm Maili SoC by extending the Hawi global clock controller since Maili is identical to Hawi and has few additional clocks. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-maili_initial_clock-v4-4-ed52ade264f0@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-31md/raid10: free r10bio before ending master_bio in raid_end_bio_io() and ↵Chen Cheng1-4/+10
raid_end_discard_bio() origin flow: bio_endio(master_bio); /* may drop active_io to zero */ allow_barrier(conf); free_r10bio(r10_bio); /* reads conf->geo, returns to pool */ one scenario is: CPU A (softirq, raid_end_bio_io) CPU B (action_store) --> reshape ================================ =============================== bio_endio(master_bio) md_end_clone_io percpu_ref_put -> 0 wait_event wakeup, and, mddev_suspend return raid10_start_reshape: setup_geo(&conf->geo, new) ... mempool_destroy(old_pool) conf->r10bio_pool = new_pool allow_barrier(conf) free_r10bio(r10_bio) put_all_bios: for (i=0; i<conf->geo.raid_disks; i++) ==> old obj, new geo, OOB mempool_free(r10_bio, conf->r10bio_pool) ==> old-geometry obj freed into new pool so .. fix by reorder the flow: free_r10bio(r10_bio) bio_endio(master_bio) allow_barrier(conf) raid_end_discard_bio() is exactly the same. Signed-off-by: Chen Cheng <chencheng@fnnas.com> Link: https://patch.msgid.link/20260711100352.425177-4-chencheng@fnnas.com Signed-off-by: Yu Kuai <yukuai@fygo.io>
2026-07-31md/raid10: resize r10bio_pool for reshapeChen Cheng2-14/+34
When reshape grows raid_disks, the pool must also switch to new geometry object size , and allocate a new geometry size pool and replace the old. But not for shrinking reshape, because regular I/O can still use the prev geo for sectors that have not crossed reshape_progress yet. Signed-off-by: Chen Cheng <chencheng@fnnas.com> Link: https://patch.msgid.link/20260711100352.425177-3-chencheng@fnnas.com Signed-off-by: Yu Kuai <yukuai@fygo.io>
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-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-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-30soc: qcom: geni-se: Use HW PROG_RAM_DEPTH to validate firmware sizeViken Dadhaniya1-11/+13
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-30rust: driver: remove open-coded matching logicGary Guo1-3/+3
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: remove `$module_table_name` from `module_device_table`Gary Guo5-5/+0
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-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-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-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-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>
2026-07-30Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski179-1144/+2411
Cross-merge networking fixes after downstream PR (net-7.2-rc6). No conflicts. Adjacent changes: net/ipv4/route.c dbc3791e3b24 ("net: do not send ICMP/NDISC Redirects when peer allocation fails") 7804eaa057fe ("ipv4: snapshot dst.dev in ip_rt_send_redirect() and ip_rt_get_source()") drivers/net/tun.c 23dad2d088df ("tun: no longer rely on RTNL in tun_fill_info()") c3da92af07ea ("Revert "tun/tap: add ptr_ring consume helper with netdev queue wakeup"") drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c 3bd438a58e91 ("octeontx2-af: Block VFs from clobbering special CGX PKIND state") 5ba5611ef946 ("octeontx2-af: reserve 4 PKINDs for skip-size custom use") drivers/net/wireless/ath/ath12k/core.h drivers/net/wireless/ath/ath12k/mac.c drivers/net/wireless/ath/ath12k/peer.c 469d7e6077c1 ("wifi: ath12k: resolve PENDING ML peer ID from MLO_PEER_MAP HTT event") 378e659029d5 ("wifi: ath12k: introduce host_alloc_ml_id hardware parameter") c42b27336eef ("wifi: ath12k: fix survey indexing across bands") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30HID: bpf: Make syscall kfunc flags match the struct_ops setIhor Solodrai1-5/+5
Update kfunc flags for hid_bpf_syscall_kfunc_ids set to exactly match hid_bpf_kfunc_ids set by adding KF_SLEEPABLE flag. The syscall set omitted the flag because syscall programs are always sleepable (the verifier rejects a non-sleepable syscall program). However the upcoming resolve_btfids change enforces per-kfunc flag consistency across BTF ID sets at build time, which is why this change is necessary. Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Reviewed-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/bpf/20260722233518.778854-7-ihor.solodrai@linux.dev
2026-07-31md: widen badblock sectors param from int to sector_tHiroshi Nishida2-5/+5
The badblocks core API -- badblocks_set(), badblocks_clear() and badblocks_check() -- and the is_badblock() helper all take the range length as sector_t. The md wrappers rdev_set_badblocks(), rdev_clear_badblocks() and rdev_has_badblock(), however, declared the same length as int, narrowing sector_t to int and back again in the middle of an otherwise 64-bit clean path. Change the sectors parameter to sector_t in these three wrappers so it matches the core API and is_badblock(). No functional change: current callers pass per-I/O or per-resync-chunk lengths well within int range. This just removes a gratuitous truncation point and keeps the type consistent end to end. Signed-off-by: Hiroshi Nishida <nishidafmly@gmail.com> Link: https://patch.msgid.link/20260710132329.7273-3-nishidafmly@gmail.com Signed-off-by: Yu Kuai <yukuai@fygo.io>
2026-07-30Merge tag 'pm-7.2-rc6' of ↵Linus Torvalds4-19/+52
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fixes from Rafael Wysocki: "These fix issues related to cpufreq, in the ACPI CPPC library and the generic CPPC cpufreq driver, in the powernow-k8 and amd-pstate drivers, and in the schedutil governor: - Allow fast frequency switching in the ACPI CPPC library only when every supported control used by the driver callback has an address space already accepted for fast access (Christian Loehle) - Skip writes to unsupported performance controls in the ACPI CPPC library (Christian Loehle) - Update cppc_cpufreq_update_perf_limits() to read policy->min and policy->max once and, if the lockless snapshot is inconsistent, reduce the minimum to the observed maximum, along the lines of cpufreq_driver_resolve_freq() (Christian Loehle) - Fix a possible memory leak in the powernowk8_cpu_init() error paths (Abdun Nihaal) - Loosen the requirement on lowest nonlinear frequency != min freq in the amd-pstate driver that is too tight for new systems some of which actually have the lowest nonlinear frequency identical to the minimum frequency (Mario Limonciello) - Prevent amd-pstate from loading on unsupported hardware (Rong Zhang) - Address an initialization race in the schedutil governor when it runs on multi-CPU cpufreq policies, by making it initialize all per-CPU structures first and only then publish the per-CPU utilization update hooks (Zhongqiu Han)" * tag 'pm-7.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: cpufreq: powernow-k8: Fix possible memory leak in powernowk8_cpu_init() ACPI: CPPC: Skip writes to unsupported performance controls cpufreq/amd-pstate: Prevent the driver from loading on unsupported hardware cpufreq/amd-pstate: Loosen requirement on lowest nonlinear frequency != min freq cpufreq: schedutil: Publish util hooks only after all sg_cpu are initialized cpufreq: cppc: Sanitize lockless policy limit snapshots ACPI: CPPC: Check all controls for fast switching
2026-07-30spi: ppc4xx: use of_property_read_u32 for clock frequencyRosen Penev1-9/+7
Replace of_get_property with of_property_read_u32 for the "clock-frequency" property, which is the modern typed DT accessor that returns an error code directly and avoids the raw const unsigned int * pointer dance. Also drop the dev_err_probe wrapper on devm_request_irq failure, returning ret directly since the core already logs probe errors. Get rid of irqnum in the private struct. It's only used in _probe. Was used in _remove before devm to free the irq. Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev <rosenp@gmail.com> Link: https://patch.msgid.link/20260728202932.16207-1-rosenp@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-30EDAC/igen6: Add Intel Starfire SoCs supportQiuxu Zhuo1-0/+5
Starfire is a derivative of Panther Lake SoC and shares a similar memory subsystem architecture. Add Starfire compute die ID and reuse Panther Lake's configuration data for EDAC support. Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Tested-by: Jie Wang <jie.wang@intel.com> Link: https://patch.msgid.link/20260730025454.4099934-1-qiuxu.zhuo@intel.com
2026-07-30EDAC/igen6: Refactor address translation logicQiuxu Zhuo1-85/+159
The igen6 EDAC driver implements similar interleave and hash translation logic at multiple levels of the memory hierarchy. The separate implementations duplicate decoding logic, making future changes harder and increasing the risk of behavior diverging. Consolidate the common address translation operations into shared helpers so all decoding paths use a single implementation. No functional changes intended. Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Link: https://patch.msgid.link/20260730024238.4096623-11-qiuxu.zhuo@intel.com
2026-07-30EDAC/igen6: Remove redundant resource configuration tablesQiuxu Zhuo1-47/+19
Several resource configuration tables differ only in their num_imc value, while all other fields are identical. Their only purpose is to describe the number of memory controllers supported by a platform. Since IMC count is now detected at runtime, these duplicate tables no longer carry any unique platform information. Reuse the shared configurations and remove the redundant tables. Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Link: https://patch.msgid.link/20260730024238.4096623-10-qiuxu.zhuo@intel.com
2026-07-30EDAC/igen6: Detect present memory controllers at runtimeQiuxu Zhuo1-32/+63
The igen6_edac currently relies on res_config::num_imc to describe the number of memory controllers supported by each SoC. As a result, adding support for a new platform requires updating this configuration even though the hardware can be discovered at runtime. Instead, detect the number of present memory controllers at runtime and size the driver state accordingly. This eliminates the need to update res_config whenever a new SoC variant is added. Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Link: https://patch.msgid.link/20260730024238.4096623-9-qiuxu.zhuo@intel.com
2026-07-30EDAC/igen6: Simplify compute die ID commentsQiuxu Zhuo1-14/+15
The existing comments repeat information already implied by the code structure. Shorten them to SoC names only to reduce clutter and improve readability. No functional changes intended. Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Link: https://patch.msgid.link/20260730024238.4096623-8-qiuxu.zhuo@intel.com
2026-07-30EDAC/igen6: Remove unnecessary XOR on the zero-valued interleave bitQiuxu Zhuo1-4/+4
When reconstructing the removed interleave bit from an inflated memory slice address, where a zero was inserted at the interleave bit position, it's unnecessary to XOR this zero-valued interleave bit. Remove this unnecessary XOR operation. No functional changes intended. Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Link: https://patch.msgid.link/20260730024238.4096623-7-qiuxu.zhuo@intel.com
2026-07-30EDAC/igen6: Fix Raptor Lake-P logged error addressQiuxu Zhuo1-33/+6
Raptor Lake-P was treated as using a different IBECC (In-Band ECC) error address format and therefore had a dedicated extraction path that shifted the logged address. However, Raptor Lake-P uses the same cache-line-granularity error address format as other IBECC platforms. The special handling causes the logged address to be decoded incorrectly. Fix the issue by removing Raptor Lake-P specific extraction logic and using the common path instead. This also allows reusing Alder Lake resource configuration data. Fixes: d23627a7688f ("EDAC/igen6: Add Intel Raptor Lake-P SoCs support") Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Link: https://patch.msgid.link/20260730024238.4096623-6-qiuxu.zhuo@intel.com
generated by cgit (git 2.54.0.dirty) at 2026-09-29 20:52:08 +0000