aboutsummaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)AuthorFilesLines
2021-07-21usb: hso: remove the bailout parameterDongliang Mu1-3/+3
There are two invocation sites of hso_free_net_device. After refactoring hso_create_net_device, this parameter is useless. Remove the bailout in the hso_free_net_device and change the invocation sites of this function. Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-21usb: hso: fix error handling code of hso_create_net_deviceDongliang Mu1-10/+23
The current error handling code of hso_create_net_device is hso_free_net_device, no matter which errors lead to. For example, WARNING in hso_free_net_device [1]. Fix this by refactoring the error handling code of hso_create_net_device by handling different errors by different code. [1] https://syzkaller.appspot.com/bug?id=66eff8d49af1b28370ad342787413e35bbe76efe Reported-by: syzbot+44d53c7255bb1aea22d2@syzkaller.appspotmail.com Fixes: 5fcfb6d0bfcd ("hso: fix bailout in error case of probe") Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-21i40e: add support for PTP external synchronization clockPiotr Kwapulinski4-20/+871
Add support for external synchronization clock via GPIOs. 1PPS signals are handled via the dedicated 3 GPIOs: SDP3_2, SDP3_3 and GPIO_4. Previously it was not possible to use the external PTP synchronization clock. All possible HW configurations are supported. SDP3_2, SDP3_3, GPIO_4 off, off, off off, in_A, off off, out_A, off off, in_B, off off, out_B, off in_A, off, off in_A, in_B, off in_A, out_B, off out_A, off, off out_A, in_B, off in_B, off, off in_B, in_A, off in_B, out_A, off out_B, off, off out_B, in_A, off off, off, in_A off, out_A, in_A off, in_B, in_A off, out_B, in_A out_A, off, in_A out_A, in_B, in_A in_B, off, in_A in_B, out_A, in_A out_B, off, in_A off, off, out_A off, in_A, out_A off, in_B, out_A off, out_B, out_A in_A, off, out_A in_A, in_B, out_A in_A, out_B, out_A in_B, off, out_A in_B, in_A, out_A out_B, off, out_A out_B, in_A, out_A off, off, in_B off, in_A, in_B off, out_A, in_B off, out_B, in_B in_A, off, in_B in_A, out_B, in_B out_A, off, in_B out_B, off, in_B out_B, in_A, in_B off, off, out_B off, in_A, out_B off, out_A, out_B off, in_B, out_B in_A, off, out_B in_A, in_B, out_B out_A, off, out_B out_A, in_B, out_B in_B, off, out_B in_B, in_A, out_B in_B, out_A, out_B Tested with oscilloscope, 1PPS generator and ts2phc. Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Signed-off-by: Piotr Kwapulinski <piotr.kwapulinski@intel.com> Tested-by: Ashish K <ashishx.k@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-21net: phy: at803x: finish the phy id checking simplificationVladimir Oltean1-1/+1
The blamed commit was probably not tested on net-next, since it did not refactor the extra phy id check introduced in commit b856150c8098 ("net: phy: at803x: mask 1000 Base-X link mode"). Fixes: 8887ca5474bd ("net: phy: at803x: simplify custom phy id matching") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-21net: phylink: cleanup ksettings_setRussell King (Oracle)1-7/+9
We only need to fiddle about with the supported mask after we have validated the user's requested parameters. Simplify and streamline the code by moving the linkmode copy and update of the autoneg bit after validating the user's request. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-20igc: Increase timeout value for Speed 100/1000/2500Muhammad Husaini Zulkifli1-1/+3
As the cycle time is set to maximum of 1s, the TX Hang timeout need to be increase to avoid possible TX Hang. There is no dedicated number specific in data sheet for the timeout factor. Timeout factor was determined during the debugging to solve the "Tx Hang" issues that happen in some cases mainly during ETF(Earliest TxTime First). This can be test by using TSN Schedule Tx Tools udp_tai sample application. Signed-off-by: Muhammad Husaini Zulkifli <muhammad.husaini.zulkifli@intel.com> Acked-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-07-20igc: Set QBVCYCLET_S to 0 for TSN Basic SchedulingMuhammad Husaini Zulkifli1-1/+1
According to datasheet section 8.12.19, when there's no TSN offloading Shadow_QbvCycle bit[29:0] must be set to zero for basic scheduling. Signed-off-by: Muhammad Husaini Zulkifli <muhammad.husaini.zulkifli@intel.com> Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-07-20igc: Remove phy->type checkingSasha Neftin1-11/+4
i225 devices have only one phy->type: copper. There is no point checking phy->type during the igc_has_link method from the watchdog that invoked every 2 seconds. This patch comes to clean up these pointless checkings. Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-07-20igc: Remove _I_PHY_ID checkingSasha Neftin3-15/+4
i225 devices have only one PHY vendor. There is no point checking _I_PHY_ID during the link establishment and auto-negotiation process. This patch comes to clean up these pointless checkings. Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-07-20igc: Check if num of q_vectors is smaller than max before array accessSasha Neftin1-1/+8
Ensure that the adapter->q_vector[MAX_Q_VECTORS] array isn't accessed beyond its size. It was fixed by using a local variable num_q_vectors as a limit for loop index, and ensure that num_q_vectors is not bigger than MAX_Q_VECTORS. Suggested-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-07-20net/e1000e: Fix spelling mistake "The" -> "This"Tree Davies1-1/+1
There is a spelling mistake in the comment block. Signed-off-by: Tree Davies <tdavies@darkphysics.net> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-07-20e1000e: Add space to the debug printSasha Neftin1-2/+4
Minor fixes to allow debug prints more readable. Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-07-20e1000e: Add support for the next LOM generationSasha Neftin2-0/+8
Add devices IDs for the next LOM generations that will be available on the next Intel Client platforms This patch provides the initial support for these devices Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-07-20e1000e: Add support for Lunar LakeSasha Neftin5-0/+21
Add devices IDs for the next LOM generations that will be available on the next Intel Client platform (Lunar Lake) This patch provides the initial support for these devices Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-07-20e1000e: Additional PHY power saving in S0ixSasha Neftin1-0/+6
After transferring the MAC-PHY interface to the SMBus set the PHY to S0ix low power idle mode. Suggested-by: Dima Ruinskiy <dima.ruinskiy@intel.com> Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-07-20e1000e: Add polling mechanism to indicate CSME DPG exitSasha Neftin3-0/+26
Per guidance from the CSME architecture team, it may take up to 1 second for unconfiguring dynamic power gating mode. Practically it can take more time. Wait up to 2.5 seconds to indicate dynamic power gating exit from the S0ix configuration. Detect scenarios that take more than 1 second but less than 2.5 seconds will emit warning message. Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-07-20e1000e: Add handshake with the CSME to support S0ixSasha Neftin2-154/+176
On the corporate system, the driver will ask from the CSME (manageability engine) to perform device settings are required to allow S0ix residency. This patch provides initial support. Reviewed-by: Dima Ruinskiy <dima.ruinskiy@intel.com> Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-07-20net: phy: at803x: simplify custom phy id matchingRussell King1-11/+5
The at803x driver contains a function, at803x_match_phy_id(), which tests whether the PHY ID matches the value passed, comparing phy_id with phydev->phy_id and testing all bits that in the driver's mask. This is the same test that is used to match the driver, with phy_id replaced with the driver specified ID, phydev->drv->phy_id. Hence, we already know the value of the bits being tested if we look at phydev->drv->phy_id directly, and we do not require a complicated test to check them. Test directly against phydev->drv->phy_id instead. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Fabio Estevam <festevam@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-20net: marvell: clean up trigraph warning on ??! stringColin Ian King1-1/+1
The character sequence ??! is a trigraph and causes the following clang warning: drivers/net/ethernet/marvell/mvneta.c:2604:39: warning: trigraph ignored [-Wtrigraphs] Clean this by replacing it with single ?. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-20net: phy: intel-xway: Add RGMII internal delay configurationMartin Schiller1-0/+76
This adds the possibility to configure the RGMII RX/TX clock skew via devicetree. Simply set phy mode to "rgmii-id", "rgmii-rxid" or "rgmii-txid" and add the "rx-internal-delay-ps" or "tx-internal-delay-ps" property to the devicetree. Furthermore, a warning is now issued if the phy mode is configured to "rgmii" and an internal delay is set in the phy (e.g. by pin-strapping), as in the dp83867 driver. Signed-off-by: Martin Schiller <ms@dev.tdt.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-20net: phylink: add phy change pause mode debugRussell King (Oracle)1-2/+3
Augment the phy link debug prints with the pause state. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-20net: mvpp2: deny disabling autoneg for 802.3z modesRussell King (Oracle)1-0/+9
The documentation for Armada 8040 says: Bit 2 Field InBandAnEn In-band Auto-Negotiation enable. ... When <PortType> = 1 (1000BASE-X) this field must be set to 1. We presently ignore whether userspace requests autonegotiation or not through the ethtool ksettings interface. However, we have some network interfaces that wish to do this. To offer a consistent API across network interfaces, deny the ability to disable autonegotiation on mvpp2 hardware when in 1000BASE-X and 2500BASE-X. This means the only way to switch between 2500BASE-X and 1000BASE-X on SFPs that support this will be: # ethtool -s ethX advertise 0x20000006000 # 1000BASE-X Pause AsymPause # ethtool -s ethX advertise 0xe000 # 2500BASE-X Pause AsymPause Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Acked-by: Marek Behún <kabel@kernel.org> Acked-by: Marcin Wojtas <mw@semihalf.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-20net: mvneta: deny disabling autoneg for 802.3z modesRussell King (Oracle)1-6/+14
The documentation for Armada 38x says: Bit 2 Field InBandAnEn In-band Auto-Negotiation enable. ... When <PortType> = 1 (1000BASE-X) this field must be set to 1. We presently ignore whether userspace requests autonegotiation or not through the ethtool ksettings interface. However, we have some network interfaces that wish to do this. To offer a consistent API across network interfaces, deny the ability to disable autonegotiation on mvneta hardware when in 1000BASE-X and 2500BASE-X. This means the only way to switch between 2500BASE-X and 1000BASE-X on SFPs that support this will be: # ethtool -s ethX advertise 0x20000002000 # 1000BASE-X Pause # ethtool -s ethX advertise 0xa000 # 2500BASE-X Pause Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Acked-by: Marek Behún <kabel@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-20net: ipa: fix IPA v4.11 interconnect dataAlex Elder1-9/+4
Currently three interconnects are defined for the Qualcomm SC7280 SoC, but this was based on a misunderstanding. There should only be two interconnects defined: one between the IPA and system memory; and another between the AP and IPA config space. The bandwidths defined for the memory and config interconnects do not match what I understand to be proper values, so update these. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-20net: phy: add Maxlinear GPY115/21x/24x driverXu Liang3-0/+735
Add driver to support the Maxlinear GPY115, GPY211, GPY212, GPY215, GPY241, GPY245 PHYs. Separate from XWAY PHY driver because this series has different register layout and new features not supported in XWAY PHY. Signed-off-by: Xu Liang <lxu@maxlinear.com> Acked-by: Hauke Mehrtens <hmehrtens@maxlinear.com> Tested-by: Wong Vee Khee <vee.khee.wong@linux.intel.com> Tested-by: Wong Vee Khee <vee.khee.wong@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-20net: phy: add API to read 802.3-c45 IDsXu Liang1-0/+14
Add API to read 802.3-c45 IDs so that C22/C45 mixed device can use C45 APIs without failing ID checks. Signed-off-by: Xu Liang <lxu@maxlinear.com> Acked-by: Hauke Mehrtens <hmehrtens@maxlinear.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-20net: dsa: tag_8021q: add proper cross-chip notifier supportVladimir Oltean1-126/+6
The big problem which mandates cross-chip notifiers for tag_8021q is this: | sw0p0 sw0p1 sw0p2 sw0p3 sw0p4 [ user ] [ user ] [ user ] [ dsa ] [ cpu ] | +---------+ | sw1p0 sw1p1 sw1p2 sw1p3 sw1p4 [ user ] [ user ] [ user ] [ dsa ] [ dsa ] | +---------+ | sw2p0 sw2p1 sw2p2 sw2p3 sw2p4 [ user ] [ user ] [ user ] [ dsa ] [ dsa ] When the user runs: ip link add br0 type bridge ip link set sw0p0 master br0 ip link set sw2p0 master br0 It doesn't work. This is because dsa_8021q_crosschip_bridge_join() assumes that "ds" and "other_ds" are at most 1 hop away from each other, so it is sufficient to add the RX VLAN of {ds, port} into {other_ds, other_port} and vice versa and presto, the cross-chip link works. When there is another switch in the middle, such as in this case switch 1 with its DSA links sw1p3 and sw1p4, somebody needs to tell it about these VLANs too. Which is exactly why the problem is quadratic: when a port joins a bridge, for each port in the tree that's already in that same bridge we notify a tag_8021q VLAN addition of that port's RX VLAN to the entire tree. It is a very complicated web of VLANs. It must be mentioned that currently we install tag_8021q VLANs on too many ports (DSA links - to be precise, on all of them). For example, when sw2p0 joins br0, and assuming sw1p0 was part of br0 too, we add the RX VLAN of sw2p0 on the DSA links of switch 0 too, even though there isn't any port of switch 0 that is a member of br0 (at least yet). In theory we could notify only the switches which sit in between the port joining the bridge and the port reacting to that bridge_join event. But in practice that is impossible, because of the way 'link' properties are described in the device tree. The DSA bindings require DT writers to list out not only the real/physical DSA links, but in fact the entire routing table, like for example switch 0 above will have: sw0p3: port@3 { link = <&sw1p4 &sw2p4>; }; This was done because: /* TODO: ideally DSA ports would have a single dp->link_dp member, * and no dst->rtable nor this struct dsa_link would be needed, * but this would require some more complex tree walking, * so keep it stupid at the moment and list them all. */ but it is a perfect example of a situation where too much information is actively detrimential, because we are now in the position where we cannot distinguish a real DSA link from one that is put there to avoid the 'complex tree walking'. And because DT is ABI, there is not much we can change. And because we do not know which DSA links are real and which ones aren't, we can't really know if DSA switch A is in the data path between switches B and C, in the general case. So this is why tag_8021q RX VLANs are added on all DSA links, and probably why it will never change. On the other hand, at least the number of additions/deletions is well balanced, and this means that once we implement reference counting at the cross-chip notifier level a la fdb/mdb, there is absolutely zero need for a struct dsa_8021q_crosschip_link, it's all self-managing. In fact, with the tag_8021q notifiers emitted from the bridge join notifiers, it becomes so generic that sja1105 does not need to do anything anymore, we can just delete its implementation of the .crosschip_bridge_{join,leave} methods. Among other things we can simply delete is the home-grown implementation of sja1105_notify_crosschip_switches(). The reason why that is wrong is because it is not quadratic - it only covers remote switches to which we have a cross-chip bridging link and that does not cover in-between switches. This deletion is part of the same patch because sja1105 used to poke deep inside the guts of the tag_8021q context in order to do that. Because the cross-chip links went away, so needs the sja1105 code. Last but not least, dsa_8021q_setup_port() is simplified (and also renamed). Because our TAG_8021Q_VLAN_ADD notifier is designed to react on the CPU port too, the four dsa_8021q_vid_apply() calls: - 1 for RX VLAN on user port - 1 for the user port's RX VLAN on the CPU port - 1 for TX VLAN on user port - 1 for the user port's TX VLAN on the CPU port now get squashed into only 2 notifier calls via dsa_port_tag_8021q_vlan_add. And because the notifiers to add and to delete a tag_8021q VLAN are distinct, now we finally break up the port setup and teardown into separate functions instead of relying on a "bool enabled" flag which tells us what to do. Arguably it should have been this way from the get go. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-20net: dsa: tag_8021q: absorb dsa_8021q_setup into dsa_tag_8021q_{,un}registerVladimir Oltean2-37/+7
Right now, setting up tag_8021q is a 2-step operation for a driver, first the context structure needs to be created, then the VLANs need to be installed on the ports. A similar thing is true for teardown. Merge the 2 steps into the register/unregister methods, to be as transparent as possible for the driver as to what tag_8021q does behind the scenes. This also gets rid of the funny "bool setup == true means setup, == false means teardown" API that tag_8021q used to expose. Note that dsa_tag_8021q_register() must be called at least in the .setup() driver method and never earlier (like in the driver probe function). This is because the DSA switch tree is not initialized at probe time, and the cross-chip notifiers will not work. For symmetry with .setup(), the unregister method should be put in .teardown(). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-20net: dsa: make tag_8021q operations part of the coreVladimir Oltean2-14/+6
Make tag_8021q a more central element of DSA and move the 2 driver specific operations outside of struct dsa_8021q_context (which is supposed to hold dynamic data and not really constant function pointers). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-20net: dsa: let the core manage the tag_8021q contextVladimir Oltean4-38/+26
The basic problem description is as follows: Be there 3 switches in a daisy chain topology: | sw0p0 sw0p1 sw0p2 sw0p3 sw0p4 [ user ] [ user ] [ user ] [ dsa ] [ cpu ] | +---------+ | sw1p0 sw1p1 sw1p2 sw1p3 sw1p4 [ user ] [ user ] [ user ] [ dsa ] [ dsa ] | +---------+ | sw2p0 sw2p1 sw2p2 sw2p3 sw2p4 [ user ] [ user ] [ user ] [ user ] [ dsa ] The CPU will not be able to ping through the user ports of the bottom-most switch (like for example sw2p0), simply because tag_8021q was not coded up for this scenario - it has always assumed DSA switch trees with a single switch. To add support for the topology above, we must admit that the RX VLAN of sw2p0 must be added on some ports of switches 0 and 1 as well. This is in fact a textbook example of thing that can use the cross-chip notifier framework that DSA has set up in switch.c. There is only one problem: core DSA (switch.c) is not able right now to make the connection between a struct dsa_switch *ds and a struct dsa_8021q_context *ctx. Right now, it is drivers who call into tag_8021q.c and always provide a struct dsa_8021q_context *ctx pointer, and tag_8021q.c calls them back with the .tag_8021q_vlan_{add,del} methods. But with cross-chip notifiers, it is possible for tag_8021q to call drivers without drivers having ever asked for anything. A good example is right above: when sw2p0 wants to set itself up for tag_8021q, the .tag_8021q_vlan_add method needs to be called for switches 1 and 0, so that they transport sw2p0's VLANs towards the CPU without dropping them. So instead of letting drivers manage the tag_8021q context, add a tag_8021q_ctx pointer inside of struct dsa_switch, which will be populated when dsa_tag_8021q_register() returns success. The patch is fairly long-winded because we are partly reverting commit 5899ee367ab3 ("net: dsa: tag_8021q: add a context structure") which made the driver-facing tag_8021q API use "ctx" instead of "ds". Now that we can access "ctx" directly from "ds", this is no longer needed. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-20net: dsa: tag_8021q: create dsa_tag_8021q_{register,unregister} helpersVladimir Oltean2-17/+13
In preparation of moving tag_8021q to core DSA, move all initialization and teardown related to tag_8021q which is currently done by drivers in 2 functions called "register" and "unregister". These will gather more functionality in future patches, which will better justify the chosen naming scheme. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-20net: dsa: sja1105: delete the best_effort_vlan_filtering modeVladimir Oltean4-600/+23
Simply put, the best-effort VLAN filtering mode relied on VLAN retagging from a bridge VLAN towards a tag_8021q sub-VLAN in order to be able to decode the source port in the tagger, but the VLAN retagging implementation inside the sja1105 chips is not the best and we were relying on marginal operating conditions. The most notable limitation of the best-effort VLAN filtering mode is its incapacity to treat this case properly: ip link add br0 type bridge vlan_filtering 1 ip link set swp2 master br0 ip link set swp4 master br0 bridge vlan del dev swp4 vid 1 bridge vlan add dev swp4 vid 1 pvid When sending an untagged packet through swp2, the expectation is for it to be forwarded to swp4 as egress-tagged (so it will contain VLAN ID 1 on egress). But the switch will send it as egress-untagged. There was an attempt to fix this here: https://patchwork.kernel.org/project/netdevbpf/patch/20210407201452.1703261-2-olteanv@gmail.com/ but it failed miserably because it broke PTP RX timestamping, in a way that cannot be corrected due to hardware issues related to VLAN retagging. So with either PTP broken or pushing VLAN headers on egress for untagged packets being broken, the sad reality is that the best-effort VLAN filtering code is broken. Delete it. Note that this means there will be a temporary loss of functionality in this driver until it is replaced with something better (network stack RX/TX capability for "mode 2" as described in Documentation/networking/dsa/sja1105.rst, the "port under VLAN-aware bridge" case). We simply cannot keep this code until that driver rework is done, it is super bloated and tangled with tag_8021q. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-20Merge branch 's390-next'David S. Miller2-11/+70
Julian Wiedmann says: ==================== s390/qeth: updates 2021-07-20 please apply the following patch series for qeth to netdev's net-next tree. This removes the deprecated support for OSN-mode devices, and does some follow-on cleanups. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-20Merge branch 'veth-flexible-channel-numbers'David S. Miller1-53/+252
Paolo Abeni says: ==================== veth: more flexible channels number configuration XDP setups can benefit from multiple veth RX/TX queues. Currently veth allow setting such number only at creation time via the 'numrxqueues' and 'numtxqueues' parameters. This series introduces support for the ethtool set_channel operation and allows configuring the queue number via a new module parameter. The veth default configuration is not changed. Finally self-tests are updated to check the new features, with both valid and invalid arguments. This iteration is a rebase of the most recent RFC, it does not provide a module parameter to configure the default number of queues, but I think could be worthy RFC v1 -> RFC v2: - report more consistent 'combined' count - make set_channel as resilient as possible to errors - drop module parameter - but I would still consider it. - more self-tests ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-20Merge branch '40GbE' of ↵David S. Miller3-16/+73
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue Tony Nguyen says: ==================== 40GbE Intel Wired LAN Driver Updates 2021-07-19 This series contains updates to iavf and i40e drivers. Stefan Assmann adds locking to a path that does not acquire a spinlock where needed for i40e. He also adjusts locking of critical sections to help avoid races and removes overriding of the adapter state during pending reset for iavf driver. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-20veth: create by default nr_possible_cpus queuesPaolo Abeni1-0/+37
This allows easier XDP usage. The number of default active queues is not changed: 1 RX and 1 TX so that this does not introduce overhead on the datapath for queue selection. v1 -> v2: - drop the module parameter, force default to nr_possible_cpus - Toke Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-20veth: implement support for set_channel ethtool opPaolo Abeni1-2/+123
This change implements the set_channel() ethtool operation, preserving the current defaults values and allowing up set the number of queues in the range set ad device creation time. The update operation tries hard to leave the device in a consistent status in case of errors. RFC v1 -> RFC v2: - don't flip device status on set_channel() - roll-back the changes if possible on error - Jackub Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-20veth: factor out initialization helperPaolo Abeni1-49/+92
Extract in simpler helpers the code to enable and disable a range of xdp/napi instance, with the common property that "disable" helpers can't fail. Will be used by the next patch. No functional change intended. Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-20veth: always report zero combined channelsPaolo Abeni1-2/+0
veth get_channel currently reports for channels being both RX/TX and combined. As Jakub noted: """ ethtool man page is relatively clear, unfortunately the kernel code is not and few read the man page. A channel is approximately an IRQ, not a queue, and IRQ can't be dedicated and combined simultaneously """ This patch changes the information exposed by veth_get_channels, setting max_combined to zero, being more consistent with the above statement. The ethtool_channels is always cleared by the caller, we just need to avoid setting the 'combined' fields. Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-20Revert "igc: Export LEDs"Kurt Kanzenbach5-155/+0
This reverts commit cf8331825a8d10e46fa574fdf015a65cb5a6db86. There are better Linux interfaces to export the different LED modes and blinking reasons. Revert this patch for now and come up with better solution later. Suggested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de> Link: https://lore.kernel.org/r/20210719101640.16047-1-kurt@linutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-07-19iavf: fix locking of critical sectionsStefan Assmann1-7/+50
To avoid races between iavf_init_task(), iavf_reset_task(), iavf_watchdog_task(), iavf_adminq_task() as well as the shutdown and remove functions more locking is required. The current protection by __IAVF_IN_CRITICAL_TASK is needed in additional places. - The reset task performs state transitions, therefore needs locking. - The adminq task acts on replies from the PF in iavf_virtchnl_completion() which may alter the states. - The init task is not only run during probe but also if a VF gets stuck to reinitialize it. - The shutdown function performs a state transition. - The remove function performs a state transition and also free's resources. iavf_lock_timeout() is introduced to avoid waiting infinitely and cause a deadlock. Rather unlock and print a warning. Signed-off-by: Stefan Assmann <sassmann@kpanic.de> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-07-19iavf: do not override the adapter state in the watchdog taskStefan Assmann1-1/+0
The iavf watchdog task overrides adapter->state to __IAVF_RESETTING when it detects a pending reset. Then schedules iavf_reset_task() which takes care of the reset. The reset task is capable of handling the reset without changing adapter->state. In fact we lose the state information when the watchdog task prematurely changes the adapter state. This may lead to a crash if instead of the reset task the iavf_remove() function gets called before the reset task. In that case (if we were in state __IAVF_RUNNING previously) the iavf_remove() function triggers iavf_close() which fails to close the device because of the incorrect state information. This may result in a crash due to pending interrupts. kernel BUG at drivers/pci/msi.c:357! [...] Call Trace: [<ffffffffbddf24dd>] pci_disable_msix+0x3d/0x50 [<ffffffffc08d2a63>] iavf_reset_interrupt_capability+0x23/0x40 [iavf] [<ffffffffc08d312a>] iavf_remove+0x10a/0x350 [iavf] [<ffffffffbddd3359>] pci_device_remove+0x39/0xc0 [<ffffffffbdeb492f>] __device_release_driver+0x7f/0xf0 [<ffffffffbdeb49c3>] device_release_driver+0x23/0x30 [<ffffffffbddcabb4>] pci_stop_bus_device+0x84/0xa0 [<ffffffffbddcacc2>] pci_stop_and_remove_bus_device+0x12/0x20 [<ffffffffbddf361f>] pci_iov_remove_virtfn+0xaf/0x160 [<ffffffffbddf3bcc>] sriov_disable+0x3c/0xf0 [<ffffffffbddf3ca3>] pci_disable_sriov+0x23/0x30 [<ffffffffc0667365>] i40e_free_vfs+0x265/0x2d0 [i40e] [<ffffffffc0667624>] i40e_pci_sriov_configure+0x144/0x1f0 [i40e] [<ffffffffbddd5307>] sriov_numvfs_store+0x177/0x1d0 Code: 00 00 e8 3c 25 e3 ff 49 c7 86 88 08 00 00 00 00 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 48 8b 7b 28 e8 0d 44 RIP [<ffffffffbbbf1068>] free_msi_irqs+0x188/0x190 The solution is to not touch the adapter->state in iavf_watchdog_task() and let the reset task handle the state transition. Signed-off-by: Stefan Assmann <sassmann@kpanic.de> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-07-19i40e: improve locking of mac_filter_hashStefan Assmann1-3/+20
i40e_config_vf_promiscuous_mode() calls i40e_getnum_vf_vsi_vlan_filters() without acquiring the mac_filter_hash_lock spinlock. This is unsafe because mac_filter_hash may get altered in another thread while i40e_getnum_vf_vsi_vlan_filters() traverses the hashes. Simply adding the spinlock in i40e_getnum_vf_vsi_vlan_filters() is not possible as it already gets called in i40e_get_vlan_list_sync() with the spinlock held. Therefore adding a wrapper that acquires the spinlock and call the correct function where appropriate. Fixes: 37d318d7805f ("i40e: Remove scheduling while atomic possibility") Fix-suggested-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Stefan Assmann <sassmann@kpanic.de> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-07-18net: phy: Fix data type in DP83822 dp8382x_disable_wol()Marek Vasut1-5/+3
The last argument of phy_clear_bits_mmd(..., u16 val); is u16 and not int, just inline the value into the function call arguments. No functional change. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: David S. Miller <davem@davemloft.net> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-16vmxnet3: update to version 6Ronak Doshi2-3/+13
With all vmxnet3 version 6 changes incorporated in the vmxnet3 driver, the driver can configure emulation to run at vmxnet3 version 6, provided the emulation advertises support for version 6. Signed-off-by: Ronak Doshi <doshir@vmware.com> Acked-by: Guolin Yang <gyang@vmware.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-16vmxnet3: increase maximum configurable mtu to 9190Ronak Doshi2-2/+6
This patch increases the maximum configurable mtu to 9190 to accommodate jumbo packets of overlay traffic. Signed-off-by: Ronak Doshi <doshir@vmware.com> Acked-by: Guolin Yang <gyang@vmware.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-16vmxnet3: set correct hash type based on rss informationRonak Doshi2-9/+29
As vmxnet3 supports IP/TCP/UDP RSS, this patch sets appropriate hash type based on the type of RSS performed. Signed-off-by: Ronak Doshi <doshir@vmware.com> Acked-by: Guolin Yang <gyang@vmware.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-16vmxnet3: add support for ESP IPv6 RSSRonak Doshi1-0/+20
Vmxnet3 version 4 added support for ESP RSS. However, only IPv4 was supported. With vmxnet3 version 6, this patch enables RSS for ESP IPv6 packets as well. Signed-off-by: Ronak Doshi <doshir@vmware.com> Acked-by: Guolin Yang <gyang@vmware.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-16vmxnet3: remove power of 2 limitation on the queuesRonak Doshi1-3/+5
With version 6, vmxnet3 relaxes the restriction on queues to be power of two. This is helpful in cases (Edge VM) where vcpus are less than 8 and device requires more than 4 queues. Signed-off-by: Ronak Doshi <doshir@vmware.com> Acked-by: Guolin Yang <gyang@vmware.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-16vmxnet3: add support for 32 Tx/Rx queuesRonak Doshi3-60/+151
Currently, vmxnet3 supports maximum of 8 Tx/Rx queues. With increase in number of vcpus on a VM, to achieve better performance and utilize idle vcpus, we need to increase the max number of queues supported. This patch enhances vmxnet3 to support maximum of 32 Tx/Rx queues. Increasing the Rx queues also increases the probability of distrubuting the traffic from different flows to different queues with RSS. Signed-off-by: Ronak Doshi <doshir@vmware.com> Acked-by: Guolin Yang <gyang@vmware.com> Signed-off-by: David S. Miller <davem@davemloft.net>