Re: [PATCH 1/2] drivers: uio_dmem_genirq: Use of_match_ptr() macro

On 2013/03/14 19:22, Sachin Kamat wrote: This eliminates having an #ifdef returning NULL for the case when OF is disabled. Signed-off-by: Sachin Kamat Cc: Damian Hobson-Garcia --- Thank you, Looks fine by me. Acked-by: Damian Hobson-Garcia -- To unsubscribe from this list: send the line

Re: [PATCH 0/2] Renesas IPMMU driver for sh7372

Hi Simon, On 2012/08/25 16:13, Simon Horman wrote: > On Wed, Jul 25, 2012 at 03:29:00PM +0900, Hideki EIRAKU wrote: >> This is the Renesas IPMMU driver, IOMMU API implementation and IPMMU >> device support for sh7372 (AP4EVB and Mackerel). >> >> The IPMMU module supports the MMU function and the P

[RFC PATCH 2/2] ARM: shmobile: sh7372: Change VPU UIO to uio_dmem_genirq

This allows the VPU memory to be allocated dynamically only when it is needed. Signed-off-by: Damian Hobson-Garcia --- arch/arm/mach-shmobile/setup-sh7372.c | 19 ++- 1 files changed, 14 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-shmobile/setup-sh7372.c b/arch

[RFC PATCH 1/2] Add new uio device for dynamic memory allocation

en no processes are holding the device file open, the address returned to userspace is DMA_ERROR_CODE. Signed-off-by: Damian Hobson-Garcia --- drivers/uio/Kconfig | 16 ++ drivers/uio/Makefile |1 + drivers/uio/uio_dmem_genirq.c |

[RFC PATCH 0/2] Add UIO device supporting dynamic memory allocation

The total number of dynamic and static regions combined cannot exceed MAX_UIO_MAPS. Any comments, especially with regard to exposing the dma-mapping API to userspace in this way, would be greatly appreciated. Damian Hobson-Garcia (2): Add new uio device for dynamic memory allocation ARM: shmobile

Re: [v2 PATCH 1/2] Add new uio device for dynamic memory allocation

