Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

On 02/04/18 01:16 PM, Jerome Glisse wrote: > There isn't good API at the moment AFAIK, closest thing would either be > lookup_resource() or region_intersects(), but a more appropriate one can > easily be added, code to walk down the tree is readily available. More- > over this can be optimize

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

On 02/04/18 11:20 AM, Jerome Glisse wrote: > The point i have been trying to get accross is that you do have this > information with dma_map_resource() you know the device to which you > are trying to map (dev argument to dma_map_resource()) and you can > easily get the device to which the

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

On 30/03/18 01:45 PM, Jerome Glisse wrote: > Looking at upstream code it seems that the x86 bits never made it upstream > and thus what is now upstream is only for ARM. See [1] for x86 code. Dunno > what happen, i was convince it got merge. So yes current code is broken on > x86. ccing Joerg

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

On 29/03/18 07:58 PM, Jerome Glisse wrote: > On Thu, Mar 29, 2018 at 10:25:52AM -0600, Logan Gunthorpe wrote: >> >> >> On 29/03/18 10:10 AM, Christian König wrote: >>> Why not? I mean the dma_map_resource() function is for P2P while other >>> dma_map

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

On 29/03/18 10:10 AM, Christian König wrote: > Why not? I mean the dma_map_resource() function is for P2P while other > dma_map_* functions are only for system memory. Oh, hmm, I wasn't aware dma_map_resource was exclusively for mapping P2P. Though it's a bit odd seeing we've been working

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

On 29/03/18 05:44 AM, Christian König wrote: > Am 28.03.2018 um 21:53 schrieb Logan Gunthorpe: >> >> On 28/03/18 01:44 PM, Christian König wrote: >>> Well, isn't that exactly what dma_map_resource() is good for? As far as >>> I can see it makes sure I

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

On 28/03/18 01:44 PM, Christian König wrote: > Well, isn't that exactly what dma_map_resource() is good for? As far as > I can see it makes sure IOMMU is aware of the access route and > translates a CPU address into a PCI Bus address. > I'm using that with the AMD IOMMU driver and at least

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

On 28/03/18 12:28 PM, Christian König wrote: > I'm just using amdgpu as blueprint because I'm the co-maintainer of it > and know it mostly inside out. Ah, I see. > The resource addresses are translated using dma_map_resource(). As far > as I know that should be sufficient to offload all the

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

On 28/03/18 10:02 AM, Christian König wrote: > Yeah, that looks very similar to what I picked up from the older > patches, going to read up on that after my vacation. Yeah, I was just reading through your patchset and there are a lot of similarities. Though, I'm not sure what you're trying to

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

On 28/03/18 09:07 AM, Christian König wrote: > Am 28.03.2018 um 14:38 schrieb Christoph Hellwig: >> On Sun, Mar 25, 2018 at 12:59:54PM +0200, Christian König wrote: >>> From: "wda...@nvidia.com" >>> >>> Add an interface to find the first device which is upstream of both >>>

Re: Enabling peer to peer device transactions for PCIe devices

On 23/10/17 10:08 AM, David Laight wrote: It is also worth checking that the hardware actually supports p2p transfers. Writes are more likely to be supported then reads. ISTR that some intel cpus support some p2p writes, but there could easily be errata against them. Ludwig mentioned a PCIe

Re: Enabling peer to peer device transactions for PCIe devices

On 22/10/17 12:13 AM, Petrosyan, Ludwig wrote: > But at first sight it has to be simple: > The PCIe Write transactions are address routed, so if in the packet header > the other endpoint address is written the TLP has to be routed (by PCIe > Switch to the endpoint), the DMA reading from the end

Re: Enabling peer to peer device transactions for PCIe devices

Hi Ludwig, P2P transactions are still *very* experimental at the moment and take a lot of expertise to get working in a general setup. It will definitely require changes to the kernel, including the drivers of all the devices you are trying to make talk to eachother. If you're up for it you

