1. 08 9月, 2016 1 次提交
    • S
      be2net: Support UE recovery in BEx/Skyhawk adapters · 710f3e59
      Sriharsha Basavapatna 提交于
      This patch supports recovery from UEs caused due to Transient Parity
      Errors (TPE), in BE2, BE3 and Skyhawk adapters. This change avoids
      system reboot when such errors occur. The driver recovers from these
      errors such that the adapter resumes full operational status as prior
      to the UE.
      
      Following is the list of changes in the driver to support this:
      
      o The driver registers its UE recoverable capability with ARM FW at init
      time. This also allows the driver to know if the feature is supported in
      the FW.
      
      o As the UE recovery requires precise time bound processing, the driver
      creates its own error recovery work queue with a single worker thread (per
      module, shared across functions).
      
      o Each function runs an error detection task at an interval of 1 second as
      required by the FW. The error detection logic already exists for BEx/SH,
      but it now runs in the context of a separate worker thread.
      
      o When an error is detected by the task, if it is recoverable, the PF0
      driver instance initiates a soft reset, while other PF driver instances
      wait for the reset to complete and the chip to become ready. Once
      the chip is ready, all driver instances including PF0, resume to
      reinitialize the respective functions.
      
      o The PF0 driver checks for some recovery criteria, to determine if the
      recovery can be initiated. If the criteria is not met, the PF0 driver does
      not initiate a soft reset, it retains the existing behavior to stop
      further processing and requires a reboot to get the chip to operational
      state again.
      
      o To allow each function to share the workq, while also making progress in
      its recovery process, a per-function recovery state machine is used.
      The per-function tasks avoid blocking operations like msleep() while in
      this state machine (until reinit state) and instead reschedule for the
      required delay.
      
      o With these changes, the existing error recovery code for Lancer also
      runs in the context of the new worker thread.
      Signed-off-by: NSriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      710f3e59
  2. 27 6月, 2016 1 次提交
  3. 08 6月, 2016 3 次提交
    • S
      be2net: Fix provisioning of RSS for VFs in multi-partition configurations · de2b1e03
      Somnath Kotur 提交于
      Currently, we do not distribute queue resources to enable RSS for VFs
      in multi-channel/partition configurations.
      Fix this by having each PF(SRIOV capable) calculate it's share of the
      15 RSS Policy Tables available per port before provisioning resources for
      all the VFs.
      This  proportional share calculation is done based on division of the
      PF's MAX VFs with the Total MAX VFs on that port. It also needs to
      learn about the no: of NIC PFs on the port and subtract that from
      the 15 RSS Policy Tables on the port.
      Signed-off-by: NSomnath Kotur <somnath.kotur@emulex.com>
      Signed-off-by: NSathya Perla <sathya.perla@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      de2b1e03
    • S
      be2net: Enable Wake-On-LAN from shutdown for Skyhawk · 45f13df7
      Sriharsha Basavapatna 提交于
      Skyhawk does support wake-up from ACPI shutdown state - S5, provided the
      platform supports it (like Auxiliary power source etc). The changes listed
      below are done to fix this.
      
      1) There's no need to defer the HW configuration of WOL to be_suspend().
      Remove this in be_suspend() and move it to be_set_wol() ethtool function
      so it is configured directly in the context of ethtool. This automatically
      takes care of the shutdown case.
      
      2) The driver incorrectly uses WOL_CAP field in the FW response to
      get_acpi_wol_cap() command, to determine if WOL is enabled. Instead the
      driver must rely on the macaddr field in the response to infer WOL state.
      
      3) In be_get_config() during init, if we find that WOL is enabled in FW,
      call pci_enable_wake() to enable pmcsr.pme_en bit. This is needed to
      support persistent WOL configuration provided by the FW in some platforms.
      
      4) Remove code in be_set_wol() that writes to PCICFG_PM_CONTROL_OFFSET
      to set pme_en bit; pci_enable_wake() sets that.
      
      Fixes: 028991e4 ("Enabling Wake-on-LAN is not supported in S5 state")
      Signed-off-by: NSriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
      Signed-off-by: NSathya Perla <sathya.perla@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      45f13df7
    • S
      be2net: use max-TXQs limit too while provisioning VF queue pairs · b9263cbf
      Suresh Reddy 提交于
      When the PF driver provisions resources for VFs, it currently only looks
      at max RSS queues available to calculate the number of VF queue pairs.
      This logic breaks when there are less number of TX-queues than RSS-queues.
      This patch fixes this problem by using the max-TXQs available in the
      PF-pool in the calculations. As a part of this change the
      be_calculate_vf_qs() routine is renamed as be_calculate_vf_res() and the
      code that calculates limits on other related resources is moved here to
      contain all resource calculation code inside one routine.
      Signed-off-by: NSuresh Reddy <suresh.reddy@broadcom.com>
      Signed-off-by: NSathya Perla <sathya.perla@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b9263cbf
  4. 04 3月, 2016 1 次提交
    • V
      be2net: don't enable multicast flag in be_enable_if_filters() routine · c1bb0a55
      Venkat Duvvuru 提交于
      When the interface is opened (in be_open()) the routine
      be_enable_if_filters() must be called to switch on the basic filtering
      capabilities of an interface that are not changed at run-time.
      These include the flags UNTAGGED, BROADCAST and PASS_L3L4_ERRORS.
      Other flags such as MULTICAST and PROMISC must be enabled later by
      be_set_rx_mode() based on the state in the netdev/adapter struct.
      
      be_enable_if_filters() routine is wrongly trying to enable MULTICAST flag
      without checking the current adapter state. This can cause the RX_FILTER
      cmds to the FW to fail.  This patch fixes this problem by only enabling
      the basic filtering flags in be_enable_if_filters().
      
      The VF must be able to issue RX_FILTER cmd with any filter flag, as long
      as the PF allowed those flags (if_cap_flags) in the iface it provisioned
      for the VF. This rule is applicable even when the VF doesn't have the
      FILTMGMT privilege. There is a bug in BE3 FW that wrongly fails RX_FILTER
      multicast programming cmds on VFs that don't have FILTMGMT privilege.
      This patch also helps in insulating the VF driver from be_open failures due
      to the FW bug. A fix for the BE3 FW issue will be available in
      versions >= 11.0.283.0 and 10.6.334.0
      Reported-by: NIvan Vecera <ivecera@redhat.com>
      Signed-off-by: NVenkat Duvvuru <venkatkumar.duvvuru@avagotech.com>
      Signed-off-by: NSathya Perla <sathya.perla@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c1bb0a55
  5. 11 2月, 2016 1 次提交
  6. 08 2月, 2016 1 次提交
  7. 31 12月, 2015 6 次提交
  8. 13 10月, 2015 1 次提交
  9. 08 8月, 2015 1 次提交
  10. 25 7月, 2015 1 次提交
  11. 11 7月, 2015 2 次提交
  12. 15 5月, 2015 1 次提交
    • V
      be2net: Support for OS2BMC. · 760c295e
      Venkata Duvvuru 提交于
      OS2BMC feature will allow the server to communicate with the on-board
      BMC/idrac (Baseboard Management Controller) over the LOM via
      standard Ethernet.
      
      When OS2BMC feature is enabled, the LOM will filter traffic coming
      from the host. If the destination MAC address matches the iDRAC MAC
      address, it will forward the packet to the NC-SI side band interface
      for iDRAC processing. Otherwise, it would send it out on the wire to
      the external network. Broadcast and multicast packets are sent on the
      side-band NC-SI channel and on the wire as well. Some of the packet
      filters are not supported in the NIC and hence driver will identify
      such packets and will hint the NIC to send those packets to the BMC.
      This is done by duplicating packets on the management ring. Packets
      are sent to the management ring, by setting mgmt bit in the wrb header.
      The NIC will forward the packets on the management ring to the BMC
      through the side-band NC-SI channel.
      
      Please refer to this online document for more details,
      http://www.dell.com/downloads/global/products/pedge/
      os_to_bmc_passthrough_a_new_chapter_in_system_management.pdf
      Signed-off-by: NVenkat Duvvuru <VenkatKumar.Duvvuru@Emulex.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      760c295e
  13. 10 5月, 2015 4 次提交
  14. 21 3月, 2015 1 次提交
  15. 05 3月, 2015 2 次提交
  16. 08 2月, 2015 6 次提交
  17. 25 1月, 2015 1 次提交
  18. 23 9月, 2014 2 次提交
  19. 14 9月, 2014 3 次提交
  20. 03 9月, 2014 1 次提交