[PATCH] staging: ks7010: Replace mdelay with usleep_range in ks7010_upload_firmware

[Jia-Ju Bai]

ks7010_upload_firmware() is never called in atomic context.

The call chain ending up at ks7010_upload_firmware() is:
[1] ks7010_upload_firmware() <- ks7010_sdio_probe()

ks7010_sdio_probe() is set as ".probe" in struct sdio_driver.
This function is not called in atomic context.

Despite never getting called from atomic context, ks7010_upload_firmware()
calls mdelay() to busily wait.
This is not necessary and can be replaced with usleep_range() to
avoid busy waiting.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

Signed-off-by: Jia-Ju Bai 
---
 drivers/staging/ks7010/ks7010_sdio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/ks7010/ks7010_sdio.c 
b/drivers/staging/ks7010/ks7010_sdio.c
index 8cfdff1..8d7bc26 100644
--- a/drivers/staging/ks7010/ks7010_sdio.c
+++ b/drivers/staging/ks7010/ks7010_sdio.c
@@ -719,7 +719,7 @@ static int ks7010_upload_firmware(struct ks_sdio_card *card)
 
/* Firmware running check */
for (n = 0; n < 50; ++n) {
-   mdelay(10); /* wait_ms(10); */
+   usleep_range(1, 11000); /* wait_ms(10); */
ret = ks7010_sdio_readb(priv, GCR_A, );
if (ret)
goto release_firmware;
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 1/3] resource: Use list_head to link resource sibling

[Baoquan He]

Hi Rob,

Thanks a lot for looking into this and involve Nico to this thread!

On 04/09/18 at 09:49am, Rob Herring wrote:
> +Nico who has been working on tinification of the kernel.
> 
> On Mon, Apr 9, 2018 at 4:08 AM, Baoquan He  wrote:
> > The struct resource uses singly linked list to link siblings. It's not
> > easy to do reverse iteration on sibling list. So replace it with list_head.
> 
> Why is reverse iteration needed?

This is the explanation I made when Andrew helped to review the v1 post:
https://lkml.org/lkml/2018/3/23/78

Because we have been using kexec-tools utility to search available
System RAM space for loading kernel/initrd/purgatory from top to down.
That is done in user space by searching /proc/iomem. While later added
kexec_file interface, the searching code happened in kernel, and it
only search System RAM region bottom up, then take an area in that found
RAM region from top to down. We need unify these two interfaces on
behaviour since they are the same on essense from the users' point of
view, though implementation is different. As you know, the singly linked
list implementation of the current resource's sibling linking, makes the
searching from top to down very hard to satisfy people. 

Below is the v1 post, we make an temporary array to copy iomem_resource's
first level of children, then iterate the array reversedly. Andrew
suggested me to try list_head after reviewing. In fact we can optimize
that patch to only copy resource pointer into array, still the way is
ugly.
https://lkml.org/lkml/2018/3/21/952

Then Wei pasted a patch he had made as below. He didn't mention if he
also has requirement on reversed iteration of resource. That is an O(n*n)
way, from personal feelings, hard to say if it's bettern than v1 post.
https://lkml.org/lkml/2018/3/24/157

That's why I would like to have a try of the list_head linking.

> 
> > And code refactoring makes codes in kernel/resource.c more readable than
> > pointer operation.
> 
> resource_for_each_* helpers could solve that without the size increase.

Nico mentioned llist, that is a linux kernel standard singly linked
list, very elegant code existed. Still can not satisfy the reversed
iteration requirement.

> 
> > Besides, type of member variables of struct resource, sibling and child, are
> > changed from 'struct resource *' to 'struct list_head'. Kernel size will
> > increase because of those statically defined struct resource instances.
> 
> The DT struct device_node also has the same tree structure with
> parent, child, sibling pointers and converting to list_head had been
> on the todo list for a while. ACPI also has some tree walking
> functions (drivers/acpi/acpica/pstree.c). Perhaps there should be a
> common tree struct and helpers defined either on top of list_head or a
> new struct if that saves some size.

We have had many this kind of trees in kernel, the obvious examples is 
task_struct. And struct task_group {} too. They have used list_head
already.
struct task_struct {
...
/* Real parent process: */  
   
struct task_struct __rcu*real_parent;   
   

   
/* Recipient of SIGCHLD, wait4() reports: */
   
struct task_struct __rcu*parent;
struct list_headchildren;   
   
struct list_headsibling;
...
}

root
///   |   \\\
   ///|\\\
  /// | \\\
 ///  |  \\\
  (child)<->(child)<->(child)
 ///   |   \\\
 ///   |  \\\
   /// |  \\\
///| \\\
 (grandchild)<->(grandchild)<->(grandchild)

If define an new struct, , like tree_list, or tlist?

struct tlist {
void*parent;
struct list_headsibling;
 
struct list_headchild;
}

Just a rough idea, feel it might not bring too much benefit compared
with direct list operation.

