aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2024-06-06drm/i915/display: include i915_gpu_error.h where neededJani Nikula2-1/+1
Include what you use. With this, we can drop the include from xe compat i915_drv.h. Reviewed-by: Rodrigo Vivi <[email protected]> Acked-by: Rodrigo Vivi <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/a5dbb8d46403761bd8518db45fa71dc55930d3cf.1717004739.git.jani.nikula@intel.com
2024-06-06drm/i915/display: include gt/intel_gt_types.h where neededJani Nikula3-1/+1
Include what you use. We need to move the compat intel_gt_types.h under gt subdir. With this, we can drop the include from xe compat i915_drv.h. Reviewed-by: Rodrigo Vivi <[email protected]> Acked-by: Rodrigo Vivi <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/df73c0934ad21f157714a41b33b81cebd2a523a6.1717004739.git.jani.nikula@intel.com
2024-06-06drm/i915/display: include gem/i915_gem_stolen.h where neededJani Nikula3-1/+1
Include what you use. We need to move the compat i915_gem_stolen.h under gem subdir. With this, we can drop the include from xe compat i915_drv.h. Reviewed-by: Rodrigo Vivi <[email protected]> Acked-by: Rodrigo Vivi <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/6ac3480a8689fda5aaf4007cb604e06e939a03f7.1717004739.git.jani.nikula@intel.com
2024-06-06ata: pata_macio: Fix max_segment_size with PAGE_SIZE == 64KMichael Ellerman1-3/+6
The pata_macio driver advertises a max_segment_size of 0xff00, because the hardware doesn't cope with requests >= 64K. However the SCSI core requires max_segment_size to be at least PAGE_SIZE, which is a problem for pata_macio when the kernel is built with 64K pages. In older kernels the SCSI core would just increase the segment size to be equal to PAGE_SIZE, however since the commit tagged below it causes a warning and the device fails to probe: WARNING: CPU: 0 PID: 26 at block/blk-settings.c:202 .blk_validate_limits+0x2f8/0x35c CPU: 0 PID: 26 Comm: kworker/u4:1 Not tainted 6.10.0-rc1 #1 Hardware name: PowerMac7,2 PPC970 0x390202 PowerMac ... NIP .blk_validate_limits+0x2f8/0x35c LR .blk_alloc_queue+0xc0/0x2f8 Call Trace: .blk_alloc_queue+0xc0/0x2f8 .blk_mq_alloc_queue+0x60/0xf8 .scsi_alloc_sdev+0x208/0x3c0 .scsi_probe_and_add_lun+0x314/0x52c .__scsi_add_device+0x170/0x1a4 .ata_scsi_scan_host+0x2bc/0x3e4 .async_port_probe+0x6c/0xa0 .async_run_entry_fn+0x60/0x1bc .process_one_work+0x228/0x510 .worker_thread+0x360/0x530 .kthread+0x134/0x13c .start_kernel_thread+0x10/0x14 ... scsi_alloc_sdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured Although the hardware can't cope with a 64K segment, the driver already deals with that internally by splitting large requests in pata_macio_qc_prep(). That is how the driver has managed to function until now on 64K kernels. So fix the driver to advertise a max_segment_size of 64K, which avoids the warning and keeps the SCSI core happy. Fixes: afd53a3d8528 ("scsi: core: Initialize scsi midlayer limits before allocating the queue") Reported-by: Guenter Roeck <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Reported-by: Doru Iorgulescu <[email protected]> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218858 Signed-off-by: Michael Ellerman <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Damien Le Moal <[email protected]> Reviewed-by: John Garry <[email protected]> Signed-off-by: Niklas Cassel <[email protected]>
2024-06-06soc: amlogic: meson-gx-socinfo: add new A113X SoC idViacheslav Bocharov1-0/+1
Add new definition for Amlogix A113X SoC found in JetHub D1/D1+ devices: soc soc0: Amlogic Meson AXG (A113X) Revision 25:b (43:2) Detected Signed-off-by: Viacheslav Bocharov <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Neil Armstrong <[email protected]>
2024-06-06soc: amlogic: meson-gx-socinfo: Add S905L IDChristian Hewitt1-0/+1
Add the S905L SoC ID observed in several P271 boards: kernel: soc soc0: Amlogic Meson GXLX (S905L) Revision 26:a (c1:2) Detected Signed-off-by: Christian Hewitt <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Neil Armstrong <[email protected]>
2024-06-06cpufreq: ti-cpufreq: Handle deferred probe with dev_err_probe()Primoz Fiser1-1/+1
Handle deferred probing gracefully by using dev_err_probe() to not spam console with unnecessary error messages. Fixes: f88d152dc739 ("cpufreq: ti: Migrate to dev_pm_opp_set_config()") Signed-off-by: Primoz Fiser <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2024-06-06HID: add missing MODULE_DESCRIPTION() macrosJeff Johnson57-0/+57
make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-a4tech.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-apple.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-aureal.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-belkin.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-betopff.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-bigbenff.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-cherry.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-chicony.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-cypress.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-dr.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-emsff.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-elecom.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-elo.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-evision.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-ezkey.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-vivaldi-common.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-google-hammer.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-google-stadiaff.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-gyration.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-holtek-kbd.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-holtek-mouse.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-ite.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-kensington.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-keytouch.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-kye.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-lcpower.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-lenovo.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-logitech.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-magicmouse.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-maltron.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-mf.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-megaworld.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-microsoft.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-monterey.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-ntrig.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-ortek.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-prodikeys.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-pl.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-petalynx.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-primax.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-razer.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-redragon.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-retrode.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-saitek.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-samsung.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-semitek.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-sjoy.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-sony.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-speedlink.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-steam.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-steelseries.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-sunplus.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-gaff.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-tmff.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-tivo.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-topseed.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-twinhan.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-uclogic.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-xinmo.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-zpff.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-zydacron.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-viewsonic.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-waltop.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-winwing.o Add the missing invocations of the MODULE_DESCRIPTION() macro. Note: All HID drivers that had explicit entries in the MAINTAINERS file were fixed individually. This patch fixes all remaining HID drivers that fall under the generic "HID CORE LAYER" entry in the MAINTAINERS file. Almost all descriptions were taken from the header comment in each file. Signed-off-by: Jeff Johnson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Benjamin Tissoires <[email protected]>
2024-06-06HID: logitech-dj: add missing MODULE_DESCRIPTION() macroJeff Johnson1-0/+1
make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-logitech-dj.o Add the missing invocation of the MODULE_DESCRIPTION() macro. Signed-off-by: Jeff Johnson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Benjamin Tissoires <[email protected]>
2024-06-06HID: lg-g15: add missing MODULE_DESCRIPTION() macroJeff Johnson1-0/+1
make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-lg-g15.o Add the missing invocation of the MODULE_DESCRIPTION() macro. Signed-off-by: Jeff Johnson <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Benjamin Tissoires <[email protected]>
2024-06-06HID: letsketch: add missing MODULE_DESCRIPTION() macroJeff Johnson1-0/+1
make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-letsketch.o Add the missing invocation of the MODULE_DESCRIPTION() macro. Signed-off-by: Jeff Johnson <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Benjamin Tissoires <[email protected]>
2024-06-06drm/meson: plane: Add error handlingHaoran Liu1-6/+11
This patch adds robust error handling to the meson_plane_create function in drivers/gpu/drm/meson/meson_plane.c. The function previously lacked proper handling for potential failure scenarios of the drm_universal_plane_init call. Signed-off-by: Haoran Liu <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/[email protected] [narmstrong: fixe the commit subject] Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-06net: wwan: iosm: Fix tainted pointer delete is case of region creation failAleksandr Mishin1-1/+1
In case of region creation fail in ipc_devlink_create_region(), previously created regions delete process starts from tainted pointer which actually holds error code value. Fix this bug by decreasing region index before delete. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 4dcd183fbd67 ("net: wwan: iosm: devlink registration") Signed-off-by: Aleksandr Mishin <[email protected]> Acked-by: Sergey Ryazanov <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]>
2024-06-06net: ravb: Allocate RX buffers via page poolPaul Barker2-96/+175
This patch makes multiple changes that can't be separated: 1) Allocate plain RX buffers via a page pool instead of allocating SKBs, then use build_skb() when a packet is received. 2) For GbEth IP, reduce the RX buffer size to 2kB. 3) For GbEth IP, merge packets which span more than one RX descriptor as SKB fragments instead of copying data. Implementing (1) without (2) would require the use of an order-1 page pool (instead of an order-0 page pool split into page fragments) for GbEth. Implementing (2) without (3) would leave us no space to re-assemble packets which span more than one RX descriptor. Implementing (3) without (1) would not be possible as the network stack expects to use put_page() or page_pool_put_page() to free SKB fragments after an SKB is consumed. RX checksum offload support is adjusted to handle both linear and nonlinear (fragmented) packets. This patch gives the following improvements during testing with iperf3. * RZ/G2L: * TCP RX: same bandwidth at -43% CPU load (70% -> 40%) * UDP RX: same bandwidth at -17% CPU load (88% -> 74%) * RZ/G2UL: * TCP RX: +30% bandwidth (726Mbps -> 941Mbps) * UDP RX: +417% bandwidth (108Mbps -> 558Mbps) * RZ/G3S: * TCP RX: +64% bandwidth (562Mbps -> 920Mbps) * UDP RX: +420% bandwidth (90Mbps -> 468Mbps) * RZ/Five: * TCP RX: +217% bandwidth (145Mbps -> 459Mbps) * UDP RX: +470% bandwidth (20Mbps -> 114Mbps) There is no significant impact on bandwidth or CPU load in testing on RZ/G2H or R-Car M3N. Signed-off-by: Paul Barker <[email protected]> Reviewed-by: Sergey Shtylyov <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2024-06-06net: ravb: Use NAPI threaded mode on 1-core CPUs with GbEth IPPaul Barker1-1/+4
NAPI Threaded mode (along with the previously enabled SW IRQ Coalescing) is required to improve network stack performance for single core SoCs using the GbEth IP (currently the RZ/G2L SoC family and the RZ/G3S SoC). This patch gives the following improvements during testing with iperf3. * RZ/G2UL: * TCP TX: +32% bandwidth (638Mbps -> 841Mbps) * TXP RX: +8.8% bandwidth (667Mbps -> 726Mbps) * UDP RX: +104% bandwidth (53Mbps -> 108Mbps) * RZ/G3S: * TCP TX: 29% bandwidth (529Mbps -> 681Mbps) * UDP RX: +1290% bandwidth (6.46Mbps -> 90Mbps) * RZ/Five: * UDP RX: Test no longer crashes (0 -> 20 Mbps) This patch gives the following reductions in performance in the same testing: * RZ/G2UL: * UDP TX: -7.5% bandwidth (594Mbps -> 549Mbps) * RZ/G3S: * UDP TX: -5% bandwidth (625Mbps -> 594Mbps) These losses are considered acceptable given the benefits shown above. If UDP TX bandwidth must be maximised for a particular use case, NAPI threaded mode can be disabled at runtime via sysfs writes. The improvement of UDP RX bandwidth for the single core SoCs (RZ/G2UL & RZ/G3S) is particularly critical. Signed-off-by: Paul Barker <[email protected]> Reviewed-by: Sergey Shtylyov <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2024-06-06net: ravb: Enable SW IRQ Coalescing for GbEthPaul Barker2-0/+5
Software IRQ Coalescing is required to improve network stack performance in the RZ/G2L SoC family and the RZ/G3S SoC, i.e. the SoCs which use the GbEth IP. This patch gives the following improvements during testing with iperf3: * RZ/G2L: * TCP RX: same bandwidth with -6% CPU load (76% -> 71%) * UDP RX: same bandwidth with -10% CPU load (99% -> 89%) * RZ/G2UL: * UDP RX: +4200% bandwidth (1.23Mbps -> 53Mbps) * RZ/G3S: * UDP RX: +425% bandwidth (1.23Mbps -> 6.46Mbps) The improvement of UDP RX bandwidth for the single core SoCs (RZ/G2UL & RZ/G3S) is particularly critical. Signed-off-by: Paul Barker <[email protected]> Reviewed-by: Sergey Shtylyov <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2024-06-06net: ravb: Refactor GbEth RX code pathPaul Barker1-27/+32
We can reduce code duplication in ravb_rx_gbeth(). Signed-off-by: Paul Barker <[email protected]> Reviewed-by: Sergey Shtylyov <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2024-06-06net: ravb: Refactor RX ring refillPaul Barker1-93/+57
To reduce code duplication, we add a new RX ring refill function which can handle both the initial RX ring population (which was split between ravb_ring_init() and ravb_ring_format()) and the RX ring refill after polling (in ravb_rx()). Signed-off-by: Paul Barker <[email protected]> Reviewed-by: Sergey Shtylyov <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2024-06-06net: ravb: Align poll function with NAPI docsPaul Barker1-15/+11
Align ravb_poll() with the documentation in `Documentation/networking/kapi.rst` and `Documentation/networking/napi.rst`. The documentation says that we should prefer napi_complete_done() over napi_complete(), and using the former allows us to properly support busy polling. We should ensure that napi_complete_done() is only called if the work budget has not been exhausted, and we should only re-arm interrupts if it returns true. Signed-off-by: Paul Barker <[email protected]> Reviewed-by: Sergey Shtylyov <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2024-06-06net: ravb: Simplify poll & receive functionsPaul Barker2-16/+13
We don't need to pass the work budget to ravb_rx() by reference, it's cleaner to pass this by value and return the amount of work done. This allows us to simplify the ravb_poll() function and use the common `work_done` variable name seen in other network drivers for consistency and ease of understanding. This is a pure refactor and should not affect behaviour. Signed-off-by: Paul Barker <[email protected]> Reviewed-by: Sergey Shtylyov <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2024-06-06HID: usbhid: Share USB device firmware node with child HID deviceDanny Kaehn1-0/+2
USB HID core now shares its fwnode with its child HID device. Since there can only be one HID device on a USB interface, it is redundant to specify a hid node under the USB device. This allows usb HID device drivers to be described in firmware and make use of device properties. Signed-off-by: Danny Kaehn <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Benjamin Tissoires <[email protected]>
2024-06-06Drivers: hv: Cosmetic changes for hv.c and balloon.cAditya Nagesh2-82/+53
Fix issues reported by checkpatch.pl script in hv.c and balloon.c - Remove unnecessary parentheses - Remove extra newlines - Remove extra spaces - Add spaces between comparison operators - Remove comparison with NULL in if statements No functional changes intended Signed-off-by: Aditya Nagesh <[email protected]> Reviewed-by: Saurabh Sengar <[email protected]> Reviewed-by: Michael Kelley <[email protected]> Link: https://lore.kernel.org/r/1717152521-6439-1-git-send-email-adityanagesh@linux.microsoft.com Signed-off-by: Wei Liu <[email protected]> Message-ID: <1717152521-6439-1-git-send-email-adityanagesh@linux.microsoft.com>
2024-06-05net/mlx5e: SHAMPO, Coalesce skb fragments to page sizeDragos Tatulea1-6/+13
When doing hardware GRO (SHAMPO), the driver puts each data payload of a packet from the wire into one skb fragment. TCP Zero-Copy expects page sized skb fragments to be able to do it's page-flipping magic. With the current way of arranging fragments by the driver, only specific MTUs (page sized multiple + header size) will yield such page sized fragments in a high percentage. This change improves payload arrangement in the skb for hardware GRO by coalescing payloads into a single skb fragment when possible. To demonstrate the fix, running tcp_mmap with a MTU of 1500 yields: - Before: 0 % bytes mmap'ed - After : 81 % bytes mmap'ed More importantly, coalescing considerably improves the HW GRO performance. Here are the results for a iperf3 bandwidth benchmark: +---------+--------+--------+------------------------+-----------+ | streams | SW GRO | HW GRO | HW GRO with coalescing | Unit | |---------+--------+--------+------------------------+-----------| | 1 | 36 | 42 | 57 | Gbits/sec | | 4 | 34 | 39 | 50 | Gbits/sec | | 8 | 31 | 35 | 43 | Gbits/sec | +---------+--------+--------+------------------------+-----------+ Benchmark details: VM based setup CPU: Intel(R) Xeon(R) Platinum 8380 CPU, 24 cores NIC: ConnectX-7 100GbE iperf3 and irq running on same CPU over a single receive queue Signed-off-by: Dragos Tatulea <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-06-05net/mlx5e: SHAMPO, Re-enable HW-GROYoray Zack1-0/+26
Add back HW-GRO to the reported features. As the current implementation of HW-GRO uses KSMs with a specific fixed buffer size (256B) to map its headers buffer, we reported the feature only if the NIC is supporting KSM and the minimum value for buffer size is below the requested one. iperf3 bandwidth comparison: +---------+--------+--------+-----------+ | streams | SW GRO | HW GRO | Unit | |---------+--------+--------+-----------| | 1 | 36 | 42 | Gbits/sec | | 4 | 34 | 39 | Gbits/sec | | 8 | 31 | 35 | Gbits/sec | +---------+--------+--------+-----------+ A downstream patch will add skb fragment coalescing which will improve performance considerably. Benchmark details: VM based setup CPU: Intel(R) Xeon(R) Platinum 8380 CPU, 24 cores NIC: ConnectX-7 100GbE iperf3 and irq running on same CPU over a single receive queue Signed-off-by: Yoray Zack <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-06-05net/mlx5e: SHAMPO, Use KSMs instead of KLMsYoray Zack5-67/+70
KSM Mkey is KLM Mkey with a fixed buffer size. Due to this fact, it is a faster mechanism than KLM. SHAMPO feature used KLMs Mkeys for memory mappings of its headers buffer. As it used KLMs with the same buffer size for each entry, we can use KSMs instead. This commit changes the Mkeys that map the SHAMPO headers buffer from KLMs to KSMs. Signed-off-by: Yoray Zack <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-06-05net/mlx5e: SHAMPO, Add header-only ethtool counters for header data splitTariq Toukan3-0/+11
Count the number of header-only packets and bytes from SHAMPO. Signed-off-by: Dragos Tatulea <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-06-05net/mlx5e: SHAMPO, Drop rx_gro_match_packets counterDragos Tatulea3-7/+0
After modifying rx_gro_packets to be more accurate, the rx_gro_match_packets counter is redundant. Signed-off-by: Dragos Tatulea <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-06-05net/mlx5e: SHAMPO, Make GRO counters more preciseDragos Tatulea1-5/+8
Don't count non GRO packets. A non GRO packet is a packet with a GRO cb count of 1. Signed-off-by: Dragos Tatulea <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-06-05net/mlx5e: SHAMPO, Skipping on duplicate flush of the same SHAMPO SKBYoray Zack1-1/+1
SHAMPO SKB can be flushed in mlx5e_shampo_complete_rx_cqe(). If the SKB was flushed, rq->hw_gro_data->skb was also set to NULL. We can skip on flushing the SKB in mlx5e_shampo_flush_skb if rq->hw_gro_data->skb == NULL. Signed-off-by: Yoray Zack <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-06-05net/mlx5e: SHAMPO, Specialize mlx5e_fill_skb_data()Dragos Tatulea1-14/+11
mlx5e_fill_skb_data() used to have multiple callers. But after the XDP multibuf refactoring from commit 2cb0e27d43b4 ("net/mlx5e: RX, Prepare non-linear striding RQ for XDP multi-buffer support") the SHAMPO code path is the only caller. Take advantage of this and specialize the function: - Drop the redundant check. - Assume that data_bcnt is > 0. This is needed in a downstream patch. Rename the function as well to make things clear. Signed-off-by: Dragos Tatulea <[email protected]> Suggested-by: Tariq Toukan <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-06-05net/mlx5e: SHAMPO, Simplify header page release in teardownDragos Tatulea3-58/+17
The function that releases SHAMPO header pages (mlx5e_shampo_dealloc_hd) has some complicated logic that comes from the fact that it is called twice during teardown: 1) To release the posted header pages that didn't get any completions. 2) To release all remaining header pages. This flow is not necessary: all header pages can be released from the driver side in one go. Furthermore, the above flow is buggy. Taking the 8 headers per page example: 1) Release fragments 5-7. Page will be released. 2) Release remaining fragments 0-4. The bits in the header will indicate that the page needs releasing. But this is incorrect: page was released in step 1. This patch releases all header pages in one go. This simplifies the header page cleanup function. For consistency, the datapath header page release API (mlx5e_free_rx_shampo_hd_entry()) is used. Signed-off-by: Dragos Tatulea <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-06-05net/mlx5e: SHAMPO, Disable gso_size for non GRO packetsDragos Tatulea1-0/+2
When HW GRO is enabled, forwarding of packets is broken due to gso_size being set incorrectly on non GRO packets. Non GRO packets have a skb GRO count of 1. mlx5 always sets gso_size on the skb, even for non GRO packets. It leans on the fact that gso_size is normally reset in napi_gro_complete(). But this happens only for packets from GRO'able protocols (TCP/UDP) that have a gro_receive() handler. The problematic scenarios are: 1) Non GRO protocol packets are received, validate_xmit_skb() will drop them (see EPROTONOSUPPORT in skb_mac_gso_segment()). The fix for this case would be to not set gso_size at all for SHAMPO packets with header size 0. 2) Packets from a GRO'ed protocol (TCP) are received but immediately flushed because they are not GRO'able (TCP SYN for example). mlx5e_shampo_update_hdr(), which updates the remaining GRO state on the skb, is not called because skb GRO count is 1. The fix here would be to always call mlx5e_shampo_update_hdr(), regardless of skb GRO count. But this call is expensive The unified fix for both cases is to reset gso_size before calling napi_gro_receive(). It is a change that is more effective (no call to mlx5e_shampo_update_hdr() necessary) and simple (smallest code footprint). Signed-off-by: Dragos Tatulea <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-06-05net/mlx5e: SHAMPO, Fix FCS config when HW GRO onDragos Tatulea1-3/+9
For the following scenario: ethtool --features eth3 rx-gro-hw on ethtool --features eth3 rx-fcs on ethtool --features eth3 rx-fcs off ... there is a firmware error because the driver enables HW GRO first while FCS is still enabled. This patch fixes this by swapping the order of HW GRO and FCS for this specific case. Take LRO into consideration as well for consistency. Signed-off-by: Dragos Tatulea <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-06-05net/mlx5e: SHAMPO, Fix invalid WQ linked list unlinkDragos Tatulea1-0/+3
When all the strides in a WQE have been consumed, the WQE is unlinked from the WQ linked list (mlx5_wq_ll_pop()). For SHAMPO, it is possible to receive CQEs with 0 consumed strides for the same WQE even after the WQE is fully consumed and unlinked. This triggers an additional unlink for the same wqe which corrupts the linked list. Fix this scenario by accepting 0 sized consumed strides without unlinking the WQE again. Signed-off-by: Dragos Tatulea <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-06-05net/mlx5e: SHAMPO, Fix incorrect page releaseDragos Tatulea1-1/+2
Under the following conditions: 1) No skb created yet 2) header_size == 0 (no SHAMPO header) 3) header_index + 1 % MLX5E_SHAMPO_WQ_HEADER_PER_PAGE == 0 (this is the last page fragment of a SHAMPO header page) a new skb is formed with a page that is NOT a SHAMPO header page (it is a regular data page). Further down in the same function (mlx5e_handle_rx_cqe_mpwrq_shampo()), a SHAMPO header page from header_index is released. This is wrong and it leads to SHAMPO header pages being released more than once. Signed-off-by: Dragos Tatulea <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-06-05net/mlx5e: SHAMPO, Use net_prefetch APITariq Toukan1-3/+3
Let the SHAMPO functions use the net-specific prefetch API, similar to all other usages. Signed-off-by: Tariq Toukan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-06-06platform/chrome: cros_ec_lpc: Add quirks for Framework LaptopBen Walsh1-0/+7
For Framework Laptops with Microchip EC (MEC), use the ACPI id "PNP0C09" to find the ACPI device, and AML mutex "ECMT" to protect EC memory access. Tested-by: Dustin L. Howett <[email protected]> Signed-off-by: Ben Walsh <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Tzung-Bi Shih <[email protected]>
2024-06-06platform/chrome: cros_ec_lpc: Add a new quirk for AML mutexBen Walsh1-0/+19
Add a new quirk "CROS_EC_LPC_QUIRK_AML_MUTEX" which provides the name of an AML mutex to protect MEC memory access. Tested-by: Dustin L. Howett <[email protected]> Signed-off-by: Ben Walsh <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Tzung-Bi Shih <[email protected]>
2024-06-06platform/chrome: cros_ec_lpc: Add a new quirk for ACPI idBen Walsh1-12/+38
Framework Laptops' ACPI exposes the EC with id "PNP0C09". But "PNP0C09" is part of the ACPI standard; there are lots of computers with EC chips with this id, and most of them don't support the cros_ec protocol. The driver could find the ACPI device by having "PNP0C09" in the acpi_match_table, but this would match devices which don't support the cros_ec protocol. Instead, add a new quirk "CROS_EC_LPC_QUIRK_ACPI_ID" which allows the id to be specified. This quirk is applied after the DMI check shows that the device is supported. Tested-by: Dustin L. Howett <[email protected]> Signed-off-by: Ben Walsh <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Tzung-Bi Shih <[email protected]>
2024-06-06platform/chrome: cros_ec_lpc: MEC access can use an AML mutexBen Walsh2-2/+85
Framework Laptops have ACPI code which accesses the MEC memory. It uses an AML mutex to prevent concurrent access. But the cros_ec_lpc driver was not aware of this mutex. The ACPI code and LPC driver both attempted to talk to the EC at the same time, messing up communication with the EC. Allow the LPC driver MEC code to find and use the AML mutex. Tested-by: Dustin L. Howett <[email protected]> Signed-off-by: Ben Walsh <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Tzung-Bi Shih <[email protected]>
2024-06-06platform/chrome: cros_ec_lpc: MEC access can return error codeBen Walsh4-56/+112
cros_ec_lpc_io_bytes_mec was returning a u8 checksum of all bytes read/written, which didn't leave room to indicate errors. Change this u8 to an int where negative values indicate an error, and non-negative values are the checksum as before. Tested-by: Dustin L. Howett <[email protected]> Signed-off-by: Ben Walsh <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Tzung-Bi Shih <[email protected]>
2024-06-05soc: qcom: spm: add missing MODULE_DESCRIPTION()Jeff Johnson1-0/+1
make allmodconfig && make W=1 C=1 warns: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/soc/qcom/spm.o Add the missing MODULE_DESCRIPTION(), using the same description as the underlying QCOM_SPM Kconfig item. Signed-off-by: Jeff Johnson <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2024-06-05drm/vmwgfx: Don't memcmp equivalent pointersIan Forbes1-1/+1
These pointers are frequently the same and memcmp does not compare the pointers before comparing their contents so this was wasting cycles comparing 16 KiB of memory which will always be equal. Fixes: bb6780aa5a1d ("drm/vmwgfx: Diff cursors when using cmds") Signed-off-by: Ian Forbes <[email protected]> Signed-off-by: Zack Rusin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-05igc: Fix Energy Efficient Ethernet support declarationSasha Neftin2-2/+11
The commit 01cf893bf0f4 ("net: intel: i40e/igc: Remove setting Autoneg in EEE capabilities") removed SUPPORTED_Autoneg field but left inappropriate ethtool_keee structure initialization. When "ethtool --show <device>" (get_eee) invoke, the 'ethtool_keee' structure was accidentally overridden. Remove the 'ethtool_keee' overriding and add EEE declaration as per IEEE specification that allows reporting Energy Efficient Ethernet capabilities. Examples: Before fix: ethtool --show-eee enp174s0 EEE settings for enp174s0: EEE status: not supported After fix: EEE settings for enp174s0: EEE status: disabled Tx LPI: disabled Supported EEE link modes: 100baseT/Full 1000baseT/Full 2500baseT/Full Fixes: 01cf893bf0f4 ("net: intel: i40e/igc: Remove setting Autoneg in EEE capabilities") Suggested-by: Dima Ruinskiy <[email protected]> Signed-off-by: Sasha Neftin <[email protected]> Tested-by: Naama Meir <[email protected]> Signed-off-by: Jacob Keller <[email protected]> Link: https://lore.kernel.org/r/20240603-net-2024-05-30-intel-net-fixes-v2-6-e3563aa89b0c@intel.com Signed-off-by: Jakub Kicinski <[email protected]>
2024-06-05ice: map XDP queues to vectors in ice_vsi_map_rings_to_vectors()Larysa Zaremba4-46/+68
ice_pf_dcb_recfg() re-maps queues to vectors with ice_vsi_map_rings_to_vectors(), which does not restore the previous state for XDP queues. This leads to no AF_XDP traffic after rebuild. Map XDP queues to vectors in ice_vsi_map_rings_to_vectors(). Also, move the code around, so XDP queues are mapped independently only through .ndo_bpf(). Fixes: 6624e780a577 ("ice: split ice_vsi_setup into smaller functions") Reviewed-by: Przemek Kitszel <[email protected]> Signed-off-by: Larysa Zaremba <[email protected]> Reviewed-by: Simon Horman <[email protected]> Tested-by: Chandan Kumar Rout <[email protected]> Signed-off-by: Jacob Keller <[email protected]> Link: https://lore.kernel.org/r/20240603-net-2024-05-30-intel-net-fixes-v2-5-e3563aa89b0c@intel.com Signed-off-by: Jakub Kicinski <[email protected]>
2024-06-05ice: add flag to distinguish reset from .ndo_bpf in XDP rings configLarysa Zaremba3-14/+24
Commit 6624e780a577 ("ice: split ice_vsi_setup into smaller functions") has placed ice_vsi_free_q_vectors() after ice_destroy_xdp_rings() in the rebuild process. The behaviour of the XDP rings config functions is context-dependent, so the change of order has led to ice_destroy_xdp_rings() doing additional work and removing XDP prog, when it was supposed to be preserved. Also, dependency on the PF state reset flags creates an additional, fortunately less common problem: * PFR is requested e.g. by tx_timeout handler * .ndo_bpf() is asked to delete the program, calls ice_destroy_xdp_rings(), but reset flag is set, so rings are destroyed without deleting the program * ice_vsi_rebuild tries to delete non-existent XDP rings, because the program is still on the VSI * system crashes With a similar race, when requested to attach a program, ice_prepare_xdp_rings() can actually skip setting the program in the VSI and nevertheless report success. Instead of reverting to the old order of function calls, add an enum argument to both ice_prepare_xdp_rings() and ice_destroy_xdp_rings() in order to distinguish between calls from rebuild and .ndo_bpf(). Fixes: efc2214b6047 ("ice: Add support for XDP") Reviewed-by: Igor Bagnucki <[email protected]> Signed-off-by: Larysa Zaremba <[email protected]> Reviewed-by: Simon Horman <[email protected]> Tested-by: Chandan Kumar Rout <[email protected]> Signed-off-by: Jacob Keller <[email protected]> Link: https://lore.kernel.org/r/20240603-net-2024-05-30-intel-net-fixes-v2-4-e3563aa89b0c@intel.com Signed-off-by: Jakub Kicinski <[email protected]>
2024-06-05ice: remove af_xdp_zc_qps bitmapLarysa Zaremba3-26/+27
Referenced commit has introduced a bitmap to distinguish between ZC and copy-mode AF_XDP queues, because xsk_get_pool_from_qid() does not do this for us. The bitmap would be especially useful when restoring previous state after rebuild, if only it was not reallocated in the process. This leads to e.g. xdpsock dying after changing number of queues. Instead of preserving the bitmap during the rebuild, remove it completely and distinguish between ZC and copy-mode queues based on the presence of a device associated with the pool. Fixes: e102db780e1c ("ice: track AF_XDP ZC enabled queues in bitmap") Reviewed-by: Przemek Kitszel <[email protected]> Signed-off-by: Larysa Zaremba <[email protected]> Reviewed-by: Simon Horman <[email protected]> Tested-by: Chandan Kumar Rout <[email protected]> Signed-off-by: Jacob Keller <[email protected]> Link: https://lore.kernel.org/r/20240603-net-2024-05-30-intel-net-fixes-v2-3-e3563aa89b0c@intel.com Signed-off-by: Jakub Kicinski <[email protected]>
2024-06-05ice: fix reads from NVM Shadow RAM on E830 and E825-C devicesJacob Keller2-9/+93
The ice driver reads data from the Shadow RAM portion of the NVM during initialization, including data used to identify the NVM image and device, such as the ETRACK ID used to populate devlink dev info fw.bundle. Currently it is using a fixed offset defined by ICE_CSS_HEADER_LENGTH to compute the appropriate offset. This worked fine for E810 and E822 devices which both have CSS header length of 330 words. Other devices, including both E825-C and E830 devices have different sizes for their CSS header. The use of a hard coded value results in the driver reading from the wrong block in the NVM when attempting to access the Shadow RAM copy. This results in the driver reporting the fw.bundle as 0x0 in both the devlink dev info and ethtool -i output. The first E830 support was introduced by commit ba20ecb1d1bb ("ice: Hook up 4 E830 devices by adding their IDs") and the first E825-C support was introducted by commit f64e18944233 ("ice: introduce new E825C devices family") The NVM actually contains the CSS header length embedded in it. Remove the hard coded value and replace it with logic to read the length from the NVM directly. This is more resilient against all existing and future hardware, vs looking up the expected values from a table. It ensures the driver will read from the appropriate place when determining the ETRACK ID value used for populating the fw.bundle_id and for reporting in ethtool -i. The CSS header length for both the active and inactive flash bank is stored in the ice_bank_info structure to avoid unnecessary duplicate work when accessing multiple words of the Shadow RAM. Both banks are read in the unlikely event that the header length is different for the NVM in the inactive bank, rather than being different only by the overall device family. Fixes: ba20ecb1d1bb ("ice: Hook up 4 E830 devices by adding their IDs") Co-developed-by: Paul Greenwalt <[email protected]> Signed-off-by: Paul Greenwalt <[email protected]> Reviewed-by: Przemek Kitszel <[email protected]> Tested-by: Pucha Himasekhar Reddy <[email protected]> Signed-off-by: Jacob Keller <[email protected]> Link: https://lore.kernel.org/r/20240603-net-2024-05-30-intel-net-fixes-v2-2-e3563aa89b0c@intel.com Signed-off-by: Jakub Kicinski <[email protected]>
2024-06-05ice: fix iteration of TLVs in Preserved Fields AreaJacob Keller1-7/+21
The ice_get_pfa_module_tlv() function iterates over the Type-Length-Value structures in the Preserved Fields Area (PFA) of the NVM. This is used by the driver to access data such as the Part Board Assembly identifier. The function uses simple logic to iterate over the PFA. First, the pointer to the PFA in the NVM is read. Then the total length of the PFA is read from the first word. A pointer to the first TLV is initialized, and a simple loop iterates over each TLV. The pointer is moved forward through the NVM until it exceeds the PFA area. The logic seems sound, but it is missing a key detail. The Preserved Fields Area length includes one additional final word. This is documented in the device data sheet as a dummy word which contains 0xFFFF. All NVMs have this extra word. If the driver tries to scan for a TLV that is not in the PFA, it will read past the size of the PFA. It reads and interprets the last dummy word of the PFA as a TLV with type 0xFFFF. It then reads the word following the PFA as a length. The PFA resides within the Shadow RAM portion of the NVM, which is relatively small. All of its offsets are within a 16-bit size. The PFA pointer and TLV pointer are stored by the driver as 16-bit values. In almost all cases, the word following the PFA will be such that interpreting it as a length will result in 16-bit arithmetic overflow. Once overflowed, the new next_tlv value is now below the maximum offset of the PFA. Thus, the driver will continue to iterate the data as TLVs. In the worst case, the driver hits on a sequence of reads which loop back to reading the same offsets in an endless loop. To fix this, we need to correct the loop iteration check to account for this extra word at the end of the PFA. This alone is sufficient to resolve the known cases of this issue in the field. However, it is plausible that an NVM could be misconfigured or have corrupt data which results in the same kind of overflow. Protect against this by using check_add_overflow when calculating both the maximum offset of the TLVs, and when calculating the next_tlv offset at the end of each loop iteration. This ensures that the driver will not get stuck in an infinite loop when scanning the PFA. Fixes: e961b679fb0b ("ice: add board identifier info to devlink .info_get") Co-developed-by: Paul Greenwalt <[email protected]> Signed-off-by: Paul Greenwalt <[email protected]> Reviewed-by: Przemek Kitszel <[email protected]> Tested-by: Pucha Himasekhar Reddy <[email protected]> Signed-off-by: Jacob Keller <[email protected]> Link: https://lore.kernel.org/r/20240603-net-2024-05-30-intel-net-fixes-v2-1-e3563aa89b0c@intel.com Signed-off-by: Jakub Kicinski <[email protected]>
2024-06-05drm/vmwgfx: remove unused struct 'vmw_stdu_dma'Dr. David Alan Gilbert1-5/+0
'vmw_stdu_dma' is unused since commit 39985eea5a6d ("drm/vmwgfx: Abstract placement selection") Remove it. Signed-off-by: Dr. David Alan Gilbert <[email protected]> Signed-off-by: Zack Rusin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.