Re: [PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function

On 28/04/17 11:51 AM, Herbert Xu wrote: > On Fri, Apr 28, 2017 at 10:53:45AM -0600, Logan Gunthorpe wrote: >> >> >> On 28/04/17 12:30 AM, Herbert Xu wrote: >>> You are right. Indeed the existing code looks buggy as they >>> don't take sg->offset into a

Re: [PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function

On 28/04/17 12:30 AM, Herbert Xu wrote: > You are right. Indeed the existing code looks buggy as they > don't take sg->offset into account when doing the kmap. Could > you send me some patches that fix these problems first so that > they can be easily backported? Ok, I think the only buggy

Re: [PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper function

On 27/04/17 05:20 PM, Jason Gunthorpe wrote: > It seems the most robust: test for iomem, and jump to a slow path > copy, otherwise inline the kmap and memcpy > > Every place doing memcpy from sgl will need that pattern to be > correct. Ok, sounds like a good place to start to me. I'll see what

Re: [PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper function

On 27/04/17 04:11 PM, Jason Gunthorpe wrote: > On Thu, Apr 27, 2017 at 03:53:37PM -0600, Logan Gunthorpe wrote: > Well, that is in the current form, with more users it would make sense > to optimize for the single page case, eg by providing the existing > call, providing a faster

Re: [PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper function

On 27/04/17 02:53 PM, Jason Gunthorpe wrote: > blkfront is one of the drivers I looked at, and it appears to only be > memcpying with the bvec_data pointer, so I wonder why it does not use > sg_copy_X_buffer instead.. Yes, sort of... But you'd potentially end up calling sg_copy_to_buffer

Re: [PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper function

On 26/04/17 01:37 AM, Roger Pau Monné wrote: > On Tue, Apr 25, 2017 at 12:21:02PM -0600, Logan Gunthorpe wrote: >> Straightforward conversion to the new helper, except due to the lack >> of error path, we have to use SG_MAP_MUST_NOT_FAIL which may BUG_ON in >> certai

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

On 26/04/17 01:44 AM, Christoph Hellwig wrote: > I think we'll at least need a draft of those to make sense of these > patches. Otherwise they just look very clumsy. Ok, what follows is a draft patch attempting to show where I'm thinking of going with this. Obviously it will not compile because

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

On 27/04/17 09:27 AM, Jason Gunthorpe wrote: > On Thu, Apr 27, 2017 at 08:53:38AM +0200, Christoph Hellwig wrote: > How about first switching as many call sites as possible to use > sg_copy_X_buffer instead of kmap? Yeah, I could look at doing that first. One problem is we might get more Naks

Re: [PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function

On 26/04/17 09:56 PM, Herbert Xu wrote: > On Tue, Apr 25, 2017 at 12:20:54PM -0600, Logan Gunthorpe wrote: >> Very straightforward conversion to the new function in the caam driver >> and shash library. >> >> Signed-off-by: Logan Gunthorpe <log...@deltate

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

On 27/04/17 12:53 AM, Christoph Hellwig wrote: > I think you'll need to follow the existing kmap semantics and never > fail the iomem version either. Otherwise you'll have a special case > that's almost never used that has a different error path. > > Again, wrong way. Suddenly making things

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

On 26/04/17 02:59 AM, wrote: > Good to know that somebody is working on this. Those problems troubled > us as well. Thanks Christian. It's a daunting problem and a there's a lot of work to do before we will ever be where we need to be so any help, even an ack, is greatly appreciated. Logan

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

On 26/04/17 01:44 AM, Christoph Hellwig wrote: > I think we'll at least need a draft of those to make sense of these > patches. Otherwise they just look very clumsy. Ok, I'll work up a draft proposal and send it in a couple days. But without a lot of cleanup such as this series it's not going

[PATCH v2 16/21] mmc: sdhci: Make use of the new sg_map helper function

Straightforward conversion, except due to the lack of an error path we have to use SG_MAP_MUST_NOT_FAIL which may BUG_ON in certain cases in the future. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Cc: Adrian Hunter <adrian.hun...@intel.com> Cc: Ulf Hansson <ulf.han

[PATCH v2 18/21] mmc: tmio: Make use of the new sg_map helper function

Straightforward conversion to sg_map helper. Seeing there is no cleare error path, SG_MAP_MUST_NOT_FAIL which may BUG_ON in certain cases in the future. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Cc: Wolfram Sang <wsa+rene...@sang-engineering.com> Cc: Ulf Hansson <ulf.han

[PATCH v2 04/21] target: Make use of the new sg_map function at 16 call sites

with this driver. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Cc: "Nicholas A. Bellinger" <n...@linux-iscsi.org> --- drivers/target/iscsi/iscsi_target.c| 29 +++--- drivers/target/target_core_rd.c| 3 +- drivers/target/target_

[PATCH v2 03/21] libiscsi: Make use of new the sg_map helper function

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 use ISCSI_TCP_INTERNAL_ERR error type that was prepared earlier for this. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Cc: Lee Duncan

[PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function

Very straightforward conversion to the new function in the caam driver and shash library. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Cc: Herbert Xu <herb...@gondor.apana.org.au> Cc: "David S. Miller" <da...@davemloft.net> --- crypto/shash.c|

[PATCH v2 14/21] scsi: libfc, csiostor: Change to sg_copy_buffer in two drivers

These two drivers appear to duplicate the functionality of sg_copy_buffer. So we clean them up to use the common code. This helps us remove a couple of instances that would otherwise be slightly tricky sg_map usages. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Cc: Johannes Thumsh

[PATCH v2 00/21] Introduce common scatterlist map function

and then I can send the individual subsystem patches on to their respective maintainers and get them merged independantly. (This is to avoid the conflicts I created with my last cleanup set... Sorry) Though, I'm certainly open to other suggestions to get it merged. Logan Gunthorpe (21

[PATCH v2 17/21] mmc: spi: Make use of the new sg_map helper function

We use the sg_map helper but it's slightly more complicated as we only check for the error when the mapping actually gets used. Such that if the mapping failed but wasn't needed then no error occurs. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Cc: Ulf Hansson <ulf.hans...@l

[PATCH v2 21/21] memstick: Make use of the new sg_map helper function

Straightforward conversion, but we have to make use of SG_MAP_MUST_NOT_FAIL which may BUG_ON in certain cases in the future. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Cc: Alex Dubov <oa...@yahoo.com> --- drivers/memstick/host/jmb38x_ms.c | 11 ++- drivers/m

[PATCH v2 09/21] staging: unisys: visorbus: Make use of the new sg_map helper function

Straightforward conversion to the new function. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Acked-by: David Kershner <david.kersh...@unisys.com> --- drivers/staging/unisys/visorhba/visorhba_main.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --g

[PATCH v2 06/21] crypto: hifn_795x: Make use of the new sg_map helper function

t t->offset is likely always zero anyway. So, this patch cleans that brokeness up. Also, a change to the error path: if ablkcipher_get failed, everything seemed to proceed as if it hadn't. Setting 'error' should hopefully clear that up. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Cc

[PATCH v2 11/21] scsi: ipr, pmcraid, isci: Make use of the new sg_map helper

Very straightforward conversion of three scsi drivers. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Cc: Brian King <brk...@us.ibm.com> Cc: Artur Paszkiewicz <artur.paszkiew...@intel.com> --- drivers/scsi/ipr.c | 27 ++- drivers/scsi/i

[PATCH v2 19/21] mmc: sdricoh_cs: Make use of the new sg_map helper function

This is a straightforward conversion to the new function. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Cc: Sascha Sommer <saschasom...@freenet.de> Cc: Ulf Hansson <ulf.hans...@linaro.org> --- drivers/mmc/host/sdricoh_cs.c | 14 +- 1 file changed, 9 insertio

[PATCH v2 10/21] RDS: Make use of the new sg_map helper function

Straightforward conversion except there's no error path, so we make use of SG_MAP_MUST_NOT_FAIL which may BUG_ON in certain cases in the future. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Cc: Santosh Shilimkar <santosh.shilim...@oracle.com> Cc: "David S. Miller"

[PATCH v2 12/21] scsi: hisi_sas, mvsas, gdth: Make use of the new sg_map helper function

Very straightforward conversion of three scsi drivers. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Cc: Achim Leubner <achim_leub...@adaptec.com> Cc: John Garry <john.ga...@huawei.com> --- drivers/scsi/gdth.c| 9 +++-- drivers/scsi/hisi_sas/his

[PATCH v2 13/21] scsi: arcmsr, ips, megaraid: Make use of the new sg_map helper function

Very straightforward conversion of three scsi drivers Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Cc: Adaptec OEM Raid Solutions <aacr...@adaptec.com> Cc: Kashyap Desai <kashyap.de...@broadcom.com> Cc: Sumit Saxena <sumit.sax...@broadcom.com> Cc: Shivasharan S

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

This is a single straightforward conversion from kmap to sg_map. We also create the i915_gem_object_unmap function to common up the unmap code. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Acked-by: Daniel Vetter <daniel.vet...@ffwll.ch> --- drivers/gpu/drm/i915/i91

[PATCH v2 20/21] mmc: tifm_sd: Make use of the new sg_map helper function

of the offset but it's already added and used earlier in the code.) There's also no error path, so we use SG_MAP_MUST_NOT_FAIL which may BUG_ON in certain cases in the future. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Cc: Alex Dubov <oa...@yahoo.com> Cc: Ulf Hansson <ulf.han

[PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper function

Straightforward conversion to the new helper, except due to the lack of error path, we have to use SG_MAP_MUST_NOT_FAIL which may BUG_ON in certain cases in the future. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Cc: Boris Ostrovsky <boris.ostrov...@oracle.com> Cc: Juerge

[PATCH v2 08/21] dm-crypt: Make use of the new sg_map helper in 4 call sites

Very straightforward conversion to the new function in all four spots. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Cc: Alasdair Kergon <a...@redhat.com> Cc: Mike Snitzer <snit...@redhat.com> --- drivers/md/dm-crypt.c | 39 ++-

[PATCH v2 01/21] scatterlist: Introduce sg_map helper functions

. Also, in terms of cleanup, a few of the existing kmap(sg_page) users play things a bit loose in terms of whether they apply sg->offset so using these helper functions should help avoid such issues. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- include/linux/scatterli

[PATCH v2 02/21] 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

[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.

[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: [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: [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 09/22] dm-crypt: Make use of the new sg_map helper in 4 call sites

Thanks for the information Milan. On 15/04/17 06:10 AM, Milan Broz wrote: > I think your patch is ok (if it is just plain conversion), if it is > really needed, we can switch to ahash later in follow-up patch. Sounds good to me. > p.s. > there is a lot of lists on cc, but for this patch is

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: [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 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 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 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 02/22] nvmet: Make use of the new sg_map helper function

On 13/04/17 10:59 PM, Christoph Hellwig wrote: > On Thu, Apr 13, 2017 at 04:05:15PM -0600, Logan Gunthorpe wrote: >> This is a straight forward conversion in two places. Should kmap fail, >> the code will return an INVALD_DATA error in the completion. > > It r

[PATCH 15/22] scsi: libfc, csiostor: Change to sg_copy_buffer in two drivers

These two drivers appear to duplicate the functionality of sg_copy_buffer. So we clean them up to use the common code. This helps us remove a couple of instances that would otherwise be slightly tricky sg_map usages. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/scsi/cs

[PATCH 07/22] crypto: shash, caam: Make use of the new sg_map helper function

Very straightforward conversion to the new function in two crypto drivers. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- crypto/shash.c| 9 ++--- drivers/crypto/caam/caamalg.c | 8 +++- 2 files changed, 9 insertions(+), 8 deletions(-) diff --git a/

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

Straightforward conversion to the new function. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/staging/unisys/visorhba/visorhba_main.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/staging/unisys/visorhba/visorhba_main.c b/d

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

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 propogate a possible kmap error down and create a new ISCSI_TCP_INTERNAL_ERR error type for this. Signed-off-by: Logan Gunthorpe <

[PATCH 12/22] scsi: ipr, pmcraid, isci: Make use of the new sg_map helper in 4 call sites

Very straightforward conversion of three scsi drivers. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/scsi/ipr.c | 27 ++- drivers/scsi/isci/request.c | 42 +- drivers/scsi/pmcraid.c

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

with this driver. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/target/iscsi/iscsi_target.c| 27 +--- drivers/target/target_core_rd.c| 3 +- drivers/target/target_core_sbc.c | 122 +++-- drivers/target/target_core_transport.c

[PATCH 18/22] mmc: spi: Make use of the new sg_map helper function

We use the sg_map helper but it's slightly more complicated as we only check for the error when the mapping actually gets used. Such that if the mapping failed but wasn't needed then no error occurs. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/mmc/host/mmc_spi.

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

Straightforward conversion to the new helper, except due to the lack of error path, we have to warn if unmapable memory is ever present in the sgl. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/block/xen-blkfront.c | 33 +++-- 1 file chang

[PATCH 22/22] memstick: Make use of the new sg_map helper function

Straightforward conversion, but we have to WARN if unmappable memory finds its way into the sgl. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/memstick/host/jmb38x_ms.c | 23 ++- drivers/memstick/host/tifm_ms.c | 22 +- 2 files c

[PATCH 19/22] mmc: tmio: Make use of the new sg_map helper function

Straightforward conversion to sg_map helper. A couple paths will WARN if the memory does not end up being mappable. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/mmc/host/tmio_mmc.h | 12 ++-- drivers/mmc/host/tmio_mmc_dma.c | 5 + drivers/mm

[PATCH 08/22] crypto: chcr: Make use of the new sg_map helper function

The get_page in this area looks *highly* suspect due to there being no corresponding put_page. However, I've left that as is to avoid breaking things. I've also removed the KMAP_ATOMIC_ARGS check as it appears to be dead code that dates back to when it was first committed... Signed-off-by: Logan

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

This is a single straightforward conversion from kmap to sg_map. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/gpu/drm/i915/i915_gem.c | 27 --- 1 file changed, 16 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/d

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

, a few of the existing kmap(sg_page) users play things a bit loose in terms of whether they apply sg->offset so using these helper functions should help avoid such issues. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/dma-buf/dma-buf.c | 3 ++ include/linux/scatterli

[PATCH 02/22] nvmet: Make use of the new sg_map helper function

This is a straight forward conversion in two places. Should kmap fail, the code will return an INVALD_DATA error in the completion. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/nvme/target/fabrics-cmd.c | 16 1 file changed, 12 insertions(+), 4 del

[PATCH 11/22] RDS: Make use of the new sg_map helper function

Straightforward conversion except there's no error path, so we WARN if the sg_map fails. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- net/rds/ib_recv.c | 17 ++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/net/rds/ib_recv.c b/net/rds/ib_recv.c

[PATCH 00/22] Introduce common scatterlist map function

certainly open to other suggestions to get it merged. The patchset is based on v4.11-rc6 and can be found in the sg_map branch from this git tree: https://github.com/sbates130272/linux-p2pmem.git Thanks, Logan Logan Gunthorpe (22): scatterlist: Introduce sg_map helper functions nvmet: Make

[PATCH 17/22] mmc: sdhci: Make use of the new sg_map helper function

Straightforward conversion, except due to the lack of error path we have to WARN if the memory in the SGL is not mappable. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/mmc/host/sdhci.c | 35 ++- 1 file changed, 30 insertions(+), 5 del

[PATCH 21/22] mmc: tifm_sd: Make use of the new sg_map helper function

of the offset but it's already added and used earlier in the code. There's also no error path, so if unmappable memory finds its way into the sgl we can only WARN. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/mmc/host/tifm_sd.

[PATCH 13/22] scsi: hisi_sas, mvsas, gdth: Make use of the new sg_map helper function

Very straightforward conversion of three scsi drivers. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/scsi/gdth.c| 9 +++-- drivers/scsi/hisi_sas/hisi_sas_v1_hw.c | 14 +- drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 13 + d

[PATCH 20/22] mmc: sdricoh_cs: Make use of the new sg_map helper function

This is a straightforward conversion to the new function. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/mmc/host/sdricoh_cs.c | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/drivers/mmc/host/sdricoh_cs.c b/drivers/mmc/host/sdricoh_cs.c

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

Very straightforward conversion to the new function in all four spots. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/md/dm-crypt.c | 38 +- 1 file changed, 25 insertions(+), 13 deletions(-) diff --git a/drivers/md/dm-crypt.c b/drivers

[PATCH 14/22] scsi: arcmsr, ips, megaraid: Make use of the new sg_map helper function

Very straightforward conversion of three scsi drivers Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/scsi/arcmsr/arcmsr_hba.c | 16 drivers/scsi/ips.c | 8 drivers/scsi/megaraid.c | 9 +++-- 3 files changed, 23 inse

[PATCH 06/22] crypto: hifn_795x: Make use of the new sg_map helper function

t t->offset is likely always zero anyway. So, this patch cleans that brokeness up. Also, a change to the error path: if ablkcipher_get failed, everything seemed to proceed as if it hadn't. Setting 'error' should hopefully clear that up. Signed-off-by: Logan Gunthorpe <log...@deltatee.com>

[PATCH v5 10/16] iio:core: utilize new cdev_device_add helper function

, but this doesn't appear to be required in any way. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/iio/industrialio-core.c | 15 --- 1 file changed, 4 insertions(+), 11 deletions(-) diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c

[PATCH v5 11/16] media: utilize new cdev_device_add helper function

Replace the open coded registration of the cdev and dev with the new device_add_cdev() helper. The helper replaces a common pattern by taking the proper reference against the parent device and adding both the cdev and the device. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Acked-by

[PATCH v5 07/16] platform/chrome: cros_ec_dev - utilize new cdev_device_add helper function

function: we use put_device instead of kfree directly as recommended by the device_initialize documentation. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/platform/chrome/cros_ec_dev.c | 31 +++ 1 file changed, 7 insertions(+), 24 deletions(-)

[PATCH v5 05/16] gpiolib: utilize new cdev_device_add helper function

Replace the open coded registration of the cdev and dev with the new device_add_cdev() helper. The helper replaces a common pattern by taking the proper reference against the parent device and adding both the cdev and the device. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Re

[PATCH v5 12/16] mtd: utilize new cdev_device_add helper function

to use put_device in the error path which simplifies things a good deal. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/mtd/ubi/build.c | 91 + drivers/mtd/ubi/vmt.c | 49 +- 2 files changed, 33 inse

[PATCH v5 09/16] infiniband: utilize the new cdev_set_parent function

This replaces the suspect looking cdev.kobj.parent lines with the equivalent cdev_set_parent function. This is a straightforward change that's largely cosmetic but it does push the kobj.parent ownership into char_dev.c where it belongs. Signed-off-by: Logan Gunthorpe <log...@deltatee.

[PATCH v5 03/16] device-dax: utilize new cdev_device_add helper function

Replace the open coded registration of the cdev and dev with the new device_add_cdev() helper. The helper replaces a common pattern by taking the proper reference against the parent device and adding both the cdev and the device. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Re

[PATCH v5 13/16] rapidio: utilize new cdev_device_add helper function

). We also remove an unnecessary extra get_device from the code. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/rapidio/devices/rio_mport_cdev.c | 24 1 file changed, 8 insertions(+), 16 deletions(-) diff --git a/drivers/rapidio/devices/rio_mport_

[PATCH v5 06/16] tpm-chip: utilize new cdev_device_add helper function

Replace the open coded registration of the cdev and dev with the new device_add_cdev() helper. The helper replaces a common pattern by taking the proper reference against the parent device and adding both the cdev and the device. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Re

[PATCH v5 15/16] scsi: utilize new cdev_device_add helper function

is also moved out of __remove and into unregister to simplify things and follow the pattern other devices are using. This also drop an extra unnecessary get_device/put_device in the code. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/scsi/osd/osd_uld.

[PATCH v5 00/16] Cleanup chardev instances with helper function

n Williams (1): device-dax: fix cdev leak Jason Gunthorpe (1): IB/ucm: utilize new cdev_device_add helper function Logan Gunthorpe (14): chardev: add helper function to register char devs with a struct device device-dax: utilize new cdev_device_add helper function input: utilize new cd

[PATCH v5 14/16] rtc: utilize new cdev_device_add helper function

this by avoiding calling cdev_add if the devt is not set. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Acked-by: Alexandre Belloni <alexandre.bell...@free-electrons.com> --- drivers/rtc/class.c| 14 ++ drivers/rtc/rtc-core.h | 10 -- drivers/rtc/rtc

[PATCH v5 16/16] switchtec: utilize new device_add_cdev helper function

Very straightforward conversion to device_add_cdev. Drop cdev_add and device_add and use cdev_device_add. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/pci/switch/switchtec.c | 11 ++- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/drivers/pci/

[PATCH v5 02/16] device-dax: fix cdev leak

.willi...@intel.com> Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Reviewed-by: Johannes Thumshirn <jthumsh...@suse.de> --- drivers/dax/dax.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c index 8d9829f

[PATCH v5 04/16] input: utilize new cdev_device_add helper function

Replace the open coded registration of the cdev and dev with the new device_add_cdev() helper in evdev, joydev and mousedev. The helper replaces a common pattern by taking the proper reference against the parent device and adding both the cdev and the device. Signed-off-by: Logan Gunthorpe <

[PATCH v5 01/16] chardev: add helper function to register char devs with a struct device

] https://lkml.org/lkml/2017/2/13/700 [2] https://lkml.org/lkml/2017/2/10/370 Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Signed-off-by: Dan Williams <dan.j.willi...@intel.com> Reviewed-by: Hans Verkuil <hans.verk...@cisco.com> Reviewed-by: Alexandre Belloni <a

[PATCH v5 08/16] IB/ucm: utilize new cdev_device_add helper function

ve out of the struct device release function. This cleans up the error path significantly and thus also fixes a minor bug where the devnum would not be released if cdev_add failed. Signed-off-by: Jason Gunthorpe <jguntho...@obsidianresearch.com> Signed-off-by: Logan Gunthorpe <log.

Re: Enabling peer to peer device transactions for PCIe devices

On 11/01/17 09:54 PM, Stephen Bates wrote: > The iopmem patchset addressed all the use cases above and while it is not > an in kernel API it could have been modified to be one reasonably easily. > As Logan states the driver can then choose to pass the VMAs to user-space > in a manner that makes

  1   2   >