> 
> >
> > Signed-off-by: Baoquan He 
> > ---
> > v2->v3:
> >   Make sibling() and first_child() global so that they can be called
> >   out of kernel/resource.c to simplify code.
> 
> These should probably be inline functions. Or exported if not.
> 
> >
> >   Fix several code bugs found by kbuild test robot.
> >
> >   Got report from lkp that kernel size increased. It's on purpose since
> >   the type change of sibling and 

[PATCH 4/6] staging: rtl8192u: Replace GFP_ATOMIC with GFP_KERNEL in ieee80211_softmac_init

[Jia-Ju Bai]

ieee80211_softmac_init() is never called in atomic context.

The call chains ending up at ieee80211_softmac_init() is:
[1] ieee80211_softmac_init() <- alloc_ieee80211_rsl() <-
rtl8192_usb_probe()

rtl8192_usb_probe() is set as ".probe" in struct usb_driver.

Despite never getting called from atomic context,
ieee80211_softmac_init() calls kzalloc() with GFP_ATOMIC,
which does not sleep for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
which can sleep and improve the possibility of sucessful allocation.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

Signed-off-by: Jia-Ju Bai 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
index fe6f38b..cb4a2ad 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
@@ -2682,7 +2682,7 @@ void ieee80211_softmac_init(struct ieee80211_device *ieee)
for(i = 0; i < 5; i++) {
  ieee->seq_ctrl[i] = 0;
}
-   ieee->pDot11dInfo = kzalloc(sizeof(RT_DOT11D_INFO), GFP_ATOMIC);
+   ieee->pDot11dInfo = kzalloc(sizeof(RT_DOT11D_INFO), GFP_KERNEL);
if (!ieee->pDot11dInfo)
IEEE80211_DEBUG(IEEE80211_DL_ERR, "can't alloc memory for 
DOT11D\n");
//added for  AP roaming
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 3/6] staging: rtl8192u: Replace GFP_ATOMIC with GFP_KERNEL in prism2_wep_init

[Jia-Ju Bai]

prism2_wep_init() is never called in atomic context.

prism2_wep_init() is only set as ".init" in
struct ieee80211_crypto_ops.
The call chains ending up at "->init" function are:
[1] ->init() <- ieee80211_wpa_set_encryption() <-
ieee80211_wpa_supplicant_ioctl()
[2] ->init() <- ieee80211_wx_set_encode_ext_rsl() <-
r8192_wx_set_enc_ext()
[3] ->init() <- ieee80211_wx_set_encode_rsl() <-
r8192_wx_set_enc()

ieee80211_wpa_supplicant_ioctl(), r8192_wx_set_enc_ext() and
r8192_wx_set_enc() call mutex_lock(), which indicates these functions
are not called in atomic context.

Despite never getting called from atomic context,
prism2_wep_init() calls kzalloc() with GFP_ATOMIC,
which does not sleep for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
which can sleep and improve the possibility of sucessful allocation.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it

Signed-off-by: Jia-Ju Bai 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
index 7ba4b07..b9f86be 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
@@ -41,7 +41,7 @@ static void *prism2_wep_init(int keyidx)
 {
struct prism2_wep_data *priv;
 
-   priv = kzalloc(sizeof(*priv), GFP_ATOMIC);
+   priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (!priv)
return NULL;
priv->key_idx = keyidx;
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 5/6] staging: rtl8192u: Replace mdelay with usleep_range in rtl8192_usb_disconnect

[Jia-Ju Bai]

rtl8192_usb_disconnect() is never called in atomic context.

rtl8192_usb_disconnect() is only set as ".disconnect" in 
struct usb_driver.

Despite never getting called from atomic context, 
rtl8192_usb_disconnect() calls mdelay() to busily wait.
This is not necessary and can be replaced with usleep_range() to
avoid busy waiting.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

Signed-off-by: Jia-Ju Bai 
---
 drivers/staging/rtl8192u/r8192U_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 46b3f19..04ed34a 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -5033,7 +5033,7 @@ static void rtl8192_usb_disconnect(struct usb_interface 
*intf)
kfree(priv->pFirmware);
priv->pFirmware = NULL;
rtl8192_usb_deleteendpoints(dev);
-   mdelay(10);
+   usleep_range(1, 11000);
}
free_ieee80211(dev);
RT_TRACE(COMP_DOWN, "wlan driver removed\n");
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: wilc1000: Remove unnecessary braces {} around single statement block

[Eyal Ilsar]

Remove unnecessary braces {} around an 'if' statement block with a single 
statement. Issue found by checkpatch.
Signed-off-by: Eyal Ilsar
---
This is part of my take on the Eudyptula challenge

 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index 205304c..325afe1 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -284,9 +284,8 @@ static void remove_network_from_shadow(struct timer_list 
*unused)
}
}
 
-   if (last_scanned_cnt != 0) {
+   if (last_scanned_cnt != 0)
mod_timer(, jiffies + msecs_to_jiffies(AGING_TIME));
-   }
 }
 
 static void clear_duringIP(struct timer_list *unused)
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 2/4] hv_netvsc: Split netvsc_revoke_buf() and netvsc_teardown_gpadl()

