aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2024-04-08md: add check for sleepers in md_wakeup_thread()Florian-Ewald Mueller1-1/+2
Check for sleeping thread before attempting its wake_up in md_wakeup_thread() to avoid unnecessary spinlock contention. With a 6.1 kernel, fio random read/write tests on many (>= 100) virtual volumes, of 100 GiB each, on 3 md-raid5s on 8 SSDs each (building a raid50), show by 3 to 4 % improved IOPS performance. Signed-off-by: Florian-Ewald Mueller <[email protected]> Reviewed-by: Yu Kuai <[email protected]> Signed-off-by: Jack Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Song Liu <[email protected]>
2024-04-09fpga: tests: use KUnit devices instead of platform devicesMarco Pagani3-46/+44
KUnit now provides helper functions to create fake devices, so use them instead of relying on platform devices. Other changes: remove an unnecessary white space in the fpga region suite. Reviewed-by: Russ Weight <[email protected]> Signed-off-by: Marco Pagani <[email protected]> Acked-by: Xu Yilun <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Xu Yilun <[email protected]>
2024-04-08md/raid5: fix deadlock that raid5d() wait for itself to clear ↵Yu Kuai1-12/+3
MD_SB_CHANGE_PENDING Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with small possibility, the root cause is exactly the same as commit bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"") However, Dan reported another hang after that, and junxiao investigated the problem and found out that this is caused by plugged bio can't issue from raid5d(). Current implementation in raid5d() has a weird dependence: 1) md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear MD_SB_CHANGE_PENDING; 2) raid5d() handles IO in a deadloop, until all IO are issued; 3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared; This behaviour is introduce before v2.6, and for consequence, if other context hold 'reconfig_mutex', and md_check_recovery() can't update super_block, then raid5d() will waste one cpu 100% by the deadloop, until 'reconfig_mutex' is released. Refer to the implementation from raid1 and raid10, fix this problem by skipping issue IO if MD_SB_CHANGE_PENDING is still set after md_check_recovery(), daemon thread will be woken up when 'reconfig_mutex' is released. Meanwhile, the hang problem will be fixed as well. Fixes: 5e2cf333b7bd ("md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d") Cc: [email protected] # v5.19+ Reported-and-tested-by: Dan Moulding <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Investigated-by: Junxiao Bi <[email protected]> Signed-off-by: Yu Kuai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Song Liu <[email protected]>
2024-04-08Merge tag 'md-6.9-20240408' of ↵Jens Axboe1-1/+1
https://git.kernel.org/pub/scm/linux/kernel/git/song/md into block-6.9 Pull MD fix from Song: "This change, by Yu Kuai, fixes a UAF in a corner case." * tag 'md-6.9-20240408' of https://git.kernel.org/pub/scm/linux/kernel/git/song/md: raid1: fix use-after-free for original bio in raid1_write_request()
2024-04-09nouveau: fix devinit paths to only handle display on GSP.Dave Airlie2-4/+9
This reverts: nouveau/gsp: don't check devinit disable on GSP. and applies a further fix. It turns out the open gpu driver, checks this register, but only for display. Match that behaviour and in the turing path only disable the display block. (ampere already only does displays). Fixes: 5d4e8ae6e57b ("nouveau/gsp: don't check devinit disable on GSP.") Reviewed-by: Danilo Krummrich <[email protected]> Signed-off-by: Dave Airlie <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08net: ks8851: Handle softirqs at the end of IRQ thread to fix hangMarek Vasut1-1/+5
The ks8851_irq() thread may call ks8851_rx_pkts() in case there are any packets in the MAC FIFO, which calls netif_rx(). This netif_rx() implementation is guarded by local_bh_disable() and local_bh_enable(). The local_bh_enable() may call do_softirq() to run softirqs in case any are pending. One of the softirqs is net_rx_action, which ultimately reaches the driver .start_xmit callback. If that happens, the system hangs. The entire call chain is below: ks8851_start_xmit_par from netdev_start_xmit netdev_start_xmit from dev_hard_start_xmit dev_hard_start_xmit from sch_direct_xmit sch_direct_xmit from __dev_queue_xmit __dev_queue_xmit from __neigh_update __neigh_update from neigh_update neigh_update from arp_process.constprop.0 arp_process.constprop.0 from __netif_receive_skb_one_core __netif_receive_skb_one_core from process_backlog process_backlog from __napi_poll.constprop.0 __napi_poll.constprop.0 from net_rx_action net_rx_action from __do_softirq __do_softirq from call_with_stack call_with_stack from do_softirq do_softirq from __local_bh_enable_ip __local_bh_enable_ip from netif_rx netif_rx from ks8851_irq ks8851_irq from irq_thread_fn irq_thread_fn from irq_thread irq_thread from kthread kthread from ret_from_fork The hang happens because ks8851_irq() first locks a spinlock in ks8851_par.c ks8851_lock_par() spin_lock_irqsave(&ksp->lock, ...) and with that spinlock locked, calls netif_rx(). Once the execution reaches ks8851_start_xmit_par(), it calls ks8851_lock_par() again which attempts to claim the already locked spinlock again, and the hang happens. Move the do_softirq() call outside of the spinlock protected section of ks8851_irq() by disabling BHs around the entire spinlock protected section of ks8851_irq() handler. Place local_bh_enable() outside of the spinlock protected section, so that it can trigger do_softirq() without the ks8851_par.c ks8851_lock_par() spinlock being held, and safely call ks8851_start_xmit_par() without attempting to lock the already locked spinlock. Since ks8851_irq() is protected by local_bh_disable()/local_bh_enable() now, replace netif_rx() with __netif_rx() which is not duplicating the local_bh_disable()/local_bh_enable() calls. Fixes: 797047f875b5 ("net: ks8851: Implement Parallel bus operations") Signed-off-by: Marek Vasut <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-04-08net: ks8851: Inline ks8851_rx_skb()Marek Vasut4-36/+1
Both ks8851_rx_skb_par() and ks8851_rx_skb_spi() call netif_rx(skb), inline the netif_rx(skb) call directly into ks8851_common.c and drop the .rx_skb callback and ks8851_rx_skb() wrapper. This removes one indirect call from the driver, no functional change otherwise. Signed-off-by: Marek Vasut <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-04-08net: phy: air_en8811h: fix some error codesDan Carpenter1-4/+4
These error paths accidentally return "ret" which is zero/success instead of the correct error code. Fixes: 71e79430117d ("net: phy: air_en8811h: Add the Airoha EN8811H PHY driver") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-04-08archnet: Convert from tasklet to BH workqueueAllen Pais2-6/+8
The only generic interface to execute asynchronously in the BH context is tasklet; however, it's marked deprecated and has some design flaws. To replace tasklets, BH workqueue support was recently added. A BH workqueue behaves similarly to regular workqueues except that the queued work items are executed in the BH context. This patch converts drivers/net/archnet/* from tasklet to BH workqueue. Based on the work done by Tejun Heo <[email protected]> Branch: https://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git for-6.10 Signed-off-by: Allen Pais <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-04-08Merge patch series "Improve the code for showing commands in debugfs"Martin K. Petersen1-25/+31
Bart Van Assche <[email protected]> says: Hi Martin, The SCSI debugfs code may show information in debugfs that is invalid. Hence this patch series that makes sure only valid information is shown in debugfs. Please consider this patch series for the next merge window. Thanks, Bart. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-04-08scsi: core: Improve the code for showing commands in debugfsBart Van Assche1-8/+12
Some but not all command information is cleared by scsi_end_request(). As an example, if scsi_show_rq() is called after a SCSI command has been allocated and before SCMD_INITIALIZED is set, .cmnd holds the CDB of a previous command. Showing that information in debugfs is confusing. Hence this patch that restricts the information shown in debugfs to valid information. Signed-off-by: Bart Van Assche <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-04-08scsi: core: Introduce scsi_cmd_list_info()Bart Van Assche1-19/+21
Slightly improve code readability by introducing a helper function for deriving the list information and by using guard() + return instead of goto + explicit unlock + return. Signed-off-by: Bart Van Assche <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-04-08scsi: snic: Convert sprintf() family to sysfs_emit() familyLi Zhijian1-6/+5
Per filesystems/sysfs.rst, show() should only use sysfs_emit() or sysfs_emit_at() when formatting the value to be returned to user space. coccinelle complains that there are still a couple of functions that use snprintf(). Convert them to sysfs_emit(). sprintf() and scnprintf() will be converted as well if they have. Generally, this patch is generated by make coccicheck M=<path/to/file> MODE=patch \ COCCI=scripts/coccinelle/api/device_attr_show.cocci No functional change intended CC: Karan Tilak Kumar <[email protected]> CC: Sesidhar Baddela <[email protected]> CC: James E.J. Bottomley <[email protected]> CC: Martin K. Petersen <[email protected]> CC: [email protected] Signed-off-by: Li Zhijian <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Karan Tilak Kumar <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2024-04-08scsi: FlashPoint: Remove redundant assignment to pointer currTar_InfoColin Ian King1-1/+0
Pointer currTar_Info is being assigned a value that is never read, it is being re-assigned a few lines later in the start of a following do-while loop. The assignment is redundant and can be removed. Signed-off-by: Colin Ian King <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-04-08scsi: aic7xxx: Indent kconfig help textPrasad Pandit2-85/+87
Fix indentation of config option's help text by adding leading spaces. Generally help text is indented by two more spaces beyond the leading tab <\t> character. It helps Kconfig parsers to read file without error. Signed-off-by: Prasad Pandit <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-04-08scsi: qla2xxx: Indent help textPrasad Pandit2-22/+24
Fix indentation of config option's help text by adding leading spaces. Generally help text is indented by couple of spaces more beyond the leading tab <\t> character. It helps Kconfig parsers to read file without error. Signed-off-by: Prasad Pandit <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-04-08scsi: core: Fix handling of SCMD_FAIL_IF_RECOVERINGBart Van Assche1-4/+3
There is code in the SCSI core that sets the SCMD_FAIL_IF_RECOVERING flag but there is no code that clears this flag. Instead of only clearing SCMD_INITIALIZED in scsi_end_request(), clear all flags. It is never necessary to preserve any command flags inside scsi_end_request(). Cc: [email protected] Fixes: 310bcaef6d7e ("scsi: core: Support failing requests while recovering") Signed-off-by: Bart Van Assche <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-04-08scsi: megaraid: Indent Kconfig option help textPrasad Pandit1-57/+56
Fix indentation of megaraid options help text by adding leading spaces. Generally help text is indented by couple of spaces more beyond the leading tab <\t> character. Signed-off-by: Prasad Pandit <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-04-08drm/xe: Capture GuC CT snapshot when stoppedMatthew Brost1-1/+1
It is useful capture the GuC CT snapshot if the GuC CT has been forcefully put into the stopped state. Enable snapshot capture when in this state. Cc: Rodrigo Vivi <[email protected]> Signed-off-by: Matthew Brost <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/xe: Always capture exec queues on snapshotMatthew Brost3-25/+6
Always capture exec queues on snapshot regardless if exec queue has pending jobs or not. Having jobs or not does indicate whether the exec queue capture is useful. Example bugs that would not be easily detected by skipping capture when pending job list is empty: - Jobs pending on exec queue have dependencies - Leaking exec queue refs - GuC protocol issues (i.e. losing G2H) In addition to above bugs, in general it just useful to see every exec queue registered with the GuC and its state. Cc: Rodrigo Vivi <[email protected]> Signed-off-by: Matthew Brost <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08igc: Remove redundant runtime resume for ethtool opsBjorn Helgaas1-17/+0
8c5ad0dae93c ("igc: Add ethtool support") added ethtool_ops.begin() and .complete(), which used pm_runtime_get_sync() to resume suspended devices before any ethtool_ops callback and allow suspend after it completed. Subsequently, f32a21376573 ("ethtool: runtime-resume netdev parent before ethtool ioctl ops") added pm_runtime_get_sync() in the dev_ethtool() path, so the device is resumed before any ethtool_ops callback even if the driver didn't supply a .begin() callback. Remove the .begin() and .complete() callbacks, which are now redundant because dev_ethtool() already resumes the device. Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Simon Horman <[email protected]> Tested-by: Naama Meir <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2024-04-08igb: Remove redundant runtime resume for ethtool_opsBjorn Helgaas1-15/+0
749ab2cd1270 ("igb: add basic runtime PM support") added ethtool_ops.begin() and .complete(), which used pm_runtime_get_sync() to resume suspended devices before any ethtool_ops callback and allow suspend after it completed. Subsequently, f32a21376573 ("ethtool: runtime-resume netdev parent before ethtool ioctl ops") added pm_runtime_get_sync() in the dev_ethtool() path, so the device is resumed before any ethtool_ops callback even if the driver didn't supply a .begin() callback. Remove the .begin() and .complete() callbacks, which are now redundant because dev_ethtool() already resumes the device. Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Simon Horman <[email protected]> Tested-by: Sunitha Mekala <[email protected]> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <[email protected]>
2024-04-08e1000e: Remove redundant runtime resume for ethtool_opsBjorn Helgaas1-56/+6
e60b22c5b7e5 ("e1000e: fix accessing to suspended device") added ethtool_ops.begin() and .complete(), which used pm_runtime_get_sync() to resume suspended devices before any ethtool_ops callback and allow suspend after it completed. 3ef672ab1862 ("e1000e: ethtool unnecessarily takes device out of RPM suspend") removed ethtool_ops.begin() and .complete() and instead did pm_runtime_get_sync() only in the individual ethtool_ops callbacks that access device registers. Subsequently, f32a21376573 ("ethtool: runtime-resume netdev parent before ethtool ioctl ops") added pm_runtime_get_sync() in the dev_ethtool() path, so the device is resumed before *any* ethtool_ops callback, as it was before 3ef672ab1862. Remove most runtime resumes from ethtool_ops, which are now redundant because the resume has already been done by dev_ethtool(). This is essentially a revert of 3ef672ab1862 ("e1000e: ethtool unnecessarily takes device out of RPM suspend"). There are a couple subtleties: - Prior to 3ef672ab1862, the device was resumed only for the duration of a single ethtool callback. 3ef672ab1862 changed e1000_set_phys_id() so the device was resumed for ETHTOOL_ID_ACTIVE and remained resumed until a subsequent callback for ETHTOOL_ID_INACTIVE. Preserve that part of 3ef672ab1862 so the device will not be runtime suspended while in the ETHTOOL_ID_ACTIVE state. - 3ef672ab1862 added "if (!pm_runtime_suspended())" in before reading the STATUS register in e1000_get_settings(). This was racy and is now unnecessary because dev_ethtool() has resumed the device already, so revert that. Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Simon Horman <[email protected]> Tested-by: Naama Meir <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2024-04-08scsi: cxlflash: Fix function pointer cast warningsArnd Bergmann5-46/+38
Calling a function through an incompatible pointer type causes breaks kcfi, so clang warns about the assignments: drivers/scsi/cxlflash/main.c:3498:3: error: cast from 'int (*)(struct cxlflash_cfg *, struct ht_cxlflash_lun_provision *)' to 'hioctl' (aka 'int (*)(struct cxlflash_cfg *, void *)') converts to incompatible function type [-Werror,-Wcast-function-type-strict] 3498 | (hioctl)cxlflash_lun_provision }, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/scsi/cxlflash/main.c:3500:3: error: cast from 'int (*)(struct cxlflash_cfg *, struct ht_cxlflash_afu_debug *)' to 'hioctl' (aka 'int (*)(struct cxlflash_cfg *, void *)') converts to incompatible function type [-Werror,-Wcast-function-type-strict] 3500 | (hioctl)cxlflash_afu_debug }, | ^~~~~~~~~~~~~~~~~~~~~~~~~~ Address these by changing the functions to have the correct type and replace the function pointer cast with a cast of its argument. Link: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Arnd Bergmann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-04-08scsi: ufs: qcom: Add sanity checks for gear/lane values during ICC scalingManivannan Sadhasivam1-0/+10
Let's add the checks to warn the user if the ICC scaling is not supported for the gear/lane values and also fallback to the max value if that's the case. Signed-off-by: Manivannan Sadhasivam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Andrew Halaney <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2024-04-08scsi: ufs: qcom: Add missing interconnect bandwidth values for Gear 5Manivannan Sadhasivam1-1/+7
These entries are necessary to scale the interconnect bandwidth while operating in Gear 5. Cc: Amit Pundir <[email protected]> Fixes: 03ce80a1bb86 ("scsi: ufs: qcom: Add support for scaling interconnects") Tested-by: Amit Pundir <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-04-08drm/xe/uapi: Restore flags VM_BIND_FLAG_READONLY and VM_BIND_FLAG_IMMEDIATEFrancois Dugast2-2/+15
The commit 84a1ed5e6756 ("drm/xe/uapi: Remove unused flags") is partially reverted. At the time, flags not used by user space were removed during cleanup. Some flags now needed by the compute runtime are brought back in this commit: - DRM_XE_VM_BIND_FLAG_READONLY is used to write protect kernel ISA thus preventing accidental overwrites. - DRM_XE_VM_BIND_FLAG_IMMEDIATE is used to trigger mapping at the time of binding in order to prevent faulting at execution time. The changes in the compute runtime are ready and approved, see link below. v2: Include a link to the PR in the commit message (Matthew Brost) v3: Update kernel doc and improve commit message (Lucas De Marchi) Cc: Mateusz Jablonski <[email protected]> Cc: Michal Mrozek <[email protected]> Cc: Matthew Brost <[email protected]> Cc: Lucas De Marchi <[email protected]> Link: https://github.com/intel/compute-runtime/pull/717 Signed-off-by: Francois Dugast <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Lucas De Marchi <[email protected]>
2024-04-08drm/xe: Remove dead clock codeLucas De Marchi2-6/+1
xe_gt_clock_cycles_to_ns() is not called from anywhere after PMU handling was removed in commit 90a8b23f9b85 ("drm/xe/pmu: Remove PMU from Xe till uapi is finalized"). Drop it. Reviewed-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Lucas De Marchi <[email protected]>
2024-04-08drm/i915/vrr: Disable VRR when using bigjoinerVille Syrjälä1-0/+7
All joined pipes share the same transcoder/timing generator. Currently we just do the commits per-pipe, which doesn't really work if we need to change switch between non-VRR and VRR timings generators on the fly, or even when sending the push to the transcoder. For now just disable VRR when bigjoiner is needed. Cc: [email protected] Tested-by: Vidya Srinivas <[email protected]> Reviewed-by: Vandita Kulkarni <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Ville Syrjälä <[email protected]> (cherry picked from commit f9d5e51db65652dbd8a2102fd7619440e3599fd2) Signed-off-by: Rodrigo Vivi <[email protected]>
2024-04-08drm/i915: Disable live M/N updates when using bigjoinerVille Syrjälä1-1/+5
All joined pipes share the same transcoder/timing generator. Currently we just do the commits per-pipe, which doesn't really work if we need to change the timings at the same time. For now just disable live M/N updates when bigjoiner is needed. Cc: [email protected] Tested-by: Vidya Srinivas <[email protected]> Reviewed-by: Arun R Murthy <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Ville Syrjälä <[email protected]> (cherry picked from commit ef79820db723a2a7c229a7251c12859e7e25a247) Signed-off-by: Rodrigo Vivi <[email protected]>
2024-04-08drm/i915: Disable port sync when bigjoiner is usedVille Syrjälä1-0/+5
The current modeset sequence can't handle port sync and bigjoiner at the same time. Refuse port sync when bigjoiner is needed, at least until we fix the modeset sequence. v2: Add a FIXME (Vandite) Cc: [email protected] Tested-by: Vidya Srinivas <[email protected]> Reviewed-by: Vandita Kulkarni <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Ville Syrjälä <[email protected]> (cherry picked from commit b37e1347b991459c38c56ec2476087854a4f720b) Signed-off-by: Rodrigo Vivi <[email protected]>
2024-04-08drm/i915/psr: Disable PSR when bigjoiner is usedVille Syrjälä1-0/+11
Bigjoiner seem to be causing all kinds of grief to the PSR code currently. I don't believe there is any hardware issue but the code simply not handling this correctly. For now just disable PSR when bigjoiner is needed. Cc: [email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Arun R Murthy <[email protected]> Acked-by: Jouni Högander <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> (cherry picked from commit 372fa0c79d3f289f813d8001e0a8a96d1011826c) Signed-off-by: Rodrigo Vivi <[email protected]>
2024-04-08drm/i915/guc: Fix the fix for reset lock confusionJohn Harrison2-14/+13
The previous fix for the circlular lock splat about the busyness worker wasn't quite complete. Even though the reset-in-progress flag is cleared at the start of intel_uc_reset_finish, the entire function is still inside the reset mutex lock. Not sure why the patch appeared to fix the issue both locally and in CI. However, it is now back again. There is a further complication that the wedge code path within intel_gt_reset() jumps around so much that it results in nested reset_prepare/_finish calls. That is, the call sequence is: intel_gt_reset | reset_prepare | __intel_gt_set_wedged | | reset_prepare | | reset_finish | reset_finish The nested finish means that even if the clear of the in-progress flag was moved to the end of _finish, it would still be clear for the entire second call. Surprisingly, this does not seem to be causing any other problems at present. As an aside, a wedge on fini does not call the finish functions at all. The reset_in_progress flag is left set (twice). So instead of trying to cancel the worker anywhere at all in the reset path, just add a cancel to intel_guc_submission_fini instead. Note that it is not a problem if the worker is still active during a reset. Either it will run before the reset path starts locking things and will simply block the reset code for a tiny amount of time. Or it will run after the locks have been acquired and will early exit due to the try-lock. Also, do not use the reset-in-progress flag to decide whether a synchronous cancel is safe (from a lockdep perspective) or not. Instead, use the actual reset mutex state (both the genuine one and the custom rolled BACKOFF one). Fixes: 0e00a8814eec ("drm/i915/guc: Avoid circular locking issue on busyness flush") Signed-off-by: John Harrison <[email protected]> Cc: Zhanjun Dong <[email protected]> Cc: John Harrison <[email protected]> Cc: Andi Shyti <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Nirmoy Das <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Umesh Nerlige Ramappa <[email protected]> Cc: Andrzej Hajda <[email protected]> Cc: Matt Roper <[email protected]> Cc: Jonathan Cavitt <[email protected]> Cc: Prathap Kumar Valsan <[email protected]> Cc: Alan Previn <[email protected]> Cc: Madhumitha Tolakanahalli Pradeep <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Cc: Ashutosh Dixit <[email protected]> Cc: Dnyaneshwar Bhadane <[email protected]> Reviewed-by: Nirmoy Das <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 3563d855312acedcd445a3767f0cb07906f1c26f) Signed-off-by: Rodrigo Vivi <[email protected]>
2024-04-08drm/i915/hdcp: Fix get remote hdcp capability functionSuraj Kandpal1-1/+4
HDCP 1.x capability needs to be checked even if setup is not HDCP 2.x capable. --v2 -Assign hdcp_capable and hdcp2_capable to false [Chaitanya] --v3 -Fix variable assignment [Chaitanya] Fixes: 813cca96e4ac ("drm/i915/hdcp: Add new remote capability check shim function") Signed-off-by: Suraj Kandpal <[email protected]> Reviewed-by: Chaitanya Kumar Borah <[email protected]> Signed-off-by: Animesh Manna <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 6809f9246d43f7cb07310ca6a3deb7aa1c0ea938) Signed-off-by: Rodrigo Vivi <[email protected]>
2024-04-08drm/i915/cdclk: Fix voltage_level programming edge caseVille Syrjälä1-10/+27
Currently we only consider the relationship of the old and new CDCLK frequencies when determining whether to do the repgramming from intel_set_cdclk_pre_plane_update() or intel_set_cdclk_post_plane_update(). It is technically possible to have a situation where the CDCLK frequency is decreasing, but the voltage_level is increasing due a DDI port. In this case we should bump the voltage level already in intel_set_cdclk_pre_plane_update() (so that the voltage_level will have been increased by the time the port gets enabled), while leaving the CDCLK frequency unchanged (as active planes/etc. may still depend on it). We can then reduce the CDCLK frequency to its final value from intel_set_cdclk_post_plane_update(). In order to handle that correctly we shall construct a suitable amalgam of the old and new cdclk states in intel_set_cdclk_pre_plane_update(). And we can simply call intel_set_cdclk() unconditionally in both places as it will not do anything if nothing actually changes vs. the current hw state. v2: Handle cdclk_state->disable_pipes v3: Only synchronize the cd2x update against the pipe's vblank when the cdclk frequency is changing during the current commit phase (Gustavo) Cc: [email protected] Cc: Gustavo Sousa <[email protected]> Reviewed-by: Uma Shankar <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 34d127e2bdef73a923aa0dcd95cbc3257ad5af52) Signed-off-by: Rodrigo Vivi <[email protected]>
2024-04-08drm/i915/cdclk: Fix CDCLK programming order when pipes are activeVille Syrjälä2-2/+8
Currently we always reprogram CDCLK from the intel_set_cdclk_pre_plane_update() when using squash/crawl. The code only works correctly for the cd2x update or full modeset cases, and it was simply never updated to deal with squash/crawl. If the CDCLK frequency is increasing we must reprogram it before we do anything else that might depend on the new higher frequency, and conversely we must not decrease the frequency until everything that might still depend on the old higher frequency has been dealt with. Since cdclk_state->pipe is only relevant when doing a cd2x update we can't use it to determine the correct sequence during squash/crawl. To that end introduce cdclk_state->disable_pipes which simply indicates that we must perform the update while the pipes are disable (ie. during intel_set_cdclk_pre_plane_update()). Otherwise we use the same old vs. new CDCLK frequency comparsiong as for cd2x updates. The only remaining problem case is when the voltage_level needs to increase due to a DDI port, but the CDCLK frequency is decreasing (and not all pipes are being disabled). The current approach will not bump the voltage level up until after the port has already been enabled, which is too late. But we'll take care of that case separately. v2: Don't break the "must disable pipes case" v3: Keep the on stack 'pipe' for future use Cc: [email protected] Fixes: d62686ba3b54 ("drm/i915/adl_p: CDCLK crawl support for ADL") Reviewed-by: Uma Shankar <[email protected]> Reviewed-by: Gustavo Sousa <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 3aecee90ac12a351905f12dda7643d5b0676d6ca) Signed-off-by: Rodrigo Vivi <[email protected]>
2024-04-08EDAC/skx_common: Allow decoding of SGX addressesQiuxu Zhuo1-1/+1
There are no "struct page" associations with SGX pages, causing the check pfn_to_online_page() to fail. This results in the inability to decode the SGX addresses and warning messages like: Invalid address 0x34cc9a98840 in IA32_MC17_ADDR Add an additional check to allow the decoding of the error address and to skip the warning message, if the error address is an SGX address. Fixes: 1e92af09fab1 ("EDAC/skx_common: Filter out the invalid address") Signed-off-by: Qiuxu Zhuo <[email protected]> Signed-off-by: Tony Luck <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-04-08remoteproc: zynqmp: Add coredump supportLeonard Crestez1-0/+5
Supporting remoteproc coredump requires the platform-specific driver to register coredump segments to be dumped. Do this by calling rproc_coredump_add_segment for every carveout. Also call rproc_coredump_set_elf_info when then rproc is created. If the ELFCLASS parameter is not provided then coredump fails with an error. Other drivers seem to pass EM_NONE for the machine argument but for me this shows a warning in gdb. Pass EM_ARM because this is an ARM R5. Signed-off-by: Leonard Crestez <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mathieu Poirier <[email protected]>
2024-04-08platform/x86: asus-wmi: cleanup main struct to avoid some holesLuke D. Jones1-11/+6
Reorganises some attr-available calls to remove a few unrequired booleans in the main driver struct which combined with some reorganisation prevents a series of large holes seen with pahole. Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Luke D. Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2024-04-08platform/x86: asus-wmi: Add support for MCU powersaveLuke D. Jones1-0/+50
Add support for an MCU powersave WMI call. This is intended to set the MCU in to a low-power mode when sleeping. This mode can cut sleep power use by around half. Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Luke D. Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2024-04-08platform/x86: asus-wmi: ROG Ally increase wait time, allow MCU powersaveLuke D. Jones1-10/+2
The previous work to allow the MCU to be resumed correctly after sleep and resume tried to take the shortest possible time. However as work continues in various other parts of the s2idle subsystems it has shown that it wasn't entirely reliable. If the MCU disable/enable call is done correctly the MCU fully removes its USB endpoints, and this shows as a full USB device reconnection on resume. When we tried to short this as much as possible sometimes the MCU doesn't get to complete what it needs to do before going to low-power and this affected the reconnection. Through trial it is found that the minimum time required is approx 1200ms to allow a proper disconnect and disable, and the same amount of time on resume is required to prevent a rapid disconnect/reconnect happening on seemingly random occasions. To be safe the time is now 1500ms for msleep. Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Luke D. Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2024-04-08platform/x86: asus-wmi: adjust formatting of ppt-<name>() functionsLuke D. Jones1-14/+7
Shift the call to dev_get_drvdata() up to top of the function block in all of the ppt_<name>() functions as part of a minor cleanup. Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Luke D. Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2024-04-08platform/x86: asus-wmi: store a min default for ppt optionsLuke D. Jones1-28/+99
Laptops with any of the ppt or nv tunables default to the minimum setting on boot so we can safely assume a stored value is correct. This patch adds storing of those values in the local struct, and enables reading of those values back. To prevent creating a series of byte holes in the struct the "<name>_available" bool is removed and `asus_sysfs_is_visible()` uses the `ASUS_WMI_DEVID_<name>` directly. Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Luke D. Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2024-04-08platform/x86: asus-wmi: support toggling POST soundLuke D. Jones1-0/+51
Add support for toggling the BIOS POST sound on some ASUS laptops. Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Luke D. Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2024-04-08platform/x86: asus-wmi: add support variant of TUF RGBLuke D. Jones1-4/+9
Adds support for a second TUF RGB wmi call that some versions of the TUF laptop come with. Also adjusts existing support to select whichever is available. Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Luke D. Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2024-04-08platform/x86: asus-wmi: add support for Vivobook GPU MUXLuke D. Jones1-9/+13
Add support for the Vivobook dgpu MUX available on the ASUS Viviobook and some of the other ranges (Zen). This MUX functions exactly the same as the existing ROG MUX support so the existing functionality now detects which MUX is available and uses that for control. Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Luke D. Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2024-04-08platform/x86: asus-wmi: add support for 2024 ROG Mini-LEDLuke D. Jones1-10/+86
Support the 2024 mini-led backlight and adjust the related functions to select the relevant dev-id. Also add `available_mini_led_mode` to the platform sysfs since the available mini-led levels can be different. Reviewed-by: Ilpo Järvinen <[email protected]> signed-off-by: Luke D. Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2024-04-08drm/msm/dp: Account for the timeout in wait_hpd_asserted() callbackDouglas Anderson3-6/+9
The DP wait_hpd_asserted() callback is passed a timeout which indicates how long we should wait for HPD. This timeout was being ignored in the MSM DP implementation and instead a hardcoded 500 ms timeout was used. Fix it to use the proper timeout. As part of this we move the hardcoded 500 ms number into the AUX transfer function, which isn't given a timeout. The wait in the AUX transfer function will be removed in a future commit. Fixes: e2969ee30252 ("drm/msm/dp: move of_dp_aux_populate_bus() to eDP probe()") Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/583128/ Link: https://lore.kernel.org/r/20240315143621.v2.2.I7758d18a1773821fa39c034b16a12ef3f18a51ee@changeid Signed-off-by: Dmitry Baryshkov <[email protected]>
2024-04-08drm/msm/dp: Avoid a long timeout for AUX transfer if nothing connectedDouglas Anderson3-0/+25
As documented in the description of the transfer() function of "struct drm_dp_aux", the transfer() function can be called at any time regardless of the state of the DP port. Specifically if the kernel has the DP AUX character device enabled and userspace accesses "/dev/drm_dp_auxN" directly then the AUX transfer function will be called regardless of whether a DP device is connected. For eDP panels we have a special rule where we wait (with a 5 second timeout) for HPD to go high. This rule was important before all panels drivers were converted to call wait_hpd_asserted() and actually can be removed in a future commit. For external DP devices we never checked for HPD. That means that trying to access the DP AUX character device (AKA `hexdump -C /dev/drm_dp_auxN`) would very, very slowly timeout. Specifically on my system: $ time hexdump -C /dev/drm_dp_aux0 hexdump: /dev/drm_dp_aux0: Connection timed out real 0m8.200s We want access to the drm_dp_auxN character device to fail faster than 8 seconds when no DP cable is plugged in. Let's add a test to make transfers fail right away if a device isn't plugged in. Rather than testing the HPD line directly, we have the dp_display module tell us when AUX transfers should be enabled so we can handle cases where HPD is signaled out of band like with Type C. Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support") Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/583127/ Link: https://lore.kernel.org/r/20240315143621.v2.1.I16aff881c9fe82b5e0fc06ca312da017aa7b5b3e@changeid Signed-off-by: Dmitry Baryshkov <[email protected]>
2024-04-08drm/msm/dpu: add current resource allocation to dumped stateDmitry Baryshkov4-0/+78
Provide atomic_print_state callback to the DPU's private object. This way the debugfs/dri/0/state will also include RM's internal state. Example output (RB5 board, HDMI and writeback encoder enabled) resource mapping: pingpong=31 36 # # # # - - - - - mixer=31 36 # # # # - ctl=# # 31 36 # # dspp=# # # # dsc=# # # # - - cdm=# Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/579648/ Link: https://lore.kernel.org/r/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.