[PATCH 1/1] [PATCH] Staging:vt6655: sparse warning fix

2014-12-09 Thread Adithya K 
From: Adithya Krishnamurthy 

Fixed sparse warning fix.

Signed-off-by: Adithya Krishnamurthy 
---
---
 drivers/staging/vt6655/device_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vt6655/device_main.c 
b/drivers/staging/vt6655/device_main.c
index 83e4162..a3f5cd8 100644
--- a/drivers/staging/vt6655/device_main.c
+++ b/drivers/staging/vt6655/device_main.c
@@ -1669,7 +1669,7 @@ static const struct ieee80211_ops vnt_mac_ops = {
.reset_tsf  = vnt_reset_tsf,
 };
 
-int vnt_init(struct vnt_private *priv)
+static int vnt_init(struct vnt_private *priv)
 {
SET_IEEE80211_PERM_ADDR(priv->hw, priv->abyCurrentNetAddr);
 
-- 
1.9.1

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

Re: [PATCH 2/2] Drivers: hv: balloon: Fix the deadlock issue in the memory hot-add code

2014-12-09 Thread Michal Hocko 
On Tue 09-12-14 10:23:51, Yasuaki Ishimatsu wrote:
> (2014/12/09 0:04), Michal Hocko wrote:
> >On Fri 05-12-14 16:41:38, K. Y. Srinivasan wrote:
> >>Andy Whitcroft  initially saw this deadlock. We
> >>have seen this as well. Here is the original description of the
> >>problem (and a potential solution) from Andy:
> >>
> >>https://lkml.org/lkml/2014/3/14/451
> >>
> >>Here is an excerpt from that mail:
> >>
> >>"We are seeing machines lockup with what appears to be an ABBA
> >>deadlock in the memory hotplug system.  These are from the 3.13.6 based 
> >>Ubuntu kernels.
> >>The hv_balloon driver is adding memory using add_memory() which takes
> >>the hotplug lock
> >
> >Do you mean mem_hotplug_begin?
> >
> 
> >>and then emits a udev event, and then attempts to
> >>lock the sysfs device.  In response to the udev event udev opens the
> >>sysfs device and locks it, then attempts to grab the hotplug lock to online 
> >>the memory.
> >
> >Cannot we simply teach online_pages to fail with EBUSY when the memory
> >hotplug is on the way.  We shouldn't try to online something that is not
> >initialized yet, no?
> 
> Yes. Memory online shouldn't try before initializing it. Then memory online
> should wait for initializing it, not easily fails. Generally, kernel sends
> memory ONLINE event to userland by kobject_uevent() during initializing memory
> and udev makes memory online after catching the event. Onlining memory by
> udev almost run during initializing memory.

I guess this is because the event is sent after a mem section is
initialized while the overal hotplug operation is still not completed.

> So if memory online easily fails, onlining memory by udev almost
> fails.

Doesn't udev retry the operation if it gets EBUSY or EAGAIN?

> >The memory hotplug log is global so we can get
> >false positives but that should be easier to deal with than exporting
> >lock_device_hotplug and adding yet another lock dependency.
> >
> >>This seems to be inverted nesting in the two cases, leading to the hangs 
> >>below:
> >>
> >>[  240.608612] INFO: task kworker/0:2:861 blocked for more than 120 seconds.
> >>[  240.608705] INFO: task systemd-udevd:1906 blocked for more than 120 
> >>seconds.
> >>
> >>I note that the device hotplug locking allows complete retries (via
> >>ERESTARTSYS) and if we could detect this at the online stage it could
> >>be used to get us out.
> >
> >I am not sure I understand this but it suggests EBUSY above?
> >
> >>But before I go down this road I wanted to
> >>make sure I am reading this right.  Or indeed if the hv_balloon driver
> >>is just doing this wrong."
> >>
> >>This patch is based on the suggestion from
> >>Yasuaki Ishimatsu 
> >
> >This changelog doesn't explain us much. And boy this whole thing is so
> >convoluted. E.g. I have hard time to see why ACPI hotplug is working
> >correctly. My trail got lost at acpi_memory_device_add level which is
> >a callback while acpi_device_hotplug is holding lock_device_hotplug but
> >then again the rest is hidden by callbacks.
> 
> Commit 0f1cfe9d0d06 (mm/hotplug: remove stop_machine() from 
> try_offline_node()) said:
> 
>   ---
> lock_device_hotplug() serializes hotplug & online/offline operations.  The
> lock is held in common sysfs online/offline interfaces and ACPI hotplug
> code paths.
> 
> And here are the code paths:
> 
> - CPU & Mem online/offline via sysfs online
> store_online()->lock_device_hotplug()
> 
> - Mem online via sysfs state:
> store_mem_state()->lock_device_hotplug()
> 
> - ACPI CPU & Mem hot-add:
> acpi_scan_bus_device_check()->lock_device_hotplug()
> 
> - ACPI CPU & Mem hot-delete:
> acpi_scan_hot_remove()->lock_device_hotplug()
>   ---
> 
> CPU & Memory online/offline/hotplug are serialized by lock_device_hotplug().

OK, this patch aimed at the complete nodes hotplug. I am not familiar
with the code enough to tell whether this is really needed but it sounds
like an overkill when we are interested only in the memory hotplug. Why
would we need stop_machine or anything for memory that is guaranteed to
be not used at the time of both online and offline.
And again, why cannot we simply make the onlining fail or try_lock and
retry internally if the event consumer cannot cope with errors?
And even if that is not possible then do not export lock_device_hotplug
but export a memory hotplug functions which use it properly so that
other consumers (xen ballon seem to rely on add_memory as well) do not
need the same change as well.

> >I cannot seem to find any documentation which would explain all the
> >locking here.
> 
> Yes. I need the documentation.

Yes please! This code is incredibly hard to follow and deduce all the
hidden requirements and dependencies is even harder.
-- 
Michal Hocko
SUSE Labs
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 2/2] Drivers: hv: balloon: Fix the deadlock issue in the memory hot-add code

2014-12-09 Thread Yasuaki Ishimatsu 

(2014/12/09 18:08), Michal Hocko wrote:

On Tue 09-12-14 10:23:51, Yasuaki Ishimatsu wrote:

(2014/12/09 0:04), Michal Hocko wrote:

On Fri 05-12-14 16:41:38, K. Y. Srinivasan wrote:

Andy Whitcroft  initially saw this deadlock. We
have seen this as well. Here is the original description of the
problem (and a potential solution) from Andy:

https://lkml.org/lkml/2014/3/14/451

Here is an excerpt from that mail:

"We are seeing machines lockup with what appears to be an ABBA
deadlock in the memory hotplug system.  These are from the 3.13.6 based Ubuntu 
kernels.
The hv_balloon driver is adding memory using add_memory() which takes
the hotplug lock


Do you mean mem_hotplug_begin?




and then emits a udev event, and then attempts to
lock the sysfs device.  In response to the udev event udev opens the
sysfs device and locks it, then attempts to grab the hotplug lock to online the 
memory.


Cannot we simply teach online_pages to fail with EBUSY when the memory
hotplug is on the way.  We shouldn't try to online something that is not
initialized yet, no?


Yes. Memory online shouldn't try before initializing it. Then memory online
should wait for initializing it, not easily fails. Generally, kernel sends
memory ONLINE event to userland by kobject_uevent() during initializing memory
and udev makes memory online after catching the event. Onlining memory by
udev almost run during initializing memory.


I guess this is because the event is sent after a mem section is
initialized while the overal hotplug operation is still not completed.


right.




So if memory online easily fails, onlining memory by udev almost
fails.


Doesn't udev retry the operation if it gets EBUSY or EAGAIN?


