Re: [PATCH 3/3 staging-next] mm: Remove RCU and tasklocks from lmk

2017-02-09 Thread Michal Hocko
On Fri 10-02-17 08:39:11, peter enderborg wrote:
> On 02/09/2017 09:05 PM, Michal Hocko wrote:
> > On Thu 09-02-17 14:21:52, peter enderborg wrote:
> >> Fundamental changes:
> >> 1 Does NOT take any RCU lock in shrinker functions.
> >> 2 It returns same result for scan and counts, so  we dont need to do
> >>   shinker will know when it is pointless to call scan.
> >> 3 It does not lock any other process than the one that is
> >>   going to be killed.
> >>
> >> Background.
> >> The low memory killer scans for process that can be killed to free
> >> memory. This can be cpu consuming when there is a high demand for
> >> memory. This can be seen by analysing the kswapd0 task work.
> >> The stats function added in earler patch adds a counter for waste work.
> >>
> >> How it works.
> >> This patch create a structure within the lowmemory killer that caches
> >> the user spaces processes that it might kill. It is done with a
> >> sorted rbtree so we can very easy find the candidate to be killed,
> >> and knows its properies as memory usage and sorted by oom_score_adj
> >> to look up the task with highest oom_score_adj. To be able to achive
> >> this it uses oom_score_notify events.
> >>
> >> This patch also as a other effect, we are now free to do other
> >> lowmemorykiller configurations.  Without the patch there is a need
> >> for a tradeoff between freed memory and task and rcu locks. This
> >> is no longer a concern for tuning lmk. This patch is not intended
> >> to do any calculation changes other than we do use the cache for
> >> calculate the count values and that makes kswapd0 to shrink other
> >> areas.
> > I have to admit I really do not understand big part of the above
> > paragraph as well as how this all is supposed to work. A quick glance
> > over the implementation. __lmk_task_insert seems to be only called from
> > the oom_score notifier context. If nobody updates the value then no task
> > will get into the tree. Or am I missing something really obvious here?
> > Moreover oom scores tend to be mostly same for tasks. That means that
> > your sorted tree will become sorted by pids in most cases. I do not see
> > any sorting based on the rss nor any updates that would reflect updates
> > of rss. How can this possibly work?
> 
> The task tree nodes are created,updated or removed from the notifier when
> there is a relevant oom_score_adj change. If no one create a task that
> is in the range for the lowmemorykiller the tree will be empty. This is
> an android feature so the score will be updated very often. It is
> part of activity manager to prioritise tasks.  Why should we do sort of
> rss?
 
Because the current lmk selects the tasks based on rss. And the patch
doesn't explain why this is no longer suitable and a different metric
shoult be used. If you also consider that the scale of oom_score_adj is
quite small, conllisions when you simply sort based on pids which is
more than questionable. I really fail to see how this can work
reasonably and why the change of the lmk semantic is even acceptable.

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


Re: [PATCH 1/3 staging-next] android: Collect statistics from lowmemorykiller

2017-02-09 Thread Greg Kroah-Hartman
On Fri, Feb 10, 2017 at 08:21:32AM +0100, peter enderborg wrote:
> Im not speaking for google, but I think there is a work ongoing to
> replace this with user-space code.

Really?  I have not heard this at all, any pointers to whom in Google is
doing it?

> Until then we have to polish this version as good as we can. It is
> essential for android as it is now.

But if no one is willing to do the work to fix the reported issues, why
should it remain?  Can you do the work here?  You're already working on
fixing some of the issues in a differnt way, why not do the "real work"
here instead for everyone to benifit from?

thanks,

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


Re: [PATCH v4 1/2] staging: omap4iss: fix multiline comment style

2017-02-09 Thread Laurent Pinchart
Hi Avraham,

Thank you for the patches.

On Thursday 09 Feb 2017 18:57:55 Avraham Shukron wrote:
> Fixed multi-line comments to their preferred style (First line empty)
> 
> Signed-off-by: Avraham Shukron 

For both of them,

Acked-by: Laurent Pinchart 

I've applied the patches to my tree and will send a pull request for v4.12.

