1. 27 Jan, 2012 4 commits
    • Ben Hutchings's avatar
      sfc: Hold efx_nic::stats_lock while reading efx_nic::mac_stats · 1cb34522
      Ben Hutchings authored
      efx_nic::stats_lock is used to serialise stats updates, but each
      reader was dropping it before it finished reading efx_nic::mac_stats.
      
      If there were concurrent stats reads using procfs, or one using procfs
      and one using ethtool, an update could race with a read.  On a 32-bit
      system, the reader could see word-tearing of 64-bit stats (32 bits of
      the old value and 32 bits of the new).
      Signed-off-by: default avatarBen Hutchings <bhutchings@solarflare.com>
      1cb34522
    • Ben Hutchings's avatar
      sfc: Use new names for MC shared memory layout constants · 788ec41c
      Ben Hutchings authored
      These are defined alongside the firmware protocol in mcdi_pcol.h.
      Signed-off-by: default avatarBen Hutchings <bhutchings@solarflare.com>
      788ec41c
    • Ben Hutchings's avatar
      sfc: Make handling of MC reboot more reliable · 3f713bf4
      Ben Hutchings authored
      When the MC reboots, either as part of a firmware upgrade or due to a
      bug, it attempts to complete (with an error) any requests that were
      outstanding before the reboot.  Since there is an inherent race
      condition in checking this, it will also write to a status word in
      shared memory.
      
      If we look at each of these separately, we may detect each reboot
      twice, resulting in a spurious command failure after a firmware
      upgrade or frustrating recovery from a firmware bug.  Instead, if a
      request completion indicates a reboot, we must poll and clear the
      status word.
      
      This bug was previously masked by use of an incorrect address for the
      status word.  Fix that, using the definition now included in
      mcdi_pcol.h.
      Signed-off-by: default avatarBen Hutchings <bhutchings@solarflare.com>
      3f713bf4
    • Ben Hutchings's avatar
      sfc: Remove fallback for invalid permanent MAC address · e332bcb3
      Ben Hutchings authored
      By the time we look at the MAC address in efx_probe_port(), either the
      driver or the firmware has already validated the board configuration.
      The possibility of having an invalid MAC address just isn't worth
      considering.  It certainly isn't worth having a compile-time option
      for this.
      Signed-off-by: default avatarBen Hutchings <bhutchings@solarflare.com>
      e332bcb3
  2. 09 Jan, 2012 5 commits
  3. 05 Jan, 2012 3 commits
  4. 04 Jan, 2012 21 commits
  5. 03 Jan, 2012 7 commits