[PATCH v4 1/7] drivers:hv: Lock access to hyperv_mmio resource tree

In existing code, this tree of resources is created in single-threaded code and never modified after it is created, and thus needs no locking. This patch introduces a semaphore for tree access, as other patches in this series introduce run-time modifications of this resource tree which can happen

[PATCH v4 5/7] drivers:hv: Track allocations of children of hv_vmbus in private resource tree

This patch changes vmbus_allocate_mmio() and vmbus_free_mmio() so that when child paravirtual devices allocate memory-mapped I/O space, they allocate it privately from a resource tree pointed at by hyperv_mmio and also by the public resource tree iomem_resource. This allows the region to be

[PATCH v4 2/7] drivers:hv: Make a function to free mmio regions through vmbus

This patch introduces a function that reverses everything done by vmbus_allocate_mmio(). Existing code just called release_mem_region(). Future patches in this series require a more complex sequence of actions, so this function is introduced to wrap those actions. Signed-off-by: Jake Oshins

[PATCH v4 6/7] drivers:hv: Record MMIO range in use by frame buffer

Later in the boot sequence, we need to figure out which memory ranges can be given out to various paravirtual drivers. The hyperv_fb driver should, ideally, be placed right on top of the frame buffer, without some other device getting plopped on top of this range in the meantime. Recording this

[PATCH v4 0/7] drivers:hv: Ensure that bridge windows don't overlap

This series differs from v3 in that it folds in a patch suggested by the kbuild test robot, substituting resource_size() for directly calculating the size. Hyper-V VMs expose paravirtual drivers through a mechanism called VMBus, which is managed by hv_vmbus.ko. For each parvirtual service

[PATCH v4 7/7] drivers:hv: Separate out frame buffer logic when picking MMIO range

Simplify the logic that picks MMIO ranges by pulling out the logic related to trying to lay frame buffer claim on top of where the firmware placed the frame buffer. Signed-off-by: Jake Oshins --- drivers/hv/vmbus_drv.c | 80 ++

[PATCH v4 4/7] drivers:hv: Reverse order of resources in hyperv_mmio

A patch later in this series allocates child nodes in this resource tree. For that to work, this tree needs to be sorted in ascending order. Signed-off-by: Jake Oshins --- drivers/hv/vmbus_drv.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

[PATCH v4 3/7] drivers:hv: Use new vmbus_mmio_free() from client drivers.

This patch modifies all the callers of vmbus_mmio_allocate() to call vmbus_mmio_free() instead of release_mem_region(). Signed-off-by: Jake Oshins --- drivers/pci/host/pci-hyperv.c | 14 +++--- drivers/video/fbdev/hyperv_fb.c | 4 ++-- 2 files changed, 9

[PATCH] drivers:hv: fix resource_size.cocci warnings

drivers/hv/vmbus_drv.c:1099:15-18: ERROR: Missing resource_size with fb_mmio Use resource_size function on resource object instead of explicit computation. Generated by: scripts/coccinelle/api/resource_size.cocci CC: Jake Oshins Signed-off-by: Fengguang Wu

Re: [PATCH v3 6/7] drivers:hv: Record MMIO range in use by frame buffer

Hi Jake, [auto build test WARNING on v4.6-rc1] [also build test WARNING on next-20160401] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Jake-Oshins/drivers-hv-Ensure-that-bridge-windows-don

RE: [PATCH 2/7] Drivers: hv: vmbus: Use READ_ONCE() to read variables that are volatile

> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Thursday, March 31, 2016 5:01 PM > To: KY Srinivasan > Cc: linux-ker...@vger.kernel.org; de...@linuxdriverproject.org; > o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com; >

RE: [PATCH 3/7] Drivers: hv: vmbus: Fix a bug in hv_need_to_signal_on_read()

> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Thursday, March 31, 2016 5:00 PM > To: KY Srinivasan > Cc: linux-ker...@vger.kernel.org; de...@linuxdriverproject.org; > o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com; >

[PATCH v3 4/7] drivers:hv: Reverse order of resources in hyperv_mmio

A patch later in this series allocates child nodes in this resource tree. For that to work, this tree needs to be sorted in ascending order. Signed-off-by: Jake Oshins --- drivers/hv/vmbus_drv.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

[PATCH v3 3/7] drivers:hv: Use new vmbus_mmio_free() from client drivers.

This patch modifies all the callers of vmbus_mmio_allocate() to call vmbus_mmio_free() instead of release_mem_region(). Signed-off-by: Jake Oshins --- drivers/pci/host/pci-hyperv.c | 14 +++--- drivers/video/fbdev/hyperv_fb.c | 4 ++-- 2 files changed, 9