[Sasha Levin]

Hi,

[This is an automated email]

This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 0ef58b0a05c1 hv_netvsc: change GPAD teardown order on older 
versions.

The bot has also determined it's probably a bug fixing patch. (score: 3.6623)

The bot has tested the following trees: v4.16.1.

v4.16.1: Failed to apply! Possible dependencies:
2afc5d61a719 ("hv_netvsc: Use Windows version instead of NVSP version on 
GPAD teardown")


--
Thanks,
Sasha
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/6] staging: rtl8192u: Replace GFP_ATOMIC with GFP_KERNEL in ieee80211_tkip_init

[Jia-Ju Bai]

ieee80211_tkip_init() is never called in atomic context.

ieee80211_tkip_init() is only set as ".init" in
struct ieee80211_crypto_ops.
The call chains ending up at "->init" function are:
[1] ->init() <- ieee80211_wpa_set_encryption() <-
ieee80211_wpa_supplicant_ioctl()
[2] ->init() <- ieee80211_wx_set_encode_ext_rsl() <-
r8192_wx_set_enc_ext()
[3] ->init() <- ieee80211_wx_set_encode_rsl() <-
r8192_wx_set_enc()

ieee80211_wpa_supplicant_ioctl(), r8192_wx_set_enc_ext() and
r8192_wx_set_enc() call mutex_lock(), which indicates these functions
are not called in atomic context.

Despite never getting called from atomic context,
ieee80211_tkip_init() calls kzalloc() with GFP_ATOMIC,
which does not sleep for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
which can sleep and improve the possibility of sucessful allocation.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

Signed-off-by: Jia-Ju Bai 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
index 60ecfec..a7efaae 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
@@ -66,7 +66,7 @@ static void *ieee80211_tkip_init(int key_idx)
 {
struct ieee80211_tkip_data *priv;
 
-   priv = kzalloc(sizeof(*priv), GFP_ATOMIC);
+   priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (!priv)
goto fail;
priv->key_idx = key_idx;
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/6] staging: rtl8192u: Replace GFP_ATOMIC with GFP_KERNEL in ieee80211_ccmp_init

[Jia-Ju Bai]

ieee80211_ccmp_init() is never called in atomic context.

ieee80211_ccmp_init() is only set as ".init" in 
struct ieee80211_crypto_ops.
The call chains ending up at "->init" function are:
[1] ->init() <- ieee80211_wpa_set_encryption() <- 
ieee80211_wpa_supplicant_ioctl()
[2] ->init() <- ieee80211_wx_set_encode_ext_rsl() <-
r8192_wx_set_enc_ext()
[3] ->init() <- ieee80211_wx_set_encode_rsl() <-
r8192_wx_set_enc()

ieee80211_wpa_supplicant_ioctl(), r8192_wx_set_enc_ext() and
r8192_wx_set_enc() call mutex_lock(), which indicates these functions 
are not called in atomic context.

Despite never getting called from atomic context,
ieee80211_ccmp_init() calls kzalloc() with GFP_ATOMIC,
which does not sleep for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
which can sleep and improve the possibility of sucessful allocation.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

Signed-off-by: Jia-Ju Bai 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c
index e6648f7..a8d39f1 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c
@@ -66,7 +66,7 @@ static void *ieee80211_ccmp_init(int key_idx)
 {
struct ieee80211_ccmp_data *priv;
 
-   priv = kzalloc(sizeof(*priv), GFP_ATOMIC);
+   priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (!priv)
goto fail;
priv->key_idx = key_idx;
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/4] hv_netvsc: Use Windows version instead of NVSP version on GPAD teardown

[Sasha Levin]

Hi,

[This is an automated email]

This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 0ef58b0a05c1 hv_netvsc: change GPAD teardown order on older 
versions.

The bot has also determined it's probably a bug fixing patch. (score: 19.6070)

The bot has tested the following trees: v4.16.1.

v4.16.1: Build OK!

--
Thanks,
Sasha
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 3/4] hv_netvsc: Ensure correct teardown message sequence order

[Sasha Levin]

Hi,

[This is an automated email]

This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 0ef58b0a05c1 hv_netvsc: change GPAD teardown order on older 
versions.

The bot has also determined it's probably a bug fixing patch. (score: 60.7987)

The bot has tested the following trees: v4.16.1.

v4.16.1: Failed to apply! Possible dependencies:
7992894c305e ("hv_netvsc: Split netvsc_revoke_buf() and 
netvsc_teardown_gpadl()")


--
Thanks,
Sasha
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 6/6] staging: rtl8192u: Replace mdelay with usleep_range in dm_TXPowerTrackingCallback_TSSI

[Jia-Ju Bai]

dm_TXPowerTrackingCallback_TSSI() is never called in atomic context.

