[PATCH] staging: lustre: really make lustre dependent on LNet

2016-03-14 Thread Arnd Bergmann 
A patch intended to add a dependency on LNET for lustre didn't
actually do that and instead allowed configurations that contain
lustre with lnet but without IPv4 support that subsequently
fail to link:

warning: (LUSTRE_FS) selects LNET which has unmet direct dependencies (STAGING 
&& INET && m && MODULES)
ERROR: "kernel_sendmsg" [drivers/staging/lustre/lnet/lnet/lnet.ko] undefined!
ERROR: "sock_create_lite" [drivers/staging/lustre/lnet/lnet/lnet.ko] undefined!
ERROR: "sock_release" [drivers/staging/lustre/lnet/lnet/lnet.ko] undefined!
ERROR: "release_sock" [drivers/staging/lustre/lnet/klnds/socklnd/ksocklnd.ko] 
undefined!
ERROR: "kernel_sendmsg" [drivers/staging/lustre/lnet/klnds/socklnd/ksocklnd.ko] 
undefined!
ERROR: "tcp_sendpage" [drivers/staging/lustre/lnet/klnds/socklnd/ksocklnd.ko] 
undefined!

This adds the one-line change that was evidently missing from the
commit, doing what was intended there to have a correct set of dependencies.

Signed-off-by: Arnd Bergmann 
Fixes: b08bb6bb5af5 ("staging: lustre: make lustre dependent on LNet")
---
 drivers/staging/lustre/lustre/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lustre/Kconfig 
b/drivers/staging/lustre/lustre/Kconfig
index a09b51ce8265..8ac7cd4d6fdb 100644
--- a/drivers/staging/lustre/lustre/Kconfig
+++ b/drivers/staging/lustre/lustre/Kconfig
@@ -1,7 +1,7 @@
 config LUSTRE_FS
tristate "Lustre file system client support"
depends on m && !MIPS && !XTENSA && !SUPERH
-   select LNET
+   depends on LNET
select CRYPTO
select CRYPTO_CRC32
select CRYPTO_CRC32_PCLMUL if X86
-- 
2.7.0

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

[PATCH] staging/comedi/dt282x: avoid integer overflow warning

2016-03-14 Thread Arnd Bergmann 
gcc-6 warns about passing negative signed integer into swab16()
in the dt282x driver:

drivers/staging/comedi/drivers/dt282x.c: In function 'dt282x_load_changain':
include/uapi/linux/swab.h:14:33: warning: integer overflow in expression 
[-Woverflow]
  (((__u16)(x) & (__u16)0xff00U) >> 8)))
  ~~~^
include/uapi/linux/swab.h:107:2: note: in expansion of macro 
'___constant_swab16'
  ___constant_swab16(x) :   \
  ^~
include/uapi/linux/byteorder/big_endian.h:34:43: note: in expansion of macro 
'__swab16'
 #define __cpu_to_le16(x) ((__force __le16)__swab16((x)))
   ^~~~
include/linux/byteorder/generic.h:89:21: note: in expansion of macro 
'__cpu_to_le16'
 #define cpu_to_le16 __cpu_to_le16
 ^
arch/arm/include/asm/io.h:250:6: note: in expansion of macro 'cpu_to_le16'
  cpu_to_le16(v),__io(p)); })
  ^~~
