Re: [PATCH] staging: rtl8192u: Correct coding style issues.

[Greg KH]

On Tue, Jan 10, 2017 at 11:23:20PM +0100, Javier Rodriguez wrote:
> Add character '*' in all lines of the block comments.
> Also remove one unnecessary line.

When you have to say "also", that's a huge hint that you need to break
the patch up into different patches.  Please do so here and resend.

thanks,

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

[PATCH] staging: wlan-ng: Fix sparse warnings about endianness

[Eric Salem]

Fixed sparse warnings about endianness. E.g.:

warning: cast to restricted __le16

Signed-off-by: Eric Salem 
---
 drivers/staging/wlan-ng/hfa384x.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/wlan-ng/hfa384x.h 
b/drivers/staging/wlan-ng/hfa384x.h
index 60caf9c3..5f1851c 100644
--- a/drivers/staging/wlan-ng/hfa384x.h
+++ b/drivers/staging/wlan-ng/hfa384x.h
@@ -1388,13 +1388,13 @@ static inline int hfa384x_drvr_getconfig16(struct 
hfa384x *hw, u16 rid, void *va
 
result = hfa384x_drvr_getconfig(hw, rid, val, sizeof(u16));
if (result == 0)
-   *((u16 *)val) = le16_to_cpu(*((u16 *)val));
+   le16_to_cpus(val);
return result;
 }
 
 static inline int hfa384x_drvr_setconfig16(struct hfa384x *hw, u16 rid, u16 
val)
 {
-   u16 value = cpu_to_le16(val);
+   __le16 value = cpu_to_le16(val);
 
return hfa384x_drvr_setconfig(hw, rid, , sizeof(value));
 }
-- 
2.9.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging:vt6656:mac.c Aligned to match open parenthesis

[Scott Matheina]

Fixes checkpatch warning: Alignment should match open parenthesis

Signed-off-by: Scott Matheina 
---
 drivers/staging/vt6656/mac.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/vt6656/mac.c b/drivers/staging/vt6656/mac.c
index 86d98bc..417fdad 100644
--- a/drivers/staging/vt6656/mac.c
+++ b/drivers/staging/vt6656/mac.c
@@ -169,8 +169,8 @@ void vnt_mac_write_word(struct vnt_private *priv, u8 
reg_ofs, u16 word)
data[0] = (u8)(word & 0xff);
data[1] = (u8)(word >> 8);
 
-   vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   reg_ofs, MESSAGE_REQUEST_MACREG, ARRAY_SIZE(data), data);
+   vnt_control_out(priv, MESSAGE_TYPE_WRITE, reg_ofs,
+   MESSAGE_REQUEST_MACREG, ARRAY_SIZE(data), data);
 }
 
 void vnt_mac_set_bssid_addr(struct vnt_private *priv, u8 *addr)
-- 
2.7.4

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

Re: [PATCH] staging: greybus: loopback_test: fix checkpatch bad function definition error

[Viresh Kumar]

On Wed, Jan 11, 2017 at 6:59 AM, Abdul Rauf  wrote:
> Fix the following Errors:
> Bad function definition - void abort() should probably be void abort(void)
>
> Signed-off-by: Abdul Rauf 
> ---
>  drivers/staging/greybus/tools/loopback_test.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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

Re: [PATCH] staging: greybus: fix checkpatch braces not necessary warning

[Viresh Kumar]

On Wed, Jan 11, 2017 at 6:25 AM, Abdul Rauf  wrote:
> Fix the following warnings:
> braces {} are not necessary for any arm of this statement
>
> Signed-off-by: Abdul Rauf 
> ---
>  drivers/staging/greybus/loopback.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)

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

[PATCH 9/9] treewide: Inline ib_dma_map_*() functions

[Bart Van Assche]

Almost all changes in this patch except the removal of local variables
that became superfluous and the actual removal of the ib_dma_map_*()
functions have been generated as follows:

git grep -lE 'ib_(sg_|)dma_' |
  xargs -d\\n \
sed -i -e 
's/\([^[:alnum:]_]\)ib_dma_\([^(]*\)(\&\([^,]\+\),/\1dma_\2(\3.dma_device,/g' \
   -e 
's/\([^[:alnum:]_]\)ib_dma_\([^(]*\)(\([^,]\+\),/\1dma_\2(\3->dma_device,/g' \
   -e 's/ib_sg_dma_\(len\|address\)(\([^,]\+\), /sg_dma_\1(/g'