Hi Geert, On 2012/11/04 22:20, Geert Uytterhoeven wrote: > On Tue, Sep 25, 2012 at 8:09 AM, Damian Hobson-Garcia > wrote: >> are holding the device file open, the address returned to userspace is >> DMA_ERROR_CODE. > > Only a small subset of the architectures > (a

[v2 PATCH 0/2] Add UIO device supporting dynamic memory allocation

e same was as for static regions. The total number of dynamic and static regions combined cannot exceed MAX_UIO_MAPS. Changes from v1/RFC * Add driver documentation to UIO HOWTO * Remove sh7372 specific example code Damian Hobson-Garcia (2): Add new uio device for dynamic memory alloca

[v2 PATCH 1/2] Add new uio device for dynamic memory allocation

en no processes are holding the device file open, the address returned to userspace is DMA_ERROR_CODE. Signed-off-by: Damian Hobson-Garcia --- drivers/uio/Kconfig | 16 ++ drivers/uio/Makefile |1 + drivers/uio/uio_dmem_genirq.c |

[v2 PATCH 2/2] Add uio_dmem_genirq description to UIO documentation

Signed-off-by: Damian Hobson-Garcia --- Documentation/DocBook/uio-howto.tmpl | 56 ++ 1 files changed, 56 insertions(+), 0 deletions(-) diff --git a/Documentation/DocBook/uio-howto.tmpl b/Documentation/DocBook/uio-howto.tmpl index ac3d001..db08c1a 100644 --- a

[PATCH 0/4] UIO platform device fixes

Here are a few fixes for the uio_dmem_genirq driver which allows for dynamic allocation/deallocation of UIO memory resources via the DMA-mapping API. Damian Hobson-Garcia (4): drivers: uio_dmem_genirq: Don't mix address spaces for dynamic region vaddr drivers: uio_dmem_genirq: Don&

[PATCH 2/4] drivers: uio_dmem_genirq: Don't use DMA_ERROR_CODE to indicate unmapped regions

DMA_ERROR_CODE is not defined on all architectures and is architecture specific. Instead, use the constant, ~0 to indicate unmapped regions. Reported-by: Fengguang Wu Reported-by: Geert Uytterhoeven Signed-off-by: Damian Hobson-Garcia --- Documentation/DocBook/uio-howto.tmpl |2

[PATCH 3/4] drivers: uio_dmem_genirq: Allow partial success when opening device

user space. Also deals with the case where failing to map a region after successfully allocating others would not unmap the successfully allocated regions before dying. Signed-off-by: Damian Hobson-Garcia --- drivers/uio/uio_dmem_genirq.c | 12 ++-- 1 files changed, 6 insertions(+), 6

[PATCH 4/4] drivers: uio: Only allocate new private data when probing device tree node

The same condition should be used both when allocating and freeing the driver private data. When dev.of_node is non NULL, allocate a new private data structure, otherwise use the values from the platform data. Reported-by: Fengguang Wu Signed-off-by: Damian Hobson-Garcia --- drivers/uio

[PATCH 1/4] drivers: uio_dmem_genirq: Don't mix address spaces for dynamic region vaddr

/uio_dmem_genirq.c:93:17:expected void *vaddr drivers/uio/uio_dmem_genirq.c:93:17:got void [noderef] *internal_addr Store the void * in the driver's private data instead. Reported-by: Fengguang Wu Signed-off-by: Damian Hobson-Garcia --- drivers/uio/uio_dmem_genirq.c |9 ++--- 1

[RFC/PATCH 0/4] dma-mapping: Define dma_{alloc,free}_attrs() for all archs

CONFIG_HAVE_DMA=y, but have no implementation for dma_{alloc,free}_attrs() by simply calling dma_{alloc,free}_coherent() and throwing away the attrs argument. Damian Hobson-Garcia (4): Provide default implementation for dma_{alloc,free}_attrs on arm64 Provide default implementation for dma_

[RFC/PATCH 1/4] arm64: Provide default implementation for dma_{alloc,free}_attrs

. Signed-off-by: Damian Hobson-Garcia --- arch/arm64/include/asm/dma-mapping.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm64/include/asm/dma-mapping.h b/arch/arm64/include/asm/dma-mapping.h index 9947768..65ab181 100644 --- a/arch/arm64/include/asm/dma

[RFC/PATCH 2/4] c6x: Provide default implementation for dma_{alloc,free}_attrs

. Signed-off-by: Damian Hobson-Garcia --- arch/c6x/include/asm/dma-mapping.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/c6x/include/asm/dma-mapping.h b/arch/c6x/include/asm/dma-mapping.h index 88bd0d8..8947605 100644 --- a/arch/c6x/include/asm/dma-mapping.h

[RFC/PATCH 3/4] parisc: Provide default implementation for dma_{alloc,free}_attrs

parisc. Signed-off-by: Damian Hobson-Garcia --- arch/parisc/include/asm/dma-mapping.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/parisc/include/asm/dma-mapping.h b/arch/parisc/include/asm/dma-mapping.h index 106b395..d0eae5f 100644 --- a/arch/parisc/include/asm

[RFC/PATCH 4/4] s390: Provide default implementation for dma_{alloc,free}_attrs

. Signed-off-by: Damian Hobson-Garcia --- arch/s390/include/asm/dma-mapping.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/s390/include/asm/dma-mapping.h b/arch/s390/include/asm/dma-mapping.h index 9411db65..91f7312 100644 --- a/arch/s390/include/asm/dma

Re: [RFC/PATCH 1/4] arm64: Provide default implementation for dma_{alloc, free}_attrs

Hi Lars, On 2013/04/22 15:11, Lars-Peter Clausen wrote: > On 04/22/2013 07:09 AM, Damian Hobson-Garcia wrote: >> Most architectures that define CONFIG_HAVE_DMA, have implementations for >> both dma_alloc_attrs() and dma_free_attrs(). All achitectures that do >> not define

Re: [RFC][PATCH] fs/buffer.c: Revoke LRU when trying to drop buffers

from being dropped during page migration. I've tried the patch and it seems to solve my problems, so I'm wondering if it is worth resubmitting. The discussion on the original thread seems to have faded out. Does anyone know if it was continued somewhere else? Thank you, Damian -- Damia

[PATCH] drivers: uio: Fix UIO device registration failure

: Damian Hobson-Garcia --- drivers/uio/uio.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c index c8b9262..b645c47 100644 --- a/drivers/uio/uio.c +++ b/drivers/uio/uio.c @@ -374,6 +374,7 @@ static int uio_get_minor(struct uio_device *idev

[PATCH v2 0/4] dma-mapping: Define dma_{alloc,free}_attrs() for all archs

sted (I don't have cross compilers) Cheers, Damian Damian Hobson-Garcia (4): arm64: Provide default implementation for dma_{alloc,free}_attrs c6x: Provide default implementation for dma_{alloc,free}_attrs parisc: Provide default implementation for dma_{alloc,free}_attrs s390: Provide

[PATCH v2 1/4] arm64: Provide default implementation for dma_{alloc,free}_attrs

. Signed-off-by: Damian Hobson-Garcia --- arch/arm64/include/asm/dma-mapping.h | 17 +++-- 1 files changed, 11 insertions(+), 6 deletions(-) diff --git a/arch/arm64/include/asm/dma-mapping.h b/arch/arm64/include/asm/dma-mapping.h index 9947768..6ff7b8d 100644 --- a/arch/arm64

[PATCH v2 2/4] c6x: Provide default implementation for dma_{alloc,free}_attrs

. Signed-off-by: Damian Hobson-Garcia --- arch/c6x/include/asm/dma-mapping.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/c6x/include/asm/dma-mapping.h b/arch/c6x/include/asm/dma-mapping.h index 88bd0d8..8947605 100644 --- a/arch/c6x/include/asm/dma-mapping.h

[PATCH v2 3/4] parisc: Provide default implementation for dma_{alloc,free}_attrs

parisc. Signed-off-by: Damian Hobson-Garcia --- arch/parisc/include/asm/dma-mapping.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/parisc/include/asm/dma-mapping.h b/arch/parisc/include/asm/dma-mapping.h index 106b395..d0eae5f 100644 --- a/arch/parisc/include/asm

[PATCH v2 4/4] s390: Provide default implementation for dma_{alloc,free}_attrs

. Signed-off-by: Damian Hobson-Garcia --- arch/s390/include/asm/dma-mapping.h | 17 +++-- 1 files changed, 11 insertions(+), 6 deletions(-) diff --git a/arch/s390/include/asm/dma-mapping.h b/arch/s390/include/asm/dma-mapping.h index 9411db65..3a549b6 100644 --- a/arch/s390/include

Re: [PATCH v2 0/4] dma-mapping: Define dma_{alloc,free}_attrs() for all archs

Hello, On 2013/04/30 12:01, Damian Hobson-Garcia wrote: > Most architectures that define CONFIG_HAVE_DMA=y, have implementations for > both dma_alloc_attrs() and dma_free_attrs(). All achitectures that do > not define CONFIG_HAVE_DMA also have both of these definitions provided by >

Re: [PATCH v2 0/4] dma-mapping: Define dma_{alloc,free}_attrs() for all archs

Hi Catalin, On 2013/05/22 18:47, Catalin Marinas wrote: > On Wed, May 22, 2013 at 03:37:17AM +0100, Damian Hobson-Garcia wrote: >> Hello, >> On 2013/04/30 12:01, Damian Hobson-Garcia wrote: >>> Most architectures that define CONFIG_HAVE_DMA=y, have implementations for

Re: [PATCH v2 0/4] dma-mapping: Define dma_{alloc,free}_attrs() for all archs

On 2013/05/23 18:47, Catalin Marinas wrote: > On Thu, May 23, 2013 at 03:47:13AM +0100, Damian Hobson-Garcia wrote: >> Hi Catalin, >> On 2013/05/22 18:47, Catalin Marinas wrote: >>> On Wed, May 22, 2013 at 03:37:17AM +0100, Damian Hobson-Garcia wrote: >>>> Hel

[PATCH v3 0/3] dma-mapping: Define dma_{alloc,free}_attrs() for all archs

ops->alloc(). * Indicate that these patches are compile teseted only (I don't have hardware) c6x: * Indicate that this patch is untested (I don't have a cross compiler) Cheers, Damian Damian Hobson-Garcia (3): arm64: Provide default implementation for dma_{alloc,free}_attrs

[PATCH v3 1/3] arm64: Provide default implementation for dma_{alloc,free}_attrs

. Signed-off-by: Damian Hobson-Garcia --- arch/arm64/include/asm/dma-mapping.h | 17 +++-- 1 files changed, 11 insertions(+), 6 deletions(-) diff --git a/arch/arm64/include/asm/dma-mapping.h b/arch/arm64/include/asm/dma-mapping.h index 9947768..6ff7b8d 100644 --- a/arch/arm64

[PATCH v3 2/3] c6x: Provide default implementation for dma_{alloc,free}_attrs

. Signed-off-by: Damian Hobson-Garcia Acked-by: Mark Salter --- arch/c6x/include/asm/dma-mapping.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/c6x/include/asm/dma-mapping.h b/arch/c6x/include/asm/dma-mapping.h index 88bd0d8..8947605 100644 --- a/arch/c6x/include

[PATCH v3 3/3] s390: Provide default implementation for dma_{alloc,free}_attrs

. Signed-off-by: Damian Hobson-Garcia --- arch/s390/include/asm/dma-mapping.h | 17 +++-- 1 files changed, 11 insertions(+), 6 deletions(-) diff --git a/arch/s390/include/asm/dma-mapping.h b/arch/s390/include/asm/dma-mapping.h index 9411db65..3a549b6 100644 --- a/arch/s390/include

Re: [PATCH/WIP/RFC 02/14] shmobile-iommu: Move IPMMU driver to drivers/iommu

e it might be better to treat the IPMMU like a multifuction device, with a core driver (ipmmu.c) in one location and the function implementations in their own respective directories. Does drivers/mfd sound like a good place for it? Thanks, Damian. -- Damian Hobson-Garcia IGEL Co.,Ltd http://www.igel.co

[PATCH] drivers: uio_dmem_genirq: Add mmap support for dynamic regions

Dynamic regions allocated with dma_alloc_coherent() should use dma_mmap_coherent() to perform memory mapping. Other regions are simply ioremapped, the same way as in the uio subsystem base implementation. Signed-off-by: Damian Hobson-Garcia --- drivers/uio/uio_dmem_genirq.c | 33

[PATCH v3 0/1] Generalize poll events from eventfd

Using eventfd user space can generate POLLIN/POLLOUT events but some applications may want to generate POLLPRI/POLLERR events as well. This patch submission aims to generalize the events generated by an eventfd. This is a resubmission of a patch from Feb 2013[1]. The original discussion trailed off

[PATCH v3 1/1] eventfd: implementation of EFD_MASK flag

.co.jp: Rebased, and resubmitted for Linux 4.3] Signed-off-by: Damian Hobson-Garcia --- fs/eventfd.c | 102 ++- include/linux/eventfd.h | 16 +-- include/uapi/linux/eventfd.h | 33 ++ 3 files changed, 126 inserti

Re: [PATCH v3 1/1] eventfd: implementation of EFD_MASK flag

Hello, > diff --git a/include/linux/eventfd.h b/include/linux/eventfd.h > index ff0b981..87de343 100644 > --- a/include/linux/eventfd.h > +++ b/include/linux/eventfd.h > > -/* > - * CAREFUL: Check include/uapi/asm-generic/fcntl.h when defining > - * new flags, since they might collide with O_*

Re: [PATCH v2 v3.18-rc4 1/4] drm: prime: Honour O_RDWR during prime-handle-to-fd

Hello, >On Wed, Nov 12, 2014 at 6:38 AM, Daniel Thompson >wrote: >> Currently DRM_IOCTL_PRIME_HANDLE_TO_FD rejects all flags except >> (DRM|O)_CLOEXEC making it hard for the userspace to generate a file >> descriptor that can be used by mmap(). >> >> It is easy to relax the restriction and allow

Re: [PATCH v3 1/1] eventfd: implementation of EFD_MASK flag

Hello Martin and all, I recently came across this (quite old by now) patch submission for an extension to the functionality of eventfd and I noticed that the discussion seems to have fizzled out. Is this functionality still of use for user space network protocols? It seems like it would be usabl

Re: [PATCH v3 1/1] eventfd: implementation of EFD_MASK flag

Hi Martin, On 2015-07-09 5:41 PM, Martin Sustrik wrote: > Hi Damian, > > Yes, this patch would be geneally useful for implementing stuff in user > space that otherwise would have to live in kernelspace. > > Unfortunately, I have no cycles left to pursue getting it to the > mainline. If you feel

[RFC/PATCH] Generalize poll events from eventfd

Hello all, eventfd is very useful for generating POLLIN/POLLOUT poll events from user space but some applications may want to generate POLLPRI/POLLERR events as well. This patch submission aims to generalize the events generated by an eventfd. This is a resubmission of a patch from Feb 2013[1]. Th

[PATCH] eventfd: implementation of EFD_MASK flag

From: Martin Sustrik When implementing network protocols in user space, one has to implement fake file descriptors to represent the sockets for the protocol. Polling on such fake file descriptors is a problem (poll/select/epoll accept only true file descriptors) and forces protocol implementers

Re: [PATCH] eventfd: implementation of EFD_MASK flag

Replying to my own post, but I had the following comments/questions. Martin, if you have any response to my comments I would be very happy to hear them. On 2015-08-10 2:51 PM, Damian Hobson-Garcia wrote: > From: Martin Sustrik > [snip] > > write(2): > > User is allowed to

Re: [PATCH] eventfd: implementation of EFD_MASK flag

Hi Martin, Thanks for your comments. On 2015-08-10 3:39 PM, Martin Sustrik wrote: > On 2015-08-10 08:23, Damian Hobson-Garcia wrote: >> Replying to my own post, but I had the following comments/questions. >> Martin, if you have any response to my comments I would be very happy

[PATCH v2 0/1] Generalize poll events from eventfd

Using eventfd user space can generate POLLIN/POLLOUT events but some applications may want to generate POLLPRI/POLLERR events as well. This patch submission aims to generalize the events generated by an eventfd. This is a resubmission of a patch from Feb 2013[1]. The original discussion trailed off

[PATCH v2 1/1] eventfd: implementation of EFD_MASK flag

ith EINVAL. select(2), poll(2) and similar: When polling on the eventfd marked by EFD_MASK flag, all the events specified in last written 'events' field shall be signaled. Signed-off-by: Martin Sustrik [dhobs...@igel.co.jp: Rebased, and resubmitted for Linux 4.3] Signed-off-by:

Re: [PATCH v2 1/1] eventfd: implementation of EFD_MASK flag

Hi Martin, On 2015-09-16 3:51 PM, Martin Sustrik wrote: > On 2015-09-16 08:27, Damian Hobson-Garcia wrote: >> >> Additionally, to provide a way to associate user-space state with eventfd >> object, it allows to attach user-space data to the file descriptor. > > The ab

Re: [PATCH] eventfd: implementation of EFD_MASK flag

On 2015-08-11 6:16 AM, Martin Sustrik wrote: > On 2015-08-10 10:57, Damian Hobson-Garcia wrote: >> Hi Martin, >> >> Thanks for your comments. >> >> On 2015-08-10 3:39 PM, Martin Sustrik wrote: >>> On 2015-08-10 08:23, Damian Hobson-Garcia wrote: &

Re: [PATCH v3 1/1] eventfd: implementation of EFD_MASK flag

rite(), but there is no way to signal V4L2 > events, as they are signaled via POLLPRI. > > > Thank you, > > Paul > > [1] https://libcamera.org/docs.html#id1 > > On Thu, Oct 15, 2015 at 10:42:08AM +0900, Damian Hobson-Garcia wrote: >> From: Martin Sustrik >>