[PATCH v3 5/7] drivers:hv: Track allocations of children of hv_vmbus in private resource tree

This patch changes vmbus_allocate_mmio() and vmbus_free_mmio() so that when child paravirtual devices allocate memory-mapped I/O space, they allocate it privately from a resource tree pointed at by hyperv_mmio and also by the public resource tree iomem_resource. This allows the region to be

[PATCH v3 2/7] drivers:hv: Make a function to free mmio regions through vmbus

This patch introduces a function that reverses everything done by vmbus_allocate_mmio(). Existing code just called release_mem_region(). Future patches in this series require a more complex sequence of actions, so this function is introduced to wrap those actions. Signed-off-by: Jake Oshins

[PATCH v3 1/7] drivers:hv: Lock access to hyperv_mmio resource tree

In existing code, this tree of resources is created in single-threaded code and never modified after it is created, and thus needs no locking. This patch introduces a semaphore for tree access, as other patches in this series introduce run-time modifications of this resource tree which can happen

[PATCH v3 7/7] drivers:hv: Separate out frame buffer logic when picking MMIO range

Simplify the logic that picks MMIO ranges by pulling out the logic related to trying to lay frame buffer claim on top of where the firmware placed the frame buffer. Signed-off-by: Jake Oshins --- drivers/hv/vmbus_drv.c | 80 ++

[PATCH v3 6/7] drivers:hv: Record MMIO range in use by frame buffer

Later in the boot sequence, we need to figure out which memory ranges can be given out to various paravirtual drivers. The hyperv_fb driver should, ideally, be placed right on top of the frame buffer, without some other device getting plopped on top of this range in the meantime. Recording this

[PATCH v3 0/7] drivers:hv: Ensure that bridge windows don't overlap

This series differs from v2 in that it reserves not only the memory in use as the UEFI frame buffer but also the off-screen memory, so that PCI devices can't reserve that, either. Hyper-V VMs expose paravirtual drivers through a mechanism called VMBus, which is managed by hv_vmbus.ko. For each

[RFC PATCH 3/3] staging: lustre: Remove typedef lnet_msg_t

Just use struct lnet_msg instead. Signed-off-by: Joe Perches --- .../staging/lustre/include/linux/lnet/lib-lnet.h | 38 ++-- .../staging/lustre/include/linux/lnet/lib-types.h | 10 +-- .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h| 6 +-

RE: [PATCH 3/7] Drivers: hv: vmbus: Fix a bug in hv_need_to_signal_on_read()

> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Thursday, March 31, 2016 5:00 PM > To: KY Srinivasan > Cc: linux-ker...@vger.kernel.org; de...@linuxdriverproject.org; > o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com; >

RE: [PATCH 1/6] Drivers: hv: kvp: fix IP Failover

> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Thursday, March 31, 2016 1:19 PM > To: Vitaly Kuznetsov > Cc: KY Srinivasan ; o...@aepfle.de; > jasow...@redhat.com; linux-ker...@vger.kernel.org;

Re: [lustre-devel] [RFC PATCH 0/3] staging: lustre: detypedef

> > I know James is working on cleaning up LNet, but I don't know if he has > > anything this would be conflicting at this moment or not. > > > > Thanks for the patches. I wonder if you are generating them automatically? > > Because it would be great if it also fixes the alignment issues > >

Re: [lustre-devel] [RFC PATCH 0/3] staging: lustre: detypedef

> > I know James is working on cleaning up LNet, but I don't know if he has > > anything this would be conflicting at this moment or not. > > > > Thanks for the patches. I wonder if you are generating them automatically? > > Because it would be great if it also fixes the alignment issues > >

Re: [lustre-devel] [RFC PATCH 0/3] staging: lustre: detypedef

> > I know James is working on cleaning up LNet, but I don't know if he has > > anything this would be conflicting at this moment or not. > > > > Thanks for the patches. I wonder if you are generating them automatically? > > Because it would be great if it also fixes the alignment issues > >

Re: [lustre-devel] [RFC PATCH 0/3] staging: lustre: detypedef

> > I know James is working on cleaning up LNet, but I don't know if he has > > anything this would be conflicting at this moment or not. > > > > Thanks for the patches. I wonder if you are generating them automatically? > > Because it would be great if it also fixes the alignment issues > >

Re: [lustre-devel] [RFC PATCH 0/3] staging: lustre: detypedef

