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
http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-c5500-c3500-spec-update.pdf
See BT119 in
http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-e5-family-spec-update.pdfSigned-off-by: NJon Mason <jon.mason@intel.com>

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: NJon Mason <jon.mason@intel.com>

Due to ambiguous documentation, the USD/DSD identification is backward
when compared to the setting in BIOS.  Correct the bits to match the
BIOS setting.
Signed-off-by: NJon Mason <jon.mason@intel.com>

The NTB Xeon hardware has 16 scratch pad registers and 16 back-to-back
scratch pad registers.  Correct the #define to represent this and update
the variable names to reflect their usage.
Signed-off-by: NJon Mason <jon.mason@intel.com>

If an error is encountered in ntb_device_setup, it is possible that the
spci_cmd isn't populated.  Writes to the offset can result in a NULL
pointer dereference.  This issue is easily encountered by running in
NTB-RP mode, as it currently is not supported and will generate an
error.  To get around this issue, return if an error is encountered
prior to attempting to write to the spci_cmd offset.
Signed-off-by: NJon Mason <jon.mason@intel.com>

64bit BAR sizes are permissible with an NTB device.  To support them
various modifications and clean-ups were required, most significantly
using 2 32bit scratch pad registers for each BAR.

Also, modify the driver to allow more than 2 Memory Windows.
Signed-off-by: NJon Mason <jon.mason@intel.com>

These tests are off by one.  If "mw" is equal to NTB_NUM_MW then we
would go beyond the end of the ndev->mw[] array.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NJon Mason <jon.mason@intel.com>

Address the sparse warnings and resulting fallout
Signed-off-by: NJon Mason <jon.mason@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Update NTB version to 0.25
Signed-off-by: NJon Mason <jon.mason@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Declare ntb_bus_type static to remove it from name space, and remove
unused ntb_get_max_spads function.  Found via `make namespacecheck`.
Signed-off-by: NJon Mason <jon.mason@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

These are now gone from the kernel, so remove them from the newly-added
drivers before they start to cause build errors for people.

Cc: Jon Mason <jon.mason@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NJon Mason <jon.mason@intel.com>
Reviewed-by: NNicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>