Re: [PATCH] media: bcm2048: remove unused return of function

[Pali Rohár]

On Sunday 08 February 2015 23:29:11 Luis de Bethencourt wrote:
> Integer return of bcm2048_parse_rds_rt () is never used,
> changing the return type to void.
> 
> Signed-off-by: Luis de Bethencourt 
> ---
>  drivers/staging/media/bcm2048/radio-bcm2048.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 

Looks good,

Acked-by: Pali Rohár 

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: lustre: use linux headers

[Asaf Vertz]

WARNING: Use #include  instead of 
WARNING: Use #include  instead of 
WARNING: Use #include  instead of 

Signed-off-by: Asaf Vertz 
---
 .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h|2 +-
 .../lustre/lnet/klnds/socklnd/socklnd_lib-linux.h  |2 +-
 .../lustre/lustre/libcfs/linux/linux-debug.c   |2 +-
 .../lustre/lustre/libcfs/linux/linux-prim.c|2 +-
 .../lustre/lustre/libcfs/linux/linux-proc.c|2 +-
 drivers/staging/lustre/lustre/llite/dir.c  |2 +-
 drivers/staging/lustre/lustre/llite/llite_mmap.c   |2 +-
 drivers/staging/lustre/lustre/llite/lloop.c|3 +--
 drivers/staging/lustre/lustre/llite/rw.c   |2 +-
 drivers/staging/lustre/lustre/llite/rw26.c |2 +-
 drivers/staging/lustre/lustre/lmv/lmv_obd.c|2 +-
 drivers/staging/lustre/lustre/lov/lproc_lov.c  |2 +-
 drivers/staging/lustre/lustre/osc/lproc_osc.c  |2 +-
 13 files changed, 13 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h 
b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h
index ab128de..cd664d0 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h
@@ -46,8 +46,8 @@
 #include 
 #include 
 #include 
+#include 
 
-#include 
 #include 
 
 #include 
diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib-linux.h 
b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib-linux.h
index 7a793d2..f556388 100644
--- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib-linux.h
+++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib-linux.h
@@ -50,8 +50,8 @@
 #include 
 #include 
 #include 
+#include 
 
-#include 
 #include 
 
 #include 
diff --git a/drivers/staging/lustre/lustre/libcfs/linux/linux-debug.c 
b/drivers/staging/lustre/lustre/libcfs/linux/linux-debug.c
index 12005a7..4545d54 100644
--- a/drivers/staging/lustre/lustre/libcfs/linux/linux-debug.c
+++ b/drivers/staging/lustre/lustre/libcfs/linux/linux-debug.c
@@ -50,7 +50,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 # define DEBUG_SUBSYSTEM S_LNET
diff --git a/drivers/staging/lustre/lustre/libcfs/linux/linux-prim.c 
b/drivers/staging/lustre/lustre/libcfs/linux/linux-prim.c
index 19f405e..fde2819 100644
--- a/drivers/staging/lustre/lustre/libcfs/linux/linux-prim.c
+++ b/drivers/staging/lustre/lustre/libcfs/linux/linux-prim.c
@@ -43,7 +43,7 @@
 #include "../../../include/linux/libcfs/libcfs.h"
 
 #if defined(CONFIG_KGDB)
-#include 
+#include 
 #endif
 
 /**
diff --git a/drivers/staging/lustre/lustre/libcfs/linux/linux-proc.c 
b/drivers/staging/lustre/lustre/libcfs/linux/linux-proc.c
index c539e37..0f65929 100644
--- a/drivers/staging/lustre/lustre/libcfs/linux/linux-proc.c
+++ b/drivers/staging/lustre/lustre/libcfs/linux/linux-proc.c
@@ -50,7 +50,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 #include 
 #include 
diff --git a/drivers/staging/lustre/lustre/llite/dir.c 
b/drivers/staging/lustre/lustre/llite/dir.c
index babba60..e70d5bd 100644
--- a/drivers/staging/lustre/lustre/llite/dir.c
+++ b/drivers/staging/lustre/lustre/llite/dir.c
@@ -41,7 +41,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include/* for wait_on_buffer */
 #include 
 #include 
diff --git a/drivers/staging/lustre/lustre/llite/llite_mmap.c 
b/drivers/staging/lustre/lustre/llite/llite_mmap.c
index 479bf42..ab07959 100644
--- a/drivers/staging/lustre/lustre/llite/llite_mmap.c
+++ b/drivers/staging/lustre/lustre/llite/llite_mmap.c
@@ -40,7 +40,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 #include 
diff --git a/drivers/staging/lustre/lustre/llite/lloop.c 
b/drivers/staging/lustre/lustre/llite/lloop.c
index 0312488..cec9254 100644
--- a/drivers/staging/lustre/lustre/llite/lloop.c
+++ b/drivers/staging/lustre/lustre/llite/lloop.c
@@ -100,8 +100,7 @@
 #include 
 #include 
 #include 
-
-#include 
+#include 
 
 #include "../include/lustre_lib.h"
 #include "../include/lustre_lite.h"
diff --git a/drivers/staging/lustre/lustre/llite/rw.c 
b/drivers/staging/lustre/lustre/llite/rw.c
index 10a0421..8884a43 100644
--- a/drivers/staging/lustre/lustre/llite/rw.c
+++ b/drivers/staging/lustre/lustre/llite/rw.c
@@ -45,7 +45,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 #include 
diff --git a/drivers/staging/lustre/lustre/llite/rw26.c 
b/drivers/staging/lustre/lustre/llite/rw26.c
index 2f21304..91442fa 100644
--- a/drivers/staging/lustre/lustre/llite/rw26.c
+++ b/drivers/staging/lustre/lustre/llite/rw26.c
@@ -44,7 +44,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 #include 
diff --git a/drivers/staging/lustre/lustre/lmv/lmv_obd.c 
b/drivers/staging/lustre/lustre/lmv/lmv_obd.c
index b779f47..403e9f5 100644
--- a/drivers/staging/lustre/lustre/lmv/lmv_obd.c
+++ b/drivers/staging/lustre/lustre/lmv/lmv_obd.c
@@ -43,7 +43,7 @@
 #include 
 #include 
 #include 
-#include 
+#

Re: [PATCH v3 20/20] arm: mach-pxa: Decrement the power supply's device reference counter

[Krzysztof Kozlowski]

On pią, 2015-02-06 at 15:59 +0100, Pavel Machek wrote:
> On Fri 2015-02-06 15:43:08, Krzysztof Kozlowski wrote:
> > On pią, 2015-02-06 at 14:49 +0100, Pavel Machek wrote:
> > > On Fri 2015-01-30 15:47:58, Krzysztof Kozlowski wrote:
> > > > Use power_supply_put() to decrement the power supply's device reference
> > > > counter.
> > > > 
> > > > Signed-off-by: Krzysztof Kozlowski 
> > > > Reviewed-by: Bartlomiej Zolnierkiewicz 
> > > > Reviewed-by: Sebastian Reichel 
> > > 
> > > 11,13,20 nothing obviously wrong. But I'm not sure if I studied them
> > > closely enough to warrant an ACK.
> > > 
> > > It would be good to get this into kernel -- I seen no bad comments,
> > > and it is not going to improve without merge into mainline.
> > 
> > Thanks for looking at patchset. It would be really nice if this could be
> > tested for some time in linux-next. Such testing would help a lot. But I
> > need acks from various maintainers for that.
> 
> Actually, you don't. The various maintainers clearly don't care at
> this point. They had enough time. So you select one maintainer you
> want to push this through, and you push it.
> 
> Someone may complain, so you'll solve the feedback...

I am thinking also on another way of solving this huge-patch problem:
1. Mark all drivers broken (CONFIG_BROKEN).
2. Introduce change in power_supply_register() API. Broken drivers
   will fail to build.
3. Convert broken drivers to new API incrementally (one driver
   per patch) marking them also non-broken.

This would be much easier to review but also this would break
build-bisectability for drivers and some platforms using them (like
OLPC, compal-laptop, ACPI).

In case of important platforms (like ACPI) I could do the old-way:
change the driver along with API change.

What do you think about this?