> > I know James is working on cleaning up LNet, but I don't know if he has > > anything this would be conflicting at this moment or not. > > > > Thanks for the patches. I wonder if you are generating them automatically? > > Because it would be great if it also fixes the alignment issues > >

Re: [lustre-devel] [RFC PATCH 0/3] staging: lustre: detypede

Sorry I was seeing a email error that I thought was preventing my email being sent out. That is not the case. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [lustre-devel] [RFC PATCH 0/3] staging: lustre: detypedef

On Fri, 2016-04-01 at 19:14 +, Drokin, Oleg wrote: > On Apr 1, 2016, at 2:44 PM, Joe Perches wrote: > > On Fri, 2016-04-01 at 14:23 +, Drokin, Oleg wrote: > > > On Apr 1, 2016, at 9:02 AM, Joe Perches wrote: > > > > Question about removing lustre typedefs. > > > > > > > > Various bits of

Re: [lustre-devel] [RFC PATCH 0/3] staging: lustre: detypedef

On Fri, 2016-04-01 at 14:23 +, Drokin, Oleg wrote: > On Apr 1, 2016, at 9:02 AM, Joe Perches wrote: > > > > Question about removing lustre typedefs. > > > > Various bits of lustre code use a mix of struct foo and foo_t. > > > > When would be an appropriate time to submit patches similar to

[PATCH 1/3] staging/lustre: Fix braces {} style

From: Oleg Drokin This fixes all checkpatch form of this from the Lustre tree: CHECK: braces {} should be used on all arms of this statement Signed-off-by: Oleg Drokin --- drivers/staging/lustre/lustre/fld/fld_cache.c| 3 ++-

[PATCH 3/3] staging/lustre: Get rid of ldlm_policy_res_t typedef

From: Oleg Drokin Directly use enum ldlm_policy_res everywhere. Signed-off-by: Oleg Drokin --- drivers/staging/lustre/lustre/ldlm/ldlm_internal.h | 2 - drivers/staging/lustre/lustre/ldlm/ldlm_request.c | 49 +++--- 2 files

[PATCH 2/3] staging/lustre: Fix blank line after/before {/} style

