summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)Author
2023-12-04net: stmmac: fix FPE events losingJianheng Zhang
The status bits of register MAC_FPE_CTRL_STS are clear on read. Using 32-bit read for MAC_FPE_CTRL_STS in dwmac5_fpe_configure() and dwmac5_fpe_send_mpacket() clear the status bits. Then the stmmac interrupt handler missing FPE event status and leads to FPE handshaking failure and retries. To avoid clear status bits of MAC_FPE_CTRL_STS in dwmac5_fpe_configure() and dwmac5_fpe_send_mpacket(), add fpe_csr to stmmac_fpe_cfg structure to cache the control bits of MAC_FPE_CTRL_STS and to avoid reading MAC_FPE_CTRL_STS in those methods. Fixes: 5a5586112b92 ("net: stmmac: support FPE link partner hand-shaking procedure") Reviewed-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: Jianheng Zhang <Jianheng.Zhang@synopsys.com> Link: https://lore.kernel.org/r/CY5PR12MB637225A7CF529D5BE0FBE59CBF81A@CY5PR12MB6372.namprd12.prod.outlook.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-04octeontx2-pf: consider both Rx and Tx packet stats for adaptive interrupt ↵Naveen Mamindlapalli
coalescing The current adaptive interrupt coalescing code updates only rx packet stats for dim algorithm. This patch also updates tx packet stats which will be useful when there is only tx traffic. Also moved configuring hardware adaptive interrupt setting to driver dim callback. Fixes: 6e144b47f560 ("octeontx2-pf: Add support for adaptive interrupt coalescing") Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com> Signed-off-by: Suman Ghosh <sumang@marvell.com> Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com> Link: https://lore.kernel.org/r/20231201053330.3903694-1-sumang@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-04net: ethernet: ti: davinci_mdio: Update K3 SoCs list for errata i2329Ravi Gunasekaran
The errata i2329 affects all the currently available silicon revisions of AM62x, AM64x, AM65x, J7200, J721E and J721S2. So remove the revision string from the SoC list. The silicon revisions affected by the errata i2329 can be found under the MDIO module in the "Advisories by Modules" section of each SoC errata document listed below AM62x: https://www.ti.com/lit/er/sprz487c/sprz487c.pdf AM64X: https://www.ti.com/lit/er/sprz457g/sprz457g.pdf AM65X: https://www.ti.com/lit/er/sprz452i/sprz452i.pdf J7200: https://www.ti.com/lit/er/sprz491d/sprz491d.pdf J721E: https://www.ti.com/lit/er/sprz455d/sprz455d.pdf J721S2: https://www.ti.com/lit/er/sprz530b/sprz530b.pdf Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com> Reviewed-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20231201132033.29576-1-r-gunasekaran@ti.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-04eth: bnxt: link NAPI instances to queues and IRQsJakub Kicinski
Make bnxt compatible with the newly added netlink queue GET APIs. Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com> Reviewed-by: Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/170147336340.5260.6773000274196548907.stgit@anambiarhost.jf.intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-04net: Add NAPI IRQ supportAmritha Nambiar
Add support to associate the interrupt vector number for a NAPI instance. Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com> Reviewed-by: Sridhar Samudrala <sridhar.samudrala@intel.com> Link: https://lore.kernel.org/r/170147334728.5260.13221803396905901904.stgit@anambiarhost.jf.intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-04ice: Add support in the driver for associating queue with napiAmritha Nambiar
After the napi context is initialized, map the napi instance with the queue/queue-set on the corresponding irq line. Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com> Reviewed-by: Sridhar Samudrala <sridhar.samudrala@intel.com> Link: https://lore.kernel.org/r/170147332060.5260.13310934657151560599.stgit@anambiarhost.jf.intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-04arcnet: restoring support for multiple Sohard Arcnet cardsThomas Reichinger
Probe of Sohard Arcnet cards fails, if 2 or more cards are installed in a system. See kernel log: [ 2.759203] arcnet: arcnet loaded [ 2.763648] arcnet:com20020: COM20020 chipset support (by David Woodhouse et al.) [ 2.770585] arcnet:com20020_pci: COM20020 PCI support [ 2.772295] com20020 0000:02:00.0: enabling device (0000 -> 0003) [ 2.772354] (unnamed net_device) (uninitialized): PLX-PCI Controls ... [ 3.071301] com20020 0000:02:00.0 arc0-0 (uninitialized): PCI COM20020: station FFh found at F080h, IRQ 101. [ 3.071305] com20020 0000:02:00.0 arc0-0 (uninitialized): Using CKP 64 - data rate 2.5 Mb/s [ 3.071534] com20020 0000:07:00.0: enabling device (0000 -> 0003) [ 3.071581] (unnamed net_device) (uninitialized): PLX-PCI Controls ... [ 3.369501] com20020 0000:07:00.0: Led pci:green:tx:0-0 renamed to pci:green:tx:0-0_1 due to name collision [ 3.369535] com20020 0000:07:00.0: Led pci:red:recon:0-0 renamed to pci:red:recon:0-0_1 due to name collision [ 3.370586] com20020 0000:07:00.0 arc0-0 (uninitialized): PCI COM20020: station E1h found at C000h, IRQ 35. [ 3.370589] com20020 0000:07:00.0 arc0-0 (uninitialized): Using CKP 64 - data rate 2.5 Mb/s [ 3.370608] com20020: probe of 0000:07:00.0 failed with error -5 commit 5ef216c1f848 ("arcnet: com20020-pci: add rotary index support") changes the device name of all COM20020 based PCI cards, even if only some cards support this: snprintf(dev->name, sizeof(dev->name), "arc%d-%d", dev->dev_id, i); The error happens because all Sohard Arcnet cards would be called arc0-0, since the Sohard Arcnet cards don't have a PLX rotary coder. I.e. EAE Arcnet cards have a PLX rotary coder, which sets the first decimal, ensuring unique devices names. This patch adds two new card feature flags to indicate which cards support LEDs and the PLX rotary coder. For EAE based cards the names still depend on the PLX rotary coder (untested, since missing EAE hardware). For Sohard based cards, this patch will result in devices being called arc0, arc1, ... (tested). Signed-off-by: Thomas Reichinger <thomas.reichinger@sohard.de> Fixes: 5ef216c1f848 ("arcnet: com20020-pci: add rotary index support") Link: https://lore.kernel.org/r/20231130113503.6812-1-thomas.reichinger@sohard.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-04bnxt_en: Add 5760X (P7) PCI IDsMichael Chan
Now with basic support for the new chip family, add the PCI IDs of the new devices. Reviewed-by: Andy Gospodarek <gospo@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/20231201223924.26955-16-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-04bnxt_en: Report the new ethtool link modes in the new firmware interfaceMichael Chan
Add new look up entries to convert the new supported speeds, advertised speeds, etc to ethtool link modes. Reviewed-by: Damodharam Ammepalli <damodharam.ammepalli@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/20231201223924.26955-15-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-04bnxt_en: Support force speed using the new HWRM fieldsMichael Chan
Modify bnxt_force_link_speed() to support the new speeds stored in link_info->support_speeds2, including the new 400G speed. Reviewed-by: Ajit Khaparde <ajit.khaparde@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/20231201223924.26955-14-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-04bnxt_en: Support new firmware link parametersMichael Chan
Newer firmware supporting PAM4 112Gbps speeds use new parameters in firmware message structures. Detect the new firmware capability and add basic logic to report and store these new fields. Reviewed-by: Hongguang Gao <hongguang.gao@broadcom.com> Reviewed-by: Damodharam Ammepalli <damodharam.ammepalli@broadcom.com> Reviewed-by: Ajit Khaparde <ajit.khaparde@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/20231201223924.26955-13-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-04bnxt_en: Refactor ethtool speeds logicMichael Chan
Add helper functions to refactor the logic that converts firmware speed masks to ethtool speeds. Pass the phy_flags to bnxt_get_ethtool_speeds() and the call chain. The refactoring and the phy_flags will be needed when adding support for the new speeds in the next patches. Reviewed-by: Ajit Khaparde <ajit.khaparde@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/20231201223924.26955-12-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-04bnxt_en: Add support for new RX and TPA_START completion types for P7Michael Chan
These new completion types are supported on the new P7 chips. These new types have commonalities with the legacy types. After the refactoring, we mainly have to add new functions to handle the the new meta data formats and the RX hash information in the new types. Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/20231201223924.26955-11-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-04bnxt_en: Refactor and refine bnxt_tpa_start() and bnxt_tpa_end().Michael Chan
Refactor bnxt_tpa_start() by adding bnxt_tpa_metadata() to gather the metadata from the TPA_START completion. This makes it easier to support the new P7 chip which has a modified TPA_START completion structure with different metadata formats. We also add vlan_valid and cfa_code_valid fields to the bnxt_tpa_info structure so that the VLAN and VF rep logic can be common for all chips. The VLAN metadata is now collected in bnxt_tpa_start() only when it is valid and the vlan_valid field will be set. bnxt_tpa_end() can now use common VLAN logic for all chips. Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/20231201223924.26955-10-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-04bnxt_en: Refactor RX VLAN acceleration logic.Michael Chan
Refactor the logic in the RX path that checks for the accelerated VLAN tag by adding a new function. This will make it easier to support the new receive logic on P7 chips. Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/20231201223924.26955-9-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-04bnxt_en: Add new P7 hardware interface definitionsMichael Chan
Add new RX, TX, and TPA hardware interface structures and macros for the P7 chips. Reviewed-by: Andy Gospodarek <gospo@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/20231201223924.26955-8-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-04bnxt_en: Refactor RSS capability fieldsAjit Khaparde
Add a new rss_cap field in the per device struct bnxt and move all the RSS capability fields there. It will be easier to add new RSS capabilities for the new P7 chips. Signed-off-by: Ajit Khaparde <ajit.khaparde@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/20231201223924.26955-7-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-04bnxt_en: Implement the new toggle bit doorbell mechanism on P7 chipsMichael Chan
The new chip family passes the Toggle bits to the driver in the NQE notification. The driver now stores this value and sends it back to hardware when it re-arms the RX and TX CQs. Together with the earlier patch that guarantees the driver will only re-arm the CQ at the end of NAPI polling if it has seen a new NQE, this method allows the hardware to detect any dropped doorbells. Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/20231201223924.26955-6-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-04bnxt_en: Consolidate DB offset calculationHongguang Gao
The doorbell offset on P5 chips is hard coded. On the new P7 chips, it is returned by the firmware. Simplify the logic that determines this offset and store it in a new db_offset field in struct bnxt. Also, provide this offset to the RoCE driver in struct bnxt_en_dev. Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Hongguang Gao <hongguang.gao@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/20231201223924.26955-5-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-04bnxt_en: Define basic P7 macrosMichael Chan
Repurpose the BNXT_FLAG_CHIP_SR2 flag by renaming it to BNXT_FLAG_CHIP_P7 since the SR2 chip never went to production. The SR2 statictics structure is also renamed for the P7 chip. Define the basic P7 doorbell bits (Epoch. Toggle, etc) and implement the Epoch bit logic. The next higher bit beyond the legal doorbell mask is the Epoch bit used for doorbells on P7 chips. This bit is used by the chip to detect dropped doorbells. The 57608 chip ID belonging to the P7 family is also defined. Note that the PCI ID is not added until the last patch in the series. Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/20231201223924.26955-4-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-04bnxt_en: Update firmware interface to 1.10.3.15Michael Chan
This updated interface supports the new 5760X P7 chip family. It has the changes to support the new link speeds/modes and other changes for the basic L2 features. Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/20231201223924.26955-3-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-04bnxt_en: Fix backing store V2 logicMichael Chan
The current code determines the last backing store valid type during bnxt_hwrm_func_backing_store_qcaps_v2(). In effect, the last type is determined based on what firmware advertises. The more correct way is to determine it based on what the driver is configuring. The driver may not configure all the backing store types advertised by firmware. Move the logic to determine the last type to bnxt_backing_store_cfg_v2(). We need to pass the legacy enable flags to the function in case only the legacy types are being configured. Fixes: 236e237f8ffe ("bnxt_en: Add support for HWRM_FUNC_BACKING_STORE_CFG_V2 firmware calls") Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/20231201223924.26955-2-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-04net: phy: micrel: allow usage of generic ethernet-phy clockHeiko Stuebner
The generic ethernet-phy binding allows describing an external clock since commit 350b7a258f20 ("dt-bindings: net: phy: Document support for external PHY clk") for cases where the phy is not supplied by an oscillator but instead by a clock from the host system. And the old named "rmii-ref" clock from 2014 is only specified for phys of the KSZ8021, KSZ8031, KSZ8081, KSZ8091 types. So allow retrieving and enabling the optional generic clock on phys that do not provide a rmii-ref clock. Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20231201150131.326766-3-heiko@sntech.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-04net: phy: micrel: use devm_clk_get_optional_enabled for the rmii-ref clockHeiko Stuebner
While the external clock input will most likely be enabled, it's not guaranteed and clk_get_rate in some suppliers will even just return valid results when the clock is running. So use devm_clk_get_optional_enabled to retrieve and enable the clock in one go. Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20231201150131.326766-2-heiko@sntech.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-04r8152: Choose our USB config with choose_configuration() rather than probe()Douglas Anderson
If you deauthorize the r8152 device (by writing 0 to the "authorized" field in sysfs) and then reauthorize it (by writing a 1) then it no longer works. This is because when you do the above we lose the special configuration that we set in rtl8152_cfgselector_probe(). Deauthorizing causes the config to be set to -1 and then reauthorizing runs the default logic for choosing the best config. I made an attempt to fix it so that the config is kept across deauthorizing / reauthorizing [1] but it was a bit ugly. Let's instead use the new USB core feature to override choose_configuration(). This patch relies upon the patches ("usb: core: Don't force USB generic_subclass drivers to define probe()") and ("usb: core: Allow subclassed USB drivers to override usb_choose_configuration()") [1] https://lore.kernel.org/r/20231130154337.1.Ie00e07f07f87149c9ce0b27ae4e26991d307e14b@changeid Fixes: ec51fbd1b8a2 ("r8152: add USB device driver for config selection") Suggested-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Grant Grundler <grundler@chromium.org> Link: https://lore.kernel.org/r/20231201102946.v2.3.Ie00e07f07f87149c9ce0b27ae4e26991d307e14b@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-04spi: spl022: fix sleeping in interrupt contextMark Brown
Merge series from Nam Cao <namcao@linutronix.de>: While running the spl022, I got the following warning: BUG: sleeping function called from invalid context at drivers/spi/spi.c:1428 This is because between spi transfers, spi_transfer_delay_exec() (who may sleep if the delay is >10us) is called in interrupt context. This is a problem for anyone who runs this driver and need more than 10us delay. Patch 1 adds an error reporting mechanism, needed by patch 2 who switch to use the default spi_transfer_one_message(), which fix the problem. The series is tested with polling transfer mode and interrupt transfer mode. I can't test the DMA mode, so some help testing here is very appreciated.
2023-12-04r8152: Add RTL8152_INACCESSIBLE to r8153_aldps_en()Douglas Anderson
Delay loops in r8152 should break out if RTL8152_INACCESSIBLE is set so that they don't delay too long if the device becomes inaccessible. Add the break to the loop in r8153_aldps_en(). Fixes: 4214cc550bf9 ("r8152: check if disabling ALDPS is finished") Reviewed-by: Grant Grundler <grundler@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-04r8152: Add RTL8152_INACCESSIBLE to r8153_pre_firmware_1()Douglas Anderson
Delay loops in r8152 should break out if RTL8152_INACCESSIBLE is set so that they don't delay too long if the device becomes inaccessible. Add the break to the loop in r8153_pre_firmware_1(). Fixes: 9370f2d05a2a ("r8152: support request_firmware for RTL8153") Reviewed-by: Grant Grundler <grundler@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-04r8152: Add RTL8152_INACCESSIBLE to r8156b_wait_loading_flash()Douglas Anderson
Delay loops in r8152 should break out if RTL8152_INACCESSIBLE is set so that they don't delay too long if the device becomes inaccessible. Add the break to the loop in r8156b_wait_loading_flash(). Fixes: 195aae321c82 ("r8152: support new chips") Reviewed-by: Grant Grundler <grundler@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-04r8152: Add RTL8152_INACCESSIBLE checks to more loopsDouglas Anderson
Previous commits added checks for RTL8152_INACCESSIBLE in the loops in the driver. There are still a few more that keep tripping the driver up in error cases and make things take longer than they should. Add those in. All the loops that are part of this commit existed in some form or another since the r8152 driver was first introduced, though RTL8152_INACCESSIBLE was known as RTL8152_UNPLUG before commit 715f67f33af4 ("r8152: Rename RTL8152_UNPLUG to RTL8152_INACCESSIBLE") Fixes: ac718b69301c ("net/usb: new driver for RTL8152") Reviewed-by: Grant Grundler <grundler@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-04r8152: Hold the rtnl_lock for all of resetDouglas Anderson
As of commit d9962b0d4202 ("r8152: Block future register access if register access fails") there is a race condition that can happen between the USB device reset thread and napi_enable() (not) getting called during rtl8152_open(). Specifically: * While rtl8152_open() is running we get a register access error that's _not_ -ENODEV and queue up a USB reset. * rtl8152_open() exits before calling napi_enable() due to any reason (including usb_submit_urb() returning an error). In that case: * Since the USB reset is perform in a separate thread asynchronously, it can run at anytime USB device lock is not held - even before rtl8152_open() has exited with an error and caused __dev_open() to clear the __LINK_STATE_START bit. * The rtl8152_pre_reset() will notice that the netif_running() returns true (since __LINK_STATE_START wasn't cleared) so it won't exit early. * rtl8152_pre_reset() will then hang in napi_disable() because napi_enable() was never called. We can fix the race by making sure that the r8152 reset routines don't run at the same time as we're opening the device. Specifically we need the reset routines in their entirety rely on the return value of netif_running(). The only way to reliably depend on that is for them to hold the rntl_lock() mutex for the duration of reset. Grabbing the rntl_lock() mutex for the duration of reset seems like a long time, but reset is not expected to be common and the rtnl_lock() mutex is already held for long durations since the core grabs it around the open/close calls. Fixes: d9962b0d4202 ("r8152: Block future register access if register access fails") Reviewed-by: Grant Grundler <grundler@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-04octeontx2-pf: TC flower offload support for mirrorSuman Ghosh
This patch extends TC flower offload support for mirroring ingress traffic to a different PF/VF. Below is an example command, 'tc filter add dev eth1 ingress protocol ip flower src_ip <ip-addr> skip_sw action mirred ingress mirror dev eth2' Signed-off-by: Suman Ghosh <sumang@marvell.com> Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-04octeontx2-af: Add new mbox to support multicast/mirror offloadSuman Ghosh
A new mailbox is added to support offloading of multicast/mirror functionality. The mailbox also supports dynamic updation of the multicast/mirror list. Signed-off-by: Suman Ghosh <sumang@marvell.com> Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-02r8169: fix rtl8125b PAUSE frames blasting when suspendedChunHao Lin
When FIFO reaches near full state, device will issue pause frame. If pause slot is enabled(set to 1), in this time, device will issue pause frame only once. But if pause slot is disabled(set to 0), device will keep sending pause frames until FIFO reaches near empty state. When pause slot is disabled, if there is no one to handle receive packets, device FIFO will reach near full state and keep sending pause frames. That will impact entire local area network. This issue can be reproduced in Chromebox (not Chromebook) in developer mode running a test image (and v5.10 kernel): 1) ping -f $CHROMEBOX (from workstation on same local network) 2) run "powerd_dbus_suspend" from command line on the $CHROMEBOX 3) ping $ROUTER (wait until ping fails from workstation) Takes about ~20-30 seconds after step 2 for the local network to stop working. Fix this issue by enabling pause slot to only send pause frame once when FIFO reaches near full state. Fixes: f1bce4ad2f1c ("r8169: add support for RTL8125") Reported-by: Grant Grundler <grundler@chromium.org> Tested-by: Grant Grundler <grundler@chromium.org> Cc: stable@vger.kernel.org Signed-off-by: ChunHao Lin <hau@realtek.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/20231129155350.5843-1-hau@realtek.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-01nfp: ethtool: expose transmit SO_TIMESTAMPING capabilityYinjun Zhang
NFP always supports software time stamping of tx, now expose the capability through ethtool ops. Signed-off-by: Yinjun Zhang <yinjun.zhang@corigine.com> Signed-off-by: Louis Peens <louis.peens@corigine.com> Link: https://lore.kernel.org/r/20231129080413.83789-1-louis.peens@corigine.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-01net: ethernet: renesas: rcar_gen4_ptp: Depend on PTP_1588_CLOCKNiklas Söderlund
When breaking out the Gen4 gPTP support to its own module the dependency on the PTP_1588_CLOCK framework was left as optional and only stated for the driver using the module. This leads to issues when doing COMPILE_TEST of RENESAS_GEN4_PTP separately and PTP_1588_CLOCK is built as a module and the other as a built-in. Add an explicit depend on PTP_1588_CLOCK. While at it remove the optional support for PTP_1588_CLOCK from RENESAS_ETHER_SWITCH as the driver unconditionally calls the Gen4 gPTP module and thus also requires the PTP_1588_CLOCK framework. Reported-by: Arnd Bergmann <arnd@arndb.de> Fixes: 8c1c66235e03 ("net: ethernet: renesas: rcar_gen4_ptp: Break out to module") Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20231129111142.3322667-1-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-01hv_netvsc: rndis_filter needs to select NLSRandy Dunlap
rndis_filter uses utf8s_to_utf16s() which is provided by setting NLS, so select NLS to fix the build error: ERROR: modpost: "utf8s_to_utf16s" [drivers/net/hyperv/hv_netvsc.ko] undefined! Fixes: 1ce09e899d28 ("hyperv: Add support for setting MAC from within guests") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Haiyang Zhang <haiyangz@microsoft.com> Cc: K. Y. Srinivasan <kys@microsoft.com> Cc: Wei Liu <wei.liu@kernel.org> Cc: Dexuan Cui <decui@microsoft.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Simon Horman <horms@kernel.org> # build-tested Reviewed-by: Michael Kelley <mikelley@microsoft.com> Link: https://lore.kernel.org/r/20231130055853.19069-1-rdunlap@infradead.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-01octeontx2-af: debugfs: update CQ context fieldsNithin Dabilpuram
This patch update the CQ structure fields to support the feature added in new silicons and also dump these fields in debugfs. Signed-off-by: Nithin Dabilpuram <ndabilpuram@marvell.com> Signed-off-by: Geetha sowjanya <gakula@marvell.com> Link: https://lore.kernel.org/r/20231130060703.16769-1-gakula@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-01net/tg3: fix race condition in tg3_reset_task()Thinh Tran
When an EEH error is encountered by a PCI adapter, the EEH driver modifies the PCI channel's state as shown below: enum { /* I/O channel is in normal state */ pci_channel_io_normal = (__force pci_channel_state_t) 1, /* I/O to channel is blocked */ pci_channel_io_frozen = (__force pci_channel_state_t) 2, /* PCI card is dead */ pci_channel_io_perm_failure = (__force pci_channel_state_t) 3, }; If the same EEH error then causes the tg3 driver's transmit timeout logic to execute, the tg3_tx_timeout() function schedules a reset task via tg3_reset_task_schedule(), which may cause a race condition between the tg3 and EEH driver as both attempt to recover the HW via a reset action. EEH driver gets error event --> eeh_set_channel_state() and set device to one of error state above scheduler: tg3_reset_task() get returned error from tg3_init_hw() --> dev_close() shuts down the interface tg3_io_slot_reset() and tg3_io_resume() fail to reset/resume the device To resolve this issue, we avoid the race condition by checking the PCI channel state in the tg3_reset_task() function and skip the tg3 driver initiated reset when the PCI channel is not in the normal state. (The driver has no access to tg3 device registers at this point and cannot even complete the reset task successfully without external assistance.) We'll leave the reset procedure to be managed by the EEH driver which calls the tg3_io_error_detected(), tg3_io_slot_reset() and tg3_io_resume() functions as appropriate. Adding the same checking in tg3_dump_state() to avoid dumping all device registers when the PCI channel is not in the normal state. Signed-off-by: Thinh Tran <thinhtr@linux.vnet.ibm.com> Tested-by: Venkata Sai Duggi <venkata.sai.duggi@ibm.com> Reviewed-by: David Christensen <drc@linux.vnet.ibm.com> Reviewed-by: Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/20231201001911.656-1-thinhtr@linux.vnet.ibm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-01wifi: wcn36xx: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20231117093056.873834-12-u.kleine-koenig@pengutronix.de
2023-12-01wifi: ath5k: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20231117093056.873834-10-u.kleine-koenig@pengutronix.de
2023-12-01wifi: ath12k: avoid repeated hw access from arKarthikeyan Periyasamy
Currently, the helper functions are accessing mac80211 hw data from the radio (ar) structure repeatedly. So optimize these helper functions by storing mac80211 hw data locally and accessing it directly. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Signed-off-by: Karthikeyan Periyasamy <quic_periyasa@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20231120235812.2602198-3-quic_periyasa@quicinc.com
2023-12-01wifi: ath12k: Optimize the mac80211 hw data accessKarthikeyan Periyasamy
Currently mac80211 hw data is accessed by convert the hw to radio (ar) structure and then radio to hw structure which is not necessary in some places where mac80211 hw data is already present. So in that kind of places avoid the conversion and directly access the mac80211 hw data. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Signed-off-by: Karthikeyan Periyasamy <quic_periyasa@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20231120235812.2602198-2-quic_periyasa@quicinc.com
2023-12-01wifi: ath12k: add 320 MHz bandwidth enumsMuna Sinada
Add 320 MHz bandwidth as a new bandwidth enum for ATH12k driver. This is extending existing bandwidth related enums to include 320 MHz. This is a precursor to supporting 320 MHz in the future. Sanity test performed to confirm that there was no impact in existing bandwidths. Additionally update QuIC copyright to include 2023 in hal_rx.h. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00125-QCAHKSWPL_SILICONZ-1 Signed-off-by: Muna Sinada <quic_msinada@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20231116221839.1303170-1-quic_msinada@quicinc.com
2023-12-01wifi: rtw89: fix misbehavior of TX beacon in concurrent modeChih-Kang Chang
In concurrent mode, when STA interface is scanning, it causes AP interface TX beacon on wrong channel. We modified it to scan with the operating channel when one of the interfaces is already connected. Additionally, STA interface need to stop scan when AP interface is starting to avoid TX beacon on wrong channel. Finally, AP interface need to stop TX beacon when STA interface is scanning and switching to non-OP channel,This prevent other device to get beacons on wrong channel. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20231129070046.18443-5-pkshih@realtek.com
2023-12-01wifi: rtw89: refine remain on channel flow to improve P2P connectionChih-Kang Chang
We add a scanning check to avoid entering IPS after ROC (remain on channel) during scanning. Additionally, When P2P scanning, the flow is `1. p2p_listen step` and `2. configure filter` and `3. p2p_scan starts` in wpas, but in kernel, cfg80211 uses another workqueue to notify driver the filter change, so sometimes we see (1 > 3 > 2), that will cause Rx filter related to scan to be cleared. Therefore, we add a scanning check when configure filter to avoid scan results to be filtered. Finally, we cancel the ROC delayed workqueue before entering ROC to avoid entering twice, which might cause leaving ROC too early. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20231129070046.18443-4-pkshih@realtek.com
2023-12-01wifi: rtw89: Refine active scan behavior in 6 GHzPo-Hao Huang
The interval between sending each probe request is regulated. Before this patch, some packets are not sent out properly because of our HW limit. Extend the 6 GHz channel dwell time to cope with this. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20231129070046.18443-3-pkshih@realtek.com
2023-12-01wifi: rtw89: fix not entering PS mode after AP stopsPo-Hao Huang
The attempt to enter power save mode might fail if there are still beacons pending in the queue. This sometimes happens after stopping P2P GO or AP mode. Extend stop AP function and flush all beacons to resolve this. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20231129070046.18443-2-pkshih@realtek.com
2023-12-01wifi: rt2x00: make watchdog param per deviceStanislaw Gruszka
We can run PCI/MMIO devices together with USB devices in the system. Make watchdog parameter per device to avoid situation when plugin USB device change modparam_watchdog for PCI/MMIO device. Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl> Tested-by: Shiji Yang <yangshiji66@outlook.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20231126195358.500259-1-stf_xl@wp.pl
2023-12-01wifi: rtlwifi: Remove bridge vendor/device idsIlpo Järvinen
Neither vendorid nor deviceid in the struct mp_adapter is used so remove them. Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20231124084725.12738-11-ilpo.jarvinen@linux.intel.com
generated by cgit (git 2.34.1) at 2025-10-03 12:10:46 +0000