dm_TXPowerTrackingCallback_TSSI() is only called by 
dm_txpower_trackingcallback(), which is set a parameter of 
INIT_DELAYED_WORK() in rtl8192_init_priv_task().

Despite never getting called from atomic context,
dm_TXPowerTrackingCallback_TSSI() calls mdelay() to busily wait.
This is not necessary and can be replaced with usleep_range() to
avoid busy waiting.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it

Signed-off-by: Jia-Ju Bai 
---
 drivers/staging/rtl8192u/r8192U_dm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_dm.c 
b/drivers/staging/rtl8192u/r8192U_dm.c
index e6f8d1d..51b2516 100644
--- a/drivers/staging/rtl8192u/r8192U_dm.c
+++ b/drivers/staging/rtl8192u/r8192U_dm.c
@@ -538,13 +538,13 @@ static void dm_TXPowerTrackingCallback_TSSI(struct 
net_device *dev)
rtStatus = SendTxCommandPacket(dev, _cmd, 12);
if (rtStatus == RT_STATUS_FAILURE)
RT_TRACE(COMP_POWER_TRACKING, "Set configuration with 
tx cmd queue fail!\n");
-   mdelay(1);
+   usleep_range(1000, 2000);
/*DbgPrint("hi, vivi, strange\n");*/
for (i = 0; i <= 30; i++) {
read_nic_byte(dev, 0x1ba, _Flag);
 
if (Pwr_Flag == 0) {
-   mdelay(1);
+   usleep_range(1000, 2000);
continue;
}
read_nic_word(dev, 0x13c, _TSSI_Meas);
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: Android: Add 'vsoc' driver for cuttlefish.

[Alistair Strachan]

From: Greg Hartman 

The cuttlefish system is a virtual SoC architecture based on QEMU. It
uses the QEMU ivshmem feature to share memory regions between guest and
host with a custom protocol.

Cc: Greg Kroah-Hartman 
Cc: Arve Hjønnevåg 
Cc: Todd Kjos 
Cc: Martijn Coenen 
Cc: de...@driverdev.osuosl.org
Cc: kernel-t...@android.com
Signed-off-by: Greg Hartman 
[astrachan: rebased against 4.16, added TODO, fixed checkpatch issues]
Signed-off-by: Alistair Strachan 
---
 drivers/staging/android/Kconfig |9 +
 drivers/staging/android/Makefile|1 +
 drivers/staging/android/TODO|   10 +
 drivers/staging/android/uapi/vsoc_shm.h |  303 ++
 drivers/staging/android/vsoc.c  | 1167 +++
 5 files changed, 1490 insertions(+)
 create mode 100644 drivers/staging/android/uapi/vsoc_shm.h
 create mode 100644 drivers/staging/android/vsoc.c

diff --git a/drivers/staging/android/Kconfig b/drivers/staging/android/Kconfig
index 71a50b99caff..29d891355f7a 100644
--- a/drivers/staging/android/Kconfig
+++ b/drivers/staging/android/Kconfig
@@ -14,6 +14,15 @@ config ASHMEM
  It is, in theory, a good memory allocator for low-memory devices,
  because it can discard shared memory units when under memory pressure.
 
+config ANDROID_VSOC
+   tristate "Android Virtual SoC support"
+   default n
+   depends on PCI_MSI
+   ---help---
+ This option adds support for the Virtual SoC driver needed to boot
+ a 'cuttlefish' Android image inside QEmu. The driver interacts with
+ a QEmu ivshmem device. If built as a module, it will be called vsoc.
+
 source "drivers/staging/android/ion/Kconfig"
 
 endif # if ANDROID
diff --git a/drivers/staging/android/Makefile b/drivers/staging/android/Makefile
index 7cf1564a49a5..90e6154f11a4 100644
--- a/drivers/staging/android/Makefile
+++ b/drivers/staging/android/Makefile
@@ -3,3 +3,4 @@ ccflags-y += -I$(src)   # needed for trace 
events
 obj-y  += ion/
 
 obj-$(CONFIG_ASHMEM)   += ashmem.o
+obj-$(CONFIG_ANDROID_VSOC) += vsoc.o
diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO
index 687e0eac85bf..6aab759efa48 100644
--- a/drivers/staging/android/TODO
+++ b/drivers/staging/android/TODO
@@ -11,5 +11,15 @@ ion/
  - Split /dev/ion up into multiple nodes (e.g. /dev/ion/heap0)
  - Better test framework (integration with VGEM was suggested)
 
+vsoc.c, uapi/vsoc_shm.h
+ - The current driver uses the same wait queue for all of the futexes in a
+   region. This will cause false wakeups in regions with a large number of
+   waiting threads. We should eventually use multiple queues and select the
+   queue based on the region.
+ - Add debugfs support for examining the permissions of regions.
+ - Use ioremap_wc instead of ioremap_nocache.
+ - Remove VSOC_WAIT_FOR_INCOMING_INTERRUPT ioctl. This functionality has been
+   superseded by the futex and is there for legacy reasons.
+
 Please send patches to Greg Kroah-Hartman  and Cc:
 Arve Hjønnevåg  and Riley Andrews 
diff --git a/drivers/staging/android/uapi/vsoc_shm.h 
b/drivers/staging/android/uapi/vsoc_shm.h
new file mode 100644
index ..741b1387c25b
--- /dev/null
+++ b/drivers/staging/android/uapi/vsoc_shm.h
@@ -0,0 +1,303 @@
+/*
+ * Copyright (C) 2017 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef _UAPI_LINUX_VSOC_SHM_H
+#define _UAPI_LINUX_VSOC_SHM_H
+
+#include 
+
+/**
+ * A permission is a token that permits a receiver to read and/or write an area
+ * of memory within a Vsoc region.
+ *
+ * An fd_scoped permission grants both read and write access, and can be
+ * attached to a file description (see open(2)).
+ * Ownership of the area can then be shared by passing a file descriptor
+ * among processes.
+ *
+ * begin_offset and end_offset define the area of memory that is controlled by
+ * the permission. owner_offset points to a word, also in shared memory, that
+ * controls ownership of the area.
+ *
+ * ownership of the region expires when the associated file description is
+ * released.
+ *
+ * At most one permission can be attached to each file description.
+ *
+ * This is useful when implementing HALs like gralloc that scope and pass
+ * ownership of shared resources via file descriptors.
+ *
+ * 

[PATCH] staging: comedi: cb_pcidas64: fix alignment of function parameters

[Gabriel Francisco Mandaji]

Fix most checkpatch.pl issues of type:

CHECK: Alignment should match open parenthesis

Signed-off-by: Gabriel Francisco Mandaji 
---
 drivers/staging/comedi/drivers/cb_pcidas64.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/comedi/drivers/cb_pcidas64.c 
b/drivers/staging/comedi/drivers/cb_pcidas64.c
index fdd81c3..631a703 100644
--- a/drivers/staging/comedi/drivers/cb_pcidas64.c
+++ b/drivers/staging/comedi/drivers/cb_pcidas64.c
@@ -2268,14 +2268,14 @@ static inline unsigned int dma_transfer_size(struct 
comedi_device *dev)
 }
 
 static u32 ai_convert_counter_6xxx(const struct comedi_device *dev,
-   const struct comedi_cmd *cmd)
+  const struct comedi_cmd *cmd)
 {
/* supposed to load counter with desired divisor minus 3 */
return cmd->convert_arg / TIMER_BASE - 3;
 }
 
 static u32 ai_scan_counter_6xxx(struct comedi_device *dev,
-struct comedi_cmd *cmd)
+   struct comedi_cmd *cmd)
 {
u32 count;
 
@@ -2296,7 +2296,7 @@ static u32 ai_scan_counter_6xxx(struct comedi_device *dev,
 }
 
 static u32 ai_convert_counter_4020(struct comedi_device *dev,
-   struct comedi_cmd *cmd)
+  struct comedi_cmd *cmd)
 {
struct pcidas64_private *devpriv = dev->private;
unsigned int divisor;
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] Staging: most: Move comments to the end of line

