summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* arm64: dts: fsl: ls1028a: Enable eth port1 on the ls1028a QDS boardClaudiu Manoil2019-08-022-0/+46
| | | | | | | | | | | | | | | | | | | | | LS1028a has one Ethernet management interface. On the QDS board, the MDIO signals are multiplexed to either on-board AR8035 PHY device or to 4 PCIe slots allowing for SGMII cards. To enable the Ethernet ENETC Port 1, which can only be connected to a RGMII PHY, the multiplexer needs to be configured to route the MDIO to the AR8035 PHY. The MDIO/MDC routing is controlled by bits 7:4 of FPGA board config register 0x54, and value 0 selects the on-board RGMII PHY. The FPGA board config registers are accessible on the i2c bus, at address 0x66. The PF3 MDIO PCIe integrated endpoint device allows for centralized access to the MDIO bus. Add the corresponding devicetree node and set it to be the MDIO bus parent. Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com> Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* dt-bindings: net: fsl: enetc: Add bindings for the central MDIO PCIe endpointClaudiu Manoil2019-08-021-3/+39
| | | | | | | | | | | The on-chip PCIe root complex that integrates the ENETC ethernet controllers also integrates a PCIe endpoint for the MDIO controller providing for centralized control of the ENETC mdio bus. Add bindings for this "central" MDIO Integrated PCIe Endpoint. Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* enetc: Add mdio bus driver for the PCIe MDIO endpointClaudiu Manoil2019-08-026-9/+132
| | | | | | | | | | | | | | | | | | | | | | | | ENETC ports can manage the MDIO bus via local register interface. However there's also a centralized way to manage the MDIO bus, via the MDIO PCIe endpoint device integrated by the same root complex that also integrates the ENETC ports (eth controllers). Depending on board design and use case, centralized access to MDIO may be better than using local ENETC port registers. For instance, on the LS1028A QDS board where MDIO muxing is required. Also, the LS1028A on-chip switch doesn't have a local MDIO register interface. The current patch registers the above PCIe endpoint as a separate MDIO bus and provides a driver for it by re-using the code used for local MDIO access. It also allows the ENETC port PHYs to be managed by this driver if the local "mdio" node is missing from the ENETC port node. Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* enetc: Clean up makefileClaudiu Manoil2019-08-021-12/+6
| | | | | | | | | | | Clean up overcomplicated makefile to make it more maintainable. Basically, there's a set of common objects shared between the PF and VF driver modules. This can be implemented in a simpler way, without conditionals, less repetition, allowing also for easier updates in the future. Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* enetc: Clean up local mdio bus allocationClaudiu Manoil2019-08-021-48/+46
| | | | | | | | | | | | | | | | | | | | What's needed is basically a pointer to the mdio registers. This is one way to store it inside bus->priv allocated space, without upsetting sparse. Reworked accessors to avoid __iomem casting. Used devm_* variant to further clean up the init error / remove paths. Fixes following sparse warning: warning: incorrect type in assignment (different address spaces) expected void *priv got struct enetc_mdio_regs [noderef] <asn:2>*[assigned] regs Fixes: ebfcb23d62ab ("enetc: Add ENETC PF level external MDIO support") Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'net-dsa-mv88e6xxx-add-support-for-MV88E6220'David S. Miller2019-08-026-26/+168
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Hubert Feurstein says: ==================== net: dsa: mv88e6xxx: add support for MV88E6220 This patch series adds support for the MV88E6220 chip to the mv88e6xxx driver. The MV88E6220 is almost the same as MV88E6250 except that the ports 2-4 are not routed to pins. Furthermore, PTP support is added to the MV88E6250 family. v2: - insert all 6220 entries in correct numerical order - introduce invalid_port_mask - move ptp_cc_mult* to ptp_ops and restored original ptp_adjfine code - added Andrews Reviewed-By to patch 2 and 4 ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: dsa: mv88e6xxx: add PTP support for MV88E6250 familyHubert Feurstein2019-08-024-11/+78
| | | | | | | | | | | | | | | | | | This adds PTP support for the MV88E6250 family. Signed-off-by: Hubert Feurstein <h.feurstein@gmail.com> Acked-by: Richard Cochran <richardcochran@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: dsa: mv88e6xxx: order ptp structs numerically ascendingHubert Feurstein2019-08-022-18/+18
| | | | | | | | | | | | | | | | As it is done for all the other structs within this driver. Signed-off-by: Hubert Feurstein <h.feurstein@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: dsa: mv88e6xxx: setup message port is not supported in the 6250 familiyHubert Feurstein2019-08-022-3/+32
| | | | | | | | | | | | | | | | | | The MV88E6250 family doesn't support the MV88E6XXX_PORT_CTL1_MESSAGE_PORT bit. Signed-off-by: Hubert Feurstein <h.feurstein@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: dsa: mv88e6xxx: introduce invalid_port_mask in mv88e6xxx_infoHubert Feurstein2019-08-022-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | With this it is possible to mark certain chip ports as invalid. This is required for example for the MV88E6220 (which is in general a MV88E6250 with 7 ports) but the ports 2-4 are not routed to pins. If a user configures an invalid port, an error is returned. Signed-off-by: Hubert Feurstein <h.feurstein@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
| * dt-bindings: net: dsa: marvell: add 6220 model to the 6250 familyHubert Feurstein2019-08-021-1/+1
| | | | | | | | | | | | | | | | The MV88E6220 is part of the MV88E6250 family. Signed-off-by: Hubert Feurstein <h.feurstein@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: dsa: mv88e6xxx: add support for MV88E6220Hubert Feurstein2019-08-023-1/+28
|/ | | | | | | | | The MV88E6220 is almost the same as MV88E6250 except that the ports 2-4 are not routed to pins. So the usable ports are 0, 1, 5 and 6. Signed-off-by: Hubert Feurstein <h.feurstein@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'net-phy-Add-AST2600-MDIO-support'David S. Miller2019-08-026-4/+250
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Andrew Jeffery says: ==================== net: phy: Add AST2600 MDIO support v2 of the ASPEED MDIO series addresses comments from Rob on the devicetree bindings and Andrew on the driver itself. v1 of the series can be found here: http://patchwork.ozlabs.org/cover/1138140/ ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: ftgmac100: Select ASPEED MDIO driver for the AST2600Andrew Jeffery2019-08-021-0/+1
| | | | | | | | | | | | | | | | | | Ensures we can talk to a PHY via MDIO on the AST2600, as the MDIO controller is now separate from the MAC. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: ftgmac100: Add support for DT phy-handle propertyAndrew Jeffery2019-08-021-4/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | phy-handle is necessary for the AST2600 which separates the MDIO controllers from the MAC. I've tried to minimise the intrusion of supporting the AST2600 to the FTGMAC100 by leaving in place the existing MDIO support for the embedded MDIO interface. The AST2400 and AST2500 continue to be supported this way, as it avoids breaking/reworking existing devicetrees. The AST2600 support by contrast requires the presence of the phy-handle property in the MAC devicetree node to specify the appropriate PHY to associate with the MAC. In the event that someone wants to specify the MDIO bus topology under the MAC node on an AST2400 or AST2500, the current auto-probe approach is done conditional on the absence of an "mdio" child node of the MAC. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: phy: Add mdio-aspeedAndrew Jeffery2019-08-023-0/+171
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The AST2600 design separates the MDIO controllers from the MAC, which is where they were placed in the AST2400 and AST2500. Further, the register interface is reworked again, so now we have three possible different interface implementations, however this driver only supports the interface provided by the AST2600. The AST2400 and AST2500 will continue to be supported by the MDIO support embedded in the FTGMAC100 driver. The hardware supports both C22 and C45 mode, but for the moment only C22 support is implemented. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
| * dt-bindings: net: Add aspeed, ast2600-mdio bindingAndrew Jeffery2019-08-021-0/+45
|/ | | | | | | | | | The AST2600 splits out the MDIO bus controller from the MAC into its own IP block and rearranges the register layout. Add a new binding to describe the new hardware. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* tipc: reduce risk of wakeup queue starvationJon Maloy2019-08-011-8/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit 365ad353c256 ("tipc: reduce risk of user starvation during link congestion") we allowed senders to add exactly one list of extra buffers to the link backlog queues during link congestion (aka "oversubscription"). However, the criteria for when to stop adding wakeup messages to the input queue when the overload abates is inaccurate, and may cause starvation problems during very high load. Currently, we stop adding wakeup messages after 10 total failed attempts where we find that there is no space left in the backlog queue for a certain importance level. The counter for this is accumulated across all levels, which may lead the algorithm to leave the loop prematurely, although there may still be plenty of space available at some levels. The result is sometimes that messages near the wakeup queue tail are not added to the input queue as they should be. We now introduce a more exact algorithm, where we keep adding wakeup messages to a level as long as the backlog queue has free slots for the corresponding level, and stop at the moment there are no more such slots or when there are no more wakeup messages to dequeue. Fixes: 365ad35 ("tipc: reduce risk of user starvation during link congestion") Reported-by: Tung Nguyen <tung.q.nguyen@dektech.com.au> Acked-by: Ying Xue <ying.xue@windriver.com> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'net-dsa-mv88e6xxx-avoid-some-redundant-VTU-operations'David S. Miller2019-08-011-84/+98
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Vivien Didelot says: ==================== net: dsa: mv88e6xxx: avoid some redundant VTU operations The mv88e6xxx driver currently uses a mv88e6xxx_vtu_get wrapper to get a single entry and uses a boolean to eventually initialize a fresh one. However the fresh entry is only needed in one place and mv88e6xxx_vtu_getnext is simple enough to call it directly. Doing so makes the code easier to read, especially for the return code expected by switchdev to honor software VLANs. In addition to not loading the VTU again when an entry is already correctly programmed, this also allows to avoid programming the broadcast entries again when updating a port's membership, from e.g. tagged to untagged. This patch series removes the mv88e6xxx_vtu_get wrapper in favor of direct calls to mv88e6xxx_vtu_getnext, and also renames the _mv88e6xxx_port_vlan_add and _mv88e6xxx_port_vlan_del helpers using an old underscore prefix convention. In case the port's membership is already correctly programmed in hardware, the following debug message may be printed: [ 745.989884] mv88e6085 2188000.ethernet-1:00: p4: already a member of VLAN 42 ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: dsa: mv88e6xxx: call vtu_getnext directly in vlan_addVivien Didelot2019-08-011-49/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Wrapping mv88e6xxx_vtu_getnext makes the code less easy to read and _mv88e6xxx_port_vlan_add is the only function requiring the preparation of a new VLAN entry. To simplify things up, remove the mv88e6xxx_vtu_get wrapper and explicit the VLAN lookup in _mv88e6xxx_port_vlan_add. This rework also avoids programming the broadcast entries again when changing a port's membership, e.g. from tagged to untagged. At the same time, rename the helper using an old underscore convention. Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: dsa: mv88e6xxx: call vtu_getnext directly in vlan_delVivien Didelot2019-08-011-6/+15
| | | | | | | | | | | | | | | | | | | | | | Wrapping mv88e6xxx_vtu_getnext makes the code less easy to read. Explicit the call to mv88e6xxx_vtu_getnext in _mv88e6xxx_port_vlan_del and the return value expected by switchdev in case of software VLANs. At the same time, rename the helper using an old underscore convention. Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: dsa: mv88e6xxx: call vtu_getnext directly in db load/purgeVivien Didelot2019-08-011-9/+22
| | | | | | | | | | | | | | | | | | | | mv88e6xxx_vtu_getnext is simple enough to call it directly in the mv88e6xxx_port_db_load_purge function and explicit the return code expected by switchdev for software VLANs when an hardware VLAN does not exist. Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: dsa: mv88e6xxx: explicit entry passed to vtu_getnextVivien Didelot2019-08-011-9/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | mv88e6xxx_vtu_getnext interprets two members from the input mv88e6xxx_vtu_entry structure: the (excluded) vid member to start the iteration from, and the valid argument specifying whether the VID must be written or not (only required once at the start of a loop). Explicit the assignation of these two fields right before calling mv88e6xxx_vtu_getnext, as it is done in the mv88e6xxx_vtu_get wrapper. Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: dsa: mv88e6xxx: lock mutex in vlan_prepareVivien Didelot2019-08-011-12/+6
|/ | | | | | | | | Lock the mutex in the mv88e6xxx_port_vlan_prepare function called by the DSA stack, instead of doing it in the internal mv88e6xxx_port_check_hw_vlan helper. Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch '100GbE' of ↵David S. Miller2019-08-0112-431/+527
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue Jeff Kirsher says: ==================== 100GbE Intel Wired LAN Driver Updates 2019-07-31 This series contains updates to ice driver only. Paul adds support for reporting what the link partner is advertising for flow control settings. Jake fixes the hardware statistics register which is prone to rollover since the statistic registers are either 32 or 40 bits wide, depending on which register is being read. So use a 64 bit software statistic to store off the hardware statistics to track past when it rolls over. Fixes an issue with the locking of the control queue, where locks were being destroyed at run time. Tony fixes an issue that was created when interrupt tracking was refactored and the call to ice_vsi_setup_vector_base() was removed from the PF VSI instead of the VF VSI. Adds a check before trying to configure a port to ensure that media is attached. Brett fixes an issue in the receive queue configuration where prefena (Prefetch Enable) was being set to 0 which caused the hardware to only fetch descriptors when there are none free in the cache for a received packet. Updates the driver to only bump the receive tail once per napi_poll call, instead of the current model of bumping the tail up to 4 times per napi_poll call. Adds statistics for receive drops at the port level to ethtool/netlink. Cleans up duplicate code in the allocation of receive buffer code. Akeem updates the driver to ensure that VFs stay disabled until the setup or reset is completed. Modifies the driver to use the allocated number of transmit queues per VSI to set up the scheduling tree versus using the total number of available transmit queues. Also fix the driver to update the total number of configured queues, after a successful VF request to change its number of queues before updating the corresponding VSI for that VF. Cleaned up unnecessary flags that are no longer needed. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * ice: Bump version numberTony Nguyen2019-07-311-1/+1
| | | | | | | | | | | | | | | | Update driver version to 0.7.5 Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ice: Remove flag to track VF interrupt statusAkeem G Abodunrin2019-07-312-16/+0
| | | | | | | | | | | | | | | | | | | | | | As a result of refactoring of VF VSIs interrupts code, there is no need to track its configuration status again with ICE_VF_STATE_CFG_INTR flag - In fact, it is not being checked anywhere in the code right now, so this patch removes the dead code as applicable to the flag. Signed-off-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ice: Remove unnecessary flag ICE_FLAG_MSIX_ENABrett Creeley2019-07-314-102/+48
| | | | | | | | | | | | | | | | | | | | | | This flag is not needed and is called every time we re-enable interrupts in the hotpath so remove it. Also remove ice_vsi_req_irq() because it was a wrapper function for ice_vsi_req_irq_msix() whose sole purpose was checking the ICE_FLAG_MSIX_ENA flag. Signed-off-by: Brett Creeley <brett.creeley@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ice: Don't return error for disabling LAN Tx queue that does existAkeem G Abodunrin2019-07-311-0/+3
| | | | | | | | | | | | | | | | | | | | | | Since Tx rings are being managed by FW/NVM, Tx rings might have not been set up or driver had already wiped them off - In that case, call to disable LAN Tx queue is being returned as not in existence. This patch makes sure we don't return unnecessary error for such scenario. Signed-off-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ice: Remove duplicate code in ice_alloc_rx_bufsBrett Creeley2019-07-311-11/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently if the call to ice_alloc_mapped_page() fails we jump to the no_buf label, possibly call ice_release_rx_desc(), and return true indicating that there is more work to do. In the success case we just fall out of the while loop, possibly call ice_alloc_mapped_page(), and return false saying we exhausted cleaned_count. This flow can be improved by breaking if ice_alloc_mapped_page() fails and then the flow outside of the while loop is the same for the failure and success case. Signed-off-by: Brett Creeley <brett.creeley@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ice: Add stats for Rx drops at the port levelBrett Creeley2019-07-312-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently we are not reporting dropped counts at the port level to ethtool or netlink. This was found when debugging Rx dropped issues and the total packets sent did not equal the total packets received minus the rx_dropped, which was very confusing. To determine dropped counts at the port level we need to read the PRTRPB_RDPC register. To fix reporting we will store the dropped counts in the PF's rx_discards. This will be reported to netlink by storing it in the PF VSI's rx_missed_errors signaling that the receiver missed the packet. Also, we will report this to ethtool in the rx_dropped.nic field. Signed-off-by: Brett Creeley <brett.creeley@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ice: Update number of VF queue before setting VSI resourcesAkeem G Abodunrin2019-07-311-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | In case there is a request from a VF to change its number of queues, and the request was successful, we need to update number of queues configured on the VF before updating corresponding VSI for that VF, especially LAN Tx queue tree and TC update, otherwise, we would continued to use old value of vf->num_vf_qs for allocated Tx/Rx queues... Signed-off-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ice: Set up Tx scheduling tree based on alloc VSI Tx queuesAkeem G Abodunrin2019-07-311-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch uses allocated number of Tx queues per VSI to set up its scheduling tree instead of using total number of available Tx queues. Only PF VSIs have total number of allocated Tx queues equal to number of available Tx queues, other VSIs have different number of queues configured. Signed-off-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ice: Only bump Rx tail and release buffers once per napi_pollBrett Creeley2019-07-311-15/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently we bump the Rx tail and release/give buffers to hardware every 16 descriptors. This causes us to bump Rx tail up to 4 times per napi_poll call. Also we are always bumping tail on an odd index and this is a problem because hardware ignores the lower 3 bits in the QRX_TAIL register. This is making it so hardware sees tail bumps only every 8 descriptors. Instead lets only bump Rx tail once per napi_poll if the value aligns with hardware's expectations of the lower 3 bits being cleared. Also only release/give Rx buffers once per napi_poll call. Signed-off-by: Brett Creeley <brett.creeley@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ice: Disable VFs until reset is completedAkeem G Abodunrin2019-07-311-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | This patch adds code to clear VFs enable status until reset is completed, and Tx/Rx rings are setup. Without this patch, the code flow request Tx queues to be disabled after reset, especially PFR - where VF VSI Tx rings have already been wiped off in the NVM and result to adminq error based on the call to disable Tx LAN queue in ice_reset_all_vfs function call. Signed-off-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ice: Do not configure port with no mediaTony Nguyen2019-07-312-82/+158
| | | | | | | | | | | | | | | | | | | | | | | | | | The firmware reports an error when trying to configure a port with no media. Instead of always configuring the port, check for media before attempting to configure it. In the absence of media, turn off link and poll for media to become available before re-enabling link. Move ice_force_phys_link_state() up to avoid forward declaration. Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ice: separate out control queue lock creationJacob Keller2019-07-313-29/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ice_init_all_ctrlq and ice_shutdown_all_ctrlq functions create and destroy the locks used to protect the send and receive process of each control queue. This is problematic, as the driver may use these functions to shutdown and re-initialize the control queues at run time. For example, it may do this in response to a device reset. If the driver failed to recover from a reset, it might leave the control queues offline. In this case, the locks will no longer be initialized. A later call to ice_sq_send_cmd will then attempt to acquire a lock that has been destroyed. It is incorrect behavior to access a lock that has been destroyed. Indeed, ice_aq_send_cmd already tries to avoid accessing an offline control queue, but the check occurs inside the lock. The root of the problem is that the locks are destroyed at run time. Modify ice_init_all_ctrlq and ice_shutdown_all_ctrlq such that they no longer create or destroy the locks. Introduce new functions, ice_create_all_ctrlq and ice_destroy_all_ctrlq. Call these functions in ice_init_hw and ice_deinit_hw. Now, the control queue locks will remain valid for the life of the driver, and will not be destroyed until the driver unloads. This also allows removing a duplicate check of the sq.count and rq.count values when shutting down the controlqs. The ice_shutdown_ctrlq function already checks this value under the lock. Previously commit dec64ff10ed9 ("ice: use [sr]q.count when checking if queue is initialized") needed this check to happen outside the lock, because it prevented duplicate attempts at destroying the locks. The driver may now safely use ice_init_all_ctrlq and ice_shutdown_all_ctrlq while handling reset events, without causing the locks to be invalid. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ice: Always set prefena when configuring an Rx queueBrett Creeley2019-07-312-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | Currently we are always setting prefena to 0. This is causing the hardware to only fetch descriptors when there are none free in the cache for a received packet instead of prefetching when it has used the last descriptor regardless of incoming packets. Fix this by allowing the hardware to prefetch Rx descriptors. Signed-off-by: Brett Creeley <brett.creeley@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ice: Move vector base setup to PF VSITony Nguyen2019-07-311-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | When interrupt tracking was refactored, during rebuild, the call to ice_vsi_setup_vector_base() was inadvertently removed from the PF VSI instead of being removed from the VF VSI. During reset, the failure to properly setup the vector base generates a call trace. Correct this so that resets/rebuilds properly complete. Fixes: cbe66bfee6a0 ("ice: Refactor interrupt tracking") Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ice: track hardware stat registers past rolloverJacob Keller2019-07-315-130/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, ice_stat_update32 and ice_stat_update40 will limit the value of the software statistic to 32 or 40 bits wide, depending on which register is being read. This means that if a driver is running for a long time, the displayed software register values will roll over to zero at 40 bits or 32 bits. This occurs because the functions directly assign the difference between the previous value and current value of the hardware statistic. Instead, add this value to the current software statistic, and then update the previous value. In this way, each time ice_stat_update40 or ice_stat_update32 are called, they will increment the software tracking value by the difference of the hardware register from its last read. The software tracking value will correctly count up until it overflows a u64. The only requirement is that the ice_stat_update functions be called at least once each time the hardware register overflows. While we're fixing ice_stat_update40, modify it to use rd64 instead of two calls to rd32. Additionally, drop the now unnecessary hireg function parameter. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ice: add lp_advertising flow control supportPaul Greenwalt2019-07-311-32/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for reporting link partner advertising when ETHTOOL_GLINKSETTINGS defined. Get pause param reports the Tx/Rx pause configured, and then ethtool issues ETHTOOL_GSET ioctl and ice_get_settings_link_up reports the negotiated Tx/Rx pause. Negotiated pause frame report per IEEE 802.3-2005 table 288-3. $ ethtool --show-pause ens6f0 Pause parameters for ens6f0: Autonegotiate: on RX: on TX: on RX negotiated: on TX negotiated: on $ ethtool ens6f0 Settings for ens6f0: Supported ports: [ FIBRE ] Supported link modes: 25000baseCR/Full Supported pause frame use: Symmetric Supports auto-negotiation: Yes Supported FEC modes: None BaseR RS Advertised link modes: 25000baseCR/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Advertised FEC modes: None BaseR RS Link partner advertised link modes: Not reported Link partner advertised pause frame use: Symmetric Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 25000Mb/s Duplex: Full Port: Direct Attach Copper PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: g Wake-on: g Current message level: 0x00000007 (7) drv probe link Link detected: yes When ETHTOOL_GLINKSETTINGS is not defined, get pause param reports the negotiated Tx/Rx pause. Signed-off-by: Paul Greenwalt <paul.greenwalt@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | Merge branch 'net-hns3-some-code-optimizations-bugfixes-features'David S. Miller2019-08-0116-153/+397
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Huazhong Tan says: ==================== net: hns3: some code optimizations & bugfixes & features This patch-set includes code optimizations, bugfixes and features for the HNS3 ethernet controller driver. [patch 01/12] adds support for reporting link change event. [patch 02/12] adds handler for NCSI error. [patch 03/12] fixes bug related to debugfs. [patch 04/12] adds a code optimization for setting ring parameters. [patch 05/12 - 09/12] adds some cleanups. [patch 10/12 - 12/12] adds some patches related to reset issue. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net: hns3: activate reset timer when calling reset_eventHuazhong Tan2019-08-011-3/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When calling hclge_reset_event() within HCLGE_RESET_INTERVAL, it returns directly now. If no one call it again, then the error which needs a reset to fix it can not be fixed. So this patch activates the reset timer for this case, and adds checking in the end of the reset procedure to make this error fixed earlier. Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Reviewed-by: Peng Li <lipeng321@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net: hns3: clear reset interrupt status in hclge_irq_handle()Huazhong Tan2019-08-014-13/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the reset interrupt is cleared in the reset task, which is too late. Since, when the hardware finish the previous reset, it can begin to do a new global/IMP reset, if this new coming reset type is same as the previous one, the driver will clear them together, then driver can not get that there is another reset, but the hardware still wait for the driver to deal with the second one. So this patch clears PF's reset interrupt status in the hclge_irq_handle(), the hardware waits for handshaking from driver before doing reset, so the driver and hardware deal with reset one by one. BTW, when VF doing global/IMP reset, it reads PF's reset interrupt register to get that whether PF driver's re-initialization is done, since VF's re-initialization should be done after PF's. So we add a new command and a register bit to do that. When VF receive reset interrupt, it sets up this bit, and PF finishes re-initialization send command to clear this bit, then VF do re-initialization. Fixes: 4ed340ab8f49 ("net: hns3: Add reset process in hclge_main") Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Reviewed-by: Yunsheng Lin <linyunsheng@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net: hns3: fix some reset handshake issueHuazhong Tan2019-08-016-15/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the driver sets handshake status to tell the hardware that the driver have downed the netdev and it can continue with reset process. The driver will clear the handshake status when re-initializing the CMDQ, and does not recover this status when reset fail, which may cause the hardware to wait for the handshake status to be set and not being able to continue with reset process. So this patch delays clearing handshake status just before UP, and recovers this status when reset fail. BTW, this patch adds a new function hclge(vf)_reset_handshake() to deal with the reset handshake issue, and renames HCLGE(VF)_NIC_CMQ_ENABLE to HCLGE(VF)_NIC_SW_RST_RDY which represents this register bit more accurately. Fixes: ada13ee3db7b ("net: hns3: add handshake with hardware while doing reset") Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Reviewed-by: Peng Li <lipeng321@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net: hns3: rename a member in struct hclge_mac_ethertype_idx_rd_cmdGuojia Liao2019-08-012-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The member 'mac_add' defined in hclge_mac_ethertype_idx_rd_cmd means MAC address, so 'mac_addr' is a better name for it. Signed-off-by: Guojia Liao <liaoguojia@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net: hns3: simplify hclge_cmd_query_error()Weihang Li2019-08-011-14/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The 4th and 5th parameter of hclge_cmd_query_error is useless, so this patch removes them. Signed-off-by: Weihang Li <liweihang@hisilicon.com> Reviewed-by: Peng Li <lipeng321@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net: hns3: minior error handling change for hclge_tm_schd_info_initYunsheng Lin2019-08-011-12/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When hclge_tm_schd_info_update calls hclge_tm_schd_info_init to initialize the schedule info, hdev->tm_info.num_pg and hdev->tx_sch_mode is not changed, which makes the checking in hclge_tm_schd_info_init unnecessary. So this patch moves the hdev->tm_info.num_pg and hdev->tx_sch_mode checking into hclge_tm_schd_init and changes the return type of hclge_tm_schd_info_init from int to void. Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com> Reviewed-by: Peng Li <lipeng321@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net: hns3: minor cleanup in hns3_clean_rx_ringYunsheng Lin2019-08-011-11/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The unused_count variable is used to indicate how many RX BD need attaching new buffer in hns3_clean_rx_ring, and the clean_count variable has the similar meaning. This patch removes the clean_count variable and use unused_count to uniformly indicate the RX BD that need attaching new buffer. This patch also clean up some coding style related to variable assignment in hns3_clean_rx_ring. Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com> Reviewed-by: Peng Li <lipeng321@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net: hns3: remove unnecessary variable in hclge_get_mac_vlan_cmd_status()Jian Shen2019-08-011-25/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The local variable return_status in hclge_get_mac_val_cmd_status() is useless. So this patch returns the error code directly, instead of using this variable. Also, replace some '%d' with '%u' in hclge_get_mac_val_cmd_status(). Signed-off-by: Jian Shen <shenjian15@huawei.com> Reviewed-by: Peng Li <lipeng321@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-18 22:57:38 +0000