On 2020-12-10 12:25 p.m., Thomas Gleixner wrote:
> Use the proper core function.
>
> Signed-off-by: Thomas Gleixner
> Cc: Jon Mason
> Cc: Dave Jiang
> Cc: Allen Hubbe
> Cc: linux-...@googlegroups.com
Looks good to me.
Reviewed-by: Logan Gunthorpe
> ---
>
On 2022-01-11 1:17 a.m., John Hubbard wrote:
> On 1/10/22 11:34, Matthew Wilcox wrote:
>> TLDR: I want to introduce a new data type:
>>
>> struct phyr {
>> phys_addr_t addr;
>> size_t len;
>> };
>>
>> and use it to replace bio_vec as well as using it to replace the array
>> of
On 2022-01-11 2:25 p.m., Matthew Wilcox wrote:
> That's reproducing the bad decision of the scatterlist, only with
> a different encoding. You end up with something like:
>
> struct neoscat {
> dma_addr_t dma_addr;
> phys_addr_t phys_addr;
> size_t dma_len;
> size_t phy
On 2022-01-11 3:53 p.m., Jason Gunthorpe wrote:
> I just want to share the whole API that will have to exist to
> reasonably support this flexible array of intervals data structure..
Is that really worth it? I feel like type safety justifies replicating a
bit of iteration and allocation infrast
On 2022-01-11 3:57 p.m., Jason Gunthorpe wrote:
> On Tue, Jan 11, 2022 at 03:09:13PM -0700, Logan Gunthorpe wrote:
>
>> Either that, or we need a wrapper that allocates an appropriately
>> sized SGL to pass to any dma_map implementation that doesn't support
>> the
On 2022-01-11 4:02 p.m., Jason Gunthorpe wrote:
> On Tue, Jan 11, 2022 at 03:57:07PM -0700, Logan Gunthorpe wrote:
>>
>>
>> On 2022-01-11 3:53 p.m., Jason Gunthorpe wrote:
>>> I just want to share the whole API that will have to exist to
>>> reasonably s
On 2019-05-01 5:01 p.m., Brendan Higgins wrote:
> +/*
> + * struct kunit_try_catch - provides a generic way to run code which might
> fail.
> + * @context: used to pass user data to the try and catch functions.
> + *
> + * kunit_try_catch provides a generic, architecture independent way to
> ex
f using UML
(ie. not being able to compile large swaths of the tree due to features
that don't exist in that arch) but these are concerns for later.
I'd prefer to see the unnecessary indirection that I pointed out in
patch 8 cleaned up but, besides that, the code looks good to me.
Rev
On 2019-05-03 12:48 a.m., Brendan Higgins wrote:
> On Thu, May 2, 2019 at 8:15 PM Logan Gunthorpe wrote:
>> On 2019-05-01 5:01 p.m., Brendan Higgins wrote:
>>> +/*
>>> + * struct kunit_try_catch - provides a generic way to run code which might
>>> fail.
>
On 2019-05-14 6:14 p.m., Frank Rowand wrote:
> The high level issue is to provide reviewers with enough context to be
> able to evaluate the patch series. That is probably not very obvious
> at this point in the thread. At this point I was responding to Logan's
> response to me that I should be
On 2019-01-29 12:44 p.m., Greg Kroah-Hartman wrote:
> On Tue, Jan 29, 2019 at 11:24:09AM -0700, Logan Gunthorpe wrote:
>>
>>
>> On 2019-01-29 10:47 a.m., jgli...@redhat.com wrote:
>>> +bool pci_test_p2p(struct device *devA, struct device *devB)
>>>
On 2019-01-29 10:47 a.m., jgli...@redhat.com wrote:
> From: Jérôme Glisse
>
> device_test_p2p() return true if two devices can peer to peer to
> each other. We add a generic function as different inter-connect
> can support peer to peer and we want to genericaly test this no
> matter what the i
On 2019-01-29 1:57 p.m., Jerome Glisse wrote:
> GPU driver must be in control and must be call to. Here there is 2 cases
> in this patchset and i should have instead posted 2 separate patchset as
> it seems that it is confusing things.
>
> For the HMM page, the physical address of the page ie th
On 2019-01-29 4:47 p.m., Jerome Glisse wrote:
> The whole point is to allow to use device memory for range of virtual
> address of a process when it does make sense to use device memory for
> that range. So they are multiple cases where it does make sense:
> [1] - Only the device is accessing the
On 2019-01-29 12:44 p.m., Jerome Glisse wrote:
>> I'd suggest [1] should be a part of the patchset so we can actually see
>> a user of the stuff you're adding.
>
> I did not wanted to clutter patchset with device driver specific usage
> of this. As the API can be reason about in abstract way.
I
On 2019-01-29 10:47 a.m., jgli...@redhat.com wrote:
> + /*
> + * Optional for device driver that want to allow peer to peer (p2p)
> + * mapping of their vma (which can be back by some device memory) to
> + * another device.
> + *
> + * Note that the exporting device
On 2019-01-29 12:11 p.m., Jerome Glisse wrote:
> On Tue, Jan 29, 2019 at 11:36:29AM -0700, Logan Gunthorpe wrote:
>>
>>
>> On 2019-01-29 10:47 a.m., jgli...@redhat.com wrote:
>>
>>> + /*
>>> +* Optional for device driver that want to allow peer
On 2019-01-29 12:32 p.m., Jason Gunthorpe wrote:
> Jerome, I think it would be nice to have a helper scheme - I think the
> simple case would be simple remapping of PCI BAR memory, so if we
> could have, say something like:
>
> static const struct vm_operations_struct my_ops {
> .p2p_map = p2p
On 2019-01-29 10:47 a.m., jgli...@redhat.com wrote:
> +bool pci_test_p2p(struct device *devA, struct device *devB)
> +{
> + struct pci_dev *pciA, *pciB;
> + bool ret;
> + int tmp;
> +
> + /*
> + * For now we only support PCIE peer to peer but other inter-connect
> + * ca
On 2019-01-29 12:56 p.m., Alex Deucher wrote:
> On Tue, Jan 29, 2019 at 12:47 PM wrote:
>>
>> From: Jérôme Glisse
>>
>> device_test_p2p() return true if two devices can peer to peer to
>> each other. We add a generic function as different inter-connect
>> can support peer to peer and we want to
On 2019-01-29 2:50 p.m., Jerome Glisse wrote:
> No this is the non HMM case i am talking about here. Fully ignore HMM
> in this frame. A GPU driver that do not support or use HMM in anyway
> has all the properties and requirement i do list above. So all the points
> i was making are without HMM i
On 2019-01-30 12:19 p.m., Jason Gunthorpe wrote:
> On Wed, Jan 30, 2019 at 11:13:11AM -0700, Logan Gunthorpe wrote:
>>
>>
>> On 2019-01-30 10:44 a.m., Jason Gunthorpe wrote:
>>> I don't see why a special case with a VMA is really that different.
>>
>&
On 2019-01-30 12:06 p.m., Jason Gunthorpe wrote:
>> Way less problems than not having struct page for doing anything
>> non-trivial. If you map the BAR to userspace with remap_pfn_range
>> and friends the mapping is indeed very simple. But any operation
>> that expects a page structure, which i
On 2019-01-30 2:50 p.m., Jason Gunthorpe wrote:
> On Wed, Jan 30, 2019 at 02:01:35PM -0700, Logan Gunthorpe wrote:
>
>> And I feel the GUP->SGL->DMA flow should still be what we are aiming
>> for. Even if we need a special GUP for special pages, and a special DMA
>&
On 2019-01-30 12:22 p.m., Jerome Glisse wrote:
> On Wed, Jan 30, 2019 at 06:56:59PM +, Jason Gunthorpe wrote:
>> On Wed, Jan 30, 2019 at 10:17:27AM -0700, Logan Gunthorpe wrote:
>>>
>>>
>>> On 2019-01-29 9:18 p.m., Jason Gunthorpe wrote:
>>>>
On 2019-01-30 12:38 p.m., Jason Gunthorpe wrote:
> On Wed, Jan 30, 2019 at 02:22:34PM -0500, Jerome Glisse wrote:
>
>> For GPU it would not work, GPU might want to use main memory (because
>> it is running out of BAR space) it is a lot easier if the p2p_map
>> callback calls the right dma map fu
On 2019-01-30 12:59 p.m., Jason Gunthorpe wrote:
> On Wed, Jan 30, 2019 at 12:45:46PM -0700, Logan Gunthorpe wrote:
>>
>>
>> On 2019-01-30 12:06 p.m., Jason Gunthorpe wrote:
>>>> Way less problems than not having struct page for doing anything
>>>>
On 2019-01-29 9:18 p.m., Jason Gunthorpe wrote:
> Every attempt to give BAR memory to struct page has run into major
> trouble, IMHO, so I like that this approach avoids that.
>
> And if you don't have struct page then the only kernel object left to
> hang meta data off is the VMA itself.
>
> I
On 2019-01-30 10:44 a.m., Jason Gunthorpe wrote:
> I don't see why a special case with a VMA is really that different.
Well one *really* big difference is the VMA changes necessarily expose
specialized new functionality to userspace which has to be supported
forever and may be difficult to chang
On 2019-01-30 10:26 a.m., Christoph Hellwig wrote:
> On Wed, Jan 30, 2019 at 10:55:43AM -0500, Jerome Glisse wrote:
>> Even outside GPU driver, device driver like RDMA just want to share their
>> doorbell to other device and they do not want to see those doorbell page
>> use in direct I/O or anyt
On 2019-01-31 12:02 p.m., Jason Gunthorpe wrote:
> I still think the right direction is to build on what Logan has done -
> realize that he created a DMA-only SGL - make that a formal type of
> the kernel and provide the right set of APIs to work with this type,
> without being forced to expose s
On 2019-01-31 12:35 p.m., Jerome Glisse wrote:
> So what is this O_DIRECT thing that keep coming again and again here :)
> What is the use case ? Note that bio will always have valid struct page
> of regular memory as using PCIE BAR for filesystem is crazy (you do not
> have atomic or cache coher
| 12 ++--
> mm/hmm.c | 8 ++--
> tools/testing/nvdimm/test/iomap.c | 2 +-
> 7 files changed, 50 insertions(+), 30 deletions(-)
Looks good to me,
Reviewed-by: Logan Gunthorpe
Logan
___
dri-devel mai
On 2019-06-13 2:21 p.m., Dan Williams wrote:
> On Thu, Jun 13, 2019 at 1:18 PM Logan Gunthorpe wrote:
>>
>>
>>
>> On 2019-06-13 12:27 p.m., Dan Williams wrote:
>>> On Thu, Jun 13, 2019 at 2:43 AM Christoph Hellwig wrote:
>>>>
>>>>
On 2019-06-13 3:43 a.m., Christoph Hellwig wrote:
> Passing the actual typed structure leads to more understandable code
> vs the actual references.
Ha, ok, I originally suggested this to Dan when he introduced the
callback[1].
Reviewed-by: Logan Gunthorpe
Logan
[1]
https://lore.kern
On 2019-06-13 12:27 p.m., Dan Williams wrote:
> On Thu, Jun 13, 2019 at 2:43 AM Christoph Hellwig wrote:
>>
>> Hi Dan, Jérôme and Jason,
>>
>> below is a series that cleans up the dev_pagemap interface so that
>> it is more easily usable, which removes the need to wrap it in hmm
>> and thus allo
On 2019-06-17 6:27 a.m., Christoph Hellwig wrote:
> The functionality is identical to the one currently open coded in
> p2pdma.c.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Logan Gunthorpe
I also did a quick test with the full patch-set to ensure that the setup
and tea
On 2019-06-17 6:27 a.m., Christoph Hellwig wrote:
> diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
> index a98126ad9c3a..e083567d26ef 100644
> --- a/drivers/pci/p2pdma.c
> +++ b/drivers/pci/p2pdma.c
> @@ -100,7 +100,7 @@ static void pci_p2pdma_percpu_cleanup(struct percpu_ref
> *ref)
>
On 2019-06-26 6:27 a.m., Christoph Hellwig wrote:
> The functionality is identical to the one currently open coded in
> p2pdma.c.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Logan Gunthorpe
Also, for the P2PDMA changes in this series:
Tested-by: Logan Gunthorpe
I'v
Hi,
On 2019-02-14 2:37 p.m., Brendan Higgins wrote:
> This patch set proposes KUnit, a lightweight unit testing and mocking
> framework for the Linux kernel.
I haven't followed the entire conversation but I saw the KUnit write-up
on LWN and ended up, as an exercise, giving it a try.
I really lik
On 2019-03-21 1:13 p.m., Knut Omang wrote:
>> Nevertheless, I don't really see KTF as a real unit testing framework
>> for a number of different reasons; you pointed out some below, but I
>> think the main one being that it requires booting a real kernel on
>> actual hardware;
>
> That depends
On 2019-03-20 11:23 p.m., Knut Omang wrote:
> Testing drivers, hardware and firmware within production kernels was the use
> case that inspired KTF (Kernel Test Framework). Currently KTF is available as
> a
> standalone git repository. That's been the most efficient form for us so far,
> as we
On 2019-03-21 4:07 p.m., Brendan Higgins wrote:
> A couple of points, as for needing CONFIG_PCI; my plan to deal with
> that type of thing has been that we would add support for a KUnit/UML
> version that is just for KUnit. It would mock out the necessary bits
> to provide a fake hardware impleme
On 2022-02-06 11:32 p.m., Christoph Hellwig wrote:
> Move the check for the actual pgmap types that need the free at refcount
> one behavior into the out of line helper, and thus avoid the need to
> pull memremap.h into mm.h.
>
> Signed-off-by: Christoph Hellwig
I've noticed mm/memcontrol.c u
| 49 ++--
> 23 files changed, 90 insertions(+), 157 deletions(-)
Looks good to me. I was wondering about the location of some of this
code, so it's nice to see it cleaned up. Except for the one minor issue
I noted on patch 6, it all looks good to me. I've reviewed all the
patches and tested the series under my p2pdma series.
Reviewed-by: Logan Gunthorpe
Logan
r.
Reviewed-by: Logan Gunthorpe
> ---
> mm/memremap.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mm/memremap.c b/mm/memremap.c
> index fef5734d5e4933..e00ffcdba7b632 100644
> --- a/mm/memremap.c
> +++ b/mm/memremap.c
> @@ -452,7 +
On 2020-03-12 8:19 a.m., Jason Gunthorpe wrote:
> On Thu, Mar 12, 2020 at 03:47:29AM -0700, Christoph Hellwig wrote:
>> On Thu, Mar 12, 2020 at 11:31:35AM +0100, Christian König wrote:
>>> But how should we then deal with all the existing interfaces which already
>>> take a scatterlist/sg_table ?
On 30/11/16 09:23 AM, Jason Gunthorpe wrote:
>> Two cases I can think of are RDMA access to an NVMe device's controller
>> memory buffer,
>
> I'm not sure on the use model there..
The NVMe fabrics stuff could probably make use of this. It's an
in-kernel system to allow remote access to an NVMe
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
---
drivers/mmc/host/sdhci.c | 35 ++-
1 file changed, 30 insertions(+), 5 deletions(-)
diff --git a/drivers
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
---
drivers/mmc/host/tmio_mmc.h | 12 ++--
drivers/mmc/host/tmio_mmc_dma.c | 5 +
drivers/mmc/host/tmio_mmc_pio.c | 24
re 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
---
drivers/mmc/host/tifm_sd.c | 88 +++---
1 f
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
---
drivers/block/xen-blkfront.c | 33 +++--
1 file changed, 27 insertions(+), 6
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
Very straightforward conversion to the new function in all four spots.
Signed-off-by: Logan Gunthorpe
---
drivers/md/dm-crypt.c | 38 +-
1 file changed, 25 insertions(+), 13 deletions(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index
Straightforward conversion, but we have to WARN if unmappable
memory finds its way into the sgl.
Signed-off-by: Logan Gunthorpe
---
drivers/memstick/host/jmb38x_ms.c | 23 ++-
drivers/memstick/host/tifm_ms.c | 22 +-
2 files changed, 35 insertions
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
---
drivers/scsi/csiostor/csio_scsi.c | 54
Very straightforward conversion of three scsi drivers.
Signed-off-by: Logan Gunthorpe
---
drivers/scsi/ipr.c | 27 ++-
drivers/scsi/isci/request.c | 42 +-
drivers/scsi/pmcraid.c | 19 ---
3 files
Very straightforward conversion to the new function in two crypto
drivers.
Signed-off-by: Logan Gunthorpe
---
crypto/shash.c| 9 ++---
drivers/crypto/caam/caamalg.c | 8 +++-
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/crypto/shash.c b/crypto/shash.c
Very straightforward conversion of three scsi drivers
Signed-off-by: Logan Gunthorpe
---
drivers/scsi/arcmsr/arcmsr_hba.c | 16
drivers/scsi/ips.c | 8
drivers/scsi/megaraid.c | 9 +++--
3 files changed, 23 insertions(+), 10 deletions
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
---
drivers
, 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
---
drivers/dma-buf/dma-buf.c | 3 ++
include/linux/scatterlist.h |
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
---
drivers/nvme/target/fabrics-cmd.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers
anup set... Sorry) Though, I'm 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
Very straightforward conversion of three scsi drivers.
Signed-off-by: Logan Gunthorpe
---
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 +
drivers/scsi/mvsas/mv_sas.c
This is a straightforward conversion to the new function.
Signed-off-by: Logan Gunthorpe
---
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
index 5ff26ab..7eeed23
Straightforward conversion except there's no error path, so we WARN if
the sg_map fails.
Signed-off-by: Logan Gunthorpe
---
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
index e10624a..7f
Straightforward conversion to the new function.
Signed-off-by: Logan Gunthorpe
---
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/drivers/staging/unisys/visorhba
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
---
drivers/mmc/host/mmc_
with this driver.
Signed-off-by: Logan Gunthorpe
---
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 | 18 +++--
drivers/t
e, but 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
---
drive
This is a single straightforward conversion from kmap to sg_map.
Signed-off-by: Logan Gunthorpe
---
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/drivers/gpu/drm/i915/i915_gem.c
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 missi
aming 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
---
drivers/d
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 happil
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
>
> Acked-by: Daniel Vetter
>
> Probably
mited 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 Gunthor
ed [1] 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
Reviewed-by: Si
Thanks Stephen. Looks good to me.
Logan
On 20/04/17 08:10 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/tee/tee_shm.c:87:2: error: unknown field 'kmap_atomic' specified in
> initializer
to. I'd suggest we look
toward merging the first patch 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
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
Cc: Ulf Hansson
---
drivers/mmc/host/mmc_
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
Acked-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c | 27 ---
1 file changed, 16
This is a straightforward conversion to the new function.
Signed-off-by: Logan Gunthorpe
Cc: Sascha Sommer
Cc: Ulf Hansson
---
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
with this driver.
Signed-off-by: Logan Gunthorpe
Cc: "Nicholas A. Bellinger"
---
drivers/target/iscsi/iscsi_target.c| 29 +++---
drivers/target/target_core_rd.c| 3 +-
drivers/target/target_core_sbc.c | 103 +
Very straightforward conversion to the new function in the caam driver
and shash library.
Signed-off-by: Logan Gunthorpe
Cc: Herbert Xu
Cc: "David S. Miller"
---
crypto/shash.c| 9 ++---
drivers/crypto/caam/caamalg.c | 8 +++-
2 files changed, 9 insert
Very straightforward conversion of three scsi drivers.
Signed-off-by: Logan Gunthorpe
Cc: Brian King
Cc: Artur Paszkiewicz
---
drivers/scsi/ipr.c | 27 ++-
drivers/scsi/isci/request.c | 42 +-
drivers/scsi/pmcraid.c
Very straightforward conversion to the new function in all four spots.
Signed-off-by: Logan Gunthorpe
Cc: Alasdair Kergon
Cc: Mike Snitzer
---
drivers/md/dm-crypt.c | 39 ++-
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git a/drivers/md/dm
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
Cc: Adrian Hunter
Cc: Ulf Hansson
---
drivers/mmc/host/sdhci.c | 14 +-
1 file changed, 9
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
Cc: Johannes Thumshirn
---
drivers/scsi
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:
Very straightforward conversion of three scsi drivers.
Signed-off-by: Logan Gunthorpe
Cc: Achim Leubner
Cc: John Garry
---
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
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
Cc: Wolfram Sang
Cc: Ulf Hansson
---
drivers/mmc/host/tmio_mmc.h | 7 +--
drivers/mmc/host
Straightforward conversion to the new function.
Signed-off-by: Logan Gunthorpe
Acked-by: David Kershner
---
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
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
Cc: Lee Duncan
Cc: Chris Leech
---
drivers
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
Cc: Alex Dubov
---
drivers/memstick/host/jmb38x_ms.c | 11 ++-
drivers/memstick/host/tifm_ms.c | 11 ++-
2 files changed
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
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Konrad Rzeszutek Wilk
Cc: "Roger Pau
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
Cc: Santosh Shilimkar
Cc: "David S. Miller"
---
net/rds/ib_recv.c | 8
1 file changed, 4 i
e, but 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
Cc: Herber
re 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
Cc: Alex Dubov
Cc: Ulf Hansson
---
drivers/mmc/host
.
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
---
include/linux/scatterlist.h |
Very straightforward conversion of three scsi drivers
Signed-off-by: Logan Gunthorpe
Cc: Adaptec OEM Raid Solutions
Cc: Kashyap Desai
Cc: Sumit Saxena
Cc: Shivasharan S
---
drivers/scsi/arcmsr/arcmsr_hba.c | 16
drivers/scsi/ips.c | 8
drivers/scsi
1 - 100 of 178 matches
Mail list logo
