Re: [PATCH v2] staging: Convert to using %pOFn instead of device_node.name

On Wed, 2018-09-12 at 15:26 -0500, Rob Herring wrote: > A problem with MAINTAINERS is there is no way to tell who applies > patches for a given path vs. anyone else listed. try the --scm option ___ devel mailing list de...@linuxdriverproject.org

[PATCH 4/6] uio: introduce UIO_MEM_IOVA

Introduce the concept of mapping physical memory locations that are normal memory. The new type UIO_MEM_IOVA are similar to existing UIO_MEM_PHYS but the backing memory is not marked as uncached. Also, indent related switch to the currently used style. Signed-off-by: Stephen Hemminger ---

[PATCH 6/6] uio_hv_generic: defer opening vmbus until first use

This fixes two design flaws in hv_uio_generic. Since hv_uio_probe is called from vmbus_probe with lock held it potentially can cause sleep in an atomic section because vmbus_open will wait for response from host. The hv_uio_generic driver could not handle applications exiting and restarting

[PATCH 0/6] fix Hyper-V uio restart

This set of patches fixes the problem where DPDK applications using hv_uio_generic driver can not be successfully restarted. In order to get this working it required small change to uio to allow for mapping without no-cache. And refactoring of how ring buffer is setup in vmbus code. It could be

[PATCH 3/6] vmbus: split ring buffer allocation from open

The UIO driver needs the ring buffer to be persistent(reused) across open/close. Split the allocation and setup of ring buffer out of vmbus_open. For normal usage vmbus_open/vmbus_close there are no changes; only impacts uio_hv_generic which needs to keep ring buffer memory and reuse when

[PATCH 2/6] vmbus: keep pointer to ring buffer page

Avoid going from struct page to virt address (and back) by just keeping pointer to the allocated pages instead of virt address. Signed-off-by: Stephen Hemminger --- drivers/hv/channel.c | 20 +--- drivers/uio/uio_hv_generic.c | 5 +++-- include/linux/hyperv.h | 2

[PATCH 1/6] vmbus: pass channel to hv_process_channel_removal

Rather than passing relid and then looking up the channel. Pass the channel directly, since caller already knows it. Signed-off-by: Stephen Hemminger --- drivers/hv/channel.c | 3 +-- drivers/hv/channel_mgmt.c | 17 + drivers/hv/vmbus_drv.c| 3 +--

[PATCH 5/6] hv_uio_generic: map ringbuffer phys addr

The ring buffer is contiguous IOVA and is mapped via phys addr for sysfs file. Use same method for the UIO mapping. Signed-off-by: Stephen Hemminger --- drivers/uio/uio_hv_generic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/uio/uio_hv_generic.c

Re: [PATCH v2] staging: Convert to using %pOFn instead of device_node.name

On Thu, Sep 13, 2018 at 3:45 PM Joe Perches wrote: > > On Wed, 2018-09-12 at 15:26 -0500, Rob Herring wrote: > > A problem with MAINTAINERS is there is no way to tell who applies > > patches for a given path vs. anyone else listed. > > try the --scm option That kind of helps if the maintainer

[PATCH] staging: rtl8188eu: remove code that is valid only for 5 GHz

Remove code that is used only for 5 GHz. This addresses the below TODO item: - find and remove remaining code valid only for 5 GHz. Most of the obvious ones have been removed, but things like channel > 14 still exist. Signed-off-by: Robert Węcławski ---

Re: [PATCH v4] staging: erofs: use explicit unsigned int type

Hi Thomas, ping... On 2018/9/12 14:21, Gao Xiang wrote: > Hi Thomas, > > On 2018/9/11 3:41, Thomas Weißschuh wrote: >> Hi Chao, >> >> On Mon, 2018-09-10T23:59+0800, Chao Yu wrote: >>> [...] > I was not aware of this tree and worked off of staging / next. > A patch is attached to this

Re: [PATCH v8 0/4] gpiolib: speed up GPIO array processing

On Wed, Sep 5, 2018 at 11:49 PM Janusz Krzysztofik wrote: > The goal is to boost performance of get/set array functions while > processing GPIO arrays which represent pins of a signle chip in > hardware order. If resulting performance is close to PIO, GPIO API > can be used for data I/O without