[Ian Liu Rodrigues]

Signed-off-by: Ian Liu Rodrigues 
---
 drivers/staging/most/dim2/reg.h | 84 -
 1 file changed, 42 insertions(+), 42 deletions(-)

diff --git a/drivers/staging/most/dim2/reg.h b/drivers/staging/most/dim2/reg.h
index 69cbf78239f1..4343a483017e 100644
--- a/drivers/staging/most/dim2/reg.h
+++ b/drivers/staging/most/dim2/reg.h
@@ -12,48 +12,48 @@
 #include 
 
 struct dim2_regs {
-   /* 0x00 */ u32 MLBC0;
-   /* 0x01 */ u32 rsvd0[1];
-   /* 0x02 */ u32 MLBPC0;
-   /* 0x03 */ u32 MS0;
-   /* 0x04 */ u32 rsvd1[1];
-   /* 0x05 */ u32 MS1;
-   /* 0x06 */ u32 rsvd2[2];
-   /* 0x08 */ u32 MSS;
-   /* 0x09 */ u32 MSD;
-   /* 0x0A */ u32 rsvd3[1];
-   /* 0x0B */ u32 MIEN;
-   /* 0x0C */ u32 rsvd4[1];
-   /* 0x0D */ u32 MLBPC2;
-   /* 0x0E */ u32 MLBPC1;
-   /* 0x0F */ u32 MLBC1;
-   /* 0x10 */ u32 rsvd5[0x10];
-   /* 0x20 */ u32 HCTL;
-   /* 0x21 */ u32 rsvd6[1];
-   /* 0x22 */ u32 HCMR0;
-   /* 0x23 */ u32 HCMR1;
-   /* 0x24 */ u32 HCER0;
-   /* 0x25 */ u32 HCER1;
-   /* 0x26 */ u32 HCBR0;
-   /* 0x27 */ u32 HCBR1;
-   /* 0x28 */ u32 rsvd7[8];
-   /* 0x30 */ u32 MDAT0;
-   /* 0x31 */ u32 MDAT1;
-   /* 0x32 */ u32 MDAT2;
-   /* 0x33 */ u32 MDAT3;
-   /* 0x34 */ u32 MDWE0;
-   /* 0x35 */ u32 MDWE1;
-   /* 0x36 */ u32 MDWE2;
-   /* 0x37 */ u32 MDWE3;
-   /* 0x38 */ u32 MCTL;
-   /* 0x39 */ u32 MADR;
-   /* 0x3A */ u32 rsvd8[0xB6];
-   /* 0xF0 */ u32 ACTL;
-   /* 0xF1 */ u32 rsvd9[3];
-   /* 0xF4 */ u32 ACSR0;
-   /* 0xF5 */ u32 ACSR1;
-   /* 0xF6 */ u32 ACMR0;
-   /* 0xF7 */ u32 ACMR1;
+   u32 MLBC0;   /* 0x00 */
+   u32 rsvd0[1];/* 0x01 */
+   u32 MLBPC0;  /* 0x02 */
+   u32 MS0; /* 0x03 */
+   u32 rsvd1[1];/* 0x04 */
+   u32 MS1; /* 0x05 */
+   u32 rsvd2[2];/* 0x06 */
+   u32 MSS; /* 0x08 */
+   u32 MSD; /* 0x09 */
+   u32 rsvd3[1];/* 0x0A */
+   u32 MIEN;/* 0x0B */
+   u32 rsvd4[1];/* 0x0C */
+   u32 MLBPC2;  /* 0x0D */
+   u32 MLBPC1;  /* 0x0E */
+   u32 MLBC1;   /* 0x0F */
+   u32 rsvd5[0x10]; /* 0x10 */
+   u32 HCTL;/* 0x20 */
+   u32 rsvd6[1];/* 0x21 */
+   u32 HCMR0;   /* 0x22 */
+   u32 HCMR1;   /* 0x23 */
+   u32 HCER0;   /* 0x24 */
+   u32 HCER1;   /* 0x25 */
+   u32 HCBR0;   /* 0x26 */
+   u32 HCBR1;   /* 0x27 */
+   u32 rsvd7[8];/* 0x28 */
+   u32 MDAT0;   /* 0x30 */
+   u32 MDAT1;   /* 0x31 */
+   u32 MDAT2;   /* 0x32 */
+   u32 MDAT3;   /* 0x33 */
+   u32 MDWE0;   /* 0x34 */
+   u32 MDWE1;   /* 0x35 */
+   u32 MDWE2;   /* 0x36 */
+   u32 MDWE3;   /* 0x37 */
+   u32 MCTL;/* 0x38 */
+   u32 MADR;/* 0x39 */
+   u32 rsvd8[0xb6]; /* 0x3A */
+   u32 ACTL;/* 0xF0 */
+   u32 rsvd9[3];/* 0xF1 */
+   u32 ACSR0;   /* 0xF4 */
+   u32 ACSR1;   /* 0xF5 */
+   u32 ACMR0;   /* 0xF6 */
+   u32 ACMR1;   /* 0xF7 */
 };
 
 #define DIM2_MASK(n)  (~((~(u32)0) << (n)))