> ---
>  drivers/staging/media/omap4iss/iss_video.c | 38 ++-
>  1 file changed, 25 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/staging/media/omap4iss/iss_video.c
> b/drivers/staging/media/omap4iss/iss_video.c index bb0e3b4..e21811a 100644
> --- a/drivers/staging/media/omap4iss/iss_video.c
> +++ b/drivers/staging/media/omap4iss/iss_video.c
> @@ -128,7 +128,8 @@ static unsigned int iss_video_mbus_to_pix(const struct
> iss_video *video, pix->width = mbus->width;
>   pix->height = mbus->height;
> 
> - /* Skip the last format in the loop so that it will be selected if no
> + /*
> +  * Skip the last format in the loop so that it will be selected if no
>* match is found.
>*/
>   for (i = 0; i < ARRAY_SIZE(formats) - 1; ++i) {
> @@ -138,7 +139,8 @@ static unsigned int iss_video_mbus_to_pix(const struct
> iss_video *video,
> 
>   min_bpl = pix->width * ALIGN(formats[i].bpp, 8) / 8;
> 
> - /* Clamp the requested bytes per line value. If the maximum bytes per
> + /*
> +  * Clamp the requested bytes per line value. If the maximum bytes per
>* line value is zero, the module doesn't support user configurable 
line
>* sizes. Override the requested value with the minimum in that case.
>*/
> @@ -172,7 +174,8 @@ static void iss_video_pix_to_mbus(const struct
> v4l2_pix_format *pix, mbus->width = pix->width;
>   mbus->height = pix->height;
> 
> - /* Skip the last format in the loop so that it will be selected if no
> + /*
> +  * Skip the last format in the loop so that it will be selected if no
>* match is found.
>*/
>   for (i = 0; i < ARRAY_SIZE(formats) - 1; ++i) {
> @@ -360,7 +363,8 @@ static void iss_video_buf_queue(struct vb2_buffer *vb)
> 
>   spin_lock_irqsave(>qlock, flags);
> 
> - /* Mark the buffer is faulty and give it back to the queue immediately
> + /*
> +  * Mark the buffer is faulty and give it back to the queue immediately
>* if the video node has registered an error. vb2 will perform the 
same
>* check when preparing the buffer, but that is inherently racy, so we
>* need to handle the race condition with an authoritative check here.
> @@ -443,7 +447,8 @@ struct iss_buffer *omap4iss_video_buffer_next(struct
> iss_video *video)
> 
>   buf->vb.vb2_buf.timestamp = ktime_get_ns();
> 
> - /* Do frame number propagation only if this is the output video node.
> + /*
> +  * Do frame number propagation only if this is the output video node.
>* Frame number either comes from the CSI receivers or it gets
>* incremented here if H3A is not active.
>* Note: There is no guarantee that the output buffer will finish
> @@ -605,7 +610,8 @@ iss_video_set_format(struct file *file, void *fh, struct
> v4l2_format *format)
> 
>   mutex_lock(>mutex);
> 
> - /* Fill the bytesperline and sizeimage fields by converting to media 
bus
> + /*
> +  * Fill the bytesperline and sizeimage fields by converting to media 
bus
>* format and back to pixel format.
>*/
>   iss_video_pix_to_mbus(>fmt.pix, );
> @@ -678,8 +684,9 @@ iss_video_get_selection(struct file *file, void *fh,
> struct v4l2_selection *sel) if (subdev == NULL)
>   return -EINVAL;
> 
> - /* Try the get selection operation first and fallback to get format if 
not
> -  * implemented.
> + /*
> +  * Try the get selection operation first and fallback to get format if
> +  * not implemented.
>*/
>   sdsel.pad = pad;
>   ret = v4l2_subdev_call(subdev, pad, get_selection, NULL, );
> @@ -867,7 +874,8 @@ iss_video_streamon(struct file *file, void *fh, enum
> v4l2_buf_type type)
> 
>   mutex_lock(>stream_lock);
> 
> - /* Start streaming on the pipeline. No link touching an entity in the
> + /*
> +  * Start streaming on the pipeline. No link touching an entity in the
>* pipeline can be activated or deactivated once streaming is started.
>*/
>   pipe = entity->pipe
> @@ -895,7 +903,8 @@ iss_video_streamon(struct file *file, void *fh, enum
> v4l2_buf_type type) while ((entity = media_graph_walk_next()))
>   media_entity_enum_set(>ent_enum, entity);
> 
> - /* Verify that the currently configured format matches the output of
> + /*
> +  * Verify that the currently configured format matches the output of
>* the connected subdev.
>*/
>   ret = iss_video_check_format(video, vfh);
> @@ -905,7 +914,8 @@ 

Re: [PATCH 3/3 staging-next] mm: Remove RCU and tasklocks from lmk

2017-02-09 Thread peter enderborg
On 02/09/2017 09:05 PM, Michal Hocko wrote:
> On Thu 09-02-17 14:21:52, peter enderborg wrote:
>> Fundamental changes:
>> 1 Does NOT take any RCU lock in shrinker functions.
>> 2 It returns same result for scan and counts, so  we dont need to do
>>   shinker will know when it is pointless to call scan.
>> 3 It does not lock any other process than the one that is
>>   going to be killed.
>>
>> Background.
>> The low memory killer scans for process that can be killed to free
>> memory. This can be cpu consuming when there is a high demand for
>> memory. This can be seen by analysing the kswapd0 task work.
>> The stats function added in earler patch adds a counter for waste work.
>>
>> How it works.
>> This patch create a structure within the lowmemory killer that caches
>> the user spaces processes that it might kill. It is done with a
>> sorted rbtree so we can very easy find the candidate to be killed,
>> and knows its properies as memory usage and sorted by oom_score_adj
>> to look up the task with highest oom_score_adj. To be able to achive
>> this it uses oom_score_notify events.
>>
>> This patch also as a other effect, we are now free to do other
>> lowmemorykiller configurations.  Without the patch there is a need
>> for a tradeoff between freed memory and task and rcu locks. This
>> is no longer a concern for tuning lmk. This patch is not intended
>> to do any calculation changes other than we do use the cache for
>> calculate the count values and that makes kswapd0 to shrink other
>> areas.
> I have to admit I really do not understand big part of the above
> paragraph as well as how this all is supposed to work. A quick glance
> over the implementation. __lmk_task_insert seems to be only called from
> the oom_score notifier context. If nobody updates the value then no task
> will get into the tree. Or am I missing something really obvious here?
> Moreover oom scores tend to be mostly same for tasks. That means that
> your sorted tree will become sorted by pids in most cases. I do not see
> any sorting based on the rss nor any updates that would reflect updates
> of rss. How can this possibly work?

The task tree nodes are created,updated or removed from the notifier when
there is a relevant oom_score_adj change. If no one create a task that
is in the range for the lowmemorykiller the tree will be empty. This is
an android feature so the score will be updated very often. It is
part of activity manager to prioritise tasks.  Why should we do sort of
rss?


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


Re: [PATCH 1/3 staging-next] android: Collect statistics from lowmemorykiller

2017-02-09 Thread peter enderborg
Im not speaking for google, but I think there is a work ongoing to
replace this with user-space code. Until then we have to polish
this version as good as we can. It is essential for android as it is now.

On 02/09/2017 09:54 PM, Michal Hocko wrote:
> On Thu 09-02-17 21:07:37, Greg KH wrote:
>> On Thu, Feb 09, 2017 at 08:26:41PM +0100, Michal Hocko wrote:
>>> On Thu 09-02-17 14:21:45, peter enderborg wrote:
 This collects stats for shrinker calls and how much
 waste work we do within the lowmemorykiller.
>>> This doesn't explain why do we need this information and who is going to
>>> use it. Not to mention it exports it in /proc which is considered a
>>> stable user API. This is a no-go, especially for something that is still
>>> lingering in the staging tree without any actuall effort to make it
>>> fully supported MM feature. I am actually strongly inclined to simply
>>> drop lmk from the tree completely.
>> I thought that someone was working to get the "native" mm features to
>> work properly with the lmk "feature"  Do you recall if that work got
>> rejected, or just never happened?
> Never happened AFAIR. There were some attempts to tune the current
> behavior which has been rejected for one reason or another but I am not
> really aware of anybody working on moving the code from staging area.
>
> I already have this in the to-send queue, just didn't get to post it yet
> because I planned to polish the reasoning some more.
> ---
> From 9f871b54a387e0a7cdfaf0fa256d1440093e427c Mon Sep 17 00:00:00 2001
> From: Michal Hocko 
> Date: Wed, 1 Feb 2017 10:37:30 +0100
> Subject: [PATCH] staging, android: remove lowmemory killer from the tree
>
> Lowmemory killer is sitting in the staging tree since 2008 without any
> serious interest for fixing issues brought up by the MM folks. The main
> objection is that the implementation is basically broken by design:
>   - it hooks into slab shrinker API which is not suitable for this
> purpose. lowmem_count implementation just shows this nicely.
> There is no scaling based on the memory pressure and no
> feedback to the generic shrinker infrastructure.
>   - it is not reclaim context aware - no NUMA and/or memcg
> awareness.
>
> As the code stands right now it just adds a maintenance overhead when
> core MM changes have to update lowmemorykiller.c as well.
>
> Signed-off-by: Michal Hocko 
> ---
>  drivers/staging/android/Kconfig   |  10 --
>  drivers/staging/android/Makefile  |   1 -
>  drivers/staging/android/lowmemorykiller.c | 212 
> --
>  include/linux/sched.h |   4 -
>  4 files changed, 227 deletions(-)
>  delete mode 100644 drivers/staging/android/lowmemorykiller.c
>
> diff --git a/drivers/staging/android/Kconfig b/drivers/staging/android/Kconfig
> index 6c00d6f765c6..71a50b99caff 100644
> --- a/drivers/staging/android/Kconfig
> +++ b/drivers/staging/android/Kconfig
> @@ -14,16 +14,6 @@ config ASHMEM
> It is, in theory, a good memory allocator for low-memory devices,
> because it can discard shared memory units when under memory pressure.
>  
> -config ANDROID_LOW_MEMORY_KILLER
> - bool "Android Low Memory Killer"
> - ---help---
> -   Registers processes to be killed when low memory conditions, this is 
> useful
> -   as there is no particular swap space on android.
> -
> -   The registered process will kill according to the priorities in 
> android init
> -   scripts (/init.rc), and it defines priority values with minimum free 
> memory size
> -   for each priority.
> -
>  source "drivers/staging/android/ion/Kconfig"
>  
>  endif # if ANDROID
> diff --git a/drivers/staging/android/Makefile 
> b/drivers/staging/android/Makefile
> index 7ed1be798909..7cf1564a49a5 100644
> --- a/drivers/staging/android/Makefile
> +++ b/drivers/staging/android/Makefile
> @@ -3,4 +3,3 @@ ccflags-y += -I$(src) # needed for trace 
> events
>  obj-y+= ion/
>  
>  obj-$(CONFIG_ASHMEM) += ashmem.o
> -obj-$(CONFIG_ANDROID_LOW_MEMORY_KILLER)  += lowmemorykiller.o
> diff --git a/drivers/staging/android/lowmemorykiller.c 
> b/drivers/staging/android/lowmemorykiller.c
> deleted file mode 100644
> index ec3b66561412..
> --- a/drivers/staging/android/lowmemorykiller.c
> +++ /dev/null
> @@ -1,212 +0,0 @@
> -/* drivers/misc/lowmemorykiller.c
> - *
> - * The lowmemorykiller driver lets user-space specify a set of memory 
> thresholds
> - * where processes with a range of oom_score_adj values will get killed. 
> Specify
> - * the minimum oom_score_adj values in
> - * /sys/module/lowmemorykiller/parameters/adj and the number of free pages in
> - * /sys/module/lowmemorykiller/parameters/minfree. Both files take a comma
> - * separated list of numbers in ascending order.
> - *
> - * For example, write "0,8" to 

Re: [PATCH 1/3 v2 staging-next] android: Collect statistics from lowmemorykiller

2017-02-09 Thread peter enderborg
On 02/09/2017 09:13 PM, Greg Kroah-Hartman wrote:
> On Thu, Feb 09, 2017 at 04:42:35PM +0100, peter enderborg wrote:
>> This collects stats for shrinker calls and how much
>> waste work we do within the lowmemorykiller.
>>
>> Signed-off-by: Peter Enderborg 
>> ---
>>  drivers/staging/android/Kconfig | 11 
>>  drivers/staging/android/Makefile|  1 +
>>  drivers/staging/android/lowmemorykiller.c   |  9 ++-
>>  drivers/staging/android/lowmemorykiller_stats.c | 85 
>> +
>>  drivers/staging/android/lowmemorykiller_stats.h | 29 +
>>  5 files changed, 134 insertions(+), 1 deletion(-)
>>  create mode 100644 drivers/staging/android/lowmemorykiller_stats.c
>>  create mode 100644 drivers/staging/android/lowmemorykiller_stats.h
> What changed from v1?
Nothing. I thought I found the reason why my tabs are replaced by spaces in 
transport.

>> @@ -72,6 +73,7 @@ static unsigned long lowmem_deathpending_timeout;
>>  static unsigned long lowmem_count(struct shrinker *s,
>>struct shrink_control *sc)
>>  {
>> +lmk_inc_stats(LMK_COUNT);
>>  return global_node_page_state(NR_ACTIVE_ANON) +
>>  global_node_page_state(NR_ACTIVE_FILE) +
>>  global_node_page_state(NR_INACTIVE_ANON) +
> Your email client is eating tabs and spitting out spaces, making this
> impossible to even consider being merged :(
>
> Please fix your email client, documentation for how to do so is in the
> kernel Documentation directory.
>
> thanks,
>
> greg k-h


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


[PATCH] Staging: iio: meter: meter.h - style fix

2017-02-09 Thread Derek Robson
Changed file permissions to octal.
Found with checkpatch.

Signed-off-by: Derek Robson 
---
 drivers/staging/iio/meter/meter.h | 60 +++
 1 file changed, 30 insertions(+), 30 deletions(-)

diff --git a/drivers/staging/iio/meter/meter.h 
b/drivers/staging/iio/meter/meter.h
index dfba510f29be..0e37f23853f1 100644
--- a/drivers/staging/iio/meter/meter.h
+++ b/drivers/staging/iio/meter/meter.h
@@ -81,94 +81,94 @@
IIO_DEVICE_ATTR(reactive_power_c_gain, _mode, _show, _store, _addr)
 
 #define IIO_DEV_ATTR_CURRENT_A(_show, _addr)   \
-   IIO_DEVICE_ATTR(current_a, S_IRUGO, _show, NULL, _addr)
+   IIO_DEVICE_ATTR(current_a, 0444, _show, NULL, _addr)
 
 #define IIO_DEV_ATTR_CURRENT_B(_show, _addr)   \
-   IIO_DEVICE_ATTR(current_b, S_IRUGO, _show, NULL, _addr)
+   IIO_DEVICE_ATTR(current_b, 0444, _show, NULL, _addr)
 
 #define IIO_DEV_ATTR_CURRENT_C(_show, _addr)   \
-   IIO_DEVICE_ATTR(current_c, S_IRUGO, _show, NULL, _addr)
+   IIO_DEVICE_ATTR(current_c, 0444, _show, NULL, _addr)
 
 #define IIO_DEV_ATTR_VOLT_A(_show, _addr)  \
-   IIO_DEVICE_ATTR(volt_a, S_IRUGO, _show, NULL, _addr)
+   IIO_DEVICE_ATTR(volt_a, 0444, _show, NULL, _addr)
 
 #define IIO_DEV_ATTR_VOLT_B(_show, _addr)  \
-   IIO_DEVICE_ATTR(volt_b, S_IRUGO, _show, NULL, _addr)
+   IIO_DEVICE_ATTR(volt_b, 0444, _show, NULL, _addr)
 
 #define IIO_DEV_ATTR_VOLT_C(_show, _addr)  \
-   IIO_DEVICE_ATTR(volt_c, S_IRUGO, _show, NULL, _addr)
+   IIO_DEVICE_ATTR(volt_c, 0444, _show, NULL, _addr)
 
 #define IIO_DEV_ATTR_AENERGY(_show, _addr) \
-   IIO_DEVICE_ATTR(aenergy, S_IRUGO, _show, NULL, _addr)
+   IIO_DEVICE_ATTR(aenergy, 0444, _show, NULL, _addr)
 
 #define IIO_DEV_ATTR_LENERGY(_show, _addr) \
-   IIO_DEVICE_ATTR(lenergy, S_IRUGO, _show, NULL, _addr)
+   IIO_DEVICE_ATTR(lenergy, 0444, _show, NULL, _addr)
 
 #define IIO_DEV_ATTR_RAENERGY(_show, _addr)\
-   IIO_DEVICE_ATTR(raenergy, S_IRUGO, _show, NULL, _addr)
+   IIO_DEVICE_ATTR(raenergy, 0444, _show, NULL, _addr)
 
 #define IIO_DEV_ATTR_LAENERGY(_show, _addr)\
-   IIO_DEVICE_ATTR(laenergy, S_IRUGO, _show, NULL, _addr)
+   IIO_DEVICE_ATTR(laenergy, 0444, _show, NULL, _addr)
 
 #define IIO_DEV_ATTR_VAENERGY(_show, _addr)\
-   IIO_DEVICE_ATTR(vaenergy, S_IRUGO, _show, NULL, _addr)
+   IIO_DEVICE_ATTR(vaenergy, 0444, _show, NULL, _addr)
 
 #define IIO_DEV_ATTR_LVAENERGY(_show, _addr)   \
-   IIO_DEVICE_ATTR(lvaenergy, S_IRUGO, _show, NULL, _addr)
+   IIO_DEVICE_ATTR(lvaenergy, 0444, _show, NULL, _addr)
 
 #define IIO_DEV_ATTR_RVAENERGY(_show, _addr)   \
-   IIO_DEVICE_ATTR(rvaenergy, S_IRUGO, _show, NULL, _addr)
+   IIO_DEVICE_ATTR(rvaenergy, 0444, _show, NULL, _addr)
 
 #define IIO_DEV_ATTR_LVARENERGY(_show, _addr)  \
-   IIO_DEVICE_ATTR(lvarenergy, S_IRUGO, _show, NULL, _addr)
+   IIO_DEVICE_ATTR(lvarenergy, 0444, _show, NULL, _addr)
 
 #define IIO_DEV_ATTR_CHKSUM(_show, _addr)   \
-   IIO_DEVICE_ATTR(chksum, S_IRUGO, _show, NULL, _addr)
+   IIO_DEVICE_ATTR(chksum, 0444, _show, NULL, _addr)
 
 #define IIO_DEV_ATTR_ANGLE0(_show, _addr)   \
-   IIO_DEVICE_ATTR(angle0, S_IRUGO, _show, NULL, _addr)
+   IIO_DEVICE_ATTR(angle0, 0444, _show, NULL, _addr)
 
 #define IIO_DEV_ATTR_ANGLE1(_show, _addr)   \
-   IIO_DEVICE_ATTR(angle1, S_IRUGO, _show, NULL, _addr)
+   IIO_DEVICE_ATTR(angle1, 0444, _show, NULL, _addr)
 
 #define IIO_DEV_ATTR_ANGLE2(_show, _addr)   \
-   IIO_DEVICE_ATTR(angle2, S_IRUGO, _show, NULL, _addr)
+   IIO_DEVICE_ATTR(angle2, 0444, _show, NULL, _addr)
 
 #define IIO_DEV_ATTR_AWATTHR(_show, _addr) \
-   IIO_DEVICE_ATTR(awatthr, S_IRUGO, _show, NULL, _addr)
+   IIO_DEVICE_ATTR(awatthr, 0444, _show, NULL, _addr)
 
 #define IIO_DEV_ATTR_BWATTHR(_show, _addr) \
-   IIO_DEVICE_ATTR(bwatthr, S_IRUGO, _show, NULL, _addr)
+   IIO_DEVICE_ATTR(bwatthr, 0444, _show, NULL, _addr)
 
 #define IIO_DEV_ATTR_CWATTHR(_show, _addr) \
-   IIO_DEVICE_ATTR(cwatthr, S_IRUGO, _show, NULL, _addr)
+   IIO_DEVICE_ATTR(cwatthr, 0444, _show, NULL, _addr)
 
 #define IIO_DEV_ATTR_AFWATTHR(_show, _addr)\
-   IIO_DEVICE_ATTR(afwatthr, S_IRUGO, _show, NULL, _addr)
+   IIO_DEVICE_ATTR(afwatthr, 0444, _show, NULL, _addr)
 
 #define IIO_DEV_ATTR_BFWATTHR(_show, _addr)\
-   IIO_DEVICE_ATTR(bfwatthr, S_IRUGO, _show, NULL, _addr)
+   IIO_DEVICE_ATTR(bfwatthr, 0444, _show, NULL, _addr)
 
 #define IIO_DEV_ATTR_CFWATTHR(_show, _addr)\
-   

[PATCH] staging: r8712u: remove unnecessary le32_to_cpu

2017-02-09 Thread Perry Hooker
This patch fixes the following sparse warning:
drivers/staging/rtl8712/usb_ops_linux.c:212:33: warning: cast to restricted 
__le32

Signed-off-by: Perry Hooker 
---
 drivers/staging/rtl8712/usb_ops_linux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8712/usb_ops_linux.c 
b/drivers/staging/rtl8712/usb_ops_linux.c
index fc6bb0b..259ef8f 100644
--- a/drivers/staging/rtl8712/usb_ops_linux.c
+++ b/drivers/staging/rtl8712/usb_ops_linux.c
@@ -209,7 +209,7 @@ static void r8712_usb_read_port_complete(struct urb *purb)
 
precvbuf->transfer_len = purb->actual_length;
pbuf = (uint *)precvbuf->pbuf;
-   isevt = le32_to_cpu(*(pbuf + 1)) & 0x1ff;
+   isevt = *(pbuf + 1) & 0x1ff;
if ((isevt & 0x1ff) == 0x1ff) {
r8712_rxcmd_event_hdl(padapter, pbuf);
skb_queue_tail(>rx_skb_queue, pskb);
-- 
2.4.11

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


Re: [PATCH 1/1] Ddrivers: hv: Turn off write permission on the hypercall page

2017-02-09 Thread Stephen Hemminger
On Wed,  8 Feb 2017 18:30:56 -0700
k...@exchange.microsoft.com wrote:

> From: K. Y. Srinivasan 
> 
> The hypercall page only needs to be executable but currently it is setup to
> be writable as well. Fix the issue.
> 
> Signed-off-by: K. Y. Srinivasan 
> Cc: 
> ---
>  arch/x86/hyperv/hv_init.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
> index c224b7d..db64baf 100644
> --- a/arch/x86/hyperv/hv_init.c
> +++ b/arch/x86/hyperv/hv_init.c
> @@ -125,7 +125,7 @@ void hyperv_init(void)
>   guest_id = generate_guest_id(0, LINUX_VERSION_CODE, 0);
>   wrmsrl(HV_X64_MSR_GUEST_OS_ID, guest_id);
>  
> - hypercall_pg  = __vmalloc(PAGE_SIZE, GFP_KERNEL, PAGE_KERNEL_EXEC);
> + hypercall_pg  = __vmalloc(PAGE_SIZE, GFP_KERNEL, PAGE_KERNEL_RX);
>   if (hypercall_pg == NULL) {
>   wrmsrl(HV_X64_MSR_GUEST_OS_ID, 0);

Verified that this fixes the original problem.
I don't see the warning anymore and the guest works normally.

Reported-by: Stephen Hemminger 
Tested-by: Stephen Hemminger 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v3 21/24] media: imx: Add MIPI CSI-2 Receiver subdev driver

2017-02-09 Thread Steve Longerbeam



On 02/09/2017 03:49 PM, Steve Longerbeam wrote:



On 02/08/2017 03:42 PM, Russell King - ARM Linux wrote:

On Wed, Feb 08, 2017 at 03:23:53PM -0800, Steve Longerbeam wrote:
Actually, this exact function already exists as 
dw_mipi_dsi_phy_write in

drivers/gpu/drm/rockchip/dw-mipi-dsi.c, and it looks like the D-PHY
register 0x44 might contain a field called HSFREQRANGE_SEL.

Thanks for pointing out drivers/gpu/drm/rockchip/dw-mipi-dsi.c.
It's clear from that driver that there probably needs to be a fuller
treatment of the D-PHY programming here, but I don't know where
to find the MIPI CSI-2 D-PHY documentation for the i.MX6. The code
in imxcsi2_reset() was also pulled from FSL, and that's all I really 
have

to go on for the D-PHY programming. I assume the D-PHY is also a
Synopsys core, like the host controller, but the i.MX6 manual doesn't
cover it.

Why exactly?  What problems are you seeing that would necessitate a
more detailed programming of the D-PHY?  From my testing, I can wind
a 2-lane MIPI bus on iMX6D from 912Mbps per lane down to (eg) 308Mbps
per lane with your existing code without any issues.


That's good to hear.

Just from my experience with struggles to get the CSI2 receiver
up and running with an active clock lane, and my suspicions that
some of that could be due to my lack of understanding of the D-PHY
programming.


But I should add that after a re-org of the sequence, it looks more stable
now. Tested on both the SabreSD and SabreLite with the OV5640.

Steve


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


Re: [PATCH v3 21/24] media: imx: Add MIPI CSI-2 Receiver subdev driver

2017-02-09 Thread Steve Longerbeam



On 02/08/2017 03:42 PM, Russell King - ARM Linux wrote:

On Wed, Feb 08, 2017 at 03:23:53PM -0800, Steve Longerbeam wrote:

Actually, this exact function already exists as dw_mipi_dsi_phy_write in
drivers/gpu/drm/rockchip/dw-mipi-dsi.c, and it looks like the D-PHY
register 0x44 might contain a field called HSFREQRANGE_SEL.

Thanks for pointing out drivers/gpu/drm/rockchip/dw-mipi-dsi.c.
It's clear from that driver that there probably needs to be a fuller
treatment of the D-PHY programming here, but I don't know where
to find the MIPI CSI-2 D-PHY documentation for the i.MX6. The code
in imxcsi2_reset() was also pulled from FSL, and that's all I really have
to go on for the D-PHY programming. I assume the D-PHY is also a
Synopsys core, like the host controller, but the i.MX6 manual doesn't
cover it.

Why exactly?  What problems are you seeing that would necessitate a
more detailed programming of the D-PHY?  From my testing, I can wind
a 2-lane MIPI bus on iMX6D from 912Mbps per lane down to (eg) 308Mbps
per lane with your existing code without any issues.


That's good to hear.

Just from my experience with struggles to get the CSI2 receiver
up and running with an active clock lane, and my suspicions that
some of that could be due to my lack of understanding of the D-PHY
programming.

Steve

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


Re: [PATCH 1/2] hyperv: implement hv_get_tsc_page()

2017-02-09 Thread Stephen Hemminger
On Thu, 9 Feb 2017 21:14:25 +0100 (CET)
Thomas Gleixner  wrote:

> On Thu, 9 Feb 2017, Stephen Hemminger wrote:
> 
> > The actual code looks fine, but the style police will not like you.
> > { should be at start of line on functions.
> > And #else should be at start of line,
> > 
> > But maybe this was just more of exchange mangling the mail.  
> 
> Looks like.
> 
> > +struct ms_hyperv_tsc_page *hv_get_tsc_page(void) {
> > +   return tsc_pg;
> > +}
> > +  
> 
> That's how it reads in a proper mail client connected to a proper mail
> server:
> 
> > +struct ms_hyperv_tsc_page *hv_get_tsc_page(void)
> > +{
> > +   return tsc_pg;
> > +}  
> 
> :)


Yup. it looks like the mail server is trying to be "helpful" by eliminating 
extra white space.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH 2/2] x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read method

2017-02-09 Thread Stephen Hemminger
On Thu, 9 Feb 2017 14:55:50 -0800
Andy Lutomirski  wrote:

> On Thu, Feb 9, 2017 at 12:45 PM, KY Srinivasan  wrote:
> >
> >  
> >> -Original Message-
> >> From: Thomas Gleixner [mailto:t...@linutronix.de]
> >> Sent: Thursday, February 9, 2017 9:08 AM
> >> To: Vitaly Kuznetsov 
> >> Cc: x...@kernel.org; Andy Lutomirski ; Ingo Molnar
> >> ; H. Peter Anvin ; KY Srinivasan
> >> ; Haiyang Zhang ; Stephen
> >> Hemminger ; Dexuan Cui
> >> ; linux-ker...@vger.kernel.org;
> >> de...@linuxdriverproject.org; virtualizat...@lists.linux-foundation.org
> >> Subject: Re: [PATCH 2/2] x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read
> >> method
> >>
> >> On Thu, 9 Feb 2017, Vitaly Kuznetsov wrote:  
> >> > +#ifdef CONFIG_HYPERV_TSCPAGE
> >> > +static notrace u64 vread_hvclock(int *mode)
> >> > +{
> >> > +   const struct ms_hyperv_tsc_page *tsc_pg =
> >> > +   (const struct ms_hyperv_tsc_page *)_page;
> >> > +   u64 sequence, scale, offset, current_tick, cur_tsc;
> >> > +
> >> > +   while (1) {
> >> > +   sequence = READ_ONCE(tsc_pg->tsc_sequence);
> >> > +   if (!sequence)
> >> > +   break;
> >> > +
> >> > +   scale = READ_ONCE(tsc_pg->tsc_scale);
> >> > +   offset = READ_ONCE(tsc_pg->tsc_offset);
> >> > +   rdtscll(cur_tsc);
> >> > +
> >> > +   current_tick = mul_u64_u64_shr(cur_tsc, scale, 64) + offset;
> >> > +
> >> > +   if (READ_ONCE(tsc_pg->tsc_sequence) == sequence)
> >> > +   return current_tick;  
> >>
> >> That sequence stuff lacks still a sensible explanation. It's fundamentally
> >> different from the sequence counting we do in the kernel, so documentation
> >> for it is really required.  
> >
> > The host is updating multiple fields in this shared TSC page and the 
> > sequence number is
> > used to ensure that the guest sees a consistent set values published. If I 
> > remember
> > correctly, Xen has a similar mechanism.  
> 
> So what's the actual protocol?  When the hypervisor updates the page,
> does it freeze all guest cpus?  If not, how does it maintain
> atomicity?

The protocol looks a lot like Linux seqlock, but it has an extra protection
which is missing here.

The host needs to update sequence number twice in order to guarantee ordering.
Otherwise it is possible that Host and guest can race.

Host
Write offset
Write scale
Set tsc_sequence = N
  Guest
read sequence = N
Read scale
Write scale
Write offset

Read Offset
Check sequence == N
Set tsc_sequence = N +1

Look like the current host side protocol is wrong.

The solution that Andi Kleen invented, and I used in seqlock was for the writer 
to update
sequence at start and end of transaction. If sequence number is odd, then the 
reader knows
it is looking at stale data.
Host
Write offset
Write scale
Set tsc_sequence = N (end of 
transaction)
  Guest
read sequence = N
Spin until sequence is even (N is even)
Read scale
Set tsc_sequence += 1
Write scale
Write offset

Read Offset
Check sequence == N? (fails is N + 1)
Set tsc_sequence += 1 (end of 
transaction)
read sequence = N+2
Spin until sequence is even (ie N +2)
Read scale  
Read Offset
Check sequence == N +2? (yes ok).

Also it is faster to just read scale and offset with this loop and save
the reading of TSC and doing multiply until after scale/offset has been 
acquired.




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


Re: [PATCH 2/2] x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read method

2017-02-09 Thread Andy Lutomirski
On Thu, Feb 9, 2017 at 12:45 PM, KY Srinivasan  wrote:
>
>
>> -Original Message-
>> From: Thomas Gleixner [mailto:t...@linutronix.de]
>> Sent: Thursday, February 9, 2017 9:08 AM
>> To: Vitaly Kuznetsov 
>> Cc: x...@kernel.org; Andy Lutomirski ; Ingo Molnar
>> ; H. Peter Anvin ; KY Srinivasan
>> ; Haiyang Zhang ; Stephen
>> Hemminger ; Dexuan Cui
>> ; linux-ker...@vger.kernel.org;
>> de...@linuxdriverproject.org; virtualizat...@lists.linux-foundation.org
>> Subject: Re: [PATCH 2/2] x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read
>> method
>>
>> On Thu, 9 Feb 2017, Vitaly Kuznetsov wrote:
>> > +#ifdef CONFIG_HYPERV_TSCPAGE
>> > +static notrace u64 vread_hvclock(int *mode)
>> > +{
>> > +   const struct ms_hyperv_tsc_page *tsc_pg =
>> > +   (const struct ms_hyperv_tsc_page *)_page;
>> > +   u64 sequence, scale, offset, current_tick, cur_tsc;
>> > +
>> > +   while (1) {
>> > +   sequence = READ_ONCE(tsc_pg->tsc_sequence);
>> > +   if (!sequence)
>> > +   break;
>> > +
>> > +   scale = READ_ONCE(tsc_pg->tsc_scale);
>> > +   offset = READ_ONCE(tsc_pg->tsc_offset);
>> > +   rdtscll(cur_tsc);
>> > +
>> > +   current_tick = mul_u64_u64_shr(cur_tsc, scale, 64) + offset;
>> > +
>> > +   if (READ_ONCE(tsc_pg->tsc_sequence) == sequence)
>> > +   return current_tick;
>>
>> That sequence stuff lacks still a sensible explanation. It's fundamentally
>> different from the sequence counting we do in the kernel, so documentation
>> for it is really required.
>
> The host is updating multiple fields in this shared TSC page and the sequence 
> number is
> used to ensure that the guest sees a consistent set values published. If I 
> remember
> correctly, Xen has a similar mechanism.

So what's the actual protocol?  When the hypervisor updates the page,
does it freeze all guest cpus?  If not, how does it maintain
atomicity?

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


[PATCH] Do not initialise statics to NULL

2017-02-09 Thread William Stevenson
This patch fixes a checkpatch.pl error in bcm2835.c

ERROR: do not initialise statics to NULL

Signed-off-by: William Stevenson 
---
 drivers/staging/bcm2835-audio/bcm2835.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/bcm2835-audio/bcm2835.c 
b/drivers/staging/bcm2835-audio/bcm2835.c
index a84d74daccbc..265fe5565f42 100644
--- a/drivers/staging/bcm2835-audio/bcm2835.c
+++ b/drivers/staging/bcm2835-audio/bcm2835.c
@@ -28,8 +28,8 @@
  * to debug if we run into issues
  */
 
-static struct snd_card *g_card = NULL;
-static struct bcm2835_chip *g_chip = NULL;
+static struct snd_card *g_card;
+static struct bcm2835_chip *g_chip;
 
 static int snd_bcm2835_free(struct bcm2835_chip *chip)
 {
-- 
2.11.1

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


[PATCH] staging: wlan_ng: fix logical continuation alignment

2017-02-09 Thread Frans Klaver
It appears that our coding style prefers that logical continuations
have the operator at the end of the line. Fix that.

While at it, stick the 'if' after 'else' where it belongs.

Signed-off-by: Frans Klaver 
---
 drivers/staging/wlan-ng/prism2mgmt.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/wlan-ng/prism2mgmt.c 
b/drivers/staging/wlan-ng/prism2mgmt.c
index c558ad6..0e671c3 100644
--- a/drivers/staging/wlan-ng/prism2mgmt.c
+++ b/drivers/staging/wlan-ng/prism2mgmt.c
@@ -1303,14 +1303,13 @@ int prism2mgmt_wlansniff(struct wlandevice *wlandev, 
void *msgp)
/* Set the driver state */
/* Do we want the prism2 header? */
if ((msg->prismheader.status ==
-P80211ENUM_msgitem_status_data_ok)
-   && (msg->prismheader.data == P80211ENUM_truth_true)) {
+P80211ENUM_msgitem_status_data_ok) &&
+   (msg->prismheader.data == P80211ENUM_truth_true)) {
hw->sniffhdr = 0;
wlandev->netdev->type = ARPHRD_IEEE80211_PRISM;
-   } else
-   if ((msg->wlanheader.status ==
-P80211ENUM_msgitem_status_data_ok)
-   && (msg->wlanheader.data == P80211ENUM_truth_true)) {
+   } else if ((msg->wlanheader.status ==
+   P80211ENUM_msgitem_status_data_ok) &&
+  (msg->wlanheader.data == P80211ENUM_truth_true)) {
hw->sniffhdr = 1;
wlandev->netdev->type = ARPHRD_IEEE80211_PRISM;
} else {
-- 
2.10.2

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


[PATCH 1/1] staging: comedi: s626: usleep_range is preferred over udelay

2017-02-09 Thread Saber Rezvani
Fix the checkpatch.pl issue:
CHECK: usleep_range is preferred over udelay

Signed-off-by: Saber Rezvani 
---
 drivers/staging/comedi/drivers/s626.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/drivers/s626.c 
b/drivers/staging/comedi/drivers/s626.c
index 0dd5fe2..e5db405 100644
--- a/drivers/staging/comedi/drivers/s626.c
+++ b/drivers/staging/comedi/drivers/s626.c
@@ -1513,7 +1513,7 @@ static int s626_ai_insn_read(struct comedi_device *dev,
 
for (n = 0; n < insn->n; n++) {
/* Delay 10 microseconds for analog input settling. */
-   udelay(10);
+   usleep_range(10, 100);
 
/* Start ADC by pulsing GPIO1 low */
gpio_image = readl(dev->mmio + S626_P_GPIO);
-- 
2.7.4


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


[PATCH 1/1] staging: comedi: ni_at_a2150: usleep_range is preferred over udelay

2017-02-09 Thread Saber Rezvani
Fix the checkpatch.pl issue:
CHECK: usleep_range is preferred over udelay

Signed-off-by: Saber Rezvani 
---
 drivers/staging/comedi/drivers/ni_at_a2150.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/drivers/ni_at_a2150.c 
b/drivers/staging/comedi/drivers/ni_at_a2150.c
index 5a4dcc6..c69cd67 100644
--- a/drivers/staging/comedi/drivers/ni_at_a2150.c
+++ b/drivers/staging/comedi/drivers/ni_at_a2150.c
@@ -757,7 +757,7 @@ static int a2150_attach(struct comedi_device *dev, struct 
comedi_devconfig *it)
for (i = 0; i < timeout; i++) {
if ((DCAL_BIT & inw(dev->iobase + STATUS_REG)) == 0)
break;
-   udelay(1000);
+   usleep_range(1000, 3000);
}
if (i == timeout) {
dev_err(dev->class_dev,
-- 
2.7.4


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


Re: [PATCH 1/3 staging-next] android: Collect statistics from lowmemorykiller

2017-02-09 Thread Michal Hocko
On Thu 09-02-17 21:07:37, Greg KH wrote:
> On Thu, Feb 09, 2017 at 08:26:41PM +0100, Michal Hocko wrote:
> > On Thu 09-02-17 14:21:45, peter enderborg wrote:
> > > This collects stats for shrinker calls and how much
> > > waste work we do within the lowmemorykiller.
> > 
> > This doesn't explain why do we need this information and who is going to
> > use it. Not to mention it exports it in /proc which is considered a
> > stable user API. This is a no-go, especially for something that is still
> > lingering in the staging tree without any actuall effort to make it
> > fully supported MM feature. I am actually strongly inclined to simply
> > drop lmk from the tree completely.
> 
> I thought that someone was working to get the "native" mm features to
> work properly with the lmk "feature"  Do you recall if that work got
> rejected, or just never happened?

Never happened AFAIR. There were some attempts to tune the current
behavior which has been rejected for one reason or another but I am not
really aware of anybody working on moving the code from staging area.

I already have this in the to-send queue, just didn't get to post it yet
because I planned to polish the reasoning some more.
---
>From 9f871b54a387e0a7cdfaf0fa256d1440093e427c Mon Sep 17 00:00:00 2001
From: Michal Hocko 
Date: Wed, 1 Feb 2017 10:37:30 +0100
Subject: [PATCH] staging, android: remove lowmemory killer from the tree

Lowmemory killer is sitting in the staging tree since 2008 without any
serious interest for fixing issues brought up by the MM folks. The main
objection is that the implementation is basically broken by design:
- it hooks into slab shrinker API which is not suitable for this
  purpose. lowmem_count implementation just shows this nicely.
  There is no scaling based on the memory pressure and no
  feedback to the generic shrinker infrastructure.
- it is not reclaim context aware - no NUMA and/or memcg
  awareness.

As the code stands right now it just adds a maintenance overhead when
core MM changes have to update lowmemorykiller.c as well.

Signed-off-by: Michal Hocko 
---
 drivers/staging/android/Kconfig   |  10 --
 drivers/staging/android/Makefile  |   1 -
 drivers/staging/android/lowmemorykiller.c | 212 --
 include/linux/sched.h |   4 -
 4 files changed, 227 deletions(-)
 delete mode 100644 drivers/staging/android/lowmemorykiller.c

diff --git a/drivers/staging/android/Kconfig b/drivers/staging/android/Kconfig
index 6c00d6f765c6..71a50b99caff 100644
--- a/drivers/staging/android/Kconfig
+++ b/drivers/staging/android/Kconfig
@@ -14,16 +14,6 @@ config ASHMEM
  It is, in theory, a good memory allocator for low-memory devices,
  because it can discard shared memory units when under memory pressure.
 
-config ANDROID_LOW_MEMORY_KILLER
-   bool "Android Low Memory Killer"
-   ---help---
- Registers processes to be killed when low memory conditions, this is 
useful
- as there is no particular swap space on android.
-
- The registered process will kill according to the priorities in 
android init
- scripts (/init.rc), and it defines priority values with minimum free 
memory size
- for each priority.
-
 source "drivers/staging/android/ion/Kconfig"
 
 endif # if ANDROID
diff --git a/drivers/staging/android/Makefile b/drivers/staging/android/Makefile
index 7ed1be798909..7cf1564a49a5 100644
--- a/drivers/staging/android/Makefile
+++ b/drivers/staging/android/Makefile
@@ -3,4 +3,3 @@ ccflags-y += -I$(src)   # needed for trace 
events
 obj-y  += ion/
 
 obj-$(CONFIG_ASHMEM)   += ashmem.o
-obj-$(CONFIG_ANDROID_LOW_MEMORY_KILLER)+= lowmemorykiller.o
diff --git a/drivers/staging/android/lowmemorykiller.c 
b/drivers/staging/android/lowmemorykiller.c
deleted file mode 100644
index ec3b66561412..
--- a/drivers/staging/android/lowmemorykiller.c
+++ /dev/null
@@ -1,212 +0,0 @@
-/* drivers/misc/lowmemorykiller.c
- *
- * The lowmemorykiller driver lets user-space specify a set of memory 
thresholds
- * where processes with a range of oom_score_adj values will get killed. 
Specify
- * the minimum oom_score_adj values in
- * /sys/module/lowmemorykiller/parameters/adj and the number of free pages in
- * /sys/module/lowmemorykiller/parameters/minfree. Both files take a comma
- * separated list of numbers in ascending order.
- *
- * For example, write "0,8" to /sys/module/lowmemorykiller/parameters/adj and
- * "1024,4096" to /sys/module/lowmemorykiller/parameters/minfree to kill
- * processes with a oom_score_adj value of 8 or higher when the free memory
- * drops below 4096 pages and kill processes with a oom_score_adj value of 0 or
- * higher when the free memory drops below 1024 pages.
- *
- * The driver considers memory used for caches to be free, but if a 

RE: [PATCH 2/2] x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read method

2017-02-09 Thread KY Srinivasan


> -Original Message-
> From: Thomas Gleixner [mailto:t...@linutronix.de]
> Sent: Thursday, February 9, 2017 9:08 AM
> To: Vitaly Kuznetsov 
> Cc: x...@kernel.org; Andy Lutomirski ; Ingo Molnar
> ; H. Peter Anvin ; KY Srinivasan
> ; Haiyang Zhang ; Stephen
> Hemminger ; Dexuan Cui
> ; linux-ker...@vger.kernel.org;
> de...@linuxdriverproject.org; virtualizat...@lists.linux-foundation.org
> Subject: Re: [PATCH 2/2] x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read
> method
> 
> On Thu, 9 Feb 2017, Vitaly Kuznetsov wrote:
> > +#ifdef CONFIG_HYPERV_TSCPAGE
> > +static notrace u64 vread_hvclock(int *mode)
> > +{
> > +   const struct ms_hyperv_tsc_page *tsc_pg =
> > +   (const struct ms_hyperv_tsc_page *)_page;
> > +   u64 sequence, scale, offset, current_tick, cur_tsc;
> > +
> > +   while (1) {
> > +   sequence = READ_ONCE(tsc_pg->tsc_sequence);
> > +   if (!sequence)
> > +   break;
> > +
> > +   scale = READ_ONCE(tsc_pg->tsc_scale);
> > +   offset = READ_ONCE(tsc_pg->tsc_offset);
> > +   rdtscll(cur_tsc);
> > +
> > +   current_tick = mul_u64_u64_shr(cur_tsc, scale, 64) + offset;
> > +
> > +   if (READ_ONCE(tsc_pg->tsc_sequence) == sequence)
> > +   return current_tick;
> 
> That sequence stuff lacks still a sensible explanation. It's fundamentally
> different from the sequence counting we do in the kernel, so documentation
> for it is really required.

The host is updating multiple fields in this shared TSC page and the sequence 
number is
used to ensure that the guest sees a consistent set values published. If I 
remember
correctly, Xen has a similar mechanism.

K. Y
> 
> Thanks,
> 
>   tglx
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH 1/3 v2 staging-next] android: Collect statistics from lowmemorykiller

2017-02-09 Thread Greg Kroah-Hartman
On Thu, Feb 09, 2017 at 04:42:35PM +0100, peter enderborg wrote:
> This collects stats for shrinker calls and how much
> waste work we do within the lowmemorykiller.
> 
> Signed-off-by: Peter Enderborg 
> ---
>  drivers/staging/android/Kconfig | 11 
>  drivers/staging/android/Makefile|  1 +
>  drivers/staging/android/lowmemorykiller.c   |  9 ++-
>  drivers/staging/android/lowmemorykiller_stats.c | 85 
> +
>  drivers/staging/android/lowmemorykiller_stats.h | 29 +
>  5 files changed, 134 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/staging/android/lowmemorykiller_stats.c
>  create mode 100644 drivers/staging/android/lowmemorykiller_stats.h

What changed from v1?

> @@ -72,6 +73,7 @@ static unsigned long lowmem_deathpending_timeout;
>  static unsigned long lowmem_count(struct shrinker *s,
>struct shrink_control *sc)
>  {
> +lmk_inc_stats(LMK_COUNT);
>  return global_node_page_state(NR_ACTIVE_ANON) +
>  global_node_page_state(NR_ACTIVE_FILE) +
>  global_node_page_state(NR_INACTIVE_ANON) +

Your email client is eating tabs and spitting out spaces, making this
impossible to even consider being merged :(

Please fix your email client, documentation for how to do so is in the
kernel Documentation directory.

thanks,

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


Re: [PATCH 1/3 staging-next] android: Collect statistics from lowmemorykiller

2017-02-09 Thread Greg Kroah-Hartman
On Thu, Feb 09, 2017 at 08:26:41PM +0100, Michal Hocko wrote:
> On Thu 09-02-17 14:21:45, peter enderborg wrote:
> > This collects stats for shrinker calls and how much
> > waste work we do within the lowmemorykiller.
> 
> This doesn't explain why do we need this information and who is going to
> use it. Not to mention it exports it in /proc which is considered a
> stable user API. This is a no-go, especially for something that is still
> lingering in the staging tree without any actuall effort to make it
> fully supported MM feature. I am actually strongly inclined to simply
> drop lmk from the tree completely.

I thought that someone was working to get the "native" mm features to
work properly with the lmk "feature"  Do you recall if that work got
rejected, or just never happened?

thanks,

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


RE: [PATCH 1/2] hyperv: implement hv_get_tsc_page()

2017-02-09 Thread Thomas Gleixner
On Thu, 9 Feb 2017, Stephen Hemminger wrote:

> The actual code looks fine, but the style police will not like you.
> { should be at start of line on functions.
> And #else should be at start of line,
> 
> But maybe this was just more of exchange mangling the mail.

Looks like.

> +struct ms_hyperv_tsc_page *hv_get_tsc_page(void) {
> + return tsc_pg;
> +}
> +

That's how it reads in a proper mail client connected to a proper mail
server:

> +struct ms_hyperv_tsc_page *hv_get_tsc_page(void)
> +{
> +   return tsc_pg;
> +}

:)

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


Re: [PATCH 3/3 staging-next] mm: Remove RCU and tasklocks from lmk

2017-02-09 Thread Michal Hocko
On Thu 09-02-17 14:21:52, peter enderborg wrote:
> Fundamental changes:
> 1 Does NOT take any RCU lock in shrinker functions.
> 2 It returns same result for scan and counts, so  we dont need to do
>   shinker will know when it is pointless to call scan.
> 3 It does not lock any other process than the one that is
>   going to be killed.
> 
> Background.
> The low memory killer scans for process that can be killed to free
> memory. This can be cpu consuming when there is a high demand for
> memory. This can be seen by analysing the kswapd0 task work.
> The stats function added in earler patch adds a counter for waste work.
> 
> How it works.
> This patch create a structure within the lowmemory killer that caches
> the user spaces processes that it might kill. It is done with a
> sorted rbtree so we can very easy find the candidate to be killed,
> and knows its properies as memory usage and sorted by oom_score_adj
> to look up the task with highest oom_score_adj. To be able to achive
> this it uses oom_score_notify events.
> 
> This patch also as a other effect, we are now free to do other
> lowmemorykiller configurations.  Without the patch there is a need
> for a tradeoff between freed memory and task and rcu locks. This
> is no longer a concern for tuning lmk. This patch is not intended
> to do any calculation changes other than we do use the cache for
> calculate the count values and that makes kswapd0 to shrink other
> areas.

I have to admit I really do not understand big part of the above
paragraph as well as how this all is supposed to work. A quick glance
over the implementation. __lmk_task_insert seems to be only called from
the oom_score notifier context. If nobody updates the value then no task
will get into the tree. Or am I missing something really obvious here?
Moreover oom scores tend to be mostly same for tasks. That means that
your sorted tree will become sorted by pids in most cases. I do not see
any sorting based on the rss nor any updates that would reflect updates
of rss. How can this possibly work?
-- 
Michal Hocko
SUSE Labs
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH 1/3 staging-next] android: Collect statistics from lowmemorykiller

2017-02-09 Thread Michal Hocko
On Thu 09-02-17 14:21:45, peter enderborg wrote:
> This collects stats for shrinker calls and how much
> waste work we do within the lowmemorykiller.

This doesn't explain why do we need this information and who is going to
use it. Not to mention it exports it in /proc which is considered a
stable user API. This is a no-go, especially for something that is still
lingering in the staging tree without any actuall effort to make it
fully supported MM feature. I am actually strongly inclined to simply
drop lmk from the tree completely.

> Signed-off-by: Peter Enderborg 

Nacked-by: Michal Hocko 

> ---
>  drivers/staging/android/Kconfig | 11 
>  drivers/staging/android/Makefile|  1 +
>  drivers/staging/android/lowmemorykiller.c   |  9 ++-
>  drivers/staging/android/lowmemorykiller_stats.c | 85 
> +
>  drivers/staging/android/lowmemorykiller_stats.h | 29 +
>  5 files changed, 134 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/staging/android/lowmemorykiller_stats.c
>  create mode 100644 drivers/staging/android/lowmemorykiller_stats.h
> 
> diff --git a/drivers/staging/android/Kconfig b/drivers/staging/android/Kconfig
> index 6c00d6f..96e86c7 100644
> --- a/drivers/staging/android/Kconfig
> +++ b/drivers/staging/android/Kconfig
> @@ -24,6 +24,17 @@ config ANDROID_LOW_MEMORY_KILLER
>scripts (/init.rc), and it defines priority values with minimum free 
> memory size
>for each priority.
> 
> +config ANDROID_LOW_MEMORY_KILLER_STATS
> +bool "Android Low Memory Killer: collect statistics"
> +depends on ANDROID_LOW_MEMORY_KILLER
> +default n
> +help
> +  Create a file in /proc/lmkstats that includes
> +  collected statistics about kills, scans and counts
> +  and  interaction with the shrinker. Its content
> +  will be different depeding on lmk implementation used.
> +
> +
>  source "drivers/staging/android/ion/Kconfig"
> 
>  endif # if ANDROID
> diff --git a/drivers/staging/android/Makefile 
> b/drivers/staging/android/Makefile
> index 7ed1be7..d710eb2 100644
> --- a/drivers/staging/android/Makefile
> +++ b/drivers/staging/android/Makefile
> @@ -4,3 +4,4 @@ obj-y+= ion/
> 
>  obj-$(CONFIG_ASHMEM)+= ashmem.o
>  obj-$(CONFIG_ANDROID_LOW_MEMORY_KILLER)+= lowmemorykiller.o
> +obj-$(CONFIG_ANDROID_LOW_MEMORY_KILLER_STATS)+= lowmemorykiller_stats.o
> diff --git a/drivers/staging/android/lowmemorykiller.c 
> b/drivers/staging/android/lowmemorykiller.c
> index ec3b665..15c1b38 100644
> --- a/drivers/staging/android/lowmemorykiller.c
> +++ b/drivers/staging/android/lowmemorykiller.c
> @@ -42,6 +42,7 @@
>  #include 
>  #include 
>  #include 
> +#include "lowmemorykiller_stats.h"
> 
>  static u32 lowmem_debug_level = 1;
>  static short lowmem_adj[6] = {
> @@ -72,6 +73,7 @@ static unsigned long lowmem_deathpending_timeout;
>  static unsigned long lowmem_count(struct shrinker *s,
>struct shrink_control *sc)
>  {
> +lmk_inc_stats(LMK_COUNT);
>  return global_node_page_state(NR_ACTIVE_ANON) +
>  global_node_page_state(NR_ACTIVE_FILE) +
>  global_node_page_state(NR_INACTIVE_ANON) +
> @@ -95,6 +97,7 @@ static unsigned long lowmem_scan(struct shrinker *s, struct 
> shrink_control *sc)
>  global_node_page_state(NR_SHMEM) -
>  total_swapcache_pages();
> 
> +lmk_inc_stats(LMK_SCAN);
>  if (lowmem_adj_size < array_size)
>  array_size = lowmem_adj_size;
>  if (lowmem_minfree_size < array_size)
> @@ -134,6 +137,7 @@ static unsigned long lowmem_scan(struct shrinker *s, 
> struct shrink_control *sc)
>  if (task_lmk_waiting(p) &&
>  time_before_eq(jiffies, lowmem_deathpending_timeout)) {
>  task_unlock(p);
> +lmk_inc_stats(LMK_TIMEOUT);
>  rcu_read_unlock();
>  return 0;
>  }
> @@ -179,7 +183,9 @@ static unsigned long lowmem_scan(struct shrinker *s, 
> struct shrink_control *sc)
>   other_free * (long)(PAGE_SIZE / 1024));
>  lowmem_deathpending_timeout = jiffies + HZ;
>  rem += selected_tasksize;
> -}
> +lmk_inc_stats(LMK_KILL);
> +} else
> +lmk_inc_stats(LMK_WASTE);
> 
>  lowmem_print(4, "lowmem_scan %lu, %x, return %lu\n",
>   sc->nr_to_scan, sc->gfp_mask, rem);
> @@ -196,6 +202,7 @@ static struct shrinker lowmem_shrinker = {
>  static int __init lowmem_init(void)
>  {
>  register_shrinker(_shrinker);
> +init_procfs_lmk();
>  return 0;
>  }
>  device_initcall(lowmem_init);
> diff --git a/drivers/staging/android/lowmemorykiller_stats.c 
> b/drivers/staging/android/lowmemorykiller_stats.c
> new file mode 100644
> index 000..673691c
> --- /dev/null
> +++ b/drivers/staging/android/lowmemorykiller_stats.c
> @@ -0,0 +1,85 @@
> +/*
> + *  lowmemorykiller_stats
> + *
> + *  

Re: [PATCH 2/3 staging-next] oom: Add notification for oom_score_adj

2017-02-09 Thread Michal Hocko
On Thu 09-02-17 14:21:49, peter enderborg wrote:
> This adds subscribtion for changes in oom_score_adj, this
> value is important to android systems.

Why? Who is user of this API?
-- 
Michal Hocko
SUSE Labs
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH] staging: rtl8192u: Removing unnecessary space after a cast

2017-02-09 Thread simran singhal
This patch fixes the checkpatch issue:
CHECK: No space is necessary after a cast

Signed-off-by: simran singhal 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.c
index 403f0ec..a38a064 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.c
@@ -135,7 +135,7 @@ int ieee80211_unregister_crypto_ops(struct 
ieee80211_crypto_ops *ops)
spin_lock_irqsave(>lock, flags);
for (ptr = hcrypt->algs.next; ptr != >algs; ptr = ptr->next) {
struct ieee80211_crypto_alg *alg =
-   (struct ieee80211_crypto_alg *) ptr;
+   (struct ieee80211_crypto_alg *)ptr;
if (alg->ops == ops) {
list_del(>list);
del_alg = alg;
@@ -166,7 +166,7 @@ struct ieee80211_crypto_ops *ieee80211_get_crypto_ops(const 
char *name)
spin_lock_irqsave(>lock, flags);
for (ptr = hcrypt->algs.next; ptr != >algs; ptr = ptr->next) {
struct ieee80211_crypto_alg *alg =
-   (struct ieee80211_crypto_alg *) ptr;
+   (struct ieee80211_crypto_alg *)ptr;
if (strcmp(alg->ops->name, name) == 0) {
found_alg = alg;
break;
@@ -228,7 +228,7 @@ void __exit ieee80211_crypto_deinit(void)
for (ptr = hcrypt->algs.next, n = ptr->next; ptr != >algs;
 ptr = n, n = ptr->next) {
struct ieee80211_crypto_alg *alg =
-   (struct ieee80211_crypto_alg *) ptr;
+   (struct ieee80211_crypto_alg *)ptr;
list_del(ptr);
pr_debug("ieee80211_crypt: unregistered algorithm '%s' 
(deinit)\n",
alg->ops->name);
-- 
2.7.4

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


[PATCH] staging: rtl8192u: Replace explicit NULL comparisons with !

2017-02-09 Thread simran singhal
This patch replace explicit NULL comparison with ! or unmark operator to
simplify code.
Reported by checkpatch.pl for comparison to NULL could be
written "!XXX" or "XXX".

Signed-off-by: simran singhal 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.c
index 9cf90d0..403f0ec 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.c
@@ -80,7 +80,7 @@ void ieee80211_crypt_delayed_deinit(struct ieee80211_device 
*ieee,
struct ieee80211_crypt_data *tmp;
unsigned long flags;
 
-   if (*crypt == NULL)
+   if (!(*crypt))
return;
 
tmp = *crypt;
@@ -104,11 +104,11 @@ int ieee80211_register_crypto_ops(struct 
ieee80211_crypto_ops *ops)
unsigned long flags;
struct ieee80211_crypto_alg *alg;
 
-   if (hcrypt == NULL)
+   if (!hcrypt)
return -1;
 
alg = kzalloc(sizeof(*alg), GFP_KERNEL);
-   if (alg == NULL)
+   if (!alg)
return -ENOMEM;
 
alg->ops = ops;
@@ -129,7 +129,7 @@ int ieee80211_unregister_crypto_ops(struct 
ieee80211_crypto_ops *ops)
struct list_head *ptr;
struct ieee80211_crypto_alg *del_alg = NULL;
 
-   if (hcrypt == NULL)
+   if (!hcrypt)
return -1;
 
spin_lock_irqsave(>lock, flags);
@@ -160,7 +160,7 @@ struct ieee80211_crypto_ops *ieee80211_get_crypto_ops(const 
char *name)
struct list_head *ptr;
struct ieee80211_crypto_alg *found_alg = NULL;
 
-   if (hcrypt == NULL)
+   if (!hcrypt)
return NULL;
 
spin_lock_irqsave(>lock, flags);
@@ -222,7 +222,7 @@ void __exit ieee80211_crypto_deinit(void)
 {
struct list_head *ptr, *n;
 
-   if (hcrypt == NULL)
+   if (!hcrypt)
return;
 
for (ptr = hcrypt->algs.next, n = ptr->next; ptr != >algs;
-- 
2.7.4

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


RE: [PATCH 2/2] x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read method

2017-02-09 Thread Stephen Hemminger
Why not use existing seqlock's?

-Original Message-
From: Thomas Gleixner [mailto:t...@linutronix.de] 
Sent: Thursday, February 9, 2017 9:08 AM
To: Vitaly Kuznetsov 
Cc: x...@kernel.org; Andy Lutomirski ; Ingo Molnar 
; H. Peter Anvin ; KY Srinivasan 
; Haiyang Zhang ; Stephen Hemminger 
; Dexuan Cui ; 
linux-ker...@vger.kernel.org; de...@linuxdriverproject.org; 
virtualizat...@lists.linux-foundation.org
Subject: Re: [PATCH 2/2] x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read method

On Thu, 9 Feb 2017, Vitaly Kuznetsov wrote:
> +#ifdef CONFIG_HYPERV_TSCPAGE
> +static notrace u64 vread_hvclock(int *mode) {
> + const struct ms_hyperv_tsc_page *tsc_pg =
> + (const struct ms_hyperv_tsc_page *)_page;
> + u64 sequence, scale, offset, current_tick, cur_tsc;
> +
> + while (1) {
> + sequence = READ_ONCE(tsc_pg->tsc_sequence);
> + if (!sequence)
> + break;
> +
> + scale = READ_ONCE(tsc_pg->tsc_scale);
> + offset = READ_ONCE(tsc_pg->tsc_offset);
> + rdtscll(cur_tsc);
> +
> + current_tick = mul_u64_u64_shr(cur_tsc, scale, 64) + offset;
> +
> + if (READ_ONCE(tsc_pg->tsc_sequence) == sequence)
> + return current_tick;

That sequence stuff lacks still a sensible explanation. It's fundamentally 
different from the sequence counting we do in the kernel, so documentation for 
it is really required.

Thanks,

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


RE: [PATCH 1/2] hyperv: implement hv_get_tsc_page()

2017-02-09 Thread Stephen Hemminger
The actual code looks fine, but the style police will not like you.
{ should be at start of line on functions.
And #else should be at start of line,

But maybe this was just more of exchange mangling the mail.

-Original Message-
From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] 
Sent: Thursday, February 9, 2017 6:11 AM
To: x...@kernel.org; Andy Lutomirski 
Cc: Thomas Gleixner ; Ingo Molnar ; H. 
Peter Anvin ; KY Srinivasan ; Haiyang Zhang 
; Stephen Hemminger ; Dexuan 
Cui ; linux-ker...@vger.kernel.org; 
de...@linuxdriverproject.org; virtualizat...@lists.linux-foundation.org
Subject: [PATCH 1/2] hyperv: implement hv_get_tsc_page()

To use Hyper-V TSC page clocksource from vDSO we need to make tsc_pg available. 
Implement hv_get_tsc_page() and add CONFIG_HYPERV_TSCPAGE to make #ifdef-s 
simple.

Signed-off-by: Vitaly Kuznetsov 
---
 arch/x86/hyperv/hv_init.c   | 9 +++--
 arch/x86/include/asm/mshyperv.h | 8 
 drivers/hv/Kconfig  | 3 +++
 3 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c index 
b371d0e..0ce8485 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -27,10 +27,15 @@
 #include 
 
 
-#ifdef CONFIG_X86_64
+#ifdef CONFIG_HYPERV_TSCPAGE
 
 static struct ms_hyperv_tsc_page *tsc_pg;
 
+struct ms_hyperv_tsc_page *hv_get_tsc_page(void) {
+   return tsc_pg;
+}
+
 static u64 read_hv_clock_tsc(struct clocksource *arg)  {
u64 current_tick;
@@ -136,7 +141,7 @@ void hyperv_init(void)
/*
 * Register Hyper-V specific clocksource.
 */
-#ifdef CONFIG_X86_64
+#ifdef CONFIG_HYPERV_TSCPAGE
if (ms_hyperv.features & HV_X64_MSR_REFERENCE_TSC_AVAILABLE) {
union hv_x64_msr_hypercall_contents tsc_msr;
 
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h 
index f8dc370..14dd92c 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -173,4 +173,12 @@ void hyperv_report_panic(struct pt_regs *regs);  bool 
hv_is_hypercall_page_setup(void);  void hyperv_cleanup(void);  #endif
+#ifdef CONFIG_HYPERV_TSCPAGE
+struct ms_hyperv_tsc_page *hv_get_tsc_page(void); #else static inline 
+struct ms_hyperv_tsc_page *hv_get_tsc_page(void) {
+   return NULL;
+}
+#endif
 #endif
diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig index 0403b51..c29cd53 
100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -7,6 +7,9 @@ config HYPERV
  Select this option to run Linux as a Hyper-V client operating
  system.
 
+config HYPERV_TSCPAGE
+   def_bool HYPERV && X86_64
+
 config HYPERV_UTILS
tristate "Microsoft Hyper-V Utilities driver"
depends on HYPERV && CONNECTOR && NLS
--
2.9.3

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


[PATCH] staging: rtl8192u: Remove useless function

2017-02-09 Thread simran singhal
This patch remove useless function ieee80211_ccmp_null.

Signed-off-by: simran singhal 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211.h| 1 -
 drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c | 6 --
 drivers/staging/rtl8192u/ieee80211/ieee80211_module.c | 1 -
 3 files changed, 8 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211.h 
b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
index 077ea13..e71af2f 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211.h
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
@@ -2255,7 +2255,6 @@ void softmac_mgmt_xmit(struct sk_buff *skb, struct 
ieee80211_device *ieee);
 
 /* ieee80211_crypt_ccmp */
 void ieee80211_tkip_null(void);
-void ieee80211_ccmp_null(void);
 
 int ieee80211_crypto_init(void);
 void ieee80211_crypto_deinit(void);
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c
index b9377f3..cb226ed 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c
@@ -426,12 +426,6 @@ static char *ieee80211_ccmp_print_stats(char *p, void 
*priv)
return p;
 }
 
-void ieee80211_ccmp_null(void)
-{
-   /* printk(">%s()\n", __func__); */
-   return;
-}
-
 static struct ieee80211_crypto_ops ieee80211_crypt_ccmp = {
.name   = "CCMP",
.init   = ieee80211_ccmp_init,
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c
index 30fff6c..0b162bf 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c
@@ -177,7 +177,6 @@ struct net_device *alloc_ieee80211(int sizeof_priv)
 
 /* These function were added to load crypte module autoly */
ieee80211_tkip_null();
-   ieee80211_ccmp_null();
 
return dev;
 
-- 
2.7.4

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


Re: [PATCH 2/2] x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read method

2017-02-09 Thread Thomas Gleixner
On Thu, 9 Feb 2017, Vitaly Kuznetsov wrote:
> +#ifdef CONFIG_HYPERV_TSCPAGE
> +static notrace u64 vread_hvclock(int *mode)
> +{
> + const struct ms_hyperv_tsc_page *tsc_pg =
> + (const struct ms_hyperv_tsc_page *)_page;
> + u64 sequence, scale, offset, current_tick, cur_tsc;
> +
> + while (1) {
> + sequence = READ_ONCE(tsc_pg->tsc_sequence);
> + if (!sequence)
> + break;
> +
> + scale = READ_ONCE(tsc_pg->tsc_scale);
> + offset = READ_ONCE(tsc_pg->tsc_offset);
> + rdtscll(cur_tsc);
> +
> + current_tick = mul_u64_u64_shr(cur_tsc, scale, 64) + offset;
> +
> + if (READ_ONCE(tsc_pg->tsc_sequence) == sequence)
> + return current_tick;

That sequence stuff lacks still a sensible explanation. It's fundamentally
different from the sequence counting we do in the kernel, so documentation
for it is really required.

Thanks,

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


[PATCH v4 2/2] staging: omap4iss: fix coding style issue

2017-02-09 Thread Avraham Shukron
Broke argument list so that it won't exceed 80 characters

Signed-off-by: Avraham Shukron 
---
 drivers/staging/media/omap4iss/iss_video.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/omap4iss/iss_video.c 
b/drivers/staging/media/omap4iss/iss_video.c
index e21811a..0bac582 100644
--- a/drivers/staging/media/omap4iss/iss_video.c
+++ b/drivers/staging/media/omap4iss/iss_video.c
@@ -301,7 +301,8 @@ iss_video_check_format(struct iss_video *video, struct 
iss_video_fh *vfh)

 static int iss_video_queue_setup(struct vb2_queue *vq,
 unsigned int *count, unsigned int *num_planes,
-unsigned int sizes[], struct device 
*alloc_devs[])
+unsigned int sizes[],
+struct device *alloc_devs[])
 {
struct iss_video_fh *vfh = vb2_get_drv_priv(vq);
struct iss_video *video = vfh->video;
-- 
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH v4 1/2] staging: omap4iss: fix multiline comment style

2017-02-09 Thread Avraham Shukron
Fixed multi-line comments to their preferred style (First line empty)

Signed-off-by: Avraham Shukron 
---
 drivers/staging/media/omap4iss/iss_video.c | 38 --
 1 file changed, 25 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/media/omap4iss/iss_video.c 
b/drivers/staging/media/omap4iss/iss_video.c
index bb0e3b4..e21811a 100644
--- a/drivers/staging/media/omap4iss/iss_video.c
+++ b/drivers/staging/media/omap4iss/iss_video.c
@@ -128,7 +128,8 @@ static unsigned int iss_video_mbus_to_pix(const struct 
iss_video *video,
pix->width = mbus->width;
pix->height = mbus->height;

-   /* Skip the last format in the loop so that it will be selected if no
+   /*
+* Skip the last format in the loop so that it will be selected if no
 * match is found.
 */
for (i = 0; i < ARRAY_SIZE(formats) - 1; ++i) {
@@ -138,7 +139,8 @@ static unsigned int iss_video_mbus_to_pix(const struct 
iss_video *video,

min_bpl = pix->width * ALIGN(formats[i].bpp, 8) / 8;

-   /* Clamp the requested bytes per line value. If the maximum bytes per
+   /*
+* Clamp the requested bytes per line value. If the maximum bytes per
 * line value is zero, the module doesn't support user configurable line
 * sizes. Override the requested value with the minimum in that case.
 */
@@ -172,7 +174,8 @@ static void iss_video_pix_to_mbus(const struct 
v4l2_pix_format *pix,
mbus->width = pix->width;
mbus->height = pix->height;

-   /* Skip the last format in the loop so that it will be selected if no
+   /*
+* Skip the last format in the loop so that it will be selected if no
 * match is found.
 */
for (i = 0; i < ARRAY_SIZE(formats) - 1; ++i) {
@@ -360,7 +363,8 @@ static void iss_video_buf_queue(struct vb2_buffer *vb)

spin_lock_irqsave(>qlock, flags);

-   /* Mark the buffer is faulty and give it back to the queue immediately
+   /*
+* Mark the buffer is faulty and give it back to the queue immediately
 * if the video node has registered an error. vb2 will perform the same
 * check when preparing the buffer, but that is inherently racy, so we
 * need to handle the race condition with an authoritative check here.
@@ -443,7 +447,8 @@ struct iss_buffer *omap4iss_video_buffer_next(struct 
iss_video *video)

buf->vb.vb2_buf.timestamp = ktime_get_ns();

-   /* Do frame number propagation only if this is the output video node.
+   /*
+* Do frame number propagation only if this is the output video node.
 * Frame number either comes from the CSI receivers or it gets
 * incremented here if H3A is not active.
 * Note: There is no guarantee that the output buffer will finish
@@ -605,7 +610,8 @@ iss_video_set_format(struct file *file, void *fh, struct 
v4l2_format *format)

mutex_lock(>mutex);

-   /* Fill the bytesperline and sizeimage fields by converting to media bus
+   /*
+* Fill the bytesperline and sizeimage fields by converting to media bus
 * format and back to pixel format.
 */
iss_video_pix_to_mbus(>fmt.pix, );
@@ -678,8 +684,9 @@ iss_video_get_selection(struct file *file, void *fh, struct 
v4l2_selection *sel)
if (subdev == NULL)
return -EINVAL;

-   /* Try the get selection operation first and fallback to get format if 
not
-* implemented.
+   /*
+* Try the get selection operation first and fallback to get format if
+* not implemented.
 */
sdsel.pad = pad;
ret = v4l2_subdev_call(subdev, pad, get_selection, NULL, );
@@ -867,7 +874,8 @@ iss_video_streamon(struct file *file, void *fh, enum 
v4l2_buf_type type)

mutex_lock(>stream_lock);

-   /* Start streaming on the pipeline. No link touching an entity in the
+   /*
+* Start streaming on the pipeline. No link touching an entity in the
 * pipeline can be activated or deactivated once streaming is started.
 */
pipe = entity->pipe
@@ -895,7 +903,8 @@ iss_video_streamon(struct file *file, void *fh, enum 
v4l2_buf_type type)
while ((entity = media_graph_walk_next()))
media_entity_enum_set(>ent_enum, entity);

-   /* Verify that the currently configured format matches the output of
+   /*
+* Verify that the currently configured format matches the output of
 * the connected subdev.
 */
ret = iss_video_check_format(video, vfh);
@@ -905,7 +914,8 @@ iss_video_streamon(struct file *file, void *fh, enum 
v4l2_buf_type type)
video->bpl_padding = ret;
video->bpl_value = vfh->format.fmt.pix.bytesperline;

-   /* Find the ISS video node connected at the far end of the pipeline and
+   /*
+* Find the ISS video node connected at the far end of the 

Re: [PATCH] staging: greybus: uart: fix uninitialized newline.flow_control

2017-02-09 Thread Johan Hovold
On Thu, Feb 09, 2017 at 01:01:18PM +, Colin King wrote:
> From: Colin Ian King 
> 
> Currently newline.flow_control is uninitialized, so it can contain
> any garbage from the stack.  I believe it should be initialized with
> GB_SERIAL_AUTO_RTSCTS_EN enabled if the termios c_cflag is CRTSCTS
> enabled.

Good catch. The CRTSCTS flag is actually honoured a bit further down in
the set_termios(), but there's a bug in that it assumes newline to have
been initialised with the current (old) values. It should
unconditionally set the flow_control field rather than manipulate bits
(we currently use one bit of this field).

Care to send a v2 fixing this up as suggested above?

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


[PATCH 1/2] staging: greybus: fix "line over 80 characters" coding style issues

2017-02-09 Thread Gioh Kim
This patch fixes only obvious lines.
There are still more issues.

Signed-off-by: Gioh Kim 
---
 drivers/staging/greybus/arche-apb-ctrl.c |  5 +++-
 drivers/staging/greybus/arche-platform.c | 43 +---
 drivers/staging/greybus/audio_codec.c|  5 +++-
 drivers/staging/greybus/bootrom.c| 13 ++
 drivers/staging/greybus/es2.c|  3 ++-
 drivers/staging/greybus/fw-download.c|  6 +++--
 drivers/staging/greybus/gbphy.c  |  3 ++-
 drivers/staging/greybus/gpio.c   |  3 ++-
 drivers/staging/greybus/svc.c| 26 +++
 drivers/staging/greybus/uart.c   |  8 +++---
 drivers/staging/greybus/vibrator.c   |  4 ++-
 11 files changed, 77 insertions(+), 42 deletions(-)

diff --git a/drivers/staging/greybus/arche-apb-ctrl.c 
b/drivers/staging/greybus/arche-apb-ctrl.c
index 17fa290..02243b4 100644
--- a/drivers/staging/greybus/arche-apb-ctrl.c
+++ b/drivers/staging/greybus/arche-apb-ctrl.c
@@ -168,7 +168,10 @@ static int standby_boot_seq(struct platform_device *pdev)
if (apb->init_disabled)
return 0;
 
-   /* Even if it is in OFF state, then we do not want to change the state 
*/
+   /*
+* Even if it is in OFF state,
+* then we do not want to change the state
+*/
if (apb->state == ARCHE_PLATFORM_STATE_STANDBY ||
apb->state == ARCHE_PLATFORM_STATE_OFF)
return 0;
diff --git a/drivers/staging/greybus/arche-platform.c 
b/drivers/staging/greybus/arche-platform.c
index 338c2d3..aac1145 100644
--- a/drivers/staging/greybus/arche-platform.c
+++ b/drivers/staging/greybus/arche-platform.c
@@ -312,9 +312,11 @@ static irqreturn_t arche_platform_wd_irq(int irq, void 
*devid)
if (arche_pdata->wake_detect_state == WD_STATE_IDLE) {
arche_pdata->wake_detect_start = jiffies;
/*
-* In the begining, when wake/detect goes low (first 
time), we assume
-* it is meant for coldboot and set the flag. If 
wake/detect line stays low
-* beyond 30msec, then it is coldboot else fallback to 
standby boot.
+* In the begining, when wake/detect goes low
+* (first time), we assume it is meant for coldboot
+* and set the flag. If wake/detect line stays low
+* beyond 30msec, then it is coldboot else fallback
+* to standby boot.
 */
arche_platform_set_wake_detect_state(arche_pdata,
 
WD_STATE_BOOT_INIT);
@@ -330,7 +332,8 @@ static irqreturn_t arche_platform_wd_irq(int irq, void 
*devid)
 /*
  * Requires arche_pdata->platform_state_mutex to be held
  */
-static int arche_platform_coldboot_seq(struct arche_platform_drvdata 
*arche_pdata)
+static int
+arche_platform_coldboot_seq(struct arche_platform_drvdata *arche_pdata)
 {
int ret;
 
@@ -364,7 +367,8 @@ static int arche_platform_coldboot_seq(struct 
arche_platform_drvdata *arche_pdat
 /*
  * Requires arche_pdata->platform_state_mutex to be held
  */
-static int arche_platform_fw_flashing_seq(struct arche_platform_drvdata 
*arche_pdata)
+static int
+arche_platform_fw_flashing_seq(struct arche_platform_drvdata *arche_pdata)
 {
int ret;
 
@@ -398,7 +402,8 @@ static int arche_platform_fw_flashing_seq(struct 
arche_platform_drvdata *arche_p
 /*
  * Requires arche_pdata->platform_state_mutex to be held
  */
-static void arche_platform_poweroff_seq(struct arche_platform_drvdata 
*arche_pdata)
+static void
+arche_platform_poweroff_seq(struct arche_platform_drvdata *arche_pdata)
 {
unsigned long flags;
 
@@ -561,14 +566,17 @@ static int arche_platform_probe(struct platform_device 
*pdev)
struct device_node *np = dev->of_node;
int ret;
 
-   arche_pdata = devm_kzalloc(>dev, sizeof(*arche_pdata), 
GFP_KERNEL);
+   arche_pdata = devm_kzalloc(>dev, sizeof(*arche_pdata),
+  GFP_KERNEL);
if (!arche_pdata)
return -ENOMEM;
 
/* setup svc reset gpio */
arche_pdata->is_reset_act_hi = of_property_read_bool(np,
"svc,reset-active-high");
-   arche_pdata->svc_reset_gpio = of_get_named_gpio(np, "svc,reset-gpio", 
0);
+   arche_pdata->svc_reset_gpio = of_get_named_gpio(np,
+   "svc,reset-gpio",
+   0);
if (arche_pdata->svc_reset_gpio < 0) {
dev_err(dev, "failed to get reset-gpio\n");
return arche_pdata->svc_reset_gpio;
@@ -610,7 +618,8 @@ static int arche_platform_probe(struct platform_device 
*pdev)
dev_err(dev, "failed to 

[PATCH 2/2] staging: greybus: fix symbolic permission coding style issues

2017-02-09 Thread Gioh Kim
Fix "Octal permissions are preffered than symbolic ones" issues.

Signed-off-by: Gioh Kim 
---
 drivers/staging/greybus/es2.c  | 4 ++--
 drivers/staging/greybus/loopback.c | 2 +-
 drivers/staging/greybus/svc.c  | 6 +++---
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/greybus/es2.c b/drivers/staging/greybus/es2.c
index 0eba059..f7b24e0 100644
--- a/drivers/staging/greybus/es2.c
+++ b/drivers/staging/greybus/es2.c
@@ -1152,7 +1152,7 @@ static void usb_log_enable(struct es2_ap_dev *es2)
if (IS_ERR(es2->apb_log_task))
return;
/* XXX We will need to rename this per APB */
-   es2->apb_log_dentry = debugfs_create_file("apb_log", S_IRUGO,
+   es2->apb_log_dentry = debugfs_create_file("apb_log", 0444,
gb_debugfs_get(), es2,
_log_fops);
 }
@@ -1409,7 +1409,7 @@ static int ap_probe(struct usb_interface *interface,
 
/* XXX We will need to rename this per APB */
es2->apb_log_enable_dentry = debugfs_create_file("apb_log_enable",
-   (S_IWUSR | S_IRUGO),
+   0644,
gb_debugfs_get(), es2,
_log_enable_fops);
 
diff --git a/drivers/staging/greybus/loopback.c 
b/drivers/staging/greybus/loopback.c
index 6c2a41c..f0ceee6 100644
--- a/drivers/staging/greybus/loopback.c
+++ b/drivers/staging/greybus/loopback.c
@@ -1209,7 +1209,7 @@ static int gb_loopback_probe(struct gb_bundle *bundle,
/* Create per-connection sysfs and debugfs data-points */
snprintf(name, sizeof(name), "raw_latency_%s",
 dev_name(>bundle->dev));
-   gb->file = debugfs_create_file(name, S_IFREG | S_IRUGO, gb_dev.root, gb,
+   gb->file = debugfs_create_file(name, S_IFREG | 0444, gb_dev.root, gb,
   _loopback_debugfs_latency_ops);
 
gb->id = ida_simple_get(_ida, 0, 0, GFP_KERNEL);
diff --git a/drivers/staging/greybus/svc.c b/drivers/staging/greybus/svc.c
index 5549db2..516f827 100644
--- a/drivers/staging/greybus/svc.c
+++ b/drivers/staging/greybus/svc.c
@@ -803,11 +803,11 @@ static void gb_svc_pwrmon_debugfs_init(struct gb_svc *svc)
rail->svc = svc;
 
dir = debugfs_create_dir(fname, dent);
-   debugfs_create_file("voltage_now", S_IRUGO, dir, rail,
+   debugfs_create_file("voltage_now", 0444, dir, rail,
_debugfs_voltage_fops);
-   debugfs_create_file("current_now", S_IRUGO, dir, rail,
+   debugfs_create_file("current_now", 0444, dir, rail,
_debugfs_current_fops);
-   debugfs_create_file("power_now", S_IRUGO, dir, rail,
+   debugfs_create_file("power_now", 0444, dir, rail,
_debugfs_power_fops);
}
 
-- 
2.5.0

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


[PATCH] staging: rtl8192u: Fix braces {} style

2017-02-09 Thread simran singhal
This fixes all checkpatch form of this from the Lustre tree: CHECK:
braces {} should be used on all arms of this statement

Signed-off-by: simran singhal 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c
index eaeb9dc..b9377f3 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c
@@ -380,10 +380,11 @@ static int ieee80211_ccmp_set_key(void *key, int len, u8 
*seq, void *priv)
data->rx_pn[5] = seq[0];
}
crypto_cipher_setkey((void *)data->tfm, data->key, CCMP_TK_LEN);
-   } else if (len == 0)
+   } else if (len == 0) {
data->key_set = 0;
-   else
+   } else {
return -1;
+   }
 
return 0;
 }
-- 
2.7.4

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


RE: [PATCH 1/1] Ddrivers: hv: Turn off write permission on the hypercall page

2017-02-09 Thread KY Srinivasan


> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Wednesday, February 8, 2017 10:55 PM
> To: KY Srinivasan 
> Cc: linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
> o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com;
> jasow...@redhat.com; leann.ogasaw...@canonical.com;
> keesc...@google.com; step...@networkplumber.org; s...@tycho.nsa.gov;
> sta...@vger.kernel.org
> Subject: Re: [PATCH 1/1] Ddrivers: hv: Turn off write permission on the
> hypercall page
> 
> On Wed, Feb 08, 2017 at 06:30:56PM -0700, k...@exchange.microsoft.com
> wrote:
> > From: K. Y. Srinivasan 
> >
> > The hypercall page only needs to be executable but currently it is setup to
> > be writable as well. Fix the issue.
> >
> > Signed-off-by: K. Y. Srinivasan 
> > Cc: 
> 
> What type of bug is this fixing that it is needed to be backported?
> Does this affect any current users?  How far back should it go?

This issue has been there from day 1 and the mapping was setup after the
scan was done (for questionable mappings) and so we did not see it. Now, we
are setting up the hypercall page much earlier in the boot sequence and so
this issue was noticed. Once this is committed, I will send the patch for 
stable.
The main issue is that the page can be written and is executable and could be 
a vulnerability.

Thanks,

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


[PATCH 1/3 v2 staging-next] android: Collect statistics from lowmemorykiller

2017-02-09 Thread peter enderborg
This collects stats for shrinker calls and how much
waste work we do within the lowmemorykiller.

Signed-off-by: Peter Enderborg 
---
 drivers/staging/android/Kconfig | 11 
 drivers/staging/android/Makefile|  1 +
 drivers/staging/android/lowmemorykiller.c   |  9 ++-
 drivers/staging/android/lowmemorykiller_stats.c | 85 +
 drivers/staging/android/lowmemorykiller_stats.h | 29 +
 5 files changed, 134 insertions(+), 1 deletion(-)
 create mode 100644 drivers/staging/android/lowmemorykiller_stats.c
 create mode 100644 drivers/staging/android/lowmemorykiller_stats.h

diff --git a/drivers/staging/android/Kconfig b/drivers/staging/android/Kconfig
index 6c00d6f..96e86c7 100644
--- a/drivers/staging/android/Kconfig
+++ b/drivers/staging/android/Kconfig
@@ -24,6 +24,17 @@ config ANDROID_LOW_MEMORY_KILLER
   scripts (/init.rc), and it defines priority values with minimum free 
memory size
   for each priority.
 
+config ANDROID_LOW_MEMORY_KILLER_STATS
+bool "Android Low Memory Killer: collect statistics"
+depends on ANDROID_LOW_MEMORY_KILLER
+default n
+help
+  Create a file in /proc/lmkstats that includes
+  collected statistics about kills, scans and counts
+  and  interaction with the shrinker. Its content
+  will be different depeding on lmk implementation used.
+
+
 source "drivers/staging/android/ion/Kconfig"
 
 endif # if ANDROID
diff --git a/drivers/staging/android/Makefile b/drivers/staging/android/Makefile
index 7ed1be7..d710eb2 100644
--- a/drivers/staging/android/Makefile
+++ b/drivers/staging/android/Makefile
@@ -4,3 +4,4 @@ obj-y+= ion/
 
 obj-$(CONFIG_ASHMEM)+= ashmem.o
 obj-$(CONFIG_ANDROID_LOW_MEMORY_KILLER)+= lowmemorykiller.o
+obj-$(CONFIG_ANDROID_LOW_MEMORY_KILLER_STATS)+= lowmemorykiller_stats.o
diff --git a/drivers/staging/android/lowmemorykiller.c 
b/drivers/staging/android/lowmemorykiller.c
index ec3b665..15c1b38 100644
--- a/drivers/staging/android/lowmemorykiller.c
+++ b/drivers/staging/android/lowmemorykiller.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include "lowmemorykiller_stats.h"
 
 static u32 lowmem_debug_level = 1;
 static short lowmem_adj[6] = {
@@ -72,6 +73,7 @@ static unsigned long lowmem_deathpending_timeout;
 static unsigned long lowmem_count(struct shrinker *s,
   struct shrink_control *sc)
 {
+lmk_inc_stats(LMK_COUNT);
 return global_node_page_state(NR_ACTIVE_ANON) +
 global_node_page_state(NR_ACTIVE_FILE) +
 global_node_page_state(NR_INACTIVE_ANON) +
@@ -95,6 +97,7 @@ static unsigned long lowmem_scan(struct shrinker *s, struct 
shrink_control *sc)
 global_node_page_state(NR_SHMEM) -
 total_swapcache_pages();
 
+lmk_inc_stats(LMK_SCAN);
 if (lowmem_adj_size < array_size)
 array_size = lowmem_adj_size;
 if (lowmem_minfree_size < array_size)
@@ -134,6 +137,7 @@ static unsigned long lowmem_scan(struct shrinker *s, struct 
shrink_control *sc)
 if (task_lmk_waiting(p) &&
 time_before_eq(jiffies, lowmem_deathpending_timeout)) {
 task_unlock(p);
+lmk_inc_stats(LMK_TIMEOUT);
 rcu_read_unlock();
 return 0;
 }
@@ -179,7 +183,9 @@ static unsigned long lowmem_scan(struct shrinker *s, struct 
shrink_control *sc)
  other_free * (long)(PAGE_SIZE / 1024));
 lowmem_deathpending_timeout = jiffies + HZ;
 rem += selected_tasksize;
-}
+lmk_inc_stats(LMK_KILL);
+} else
+lmk_inc_stats(LMK_WASTE);
 
 lowmem_print(4, "lowmem_scan %lu, %x, return %lu\n",
  sc->nr_to_scan, sc->gfp_mask, rem);
@@ -196,6 +202,7 @@ static struct shrinker lowmem_shrinker = {
 static int __init lowmem_init(void)
 {
 register_shrinker(_shrinker);
+init_procfs_lmk();
 return 0;
 }
 device_initcall(lowmem_init);
diff --git a/drivers/staging/android/lowmemorykiller_stats.c 
b/drivers/staging/android/lowmemorykiller_stats.c
new file mode 100644
index 000..673691c
--- /dev/null
+++ b/drivers/staging/android/lowmemorykiller_stats.c
@@ -0,0 +1,85 @@
+/*
+ *  lowmemorykiller_stats
+ *
+ *  Copyright (C) 2017 Sony Mobile Communications Inc.
+ *
+ *  Author: Peter Enderborg 
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+/* This code is bookkeeping of statistical information
+ * from lowmemorykiller and provide a node in proc "/proc/lmkstats".
+ */
+
+#include 
+#include 
+#include "lowmemorykiller_stats.h"
+
+struct lmk_stats {
+atomic_long_t scans; /* counter as in shrinker scans */
+atomic_long_t kills; /* the number of sigkills sent */
+atomic_long_t waste; /* the numer of extensive calls that 

[PATCH 1/1] staging: comedi: dyna_pci10xx: usleep_range is preferred over udelay

2017-02-09 Thread Saber Rezvani
Fix the checkpatch.pl issue:
CHECK: usleep_range is preferred over udelay

Signed-off-by: Saber Rezvani 
---
 drivers/staging/comedi/drivers/dyna_pci10xx.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/comedi/drivers/dyna_pci10xx.c 
b/drivers/staging/comedi/drivers/dyna_pci10xx.c
index c9eb26f..febdc88 100644
--- a/drivers/staging/comedi/drivers/dyna_pci10xx.c
+++ b/drivers/staging/comedi/drivers/dyna_pci10xx.c
@@ -89,7 +89,7 @@ static int dyna_pci10xx_insn_read_ai(struct comedi_device 
*dev,
/* trigger conversion */
smp_mb();
outw_p(0x + range + chan, dev->iobase + 2);
-   udelay(10);
+   usleep_range(10, 100);
 
ret = comedi_timeout(dev, s, insn, dyna_pci10xx_ai_eoc, 0);
if (ret)
@@ -125,7 +125,7 @@ static int dyna_pci10xx_insn_write_ao(struct comedi_device 
*dev,
smp_mb();
/* trigger conversion and write data */
outw_p(data[n], dev->iobase);
-   udelay(10);
+   usleep_range(10, 100);
}
mutex_unlock(>mutex);
return n;
@@ -143,7 +143,7 @@ static int dyna_pci10xx_di_insn_bits(struct comedi_device 
*dev,
mutex_lock(>mutex);
smp_mb();
d = inw_p(devpriv->BADR3);
-   udelay(10);
+   usleep_range(10, 100);
 
/* on return the data[0] contains output and data[1] contains input */
data[1] = d;
@@ -163,7 +163,7 @@ static int dyna_pci10xx_do_insn_bits(struct comedi_device 
*dev,
if (comedi_dio_update_state(s, data)) {
smp_mb();
outw_p(s->state, devpriv->BADR3);
-   udelay(10);
+   usleep_range(10, 100);
}
 
data[1] = s->state;
-- 
2.7.4


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


[PATCH] staging: nvec: Fix coding style

2017-02-09 Thread Youngdo, Lee
Removed unnecessary white spaces found via checkpatch.pl:
WARNING: Statements should start on a tabstop

Signed-off-by: Youngdo, Lee 
---
 drivers/staging/nvec/nvec_power.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/nvec/nvec_power.c 
b/drivers/staging/nvec/nvec_power.c
index fcbb0fa..688b805 100644
--- a/drivers/staging/nvec/nvec_power.c
+++ b/drivers/staging/nvec/nvec_power.c
@@ -441,8 +441,8 @@ static int nvec_power_remove(struct platform_device *pdev)
.probe = nvec_power_probe,
.remove = nvec_power_remove,
.driver = {
-  .name = "nvec-power",
-  }
+   .name = "nvec-power",
+   }
 };
 
 module_platform_driver(nvec_power_driver);
-- 
1.9.1

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


[PATCH 1/1] staging: comedi: dt2815: usleep_range is preferred over udelay

2017-02-09 Thread Saber Rezvani
Fix the checkpatch.pl issue:
CHECK: usleep_range is preferred over udelay

Signed-off-by: Saber Rezvani 
---
 drivers/staging/comedi/drivers/dt2815.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/drivers/dt2815.c 
b/drivers/staging/comedi/drivers/dt2815.c
index 0be77cc..ce55719 100644
--- a/drivers/staging/comedi/drivers/dt2815.c
+++ b/drivers/staging/comedi/drivers/dt2815.c
@@ -188,7 +188,7 @@ static int dt2815_attach(struct comedi_device *dev, struct 
comedi_devconfig *it)
/* This is incredibly slow (approx 20 ms) */
unsigned int status;
 
-   udelay(1000);
+   usleep_range(1000, 3000);
status = inb(dev->iobase + DT2815_STATUS);
if (status == 4) {
unsigned int program;
-- 
2.7.4


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


[PATCH] staging: rtl8192u: Clean up comparison to NULL

2017-02-09 Thread simran singhal
Checkpatch recommended changes.

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

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c
index 21abb2d..eaeb9dc 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c
@@ -67,7 +67,7 @@ static void *ieee80211_ccmp_init(int key_idx)
struct ieee80211_ccmp_data *priv;
 
priv = kzalloc(sizeof(*priv), GFP_ATOMIC);
-   if (priv == NULL)
+   if (!priv)
goto fail;
priv->key_idx = key_idx;
 
-- 
2.7.4

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


[PATCH] staging:vt6656:channel.h: fix function definition argument without identifier name issue

2017-02-09 Thread Arushi Singhal
Function definitions arguments should also have an identifier name as
reported by checkpatch.pl.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/vt6656/channel.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vt6656/channel.h b/drivers/staging/vt6656/channel.h
index fcea6995fe26..62f18a959098 100644
--- a/drivers/staging/vt6656/channel.h
+++ b/drivers/staging/vt6656/channel.h
@@ -28,6 +28,6 @@
 
 #include "device.h"
 
-void vnt_init_bands(struct vnt_private *);
+void vnt_init_bands(struct vnt_private *priv);
 
 #endif  /* _CHANNEL_H_ */
-- 
2.11.0

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


[PATCH 1/1] staging: comedi: dt2814: usleep_range is preferred over udelay

2017-02-09 Thread Saber Rezvani
Fix the checkpatch.pl issue:
CHECK: usleep_range is preferred over udelay

Signed-off-by: Saber Rezvani 
---
 drivers/staging/comedi/drivers/dt2814.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/drivers/dt2814.c 
b/drivers/staging/comedi/drivers/dt2814.c
index 2f903be..09984a6 100644
--- a/drivers/staging/comedi/drivers/dt2814.c
+++ b/drivers/staging/comedi/drivers/dt2814.c
@@ -245,7 +245,7 @@ static int dt2814_attach(struct comedi_device *dev, struct 
comedi_devconfig *it)
return ret;
 
outb(0, dev->iobase + DT2814_CSR);
-   udelay(100);
+   usleep_range(100, 200);
if (inb(dev->iobase + DT2814_CSR) & DT2814_ERR) {
dev_err(dev->class_dev, "reset error (fatal)\n");
return -EIO;
-- 
2.7.4


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


[PATCH] staging: fsl-mc: update MAINTAINERS

2017-02-09 Thread Stuart Yoder
Add Laurentiu Tudor as a second maintainer and update Stuart Yoder's
email address.

Signed-off-by: Stuart Yoder 
---
 MAINTAINERS | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index c2395ea..6050912 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10177,7 +10177,8 @@ F:  include/uapi/linux/qnx4_fs.h
 F: include/uapi/linux/qnxtypes.h
 
 QORIQ DPAA2 FSL-MC BUS DRIVER
-M: Stuart Yoder 
+M: Stuart Yoder 
+M: Laurentiu Tudor 
 L: linux-ker...@vger.kernel.org
 S: Maintained
 F: drivers/staging/fsl-mc/
-- 
1.9.0

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


[PATCH 1/1] staging: comedi: dt2801: usleep_range is preferred over udelay

2017-02-09 Thread Saber Rezvani
Fix the checkpatch.pl issue:
CHECK: usleep_range is preferred over udelay

Signed-off-by: Saber Rezvani 
---
 drivers/staging/comedi/drivers/dt2801.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/comedi/drivers/dt2801.c 
b/drivers/staging/comedi/drivers/dt2801.c
index c2ce1eb..3080579 100644
--- a/drivers/staging/comedi/drivers/dt2801.c
+++ b/drivers/staging/comedi/drivers/dt2801.c
@@ -343,7 +343,7 @@ static int dt2801_reset(struct comedi_device *dev)
outb_p(DT_C_STOP, dev->iobase + DT2801_CMD);
 
/* dt2801_wait_for_ready(dev); */
-   udelay(100);
+   usleep_range(100, 200);
timeout = 1;
do {
stat = inb_p(dev->iobase + DT2801_STATUS);
@@ -358,7 +358,7 @@ static int dt2801_reset(struct comedi_device *dev)
outb_p(DT_C_RESET, dev->iobase + DT2801_CMD);
/* dt2801_writecmd(dev,DT_C_RESET); */
 
-   udelay(100);
+   usleep_range(100, 200);
timeout = 1;
do {
stat = inb_p(dev->iobase + DT2801_STATUS);
-- 
2.7.4


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


[PATCH 2/2] x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read method

2017-02-09 Thread Vitaly Kuznetsov
Hyper-V TSC page clocksource is suitable for vDSO, however, the protocol
defined by the hypervisor is different from VCLOCK_PVCLOCK. Implement the
required support by adding hvclock_page VVAR.

Signed-off-by: Vitaly Kuznetsov 
---
 arch/x86/entry/vdso/vclock_gettime.c  | 36 +++
 arch/x86/entry/vdso/vdso-layout.lds.S |  3 ++-
 arch/x86/entry/vdso/vdso2c.c  |  3 +++
 arch/x86/entry/vdso/vma.c |  7 +++
 arch/x86/hyperv/hv_init.c |  3 +++
 arch/x86/include/asm/clocksource.h|  3 ++-
 arch/x86/include/asm/vdso.h   |  1 +
 7 files changed, 54 insertions(+), 2 deletions(-)

diff --git a/arch/x86/entry/vdso/vclock_gettime.c 
b/arch/x86/entry/vdso/vclock_gettime.c
index 9d4d6e1..4af10b4 100644
--- a/arch/x86/entry/vdso/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vclock_gettime.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -32,6 +33,11 @@ extern u8 pvclock_page
__attribute__((visibility("hidden")));
 #endif
 
+#ifdef CONFIG_HYPERV_TSCPAGE
+extern u8 hvclock_page
+   __attribute__((visibility("hidden")));
+#endif
+
 #ifndef BUILD_VDSO32
 
 notrace static long vdso_fallback_gettime(long clock, struct timespec *ts)
@@ -141,6 +147,32 @@ static notrace u64 vread_pvclock(int *mode)
return last;
 }
 #endif
+#ifdef CONFIG_HYPERV_TSCPAGE
+static notrace u64 vread_hvclock(int *mode)
+{
+   const struct ms_hyperv_tsc_page *tsc_pg =
+   (const struct ms_hyperv_tsc_page *)_page;
+   u64 sequence, scale, offset, current_tick, cur_tsc;
+
+   while (1) {
+   sequence = READ_ONCE(tsc_pg->tsc_sequence);
+   if (!sequence)
+   break;
+
+   scale = READ_ONCE(tsc_pg->tsc_scale);
+   offset = READ_ONCE(tsc_pg->tsc_offset);
+   rdtscll(cur_tsc);
+
+   current_tick = mul_u64_u64_shr(cur_tsc, scale, 64) + offset;
+
+   if (READ_ONCE(tsc_pg->tsc_sequence) == sequence)
+   return current_tick;
+   }
+
+   *mode = VCLOCK_NONE;
+   return 0;
+}
+#endif
 
 notrace static u64 vread_tsc(void)
 {
@@ -173,6 +205,10 @@ notrace static inline u64 vgetsns(int *mode)
else if (gtod->vclock_mode == VCLOCK_PVCLOCK)
cycles = vread_pvclock(mode);
 #endif
+#ifdef CONFIG_HYPERV_TSCPAGE
+   else if (gtod->vclock_mode == VCLOCK_HVCLOCK)
+   cycles = vread_hvclock(mode);
+#endif
else
return 0;
v = (cycles - gtod->cycle_last) & gtod->mask;
diff --git a/arch/x86/entry/vdso/vdso-layout.lds.S 
b/arch/x86/entry/vdso/vdso-layout.lds.S
index a708aa9..8ebb4b6 100644
--- a/arch/x86/entry/vdso/vdso-layout.lds.S
+++ b/arch/x86/entry/vdso/vdso-layout.lds.S
@@ -25,7 +25,7 @@ SECTIONS
 * segment.
 */
 
-   vvar_start = . - 2 * PAGE_SIZE;
+   vvar_start = . - 3 * PAGE_SIZE;
vvar_page = vvar_start;
 
/* Place all vvars at the offsets in asm/vvar.h. */
@@ -36,6 +36,7 @@ SECTIONS
 #undef EMIT_VVAR
 
pvclock_page = vvar_start + PAGE_SIZE;
+   hvclock_page = vvar_start + 2 * PAGE_SIZE;
 
. = SIZEOF_HEADERS;
 
diff --git a/arch/x86/entry/vdso/vdso2c.c b/arch/x86/entry/vdso/vdso2c.c
index 491020b..0780a44 100644
--- a/arch/x86/entry/vdso/vdso2c.c
+++ b/arch/x86/entry/vdso/vdso2c.c
@@ -74,6 +74,7 @@ enum {
sym_vvar_page,
sym_hpet_page,
sym_pvclock_page,
+   sym_hvclock_page,
sym_VDSO_FAKE_SECTION_TABLE_START,
sym_VDSO_FAKE_SECTION_TABLE_END,
 };
@@ -82,6 +83,7 @@ const int special_pages[] = {
sym_vvar_page,
sym_hpet_page,
sym_pvclock_page,
+   sym_hvclock_page,
 };
 
 struct vdso_sym {
@@ -94,6 +96,7 @@ struct vdso_sym required_syms[] = {
[sym_vvar_page] = {"vvar_page", true},
[sym_hpet_page] = {"hpet_page", true},
[sym_pvclock_page] = {"pvclock_page", true},
+   [sym_hvclock_page] = {"hvclock_page", true},
[sym_VDSO_FAKE_SECTION_TABLE_START] = {
"VDSO_FAKE_SECTION_TABLE_START", false
},
diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
index 10820f6..b256a3b 100644
--- a/arch/x86/entry/vdso/vma.c
+++ b/arch/x86/entry/vdso/vma.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #if defined(CONFIG_X86_64)
 unsigned int __read_mostly vdso64_enabled = 1;
@@ -120,6 +121,12 @@ static int vvar_fault(const struct vm_special_mapping *sm,
vmf->address,
__pa(pvti) >> PAGE_SHIFT);
}
+   } else if (sym_offset == image->sym_hvclock_page) {
+   struct ms_hyperv_tsc_page *tsc_pg = hv_get_tsc_page();
+
+   if (tsc_pg && vclock_was_used(VCLOCK_HVCLOCK))
+   ret = vm_insert_pfn(vma, vmf->address,
+   

[PATCH 1/2] hyperv: implement hv_get_tsc_page()

2017-02-09 Thread Vitaly Kuznetsov
To use Hyper-V TSC page clocksource from vDSO we need to make tsc_pg
available. Implement hv_get_tsc_page() and add CONFIG_HYPERV_TSCPAGE to
make #ifdef-s simple.

Signed-off-by: Vitaly Kuznetsov 
---
 arch/x86/hyperv/hv_init.c   | 9 +++--
 arch/x86/include/asm/mshyperv.h | 8 
 drivers/hv/Kconfig  | 3 +++
 3 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index b371d0e..0ce8485 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -27,10 +27,15 @@
 #include 
 
 
-#ifdef CONFIG_X86_64
+#ifdef CONFIG_HYPERV_TSCPAGE
 
 static struct ms_hyperv_tsc_page *tsc_pg;
 
+struct ms_hyperv_tsc_page *hv_get_tsc_page(void)
+{
+   return tsc_pg;
+}
+
 static u64 read_hv_clock_tsc(struct clocksource *arg)
 {
u64 current_tick;
@@ -136,7 +141,7 @@ void hyperv_init(void)
/*
 * Register Hyper-V specific clocksource.
 */
-#ifdef CONFIG_X86_64
+#ifdef CONFIG_HYPERV_TSCPAGE
if (ms_hyperv.features & HV_X64_MSR_REFERENCE_TSC_AVAILABLE) {
union hv_x64_msr_hypercall_contents tsc_msr;
 
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index f8dc370..14dd92c 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -173,4 +173,12 @@ void hyperv_report_panic(struct pt_regs *regs);
 bool hv_is_hypercall_page_setup(void);
 void hyperv_cleanup(void);
 #endif
+#ifdef CONFIG_HYPERV_TSCPAGE
+struct ms_hyperv_tsc_page *hv_get_tsc_page(void);
+#else
+static inline struct ms_hyperv_tsc_page *hv_get_tsc_page(void)
+{
+   return NULL;
+}
+#endif
 #endif
diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index 0403b51..c29cd53 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -7,6 +7,9 @@ config HYPERV
  Select this option to run Linux as a Hyper-V client operating
  system.
 
+config HYPERV_TSCPAGE
+   def_bool HYPERV && X86_64
+
 config HYPERV_UTILS
tristate "Microsoft Hyper-V Utilities driver"
depends on HYPERV && CONNECTOR && NLS
-- 
2.9.3

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


[PATCH 0/2] x86/vdso: Add Hyper-V TSC page clocksource support

2017-02-09 Thread Vitaly Kuznetsov
Hi,

Hyper-V TSC page clocksource is suitable for vDSO, however, the protocol
defined by the hypervisor is different from VCLOCK_PVCLOCK. Implemented the
required support. Simple sysbench test shows the following results:

Before:
# time sysbench --test=memory --max-requests=50 run
...
real1m22.618s
user0m50.193s
sys 0m32.268s

After:
# time sysbench --test=memory --max-requests=50 run
...
real0m47.241s
user0m47.117s
sys 0m0.008s

So it seems it is worth it. As nobody seems to be strongly offended by my RFC
I'm sending first non-RFC version. Patch 1 is made on top of K. Y.'s code
refactoring which moved tsc page clocksource to arch/x86/hyperv/hv_init.c,
this is currently present in Greg's char-misc-next tree.

Changes since RFC:
- Use mul_u64_u64_shr() instead of an open coded implementation
  [Andy Lutomirski, Thomas Gleixner]
- Don't use the same pvclock_page for both VCLOCK_PVCLOCK and
  VCLOCK_HVCLOCK, create another one [Andy Lutomirski]
- Fix issues reported by kbuild test robot.
- Rename HYPERV_CLOCK -> HYPERV_TSCPAGE to avoid the ambiguity.

I'm also going to try to optimize mul_u64_u64_shr() for 32bit but this can
be split from this series I guess.

Vitaly Kuznetsov (2):
  hyperv: implement hv_get_tsc_page()
  x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read method

 arch/x86/entry/vdso/vclock_gettime.c  | 36 +++
 arch/x86/entry/vdso/vdso-layout.lds.S |  3 ++-
 arch/x86/entry/vdso/vdso2c.c  |  3 +++
 arch/x86/entry/vdso/vma.c |  7 +++
 arch/x86/hyperv/hv_init.c | 12 ++--
 arch/x86/include/asm/clocksource.h|  3 ++-
 arch/x86/include/asm/mshyperv.h   |  8 
 arch/x86/include/asm/vdso.h   |  1 +
 drivers/hv/Kconfig|  3 +++
 9 files changed, 72 insertions(+), 4 deletions(-)

-- 
2.9.3

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


Re: [PATCH 1/3 staging-next] android: Collect statistics from lowmemorykiller

2017-02-09 Thread Greg Kroah-Hartman
On Thu, Feb 09, 2017 at 02:21:45PM +0100, peter enderborg wrote:
> This collects stats for shrinker calls and how much
> waste work we do within the lowmemorykiller.
> 
> Signed-off-by: Peter Enderborg 
> ---
>  drivers/staging/android/Kconfig | 11 
>  drivers/staging/android/Makefile|  1 +
>  drivers/staging/android/lowmemorykiller.c   |  9 ++-
>  drivers/staging/android/lowmemorykiller_stats.c | 85 
> +
>  drivers/staging/android/lowmemorykiller_stats.h | 29 +
>  5 files changed, 134 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/staging/android/lowmemorykiller_stats.c
>  create mode 100644 drivers/staging/android/lowmemorykiller_stats.h
> 
> diff --git a/drivers/staging/android/Kconfig b/drivers/staging/android/Kconfig
> index 6c00d6f..96e86c7 100644
> --- a/drivers/staging/android/Kconfig
> +++ b/drivers/staging/android/Kconfig
> @@ -24,6 +24,17 @@ config ANDROID_LOW_MEMORY_KILLER
>scripts (/init.rc), and it defines priority values with minimum free 
> memory size
>for each priority.
> 
> +config ANDROID_LOW_MEMORY_KILLER_STATS
> +bool "Android Low Memory Killer: collect statistics"
> +depends on ANDROID_LOW_MEMORY_KILLER
> +default n
> +help
> +  Create a file in /proc/lmkstats that includes
> +  collected statistics about kills, scans and counts
> +  and  interaction with the shrinker. Its content
> +  will be different depeding on lmk implementation used.
> +
> +
>  source "drivers/staging/android/ion/Kconfig"
> 
>  endif # if ANDROID
> diff --git a/drivers/staging/android/Makefile 
> b/drivers/staging/android/Makefile
> index 7ed1be7..d710eb2 100644
> --- a/drivers/staging/android/Makefile
> +++ b/drivers/staging/android/Makefile
> @@ -4,3 +4,4 @@ obj-y+= ion/
> 
>  obj-$(CONFIG_ASHMEM)+= ashmem.o
>  obj-$(CONFIG_ANDROID_LOW_MEMORY_KILLER)+= lowmemorykiller.o
> +obj-$(CONFIG_ANDROID_LOW_MEMORY_KILLER_STATS)+= lowmemorykiller_stats.o
> diff --git a/drivers/staging/android/lowmemorykiller.c 
> b/drivers/staging/android/lowmemorykiller.c
> index ec3b665..15c1b38 100644
> --- a/drivers/staging/android/lowmemorykiller.c
> +++ b/drivers/staging/android/lowmemorykiller.c
> @@ -42,6 +42,7 @@
>  #include 
>  #include 
>  #include 
> +#include "lowmemorykiller_stats.h"
> 
>  static u32 lowmem_debug_level = 1;
>  static short lowmem_adj[6] = {
> @@ -72,6 +73,7 @@ static unsigned long lowmem_deathpending_timeout;
>  static unsigned long lowmem_count(struct shrinker *s,
>struct shrink_control *sc)
>  {
> +lmk_inc_stats(LMK_COUNT);
>  return global_node_page_state(NR_ACTIVE_ANON) +
>  global_node_page_state(NR_ACTIVE_FILE) +
>  global_node_page_state(NR_INACTIVE_ANON) +

Your patch is corrupted and can not be applied :(

all of them are like this.

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


[PATCH] staging: wilc1000: remove unnecessary local array

2017-02-09 Thread Franck Demathieu
It fixes the following warning reported by sparse:

  drivers/staging/wilc1000/linux_wlan.c:67:33: warning: too long 
initializer-string for array of char(no space for nul char)

Signed-off-by: Franck Demathieu 
---
 drivers/staging/wilc1000/linux_wlan.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/wilc1000/linux_wlan.c 
b/drivers/staging/wilc1000/linux_wlan.c
index 2eebc62..fc61f4e 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -64,7 +64,6 @@ static int dev_state_ev_handler(struct notifier_block *this,
u8 *ip_addr_buf;
struct wilc_vif *vif;
u8 null_ip[4] = {0};
-   char wlan_dev_name[5] = "wlan0";
 
if (!dev_iface || !dev_iface->ifa_dev || !dev_iface->ifa_dev->dev)
return NOTIFY_DONE;
@@ -113,7 +112,7 @@ static int dev_state_ev_handler(struct notifier_block *this,
wilc_optaining_ip = false;
}
 
-   if (memcmp(dev_iface->ifa_label, wlan_dev_name, 5) == 0)
+   if (memcmp(dev_iface->ifa_label, "wlan0", 5) == 0)
wilc_set_power_mgmt(vif, 0, 0);
 
wilc_resolve_disconnect_aberration(vif);
-- 
2.10.1

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


[PATCH] staging: rtl8192u: Fixing multiple assignments

2017-02-09 Thread simran singhal
This patch modifies the assignments into single assignments.

Signed-off-by: simran singhal 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c
index c4abfd1..21abb2d 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c
@@ -181,7 +181,8 @@ static void ccmp_init_blocks(struct crypto_tfm *tfm,
xor_block(auth, [AES_BLOCK_LEN], AES_BLOCK_LEN);
ieee80211_ccmp_aes_encrypt(tfm, auth, auth);
b0[0] &= 0x07;
-   b0[14] = b0[15] = 0;
+   b0[14] = 0;
+   b0[15] = 0;
ieee80211_ccmp_aes_encrypt(tfm, b0, s0);
 }
 
-- 
2.7.4

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


[PATCH 3/3 staging-next] mm: Remove RCU and tasklocks from lmk

2017-02-09 Thread peter enderborg

Fundamental changes:
1 Does NOT take any RCU lock in shrinker functions.
2 It returns same result for scan and counts, so  we dont need to do
  shinker will know when it is pointless to call scan.
3 It does not lock any other process than the one that is
  going to be killed.

Background.
The low memory killer scans for process that can be killed to free
memory. This can be cpu consuming when there is a high demand for
memory. This can be seen by analysing the kswapd0 task work.
The stats function added in earler patch adds a counter for waste work.

How it works.
This patch create a structure within the lowmemory killer that caches
the user spaces processes that it might kill. It is done with a
sorted rbtree so we can very easy find the candidate to be killed,
and knows its properies as memory usage and sorted by oom_score_adj
to look up the task with highest oom_score_adj. To be able to achive
this it uses oom_score_notify events.

This patch also as a other effect, we are now free to do other
lowmemorykiller configurations.  Without the patch there is a need
for a tradeoff between freed memory and task and rcu locks. This
is no longer a concern for tuning lmk. This patch is not intended
to do any calculation changes other than we do use the cache for
calculate the count values and that makes kswapd0 to shrink other
areas.

Signed-off-by: Peter Enderborg 
---
 drivers/staging/android/Kconfig |   1 +
 drivers/staging/android/Makefile|   1 +
 drivers/staging/android/lowmemorykiller.c   | 294 +++-
 drivers/staging/android/lowmemorykiller.h   |  15 ++
 drivers/staging/android/lowmemorykiller_stats.c |  24 ++
 drivers/staging/android/lowmemorykiller_stats.h |  14 +-
 drivers/staging/android/lowmemorykiller_tasks.c | 220 ++
 drivers/staging/android/lowmemorykiller_tasks.h |  35 +++
 8 files changed, 498 insertions(+), 106 deletions(-)
 create mode 100644 drivers/staging/android/lowmemorykiller.h
 create mode 100644 drivers/staging/android/lowmemorykiller_tasks.c
 create mode 100644 drivers/staging/android/lowmemorykiller_tasks.h

diff --git a/drivers/staging/android/Kconfig b/drivers/staging/android/Kconfig
index 96e86c7..899186c 100644
--- a/drivers/staging/android/Kconfig
+++ b/drivers/staging/android/Kconfig
@@ -16,6 +16,7 @@ config ASHMEM

 config ANDROID_LOW_MEMORY_KILLER
 bool "Android Low Memory Killer"
+select OOM_SCORE_NOTIFIER
 ---help---
   Registers processes to be killed when low memory conditions, this is 
useful
   as there is no particular swap space on android.
diff --git a/drivers/staging/android/Makefile b/drivers/staging/android/Makefile
index d710eb2..b7a8036 100644
--- a/drivers/staging/android/Makefile
+++ b/drivers/staging/android/Makefile
@@ -4,4 +4,5 @@ obj-y+= ion/

 obj-$(CONFIG_ASHMEM)+= ashmem.o
 obj-$(CONFIG_ANDROID_LOW_MEMORY_KILLER)+= lowmemorykiller.o
+obj-$(CONFIG_ANDROID_LOW_MEMORY_KILLER)+= lowmemorykiller_tasks.o
 obj-$(CONFIG_ANDROID_LOW_MEMORY_KILLER_STATS)+= lowmemorykiller_stats.o
diff --git a/drivers/staging/android/lowmemorykiller.c 
b/drivers/staging/android/lowmemorykiller.c
index 15c1b38..1e275b1 100644
--- a/drivers/staging/android/lowmemorykiller.c
+++ b/drivers/staging/android/lowmemorykiller.c
@@ -41,10 +41,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
+#include "lowmemorykiller.h"
 #include "lowmemorykiller_stats.h"
+#include "lowmemorykiller_tasks.h"

-static u32 lowmem_debug_level = 1;
+u32 lowmem_debug_level = 1;
 static short lowmem_adj[6] = {
 0,
 1,
@@ -62,135 +66,212 @@ static int lowmem_minfree[6] = {

 static int lowmem_minfree_size = 4;

-static unsigned long lowmem_deathpending_timeout;
-
-#define lowmem_print(level, x...)\
-do {\
-if (lowmem_debug_level >= (level))\
-pr_info(x);\
-} while (0)
-
-static unsigned long lowmem_count(struct shrinker *s,
-  struct shrink_control *sc)
-{
-lmk_inc_stats(LMK_COUNT);
-return global_node_page_state(NR_ACTIVE_ANON) +
-global_node_page_state(NR_ACTIVE_FILE) +
-global_node_page_state(NR_INACTIVE_ANON) +
-global_node_page_state(NR_INACTIVE_FILE);
-}
+struct calculated_params {
+long selected_tasksize;
+long minfree;
+int other_file;
+int other_free;
+int dynamic_max_queue_len;
+short selected_oom_score_adj;
+short min_score_adj;
+};

-static unsigned long lowmem_scan(struct shrinker *s, struct shrink_control *sc)
+static int kill_needed(int level, struct shrink_control *sc,
+   struct calculated_params *cp)
 {
-struct task_struct *tsk;
-struct task_struct *selected = NULL;
-unsigned long rem = 0;
-int tasksize;
 int i;
-short min_score_adj = OOM_SCORE_ADJ_MAX + 1;
-int minfree = 0;
-int selected_tasksize = 0;
-  

[PATCH 0/3 staging-next] android: Lowmemmorykiller task tree

2017-02-09 Thread peter enderborg

Lowmemorykiller efficiency problem and a solution.

Lowmemorykiller in android has a severe efficiency problem. The basic
problem is that the registered shrinker gets called very often without
 anything actually happening. This is in some cases not a problem as
it is a simple calculation that returns a value. But when there is
high pressure on memory and we get to start killing processes to free
memory we get some heavy work that does lots of cpu processing and
lock holding for no real benefit. This occurs when we are below the
first threshold level in minfree. We call that waste. To see this
problem we introduce a patch that collects statistics from
lowmemorykiller. We collect the amount of kills, scans, counts and
some other metrics. One of this metrics is called waste. These metrics
are presented in procfs as /proc/lmkstats.

Patchset:
0001-android-Collect-statistics-from-lowmemorykiller.patch
0002-oom-Add-notification-for-oom_score_adj.patch
0003-mm-Remove-RCU-and-tasklocks-from-lmk.patch


Collect-statistics-from-lowmemorykiller.patch
-
This patch only adds metrics and is there to show
behavour before and after and is a good way to
see that the device is in waste zone.


0002-oom-Add-notification-for-oom_score_adj.patch

This is the prerequisite patch to be able to do
the lowmemorykiller change. It introduces notifiers
for oom_score_adj. It generates notifier events for
process creation and death, and when process values
are changed.  These patches are outside from stageing
drivers and are applied to core functions in e.g. fork.c.

0003-mm-Remove-RCU-and-tasklocks-from-lmk.patch
---
This patch is the change of lowmemorykiller. It
builds a tree structure that works as cache for
the task list, but only contains the tasks that
are relevant for the lmk. The key thing here is
that the cache is sorted based on the oom_score_adj
value so the scan and count function can find
the right task with only a tree first operation.
Based on the right task the count can give a
proper reply and give a right estimate of the
amount it will free, and more important when
it is not willing to free anything. This makes
the shrinker not to call the scan function at all,
and when it is called it actually do what it's
supposed to do that is to free up some memory.
I consider this as mm based on the behaviour
changes for the shrinker even if the code is
a driver.

About testing.
Reproduce the problem. For this the first patch is needed and enabeld.
It does not change the lowmemory killer other than it add some metrics.
One counter is called WASTE. This is what this patch-set is about.
In android environment this can be tested directly. On other systems
like fedora a method using the stress package can be used. Apply the
patches. (First with only metrics) then in your

shell: echo 400 > /proc/self/oom_score_adj

Now you have created a shell that has something that can be killed.
In the same shell use stress program. The parameters will be very
dependent on your configuration, but you need to run out of memmory.

Most of the wasted cpu cycles are accounted in kswapd0 task so a compare
of the reduced waste can also be seen in the schedstat for that task.
However activitymanager will get some more work done in kernel space.
Finaly the new version also has the WASTE counter, but this one is
the cost of only a rbtree search.

Cost/Drawback
The impact on the fork call is on a 2ghz arm64 is about 500ns for the
notifier.

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


[PATCH 2/3 staging-next] oom: Add notification for oom_score_adj

2017-02-09 Thread peter enderborg

This adds subscribtion for changes in oom_score_adj, this
value is important to android systems. For task that uses
oom_score_adj they read the task list. This can be long
and need rcu locks and has a impact on the system. Let
the user track the changes based on oom_score_adj changes
and keep them in their own context so they do their actions
with minimal system impact.

Signed-off-by: Peter Enderborg 
---
 fs/proc/base.c | 13 +++
 include/linux/oom_score_notifier.h | 47 
 kernel/Makefile|  1 +
 kernel/fork.c  |  6 +++
 kernel/oom_score_notifier.c| 75 ++
 mm/Kconfig |  9 +
 6 files changed, 151 insertions(+)
 create mode 100644 include/linux/oom_score_notifier.h
 create mode 100644 kernel/oom_score_notifier.c

diff --git a/fs/proc/base.c b/fs/proc/base.c
index 87c9a9a..60c2d9b 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -87,6 +87,7 @@
 #include 
 #include 
 #include 
+#include 
 #ifdef CONFIG_HARDWALL
 #include 
 #endif
@@ -1057,6 +1058,7 @@ static int __set_oom_adj(struct file *file, int oom_adj, 
bool legacy)
 static DEFINE_MUTEX(oom_adj_mutex);
 struct mm_struct *mm = NULL;
 struct task_struct *task;
+int old_oom_score_adj;
 int err = 0;

 task = get_proc_task(file_inode(file));
@@ -1102,9 +1104,20 @@ static int __set_oom_adj(struct file *file, int oom_adj, 
bool legacy)
 }
 }

+old_oom_score_adj = task->signal->oom_score_adj;
 task->signal->oom_score_adj = oom_adj;
 if (!legacy && has_capability_noaudit(current, CAP_SYS_RESOURCE))
 task->signal->oom_score_adj_min = (short)oom_adj;
+
+#ifdef CONFIG_OOM_SCORE_NOTIFIER
+err = oom_score_notify_update(task, old_oom_score_adj);
+if (err) {
+/* rollback and error handle. */
+task->signal->oom_score_adj = old_oom_score_adj;
+goto err_unlock;
+}
+#endif
+
 trace_oom_score_adj_update(task);

 if (mm) {
diff --git a/include/linux/oom_score_notifier.h 
b/include/linux/oom_score_notifier.h
new file mode 100644
index 000..c5cea47
--- /dev/null
+++ b/include/linux/oom_score_notifier.h
@@ -0,0 +1,47 @@
+/*
+ *  oom_score_notifier interface
+ *  Copyright (C) 2017 Sony Mobile Communications Inc.
+ *
+ *  Author: Peter Enderborg 
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+#ifndef _LINUX_OOM_SCORE_NOTIFIER_H
+#define _LINUX_OOM_SCORE_NOTIFIER_H
+
+#ifdef CONFIG_OOM_SCORE_NOTIFIER
+
+#include 
+#include 
+#include 
+
+enum osn_msg_type {
+OSN_NEW,
+OSN_FREE,
+OSN_UPDATE
+};
+
+extern struct atomic_notifier_head oom_score_notifier;
+extern int oom_score_notifier_register(struct notifier_block *n);
+extern int oom_score_notifier_unregister(struct notifier_block *n);
+extern int oom_score_notify_free(struct task_struct *tsk);
+extern int oom_score_notify_new(struct task_struct *tsk);
+extern int oom_score_notify_update(struct task_struct *tsk, int old_score);
+
+struct oom_score_notifier_struct {
+struct task_struct *tsk;
+int old_score;
+};
+
+#else
+
+#define oom_score_notify_free(t)  do {} while (0)
+#define oom_score_notify_new(t) false
+#define oom_score_notify_update(t, s) do {} while (0)
+
+#endif /* CONFIG_OOM_SCORE_NOTIFIER */
+
+#endif /* _LINUX_OOM_SCORE_NOTIFIER_H */
diff --git a/kernel/Makefile b/kernel/Makefile
index 12c679f..747c66c 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -91,6 +91,7 @@ obj-$(CONFIG_SYSCTL) += utsname_sysctl.o
 obj-$(CONFIG_TASK_DELAY_ACCT) += delayacct.o
 obj-$(CONFIG_TASKSTATS) += taskstats.o tsacct.o
 obj-$(CONFIG_TRACEPOINTS) += tracepoint.o
+obj-$(CONFIG_OOM_SCORE_NOTIFIER) += oom_score_notifier.o
 obj-$(CONFIG_LATENCYTOP) += latencytop.o
 obj-$(CONFIG_ELFCORE) += elfcore.o
 obj-$(CONFIG_FUNCTION_TRACER) += trace/
diff --git a/kernel/fork.c b/kernel/fork.c
index 11c5c8a..f8a1a89 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -73,6 +73,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -391,6 +392,7 @@ void __put_task_struct(struct task_struct *tsk)
 exit_creds(tsk);
 delayacct_tsk_free(tsk);
 put_signal_struct(tsk->signal);
+oom_score_notify_free(tsk);

 if (!profile_handoff_task(tsk))
 free_task(tsk);
@@ -1790,6 +1792,10 @@ static __latent_entropy struct task_struct *copy_process(

 init_task_pid(p, PIDTYPE_PID, pid);
 if (thread_group_leader(p)) {
+retval = oom_score_notify_new(p);
+if (retval)
+goto bad_fork_cancel_cgroup;
+
 init_task_pid(p, PIDTYPE_PGID, task_pgrp(current));
 init_task_pid(p, PIDTYPE_SID, task_session(current));

diff --git 

[PATCH 1/3 staging-next] android: Collect statistics from lowmemorykiller

2017-02-09 Thread peter enderborg

This collects stats for shrinker calls and how much
waste work we do within the lowmemorykiller.

Signed-off-by: Peter Enderborg 
---
 drivers/staging/android/Kconfig | 11 
 drivers/staging/android/Makefile|  1 +
 drivers/staging/android/lowmemorykiller.c   |  9 ++-
 drivers/staging/android/lowmemorykiller_stats.c | 85 +
 drivers/staging/android/lowmemorykiller_stats.h | 29 +
 5 files changed, 134 insertions(+), 1 deletion(-)
 create mode 100644 drivers/staging/android/lowmemorykiller_stats.c
 create mode 100644 drivers/staging/android/lowmemorykiller_stats.h

diff --git a/drivers/staging/android/Kconfig b/drivers/staging/android/Kconfig
index 6c00d6f..96e86c7 100644
--- a/drivers/staging/android/Kconfig
+++ b/drivers/staging/android/Kconfig
@@ -24,6 +24,17 @@ config ANDROID_LOW_MEMORY_KILLER
   scripts (/init.rc), and it defines priority values with minimum free 
memory size
   for each priority.

+config ANDROID_LOW_MEMORY_KILLER_STATS
+bool "Android Low Memory Killer: collect statistics"
+depends on ANDROID_LOW_MEMORY_KILLER
+default n
+help
+  Create a file in /proc/lmkstats that includes
+  collected statistics about kills, scans and counts
+  and  interaction with the shrinker. Its content
+  will be different depeding on lmk implementation used.
+
+
 source "drivers/staging/android/ion/Kconfig"

 endif # if ANDROID
diff --git a/drivers/staging/android/Makefile b/drivers/staging/android/Makefile
index 7ed1be7..d710eb2 100644
--- a/drivers/staging/android/Makefile
+++ b/drivers/staging/android/Makefile
@@ -4,3 +4,4 @@ obj-y+= ion/

 obj-$(CONFIG_ASHMEM)+= ashmem.o
 obj-$(CONFIG_ANDROID_LOW_MEMORY_KILLER)+= lowmemorykiller.o
+obj-$(CONFIG_ANDROID_LOW_MEMORY_KILLER_STATS)+= lowmemorykiller_stats.o
diff --git a/drivers/staging/android/lowmemorykiller.c 
b/drivers/staging/android/lowmemorykiller.c
index ec3b665..15c1b38 100644
--- a/drivers/staging/android/lowmemorykiller.c
+++ b/drivers/staging/android/lowmemorykiller.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include "lowmemorykiller_stats.h"

 static u32 lowmem_debug_level = 1;
 static short lowmem_adj[6] = {
@@ -72,6 +73,7 @@ static unsigned long lowmem_deathpending_timeout;
 static unsigned long lowmem_count(struct shrinker *s,
   struct shrink_control *sc)
 {
+lmk_inc_stats(LMK_COUNT);
 return global_node_page_state(NR_ACTIVE_ANON) +
 global_node_page_state(NR_ACTIVE_FILE) +
 global_node_page_state(NR_INACTIVE_ANON) +
@@ -95,6 +97,7 @@ static unsigned long lowmem_scan(struct shrinker *s, struct 
shrink_control *sc)
 global_node_page_state(NR_SHMEM) -
 total_swapcache_pages();

+lmk_inc_stats(LMK_SCAN);
 if (lowmem_adj_size < array_size)
 array_size = lowmem_adj_size;
 if (lowmem_minfree_size < array_size)
@@ -134,6 +137,7 @@ static unsigned long lowmem_scan(struct shrinker *s, struct 
shrink_control *sc)
 if (task_lmk_waiting(p) &&
 time_before_eq(jiffies, lowmem_deathpending_timeout)) {
 task_unlock(p);
+lmk_inc_stats(LMK_TIMEOUT);
 rcu_read_unlock();
 return 0;
 }
@@ -179,7 +183,9 @@ static unsigned long lowmem_scan(struct shrinker *s, struct 
shrink_control *sc)
  other_free * (long)(PAGE_SIZE / 1024));
 lowmem_deathpending_timeout = jiffies + HZ;
 rem += selected_tasksize;
-}
+lmk_inc_stats(LMK_KILL);
+} else
+lmk_inc_stats(LMK_WASTE);

 lowmem_print(4, "lowmem_scan %lu, %x, return %lu\n",
  sc->nr_to_scan, sc->gfp_mask, rem);
@@ -196,6 +202,7 @@ static struct shrinker lowmem_shrinker = {
 static int __init lowmem_init(void)
 {
 register_shrinker(_shrinker);
+init_procfs_lmk();
 return 0;
 }
 device_initcall(lowmem_init);
diff --git a/drivers/staging/android/lowmemorykiller_stats.c 
b/drivers/staging/android/lowmemorykiller_stats.c
new file mode 100644
index 000..673691c
--- /dev/null
+++ b/drivers/staging/android/lowmemorykiller_stats.c
@@ -0,0 +1,85 @@
+/*
+ *  lowmemorykiller_stats
+ *
+ *  Copyright (C) 2017 Sony Mobile Communications Inc.
+ *
+ *  Author: Peter Enderborg 
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+/* This code is bookkeeping of statistical information
+ * from lowmemorykiller and provide a node in proc "/proc/lmkstats".
+ */
+
+#include 
+#include 
+#include "lowmemorykiller_stats.h"
+
+struct lmk_stats {
+atomic_long_t scans; /* counter as in shrinker scans */
+atomic_long_t kills; /* the number of sigkills sent */
+atomic_long_t waste; /* the numer of extensive calls that did

Re: [PATCH 1/1] staging: comedi: dmm32at: usleep_range is preferred over udelay

2017-02-09 Thread Ian Abbott

On 09/02/17 12:59, Saber Rezvani wrote:

Fix the checkpatch.pl issue:
CHECK: usleep_range is preferred over udelay

Signed-off-by: Saber Rezvani 
---
 drivers/staging/comedi/drivers/dmm32at.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/comedi/drivers/dmm32at.c 
b/drivers/staging/comedi/drivers/dmm32at.c
index b8606de..771cceb7 100644
--- a/drivers/staging/comedi/drivers/dmm32at.c
+++ b/drivers/staging/comedi/drivers/dmm32at.c
@@ -510,7 +510,7 @@ static int dmm32at_reset(struct comedi_device *dev)
outb(DMM32AT_CTRL_RESETA, dev->iobase + DMM32AT_CTRL_REG);

/* allow a millisecond to reset */
-   udelay(1000);
+   usleep_range(1000, 3000);

/* zero scan and fifo control */
outb(0x0, dev->iobase + DMM32AT_FIFO_CTRL_REG);
@@ -526,7 +526,7 @@ static int dmm32at_reset(struct comedi_device *dev)
outb(DMM32AT_RANGE_U10, dev->iobase + DMM32AT_AI_CFG_REG);

/* should take 10 us to settle, here's a hundred */
-   udelay(100);
+   usleep_range(100, 200);

/* read back the values */
ailo = inb(dev->iobase + DMM32AT_AI_LO_CHAN_REG);



Looks good, thanks!

Reviewed-by: Ian Abbott 

--
-=( 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:vt6656:baseband.h: fix function definition argument without identifier name issue

2017-02-09 Thread Arushi Singhal
Function definitions arguments should also have an identifier name as
reported by checkpatch.pl.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/vt6655/baseband.h | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/vt6655/baseband.h 
b/drivers/staging/vt6655/baseband.h
index 8a567c9155b4..c351e03f6ad2 100644
--- a/drivers/staging/vt6655/baseband.h
+++ b/drivers/staging/vt6655/baseband.h
@@ -75,13 +75,13 @@ void BBvSetShortSlotTime(struct vnt_private *);
 void BBvSetVGAGainOffset(struct vnt_private *, unsigned char byData);
 
 /* VT3253 Baseband */
-bool BBbVT3253Init(struct vnt_private *);
-void BBvSoftwareReset(struct vnt_private *);
-void BBvPowerSaveModeON(struct vnt_private *);
-void BBvPowerSaveModeOFF(struct vnt_private *);
-void BBvSetTxAntennaMode(struct vnt_private *, unsigned char byAntennaMode);
-void BBvSetRxAntennaMode(struct vnt_private *, unsigned char byAntennaMode);
-void BBvSetDeepSleep(struct vnt_private *, unsigned char byLocalID);
-void BBvExitDeepSleep(struct vnt_private *, unsigned char byLocalID);
+bool BBbVT3253Init(struct vnt_private *priv);
+void BBvSoftwareReset(struct vnt_private *priv);
+void BBvPowerSaveModeON(struct vnt_private *priv);
+void BBvPowerSaveModeOFF(struct vnt_private *priv);
+void BBvSetTxAntennaMode(struct vnt_private *priv, unsigned char 
byAntennaMode);
+void BBvSetRxAntennaMode(struct vnt_private *priv, unsigned char 
byAntennaMode);
+void BBvSetDeepSleep(struct vnt_private *priv, unsigned char byLocalID);
+void BBvExitDeepSleep(struct vnt_private *priv, unsigned char byLocalID);
 
 #endif /* __BASEBAND_H__ */
-- 
2.11.0

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


[PATCH] staging: rtl8192u: Removing unnecessary space after a cast

2017-02-09 Thread simran singhal
This patch fixes the checkpatch warning by removing unnecessary space
after a cast.
CHECK: No space is necessary after a cast

Signed-off-by: simran singhal 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c
index 0ddd5ac..c4abfd1 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c
@@ -131,7 +131,7 @@ static void ccmp_init_blocks(struct crypto_tfm *tfm,
if (a4_included)
aad_len += 6;
if (qc_included) {
-   pos = (u8 *) >addr4;
+   pos = (u8 *)>addr4;
if (a4_included)
pos += 6;
qc = *pos & 0x0f;
@@ -157,13 +157,13 @@ static void ccmp_init_blocks(struct crypto_tfm *tfm,
 * A4 (if present)
 * QC (if present)
 */
-   pos = (u8 *) hdr;
+   pos = (u8 *)hdr;
aad[0] = 0; /* aad_len >> 8 */
aad[1] = aad_len & 0xff;
aad[2] = pos[0] & 0x8f;
aad[3] = pos[1] & 0xc7;
memcpy(aad + 4, hdr->addr1, 3 * ETH_ALEN);
-   pos = (u8 *) >seq_ctl;
+   pos = (u8 *)>seq_ctl;
aad[22] = pos[0] & 0x0f;
aad[23] = 0; /* all bits masked */
memset(aad + 24, 0, 8);
@@ -221,7 +221,7 @@ static int ieee80211_ccmp_encrypt(struct sk_buff *skb, int 
hdr_len, void *priv)
*pos++ = key->tx_pn[1];
*pos++ = key->tx_pn[0];
 
-   hdr = (struct rtl_80211_hdr_4addr *) skb->data;
+   hdr = (struct rtl_80211_hdr_4addr *)skb->data;
if (!tcb_desc->bHwSec) {
int blocks, last, len;
u8 *mic;
@@ -270,7 +270,7 @@ static int ieee80211_ccmp_decrypt(struct sk_buff *skb, int 
hdr_len, void *priv)
return -1;
}
 
-   hdr = (struct rtl_80211_hdr_4addr *) skb->data;
+   hdr = (struct rtl_80211_hdr_4addr *)skb->data;
pos = skb->data + hdr_len;
keyidx = pos[3];
if (!(keyidx & (1 << 5))) {
-- 
2.7.4

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


[PATCH] staging: greybus: uart: fix uninitialized newline.flow_control

2017-02-09 Thread Colin King
From: Colin Ian King 

Currently newline.flow_control is uninitialized, so it can contain
any garbage from the stack.  I believe it should be initialized with
GB_SERIAL_AUTO_RTSCTS_EN enabled if the termios c_cflag is CRTSCTS
enabled.

Signed-off-by: Colin Ian King 
---
 drivers/staging/greybus/uart.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/greybus/uart.c b/drivers/staging/greybus/uart.c
index 248ad66..b542f67 100644
--- a/drivers/staging/greybus/uart.c
+++ b/drivers/staging/greybus/uart.c
@@ -506,6 +506,8 @@ static void gb_tty_set_termios(struct tty_struct *tty,
newline.parity = termios->c_cflag & PARENB ?
(termios->c_cflag & PARODD ? 1 : 2) +
(termios->c_cflag & CMSPAR ? 2 : 0) : 0;
+   newline.flow_control = termios->c_cflag & CRTSCTS ?
+   GB_SERIAL_AUTO_RTSCTS_EN : 0;
 
switch (termios->c_cflag & CSIZE) {
case CS5:
-- 
2.10.2

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


Re: [PATCH] staging:vt6656:baseband.h: fix function definition argument without identifier name issue

2017-02-09 Thread Greg KH
On Thu, Feb 09, 2017 at 06:25:20PM +0530, Arushi wrote:
> Function definitions arguments should also have an identifier name as 
> reported by checkpatch.pl.
> 
> Signed-off-by: Arushi Singhal 

This name does not match up with your From: line :(

Also, please wrap your changelog text at the correct width.

thanks,

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


[PATCH 1/1] staging: comedi: dmm32at: usleep_range is preferred over udelay

2017-02-09 Thread Saber Rezvani
Fix the checkpatch.pl issue:
CHECK: usleep_range is preferred over udelay

Signed-off-by: Saber Rezvani 
---
 drivers/staging/comedi/drivers/dmm32at.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/comedi/drivers/dmm32at.c 
b/drivers/staging/comedi/drivers/dmm32at.c
index b8606de..771cceb7 100644
--- a/drivers/staging/comedi/drivers/dmm32at.c
+++ b/drivers/staging/comedi/drivers/dmm32at.c
@@ -510,7 +510,7 @@ static int dmm32at_reset(struct comedi_device *dev)
outb(DMM32AT_CTRL_RESETA, dev->iobase + DMM32AT_CTRL_REG);
 
/* allow a millisecond to reset */
-   udelay(1000);
+   usleep_range(1000, 3000);
 
/* zero scan and fifo control */
outb(0x0, dev->iobase + DMM32AT_FIFO_CTRL_REG);
@@ -526,7 +526,7 @@ static int dmm32at_reset(struct comedi_device *dev)
outb(DMM32AT_RANGE_U10, dev->iobase + DMM32AT_AI_CFG_REG);
 
/* should take 10 us to settle, here's a hundred */
-   udelay(100);
+   usleep_range(100, 200);
 
/* read back the values */
ailo = inb(dev->iobase + DMM32AT_AI_LO_CHAN_REG);
-- 
2.7.4


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


[PATCH] staging:vt6656:baseband.h: fix function definition argument without identifier name issue

2017-02-09 Thread Arushi
Function definitions arguments should also have an identifier name as reported 
by checkpatch.pl.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/vt6655/baseband.h | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/vt6655/baseband.h 
b/drivers/staging/vt6655/baseband.h
index 8a567c9155b4..c351e03f6ad2 100644
--- a/drivers/staging/vt6655/baseband.h
+++ b/drivers/staging/vt6655/baseband.h
@@ -75,13 +75,13 @@ void BBvSetShortSlotTime(struct vnt_private *);
 void BBvSetVGAGainOffset(struct vnt_private *, unsigned char byData);
 
 /* VT3253 Baseband */
-bool BBbVT3253Init(struct vnt_private *);
-void BBvSoftwareReset(struct vnt_private *);
-void BBvPowerSaveModeON(struct vnt_private *);
-void BBvPowerSaveModeOFF(struct vnt_private *);
-void BBvSetTxAntennaMode(struct vnt_private *, unsigned char byAntennaMode);
-void BBvSetRxAntennaMode(struct vnt_private *, unsigned char byAntennaMode);
-void BBvSetDeepSleep(struct vnt_private *, unsigned char byLocalID);
-void BBvExitDeepSleep(struct vnt_private *, unsigned char byLocalID);
+bool BBbVT3253Init(struct vnt_private *priv);
+void BBvSoftwareReset(struct vnt_private *priv);
+void BBvPowerSaveModeON(struct vnt_private *priv);
+void BBvPowerSaveModeOFF(struct vnt_private *priv);
+void BBvSetTxAntennaMode(struct vnt_private *priv, unsigned char 
byAntennaMode);
+void BBvSetRxAntennaMode(struct vnt_private *priv, unsigned char 
byAntennaMode);
+void BBvSetDeepSleep(struct vnt_private *priv, unsigned char byLocalID);
+void BBvExitDeepSleep(struct vnt_private *priv, unsigned char byLocalID);
 
 #endif /* __BASEBAND_H__ */
-- 
2.11.0

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


Re: [PATCH] Staging: comedi: drivers: comedi_test: Set max input value for auto config

2017-02-09 Thread Ian Abbott

On 27/01/17 15:55, Cheah Kok Cheong wrote:

Currently user can input any value for amplitude and period.
This patch set a sane max value for auto-configuration mode.

For manual configuration mode, it is assumed this is taken care of
by the COMEDI userspace tool since there's no limit set here from
day one in the staging tree. If otherwise then maybe this can be
looked at separately.

Signed-off-by: Cheah Kok Cheong 


I don't think there is any need to limit these unless it results in 
arithmetic overflow, since they only affect the fake sample data values 
produced by the driver, not system performance.


--
-=( 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: rtl8192u: Removing multiple blank lines

2017-02-09 Thread simran singhal
This patch fixes the checkpatch warning by removing multiple blank
lines.
CHECK: Please don't use multiple blank lines

Signed-off-by: simran singhal 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c | 12 
 1 file changed, 12 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c
index 2dc25cc..0ddd5ac 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c
@@ -90,7 +90,6 @@ static void *ieee80211_ccmp_init(int key_idx)
return NULL;
 }
 
-
 static void ieee80211_ccmp_deinit(void *priv)
 {
struct ieee80211_ccmp_data *_priv = priv;
@@ -100,7 +99,6 @@ static void ieee80211_ccmp_deinit(void *priv)
kfree(priv);
 }
 
-
 static inline void xor_block(u8 *b, u8 *a, size_t len)
 {
int i;
@@ -109,8 +107,6 @@ static inline void xor_block(u8 *b, u8 *a, size_t len)
b[i] ^= a[i];
 }
 
-
-
 static void ccmp_init_blocks(struct crypto_tfm *tfm,
 struct rtl_80211_hdr_4addr *hdr,
 u8 *pn, size_t dlen, u8 *b0, u8 *auth,
@@ -189,8 +185,6 @@ static void ccmp_init_blocks(struct crypto_tfm *tfm,
ieee80211_ccmp_aes_encrypt(tfm, b0, s0);
 }
 
-
-
 static int ieee80211_ccmp_encrypt(struct sk_buff *skb, int hdr_len, void *priv)
 {
struct ieee80211_ccmp_data *key = priv;
@@ -227,7 +221,6 @@ static int ieee80211_ccmp_encrypt(struct sk_buff *skb, int 
hdr_len, void *priv)
*pos++ = key->tx_pn[1];
*pos++ = key->tx_pn[0];
 
-
hdr = (struct rtl_80211_hdr_4addr *) skb->data;
if (!tcb_desc->bHwSec) {
int blocks, last, len;
@@ -264,7 +257,6 @@ static int ieee80211_ccmp_encrypt(struct sk_buff *skb, int 
hdr_len, void *priv)
return 0;
 }
 
-
 static int ieee80211_ccmp_decrypt(struct sk_buff *skb, int hdr_len, void *priv)
 {
struct ieee80211_ccmp_data *key = priv;
@@ -327,7 +319,6 @@ static int ieee80211_ccmp_decrypt(struct sk_buff *skb, int 
hdr_len, void *priv)
u8 *a = key->rx_a;
int i, blocks, last, len;
 
-
ccmp_init_blocks(key->tfm, hdr, pn, data_len, b0, a, b);
xor_block(mic, b, CCMP_MIC_LEN);
 
@@ -366,7 +357,6 @@ static int ieee80211_ccmp_decrypt(struct sk_buff *skb, int 
hdr_len, void *priv)
return keyidx;
 }
 
-
 static int ieee80211_ccmp_set_key(void *key, int len, u8 *seq, void *priv)
 {
struct ieee80211_ccmp_data *data = priv;
@@ -397,7 +387,6 @@ static int ieee80211_ccmp_set_key(void *key, int len, u8 
*seq, void *priv)
return 0;
 }
 
-
 static int ieee80211_ccmp_get_key(void *key, int len, u8 *seq, void *priv)
 {
struct ieee80211_ccmp_data *data = priv;
@@ -421,7 +410,6 @@ static int ieee80211_ccmp_get_key(void *key, int len, u8 
*seq, void *priv)
return CCMP_TK_LEN;
 }
 
-
 static char *ieee80211_ccmp_print_stats(char *p, void *priv)
 {
struct ieee80211_ccmp_data *ccmp = priv;
-- 
2.7.4

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


Re: [PATCH] Staging: comedi: drivers: comedi_test: Add auto-configuration capability

2017-02-09 Thread Ian Abbott

On 25/01/17 17:31, Cheah Kok Cheong wrote:

Currently this module needs to be manually configured by COMEDI
userspace tool before the test waveform can be read by a COMEDI
compatible application.

This patch adds auto-configuration capability and makes it the default
loading option. This is achieved by creating a device during init
to stand in for a real hardware device. This allows comedi_auto_config
to perform auto-configuration. With this patch, the test waveform can
be read by a COMEDI compatible application without needing manual
configuration.


This looks like a useful feature.  It avoids the need to reserve 
"legacy" devices in the core comedi module (using the 
"comedi_num_legacy_minors" module parameter), and configuring a reserved 
device "manually" with the comedi_config utiity.



Manual configuration [previous behaviour] is still selectable via
module loading parameter. Module loading without passing any
parameter will default to auto-configuration with the same default
waveform amplitude and period values. For auto-configuration,
different amplitude and period values can be set via module loading
parameters.

Tested on Xubuntu 16.04 using Xoscope ver: 2.0 which is available
in the Ubuntu repository. Xoscope is a COMEDI compatible digital
oscilloscope application. For manual configuration, only module
loading/unloading is tested.

Here are the truncated dmesg output.
[sudo modprobe comedi_test]

comedi_test: 100 microvolt, 10 microsecond waveform attached
driver 'comedi_test' has successfully auto-configured 'comedi_test'.

[sudo modprobe comedi_test amplitude=250 period=15]

comedi_test: 250 microvolt, 15 microsecond waveform attached
driver 'comedi_test' has successfully auto-configured 'comedi_test'.

[sudo modprobe comedi_test manual=1]

comedi_test: module is from the staging directory, the quality is unknown,
you have been warned.

For those without an actual hardware, the comedi_test module
is as close as one can get to test the COMEDI system.
Having both auto and manual configuration capability will broaden
the test function of this module.
Hopefully this will make it easier for people to check out the
COMEDI system and contribute to its development.

Signed-off-by: Cheah Kok Cheong 
---
 drivers/staging/comedi/drivers/comedi_test.c | 140 ---
 1 file changed, 128 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/comedi/drivers/comedi_test.c 
b/drivers/staging/comedi/drivers/comedi_test.c
index ec5b9a2..92b3a4f1 100644
--- a/drivers/staging/comedi/drivers/comedi_test.c
+++ b/drivers/staging/comedi/drivers/comedi_test.c
@@ -36,7 +36,15 @@
  * generate sample waveforms on systems that don't have data acquisition
  * hardware.
  *
- * Configuration options:
+ * Auto configuration is the default mode if no parameter is supplied during
+ * module loading. Manual configuration requires COMEDI userspace tool.
+ * To select manual configuration mode, pass "manual=1" parameter for module
+ * loading. Refer modinfo or MODULE_PARM_DESC description below for details.


I think the "manual" parameter is misnamed, since this parameter 
controls whether a dummy hardware device is created by the driver or 
not.  Reserved COMEDI devices can still be configured manually to use 
this driver irrespective of the setting of the "manual" parameter.


Some possible options are to rename the parameter "noauto" (or 
"nocreate"), or to name it "auto" (or "create") with default value 1.



+ *
+ * Auto configuration options:
+ *   Refer modinfo or MODULE_PARM_DESC description below for details.
+ *
+ * Manual configuration options:
  *   [0] - Amplitude in microvolts for fake waveforms (default 1 volt)
  *   [1] - Period in microseconds for fake waveforms (default 0.1 sec)
  *
@@ -53,8 +61,27 @@
 #include 
 #include 
 #include 
+#include 
+#include 

 #define N_CHANS 8
+#define DEV_NAME "comedi_testd"
+#define CLASS_NAME "comedi_char"


I'm not sure about the class name "comedi_char".  Perhaps "comedi_test" 
would be better to associate it with this module.



+
+static bool config_mode;
+static unsigned int set_amplitude;
+static unsigned int set_period;
+static struct class *ctcls;
+static struct device *ctdev;
+
+module_param_named(manual, config_mode, bool, 0444);
+MODULE_PARM_DESC(manual, "Enable manual configuration: (1=enable [defaults to 
auto])");
+
+module_param_named(amplitude, set_amplitude, uint, 0444);
+MODULE_PARM_DESC(amplitude, "Set auto mode wave amplitude in microvolts: (defaults 
to 1 volt)");
+
+module_param_named(period, set_period, uint, 0444);
+MODULE_PARM_DESC(period, "Set auto mode wave period in microseconds: (defaults to 
0.1 sec)");

 /* Data unique to this driver */
 struct waveform_private {
@@ -607,13 +634,11 @@ static int waveform_ao_insn_write(struct comedi_device 
*dev,
return insn->n;
 }

-static int waveform_attach(struct comedi_device *dev,
-  struct 

[PATCH v6] staging: rtl8192e: Aligning the * on each line in block comments

2017-02-09 Thread Arushi
This patch fixes the issue by aligning the * on each line in block comments.

Signed-off-by: Arushi Singhal 
---
[Patch v1] is rejected as the changes done is not correct and is not following 
the linux kernel coding style in file drivers/staging/speakup/speakup_decpc.c 
as * on each line in block was not correctly alligned.
[Patch v2] is rejected for not to mention the cause of rejection of [Patch v1] 
but warnings is corrected.
In [Patch v3] mention of the cause was not in the correct format and is not 
descriptive.
In [Patch v4] didn't send patch message to all the list members so asked to 
again repatch it.
In [Patch v5] in description is not given with proper line-feeds.
---
 drivers/staging/speakup/fakekey.c| 10 +-
 drivers/staging/speakup/i18n.c   | 14 +++---
 drivers/staging/speakup/main.c   |  2 +-
 drivers/staging/speakup/speakup_acntsa.c |  2 +-
 drivers/staging/speakup/speakup_apollo.c |  2 +-
 drivers/staging/speakup/speakup_decext.c |  2 +-
 drivers/staging/speakup/speakup_decpc.c  |  4 ++--
 drivers/staging/speakup/speakup_dtlk.c   |  2 +-
 drivers/staging/speakup/speakup_dtlk.h   | 10 +-
 drivers/staging/speakup/speakup_ltlk.c   |  2 +-
 10 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/drivers/staging/speakup/fakekey.c 
b/drivers/staging/speakup/fakekey.c
index 8f058b42f68d..d76da0a1382c 100644
--- a/drivers/staging/speakup/fakekey.c
+++ b/drivers/staging/speakup/fakekey.c
@@ -63,8 +63,8 @@ void speakup_remove_virtual_keyboard(void)
 }
 
 /*
-* Send a simulated down-arrow to the application.
-*/
+ * Send a simulated down-arrow to the application.
+ */
 void speakup_fake_down_arrow(void)
 {
unsigned long flags;
@@ -87,9 +87,9 @@ void speakup_fake_down_arrow(void)
 }
 
 /*
-* Are we handling a simulated keypress on the current CPU?
-* Returns a boolean.
-*/
+ * Are we handling a simulated keypress on the current CPU?
+ * Returns a boolean.
+ */
 bool speakup_fake_key_pressed(void)
 {
return this_cpu_read(reporting_keystroke);
diff --git a/drivers/staging/speakup/i18n.c b/drivers/staging/speakup/i18n.c
index 8960079e4d60..2f9b3df7f78d 100644
--- a/drivers/staging/speakup/i18n.c
+++ b/drivers/staging/speakup/i18n.c
@@ -401,7 +401,7 @@ char *spk_msg_get(enum msg_index_t index)
  * Finds the start of the next format specifier in the argument string.
  * Return value: pointer to start of format
  * specifier, or NULL if no specifier exists.
-*/
+ */
 static char *next_specifier(char *input)
 {
int found = 0;
@@ -450,7 +450,7 @@ static char *skip_width(char *input)
  * Note that this code only accepts a handful of conversion specifiers:
  * c d s x and ld.  Not accidental; these are exactly the ones used in
  * the default group of formatted messages.
-*/
+ */
 static char *skip_conversion(char *input)
 {
if ((input[0] == 'l') && (input[1] == 'd'))
@@ -463,7 +463,7 @@ static char *skip_conversion(char *input)
 /*
  * Function: find_specifier_end
  * Return a pointer to the end of the format specifier.
-*/
+ */
 static char *find_specifier_end(char *input)
 {
input++;/* Advance over %. */
@@ -478,7 +478,7 @@ static char *find_specifier_end(char *input)
  * Compare the format specifiers pointed to by *input1 and *input2.
  * Return 1 if they are the same, 0 otherwise.  Advance *input1 and *input2
  * so that they point to the character following the end of the specifier.
-*/
+ */
 static int compare_specifiers(char **input1, char **input2)
 {
int same = 0;
@@ -500,7 +500,7 @@ static int compare_specifiers(char **input1, char **input2)
  * Check that two format strings contain the same number of format specifiers,
  * and that the order of specifiers is the same in both strings.
  * Return 1 if the condition holds, 0 if it doesn't.
-*/
+ */
 static int fmt_validate(char *template, char *user)
 {
int valid = 1;
@@ -537,7 +537,7 @@ static int fmt_validate(char *template, char *user)
  * Failure conditions:
  * -EINVAL -  Invalid format specifiers in formatted message or illegal index.
  * -ENOMEM -  Unable to allocate memory.
-*/
+ */
 ssize_t spk_msg_set(enum msg_index_t index, char *text, size_t length)
 {
int rc = 0;
@@ -573,7 +573,7 @@ ssize_t spk_msg_set(enum msg_index_t index, char *text, 
size_t length)
 /*
  * Find a message group, given its name.  Return a pointer to the structure
  * if found, or NULL otherwise.
-*/
+ */
 struct msg_group_t *spk_find_msg_group(const char *group_name)
 {
struct msg_group_t *group = NULL;
diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index bf539d38..c2f70ef5b9b3 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -16,7 +16,7 @@
  *  but WITHOUT ANY WARRANTY; without even the implied warranty of
  *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  *  GNU 

Re: [PATCH v3] staging: bcm2835-audio: Remove the initialization of static pointers.

2017-02-09 Thread Greg KH
On Wed, Feb 08, 2017 at 12:45:47AM +0100, AbdAllah-MEZITI wrote:
> In C a static pointer will be initialized to NULL.
> The ยง6.7.8 of the ISO/IEC 9899:1999 (E) document says that:
> If an object that has static storage duration is not initialized
> explicitly, then:
>  __ if it has pointer type, it is initialized to a null pointer.
> 
> Signed-off-by: AbdAllah-MEZITI 
> 
> v2: -fix the line-wrapping of the changelog.
> -fix the ref. documentation: C99 standards release,
>   and not the draft.
> -this patch is the Task 10 Eudyptula Challenge
>   that only fix one code style problem.
> v3: -fix the subject prefix: must be based on the previous submissions.
> ---
>  drivers/staging/bcm2835-audio/bcm2835.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

This patch does not apply to my tree at all, sorry.

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


[PATCH] staging: rtl8192u: Adding a blank line after declarations

2017-02-09 Thread simran singhal
This patch fixes the checkpatch warning by adding a blank line after
declarations.
WARNING: Missing a blank line after declarations

Signed-off-by: simran singhal 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
index 83f7b14..e030b28 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
@@ -146,6 +146,7 @@ static void ieee80211_TURBO_Info(struct ieee80211_device 
*ieee, u8 **tag_p)
 static void enqueue_mgmt(struct ieee80211_device *ieee, struct sk_buff *skb)
 {
int nh;
+
nh = (ieee->mgmt_queue_head +1) % MGMT_QUEUE_NUM;
 
 /*
@@ -226,6 +227,7 @@ inline void softmac_mgmt_xmit(struct sk_buff *skb, struct 
ieee80211_device *ieee
(struct rtl_80211_hdr_3addr  *) skb->data;
 
cb_desc *tcb_desc = (cb_desc *)(skb->cb + 8);
+
spin_lock_irqsave(>lock, flags);
 
/* called with 2nd param 0, no mgmt lock required */
@@ -364,6 +366,7 @@ struct sk_buff *ieee80211_get_beacon_(struct 
ieee80211_device *ieee);
 static void ieee80211_send_beacon(struct ieee80211_device *ieee)
 {
struct sk_buff *skb;
+
if(!ieee->ieee_up)
return;
//unsigned long flags;
@@ -427,6 +430,7 @@ void ieee80211_softmac_scan_syncro(struct ieee80211_device 
*ieee)
 {
short ch = 0;
u8 channel_map[MAX_CHANNEL_NUMBER+1];
+
memcpy(channel_map, GET_DOT11D_INFO(ieee)->channel_map, 
MAX_CHANNEL_NUMBER+1);
mutex_lock(>scan_mutex);
 
@@ -493,6 +497,7 @@ static void ieee80211_softmac_scan_wq(struct work_struct 
*work)
struct ieee80211_device *ieee = container_of(dwork, struct 
ieee80211_device, softmac_scan_wq);
static short watchdog;
u8 channel_map[MAX_CHANNEL_NUMBER+1];
+
memcpy(channel_map, GET_DOT11D_INFO(ieee)->channel_map, 
MAX_CHANNEL_NUMBER+1);
if(!ieee->ieee_up)
return;
@@ -2623,6 +2628,7 @@ void ieee80211_start_protocol(struct ieee80211_device 
*ieee)
 {
short ch = 0;
int i = 0;
+
if (ieee->proto_started)
return;
 
@@ -3129,6 +3135,7 @@ SendDisassociation(
 {
struct ieee80211_network *beacon = >current_network;
struct sk_buff *skb;
+
skb = ieee80211_disassociate_skb(beacon, ieee, asRsn);
if (skb) {
softmac_mgmt_xmit(skb, ieee);
@@ -3196,6 +3203,7 @@ EXPORT_SYMBOL(ieee80211_wpa_supplicant_ioctl);
 void notify_wx_assoc_event(struct ieee80211_device *ieee)
 {
union iwreq_data wrqu;
+
wrqu.ap_addr.sa_family = ARPHRD_ETHER;
if (ieee->state == IEEE80211_LINKED)
memcpy(wrqu.ap_addr.sa_data, ieee->current_network.bssid, 
ETH_ALEN);
-- 
2.7.4

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


Re: [PATCH 1/2] staging: bcm2835-audio: Removed spaces before ')'

2017-02-09 Thread Greg KH
On Mon, Feb 06, 2017 at 01:26:50PM +0530, Abhijit Naik wrote:
> bcm2835-vchiq.c and vc_vchi_audioserv_defs.h:
> fixing ERROR: space prohibited before that close parenthesis
> 
> Signed-off-by: Abhijit Naik 
> ---
>  drivers/staging/bcm2835-audio/bcm2835-vchiq.c  | 16 
>  drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h |  2 +-
>  2 files changed, 9 insertions(+), 9 deletions(-)

These two patches do not apply to my tree at all, it looks like someone
else already did this :(

sorry,

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


Re: [PATCH v5 0/3] staging: wlan-ng: align else if statement to coding standard

2017-02-09 Thread Greg Kroah-Hartman
On Tue, Feb 07, 2017 at 07:06:12AM -0500, Maksymilian Piechota wrote:
> Patch version 5:
> - break up particular changes to separate commits
> - change prefix to proper driver (wlan-ng)

What changed in the previous 4 versions?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v5 1/3] staging: wlan-ng: move logical continuations at the end of line

2017-02-09 Thread Greg Kroah-Hartman
On Tue, Feb 07, 2017 at 07:07:59AM -0500, Maksymilian Piechota wrote:
> Signed-off-by: Maksymilian Piechota 
> ---
>  drivers/staging/wlan-ng/prism2mgmt.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)

I can not take patches without any changelog text, sorry.  Please fix up
and resend the whole series.

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


[PATCH] staging: comedi: ni_pcimio: remove unused variable 'serial_number'

2017-02-09 Thread Karthik Nayak
The struct 'ni_private' holds the variable 'serial_number' which post
assignment is never used. Remove the variable and code pertaining to
obtaining its value.

As a side note, this also fixes the following sparse error:
drivers/staging/comedi/drivers//ni_pcimio.c:1229:32: warning: incorrect type in 
assignment (different base types)
drivers/staging/comedi/drivers//ni_pcimio.c:1229:32:expected restricted 
__be32 [usertype] serial_number
drivers/staging/comedi/drivers//ni_pcimio.c:1229:32:got unsigned int

Signed-off-by: Karthik Nayak 
---
 drivers/staging/comedi/drivers/ni_pcimio.c | 9 -
 drivers/staging/comedi/drivers/ni_stc.h| 1 -
 2 files changed, 10 deletions(-)

diff --git a/drivers/staging/comedi/drivers/ni_pcimio.c 
b/drivers/staging/comedi/drivers/ni_pcimio.c
index cdb66eab1292..3a96913c025e 100644
--- a/drivers/staging/comedi/drivers/ni_pcimio.c
+++ b/drivers/staging/comedi/drivers/ni_pcimio.c
@@ -1202,8 +1202,6 @@ static void m_series_init_eeprom_buffer(struct 
comedi_device *dev)
resource_size_t daq_phys_addr;
static const int Start_Cal_EEPROM = 0x400;
static const unsigned int window_size = 10;
-   static const int serial_number_eeprom_offset = 0x4;
-   static const int serial_number_eeprom_length = 0x4;
unsigned int old_iodwbsr_bits;
unsigned int old_iodwbsr1_bits;
unsigned int old_iodwcr1_bits;
@@ -1221,13 +1219,6 @@ static void m_series_init_eeprom_buffer(struct 
comedi_device *dev)
writel(0x1 | old_iodwcr1_bits, mite->mmio + MITE_IODWCR_1);
writel(0xf, mite->mmio + 0x30);
 
-   BUG_ON(serial_number_eeprom_length > sizeof(devpriv->serial_number));
-   for (i = 0; i < serial_number_eeprom_length; ++i) {
-   char *byte_ptr = (char *)>serial_number + i;
-   *byte_ptr = ni_readb(dev, serial_number_eeprom_offset + i);
-   }
-   devpriv->serial_number = be32_to_cpu(devpriv->serial_number);
-
for (i = 0; i < M_SERIES_EEPROM_SIZE; ++i)
devpriv->eeprom_buffer[i] = ni_readb(dev, Start_Cal_EEPROM + i);
 
diff --git a/drivers/staging/comedi/drivers/ni_stc.h 
b/drivers/staging/comedi/drivers/ni_stc.h
index f27b545f83eb..61138e86a455 100644
--- a/drivers/staging/comedi/drivers/ni_stc.h
+++ b/drivers/staging/comedi/drivers/ni_stc.h
@@ -1031,7 +1031,6 @@ struct ni_private {
 
unsigned short ai_fifo_buffer[0x2000];
u8 eeprom_buffer[M_SERIES_EEPROM_SIZE];
-   __be32 serial_number;
 
struct mite *mite;
struct mite_channel *ai_mite_chan;
-- 
2.11.1

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


Re: [PATCH v5] staging: rtl8192e: Aligning the * on each line in block comments

2017-02-09 Thread Greg KH
On Thu, Feb 09, 2017 at 05:13:34PM +0530, Arushi wrote:
> This patch fixes the issue by aligning the * on each line in block comments.
> 
> Signed-off-by: Arushi 

Do you really sign documents with just this single word for a name?

> ---
> [Patch v1] is rejected as the changes done is not correct and is not 
> following the linux kernel coding style in file 
> drivers/staging/speakup/speakup_decpc.c as * on each line in block was not 
> correctly alligned.[Patch v2] is rejected for not to mention the cause of 
> rejection of [Patch v1] but warnings is corrected.The cause of rejection of 
> [Patch v3] is that the mention of the cause was not in the correct format and 
> is not descriptive.In [Patch v4] didn't send patch message to all the list 
> members so asked to again repatch it.

Please properly use line-feeds, this is unreadable.

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


[PATCH v5] staging: rtl8192e: Aligning the * on each line in block comments

2017-02-09 Thread Arushi
This patch fixes the issue by aligning the * on each line in block comments.

Signed-off-by: Arushi 
---
[Patch v1] is rejected as the changes done is not correct and is not following 
the linux kernel coding style in file drivers/staging/speakup/speakup_decpc.c 
as * on each line in block was not correctly alligned.[Patch v2] is rejected 
for not to mention the cause of rejection of [Patch v1] but warnings is 
corrected.The cause of rejection of [Patch v3] is that the mention of the cause 
was not in the correct format and is not descriptive.In [Patch v4] didn't send 
patch message to all the list members so asked to again repatch it.
---
 drivers/staging/speakup/fakekey.c| 10 +-
 drivers/staging/speakup/i18n.c   | 14 +++---
 drivers/staging/speakup/main.c   |  2 +-
 drivers/staging/speakup/speakup_acntsa.c |  2 +-
 drivers/staging/speakup/speakup_apollo.c |  2 +-
 drivers/staging/speakup/speakup_decext.c |  2 +-
 drivers/staging/speakup/speakup_decpc.c  |  4 ++--
 drivers/staging/speakup/speakup_dtlk.c   |  2 +-
 drivers/staging/speakup/speakup_dtlk.h   | 10 +-
 drivers/staging/speakup/speakup_ltlk.c   |  2 +-
 10 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/drivers/staging/speakup/fakekey.c 
b/drivers/staging/speakup/fakekey.c
index 8f058b42f68d..d76da0a1382c 100644
--- a/drivers/staging/speakup/fakekey.c
+++ b/drivers/staging/speakup/fakekey.c
@@ -63,8 +63,8 @@ void speakup_remove_virtual_keyboard(void)
 }
 
 /*
-* Send a simulated down-arrow to the application.
-*/
+ * Send a simulated down-arrow to the application.
+ */
 void speakup_fake_down_arrow(void)
 {
unsigned long flags;
@@ -87,9 +87,9 @@ void speakup_fake_down_arrow(void)
 }
 
 /*
-* Are we handling a simulated keypress on the current CPU?
-* Returns a boolean.
-*/
+ * Are we handling a simulated keypress on the current CPU?
+ * Returns a boolean.
+ */
 bool speakup_fake_key_pressed(void)
 {
return this_cpu_read(reporting_keystroke);
diff --git a/drivers/staging/speakup/i18n.c b/drivers/staging/speakup/i18n.c
index 8960079e4d60..2f9b3df7f78d 100644
--- a/drivers/staging/speakup/i18n.c
+++ b/drivers/staging/speakup/i18n.c
@@ -401,7 +401,7 @@ char *spk_msg_get(enum msg_index_t index)
  * Finds the start of the next format specifier in the argument string.
  * Return value: pointer to start of format
  * specifier, or NULL if no specifier exists.
-*/
+ */
 static char *next_specifier(char *input)
 {
int found = 0;
@@ -450,7 +450,7 @@ static char *skip_width(char *input)
  * Note that this code only accepts a handful of conversion specifiers:
  * c d s x and ld.  Not accidental; these are exactly the ones used in
  * the default group of formatted messages.
-*/
+ */
 static char *skip_conversion(char *input)
 {
if ((input[0] == 'l') && (input[1] == 'd'))
@@ -463,7 +463,7 @@ static char *skip_conversion(char *input)
 /*
  * Function: find_specifier_end
  * Return a pointer to the end of the format specifier.
-*/
+ */
 static char *find_specifier_end(char *input)
 {
input++;/* Advance over %. */
@@ -478,7 +478,7 @@ static char *find_specifier_end(char *input)
  * Compare the format specifiers pointed to by *input1 and *input2.
  * Return 1 if they are the same, 0 otherwise.  Advance *input1 and *input2
  * so that they point to the character following the end of the specifier.
-*/
+ */
 static int compare_specifiers(char **input1, char **input2)
 {
int same = 0;
@@ -500,7 +500,7 @@ static int compare_specifiers(char **input1, char **input2)
  * Check that two format strings contain the same number of format specifiers,
  * and that the order of specifiers is the same in both strings.
  * Return 1 if the condition holds, 0 if it doesn't.
-*/
+ */
 static int fmt_validate(char *template, char *user)
 {
int valid = 1;
@@ -537,7 +537,7 @@ static int fmt_validate(char *template, char *user)
  * Failure conditions:
  * -EINVAL -  Invalid format specifiers in formatted message or illegal index.
  * -ENOMEM -  Unable to allocate memory.
-*/
+ */
 ssize_t spk_msg_set(enum msg_index_t index, char *text, size_t length)
 {
int rc = 0;
@@ -573,7 +573,7 @@ ssize_t spk_msg_set(enum msg_index_t index, char *text, 
size_t length)
 /*
  * Find a message group, given its name.  Return a pointer to the structure
  * if found, or NULL otherwise.
-*/
+ */
 struct msg_group_t *spk_find_msg_group(const char *group_name)
 {
struct msg_group_t *group = NULL;
diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index bf539d38..c2f70ef5b9b3 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -16,7 +16,7 @@
  *  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.
-*/

[PATCH] staging: rtl8192e: Aligning the * on each line in block comments

2017-02-09 Thread Arushi
This patch fixes the issue by aligning the * on each line in block comments.

Signed-off-by: Arushi 
---
[Patch v1] is rejected as the changes done is not correct and is not following 
the linux kernel coding style in file drivers/staging/speakup/speakup_decpc.c 
as * on each line in block was not correctly alligned.[Patch v2] is rejected 
for not to mention the cause of rejection of [Patch v1] but warnings is 
corrected.The cause of rejection of [Patch v3] is that the mention of the cause 
was not in the correct format and is not descriptive.In [Patch v4] didn't send 
patch message to all the list members so asked to again repatch it.
---
 drivers/staging/speakup/fakekey.c| 10 +-
 drivers/staging/speakup/i18n.c   | 14 +++---
 drivers/staging/speakup/main.c   |  2 +-
 drivers/staging/speakup/speakup_acntsa.c |  2 +-
 drivers/staging/speakup/speakup_apollo.c |  2 +-
 drivers/staging/speakup/speakup_decext.c |  2 +-
 drivers/staging/speakup/speakup_decpc.c  |  4 ++--
 drivers/staging/speakup/speakup_dtlk.c   |  2 +-
 drivers/staging/speakup/speakup_dtlk.h   | 10 +-
 drivers/staging/speakup/speakup_ltlk.c   |  2 +-
 10 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/drivers/staging/speakup/fakekey.c 
b/drivers/staging/speakup/fakekey.c
index 8f058b42f68d..d76da0a1382c 100644
--- a/drivers/staging/speakup/fakekey.c
+++ b/drivers/staging/speakup/fakekey.c
@@ -63,8 +63,8 @@ void speakup_remove_virtual_keyboard(void)
 }
 
 /*
-* Send a simulated down-arrow to the application.
-*/
+ * Send a simulated down-arrow to the application.
+ */
 void speakup_fake_down_arrow(void)
 {
unsigned long flags;
@@ -87,9 +87,9 @@ void speakup_fake_down_arrow(void)
 }
 
 /*
-* Are we handling a simulated keypress on the current CPU?
-* Returns a boolean.
-*/
+ * Are we handling a simulated keypress on the current CPU?
+ * Returns a boolean.
+ */
 bool speakup_fake_key_pressed(void)
 {
return this_cpu_read(reporting_keystroke);
diff --git a/drivers/staging/speakup/i18n.c b/drivers/staging/speakup/i18n.c
index 8960079e4d60..2f9b3df7f78d 100644
--- a/drivers/staging/speakup/i18n.c
+++ b/drivers/staging/speakup/i18n.c
@@ -401,7 +401,7 @@ char *spk_msg_get(enum msg_index_t index)
  * Finds the start of the next format specifier in the argument string.
  * Return value: pointer to start of format
  * specifier, or NULL if no specifier exists.
-*/
+ */
 static char *next_specifier(char *input)
 {
int found = 0;
@@ -450,7 +450,7 @@ static char *skip_width(char *input)
  * Note that this code only accepts a handful of conversion specifiers:
  * c d s x and ld.  Not accidental; these are exactly the ones used in
  * the default group of formatted messages.
-*/
+ */
 static char *skip_conversion(char *input)
 {
if ((input[0] == 'l') && (input[1] == 'd'))
@@ -463,7 +463,7 @@ static char *skip_conversion(char *input)
 /*
  * Function: find_specifier_end
  * Return a pointer to the end of the format specifier.
-*/
+ */
 static char *find_specifier_end(char *input)
 {
input++;/* Advance over %. */
@@ -478,7 +478,7 @@ static char *find_specifier_end(char *input)
  * Compare the format specifiers pointed to by *input1 and *input2.
  * Return 1 if they are the same, 0 otherwise.  Advance *input1 and *input2
  * so that they point to the character following the end of the specifier.
-*/
+ */
 static int compare_specifiers(char **input1, char **input2)
 {
int same = 0;
@@ -500,7 +500,7 @@ static int compare_specifiers(char **input1, char **input2)
  * Check that two format strings contain the same number of format specifiers,
  * and that the order of specifiers is the same in both strings.
  * Return 1 if the condition holds, 0 if it doesn't.
-*/
+ */
 static int fmt_validate(char *template, char *user)
 {
int valid = 1;
@@ -537,7 +537,7 @@ static int fmt_validate(char *template, char *user)
  * Failure conditions:
  * -EINVAL -  Invalid format specifiers in formatted message or illegal index.
  * -ENOMEM -  Unable to allocate memory.
-*/
+ */
 ssize_t spk_msg_set(enum msg_index_t index, char *text, size_t length)
 {
int rc = 0;
@@ -573,7 +573,7 @@ ssize_t spk_msg_set(enum msg_index_t index, char *text, 
size_t length)
 /*
  * Find a message group, given its name.  Return a pointer to the structure
  * if found, or NULL otherwise.
-*/
+ */
 struct msg_group_t *spk_find_msg_group(const char *group_name)
 {
struct msg_group_t *group = NULL;
diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index bf539d38..c2f70ef5b9b3 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -16,7 +16,7 @@
  *  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.
-*/

[PATCH] Staging: rtl8192e: remove redundant null check on array alg

2017-02-09 Thread Colin King
From: Colin Ian King 

u.crypt.alg is an array of u8 integers and hence the null check on
this array is redundant and can be removed.

Detected with CoverityScan, CID#146583 ("Array compared against 0")

Signed-off-by: Colin Ian King 
---
 drivers/staging/rtl8192e/rtllib_softmac.c | 32 +++
 1 file changed, 15 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c 
b/drivers/staging/rtl8192e/rtllib_softmac.c
index 1430ba2..eeda17d 100644
--- a/drivers/staging/rtl8192e/rtllib_softmac.c
+++ b/drivers/staging/rtl8192e/rtllib_softmac.c
@@ -3365,23 +3365,21 @@ static int rtllib_wpa_set_encryption(struct 
rtllib_device *ieee,
} else
sec.flags &= ~SEC_ACTIVE_KEY;
 
-   if (param->u.crypt.alg != NULL) {
-   memcpy(sec.keys[param->u.crypt.idx],
-  param->u.crypt.key,
-  param->u.crypt.key_len);
-   sec.key_sizes[param->u.crypt.idx] = param->u.crypt.key_len;
-   sec.flags |= (1 << param->u.crypt.idx);
-
-   if (strcmp(param->u.crypt.alg, "R-WEP") == 0) {
-   sec.flags |= SEC_LEVEL;
-   sec.level = SEC_LEVEL_1;
-   } else if (strcmp(param->u.crypt.alg, "R-TKIP") == 0) {
-   sec.flags |= SEC_LEVEL;
-   sec.level = SEC_LEVEL_2;
-   } else if (strcmp(param->u.crypt.alg, "R-CCMP") == 0) {
-   sec.flags |= SEC_LEVEL;
-   sec.level = SEC_LEVEL_3;
-   }
+   memcpy(sec.keys[param->u.crypt.idx],
+  param->u.crypt.key,
+  param->u.crypt.key_len);
+   sec.key_sizes[param->u.crypt.idx] = param->u.crypt.key_len;
+   sec.flags |= (1 << param->u.crypt.idx);
+
+   if (strcmp(param->u.crypt.alg, "R-WEP") == 0) {
+   sec.flags |= SEC_LEVEL;
+   sec.level = SEC_LEVEL_1;
+   } else if (strcmp(param->u.crypt.alg, "R-TKIP") == 0) {
+   sec.flags |= SEC_LEVEL;
+   sec.level = SEC_LEVEL_2;
+   } else if (strcmp(param->u.crypt.alg, "R-CCMP") == 0) {
+   sec.flags |= SEC_LEVEL;
+   sec.level = SEC_LEVEL_3;
}
  done:
if (ieee->set_security)
-- 
2.10.2

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


Re: [PATCH] staging: comedi: Fix incorrect type assignment

2017-02-09 Thread Karthik Nayak
Hello,

On Thu, Feb 9, 2017 at 4:34 PM, Greg KH  wrote:
> On Thu, Feb 09, 2017 at 01:53:56AM +0530, Karthik Nayak wrote:
>> This patch fixes the following sparse error:
>> drivers/staging/comedi/drivers//ni_pcimio.c:1229:32: warning: incorrect type 
>> in assignment (different base types)
>> drivers/staging/comedi/drivers//ni_pcimio.c:1229:32:expected restricted 
>> __be32 [usertype] serial_number
>> drivers/staging/comedi/drivers//ni_pcimio.c:1229:32:got unsigned int
>>
>> This is done by removing the whole code block, since the variable
>> 'serial_number' is only assigned but never used.
>>
>> Helped-by: Ian Abbott 
>
> There's no such tag, sorry :(
>

Ah! This is common back in the Git community, I shall drop it :)

> And does this obsolete all of your other ones?  Please make it obvious
> what I am supposed to do here.
>
> I've now dropped all of these patches from my queue.  please resend the
> proper one.
>

That works! I'll send the patch again, lets ignore the previous patches.


On Thu, Feb 9, 2017 at 4:52 PM, Ian Abbott  wrote:
> To add to that, I think the emphasis of the patch title and description
> should now be on the removal of serial_number, with fixing the sparse error
> as a useful side-effect/inspiration.  The patch title should also mention
> ni_pcimio.
>
> Thanks,
> Ian.

Makes sense, will make the necessary changes.


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


Re: [PATCH] staging: comedi: Fix incorrect type assignment

2017-02-09 Thread Ian Abbott

On 09/02/2017 11:04, Greg KH wrote:

On Thu, Feb 09, 2017 at 01:53:56AM +0530, Karthik Nayak wrote:

This patch fixes the following sparse error:
drivers/staging/comedi/drivers//ni_pcimio.c:1229:32: warning: incorrect type in 
assignment (different base types)
drivers/staging/comedi/drivers//ni_pcimio.c:1229:32:expected restricted 
__be32 [usertype] serial_number
drivers/staging/comedi/drivers//ni_pcimio.c:1229:32:got unsigned int

This is done by removing the whole code block, since the variable
'serial_number' is only assigned but never used.

Helped-by: Ian Abbott 


There's no such tag, sorry :(

And does this obsolete all of your other ones?  Please make it obvious
what I am supposed to do here.

I've now dropped all of these patches from my queue.  please resend the
proper one.

thanks,

greg k-h



To add to that, I think the emphasis of the patch title and description 
should now be on the removal of serial_number, with fixing the sparse 
error as a useful side-effect/inspiration.  The patch title should also 
mention ni_pcimio.


Thanks,
Ian.

--
-=( 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


Re: [PATCH] staging: fbtft: fix some coding style issues

2017-02-09 Thread Greg KH
On Thu, Feb 09, 2017 at 12:04:01PM +0100, Gioh Kim wrote:
> There are many coding style issues.
> I fixed only obvious issues.
> Fixied issues:
> - Use 4 digit octal (0777) not decimal permissions
> - line over 80 characters
> - Avoid unnecessary line continuations

Again, only do one thing per patch.

Now dropped.

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


Re: [PATCH] staging: greybus: es2.c: fix some coding style issues

2017-02-09 Thread Greg KH
On Thu, Feb 09, 2017 at 12:04:59PM +0100, Gioh Kim wrote:
> Fix two coding style issues:
> 1. line over 80 characters
> 2. Octal permissions are preffered than symbolic ones

I just said not to do this, why resend it?

Also, you forgot to include the correct people and mailing list on the
patch, please fix up.

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


[PATCH] staging: greybus: es2.c: fix some coding style issues

2017-02-09 Thread Gioh Kim
Fix two coding style issues:
1. line over 80 characters
2. Octal permissions are preffered than symbolic ones

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

diff --git a/drivers/staging/greybus/es2.c b/drivers/staging/greybus/es2.c
index 93afd93..f7b24e0 100644
--- a/drivers/staging/greybus/es2.c
+++ b/drivers/staging/greybus/es2.c
@@ -1085,7 +1085,8 @@ static void apb_log_get(struct es2_ap_dev *es2, char *buf)
retval = usb_control_msg(es2->usb_dev,
usb_rcvctrlpipe(es2->usb_dev, 0),
GB_APB_REQUEST_LOG,
-   USB_DIR_IN | USB_TYPE_VENDOR | 
USB_RECIP_INTERFACE,
+   USB_DIR_IN | USB_TYPE_VENDOR |
+   USB_RECIP_INTERFACE,
0x00, 0x00,
buf,
APB1_LOG_MSG_SIZE,
@@ -1151,7 +1152,7 @@ static void usb_log_enable(struct es2_ap_dev *es2)
if (IS_ERR(es2->apb_log_task))
return;
/* XXX We will need to rename this per APB */
-   es2->apb_log_dentry = debugfs_create_file("apb_log", S_IRUGO,
+   es2->apb_log_dentry = debugfs_create_file("apb_log", 0444,
gb_debugfs_get(), es2,
_log_fops);
 }
@@ -1408,7 +1409,7 @@ static int ap_probe(struct usb_interface *interface,
 
/* XXX We will need to rename this per APB */
es2->apb_log_enable_dentry = debugfs_create_file("apb_log_enable",
-   (S_IWUSR | S_IRUGO),
+   0644,
gb_debugfs_get(), es2,
_log_enable_fops);
 
-- 
2.5.0

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


[PATCH] staging: fbtft: fix some coding style issues

2017-02-09 Thread Gioh Kim
There are many coding style issues.
I fixed only obvious issues.
Fixied issues:
- Use 4 digit octal (0777) not decimal permissions
- line over 80 characters
- Avoid unnecessary line continuations

I checked all files were built without error.

Signed-off-by: Gioh Kim 
---
 drivers/staging/fbtft/fb_hx8340bn.c  |  2 +-
 drivers/staging/fbtft/fb_pcd8544.c   |  4 ++--
 drivers/staging/fbtft/fb_ssd1289.c   |  2 +-
 drivers/staging/fbtft/fb_ssd1306.c   |  3 ++-
 drivers/staging/fbtft/fb_ssd1331.c   | 12 +++-
 drivers/staging/fbtft/fb_ssd1351.c   |  8 
 drivers/staging/fbtft/fb_tls8204.c   |  2 +-
 drivers/staging/fbtft/fb_uc1611.c| 12 ++--
 drivers/staging/fbtft/fb_watterott.c |  2 +-
 drivers/staging/fbtft/fbtft-core.c   |  5 +++--
 drivers/staging/fbtft/fbtft-sysfs.c  | 10 +++---
 drivers/staging/fbtft/fbtft_device.c | 38 ++--
 drivers/staging/fbtft/flexfb.c   | 21 +---
 13 files changed, 68 insertions(+), 53 deletions(-)

diff --git a/drivers/staging/fbtft/fb_hx8340bn.c 
b/drivers/staging/fbtft/fb_hx8340bn.c
index 9970ed7..c24331c 100644
--- a/drivers/staging/fbtft/fb_hx8340bn.c
+++ b/drivers/staging/fbtft/fb_hx8340bn.c
@@ -37,7 +37,7 @@
"3 3 17 8 4 7 05 7 6 0 3 1 6 0 0 "
 
 static bool emulate;
-module_param(emulate, bool, 0);
+module_param(emulate, bool, );
 MODULE_PARM_DESC(emulate, "Force emulation in 9-bit mode");
 
 static int init_display(struct fbtft_par *par)
diff --git a/drivers/staging/fbtft/fb_pcd8544.c 
b/drivers/staging/fbtft/fb_pcd8544.c
index a4710dc..636cc83 100644
--- a/drivers/staging/fbtft/fb_pcd8544.c
+++ b/drivers/staging/fbtft/fb_pcd8544.c
@@ -33,11 +33,11 @@
 #define DEFAULT_GAMMA  "40" /* gamma controls the contrast in this driver */
 
 static unsigned int tc;
-module_param(tc, uint, 0);
+module_param(tc, uint, );
 MODULE_PARM_DESC(tc, "TC[1:0] Temperature coefficient: 0-3 (default: 0)");
 
 static unsigned int bs = 4;
-module_param(bs, uint, 0);
+module_param(bs, uint, );
 MODULE_PARM_DESC(bs, "BS[2:0] Bias voltage level: 0-7 (default: 4)");
 
 static int init_display(struct fbtft_par *par)
diff --git a/drivers/staging/fbtft/fb_ssd1289.c 
b/drivers/staging/fbtft/fb_ssd1289.c
index 25f9fbe..6dc0858 100644
--- a/drivers/staging/fbtft/fb_ssd1289.c
+++ b/drivers/staging/fbtft/fb_ssd1289.c
@@ -30,7 +30,7 @@
"02 03 2 5 7 5 4 2 4 2"
 
 static unsigned int reg11 = 0x6040;
-module_param(reg11, uint, 0);
+module_param(reg11, uint, );
 MODULE_PARM_DESC(reg11, "Register 11h value");
 
 static int init_display(struct fbtft_par *par)
diff --git a/drivers/staging/fbtft/fb_ssd1306.c 
b/drivers/staging/fbtft/fb_ssd1306.c
index 76f7da3..af22f98 100644
--- a/drivers/staging/fbtft/fb_ssd1306.c
+++ b/drivers/staging/fbtft/fb_ssd1306.c
@@ -193,7 +193,8 @@ static int write_vmem(struct fbtft_par *par, size_t offset, 
size_t len)
for (y = 0; y < yres / 8; y++) {
*buf = 0x00;
for (i = 0; i < 8; i++)
-   *buf |= (vmem16[(y * 8 + i) * xres + x] ? 1 : 
0) << i;
+   *buf |= (vmem16[(y * 8 + i) * xres + x] ?
+1 : 0) << i;
buf++;
}
}
diff --git a/drivers/staging/fbtft/fb_ssd1331.c 
b/drivers/staging/fbtft/fb_ssd1331.c
index 1d74ac1..5229d67 100644
--- a/drivers/staging/fbtft/fb_ssd1331.c
+++ b/drivers/staging/fbtft/fb_ssd1331.c
@@ -67,7 +67,9 @@ static void write_reg8_bus8(struct fbtft_par *par, int len, 
...)
for (i = 0; i < len; i++)
buf[i] = (u8)va_arg(args, unsigned int);
va_end(args);
-   fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par, par->info->device, 
u8, buf, len, "%s: ", __func__);
+   fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par,
+ par->info->device, u8,
+ buf, len, "%s: ", __func__);
}
 
va_start(args, len);
@@ -130,16 +132,16 @@ static int set_gamma(struct fbtft_par *par, unsigned long 
*curves)
for (i = 0; i < 63; i++) {
if (i > 0 && curves[i] < 2) {
dev_err(par->info->device,
-   "Illegal value in Grayscale Lookup Table at 
index %d. " \
-   "Must be greater than 1\n", i);
+   "Illegal value in Grayscale Lookup Table at 
index %d. Must be greater than 1\n",
+   i);
return -EINVAL;
}
acc += curves[i];
tmp[i] = acc;
if (acc > 180) {
dev_err(par->info->device,
-   "Illegal value(s) in Grayscale Lookup Table. " \
-   "At index=%d, the accumulated 

[PATCH] staging: rtl8192u: remove redundant null check on array alg

2017-02-09 Thread Colin King
From: Colin Ian King 

u.crypt.alg is an array of u8 integers and hence the null check on
this array is redundant and can be removed.

Detected with CoverityScan, CID#143214 ("Array compared against 0")

Signed-off-by: Colin Ian King 
---
 .../staging/rtl8192u/ieee80211/ieee80211_softmac.c | 32 ++
 1 file changed, 15 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
index 844e257..02b9f7a 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
@@ -3056,23 +3056,21 @@ static int ieee80211_wpa_set_encryption(struct 
ieee80211_device *ieee,
} else
sec.flags &= ~SEC_ACTIVE_KEY;
 
-   if (param->u.crypt.alg != NULL) {
-   memcpy(sec.keys[param->u.crypt.idx],
-  param->u.crypt.key,
-  param->u.crypt.key_len);
-   sec.key_sizes[param->u.crypt.idx] = param->u.crypt.key_len;
-   sec.flags |= (1 << param->u.crypt.idx);
-
-   if (strcmp(param->u.crypt.alg, "WEP") == 0) {
-   sec.flags |= SEC_LEVEL;
-   sec.level = SEC_LEVEL_1;
-   } else if (strcmp(param->u.crypt.alg, "TKIP") == 0) {
-   sec.flags |= SEC_LEVEL;
-   sec.level = SEC_LEVEL_2;
-   } else if (strcmp(param->u.crypt.alg, "CCMP") == 0) {
-   sec.flags |= SEC_LEVEL;
-   sec.level = SEC_LEVEL_3;
-   }
+   memcpy(sec.keys[param->u.crypt.idx],
+  param->u.crypt.key,
+  param->u.crypt.key_len);
+   sec.key_sizes[param->u.crypt.idx] = param->u.crypt.key_len;
+   sec.flags |= (1 << param->u.crypt.idx);
+
+   if (strcmp(param->u.crypt.alg, "WEP") == 0) {
+   sec.flags |= SEC_LEVEL;
+   sec.level = SEC_LEVEL_1;
+   } else if (strcmp(param->u.crypt.alg, "TKIP") == 0) {
+   sec.flags |= SEC_LEVEL;
+   sec.level = SEC_LEVEL_2;
+   } else if (strcmp(param->u.crypt.alg, "CCMP") == 0) {
+   sec.flags |= SEC_LEVEL;
+   sec.level = SEC_LEVEL_3;
}
  done:
if (ieee->set_security)
-- 
2.10.2

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


Re: [PATCH v3 1/2] staging: omap4iss: fix multiline comment style

2017-02-09 Thread Greg KH
On Tue, Feb 07, 2017 at 05:40:57PM +0200, Avraham Shukron wrote:
> Signed-off-by: Avraham Shukron 
> ---
>  drivers/staging/media/omap4iss/iss_video.c | 38 
> --
>  1 file changed, 25 insertions(+), 13 deletions(-)

Again, I don't take patches with no changelog text :(
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: comedi: Fix incorrect type assignment

2017-02-09 Thread Greg KH
On Thu, Feb 09, 2017 at 01:53:56AM +0530, Karthik Nayak wrote:
> This patch fixes the following sparse error:
> drivers/staging/comedi/drivers//ni_pcimio.c:1229:32: warning: incorrect type 
> in assignment (different base types)
> drivers/staging/comedi/drivers//ni_pcimio.c:1229:32:expected restricted 
> __be32 [usertype] serial_number
> drivers/staging/comedi/drivers//ni_pcimio.c:1229:32:got unsigned int
> 
> This is done by removing the whole code block, since the variable
> 'serial_number' is only assigned but never used.
> 
> Helped-by: Ian Abbott 

There's no such tag, sorry :(

And does this obsolete all of your other ones?  Please make it obvious
what I am supposed to do here.

I've now dropped all of these patches from my queue.  please resend the
proper one.

thanks,

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


Re: [V2] android: binder: use VM_ALLOC to get vm area

2017-02-09 Thread Greg KH
On Thu, Feb 09, 2017 at 06:30:02PM +0800, Ganesh Mahendran wrote:
> Hi, Greg:
> 
> 2017-02-09 18:17 GMT+08:00 Greg KH :
> > On Thu, Feb 09, 2017 at 05:54:03PM +0800, Ganesh Mahendran wrote:
> >> A gentle ping.
> >
> > I don't see a patch here that can be accepted, what are you asking for
> > a response from?
> 
> I sent a patch before:
> https://patchwork.kernel.org/patch/9429257/

I don't use patchwork, please respond to the patch you are referring to,
or resend it.

thanks,

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


Re: [V2] android: binder: use VM_ALLOC to get vm area

2017-02-09 Thread Ganesh Mahendran
Hi, Greg:

2017-02-09 18:17 GMT+08:00 Greg KH :
> On Thu, Feb 09, 2017 at 05:54:03PM +0800, Ganesh Mahendran wrote:
>> A gentle ping.
>
> I don't see a patch here that can be accepted, what are you asking for
> a response from?

I sent a patch before:
https://patchwork.kernel.org/patch/9429257/

Please help to review.

Thanks.

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


[PATCH v2] staging: rtl8712: rtl8712: fixed missing conversion to le32

2017-02-09 Thread Carlos Palminha
Fixed missing conversion to le32, detected by sparse
(invalid assignment from int to __le32)

Signed-off-by: Carlos Palminha 
---
v1->v2:
missed sob line (too late in the night...)

 drivers/staging/rtl8712/rtl8712_xmit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8712/rtl8712_xmit.c 
b/drivers/staging/rtl8712/rtl8712_xmit.c
index 041508d6ec6d..4231a0a83097 100644
--- a/drivers/staging/rtl8712/rtl8712_xmit.c
+++ b/drivers/staging/rtl8712/rtl8712_xmit.c
@@ -573,7 +573,7 @@ static void update_txdesc(struct xmit_frame *pxmitframe, 
uint *pmem, int sz)
}
} else if (pxmitframe->frame_tag == MGNT_FRAMETAG) {
/* offset 4 */
-   ptxdesc->txdw1 |= (0x05) & 0x1f;/*CAM_ID(MAC_ID), default=5;*/
+   ptxdesc->txdw1 |= cpu_to_le32((0x05) & 0x1f);/*CAM_ID(MAC_ID), 
default=5;*/
qsel = (uint)(pattrib->qsel & 0x001f);
ptxdesc->txdw1 |= cpu_to_le32((qsel << QSEL_SHT) & 0x1f00);
ptxdesc->txdw1 |= cpu_to_le32(BIT(16));/* Non-QoS */
--
2.11.0

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


Re: [V2] android: binder: use VM_ALLOC to get vm area

2017-02-09 Thread Greg KH
On Thu, Feb 09, 2017 at 05:54:03PM +0800, Ganesh Mahendran wrote:
> A gentle ping.

I don't see a patch here that can be accepted, what are you asking for
a response from?

confused,

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


Re: [V2] android: binder: use VM_ALLOC to get vm area

2017-02-09 Thread Ganesh Mahendran
A gentle ping.

Thanks.

2016-11-15 21:18 GMT+08:00 Ganesh Mahendran :
> Hi, Greg
>
> 2016-11-15 18:18 GMT+08:00 Greg KH :
>> On Tue, Nov 15, 2016 at 05:55:39PM +0800, Ganesh Mahendran wrote:
>>> VM_IOREMAP is used to access hardware through a mechanism called
>>> I/O mapped memory. Android binder is a IPC machanism which will
>>> not access I/O memory.
>>>
>>> Also VM_IOREMAP has alignment requiement which may not needed in
>>> binder.
>>> __get_vm_area_node()
>>> {
>>> ...
>>> if (flags & VM_IOREMAP)
>>> align = 1ul << clamp_t(int, fls_long(size),
>>>PAGE_SHIFT, IOREMAP_MAX_ORDER);
>>> ...
>>> }
>>>
>>> This patch use VM_ALLOC to get vm area.
>>>
>>> Below is the throughput test result:
>>>
>>>   # ./binderThroughputTest -w 100
>>>   I run this command 10 times:
>>>beforeafter
>>>   average iterations per sec:  11199.9   11886.9
>>>
>>> No performance regression found throgh binder test.
>>>
>>> Signed-off-by: Ganesh Mahendran 
>>> ---
>>>  drivers/android/binder.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> What changed from v1?
>
> Sorry for missing the change information.
>
> In V2, I run the binder test. And there is no side effect with this
> patch.
>
>>
>> Always list that below the --- line.
>
> Thanks for reminder.
>
>>
>> thanks,
>>
>> greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v3 21/24] media: imx: Add MIPI CSI-2 Receiver subdev driver

2017-02-09 Thread Philipp Zabel
On Wed, 2017-02-08 at 15:23 -0800, Steve Longerbeam wrote:
[...]
> >> +
> >> +static int imxcsi2_get_fmt(struct v4l2_subdev *sd,
> >> + struct v4l2_subdev_pad_config *cfg,
> >> + struct v4l2_subdev_format *sdformat)
> >> +{
> >> +  struct imxcsi2_dev *csi2 = sd_to_dev(sd);
> >> +
> >> +  sdformat->format = csi2->format_mbus;
> > The output formats are different from the input formats, see the media
> > bus format discussion in the other thread. The input pad is the MIPI
> > CSI-2 bus, but the four output pads are connected to the muxes / CSIs
> > via a 16-bit parallel bus.
> >
> > So if the input format is UYVY8_1X16, for example, the output should be
> > set to UYVY8_2X8.
> 
> Since the output buses from the CSI2IPU gasket are 16-bit
> parallel buses, shouldn't an input format UYVY8_1X16 also be
> the same at the output?

I looked at the reference manual again, and I think I have read this
incorrectly, probably confused by the coloring in Figure 19-10 "YUV422-8
data reception" in the CSI2IPU chapter. It looks like indeed the 16-bit
bus carries UYVY8_1X16, whereas the internal 32-bit bus between MIPI
CSI-2 decoder and the CSI2IPU carries two samples (complete UYVY) per
pixel clock.
So UYVY is straight forward. It's the YUV420, RGB, and RAW formats that
would be interesting to describe correctly.

regards
Philipp

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