1. 23 Dec, 2016 2 commits
  2. 22 Jan, 2016 1 commit
    • Allen Hubbe's avatar
      NTB: Fix macro parameter conflict with field name · 03beaec8
      Allen Hubbe authored
      If the parameter given to the macro is replaced throughout the macro as
      it is evaluated.  The intent is that the macro parameter should replace
      the only the first parameter to container_of().  However, the way the
      macro was written, it would also inadvertantly replace a structure field
      name.  If a parameter of any other name is given to the macro, it will
      fail to compile, if the structure does not contain a field of the same
      name.  At worst, it will compile, and hide improper access of an
      unintended field in the structure.
      Change the macro parameter name, so it does not conflict with the
      structure field name.
      Signed-off-by: default avatarAllen Hubbe <Allen.Hubbe@emc.com>
      Acked-by: default avatarDave Jiang <dave.jiang@intel.com>
      Signed-off-by: default avatarJon Mason <jdmason@kudzu.us>
  3. 11 Jan, 2016 1 commit
  4. 08 Nov, 2015 1 commit
  5. 07 Sep, 2015 1 commit
  6. 04 Jul, 2015 2 commits
  7. 02 Jul, 2015 1 commit
  8. 17 Oct, 2014 3 commits
  9. 07 Apr, 2014 3 commits
  10. 20 Nov, 2013 1 commit
  11. 05 Sep, 2013 2 commits
  12. 03 Sep, 2013 5 commits
    • Jon Mason's avatar
      NTB: Enable 32bit Support · ac477afb
      Jon Mason authored
      Correct the issues on NTB that prevented it from working on x86_32 and
      modify the Kconfig to allow it to be permitted to be used in that
      environment as well.
      Signed-off-by: default avatarJon Mason <jon.mason@intel.com>
    • Jon Mason's avatar
      NTB: Update Device IDs · be4dac0f
      Jon Mason authored
      Add support for new Intel NTB devices on upcoming Xeon hardware.  Since
      the Xeon hardware design is already in place in the driver, all that is
      needed are the new device ids.
      Remove the device IDs for NTB devs running in Transparent Bridge mode,
      as this driver is not being used for those devices.
      Rename the device IDs for NTB devs running in NTB-RP mode to better
      identify their usage model.  "PS" to denote the Primary Side of NTB, and
      "SS" to denote the secondary side.  The primary side is the interface
      exposed to the local system, and the secondary side is the interface
      exposed to the remote system.
      Signed-off-by: default avatarJon Mason <jon.mason@intel.com>
    • Jon Mason's avatar
      NTB: BWD Link Recovery · 113bf1c9
      Jon Mason authored
      The BWD NTB device will drop the link if an error is encountered on the
      point-to-point PCI bridge.  The link will stay down until all errors are
      cleared and the link is re-established.  On link down, check to see if
      the error is detected, if so do the necessary housekeeping to try and
      recover from the error and reestablish the link.
      There is a potential race between the 2 NTB devices recovering at the
      same time.  If the times are synchronized, the link will not recover and the
      driver will be stuck in this loop forever.  Add a random interval to the
      recovery time to prevent this race.
      Signed-off-by: default avatarJon Mason <jon.mason@intel.com>
    • Jon Mason's avatar
      NTB: Xeon Errata Workaround · 948d3a65
      Jon Mason authored
      There is a Xeon hardware errata related to writes to SDOORBELL or
      B2BDOORBELL in conjunction with inbound access to NTB MMIO Space, which
      may hang the system.  To workaround this issue, use one of the memory
      windows to access the interrupt and scratch pad registers on the remote
      system.  This bypasses the issue, but removes one of the memory windows
      from use by the transport.  This reduction of MWs necessitates adding
      some logic to determine the number of available MWs.
      Since some NTB usage methodologies may have unidirectional traffic, the
      ability to disable the workaround via modparm has been added.
      See BF113 in
      See BT119 in
      Signed-off-by: default avatarJon Mason <jon.mason@intel.com>
    • Jon Mason's avatar
      NTB: Correct debugfs to work with more than 1 NTB Device · 1517a3f2
      Jon Mason authored
      Debugfs was setup in NTB to only have a single debugfs directory.  This
      resulted in the leaking of debugfs directories and files when multiple
      NTB devices were present, due to each device stomping on the variables
      containing the previous device's values (thus preventing them from being
      freed on cleanup).  Correct this by creating a secondary directory of
      the PCI BDF for each device present, and nesting the previously existing
      information in those directories.
      Signed-off-by: default avatarJon Mason <jon.mason@intel.com>
  13. 21 Jan, 2013 1 commit
  14. 18 Jan, 2013 1 commit
    • Jon Mason's avatar
      PCI-Express Non-Transparent Bridge Support · fce8a7bb
      Jon Mason authored
      A PCI-Express non-transparent bridge (NTB) is a point-to-point PCIe bus
      connecting 2 systems, providing electrical isolation between the two subsystems.
      A non-transparent bridge is functionally similar to a transparent bridge except
      that both sides of the bridge have their own independent address domains.  The
      host on one side of the bridge will not have the visibility of the complete
      memory or I/O space on the other side of the bridge.  To communicate across the
      non-transparent bridge, each NTB endpoint has one (or more) apertures exposed to
      the local system.  Writes to these apertures are mirrored to memory on the
      remote system.  Communications can also occur through the use of doorbell
      registers that initiate interrupts to the alternate domain, and scratch-pad
      registers accessible from both sides.
      The NTB device driver is needed to configure these memory windows, doorbell, and
      scratch-pad registers as well as use them in such a way as they can be turned
      into a viable communication channel to the remote system.  ntb_hw.[ch]
      determines the usage model (NTB to NTB or NTB to Root Port) and abstracts away
      the underlying hardware to provide access and a common interface to the doorbell
      registers, scratch pads, and memory windows.  These hardware interfaces are
      exported so that other, non-mainlined kernel drivers can access these.
      ntb_transport.[ch] also uses the exported interfaces in ntb_hw.[ch] to setup a
      communication channel(s) and provide a reliable way of transferring data from
      one side to the other, which it then exports so that "client" drivers can access
      them.  These client drivers are used to provide a standard kernel interface
      (i.e., Ethernet device) to NTB, such that Linux can transfer data from one
      system to the other in a standard way.
      Signed-off-by: default avatarJon Mason <jon.mason@intel.com>
      Reviewed-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>