1. 05 10月, 2013 1 次提交
  2. 30 8月, 2013 1 次提交
  3. 22 8月, 2013 1 次提交
    • B
      sfc: Update MCDI protocol definitions for EF10 · f2b0befd
      Ben Hutchings 提交于
      EF10 controllers do not have shared memory for communication with the
      MC; instead it reads requests and writes responses in host memory,
      which allows for longer messages.  It is also responsible for all
      datapath control operations and hardware resource allocation, which
      requires a large number of new commands and adds more possible error
      cases.  MCDI v2 extends the message header to support this.
      
      Update the MCDI protocol definition header to include v2 lengths,
      errors and messages, and a few definitions specific to the
      SFC9100 family (codenames Farmingdale and Huntington) which is
      the first generation of EF10.
      
      Some messages have been extended, so adjust the code accordingly:
      - The request for MC_CMD_DRV_ATTACH now includes a datapath firmware
        ID.  This is ignored by Siena but we should fill it in anyway,
        initially always specifying low-latency datapath.
      - The response for MC_CMD_GET_LOOPBACK_MODES now includes a 40G
        field.  Accept shorter responses that don't include it.
      Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
      f2b0befd
  4. 21 8月, 2013 1 次提交
  5. 08 3月, 2013 1 次提交
    • L
      sfc: PTP changes to support improved UUID filtering mode · c939a316
      Laurence Evans 提交于
      There is a long-standing problem with the packet-timestamp matching in
      the driver. When a PTP packet is received by the MC, the FPGA
      timestamps the packet and the MC sends the timestamp and 6 bytes of
      the UUID to the driver. The driver then matches the timestamp against
      received packets using the same 6 bytes of UUID.
      
      The problem comes from the choice of which 6 bytes to use. The PTP
      spec is slightly contradictory and misleading in one of the two places
      where the UUIDs are discussed. From section 7.2.2.2 of the spec, a
      PTPD2 UUID can be either a EUI-64 or a EUI-64 constructed from a
      EUI-48. The typical ethernet based implementation uses a EUI-64
      constructed from a EUI-48. This works by taking the first 3 bytes of
      the MAC address of the NIC being used for PTP (the OUI), then
      inserting 0xFF, 0xFE, then taking the last 3 bytes of the MAC address
      giving
                MAC[0], MAC[1], MAC[2], 0xFF, 0xFE, MAC[3], MAC[4], MAC[5]
      The current MC firmware and driver discard the first two bytes of this
      UUID and packets are matched against timestamps using bytes 2 to 7 so
      there is a small risk that in a deployment of Solarflare PTP NICs used
      with other vendors NICs, that a PTP packet could be matched against
      the wrong timestamp. This applies to all other organisations whose
      third byte of the OUI is 0x53. It's a long list but I notice that it
      includes Cisco.
      
      The necessary modifications to use bytes 0-2 and 5-7 of the UUID to
      match against are quite small but introduce incompatibility between
      older version of the firmware and driver.
      
      When PTP is enabled via SO_TIMESTAMPING specifying PTP V2, the driver
      will try to enable PTP in the firmware using the enhanced mode
      (above). If the firmware returns an error, the driver will enable PTP
      in the firmware using the old mode.
      
      [bwh: Fix some style errors; remove private ioctl bits]
      Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
      c939a316
  6. 19 9月, 2012 2 次提交
  7. 11 7月, 2012 1 次提交
  8. 10 1月, 2012 1 次提交
  9. 11 8月, 2011 1 次提交
  10. 31 3月, 2011 1 次提交
  11. 01 3月, 2011 1 次提交
  12. 29 4月, 2010 1 次提交
  13. 04 2月, 2010 1 次提交
  14. 26 1月, 2010 1 次提交
  15. 30 11月, 2009 1 次提交