From: Oleg Drokin This patch fixes all checkpatch occurences of CHECK: Blank lines aren't necessary after an open brace '{' CHECK: Blank lines aren't necessary before a close brace '}' in Lustre code. Signed-off-by: Oleg Drokin ---

[PATCH 0/3] A few more Lustre styel cleanups

From: Oleg Drokin More of the checkpatch warning fixes. Oleg Drokin (3): staging/lustre: Fix braces {} style staging/lustre: Fix blank line after/before {/} style staging/lustre: Get rid of ldlm_policy_res_t typedef drivers/staging/lustre/lustre/fld/fld_cache.c

Re: [lustre-devel] [RFC PATCH 0/3] staging: lustre: detypedef

On Apr 1, 2016, at 2:44 PM, Joe Perches wrote: > On Fri, 2016-04-01 at 14:23 +, Drokin, Oleg wrote: >> On Apr 1, 2016, at 9:02 AM, Joe Perches wrote: >>> >>> Question about removing lustre typedefs. >>> >>> Various bits of lustre code use a mix of struct foo and foo_t. >>> >>> When would

Re: [lustre-devel] [RFC PATCH 0/3] staging: lustre: detypedef

On Fri, 2016-04-01 at 15:58 +, Simmons, James A. wrote: > > When would be an appropriate time to submit patches similar to > > below that individually remove various typedefs from lustre code? > > > > These are pretty trivial to produce and verify so there's no > > particular hurry to do them

[PATCH] staging: iio: ad7606: use iio_device_{claim|release}_direct_mode()

Two instances are moved to the new claim/release API: In the first instance, the driver was using mlock followed by iio_buffer_enabled(). Replace that code with the new API to guarantee the device stays in direct mode. There is no change in driver behavior. In the second instance, the driver was

Re: [PATCH v5 45/50] mtd: nand: vf610: switch to mtd_ooblayout_ops

On 2016-03-30 09:15, Boris Brezillon wrote: > Implementing the mtd_ooblayout_ops interface is the new way of exposing > ECC/OOB layout to MTD users. I think I sent this already in the last revision: Tested-by: Stefan Agner Acked-by: Stefan Agner -- Stefan >

RE: [lustre-devel] [RFC PATCH 0/3] staging: lustre: detypedef

>Question about removing lustre typedefs. > >Various bits of lustre code use a mix of struct foo and foo_t. > >When would be an appropriate time to submit patches similar to >below that individually remove various typedefs from lustre code? > >These are pretty trivial to produce and verify so

Re: [lustre-devel] [RFC PATCH 0/3] staging: lustre: detypedef

On Apr 1, 2016, at 9:02 AM, Joe Perches wrote: > Question about removing lustre typedefs. > > Various bits of lustre code use a mix of struct foo and foo_t. > > When would be an appropriate time to submit patches similar to > below that individually remove various typedefs from lustre code? I

[RFC PATCH 0/3] staging: lustre: detypedef

Question about removing lustre typedefs. Various bits of lustre code use a mix of struct foo and foo_t. When would be an appropriate time to submit patches similar to below that individually remove various typedefs from lustre code? These are pretty trivial to produce and verify so there's no

[RFC PATCH 1/3] staging: lustre: Remove typedef lnet_peer_t

Just use struct lnet_peer instead. Signed-off-by: Joe Perches --- .../staging/lustre/include/linux/lnet/lib-lnet.h | 18 ++--- .../staging/lustre/include/linux/lnet/lib-types.h | 6 ++--- drivers/staging/lustre/lnet/lnet/lib-move.c| 20 +++

[RFC PATCH 2/3] staging: lustre: Remove typedef lnd_t

Just use struct lnet_lnd instead. Signed-off-by: Joe Perches --- drivers/staging/lustre/include/linux/lnet/lib-lnet.h | 6 +++--- drivers/staging/lustre/include/linux/lnet/lib-types.h | 6 +++--- drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c | 4 ++--

[PATCH 7/7] staging: wilc1000: adds a check routine when performed del_key()

This patch is adds a check routine when performed del_key(). We was find this situation while test the 'rmmod sdio'. That is received inform a .del_key cmd from cfg80211. If is not exist wep keys, must be ignore a wilc_remove_wep_key() function. Thus, adds a check routine that key length of wep.

[PATCH 3/7] staging: wilc1000: txq_thread_started: replaces a semaphore with a completion

This patch replaces a semaphore(txq_thread_started) with a completion. Struct semaphore txq_thread_started is used to signal completion of txq thread. It is better to use completion than semaphore for this case. Signed-off-by: Leo Kim --- drivers/staging/wilc1000/linux_wlan.c

[PATCH 5/7] staging: wilc1000: add set to null after release firmware

This patch add set to null after release firmware. Signed-off-by: Leo Kim --- drivers/staging/wilc1000/linux_wlan.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/staging/wilc1000/linux_wlan.c b/drivers/staging/wilc1000/linux_wlan.c index

[PATCH 6/7] staging: wilc1000: adds a cfg80211_disconnected() function

This patch is adds a cfg80211_disconnected() when connection is lost already. We was find this situation while test the 'rmmod sdio'. SDIO remove function are include both remove mac_close and unregister net_device. That is received one more a disconnect cmd from cfg80211. Driver was already

[PATCH 1/7] staging: wilc1000: changes logic when happened mq_send fail

This patch changes logic when happened mq_send fail. The check as a result value that mq_send fail. But, regardless of the result value then perform a semaphore up. That is an occur that semaphore locking. Add to 'else' routine and move to 'else' position a semaphore up. Signed-off-by: Leo Kim

[PATCH 4/7] staging: wilc1000: removes unnecessary test code

This patch removes unnecessary test code that mac address hardcoding setting. This test code is support to old firmware. Signed-off-by: Leo Kim --- drivers/staging/wilc1000/linux_wlan.c | 9 - 1 file changed, 9 deletions(-) diff --git

[PATCH 2/7] staging: wilc1000: removes duplicate del_timer_sync

This patch removes del_timer_sync(_rssi) which was already performed this action. Signed-off-by: Leo Kim --- drivers/staging/wilc1000/host_interface.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/wilc1000/host_interface.c

[PATCH 2/2] staging: dgnc: fix CamelCase in dgnc_tty.c

fix checkpatch.pl warning about 'Avoid CamelCase' Signed-off-by: Daeseok Youn --- drivers/staging/dgnc/dgnc_tty.c | 2 +- drivers/staging/dgnc/digi.h | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/dgnc/dgnc_tty.c

[PATCH 1/2] staging: dgnc: remove too many traverse pointer

The "ch->ch_bd" is already assined to "bd" but this is only for checking null or MAGIC number. in the dgnc_tty_ioctl function, bd can be used for referencing to board_ops structure. Signed-off-by: Daeseok Youn --- drivers/staging/dgnc/dgnc_tty.c | 37