Signed-off-by: Bart Van Assche 
Reviewed-by: Christoph Hellwig 
Cc: Andreas Dilger 
Cc: Anna Schumaker 
Cc: David S. Miller 
Cc: Eric Van Hensbergen 
Cc: James Simmons 
Cc: Latchesar Ionkov 
Cc: Oleg Drokin 
Cc: Ron Minnich 
Cc: Trond Myklebust 
Cc: de...@driverdev.osuosl.org
Cc: linux-...@vger.kernel.org
Cc: linux-n...@lists.infradead.org
Cc: linux-r...@vger.kernel.org
Cc: lustre-de...@lists.lustre.org
Cc: net...@vger.kernel.org
Cc: rds-de...@oss.oracle.com
Cc: target-de...@vger.kernel.org
Cc: v9fs-develo...@lists.sourceforge.net
---
 drivers/infiniband/core/mad.c  |  28 +--
 drivers/infiniband/core/rw.c   |  30 ++-
 drivers/infiniband/core/umem.c |   4 +-
 drivers/infiniband/core/umem_odp.c |   6 +-
 drivers/infiniband/hw/mlx4/cq.c|   2 +-
 drivers/infiniband/hw/mlx4/mad.c   |  28 +--
 drivers/infiniband/hw/mlx4/mr.c|   4 +-
 drivers/infiniband/hw/mlx4/qp.c|  10 +-
 drivers/infiniband/hw/mlx5/mr.c|   4 +-
 drivers/infiniband/ulp/ipoib/ipoib_cm.c|  20 +-
 drivers/infiniband/ulp/ipoib/ipoib_ib.c|  22 +--
 drivers/infiniband/ulp/iser/iscsi_iser.c   |   6 +-
 drivers/infiniband/ulp/iser/iser_initiator.c   |  38 ++--
 drivers/infiniband/ulp/iser/iser_memory.c  |  12 +-
 drivers/infiniband/ulp/iser/iser_verbs.c   |   2 +-
 drivers/infiniband/ulp/isert/ib_isert.c|  60 +++---
 drivers/infiniband/ulp/srp/ib_srp.c|  50 +++--
 drivers/infiniband/ulp/srpt/ib_srpt.c  |  10 +-
 drivers/nvme/host/rdma.c   |  22 +--
 drivers/nvme/target/rdma.c |  20 +-
 .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h|  14 +-
 include/rdma/ib_verbs.h| 218 -
 net/9p/trans_rdma.c|  12 +-
 net/rds/ib.h   |  39 
 net/rds/ib_cm.c|  18 +-
 net/rds/ib_fmr.c   |  10 +-
 net/rds/ib_frmr.c  |   8 +-
 net/rds/ib_rdma.c  |   6 +-
 net/rds/ib_recv.c  |  14 +-
 net/rds/ib_send.c  |  28 +--
 net/sunrpc/xprtrdma/fmr_ops.c  |   6 +-
 net/sunrpc/xprtrdma/frwr_ops.c |   6 +-
 net/sunrpc/xprtrdma/rpc_rdma.c |  14 +-
 net/sunrpc/xprtrdma/svc_rdma_backchannel.c |   4 +-
 net/sunrpc/xprtrdma/svc_rdma_recvfrom.c|   8 +-
 net/sunrpc/xprtrdma/svc_rdma_sendto.c  |  14 +-
 net/sunrpc/xprtrdma/svc_rdma_transport.c   |   8 +-
 net/sunrpc/xprtrdma/verbs.c|   8 +-
 38 files changed, 275 insertions(+), 538 deletions(-)

diff --git a/drivers/infiniband/core/mad.c b/drivers/infiniband/core/mad.c
index a009f7132c73..2d51f0bdc13f 100644
--- a/drivers/infiniband/core/mad.c
+++ b/drivers/infiniband/core/mad.c
@@ -1152,21 +1152,21 @@ int ib_send_mad(struct ib_mad_send_wr_private 
*mad_send_wr)
 