drivers/staging/comedi/drivers/dt282x.c:566:2: note: in expansion of macro 
'outw'
  outw(DT2821_CHANCSR_LLE | DT2821_CHANCSR_NUMB(n),
  ^~~~

The warning makes sense, though the code is correct as far as I
can tell.

This disambiguates the operation by making the constant expressions
we pass here explicitly 'unsigned', which helps to avoid the warning.

Signed-off-by: Arnd Bergmann 
---
 drivers/staging/comedi/drivers/dt282x.c | 62 -
 1 file changed, 31 insertions(+), 31 deletions(-)

diff --git a/drivers/staging/comedi/drivers/dt282x.c 
b/drivers/staging/comedi/drivers/dt282x.c
index 40bf00984fa5..d4d45c759c62 100644
--- a/drivers/staging/comedi/drivers/dt282x.c
+++ b/drivers/staging/comedi/drivers/dt282x.c
@@ -69,48 +69,48 @@
  * Register map
  */
 #define DT2821_ADCSR_REG   0x00
-#define DT2821_ADCSR_ADERR (1 << 15)
-#define DT2821_ADCSR_ADCLK (1 << 9)
-#define DT2821_ADCSR_MUXBUSY   (1 << 8)
-#define DT2821_ADCSR_ADDONE(1 << 7)
-#define DT2821_ADCSR_IADDONE   (1 << 6)
+#define DT2821_ADCSR_ADERR (1u << 15)
+#define DT2821_ADCSR_ADCLK (1u << 9)
+#define DT2821_ADCSR_MUXBUSY   (1u << 8)
+#define DT2821_ADCSR_ADDONE(1u << 7)
+#define DT2821_ADCSR_IADDONE   (1u << 6)
 #define DT2821_ADCSR_GS(x) (((x) & 0x3) << 4)
 #define DT2821_ADCSR_CHAN(x)   (((x) & 0xf) << 0)
 #define DT2821_CHANCSR_REG 0x02
-#define DT2821_CHANCSR_LLE (1 << 15)
+#define DT2821_CHANCSR_LLE (1u << 15)
 #define DT2821_CHANCSR_PRESLA(x)   (((x) & 0xf) >> 8)
 #define DT2821_CHANCSR_NUMB(x) x) - 1) & 0xf) << 0)
 #define DT2821_ADDAT_REG   0x04
 #define DT2821_DACSR_REG   0x06
-#define DT2821_DACSR_DAERR (1 << 15)
+#define DT2821_DACSR_DAERR (1u << 15)
 #define DT2821_DACSR_YSEL(x)   ((x) << 9)
-#define DT2821_DACSR_SSEL  (1 << 8)
-#define DT2821_DACSR_DACRDY(1 << 7)
-#define DT2821_DACSR_IDARDY(1 << 6)
-#define DT2821_DACSR_DACLK (1 << 5)
-#define DT2821_DACSR_HBOE  (1 << 1)
-#define DT2821_DACSR_LBOE  (1 << 0)
+#define DT2821_DACSR_SSEL  (1u << 8)
+#define DT2821_DACSR_DACRDY(1u << 7)
+#define DT2821_DACSR_IDARDY(1u << 6)
+#define DT2821_DACSR_DACLK (1u << 5)
+#define DT2821_DACSR_HBOE  (1u << 1)
+#define DT2821_DACSR_LBOE  (1u << 0)
 #define DT2821_DADAT_REG   0x08
 #define DT2821_DIODAT_REG  0x0a
 #define DT2821_SUPCSR_REG  0x0c
-#define DT2821_SUPCSR_DMAD (1 << 15)
-#define DT2821_SUPCSR_ERRINTEN (1 << 14)
-#define DT2821_SUPCSR_CLRDMADNE(1 << 13)
-#define DT2821_SUPCSR_DDMA (1 << 12)
-#define DT2821_SUPCSR_DS_PIO   (0 << 10)
-#define DT2821_SUPCSR_DS_AD_CLK(1 << 10)
-#define DT2821_SUPCSR_DS_DA_CLK(2 << 10)
-#define DT2821_SUPCSR_DS_AD_TRIG   (3 << 10)
-#define DT2821_SUPCSR_BUFFB(1 << 9)
-#define DT2821_SUPCSR_SCDN (1 << 8)
-#define DT2821_SUPCSR_DACON(1 << 7)
-#define DT2821_SUPCSR_ADCINIT  (1 << 6)
-#define DT2821_SUPCSR_DACINIT  (1 << 5)
-#define DT2821_SUPCSR_PRLD (1 << 4)
-#define DT2821_SUPCSR_STRIG(1 << 3)
-#define DT2821_SUPCSR_XTRIG(1 << 2)
-#define DT2821_SUPCSR_XCLK (1 << 1)
-#define DT2821_SUPCSR_BDINIT   (1 << 0)
+#define DT2821_SUPCSR_DMAD (1u << 15)
+#define DT2821_SUPCSR_ERRINTEN (1u << 14)
+#define DT2821_SUPCSR_CLRDMADNE(1u << 13)
+#define DT2821_SUPCSR_DDMA (1u << 12)
+#define DT2821_SUPCSR_DS_PIO   (0u << 10)
+#define DT2821_SUPCSR_DS_AD_CLK(1u << 10)
+#define DT2821_SUPCSR_DS_DA_CLK(2u << 10)
+#define DT2821_SUPCSR_DS_AD_TRIG   (3u <<

[PATCH v8 1/2] staging/android: remove redundant comments on sync_merge_data

2016-03-14 Thread Gustavo Padovan 
From: Gustavo Padovan 

struct sync_merge_data already have documentation on top of the
struct definition. No need to duplicate it.

Signed-off-by: Gustavo Padovan 
Reviewed-by: Maarten Lankhorst 
---
 drivers/staging/android/uapi/sync.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/android/uapi/sync.h 
b/drivers/staging/android/uapi/sync.h
index a0cf357..4467c76 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -21,9 +21,9 @@
  * @fence: returns the fd of the new fence to userspace
  */
 struct sync_merge_data {
-   __s32   fd2; /* fd of second fence */
-   charname[32]; /* name of new fence */
-   __s32   fence; /* fd on newly created fence */
+   __s32   fd2;
+   charname[32];
+   __s32   fence;
 };
 
 /**
-- 
2.5.0

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

[PATCH v8 2/2] staging/android: refactor SYNC IOCTLs

2016-03-14 Thread Gustavo Padovan 
From: Gustavo Padovan 

Change SYNC_IOC_FILE_INFO (former SYNC_IOC_FENCE_INFO) behaviour to avoid
future API breaks and optimize buffer allocation.

Now num_fences can be filled by the caller to inform how many fences it
wants to retrieve from the kernel. If the num_fences passed is greater
than zero info->sync_fence_info should point to a buffer with enough space
to fit all fences.

However if num_fences passed to the kernel is 0, the kernel will reply
with number of fences of the sync_file.

Sending first an ioctl with num_fences = 0 can optimize buffer allocation,
in a first call with num_fences = 0 userspace will receive the actual
number of fences in the num_fences filed.

Then it can allocate a buffer with the correct size on sync_fence_info and
call SYNC_IOC_FILE_INFO again, but now with the actual value of num_fences
in the sync_file.

info->sync_fence_info was converted to __u64 pointer to prevent 32bit
compatibility issues. And a flags member was added.

An example userspace code for the later would be:

struct sync_file_info *info;
int err, size, num_fences;

info = malloc(sizeof(*info));

info.flags = 0;
err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
num_fences = info->num_fences;

if (num_fences) {
info.flags = 0;
size = sizeof(struct sync_fence_info) * num_fences;
info->num_fences = num_fences;
info->sync_fence_info = (uint64_t) calloc(num_fences,
  sizeof(struct 
sync_fence_info));

err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
}

Finally the IOCTLs numbers were changed to avoid any potential old
userspace running the old API to get weird errors. Changing the opcodes
will make them fail right away. This is just a precaution, there no
upstream users of these interfaces yet and the only user is Android, but
we don't expect anyone trying to run android userspace and all it
dependencies on top of upstream kernels.

Signed-off-by: Gustavo Padovan 
Reviewed-by: Maarten Lankhorst 
Acked-by: Greg Hackmann 
Acked-by: Rob Clark 
Acked-by: Daniel Vetter 

---
v2: fix fence_info memory leak

v3: Comments from Emil Velikov
- improve commit message
- remove __u64 cast
- remove check for output fields in file_info
- clean up sync_fill_fence_info()

Comments from Maarten Lankhorst
- remove in.num_fences && !in.sync_fence_info check
- remove info->len and use only num_fences to calculate size

Comments from Dan Carpenter
- fix info->sync_fence_info documentation

v4: remove allocated struct sync_file_info (comment from Maarten)

v5: merge all commits that were changing the ABI
---
 drivers/staging/android/sync.c  | 76 -
 drivers/staging/android/uapi/sync.h | 36 +-
 2 files changed, 67 insertions(+), 45 deletions(-)

diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 3a8f210..ae81c95 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -445,6 +445,11 @@ static long sync_file_ioctl_merge(struct sync_file 
*sync_file,
goto err_put_fd;
}
 
+   if (data.flags || data.pad) {
+   err = -EINVAL;
+   goto err_put_fd;
+   }
+
fence2 = sync_file_fdget(data.fd2);
if (!fence2) {
err = -ENOENT;
@@ -479,13 +484,9 @@ err_put_fd:
return err;
 }
 
-static int sync_fill_fence_info(struct fence *fence, void *data, int size)
+static void sync_fill_fence_info(struct fence *fence,
+   struct sync_fence_info *info)
 {
-   struct sync_fence_info *info = data;
-
-   if (size < sizeof(*info))
-   return -ENOMEM;
-
strlcpy(info->obj_name, fence->ops->get_timeline_name(fence),
sizeof(info->obj_name));
strlcpy(info->driver_name, fence->ops->get_driver_name(fence),
@@ -495,58 +496,63 @@ static int sync_fill_fence_info(struct fence *fence, void 
*data, int size)
else
info->status = 0;
info->timestamp_ns = ktime_to_ns(fence->timestamp);
-
-   return sizeof(*info);
 }
 
 static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
unsigned long arg)
 {
-   struct sync_file_info *info;
+   struct sync_file_info info;
+   struct sync_fence_info *fence_info = NULL;
__u32 size;
-   __u32 len = 0;
int ret, i;
 
-   if (copy_from_user(, (void __user *)arg, sizeof(size)))
+   if (copy_from_user(, (void __user *)arg, sizeof(info)))
return -EFAULT;
 
-   if (size < sizeof(struct sync_file_info))
+

[PATCH] Staging: wlan-ng: defined oui_rfc1042[] and oui_8021h[] arrays as const arrays

2016-03-14 Thread Claudiu Beznea 
This patch defines oui_rfc1042[] and oui_8021h[] arrays from
p80211conv.c as const arrays since these are not changed
anywhere in code.

Signed-off-by: Claudiu Beznea 
---
 drivers/staging/wlan-ng/p80211conv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/wlan-ng/p80211conv.c 
b/drivers/staging/wlan-ng/p80211conv.c
index 0a8f396..bdb50a5 100644
--- a/drivers/staging/wlan-ng/p80211conv.c
+++ b/drivers/staging/wlan-ng/p80211conv.c
@@ -75,8 +75,8 @@
 #include "p80211ioctl.h"
 #include "p80211req.h"
 
-static u8 oui_rfc1042[] = { 0x00, 0x00, 0x00 };
-static u8 oui_8021h[] = { 0x00, 0x00, 0xf8 };
+static const u8 oui_rfc1042[] = { 0x00, 0x00, 0x00 };
+static const u8 oui_8021h[] = { 0x00, 0x00, 0xf8 };
 
 /*
 * p80211pb_ether_to_80211
-- 
1.9.1

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

[PATCH] Staging: vt6655: defined byVT3253InitTab_RFMD[] and byVT3253B0_RFMD[] as const arrays.

2016-03-14 Thread Claudiu Beznea 
This patch changes byVT3253InitTab_RFMD[] and byVT3253B0_RFMD[]
arrays in const arrays since these are not changed anywhere in the
code.

Signed-off-by: Claudiu Beznea 
---
 drivers/staging/vt6655/baseband.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/vt6655/baseband.c 
b/drivers/staging/vt6655/baseband.c
index 1e6c0c4..94a7e64 100644
--- a/drivers/staging/vt6655/baseband.c
+++ b/drivers/staging/vt6655/baseband.c
@@ -66,7 +66,7 @@
 /*-  Static Variables  --*/
 
 #define CB_VT3253_INIT_FOR_RFMD 446
-static unsigned char byVT3253InitTab_RFMD[CB_VT3253_INIT_FOR_RFMD][2] = {
+static const unsigned char byVT3253InitTab_RFMD[CB_VT3253_INIT_FOR_RFMD][2] = {
{0x00, 0x30},
{0x01, 0x00},
{0x02, 0x00},
@@ -516,7 +516,7 @@ static unsigned char 
byVT3253InitTab_RFMD[CB_VT3253_INIT_FOR_RFMD][2] = {
 };
 
 #define CB_VT3253B0_INIT_FOR_RFMD 256
-static unsigned char byVT3253B0_RFMD[CB_VT3253B0_INIT_FOR_RFMD][2] = {
+static const unsigned char byVT3253B0_RFMD[CB_VT3253B0_INIT_FOR_RFMD][2] = {
{0x00, 0x31},
{0x01, 0x00},
{0x02, 0x00},
-- 
1.9.1

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

[PATCH 4.4 35/50] x86/mm: Fix slow_virt_to_phys() for X86_PAE again

2016-03-14 Thread Greg Kroah-Hartman 
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Dexuan Cui 

commit bf70e5513dfea29c3682e7eb3dbb45f0723bac09 upstream.

"d1cd12108346: x86, pageattr: Prevent overflow in slow_virt_to_phys() for
X86_PAE" was unintentionally removed by the recent "34437e67a672: x86/mm: Fix
slow_virt_to_phys() to handle large PAT bit".

And, the variable 'phys_addr' was defined as "unsigned long" by mistake -- it 
should
be "phys_addr_t".

As a result, Hyper-V network driver in 32-PAE Linux guest can't work again.

Fixes: commit 34437e67a672: "x86/mm: Fix slow_virt_to_phys() to handle large 
PAT bit"
Signed-off-by: Dexuan Cui 
Reviewed-by: Toshi Kani 
Cc: o...@aepfle.de
Cc: jasow...@redhat.com
Cc: driverdev-devel@linuxdriverproject.org
Cc: linux...@kvack.org
Cc: a...@canonical.com
Cc: Andrew Morton 
Cc: K. Y. Srinivasan 
Cc: Haiyang Zhang 
Link: 
http://lkml.kernel.org/r/1456394292-9030-1-git-send-email-de...@microsoft.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/mm/pageattr.c |   14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -414,24 +414,30 @@ pmd_t *lookup_pmd_address(unsigned long
 phys_addr_t slow_virt_to_phys(void *__virt_addr)
 {
unsigned long virt_addr = (unsigned long)__virt_addr;
-   unsigned long phys_addr, offset;
+   phys_addr_t phys_addr;
+   unsigned long offset;
enum pg_level level;
pte_t *pte;
 
pte = lookup_address(virt_addr, );
BUG_ON(!pte);
 
+   /*
+* pXX_pfn() returns unsigned long, which must be cast to phys_addr_t
+* before being left-shifted PAGE_SHIFT bits -- this trick is to
+* make 32-PAE kernel work correctly.
+*/
switch (level) {
case PG_LEVEL_1G:
-   phys_addr = pud_pfn(*(pud_t *)pte) << PAGE_SHIFT;
+   phys_addr = (phys_addr_t)pud_pfn(*(pud_t *)pte) << PAGE_SHIFT;
offset = virt_addr & ~PUD_PAGE_MASK;
break;
case PG_LEVEL_2M:
-   phys_addr = pmd_pfn(*(pmd_t *)pte) << PAGE_SHIFT;
+   phys_addr = (phys_addr_t)pmd_pfn(*(pmd_t *)pte) << PAGE_SHIFT;
offset = virt_addr & ~PMD_PAGE_MASK;
break;
default:
-   phys_addr = pte_pfn(*pte) << PAGE_SHIFT;
+   phys_addr = (phys_addr_t)pte_pfn(*pte) << PAGE_SHIFT;
offset = virt_addr & ~PAGE_MASK;
}
 


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

[PATCH] Staging: rtl8192u: remove extra blank lines.

2016-03-14 Thread Ben Marsh 
This patch removes blank lines in r8192U_wx.c that were flagged by
checkpatch.pl

Signed-off-by: Ben Marsh 
---
 drivers/staging/rtl8192u/r8192U_wx.c | 22 --
 1 file changed, 22 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_wx.c 
b/drivers/staging/rtl8192u/r8192U_wx.c
index f828e64..837704d 100644
--- a/drivers/staging/rtl8192u/r8192U_wx.c
+++ b/drivers/staging/rtl8192u/r8192U_wx.c
@@ -30,7 +30,6 @@
 static const u32 rtl8180_rates[] = {100, 200, 550, 1100,
600, 900, 1200, 1800, 2400, 3600, 4800, 
5400};
 
-
 #ifndef ENETDOWN
 #define ENETDOWN 1
 #endif
@@ -44,7 +43,6 @@ static int r8192_wx_get_freq(struct net_device *dev,
return ieee80211_wx_get_freq(priv->ieee80211, a, wrqu, b);
 }
 
-
 static int r8192_wx_get_mode(struct net_device *dev, struct iw_request_info *a,
 union iwreq_data *wrqu, char *b)
 {
@@ -53,8 +51,6 @@ static int r8192_wx_get_mode(struct net_device *dev, struct 
iw_request_info *a,
return ieee80211_wx_get_mode(priv->ieee80211, a, wrqu, b);
 }
 
-
-
 static int r8192_wx_get_rate(struct net_device *dev,
 struct iw_request_info *info,
 union iwreq_data *wrqu, char *extra)
@@ -64,8 +60,6 @@ static int r8192_wx_get_rate(struct net_device *dev,
return ieee80211_wx_get_rate(priv->ieee80211, info, wrqu, extra);
 }
 
-
-
 static int r8192_wx_set_rate(struct net_device *dev,
 struct iw_request_info *info,
 union iwreq_data *wrqu, char *extra)
@@ -82,7 +76,6 @@ static int r8192_wx_set_rate(struct net_device *dev,
return ret;
 }
 
-
 static int r8192_wx_set_rts(struct net_device *dev,
 struct iw_request_info *info,
 union iwreq_data *wrqu, char *extra)
@@ -148,7 +141,6 @@ static int r8192_wx_force_reset(struct net_device *dev,
 
 }
 
-
 static int r8192_wx_set_rawtx(struct net_device *dev,
   struct iw_request_info *info,
   union iwreq_data *wrqu, char *extra)
@@ -301,7 +293,6 @@ static int rtl8180_wx_get_range(struct net_device *dev,
/* range->min_r_time; *//* Minimal retry lifetime */
/* range->max_r_time; *//* Maximal retry lifetime */
 
-
for (i = 0, val = 0; i < 14; i++) {
 
/* Include only legal frequencies for some countries */
@@ -326,7 +317,6 @@ static int rtl8180_wx_get_range(struct net_device *dev,
return 0;
 }
 
-
 static int r8192_wx_set_scan(struct net_device *dev, struct iw_request_info *a,
 union iwreq_data *wrqu, char *b)
 {
@@ -396,9 +386,6 @@ static int r8192_wx_set_essid(struct net_device *dev,
return ret;
 }
 
-
-
-
 static int r8192_wx_get_essid(struct net_device *dev,
  struct iw_request_info *a,
  union iwreq_data *wrqu, char *b)
@@ -415,7 +402,6 @@ static int r8192_wx_get_essid(struct net_device *dev,
return ret;
 }
 
-
 static int r8192_wx_set_freq(struct net_device *dev, struct iw_request_info *a,
 union iwreq_data *wrqu, char *b)
 {
@@ -439,7 +425,6 @@ static int r8192_wx_get_name(struct net_device *dev,
return ieee80211_wx_get_name(priv->ieee80211, info, wrqu, extra);
 }
 
-
 static int r8192_wx_set_frag(struct net_device *dev,
 struct iw_request_info *info,
 union iwreq_data *wrqu, char *extra)
@@ -493,7 +478,6 @@ static int r8192_wx_set_wap(struct net_device *dev,
 
 }
 
-
 static int r8192_wx_get_wap(struct net_device *dev,
struct iw_request_info *info,
union iwreq_data *wrqu, char *extra)
@@ -503,7 +487,6 @@ static int r8192_wx_get_wap(struct net_device *dev,
return ieee80211_wx_get_wap(priv->ieee80211, info, wrqu, extra);
 }
 
-
 static int r8192_wx_get_enc(struct net_device *dev,
struct iw_request_info *info,
union iwreq_data *wrqu, char *key)
@@ -695,7 +678,6 @@ static int r8192_wx_get_retry(struct net_device *dev,
wrqu->retry.value = priv->retry_data;
}
 
-
return 0;
 }
 
@@ -711,7 +693,6 @@ static int r8192_wx_get_sens(struct net_device *dev,
return 0;
 }
 
-
 static int r8192_wx_set_sens(struct net_device *dev,
struct iw_request_info *info,
union iwreq_data *wrqu, char *extra)
@@ -862,7 +843,6 @@ static int dummy(struct net_device *dev, struct 
iw_request_info *a,
return -1;
 }
 
-
 static iw_handler r8192_wx_handlers[] = {
NULL, /* SIOCSIWCOMMIT */
r8192_wx_get_name,/* SIOCGIWNAME */
@@ -949,7 +929,6 @@ static const struct iw_priv_args

[PATCH 2/2] staging: fsl-mc: fix incorrect type passed to dev_err macros

2016-03-14 Thread Cihangir Akturk 
dev_err macros expect const struct device ** as its second
argument, but here the argument we are passing is of typ
struct device **. This patch fixes this error.

Signed-off-by: Cihangir Akturk 
---
 drivers/staging/fsl-mc/bus/mc-bus.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/fsl-mc/bus/mc-bus.c 
b/drivers/staging/fsl-mc/bus/mc-bus.c
index 9f77c37b..b594556 100644
--- a/drivers/staging/fsl-mc/bus/mc-bus.c
+++ b/drivers/staging/fsl-mc/bus/mc-bus.c
@@ -260,14 +260,14 @@ static int get_dprc_icid(struct fsl_mc_io *mc_io,
 
error = dprc_open(mc_io, 0, container_id, _handle);
if (error < 0) {
-   dev_err(_io->dev, "dprc_open() failed: %d\n", error);
+   dev_err(mc_io->dev, "dprc_open() failed: %d\n", error);
return error;
}
 
memset(, 0, sizeof(attr));
error = dprc_get_attributes(mc_io, 0, dprc_handle, );
if (error < 0) {
-   dev_err(_io->dev, "dprc_get_attributes() failed: %d\n",
+   dev_err(mc_io->dev, "dprc_get_attributes() failed: %d\n",
error);
goto common_cleanup;
}
-- 
2.1.4

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

[PATCH 1/2] staging: fsl-mc: fix incorrect type passed to dev_dbg macros

2016-03-14 Thread Cihangir Akturk 
dev_dbg macros expect const struct device ** as its second
argument but here the argument we are passing is of type
struct device ** this patch fixes this error.

Signed-off-by: Cihangir Akturk 
---
 drivers/staging/fsl-mc/bus/mc-sys.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/fsl-mc/bus/mc-sys.c 
b/drivers/staging/fsl-mc/bus/mc-sys.c
index 8101c46..810a611 100644
--- a/drivers/staging/fsl-mc/bus/mc-sys.c
+++ b/drivers/staging/fsl-mc/bus/mc-sys.c
@@ -328,7 +328,7 @@ static int mc_polling_wait_preemptible(struct fsl_mc_io 
*mc_io,
 MC_CMD_COMPLETION_POLLING_MAX_SLEEP_USECS);
 
if (time_after_eq(jiffies, jiffies_until_timeout)) {
-   dev_dbg(_io->dev,
+   dev_dbg(mc_io->dev,
"MC command timed out (portal: %#llx, obj 
handle: %#x, command: %#x)\n",
 mc_io->portal_phys_addr,
 (unsigned int)
@@ -370,7 +370,7 @@ static int mc_polling_wait_atomic(struct fsl_mc_io *mc_io,
udelay(MC_CMD_COMPLETION_POLLING_MAX_SLEEP_USECS);
timeout_usecs -= MC_CMD_COMPLETION_POLLING_MAX_SLEEP_USECS;
if (timeout_usecs == 0) {
-   dev_dbg(_io->dev,
+   dev_dbg(mc_io->dev,
"MC command timed out (portal: %#llx, obj 
handle: %#x, command: %#x)\n",
 mc_io->portal_phys_addr,
 (unsigned int)
@@ -426,7 +426,7 @@ int mc_send_command(struct fsl_mc_io *mc_io, struct 
mc_command *cmd)
goto common_exit;
 
if (status != MC_CMD_STATUS_OK) {
-   dev_dbg(_io->dev,
+   dev_dbg(mc_io->dev,
"MC command failed: portal: %#llx, obj handle: %#x, 
command: %#x, status: %s (%#x)\n",
 mc_io->portal_phys_addr,
 (unsigned int)MC_CMD_HDR_READ_TOKEN(cmd->header),
-- 
2.1.4

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

[PATCH 0/2] fix incorrect type passed to dev_* macros

2016-03-14 Thread Cihangir Akturk 
Following patches fixes the incorrect pointer type passed to
dev_* macros.

Cihangir Akturk (2):
  staging: fsl-mc: fix incorrect type passed to dev_dbg macros
  staging: fsl-mc: fix incorrect type passed to dev_err macros

 drivers/staging/fsl-mc/bus/mc-bus.c | 4 ++--
 drivers/staging/fsl-mc/bus/mc-sys.c | 6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

-- 
2.1.4

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

Re: [PATCH 1/5] Staging: comedi: Fix type issues in s626.c

2016-03-14 Thread Ian Abbott 

On 14/03/16 11:06, Ravishankar Karkala Mallikarjunayya wrote:

This is a patch to the s626.c file that fixes up a type issues
found by the checkpatch.pl tool.

i.e Prefer kernel type 'u8' over 'uint8_t'
 Prefer kernel type 'u16' over 'uint16_t'
 Prefer kernel type 'u32' over 'uint32_t'
 Prefer kernel type 's16' over 'int16_t'
 Prefer kernel type 's32' over 'int32_t'

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
  drivers/staging/comedi/drivers/s626.c | 312 +-
  1 file changed, 156 insertions(+), 156 deletions(-)


The patch would be okay, but it doesn't apply to the "staging-next" 
branch of Greg's staging.git on git.kernel.org.  (It doesn't apply to 
the "master" branch of linux-next.git either.)


--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: refresh TODO for rtl8712

2016-03-14 Thread Xose Vazquez Perez 
People should not waste time and energy working on this staging driver.
At least four drivers were written for this hardware:
 https://marc.info/?l=linux-wireless=138358275410975
And there is a replacement using the kernel wireless stack at:
 https://github.com/chunkeey/rtl8192su
Also a fullmac/cfg80211 driver(r92su) is available.

Cc: Larry Finger 
Cc: Florian Schilhabel 
Cc: Christian Lamparter 
Cc: Joshua Roys 
Cc: Greg Kroah-Hartman 
Cc: Linux Driver Project Developer List 
Cc: Linux Wireless 
Signed-off-by: Xose Vazquez Perez 
---
 drivers/staging/rtl8712/TODO | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/rtl8712/TODO b/drivers/staging/rtl8712/TODO
index d8dfe5b..847c8c4 100644
--- a/drivers/staging/rtl8712/TODO
+++ b/drivers/staging/rtl8712/TODO
@@ -4,10 +4,10 @@ TODO:
 - switch to use MAC80211
 - checkpatch.pl fixes - only a few remain
 
-Please send any patches to Greg Kroah-Hartman ,
-Larry Finger  and
-Florian Schilhabel .
-
-
-
+A replacement for this driver with MAC80211 support is available
+at https://github.com/chunkeey/rtl8192su
 
+Please send any patches to Greg Kroah-Hartman ,
+Larry Finger ,
+Florian Schilhabel  and
+Linux Driver Project Developer List .
-- 
2.5.0

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

Re: [PATCH 5/5] Staging: comedi: Fix type issue in ni_tio.c

2016-03-14 Thread Joe Perches 
On Mon, 2016-03-14 at 16:36 +0530, Ravishankar Karkala Mallikarjunayya wrote:
> This is a patch to the ni_tio.c file that fixes up a type issues
> found by the checkpatch.pl tool.
> i.e. Prefer kernel type 'u64' over 'uint64_t'
[]
> diff --git a/drivers/staging/comedi/drivers/ni_tio.c 
> b/drivers/staging/comedi/drivers/ni_tio.c
[]
> @@ -189,7 +189,7 @@ static void ni_tio_reset_count_and_disarm(struct ni_gpct 
> *counter)
>  static uint64_t ni_tio_clock_period_ps(const struct ni_gpct *counter,
>      unsigned generic_clock_source)
>  {
> - uint64_t clock_period_ps;
> + u64 clock_period_ps;

Please don't blinkeredly fix checkpatch messages.
Understand the code, not just the checkpatch output.

This function returns a uint64_t, maybe it should be
converted to u64 as well.


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

Re: [PATCH] media: add GFP flag to media_*() that could get called in atomic context

2016-03-14 Thread Sakari Ailus 
Hi Mauro,

On Mon, Mar 14, 2016 at 08:46:33AM -0300, Mauro Carvalho Chehab wrote:
> Em Mon, 14 Mar 2016 12:52:54 +0200
> Sakari Ailus  escreveu:
> 
> > Hi Mauro,
> > 
> > On Mon, Mar 14, 2016 at 07:13:58AM -0300, Mauro Carvalho Chehab wrote:
> > > Em Mon, 14 Mar 2016 09:22:37 +0200
> > > Sakari Ailus  escreveu:
> > >   
> > > > Hi Shuah,
> > > > 
> > > > On Sat, Mar 12, 2016 at 06:48:09PM -0700, Shuah Khan wrote:  
> > > > > Add GFP flags to media_create_pad_link(), media_create_intf_link(),
> > > > > media_devnode_create(), and media_add_link() that could get called
> > > > > in atomic context to allow callers to pass in the right flags for
> > > > > memory allocation.
> > > > > 
> > > > > tree-wide driver changes for media_*() GFP flags change:
> > > > > Change drivers to add gfpflags to interffaces, 
> > > > > media_create_pad_link(),
> > > > > media_create_intf_link() and media_devnode_create().
> > > > > 
> > > > > Signed-off-by: Shuah Khan 
> > > > > Suggested-by: Mauro Carvalho Chehab 
> > > > 
> > > > What's the use case for calling the above functions in an atomic 
> > > > context?
> > > >   
> > > 
> > > ALSA code seems to do a lot of stuff at atomic context. That's what
> > > happens on my test machine when au0828 gets probed before
> > > snd-usb-audio:
> > >   http://pastebin.com/LEX5LD5K
> > > 
> > > It seems that ALSA USB probe routine (usb_audio_probe) happens in
> > > atomic context.  
> > 
> > usb_audio_probe() grabs a mutex (register_mutex) on its own. It certainly
> > cannot be called in atomic context.
> > 
> > In the above log, what I did notice, though, was that because *we* grab
> > mdev->lock spinlock in media_device_register_entity(), we may not sleep
> > which is what the notify() callback implementation in au0828 driver does
> > (for memory allocation).
> 
> True. After looking into the code, the problem is that the notify
> callbacks are called with the spinlock hold. I don't see any reason
> to do that.

Notify callbacks, perhaps not, but the list is still protected by the
spinlock. It perhaps is not likely that another process would change it but
I don't think we can rely on that.

> 
> > Could we instead replace mdev->lock by a mutex?
> 
> We changed the code to use a spinlock for a reason: this fixed some
> troubles in the past with the code locking (can't remember the problem,
> but this was documented at the kernel logs and at the ML). Yet, the code
> under the spinlock never sleeps, so this is fine.

struct media_device.lock was added by this patch:

commit 53e269c102fbaf77e7dc526b1606ad4a48e57200
Author: Laurent Pinchart 
Date:   Wed Dec 9 08:40:00 2009 -0300

[media] media: Entities, pads and links

As video hardware pipelines become increasingly complex and
configurable, the current hardware description through v4l2 subdevices
reaches its limits. In addition to enumerating and configuring
subdevices, video camera drivers need a way to discover and modify at
runtime how those subdevices are connected. This is done through new
elements called entities, pads and links.

...

Signed-off-by: Laurent Pinchart 
Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 

I think it was always a spinlock, for the reason you stated above as well:
it did not need to sleep. But if there is a need to sleep, I think we should
consider changing that.

> 
> Yet, in the future, we'll need to do a review of all the locking schema,
> in order to better support dynamic graph changes.

Agreed. I think more fine grained locking should be considered. The media
graph mutex will become a bottleneck at some point, especially if we make
the media devices system wide at some point.

> 
> > If there is no pressing need to implement atomic memory allocation I simply
> > wouldn't do it, especially in device initialisation where an allocation
> > failure will lead to probe failure as well.
> 
> The fix for this issue should be simple. See the enclosed code. Btw.
> it probably makes sense to add some code here to avoid starving the
> stack, as a notify callback could try to create an entity, with,
> in turn, would call the notify callback again.
> 
> I'll run some tests here to double check if it fixes the issue.
> 
> ---
> 
> [media] media-device: Don't call notify callbacks holding a spinlock
> 
> The notify routines may sleep. So, they can't be called in spinlock
> context. Also, they may want to call other media routines that might
> be spinning the spinlock, like creating a link.
> 
> This fixes the following bug:
> 
> [ 1839.510587] BUG: sleeping function called from invalid context at 
> mm/slub.c:1289
> [ 1839.510881] in_atomic(): 1, irqs_disabled(): 0, pid: 3479, name: modprobe
> [ 1839.511157]

Re: [PATCH] media: add GFP flag to media_*() that could get called in atomic context

2016-03-14 Thread Mauro Carvalho Chehab 
Em Mon, 14 Mar 2016 12:52:54 +0200
Sakari Ailus  escreveu:

> Hi Mauro,
> 
> On Mon, Mar 14, 2016 at 07:13:58AM -0300, Mauro Carvalho Chehab wrote:
> > Em Mon, 14 Mar 2016 09:22:37 +0200
> > Sakari Ailus  escreveu:
> >   
> > > Hi Shuah,
> > > 
> > > On Sat, Mar 12, 2016 at 06:48:09PM -0700, Shuah Khan wrote:  
> > > > Add GFP flags to media_create_pad_link(), media_create_intf_link(),
> > > > media_devnode_create(), and media_add_link() that could get called
> > > > in atomic context to allow callers to pass in the right flags for
> > > > memory allocation.
> > > > 
> > > > tree-wide driver changes for media_*() GFP flags change:
> > > > Change drivers to add gfpflags to interffaces, media_create_pad_link(),
> > > > media_create_intf_link() and media_devnode_create().
> > > > 
> > > > Signed-off-by: Shuah Khan 
> > > > Suggested-by: Mauro Carvalho Chehab 
> > > 
> > > What's the use case for calling the above functions in an atomic context?
> > >   
> > 
> > ALSA code seems to do a lot of stuff at atomic context. That's what
> > happens on my test machine when au0828 gets probed before
> > snd-usb-audio:
> > http://pastebin.com/LEX5LD5K
> > 
> > It seems that ALSA USB probe routine (usb_audio_probe) happens in
> > atomic context.  
> 
> usb_audio_probe() grabs a mutex (register_mutex) on its own. It certainly
> cannot be called in atomic context.
> 
> In the above log, what I did notice, though, was that because *we* grab
> mdev->lock spinlock in media_device_register_entity(), we may not sleep
> which is what the notify() callback implementation in au0828 driver does
> (for memory allocation).

True. After looking into the code, the problem is that the notify
callbacks are called with the spinlock hold. I don't see any reason
to do that.

> Could we instead replace mdev->lock by a mutex?

We changed the code to use a spinlock for a reason: this fixed some
troubles in the past with the code locking (can't remember the problem,
but this was documented at the kernel logs and at the ML). Yet, the code
under the spinlock never sleeps, so this is fine.

Yet, in the future, we'll need to do a review of all the locking schema,
in order to better support dynamic graph changes.

> If there is no pressing need to implement atomic memory allocation I simply
> wouldn't do it, especially in device initialisation where an allocation
> failure will lead to probe failure as well.

The fix for this issue should be simple. See the enclosed code. Btw.
it probably makes sense to add some code here to avoid starving the
stack, as a notify callback could try to create an entity, with,
in turn, would call the notify callback again.

I'll run some tests here to double check if it fixes the issue.

---

[media] media-device: Don't call notify callbacks holding a spinlock

The notify routines may sleep. So, they can't be called in spinlock
context. Also, they may want to call other media routines that might
be spinning the spinlock, like creating a link.

This fixes the following bug:

[ 1839.510587] BUG: sleeping function called from invalid context at 
mm/slub.c:1289
[ 1839.510881] in_atomic(): 1, irqs_disabled(): 0, pid: 3479, name: modprobe
[ 1839.511157] 4 locks held by modprobe/3479:
[ 1839.511415]  #0:  (>mutex){..}, at: [] 
__driver_attach+0xa3/0x160
[ 1839.512381]  #1:  (>mutex){..}, at: [] 
__driver_attach+0xb1/0x160
[ 1839.512388]  #2:  (register_mutex#5){+.+.+.}, at: [] 
usb_audio_probe+0x257/0x1c90 [snd_usb_audio]
[ 1839.512401]  #3:  (&(>lock)->rlock){+.+.+.}, at: [] 
media_device_register_entity+0x1cb/0x700 [media]
[ 1839.512412] CPU: 2 PID: 3479 Comm: modprobe Not tainted 4.5.0-rc3+ #49
[ 1839.512415] Hardware name:  /NUC5i7RYB, BIOS 
RYBDWi35.86A.0350.2015.0812.1722 08/12/2015
[ 1839.512417]   8803b3f6f288 81933901 
8803c4bae000
[ 1839.512422]  8803c4bae5c8 8803b3f6f2b0 811c6af5 
8803c4bae000
[ 1839.512427]  8285d7f6 0509 8803b3f6f2f0 
811c6ce5
[ 1839.512432] Call Trace:
[ 1839.512436]  [] dump_stack+0x85/0xc4
[ 1839.512440]  [] ___might_sleep+0x245/0x3a0
[ 1839.512443]  [] __might_sleep+0x95/0x1a0
[ 1839.512446]  [] kmem_cache_alloc_trace+0x20e/0x300
[ 1839.512451]  [] ? media_add_link+0x4d/0x140 [media]
[ 1839.512455]  [] media_add_link+0x4d/0x140 [media]
[ 1839.512459]  [] media_create_pad_link+0xa1/0x600 [media]
[ 1839.512463]  [] au0828_media_graph_notify+0x173/0x360 
[au0828]
[ 1839.512467]  [] ? media_gobj_create+0x1ba/0x480 [media]
[ 1839.512471]  [] media_device_register_entity+0x3ab/0x700 
[media]

(untested)

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 6ba6e8f982fc..fc3c199e5500 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -587,14 +587,15 @@ int __must_check

[PATCH 1/5] Staging: comedi: Fix type issues in s626.c

2016-03-14 Thread Ravishankar Karkala Mallikarjunayya 
This is a patch to the s626.c file that fixes up a type issues
found by the checkpatch.pl tool.

i.e Prefer kernel type 'u8' over 'uint8_t'
Prefer kernel type 'u16' over 'uint16_t'
Prefer kernel type 'u32' over 'uint32_t'
Prefer kernel type 's16' over 'int16_t'
Prefer kernel type 's32' over 'int32_t'

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
 drivers/staging/comedi/drivers/s626.c | 312 +-
 1 file changed, 156 insertions(+), 156 deletions(-)

diff --git a/drivers/staging/comedi/drivers/s626.c 
b/drivers/staging/comedi/drivers/s626.c
index 35f0f67..5c20440 100644
--- a/drivers/staging/comedi/drivers/s626.c
+++ b/drivers/staging/comedi/drivers/s626.c
@@ -75,24 +75,24 @@ struct s626_buffer_dma {
 };
 
 struct s626_private {
-   uint8_t ai_cmd_running; /* ai_cmd is running */
+   u8 ai_cmd_running;  /* ai_cmd is running */
unsigned int ai_sample_timer;   /* time between samples in
 * units of the timer */
int ai_convert_count;   /* conversion counter */
unsigned int ai_convert_timer;  /* time between conversion in
 * units of the timer */
-   uint16_t counter_int_enabs; /* counter interrupt enable mask
+   u16 counter_int_enabs;  /* counter interrupt enable mask
 * for MISC2 register */
-   uint8_t adc_items;  /* number of items in ADC poll list */
+   u8 adc_items;   /* number of items in ADC poll list */
struct s626_buffer_dma rps_buf; /* DMA buffer used to hold ADC (RPS1)
 * program */
struct s626_buffer_dma ana_buf; /* DMA buffer used to receive ADC data
 * and hold DAC data */
-   uint32_t *dac_wbuf; /* pointer to logical adrs of DMA buffer
+   u32 *dac_wbuf;  /* pointer to logical adrs of DMA buffer
 * used to hold DAC data */
-   uint16_t dacpol;/* image of DAC polarity register */
-   uint8_t trim_setpoint[12];  /* images of TrimDAC setpoints */
-   uint32_t i2c_adrs;  /* I2C device address for onboard EEPROM
+   u16 dacpol; /* image of DAC polarity register */
+   u8 trim_setpoint[12];   /* images of TrimDAC setpoints */
+   u32 i2c_adrs;   /* I2C device address for onboard EEPROM
 * (board rev dependent) */
 };
 
@@ -179,7 +179,7 @@ static void s626_debi_transfer(struct comedi_device *dev)
 /*
  * Read a value from a gate array register.
  */
-static uint16_t s626_debi_read(struct comedi_device *dev, uint16_t addr)
+static u16 s626_debi_read(struct comedi_device *dev, u16 addr)
 {
/* Set up DEBI control register value in shadow RAM */
writel(S626_DEBI_CMD_RDWORD | addr, dev->mmio + S626_P_DEBICMD);
@@ -193,8 +193,8 @@ static uint16_t s626_debi_read(struct comedi_device *dev, 
uint16_t addr)
 /*
  * Write a value to a gate array register.
  */
-static void s626_debi_write(struct comedi_device *dev, uint16_t addr,
-   uint16_t wdata)
+static void s626_debi_write(struct comedi_device *dev,
+   u16 addr, u16 wdata)
 {
/* Set up DEBI control register value in shadow RAM */
writel(S626_DEBI_CMD_WRWORD | addr, dev->mmio + S626_P_DEBICMD);
@@ -241,7 +241,7 @@ static int s626_i2c_handshake_eoc(struct comedi_device *dev,
return -EBUSY;
 }
 
-static int s626_i2c_handshake(struct comedi_device *dev, uint32_t val)
+static int s626_i2c_handshake(struct comedi_device *dev, u32 val)
 {
unsigned int ctrl;
int ret;
@@ -267,8 +267,8 @@ static int s626_i2c_handshake(struct comedi_device *dev, 
uint32_t val)
return ctrl & S626_I2C_ERR;
 }
 
-/* Read uint8_t from EEPROM. */
-static uint8_t s626_i2c_read(struct comedi_device *dev, uint8_t addr)
+/* Read u8 from EEPROM. */
+static u8 s626_i2c_read(struct comedi_device *dev, u8 addr)
 {
struct s626_private *devpriv = dev->private;
 
@@ -288,7 +288,7 @@ static uint8_t s626_i2c_read(struct comedi_device *dev, 
uint8_t addr)
/*
 * Execute EEPROM read:
 *  Byte2 = I2C command: read from I2C EEPROM device.
-*  Byte1 receives uint8_t from EEPROM.
+*  Byte1 receives u8 from EEPROM.
 *  Byte0 = Not sent.
 */
if (s626_i2c_handshake(dev, S626_I2C_B2(S626_I2C_ATTRSTART,
@@ -304,10 +304,10 @@ static uint8_t s626_i2c_read(struct comedi_device *dev, 
uint8_t addr)
 /* ***  DAC FUNCTIONS *** */
 
 /* TrimDac LogicalChan-to-PhysicalChan mapping table. */
-static const uint8_t s626_trimchan[] = { 10, 9, 8, 3, 2, 7, 6, 1, 0, 5, 4 };
+static const u8 s626_trimchan[] = { 10, 9, 8, 3, 2, 7, 6, 1, 0, 5, 4 };
 
 /* TrimDac

[PATCH 5/5] Staging: comedi: Fix type issue in ni_tio.c

2016-03-14 Thread Ravishankar Karkala Mallikarjunayya 
This is a patch to the ni_tio.c file that fixes up a type issues
found by the checkpatch.pl tool.
i.e. Prefer kernel type 'u64' over 'uint64_t'

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
 drivers/staging/comedi/drivers/ni_tio.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/comedi/drivers/ni_tio.c 
b/drivers/staging/comedi/drivers/ni_tio.c
index f006805..0ee6d6c 100644
--- a/drivers/staging/comedi/drivers/ni_tio.c
+++ b/drivers/staging/comedi/drivers/ni_tio.c
@@ -189,7 +189,7 @@ static void ni_tio_reset_count_and_disarm(struct ni_gpct 
*counter)
 static uint64_t ni_tio_clock_period_ps(const struct ni_gpct *counter,
   unsigned generic_clock_source)
 {
-   uint64_t clock_period_ps;
+   u64 clock_period_ps;
 
switch (generic_clock_source & NI_GPCT_CLOCK_SRC_SELECT_MASK) {
case NI_GPCT_TIMEBASE_1_CLOCK_SRC_BITS:
@@ -385,9 +385,9 @@ static void ni_tio_set_sync_mode(struct ni_gpct *counter, 
int force_alt_sync)
struct ni_gpct_device *counter_dev = counter->counter_dev;
unsigned cidx = counter->counter_index;
const unsigned counting_mode_reg = NITIO_CNT_MODE_REG(cidx);
-   static const uint64_t min_normal_sync_period_ps = 25000;
+   static const u64 min_normal_sync_period_ps = 25000;
unsigned mode;
-   uint64_t clock_period_ps;
+   u64 clock_period_ps;
 
if (ni_tio_counting_mode_registers_present(counter_dev) == 0)
return;
@@ -730,7 +730,7 @@ static void ni_tio_get_clock_src(struct ni_gpct *counter,
 unsigned int *clock_source,
 unsigned int *period_ns)
 {
-   uint64_t temp64;
+   u64 temp64;
 
*clock_source = ni_tio_generic_clock_src_select(counter);
temp64 = ni_tio_clock_period_ps(counter, *clock_source);
-- 
1.9.1

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

[PATCH 4/5] Staging: comedi: fix CHECK issue in ni_tio.c

2016-03-14 Thread Ravishankar Karkala Mallikarjunayya 
This is a patch to the ni_tio.c file that fixes up a CHECK issues
found by the checkpatch.pl tool.

i.e. Avoid crashing the kernel - try using WARN_ON & recovery code
rather than BUG() or BUG_ON().

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
 drivers/staging/comedi/drivers/ni_tio.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/comedi/drivers/ni_tio.c 
b/drivers/staging/comedi/drivers/ni_tio.c
index b74e44e..f006805 100644
--- a/drivers/staging/comedi/drivers/ni_tio.c
+++ b/drivers/staging/comedi/drivers/ni_tio.c
@@ -222,7 +222,7 @@ static uint64_t ni_tio_clock_period_ps(const struct ni_gpct 
*counter,
clock_period_ps *= 8;
break;
default:
-   BUG();
+   WARN_ON(1);
break;
}
return clock_period_ps;
@@ -304,7 +304,7 @@ static unsigned ni_m_series_clock_src_select(const struct 
ni_gpct *counter)
}
if (i <= NI_M_MAX_PFI_CHAN)
break;
-   BUG();
+   WARN_ON(1);
break;
}
clock_source |= ni_tio_clock_src_modifiers(counter);
@@ -361,7 +361,7 @@ static unsigned ni_660x_clock_src_select(const struct 
ni_gpct *counter)
}
if (i <= NI_660X_MAX_SRC_PIN)
break;
-   BUG();
+   WARN_ON(1);
break;
}
clock_source |= ni_tio_clock_src_modifiers(counter);
@@ -584,7 +584,7 @@ static unsigned ni_660x_clk_src(unsigned int clock_source)
if (i <= NI_660X_MAX_SRC_PIN)
break;
ni_660x_clock = 0;
-   BUG();
+   WARN_ON(1);
break;
}
return GI_SRC_SEL(ni_660x_clock);
@@ -643,7 +643,7 @@ static unsigned ni_m_clk_src(unsigned int clock_source)
break;
pr_err("invalid clock source 0x%lx\n",
   (unsigned long)clock_source);
-   BUG();
+   WARN_ON(1);
ni_m_series_clock = 0;
break;
}
@@ -946,7 +946,7 @@ int ni_tio_set_gate_src(struct ni_gpct *counter, unsigned 
gate_index,
case ni_gpct_variant_660x:
return ni_660x_set_gate2(counter, gate_source);
default:
-   BUG();
+   WARN_ON(1);
break;
}
break;
@@ -1015,7 +1015,7 @@ static unsigned ni_660x_gate_to_generic_gate(unsigned 
gate)
if (gate == NI_660X_PIN_GATE_SEL(i))
return NI_GPCT_GATE_PIN_GATE_SELECT(i);
}
-   BUG();
+   WARN_ON(1);
break;
}
return 0;
@@ -1051,7 +1051,7 @@ static unsigned ni_m_gate_to_generic_gate(unsigned gate)
if (gate == NI_M_PFI_GATE_SEL(i))
return NI_GPCT_PFI_GATE_SELECT(i);
}
-   BUG();
+   WARN_ON(1);
break;
}
return 0;
@@ -1083,7 +1083,7 @@ static unsigned ni_660x_gate2_to_generic_gate(unsigned 
gate)
if (gate == NI_660X_UD_PIN_GATE2_SEL(i))
return NI_GPCT_UP_DOWN_PIN_GATE_SELECT(i);
}
-   BUG();
+   WARN_ON(1);
break;
}
return 0;
-- 
1.9.1

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

[PATCH 2/5] Staging: comedi: Fix Block comment issues in s626.c

2016-03-14 Thread Ravishankar Karkala Mallikarjunayya 
This is a patch to the s626.c file that fixes up a  Block comments issues
found by the checkpatch.pl tool.

i.e. Block comments use a trailing */ on a separate line

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
 drivers/staging/comedi/drivers/s626.c | 42 ++-
 1 file changed, 26 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/comedi/drivers/s626.c 
b/drivers/staging/comedi/drivers/s626.c
index 5c20440..d0b5a0d 100644
--- a/drivers/staging/comedi/drivers/s626.c
+++ b/drivers/staging/comedi/drivers/s626.c
@@ -77,23 +77,30 @@ struct s626_buffer_dma {
 struct s626_private {
u8 ai_cmd_running;  /* ai_cmd is running */
unsigned int ai_sample_timer;   /* time between samples in
-* units of the timer */
+* units of the timer
+*/
int ai_convert_count;   /* conversion counter */
unsigned int ai_convert_timer;  /* time between conversion in
-* units of the timer */
-   u16 counter_int_enabs;  /* counter interrupt enable mask
-* for MISC2 register */
-   u8 adc_items;   /* number of items in ADC poll list */
+* units of the timer
+*/
+   u16 counter_int_enabs;  /* counter interrupt enable mask
+* for MISC2 register
+*/
+   u8 adc_items;   /* number of items in ADC poll list */
struct s626_buffer_dma rps_buf; /* DMA buffer used to hold ADC (RPS1)
-* program */
+* program
+*/
struct s626_buffer_dma ana_buf; /* DMA buffer used to receive ADC data
-* and hold DAC data */
-   u32 *dac_wbuf;  /* pointer to logical adrs of DMA buffer
-* used to hold DAC data */
-   u16 dacpol; /* image of DAC polarity register */
-   u8 trim_setpoint[12];   /* images of TrimDAC setpoints */
-   u32 i2c_adrs;   /* I2C device address for onboard EEPROM
-* (board rev dependent) */
+* and hold DAC data
+*/
+   u32 *dac_wbuf;  /* pointer to logical adrs of DMA buffer
+* used to hold DAC data
+*/
+   u16 dacpol; /* image of DAC polarity register */
+   u8 trim_setpoint[12];   /* images of TrimDAC setpoints */
+   u32 i2c_adrs;   /* I2C device address for onboard EEPROM
+* (board rev dependent)
+*/
 };
 
 /* Counter overflow/index event flag masks for RDMISC2. */
@@ -572,11 +579,14 @@ static int s626_set_dac(struct comedi_device *dev,
 * running after the packet has been sent to the target DAC.
 */
val = 0x0F00;   /* Continue clock after target DAC data
-* (write to non-existent trimdac). */
+* (write to non-existent trimdac).
+*/
val |= 0x4000;  /* Address the two main dual-DAC devices
-* (TSL's chip select enables target device). */
+* (TSL's chip select enables target device).
+*/
val |= ((u32)(chan & 1) << 15); /* Address the DAC channel
-* within the device. */
+* within the device.
+*/
val |= (u32)dacdata;/* Include DAC setpoint data. */
return s626_send_dac(dev, val);
 }
-- 
1.9.1

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

[PATCH 3/5] Staging: comedi: Fix WARNING issue in s626.c

2016-03-14 Thread Ravishankar Karkala Mallikarjunayya 
This is a patch to the s626.c file that fixes up a  line over
80 characters issues found by the checkpatch.pl tool.

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
 drivers/staging/comedi/drivers/s626.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/drivers/s626.c 
b/drivers/staging/comedi/drivers/s626.c
index d0b5a0d..3f9a186 100644
--- a/drivers/staging/comedi/drivers/s626.c
+++ b/drivers/staging/comedi/drivers/s626.c
@@ -2543,7 +2543,8 @@ static int s626_initialize(struct comedi_device *dev)
for (i = 0; i < 2; i++) {
writel(S626_I2C_CLKSEL, dev->mmio + S626_P_I2CSTAT);
s626_mc_enable(dev, S626_MC2_UPLD_IIC, S626_P_MC2);
-   ret = comedi_timeout(dev, NULL, NULL, s626_i2c_handshake_eoc, 
0);
+   ret = comedi_timeout(dev, NULL, NULL, s626_i2c_handshake_eoc,
+0);
if (ret)
return ret;
}
-- 
1.9.1

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

Re: [PATCH] media: add GFP flag to media_*() that could get called in atomic context

2016-03-14 Thread Sakari Ailus 
Hi Mauro,

On Mon, Mar 14, 2016 at 07:13:58AM -0300, Mauro Carvalho Chehab wrote:
> Em Mon, 14 Mar 2016 09:22:37 +0200
> Sakari Ailus  escreveu:
> 
> > Hi Shuah,
> > 
> > On Sat, Mar 12, 2016 at 06:48:09PM -0700, Shuah Khan wrote:
> > > Add GFP flags to media_create_pad_link(), media_create_intf_link(),
> > > media_devnode_create(), and media_add_link() that could get called
> > > in atomic context to allow callers to pass in the right flags for
> > > memory allocation.
> > > 
> > > tree-wide driver changes for media_*() GFP flags change:
> > > Change drivers to add gfpflags to interffaces, media_create_pad_link(),
> > > media_create_intf_link() and media_devnode_create().
> > > 
> > > Signed-off-by: Shuah Khan 
> > > Suggested-by: Mauro Carvalho Chehab   
> > 
> > What's the use case for calling the above functions in an atomic context?
> > 
> 
> ALSA code seems to do a lot of stuff at atomic context. That's what
> happens on my test machine when au0828 gets probed before
> snd-usb-audio:
>   http://pastebin.com/LEX5LD5K
> 
> It seems that ALSA USB probe routine (usb_audio_probe) happens in
> atomic context.

usb_audio_probe() grabs a mutex (register_mutex) on its own. It certainly
cannot be called in atomic context.

In the above log, what I did notice, though, was that because *we* grab
mdev->lock spinlock in media_device_register_entity(), we may not sleep
which is what the notify() callback implementation in au0828 driver does
(for memory allocation).

Could we instead replace mdev->lock by a mutex?

If there is no pressing need to implement atomic memory allocation I simply
wouldn't do it, especially in device initialisation where an allocation
failure will lead to probe failure as well.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] media: add GFP flag to media_*() that could get called in atomic context

2016-03-14 Thread Takashi Iwai 
On Mon, 14 Mar 2016 11:13:58 +0100,
Mauro Carvalho Chehab wrote:
> 
> Em Mon, 14 Mar 2016 09:22:37 +0200
> Sakari Ailus  escreveu:
> 
> > Hi Shuah,
> > 
> > On Sat, Mar 12, 2016 at 06:48:09PM -0700, Shuah Khan wrote:
> > > Add GFP flags to media_create_pad_link(), media_create_intf_link(),
> > > media_devnode_create(), and media_add_link() that could get called
> > > in atomic context to allow callers to pass in the right flags for
> > > memory allocation.
> > > 
> > > tree-wide driver changes for media_*() GFP flags change:
> > > Change drivers to add gfpflags to interffaces, media_create_pad_link(),
> > > media_create_intf_link() and media_devnode_create().
> > > 
> > > Signed-off-by: Shuah Khan 
> > > Suggested-by: Mauro Carvalho Chehab   
> > 
> > What's the use case for calling the above functions in an atomic context?
> > 
> 
> ALSA code seems to do a lot of stuff at atomic context. That's what
> happens on my test machine when au0828 gets probed before
> snd-usb-audio:
>   http://pastebin.com/LEX5LD5K
> 
> It seems that ALSA USB probe routine (usb_audio_probe) happens in
> atomic context.

No, usb_audio_probe() doesn't take a lock.  But
media_device_register_entity() seems taking a spinlock, instead.


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

Re: [PATCH] media: add GFP flag to media_*() that could get called in atomic context

2016-03-14 Thread Mauro Carvalho Chehab 
Em Mon, 14 Mar 2016 09:22:37 +0200
Sakari Ailus  escreveu:

> Hi Shuah,
> 
> On Sat, Mar 12, 2016 at 06:48:09PM -0700, Shuah Khan wrote:
> > Add GFP flags to media_create_pad_link(), media_create_intf_link(),
> > media_devnode_create(), and media_add_link() that could get called
> > in atomic context to allow callers to pass in the right flags for
> > memory allocation.
> > 
> > tree-wide driver changes for media_*() GFP flags change:
> > Change drivers to add gfpflags to interffaces, media_create_pad_link(),
> > media_create_intf_link() and media_devnode_create().
> > 
> > Signed-off-by: Shuah Khan 
> > Suggested-by: Mauro Carvalho Chehab   
> 
> What's the use case for calling the above functions in an atomic context?
> 

ALSA code seems to do a lot of stuff at atomic context. That's what
happens on my test machine when au0828 gets probed before
snd-usb-audio:
http://pastebin.com/LEX5LD5K

It seems that ALSA USB probe routine (usb_audio_probe) happens in
atomic context.

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

Re: [PATCH] Add tw5864 driver

2016-03-14 Thread Hans Verkuil 
Hi Andrey,

See below for a quick review of the code.

I agree with Greg's comment why this is added to staging instead of 
drivers/media/pci?

When you post the v2 patch, can you add the output of 'v4l2-compliance -s' to 
the
cover letter? Please use the latest v4l2-compliance version from the 
v4l-utils.git
repository when testing.

On 03/14/2016 02:59 AM, Andrey Utkin wrote:
> Support for boards based on Techwell TW5864 chip which provides
> multichannel video & audio grabbing and encoding (H.264, MJPEG,
> ADPCM G.726).
> 
> Signed-off-by: Andrey Utkin 
> Tested-by: Andrey Utkin 
> ---
>  MAINTAINERS  |7 +
>  drivers/staging/media/Kconfig|2 +
>  drivers/staging/media/Makefile   |1 +
>  drivers/staging/media/tw5864/Kconfig |   11 +
>  drivers/staging/media/tw5864/Makefile|3 +
>  drivers/staging/media/tw5864/tw5864-bs.h |  154 ++
>  drivers/staging/media/tw5864/tw5864-config.c |  359 +
>  drivers/staging/media/tw5864/tw5864-core.c   |  453 ++
>  drivers/staging/media/tw5864/tw5864-h264.c   |  183 +++
>  drivers/staging/media/tw5864/tw5864-reg.h| 2200 
> ++
>  drivers/staging/media/tw5864/tw5864-tables.h |  237 +++
>  drivers/staging/media/tw5864/tw5864-video.c  | 1364 
>  drivers/staging/media/tw5864/tw5864.h|  280 
>  include/linux/pci_ids.h  |1 +
>  14 files changed, 5255 insertions(+)
>  create mode 100644 drivers/staging/media/tw5864/Kconfig
>  create mode 100644 drivers/staging/media/tw5864/Makefile
>  create mode 100644 drivers/staging/media/tw5864/tw5864-bs.h
>  create mode 100644 drivers/staging/media/tw5864/tw5864-config.c
>  create mode 100644 drivers/staging/media/tw5864/tw5864-core.c
>  create mode 100644 drivers/staging/media/tw5864/tw5864-h264.c
>  create mode 100644 drivers/staging/media/tw5864/tw5864-reg.h
>  create mode 100644 drivers/staging/media/tw5864/tw5864-tables.h
>  create mode 100644 drivers/staging/media/tw5864/tw5864-video.c
>  create mode 100644 drivers/staging/media/tw5864/tw5864.h
> 



> diff --git a/drivers/staging/media/tw5864/tw5864-bs.h 
> b/drivers/staging/media/tw5864/tw5864-bs.h
> new file mode 100644
> index 000..8c1df7a
> --- /dev/null
> +++ b/drivers/staging/media/tw5864/tw5864-bs.h
> @@ -0,0 +1,154 @@



> +static inline void bs_direct_write(struct bs *s, u8 value)
> +{
> + *s->p = value;
> + s->p++;
> + s->i_left = 8;
> +}
> +
> +static inline void bs_write(struct bs *s, int i_count, u32 i_bits)

This one is a bit too big to be an inline IMHO.

> +{
> + if (s->p >= s->p_end - 4)
> + return;
> + while (i_count > 0) {
> + if (i_count < 32)
> + i_bits &= (1 << i_count) - 1;
> + if (i_count < s->i_left) {
> + *s->p = (*s->p << i_count) | i_bits;
> + s->i_left -= i_count;
> + break;
> + }
> + *s->p = (*s->p << s->i_left) | (i_bits >> (i_count -
> +s->i_left));
> + i_count -= s->i_left;
> + s->p++;
> + s->i_left = 8;
> + }
> +}
> +



> diff --git a/drivers/staging/media/tw5864/tw5864-config.c 
> b/drivers/staging/media/tw5864/tw5864-config.c
> new file mode 100644
> index 000..ff3e308
> --- /dev/null
> +++ b/drivers/staging/media/tw5864/tw5864-config.c
> @@ -0,0 +1,359 @@
> +/*
> + *  TW5864 driver - analog decoders configuration functions
> + *
> + *  Copyright (C) 2015 Bluecherry, LLC 
> + *  Author: Andrey Utkin 
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License as published by
> + *  the Free Software Foundation; either version 2 of the License, or
> + *  (at your option) any later version.
> + *
> + *  This program is distributed in the hope that it will be useful,
> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *  GNU General Public License for more details.
> + */
> +
> +#include "tw5864.h"
> +#include "tw5864-reg.h"
> +
> +#define TW5864_IIC_TIMEOUT  (3)
> +
> +static unsigned char tbl_pal_tw2864_common[] __used = {

Just use static const and remove the __used.

It would be nice to have a short comment before each array that gives a bit
more information.

> + 0x00, 0x00, 0x64, 0x11,
> + 0x80, 0x80, 0x00, 0x12,
> + 0x12, 0x20, 0x0a, 0xD0,
> + 0x00, 0x00, 0x07, 0x7F,
> +};
> +



> +static int __used i2c_multi_read(struct tw5864_dev *dev, u8 devid, u8 devfn,
> +  u8 *buf, u32 count)

Again, what's up with the __used? Just remove it.

> +{
> + int i = 0;
>

Re: [PATCH] media: add GFP flag to media_*() that could get called in atomic context

2016-03-14 Thread Sakari Ailus 
Hi Shuah,

On Sat, Mar 12, 2016 at 06:48:09PM -0700, Shuah Khan wrote:
> Add GFP flags to media_create_pad_link(), media_create_intf_link(),
> media_devnode_create(), and media_add_link() that could get called
> in atomic context to allow callers to pass in the right flags for
> memory allocation.
> 
> tree-wide driver changes for media_*() GFP flags change:
> Change drivers to add gfpflags to interffaces, media_create_pad_link(),
> media_create_intf_link() and media_devnode_create().
> 
> Signed-off-by: Shuah Khan 
> Suggested-by: Mauro Carvalho Chehab 

What's the use case for calling the above functions in an atomic context?

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: dgnc: Add whitespace around OR'd flags ("|")

2016-03-14 Thread Sam Horlbeck Olsen 
This patch fixes the checkpatch.pl message:

CHECK: spaces preferred around that '|' (ctx:VxV)
+   writeb((UART_FCR_ENABLE_FIFO|UART_FCR_CLEAR_RCVR|UART_FCR_CLEAR_XMIT),
^   ^

As per the guidelines for coding style in the kernel, I have updated the
digi international driver to include spaces around the OR'd flags; not only
is this formatting issue caught by `checkpatch.pl`, in the next `if` block
the correct formatting is used, leading to both incorrect and inconsistent
code formatting.

This patch puts the line in question at 82 characters---while this is over
the recommended limit, there are no clear locations to break the line and it
barely breaks the cutoff.

Signed-off-by: Sam Horlbeck Olsen 
---
 drivers/staging/dgnc/dgnc_cls.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/dgnc/dgnc_cls.c b/drivers/staging/dgnc/dgnc_cls.c
index 0ff3139..5e46ac8 100644
--- a/drivers/staging/dgnc/dgnc_cls.c
+++ b/drivers/staging/dgnc/dgnc_cls.c
@@ -1168,7 +1168,7 @@ static void cls_uart_init(struct channel_t *ch)
/* Clear out UART and FIFO */
readb(>ch_cls_uart->txrx);
 
-   writeb((UART_FCR_ENABLE_FIFO|UART_FCR_CLEAR_RCVR|UART_FCR_CLEAR_XMIT),
+   writeb((UART_FCR_ENABLE_FIFO | UART_FCR_CLEAR_RCVR | 
UART_FCR_CLEAR_XMIT),
   >ch_cls_uart->isr_fcr);
udelay(10);
 
-- 
2.5.0

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

Re: [PATCH] Add tw5864 driver

2016-03-14 Thread Joe Perches 
On Mon, 2016-03-14 at 03:59 +0200, Andrey Utkin wrote:
> Support for boards based on Techwell TW5864 chip which provides
> multichannel video & audio grabbing and encoding (H.264, MJPEG,
> ADPCM G.726).

trivia:

Perhaps all the __used arrays could be const

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