-- 
2.17.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: comedi: cb_pcidas64: fix alignment of function parameters

[Julia Lawall]

On Tue, 10 Apr 2018, Gabriel Francisco Mandaji wrote:

> Fix most checkpatch.pl issues of type:
>
> CHECK: Alignment should match open parenthesis
>
> Signed-off-by: Gabriel Francisco Mandaji 
> ---
>  drivers/staging/comedi/drivers/cb_pcidas64.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/comedi/drivers/cb_pcidas64.c 
> b/drivers/staging/comedi/drivers/cb_pcidas64.c
> index fdd81c3..631a703 100644
> --- a/drivers/staging/comedi/drivers/cb_pcidas64.c
> +++ b/drivers/staging/comedi/drivers/cb_pcidas64.c
> @@ -2268,14 +2268,14 @@ static inline unsigned int dma_transfer_size(struct 
> comedi_device *dev)
>  }
>
>  static u32 ai_convert_counter_6xxx(const struct comedi_device *dev,
> - const struct comedi_cmd *cmd)
> +const struct comedi_cmd *cmd)

Someone has made the effort to put const on these parameters, but not on
the other similar functions.  Perhaps this can be improved as well.

julia

>  {
>   /* supposed to load counter with desired divisor minus 3 */
>   return cmd->convert_arg / TIMER_BASE - 3;
>  }
>
>  static u32 ai_scan_counter_6xxx(struct comedi_device *dev,
> -  struct comedi_cmd *cmd)
> + struct comedi_cmd *cmd)
>  {
>   u32 count;
>
> @@ -2296,7 +2296,7 @@ static u32 ai_scan_counter_6xxx(struct comedi_device 
> *dev,
>  }
>
>  static u32 ai_convert_counter_4020(struct comedi_device *dev,
> - struct comedi_cmd *cmd)
> +struct comedi_cmd *cmd)
>  {
>   struct pcidas64_private *devpriv = dev->private;
>   unsigned int divisor;
> --
> 1.9.1
>
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/2] uio_hv_generic: make ring buffer attribute for primary channel

