summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-01-18net: xilinx: axienet: Add some symbolic constants for IRQ delay timerSean Anderson
Instead of using literals, add some symbolic constants for the IRQ delay timer calculation. Signed-off-by: Sean Anderson <sean.anderson@linux.dev> Reviewed by: Shannon Nelson <shannon.nelson@amd.com> Link: https://patch.msgid.link/20250116232954.2696930-2-sean.anderson@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-18nfc: mrvl: Don't use "proxy" headersAndy Shevchenko
Update header inclusions to follow IWYU (Include What You Use) principle. In this case replace of_gpio.h, which is subject to remove by the GPIOLIB subsystem, with the respective headers that are being used by the driver. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20250116153119.148097-1-andriy.shevchenko@linux.intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-18nfc: st21nfca: Remove unused of_gpio.hAndy Shevchenko
of_gpio.h is deprecated and subject to remove. The drivers in question don't use it, simply remove the unused header. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-18mailbox: th1520: Fix memory corruption due to incorrect array sizeMichal Wilczynski
The functions th1520_mbox_suspend_noirq and th1520_mbox_resume_noirq are intended to save and restore the interrupt mask registers in the MBOX ICU0. However, the array used to store these registers was incorrectly sized, leading to memory corruption when accessing all four registers. This commit corrects the array size to accommodate all four interrupt mask registers, preventing memory corruption during suspend and resume operations. Fixes: 5d4d263e1c6b ("mailbox: Introduce support for T-head TH1520 Mailbox driver") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/all/a99e72be-8490-4960-ad26-cbfef6af238f@stanley.mountain/ Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-01-18mailbox: zynqmp: Remove invalid __percpu annotation in zynqmp_ipi_probe()Uros Bizjak
struct zynqmp_ipi_pdata __percpu *pdata is not a per-cpu variable, so it should not be annotated with __percpu annotation. Remove invalid __percpu annotation to fix several zynqmp-ipi-mailbox.c:920:15: warning: incorrect type in assignment (different address spaces) zynqmp-ipi-mailbox.c:920:15: expected struct zynqmp_ipi_pdata [noderef] __percpu *pdata zynqmp-ipi-mailbox.c:920:15: got void * zynqmp-ipi-mailbox.c:927:56: warning: incorrect type in argument 3 (different address spaces) zynqmp-ipi-mailbox.c:927:56: expected unsigned int [usertype] *out_value zynqmp-ipi-mailbox.c:927:56: got unsigned int [noderef] __percpu * ... and several drivers/mailbox/zynqmp-ipi-mailbox.c:924:9: warning: dereference of noderef expression ... sparse warnings. There were no changes in the resulting object file. Cc: stable@vger.kernel.org Fixes: 6ffb1635341b ("mailbox: zynqmp: handle SGI for shared IPI") Signed-off-by: Uros Bizjak <ubizjak@gmail.com> Reviewed-by: Michal Simek <michal.simek@amd.com> Reviewed-by: Tanmay Shah <tanmay.shah@amd.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-01-18MAINTAINERS: add entry for Samsung Exynos mailbox driverTudor Ambarus
Add entry for the Samsung Exynos mailbox driver. Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Peter Griffin <peter.griffin@linaro.org> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-01-18mailbox: add Samsung Exynos driverTudor Ambarus
The Samsung Exynos mailbox controller, used on Google GS101 SoC, has 16 flag bits for hardware interrupt generation and a shared register for passing mailbox messages. When the controller is used by the ACPM interface the shared register is ignored and the mailbox controller acts as a doorbell. The controller just raises the interrupt to APM after the ACPM interface has written the message to SRAM. Add support for the Samsung Exynos mailbox controller. Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-01-18dt-bindings: mailbox: add google,gs101-mboxTudor Ambarus
Add bindings for the Samsung Exynos Mailbox Controller. Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-01-18mailbox: qcom: Add support for IPQ5424 APCS IPCGokul Sriram Palanisamy
IPQ5424 mailbox do not have clock support and reuses msm8994_apcs_data. Signed-off-by: Gokul Sriram Palanisamy <quic_gokulsri@quicinc.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-01-18dt-bindings: mailbox: qcom: Add IPQ5424 APCS compatibleGokul Sriram Palanisamy
Add compatible for the Qualcomm IPQ5424 APCS block. Signed-off-by: Gokul Sriram Palanisamy <quic_gokulsri@quicinc.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-01-18mailbox: qcom-ipcc: Reset CLEAR_ON_RECV_RD if set from boot firmwareMukesh Ojha
For some SoCs, boot firmware is using the same IPCC instance used by Linux and it has kept CLEAR_ON_RECV_RD set which basically means interrupt pending registers are cleared when RECV_ID is read and the register automatically updates to the next pending interrupt/client status based on priority. Clear the CLEAR_ON_RECV_RD if it is set from the boot firmware. Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-01-18mailbox: add Microchip IPC supportValentina Fernandez
Add a mailbox controller driver for the Microchip Inter-processor Communication (IPC), which is used to send and receive data between processors. The driver uses the RISC-V Supervisor Binary Interface (SBI) to communicate with software running in machine mode (M-mode) to access the IPC hardware block. Additional details on the Microchip vendor extension and the IPC function IDs described in the driver can be found in the following documentation: https://github.com/linux4microchip/microchip-sbi-ecall-extension This SBI interface in this driver is compatible with the Mi-V Inter-hart Communication (IHC) IP. Transmitting and receiving data through the mailbox framework is done through struct mchp_ipc_msg. Signed-off-by: Valentina Fernandez <valentina.fernandezalanis@microchip.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-01-18dt-bindings: mailbox: add binding for Microchip IPC mailbox controllerValentina Fernandez
Add a dt-binding for the Microchip Inter-Processor Communication (IPC) mailbox controller. Signed-off-by: Valentina Fernandez <valentina.fernandezalanis@microchip.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-01-18mailbox: tegra-hsp: Clear mailbox before using messagePekka Pessi
The Tegra RCE (Camera) driver expects the mailbox to be empty before processing the IVC messages. On RT kernel, the threads processing the IVC messages (which are invoked after `mbox_chan_received_data()` is called) may be on a different CPU or running with a higher priority than the HSP interrupt handler thread. This can cause it to act on the message before the mailbox gets cleared in the HSP interrupt handler resulting in a loss of IVC notification. Fix this by clearing the mailbox data register before calling `mbox_chan_received_data()`. Fixes: 8f585d14030d ("mailbox: tegra-hsp: Add tegra_hsp_sm_ops") Fixes: 74c20dd0f892 ("mailbox: tegra-hsp: Add 128-bit shared mailbox support") Cc: stable@vger.kernel.org Signed-off-by: Pekka Pessi <ppessi@nvidia.com> Signed-off-by: Kartik Rajput <kkartik@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-01-18mailbox: mpfs: fix copy and paste bug in probeDan Carpenter
This code accidentally checks ->ctrl_base instead of ->mbox_base so the error handling can never be triggered. Fixes: a4123ffab9ec ("mailbox: mpfs: support new, syscon based, devicetree configuration") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-01-18mailbox: th1520: Fix a NULL vs IS_ERR() bugDan Carpenter
The devm_ioremap() function doesn't return error pointers, it returns NULL. Update the error checking to match. Fixes: 5d4d263e1c6b ("mailbox: Introduce support for T-head TH1520 Mailbox driver") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Michal Wilczynski <m.wilczynski@samsung.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-01-18Merge tag 'trace-v6.13-rc7-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull tracing fix from Steven Rostedt: "Fix regression in GFP output in trace events It was reported that the GFP flags in trace events went from human readable to just their hex values: gfp_flags=GFP_HIGHUSER_MOVABLE|__GFP_COMP to gfp_flags=0x140cca This was caused by a change that added the use of enums in calculating the GFP flags. As defines get translated into their values in the trace event format files, the user space tooling could easily convert the GFP flags into their symbols via the __print_flags() helper macro. The problem is that enums do not get converted, and the names of the enums show up in the format files and user space tooling cannot translate them. Add TRACE_DEFINE_ENUM() around the enums used for GFP flags which is the tracing infrastructure macro that informs the tracing subsystem what the values for enums and it can then expose that to user space" * tag 'trace-v6.13-rc7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: tracing: gfp: Fix the GFP enum values shown for user space tracing tools
2025-01-18perf test: Update event_groups test to use instructionsAthira Rajeev
In some of the powerpc platforms, event group testcase fails as below: # perf test -v 'Event groups' 69: Event groups : --- start --- test child forked, pid 9765 Using CPUID 0x00820200 Using hv_24x7 for uncore pmu event 0x0 0x0, 0x0 0x0, 0x0 0x0: Fail 0x0 0x0, 0x0 0x0, 0x1 0x3: Pass The testcase creates various combinations of hw, sw and uncore PMU events and verify group creation succeeds or fails as expected. This tests one of the limitation in perf where it doesn't allow creating a group of events from different hw PMUs. The testcase starts a leader event and opens two sibling events. The combination the fails is three hardware events in a group. "0x0 0x0, 0x0 0x0, 0x0 0x0: Fail" Type zero and config zero which translates to PERF_TYPE_HARDWARE and PERF_COUNT_HW_CPU_CYCLE. There is event constraint in powerpc that events using same counter cannot be programmed in a group. Here there is one alternative event for cycles, hence one leader and only one sibling event can go in as a group. if all three events (leader and two sibling events), are hardware events, use instructions as one of the sibling event. Since PERF_COUNT_HW_INSTRUCTIONS is a generic hardware event and present in all architectures, use this as third event. Reported-by: Tejas Manhas <Tejas.Manhas1@ibm.com> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com> Link: https://lore.kernel.org/r/20250110094620.94976-1-atrajeev@linux.vnet.ibm.com Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-01-18perf bench: Fix undefined behavior in cmpworker()Kuan-Wei Chiu
The comparison function cmpworker() violates the C standard's requirements for qsort() comparison functions, which mandate symmetry and transitivity: Symmetry: If x < y, then y > x. Transitivity: If x < y and y < z, then x < z. In its current implementation, cmpworker() incorrectly returns 0 when w1->tid < w2->tid, which breaks both symmetry and transitivity. This violation causes undefined behavior, potentially leading to issues such as memory corruption in glibc [1]. Fix the issue by returning -1 when w1->tid < w2->tid, ensuring compliance with the C standard and preventing undefined behavior. Link: https://www.qualys.com/2024/01/30/qsort.txt [1] Fixes: 121dd9ea0116 ("perf bench: Add epoll parallel epoll_wait benchmark") Cc: stable@vger.kernel.org Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com> Reviewed-by: James Clark <james.clark@linaro.org> Link: https://lore.kernel.org/r/20250116110842.4087530-1-visitorckw@gmail.com Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-01-18perf annotate: Prefer passing evsel to evsel->core.idxIan Rogers
An evsel idx may not be stable due to sorting, evlist removal, etc. Try to reduce it being part of APIs by explicitly passing the evsel in annotate code. Internally the code just reads evsel->core.idx so behavior is unchanged. Signed-off-by: Ian Rogers <irogers@google.com> Cc: Chen Ni <nichen@iscas.ac.cn> Cc: Athira Rajeev <atrajeev@linux.vnet.ibm.com> Link: https://lore.kernel.org/r/20250117181848.690474-1-irogers@google.com Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-01-18ALSA: scarlett2: Add device_setup option to use FCP driverGeoffrey D. Bennett
Add a new device_setup option (SCARLETT2_USE_FCP_DRIVER = 0x08) that allows users to opt in to using the new FCP driver instead of the existing scarlett2 driver for their device. This provides a way to test the new FCP driver on existing supported hardware while keeping the Scarlett2 driver as the default. When the SCARLETT2_USE_FCP_DRIVER bit is set in device_setup, the scarlett2 driver initialisation will hand off to the FCP driver instead of proceeding with its own initialisation. The FCP driver then provides access to the device via its hwdep interface. Signed-off-by: Geoffrey D. Bennett <g@b4.vu> Link: https://patch.msgid.link/94ffd7971d73cb0cbea6933b28f7528ce5b9edde.1737048528.git.g@b4.vu Signed-off-by: Takashi Iwai <tiwai@suse.de>
2025-01-18ALSA: FCP: Add Focusrite Control Protocol driverGeoffrey D. Bennett
Add a new kernel driver for the Focusrite Control Protocol (FCP), which is used by Focusrite Scarlett 2nd Gen, 3rd Gen, 4th Gen, Clarett USB, Clarett+, and Vocaster series audio interfaces. This driver provides a user-space control interface via ALSA's hwdep subsystem. Unlike the existing Scarlett2 driver which implements all ALSA controls in kernel space, this new FCP driver takes a different approach by providing a minimal kernel interface that allows a user-space driver to send FCP commands and receive notifications. The only control implemented in kernel space is the Level Meter, since it requires frequent polling of volatile data. While this driver supports all interfaces that the Scarlett2 driver works with, it is initially enabled only for 4th Gen 16i16, 18i16, and 18i20 interfaces that are not supported by the Scarlett2 driver. Signed-off-by: Geoffrey D. Bennett <g@b4.vu> Link: https://patch.msgid.link/597741a9b1198b965561547511d3d345f91cba20.1737048528.git.g@b4.vu Signed-off-by: Takashi Iwai <tiwai@suse.de>
2025-01-18Merge tag 'asoc-fix-v6.13-rc7' of ↵Takashi Iwai
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v6.13 A few final driver specific fixes - a couple of x86 ID field changes, plus bug fixes for simple-card-utils and nau8824.
2025-01-17Merge branch 'ethtool-get_ts_stats-for-dsa-and-ocelot-driver'Jakub Kicinski
Vladimir Oltean says: ==================== ethtool get_ts_stats() for DSA and ocelot driver After a recent patch set with fixes and general restructuring, Jakub asked for the Felix DSA driver to start reporting standardized statistics for hardware timestamping: https://lore.kernel.org/netdev/20241207180640.12da60ed@kernel.org/ Testing follows the same procedure as in the aforementioned series, with PTP packet loss induced through taprio: $ ethtool -I --show-time-stamping swp3 Time stamping parameters for swp3: Capabilities: hardware-transmit software-transmit hardware-receive software-receive software-system-clock hardware-raw-clock PTP Hardware Clock: 1 Hardware Transmit Timestamp Modes: off on onestep-sync Hardware Receive Filter Modes: none ptpv2-l4-event ptpv2-l2-event ptpv2-event Statistics: tx_pkts: 14591 tx_lost: 85 tx_err: 0 v1: https://lore.kernel.org/20241213140852.1254063-1-vladimir.oltean@nxp.com/ ==================== Link: https://patch.msgid.link/20250116104628.123555-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-17net: dsa: felix: report timestamping stats from the ocelot libraryVladimir Oltean
Make the linkage between the DSA user port ethtool_ops :: get_ts_info and the implementation from the Ocelot switch library. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Jakub Kicinski <kuba@kernel.org> Link: https://patch.msgid.link/20250116104628.123555-5-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-17net: mscc: ocelot: add TX timestamping statisticsVladimir Oltean
Add an u64 hardware timestamping statistics structure for each ocelot port. Export a function from the common switch library for reporting them to ethtool. This is called by the ocelot switchdev front-end for now. Note that for the switchdev driver, we report the one-step PTP packets as unconfirmed, even though in principle, for some transmission mechanisms like FDMA, we may be able to confirm transmission and bump the "pkts" counter in ocelot_fdma_tx_cleanup() instead. I don't have access to hardware which uses the switchdev front-end, and I've kept the implementation simple. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Jakub Kicinski <kuba@kernel.org> Link: https://patch.msgid.link/20250116104628.123555-4-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-17net: dsa: implement get_ts_stats ethtool operation for user portsVladimir Oltean
Integrate with the standard infrastructure for reporting hardware packet timestamping statistics. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Jakub Kicinski <kuba@kernel.org> Link: https://patch.msgid.link/20250116104628.123555-3-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-17net: ethtool: ts: add separate counter for unconfirmed one-step TX timestampsVladimir Oltean
For packets with two-step timestamp requests, the hardware timestamp comes back to the driver through a confirmation mechanism of sorts, which allows the driver to confidently bump the successful "pkts" counter. For one-step PTP, the NIC is supposed to autonomously insert its hardware TX timestamp in the packet headers while simultaneously transmitting it. There may be a confirmation that this was done successfully, or there may not. None of the current drivers which implement ethtool_ops :: get_ts_stats() also support HWTSTAMP_TX_ONESTEP_SYNC or HWTSTAMP_TX_ONESTEP_SYNC, so it is a bit unclear which model to follow. But there are NICs, such as DSA, where there is no transmit confirmation at all. Here, it would be wrong / misleading to increment the successful "pkts" counter, because one-step PTP packets can be dropped on TX just like any other packets. So introduce a special counter which signifies "yes, an attempt was made, but we don't know whether it also exited the port or not". I expect that for one-step PTP packets where a confirmation is available, the "pkts" counter would be bumped. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Jakub Kicinski <kuba@kernel.org> Link: https://patch.msgid.link/20250116104628.123555-2-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-17Merge branch 'mlxsw-move-tx-header-handling-to-pci-driver'Jakub Kicinski
Petr Machata says: ==================== mlxsw: Move Tx header handling to PCI driver Amit Cohen writes: Tx header should be added to all packets transmitted from the CPU to Spectrum ASICs. Historically, handling this header was added as a driver function, as Tx header is different between Spectrum and Switch-X. From May 2021, there is no support for SwitchX-2 ASIC, and all the relevant code was removed. For now, there is no justification to handle Tx header as part of spectrum.c, we can handle this as part of PCI, in skb_transmit(). This change will also be useful when XDP support will be added to mlxsw, as for XDP_TX and XDP_REDIRECT actions, Tx header should be added before transmitting the packet. Patch set overview: Patches #1-#2 add structure to store Tx header info and initialize it Patch #3 moves definitions of Tx header fields to txheader.h Patch #4 moves Tx header handling to PCI driver Patch #5 removes unnecessary attribute ==================== Link: https://patch.msgid.link/cover.1737044384.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-17mlxsw: Do not store Tx header length as driver parameterAmit Cohen
Tx header handling was moved to PCI code, as there is no several drivers which configure Tx header differently. Tx header length is stored as driver parameter, this is not really necessary as it always stores the same value. Remove this field and use the macro MLXSW_TXHDR_LEN explicitly. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Link: https://patch.msgid.link/1fb7b3f007de4d311e559c8a954b673d0895d5e9.1737044384.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-17mlxsw: Move Tx header handling to PCI driverAmit Cohen
Tx header should be added to all packets transmitted from the CPU to Spectrum ASICs. Historically, handling this header was added as a driver function, as Tx header is different between Spectrum and Switch-X. See SwitchX implementation in commit 31557f0f9755 ("mlxsw: Introduce Mellanox SwitchX-2 ASIC support"). From May 2021, there is no support for SwitchX-2 ASIC, and all the relevant code was removed. For now, there is no justification to handle Tx header as part of spectrum.c, we can handle this as part of PCI, in skb_transmit(). A future patch set will add support for XDP in mlxsw driver, to support XDP_TX and XDP_REDIRECT actions, Tx header should be added before transmitting the packet. As preparation for this, move Tx header handling to PCI driver, so then XDP code will not have to call API from spectrum.c. This also improves the code as now Tx header is pushed just before transmitting, so it is not done from many flows which might miss something. Note that for PTP, we should configure Tx header differently, use the fields from mlxsw_txhdr_info to configure the packets correctly in PCI driver. Handle VLAN tagging in switch driver, verify that packet which should be transmitted as data is tagged, otherwise, tag it. Remove the calls for thxdr_construct() functions, as now this is done as part of skb_transmit(). Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Link: https://patch.msgid.link/293a81e6f7d59a8ec9f9592edb7745536649ff11.1737044384.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-17mlxsw: Define Tx header fields in txheader.hAmit Cohen
The next patch will move Tx header constructing to pci.c. As preparation, move the definitions of Tx header fields from spectrum.c to txheader.h, so pci.c will include this header and can access the fields. Remove 'etclass' which is not used. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Link: https://patch.msgid.link/2250b5cb3998ab4850fc8251c3a0f5926d32e194.1737044384.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-17mlxsw: Initialize txhdr_info according to PTP operationsAmit Cohen
A next patch will construct Tx header as part of pci.c. The switch driver (mlxsw_spectrum.ko) should encapsulate all the differences between the different ASICs and the bus driver (mlxsw_pci.ko) should remain unaware. As preparation, add the relevant info as part of mlxsw_txhdr_info structure, so later bus driver will merely construct the Tx header based on information passed from the switch driver. Most of the packets are transmitted as control packets, but PTP packets in Spectrum-2 and Spectrum-3 should be handled differently. The driver transmits them as data packets, and the default VLAN tag (4095) is added if the packet is not already tagged. Extend PTP operations to store a boolean which indicates whether packets should be transmitted as data packets. Set it for Spectrum-2 and Spectrum-3 only. Extend mlxsw_txhdr_info to store fields which will be used later to construct Tx header. Initialize such fields according to the new boolean which is stored in PTP operations. Note that for now, mlxsw_txhdr_info structure is initialized, but not used, a next patch will use it. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Link: https://patch.msgid.link/efcaacd4bedef524e840a0c29f96cebf2c4bc0e0.1737044384.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-17mlxsw: Add mlxsw_txhdr_info structureAmit Cohen
mlxsw_tx_info structure is used to store information that is needed to process Tx completions when Tx time stamps are requested. A next patch will move Tx header handling from spectrum.c to pci.c. For that, some additional fields which are related to Tx should be passed to pci driver. As preparation, create an extended structure, called mlxsw_txhdr_info, and store mlxsw_tx_info inside. The new fields should not be added to mlxsw_tx_info structure as it is stored in the SKB control block which is of limited size. The next patch will extend the new structure with some fields which are needed in order to construct Tx header. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Link: https://patch.msgid.link/93aed1961f046f79f46869bab37a3faa5027751d.1737044384.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-17net/mlx5: fix unintentional sign extension on shift of dest_attr->vport.vhca_idColin Ian King
Shifting dest_attr->vport.vhca_id << 16 results in a promotion from an unsigned 16 bit integer to a 32 bit signed integer, this is then sign extended to a 64 bit unsigned long on 64 bitarchitectures. If vhca_id is greater than 0x7fff then this leads to a sign extended result where all the upper 32 bits of idx are set to 1. Fix this by casting vhca_id to the same type as idx before performing the shift. Fixes: 8e2e08a6d1e0 ("net/mlx5: fs, add support for dest vport HWS action") Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Acked-by: Moshe Shemesh <moshe@nvidia.com> Link: https://patch.msgid.link/20250116181700.96437-1-colin.i.king@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-17net: tc: improve qdisc error messagesJohn Ousterhout
The existing error message ("Invalid qdisc name") is confusing because it suggests that there is no qdisc with the given name. In fact, the name does refer to a valid qdisc, but it doesn't match the kind of an existing qdisc being modified or replaced. The new error message provides more detail to eliminate confusion. Signed-off-by: John Ousterhout <ouster@cs.stanford.edu> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Link: https://patch.msgid.link/20250116195642.2794-1-ouster@cs.stanford.edu Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-17Merge branch '100GbE' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue Tony Nguyen says: ==================== ice: support FW Recovery Mode Konrad Knitter says: Enable update of card in FW Recovery Mode * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: ice: support FW Recovery Mode devlink: add devl guard pldmfw: enable selected component update ==================== Link: https://patch.msgid.link/20250116212059.1254349-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-17hv_netvsc: Replace one-element array with flexible array memberThorsten Blum
Replace the deprecated one-element array with a modern flexible array member in the struct nvsp_1_message_send_receive_buffer_complete. Use struct_size_t(,,1) instead of sizeof() to maintain the same size. Compile-tested only. Link: https://github.com/KSPP/linux/issues/79 Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Tested-by: Roman Kisel <romank@linux.microsoft.com> Reviewed-by: Roman Kisel <romank@linux.microsoft.com> Link: https://patch.msgid.link/20250116211932.139564-2-thorsten.blum@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-17gtp: Prepare ip4_route_output_gtp() to .flowi4_tos conversion.Guillaume Nault
Use inet_sk_dscp() to get the socket DSCP value as dscp_t, instead of ip_sock_rt_tos() which returns a __u8. This will ease the conversion of fl4->flowi4_tos to dscp_t, which now just becomes a matter of dropping the inet_dscp_to_dsfield() call. Signed-off-by: Guillaume Nault <gnault@redhat.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/06bdb310a075355ff059cd32da2efc29a63981c9.1737034675.git.gnault@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-17dccp: Prepare dccp_v4_route_skb() to .flowi4_tos conversion.Guillaume Nault
Use inet_sk_dscp() to get the socket DSCP value as dscp_t, instead of ip_sock_rt_tos() which returns a __u8. This will ease the conversion of fl4->flowi4_tos to dscp_t, which now just becomes a matter of dropping the inet_dscp_to_dsfield() call. Signed-off-by: Guillaume Nault <gnault@redhat.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/208dc5ca28bb5595d7a545de026bba18b1d63bda.1737032802.git.gnault@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-17net/mlxfw: Drop hard coded max FW flash image sizeMaher Sanalla
Currently, mlxfw kernel module limits FW flash image size to be 10MB at most, preventing the ability to burn recent BlueField-3 FW that exceeds the said size limit. Thus, drop the hard coded limit. Instead, rely on FW's max_component_size threshold that is reported in MCQI register as the size limit for FW image. Fixes: 410ed13cae39 ("Add the mlxfw module for Mellanox firmware flash process") Signed-off-by: Maher Sanalla <msanalla@nvidia.com> Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Tested-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Link: https://patch.msgid.link/1737030796-1441634-1-git-send-email-moshe@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-17net: let net.core.dev_weight always be non-zeroLiu Jian
The following problem was encountered during stability test: (NULL net_device): NAPI poll function process_backlog+0x0/0x530 \ returned 1, exceeding its budget of 0. ------------[ cut here ]------------ list_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, \ next=ffff88905f746e40. WARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 \ __list_add_valid_or_report+0xf3/0x130 CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+ RIP: 0010:__list_add_valid_or_report+0xf3/0x130 Call Trace: ? __warn+0xcd/0x250 ? __list_add_valid_or_report+0xf3/0x130 enqueue_to_backlog+0x923/0x1070 netif_rx_internal+0x92/0x2b0 __netif_rx+0x15/0x170 loopback_xmit+0x2ef/0x450 dev_hard_start_xmit+0x103/0x490 __dev_queue_xmit+0xeac/0x1950 ip_finish_output2+0x6cc/0x1620 ip_output+0x161/0x270 ip_push_pending_frames+0x155/0x1a0 raw_sendmsg+0xe13/0x1550 __sys_sendto+0x3bf/0x4e0 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x5b/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The reproduction command is as follows: sysctl -w net.core.dev_weight=0 ping 127.0.0.1 This is because when the napi's weight is set to 0, process_backlog() may return 0 and clear the NAPI_STATE_SCHED bit of napi->state, causing this napi to be re-polled in net_rx_action() until __do_softirq() times out. Since the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() can be retriggered in enqueue_to_backlog(), causing this issue. Making the napi's weight always non-zero solves this problem. Triggering this issue requires system-wide admin (setting is not namespaced). Fixes: e38766054509 ("[NET]: Fix sysctl net.core.dev_weight") Fixes: 3d48b53fb2ae ("net: dev_weight: TX/RX orthogonality") Signed-off-by: Liu Jian <liujian56@huawei.com> Link: https://patch.msgid.link/20250116143053.4146855-1-liujian56@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-17selftests: net: give up on the cmsg_time accuracy on slow machinesJakub Kicinski
Commit b9d5f5711dd8 ("selftests: net: increase the delay for relative cmsg_time.sh test") widened the accepted value range 8x but we still see flakes (at a rate of around 7%). Return XFAIL for the most timing sensitive test on slow machines. Before: # ./cmsg_time.sh Case UDPv4 - TXTIME rel returned '8074us - 7397us < 4000', expected 'OK' FAIL - 1/36 cases failed After: # ./cmsg_time.sh Case UDPv4 - TXTIME rel returned '1123us - 941us < 500', expected 'OK' (XFAIL) Case UDPv6 - TXTIME rel returned '1227us - 776us < 500', expected 'OK' (XFAIL) OK Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20250116020105.931338-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-17Input: xpad - add support for Nacon Evol-X Xbox One ControllerMatheos Mattsson
Add Nacon Evol-X Xbox One to the list of supported devices. Signed-off-by: Matheos Mattsson <matheos.mattsson@gmail.com> Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com> Link: https://lore.kernel.org/r/20250107192830.414709-9-rojtberg@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2025-01-17Input: xpad - add unofficial Xbox 360 wireless receiver cloneNilton Perim Neto
Although it mimics the Microsoft's VendorID, it is in fact a clone. Taking into account that the original Microsoft Receiver is not being manufactured anymore, this drive can solve dpad issues encontered by those who still use the original 360 Wireless controller but are using a receiver clone. Signed-off-by: Nilton Perim Neto <niltonperimneto@gmail.com> Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com> Link: https://lore.kernel.org/r/20250107192830.414709-12-rojtberg@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2025-01-17Input: xpad - add support for wooting two he (arm)Jack Greiner
Add Wooting Two HE (ARM) to the list of supported devices. Signed-off-by: Jack Greiner <jack@emoss.org> Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com> Link: https://lore.kernel.org/r/20250107192830.414709-3-rojtberg@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2025-01-17Input: xpad - improve name of 8BitDo controller 2dc8:3106Leonardo Brondani Schenkel
8BitDo Pro 2 Wired Controller shares the same USB identifier (2dc8:3106) as a different device, so amend name to reflect that and reduce confusion as the user might think the controller was misdetected. Because Pro 2 Wired will not work in XTYPE_XBOXONE mode (button presses won't register), tagging it as XTYPE_XBOX360 remains appropriate. Signed-off-by: Leonardo Brondani Schenkel <leonardo@schenkel.net> Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com> Link: https://lore.kernel.org/r/20250107192830.414709-2-rojtberg@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2025-01-17Merge tag 'devicetree-fixes-for-6.13-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux Pull devicetree fixes from Rob Herring: "Another fix and testcase to avoid the newly added WARN in the case of non-translatable addresses" * tag 'devicetree-fixes-for-6.13-2' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: of/address: Fix WARN when attempting translating non-translatable addresses of/unittest: Add test that of_address_to_resource() fails on non-translatable address
2025-01-17Merge tag 'soc-fixes-6.13-4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull SoC fixes from Arnd Bergmann: "Two last minute fixes: one build issue on TI soc drivers, and a regression in the renesas reset controller driver" * tag 'soc-fixes-6.13-4' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: soc: ti: pruss: Fix pruss APIs reset: rzg2l-usbphy-ctrl: Assign proper of node to the allocated device
2025-01-17Merge tag 'platform-drivers-x86-v6.13-6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 Pull x86 platform driver fixes from Ilpo Järvinen: - dell-uart-backlight: Fix serdev race - lenovo-yoga-tab2-pro-1380-fastcharger: Fix serdev race * tag 'platform-drivers-x86-v6.13-6' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: platform/x86: lenovo-yoga-tab2-pro-1380-fastcharger: fix serdev race platform/x86: dell-uart-backlight: fix serdev race
generated by cgit (git 2.34.1) at 2025-09-12 10:25:48 +0000