mad_agent = mad_send_wr->send_buf.mad_agent;
sge = mad_send_wr->sg_list;
-   sge[0].addr = ib_dma_map_single(mad_agent->device,
+   sge[0].addr = dma_map_single(mad_agent->device->dma_device,
mad_send_wr->send_buf.mad,
sge[0].length,
DMA_TO_DEVICE);
-   if (unlikely(ib_dma_mapping_error(mad_agent->device, sge[0].addr)))
+   if (unlikely(dma_mapping_error(mad_agent->device->dma_device, 
sge[0].addr)))
return -ENOMEM;
 
mad_send_wr->header_mapping = sge[0].addr;
 
-   sge[1].addr = ib_dma_map_single(mad_agent->device,
+   sge[1].addr = dma_map_single(mad_agent->device->dma_device,
ib_get_payload(mad_send_wr),
sge[1].length,
DMA_TO_DEVICE);
-   if (unlikely(ib_dma_mapping_error(mad_agent->device, sge[1].addr))) {
-  

[PATCH v2] staging: most: hdm-usb: Fix mismatch between types used in sizeof operator

[Eric Salem]

Fixed mismatch between types used in sizeof operator.

Signed-off-by: Eric Salem 
---
 drivers/staging/most/hdm-usb/hdm_usb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/most/hdm-usb/hdm_usb.c 
b/drivers/staging/most/hdm-usb/hdm_usb.c
index 8a6da16..01e3a31 100644
--- a/drivers/staging/most/hdm-usb/hdm_usb.c
+++ b/drivers/staging/most/hdm-usb/hdm_usb.c
@@ -145,7 +145,7 @@ static void wq_netinfo(struct work_struct *wq_obj);
 static inline int drci_rd_reg(struct usb_device *dev, u16 reg, u16 *buf)
 {
int retval;
-   __le16 *dma_buf = kzalloc(sizeof(__le16), GFP_KERNEL);
+   __le16 *dma_buf = kzalloc(sizeof(*dma_buf), GFP_KERNEL);
u8 req_type = USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE;
 
if (!dma_buf)
@@ -154,7 +154,7 @@ static inline int drci_rd_reg(struct usb_device *dev, u16 
reg, u16 *buf)
retval = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
 DRCI_READ_REQ, req_type,
 0x,
-reg, dma_buf, sizeof(u16), 5 * HZ);
+reg, dma_buf, sizeof(*dma_buf), 5 * HZ);
*buf = le16_to_cpu(*dma_buf);
kfree(dma_buf);
 
-- 
2.9.3

On 01/10/2017 10:40 AM, Greg KH wrote:
> On Mon, Jan 09, 2017 at 09:25:56PM -0600, Eric Salem wrote:
>> Fixed the following sparse warning:
>>
>> drivers/staging/most/hdm-usb/hdm_usb.c:158:16: warning:
>> cast to restricted __le16
>>
>> by correcting the variable's type (also updated sizeof).
>>
>> Signed-off-by: Eric Salem 
>> Acked-by: Christian Gromm 
>> ---
>>  drivers/staging/most/hdm-usb/hdm_usb.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> This patch doesn't apply against linux-next, can you refresh it and
> resend?
> 
> thanks,
> 
> greg k-h
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: rtl8192u: Correct coding style issues.

[Javier Rodriguez]

Add character '*' in all lines of the block comments.
Also remove one unnecessary line.

Signed-off-by: Javier Rodriguez 
---
 drivers/staging/rtl8192u/r8180_93cx6.h | 27 +--
 1 file changed, 13 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8180_93cx6.h 
b/drivers/staging/rtl8192u/r8180_93cx6.h
index 9cf7f58..643d465 100644
--- a/drivers/staging/rtl8192u/r8180_93cx6.h
+++ b/drivers/staging/rtl8192u/r8180_93cx6.h
@@ -1,17 +1,17 @@
 /*
-   This is part of rtl8187 OpenSource driver
-   Copyright (C) Andrea Merello 2004-2005  
-   Released under the terms of GPL (General Public Licence)
-
-   Parts of this driver are based on the GPL part of the
-   official realtek driver
-   Parts of this driver are based on the rtl8180 driver skeleton
-   from Patric Schenke & Andres Salomon
-   Parts of this driver are based on the Intel Pro Wireless 2100 GPL driver
-
-   We want to thank the Authors of such projects and the Ndiswrapper
-   project Authors.
-*/
+ * This is part of rtl8187 OpenSource driver
+ * Copyright (C) Andrea Merello 2004-2005  
+ * Released under the terms of GPL (General Public Licence)
+ *
+ * Parts of this driver are based on the GPL part of the
+ * official realtek driver
+ * Parts of this driver are based on the rtl8180 driver skeleton
+ * from Patric Schenke & Andres Salomon
+ * Parts of this driver are based on the Intel Pro Wireless 2100 GPL driver
+ *
+ * We want to thank the Authors of such projects and the Ndiswrapper
+ * project Authors.
+ */
 
 /*This files contains card eeprom (93c46 or 93c56) programming routines*/
 /*memory is addressed by WORDS*/
@@ -39,5 +39,4 @@
 #define EPROM_TXPW2 0x1b
 #define EPROM_TXPW1 0x3d
 
-
 int eprom_read(struct net_device *dev, u32 addr); /* reads a 16 bits word */
-- 
1.9.1

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

Re: [PATCH] staging: android/ion: Fix coding style issues

[Joe Perches]

On Tue, 2017-01-10 at 23:40 +0200, Bogdan Purcareata wrote:
> Fix following checkpatch warnings:
> - Lines over 80 characters
> - void function with return statement
> - Unaligned comment mark
> - Header function prototypes missing variable names

Please read Documentation/SubmittingPatches
(umm, make that Documentation/process/submitting-patches.rst)

Make sure to send the patch to yourself only until
you know you can apply it correctly and then send
it to the mailing list.

btw:

This should probably be a series of 4 patches, each
single patch doing one of the things listed above.

And do please use checkpatch on your proposed patches.

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

Re: [PATCH] staging: android/ion: Fix coding style issues

[Greg KH]

On Tue, Jan 10, 2017 at 11:40:30PM +0200, Bogdan Purcareata wrote:
> Fix following checkpatch warnings:
> - Lines over 80 characters
> - void function with return statement
> - Unaligned comment mark
> - Header function prototypes missing variable names
> 
> Sent against staging-next.
> 
> Signed-off-by: Bogdan Purcareata 
> ---
>  drivers/staging/android/ion/ion-ioctl.c |  3 ++-
>  drivers/staging/android/ion/ion_of.c|  1 -
>  drivers/staging/android/ion/ion_priv.h  | 40
> -

Your patch is line-wrapped and can't be applied :(

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

[PATCH] staging: android/ion: Fix coding style issues

[Bogdan Purcareata]

Fix following checkpatch warnings:
- Lines over 80 characters
- void function with return statement
- Unaligned comment mark
- Header function prototypes missing variable names

Sent against staging-next.

Signed-off-by: Bogdan Purcareata 
---
 drivers/staging/android/ion/ion-ioctl.c |  3 ++-
 drivers/staging/android/ion/ion_of.c|  1 -
 drivers/staging/android/ion/ion_priv.h  | 40 
-

 3 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c

index 7e7431d..e28fffb 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -111,7 +111,8 @@ long ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)

struct ion_handle *handle;

mutex_lock(>lock);
-   handle = ion_handle_get_by_id_nolock(client, 
data.handle.handle);
+   handle = ion_handle_get_by_id_nolock(client,
+   data.handle.handle);
if (IS_ERR(handle)) {
mutex_unlock(>lock);
return PTR_ERR(handle);
diff --git a/drivers/staging/android/ion/ion_of.c 
b/drivers/staging/android/ion/ion_of.c

index 46b2bb9..7791c70 100644
--- a/drivers/staging/android/ion/ion_of.c
+++ b/drivers/staging/android/ion/ion_of.c
@@ -161,7 +161,6 @@ static int rmem_ion_device_init(struct reserved_mem 
*rmem, struct device *dev)

 static void rmem_ion_device_release(struct reserved_mem *rmem,
struct device *dev)
 {
-   return;
 }

 static const struct reserved_mem_ops rmem_dma_ops = {
diff --git a/drivers/staging/android/ion/ion_priv.h 
b/drivers/staging/android/ion/ion_priv.h

index 3c3b324..444a1a1 100644
--- a/drivers/staging/android/ion/ion_priv.h
+++ b/drivers/staging/android/ion/ion_priv.h
@@ -54,7 +54,7 @@
  * handle, used for debugging
  * @pid:   pid of last client to reference this buffer in a
  * handle, used for debugging
-*/
+ */
 struct ion_buffer {
struct kref ref;
union {
@@ -287,10 +287,10 @@ void ion_device_add_heap(struct ion_device *dev, 
struct ion_heap *heap);

  * some helpers for common operations on buffers using the sg_table
-void *ion_heap_map_kernel(struct ion_heap *, struct ion_buffer *);
-void ion_heap_unmap_kernel(struct ion_heap *, struct ion_buffer *);
-int ion_heap_map_user(struct ion_heap *, struct ion_buffer *,
-   struct vm_area_struct *);
+void *ion_heap_map_kernel(struct ion_heap *heap, struct ion_buffer 
*buffer);
+void ion_heap_unmap_kernel(struct ion_heap *heap, struct ion_buffer 
*buffer);

+int ion_heap_map_user(struct ion_heap *heap, struct ion_buffer *buffer,
+   struct vm_area_struct *vma);
 int ion_heap_buffer_zero(struct ion_buffer *buffer);
 int ion_heap_pages_zero(struct page *page, size_t size, pgprot_t pgprot);

@@ -371,21 +371,21 @@ size_t ion_heap_freelist_size(struct ion_heap *heap);
  * heaps as appropriate.
  */

-struct ion_heap *ion_heap_create(struct ion_platform_heap *);
-void ion_heap_destroy(struct ion_heap *);
-struct ion_heap *ion_system_heap_create(struct ion_platform_heap *);
-void ion_system_heap_destroy(struct ion_heap *);
+struct ion_heap *ion_heap_create(struct ion_platform_heap *heap_data);
+void ion_heap_destroy(struct ion_heap *heap);
+struct ion_heap *ion_system_heap_create(struct ion_platform_heap *unused);
+void ion_system_heap_destroy(struct ion_heap *heap);

-struct ion_heap *ion_system_contig_heap_create(struct ion_platform_heap *);
-void ion_system_contig_heap_destroy(struct ion_heap *);
+struct ion_heap *ion_system_contig_heap_create(struct ion_platform_heap 
*heap);

+void ion_system_contig_heap_destroy(struct ion_heap *heap);

-struct ion_heap *ion_carveout_heap_create(struct ion_platform_heap *);
-void ion_carveout_heap_destroy(struct ion_heap *);
+struct ion_heap *ion_carveout_heap_create(struct ion_platform_heap 
*heap_data);

+void ion_carveout_heap_destroy(struct ion_heap *heap);

-struct ion_heap *ion_chunk_heap_create(struct ion_platform_heap *);
-void ion_chunk_heap_destroy(struct ion_heap *);
-struct ion_heap *ion_cma_heap_create(struct ion_platform_heap *);
-void ion_cma_heap_destroy(struct ion_heap *);
+struct ion_heap *ion_chunk_heap_create(struct ion_platform_heap 
*heap_data);

+void ion_chunk_heap_destroy(struct ion_heap *heap);
+struct ion_heap *ion_cma_heap_create(struct ion_platform_heap *data);
+void ion_cma_heap_destroy(struct ion_heap *heap);

 /**
  * functions for creating and destroying a heap pool -- allows you
@@ -427,9 +427,9 @@ struct ion_page_pool {

 struct ion_page_pool *ion_page_pool_create(gfp_t gfp_mask, unsigned 
int order,

   bool cached);
-void ion_page_pool_destroy(struct ion_page_pool *);
-struct 

[PATCH] staging: greybus: loopback_test: fix checkpatch bad function definition error

[Abdul Rauf]

Fix the following Errors:
Bad function definition - void abort() should probably be void abort(void)

Signed-off-by: Abdul Rauf 
---
 drivers/staging/greybus/tools/loopback_test.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/greybus/tools/loopback_test.c 
b/drivers/staging/greybus/tools/loopback_test.c
index f7f4cd6fb55b..5312b2aa32f1 100644
--- a/drivers/staging/greybus/tools/loopback_test.c
+++ b/drivers/staging/greybus/tools/loopback_test.c
@@ -168,7 +168,7 @@ GET_AVG(latency_avg);
 GET_AVG(apbridge_unipro_latency_avg);
 GET_AVG(gbphy_firmware_latency_avg);
 
-void abort()
+void abort(void)
 {
_exit(1);
 }
-- 
2.11.0

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

[PATCH] staging: greybus: fix checkpatch braces not necessary warning

[Abdul Rauf]

Fix the following warnings:
braces {} are not necessary for any arm of this statement

Signed-off-by: Abdul Rauf 
---
 drivers/staging/greybus/loopback.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/greybus/loopback.c 
b/drivers/staging/greybus/loopback.c
index 3184dd3999b5..5ede67fcdd61 100644
--- a/drivers/staging/greybus/loopback.c
+++ b/drivers/staging/greybus/loopback.c
@@ -1037,13 +1037,12 @@ static int gb_loopback_fn(void *data)
 
/* Else operations to perform */
if (gb->async) {
-   if (type == GB_LOOPBACK_TYPE_PING) {
+   if (type == GB_LOOPBACK_TYPE_PING)
error = gb_loopback_async_ping(gb);
-   } else if (type == GB_LOOPBACK_TYPE_TRANSFER) {
+   else if (type == GB_LOOPBACK_TYPE_TRANSFER)
error = gb_loopback_async_transfer(gb, size);
-   } else if (type == GB_LOOPBACK_TYPE_SINK) {
+   else if (type == GB_LOOPBACK_TYPE_SINK)
error = gb_loopback_async_sink(gb, size);
-   }
 
if (error)
gb->error++;
-- 
2.11.0

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

RE: [PATCH] staging: unisys: fix checkpatch block comments warning

[Kershner, David A]

> -Original Message-
> From: Abdul Rauf Mujahid [mailto:abdulraufmuja...@gmail.com]
> Sent: Tuesday, January 10, 2017 6:51 PM
> To: Kershner, David A ;
> gre...@linuxfoundation.org; j...@redhat.com; *S-Par-Maintainer
> 
> Cc: de...@driverdev.osuosl.org
> Subject: Re: [PATCH] staging: unisys: fix checkpatch block comments warning
> 
> 
> 
> On 01/10/2017 06:36 PM, Kershner, David A wrote:
> >> -Original Message-
> >> From: Abdul Rauf [mailto:abdulraufmuja...@gmail.com]
> >> Sent: Tuesday, January 10, 2017 6:24 PM
> >> To: gre...@linuxfoundation.org; j...@redhat.com; *S-Par-Maintainer
> >> 
> >> Cc: de...@driverdev.osuosl.org
> >> Subject: [PATCH] staging: unisys: fix checkpatch block comments warning
> > This patch has the same subject line as the previous patch? Which one
> > should we use? Or can you make the names unique?
> >
> > David Kershner
> >
> >> Fix the following warnings:
> >> Block comments should align the * on each line
> >>
> >> Signed-off-by: Abdul Rauf 
> >> ---
> >>  drivers/staging/unisys/visorbus/visorchipset.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/staging/unisys/visorbus/visorchipset.c
> >> b/drivers/staging/unisys/visorbus/visorchipset.c
> >> index 336af52d43d7..4e630ea527e8 100644
> >> --- a/drivers/staging/unisys/visorbus/visorchipset.c
> >> +++ b/drivers/staging/unisys/visorbus/visorchipset.c
> >> @@ -1409,7 +1409,7 @@ parahotplug_process_message(struct
> >> controlvm_message *inmsg)
> >> *
> >> * devices are automatically enabled at
> >> * initialization.
> >> -  */
> >> +   */
> >>parahotplug_request_kickoff(req);
> >>controlvm_respond_physdev_changestate
> >>(>hdr,
> >> --
> >> 2.11.0
> you should use both of them. I am sending both again by changing their
> names.

Thanks!

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

Re: [PATCH] staging: unisys: fix checkpatch block comments warning

[Abdul Rauf Mujahid]

On 01/10/2017 06:36 PM, Kershner, David A wrote:
>> -Original Message-
>> From: Abdul Rauf [mailto:abdulraufmuja...@gmail.com]
>> Sent: Tuesday, January 10, 2017 6:24 PM
>> To: gre...@linuxfoundation.org; j...@redhat.com; *S-Par-Maintainer
>> 
>> Cc: de...@driverdev.osuosl.org
>> Subject: [PATCH] staging: unisys: fix checkpatch block comments warning
> This patch has the same subject line as the previous patch? Which one
> should we use? Or can you make the names unique?
>
> David Kershner
>
>> Fix the following warnings:
>> Block comments should align the * on each line
>>
>> Signed-off-by: Abdul Rauf 
>> ---
>>  drivers/staging/unisys/visorbus/visorchipset.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/staging/unisys/visorbus/visorchipset.c
>> b/drivers/staging/unisys/visorbus/visorchipset.c
>> index 336af52d43d7..4e630ea527e8 100644
>> --- a/drivers/staging/unisys/visorbus/visorchipset.c
>> +++ b/drivers/staging/unisys/visorbus/visorchipset.c
>> @@ -1409,7 +1409,7 @@ parahotplug_process_message(struct
>> controlvm_message *inmsg)
>>   *
>>   * devices are automatically enabled at
>>   * initialization.
>> -*/
>> + */
>>  parahotplug_request_kickoff(req);
>>  controlvm_respond_physdev_changestate
>>  (>hdr,
>> --
>> 2.11.0
you should use both of them. I am sending both again by changing their names.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH] staging: unisys: fix checkpatch block comments warning

[Kershner, David A]

> -Original Message-
> From: Abdul Rauf [mailto:abdulraufmuja...@gmail.com]
> Sent: Tuesday, January 10, 2017 6:24 PM
> To: gre...@linuxfoundation.org; j...@redhat.com; *S-Par-Maintainer
> 
> Cc: de...@driverdev.osuosl.org
> Subject: [PATCH] staging: unisys: fix checkpatch block comments warning

This patch has the same subject line as the previous patch? Which one
should we use? Or can you make the names unique?

David Kershner

> 
> Fix the following warnings:
> Block comments should align the * on each line
> 
> Signed-off-by: Abdul Rauf 
> ---
>  drivers/staging/unisys/visorbus/visorchipset.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/unisys/visorbus/visorchipset.c
> b/drivers/staging/unisys/visorbus/visorchipset.c
> index 336af52d43d7..4e630ea527e8 100644
> --- a/drivers/staging/unisys/visorbus/visorchipset.c
> +++ b/drivers/staging/unisys/visorbus/visorchipset.c
> @@ -1409,7 +1409,7 @@ parahotplug_process_message(struct
> controlvm_message *inmsg)
>*
>* devices are automatically enabled at
>* initialization.
> - */
> +  */
>   parahotplug_request_kickoff(req);
>   controlvm_respond_physdev_changestate
>   (>hdr,
> --
> 2.11.0

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

[PATCH] staging: unisys: fix checkpatch block comments warning

[Abdul Rauf]

Fix the following warnings:
Block comments should align the * on each line

Signed-off-by: Abdul Rauf 
---
 drivers/staging/unisys/visorbus/visorchipset.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index 336af52d43d7..4e630ea527e8 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -1409,7 +1409,7 @@ parahotplug_process_message(struct controlvm_message 
*inmsg)
 *
 * devices are automatically enabled at
 * initialization.
-   */
+*/
parahotplug_request_kickoff(req);
controlvm_respond_physdev_changestate
(>hdr,
-- 
2.11.0

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

Re: [PATCH 01/18] Drivers: hv: vmbus: Move the definition of hv_x64_msr_hypercall_contents

[Greg KH]

On Fri, Dec 30, 2016 at 01:35:55PM -0800, k...@exchange.microsoft.com wrote:
> From: K. Y. Srinivasan 
> 
> As part of the effort to separate out architecture specific code, move the
> definition of hv_x64_msr_hypercall_contents to x86 specific header file.
> 
> Signed-off-by: K. Y. Srinivasan 
> ---
>  arch/x86/include/asm/mshyperv.h |   12 
>  drivers/hv/hyperv_vmbus.h   |   15 ---
>  2 files changed, 12 insertions(+), 15 deletions(-)

This series doesn't apply against my tree.  Can you please refresh it
and resend?

thanks,

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

Re: [PATCH] greybus: checkpatch: Change parameter type unsigned to unsigned int

[roman . sommer]

> Fair enough, but you are fixing all of these new "unsigned int"
> warnings in that driver, right?
>
> How about fixing the sole remaining instance in the loopback driver so
> that this is done for the whole subsystem once and for all?

Thanks for the hint, I will do that.

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

Re: [PATCH 0/9] staging: vc04_services: Clean up vchiq driver

[Greg Kroah-Hartman]

On Sun, Jan 08, 2017 at 06:15:09PM +, Stefan Wahren wrote:
> This is a loose bunch of clean up patches for the bcm2835 vchiq driver.

All now applied, thanks.

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

Re: [PATCH] greybus: checkpatch: Change parameter type unsigned to unsigned int

[Johan Hovold]

On Tue, Jan 10, 2017 at 05:21:24PM +0100, Roman Sommer wrote:
> From: Christian Bewermeyer 
> 
> Note that this patch does not fix all checkpatch warnings for
> gpio.c

Fair enough, but you are fixing all of these new "unsigned int"
warnings in that driver, right?

How about fixing the sole remaining instance in the loopback driver so
that this is done for the whole subsystem once and for all?

Also your Subject should be

staging: greybus: gpio: fix checkpatch unsigned warnings

unless doing this subsystem-wide, in which case you can drop the
"gpio" module prefix.

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

Re: [PATCH] staging: most: hdm-usb: Fix sparse warning cast to restricted __le16

[Greg KH]

On Mon, Jan 09, 2017 at 09:25:56PM -0600, Eric Salem wrote:
> Fixed the following sparse warning:
> 
> drivers/staging/most/hdm-usb/hdm_usb.c:158:16: warning:
> cast to restricted __le16
> 
> by correcting the variable's type (also updated sizeof).
> 
> Signed-off-by: Eric Salem 
> Acked-by: Christian Gromm 
> ---
>  drivers/staging/most/hdm-usb/hdm_usb.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

This patch doesn't apply against linux-next, can you refresh it and
resend?

thanks,

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

[PATCH] greybus: checkpatch: Change parameter type unsigned to unsigned int

[Roman Sommer]

From: Christian Bewermeyer 

Note that this patch does not fix all checkpatch warnings for
gpio.c

Signed-off-by: Christian Bewermeyer 
Signed-off-by: Roman Sommer 
---
 drivers/staging/greybus/gpio.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/greybus/gpio.c b/drivers/staging/greybus/gpio.c
index 250caa0..0c95bce 100644
--- a/drivers/staging/greybus/gpio.c
+++ b/drivers/staging/greybus/gpio.c
@@ -410,21 +410,21 @@ static int gb_gpio_request_handler(struct gb_operation 
*op)
return 0;
 }
 
-static int gb_gpio_request(struct gpio_chip *chip, unsigned offset)
+static int gb_gpio_request(struct gpio_chip *chip, unsigned int offset)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
 
return gb_gpio_activate_operation(ggc, (u8)offset);
 }
 
-static void gb_gpio_free(struct gpio_chip *chip, unsigned offset)
+static void gb_gpio_free(struct gpio_chip *chip, unsigned int offset)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
 
gb_gpio_deactivate_operation(ggc, (u8)offset);
 }
 
-static int gb_gpio_get_direction(struct gpio_chip *chip, unsigned offset)
+static int gb_gpio_get_direction(struct gpio_chip *chip, unsigned int offset)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
u8 which;
@@ -438,22 +438,22 @@ static int gb_gpio_get_direction(struct gpio_chip *chip, 
unsigned offset)
return ggc->lines[which].direction ? 1 : 0;
 }
 
-static int gb_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
+static int gb_gpio_direction_input(struct gpio_chip *chip, unsigned int offset)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
 
return gb_gpio_direction_in_operation(ggc, (u8)offset);
 }
 
-static int gb_gpio_direction_output(struct gpio_chip *chip, unsigned offset,
-   int value)
+static int gb_gpio_direction_output(struct gpio_chip *chip, unsigned int 
offset,
+   int value)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
 
return gb_gpio_direction_out_operation(ggc, (u8)offset, !!value);
 }
 
-static int gb_gpio_get(struct gpio_chip *chip, unsigned offset)
+static int gb_gpio_get(struct gpio_chip *chip, unsigned int offset)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
u8 which;
@@ -467,15 +467,15 @@ static int gb_gpio_get(struct gpio_chip *chip, unsigned 
offset)
return ggc->lines[which].value;
 }
 
-static void gb_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
+static void gb_gpio_set(struct gpio_chip *chip, unsigned int offset, int value)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
 
gb_gpio_set_value_operation(ggc, (u8)offset, !!value);
 }
 
-static int gb_gpio_set_debounce(struct gpio_chip *chip, unsigned offset,
-   unsigned debounce)
+static int gb_gpio_set_debounce(struct gpio_chip *chip, unsigned int offset,
+   unsigned int debounce)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
u16 usec;
@@ -593,7 +593,7 @@ static int gb_gpio_irqchip_add(struct gpio_chip *chip,
 {
struct gb_gpio_controller *ggc;
unsigned int offset;
-   unsigned irq_base;
+   unsigned int irq_base;
 
if (!chip || !irqchip)
return -EINVAL;
@@ -625,7 +625,7 @@ static int gb_gpio_irqchip_add(struct gpio_chip *chip,
return 0;
 }
 
-static int gb_gpio_to_irq(struct gpio_chip *chip, unsigned offset)
+static int gb_gpio_to_irq(struct gpio_chip *chip, unsigned int offset)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
 
-- 
2.7.4

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

Re: [PATCH v2] Staging: greybus: style fix, permissions as octal

[Greg KH]

On Mon, Jan 09, 2017 at 02:24:29PM +0100, Johan Hovold wrote:
> On Fri, Jan 06, 2017 at 08:43:57PM +1300, Derek Robson wrote:
> > Changed permissions to be in octal style.
> > Found by checkpatch.
> > 
> > Signed-off-by: Derek Robson 
> > ---
> > 
> > This version of patch also make the file type part of the mask with the 
> > permissions, as per recommendation from Greg K-H
> > 
> >  drivers/staging/greybus/camera.c | 10 +-
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/staging/greybus/camera.c 
> > b/drivers/staging/greybus/camera.c
> > index 0ee291ca2c72..73ddb612953b 100644
> > --- a/drivers/staging/greybus/camera.c
> > +++ b/drivers/staging/greybus/camera.c
> > @@ -1067,22 +1067,22 @@ struct gb_camera_debugfs_entry {
> >  static const struct gb_camera_debugfs_entry gb_camera_debugfs_entries[] = {
> > {
> > .name = "capabilities",
> > -   .mask = S_IFREG | S_IRUGO,
> > +   .mask = 0100444,
> 
> This is not readable at all. Octal numbers make sense for the
> permissions bits, but not for the rest.
> 
> We have code that mix symbolic macros for the higher bits and octal
> permissions, please do so here too.

Yeah, Johan is right, sorry about that, your first patch was better :(

Derek, can you resend that?

thanks,

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

Re: [PATCH v2 0/4] hv_util: adjust system time smoothly

[Thomas Gleixner]

Vitaly,

On Tue, 10 Jan 2017, Vitaly Kuznetsov wrote:
> Thomas Gleixner  writes:
> > 1) do_adjtimex() is assuming that there is a single client connected which
> >is responsible for the updates. So I seriously doubt that a NTP client
> >running in the guest will cooperate nicely with that timesync magic
> >under all circumstances.
> 
> True, as Stephen suggested we'll probably need a way to inform (or
> block) the second NTP client about the ongoing timesync.

I don't see how that's supposed to work.

> > 2) There is still the possibility to force do_settimeofday() calls which
> >will upset NTP clients and have other side effects.
> >
> >Why is this call necessary at all? Just because it's in some spec?
> 
> ICTIMESYNCFLAG_SYNC flag, demanding us to do so, is only set on the
> first packet (when our VM boots) and after suspend/resume/migration
> events. In these cases guest's time can be off by minutes/hours and
> do_settimeofday() is probably justified.

Usually boot/resume time is pretty accurate through RTC readout, but IIRC
then Windows still insists on RTC being set to local time instead of UTC,
which does not really work well on Linux.

> >
> > 3) What happens if you have a PTP capable network card mapped into your
> >guest and the guest uses PTP for time synchronization? The outcome is
> >predictible: CRAP.
> >
> > I can see the value for a host wide time synchronization, but please use
> > mechanisms which do not interfere with the rest of the time eco system in
> > Linux.
> >
> > The timesync thing happens periodically every 5 seconds, which you can feed
> > nicely into the PPS subsystem and then the guest side NTP daemon can
> > utilize it (or not).
> >
> 
> My understanding is that we have no guarantees from the host that these
> messages are sent every 5 seconds and even when they are the interval is
> not very precise. We can probably create a 'fake' pps signal out of
> these messages (e.g. these messages will just be adjusting the frequency
> of the signal. I can play with such approach if you think this is the
> way to go.

The PPS stuff has some expectations about the interval, but it's a rather
solid piece of art and I think it's worth a try.

Thanks,

tglx


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

Re: [PATCH v2 0/4] hv_util: adjust system time smoothly

[Vitaly Kuznetsov]

Thomas Gleixner  writes:

> On Wed, 4 Jan 2017, Vitaly Kuznetsov wrote:
>
>> Changes since v1:
>> - do do_settimeofday64() when ICTIMESYNCFLAG_SYNC flag is present in the
>>   request (Alex Ng)
>> - add pr_debug() for the case when do_adjtimex() fails (Alex Ng)
>> 
>> Original description:
>> 
>> With TimeSync version 4 protocol support we started updating system time
>> continuously through the whole lifetime of Hyper-V guests. Every 5 seconds
>> there is a time sample from the host which triggers do_settimeofday[64]().
>> While the time from the host is very accurate such adjustments may cause
>> issues:
>> - Time is jumping forward and backward, some applications may misbehave.
>> - In case an NTP client is run in parallel things may go south, e.g. when
>>   an NTP client tries to adjust tick/frequency with ADJ_TICK/ADJ_FREQUENCY
>>   the Hyper-V module will not see this changes and time will oscillate and
>>   never converge.
>> - Systemd starts annoying you by printing "Time has been changed" every 5
>>   seconds to the system log.
>> 
>> With this series I suggest to use do_adjtimex() to adjust time. My tests
>> show that such method gives equally good time convergence but avoids all
>> the drawbacks described above.
>
> To be honest, I think all of this is just tinkering.
>

Thank you for your comments, Thomas,

> 1) do_adjtimex() is assuming that there is a single client connected which
>is responsible for the updates. So I seriously doubt that a NTP client
>running in the guest will cooperate nicely with that timesync magic
>under all circumstances.

True, as Stephen suggested we'll probably need a way to inform (or
block) the second NTP client about the ongoing timesync.

>
> 2) There is still the possibility to force do_settimeofday() calls which
>will upset NTP clients and have other side effects.
>
>Why is this call necessary at all? Just because it's in some spec?

ICTIMESYNCFLAG_SYNC flag, demanding us to do so, is only set on the
first packet (when our VM boots) and after suspend/resume/migration
events. In these cases guest's time can be off by minutes/hours and
do_settimeofday() is probably justified.

>
> 3) What happens if you have a PTP capable network card mapped into your
>guest and the guest uses PTP for time synchronization? The outcome is
>predictible: CRAP.
>
> I can see the value for a host wide time synchronization, but please use
> mechanisms which do not interfere with the rest of the time eco system in
> Linux.
>
> The timesync thing happens periodically every 5 seconds, which you can feed
> nicely into the PPS subsystem and then the guest side NTP daemon can
> utilize it (or not).
>