[Stephen Hemminger]

The primary channel also needs a ring buffer attribute. This allows
application to check if kernel supports uio sub channels, and also
makes all channels use consistent API.

Signed-off-by: Stephen Hemminger 
---
 drivers/uio/uio_hv_generic.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/uio/uio_hv_generic.c b/drivers/uio/uio_hv_generic.c
index 7ff659dff11d..972a42dd2a46 100644
--- a/drivers/uio/uio_hv_generic.c
+++ b/drivers/uio/uio_hv_generic.c
@@ -326,6 +326,11 @@ hv_uio_probe(struct hv_device *dev,
vmbus_set_chn_rescind_callback(dev->channel, hv_uio_rescind);
vmbus_set_sc_create_callback(dev->channel, hv_uio_new_channel);
 
+   ret = sysfs_create_bin_file(>channel->kobj, _buffer_bin_attr);
+   if (ret)
+   dev_notice(>device,
+  "sysfs create ring bin file failed; %d\n", ret);
+
hv_set_drvdata(dev, pdata);
 
return 0;
-- 
2.16.3

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/2] staging: irda: Replace mdelay with usleep_range in irda_usb_probe

[Jia-Ju Bai]

irda_usb_probe() is never called in atomic context.

irda_usb_probe() is only set as ".probe" in struct usb_driver.

Despite never getting called from atomic context, irda_usb_probe()
calls mdelay() to busily wait.
This is not necessary and can be replaced with usleep_range() to
avoid busy waiting.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

Signed-off-by: Jia-Ju Bai 
---
 drivers/staging/irda/drivers/irda-usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/irda/drivers/irda-usb.c 
b/drivers/staging/irda/drivers/irda-usb.c
index 723e49b..6ff5b08 100644
--- a/drivers/staging/irda/drivers/irda-usb.c
+++ b/drivers/staging/irda/drivers/irda-usb.c
@@ -1710,7 +1710,7 @@ static int irda_usb_probe(struct usb_interface *intf,
pr_debug("usb_control_msg failed %d\n", ret);
goto err_out_3;
} else {
-   mdelay(10);
+   usleep_range(1, 11000);
}
}
 
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 1/3] resource: Use list_head to link resource sibling

[Wei Yang]

On Tue, Apr 10, 2018 at 09:44:16PM +0800, Baoquan He wrote:
>Hi Rob,
>
>Thanks a lot for looking into this and involve Nico to this thread!
>
>On 04/09/18 at 09:49am, Rob Herring wrote:
>> +Nico who has been working on tinification of the kernel.
>> 
>> On Mon, Apr 9, 2018 at 4:08 AM, Baoquan He  wrote:
>> > The struct resource uses singly linked list to link siblings. It's not
>> > easy to do reverse iteration on sibling list. So replace it with list_head.
>> 
>> Why is reverse iteration needed?
>
>This is the explanation I made when Andrew helped to review the v1 post:
>https://lkml.org/lkml/2018/3/23/78
>
>Because we have been using kexec-tools utility to search available
>System RAM space for loading kernel/initrd/purgatory from top to down.
>That is done in user space by searching /proc/iomem. While later added
>kexec_file interface, the searching code happened in kernel, and it
>only search System RAM region bottom up, then take an area in that found
>RAM region from top to down. We need unify these two interfaces on
>behaviour since they are the same on essense from the users' point of
>view, though implementation is different. As you know, the singly linked
>list implementation of the current resource's sibling linking, makes the
>searching from top to down very hard to satisfy people. 
>
>Below is the v1 post, we make an temporary array to copy iomem_resource's
>first level of children, then iterate the array reversedly. Andrew
>suggested me to try list_head after reviewing. In fact we can optimize
>that patch to only copy resource pointer into array, still the way is
>ugly.
>https://lkml.org/lkml/2018/3/21/952
>
>Then Wei pasted a patch he had made as below. He didn't mention if he
>also has requirement on reversed iteration of resource. That is an O(n*n)
>way, from personal feelings, hard to say if it's bettern than v1 post.
>https://lkml.org/lkml/2018/3/24/157

I don't have requirement on reverse iteration of resource structure.

My approach is almost the same as current walk_system_ram_res(). Since each
resource keeps parent, we could get previous resource by search on
res->parent->child.

The complexity of a whole iteration is O(N * W / 2), where N is the number of
resources in the tree and W is the average number of siblings of each
resource.

And this approach doesn't need to change current structure.

>
>That's why I would like to have a try of the list_head linking.
>

-- 
Wei Yang
Help you, Help me
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v6] PCI: hv: Make sure the bus domain is really unique

[Sridhar Pitchai]

