aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2024-08-22thunderbolt: Add optional voltage offset range for receiver lane marginingRene Sapiens4-0/+85
Add optional extended voltage offset range support for software and hardware margining as defined by the USB4 specification. If supported, it can be enabled like below: # cd /sys/kernel/debug/thunderbolt/ROUTER/portX/margining/ # echo Y > optional_voltage_offset Signed-off-by: Rene Sapiens <[email protected]> Co-developed-by: R Kannappan <[email protected]> Signed-off-by: R Kannappan <[email protected]> Co-developed-by: Aapo Vienamo <[email protected]> Signed-off-by: Aapo Vienamo <[email protected]> Signed-off-by: Mika Westerberg <[email protected]>
2024-08-22thunderbolt: Consolidate margining parameters into a structureRene Sapiens4-43/+78
Consolidate the hardware and software margining parameters into a single structure to reduce the number of parameters passed to the margining functions. Signed-off-by: Rene Sapiens <[email protected]> Co-developed-by: Aapo Vienamo <[email protected]> Signed-off-by: Aapo Vienamo <[email protected]> Signed-off-by: Mika Westerberg <[email protected]>
2024-08-22thunderbolt: Add missing usb4_port_sb_read() to usb4_port_sw_margin()Aapo Vienamo3-7/+13
Synchronize the operation completion by reading back the software margining operation completion metadata into margining->results. Signed-off-by: Aapo Vienamo <[email protected]> Co-developed-by: R Kannappan <[email protected]> Signed-off-by: R Kannappan <[email protected]> Co-developed-by: Rene Sapiens <[email protected]> Signed-off-by: Rene Sapiens <[email protected]> Signed-off-by: Mika Westerberg <[email protected]>
2024-08-22dma-mapping: direct calls for dma-iommuLeon Romanovsky3-70/+37
Directly call into dma-iommu just like we have been doing for dma-direct for a while. This avoids the indirect call overhead for IOMMU ops and removes the need to have DMA ops entirely for many common configurations. Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Acked-by: Greg Kroah-Hartman <[email protected]> Acked-by: Robin Murphy <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2024-08-21drm/xe: fixup xe_alloc_pf_queueMatthew Auld1-1/+4
kzalloc expects number of bytes, therefore we should convert the number of dw into bytes, otherwise we are likely just accessing beyond the array causing all kinds of carnage. Also fixup the error handling while we are here. v2: - Prefer kcalloc (dim) Fixes: 3338e4f90c14 ("drm/xe: Use topology to determine page fault queue size") Signed-off-by: Matthew Auld <[email protected]> Cc: Stuart Summers <[email protected]> Cc: Matthew Brost <[email protected]> Reviewed-by: Nirmoy Das <[email protected]> Signed-off-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-08-22wifi: rtw89: coex: Add new Wi-Fi role format condition for function usingChing-Te Ku1-19/+71
There are many features need the information those record at Wi-Fi role structure. Implement the corresponding code for using. Signed-off-by: Ching-Te Ku <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected]
2024-08-22wifi: rtw89: coex: Bluetooth hopping map for Wi-Fi role version 7Ching-Te Ku1-0/+18
To get Wi-Fi channel & bandwidth information from new Wi-Fi role format. Bluetooth will negotiate which channel to do TX/RX with connected device. And Bluetooth will maintain a hopping map, that describe the usable channels. To avoid the interference from Wi-Fi 2.4GHz/Bluetooth each other, Bluetooth must not to hop into Wi-Fi channel. Signed-off-by: Ching-Te Ku <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected]
2024-08-22wifi: rtw89: coex: Update Wi-Fi role info version 7Ching-Te Ku4-24/+339
This version included new introduced Wi-Fi DBCC information related to WiFi role. Signed-off-by: Ching-Te Ku <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected]
2024-08-21drm/xe: Invalidate media_gt TLBs in PT codeMatthew Brost1-19/+80
Testing on LNL has shown media GT's TLBs need to be invalidated via the GuC, update PT code appropriately. v2: - Do dma_fence_get before first call of invalidation_fence_init (Himal) - No need to check for valid chain fence (Himal) Fixes: 3330361543fc ("drm/xe/lnl: Add LNL platform definition") Signed-off-by: Matthew Brost <[email protected]> Reviewed-by: Himal Prasad Ghimiray <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-08-22wifi: rtw89: coex: Update report version of Wi-Fi firmware 0.29.90.0 for ↵Ching-Te Ku2-1/+162
RTL8852BT Add the firmware related version code for RTL8852BT version 0.29.90.0. And add the version 7 report control structure format. Firmware will collect counters like mailbox count, RF on/off count, and some Bluetooth related counters into this structure and pass to driver periodically. It will help to understand how the firmware mechanism working. Signed-off-by: Ching-Te Ku <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected]
2024-08-22wifi: rtw89: limit the PPDU length for VHT rate to 0x40000Chia-Yuan Li2-0/+11
If the PPDU length for VHT rate exceeds 0x40000, calculating the PSDU length will overflow. TMAC will determine the length to be too small and as a result, all packets will be sent as ZLD (Zero Length Delimiter). Fixes: 5f7e92c59b8e ("wifi: rtw89: 8852b: set AMSDU limit to 5000") Signed-off-by: Chia-Yuan Li <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected]
2024-08-22wifi: rtw89: debugfs: support multiple adapters debuggingPing-Ke Shih4-87/+100
The rtw89 uses debugfs to access registers and driver states. To get a range of registers, the range value is set and stored to a variable, and get the set of register values by the stored range. However, the variable is a static global variable, which multiple adapters will be a problem, so move the variable to adapter context rtw89_dev. Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected]
2024-08-21Merge branch '100GbE' of ↵Jakub Kicinski3-46/+26
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2024-08-20 (ice) This series contains updates to ice driver only. Maciej fixes issues with Rx data path on architectures with PAGE_SIZE >= 8192; correcting page reuse usage and calculations for last offset and truesize. Michal corrects assignment of devlink port number to use PF id. * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: ice: use internal pf id instead of function number ice: fix truesize operations for PAGE_SIZE >= 8192 ice: fix ICE_LAST_OFFSET formula ice: fix page reuse when PAGE_SIZE is over 8k ==================== Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-08-21net: xilinx: axienet: Add statistics supportSean Anderson2-3/+407
Add support for reading the statistics counters, if they are enabled. The counters may be 64-bit, but we can't detect this statically as there's no ability bit for it and the counters are read-only. Therefore, we assume the counters are 32-bits by default. To ensure we don't miss an overflow, we read all counters at 13-second intervals. This should be often enough to ensure the bytes counters don't wrap at 2.5 Gbit/s. Another complication is that the counters may be reset when the device is reset (depending on configuration). To ensure the counters persist across link up/down (including suspend/resume), we maintain our own versions along with the last counter value we saw. Because we might wait up to 100 ms for the reset to complete, we use a mutex to protect writing hw_stats. We can't sleep in ndo_get_stats64, so we use a seqlock to protect readers. We don't bother disabling the refresh work when we detect 64-bit counters. This is because the reset issue requires us to read hw_stat_base and reset_in_progress anyway, which would still require the seqcount. And I don't think skipping the task is worth the extra bookkeeping. We can't use the byte counters for either get_stats64 or get_eth_mac_stats. This is because the byte counters include everything in the frame (destination address to FCS, inclusive). But rtnl_link_stats64 wants bytes excluding the FCS, and ethtool_eth_mac_stats wants to exclude the L2 overhead (addresses and length/type). It might be possible to calculate the byte values Linux expects based on the frame counters, but I think it is simpler to use the existing software counters. get_ethtool_stats is implemented for nonstandard statistics. This includes the aforementioned byte counters, VLAN and PFC frame counters, and user-defined (e.g. with custom RTL) counters. Signed-off-by: Sean Anderson <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-08-21net: xilinx: axienet: Report RxRject as rx_droppedSean Anderson1-1/+1
The Receive Frame Rejected interrupt is asserted whenever there was a receive error (bad FCS, bad length, etc.) or whenever the frame was dropped due to a mismatched address. So this is really a combination of rx_otherhost_dropped, rx_length_errors, rx_frame_errors, and rx_crc_errors. Mismatched addresses are common and aren't really errors at all (much like how fragments are normal on half-duplex links). To avoid confusion, report these events as rx_dropped. This better reflects what's going on: the packet was received by the MAC but dropped before being processed. Signed-off-by: Sean Anderson <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Reviewed-by: Radhey Shyam Pandey <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-08-21bnxt_en: Fix double DMA unmapping for XDP_REDIRECTSomnath Kotur1-5/+0
Remove the dma_unmap_page_attrs() call in the driver's XDP_REDIRECT code path. This should have been removed when we let the page pool handle the DMA mapping. This bug causes the warning: WARNING: CPU: 7 PID: 59 at drivers/iommu/dma-iommu.c:1198 iommu_dma_unmap_page+0xd5/0x100 CPU: 7 PID: 59 Comm: ksoftirqd/7 Tainted: G W 6.8.0-1010-gcp #11-Ubuntu Hardware name: Dell Inc. PowerEdge R7525/0PYVT1, BIOS 2.15.2 04/02/2024 RIP: 0010:iommu_dma_unmap_page+0xd5/0x100 Code: 89 ee 48 89 df e8 cb f2 69 ff 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 31 f6 31 ff 45 31 c0 e9 ab 17 71 00 <0f> 0b 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 RSP: 0018:ffffab1fc0597a48 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff99ff838280c8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffab1fc0597a78 R08: 0000000000000002 R09: ffffab1fc0597c1c R10: ffffab1fc0597cd3 R11: ffff99ffe375acd8 R12: 00000000e65b9000 R13: 0000000000000050 R14: 0000000000001000 R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffff9a06efb80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000565c34c37210 CR3: 00000005c7e3e000 CR4: 0000000000350ef0 ? show_regs+0x6d/0x80 ? __warn+0x89/0x150 ? iommu_dma_unmap_page+0xd5/0x100 ? report_bug+0x16a/0x190 ? handle_bug+0x51/0xa0 ? exc_invalid_op+0x18/0x80 ? iommu_dma_unmap_page+0xd5/0x100 ? iommu_dma_unmap_page+0x35/0x100 dma_unmap_page_attrs+0x55/0x220 ? bpf_prog_4d7e87c0d30db711_xdp_dispatcher+0x64/0x9f bnxt_rx_xdp+0x237/0x520 [bnxt_en] bnxt_rx_pkt+0x640/0xdd0 [bnxt_en] __bnxt_poll_work+0x1a1/0x3d0 [bnxt_en] bnxt_poll+0xaa/0x1e0 [bnxt_en] __napi_poll+0x33/0x1e0 net_rx_action+0x18a/0x2f0 Fixes: 578fcfd26e2a ("bnxt_en: Let the page pool manage the DMA mapping") Reviewed-by: Andy Gospodarek <[email protected]> Reviewed-by: Kalesh AP <[email protected]> Signed-off-by: Somnath Kotur <[email protected]> Signed-off-by: Michael Chan <[email protected]> Reviewed-by: Jacob Keller <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-08-21ice: Fix a 32bit bugDan Carpenter1-3/+3
BIT() is unsigned long but ->pu.flg_msk and ->pu.flg_val are u64 type. On 32 bit systems, unsigned long is a u32 and the mismatch between u32 and u64 will break things for the high 32 bits. Fixes: 9a4c07aaa0f5 ("ice: add parser execution main loop") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Alexander Lobakin <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-08-21net: dsa: sja1105: Simplify with scoped for each OF child loopJinjie Ruan1-8/+2
Use scoped for_each_available_child_of_node_scoped() when iterating over device nodes to make code a bit simpler. Signed-off-by: Jinjie Ruan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-08-21net: dsa: ocelot: Simplify with scoped for each OF child loopJinjie Ruan1-4/+1
Use scoped for_each_available_child_of_node_scoped() when iterating over device nodes to make code a bit simpler. Signed-off-by: Jinjie Ruan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-08-21nfc: pn533: Avoid -Wflex-array-member-not-at-end warningsGustavo A. R. Silva1-1/+0
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are getting ready to enable it, globally. Remove unnecessary flex-array member `data[]`, and with this fix the following warnings: drivers/nfc/pn533/usb.c:268:38: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/nfc/pn533/usb.c:275:38: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] Signed-off-by: Gustavo A. R. Silva <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/ZsPw7+6vNoS651Cb@elsanto Signed-off-by: Jakub Kicinski <[email protected]>
2024-08-22Merge tag 'platform-drivers-x86-v6.11-4' of ↵Linus Torvalds4-10/+70
git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 Pull x86 platform driver fixes from Ilpo Järvinen: - ISST: Fix an error-handling corner case - platform/surface: aggregator: Minor corner case fix and new HW support * tag 'platform-drivers-x86-v6.11-4' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: platform/x86: ISST: Fix return value on last invalid resource platform/surface: aggregator: Fix warning when controller is destroyed in probe platform/surface: aggregator_registry: Add support for Surface Laptop 6 platform/surface: aggregator_registry: Add fan and thermal sensor support for Surface Laptop 5 platform/surface: aggregator_registry: Add support for Surface Laptop Studio 2 platform/surface: aggregator_registry: Add support for Surface Laptop Go 3 platform/surface: aggregator_registry: Add Support for Surface Pro 10 platform/x86: asus-wmi: Add quirk for ROG Ally X
2024-08-22HID: hid-playstation: DS4: Update rumble and lightbar togetherMax Staudt1-0/+20
Some 3rd party gamepads expect updates to rumble and lightbar together, and setting one may cancel the other. Let's maximise compatibility by always sending rumble and lightbar updates together, even when only one has been scheduled. Further background reading: - Apparently the PS4 always sends rumble and lightbar updates together: https://eleccelerator.com/wiki/index.php?title=DualShock_4#0x11_2 - 3rd party gamepads may not implement lightbar_blink, and may simply ignore updates with 0x07 set, according to: https://github.com/Ryochan7/DS4Windows/pull/1839 [[email protected]: fix shortlog] Acked-by: Roderick Colenbrander <[email protected]> Signed-off-by: Max Staudt <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2024-08-21PCI: qcom: Use OPP only if the platform supports itManivannan Sadhasivam1-2/+5
With commit 5b6272e0efd5 ("PCI: qcom: Add OPP support to scale performance"), OPP was used to control the interconnect and power domains if the platform supported OPP. Also to maintain the backward compatibility with platforms not supporting OPP but just ICC, the above mentioned commit assumed that if ICC was not available on the platform, it would resort to OPP. Unfortunately, some old platforms don't support either ICC or OPP. On those platforms, resorting to OPP in the absence of ICC throws below errors from OPP core during suspend and resume: qcom-pcie 1c08000.pcie: dev_pm_opp_set_opp: device opp doesn't exist qcom-pcie 1c08000.pcie: _find_key: OPP table not found (-19) Also, it doesn't make sense to invoke the OPP APIs when OPP is not supported by the platform at all. Add a "use_pm_opp" flag to identify whether OPP is supported and use it to control invoking the OPP APIs. Fixes: 5b6272e0efd5 ("PCI: qcom: Add OPP support to scale performance") Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Mayank Rana <[email protected]>
2024-08-21PCI: qcom-ep: Disable MHI RAM data parity error interrupt for SA8775P SoCManivannan Sadhasivam1-0/+13
SA8775P SoC has support for the hardware parity check feature on the MHI RAM (entity that holds MHI registers, etc.) But due to a hardware bug in the parity check logic, the data parity error interrupt is getting generated all the time when using MHI. So the hardware team has suggested disabling the parity check error to work around the hardware bug. Mask the parity error interrupt in PARF_INT_ALL_5_MASK register. Fixes: 58d0d3e032b3 ("PCI: qcom-ep: Add support for SA8775P SOC") Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2024-08-21nvdimm: Remove dead code for ENODEV checking in scan_labels()Li Zhijian1-9/+0
The only way create_namespace_pmem() returns an ENODEV code is if select_pmem_id(nd_region, &uuid) returns ENODEV when its 2nd parameter is a null pointer. However, this is impossible because &uuid is always valid. Furthermore, create_namespace_pmem() is the only user of select_pmem_id(), it's safe to remove the 'return -ENODEV' branch. Signed-off-by: Li Zhijian <[email protected]> Reviewed-by: Ira Weiny <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Ira Weiny <[email protected]>
2024-08-21nvdimm: Fix devs leaks in scan_labels()Li Zhijian1-17/+17
scan_labels() leaks memory when label scanning fails and it falls back to just creating a default "seed" namespace for userspace to configure. Root can force the kernel to leak memory. Allocate the minimum resources unconditionally and release them when unneeded to avoid the memory leak. A kmemleak reports: unreferenced object 0xffff88800dda1980 (size 16): comm "kworker/u10:5", pid 69, jiffies 4294671781 hex dump (first 16 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): [<00000000c5dea560>] __kmalloc+0x32c/0x470 [<000000009ed43c83>] nd_region_register_namespaces+0x6fb/0x1120 [libnvdimm] [<000000000e07a65c>] nd_region_probe+0xfe/0x210 [libnvdimm] [<000000007b79ce5f>] nvdimm_bus_probe+0x7a/0x1e0 [libnvdimm] [<00000000a5f3da2e>] really_probe+0xc6/0x390 [<00000000129e2a69>] __driver_probe_device+0x78/0x150 [<000000002dfed28b>] driver_probe_device+0x1e/0x90 [<00000000e7048de2>] __device_attach_driver+0x85/0x110 [<0000000032dca295>] bus_for_each_drv+0x85/0xe0 [<00000000391c5a7d>] __device_attach+0xbe/0x1e0 [<0000000026dabec0>] bus_probe_device+0x94/0xb0 [<00000000c590d936>] device_add+0x656/0x870 [<000000003d69bfaa>] nd_async_device_register+0xe/0x50 [libnvdimm] [<000000003f4c52a4>] async_run_entry_fn+0x2e/0x110 [<00000000e201f4b0>] process_one_work+0x1ee/0x600 [<000000006d90d5a9>] worker_thread+0x183/0x350 Cc: Dave Jiang <[email protected]> Cc: Ira Weiny <[email protected]> Fixes: 1b40e09a1232 ("libnvdimm: blk labels and namespace instantiation") Suggested-by: Dan Williams <[email protected]> Signed-off-by: Li Zhijian <[email protected]> Reviewed-by: Dan Williams <[email protected]> Reviewed-by: Ira Weiny <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Ira Weiny <[email protected]>
2024-08-21nvdimm: Use of_property_present() and of_property_read_bool()Rob Herring (Arm)2-2/+2
Use of_property_present() and of_property_read_bool() to test property presence and read boolean properties rather than of_(find|get)_property(). This is part of a larger effort to remove callers of of_find_property() and similar functions. of_(find|get)_property() leak the DT struct property and data pointers which is a problem for dynamically allocated nodes which may be freed. Signed-off-by: Rob Herring (Arm) <[email protected]> Reviewed-by: Dave Jiang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Ira Weiny <[email protected]>
2024-08-21drivers:iio:Fix the NULL vs IS_ERR() bug for debugfs_create_dir()Yang Ruibin1-1/+1
The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it. Signed-off-by: Yang Ruibin <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-21drm/i915/display: allow creation of Xe2 ccs framebuffersJuha-Pekka Heikkila3-0/+25
Add I915_FORMAT_MOD_4_TILED_BMG_CCS and I915_FORMAT_MOD_4_TILED_LNL_CCS to possible created modifier for new framebuffer on Xe driver. Signed-off-by: Juha-Pekka Heikkila <[email protected]> Reviewed-by: Mika Kahola <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2024-08-21drm/i915/display: Don't enable decompression on Xe2 with Tile4Juha-Pekka Heikkila1-5/+0
>From now on expect Tile4 not to be using compression Signed-off-by: Juha-Pekka Heikkila <[email protected]> Reviewed-by: Mika Kahola <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2024-08-21iio: sgp40: retain documentation in driverAndreas Klinger1-3/+8
Retain documentation on how the voc index is actually calculated in driver code as it'll be removed in Documentation. This is a follow up on patch "[PATCH] iio: ABI: remove duplicate in_resistance_calibbias" from David. Signed-off-by: Andreas Klinger <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-21thermal/debugfs: Fix the NULL vs IS_ERR() confusion in debugfs_create_dir()Yang Ruibin1-3/+3
The debugfs_create_dir() return value is never NULL, it is either a valid pointer or an error one. Use IS_ERR() to check it. Fixes: 7ef01f228c9f ("thermal/debugfs: Add thermal debugfs information for mitigation episodes") Fixes: 755113d76786 ("thermal/debugfs: Add thermal cooling device debugfs information") Signed-off-by: Yang Ruibin <[email protected]> Link: https://patch.msgid.link/[email protected] [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]>
2024-08-21remoteproc: k3-r5: Delay notification of wakeup eventUdit Kumar1-2/+3
Few times, core1 was scheduled to boot first before core0, which leads to error: 'k3_r5_rproc_start: can not start core 1 before core 0'. This was happening due to some scheduling between prepare and start callback. The probe function waits for event, which is getting triggered by prepare callback. To avoid above condition move event trigger to start instead of prepare callback. Fixes: 61f6f68447ab ("remoteproc: k3-r5: Wait for core0 power-up before powering up core1") Signed-off-by: Udit Kumar <[email protected]> [ Applied wakeup event trigger only for Split-Mode booted rprocs ] Signed-off-by: Beleswar Padhi <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mathieu Poirier <[email protected]>
2024-08-21remoteproc: k3-m4: Add a remoteproc driver for M4F subsystemMartyn Welch3-0/+681
The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in the MCU domain. This core is typically used for safety applications in a stand alone mode. However, some application (non safety related) may want to use the M4F core as a generic remote processor with IPC to the host processor. The M4F core has internal IRAM and DRAM memories and are exposed to the system bus for code and data loading. A remote processor driver is added to support this subsystem, including being able to load and boot the M4F core. Loading includes to M4F internal memories and predefined external code/data memories. The carve outs for external contiguous memory is defined in the M4F device node and should match with the external memory declarations in the M4F image binary. The M4F subsystem has two resets. One reset is for the entire subsystem i.e including the internal memories and the other, a local reset is only for the M4F processing core. When loading the image, the driver first releases the subsystem reset, loads the firmware image and then releases the local reset to let the M4F processing core run. Signed-off-by: Martyn Welch <[email protected]> Signed-off-by: Hari Nagalla <[email protected]> Signed-off-by: Andrew Davis <[email protected]> Tested-by: Wadim Egorov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mathieu Poirier <[email protected]>
2024-08-21remoteproc: k3: Factor out TI-SCI processor control OF get functionAndrew Davis3-54/+28
Building the TSP structure is common for users of the TI-SCI processor control interface. Factor out this function and put it with the rest of the TI-SCI processor control functions. Signed-off-by: Andrew Davis <[email protected]> Tested-by: Wadim Egorov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mathieu Poirier <[email protected]>
2024-08-21drm/xe: Invalidate media_gt TLBsMatthew Brost1-13/+24
Testing on LNL has shown media TLBs need to be invalidated via the GuC, update xe_vm_invalidate_vma appropriately. v2: Fix 2 tile case v3: Include missing local change Fixes: 3330361543fc ("drm/xe/lnl: Add LNL platform definition") Signed-off-by: Matthew Brost <[email protected]> Reviewed-by: Himal Prasad Ghimiray <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-08-21drm/xe: Free job before xe_exec_queue_putMatthew Brost1-1/+2
Free job depends on job->vm being valid, the last xe_exec_queue_put can destroy the VM. Prevent UAF by freeing job before xe_exec_queue_put. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Brost <[email protected]> Reviewed-by: Nirmoy Das <[email protected]> Reviewed-by: Jagmeet Randhawa <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 32a42c93b74c8ca6d0915ea3eba21bceff53042f) Signed-off-by: Rodrigo Vivi <[email protected]>
2024-08-21drm/xe: Drop HW fence pointer to HW fence ctxMatthew Brost3-7/+11
The HW fence ctx objects are not ref counted rather tied to the life of an LRC object. HW fences reference the HW fence ctx, HW fences can outlive LRCs thus resulting in UAF. Drop the HW fence pointer to HW fence ctx rather just store what is needed directly in HW fence. v2: - Fix typo in commit (Ashutosh) - Use snprintf (Ashutosh) Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Brost <[email protected]> Reviewed-by: Ashutosh Dixit <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 60db6f540af9f93144d5039140aa2ed17171d168) Signed-off-by: Rodrigo Vivi <[email protected]>
2024-08-21drm/xe: Fix missing workqueue destroy in xe_gt_pagefaultStuart Summers1-2/+16
On driver reload we never free up the memory for the pagefault and access counter workqueues. Add those destroy calls here. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Stuart Summers <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/c9a951505271dc3a7aee76de7656679f69c11518.1723862633.git.stuart.summers@intel.com (cherry picked from commit 7586fc52b14e0b8edd0d1f8a434e0de2078b7b2b) Signed-off-by: Rodrigo Vivi <[email protected]>
2024-08-21drm/xe: Free job before xe_exec_queue_putMatthew Brost1-1/+2
Free job depends on job->vm being valid, the last xe_exec_queue_put can destroy the VM. Prevent UAF by freeing job before xe_exec_queue_put. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Brost <[email protected]> Reviewed-by: Nirmoy Das <[email protected]> Reviewed-by: Jagmeet Randhawa <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-08-21soc: qcom: pd-mapper: Fix singleton refcountBjorn Andersson1-0/+2
The Qualcomm pd-mapper is a refcounted singleton, but the refcount is never incremented, which means the as soon as any remoteproc instance stops the count will hit 0. At this point the pd-mapper QMI service is stopped, leaving firmware without access to the PD information. Stopping any other remoteproc instances will result in a use-after-free, which best case manifest itself as a refcount underflow: refcount_t: underflow; use-after-free. WARNING: CPU: 1 PID: 354 at lib/refcount.c:87 refcount_dec_and_mutex_lock+0xc4/0x148 ... Call trace: refcount_dec_and_mutex_lock+0xc4/0x148 qcom_pdm_remove+0x40/0x118 [qcom_pd_mapper] ... Fix this by incrementing the refcount, so that the pd-mapper is only torn down when the last remoteproc stops, as intended. Fixes: 1ebcde047c54 ("soc: qcom: add pd-mapper implementation") Signed-off-by: Bjorn Andersson <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2024-08-21s390/zcrypt_msgtype6: Cleanup debug codeHolger Dengler1-22/+15
The dynamic debugging provides function names on request. So remove all explicit function strings. Reviewed-by: Harald Freudenberger <[email protected]> [dengler: fix indent] Signed-off-by: Holger Dengler <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2024-08-21s390/zcrypt_msgtype50: Cleanup debug codeHolger Dengler1-5/+5
The dynamic debugging provides function names on request. So remove all explicit function strings. Reviewed-by: Harald Freudenberger <[email protected]> Signed-off-by: Holger Dengler <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2024-08-21s390/zcrypt_api: Cleanup debug codeHolger Dengler1-16/+13
The dynamic debugging provides function names on request. So remove all explicit function strings. Reviewed-by: Harald Freudenberger <[email protected]> Signed-off-by: Holger Dengler <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2024-08-21s390/ap_queue: Cleanup debug codeHolger Dengler1-10/+10
The dynamic debugging provides function names on request. So remove all explicit function strings. Reviewed-by: Harald Freudenberger <[email protected]> Signed-off-by: Holger Dengler <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2024-08-21s390/ap_bus: Cleanup debug codeHolger Dengler1-22/+20
The dynamic debugging provides function names on request. So remove all explicit function strings. Reviewed-by: Harald Freudenberger <[email protected]> Signed-off-by: Holger Dengler <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2024-08-21s390/ap: Refine AP bus bindings complete processingHarald Freudenberger1-1/+6
With the rework of the AP bus scan and the introduction of a bindings complete completion also the timing until the userspace finally receives a AP bus binding complete uevent had increased. Unfortunately this event triggers some important jobs for preparation of KVM guests, for example the modification of card/queue masks to reassign AP resources to the alternate AP queue device driver (vfio_ap) which is the precondition for building mediated devices which may be a precondition for starting KVM guests using AP resources. This small fix now triggers the check for binding complete each time an AP device driver has registered. With this patch the bindings complete may be posted up to 30s earlier as there is no need to wait for the next AP bus scan any more. Fixes: 778412ab915d ("s390/ap: rearm APQNs bindings complete completion") Signed-off-by: Harald Freudenberger <[email protected]> Reviewed-by: Holger Dengler <[email protected]> Cc: [email protected] Acked-by: Alexander Gordeev <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2024-08-21firmware: qcom: tzmem: disable sdm670 platformRichard Acayan1-0/+1
The Pixel 3a returns 4291821499 (-3145797 or 0xFFCFFFBB) when attempting to load the GPU firmware if tzmem is allowed. Disable it on SDM670 so the GPU can successfully probe. Signed-off-by: Richard Acayan <[email protected]> Acked-by: Bartosz Golaszewski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2024-08-21soc: qcom: pmic_glink: Actually communicate when remote goes downBjorn Andersson1-1/+1
When the pmic_glink state is UP and we either receive a protection- domain (PD) notification indicating that the PD is going down, or that the whole remoteproc is going down, it's expected that the pmic_glink client instances are notified that their function has gone DOWN. This is not what the code does, which results in the client state either not updating, or being wrong in many cases. So let's fix the conditions. Fixes: 58ef4ece1e41 ("soc: qcom: pmic_glink: Introduce base PMIC GLINK driver") Cc: [email protected] Reviewed-by: Heikki Krogerus <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Tested-by: Amit Pundir <[email protected]> Reviewed-by: Johan Hovold <[email protected]> Tested-by: Johan Hovold <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2024-08-21usb: typec: ucsi: Move unregister out of atomic sectionBjorn Andersson2-6/+31
Commit '9329933699b3 ("soc: qcom: pmic_glink: Make client-lock non-sleeping")' moved the pmic_glink client list under a spinlock, as it is accessed by the rpmsg/glink callback, which in turn is invoked from IRQ context. This means that ucsi_unregister() is now called from atomic context, which isn't feasible as it's expecting a sleepable context. An effort is under way to get GLINK to invoke its callbacks in a sleepable context, but until then lets schedule the unregistration. A side effect of this is that ucsi_unregister() can now happen after the remote processor, and thereby the communication link with it, is gone. pmic_glink_send() is amended with a check to avoid the resulting NULL pointer dereference. This does however result in the user being informed about this error by the following entry in the kernel log: ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: failed to send UCSI write request: -5 Fixes: 9329933699b3 ("soc: qcom: pmic_glink: Make client-lock non-sleeping") Cc: [email protected] Reviewed-by: Heikki Krogerus <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Tested-by: Amit Pundir <[email protected]> Reviewed-by: Johan Hovold <[email protected]> Tested-by: Johan Hovold <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.