summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2025-07-07pwm: sun4i: Drop driver local lockingUwe Kleine-König
The pwm core serializes calls to .apply(), so the driver lock doesn't add any protection and can safely be dropped. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/87b71c46b82b787959f0cea314d3010f16a50a29.1750788649.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: sti: Drop driver local lockingUwe Kleine-König
The pwm core already serializes calls to .apply(), so the driver local mutex adds no protection and can be dropped. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/7ad150e40b45d6cb16fee633dcd6390a49a327a1.1750788649.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: microchip-core: Drop driver local lockingUwe Kleine-König
The pwm core already serializes .apply() and .get_state(), so the driver local lock is always free and adds no protection. Drop it. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/6d6ef0376ea0058b040eec3b257e324493a083f1.1750788649.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: lpc18xx-sct: Drop driver local lockingUwe Kleine-König
Both mutexes are only used in one function each. These functions are only called by the .apply() callback. As the .apply() calls are serialized by the core since commit 1cc2e1faafb3 ("pwm: Add more locking") the mutexes have no effect apart from runtime overhead. Drop them. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Reviewed-by: Vladimir Zapolskiy <vz@mleia.com> Link: https://lore.kernel.org/r/4f7a2da37adbfe4743564245119045826d86eca6.1750788649.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: fsl-ftm: Drop driver local lockingUwe Kleine-König
The pwm core serializes calls to .apply(), so the driver local lock isn't needed for that. It only has the effect to serialize .apply() with .request() and .free() for a different PWM, and .request() and .free against each other. But given that .request and .free() only do a single regmap operation under the lock and regmap itself serializes register accesses, it might happen without the lock that the calls are interleaved now, but affecting different PWMs, so nothing bad can happen. So the mutex has no effect and can be dropped. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/6b72104e5e1823170c7c9664189cc0f2ca5c2347.1750788649.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: clps711x: Drop driver local lockingUwe Kleine-König
The pwm core serializes calls to .apply(), so the spinlock adds no additional protection. Disabling the irq is also irrelevant as the driver isn't an atomic one and so the callbacks cannot be called from atomic context. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/d4931dc0c0d657d80722cfe7d97cb4fb4ccec90e.1750788649.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: atmel: Drop driver local lockingUwe Kleine-König
The two functions making use of the lock are only called transitively from .apply(). Calls to .apply() are already serialized by the pwm core so the lock in the driver has no effect and can safely be dropped. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/5ad3417aecd4dc6eca9699e21691e3725ea0bb87.1750788649.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: argon-fan-hat: Add Argon40 Fan HAT supportMarek Vasut
Add trivial PWM driver for Argon40 Fan HAT, which is a RaspberryPi blower fan hat which can be controlled over I2C. Model this device as a PWM, so the pwm-fan can be attached to it and handle thermal zones and RPM management in a generic manner. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Link: https://lore.kernel.org/r/20250629220757.936212-3-marek.vasut+renesas@mailbox.org Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: pwm-mediatek: Add support for PWM IP V3.0.2 in MT6991/MT8196AngeloGioacchino Del Regno
Add support for the PWM IP version 3.0.2, found in MediaTek's Dimensity 9400 MT6991 and in the MT8196 Chromebook SoC: this needs a new register offset array and also a different offset for the PWM_CK_26M_SEL register. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20250623120118.109170-4-angelogioacchino.delregno@collabora.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: pwm-mediatek: Pass PWM_CK_26M_SEL from platform dataAngeloGioacchino Del Regno
In preparation for adding support for new SoCs, remove variable has_ck_26m_sel from pwm_mediatek_of_data and replace it with a u16 pwm_ck_26m_sel_reg, meant to hold the register offset for PWM_CK_26M_SEL. Also, since the reg offset is guaranteed to never be zero, the logic to check for "has_ck_26m_sel" is changed to check if the register offset in pwm_ck_26m_sel_reg is more than zero. Analogously, when writing, use the register offset from platform data instead of using the PWM_CK_26M_SEL definition. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20250623120118.109170-3-angelogioacchino.delregno@collabora.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: rockchip: Round period/duty down on apply, up on getNicolas Frattaroli
With CONFIG_PWM_DEBUG=y, the rockchip PWM driver produces warnings like this: rockchip-pwm fd8b0010.pwm: .apply is supposed to round down duty_cycle (requested: 23529/50000, applied: 23542/50000) This is because the driver chooses ROUND_CLOSEST for purported idempotency reasons. However, it's possible to keep idempotency while always rounding down in .apply(). Do this by making .get_state() always round up, and making .apply() always round down. This is done with u64 maths, and setting both period and duty to U32_MAX (the biggest the hardware can support) if they would exceed their 32 bits confines. Fixes: 12f9ce4a5198 ("pwm: rockchip: Fix period and duty cycle approximation") Fixes: 1ebb74cf3537 ("pwm: rockchip: Add support for hardware readout") Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Link: https://lore.kernel.org/r/20250616-rockchip-pwm-rounding-fix-v2-1-a9c65acad7b6@collabora.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: stm32: add support for stm32mp25Fabrice Gasnier
Add support for STM32MP25 SoC. Use newly introduced compatible to handle new features along with registers and bits diversity. The MFD part of the driver fills in ipidr, so it is used to check the hardware configuration register, when available to gather the number of PWM channels and complementary outputs. Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Link: https://lore.kernel.org/r/20250110091922.980627-5-fabrice.gasnier@foss.st.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: sophgo-sg2042: Add support for SG2044Longbin Li
Add PWM controller for SG2044 on base of SG2042. Reviewed-by: Chen Wang <unicorn_wang@outlook.com> Tested-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Longbin Li <looong.bin@gmail.com> Link: https://lore.kernel.org/r/20250528101139.28702-4-looong.bin@gmail.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: sophgo-sg2042: Reorganize the code structureLongbin Li
As the driver logic can be used in both SG2042 and SG2044, it will be better to reorganize the code structure. Reviewed-by: Chen Wang <unicorn_wang@outlook.com> Tested-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Longbin Li <looong.bin@gmail.com> Link: https://lore.kernel.org/r/20250528101139.28702-3-looong.bin@gmail.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: sifive: Fix rounding and idempotency issues in apply and get_stateNylon Chen
This fix ensures consistent rounding and avoids mismatches between applied and reported PWM values that could trigger false idempotency failures in debug checks This change ensures: - real_period is now calculated using DIV_ROUND_UP_ULL() to avoid underestimation. - duty_cycle is rounded up to match the fractional computation in apply() - apply() truncates the result to compensate for get_state's rounding up logic These fixes resolve issues like: .apply is supposed to round down duty_cycle (requested: 360/504000, applied: 361/504124) .apply is not idempotent (ena=1 pol=0 1739692/4032985) -> (ena=1 pol=0 1739630/4032985) Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202505080303.dBfU5YMS-lkp@intel.com/ Co-developed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Zong Li <zong.li@sifive.com> Signed-off-by: Nylon Chen <nylon.chen@sifive.com> Link: https://lore.kernel.org/r/20250529035341.51736-4-nylon.chen@sifive.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: sifive: Fix PWM algorithm and clarify inverted compare behaviorNylon Chen
The `frac` variable represents the pulse inactive time, and the result of this algorithm is the pulse active time. Therefore, we must reverse the result. Although the SiFive Reference Manual states "pwms >= pwmcmpX -> HIGH", the hardware behavior is inverted due to a fixed XNOR with 0. As a result, the pwmcmp register actually defines the low (inactive) portion of the pulse. The reference is SiFive FU740-C000 Manual[0] Link: https://sifive.cdn.prismic.io/sifive/1a82e600-1f93-4f41-b2d8-86ed8b16acba_fu740-c000-manual-v1p6.pdf [0] Co-developed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Zong Li <zong.li@sifive.com> Co-developed-by: Vincent Chen <vincent.chen@sifive.com> Signed-off-by: Vincent Chen <vincent.chen@sifive.com> Signed-off-by: Nylon Chen <nylon.chen@sifive.com> Link: https://lore.kernel.org/r/20250529035341.51736-3-nylon.chen@sifive.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: pxa: Allow to enable for SpacemiT K1 SoCGuodong Xu
The SpacemiT K1 SoC uses devices similar to the ones on PXA SoCs. Add ARCH_SPACEMIT as one of the possible architectures this driver can be enabled for. Signed-off-by: Guodong Xu <guodong@riscstar.com> Link: https://lore.kernel.org/r/20250429085048.1310409-6-guodong@riscstar.com [ukleinek: reword commit log] Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: pxa: Add optional reset controlGuodong Xu
Support optional reset control for the PWM PXA driver. During probe, it acquires the reset controller using devm_reset_control_get_optional_exclusive_deasserted() to get and deassert the reset controller to enable the PWM channel. Signed-off-by: Guodong Xu <guodong@riscstar.com> Link: https://lore.kernel.org/r/20250429085048.1310409-3-guodong@riscstar.com [ukleinek: Fix conflict with commit df08fff8add2 ("pwm: pxa: Improve using dev_err_probe()")] Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: Add support for pwmchip devices for faster and easier userspace accessUwe Kleine-König
With this change each pwmchip defining the new-style waveform callbacks can be accessed from userspace via a character device. Compared to the sysfs-API this is faster and allows to pass the whole configuration in a single ioctl allowing atomic application and thus reducing glitches. On an STM32MP13 I see: root@DistroKit:~ time pwmtestperf real 0m 1.27s user 0m 0.02s sys 0m 1.21s root@DistroKit:~ rm /dev/pwmchip0 root@DistroKit:~ time pwmtestperf real 0m 3.61s user 0m 0.27s sys 0m 3.26s pwmtestperf does essentially: for i in 0 .. 50000: pwm_set_waveform(duty_length_ns=i, period_length_ns=50000, duty_offset_ns=0) and in the presence of /dev/pwmchip0 is uses the ioctls introduced here, without that device it uses /sys/class/pwm/pwmchip0. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/ad4a4e49ae3f8ea81e23cac1ac12b338c3bf5c5b.1746010245.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: mediatek: Ensure to disable clocks in error pathUwe Kleine-König
After enabling the clocks each error path must disable the clocks again. One of them failed to do so. Unify the error paths to use goto to make it harder for future changes to add a similar bug. Fixes: 7ca59947b5fc ("pwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config()") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20250704172728.626815-2-u.kleine-koenig@baylibre.com Cc: stable@vger.kernel.org Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: Fix invalid state detectionUwe Kleine-König
Commit 9dd42d019e63 ("pwm: Allow pwm state transitions from an invalid state") intended to allow some state transitions that were not allowed before. The idea is sane and back then I also got the code comment right, but the check for enabled is bogus. This resulted in state transitions for enabled states to be allowed to have invalid duty/period settings and thus it can happen that low-level drivers get requests for invalid states🙄. Invert the check to allow state transitions for disabled states only. Fixes: 9dd42d019e63 ("pwm: Allow pwm state transitions from an invalid state") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20250704172416.626433-2-u.kleine-koenig@baylibre.com Cc: stable@vger.kernel.org Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07RDMA/bnxt_re: Use macro instead of hard coded valueKalesh AP
1. Defined a macro for the hard coded value. 2. "access" field in the request structure is of type "u8". Updated the mask accordingly. Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Shravya KN <shravya.k-n@broadcom.com> Link: https://patch.msgid.link/20250704043857.19158-4-kalesh-anakkur.purayil@broadcom.com Reviewed-by: Hongguang Gao <hongguang.gao@broadcom.com> Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-07-07RDMA/bnxt_re: Support 2G message sizeSelvin Xavier
bnxt_qplib_put_sges is calculating the length in a signed int. So handling the 2G message size is not working since it is considered as negative. Use a unsigned number to calculate the total message length. As per the spec, IB message size shall be between zero and 2^31 bytes (inclusive). So adding a check for 2G message size. Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com> Signed-off-by: Shravya KN <shravya.k-n@broadcom.com> Link: https://patch.msgid.link/20250704043857.19158-3-kalesh-anakkur.purayil@broadcom.com Reviewed-by: Saravanan Vajravel <saravanan.vajravel@broadcom.com> Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-07-07RDMA/bnxt_re: Fix size of uverbs_copy_to() in BNXT_RE_METHOD_GET_TOGGLE_MEMKalesh AP
Since both "length" and "offset" are of type u32, there is no functional issue here. Reviewed-by: Saravanan Vajravel <saravanan.vajravel@broadcom.com> Signed-off-by: Shravya KN <shravya.k-n@broadcom.com> Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Link: https://patch.msgid.link/20250704043857.19158-2-kalesh-anakkur.purayil@broadcom.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-07-07RDMA/hns: Fix -Wframe-larger-than issueJunxian Huang
Fix -Wframe-larger-than issue by allocating memory for qpc struct with kzalloc() instead of using stack memory. Fixes: 606bf89e98ef ("RDMA/hns: Refactor for hns_roce_v2_modify_qp function") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202506240032.CSgIyFct-lkp@intel.com/ Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com> Link: https://patch.msgid.link/20250703113905.3597124-7-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-07-07RDMA/hns: Drop GFP_NOWARNJunxian Huang
GFP_NOWARN silences all warnings on dma_alloc_coherent() failure, which might otherwise help with troubleshooting. Fixes: 9a4435375cd1 ("IB/hns: Add driver files for hns RoCE driver") Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com> Link: https://patch.msgid.link/20250703113905.3597124-6-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-07-07RDMA/hns: Fix accessing uninitialized resourcesJunxian Huang
hr_dev->pgdir_list and hr_dev->pgdir_mutex won't be initialized if CQ/QP record db are not enabled, but they are also needed when using SRQ with SRQ record db enabled. Simplified the logic by always initailizing the reosurces. Fixes: c9813b0b9992 ("RDMA/hns: Support SRQ record doorbell") Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com> Link: https://patch.msgid.link/20250703113905.3597124-5-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-07-07RDMA/hns: Get message length of ack_req from FWJunxian Huang
ACK_REQ_FREQ indicates the number of packets (after MTU fragmentation) HW sends before setting an ACK request. When MTU is greater than or equal to 1024, the current ACK_REQ_FREQ value causes HW to request an ACK for every MTU fragment. The processing of a large number of ACKs severely impacts HW performance when sending large size payloads. Get message length of ack_req from FW so that we can adjust this parameter according to different situations. There are several constraints for ACK_REQ_FREQ: 1. mtu * (2 ^ ACK_REQ_FREQ) should not be too large, otherwise it may cause some unexpected retries when sending large payload. 2. ACK_REQ_FREQ should be larger than or equal to LP_PKTN_INI. 3. ACK_REQ_FREQ must be equal to LP_PKTN_INI when using LDCP or HC3 congestion control algorithm. Fixes: 56518a603fd2 ("RDMA/hns: Modify the value of long message loopback slice") Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com> Link: https://patch.msgid.link/20250703113905.3597124-4-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-07-07crypto: ccp - Fix crash when rebind ccp device for ccp.koMengbiao Xiong
When CONFIG_CRYPTO_DEV_CCP_DEBUGFS is enabled, rebinding the ccp device causes the following crash: $ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/unbind $ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/bind [ 204.976930] BUG: kernel NULL pointer dereference, address: 0000000000000098 [ 204.978026] #PF: supervisor write access in kernel mode [ 204.979126] #PF: error_code(0x0002) - not-present page [ 204.980226] PGD 0 P4D 0 [ 204.981317] Oops: Oops: 0002 [#1] SMP NOPTI ... [ 204.997852] Call Trace: [ 204.999074] <TASK> [ 205.000297] start_creating+0x9f/0x1c0 [ 205.001533] debugfs_create_dir+0x1f/0x170 [ 205.002769] ? srso_return_thunk+0x5/0x5f [ 205.004000] ccp5_debugfs_setup+0x87/0x170 [ccp] [ 205.005241] ccp5_init+0x8b2/0x960 [ccp] [ 205.006469] ccp_dev_init+0xd4/0x150 [ccp] [ 205.007709] sp_init+0x5f/0x80 [ccp] [ 205.008942] sp_pci_probe+0x283/0x2e0 [ccp] [ 205.010165] ? srso_return_thunk+0x5/0x5f [ 205.011376] local_pci_probe+0x4f/0xb0 [ 205.012584] pci_device_probe+0xdb/0x230 [ 205.013810] really_probe+0xed/0x380 [ 205.015024] __driver_probe_device+0x7e/0x160 [ 205.016240] device_driver_attach+0x2f/0x60 [ 205.017457] bind_store+0x7c/0xb0 [ 205.018663] drv_attr_store+0x28/0x40 [ 205.019868] sysfs_kf_write+0x5f/0x70 [ 205.021065] kernfs_fop_write_iter+0x145/0x1d0 [ 205.022267] vfs_write+0x308/0x440 [ 205.023453] ksys_write+0x6d/0xe0 [ 205.024616] __x64_sys_write+0x1e/0x30 [ 205.025778] x64_sys_call+0x16ba/0x2150 [ 205.026942] do_syscall_64+0x56/0x1e0 [ 205.028108] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 205.029276] RIP: 0033:0x7fbc36f10104 [ 205.030420] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 e1 08 2e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5 This patch sets ccp_debugfs_dir to NULL after destroying it in ccp5_debugfs_destroy, allowing the directory dentry to be recreated when rebinding the ccp device. Tested on AMD Ryzen 7 1700X. Fixes: 3cdbe346ed3f ("crypto: ccp - Add debugfs entries for CCP information") Signed-off-by: Mengbiao Xiong <xisme1998@gmail.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-07-07crypto: inside-secure - Fix `dma_unmap_sg()` nents valueThomas Fourier
The `dma_unmap_sg()` functions should be called with the same nents as the `dma_map_sg()`, not the value the map function returned. Fixes: c957f8b3e2e5 ("crypto: inside-secure - avoid unmapping DMA memory that was not mapped") Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com> Reviewed-by: Antoine Tenart <atenart@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-07-07crypto: ccp - Fix locking on alloc failure handlingAlexey Kardashevskiy
The __snp_alloc_firmware_pages() helper allocates pages in the firmware state (alloc + rmpupdate). In case of failed rmpupdate, it tries reclaiming pages with already changed state. This requires calling the PSP firmware and since there is sev_cmd_mutex to guard such calls, the helper takes a "locked" parameter so specify if the lock needs to be held. Most calls happen from snp_alloc_firmware_page() which executes without the lock. However commit 24512afa4336 ("crypto: ccp: Handle the legacy TMR allocation when SNP is enabled") switched sev_fw_alloc() from alloc_pages() (which does not call the PSP) to __snp_alloc_firmware_pages() (which does) but did not account for the fact that sev_fw_alloc() is called from __sev_platform_init_locked() (via __sev_platform_init_handle_tmr()) and executes with the lock held. Add a "locked" parameter to __snp_alloc_firmware_pages(). Make sev_fw_alloc() use the new parameter to prevent potential deadlock in rmp_mark_pages_firmware() if rmpupdate() failed. Fixes: 24512afa4336 ("crypto: ccp: Handle the legacy TMR allocation when SNP is enabled") Signed-off-by: Alexey Kardashevskiy <aik@amd.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Pratik R. Sampat <prsampat@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-07-07power: supply: twl4030_charger: Remove redundant pm_runtime_mark_last_busy() ↵Sakari Ailus
calls pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(), pm_runtime_autosuspend() and pm_request_autosuspend() now include a call to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to pm_runtime_mark_last_busy(). Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Link: https://lore.kernel.org/r/20250704075442.3221330-1-sakari.ailus@linux.intel.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-07-07power: supply: bq24190: Remove redundant pm_runtime_mark_last_busy() callsSakari Ailus
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(), pm_runtime_autosuspend() and pm_request_autosuspend() now include a call to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to pm_runtime_mark_last_busy(). Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Link: https://lore.kernel.org/r/20250704075442.3221283-1-sakari.ailus@linux.intel.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-07-07Merge tag 'pm-runtime-6.17-rc1'Sebastian Reichel
Runtime PM updates related to autosuspend for 6.17 Make several autosuspend functions mark last busy stamp and update the documentation accordingly (Sakari Ailus). Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-07-06Merge tag 'edac_urgent_for_v6.16_rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras Pull EDAC fix from Borislav Petkov: - Initialize sysfs attributes properly to avoid lockdep complaining about an uninitialized lock class * tag 'edac_urgent_for_v6.16_rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras: EDAC: Initialize EDAC features sysfs attributes
2025-07-06Merge tag 'irq_urgent_for_v6.16_rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irq fix from Borislav Petkov: - Have irq-msi-lib select CONFIG_GENERIC_MSI_IRQ explicitly as it uses its facilities * tag 'irq_urgent_for_v6.16_rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/irq-msi-lib: Select CONFIG_GENERIC_MSI_IRQ
2025-07-06drm/dp: Clean up white space in drm_edp_backlight_probe_state()Dan Carpenter
This code needs to be indented one more tab. Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/30b896c2-ae71-4cf2-9511-2713da7e1632@sabinyo.mountain Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-07-06drm/fbdev-client: Skip DRM clients if modesetting is absentThierry Reding
Recent generations of Tegra have moved the display components outside of host1x, leading to a device that has no CRTCs attached and hence doesn't support any of the modesetting functionality. When this is detected, the driver clears the DRIVER_MODESET and DRIVER_ATOMIC flags for the device. Unfortunately, this causes the following errors during boot: [ 15.418958] ERR KERN drm drm: [drm] *ERROR* Failed to register client: -95 [ 15.425311] WARNING KERN drm drm: [drm] Failed to set up DRM client; error -95 These originate from the fbdev client checking for the presence of the DRIVER_MODESET flag and returning -EOPNOTSUPP. However, if a driver does not support DRIVER_MODESET this is entirely expected and the error isn't helpful. Prevent this misleading error message by setting up the DRM clients only if modesetting is enabled. Changes in v2: - use DRIVER_MODESET check to avoid registering any clients Reported-by: Jonathan Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20250613122838.2082334-1-thierry.reding@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-07-06iio: imu: bmi160: make bmi160_regs constDavid Lechner
Add const qualifier to struct bmi160_regs bmi160_regs[]. This is read-only data so it can be made const. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250628-iio-const-data-18-v1-1-dad85ac392ae@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-06iio: dac: ltc2688: make ltc2688_dither_ext_info constDavid Lechner
Add const qualifier to struct iio_chan_spec_ext_info ltc2688_dither_ext_info[]. This is read-only data so it can be made const. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250628-iio-const-data-16-v1-1-9b6514588b05@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-06iio: dac: ad5770r: make ad5770r_rng_tbl constDavid Lechner
Add const qualifier to struct ad5770r_output_modes ad5770r_rng_tbl[]. This is read-only data so it can be made const. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250628-iio-const-data-15-v1-1-b86ae055004c@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-06iio: common: hid-sensor-attributes: make unit_conversion constDavid Lechner
Add const qualifier to struct unit_conversion[]. This is read-only data so it can be made const. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250628-iio-const-data-14-v1-1-4faa8015e122@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-06iio: chemical: atlas-ezo-sensor: make atlas_ezo_devices constDavid Lechner
Add const qualifier to struct atlas_ezo_device atlas_ezo_devices[]. This is read-only data so it can be made const. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250628-iio-const-data-13-v1-1-2a7fd592a07c@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-06iio: amplifiers: ad8366: make ad8366_info constDavid Lechner
Add const qualifier to struct ad8366_info ad8366_infos[]. This is read-only data so it can be made const. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250628-iio-const-data-12-v1-1-88029e48a26b@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-06iio: adc: stm32-adc: make stm32_adc_trig_info constDavid Lechner
Add const qualifier to struct stm32_adc_trig_info. This is read-only data so it can be made const. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250628-iio-const-data-10-v1-1-0ba93ac792c8@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-06iio: adc: qcom-vadc: make scale_adc5_fn constDavid Lechner
Add const qualifier to struct qcom_adc5_scale_type scale_adc5_fn[]. This is read-only data so it can be made const. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250628-iio-const-data-9-v1-1-188ca6e904ee@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-06iio: adc: mp2629_adc: make mp2629_channels constDavid Lechner
Add const qualifier to struct iio_chan_spec mp2629_channels[]. This is read-only data so it can be made const. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250628-iio-const-data-8-v1-1-32ce79494d4a@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-06iio: adc: axp20x_adc: make axp717_maps constDavid Lechner
Add const qualifier to struct iio_map axp717_maps[]. This is read-only data so it can be made const. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250628-iio-const-data-7-v1-1-10008d0a4c2f@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-06iio: adc: at91_adc: make at91_adc_caps constDavid Lechner
Add const qualifier to struct at91_adc_caps at91sam*_caps. This is read-only data so it can be made const. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250628-iio-const-data-6-v1-1-fbb1ca5edc8d@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-06iio: adc: ad7091r8: make ad7091r_init_info constDavid Lechner
Add const qualifier to struct ad7091r_init_info ad7091r*_init_info. This is read-only data so it can be made const. Signed-off-by: David Lechner <dlechner@baylibre.com> Acked-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com> Link: https://patch.msgid.link/20250628-iio-const-data-4-v1-1-4e0f93c9cf83@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
generated by cgit v1.2.3 (git 2.25.1) at 2026-05-21 20:03:49 +0000