It depend on implementation of udev.rules. So we can retry online/offline
operation in udev.rules.




The memory hotplug log is global so we can get
false positives but that should be easier to deal with than exporting
lock_device_hotplug and adding yet another lock dependency.


This seems to be inverted nesting in the two cases, leading to the hangs below:

[  240.608612] INFO: task kworker/0:2:861 blocked for more than 120 seconds.
[  240.608705] INFO: task systemd-udevd:1906 blocked for more than 120 seconds.

I note that the device hotplug locking allows complete retries (via
ERESTARTSYS) and if we could detect this at the online stage it could
be used to get us out.


I am not sure I understand this but it suggests EBUSY above?


But before I go down this road I wanted to
make sure I am reading this right.  Or indeed if the hv_balloon driver
is just doing this wrong."

This patch is based on the suggestion from
Yasuaki Ishimatsu 


This changelog doesn't explain us much. And boy this whole thing is so
convoluted. E.g. I have hard time to see why ACPI hotplug is working
correctly. My trail got lost at acpi_memory_device_add level which is
a callback while acpi_device_hotplug is holding lock_device_hotplug but
then again the rest is hidden by callbacks.


Commit 0f1cfe9d0d06 (mm/hotplug: remove stop_machine() from try_offline_node()) 
said:

   ---
 lock_device_hotplug() serializes hotplug & online/offline operations.  The
 lock is held in common sysfs online/offline interfaces and ACPI hotplug
 code paths.

 And here are the code paths:

 - CPU & Mem online/offline via sysfs online
 store_online()->lock_device_hotplug()

 - Mem online via sysfs state:
 store_mem_state()->lock_device_hotplug()

 - ACPI CPU & Mem hot-add:
 acpi_scan_bus_device_check()->lock_device_hotplug()

 - ACPI CPU & Mem hot-delete:
 acpi_scan_hot_remove()->lock_device_hotplug()
   ---

CPU & Memory online/offline/hotplug are serialized by lock_device_hotplug().


OK, this patch aimed at the complete nodes hotplug. I am not familiar
with the code enough to tell whether this is really needed but it sounds
like an overkill when we are interested only in the memory hotplug. Why
would we need stop_machine or anything for memory that is guaranteed to
be not used at the time of both online and offline.


As Srinivasan mentioned, there is ABBA issue. So to evade it, 
lock_device_hotplug()
is needed.


And again, why cannot we simply make the onlining fail or try_lock and
retry internally if the event consumer cannot cope with errors?


Did you mean the following Srinivasan's first patch looks good to you?
  https://lkml.org/lkml/2014/12/2/662

Thanks,
Yasuaki Ishimatsu


And even if that is not possible then do not export lock_device_hotplug
but export a memory hotplug functions which use it properly so that
other consumers (xen ballon seem to rely on add_memory as well) do not
need the same change as well.






I cannot seem to find any documentation which would explain all the
locking here.


Yes. I need the documentation.


Yes please! This code is incredibly hard to follow and deduce all the
hidden requirements and dependencies is even harder.




___
de

[PATCH] tools: hv: kvp_daemon: make IPv6-only-injection work

2014-12-09 Thread Dexuan Cui 
Currently IPv6-only-injection doesn't work because the daemon doesn't parse
any IPv6 information at all once it finds the dhcp_enabled flag is true.

But according to the Hyper-v host team, the flag is only for IPv4.
In the case the host only injects 1 IPv6 address, the dhcp flag is true, but
we shouldn't ignore the IPv6 address and we should pass BOOTPROTO=none
to the distro-specific script hv_set_ipconfig.

Tested in Ubuntu 14.10 and RHEL7.

Cc: K. Y. Srinivasan 
Signed-off-by: Dexuan Cui 
---
 tools/hv/hv_kvp_daemon.c | 47 +++
 1 file changed, 31 insertions(+), 16 deletions(-)

diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index 6a6432a..6ef6c04 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -1145,6 +1145,9 @@ static int kvp_write_file(FILE *f, char *s1, char *s2, 
char *s3)
 }
 
 
