- 28 Sep, 2020 30 commits
-
-
Sasha Neftin authored
flash_bank_size and flash_base_addr field not in use and can be removed from a nvm_info structure Signed-off-by:
Sasha Neftin <sasha.neftin@intel.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com>
-
Vinicius Costa Gomes authored
When we set the BASET registers of i225 with a base_time in the future, i225 will "hold" all packets until that base_time is reached, causing a lot of TX Hangs. As this behaviour seems contrary to the expectations of the IEEE 802.1Q standard (section 8.6.9, especially 8.6.9.4.5), let's start by rejecting these types of schedules. If this is too limiting, we can for example, setup a timer to configure the BASET registers closer to the start time, only blocking the packets for a "short" while. Signed-off-by:
Vinicius Costa Gomes <vinicius.gomes@intel.com> Tested-by:
-
Vinicius Costa Gomes authored
The next patch will need a way to retrieve the current timestamp from the NIC's PTP clock. The 'i225' suffix is removed, if anything model specific is needed, those specifics should be hidden by this function. Signed-off-by:
-
Sasha Neftin authored
Boolean reset disable flag not applicable for i225 device and could be removed. Signed-off-by:
-
Vinicius Costa Gomes authored
Many TSN features depend on the internal PTP clock, so the internal PTP jumping when the adapter is reset can cause problems, usually in the form of "TX Hangs" warnings in the driver. The solution is to save the PTP time before a reset and restore it after the reset is done. The value of the PTP time is saved before a reset and we use the difference from CLOCK_MONOTONIC from reset time to now, to correct what's going to be the new PTP time. This is heavily inspired by commit bf4bf09b ("i40e: save PTP time before a device reset"). Signed-off-by:
-
Vinicius Costa Gomes authored
In i225, it's no longer necessary to use the SYSTIMR register to latch the timer value, the timestamp is latched when SYSTIML is read. Signed-off-by:
-
Sasha Neftin authored
Completion to commit 900d1e8b ("igc: Add LPI counters") LPI counters exposed by statistics update method. A EEE TX LPI counter reflect the transmitter entries EEE (IEEE 802.3az) into the LPI state. A EEE RX LPI counter reflect the receiver link partner entries into EEE(IEEE 802.3az) LPI state. Signed-off-by:
-
Andre Guedes authored
i225 advanced receive descriptor doesn't have the following extend error bits: CE, SE, SEQ, CXE. In addition to that, the bit TCPE is called L4E in the datasheet. Clean up the code accordingly, and get rid of the macro IGC_RXDEXT_ERR_FRAME_ERR_MASK since it doesn't make much sense anymore. Signed-off-by:
Andre Guedes <andre.guedes@intel.com> Tested-by:
-
Andre Guedes authored
The Tx timestamp timeout is already checked by the watchdog_task which runs periodically. In addition to that, from the ptp_tx work perspective, if __IGC_PTP_TX_IN_PROGRESS flag is set we always want handle the timestamp stored in hardware and update the skb. So remove the timeout check in igc_ptp_tx_work() function. Signed-off-by:
-
Andre Guedes authored
The ptp_tx work is scheduled only if TSICR.TXTS bit is set, therefore TSYNCTXCTL.TXTT_0 bit is expected to be set when we check it igc_ptp_tx_ work(). If it isn't, something is really off and rescheduling the ptp_tx work to check it later doesn't help much. This patch changes the code to WARN_ON_ONCE() if this situation ever happens. Signed-off-by:
-
Andre Guedes authored
Rename the IGC_TSYNCTXCTL_VALID macro to IGC_TSYNCTXCTL_TXTT_0 so it matches the datasheet. Signed-off-by:
-
Sasha Neftin authored
Add new device ID's for the next step of the silicon and reflect i221 and i226 parts Signed-off-by:
-
Gal Hammer authored
Fixed flash presence check for 82576 controllers so the part number string is read and displayed correctly. Signed-off-by:
Gal Hammer <ghammer@redhat.com> Tested-by:
-
Sven Auhagen authored
Add XDP support to the IGB driver. The implementation follows the IXGBE XDP implementation closely and I used the following patches as basis: 1. commit 92470808 ("ixgbe: add XDP support for pass and drop actions") 2. commit 33fdc82f ("ixgbe: add support for XDP_TX action") 3. commit ed93a398 ("ixgbe: tweak page counting for XDP_REDIRECT") Due to the hardware constraints of the devices using the IGB driver we must share the TX queues with XDP which means locking the TX queue for XDP. I ran tests on an older device to get better numbers. Test machine: Intel(R) Atom(TM) CPU C2338 @ 1.74GHz (2 Cores) 2x Intel I211 Routing Original Driver Network Stack: 382 Kpps Routing XDP Redirect (xdp_fwd_kern): 1.48 Mpps XDP Drop: 1.48 Mpps Using XDP we can achieve line rate forwarding even on an older Intel Atom CPU. Signed-off-by:
Sven Auhagen <sven.auhagen@voleatech.de> Tested-by:
Sandeep Penigalapati <sandeep.penigalapati@intel.com> Signed-off-by:
-
David S. Miller authored
Jakub Kicinski says: ==================== udp_tunnel: convert Intel drivers with shared tables This set converts Intel drivers which have the ability to spawn multiple netdevs, but have only one UDP tunnel port table. Appropriate support is added to the core infra in patch 1, followed by netdevsim support and a selftest. The table sharing works by core attaching the same table structure to all devices sharing the table. This means the reference count has to accommodate potentially large values. Once core is ready i40e and ice are converted. These are complex drivers, but we got a tested-by from Aaron, so we should be good :) Compared to v1 I've made sure the selftest is executable. Other than that patches 8 and 9 are actually from the Mellanox conversion series were kept out to avoid Mellanox vs Intel conflicts. Last patch is new, some docs to let users knows ethtool can now display UDP tunnel info. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
Add some information about VxLAN-related netdev features and how to dump port table via ethtool. Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Jakub Kicinski authored
Check UDP_TUNNEL_NIC_INFO_STATIC_IANA_VXLAN works as expected. Signed-off-by:
-
Jakub Kicinski authored
Allow setting UDP_TUNNEL_NIC_INFO_STATIC_IANA_VXLAN. Signed-off-by:
-
Jakub Kicinski authored
Convert ice to the new infra, use share port tables. Leave a tiny bit more error checking in place than usual, because this driver really does quite a bit of magic. We need to calculate the number of VxLAN and GENEVE entries the firmware has reserved. Thanks to the conversion the driver will no longer sleep in an atomic section. Signed-off-by:
-
Jakub Kicinski authored
ice_get_open_tunnel_port() is always passed TNL_ALL as the second parameter. Signed-off-by:
-
Jakub Kicinski authored
Make use of the "shared port table" to convert i40e to the new infra. i40e did not have any reference tracking, locking is also dodgy because rtnl gets released while talking to FW, so port may get removed from the table while it's getting added etc. On the good side i40e does not seem to be using the ports for TX so we can remove the table from the driver state completely. Signed-off-by:
-
Jakub Kicinski authored
Add a test run of checks validating the shared UDP tunnel port tables function as we expect. Signed-off-by:
-
Jakub Kicinski authored
Add the ability to simulate a device with a shared UDP tunnel port table. Try to reject the configurations and actions which are not supported by the core, so we don't get syzcaller etc. warning reports. Signed-off-by:
-
Jakub Kicinski authored
We should never see a removal of a port which is not in the table or adding a port to an occupied entry in the table. To make sure such errors don't escape the checks in the test script add a warning/kernel spat. Error injection will not trigger those, nor should it ever put us in a bad state. Signed-off-by:
-
Jakub Kicinski authored
Unfortunately recent Intel NIC designs share the UDP port table across netdevs. So far the UDP tunnel port state was maintained per netdev, we need to extend that to cater to Intel NICs. Expect NICs to allocate the info structure dynamically and link to the state from there. All the shared NICs will record port offload information in the one instance of the table so we need to make sure that the use count can accommodate larger numbers. Signed-off-by:
-
David S. Miller authored
Dan Murphy says: ==================== DP83869 WoL and Speed optimization Add the WoL and Speed Optimization (aka downshift) support for the DP83869 Ethernet PHY. ==================== Signed-off-by: -
Dan Murphy authored
Set the speed optimization bit on the DP83869 PHY. Speed optimization, also known as link downshift, enables fallback to 100M operation after multiple consecutive failed attempts at Gigabit link establishment. Such a case could occur if cabling with only four wires (two twisted pairs) were connected instead of the standard cabling with eight wires (four twisted pairs). The number of failed link attempts before falling back to 100M operation is configurable. By default, four failed link attempts are required before falling back to 100M. Signed-off-by:
Dan Murphy <dmurphy@ti.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Dan Murphy authored
This adds WoL support on TI DP83869 for magic, magic secure, unicast and broadcast. Signed-off-by:
-
Kunihiko Hayashi authored
Use devm_alloc_etherdev() to simplify the code instead of alloc_etherdev(). Signed-off-by:
Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Signed-off-by:
-
Florian Fainelli authored
After commit d0186842 ("net: vlan: Avoid using BUG() in vlan_proto_idx()"), vlan_proto_idx() was changed to return a signed integer, however one of its called: vlan_group_prealloc_vid() was still using an unsigned integer for its return value, fix that. Fixes: d0186842 ("net: vlan: Avoid using BUG() in vlan_proto_idx()") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
- 27 Sep, 2020 10 commits
-
-
David S. Miller authored
Michael Chan says: ==================== bnxt_en: Update for net-next. This patch series adds 2 main features to the bnxt_en driver: 200G link speed support and FEC support with some refactoring of the link speed logic. The firmware interface is updated to have proper support for these 2 features. The ethtool preset max channel value is also adjusted properly to account for XDP and TCs. ==================== Signed-off-by: -
Michael Chan authored
The current logic that calculates the preset maximum value for combined channel does not take into account the rings used for XDP and mqprio TCs. Each of these features will reduce the number of TX rings. Add the logic to divide the TX rings accordingly based on whether the device is currently in XDP mode and whether TCs are in use. Reviewed-by:
Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
-
Michael Chan authored
This feature allows the user to set the different FEC modes on the NIC port. Any new setting will take effect immediately after a link toggle. Reviewed-by:
-
Michael Chan authored
The current code is reporting the FEC configured settings during link up. Change it to report the more useful active FEC encoding that may be negotiated or auto detected. Reviewed-by:
-
Michael Chan authored
Implement .get_fecparam() method to report the configured and active FEC settings. Also report the supported and advertised FEC settings to the .get_link_ksettings() method. Reviewed-by:
-
Edwin Peer authored
PORT_PHY_CONFIG is always sent with REQ_FLAGS_RESET_PHY set. This flag must be set in order for the firmware to institute the requested PHY change immediately, but it results in a link flap. This is unnecessary and results in an improved user experience if the PHY reconfiguration is avoided when the user requested speed does not constitute a change. Signed-off-by:
Edwin Peer <edwin.peer@broadcom.com> Signed-off-by:
-
Michael Chan authored
On some 200G dual port NICs, if one port is configured to 200G, firmware will disable the ethernet link on the other port. Firmware will send notification to the driver for the disabled port when this happens. Define a new field in the link_info structure to keep track of this state. The new phy_state field replaces the unused loop_back field. Log a message when the phy_state changes state. In the disabled state, disallow any PHY configurations on the disabled port as the firmware will fail all calls to configure the PHY in this state. Reviewed-by:
-
Edwin Peer authored
Add ethtool PAM4 link modes for: 50000baseCR_Full 100000baseCR2_Full 200000baseCR4_Full Signed-off-by: -
Edwin Peer authored
The firmware interface has added support for new link speeds using PAM4 modulation. Expand the bnxt_link_info structure to closely mirror the new firmware structures. Add logic to copy the PAM4 capabilities and settings from the firmware. Signed-off-by:
-
Edwin Peer authored
It will be necessary to update more than one field in the link_info structure when PAM4 speeds are added in a later patch. Instead of merely translating ethtool speed values to firmware speed values, change the responsiblity of this function to update all the necessary link_info fields required to force the speed change to the desired ethtool value. This also reduces code duplication somewhat at the two call sites, which otherwise both have to independently update link_info fields to turn off auto negotiation advertisements. Also use the appropriate REQ_FORCE_LINK_SPEED definitions. These happen to have the same values, but req_link_speed is utilimately passed as force_link_speed in HWRM_PORT_PHY_CFG which is not defined in terms of REQ_AUTO_LINK_SPEED. Reviewed-by:
Scott Branden <scott.branden@broadcom.com> Signed-off-by:
-