I pushed the patchset here:
https://git.linaro.org/people/marek.szyprowski/linux-srpol.git/shortlog/refs/heads/v3.19-next-power-supply-core-ownership
(actually this is v4: added acks/reviews and minor issue fixed; merge
window has opened so I'll wait with sending this to LKML).


Best regards,
Krzysztof



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

Re: [PATCH] staging:lustre:libcfs:linux: Define insert_proc and remove_proc in separate header file

[Matt Tyler]

On Sun, Feb 08, 2015 at 09:44:43PM +0800, Greg KH wrote:
> On Sun, Feb 08, 2015 at 09:26:15PM +0800, Matthew Tyler wrote:
> > Sparse is currently throwing warnings as insert_proc and remove_proc
> > are not defined. 
> > 
> > The patch adds definitions for these files in a suitable header file.
> > 
> > These only seem to be exported by one location - libcfs/module.c
> > 
> > Can we remove the export and import from the header? 
> 
> Why not just move the functions to that one .c file that uses it, and
> make them static?  That would be easier and would get rid of a horrid
> global symbol name.
> 
> thanks,
> 
> greg k-h

It looks like it is primarily for separation of concerns; those two 
functions register a table full of proc handlers which are defined
in their current parent file.

We could merge the two files and remove the global symbol name?

Or is better to maintain the separation of functionality, and create 
an extra header?

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

Re: [PATCH] staging:lustre:libcfs:linux: Define insert_proc and remove_proc in separate header file

[Greg KH]

On Mon, Feb 09, 2015 at 07:47:48PM +0800, Matt Tyler wrote:
> On Sun, Feb 08, 2015 at 09:44:43PM +0800, Greg KH wrote:
> > On Sun, Feb 08, 2015 at 09:26:15PM +0800, Matthew Tyler wrote:
> > > Sparse is currently throwing warnings as insert_proc and remove_proc
> > > are not defined. 
> > > 
> > > The patch adds definitions for these files in a suitable header file.
> > > 
> > > These only seem to be exported by one location - libcfs/module.c
> > > 
> > > Can we remove the export and import from the header? 
> > 
> > Why not just move the functions to that one .c file that uses it, and
> > make them static?  That would be easier and would get rid of a horrid
> > global symbol name.
> > 
> > thanks,
> > 
> > greg k-h
> 
> It looks like it is primarily for separation of concerns; those two 
> functions register a table full of proc handlers which are defined
> in their current parent file.
> 
> We could merge the two files and remove the global symbol name?
> 
> Or is better to maintain the separation of functionality, and create 
> an extra header?

Merge it, especially given how far apart in the tree the two files are,
they don't have any obvious linkage like putting it in one file will
show.

thanks,

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

[PATCH] staging: lustre: lnet: lnet: lip-ptl:fix sparse warning of static declaration

[Mohammad Jamal]

This patch adds a static keyword to variable portal_rotor to
suppress the sparse warning of static declaration

Signed-off-by: Mohammad Jamal 
---
 drivers/staging/lustre/lnet/lnet/lib-ptl.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lnet/lnet/lib-ptl.c 
b/drivers/staging/lustre/lnet/lnet/lib-ptl.c
index 19ed696..6652036 100644
--- a/drivers/staging/lustre/lnet/lnet/lib-ptl.c
+++ b/drivers/staging/lustre/lnet/lnet/lib-ptl.c
@@ -39,7 +39,7 @@
 #include "../../include/linux/lnet/lib-lnet.h"
 
 /* NB: add /proc interfaces in upcoming patches */
-intportal_rotor= LNET_PTL_ROTOR_HASH_RT;
+static int portal_rotor= LNET_PTL_ROTOR_HASH_RT;
 module_param(portal_rotor, int, 0644);
 MODULE_PARM_DESC(portal_rotor, "redirect PUTs to different cpu-partitions");
 
-- 
1.7.9.5

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

Re: [PATCH] staging: lustre: lnet: lnet: lip-ptl:fix sparse warning of static declaration

[Joe Perches]

On Mon, 2015-02-09 at 21:45 +0530, Mohammad Jamal wrote:
> This patch adds a static keyword to variable portal_rotor to
> suppress the sparse warning of static declaration

Do please compile the subsystem before sending patches.

> diff --git a/drivers/staging/lustre/lnet/lnet/lib-ptl.c 
> b/drivers/staging/lustre/lnet/lnet/lib-ptl.c
[]
> @@ -39,7 +39,7 @@
>  #include "../../include/linux/lnet/lib-lnet.h"
>  
>  /* NB: add /proc interfaces in upcoming patches */
> -int  portal_rotor= LNET_PTL_ROTOR_HASH_RT;
> +static int   portal_rotor= LNET_PTL_ROTOR_HASH_RT;
>  module_param(portal_rotor, int, 0644);
>  MODULE_PARM_DESC(portal_rotor, "redirect PUTs to different cpu-partitions");

$ git grep -w portal_rotor
...
drivers/staging/lustre/lnet/lnet/router_proc.c:extern int portal_rotor;



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

Re: [PATCH v3] staging: lustre: fix coding style errors

[Tal Shorer]

Fix the following coding style errors in
drivers/staging/lustre/lustre/libcfs/linux/linux-proc.c:
1. initializing lnet_table_header (static pointer) to NULL
2. missing spaces around '='

There's a third coding style error in this file which I've chosen to
not fix for clarity's sake. It is: initializing min_watchdog_ratelimit
(static int) to 0

Signed-off-by: Tal Shorer 
---

drivers/staging/lustre/lustre/
libcfs/linux/linux-proc.c | 4 ++--

1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lustre/libcfs/linux/linux-proc.c
b/drivers/staging/lustre/lustre/libcfs/linux/linux-proc.c
index c539e37..acc2e10 100644
--- a/drivers/staging/lustre/lustre/libcfs/linux/linux-proc.c
+++ b/drivers/staging/lustre/lustre/libcfs/linux/linux-proc.c
@@ -65,7 +65,7 @@
#include 
#include "../tracefile.h"

-static struct ctl_table_header *lnet_table_header = NULL;
+static struct ctl_table_header *lnet_table_header;
extern char lnet_upcall[1024];
/**
  * The path of debug log dump upcall script.
@@ -308,7 +308,7 @@ static int proc_console_backoff(struct ctl_table
*table, int write,
dummy.proc_handler = &proc_dointvec;

if (!write) { /* read */
-   backoff= libcfs_console_backoff;
+   backoff = libcfs_console_backoff;
rc = proc_dointvec(&dummy, write, buffer, lenp, ppos);
return rc;
}
--
2.2.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 04/20] power_supply: sysfs: Use power_supply_*() API for accessing function attrs

[Stefan Wahren]

Hi Krzysztof,

> Krzysztof Kozlowski  hat am 30. Januar 2015 um 15:47
> geschrieben:
>
>
> Replace direct calls to power supply function attributes with wrappers.
> Wrappers provide safe access in case of unregistering the power
> supply (e.g. by removing the driver). Replace:
> - get_property -> power_supply_get_property
> - set_property -> power_supply_set_property
> - property_is_writeable -> power_supply_property_is_writeable
>
> Signed-off-by: Krzysztof Kozlowski 
> Acked-by: Jonghwa Lee 

just a nit. It looks like a typo in the mail address which is also in patch 5 -
10.

I applied patch 1 - 14 to my repo with a upcoming power driver (mxs_power) and
didn't see any problems with your patches.

Stefan

> Acked-by: Pavel Machek 
> Reviewed-by: Bartlomiej Zolnierkiewicz 
> Reviewed-by: Sebastian Reichel 
> ---
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH fix for v3.20] staging: vt6655: vnt_tx_packet fix dma_idx selection.

[Malcolm Priestley]

There is still a problem that dma_idx is causing packets to
go onto the wrong tx path.

Protect dma_idx fully with the present first lock and
use pTDInfo->byFlags TD_FLAGS_NETIF_SKB to set MACvTransmit.

Signed-off-by: Malcolm Priestley 
---
 drivers/staging/vt6655/device_main.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/vt6655/device_main.c 
