Just try to set a 64-bit DMA mask first and retry with the smaller dma_mask
if dma_set_mask failed.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_ttm.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
b
This ensures the dma mask that is supported by the driver is recorded
in the device structure.
Signed-off-by: Christoph Hellwig
---
drivers/media/pci/netup_unidvb/netup_unidvb_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/pci/netup_unidvb
This ensures the dma mask that is supported by the driver is recorded
in the device structure.
Signed-off-by: Christoph Hellwig
---
drivers/tty/serial/mpsc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/mpsc.c b/drivers/tty/serial/mpsc.c
index 82bb6d1
This ensures the dma mask that is supported by the driver is recorded
in the device structure.
Signed-off-by: Christoph Hellwig
---
drivers/media/pci/cx23885/cx23885-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/pci/cx23885/cx23885-core.c
b/drivers
This ensures the dma mask that is supported by the driver is recorded
in the device structure.
Signed-off-by: Christoph Hellwig
---
drivers/media/pci/cx25821/cx25821-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/pci/cx25821/cx25821-core.c
b/drivers
This ensures the dma mask that is supported by the driver is recorded
in the device structure.
Signed-off-by: Christoph Hellwig
---
drivers/media/pci/saa7134/saa7134-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/pci/saa7134/saa7134-core.c
b/drivers
This ensures the dma mask that is supported by the driver is recorded
in the device structure.
Signed-off-by: Christoph Hellwig
---
drivers/media/pci/cx88/cx88-alsa.c | 2 +-
drivers/media/pci/cx88/cx88-mpeg.c | 2 +-
drivers/media/pci/cx88/cx88-video.c | 2 +-
3 files changed, 3 insertions
All driver should be using dma_set_mask / pci_set_dma_mask to try
to set the dma mask instead of just querying it. Without that some
iommu implementations may not work.
pci_dma_supported is removed entirely, but dma_supported stays for
dma_ops implementations for now.
--
To unsubscribe from this
This ensures the dma mask that is supported by the driver is recorded
in the device structure.
Signed-off-by: Christoph Hellwig
---
drivers/media/pci/tw68/tw68-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/pci/tw68/tw68-core.c
b/drivers/media/pci/tw68
This ensures the dma mask that is supported by the driver is recorded
in the device structure.
Signed-off-by: Christoph Hellwig
---
drivers/media/pci/saa7164/saa7164-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/pci/saa7164/saa7164-core.c
b/drivers
This ensures the dma mask that is supported by the driver is recorded
in the device structure.
Signed-off-by: Christoph Hellwig
---
drivers/net/ethernet/amd/pcnet32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/amd/pcnet32.c
b/drivers/net/ethernet
On Fri, Oct 09, 2015 at 04:19:57PM -0500, Felipe Balbi wrote:
> > Signed-off-by: Christoph Hellwig
> > Reviewed-by: Andrzej Pietrasiewicz
>
> I suppose this depends on other fs/configfs changes ?
The whole series should be applied in order, but doesn't have any
ot
On Fri, Oct 09, 2015 at 04:05:17PM -0500, Felipe Balbi wrote:
> Pratyush Anand writes:
>
> > On Sat, Oct 3, 2015 at 7:02 PM, Christoph Hellwig wrote:
> >> Signed-off-by: Christoph Hellwig
> >
> > Acked-by: Pratyush Anand
>
> I don't seem to have
On Fri, Oct 09, 2015 at 04:37:51PM -0500, Felipe Balbi wrote:
> For reference, I'm fine if you guys take all patches through FS
> tree. Another option is waiting for dependencies to be merged in v4.4,
> and the gadget changes merge in v4.5, whatever works.
I'd prefer to take them all in one go. I
On Mon, Oct 05, 2015 at 02:37:05PM -0700, Andrew Morton wrote:
> > This series consolidates the code to implement configfs attributes
> > by providing the ->show and ->store method in common code and using
> > container_of in the methods to access the containing structure.
> >
> > This reduces sou
On Tue, Oct 20, 2015 at 02:32:32PM +0200, Andrzej Pietrasiewicz wrote:
> From: Krzysztof Opasiak
>
> This change is necessary for the SCSI target usb gadget composed with
> configfs. In this case configfs will be used for two different purposes:
> to compose a usb gadget and to configure the targ
Hi Andrzej,
please find a way to share code between the two depend function. And
also drop the duplicate undepend version and just stop passing the
unused subsystem argument. Not only do we not keep unused argument in
Linux in general, but in this case it's also really useful for the new
API.
--
On Thu, Oct 22, 2015 at 03:55:45PM -0700, Bart Van Assche wrote:
> Avoid that building with W=1 triggers compiler warnings about
> set-but-not-used variables.
Looks good,
Reviewed-by: Christoph Hellwig
--
To unsubscribe from this list: send the line "unsubscribe linux-usb"
On Mon, Nov 16, 2015 at 01:29:58PM -0500, Alan Stern wrote:
> Allocating memory pages that match the device's DMA mask, for
> use as I/O buffers, and locking them so their physical
> addresses don't change (and they don't get paged out);
>
> Mapping those pages into a use
On Mon, Nov 16, 2015 at 08:03:12PM +0100, Steinar H. Gunderson wrote:
> The original use case: DVB capture on embedded devices.
>
> My use case: USB3 uncompressed HD video capture (from multiple cards).
>
> Both of these hit (beyond the speed boost from zerocopy) the problem that
> as time goes b
On Mon, Nov 16, 2015 at 03:22:06PM -0500, Alan Stern wrote:
> In other words, you're suggesting we do this:
>
> Check that userspace requested zerocopy (otherwise the user
> program might try to access other data stored in the same cache
> lines as the buffer while the I/O is i
On Tue, Nov 17, 2015 at 02:07:58PM -0500, Alan Stern wrote:
> If we really want to do zerocopy I/O then we should not use a bounce
> buffer. But the only way to avoid bounce buffers may be to give user
> programs a way of allocating memory pages below 4 GB, because lots of
> USB hardware can on
Hi Mian,
sorry for the bug, the fix looks correct.
Reviewed-by: Christoph Hellwig
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
> @@ -136,6 +137,10 @@ void *hcd_buffer_alloc(
> if (size <= pool_max[i])
> return dma_pool_alloc(hcd->pool[i], mem_flags, dma);
> }
> +
> + if (hcd->driver->flags & HCD_LOCAL_MEM)
> + return gen_pool_dma_alloc(hcd->localmem_pool, size, dma)
On Wed, May 15, 2019 at 09:57:12AM +, Laurentiu Tudor wrote:
> Glad I could help. On the remoteproc_virtio.c case, I had a cursory look
> and found out that the dma_declare_coherent_memory() usage was
> introduced quite recently, by this patch:
> https://git.kernel.org/pub/scm/linux/kernel/gi
Looks good:
Reviewed-by: Christoph Hellwig
On Thu, Aug 08, 2019 at 10:46:36AM +0200, yvahkhfo.1df7f...@hashmail.org wrote:
> --- a/drivers/usb/core/devio.c
> +++ b/drivers/usb/core/devio.c
> @@ -238,9 +238,14 @@ static int usbdev_mmap(struct file *file, struct
> vm_area_struct *vma)
> usbm->vma_use_count = 1;
> INIT_LIST_HEAD(&
On Thu, Aug 08, 2019 at 09:10:15AM -0700, Christoph Hellwig wrote:
> On Thu, Aug 08, 2019 at 10:46:36AM +0200, yvahkhfo.1df7f...@hashmail.org
> wrote:
> > --- a/drivers/usb/core/devio.c
> > +++ b/drivers/usb/core/devio.c
> > @@ -238,9 +238,14 @@ static int usbdev_mmap(s
Thanks for doing this! The odd platforms have always been very
confusing.
> diff --git a/arch/arm/mach-omap1/include/mach/omap1510.h
> b/arch/arm/mach-omap1/include/mach/omap1510.h
> index 3d235244bf5c..7af9c0c7c5ab 100644
> --- a/arch/arm/mach-omap1/include/mach/omap1510.h
> +++ b/arch/arm/mach
Hi all,
this is another attempt to make sure the dma_mask pointer is always
initialized for platform devices. Not doing so lead to lots of
boilerplate code, and makes platform devices different from all our
major busses like PCI where we always set up a dma_mask. In the long
run this should also
cated.
Signed-off-by: Christoph Hellwig
---
drivers/base/platform.c | 15 +--
include/linux/platform_device.h | 1 +
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index ec974ba9c0c4..b216fcb0a8af 100644
If the HCD provides a localmem pool we will never use the DMA pools, so
don't create them.
Fixes: b0310c2f09bb ("USB: use genalloc for USB HCs with local memory")
Signed-off-by: Christoph Hellwig
---
drivers/usb/core/buffer.c | 6 +++---
1 file changed, 3 insertions(+), 3 del
a helper in hcd.h that checks this flag as well as the
CONFIG_HAS_DMA to simplify the caller a bit.
Signed-off-by: Christoph Hellwig
---
drivers/usb/core/buffer.c | 10 +++---
drivers/usb/core/hcd.c| 4 ++--
drivers/usb/dwc2/hcd.c| 2 +-
include/linux/usb.h | 2 +-
include
igned-off-by: Christoph Hellwig
---
drivers/staging/octeon-usb/octeon-hcd.c | 2 +-
drivers/usb/core/hcd.c | 1 -
drivers/usb/dwc2/hcd.c | 6 +++---
drivers/usb/host/ehci-grlib.c | 2 +-
drivers/usb/host/ehci-hcd.c | 2 +-
drivers/usb/host
No users left.
Signed-off-by: Christoph Hellwig
---
include/linux/dma-mapping.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index f7d1eea32c78..14702e2d6fa8 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma
Now that we have an explicit HCD_DMA flag, there is not need to override
these methods.
Signed-off-by: Christoph Hellwig
---
drivers/usb/host/max3421-hcd.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/drivers/usb/host/max3421-hcd.c b/drivers/usb/host/max3421-hcd.c
index
> diff --git a/drivers/usb/host/ehci-ppc-of.c b/drivers/usb/host/ehci-ppc-of.c
> index 576f7d79ad4e..9d17e0695e35 100644
> --- a/drivers/usb/host/ehci-ppc-of.c
> +++ b/drivers/usb/host/ehci-ppc-of.c
> @@ -31,7 +31,7 @@ static const struct hc_driver ehci_ppc_of_hc_driver = {
>* generic hardw
Thanks Geert,
applied to the dma-mapping tree for 4.17.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Apr 05, 2018 at 09:19:28AM +0200, Lars-Peter Clausen wrote:
> On 04/05/2018 08:31 AM, Kees Cook wrote:
> > On Wed, Apr 4, 2018 at 3:31 AM, Greg KH wrote:
> >> Lars-Peter Clausen (2):
> >> usb: gadget: ffs: Execute copy_to_user() with USER_DS set
> >
> > https://git.kernel.org/linus/
USB host controllers now must handle highmem, so we can get rid of bounce
buffering highmem pages in the block layer.
Signed-off-by: Christoph Hellwig
---
drivers/usb/storage/scsiglue.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb
On Sun, Apr 15, 2018 at 11:24:11AM -0400, Alan Stern wrote:
> On Sun, 15 Apr 2018, Christoph Hellwig wrote:
>
> > USB host controllers now must handle highmem, so we can get rid of bounce
> > buffering highmem pages in the block layer.
>
> Sorry, I don't quite unders
On Fri, Apr 27, 2018 at 10:09:17AM -0400, Alan Stern wrote:
> On Fri, 27 Apr 2018, Christoph Hellwig wrote:
>
> > On Sun, Apr 15, 2018 at 11:24:11AM -0400, Alan Stern wrote:
> > > On Sun, 15 Apr 2018, Christoph Hellwig wrote:
> > >
> > > > USB host cont
>
> Now we have 9 const instances of the config_item_type structure that are
> identical, with only the .ct_owner field set. Should they be all merged into
> a
> single structure ?
I think that's a good idea.
But I'm about to slurp up this whole series into my tree, how about making
that an i
On Sat, Mar 03, 2018 at 07:19:06PM +0100, Fredrik Noring wrote:
> Christoph, Alan,
>
> > If it is allocating / freeing this memory all the time in the hot path
> > it should really use a dma pool (see include/ilinux/dmapool.h).
> > The dma coherent APIs aren't really built for being called in the
On Tue, Mar 13, 2018 at 12:11:49PM +, Robin Murphy wrote:
> Taking a step back, though, provided the original rationale about
> dma_declare_coherent_memory() is still valid, I wonder if we should simply
> permit the USB code to call dma_{alloc,free}_from_dev_coherent() directly
> here instea
On Wed, Mar 14, 2018 at 05:43:46PM +, Robin Murphy wrote:
>> Looking back I don't really understand why we even indirect the "classic"
>> per-device dma_declare_coherent_memory use case through the DMA API.
>
> It certainly makes sense for devices which can exist in both shared-memory
> and de
On Thu, Mar 15, 2018 at 11:42:25AM +0100, Arnd Bergmann wrote:
> Is anyone producing a chip that includes enough of the Privileged ISA spec
> to have things like system calls, but not the MMU parts?
Various SiFive SOCs seem to support M and U mode, but no S mode or
iommu. That should be enough fo
Use the modern API to request MSI or MSI-X interrupts, which allows us to
get rid of the msix_entries array, as well as cleaning up the cleanup
code.
Signed-off-by: Christoph Hellwig
---
drivers/usb/host/xhci.c | 99 ++---
drivers/usb/host/xhci.h | 1
On Fri, May 05, 2017 at 10:06:06AM +0300, Amir Goldstein wrote:
> I much rather that you sort out uuid helpers in a way that will
> satisfy the filesystem
> needs (just provide the helpers don't need to convert filesystems code).
Yeah.
> IMO, you should acknowledge that the common use case for fi
On Fri, May 05, 2017 at 12:50:31PM +0300, Amir Goldstein wrote:
> To complete the picture for folks not cc'ed on my patches,
> xfs use case suggests there is also justification for the additional helpers:
>
> uuid_is_null() / uuid_equal()
> guid_is_null() / guid_equal()
The is_null is useful and
On Fri, May 19, 2017 at 08:37:21AM -0400, Steven Rostedt wrote:
> ktest config bisect ended with:
>
> ***
> Found bad config: CONFIG_PCI_MSI
> ***
Oh, that's interesting. I think there's been a bug in the !CONFIG_PCI_MSI
fal
On Sat, May 20, 2017 at 09:49:56AM -0700, Linus Torvalds wrote:
> Side note: why is it doing that " > 1" check, when any value _other_
> than 1 is wrong?
It's the same effect, so either one is fine with me.
> Also, to match the non-MSI implementation, wouldn't it be nicer to
> just write it that
On Wed, Jul 12, 2017 at 12:10:02PM -0400, Alan Stern wrote:
> This is pretty conclusive. The problem comes about because
> usb_stor_control_thread() calls scsi_mq_done() while holding
> shost->host_lock, and then scsi_eh_scmd_add() tries to acquire that
> same lock.
>
> I don't know why this didn
On Thu, Jul 13, 2017 at 01:00:29PM -0400, Alan Stern wrote:
> All right. In the meantime, changing usb-storage won't hurt.
> Arthur, can you test the patch below?
Do you plan to send this fix to Greg for 4.13-rc?
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body
I think the root problem is that the code added by
" of/acpi: Configure dma operations at probe time for platform/amba/pci bus
devices"
is completely bogus and needs to be reverted. We can't simply iterate
over all devices in the system and set up dma for them. We'll need
to ask the firmware / O
Please don't introduce new DMA_ATTR_NON_CONSISTENT users, it is
a rather horrible interface, and I plan to kill it off rather sooner
than later. I plan to post some patches for a better interface
that can reuse the normal dma_sync_single_* interfaces for ownership
transfers. I can happily include
> + dma_sync_single_for_cpu(&urb->dev->dev, urb->transfer_dma,
> + urb->transfer_buffer_length, DMA_FROM_DEVICE);
You can't ue dma_sync_single_for_cpu on non-coherent dma buffers,
which is one of the major issues with them.
On Thu, Aug 30, 2018 at 07:11:35PM -0300, Ezequiel Garcia wrote:
> On Thu, 2018-08-30 at 10:58 -0700, Christoph Hellwig wrote:
> > Please don't introduce new DMA_ATTR_NON_CONSISTENT users, it is
> > a rather horrible interface, and I plan to kill it off rather sooner
> &
No users of this type anywhere in the tree.
Signed-off-by: Christoph Hellwig
---
include/linux/usb/hcd.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index 97e2ddec18b1..7dc3a411bece 100644
--- a/include/linux/usb/hcd.h
+++ b/include
On Wed, Jan 23, 2019 at 11:10:13AM -0800, Bart Van Assche wrote:
> This patch does not change any functionality but reduces the size of
> struct scsi_cmnd.
This looks sensible, but please do it without adding more pointless
wrappers first, just use the field directly.
On Wed, Jan 30, 2019 at 03:01:54PM +0800, Hanjun Guo wrote:
> This is the RFC version, I'm not sure this is the best solution,
> comments are warmly welcomed.
>
> Thanks
> Hanjun
>
> drivers/usb/core/hcd-pci.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/usb/core/hcd-pci
x27;t in interrupt context or under a lock.
Signed-off-by: Christoph Hellwig
---
drivers/net/ethernet/sgi/meth.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/sgi/meth.c b/drivers/net/ethernet/sgi/meth.c
index 0e1b7e9
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
sound/mips/hal2.c | 31
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/usb/gadget/udc/fotg210-udc.c | 7 ---
1 file
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/parport/parport_ip32.c | 18
dma_map_single already transfers ownership to the device.
Signed-off-by: Christoph Hellwig
---
drivers/usb/gadget/udc/fotg210-udc.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/usb/gadget/udc/fotg210-udc.c
b/drivers/usb/gadget/udc/fotg210-udc.c
index bc6abaea907d
for another time.
Signed-off-by: Christoph Hellwig
---
drivers/net/ethernet/marvell/pxa168_eth.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/marvell/pxa168_eth.c
b/drivers/net/ethernet/marvell/pxa168_eth.c
index f8a6d6e3cb7a..35f2142aac5e
time.
Signed-off-by: Christoph Hellwig
---
drivers/net/ethernet/lantiq_etop.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/lantiq_etop.c
b/drivers/net/ethernet/lantiq_etop.c
index 32ac9045cdae..f9bb890733b5 100644
--- a/drivers/net/ethernet
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/net/ethernet/smsc/smc911x.c | 4 ++--
1 file
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Also use the proper Kconfig symbol to check for DMA API availability.
Signed-off-by: Christoph
We still have a few drivers which pass a NULL struct device pointer
to DMA API functions, which generally is a bad idea as the API
implementations rely on the device not only for ops selection, but
also the dma mask and various other attributes.
This series contains all easy conversions to pass a
Just like we do for all other DMA operations.
Signed-off-by: Christoph Hellwig
---
drivers/video/fbdev/pxa3xx-gcu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/pxa3xx-gcu.c b/drivers/video/fbdev/pxa3xx-gcu.c
index 69cfb337c857..047a2fa4b87e 100644
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/net/ethernet/amd/au1000_eth.c | 6 +++---
1 file
gbefb uses managed resources, so it should do the same for DMA
allocations.
Signed-off-by: Christoph Hellwig
---
drivers/video/fbdev/gbefb.c | 24
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/video/fbdev/gbefb.c b/drivers/video/fbdev/gbefb.c
the code to sort out.
Signed-off-by: Christoph Hellwig
---
arch/mips/lantiq/xway/vmmc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/mips/lantiq/xway/vmmc.c b/arch/mips/lantiq/xway/vmmc.c
index 577ec81b557d..3deab9a77718 100644
--- a/arch/mips/lantiq/xway/vmmc.c
++
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/video/fbdev/da8xx-fb.c | 13 +++--
1
treat this allocation as a normal kernel one.
Signed-off-by: Christoph Hellwig
---
sound/mips/sgio2audio.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/sound/mips/sgio2audio.c b/sound/mips/sgio2audio.c
index 3ec9391a4736..53a4ee01c522 100644
--- a/sound/mips
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/net/ethernet/moxa/moxart_ether.c | 11
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/dma/imx-sdma.c | 10 +-
1 file changed
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/net/ethernet/cadence/macb_main.c | 8
1
On Fri, Feb 01, 2019 at 02:12:45PM +0100, Takashi Iwai wrote:
> Shall I take this one through sound git tree or all through yours?
Feel free to merge the sound bits through your tree!
On Fri, Feb 01, 2019 at 03:19:41PM +0200, Felipe Balbi wrote:
> Christoph Hellwig writes:
>
> > dma_map_single already transfers ownership to the device.
> >
> > Signed-off-by: Christoph Hellwig
>
> Do you want me to take the USB bits or will you take the entire s
lls. This looks good to me:
Reviewed-by: Christoph Hellwig
On Fri, Feb 01, 2019 at 01:53:09PM +, Robin Murphy wrote:
>> #define LOW_WATER_MARK 100
>> #define HIGH_WATER_MARK (LOW_WATER_MARK*5)
>> -#ifdef CONFIG_UML
>> +#ifdef CONFIG_HAS_DMA
>
> #ifndef, surely?
Indeed.
On Fri, Feb 01, 2019 at 02:14:34PM +, Robin Murphy wrote:
> And equivalently for rxdma here. However, given that this all seems only
> relevant to antique ARCH_PXA platforms which are presumably managing to
> work as-is, it's probably not worth tinkering too much. I'd just stick a
> note in
On Sat, Feb 02, 2019 at 03:41:21PM +0530, Vinod Koul wrote:
> On 01-02-19, 09:47, Christoph Hellwig wrote:
> > The DMA API generally relies on a struct device to work properly, and
> > only barely works without one for legacy reasons. Pass the easily
> > available s
On Fri, Feb 01, 2019 at 05:10:26PM +0100, Christoph Hellwig wrote:
> On Fri, Feb 01, 2019 at 03:19:41PM +0200, Felipe Balbi wrote:
> > Christoph Hellwig writes:
> >
> > > dma_map_single already transfers ownership to the device.
> > >
> > > Signed-off-b
On Thu, Feb 07, 2019 at 11:29:14PM +, Paul Burton wrote:
> Would you like this to go through the MIPS tree or elsewhere? If the
> latter:
>
> Acked-by: Paul Burton
Please pick it up through the mips tree!
FYI, I think my
"usb: add a HCD_DMA flag instead of guestimating DMA capabilities"
is the proper core fix for what your patch 1 works around, as the USB
core should not assume DMA capabilities based on the presence of a DMA
mask.
On Thu, Aug 15, 2019 at 03:23:18PM +0200, Greg Kroah-Hartman wrote:
> I've taken the first 2 patches for 5.3-final. Given that patch 3 needs
> to be fixed, I'll wait for a respin of these before considering them.
I have a respun version ready, but I'd really like to hear some
comments from usb de
On Wed, Aug 14, 2019 at 04:49:13PM +0100, Robin Murphy wrote:
>> because we have to support platform_device structures that are
>> statically allocated.
>
> This would be a good point to also get rid of the long-standing bodge in
> platform_device_register_full().
platform_device_register_full lo
On Thu, Aug 15, 2019 at 03:03:25PM +0200, Greg Kroah-Hartman wrote:
> > --- a/include/linux/platform_device.h
> > +++ b/include/linux/platform_device.h
> > @@ -24,6 +24,7 @@ struct platform_device {
> > int id;
> > boolid_auto;
> > struct device dev;
> > + u6
Hi all,
this is another attempt to make sure the dma_mask pointer is always
initialized for platform devices. Not doing so lead to lots of
boilerplate code, and makes platform devices different from all our
major busses like PCI where we always set up a dma_mask. In the long
run this should also
a helper in hcd.h that checks this flag as well as the
CONFIG_HAS_DMA to simplify the caller a bit.
Signed-off-by: Christoph Hellwig
---
drivers/usb/core/buffer.c | 10 +++---
drivers/usb/core/hcd.c| 4 ++--
drivers/usb/dwc2/hcd.c| 2 +-
include/linux/usb.h | 2 +-
include
If the HCD provides a localmem pool we will never use the DMA pools, so
don't create them.
Fixes: b0310c2f09bb ("USB: use genalloc for USB HCs with local memory")
Signed-off-by: Christoph Hellwig
---
drivers/usb/core/buffer.c | 6 +++---
1 file changed, 3 insertions(+), 3 del
evice structures that are
statically allocated.
Signed-off-by: Christoph Hellwig
---
arch/m68k/kernel/dma.c | 9 ---
arch/powerpc/kernel/setup-common.c | 6 -
arch/sh/boards/mach-ap325rxa/setup.c | 1 -
arch/sh/boards/mach-ecovec24/setup.c | 2 --
arch/sh/boards/mach-kf
Now that we have an explicit HCD_DMA flag, there is not need to override
these methods.
Signed-off-by: Christoph Hellwig
---
drivers/usb/host/max3421-hcd.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/drivers/usb/host/max3421-hcd.c b/drivers/usb/host/max3421-hcd.c
index
igned-off-by: Christoph Hellwig
---
drivers/staging/octeon-usb/octeon-hcd.c | 2 +-
drivers/usb/core/hcd.c | 1 -
drivers/usb/dwc2/hcd.c | 6 +++---
drivers/usb/host/ehci-grlib.c | 2 +-
drivers/usb/host/ehci-hcd.c | 2 +-
drivers/usb/host
No users left.
Signed-off-by: Christoph Hellwig
---
include/linux/dma-mapping.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index f7d1eea32c78..14702e2d6fa8 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma
On Wed, Aug 21, 2019 at 12:49:25PM +0100, Matthias Maennich wrote:
> Modules using these symbols are required to explicitly import the
> namespace. This patch was generated with the following steps and serves
> as a reference to use the symbol namespace feature:
>
> 1) Define DEFAULT_SYMBOL_NAMES
101 - 200 of 202 matches
Mail list logo