+/* How many ipv6 addresses the host is trying to inject? */
+static int num_ipv6_injected;
+
 static int process_ip_string(FILE *f, char *ip_string, int type)
 {
int error = 0;
@@ -1190,6 +1193,7 @@ static int process_ip_string(FILE *f, char *ip_string, 
int type)
switch (type) {
case IPADDR:
snprintf(str, sizeof(str), "%s", "IPV6ADDR");
+   num_ipv6_injected++;
break;
case NETMASK:
snprintf(str, sizeof(str), "%s", "IPV6NETMASK");
@@ -1308,27 +1312,12 @@ static int kvp_set_ip_info(char *if_name, struct 
hv_kvp_ipaddr_value *new_val)
if (error)
goto setval_error;
 
-   if (new_val->dhcp_enabled) {
-   error = kvp_write_file(file, "BOOTPROTO", "", "dhcp");
-   if (error)
-   goto setval_error;
-
-   /*
-* We are done!.
-*/
-   goto setval_done;
-
-   } else {
-   error = kvp_write_file(file, "BOOTPROTO", "", "none");
-   if (error)
-   goto setval_error;
-   }
-
/*
 * Write the configuration for ipaddress, netmask, gateway and
 * name servers.
 */
 
+   num_ipv6_injected = 0;
error = process_ip_string(file, (char *)new_val->ip_addr, IPADDR);
if (error)
goto setval_error;
@@ -1345,6 +1334,32 @@ static int kvp_set_ip_info(char *if_name, struct 
hv_kvp_ipaddr_value *new_val)
if (error)
goto setval_error;
 
+   /*
+* Here "dhcp_enabled" is only for IPv4 according to Hyper-V host team.
+*
+* In the case the host only injects 1 IPv6 address:
+* new_val->dhcp_enabled is true, but we can't pass BOOTPROTO=dhcp to
+* the script hv_set_ifconfig, because in some distros (like RHEL7)
+* BOOTPROTO=dhcp has a special meaning in the config file (e.g.,
+* /etc/sysconfig/network-scripts/ifcfg-eth0): the network init program
+* ignores any static IP addr information once there is
+* BOOTPROTO=dhcp; as a result, IPv6-only injection can't work.
+*
+* In the case of IPv6-only injection, BOOTPROTO=dhcp doesn't affect
+* Ubuntu because it's ignored by the Ubuntu version of
+* hv_set_ifconfig and it doesn't seem to have special meaning in
+* Ubuntu.
+*/
+   if (new_val->dhcp_enabled && num_ipv6_injected == 0) {
+   error = kvp_write_file(file, "BOOTPROTO", "", "dhcp");
+   if (error)
+   goto setval_error;
+   } else {
+   error = kvp_write_file(file, "BOOTPROTO", "", "none");
+   if (error)
+   goto setval_error;
+   }
+
 setval_done:
fclose(file);
 
-- 
1.9.1

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

Re: [PATCH 2/2] Drivers: hv: balloon: Fix the deadlock issue in the memory hot-add code

2014-12-09 Thread Michal Hocko 
On Tue 09-12-14 19:25:50, Yasuaki Ishimatsu wrote:
> (2014/12/09 18:08), Michal Hocko wrote:
[...]
> >Doesn't udev retry the operation if it gets EBUSY or EAGAIN?
> 
> It depend on implementation of udev.rules. So we can retry online/offline
> operation in udev.rules.
[...]

# Memory hotadd request
SUBSYSTEM=="memory", ACTION=="add", 
DEVPATH=="/devices/system/memory/memory*[0-9]", TEST=="/sys$devpath/state", 
RUN+="/bin/sh -c 'echo online > /sys$devpath/state'"

OK so this is not prepared for a temporary failures and retries.

> >And again, why cannot we simply make the onlining fail or try_lock and
> >retry internally if the event consumer cannot cope with errors?
> 
> Did you mean the following Srinivasan's first patch looks good to you?
>   https://lkml.org/lkml/2014/12/2/662

Heh, I was just about to post this. Because I haven't noticed the
previous patch yet. Yeah, Something like that. Except that I would
expect EAGAIN or EBUSY rather than ERESTARTSYS which should never leak
into userspace. And that would happen here AFAICS because signal_pending
will not be true usually.

So there are two options. Either make the udev rule more robust and
retry within RUN section or do the retry withing online_pages (try_lock
and go into interruptible sleep which gets signaled by finished
add_memory()). The later option is safer wrt. the userspace because the
operation wouldn't fail unexpectedly.
Another option would be generating the sysfs file after all the internal
initialization is done and call it outside of the memory hotplug lock.

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

[PATCH] staging: vt6656: Use ether_addr_copy() on vnt_private members.

2014-12-09 Thread Krzysztof Adamski 
This patch fixes checkpatch.pl warning:
WARNING: Prefer ether_addr_copy() over memcpy() if the Ethernet
addresses are __aligned(2)

current_net_addr and permanent_net_addr members of vnt_private alignment
is changed to at last 16 bits so that ether_addr_copy can be safely used
on them.

buf->data is of type ieee80211_cts which is already properly aligned.

Signed-off-by: Krzysztof Adamski 
---
 drivers/staging/vt6656/device.h   | 4 ++--
 drivers/staging/vt6656/main_usb.c | 3 ++-
 drivers/staging/vt6656/rxtx.c | 4 ++--
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/vt6656/device.h b/drivers/staging/vt6656/device.h
index 5a7ca52..4dcc67d 100644
--- a/drivers/staging/vt6656/device.h
+++ b/drivers/staging/vt6656/device.h
@@ -307,8 +307,8 @@ struct vnt_private {
 
struct vnt_cmd_card_init init_command;
struct vnt_rsp_card_init init_response;
-   u8 current_net_addr[ETH_ALEN];
-   u8 permanent_net_addr[ETH_ALEN];
+   u8 current_net_addr[ETH_ALEN] __aligned(2);
+   u8 permanent_net_addr[ETH_ALEN] __aligned(2);
 
u8 exist_sw_net_addr;
 
diff --git a/drivers/staging/vt6656/main_usb.c 
b/drivers/staging/vt6656/main_usb.c
index b95d5b1..71adc1f 100644
--- a/drivers/staging/vt6656/main_usb.c
+++ b/drivers/staging/vt6656/main_usb.c
@@ -34,6 +34,7 @@
  */
 #undef __NO_VERSION__
 
+#include 
 #include 
 #include "device.h"
 #include "card.h"
@@ -319,7 +320,7 @@ static int vnt_init_registers(struct vnt_private *priv)
 
/* get permanent network address */
memcpy(priv->permanent_net_addr, init_rsp->net_addr, 6);
-   memcpy(priv->current_net_addr, priv->permanent_net_addr, ETH_ALEN);
+   ether_addr_copy(priv->current_net_addr, priv->permanent_net_addr);
 
/* if exist SW network address, use it */
dev_dbg(&priv->usb->dev, "Network address = %pM\n",
diff --git a/drivers/staging/vt6656/rxtx.c b/drivers/staging/vt6656/rxtx.c
index 280c923..75d2c5e 100644
--- a/drivers/staging/vt6656/rxtx.c
+++ b/drivers/staging/vt6656/rxtx.c
@@ -553,7 +553,7 @@ static u16 vnt_fill_cts_head(struct vnt_usb_send_context 
*tx_context,
buf->data.frame_control =
cpu_to_le16(IEEE80211_FTYPE_CTL | IEEE80211_STYPE_CTS);
 
-   memcpy(buf->data.ra, priv->current_net_addr, ETH_ALEN);
+   ether_addr_copy(buf->data.ra, priv->current_net_addr);
 
return vnt_rxtx_datahead_g_fb(tx_context, &buf->data_head);
} else {
@@ -571,7 +571,7 @@ static u16 vnt_fill_cts_head(struct vnt_usb_send_context 
*tx_context,
buf->data.frame_control =
cpu_to_le16(IEEE80211_FTYPE_CTL | IEEE80211_STYPE_CTS);
 
-   memcpy(buf->data.ra, priv->current_net_addr, ETH_ALEN);
+   ether_addr_copy(buf->data.ra, priv->current_net_addr);
 
return vnt_rxtx_datahead_g(tx_context, &buf->data_head);
}
-- 
1.9.3

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

Re: [PATCH 1/1] [PATCH] Staging:vt6655: sparse warning fix

2014-12-09 Thread Sudip Mukherjee 
On Mon, Dec 08, 2014 at 11:33:25PM +0530, Adithya K wrote:
> From: Adithya Krishnamurthy 
> 
> Fixed sparse warning fix.

you should mention what type of warning you have fixed.

sudip
> 
> Signed-off-by: Adithya Krishnamurthy 
> ---
> ---
>  drivers/staging/vt6655/device_main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/vt6655/device_main.c 
> b/drivers/staging/vt6655/device_main.c
> index 83e4162..a3f5cd8 100644
> --- a/drivers/staging/vt6655/device_main.c
> +++ b/drivers/staging/vt6655/device_main.c
> @@ -1669,7 +1669,7 @@ static const struct ieee80211_ops vnt_mac_ops = {
>   .reset_tsf  = vnt_reset_tsf,
>  };
>  
> -int vnt_init(struct vnt_private *priv)
> +static int vnt_init(struct vnt_private *priv)
>  {
>   SET_IEEE80211_PERM_ADDR(priv->hw, priv->abyCurrentNetAddr);
>  
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

BUSINESS ENQUIRY.

2014-12-09 Thread Taylor 
BUSINESS ENQUIRY.


Hello Sir,

My company based in United Kingdom is in need of your product I will appreciate 
if you can get back to me with your grading qualities and prices , i will 
appreciate if you send me your catalog too. 
 
Sincerely, 
Mr Simon Taylor.

Address:Brierley Hill, West Midlands, DY5 1QX , 
E-mail: taylorsimon...@gmail.com
Tel:  +44-704 1803 765.
Fax: +44-208-9952 106.

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
http://www.avast.com

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

Re: [PATCH] tools: hv: kvp_daemon: make IPv6-only-injection work

2014-12-09 Thread Vitaly Kuznetsov 
Dexuan Cui  writes:

> Currently IPv6-only-injection doesn't work because the daemon doesn't parse
> any IPv6 information at all once it finds the dhcp_enabled flag is true.
>
> But according to the Hyper-v host team, the flag is only for IPv4.
> In the case the host only injects 1 IPv6 address, the dhcp flag is true, but
> we shouldn't ignore the IPv6 address and we should pass BOOTPROTO=none
> to the distro-specific script hv_set_ipconfig.
>
> Tested in Ubuntu 14.10 and RHEL7.
>
> Cc: K. Y. Srinivasan 
> Signed-off-by: Dexuan Cui 
> ---
>  tools/hv/hv_kvp_daemon.c | 47 +++
>  1 file changed, 31 insertions(+), 16 deletions(-)
>
> diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
> index 6a6432a..6ef6c04 100644
> --- a/tools/hv/hv_kvp_daemon.c
> +++ b/tools/hv/hv_kvp_daemon.c
> @@ -1145,6 +1145,9 @@ static int kvp_write_file(FILE *f, char *s1, char *s2, 
> char *s3)
>  }
>
> +/* How many ipv6 addresses the host is trying to inject? */
> +static int num_ipv6_injected;
> +
>  static int process_ip_string(FILE *f, char *ip_string, int type)
>  {
>   int error = 0;
> @@ -1190,6 +1193,7 @@ static int process_ip_string(FILE *f, char *ip_string, 
> int type)
>   switch (type) {
>   case IPADDR:
>   snprintf(str, sizeof(str), "%s", "IPV6ADDR");
> + num_ipv6_injected++;
>   break;
>   case NETMASK:
>   snprintf(str, sizeof(str), "%s", "IPV6NETMASK");
> @@ -1308,27 +1312,12 @@ static int kvp_set_ip_info(char *if_name, struct 
> hv_kvp_ipaddr_value *new_val)
>   if (error)
>   goto setval_error;
>
> - if (new_val->dhcp_enabled) {
> - error = kvp_write_file(file, "BOOTPROTO", "", "dhcp");
> - if (error)
> - goto setval_error;
> -
> - /*
> -  * We are done!.
> -  */
> - goto setval_done;
> -
> - } else {
> - error = kvp_write_file(file, "BOOTPROTO", "", "none");
> - if (error)
> - goto setval_error;
> - }
> -
>   /*
>* Write the configuration for ipaddress, netmask, gateway and
>* name servers.
>*/
>
> + num_ipv6_injected = 0;
>   error = process_ip_string(file, (char *)new_val->ip_addr, IPADDR);
>   if (error)
>   goto setval_error;
> @@ -1345,6 +1334,32 @@ static int kvp_set_ip_info(char *if_name, struct 
> hv_kvp_ipaddr_value *new_val)
>   if (error)
>   goto setval_error;
>
> + /*
> +  * Here "dhcp_enabled" is only for IPv4 according to Hyper-V host team.
> +  *
> +  * In the case the host only injects 1 IPv6 address:
> +  * new_val->dhcp_enabled is true, but we can't pass BOOTPROTO=dhcp to
> +  * the script hv_set_ifconfig, because in some distros (like RHEL7)
> +  * BOOTPROTO=dhcp has a special meaning in the config file (e.g.,
> +  * /etc/sysconfig/network-scripts/ifcfg-eth0): the network init program
> +  * ignores any static IP addr information once there is
> +  * BOOTPROTO=dhcp; as a result, IPv6-only injection can't work.
> +  *
> +  * In the case of IPv6-only injection, BOOTPROTO=dhcp doesn't affect
> +  * Ubuntu because it's ignored by the Ubuntu version of
> +  * hv_set_ifconfig and it doesn't seem to have special meaning in
> +  * Ubuntu.
> +  */

I just checked and adding "IPV6ADDR=something" when "BOOTPROTO=dhcp"
works for me with both RHEL7 and Fedora21.

Other than that I think bringing distribution specifics into kernel.git
is not a good idea. /etc/sysconfig/network-scripts/ifcfg-* format is
distro-specific and not all Linux distros support it. Moreover,
different distros can treat setting differently. I think it was wrong to
stick to this format in kvp daemon from very beginning.

As a solution I would suggest doing the following: kvp daemon writes all
received request details in distro-agnostic format in some temporary
place and then calls distro-specific script to set things up. Actually,
we already have such script: tools/hv/hv_set_ifconfig.sh

As for this bug I propose the following: remove skipping all
IPADDR/MASK/... settings in case of "BOOTPROTO=dhcp" and let
distro-specific script deal with the rest.


> + if (new_val->dhcp_enabled && num_ipv6_injected == 0) {
> + error = kvp_write_file(file, "BOOTPROTO", "", "dhcp");
> + if (error)
> + goto setval_error;
> + } else {
> + error = kvp_write_file(file, "BOOTPROTO", "", "none");
> + if (error)
> + goto setval_error;
> + }
> +
>  setval_done:
>   fclose(file);

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

[PATCH 1/1] [PATCH] Staging:vt6655: sparse warning fix

2014-12-09 Thread Adithya K 
From: Adithya Krishnamurthy 

Fixed sparse warning(symbol was not declared. Should it be static) fix.

Signed-off-by: Adithya Krishnamurthy 
---
---
 drivers/staging/vt6655/device_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vt6655/device_main.c 
b/drivers/staging/vt6655/device_main.c
index 83e4162..a3f5cd8 100644
--- a/drivers/staging/vt6655/device_main.c
+++ b/drivers/staging/vt6655/device_main.c
@@ -1669,7 +1669,7 @@ static const struct ieee80211_ops vnt_mac_ops = {
.reset_tsf  = vnt_reset_tsf,
 };
 
-int vnt_init(struct vnt_private *priv)
+static int vnt_init(struct vnt_private *priv)
 {
SET_IEEE80211_PERM_ADDR(priv->hw, priv->abyCurrentNetAddr);
 
-- 
1.9.1

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

[PATCH 0/5] Tools: hv: fix compiler warnings and do minor cleanup

2014-12-09 Thread Vitaly Kuznetsov 
When someone does 'make' in tools/hv/ issues appear:
- hv_fcopy_daemon is not being built;
- lots of compiler warnings.

This is just a cleanup. Compile-tested by myself on top of linux-next/master.

Piggyback this series and send "[PATCH 5/5] Tools: hv: do not add redundant '/'
 in hv_start_fcopy()"

Vitaly Kuznetsov (5):
  Tools: hv: add mising fcopyd to the Makefile
  Tools: hv: remove unused bytes_written from kvp_update_file()
  Tools: hv: address compiler warnings for hv_kvp_daemon.c
  Tools: hv: address compiler warnings for hv_fcopy_daemon.c
  Tools: hv: do not add redundant '/' in hv_start_fcopy()

 tools/hv/Makefile  |  4 ++--
 tools/hv/hv_fcopy_daemon.c | 10 ++
 tools/hv/hv_kvp_daemon.c   | 29 +
 3 files changed, 17 insertions(+), 26 deletions(-)

-- 
1.9.3

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

[PATCH 2/5] Tools: hv: remove unused bytes_written from kvp_update_file()

2014-12-09 Thread Vitaly Kuznetsov 
fwrite() does not actually return the number of bytes written and
this value is being ignored anyway and ferror() is being called to
check for an error. As we assign to this variable and never use it
we get the following compile-time warning:
hv_kvp_daemon.c:149:9: warning: variable ‘bytes_written’ set but not used 
[-Wunused-but-set-variable]

Remove bytes_written completely.

Signed-off-by: Vitaly Kuznetsov 
---
 tools/hv/hv_kvp_daemon.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index 6a6432a..5a274ca 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -147,7 +147,6 @@ static void kvp_release_lock(int pool)
 static void kvp_update_file(int pool)
 {
FILE *filep;
-   size_t bytes_written;
 
/*
 * We are going to write our in-memory registry out to
@@ -163,8 +162,7 @@ static void kvp_update_file(int pool)
exit(EXIT_FAILURE);
}
 
-   bytes_written = fwrite(kvp_file_info[pool].records,
-   sizeof(struct kvp_record),
+   fwrite(kvp_file_info[pool].records, sizeof(struct kvp_record),
kvp_file_info[pool].num_records, filep);
 
if (ferror(filep) || fclose(filep)) {
-- 
1.9.3

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

[PATCH 1/5] Tools: hv: add mising fcopyd to the Makefile

2014-12-09 Thread Vitaly Kuznetsov 
fcopyd in missing in the Makefile, add it there.

Signed-off-by: Vitaly Kuznetsov 
---
 tools/hv/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/hv/Makefile b/tools/hv/Makefile
index bd22f78..99ffe61 100644
--- a/tools/hv/Makefile
+++ b/tools/hv/Makefile
@@ -5,9 +5,9 @@ PTHREAD_LIBS = -lpthread
 WARNINGS = -Wall -Wextra
 CFLAGS = $(WARNINGS) -g $(PTHREAD_LIBS)
 
-all: hv_kvp_daemon hv_vss_daemon
+all: hv_kvp_daemon hv_vss_daemon hv_fcopy_daemon
 %: %.c
$(CC) $(CFLAGS) -o $@ $^
 
 clean:
-   $(RM) hv_kvp_daemon hv_vss_daemon
+   $(RM) hv_kvp_daemon hv_vss_daemon hv_fcopy_daemon
-- 
1.9.3

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

[PATCH 3/5] Tools: hv: address compiler warnings for hv_kvp_daemon.c

2014-12-09 Thread Vitaly Kuznetsov 
This patch addresses two types of compiler warnings:
... warning: comparison between signed and unsigned integer expressions 
[-Wsign-compare]
and
... warning: pointer targets in passing argument N of ‘kvp_...’ differ in 
signedness [-Wpointer-sign]

Signed-off-by: Vitaly Kuznetsov 
---
 tools/hv/hv_kvp_daemon.c | 25 -
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index 5a274ca..48a95f9 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -308,7 +308,7 @@ static int kvp_file_init(void)
return 0;
 }
 
-static int kvp_key_delete(int pool, const char *key, int key_size)
+static int kvp_key_delete(int pool, const __u8 *key, int key_size)
 {
int i;
int j, k;
@@ -351,8 +351,8 @@ static int kvp_key_delete(int pool, const char *key, int 
key_size)
return 1;
 }
 
-static int kvp_key_add_or_modify(int pool, const char *key, int key_size, 
const char *value,
-   int value_size)
+static int kvp_key_add_or_modify(int pool, const __u8 *key, int key_size,
+const __u8 *value, int value_size)
 {
int i;
int num_records;
@@ -405,7 +405,7 @@ static int kvp_key_add_or_modify(int pool, const char *key, 
int key_size, const
return 0;
 }
 
-static int kvp_get_value(int pool, const char *key, int key_size, char *value,
+static int kvp_get_value(int pool, const __u8 *key, int key_size, __u8 *value,
int value_size)
 {
int i;
@@ -437,8 +437,8 @@ static int kvp_get_value(int pool, const char *key, int 
key_size, char *value,
return 1;
 }
 
-static int kvp_pool_enumerate(int pool, int index, char *key, int key_size,
-   char *value, int value_size)
+static int kvp_pool_enumerate(int pool, int index, __u8 *key, int key_size,
+   __u8 *value, int value_size)
 {
struct kvp_record *record;
 
@@ -659,7 +659,7 @@ static char *kvp_if_name_to_mac(char *if_name)
char*p, *x;
charbuf[256];
char addr_file[256];
-   int i;
+   unsigned int i;
char *mac_addr = NULL;
 
snprintf(addr_file, sizeof(addr_file), "%s%s%s", "/sys/class/net/",
@@ -698,7 +698,7 @@ static char *kvp_mac_to_if_name(char *mac)
charbuf[256];
char *kvp_net_dir = "/sys/class/net/";
char dev_id[256];
-   int i;
+   unsigned int i;
 
dir = opendir(kvp_net_dir);
if (dir == NULL)
@@ -748,7 +748,7 @@ static char *kvp_mac_to_if_name(char *mac)
 
 
 static void kvp_process_ipconfig_file(char *cmd,
-   char *config_buf, int len,
+   char *config_buf, unsigned int len,
int element_size, int offset)
 {
char buf[256];
@@ -766,7 +766,7 @@ static void kvp_process_ipconfig_file(char *cmd,
if (offset == 0)
memset(config_buf, 0, len);
while ((p = fgets(buf, sizeof(buf), file)) != NULL) {
-   if ((len - strlen(config_buf)) < (element_size + 1))
+   if (len < strlen(config_buf) + element_size + 1)
break;
 
x = strchr(p, '\n');
@@ -914,7 +914,7 @@ static int kvp_process_ip_address(void *addrp,
 
 static int
 kvp_get_ip_info(int family, char *if_name, int op,
-void  *out_buffer, int length)
+void  *out_buffer, unsigned int length)
 {
struct ifaddrs *ifap;
struct ifaddrs *curp;
@@ -1017,8 +1017,7 @@ kvp_get_ip_info(int family, char *if_name, int op,
weight += hweight32(&w[i]);
 
sprintf(cidr_mask, "/%d", weight);
-   if ((length - sn_offset) <
-   (strlen(cidr_mask) + 1))
+   if (length < sn_offset + strlen(cidr_mask) + 1)
goto gather_ipaddr;
 
if (sn_offset == 0)
-- 
1.9.3

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

[PATCH 5/5] Tools: hv: do not add redundant '/' in hv_start_fcopy()

2014-12-09 Thread Vitaly Kuznetsov 
We don't need to add additional '/' to smsg->path_name as snprintf("%s/%s")
does the right thing. Without the patch we get doubled '//' in the log message.

Signed-off-by: Vitaly Kuznetsov 
---
 tools/hv/hv_fcopy_daemon.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/tools/hv/hv_fcopy_daemon.c b/tools/hv/hv_fcopy_daemon.c
index 1a23872..9445d8f 100644
--- a/tools/hv/hv_fcopy_daemon.c
+++ b/tools/hv/hv_fcopy_daemon.c
@@ -43,12 +43,6 @@ static int hv_start_fcopy(struct hv_start_fcopy *smsg)
int error = HV_E_FAIL;
char *q, *p;
 
-   /*
-* If possile append a path seperator to the path.
-*/
-   if (strlen((char *)smsg->path_name) < (W_MAX_PATH - 2))
-   strcat((char *)smsg->path_name, "/");
-
p = (char *)smsg->path_name;
snprintf(target_fname, sizeof(target_fname), "%s/%s",
 (char *)smsg->path_name, (char *)smsg->file_name);
-- 
1.9.3

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

[PATCH 4/5] Tools: hv: address compiler warnings for hv_fcopy_daemon.c

2014-12-09 Thread Vitaly Kuznetsov 
This patch addresses two types of compiler warnings:
... warning: unused variable ‘fd’ [-Wunused-variable]
and
... warning: format ‘%s’ expects argument of type ‘char *’, but argument 5 has 
type ‘__u16 *’ [-Wformat=]

Signed-off-by: Vitaly Kuznetsov 
---
 tools/hv/hv_fcopy_daemon.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/hv/hv_fcopy_daemon.c b/tools/hv/hv_fcopy_daemon.c
index f437d73..1a23872 100644
--- a/tools/hv/hv_fcopy_daemon.c
+++ b/tools/hv/hv_fcopy_daemon.c
@@ -51,7 +51,7 @@ static int hv_start_fcopy(struct hv_start_fcopy *smsg)
 
p = (char *)smsg->path_name;
snprintf(target_fname, sizeof(target_fname), "%s/%s",
-   (char *)smsg->path_name, smsg->file_name);
+(char *)smsg->path_name, (char *)smsg->file_name);
 
syslog(LOG_INFO, "Target file name: %s", target_fname);
/*
@@ -137,7 +137,7 @@ void print_usage(char *argv[])
 
 int main(int argc, char *argv[])
 {
-   int fd, fcopy_fd, len;
+   int fcopy_fd, len;
int error;
int daemonize = 1, long_index = 0, opt;
int version = FCOPY_CURRENT_VERSION;
-- 
1.9.3

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

Blessed Is The Hand That Giveth.

2014-12-09 Thread PATRICIA WAGNER 
Good day and God bless you.

I feel quite safe and satisfy dealing with you in this charity project.My name 
is MRS PATRICIA WAGNER , a merchant in Dubai, in the U.A.E. I have been 
diagnosed with Esophageal cancer . It has defiled all forms of medical 
treatment, and right now I have only about a few months to live, according to 
medical experts.

I have decided to give aims to charity organizations, as I want this to be one 
of the last good deeds I do on earth. So far, I have distributed money to some 
charity organizations in the U.A.E, Algeria and Malaysia. Now that my health 
has deteriorated so badly, I cannot do this myself anymore.

The last of my money which no one knows of is the huge cash deposit of TWELVE 
MILLION DOLLARS $12,000,000,that I have with a finance/Security Company abroad. 
I will want you to help me collect this deposit and dispatched it to charity 
organizations.

I have set aside 25% for you and for your time if you want to help me to 
collect this Funds and also invest this money.




Email: patwagne...@gmail.com

Remain blessed in the name of the Lord.

Yours in Christ,

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

[socfpga-nex:for_next-fpgamgr-without-overlays-v4 8/9] drivers/staging/fpga/fpga-mgr.c:46:5: sparse: symbol 'fpga_mgr_low_level_state' was not declared. Should it be static?

2014-12-09 Thread kbuild test robot 
tree:   git://git.rocketboards.org/linux-socfpga-next 
for_next-fpgamgr-without-overlays-v4
head:   590b747bfa6791797c241116453acf50bc4e5dda
commit: 356ae534a603de3aa8b1cfc173a777f59273d32e [8/9] staging: fpga manager: 
framework core
reproduce:
  # apt-get install sparse
  git checkout 356ae534a603de3aa8b1cfc173a777f59273d32e
  make ARCH=x86_64 allmodconfig
  make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/staging/fpga/fpga-mgr.c:46:5: sparse: symbol 
>> 'fpga_mgr_low_level_state' was not declared. Should it be static?
>> drivers/staging/fpga/fpga-mgr.c:324:30: sparse: symbol 'fpga_mgr_groups' was 
>> not declared. Should it be static?
>> drivers/staging/fpga/fpga-mgr.c:365:25: sparse: symbol 'fpga_mgr_dev_pm_ops' 
>> was not declared. Should it be static?

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH socfpga-nex] staging: fpga manager: fpga_mgr_low_level_state() can be static

2014-12-09 Thread kbuild test robot 
drivers/staging/fpga/fpga-mgr.c:46:5: sparse: symbol 'fpga_mgr_low_level_state' 
was not declared. Should it be static?
drivers/staging/fpga/fpga-mgr.c:324:30: sparse: symbol 'fpga_mgr_groups' was 
not declared. Should it be static?
drivers/staging/fpga/fpga-mgr.c:365:25: sparse: symbol 'fpga_mgr_dev_pm_ops' 
was not declared. Should it be static?

Signed-off-by: Fengguang Wu 
---
 fpga-mgr.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/fpga/fpga-mgr.c b/drivers/staging/fpga/fpga-mgr.c
index d08cb82..3216276 100644
--- a/drivers/staging/fpga/fpga-mgr.c
+++ b/drivers/staging/fpga/fpga-mgr.c
@@ -43,7 +43,7 @@ static LIST_HEAD(fpga_manager_list);
  *
  * This will be used to initialize framework state
  */
-int fpga_mgr_low_level_state(struct fpga_manager *mgr)
+static int fpga_mgr_low_level_state(struct fpga_manager *mgr)
 {
if (!mgr || !mgr->mops || !mgr->mops->state)
return FPGA_MGR_STATE_UNKNOWN;
@@ -321,7 +321,7 @@ static const struct attribute_group fpga_mgr_group = {
.attrs = fpga_mgr_attrs,
 };
 
-const struct attribute_group *fpga_mgr_groups[] = {
+static const struct attribute_group *fpga_mgr_groups[] = {
&fpga_mgr_group,
NULL,
 };
@@ -362,7 +362,7 @@ static int fpga_mgr_resume(struct device *dev)
return 0;
 }
 
-const struct dev_pm_ops fpga_mgr_dev_pm_ops = {
+static const struct dev_pm_ops fpga_mgr_dev_pm_ops = {
.suspend= fpga_mgr_suspend,
.resume = fpga_mgr_resume,
 };
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 0/20] fix misspelling of current function in string

2014-12-09 Thread Julian Calaby 
Hi Julia,

On Mon, Dec 8, 2014 at 5:43 PM, Julia Lawall  wrote:
> On Mon, 8 Dec 2014, Julian Calaby wrote:
>
>> Hi Julia,
>>
>> On Mon, Dec 8, 2014 at 6:20 AM, Julia Lawall  wrote:
>> > These patches replace what appears to be a reference to the name of the
>> > current function but is misspelled in some way by either the name of the
>> > function itself, or by %s and then __func__ in an argument list.
>>
>> Would there be any value in doing this for _all_ cases where the
>> function name is written in a format string?
>
> Probably.  But there are a lot of them.  Even for the misspellings, I have
> only don about 1/3 of the cases.
>
> On the other hand, the misspelling have to be checked carefully, because a
> misspelling of one thing could be the correct spelling of the thing thst
> was actually intended.
>
> Joe, however, points out that a lot of these prints are just for function
> tracing, and could be removed.  I worked on another semantic patch that
> tries to do that.  It might be better to remove those prints completely,
> rather than sending one patch to transform them and then one patch to
> remove them after that.  That is why for this series I did only the ones
> where there was actually a problem.

Ok, that makes sense.

Either way though, this is a really interesting application of the
semantic patching. Nice work!

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH 0/5] Tools: hv: fix compiler warnings and do minor cleanup

2014-12-09 Thread Dexuan Cui 
> -Original Message-
> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> Sent: Tuesday, December 9, 2014 23:48 PM
> To: KY Srinivasan
> Cc: Haiyang Zhang; de...@linuxdriverproject.org; linux-
> ker...@vger.kernel.org; Dexuan Cui
> Subject: [PATCH 0/5] Tools: hv: fix compiler warnings and do minor cleanup
> 
> When someone does 'make' in tools/hv/ issues appear:
> - hv_fcopy_daemon is not being built;
> - lots of compiler warnings.
> 
> This is just a cleanup. Compile-tested by myself on top of linux-next/master.
> 
> Piggyback this series and send "[PATCH 5/5] Tools: hv: do not add redundant
> '/'
>  in hv_start_fcopy()"
> 
> Vitaly Kuznetsov (5):
>   Tools: hv: add mising fcopyd to the Makefile
>   Tools: hv: remove unused bytes_written from kvp_update_file()
>   Tools: hv: address compiler warnings for hv_kvp_daemon.c
>   Tools: hv: address compiler warnings for hv_fcopy_daemon.c
>   Tools: hv: do not add redundant '/' in hv_start_fcopy()
> 
>  tools/hv/Makefile  |  4 ++--
>  tools/hv/hv_fcopy_daemon.c | 10 ++
>  tools/hv/hv_kvp_daemon.c   | 29 +
>  3 files changed, 17 insertions(+), 26 deletions(-)
> 
> --
> 1.9.3

Hi Vitaly,
Thanks for the patchset!

Acked-by: Dexuan Cui 

PS, I added Greg into the TO list.
The hv code in drivers/hv/ and tools/hv/ usually has to go into
Greg's tree first.

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

[PATCH] staging: vt6655: remove unused function in mac.c

2014-12-09 Thread Fred Chou 
From: Fred Chou 

Removed the unused function MACvGetShortRetryLimit, which also
fixed the following sparse warning:
drivers/staging/vt6655/mac.c:162:6: warning: 
symbol 'MACvGetShortRetryLimit' was not declared. Should it be static?

Signed-off-by: Fred Chou 
---
 drivers/staging/vt6655/mac.c | 19 ---
 1 file changed, 19 deletions(-)

diff --git a/drivers/staging/vt6655/mac.c b/drivers/staging/vt6655/mac.c
index 8f0d652..09a91d1 100644
--- a/drivers/staging/vt6655/mac.c
+++ b/drivers/staging/vt6655/mac.c
@@ -30,7 +30,6 @@
  *  MACbIsRegBitsOff - Test if All test Bits Off
  *  MACbIsIntDisable - Test if MAC interrupt disable
  *  MACvSetShortRetryLimit - Set 802.11 Short Retry limit
- *  MACvGetShortRetryLimit - Get 802.11 Short Retry limit
  *  MACvSetLongRetryLimit - Set 802.11 Long Retry limit
  *  MACvSetLoopbackMode - Set MAC Loopback Mode
  *  MACvSaveContext - Save Context of MAC Registers
@@ -146,24 +145,6 @@ void MACvSetShortRetryLimit(void __iomem *dwIoBase, 
unsigned char byRetryLimit)
VNSvOutPortB(dwIoBase + MAC_REG_SRT, byRetryLimit);
 }
 
-/*
- * Description:
- *  Get 802.11 Short Retry Limit
- *
- * Parameters:
- *  In:
- *  dwIoBase- Base Address for MAC
- *  Out:
- *  pbyRetryLimit   - Retry Limit Get
- *
- * Return Value: none
- *
- */
-void MACvGetShortRetryLimit(void __iomem *dwIoBase, unsigned char 
*pbyRetryLimit)
-{
-   // get SRT
-   VNSvInPortB(dwIoBase + MAC_REG_SRT, pbyRetryLimit);
-}
 
 /*
  * Description:
-- 
1.9.1

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

[PATCH] staging: lustre: Fix the warning messages about casting without __user macro

2014-12-09 Thread Shalin Mehta 
From: Shalin Mehta 

This issue is showed up while compiling with sparse. The iov_base in struct 
iovec struct explicitly declares that the assigned value should be user space 
pointer with __user macro. Where as here, the __user macro isn't used while 
casting.

Signed-off-by: Shalin Mehta 
---
 drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c 
b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
index d29f5f1..c40b7e0 100644
--- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
+++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
@@ -131,7 +131,7 @@ ksocknal_send_iov (ksock_conn_t *conn, ksock_tx_t *tx)
LASSERT (tx->tx_niov > 0);
 
if (nob < (int) iov->iov_len) {
-   iov->iov_base = (void *)((char *)iov->iov_base + nob);
+   iov->iov_base = (void __user *)((char __user 
*)iov->iov_base + nob);
iov->iov_len -= nob;
return rc;
}
@@ -1052,7 +1052,7 @@ ksocknal_new_packet (ksock_conn_t *conn, int nob_to_skip)
case  KSOCK_PROTO_V3:
conn->ksnc_rx_state = SOCKNAL_RX_KSM_HEADER;
conn->ksnc_rx_iov = (struct iovec 
*)&conn->ksnc_rx_iov_space;
-   conn->ksnc_rx_iov[0].iov_base = (char *)&conn->ksnc_msg;
+   conn->ksnc_rx_iov[0].iov_base = (char __user 
*)&conn->ksnc_msg;
 
conn->ksnc_rx_nob_wanted = offsetof(ksock_msg_t, ksm_u);
conn->ksnc_rx_nob_left = offsetof(ksock_msg_t, ksm_u);
@@ -1066,7 +1066,7 @@ ksocknal_new_packet (ksock_conn_t *conn, int nob_to_skip)
conn->ksnc_rx_nob_left = sizeof(lnet_hdr_t);
 
conn->ksnc_rx_iov = (struct iovec 
*)&conn->ksnc_rx_iov_space;
-   conn->ksnc_rx_iov[0].iov_base = (char 
*)&conn->ksnc_msg.ksm_u.lnetmsg;
+   conn->ksnc_rx_iov[0].iov_base = (char __user 
*)&conn->ksnc_msg.ksm_u.lnetmsg;
conn->ksnc_rx_iov[0].iov_len  = sizeof (lnet_hdr_t);
break;
 
@@ -1093,7 +1093,7 @@ ksocknal_new_packet (ksock_conn_t *conn, int nob_to_skip)
do {
nob = MIN (nob_to_skip, sizeof (ksocknal_slop_buffer));
 
-   conn->ksnc_rx_iov[niov].iov_base = ksocknal_slop_buffer;
+   conn->ksnc_rx_iov[niov].iov_base = (void __user 
*)ksocknal_slop_buffer;
conn->ksnc_rx_iov[niov].iov_len  = nob;
niov++;
skipped += nob;
@@ -1218,7 +1218,7 @@ ksocknal_process_receive (ksock_conn_t *conn)
conn->ksnc_rx_nob_left = sizeof(ksock_lnet_msg_t);
 
conn->ksnc_rx_iov = (struct iovec *)&conn->ksnc_rx_iov_space;
-   conn->ksnc_rx_iov[0].iov_base = (char 
*)&conn->ksnc_msg.ksm_u.lnetmsg;
+   conn->ksnc_rx_iov[0].iov_base = (char __user 
*)&conn->ksnc_msg.ksm_u.lnetmsg;
conn->ksnc_rx_iov[0].iov_len  = sizeof(ksock_lnet_msg_t);
 
conn->ksnc_rx_niov = 1;
-- 
1.9.1

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

Re: [PATCH] staging: lustre: Fix the warning messages about casting without __user macro

2014-12-09 Thread Al Viro 
On Tue, Dec 09, 2014 at 10:56:12PM -0800, Shalin Mehta wrote:
> From: Shalin Mehta 
> 
> This issue is showed up while compiling with sparse. The iov_base in struct 
> iovec struct explicitly declares that the assigned value should be user space 
> pointer with __user macro. Where as here, the __user macro isn't used while 
> casting.

... and pointers are not user space ones at all.  Which is to say, quit
messing with casts; it's not struct iovec.  Proper fix is to replace
it here (and in almost all places throughout drivers/staging/lustre) with
struct kvec.  And yes, such a patch had been sent.  Still not applied,
AFAICS...
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] scsi:storvsc enable reading from VPD pages on SPC-2

2014-12-09 Thread Long Li 
MSFT targets currently claim SPC-2 compliance while they implement post SPC-2 
features. With this patch we can correctly handle WRITE_SAME_16 issues.

This patch fixes an issue where the flag is setup too late in drive 
initialization process.

Reviewed-by: K. Y. Srinivasan 
Signed-off-by: Long Li 
---
 drivers/scsi/scsi_devinfo.c |  1 +
 drivers/scsi/storvsc_drv.c  | 10 --
 2 files changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/scsi/scsi_devinfo.c b/drivers/scsi/scsi_devinfo.c
index c1d04d4..f6fe0b2 100644
--- a/drivers/scsi/scsi_devinfo.c
+++ b/drivers/scsi/scsi_devinfo.c
@@ -211,6 +211,7 @@ static struct {
{"Medion", "Flash XL  MMC/SD", "2.6D", BLIST_FORCELUN},
{"MegaRAID", "LD", NULL, BLIST_FORCELUN},
{"MICROP", "4110", NULL, BLIST_NOTQ},
+   {"Msft", "Virtual Disk", "1.0", BLIST_TRY_VPD_PAGES},
{"MYLEX", "DACARMRB", "*", BLIST_REPORTLUN2},
{"nCipher", "Fastness Crypto", NULL, BLIST_FORCELUN},
{"NAKAMICH", "MJ-4.8S", NULL, BLIST_FORCELUN | BLIST_SINGLELUN},
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index e3ba251..2452bb4 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -327,8 +327,6 @@ MODULE_PARM_DESC(storvsc_ringbuffer_size, "Ring buffer size 
(bytes)");
  */
 static int storvsc_timeout = 180;
 
-static int msft_blist_flags = BLIST_TRY_VPD_PAGES;
-
 #define STORVSC_MAX_IO_REQUESTS200
 
 static void storvsc_on_channel_callback(void *context);
@@ -1439,14 +1437,6 @@ static int storvsc_device_configure(struct scsi_device 
*sdevice)
 
sdevice->no_write_same = 1;
 
-   /*
-* Add blist flags to permit the reading of the VPD pages even when
-* the target may claim SPC-2 compliance. MSFT targets currently
-* claim SPC-2 compliance while they implement post SPC-2 features.
-* With this patch we can correctly handle WRITE_SAME_16 issues.
-*/
-   sdevice->sdev_bflags |= msft_blist_flags;
-
return 0;
 }
 
-- 
2.1.0

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

RE: [PATCH] tools: hv: kvp_daemon: make IPv6-only-injection work

2014-12-09 Thread Dexuan Cui 
> -Original Message-
> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> Sent: Tuesday, December 9, 2014 21:06 PM
> To: Dexuan Cui
> Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; driverdev-
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> jasow...@redhat.com; KY Srinivasan; Haiyang Zhang
> Subject: Re: [PATCH] tools: hv: kvp_daemon: make IPv6-only-injection work
>  ..
> > +* Here "dhcp_enabled" is only for IPv4 according to Hyper-V host
> team.
> > +*
> > +* In the case the host only injects 1 IPv6 address:
> > +* new_val->dhcp_enabled is true, but we can't pass
> BOOTPROTO=dhcp to
> > +* the script hv_set_ifconfig, because in some distros (like RHEL7)
> > +* BOOTPROTO=dhcp has a special meaning in the config file (e.g.,
> > +* /etc/sysconfig/network-scripts/ifcfg-eth0): the network init
> program
> > +* ignores any static IP addr information once there is
> > +* BOOTPROTO=dhcp; as a result, IPv6-only injection can't work.
> > +*
> > +* In the case of IPv6-only injection, BOOTPROTO=dhcp doesn't affect
> > +* Ubuntu because it's ignored by the Ubuntu version of
> > +* hv_set_ifconfig and it doesn't seem to have special meaning in
> > +* Ubuntu.
> > +*/
> 
> I just checked and adding "IPV6ADDR=something" when "BOOTPROTO=dhcp"
> works for me with both RHEL7 and Fedora21.
It doesn't work in my side. :-(
Running 'ifup eth0' shows some errors(I use "set -x")
...
+ /sbin/dhclient -H localhost -1 -q -lf /var/lib/dhclient/dhclient--eth0.lease 
-pf /var/run/dhclient-eth0.pid eth0
grep: /etc/sysconfig/network-scripts/ifcfg-eth0: Permission dinied.
grep: /etc/sysconfig/network-scripts/ifcfg-eth0: Permission dinied.
grep: /etc/sysconfig/network-scripts/ifcfg-eth0: Permission dinied.
grep: /etc/sysconfig/network-scripts/ifcfg-eth0: Permission dinied.
grep: /etc/sysconfig/network-scripts/ifcfg-eth0: Permission dinied.
grep: /etc/sysconfig/network-scripts/ifcfg-eth0: Permission dinied.
done.

I'm trying to find out the cause.

> Other than that I think bringing distribution specifics into kernel.git
> is not a good idea. /etc/sysconfig/network-scripts/ifcfg-* format is
> distro-specific and not all Linux distros support it. Moreover,
I agree.

> different distros can treat setting differently. I think it was wrong to
> stick to this format in kvp daemon from very beginning.
We can also think the current format used in kvp daemon is already
distro-agnostic -- it just happens to look like the style of network config file
used in RHEL :-)

> 
> As a solution I would suggest doing the following: kvp daemon writes all
> received request details in distro-agnostic format in some temporary
> place and then calls distro-specific script to set things up. Actually,
> we already have such script: tools/hv/hv_set_ifconfig.sh
Yeah, this is exactly what we already have today.

> As for this bug I propose the following: remove skipping all
> IPADDR/MASK/... settings in case of "BOOTPROTO=dhcp" and let
> distro-specific script deal with the rest.
> --
>   Vitaly
OK, so the patch would be 1-line only:

diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index 22b0764..53fdaad 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -1314,10 +1314,8 @@ static int kvp_set_ip_info(char *if_name, struct 
hv_kvp_ipaddr_value *new_val)
goto setval_error;

/*
-* We are done!.
+* We are not done... TODO: add comment here.
 */
-   goto setval_done;
-
} else {
error = kvp_write_file(file, "BOOTPROTO", "", "none");
if (error)

I'll send out a v2 after I resolve the "grep ... Permission dinied" issue.

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

RE: [PATCH] tools: hv: kvp_daemon: make IPv6-only-injection work

2014-12-09 Thread Dexuan Cui 


Thanks,
-- Dexuan

> -Original Message-
> From: Dexuan Cui
> Sent: Wednesday, December 10, 2014 15:34 PM
> To: 'Vitaly Kuznetsov'
> Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; driverdev-
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> jasow...@redhat.com; KY Srinivasan; Haiyang Zhang
> Subject: RE: [PATCH] tools: hv: kvp_daemon: make IPv6-only-injection work
> 
> > -Original Message-
> > From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> > Sent: Tuesday, December 9, 2014 21:06 PM
> > To: Dexuan Cui
> > Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; driverdev-
> > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> > jasow...@redhat.com; KY Srinivasan; Haiyang Zhang
> > Subject: Re: [PATCH] tools: hv: kvp_daemon: make IPv6-only-injection work
> >  ..
> > > +  * Here "dhcp_enabled" is only for IPv4 according to Hyper-V host
> > team.
> > > +  *
> > > +  * In the case the host only injects 1 IPv6 address:
> > > +  * new_val->dhcp_enabled is true, but we can't pass
> > BOOTPROTO=dhcp to
> > > +  * the script hv_set_ifconfig, because in some distros (like RHEL7)
> > > +  * BOOTPROTO=dhcp has a special meaning in the config file (e.g.,
> > > +  * /etc/sysconfig/network-scripts/ifcfg-eth0): the network init
> > program
> > > +  * ignores any static IP addr information once there is
> > > +  * BOOTPROTO=dhcp; as a result, IPv6-only injection can't work.
> > > +  *
> > > +  * In the case of IPv6-only injection, BOOTPROTO=dhcp doesn't affect
> > > +  * Ubuntu because it's ignored by the Ubuntu version of
> > > +  * hv_set_ifconfig and it doesn't seem to have special meaning in
> > > +  * Ubuntu.
> > > +  */
> >
> > I just checked and adding "IPV6ADDR=something" when
> "BOOTPROTO=dhcp"
> > works for me with both RHEL7 and Fedora21.
> It doesn't work in my side. :-(
> Running 'ifup eth0' shows some errors(I use "set -x")
> ...
> + /sbin/dhclient -H localhost -1 -q -lf 
> /var/lib/dhclient/dhclient--eth0.lease -pf
> /var/run/dhclient-eth0.pid eth0
> grep: /etc/sysconfig/network-scripts/ifcfg-eth0: Permission dinied.
BTW, I run with root, and
'chown 777 /etc/sysconfig/network-scripts/ifcfg-eth0" doesn't help.

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