b/drivers/staging/vt6655/device_main.c
index 4324282..f5c5872 100644
--- a/drivers/staging/vt6655/device_main.c
+++ b/drivers/staging/vt6655/device_main.c
@@ -1187,12 +1187,14 @@ static int vnt_tx_packet(struct vnt_private *priv, 
struct sk_buff *skb)
 {
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
PSTxDesc head_td;
-   u32 dma_idx = TYPE_AC0DMA;
+   u32 dma_idx;
unsigned long flags;
 
spin_lock_irqsave(&priv->lock, flags);
 
-   if (!ieee80211_is_data(hdr->frame_control))
+   if (ieee80211_is_data(hdr->frame_control))
+   dma_idx = TYPE_AC0DMA;
+   else
dma_idx = TYPE_TXDMA0;
 
if (AVAIL_TD(priv, dma_idx) < 1) {
@@ -1206,6 +1208,9 @@ static int vnt_tx_packet(struct vnt_private *priv, struct 
sk_buff *skb)
 
head_td->pTDInfo->skb = skb;
 
+   if (dma_idx == TYPE_AC0DMA)
+   head_td->pTDInfo->byFlags = TD_FLAGS_NETIF_SKB;
+
priv->iTDUsed[dma_idx]++;
 
/* Take ownership */
@@ -1234,13 +1239,10 @@ static int vnt_tx_packet(struct vnt_private *priv, 
struct sk_buff *skb)
 
head_td->buff_addr = cpu_to_le32(head_td->pTDInfo->skb_dma);
 
-   if (dma_idx == TYPE_AC0DMA) {
-   head_td->pTDInfo->byFlags = TD_FLAGS_NETIF_SKB;
-
+   if (head_td->pTDInfo->byFlags & TD_FLAGS_NETIF_SKB)
MACvTransmitAC0(priv->PortOffset);
-   } else {
+   else
MACvTransmit0(priv->PortOffset);
-   }
 
spin_unlock_irqrestore(&priv->lock, flags);
 
-- 
2.1.0

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

Re: [PATCH v3] staging: lustre: fix coding style errors

On Mon, Feb 09, 2015 at 07:20:30PM +0200, Tal Shorer wrote:
> Fix the following coding style errors in
> drivers/staging/lustre/lustre/libcfs/linux/linux-proc.c:
> 1. initializing lnet_table_header (static pointer) to NULL
> 2. missing spaces around '='

Those are two different things, and should be 2 different patches.
Please split up and resend that way.

> There's a third coding style error in this file which I've chosen to
> not fix for clarity's sake. It is: initializing min_watchdog_ratelimit
> (static int) to 0

Please fix that too, it's not correct.  Drop the comment there if you
think that's confusing.

thanks,

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

Re: [PATCH 1/2] staging: unisys: remove unused variable

[Greg Kroah-Hartman]

On Sun, Feb 08, 2015 at 04:31:07PM +0530, Sudip Mukherjee wrote:
> On Sat, Feb 07, 2015 at 05:22:16PM +0800, Greg Kroah-Hartman wrote:
> > On Fri, Feb 06, 2015 at 06:13:21PM +0530, Sudip Mukherjee wrote:
> > > we were getting lots of warnings about _tempresult set but not used.
> > > _tempresult was used in the macro ISSUE_IO_VMCALL_POSTCODE_SEVERITY
> > > which was again using another macro ISSUE_IO_EXTENDED_VMCALL.
> > > but the vallue assigned to it was never used.
> > > 
> > > Signed-off-by: Sudip Mukherjee 
> > 
> > Your From: address, and this address don't match, so I can't take this
> > :(
> 
> all my patches have been like this way, and you have taken them before :)
> the reason its like this way - (already discussed with Dan Carpenter, 
> reference https://lkml.org/lkml/2014/9/3/473)
> 
> we have strict DMARC check for the corporate mail server. DMARC = domain 
> based message authentication.
> So the mail i sent reached all the list subscriber from a different server 
> than our designated server,
> and as a result it is marked as spam in many places and I have already 
> received a few complaints regarding that.
> 
> so at https://lkml.org/lkml/2014/9/3/535 Dan said its ok for him, but depends 
> on you if you want to accept.
> And since you have accepted all my patches before so i thought it is ok with 
> you.

I didn't notice it before, sorry.

> if you want I can add an extra From: line, but Dan has already given his 
> commments for that at https://lkml.org/lkml/2014/9/3/135
> quoting him :
> 
> "If everyone starts using From headers like this then it becomes a pain to 
> deal with."

It's not a pain to deal with on my end at all.

But as I've missed this in the past, nevermind, I'll take it as is.  Can
you resend your outstanding patches and I'll queue them up after
3.20-rc1 is out.

thanks,

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

[PATCH 0/6] staging: rtl8723au: Further cleanups

[Jes . Sorensen]

From: Jes Sorensen 

Hi,

A couple more cleanups for the rtl8723au driver.

Cheers,
Jes


Jes Sorensen (6):
  staging: rtl8723au: Use RF_AC instead of hardcoded value for RF
register write
  staging: rtl8723au: rates are always set via the firmware interface
  staging: rtl8723au: rtl8723a_add_rateatid() simplyfy code
  staging: rtl8723au: Remove more unused #defines
  staging: rtl8723au: hal_com.h: Remove some unused #defines
  staging: rtl8723au: Firmware always handles adaptive rates

 drivers/staging/rtl8723au/hal/odm.c| 15 +
 .../staging/rtl8723au/hal/rtl8723a_bt-coexist.c| 28 ++--
 drivers/staging/rtl8723au/hal/rtl8723a_cmd.c   | 24 +++---
 drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c  |  1 -
 drivers/staging/rtl8723au/hal/usb_halinit.c| 37 +++---
 drivers/staging/rtl8723au/include/hal_com.h| 30 --
 drivers/staging/rtl8723au/include/ieee80211.h  | 14 
 drivers/staging/rtl8723au/include/odm.h|  3 --
 drivers/staging/rtl8723au/include/rtl8723a_hal.h   |  1 -
 9 files changed, 27 insertions(+), 126 deletions(-)

-- 
2.1.0

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

[PATCH 3/6] staging: rtl8723au: rtl8723a_add_rateatid() simplyfy code

[Jes . Sorensen]

From: Jes Sorensen 

No point shifting raid right, just to shift it left again before
re-adding it.

Signed-off-by: Jes Sorensen 
---
 drivers/staging/rtl8723au/hal/rtl8723a_cmd.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c 
b/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
index 0b77ee1..3304e55 100644
--- a/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
+++ b/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
@@ -142,16 +142,16 @@ int rtl8723a_set_raid_cmd(struct rtw_adapter *padapter, 
u32 mask, u8 arg)
 /* arg[5] = Short GI */
 void rtl8723a_add_rateatid(struct rtw_adapter *pAdapter, u32 bitmap, u8 arg, 
u8 rssi_level)
 {
-   struct hal_data_8723a   *pHalData = GET_HAL_DATA(pAdapter);
-   u8 macid = arg&0x1f;
-   u8 raid = (bitmap>>28) & 0x0f;
+   struct hal_data_8723a *pHalData = GET_HAL_DATA(pAdapter);
+   u8 macid = arg & 0x1f;
+   u32 raid = bitmap & 0xf000;
 
bitmap &= 0x0fff;
if (rssi_level != DM_RATR_STA_INIT)
bitmap = ODM_Get_Rate_Bitmap23a(pHalData, macid, bitmap,
rssi_level);
 
-   bitmap |= ((raid<<28)&0xf000);
+   bitmap |= raid;
 
rtl8723a_set_raid_cmd(pAdapter, bitmap, arg);
 }
-- 
2.1.0

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

[PATCH 5/6] staging: rtl8723au: hal_com.h: Remove some unused #defines

[Jes . Sorensen]

From: Jes Sorensen 

Signed-off-by: Jes Sorensen 
---
 drivers/staging/rtl8723au/include/hal_com.h | 30 -
 1 file changed, 30 deletions(-)

diff --git a/drivers/staging/rtl8723au/include/hal_com.h 
b/drivers/staging/rtl8723au/include/hal_com.h
index 7c31865..e946c4b 100644
--- a/drivers/staging/rtl8723au/include/hal_com.h
+++ b/drivers/staging/rtl8723au/include/hal_com.h
@@ -65,36 +65,6 @@
 #define RATE_36M   BIT(9)
 #define RATE_48M   BIT(10)
 #define RATE_54M   BIT(11)
-/* MCS 1 Spatial Stream */
-#define RATE_MCS0  BIT(12)
-#define RATE_MCS1  BIT(13)
-#define RATE_MCS2  BIT(14)
-#define RATE_MCS3  BIT(15)
-#define RATE_MCS4  BIT(16)
-#define RATE_MCS5  BIT(17)
-#define RATE_MCS6  BIT(18)
-#define RATE_MCS7  BIT(19)
-/* MCS 2 Spatial Stream */
-#define RATE_MCS8  BIT(20)
-#define RATE_MCS9  BIT(21)
-#define RATE_MCS10 BIT(22)
-#define RATE_MCS11 BIT(23)
-#define RATE_MCS12 BIT(24)
-#define RATE_MCS13 BIT(25)
-#define RATE_MCS14 BIT(26)
-#define RATE_MCS15 BIT(27)
-
-/*  ALL CCK Rate */
-#defineRATE_ALL_CCK(RATR_1M | RATR_2M | RATR_55M | RATR_11M)
-#defineRATE_ALL_OFDM_AG\
-   (RATR_6M | RATR_9M | RATR_12M | RATR_18M | RATR_24M| \
-RATR_36M|RATR_48M|RATR_54M)
-#defineRATE_ALL_OFDM_1SS   \
-   (RATR_MCS0 | RATR_MCS1 | RATR_MCS2 | RATR_MCS3 |\
-RATR_MCS4 | RATR_MCS5 | RATR_MCS6 | RATR_MCS7)
-#defineRATE_ALL_OFDM_2SS   \
-   (RATR_MCS8 | RATR_MCS9 | RATR_MCS10 | RATR_MCS11|   \
-RATR_MCS12 | RATR_MCS13 | RATR_MCS14 | RATR_MCS15)
 
 /*-- Tx Desc definition Macro 
*/
 /* pragma mark -- Tx Desc related definition. -- */
-- 
2.1.0

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

[PATCH 4/6] staging: rtl8723au: Remove more unused #defines

[Jes . Sorensen]

From: Jes Sorensen 

Signed-off-by: Jes Sorensen 
---
 drivers/staging/rtl8723au/include/ieee80211.h | 14 --
 1 file changed, 14 deletions(-)

diff --git a/drivers/staging/rtl8723au/include/ieee80211.h 
b/drivers/staging/rtl8723au/include/ieee80211.h
index cb23cd0..3caf4f5 100644
--- a/drivers/staging/rtl8723au/include/ieee80211.h
+++ b/drivers/staging/rtl8723au/include/ieee80211.h
@@ -171,20 +171,6 @@ struct ieee80211_snap_hdr {
 #define WLAN_REASON_JOIN_WRONG_CHANNEL   65534
 #define WLAN_REASON_EXPIRATION_CHK 65535
 
-
-#define IEEE80211_STATMASK_SIGNAL (1<<0)
-#define IEEE80211_STATMASK_RSSI (1<<1)
-#define IEEE80211_STATMASK_NOISE (1<<2)
-#define IEEE80211_STATMASK_RATE (1<<3)
-#define IEEE80211_STATMASK_WEMASK 0x7
-
-
-#define IEEE80211_CCK_MODULATION(1<<0)
-#define IEEE80211_OFDM_MODULATION   (1<<1)
-
-#define IEEE80211_24GHZ_BAND (1<<0)
-#define IEEE80211_52GHZ_BAND (1<<1)
-
 #define IEEE80211_CCK_RATE_LEN 4
 #define IEEE80211_NUM_OFDM_RATESLEN8
 
-- 
2.1.0

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

[PATCH 1/6] staging: rtl8723au: Use RF_AC instead of hardcoded value for RF register write

[Jes . Sorensen]

From: Jes Sorensen 

Signed-off-by: Jes Sorensen 
---
 drivers/staging/rtl8723au/hal/usb_halinit.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/rtl8723au/hal/usb_halinit.c 
b/drivers/staging/rtl8723au/hal/usb_halinit.c
index adbf1c2..319170d 100644
--- a/drivers/staging/rtl8723au/hal/usb_halinit.c
+++ b/drivers/staging/rtl8723au/hal/usb_halinit.c
@@ -816,9 +816,10 @@ static void phy_SsPwrSwitch92CU(struct rtw_adapter 
*Adapter,
mode. This is used to re-write the RX idle mode. */
/*  We can only prvide a usual value instead and then
HW will modify the value by itself. */
-   PHY_SetRFReg(Adapter, RF_PATH_A, 0, bRFRegOffsetMask, 0x32D95);
+   PHY_SetRFReg(Adapter, RF_PATH_A, RF_AC,
+bRFRegOffsetMask, 0x32D95);
if (pHalData->rf_type ==  RF_2T2R) {
-   PHY_SetRFReg(Adapter, RF_PATH_B, 0,
+   PHY_SetRFReg(Adapter, RF_PATH_B, RF_AC,
 bRFRegOffsetMask, 0x32D95);
}
break;
@@ -867,9 +868,9 @@ static void phy_SsPwrSwitch92CU(struct rtw_adapter *Adapter,
 0x001B25A0);
 
/*  3. issue 3-wire command that RF set to power down.*/
-   PHY_SetRFReg(Adapter, RF_PATH_A, 0, bRFRegOffsetMask, 0);
+   PHY_SetRFReg(Adapter, RF_PATH_A, RF_AC, bRFRegOffsetMask, 0);
if (pHalData->rf_type ==  RF_2T2R)
-   PHY_SetRFReg(Adapter, RF_PATH_B, 0,
+   PHY_SetRFReg(Adapter, RF_PATH_B, RF_AC,
 bRFRegOffsetMask, 0);
 
/*  4. Force PFM , disable SPS18_LDO_Marco_Block */
-- 
2.1.0

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

[PATCH 6/6] staging: rtl8723au: Firmware always handles adaptive rates

[Jes . Sorensen]

From: Jes Sorensen 

Signed-off-by: Jes Sorensen 
---
 drivers/staging/rtl8723au/hal/odm.c | 12 
 drivers/staging/rtl8723au/include/odm.h |  3 ---
 2 files changed, 15 deletions(-)

diff --git a/drivers/staging/rtl8723au/hal/odm.c 
b/drivers/staging/rtl8723au/hal/odm.c
index 523a5a5..caa3034 100644
--- a/drivers/staging/rtl8723au/hal/odm.c
+++ b/drivers/staging/rtl8723au/hal/odm.c
@@ -1010,10 +1010,6 @@ void odm_RateAdaptiveMaskInit23a(struct dm_odm_t 
*pDM_Odm)
struct odm_rate_adapt *pOdmRA = &pDM_Odm->RateAdaptive;
 
pOdmRA->Type = DM_Type_ByDriver;
-   if (pOdmRA->Type == DM_Type_ByDriver)
-   pDM_Odm->bUseRAMask = true;
-   else
-   pDM_Odm->bUseRAMask = false;
 
pOdmRA->RATRState = DM_RATR_STA_INIT;
pOdmRA->HighRSSIThresh = 50;
@@ -1139,14 +1135,6 @@ void odm_RefreshRateAdaptiveMask23aCE23a(struct dm_odm_t 
*pDM_Odm)
return;
}
 
-   if (!pDM_Odm->bUseRAMask) {
-   ODM_RT_TRACE(pDM_Odm, ODM_COMP_RA_MASK, ODM_DBG_LOUD,
-("< odm_RefreshRateAdaptiveMask23a(): driver 
does not control rate adaptive mask\n"));
-   return;
-   }
-
-   /* printk("==> %s \n", __func__); */
-
for (i = 0; i < ODM_ASSOCIATE_ENTRY_NUM; i++) {
struct sta_info *pstat = pDM_Odm->pODM_StaInfo[i];
if (pstat) {
diff --git a/drivers/staging/rtl8723au/include/odm.h 
b/drivers/staging/rtl8723au/include/odm.h
index 5a0561e..df0915d 100644
--- a/drivers/staging/rtl8723au/include/odm.h
+++ b/drivers/staging/rtl8723au/include/odm.h
@@ -749,9 +749,6 @@ struct dm_odm_t {
u8  RSSI_BT;/* come from BT 
*/
boolbPSDinProcess;
 
-   /* for rate adaptive, in fact,  88c/92c fw will handle this */
-   u8  bUseRAMask;
-
struct odm_rate_adapt   RateAdaptive;
 
 
-- 
2.1.0

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

[PATCH 2/6] staging: rtl8723au: rates are always set via the firmware interface

[Jes . Sorensen]

From: Jes Sorensen 

The only case where fw_ractrl = false was when the firmware failed to
load, and in that case we are dead in the water anyway.

Signed-off-by: Jes Sorensen 
---
 drivers/staging/rtl8723au/hal/odm.c|  3 +--
 .../staging/rtl8723au/hal/rtl8723a_bt-coexist.c| 28 +++---
 drivers/staging/rtl8723au/hal/rtl8723a_cmd.c   | 16 +
 drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c  |  1 -
 drivers/staging/rtl8723au/hal/usb_halinit.c| 28 ++
 drivers/staging/rtl8723au/include/rtl8723a_hal.h   |  1 -
 6 files changed, 18 insertions(+), 59 deletions(-)

diff --git a/drivers/staging/rtl8723au/hal/odm.c 
b/drivers/staging/rtl8723au/hal/odm.c
index 5269b46..523a5a5 100644
--- a/drivers/staging/rtl8723au/hal/odm.c
+++ b/drivers/staging/rtl8723au/hal/odm.c
@@ -1289,8 +1289,7 @@ void odm_RSSIMonitorCheck23aCE(struct dm_odm_t *pDM_Odm)
 
for (i = 0; i < sta_cnt; i++) {
if (PWDB_rssi[i] != (0)) {
-   if (pHalData->fw_ractrl) /*  Report every sta's RSSI to 
FW */
-   rtl8723a_set_rssi_cmd(Adapter, (u8 
*)&PWDB_rssi[i]);
+   rtl8723a_set_rssi_cmd(Adapter, (u8 *)&PWDB_rssi[i]);
}
}
 
diff --git a/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c 
b/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c
index 412d8cf..6796420 100644
--- a/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c
+++ b/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c
@@ -5796,7 +5796,7 @@ static void
 btdm_1AntUpdateHalRAMask(struct rtw_adapter *padapter, u32 mac_id, u32 filter)
 {
u8 init_rate = 0;
-   u8 raid;
+   u8 raid, arg;
u32 mask;
u8 shortGIrate = false;
int supportRateNum = 0;
@@ -5860,26 +5860,16 @@ btdm_1AntUpdateHalRAMask(struct rtw_adapter *padapter, 
u32 mac_id, u32 filter)
mask &= ~filter;
init_rate = get_highest_rate_idx23a(mask)&0x3f;
 
-   if (pHalData->fw_ractrl) {
-   u8 arg = 0;
+   arg = mac_id&0x1f;/* MACID */
+   arg |= BIT(7);
+   if (true == shortGIrate)
+   arg |= BIT(5);
 
-   arg = mac_id&0x1f;/* MACID */
-   arg |= BIT(7);
-   if (true == shortGIrate)
-   arg |= BIT(5);
-
-   RTPRINT(FBT, BT_TRACE,
-   ("[BTCoex], Update FW RAID entry, MASK = 0x%08x, "
-"arg = 0x%02x\n", mask, arg));
-
-   rtl8723a_set_raid_cmd(padapter, mask, arg);
-   } else {
-   if (shortGIrate)
-   init_rate |= BIT(6);
+   RTPRINT(FBT, BT_TRACE,
+   ("[BTCoex], Update FW RAID entry, MASK = 0x%08x, "
+"arg = 0x%02x\n", mask, arg));
 
-   rtl8723au_write8(padapter, REG_INIDATA_RATE_SEL + mac_id,
-init_rate);
-   }
+   rtl8723a_set_raid_cmd(padapter, mask, arg);
 
psta->init_rate = init_rate;
pdmpriv->INIDATA_RATE[mac_id] = init_rate;
diff --git a/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c 
b/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
index 7b56411..0b77ee1 100644
--- a/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
+++ b/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
@@ -153,21 +153,7 @@ void rtl8723a_add_rateatid(struct rtw_adapter *pAdapter, 
u32 bitmap, u8 arg, u8
 
bitmap |= ((raid<<28)&0xf000);
 
-   if (pHalData->fw_ractrl == true) {
-   rtl8723a_set_raid_cmd(pAdapter, bitmap, arg);
-   } else {
-   u8 init_rate, shortGIrate = false;
-
-   init_rate = get_highest_rate_idx23a(bitmap&0x0fff)&0x3f;
-
-   shortGIrate = (arg&BIT(5)) ? true:false;
-
-   if (shortGIrate == true)
-   init_rate |= BIT(6);
-
-   rtl8723au_write8(pAdapter, REG_INIDATA_RATE_SEL + macid,
-init_rate);
-   }
+   rtl8723a_set_raid_cmd(pAdapter, bitmap, arg);
 }
 
 void rtl8723a_set_FwPwrMode_cmd(struct rtw_adapter *padapter, u8 Mode)
diff --git a/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c 
b/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c
index a5eadd4..eb82c0b 100644
--- a/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c
+++ b/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c
@@ -1095,7 +1095,6 @@ void rtl8723a_init_default_value(struct rtw_adapter 
*padapter)
pdmpriv = &pHalData->dmpriv;
 
/*  init default value */
-   pHalData->fw_ractrl = false;
pHalData->bIQKInitialized = false;
if (!padapter->pwrctrlpriv.bkeepfwalive)
pHalData->LastHMEBoxNum = 0;
diff --git a/drivers/staging/rtl8723au/hal/usb_halinit.c 
b/drivers/staging/rtl8723au/hal/usb_halinit.c
index 319170d..17389347 100644
--- a/drivers/staging/rtl8723au/hal/usb_halinit.c
+++ b/drivers/staging/rtl8723au/hal/usb_halinit.c
@@ -572,12 +572,10 @@ in

[PATCH] Staging: lustre: Added missing __user keyword to several struct fields

[Adrian Remonda]

This is a patch that fixes up missing __user warnings found by the sparse

modified:   drivers/staging/lustre/include/linux/libcfs/libcfs_ioctl.h
modified:   drivers/staging/lustre/include/linux/lnet/lnetst.h
modified:   drivers/staging/lustre/lnet/selftest/conctl.c
modified:   drivers/staging/lustre/lnet/selftest/console.c
modified:   drivers/staging/lustre/lnet/selftest/console.h

modified:   drivers/staging/lustre/include/linux/libcfs/libcfs_ioctl.h
modified:   drivers/staging/lustre/lnet/selftest/console.h

Signed-off-by: Adrian Remonda 
---
 .../lustre/include/linux/libcfs/libcfs_ioctl.h |  4 +--
 drivers/staging/lustre/include/linux/lnet/lnetst.h | 36 +++---
 drivers/staging/lustre/lnet/selftest/console.c |  2 +-
 drivers/staging/lustre/lnet/selftest/console.h |  4 ++-
 4 files changed, 24 insertions(+), 22 deletions(-)

diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs_ioctl.h 
b/drivers/staging/lustre/include/linux/libcfs/libcfs_ioctl.h
index 3ee38782ad8c..aa687b79384b 100644
--- a/drivers/staging/lustre/include/linux/libcfs/libcfs_ioctl.h
+++ b/drivers/staging/lustre/include/linux/libcfs/libcfs_ioctl.h
@@ -61,9 +61,9 @@ struct libcfs_ioctl_data {
char *ioc_inlbuf2;
 
__u32 ioc_plen1; /* buffers in userspace */
-   char *ioc_pbuf1;
+   char __user *ioc_pbuf1;
__u32 ioc_plen2; /* buffers in userspace */
-   char *ioc_pbuf2;
+   char __user *ioc_pbuf2;
 
char ioc_bulk[0];
 };
diff --git a/drivers/staging/lustre/include/linux/lnet/lnetst.h 
b/drivers/staging/lustre/include/linux/lnet/lnetst.h
index 885f708d4031..846cddc11a81 100644
--- a/drivers/staging/lustre/include/linux/lnet/lnetst.h
+++ b/drivers/staging/lustre/include/linux/lnet/lnetst.h
@@ -277,7 +277,7 @@ typedef struct {
int  lstio_dbg_timeout;  /* IN: timeout of debug */
 
int  lstio_dbg_nmlen;   /* IN: len of name */
-   char   *lstio_dbg_namep;/* IN: name of group|batch */
+   char __user*lstio_dbg_namep;/* IN: name of group|batch */
int  lstio_dbg_count;   /* IN: # of test nodes to debug 
*/
lnet_process_id_t  *lstio_dbg_idsp;  /* IN: id of test nodes */
struct list_head *lstio_dbg_resultp;  /* OUT: list head 
of result buffer */
@@ -286,13 +286,13 @@ typedef struct {
 typedef struct {
int  lstio_grp_key;   /* IN: session key */
int  lstio_grp_nmlen;   /* IN: name length */
-   char   *lstio_grp_namep;/* IN: group name */
+   char __user*lstio_grp_namep;/* IN: group name */
 } lstio_group_add_args_t;
 
 typedef struct {
int  lstio_grp_key;   /* IN: session key */
int  lstio_grp_nmlen;   /* IN: name length */
-   char   *lstio_grp_namep;/* IN: group name */
+   char __user*lstio_grp_namep;/* IN: group name */
 } lstio_group_del_args_t;
 
 #define LST_GROUP_CLEAN 1 /* remove inactive nodes 
in the group */
@@ -316,7 +316,7 @@ typedef struct {
char   *lstio_grp_namep;/* IN: group name */
int  lstio_grp_count;   /* IN: # of nodes */
/** OUT: session features */
-   unsigned   *lstio_grp_featp;
+   unsigned __user*lstio_grp_featp;
lnet_process_id_t  *lstio_grp_idsp;  /* IN: nodes */
struct list_head *lstio_grp_resultp;  /* OUT: list head 
of result buffer */
 } lstio_group_nodes_args_t;
@@ -344,21 +344,21 @@ typedef struct {
 typedef struct {
int  lstio_bat_key;   /* IN: session key */
int  lstio_bat_nmlen;   /* IN: name length */
-   char   *lstio_bat_namep;/* IN: batch name */
+   char __user*lstio_bat_namep;/* IN: batch name */
 } lstio_batch_add_args_t;
 
 typedef struct {
int  lstio_bat_key;   /* IN: session key */
int  lstio_bat_nmlen;   /* IN: name length */
-   char   *lstio_bat_namep;/* IN: batch name */
+   char __user*lstio_bat_namep;/* IN: batch name */
 } lstio_batch_del_args_t;
 
 typedef struct {
int  lstio_bat_key;   /* IN: session key */
int  lstio_bat_timeout;  /* IN: timeout for the 
batch */
int  lstio_bat_nmlen;   /* IN: name length */
-   char   *lstio_bat_namep;/* IN: batch name */
-   struct list_head *lstio_bat_resultp;  /* OUT: list head 
of result buffer */
+   char __user*lstio_bat_namep;/* IN: batch name */
+   struct list_head __user *lstio_bat_resultp;  /* OUT: list head of 
result buffer */
 

Re: Question regarding sparse warning in staging/lustre

[AdrianRemonda]

On Mon, Feb 09, 2015 at 07:40:23AM +0800, Greg Kroah-Hartman wrote:
> On Sun, Feb 08, 2015 at 10:27:23PM +0100, Adrian Remonda wrote:
> > Hello,
> > 
> > I'm cleaning the drivers/staging/lustre driver.
> > I have got the next warning from sparse:
> > 
> > drivers/staging/lustre/lnet/selftest//conctl.c:918:30: warning: incorrect 
> > type in argument 1 (different address spaces)
> > drivers/staging/lustre/lnet/selftest//conctl.c:918:30:expected void 
> > [noderef] *to
> > drivers/staging/lustre/lnet/selftest//conctl.c:918:30:got char 
> > *ioc_pbuf2
> > 
> > If I add the __user macro as next:
> > 
> > --- a/drivers/staging/lustre/lnet/selftest/conctl.c
> > +++ b/drivers/staging/lustre/lnet/selftest/conctl.c
> > @@ -46,7 +46,7 @@
> >  #include "console.h"
> >  
> >  static int
> > -lst_session_new_ioctl(lstio_session_new_args_t *args)
> > +lst_session_new_ioctl(lstio_session_new_args_t __user *args)
> >  {
> > char  *name;
> > int rc;
> > 
> > The warning turns to:
> > 
> > drivers/staging/lustre/lnet/selftest//conctl.c:825:13: warning: dereference 
> > of noderef expression
> > 
> > Now the question:
> > Is this right or it is just a false warning from sparse? 
> > Should the __user macro should be also inside the structure fields?
> 
> The user/kernel fields in lustre are a total mess, I wouldn't work on
> them if you don't have to as they need an overhaul in some areas.
> 
> So I'd recommend just staying away :)
> 
> good luck!
> 
> greg k-h

Ok. I had already done some modifications anyway. I sent you the patch
of the few I did

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

Re: Question regarding sparse warning in staging/lustre

[Greg Kroah-Hartman]

On Tue, Feb 10, 2015 at 12:07:17AM +0100, AdrianRemonda wrote:
> On Mon, Feb 09, 2015 at 07:40:23AM +0800, Greg Kroah-Hartman wrote:
> > On Sun, Feb 08, 2015 at 10:27:23PM +0100, Adrian Remonda wrote:
> > > Hello,
> > > 
> > > I'm cleaning the drivers/staging/lustre driver.
> > > I have got the next warning from sparse:
> > > 
> > > drivers/staging/lustre/lnet/selftest//conctl.c:918:30: warning: incorrect 
> > > type in argument 1 (different address spaces)
> > > drivers/staging/lustre/lnet/selftest//conctl.c:918:30:expected void 
> > > [noderef] *to
> > > drivers/staging/lustre/lnet/selftest//conctl.c:918:30:got char 
> > > *ioc_pbuf2
> > > 
> > > If I add the __user macro as next:
> > > 
> > > --- a/drivers/staging/lustre/lnet/selftest/conctl.c
> > > +++ b/drivers/staging/lustre/lnet/selftest/conctl.c
> > > @@ -46,7 +46,7 @@
> > >  #include "console.h"
> > >  
> > >  static int
> > > -lst_session_new_ioctl(lstio_session_new_args_t *args)
> > > +lst_session_new_ioctl(lstio_session_new_args_t __user *args)
> > >  {
> > >   char  *name;
> > >   int rc;
> > >   
> > > The warning turns to:
> > > 
> > > drivers/staging/lustre/lnet/selftest//conctl.c:825:13: warning: 
> > > dereference of noderef expression
> > > 
> > > Now the question:
> > > Is this right or it is just a false warning from sparse? 
> > > Should the __user macro should be also inside the structure fields?
> > 
> > The user/kernel fields in lustre are a total mess, I wouldn't work on
> > them if you don't have to as they need an overhaul in some areas.
> > 
> > So I'd recommend just staying away :)
> > 
> > good luck!
> > 
> > greg k-h
> 
> Ok. I had already done some modifications anyway. I sent you the patch
> of the few I did

I can't take those as I don't think they are correct, so I'll just drop
them, sorry.

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

Re: [PATCH] Staging: lustre: Added missing __user keyword to several struct fields

[Greg Kroah-Hartman]

On Mon, Feb 09, 2015 at 11:56:58PM +0100, Adrian Remonda wrote:
> This is a patch that fixes up missing __user warnings found by the sparse
> 
>   modified:   drivers/staging/lustre/include/linux/libcfs/libcfs_ioctl.h
>   modified:   drivers/staging/lustre/include/linux/lnet/lnetst.h
>   modified:   drivers/staging/lustre/lnet/selftest/conctl.c
>   modified:   drivers/staging/lustre/lnet/selftest/console.c
>   modified:   drivers/staging/lustre/lnet/selftest/console.h
> 
>   modified:   drivers/staging/lustre/include/linux/libcfs/libcfs_ioctl.h
>   modified:   drivers/staging/lustre/lnet/selftest/console.h
> 
> Signed-off-by: Adrian Remonda 
> ---
>  .../lustre/include/linux/libcfs/libcfs_ioctl.h |  4 +--
>  drivers/staging/lustre/include/linux/lnet/lnetst.h | 36 
> +++---
>  drivers/staging/lustre/lnet/selftest/console.c |  2 +-
>  drivers/staging/lustre/lnet/selftest/console.h |  4 ++-
>  4 files changed, 24 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs_ioctl.h 
> b/drivers/staging/lustre/include/linux/libcfs/libcfs_ioctl.h
> index 3ee38782ad8c..aa687b79384b 100644
> --- a/drivers/staging/lustre/include/linux/libcfs/libcfs_ioctl.h
> +++ b/drivers/staging/lustre/include/linux/libcfs/libcfs_ioctl.h
> @@ -61,9 +61,9 @@ struct libcfs_ioctl_data {
>   char *ioc_inlbuf2;
>  
>   __u32 ioc_plen1; /* buffers in userspace */
> - char *ioc_pbuf1;
> + char __user *ioc_pbuf1;
>   __u32 ioc_plen2; /* buffers in userspace */
> - char *ioc_pbuf2;
> + char __user *ioc_pbuf2;
>  
>   char ioc_bulk[0];
>  };
> diff --git a/drivers/staging/lustre/include/linux/lnet/lnetst.h 
> b/drivers/staging/lustre/include/linux/lnet/lnetst.h
> index 885f708d4031..846cddc11a81 100644
> --- a/drivers/staging/lustre/include/linux/lnet/lnetst.h
> +++ b/drivers/staging/lustre/include/linux/lnet/lnetst.h
> @@ -277,7 +277,7 @@ typedef struct {
>   int  lstio_dbg_timeout;  /* IN: timeout of debug */
>  
>   int  lstio_dbg_nmlen;   /* IN: len of name */
> - char   *lstio_dbg_namep;/* IN: name of group|batch */
> + char __user*lstio_dbg_namep;/* IN: name of group|batch */
>   int  lstio_dbg_count;   /* IN: # of test nodes to debug 
> */
>   lnet_process_id_t  *lstio_dbg_idsp;  /* IN: id of test nodes */
>   struct list_head *lstio_dbg_resultp;  /* OUT: list head 
> of result buffer */
> @@ -286,13 +286,13 @@ typedef struct {
>  typedef struct {
>   int  lstio_grp_key;   /* IN: session key */
>   int  lstio_grp_nmlen;   /* IN: name length */
> - char   *lstio_grp_namep;/* IN: group name */
> + char __user*lstio_grp_namep;/* IN: group name */
>  } lstio_group_add_args_t;
>  
>  typedef struct {
>   int  lstio_grp_key;   /* IN: session key */
>   int  lstio_grp_nmlen;   /* IN: name length */
> - char   *lstio_grp_namep;/* IN: group name */
> + char __user*lstio_grp_namep;/* IN: group name */
>  } lstio_group_del_args_t;
>  
>  #define LST_GROUP_CLEAN   1 /* remove inactive nodes 
> in the group */
> @@ -316,7 +316,7 @@ typedef struct {
>   char   *lstio_grp_namep;/* IN: group name */
>   int  lstio_grp_count;   /* IN: # of nodes */
>   /** OUT: session features */
> - unsigned   *lstio_grp_featp;
> + unsigned __user*lstio_grp_featp;
>   lnet_process_id_t  *lstio_grp_idsp;  /* IN: nodes */
>   struct list_head *lstio_grp_resultp;  /* OUT: list head 
> of result buffer */
>  } lstio_group_nodes_args_t;
> @@ -344,21 +344,21 @@ typedef struct {
>  typedef struct {
>   int  lstio_bat_key;   /* IN: session key */
>   int  lstio_bat_nmlen;   /* IN: name length */
> - char   *lstio_bat_namep;/* IN: batch name */
> + char __user*lstio_bat_namep;/* IN: batch name */
>  } lstio_batch_add_args_t;
>  
>  typedef struct {
>   int  lstio_bat_key;   /* IN: session key */
>   int  lstio_bat_nmlen;   /* IN: name length */
> - char   *lstio_bat_namep;/* IN: batch name */
> + char __user*lstio_bat_namep;/* IN: batch name */
>  } lstio_batch_del_args_t;
>  
>  typedef struct {
>   int  lstio_bat_key;   /* IN: session key */
>   int  lstio_bat_timeout;  /* IN: timeout for the 
> batch */
>   int  lstio_bat_nmlen;   /* IN: name length */
> - char   *lstio_bat_namep;/* IN: batch name */
> - struct list_head *lstio_bat_resultp;  /* OUT: list head 
> of result buffer 

Re: [PATCH v3] staging: lustre: fix coding style errors

[Drokin, Oleg]

On Feb 9, 2015, at 4:34 PM,  wrote:
>> There's a third coding style error in this file which I've chosen to
>> not fix for clarity's sake. It is: initializing min_watchdog_ratelimit
>> (static int) to 0
> 
> Please fix that too, it's not correct.  Drop the comment there if you
> think that's confusing.

What's not correct there, I wonder? Just assignment of 0 to a static variable
to get some extra clarity?
The code in the question is:

static int min_watchdog_ratelimit = 0;/* disable ratelimiting */
static int max_watchdog_ratelimit = (24*60*60); /* limit to once per day */

So if you drop both = 0 and the comment, I think it would become even more 
cryptic?

How about something like this then (not a proper patch, but just to demonstrate
the idea):

--- a/drivers/staging/lustre/lustre/libcfs/linux/linux-proc.c
+++ b/drivers/staging/lustre/lustre/libcfs/linux/linux-proc.c
@@ -165,7 +165,7 @@ static int proc_dobitmasks(struct ctl_table *table, int 
write,
 __proc_dobitmasks);
 }
 
-static int min_watchdog_ratelimit = 0;   /* disable ratelimiting */
+static int zero;
 static int max_watchdog_ratelimit = (24*60*60); /* limit to once per day */
 
 static int __proc_dump_kernel(void *data, int write,
@@ -521,7 +521,7 @@ static struct ctl_table lnet_table[] = {
.maxlen   = sizeof(int),
.mode = 0644,
.proc_handler = &proc_dointvec_minmax,
-   .extra1   = &min_watchdog_ratelimit,
+   .extra1   = &zero, /* Disable ratelimiting */
.extra2   = &max_watchdog_ratelimit,
},
{

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

Re: [PATCH v3] staging: lustre: fix coding style errors

On Tue, Feb 10, 2015 at 12:34:07AM +, Drokin, Oleg wrote:
> 
> On Feb 9, 2015, at 4:34 PM,  wrote:
> >> There's a third coding style error in this file which I've chosen to
> >> not fix for clarity's sake. It is: initializing min_watchdog_ratelimit
> >> (static int) to 0
> > 
> > Please fix that too, it's not correct.  Drop the comment there if you
> > think that's confusing.
> 
> What's not correct there, I wonder? Just assignment of 0 to a static variable
> to get some extra clarity?
> The code in the question is:
> 
> static int min_watchdog_ratelimit = 0;/* disable ratelimiting */
> static int max_watchdog_ratelimit = (24*60*60); /* limit to once per day */
> 
> So if you drop both = 0 and the comment, I think it would become even more 
> cryptic?
> 
> How about something like this then (not a proper patch, but just to 
> demonstrate
> the idea):
> 
> --- a/drivers/staging/lustre/lustre/libcfs/linux/linux-proc.c
> +++ b/drivers/staging/lustre/lustre/libcfs/linux/linux-proc.c
> @@ -165,7 +165,7 @@ static int proc_dobitmasks(struct ctl_table *table, int 
> write,
>  __proc_dobitmasks);
>  }
>  
> -static int min_watchdog_ratelimit = 0;   /* disable ratelimiting */
> +static int zero;
>  static int max_watchdog_ratelimit = (24*60*60); /* limit to once per day */

Ick, no, just do like other places have done:
  static int min_watchdog_ratelimit;/* = 0 disable ratelimiting */

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

Re: [PATCH 1/2] staging: unisys: remove unused variable

[Sudip Mukherjee]

On Tue, Feb 10, 2015 at 05:35:40AM +0800, Greg Kroah-Hartman wrote:
> On Sun, Feb 08, 2015 at 04:31:07PM +0530, Sudip Mukherjee wrote:
> > On Sat, Feb 07, 2015 at 05:22:16PM +0800, Greg Kroah-Hartman wrote:
> > > On Fri, Feb 06, 2015 at 06:13:21PM +0530, Sudip Mukherjee wrote:
> > > > we were getting lots of warnings about _tempresult set but not used.
> > > > _tempresult was used in the macro ISSUE_IO_VMCALL_POSTCODE_SEVERITY
> > > > which was again using another macro ISSUE_IO_EXTENDED_VMCALL.
> > > > but the vallue assigned to it was never used.
> > > > 
> > > > Signed-off-by: Sudip Mukherjee 
> > > 
> > > Your From: address, and this address don't match, so I can't take this
> > > :(
> > 
> > all my patches have been like this way, and you have taken them before :)
> > the reason its like this way - (already discussed with Dan Carpenter, 
> > reference https://lkml.org/lkml/2014/9/3/473)
> > 
> > we have strict DMARC check for the corporate mail server. DMARC = domain 
> > based message authentication.
> > So the mail i sent reached all the list subscriber from a different server 
> > than our designated server,
> > and as a result it is marked as spam in many places and I have already 
> > received a few complaints regarding that.
> > 
> > so at https://lkml.org/lkml/2014/9/3/535 Dan said its ok for him, but 
> > depends on you if you want to accept.
> > And since you have accepted all my patches before so i thought it is ok 
> > with you.
> 
> I didn't notice it before, sorry.

no problem. we all know how much busy you are .. :)

> 
> > if you want I can add an extra From: line, but Dan has already given his 
> > commments for that at https://lkml.org/lkml/2014/9/3/135
> > quoting him :
> > 
> > "If everyone starts using From headers like this then it becomes a pain to 
> > deal with."
> 
> It's not a pain to deal with on my end at all.
> 
> But as I've missed this in the past, nevermind, I'll take it as is.  Can
> you resend your outstanding patches and I'll queue them up after
> 3.20-rc1 is out.
i will resend them now or should i send after the merge window closes?
and on 07th feb you have added my two patches to staging-testing, but it still 
is not in linux-next, do i need to resend them also or they are in process so 
nothing to do from my side?

regards
sudip

> 
> thanks,
> 
> greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/2] staging: unisys: remove unused variable

[Greg Kroah-Hartman]

On Tue, Feb 10, 2015 at 10:50:06AM +0530, Sudip Mukherjee wrote:
> > > if you want I can add an extra From: line, but Dan has already given his 
> > > commments for that at https://lkml.org/lkml/2014/9/3/135
> > > quoting him :
> > > 
> > > "If everyone starts using From headers like this then it becomes a pain 
> > > to deal with."
> > 
> > It's not a pain to deal with on my end at all.
> > 
> > But as I've missed this in the past, nevermind, I'll take it as is.  Can
> > you resend your outstanding patches and I'll queue them up after
> > 3.20-rc1 is out.
> i will resend them now or should i send after the merge window closes?

You can send patches any time, I'll batch them up and apply them to my
trees at the proper time.

> and on 07th feb you have added my two patches to staging-testing, but
> it still is not in linux-next, do i need to resend them also or they
> are in process so nothing to do from my side?

Nothing to do on your side, I am on the road this week and will move
those to my -next branch right now, thanks for reminding me.

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

NOTIS RASMI HADIAH TELEKOM MALAYSIA

[Telekom Malaysia Berhad]

Telekom Malaysia Berhad
G.03B, Ground Floor, Kompleks Antarabangsa, Jln Sultan Ismail, Off Jalan Ampang
50250 Kuala Lumpur
Malaysia.

NOTIS RASMI HADIAH TELEKOM MALAYSIA

Pihak Telekom Malaysia @Program Kemenangan yang telah diadakan pada 9th 
Februari 2015 di mana alamat email anda yang disertakan beraama Tiket 
Kemenangan nombor 2 - 4 - 16 -
37 - 89 - 40 -85 dengan siri nombor 2268/02 telah memenangi loteri kategori 
hadiah kedua khas keluarga Telekom Malaysia. Untuk menuntut hadiah kemenangan 
ini anda dikehendaki menghubungi melalui e mail Bahagian Tuntutan untuk tujuan 
pemerosesan dan pembayaran hadiah wang tunai kepada anda.

Di sepanjang program Khas Keluarga Telekom yang telah diadakan di Ibupejabat di 
Kuala Lumpur sejumlah Rm270,000.00 (Ringgit Malaysia : Dua Ratus Tujoh Puloh 
Ribu) telah dianugerahkan kepada anda oleh Telekom Malaysia Berhad kepada anda 
dan keluarga anda sempena sambutsn Hari Raya 2015 ini.

Program ini turut dibiayai bersama oleh Toyota Malaysia dan Tenaga Nasional 
sebagai pakej istimewa Telekom 2015 dan anda perlu memahami bahawa e mail ini 
adalah 100% sah dan diiktiraf kerana program ini kebiasaannya diadakan sekali 
dalam masa lima tahun.

Sila hubungi agen kami untuk menuntut hadiah ini :

EN SHAFIE BIN HASSAN
Pengarah Bahagian Tuntutan
E-mail: tm2015bo...@outlook.my

Untuk tujuan pemerosesan sila hubungi agen kami dengan maklumat-maklumat 
berikut:
1) Nama Penuh:
2). Umur:
3). Pekerjaan:
4). Telefon:
5). Negeri / Bandar:

Perlu diingatkan bahawa hadiah akhir tahun Telekom Malaysia Berhad 2015 ini 
adalah diberikan khas kepada anda dan keluarga anda dan anda hendaklah membuat 
tunttan ini sebelum 28th Februari 2015.

Terima kasih.

Mrs Nadia binti Rafik
Pengurus Eksekutif
Anugerah Telekom Malaysia
Ibupejabat telekom Malaysia.

---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com

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

Re: [PATCH 1/2] staging: unisys: remove unused variable

[Sudip Mukherjee]

On Tue, Feb 10, 2015 at 02:34:15PM +0800, Greg Kroah-Hartman wrote:
> On Tue, Feb 10, 2015 at 10:50:06AM +0530, Sudip Mukherjee wrote:
> 
> Nothing to do on your side, I am on the road this week and will move
> those to my -next branch right now, thanks for reminding me.

welcome sir. If you ever need an assisstant (for reminding or for coding)  you 
can count me in :)

I can see that you are in HongKong now, please do let us know if you ever plan 
to be on the roads in India. I am sure all of us here will like to meet you. we 
can have a beer or two while learning few things from you.

sudip

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

Re: [PATCH v3 04/20] power_supply: sysfs: Use power_supply_*() API for accessing function attrs

[Krzysztof Kozlowski]

On pon, 2015-02-09 at 20:02 +0100, Stefan Wahren wrote:
> Hi Krzysztof,
> 
> > Krzysztof Kozlowski  hat am 30. Januar 2015 um 
> > 15:47
> > geschrieben:
> >
> >
> > Replace direct calls to power supply function attributes with wrappers.
> > Wrappers provide safe access in case of unregistering the power
> > supply (e.g. by removing the driver). Replace:
> > - get_property -> power_supply_get_property
> > - set_property -> power_supply_set_property
> > - property_is_writeable -> power_supply_property_is_writeable
> >
> > Signed-off-by: Krzysztof Kozlowski 
> > Acked-by: Jonghwa Lee 
> 
> just a nit. It looks like a typo in the mail address which is also in patch 5 
> -
> 10.

Right, I copied it directly from Jonghwa's response. Thank you for
noticing it.

> 
> I applied patch 1 - 14 to my repo with a upcoming power driver (mxs_power) and
> didn't see any problems with your patches.

Great, thanks!

Best regards,
Krzysztof


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