[PATCH v2] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

] renaming it and pushing this patch ASAP. To maintain consistency I've renamed all four of kmap* and kunmap* to be map* and unmap*. (Even though only kmap_atomic presently conflicts.) [1] https://www.spinics.net/lists/target-devel/msg15070.html Signed-off-by: Logan Gunthorpe <log...@deltatee.

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 19/04/17 01:31 PM, Jason Gunthorpe wrote: > Try it with VT-D turned on. It shouldn't work or there is a notable > security hole in your platform.. Ah, ok. >>> const struct dma_map_ops *comp_ops = get_dma_ops(completer); >>> const struct dma_map_ops *init_ops =

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 19/04/17 12:32 PM, Jason Gunthorpe wrote: > On Wed, Apr 19, 2017 at 12:01:39PM -0600, Logan Gunthorpe wrote: > Not entirely, it would have to call through the whole process > including the arch_p2p_cross_segment().. Hmm, yes. Though it's still not clear what, if

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

Thanks, Benjamin, for the summary of some of the issues. On 14/04/17 04:07 PM, Benjamin Herrenschmidt wrote > So I assume the p2p code provides a way to address that too via special > dma_ops ? Or wrappers ? Not at this time. We will probably need a way to ensure the iommus do not attempt to

Re: [PATCH 03/22] libiscsi: Make use of new the sg_map helper function

On 14/04/17 02:36 AM, Christoph Hellwig wrote: > On Thu, Apr 13, 2017 at 04:05:16PM -0600, Logan Gunthorpe wrote: >> Convert the kmap and kmap_atomic uses to the sg_map function. We now >> store the flags for the kmap instead of a boolean to indicate >> atomicitiy. We also

Re: [PATCH 04/22] target: Make use of the new sg_map function at 16 call sites (fwd)

gt; > Hi Logan, > > [auto build test WARNING on scsi/for-next] > [also build test WARNING on v4.11-rc6] > [cannot apply to next-20170413] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: > https

Re: [PATCH 10/22] staging: unisys: visorbus: Make use of the new sg_map helper function

Great, thanks! Logan On 14/04/17 10:07 AM, Kershner, David A wrote: > Can you add Acked-by for this patch? > > Acked-by: David Kershner > > Tested on s-Par and no problems. > > Thanks, > David Kershner > >> --- >> drivers/staging/unisys/visorhba/visorhba_main.c

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 15/04/17 09:01 PM, Benjamin Herrenschmidt wrote: > Are ZONE_DEVICE pages identifiable based on the struct page alone ? (a > flag ?) Well you can't use ZONE_DEVICE as an indicator. They may be regular RAM, (eg. pmem). It would need a separate flag indicating it is backed by iomem. Logan

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 15/04/17 04:17 PM, Benjamin Herrenschmidt wrote: > You can't. If the iommu is on, everything is remapped. Or do you mean > to have dma_map_* not do a remapping ? Well, yes, you'd have to change the code so that iomem pages do not get remapped and the raw BAR address is passed to the DMA

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 16/04/17 09:53 AM, Dan Williams wrote: > ZONE_DEVICE allows you to redirect via get_dev_pagemap() to retrieve > context about the physical address in question. I'm thinking you can > hang bus address translation data off of that structure. This seems > vaguely similar to what HMM is doing.

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 16/04/17 09:44 AM, Dan Williams wrote: > I think we very much want the dma mapping layer to be in the way. > It's the only sane semantic we have to communicate this translation. Yes, I wasn't proposing bypassing that layer, per say. I just meant that the layer would, in the end, have to

Re: [PATCH 01/22] scatterlist: Introduce sg_map helper functions

