summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2024-09-05Merge tag 'qcom-drivers-fixes-for-6.11-2' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes One more Qualcomm driver fix for v6.11 This resolves a deadlock in the Qualcomm uefisecapp driver following the attempt to acquire global context is acquired in the case the device isn't probed. * tag 'qcom-drivers-fixes-for-6.11-2' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: firmware: qcom: uefisecapp: Fix deadlock in qcuefi_acquire() Link: https://lore.kernel.org/r/20240904145214.4089-1-andersson@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-09-05net: stmmac: Batch set RX OWN flag and other flagsTan En De
Minimize access to the RX descriptor by collecting all the flags in a local variable and then updating the descriptor at once. Signed-off-by: Tan En De <ende.tan@starfivetech.com> Link: https://patch.msgid.link/20240831011114.2065912-1-ende.tan@starfivetech.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-09-05pwm: stm32: Use the right CCxNP bit in stm32_pwm_enable()Uwe Kleine-König
The pwm devices for a pwm_chip are numbered starting at 0, the first hw channel however has the number 1. While introducing a parametrised macro to simplify register bit usage and making that offset explicit, one of the usages was converted wrongly. This is fixed here. Fixes: 7cea05ae1d4e ("pwm-stm32: Make use of parametrised register definitions") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20240905090627.197536-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2024-09-05drm/fbdev-dma: Only install deferred I/O if necessaryThomas Zimmermann
Deferred I/O requires struct page for framebuffer memory, which is not guaranteed for all DMA ranges. We thus only install deferred I/O if we have a framebuffer that requires it. A reported bug affected the ipu-v3 and pl111 drivers, which have video memory in either Normal or HighMem zones [ 0.000000] Zone ranges: [ 0.000000] Normal [mem 0x0000000010000000-0x000000003fffffff] [ 0.000000] HighMem [mem 0x0000000040000000-0x000000004fffffff] where deferred I/O only works correctly with HighMem. See the Closes tags for bug reports. v2: - test if screen_buffer supports deferred I/O (Sima) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 808a40b69468 ("drm/fbdev-dma: Implement damage handling and deferred I/O") Reported-by: Alexander Stein <alexander.stein@ew.tq-group.com> Closes: https://lore.kernel.org/all/23636953.6Emhk5qWAg@steina-w/ Reported-by: Linus Walleij <linus.walleij@linaro.org> Closes: https://lore.kernel.org/dri-devel/CACRpkdb+hb9AGavbWpY-=uQQ0apY9en_tWJioPKf_fAbXMP4Hg@mail.gmail.com/ Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> Tested-by: Linus Walleij <linus.walleij@linaro.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Reviewed-by: Simona Vetter <simona.vetter@ffwll.ch> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240904123750.31206-1-tzimmermann@suse.de
2024-09-05drm/panthor: flush FW AS caches in slow reset pathAdrián Larumbe
In the off-chance that waiting for the firmware to signal its booted status timed out in the fast reset path, one must flush the cache lines for the entire FW VM address space before reloading the regions, otherwise stale values eventually lead to a scheduler job timeout. Fixes: 647810ec2476 ("drm/panthor: Add the MMU/VM logical block") Cc: stable@vger.kernel.org Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240902130237.3440720-1-adrian.larumbe@collabora.com
2024-09-05drm: panel: nv3052c: Correct WL-355608-A8 panel compatibleRyan Walklin
As per the previous dt-binding commit, update the WL-355608-A8 panel compatible to reflect the the integrating device vendor and name as the panel OEM is unknown. Fixes: 62ea2eeba7bf ("drm: panel: nv3052c: Add WL-355608-A8 panel") Signed-off-by: Ryan Walklin <ryan@testtoast.com> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240904012456.35429-3-ryan@testtoast.com
2024-09-05drm/panthor: Restrict high priorities on group_createMary Guillemard
We were allowing any users to create a high priority group without any permission checks. As a result, this was allowing possible denial of service. We now only allow the DRM master or users with the CAP_SYS_NICE capability to set higher priorities than PANTHOR_GROUP_PRIORITY_MEDIUM. As the sole user of that uAPI lives in Mesa and hardcode a value of MEDIUM [1], this should be safe to do. Additionally, as those checks are performed at the ioctl level, panthor_group_create now only check for priority level validity. [1]https://gitlab.freedesktop.org/mesa/mesa/-/blob/f390835074bdf162a63deb0311d1a6de527f9f89/src/gallium/drivers/panfrost/pan_csf.c#L1038 Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com> Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Cc: stable@vger.kernel.org Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240903144955.144278-2-mary.guillemard@collabora.com
2024-09-05wifi: rtw89: avoid reading out of bounds when loading TX power FW elementsZong-Zhe Yang
Because the loop-expression will do one more time before getting false from cond-expression, the original code copied one more entry size beyond valid region. Fix it by moving the entry copy to loop-body. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240902015803.20420-1-pkshih@realtek.com
2024-09-05wifi: rtw89: use frequency domain RSSIEric Huang
To get more accurate RSSI, this commit includes frequency domain RSSI info in RSSI calculation. Add correspond physts parsing and macro to get frequency domain RSSI information for supported IC. Signed-off-by: Eric Huang <echuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240828055217.10263-3-pkshih@realtek.com
2024-09-05wifi: rtw89: adjust DIG threshold to reduce false alarmEric Huang
Use RSSI without subtracting offset as packet detection lower bound and set an absolute minimal threshold. It's equivalent to setting a higher noise floor, thereby reducing false alarm and improving interference endurance. Signed-off-by: Eric Huang <echuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240828055217.10263-2-pkshih@realtek.com
2024-09-04Merge branch '100GbE' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue Tony Nguyen says: ==================== ice: fix synchronization between .ndo_bpf() and reset Larysa Zaremba says: PF reset can be triggered asynchronously, by tx_timeout or by a user. With some unfortunate timings both ice_vsi_rebuild() and .ndo_bpf will try to access and modify XDP rings at the same time, causing system crash. The first patch factors out rtnl-locked code from VSI rebuild code to avoid deadlock. The following changes lock rebuild and .ndo_bpf() critical sections with an internal mutex as well and provide complementary fixes. * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: ice: do not bring the VSI up, if it was down before the XDP setup ice: remove ICE_CFG_BUSY locking from AF_XDP code ice: check ICE_VSI_DOWN under rtnl_lock when preparing for reset ice: check for XDP rings instead of bpf program when unconfiguring ice: protect XDP configuration with a mutex ice: move netif_queue_set_napi to rtnl-protected sections ==================== Link: https://patch.msgid.link/20240903183034.3530411-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-04Merge tag 'wireless-next-2024-09-04' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== pull-request: wireless-next-2024-09-04 here's a pull request to net-next tree, more info below. Please let me know if there are any problems. ==================== Conflicts: drivers/net/wireless/ath/ath12k/hw.c 38055789d151 ("wifi: ath12k: use 128 bytes aligned iova in transmit path for WCN7850") 8be12629b428 ("wifi: ath12k: restore ASPM for supported hardwares only") https://lore.kernel.org/87msldyj97.fsf@kernel.org Link: https://patch.msgid.link/20240904153205.64C11C4CEC2@smtp.kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-04Merge tag 'wireless-2024-09-04' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless Kalle Valo says: ==================== wireless fixes for v6.11 Hopefully final fixes for v6.11 and this time only fixes to ath11k driver. We need to revert hibernation support due to reported regressions and we have a fix for kernel crash introduced in v6.11-rc1. * tag 'wireless-2024-09-04' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: MAINTAINERS: wifi: cw1200: add net-cw1200.h Revert "wifi: ath11k: support hibernation" Revert "wifi: ath11k: restore country code during resume" wifi: ath11k: fix NULL pointer dereference in ath11k_mac_get_eirp_power() ==================== Link: https://patch.msgid.link/20240904135906.5986EC4CECA@smtp.kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-04net: cadence: macb: Enable software IRQ coalescing by defaultSean Anderson
This NIC doesn't have hardware IRQ coalescing. Under high load, interrupts can adversely affect performance. To mitigate this, enable software IRQ coalescing by default. On my system this increases receive throughput with iperf3 from 853 MBit/sec to 934 MBit/s, decreases interrupts from 69489/sec to 2016/sec, and decreases CPU utilization from 27% (4x Cortex-A53) to 14%. Latency is not affected (as far as I can tell). Signed-off-by: Sean Anderson <sean.anderson@linux.dev> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20240903184912.4151926-1-sean.anderson@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-04net: xilinx: axienet: Fix race in axienet_stopSean Anderson
axienet_dma_err_handler can race with axienet_stop in the following manner: CPU 1 CPU 2 ====================== ================== axienet_stop() napi_disable() axienet_dma_stop() axienet_dma_err_handler() napi_disable() axienet_dma_stop() axienet_dma_start() napi_enable() cancel_work_sync() free_irq() Fix this by setting a flag in axienet_stop telling axienet_dma_err_handler not to bother doing anything. I chose not to use disable_work_sync to allow for easier backporting. Signed-off-by: Sean Anderson <sean.anderson@linux.dev> Fixes: 8a3b7a252dca ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver") Link: https://patch.msgid.link/20240903175141.4132898-1-sean.anderson@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-04net: phy: Check for read errors in SIOCGMIIREGNiklas Söderlund
When reading registers from the PHY using the SIOCGMIIREG IOCTL any errors returned from either mdiobus_read() or mdiobus_c45_read() are ignored, and parts of the returned error is passed as the register value back to user-space. For example, if mdiobus_c45_read() is used with a bus that do not implement the read_c45() callback -EOPNOTSUPP is returned. This is however directly stored in mii_data->val_out and returned as the registers content. As val_out is a u16 the error code is truncated and returned as a plausible register value. Fix this by first checking the return value for errors before returning it as the register content. Before this patch, # phytool read eth0/0:1/0 0xffa1 After this change, $ phytool read eth0/0:1/0 error: phy_read (-95) Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20240903171536.628930-1-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-04pds_core: Remove redundant null pointer checksLi Zetao
Since the debugfs_create_dir() never returns a null pointer, checking the return value for a null pointer is redundant, and using IS_ERR is safe enough. Signed-off-by: Li Zetao <lizetao1@huawei.com> Link: https://patch.msgid.link/20240903143343.2004652-1-lizetao1@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-04ionic: Remove redundant null pointer checks in ionic_debugfs_add_qcq()Li Zetao
Since the debugfs_create_dir() never returns a null pointer, checking the return value for a null pointer is redundant, and using IS_ERR is safe enough. Signed-off-by: Li Zetao <lizetao1@huawei.com> Link: https://patch.msgid.link/20240903143149.2004530-1-lizetao1@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-04r8152: fix the firmware doesn't workHayes Wang
generic_ocp_write() asks the parameter "size" must be 4 bytes align. Therefore, write the bp would fail, if the mac->bp_num is odd. Align the size to 4 for fixing it. The way may write an extra bp, but the rtl8152_is_fw_mac_ok() makes sure the value must be 0 for the bp whose index is more than mac->bp_num. That is, there is no influence for the firmware. Besides, I check the return value of generic_ocp_write() to make sure everything is correct. Fixes: e5c266a61186 ("r8152: set bp in bulk") Signed-off-by: Hayes Wang <hayeswang@realtek.com> Link: https://patch.msgid.link/20240903063333.4502-1-hayeswang@realtek.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-04net: mana: Improve mana_set_channels() in low mem conditionsShradha Gupta
The mana_set_channels() function requires detaching the mana driver and reattaching it with changed channel values. During this operation if the system is low on memory, the reattach might fail, causing the network device being down. To avoid this we pre-allocate buffers at the beginning of set operation, to prevent complete network loss Signed-off-by: Shradha Gupta <shradhagupta@linux.microsoft.com> Reviewed-by: Gerhard Engleder <gerhard@engleder-embedded.com> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com> Link: https://patch.msgid.link/1725248734-21760-1-git-send-email-shradhagupta@linux.microsoft.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-04md: Report failed arrays as broken in mdstatMateusz Kusiak
Depending on if array has personality, it is either reported as active or inactive. This patch adds third status "broken" for arrays with personality that became inoperative. The reason is end users tend to assume that "active" indicates array is operational. Add "broken" state for inoperative arrays with personality and refactor the code. Signed-off-by: Mateusz Kusiak <mateusz.kusiak@intel.com> Link: https://lore.kernel.org/r/20240903142949.53628-1-mateusz.kusiak@intel.com Signed-off-by: Song Liu <song@kernel.org>
2024-09-04bareudp: Fix device stats updates.Guillaume Nault
Bareudp devices update their stats concurrently. Therefore they need proper atomic increments. Fixes: 571912c69f0e ("net: UDP tunnel encapsulation module for tunnelling different protocols like MPLS, IP, NSH etc.") Signed-off-by: Guillaume Nault <gnault@redhat.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/04b7b9d0b480158eb3ab4366ec80aa2ab7e41fcb.1725031794.git.gnault@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-04cpufreq/amd-pstate: Catch failures for amd_pstate_epp_update_limit()Mario Limonciello
amd_pstate_set_epp() calls cppc_set_epp_perf() which can fail for a variety of reasons but this is ignored. Change the return flow to allow failures. Reviewed-by: Perry Yuan <perry.yuan@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-09-04Merge tag 'hwmon-for-v6.11-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon fixes from Guenter Roeck: - hp-wmi-sensors: Check if WMI event data exists before accessing it - ltc2991: fix register bits defines * tag 'hwmon-for-v6.11-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (hp-wmi-sensors) Check if WMI event data exists hwmon: ltc2991: fix register bits defines
2024-09-04irqchip/apple-aic: Only access system registers on SoCs which provide themKonrad Dybcio
Starting from the A11 (T8015) SoC, Apple introuced system registers for fast IPI and UNCORE PMC control. These sysregs do not exist on earlier A7-A10 SoCs and trying to access them results in an instant crash. Restrict sysreg access within the AIC driver to configurations where use_fast_ipi is true to allow AIC to function properly on A7-A10 SoCs. Co-developed-by: Nick Chan <towinchenmi@gmail.com> Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org> Signed-off-by: Nick Chan <towinchenmi@gmail.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Sven Peter <sven@svenpeter.dev> Link: https://lore.kernel.org/all/20240901034143.12731-5-towinchenmi@gmail.com
2024-09-04irqchip/apple-aic: Add a new "Global fast IPIs only" feature levelNick Chan
Starting with the A11 (T8015) SoC, Apple began using arm64 sysregs for fast IPIs. However, on A11, there is no such things as "Local" fast IPIs, as the SYS_IMP_APL_IPI_RR_LOCAL_EL1 register does not seem to exist. Add a new feature level, used by the compatible "apple,t8015-aic", controlled by a static branch key named use_local_fast_ipi. When use_fast_ipi is true and use_local_fast_ipi is false, fast IPIs are used but all IPIs goes through the register SYS_IMP_APL_IPI_RR_GLOBAL_EL1, as "global" IPIs. Signed-off-by: Nick Chan <towinchenmi@gmail.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Sven Peter <sven@svenpeter.dev> Link: https://lore.kernel.org/all/20240901034143.12731-4-towinchenmi@gmail.com
2024-09-04irqchip/apple-aic: Skip unnecessary enabling of use_fast_ipiNick Chan
use_fast_ipi is true by default and there is no need to "enable" it. Signed-off-by: Nick Chan <towinchenmi@gmail.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Sven Peter <sven@svenpeter.dev> Link: https://lore.kernel.org/all/20240901034143.12731-3-towinchenmi@gmail.com
2024-09-04drm/xe/display: Avoid encoder_suspend at runtime suspendRodrigo Vivi
Fix circular locking dependency on runtime suspend. <4> [74.952215] ====================================================== <4> [74.952217] WARNING: possible circular locking dependency detected <4> [74.952219] 6.10.0-rc7-xe #1 Not tainted <4> [74.952221] ------------------------------------------------------ <4> [74.952223] kworker/7:1/82 is trying to acquire lock: <4> [74.952226] ffff888120548488 (&dev->mode_config.mutex){+.+.}-{3:3}, at: drm_modeset_lock_all+0x40/0x1e0 [drm] <4> [74.952260] but task is already holding lock: <4> [74.952262] ffffffffa0ae59c0 (xe_pm_runtime_lockdep_map){+.+.}-{0:0}, at: xe_pm_runtime_suspend+0x2f/0x340 [xe] <4> [74.952322] which lock already depends on the new lock. The commit 'b1d90a86 ("drm/xe: Use the encoder suspend helper also used by the i915 driver")' didn't do anything wrong. It actually fixed a critical bug, because the encoder_suspend was never getting actually called because it was returning if (has_display(xe)) instead of if (!has_display(xe)). However, this ended up introducing the encoder suspend calls in the runtime routines as well, causing the circular locking dependency. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2304 Fixes: b1d90a862c89 ("drm/xe: Use the encoder suspend helper also used by the i915 driver") Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240830183507.298351-2-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit 8da19441d0a02b53e362df81843bb20db3a8006a) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-09-04drm/xe: Suspend/resume user access only during system s/rImre Deak
Enable/Disable user access only during system suspend/resume. This should not happen during runtime s/r v2: rebased Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240823112148.327015-2-vinod.govindapillai@intel.com (cherry picked from commit a64e7e5b05e014dad9ae5858c9644d61400ec6ef) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-09-04drm/xe/display: Match i915 driver suspend/resume sequences betterMaarten Lankhorst
Suspend fbdev sooner, and disable user access before suspending to prevent some races. I've noticed this when comparing xe suspend to i915's. Matches the following commits from i915: 24b412b1bfeb ("drm/i915: Disable intel HPD poll after DRM poll init/enable") 1ef28d86bea9 ("drm/i915: Suspend the framebuffer console earlier during system suspend") bd738d859e71 ("drm/i915: Prevent modesets during driver init/shutdown") Thanks to Imre for pointing me to those commits. Driver shutdown is currently missing, but I have some idea how to implement it next. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240806105044.596842-2-maarten.lankhorst@linux.intel.com Signed-off-by: Maarten Lankhorst,,, <maarten.lankhorst@linux.intel.com> (cherry picked from commit 492be2a070f023c66aaef6ebd664567fda28c2a6) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-09-05PM / devfreq: imx-bus: Use of_property_present()Rob Herring (Arm)
Use of_property_present() to test for property presence rather than of_get_property(). This is part of a larger effort to remove callers of of_get_property() and similar functions. of_get_property() leaks the DT property data pointer which is a problem for dynamically allocated nodes which may be freed. Link: https://lore.kernel.org/lkml/20240731191312.1710417-11-robh@kernel.org/ Acked-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2024-09-04drm/xe: Add missing runtime reference to wedged upon gt_resetRodrigo Vivi
Fixes this missed case: xe 0000:00:02.0: [drm] Missing outer runtime PM protection WARNING: CPU: 99 PID: 1455 at drivers/gpu/drm/xe/xe_pm.c:564 xe_pm_runtime_get_noresume+0x48/0x60 [xe] Call Trace: <TASK> ? show_regs+0x67/0x70 ? __warn+0x94/0x1b0 ? xe_pm_runtime_get_noresume+0x48/0x60 [xe] ? report_bug+0x1b7/0x1d0 ? handle_bug+0x46/0x80 ? exc_invalid_op+0x19/0x70 ? asm_exc_invalid_op+0x1b/0x20 ? xe_pm_runtime_get_noresume+0x48/0x60 [xe] xe_device_declare_wedged+0x91/0x280 [xe] gt_reset_worker+0xa2/0x250 [xe] v2: Also move get and get the right Fixes tag (Himal, Brost) Fixes: fb74b205cdd2 ("drm/xe: Introduce a simple wedged state") Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240830183507.298351-1-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit bc947d9a8c3ebd207e52c0e35cfc88f3e1abe54f) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-09-04extcon: axp288: Switch to new Intel CPU model definesTony Luck
New CPU #defines encode vendor and family as well as model. Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20240903173443.7962-2-tony.luck@intel.com
2024-09-05PM / devfreq: exynos: Use Use devm_clk_get_enabled() helpersAnand Moon
The devm_clk_get_enabled() helpers: - call devm_clk_get() - call clk_prepare_enable() and register what is needed in order to call clk_disable_unprepare() when needed, as a managed resource. This simplifies the code and avoids the calls to clk_disable_unprepare(). While at it, use dev_err_probe consistently, and use its return value to return the error code. Link: https://lore.kernel.org/lkml/20240510094034.12493-1-linux.amoon@gmail.com/ Signed-off-by: Anand Moon <linux.amoon@gmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2024-09-05PM/devfreq: governor: add missing MODULE_DESCRIPTION() macrosJeff Johnson
make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/devfreq/governor_simpleondemand.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/devfreq/governor_performance.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/devfreq/governor_powersave.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/devfreq/governor_userspace.o Add all missing invocations of the MODULE_DESCRIPTION() macro. Link: https://lore.kernel.org/lkml/20240605-md-drivers-devfreq-v1-1-d01ae91b907e@quicinc.com/ Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2024-09-04cpufreq: ti-cpufreq: Use socinfo to get revision in AM62 familyDhruva Gole
In the AM62x, AM62Ax, and AM62Px devices, we already have the revision info within the k3-socinfo driver. Hence, re-use this information from there instead of re using the offset for 2 drivers trying to get the same information ie. revision. Signed-off-by: Dhruva Gole <d-gole@ti.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2024-09-04cpufreq: Fix the cacography in powernv-cpufreq.cLiu Jing
The word 'swtich' is wrong, so fix it. Signed-off-by: Liu Jing <liujing@cmss.chinamobile.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2024-09-04cpufreq: ti-cpufreq: Introduce quirks to handle syscon fails appropriatelyNishanth Menon
Commit b4bc9f9e27ed ("cpufreq: ti-cpufreq: add support for omap34xx and omap36xx") introduced special handling for OMAP3 class devices where syscon node may not be present. However, this also creates a bug where the syscon node is present, however the offset used to read is beyond the syscon defined range. Fix this by providing a quirk option that is populated when such special handling is required. This allows proper failure for all other platforms when the syscon node and efuse offsets are mismatched. Fixes: b4bc9f9e27ed ("cpufreq: ti-cpufreq: add support for omap34xx and omap36xx") Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Dhruva Gole <d-gole@ti.com> Reviewed-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2024-09-04cpufreq: loongson3: Use raw_smp_processor_id() in do_service_request()Huacai Chen
Use raw_smp_processor_id() instead of plain smp_processor_id() in do_service_request(), otherwise we may get some errors with the driver enabled: BUG: using smp_processor_id() in preemptible [00000000] code: (udev-worker)/208 caller is loongson3_cpufreq_probe+0x5c/0x250 [loongson3_cpufreq] Reported-by: Xi Ruoyao <xry111@xry111.site> Tested-by: Binbin Zhou <zhoubinbin@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2024-09-04cpufreq: amd-pstate: add check for cpufreq_cpu_get's return valueAnastasia Belova
cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it and return in case of error. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Anastasia Belova <abelova@astralinux.ru> Reviewed-by: Perry Yuan <perry.yuan@amd.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2024-09-04cpufreq: Add SM7325 to cpufreq-dt-platdev blocklistDanila Tikhonov
The Qualcomm SM7325 platform uses the qcom-cpufreq-hw driver, so add it to the cpufreq-dt-platdev driver's blocklist. Signed-off-by: Danila Tikhonov <danila@jiaxyga.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2024-09-04cpufreq: Fix warning on unused of_device_id tables for !CONFIG_OFRob Herring (Arm)
!CONFIG_OF builds cause warnings on unused of_device_id tables. This is due to of_match_node() being a macro rather than static inline function. Add a __maybe_unused annotation to the of_device_id tables. Fixes: c7582ec85342 ("cpufreq: Drop CONFIG_ARM and CONFIG_ARM64 dependency on Arm drivers") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202408090714.wcrqU6Pk-lkp@intel.com/ Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2024-09-04cpufreq/amd-pstate: Add the missing cpufreq_cpu_put()Dhananjay Ugwekar
Fix the reference counting of cpufreq_policy object in amd_pstate_update() function by adding the missing cpufreq_cpu_put(). Fixes: e8f555daacd3 ("cpufreq/amd-pstate: fix setting policy current frequency value") Signed-off-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com> Reviewed-by: Perry Yuan <perry.yuan@amd.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2024-09-04cpufreq: Drop CONFIG_ARM and CONFIG_ARM64 dependency on Arm driversRob Herring (Arm)
The CONFIG_ARM and CONFIG_ARM64 dependency is redundant as all the drivers have necessary sub-arch dependency and don't depend on the architecture support. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2024-09-04cpufreq: Enable COMPILE_TEST on Arm driversRob Herring (Arm)
COMPILE_TEST is useful for build testing without requiring a specific architecture's compiler. Enable it for most of the Arm CPUFreq drivers. As Kconfig.arm is only included on ARM and ARM64, COMPILE_TEST is only enabled for those architectures until that is dropped. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2024-09-04opp: ti: Drop unnecessary of_match_ptr()Rob Herring (Arm)
of_match_ptr() is not necessary as the driver is always enabled for DT. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2024-09-04perf/arm-cmn: Support CMN S3Robin Murphy
CMN S3 is the latest and greatest evolution for 2024, although most of the new features don't impact the PMU, so from our point of view it ends up looking a lot like CMN-700 r3 still. We have some new device types to ignore, a mildly irritating rearrangement of the register layouts, and a scary new configuration option that makes it potentially unsafe to even walk the full discovery tree, let alone attempt to use the PMU. Acked-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/2ec9eec5b6bf215a9886f3b69e3b00e4cd85095c.1725296395.git.robin.murphy@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2024-09-04perf/arm-cmn: Refactor DTC PMU register accessRobin Murphy
Annoyingly, we're soon going to have to cope with PMU registers moving about. This will mostly be straightforward, except for the hard-coding of CMN_PMU_OFFSET for the DTC PMU registers. As a first step, refactor those accessors to allow for encapsulating a variable offset without making a big mess all over. As a bonus, we can repack the arm_cmn_dtc structure to accommodate the new pointer without growing any larger, since irq_friend only encodes a range of +/-3. Acked-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/fc677576fae7b5b55780e5b245a4ef6ea1b30daf.1725296395.git.robin.murphy@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2024-09-04perf/arm-cmn: Make cycle counts less surprisingRobin Murphy
By default, CMN has automatic clock-gating with the implication that a DTC's cycle counter may not increment while the DTC is sufficiently idle. Given that we may have up to 4 DTCs to choose from when scheduling a cycles event, this may potentially lead to surprising results if trying to measure metrics based on activity in a different DTC domain from where cycles end up being counted. Furthermore, since the details of internal clock gating are not documented, we can't even reason about what "active" cycles for a DTC actually mean relative to the activity of other nodes within the same nominal DTC domain. Make the reasonable assumption that if the user wants to count cycles, they almost certainly want to count all of the cycles, and disable clock gating while a DTC's cycle counter is in use. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/c47cfdc09e907b1d7753d142a7e659982cceb246.1725296395.git.robin.murphy@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2024-09-04perf/arm-cmn: Improve build-time assertionRobin Murphy
These days we can use static_assert() in the logical place rather than jamming a BUILD_BUG_ON() into the nearest function scope. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/224ee8286f299100f1c768edb254edc898539f50.1725296395.git.robin.murphy@arm.com Signed-off-by: Will Deacon <will@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-16 05:00:22 +0000