Re: [PATCH v2] NTB: ntb_tool: Add full multi-port NTB API support

On 30/11/17 02:37 PM, Serge Semin wrote: Changelog v2: - Remove driver Author/Description/License macros This patch is already very long and should be split up, and you added more to it? If you want to fix these macros it should be in it's own patch with it's own justification. -

Re: [PATCH] NTB: Set dma mask and dma coherent mask to NTB devices

On 30/11/17 02:39 PM, Serge Semin wrote: diff --git a/drivers/ntb/hw/amd/ntb_hw_amd.c b/drivers/ntb/hw/amd/ntb_hw_amd.c index f0788aae05c9..3cfa46876239 100644 --- a/drivers/ntb/hw/amd/ntb_hw_amd.c +++ b/drivers/ntb/hw/amd/ntb_hw_amd.c @@ -1020,6 +1020,10 @@ static int amd_ntb_init_pci(struct

Re: [PATCH 01/08] NTB: ntb_test: Safely use paths with whitespace

On 30/11/17 03:12 PM, Serge Semin wrote: In general the intention of the patchset was to update the ntb_test.sh script so one would be compatible with new NTB test drivers I've also sent. It was asked of me by the NTB core maintainers. Sorry for not mentioning it in the cover letter. I

Re: [PATCH] NTB: ntb_hw_idt: Set NTB_TOPO_SWITCH topology

On 30/11/17 03:14 PM, Serge Semin wrote: Signed-off-by: Serge Semin Acked-by: Serge Semin You don't need to Ack your own patches ;) It goes to the subsystem maintained by me. I tested the change, so am responsible for the results.

Re: [PATCH 02/08] NTB: ntb_test: Add ntb_tool port tests

On 30/11/17 02:42 PM, Serge Semin wrote: +function find_pidx() +{ + PORT=$1 + PPATH=$2 + + for ((i = 0; i < 64; i++)); do + PEER_DIR="$PPATH/peer$i" + + check_file ${PEER_DIR} || break + + PEER_PORT=$(read_file "${PEER_DIR}/port") +

Re: [PATCH v2] checkpatch: Add a warning for log messages that don't end in a new line

On 27/11/17 01:49 PM, Julia Lawall wrote: Perhaps if there is a possible flow from one print to another within a single function and in both cases the format string is at least say 25 characters (completely random value), then it is pretty likely that a newline is intended. This is on the

Re: [PATCH v2] checkpatch: Add a warning for log messages that don't end in a new line

On 26/11/17 11:34 PM, Julia Lawall wrote: > It would probably be better not to mention the KERN_CONT possibility at > all. Oh? I don't disagree... but what are we supposed to do in these cases? The way v2 of my patch works it just says that there is a missing new line. But Joe calls that a

Re: [PATCH v2] checkpatch: Add a warning for log messages that don't end in a new line

On 26/11/17 11:42 PM, Julia Lawall wrote: > Although I guess that in that case the whole exercise is pointless? > Because every print will at runtime be followed by another print, which > will add either the newline or a continuation. Yes, in practice the '\n' at the end of every log line is

Re: [PATCH v2] checkpatch: Add a warning for log messages that don't end in a new line

On 26/11/17 11:11 PM, Julia Lawall wrote: > I don't have a different warning if the string ends in a space. I have a > different warning when one possible control-flow path is fine and another > control-flow path is not. The space thing relates to guessing whether > some other printing API

Re: [PATCH] NTB: switchtec_ntb: fix spelling mistake: "peforming" -> "performing"

On 21/11/17 08:13 PM, Joe Perches wrote: probably nicer to add the missing newlines too. Oh, my mistake. I was never sure what was correct so I think I've been pretty lax about that. I'll clean that up. Seems like something that should be added to checkpatch. I may attempt a patch for

[PATCH] checkpatch: Add a warning for log messages that don't end in a line feed

or a close paraenthesis, that isn't preceded by a backslash than it looks like we have found the end of the format string without a \n and we WARN. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Cc: Andy Whitcroft <a...@canonical.com> Cc: Joe Perches <j...@perches.com> ---

[PATCH v2 1/2] ntb_transport: Fix bug with max_mw_size parameter

intel and ntb_transport drivers") Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Acked-by: Allen Hubbe <allen.hu...@dell.com> Cc: Jon Mason <jdma...@kudzu.us> Cc: Dave Jiang <dave.ji...@intel.com> --- drivers/ntb/ntb_transport.c | 3 +++ 1 file changed, 3 inser

[PATCH v2 2/2] ntb_hw_switchtec: Check for alignment of the buffer in mw_set_trans()

lower than the buffer size. When we get an unaligned buffer mw_set_trans() should return an error. We also log an error so we know the cause of the problem. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Cc: Jon Mason <jdma...@kudzu.us> --- v2: Use IS_ALIGNED macro as sugges

Re: [GIT PULL] NTB bug fixes for v4.15

On 20/11/17 03:37 PM, Stephen Rothwell wrote: OK, all I need is the (git) URL for a tree/branch (or tag) and a contact (or more than one) to whom I can report conflicts and build problems. I then fetch it every day (so all you have to do it add stuff to that branch when it is ready). I

Re: [GIT PULL] NTB bug fixes for v4.15

On 19/11/17 11:37 PM, Linus Torvalds wrote: > Gaah. I guess I can take the pull request. Many thanks. > I do want to protest the timing and the lack of linux-next coverage. > If it has really been ready for months, why hasn't it been in > linux-next at all? Understood. I can't speak for Jon,

Re: [GIT PULL] NTB bug fixes for v4.15

On 19/11/17 11:12 AM, Linus Torvalds wrote: > I am now traveling, and am not inclined to pull stuff that hasn't been > in linux-next unless it's just obviously bug-fixes. Sigh. This work has been held up for two cycles due to issues with the process. If it's of any consideration, my Switchtec

Re: [PATCH] NTB: switchtec_ntb: fix spelling mistake: "peforming" -> "performing"

Thanks Colin! Reviewed-By: Logan Gunthorpe <log...@deltatee.com> On 21/11/17 03:59 PM, Colin King wrote: From: Colin Ian King <colin.k...@canonical.com> Trivial fix to spelling mistake in dev_err error message Signed-off-by: Colin Ian King <colin.k...@canonical.com> --- d

Re: [GIT PULL] NTB bug fixes for v4.15

On 21/11/17 03:19 PM, Stephen Rothwell wrote: So, I really need Jon to request this inclusion (sorry). And I would prefer to not add it until after -rc1 has been released i.e. next week probably. No worries. There's no real rush on this but it should have been done many cycles ago. After

Re: [PATCH v2 01/15] NTB: Rename NTB messaging API methods

On 05/12/17 01:54 PM, Serge Semin wrote: Just because no one said anything before, doesn't mean it's acceptable. I think that is the official Linux code review mantra ;-) Okay, if we are going to do it this way, then return ~0 instead. At least that way there is no ugly cast. Ok. I'll

Re: [PATCH v2 02/15] NTB: Set dma mask and dma coherent mask to NTB devices

On 05/12/17 09:51 AM, Jon Mason wrote: On Sun, Dec 3, 2017 at 2:17 PM, Serge Semin wrote: The dma_mask and dma_coherent_mask fields of the NTB struct device weren't initialized in hardware drivers. In fact it should be done instead of PCIe interface usage, since NTB

Re: [PATCH v2 10/15] NTB: ntb_test: Update ntb_tool DB tests

On 05/12/17 11:27 AM, Jon Mason wrote: echo "Running db tests on: $(basename $LOC) / $(basename $REM)" - write_file "c $DB_BITMASK" "$REM/db" + DB_VALID_MASK=$(read_file "$LOC/db_valid_mask") - for ((i=1; i <= 8; i++)); do - let DB=$(read_file

Re: [PATCH 0/7] Switchtec NTB Crosslink Support

On 05/12/17 12:15 PM, Jon Mason wrote: On Wed, Nov 29, 2017 at 12:58 PM, Logan Gunthorpe <log...@deltatee.com> wrote: Also, I forgot to mention, this patch set is based on today's ntb-next. All of these look sane to me. Assuming they apply cleanly, adding to ntb-next. Great,

Re: [PATCH 5/7] ntb_hw_switchtec: Expand PFF CSR registers

On 05/12/17 12:12 PM, Jon Mason wrote: It sucks that we don't already have a struct for PCI config space we can reuse here. If you find the time, it would be good to add in the future to reduce duplicate code here and in the PCI core. However, this patch is fine without it. I agree. And

Re: [PATCH v2 04/15] NTB: ntb_pp: Add full multi-port NTB API support

On 05/12/17 12:53 PM, Serge Semin wrote: Is it really necessary to have all of this info defined in macro? We don't use them anywhere in the source below. I add this change here due to the last Greg patch, where he removed DRIVER_LICENSE from the code. He said, that the license check tool

Re: [PATCH v2 05/15] NTB: ntb_tool: Add full multi-port NTB API support

On 05/12/17 11:03 AM, Jon Mason wrote: +static ssize_t tool_fn_read(struct tool_ctx *tc, char __user *ubuf, + size_t size, loff_t *offp, + u64 (*fn_read)(struct ntb_dev *)) { size_t buf_size; - char *buf; - ssize_t pos,

Re: [PATCH v2 03/15] NTB: Fix UB/bug in ntb_mw_get_align()

On 05/12/17 09:52 AM, Jon Mason wrote: On Sun, Dec 3, 2017 at 2:17 PM, Serge Semin wrote: Simple (1 << pidx) operation causes undefined behaviour when pidx >= 32. It must be casted to u64 to match the actual return value of ntb_link_is_up() method, so to have all the

Re: [PATCH v2 01/15] NTB: Rename NTB messaging API methods

On 05/12/17 10:31 AM, Serge Semin wrote: -static int idt_ntb_msg_read(struct ntb_dev *ntb, int midx, int *pidx, u32 *msg) +static u32 idt_ntb_msg_read(struct ntb_dev *ntb, int *pidx, int midx) { struct idt_ntb_dev *ndev = to_ndev_ntb(ntb); if (midx < 0 || IDT_MSG_CNT <=

Re: [PATCH v2 00/15] NTB: Add full multi-port API support to the test drivers

On 05/12/17 08:54 AM, Serge Semin wrote: Yeah, I know that. As I already said, it isn't usual of my patches being so complicated. The reason why I made so many small renamings was the code refactoring. I tried to set all the test drivers code up to the same naming convention, so it would be

Re: [PATCH v2 00/15] NTB: Add full multi-port API support to the test drivers

On 03/12/17 12:17 PM, Serge Semin wrote: > The multi-port NTB API was introduced in kernel 4.13 as well as the > first driver for the true multi-port devices of IDT PCIe-switches > series. But the test drivers still were left almost unchanged. Yes, > they didn't fail being used with new NTB API,

Re: [PATCH v3 02/15] NTB: Set dma mask and dma coherent mask to NTB devices

On 05/12/17 03:39 PM, Serge Semin wrote: The dma_mask and dma_coherent_mask fields of the NTB struct device weren't initialized in hardware drivers. In fact it should be done instead of PCIe interface usage, since NTB clients are supposed to use NTB API and left unaware of real hardware

[PATCH v9 7/8] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64

Clean up the extra ifdefs which defined the wr_reg64 and rd_reg64 functions in non-64bit cases in favour of the new common io-64-nonatomic-lo-hi header. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Cc: Andy Shevchenko <andy.shevche...@gmail.com> Cc: Horia Geantă <horia.gea

[PATCH v9 0/8] Add io{read|write}64 to io-64-atomic headers

. (earlier versions were drastically different) Logan Gunthorpe (8): drm/tilcdc: ensure nonatomic iowrite64 is not used powerpc: io.h: move iomap.h include so that it can use readq/writeq defs powerpc: iomap.c: introduce io{read|write}64_{lo_hi|hi_lo} iomap: introduce io{read|write}64_{lo_hi

[PATCH v9 3/8] powerpc: iomap.c: introduce io{read|write}64_{lo_hi|hi_lo}

-by: Logan Gunthorpe <log...@deltatee.com> Tested-by: Horia Geantă <horia.gea...@nxp.com> Reviewed-by: Andy Shevchenko <andy.shevche...@gmail.com> Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org> Cc: Paul Mackerras <pau...@samba.org> Cc: Michael Ellerman <m...@

[PATCH v9 4/8] iomap: introduce io{read|write}64_{lo_hi|hi_lo}

and writeq are defined. If they are not, then the wrappers that always use non-atomic operations from include/linux/io-64-nonatomic*.h will be used. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Reviewed-by: Andy Shevchenko <andy.shevche...@gmail.com> Cc: Benjamin Herr

[PATCH v9 6/8] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks

Now that ioread64 and iowrite64 are available in io-64-nonatomic, we can remove the hack at the top of ntb_hw_intel.c and replace it with an include. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Reviewed-by: Andy Shevchenko <andy.shevche...@gmail.com> Acked-by: Dave Ji

[PATCH v9 1/8] drm/tilcdc: ensure nonatomic iowrite64 is not used

this change, this patchset would inadvertantly change the behaviour of the tilcdc driver. [1] lkml.kernel.org/r/cak8p3a2hho_zcnstzq7hmwsz5la5thu19fwzpun16imnyyn...@mail.gmail.com Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Reviewed-by: Andy Shevchenko <andy.shevche...@gmail.com> Cc

[PATCH v9 5/8] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros

are encouraged to use ioreadXX, et al instead of readX[1], et al -- and mixing ioreadXX with readq is pretty ugly. [1] LDD3: section 9.4.2 Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Reviewed-by: Andy Shevchenko <andy.shevche...@gmail.com> Cc: Christoph Hellwig <h...@lst.de>

Re: [PATCH v3 03/15] NTB: Fix UB/bug in ntb_mw_get_align()

behaviour. Additionally there are special macros in "linux/bitops.h" to perform the bit-set-shift operations, so it's recommended to have them used for proper bit setting. Signed-off-by: Serge Semin <fancer.lan...@gmail.com> Looks like you dropped my reviewed by tag for some reason. Rev

Re: [PATCH v3 00/15] NTB: Add full multi-port API support to the test drivers

Please be kind to your reviewers and list all your changes in the cover letter. Also, your sergey.se...@t-platforms.ru email which was CC'd doesn't seem to work for me so I've dropped it from my responses. Thanks, Logan On 05/12/17 03:39 PM, Serge Semin wrote: The multi-port NTB API was

Re: [PATCH v3 01/15] NTB: Rename NTB messaging API methods

On 05/12/17 03:39 PM, Serge Semin wrote: There is a common methods signature form used over all the NTB API like functions naming scheme, arguments names and order, etc. Recently added NTB messaging API IO callbacks were named a bit different so should be renamed to be in compliance with the

[PATCH v9 8/8] ntb: ntb_hw_switchtec: Cleanup 64bit IO defines to use the common header

Clean up the ifdefs which conditionally defined the io{read|write}64 functions in favour of the new common io-64-nonatomic-lo-hi header. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Cc: Jon Mason <jdma...@kudzu.us> --- drivers/ntb/hw/mscc/ntb_hw_swit

[PATCH v9 2/8] powerpc: io.h: move iomap.h include so that it can use readq/writeq defs

Subsequent patches in this series makes use of the readq and writeq defines in iomap.h. However, as is, they get missed on the powerpc platform seeing the include comes before the define. This patch moves the include down to fix this. Signed-off-by: Logan Gunthorpe <log...@deltatee.com>

[PATCH 2/2] ntb_hw_switchtec: Check for alignment of the buffer in mw_set_trans()

lower than the buffer size. When we get an unaligned buffer mw_set_trans() should return an error. We also log an error so we know the cause of the problem. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Cc: Jon Mason <jdma...@kudzu.us> --- drivers/ntb/hw/mscc/ntb_hw_swit

Re: [PATCH] ntb_transport: fix qp count bug

Sorry, ignore this. I sent an old patch. Logan On 08/12/17 05:01 PM, Logan Gunthorpe wrote: In cases where there are more mw's than spads/2-2, the mw count gets reduced to match the limitation. ntb_transport also tries to ensure that there are fewer qps than mws but uses the full mw count

[PATCH 1/2] ntb_transport: Fix bug with max_mw_size parameter

intel and ntb_transport drivers") Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Cc: Jon Mason <jdma...@kudzu.us> Cc: Dave Jiang <dave.ji...@intel.com> Cc: Allen Hubbe <allen.hu...@emc.com> --- drivers/ntb/ntb_transport.c | 3 +++ 1 file changed, 3 inser

Re: [PATCH] ntb_netdev: set the net_device's parent

Sorry ignore this. I sent an old patch :( Logan On 08/12/17 05:01 PM, Logan Gunthorpe wrote: At present, ntb_netdev devices end up under /sys/devices/virtual/net completely unconnected to the ntb trees below them. This patch sets the parent of the net_device (using SET_NETDEV_DEV

[PATCH] ntb_transport: fix qp count bug

confused and result in a kernel paging request bug. This patch fixes the bug by reducing qp_count to the reduced mw count instead of the full mw count. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Cc: Jon Mason <jdma...@kudzu.us> Cc: Dave Jiang <dave.ji...@intel.com> Cc: All

[PATCH] ntb_netdev: set the net_device's parent

/pci:00/:00:03.0/:03:00.1/:03:00.1/ntb_netdev0/net/eth2 Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Cc: Jon Mason <jdma...@kudzu.us> Cc: Dave Jiang <dave.ji...@intel.com> Cc: Allen Hubbe <allen.hu...@emc.com> --- drivers/net/ntb_netdev.c |

Re: [PATCH 2/2] ntb_hw_switchtec: Check for alignment of the buffer in mw_set_trans()

On 11/12/17 07:58 AM, Allen Hubbe wrote: !IS_ALIGNED(addr, BIT_ULL(xlate_pos)) Ok, yes, that's much better. I'll change it. Thanks. + /* +* In certain circumstances we can get a buffer that is +* not aligned to its size. (Most of the time +

Re: [PATCH 2/2] ntb_hw_switchtec: Check for alignment of the buffer in mw_set_trans()

On 11/12/17 12:17 PM, Allen Hubbe wrote: From: Logan Gunthorpe mw_get_align doesn't communicate the fact that the buffer has to be aligned by its size. Is that not the purpose of the addr_align out parameter of ntb_mw_get_align()? addr_align provides the minimum alignment required

Re: [PATCH 2/2] ntb_hw_switchtec: Check for alignment of the buffer in mw_set_trans()

On 11/12/17 01:06 PM, Allen Hubbe wrote: In switchtec_ntb_mw_get_align, for the lut case it seems to require alignment the same as Intel, aligned to mw size, but for the non-lut case you are saying that SZ_4K is not necessarily correct. The SZ_4K is the minimum, but the actual alignment

Re: [PATCH] ntb_hw_switchtec: fix logic error

ntext. Fixes: 1b249475275d ("ntb_hw_switchtec: Allow using Switchtec NTB in multi-partition setups") Signed-off-by: Arnd Bergmann <a...@arndb.de> Reviewed-by: Logan Gunthorpe <log...@deltatee.com> Logan

Re: [PATCH] genalloc: Make the avail variable an atomic64_t

o pull in atomic64 operations on platforms that do not support them natively. Signed-off-by: Stephen Bates <sba...@raithlin.com> Reviewed-by: Logan Gunthorpe <log...@deltatee.com> This looks pretty straightforward to me. Logan

Re: [PATCH] genalloc: Make the avail variable an atomic64_t

On 25/10/17 11:55 AM, Daniel Mentz wrote: avail is defined as size_t (32 bit). Aren't you going to overflow that variable? I think the point is to get support for 64-bit systems (ie. ARM64 and x64. We're working with large PCI BARs and need some way to allocate memory from them. You aren't

Re: [PATCH v4 00/14] Copy Offload in NVMe Fabrics with P2P PCI Memory

On 04/05/18 08:27 AM, Christian König wrote: > Are you sure that this is more convenient? At least on first glance it > feels overly complicated. > > I mean what's the difference between the two approaches? > >     sum = pci_p2pdma_distance(target, [A, B, C, target]); > > and > >     sum

Re: [PATCH v4 04/14] PCI/P2PDMA: Clear ACS P2P flags for all devices behind switches

On 08/05/18 04:03 PM, Alex Williamson wrote: > If IOMMU grouping implies device assignment (because nobody else uses > it to the same extent as device assignment) then the build-time option > falls to pieces, we need a single kernel that can do both. I think we > need to get more clever about

Re: [PATCH v4 04/14] PCI/P2PDMA: Clear ACS P2P flags for all devices behind switches

On 08/05/18 05:00 PM, Dan Williams wrote: >> I'd advise caution with a user supplied BDF approach, we have no >> guaranteed persistence for a device's PCI address. Adding a device >> might renumber the buses, replacing a device with one that consumes >> more/less bus numbers can renumber the

Re: [PATCH v4 04/14] PCI/P2PDMA: Clear ACS P2P flags for all devices behind switches

On 08/05/18 02:43 PM, Alex Williamson wrote: > Yes, GPUs seem to be leading the pack in implementing ATS. So now the > dumb question, why not simply turn off the IOMMU and thus ACS? The > argument of using the IOMMU for security is rather diminished if we're > specifically enabling devices to

Re: [PATCH v4 00/14] Copy Offload in NVMe Fabrics with P2P PCI Memory

On 08/05/18 10:57 AM, Alex Williamson wrote: > AIUI from previously questioning this, the change is hidden behind a > build-time config option and only custom kernels or distros optimized > for this sort of support would enable that build option. I'm more than > a little dubious though that

Re: [PATCH v4 04/14] PCI/P2PDMA: Clear ACS P2P flags for all devices behind switches

On 08/05/18 10:50 AM, Christian König wrote: > E.g. transactions are initially send to the root complex for > translation, that's for sure. But at least for AMD GPUs the root complex > answers with the translated address which is then cached in the device. > > So further transactions for the

Re: [PATCH v4 04/14] PCI/P2PDMA: Clear ACS P2P flags for all devices behind switches

On 08/05/18 05:11 PM, Alex Williamson wrote: > On to the implementation details... I already mentioned the BDF issue > in my other reply. If we had a way to persistently identify a device, > would we specify the downstream points at which we want to disable ACS > or the endpoints that we want

Re: [PATCH v4 04/14] PCI/P2PDMA: Clear ACS P2P flags for all devices behind switches

On 08/05/18 02:13 PM, Alex Williamson wrote: > Well, I'm a bit confused, this patch series is specifically disabling > ACS on switches, but per the spec downstream switch ports implementing > ACS MUST implement direct translated P2P. So it seems the only > potential gap here is the endpoint,

Re: [PATCH v4 04/14] PCI/P2PDMA: Clear ACS P2P flags for all devices behind switches

On 08/05/18 01:34 PM, Alex Williamson wrote: > They are not so unrelated, see the ACS Direct Translated P2P > capability, which in fact must be implemented by switch downstream > ports implementing ACS and works specifically with ATS. This appears to > be the way the PCI SIG would intend for

[PATCH v17 2/7] parisc: iomap: introduce io{read|write}64

Add support for io{read|write}64() functions in parisc architecture. These are pretty straightforward copies of similar functions which make use of readq and writeq. Also, indicate that the lo_hi and hi_lo variants of these functions are not provided by this architecture. Signed-off-by: Logan

[PATCH v17 3/7] iomap: introduce io{read|write}64_{lo_hi|hi_lo}

and writeq are defined. If they are not, then the wrappers that always use non-atomic operations from include/linux/io-64-nonatomic*.h will be used. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Reviewed-by: Andy Shevchenko <andy.shevche...@gmail.com> Cc: Benjamin Herr

[PATCH v17 7/7] ntb: ntb_hw_switchtec: Cleanup 64bit IO defines to use the common header

Clean up the ifdefs which conditionally defined the io{read|write}64 functions in favour of the new common io-64-nonatomic-lo-hi header. Per a nit from Andy Shevchenko, the include list is also made alphabetical. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Reviewed-by: Andy Shev

[PATCH v17 6/7] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64

/ written to first, followed by the upper address. Indeed the I/O accessors in CAAM driver currently don't follow the spec, however this is a good opportunity to fix the code. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Reviewed-by: Horia Geantă <horia.gea...@nxp.com> Revie

Re: [PATCH v4 00/14] Copy Offload in NVMe Fabrics with P2P PCI Memory

> How do you envison merging this? There's a big chunk in drivers/pci, but > really no opportunity for conflicts there, and there's significant stuff in > block and nvme that I don't really want to merge. > > If Alex is OK with the ACS situation, I can ack the PCI parts and you could > merge it

[PATCH v17 0/7] Add io{read|write}64 to io-64-atomic headers

* headers - Fixed a typo noticed by Horia. (earlier versions were drastically different) Logan Gunthorpe (7): iomap: Use non-raw io functions for io{read|write}XXbe parisc: iomap: introduce io{read|write}64 iomap: introduce io{read|write}64_{lo_hi|hi_lo} io-64-nonatomic: add io{read|write

[PATCH v17 4/7] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros

are encouraged to use ioreadXX, et al instead of readX[1], et al -- and mixing ioreadXX with readq is pretty ugly. [1] LDD3: section 9.4.2 Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Reviewed-by: Andy Shevchenko <andy.shevche...@gmail.com> Cc: Christoph Hellwig <h...@lst.de>

[PATCH v17 5/7] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks

Now that ioread64 and iowrite64 are available in io-64-nonatomic, we can remove the hack at the top of ntb_hw_intel.c and replace it with an include. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Reviewed-by: Andy Shevchenko <andy.shevche...@gmail.com> Acked-by: Dave Ji

[PATCH v17 1/7] iomap: Use non-raw io functions for io{read|write}XXbe

code did not annotate correctly. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Kate Stewart <kstew...@linuxfoundation.org> Cc: Philippe Ombredanne <pombreda...@nexb.com> Cc: Greg Kroah-Hartman <gre...@linuxfounda

Re: [PATCH v4 01/14] PCI/P2PDMA: Support peer-to-peer memory

Thanks for the review. I'll apply all of these for the changes for next version of the set. >> +/* >> + * If a device is behind a switch, we try to find the upstream bridge >> + * port of the switch. This requires two calls to pci_upstream_bridge(): >> + * one for the upstream port on the switch,

Re: [PATCH v4 04/14] PCI/P2PDMA: Clear ACS P2P flags for all devices behind switches

On 09/05/18 07:40 AM, Christian König wrote: > The key takeaway is that when any device has ATS enabled you can't > disable ACS without breaking it (even if you unplug and replug it). I don't follow how you came to this conclusion... The ACS bits we'd be turning off are the ones that force

Re: [PATCH v4 04/14] PCI/P2PDMA: Clear ACS P2P flags for all devices behind switches

On 10/05/18 08:16 AM, Stephen Bates wrote: > Hi Christian > >> Why would a switch not identify that as a peer address? We use the PASID >>together with ATS to identify the address space which a transaction >>should use. > > I think you are conflating two types of TLPs here. If the

Re: [PATCH v4 04/14] PCI/P2PDMA: Clear ACS P2P flags for all devices behind switches

On 10/05/18 11:11 AM, Stephen Bates wrote: >> Not to me. In the p2pdma code we specifically program DMA engines with >> the PCI bus address. > > Ah yes of course. Brain fart on my part. We are not programming the P2PDMA > initiator with an IOVA but with the PCI bus address... > >> So

Re: [PATCH v4 04/14] PCI/P2PDMA: Clear ACS P2P flags for all devices behind switches

On 10/05/18 12:41 PM, Stephen Bates wrote: > Hi Jerome > >>Note on GPU we do would not rely on ATS for peer to peer. Some part >>of the GPU (DMA engines) do not necessarily support ATS. Yet those >>are the part likely to be use in peer to peer. > > OK this is good to know. I agree

Re: [PATCH v4 04/14] PCI/P2PDMA: Clear ACS P2P flags for all devices behind switches

On 5/11/2018 2:52 AM, Christian König wrote: This only works when the IOVA and the PCI bus addresses never overlap. I'm not sure how the IOVA allocation works but I don't think we guarantee that on Linux. I find this hard to believe. There's always the possibility that some part of the

Re: [PATCH v4 04/14] PCI/P2PDMA: Clear ACS P2P flags for all devices behind switches

On 5/11/2018 4:24 PM, Stephen Bates wrote: All  Alex (or anyone else) can you point to where IOVA addresses are generated? A case of RTFM perhaps (though a pointer to the code would still be appreciated). https://www.kernel.org/doc/Documentation/Intel-IOMMU.txt Some exceptions to IOVA

Re: [PATCH v4 04/14] PCI/P2PDMA: Clear ACS P2P flags for all devices behind switches

On 08/05/18 01:17 AM, Christian König wrote: > AMD APUs mandatory need the ACS flag set for the GPU integrated in the > CPU when IOMMU is enabled or otherwise you will break SVM. Well, given that the current set only disables ACS bits on bridges (previous versions were only on switches) this

Re: [PATCH 2/2] NTB: PCI Quirk to Enable Switchtec NT Functionality with IOMMU On

On 17/05/18 07:45 AM, Bjorn Helgaas wrote: > On Thu, May 17, 2018 at 05:00:13AM -0700, dme...@gigaio.com wrote: >> From: Doug Meyer >> >> Here we add the PCI quirk for the Microsemi Switchtec parts to allow >> non-transparent bridging to work when the IOMMU is turned on. > >

Re: [PATCH 2/2] NTB: PCI Quirk to Enable Switchtec NT Functionality with IOMMU On

Thanks for your hard work on this Doug! On 17/05/18 06:00 AM, dme...@gigaio.com wrote: > + if (pci_enable_device(pdev)) { > + dev_err(>dev, "Cannot enable Switchtec device\n"); > + return; > + } I suspect we should probably cass pci_disable_device() before

Re: [PATCH 2/5] mm, devm_memremap_pages: handle errors allocating final devres action

Hey Dan, On 21/05/18 06:07 PM, Dan Williams wrote: > Without this change we could fail to register the teardown of > devm_memremap_pages(). The likelihood of hitting this failure is tiny > as small memory allocations almost always succeed. However, the impact > of the failure is large given any

Re: [PATCH] ntb_transport: use put_device() instead of kfree()

On 21/05/18 06:48 PM, Jon Mason wrote: > On Fri, Mar 09, 2018 at 04:03:24PM +0530, Arvind Yadav wrote: >> Never directly free @dev after calling device_register(), even >> if it returned an error! Always use put_device() to give up the >> reference initialized. >> >> Signed-off-by: Arvind Yadav

Re: [PATCH 2/5] mm, devm_memremap_pages: handle errors allocating final devres action

On 22/05/18 10:56 AM, Dan Williams wrote: > On Tue, May 22, 2018 at 9:42 AM, Logan Gunthorpe <log...@deltatee.com> wrote: >> Hey Dan, >> >> On 21/05/18 06:07 PM, Dan Williams wrote: >>> Without this change we could fail to register the teardown of >&

Re: [PATCH v2 2/2] NTB: PCI Quirk to Enable Switchtec NT Functionality with IOMMU On

On 23/05/18 02:18 PM, dme...@gigaio.com wrote: > Signed-off-by: Doug Meyer <dme...@gigaio.com> Modulo the device ID issue: Reviewed-by: Logan Gunthorpe <log...@deltatee.com> Thanks for your work on this Doug! Logan

[PATCH] PCI: Expand documentation for pci_add_dma_alias()

Seeing there's been some confusion about the use of pci_add_dma_alias(), expand the comment to describe why it must be called early and how early it must be called. Also, expand on the purpose of this function and common reasons it would be used. Signed-off-by: Logan Gunthorpe <

Re: [PATCH v2 1/2] NTB: Migrate PCI Constants to Cannonical PCI Header

wed-by: Logan Gunthorpe <log...@deltatee.com>

Re: [PATCH 2/2] NTB: PCI Quirk to Enable Switchtec NT Functionality with IOMMU On

On 23/05/18 07:33 AM, Bjorn Helgaas wrote: > This (and Alex's) analysis is very useful and I'd like to capture it > somehow, perhaps by expanding the poor pci_add_dma_alias() function > comment I added with f0af9593372a ("PCI: Add pci_add_dma_alias() to > abstract implementation"). > > The

Re: [PATCH 2/2] NTB: PCI Quirk to Enable Switchtec NT Functionality with IOMMU On

On 22/05/18 03:51 PM, Bjorn Helgaas wrote: > I don't think the question of when the aliases need to be added is > quite closed. Logan said "it seems pci_add_dma_alias() must be called > before the driver is initialized and therefore in a quirk", but that > doesn't make clear *why* the alias

Re: [PATCH v4 06/14] PCI/P2PDMA: Add P2P DMA driver writer's documentation

Thanks for the review Randy! I'll make the changes for the next time we post the series. On 22/05/18 03:24 PM, Randy Dunlap wrote: >> +The first task an orchestrator driver must do is compile a list of >> +all client drivers that will be involved in a given transaction. For >> +example, the NVMe

[PATCH v2] PCI: Expand documentation for pci_add_dma_alias()

Williamson] Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Cc: Bjorn Helgaas <bhelg...@google.com> Cc: Alex Williamson <alex.william...@redhat.com> Cc: Doug Meyer <dme...@gigaio.com> --- v2: Reworked the patch with Alex's suggested wording. drivers/pci/pci.c | 15

Re: [PATCH v2] PCI: Expand documentation for pci_add_dma_alias()

On 24/05/18 11:44 AM, Randy Dunlap wrote: >> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c >> index dbfe7c4f3776..1c0c1ea23b90 100644 >> --- a/drivers/pci/pci.c >> +++ b/drivers/pci/pci.c >> @@ -5395,8 +5395,19 @@ int pci_set_vga_state(struct pci_dev *dev, bool >> decode, >> * @dev: the

[PATCH 3/3] PCI: Introduce the disable_acs_redir parameter

-off-by: Logan Gunthorpe <log...@deltatee.com> Reviewed-by: Stephen Bates <sba...@raithlin.com> --- Documentation/admin-guide/kernel-parameters.txt | 9 +++ drivers/pci/pci.c | 103 +++- 2 files changed, 110 insertions(+), 2 deleti

[PATCH 2/3] PCI: Allow specifying devices using a base bus and path of devfns

Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Reviewed-by: Stephen Bates <sba...@raithlin.com> --- Documentation/admin-guide/kernel-parameters.txt | 12 ++- drivers/pci/pci.c | 106 +++- 2 files changed, 112 insertions(+), 6 de

[PATCH 1/3] PCI: Make specifying PCI devices in kernel parameters reusable

and extra parentheses). Additionally, make the analogous change to the kernel parameter documentation: Separating the description of how to specify a PCI device into it's own section at the head of the pci= parameter. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Reviewed-by: Stephen Bate

[PATCH 0/3] Add parameter for disabling ACS redirection for P2P

P2P Request Redirect, ACS P2P Completion Redirect and ACS P2P Egress Control bits for the selected devices. This allows P2P traffic between selected bridges and seeing it's done at boot, before IOMMU group creating the IOMMU groups will be created correctly based on the bits. Thanks, Logan Logan

Re: [PATCH v2 4/7] mm, devm_memremap_pages: Add MEMORY_DEVICE_PRIVATE support

e Glisse" <jgli...@redhat.com> > Reported-by: Logan Gunthorpe <log...@deltatee.com> > Signed-off-by: Dan Williams <dan.j.willi...@intel.com> Reviewed-by: Logan Gunthorpe <log...@deltatee.com>

Re: [PATCH v2 3/7] mm, devm_memremap_pages: Fix shutdown handling

On 22/05/18 11:10 PM, Dan Williams wrote: > diff --git a/include/linux/memremap.h b/include/linux/memremap.h > index 7b4899c06f49..b5e894133cf6 100644 > --- a/include/linux/memremap.h > +++ b/include/linux/memremap.h > @@ -106,6 +106,7 @@ typedef void (*dev_page_free_t)(struct page *page, void

Re: [PATCH 4/5] mm, hmm: replace hmm_devmem_pages_create() with devm_memremap_pages()

On 21/05/18 04:35 PM, Dan Williams wrote: > + /* > + * For device private memory we call add_pages() as we only need to > + * allocate and initialize struct page for the device memory. More- > + * over the device memory is un-accessible thus we do not want to > + * create

<    2   3   4   5   6   7   8   9   10   11   >