On 14/04/17 02:35 AM, Christoph Hellwig wrote: >> + >> static inline int is_dma_buf_file(struct file *); >> >> struct dma_buf_list { > > I think the right fix here is to rename the operation to unmap_atomic > and send out a little patch for that ASAP. Ok, I can do that next week. > I'd

Re: [PATCH 09/22] dm-crypt: Make use of the new sg_map helper in 4 call sites

On 14/04/17 02:39 AM, Christoph Hellwig wrote: > On Thu, Apr 13, 2017 at 04:05:22PM -0600, Logan Gunthorpe wrote: >> Very straightforward conversion to the new function in all four spots. > > I think the right fix here is to switch dm-crypt to the ahash API > that takes a

Re: [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function

imited as it was, I had mailing lists yelling at me). My plan was to get buy in for the first patch, get it merged and resend the rest independently to their respective maintainers. Of course, though, I'd be open to other suggestions. >>> >>> Signed-off-by: Logan Guntho

Re: [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function

On 18/04/17 09:50 AM, Konrad Rzeszutek Wilk wrote: > I am not sure if you know, but you can add on each patch the respective > maintainer via 'CC'. That way you can have certain maintainers CCed only > on the subsystems they cover. You put it after (or before) your SoB and > git send-email

Re: [PATCH 05/22] drm/i915: Make use of the new sg_map helper function

On 18/04/17 12:44 AM, Daniel Vetter wrote: > On Thu, Apr 13, 2017 at 04:05:18PM -0600, Logan Gunthorpe wrote: >> This is a single straightforward conversion from kmap to sg_map. >> >> Signed-off-by: Logan Gunthorpe <log...@deltatee.com> > > Acked-by: Dani

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 17/04/17 01:20 AM, Benjamin Herrenschmidt wrote: > But is it ? For example take a GPU, does it, in your scheme, need an > additional "p2pmem" child ? Why can't the GPU driver just use some > helper to instantiate the necessary struct pages ? What does having an > actual "struct device" child

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 18/04/17 10:45 AM, Jason Gunthorpe wrote: > From Ben's comments, I would think that the 'first class' support that > is needed here is simply a function to return the 'struct device' > backing a CPU address range. Yes, and Dan's get_dev_pagemap suggestion gets us 90% of the way there. It's

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 19/04/17 09:55 AM, Jason Gunthorpe wrote: > I was thinking only this one would be supported with a core code > helper.. Pivoting slightly: I was looking at how HMM uses ZONE_DEVICE. They add a type flag to the dev_pagemap structure which would be very useful to us. We could add another

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 19/04/17 11:14 AM, Jason Gunthorpe wrote: > I don't see a use for the dma_map function pointer at this point.. Yes, it is kind of like designing for the future. I just find it a little odd calling the pci functions in the iommu. > It doesn't make alot of sense for the completor of the DMA

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 19/04/17 02:48 PM, Jason Gunthorpe wrote: > On Wed, Apr 19, 2017 at 01:41:49PM -0600, Logan Gunthorpe wrote: > >>> But.. it could point to a GPU and the GPU struct device could have a >>> proxy dma_ops like Dan pointed out. >> >> Seems a bit awkward to m

[PATCH] libiscsi: Add an internal error code

This is a prep patch to add a new error code to libiscsi. We want to rework some kmap calls to be able to fail. When we do, we'd like to use this error code. This patch simply introduces ISCSI_TCP_INTERNAL_ERR and prints "Internal Error." when it gets hit. Signed-off-by: Logan Gunt

Re: [PATCH v7 0/4] New Microsemi PCI Switch Management Driver

On 09/03/17 12:55 PM, Bjorn Helgaas wrote: > Applied to pci/switchtec for v4.12, thanks! Great! Thanks so much! Logan

Re: Question Regarding ERMS memcpy

On 06/03/17 12:28 AM, H. Peter Anvin wrote: > On 03/05/17 23:01, Logan Gunthorpe wrote: >> >> On 05/03/17 12:54 PM, Borislav Petkov wrote: >>> Logan, wanna give that a try, see if it takes care of your issue? >> >> Well honestly my issue was solved by fixing

Re: Question Regarding ERMS memcpy

Hey, On 04/03/17 05:33 PM, Borislav Petkov wrote: > On Sat, Mar 04, 2017 at 04:23:17PM -0800, h...@zytor.com wrote: >> What are the compilation flags? It may be that gcc still does TRT >> depending on this call site. I'd check what gcc6 or 7 generates, >> though. > Hmm, I wish we were able to

Question Regarding ERMS memcpy

Hi, I'm trying to chase down a performance issue with a driver I'm working on that does a repeated memcpy_fromio of about 1KB from a PCI device. I made a small change from a fixed size copy to a variable size only to be surprised with a performance decrease of about 1/3. I've looked through the

Re: Question Regarding ERMS memcpy

On Sun, Mar 05, 2017 at 11:19:42AM -0800, Linus Torvalds wrote: >> But it is *not* the right thing to use on IO memory, because the CPU >> only does the magic cacheline access optimizations on cacheable >> memory! Yes, and actually this is where I started. I thought my memcpy was using byte

Re: [PATCH v6 0/4] New Microsemi PCI Switch Management Driver

Hey, Ah, sorry, sorry. I noticed another minor mistake. I'll send a v7 in a second. Thanks, Logan On 02/03/17 04:07 PM, Logan Gunthorpe wrote: > Hi, > > Hopefully this is the last change necessary. The new code to handle > unbind follows Jason's suggestions and is a lot easier to

[PATCH v6 0/4] New Microsemi PCI Switch Management Driver

review process. The patch is based off of the v4.10-rc6 release. Thanks for your review, Logan [1] https://www.spinics.net/lists/linux-pci/msg56897.html [2] https://github.com/sbates130272/switchtec-user Logan Gunthorpe (4): MicroSemi Switchtec management interface driver switchtec: Add user

[PATCH v7 4/4] switchtec: Add IOCTLs to the Switchtec driver

This patch introduces a couple of special IOCTLs which are provided to: * Inform userspace of firmware partition locations * Pass event counts and allow userspace to wait on events * Translate between PFF numbers used by the switch to port numbers. Signed-off-by: Logan Gunthorpe <

[PATCH v7 3/4] switchtec: Add sysfs attributes to the Switchtec driver

This patch adds a few read-only sysfs attributes which provide some device information that is exposed from the devices. Primarily component and device names and versions. These are documented in Documentation/ABI/testing/sysfs-class-switchtec. Signed-off-by: Logan Gunthorpe <log...@deltatee.

[PATCH v6 4/4] switchtec: Add IOCTLs to the Switchtec driver

This patch introduces a couple of special IOCTLs which are provided to: * Inform userspace of firmware partition locations * Pass event counts and allow userspace to wait on events * Translate between PFF numbers used by the switch to port numbers. Signed-off-by: Logan Gunthorpe <

[PATCH v6 3/4] switchtec: Add sysfs attributes to the Switchtec driver

This patch adds a few read-only sysfs attributes which provide some device information that is exposed from the devices. Primarily component and device names and versions. These are documented in Documentation/ABI/testing/sysfs-class-switchtec. Signed-off-by: Logan Gunthorpe <log...@deltatee.

[PATCH v7 1/4] MicroSemi Switchtec management interface driver

atures may be added in the future. [1] https://github.com/sbates130272/switchtec-user [2] https://github.com/linux-nvme/nvme-cli Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Signed-off-by: Stephen Bates <stephen.ba...@microsemi.com> Tested-by: Krishna Dhulipala <krish...@fb.co

[PATCH v6 1/4] MicroSemi Switchtec management interface driver

atures may be added in the future. [1] https://github.com/sbates130272/switchtec-user [2] https://github.com/linux-nvme/nvme-cli Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Signed-off-by: Stephen Bates <stephen.ba...@microsemi.com> Tested-by: Krishna Dhulipala <krish...@fb.co

[PATCH v7 0/4] New Microsemi PCI Switch Management Driver

://www.spinics.net/lists/linux-pci/msg56897.html [2] https://github.com/sbates130272/switchtec-user Logan Gunthorpe (4): MicroSemi Switchtec management interface driver switchtec: Add user interface documentation switchtec: Add sysfs attributes to the Switchtec driver switchtec: Add IOCTLs

[PATCH v7 2/4] switchtec: Add user interface documentation

This adds standard documentation for the sysfs switchtec attributes and a RST formatted text file which documents the char device interface. Jonathan Corbet has indicated he will move this to a new user-space developer documentation book once it's created. Signed-off-by: Logan Gunthorpe <

[PATCH v6 2/4] switchtec: Add user interface documentation

This adds standard documentation for the sysfs switchtec attributes and a RST formatted text file which documents the char device interface. Jonathan Corbet has indicated he will move this to a new user-space developer documentation book once it's created. Signed-off-by: Logan Gunthorpe <

Re: [RFC 5/8] scatterlist: Modify SG copy functions to support io memory.

On 03/04/17 03:44 PM, Dan Williams wrote: > On Mon, Apr 3, 2017 at 2:20 PM, Logan Gunthorpe <log...@deltatee.com> wrote: >> Hi Christoph, >> >> What are your thoughts on an approach like the following untested >> draft patch. >> >> The patch (

Re: [RFC 1/8] Introduce Peer-to-Peer memory (p2pmem) device

On 02/04/17 03:03 PM, Sinan Kaya wrote: > Push the decision all the way to the user. Let them decide whether they > want this feature to work on a root port connected port or under the > switch. Yes, I prefer this too. If other folks agree with that I'd be very happy to go back to user chooses.

Re: [RFC 5/8] scatterlist: Modify SG copy functions to support io memory.

On 03/04/17 04:47 PM, Dan Williams wrote: > I wouldn't necessarily conflate supporting pfn_t in the scatterlist > with the stalled stuct-page-less DMA effor. A pfn_t_to_page() > conversion will still work and be required. However you're right, the > minute we use pfn_t for this we're into the

Re: [RFC 5/8] scatterlist: Modify SG copy functions to support io memory.

On 31/03/17 01:09 AM, Christoph Hellwig wrote: > You're calling memcpy_{to,from}_iomem on non-__iomem pointers. This > is a fundamental no-go as we keep I/O memory separate from kernel > pointers. Yes, that's true, however I don't know how we could get around that when the iomem is referenced

Re: [RFC 5/8] scatterlist: Modify SG copy functions to support io memory.

Hi Dan, On 03/04/17 06:07 PM, Dan Williams wrote: > The completely agnostic part is where I get worried, but I shouldn't > say anymore until I actually read the patch.The worry is cases where > this agnostic enabling allows unsuspecting code paths to do the wrong > thing. Like bypass iomem

Re: linux-next: manual merge of the scsi-mkp tree with the char-misc tree

Hi Bart, On 07/04/17 09:49 AM, Bart Van Assche wrote: > Sorry that I had not yet noticed Logan's patch series. Should my two > patches that conflict with Logan's patch series be dropped and reworked > after Logan's patches are upstream? Yeah, Greg took my patchset around a few maintainers

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 17/04/17 11:04 AM, Dan Williams wrote: >> Yes, in this scheme, it needs an additional p2pmem child. Why is that an >> issue? It certainly makes it a lot easier for the user to understand the >> p2pmem memory in the system (through the sysfs tree) and reason about >> the topology and when to

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 17/04/17 03:11 PM, Benjamin Herrenschmidt wrote: > Is it ? Again, you create a "concept" the user may have no idea about, > "p2pmem memory". So now any kind of memory buffer on a device can could > be use for p2p but also potentially a bunch of other things becomes > special and called

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 17/04/17 12:04 PM, Jerome Glisse wrote: > I disagree here. I would rather see Peer-to-Peer mapping as a form > of helper so that device driver can opt-in for multiple mecanisms > concurrently. Like HMM and p2p. I'm not against moving some of the common stuff into a library. It sounds like

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 14/04/17 05:37 AM, Benjamin Herrenschmidt wrote: > I object to designing a subsystem that by design cannot work on whole > categories of architectures out there. Hardly. That's extreme. We'd design a subsystem that works for the easy cases and needs more work to support the offset cases. It

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 18/04/17 04:28 PM, Dan Williams wrote: > Unlike the pci bus address offset case which I think is fundamental to > support since shipping archs do this today, I think it is ok to say > p2p is restricted to a single sgl that gets to talk to host memory or > a single device. That said, what's

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 18/04/17 04:50 PM, Dan Williams wrote: > On Tue, Apr 18, 2017 at 3:48 PM, Logan Gunthorpe <log...@deltatee.com> wrote: >> >> >> On 18/04/17 04:28 PM, Dan Williams wrote: >>> Unlike the pci bus address offset case which I think is fundamental to >>&g

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 18/04/17 03:36 PM, Dan Williams wrote: > On Tue, Apr 18, 2017 at 2:22 PM, Jason Gunthorpe > wrote: >> On Tue, Apr 18, 2017 at 02:11:33PM -0700, Dan Williams wrote: I think this opens an even bigger can of worms.. >>> >>> No, I don't think it does. You'd

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 18/04/17 01:48 PM, Jason Gunthorpe wrote: > I think this is why progress on this keeps getting stuck - every > solution is a lot of work. Yup! There's also a ton of work just to get the iomem safety issues addressed. Let alone the dma mapping issues. > You could try to do a dummy mapping /

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 18/04/17 02:31 PM, Dan Williams wrote: > On Tue, Apr 18, 2017 at 1:29 PM, Jerome Glisse <jgli...@redhat.com> wrote: >>> On Tue, Apr 18, 2017 at 12:35 PM, Logan Gunthorpe <log...@deltatee.com> >>> wrote: >>>> >>>> >>>> On 18/

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 18/04/17 01:01 PM, Jason Gunthorpe wrote: > Ultimately every dma_ops will need special code to support P2P with > the special hardware that ops is controlling, so it makes some sense > to start by pushing the check down there in the first place. This > advice is partially motivated by how

[PATCH] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

it and pushing this patch ASAP. To maintain consistency I've renamed all four of kmap* and kunmap* to be map* and unmap*. (Even though only kmap_atomic presently conflicts.) [1] https://www.spinics.net/lists/target-devel/msg15070.html Signed-off-by: Logan Gunthorpe <log...@deltatee.

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 18/04/17 03:03 PM, Jason Gunthorpe wrote: > What about something more incremental like this instead: > - dma_ops will set map_sg_p2p == map_sg when they are updated to > support p2p, otherwise DMA on P2P pages will fail for those ops. > - When all ops support p2p we remove the if and

[PATCH] nvmet: convert from kmap to nvmet_copy_from_sgl

reports some frame size overflows on i386. [1] https://lwn.net/Articles/720053/ Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Cc: Christoph Hellwig <h...@lst.de> Cc: Sagi Grimberg <s...@grimberg.me> --- drivers/nvme/target/fabrics-cmd.c | 32 ++

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 18/04/17 04:24 PM, Jason Gunthorpe wrote: > Try and write a stacked map_sg function like you describe and you will > see how horrible it quickly becomes. Yes, unfortunately, I have to agree with this statement completely. > Since dma mapping is a performance path we must be careful not to >

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 24/04/17 01:36 AM, Knut Omang wrote: > My first reflex when reading this thread was to think that this whole domain > lends it self excellently to testing via Qemu. Could it be that doing this in > the opposite direction might be a safer approach in the long run even though > (significant)

Re: [PATCH v5 3/6] iomap: introduce io{read|write}64_{lo_hi|hi_lo}

On 31/07/17 10:10 AM, Andy Shevchenko wrote: > Some drivers (hardware) would like to have non-atomic MMIO accesses > when readq() defined Huh? But that's the whole point of the io64-nonatomic header. If a driver wants a specific non-atomic access they should just code two 32 bit accesses. > In

Re: [PATCH v5 3/6] iomap: introduce io{read|write}64_{lo_hi|hi_lo}

On 30/07/17 10:03 AM, Andy Shevchenko wrote: > On Thu, Jul 27, 2017 at 2:19 AM, Logan Gunthorpe <log...@deltatee.com> wrote: >> In order to provide non-atomic functions for io{read|write}64 that will >> use readq and writeq when appropriate. We define a number of variants

Re: [PATCH v3 01/16] switchtec: move structure definitions into a common header

y this already has my ack and will go through > Jon's tree. > > On Tue, Jul 25, 2017 at 02:57:38PM -0600, Logan Gunthorpe wrote: >> Create the switchtec.h header in include/linux with hardware defines >> and the switchtec_dev structure. Both moved directly from switchtec.c. >&g

Re: [PATCH v5 3/6] iomap: introduce io{read|write}64_{lo_hi|hi_lo}

On 31/07/17 11:58 AM, Andy Shevchenko wrote: > On Mon, Jul 31, 2017 at 7:31 PM, Logan Gunthorpe <log...@deltatee.com> wrote: >> On 31/07/17 10:10 AM, Andy Shevchenko wrote: >>> Some drivers (hardware) would like to have non-atomic MMIO accesses >>> when read

Re: [PATCH v5 3/6] iomap: introduce io{read|write}64_{lo_hi|hi_lo}

On 31/07/17 12:03 PM, Andy Shevchenko wrote: > > Per commit 3a044178cccf they are exactly created for this kind of cases. > Sure, ok, and my patchset provides the same set of functions to satisfy such a use. Logan

Re: BUG: NULL pointer dereference at ib_uverbs_comp_handler+0x20

On 01/08/17 01:29 PM, Jason Gunthorpe wrote: > On Tue, Aug 01, 2017 at 12:32:57PM -0600, Logan Gunthorpe wrote: >> Couldn't create rdma QP - Invalid argument >> Unable to create QP. >> Failed to create QP. > > Failing to create a QP makes me wonder if you have hav

Re: [PATCH v3 14/16] switchtec_ntb: implement scratchpad registers

On 01/08/17 01:10 PM, Jon Mason wrote: > It would probaly be better if I remarked about the SPADs in the actual > patch about the SPADS :) > > The whole point of using the SPADs in the NTB driver was to workaround > the problems establishing a connection between the two sides of the > NTB and

[PATCH v4 15/15] NTB: switchtec_ntb: Update switchtec documentation with notes for NTB

The switchtec_ntb driver has a couple requirements on the switchec's hardware configuration so we add these notes to the documentation. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Reviewed-by: Stephen Bates <sba...@raithlin.com> Reviewed-by: Kurt Schwemmer <kurt.schwem..

[PATCH v4 01/15] NTB: switchtec: Move structure definitions into a common header

Create the switchtec.h header in include/linux with hardware defines and the switchtec_dev structure. Both moved directly from switchtec.c. This is a prep patch for creating an NTB driver for Switchtec. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Reviewed-by: Stephen Bate

[PATCH v4 04/15] NTB: switchtec: Add link event notifier callback

from last time we checked. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Reviewed-by: Stephen Bates <sba...@raithlin.com> Reviewed-by: Kurt Schwemmer <kurt.schwem...@microsemi.com> Acked-by: Bjorn Helgaas <bhelg...@google.com> --- drivers/pci

[PATCH v4 06/15] NTB: Add check and comment for link up to mw_count() and mw_get_align()

on hardware that this doesn't matter for. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Acked-by: Allen Hubbe <allen.hu...@dell.com> --- include/linux/ntb.h | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/include/linux/ntb.h b/include/linux/ntb.h index

[PATCH v4 09/15] NTB: switchtec_ntb: Initialize hardware for doorbells and messages

for each partition. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Reviewed-by: Stephen Bates <sba...@raithlin.com> Reviewed-by: Kurt Schwemmer <kurt.schwem...@microsemi.com> Acked-by: Allen Hubbe <allen.hu...@dell.com> --- drivers/ntb/hw/mscc/

[PATCH v6 1/7] 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> Cc: Jyri Sarha <jsa...@ti.com> Cc: Arnd Bergmann <a...@arn

[PATCH v6 6/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> Acked-by: Dave Jiang <dave.ji...@intel.com> Acked-by: Allen Hubbe <allen.hu...@

[PATCH v6 0/7] make io{read|write}64 globally usable

versions were drastically different) Horia Geantă (1): crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64 Logan Gunthorpe (6): 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

[PATCH v4 05/15] NTB: Ensure ntb_mw_get_align() is only called when the link is up

goes up. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Acked-by: Allen Hubbe <allen.hu...@dell.com> --- drivers/ntb/ntb_transport.c | 20 ++-- drivers/ntb/test/ntb_perf.c | 18 +- drivers/ntb/test/ntb_tool.c | 6 +++--- 3 files changed, 22 inser

[PATCH v4 03/15] NTB: switchtec: Add NTB hardware register definitions

There are two additional regions: ctrl and dbmsg. The first is for generic NTB control and memory windows. The second is for doorbells and message registers. This patch also adds a number of related constants for using these registers. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Re

[PATCH v4 08/15] NTB: switchtec_ntb: Initialize hardware for memory windows

windows. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Reviewed-by: Stephen Bates <sba...@raithlin.com> Reviewed-by: Kurt Schwemmer <kurt.schwem...@microsemi.com> Acked-by: Allen Hubbe <allen.hu...@dell.com> --- drivers/ntb/hw/mscc/ntb_hw_switchtec.c | 360

[PATCH v4 10/15] NTB: switchtec_ntb: Add skeleton NTB driver

Add a skeleton NTB driver which will be filled out in subsequent patches. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Reviewed-by: Stephen Bates <sba...@raithlin.com> Reviewed-by: Kurt Schwemmer <kurt.schwem...@microsemi.com> Acked-by: Allen Hubbe <allen.hu...@dell.

[PATCH v4 02/15] NTB: switchtec: Export class symbol for use in upper layer driver

We export the class pointer symbol and add an extern define in the Switchtec header file. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Reviewed-by: Stephen Bates <sba...@raithlin.com> Reviewed-by: Kurt Schwemmer <kurt.schwem...@microsemi.com> Acked-by: Bjorn Helgaas &l

[PATCH v4 00/15] Switchtec NTB Support

two seeing the current NTB API only supports two hosts. The driver has been tested with ntb_netdev and fully passes the ntb_test script. This patchset is based off of ntb-next and can be found in this git repo: https://github.com/sbates130272/linux-p2pmem.git switchtec_ntb_v4 Logan Gunthorpe

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

device endianness, the lower address should be read from / 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: Horia Geantă <horia.gea...@nxp.com> Signed-off-by: Log

[PATCH v4 11/15] NTB: switchtec_ntb: Add link management

their status. The current status is maintained in a flag so ntb_is_link_up can return quickly. We utilize Switchtec's link status notifier to also check link changes when the switch notices a port changes state. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Reviewed-by: Stephen Bate

[PATCH v4 13/15] NTB: switchtec_ntb: Implement scratchpad registers

Seeing there is no dedicated hardware for this, we simply add these as entries in the shared memory window. Thus, we could support any number of them but 128 seems like enough, for now. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Reviewed-by: Stephen Bates <sba...@raithlin.com&

[PATCH v4 12/15] NTB: switchtec_ntb: Implement doorbell registers

to avoid concurrent read-modify-write accesses. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Reviewed-by: Stephen Bates <sba...@raithlin.com> Reviewed-by: Kurt Schwemmer <kurt.schwem...@microsemi.com> Acked-by: Allen Hubbe <allen.hu...@dell.com> --- drivers/ntb/hw/mscc

[PATCH v4 07/15] NTB: switchtec_ntb: Introduce initial NTB driver

Seeing the Switchtec NTB hardware shares the same endpoint as the management endpoint we utilize the class_interface API to register an NTB driver for every Switchtec device in the system that has the NTB class code. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Reviewed-by: Stephen

[PATCH v4 14/15] NTB: switchtec_ntb: Add memory window support

parameter is given to limit the size of the advertised memory windows. Higher layers tend to allocate the maximum BAR size and this has a tendency to fail when they try to allocate 4GB of contiguous memory. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Reviewed-by: Stephen Bate

[PATCH v6 2/7] 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 v6 5/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> cc: Christoph Hellwig <h...@lst.de> cc: Arnd Bergmann <a...@arndb.de> cc: Alan Cox <gno..

[PATCH v6 4/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> Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org> Cc: Paul Mackerras <pau..

[PATCH v6 3/7] 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> Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org> Cc: Paul Mackerras <pau...@samba.org> Cc: Michael Ellerman <m...@ellerman.id.au> --- ar

Re: [PATCH] ntb: use correct mw_count function in ntb_tool and ntb_transport

Hi John, On 17/07/17 09:16 AM, Jon Mason wrote: > Per your request, this has been applied to my ntb-next branch. This isn't a huge issue but I meant for this patch to fix the mistake in the new ntb_api before it hit 4.13. On the other hand, seeing there's no way to actually trigger the issue

Re: [PATCH] ntb: use correct mw_count function in ntb_tool and ntb_transport

On 17/07/17 10:46 AM, Jon Mason wrote: > s/John/Jon Apologies. Monday morning -- not fully awake yet. > NP. I'll add a "Fixes: ..." to it. So, it'll get pulled into the > -stable trees. Ok, thanks, but it's not really the stable trees that need to see it seeing 4.13 isn't released yet, it

[PATCH v4 1/5] 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 v4 2/5] 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> Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org> Cc: Paul Mackerras <pau..

[PATCH v4 3/5] 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> cc: Christoph Hellwig <h...@lst.de> cc: Arnd Bergmann <a...@arndb.de> cc: Alan Cox <gno..

[PATCH v4 4/5] 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> Cc: Jon Mason <jdma...@kudzu.us> Cc: Allen Hubbe <allen.hu...@emc.com> Ac

[PATCH v4 5/5] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64

device endianness, the lower address should be read from / 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: Horia Geantă <horia.gea...@nxp.com> Signed-off-by: Log

[PATCH v4 0/5] make io{read|write}64 globally usable

with a couple of the defines in io-64-nonatomic* headers - Fixed a typo noticed by Horia. Horia Geantă (1): crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64 Logan Gunthorpe (4): powerpc: io.h: move iomap.h include so that it can use readq/writeq defs iomap

[PATCH v2 12/16] switchtec_ntb: add link management

their status. The current status is maintained in a flag so ntb_is_link_up can return quickly. We utilize Switchtec's link status notifier to also check link changes when the switch notices a port changes state. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Reviewed-by: Stephen Bate

[PATCH v2 11/16] switchtec_ntb: add skeleton NTB driver

Add a skeleton NTB driver which will be filled out in subsequent patches. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Reviewed-by: Stephen Bates <sba...@raithlin.com> Reviewed-by: Kurt Schwemmer <kurt.schwem...@microsemi.com> --- drivers/ntb/hw/mscc/swi

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