My understanding is that we have no guarantees from the host that these
messages are sent every 5 seconds and even when they are the interval is
not very precise. We can probably create a 'fake' pps signal out of
these messages (e.g. these messages will just be adjusting the frequency
of the signal. I can play with such approach if you think this is the
way to go.

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

[PATCH] vme: Fix wrong pointer utilization in ca91cx42_slave_get

[Augusto Mecking Caringi]

In ca91cx42_slave_get function, the value pointed by vme_base pointer is
set through:

*vme_base = ioread32(bridge->base + CA91CX42_VSI_BS[i]);

So it must be dereferenced to be used in calculation of pci_base:

*pci_base = (dma_addr_t)*vme_base + pci_offset;

This bug was caught thanks to the following gcc warning:

drivers/vme/bridges/vme_ca91cx42.c: In function ‘ca91cx42_slave_get’:
drivers/vme/bridges/vme_ca91cx42.c:467:14: warning: cast from pointer to
integer of different size [-Wpointer-to-int-cast]
*pci_base = (dma_addr_t)vme_base + pci_offset;

Signed-off-by: Augusto Mecking Caringi 
---
 drivers/vme/bridges/vme_ca91cx42.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vme/bridges/vme_ca91cx42.c 
b/drivers/vme/bridges/vme_ca91cx42.c
index 6b5ee89..7cc5122 100644
--- a/drivers/vme/bridges/vme_ca91cx42.c
+++ b/drivers/vme/bridges/vme_ca91cx42.c
@@ -464,7 +464,7 @@ static int ca91cx42_slave_get(struct vme_slave_resource 
*image, int *enabled,
vme_bound = ioread32(bridge->base + CA91CX42_VSI_BD[i]);
pci_offset = ioread32(bridge->base + CA91CX42_VSI_TO[i]);
 
-   *pci_base = (dma_addr_t)vme_base + pci_offset;
+   *pci_base = (dma_addr_t)*vme_base + pci_offset;
*size = (unsigned long long)((vme_bound - *vme_base) + granularity);
 
*enabled = 0;
-- 
2.7.4

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

[PATCH next] rtlwifi: rtl8192de: fix missing curly braces

[Vincent Stehlé]

Restore some curly braces that have been removed in commit c93ac39da006457f
("rtlwifi: Remove some redundant code") while removing redundant messages
and extraneous braces.

This fixes the following smatch warning:

  drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c:326 rtl92d_download_fw() 
warn: curly braces intended?

...and the following coccinelle warning:

  drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c:325:2-38: code aligned 
with following code on line 326

Fixes: c93ac39da006457f ("rtlwifi: Remove some redundant code")
Signed-off-by: Vincent Stehlé <vincent.ste...@laposte.net>
Cc: Larry Finger <larry.fin...@lwfinger.net>
Cc: Kalle Valo <kv...@codeaurora.org>
Cc: Joe Perches <j...@perches.com>
Cc: Ping-Ke Shih <pks...@realtek.com>
---


Hi,

I saw that in Linux next-20170110.

Best regards,

Vincent.


 drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c
index aa1e51c871df..bcde4da4e593 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c
@@ -321,9 +321,10 @@ int rtl92d_download_fw(struct ieee80211_hw *hw)
value &= (~BIT(5));
rtl_write_byte(rtlpriv, 0x1f, value);
spin_unlock_irqrestore(_for_fwdownload, flags);
-   if (err)
+   if (err) {
pr_err("fw is not ready to run!\n");
goto exit;
+   }
 exit:
err = _rtl92d_fw_init(hw);
return err;
-- 
2.11.0

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

Re: [PATCH] staging: most: hdm-usb: Fix sparse warning cast to restricted __le16

[Christian Gromm]

On Mon, 9 Jan 2017 21:25:56 -0600
Eric Salem  wrote:

> Fixed the following sparse warning:
> 
> drivers/staging/most/hdm-usb/hdm_usb.c:158:16: warning:
> cast to restricted __le16
> 
> by correcting the variable's type (also updated sizeof).
> 
> Signed-off-by: Eric Salem 

Acked-by: Christian Gromm 

> ---
>  drivers/staging/most/hdm-usb/hdm_usb.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/most/hdm-usb/hdm_usb.c 
> b/drivers/staging/most/hdm-usb/hdm_usb.c
> index d6db0bd..01e3a31 100644
> --- a/drivers/staging/most/hdm-usb/hdm_usb.c
> +++ b/drivers/staging/most/hdm-usb/hdm_usb.c
> @@ -145,7 +145,7 @@ static void wq_netinfo(struct work_struct *wq_obj);
>  static inline int drci_rd_reg(struct usb_device *dev, u16 reg, u16 *buf)
>  {
>   int retval;
> - u16 *dma_buf = kzalloc(sizeof(u16), GFP_KERNEL);
> + __le16 *dma_buf = kzalloc(sizeof(*dma_buf), GFP_KERNEL);
>   u8 req_type = USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE;
>  
>   if (!dma_buf)
> @@ -154,7 +154,7 @@ static inline int drci_rd_reg(struct usb_device *dev, u16 
> reg, u16 *buf)
>   retval = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
>DRCI_READ_REQ, req_type,
>0x,
> -  reg, dma_buf, sizeof(u16), 5 * HZ);
> +  reg, dma_buf, sizeof(*dma_buf), 5 * HZ);
>   *buf = le16_to_cpu(*dma_buf);
>   kfree(dma_buf);
>  

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