When Linux runs as a guest VM in Hyper-V and Hyper-V adds the virtual
PCI bus to the guest, Hyper-V always provides unique PCI domain.

commit 4a9b0933bdfc ("PCI: hv: Use device serial number as PCI domain")
overrode unique domain with the serial number of the first device added
to the virtual PCI bus. The reason for that patch is to have a consistent
and short name for the device. But commit 4a9b0933bdfc ("PCI: hv: Use
device serial number as PCI domain") will not guarantee unique domain id.
For example, if the serial number of the device is 0 and there exists a
PCI bus with domain 0 already, this will cause the PCI bus registration
with kernel fails.

commit 4a9b0933bdfc ("PCI: hv: Use device serial number as PCI
domain") need to be reverted.

Revert commit 4a9b0933bdfc ("PCI: hv: Use device serial number as PCI
domain") so we can reliably support multiple devices being assigned to
a guest.

Fixes: 4a9b0933bdfc ("PCI: hv: Use device serial number as PCI domain")
Signed-off-by: Sridhar Pitchai 
Cc: sta...@vger.kernel.org

---
Changes in v6:
* fix the commit comment. [Lorenzo Pieralisi, Bjorn Helgaas]
---
 drivers/pci/host/pci-hyperv.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
index 2faf38eab785..ac67e56e451a 100644
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -1518,17 +1518,6 @@ static struct hv_pci_dev *new_pcichild_device(struct 
hv_pcibus_device *hbus,
get_pcichild(hpdev, hv_pcidev_ref_childlist);
spin_lock_irqsave(>device_list_lock, flags);
 
-   /*
-* When a device is being added to the bus, we set the PCI domain
-* number to be the device serial number, which is non-zero and
-* unique on the same VM.  The serial numbers start with 1, and
-* increase by 1 for each device.  So device names including this
-* can have shorter names than based on the bus instance UUID.
-* Only the first device serial number is used for domain, so the
-* domain number will not change after the first device is added.
-*/
-   if (list_empty(>children))
-   hbus->sysdata.domain = desc->ser;
list_add_tail(>list_entry, >children);
spin_unlock_irqrestore(>device_list_lock, flags);
return hpdev;
-- 
2.14.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 0/2] uio_hv_generic: subchannel fixes

[Stephen Hemminger]

Testing of uio_hv_generic (submitted and merged version) with DPDK
revealead a couple of bits lost in upstreaming process.

Stephen Hemminger (2):
  uio_hv_generic: set size of ring buffer attribute
  uio_hv_generic: make ring buffer attribute for primary channel

 drivers/uio/uio_hv_generic.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

-- 
2.16.3

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/2] uio_hv_generic: set size of ring buffer attribute

[Stephen Hemminger]

The development version had ring size as a module parameter, but
then it was made a fixed value. The code to set the size of
the ring buffer binary file was lost in the transistion.
The size is needed by user mode driver to know the size of
the ring buffer.

Fixes: 37b96a4931db ("uio_hv_generic: support sub-channels")
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 b/drivers/uio/uio_hv_generic.c
index f695a7e8c314..7ff659dff11d 100644
--- a/drivers/uio/uio_hv_generic.c
+++ b/drivers/uio/uio_hv_generic.c
@@ -171,12 +171,12 @@ static int hv_uio_ring_mmap(struct file *filp, struct 
kobject *kobj,
return 0;
 }
 
-static struct bin_attribute ring_buffer_bin_attr __ro_after_init = {
+static const struct bin_attribute ring_buffer_bin_attr = {
.attr = {
.name = "ring",
.mode = 0600,
-   /* size is set at init time */
},
+   .size = 2 * HV_RING_SIZE * PAGE_SIZE,
.mmap = hv_uio_ring_mmap,
 };
 
-- 
2.16.3

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/2] staging: irda: Replace mdelay with usleep_range in stir421x_fw_upload

[Jia-Ju Bai]

stir421x_fw_upload() is never called in atomic context.

The call chain ending up at stir421x_fw_upload() is:
[1] stir421x_fw_upload() <- stir421x_patch_device() <- irda_usb_probe()

irda_usb_probe() is set as ".probe" in struct usb_driver.
This function is not called in atomic context.

Despite never getting called from atomic context, stir421x_fw_upload()
calls mdelay() to busily wait.
This is not necessary and can be replaced with usleep_range() to
avoid busy waiting.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

Signed-off-by: Jia-Ju Bai 
---
 drivers/staging/irda/drivers/irda-usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/irda/drivers/irda-usb.c 
b/drivers/staging/irda/drivers/irda-usb.c
index 723e49b..c6c8c2c 100644
--- a/drivers/staging/irda/drivers/irda-usb.c
+++ b/drivers/staging/irda/drivers/irda-usb.c
@@ -1050,7 +1050,7 @@ static int stir421x_fw_upload(struct irda_usb_cb *self,
if (ret < 0)
break;
 
-   mdelay(10);
+   usleep_range(1, 11000);
}
 
kfree(patch_block);
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel