linux/drivers/ntb, branch v5.2

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 288

2019-06-05T15:36:37Z

Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms and conditions of the gnu general public license version 2 as published by the free software foundation this program is distributed in the hope it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 263 file(s). Signed-off-by: Thomas Gleixner Reviewed-by: Allison Randal Reviewed-by: Alexios Zavras Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190529141901.208660670@linutronix.de Signed-off-by: Greg Kroah-Hartman

treewide: Add SPDX license identifier - Makefile/Kconfig

2019-05-21T08:50:46Z

Add SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any form These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman

drivers: Remove explicit invocations of mmiowb()

2019-04-08T11:01:02Z

mmiowb() is now implied by spin_unlock() on architectures that require it, so there is no reason to call it from driver code. This patch was generated using coccinelle: @mmiowb@ @@ - mmiowb(); and invoked as: $ for d in drivers include/linux/qed sound; do \ spatch --include-headers --sp-file mmiowb.cocci --dir $d --in-place; done NOTE: mmiowb() has only ever guaranteed ordering in conjunction with spin_unlock(). However, pairing each mmiowb() removal in this patch with the corresponding call to spin_unlock() is not at all trivial, so there is a small chance that this change may regress any drivers incorrectly relying on mmiowb() to order MMIO writes between CPUs using lock-free synchronisation. If you've ended up bisecting to this commit, you can reintroduce the mmiowb() calls using wmb() instead, which should restore the old behaviour on all architectures other than some esoteric ia64 systems. Acked-by: Linus Torvalds Signed-off-by: Will Deacon

Merge tag 'ntb-5.1' of git://github.com/jonmason/ntb

2019-03-15T21:32:59Z

Pull NTB updates from Jon Mason: - fixes for switchtec debugability and mapping table entries - NTB transport improvements - a reworking of the peer_db_addr for better abstraction * tag 'ntb-5.1' of git://github.com/jonmason/ntb: NTB: add new parameter to peer_db_addr() db_bit and db_data NTB: ntb_transport: Ensure the destination buffer is mapped for TX DMA NTB: ntb_transport: Free MWs in ntb_transport_link_cleanup() ntb_hw_switchtec: Added support of >=4G memory windows ntb_hw_switchtec: NT req id mapping table register entry number should be 512 ntb_hw_switchtec: debug print 64bit aligned crosslink BAR Numbers

NTB: add new parameter to peer_db_addr() db_bit and db_data

2019-02-13T16:03:18Z

NTB door bell usage depends on NTB hardware. ex: intel NTB gen1 has one peer door bell register which can be controlled by the bitmap writen to it, while Intel NTB gen3 has a registers per door bell and the data trigering the each door bell is always 1. therefore exposing only peer door bell address forcing the user to be aware of such low level details Signed-off-by: Leonid Ravich Acked-by: Logan Gunthorpe Acked-by: Dave Jiang Acked-by: Allen Hubbe Signed-off-by: Jon Mason

NTB: ntb_transport: Ensure the destination buffer is mapped for TX DMA

2019-02-11T14:26:30Z

Presently, when ntb_transport is used with DMA and the IOMMU turned on, it fails with errors from the IOMMU such as: DMAR: DRHD: handling fault status reg 202 DMAR: [DMA Write] Request device [00:04.0] fault addr 381fc0340000 [fault reason 05] PTE Write access is not set This is because ntb_transport does not map the BAR space with the IOMMU. To fix this, we map the entire MW region for each QP after we assign the DMA channel. This prevents needing an extra DMA map in the fast path. Link: https://lore.kernel.org/linux-pci/499934e7-3734-1aee-37dd-b42a5d2a2608@intel.com/ Signed-off-by: Logan Gunthorpe Reviewed-by: Dave Jiang Signed-off-by: Jon Mason

NTB: ntb_transport: Free MWs in ntb_transport_link_cleanup()

2019-02-11T14:26:05Z

If NTB peer host crashes or reboots, the NTB transport link will be down and the MWs of NTB transport will be invalid. But the ntb_transport_link_cleanup() does not free these invalid MWs. When the NTB peer host is recovered later, NTB transport link will be up and the ntb_set_mw() will not reset up MWs. Because the MWs of NTB transport are invalid, the NTB transport will not work. We can fix it by freeing MWs when NTB transport link is down, then the ntb_set_mw() will reset up MWs when NTB transport link is up. Signed-off-by: Joey Zhang Reviewed-by: Logan Gunthorpe Signed-off-by: Jon Mason

ntb_hw_switchtec: Added support of >=4G memory windows

2019-02-11T12:36:13Z

Current Switchtec's BAR setup registers are limited to 32bits, corresponding to the maximum MW (memory window) size is <4G. Increase the MW sizes with the addition of the BAR Setup Extension Register for the upper 32bits of a 64bits MW size. This increases the MW range to between 4K and 2^63. Reported-by: Boris Glimcher Signed-off-by: Paul Selles Signed-off-by: Wesley Sheng Reviewed-by: Logan Gunthorpe Signed-off-by: Jon Mason

ntb_hw_switchtec: debug print 64bit aligned crosslink BAR Numbers

2019-02-11T12:36:13Z

Switchtec NTB crosslink BARs are 64bit addressed but they are printed as 32bit addressed BARs. Fix debug log to increment the BAR numbers by 2 to reflect the 64bit address alignment. Fixes: 017525018202 ("ntb_hw_switchtec: Add initialization code for crosslink") Signed-off-by: Paul Selles Signed-off-by: Wesley Sheng Reviewed-by: Logan Gunthorpe Signed-off-by: Jon Mason

Merge 5.0-rc4 into char-misc-next

2019-01-28T07:13:52Z

We need the char-misc fixes in here as well. Signed-off-by: Greg Kroah-Hartman