[PATCH] powerpc: process.c: fix Kconfig typo

[Valentin Rothberg]

s/ALIVEC/ALTIVEC/

Signed-off-by: Valentin Rothberg 
---
 arch/powerpc/kernel/process.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 9e7c10fe205f..ce6dc61b15b2 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1012,7 +1012,7 @@ void restore_tm_state(struct pt_regs *regs)
/* Ensure that restore_math() will restore */
if (msr_diff & MSR_FP)
current->thread.load_fp = 1;
-#ifdef CONFIG_ALIVEC
+#ifdef CONFIG_ALTIVEC
if (cpu_has_feature(CPU_FTR_ALTIVEC) && msr_diff & MSR_VEC)
current->thread.load_vec = 1;
 #endif
-- 
2.9.3

[PATCH] powerpc: process.c: fix Kconfig typo

[Valentin Rothberg]

s/ALIVEC/ALTIVEC/

Signed-off-by: Valentin Rothberg 
---
 arch/powerpc/kernel/process.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 9e7c10fe205f..ce6dc61b15b2 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1012,7 +1012,7 @@ void restore_tm_state(struct pt_regs *regs)
/* Ensure that restore_math() will restore */
if (msr_diff & MSR_FP)
current->thread.load_fp = 1;
-#ifdef CONFIG_ALIVEC
+#ifdef CONFIG_ALTIVEC
if (cpu_has_feature(CPU_FTR_ALTIVEC) && msr_diff & MSR_VEC)
current->thread.load_vec = 1;
 #endif
-- 
2.9.3

Re: [PATCH v4 10/12] dax: add struct iomap based DAX PMD support

[Jan Kara]

On Tue 04-10-16 09:39:48, Ross Zwisler wrote:
> > The gfp_mask that propagates from __do_fault() or do_page_mkwrite() is fine
> > because at that point it is correct. But once we grab filesystem locks
> > which are not reclaim safe, we should update vmf->gfp_mask we pass further
> > down into DAX code to not contain __GFP_FS (that's a bug we apparently have
> > there). And inside DAX code, we definitely are not generally safe to add
> > __GFP_FS to mapping_gfp_mask(). Maybe we'd be better off propagating struct
> > vm_fault into this function, using passed gfp_mask there and make sure
> > callers update gfp_mask as appropriate.
> 
> Yep, that makes sense to me.  In reviewing your set it also occurred to me 
> that
> we might want to stick a struct vm_area_struct *vma pointer in the vmf, since
> you always need a vma when you are using a vmf, but we pass them as a pair
> everywhere.

Actually, vma pointer will be in struct vm_fault after my DAX
write-protection series. So once that lands, we can clean up whatever
duplicit function parameters...

Honza

-- 
Jan Kara 
SUSE Labs, CR

Re: [PATCH v4 10/12] dax: add struct iomap based DAX PMD support

[Jan Kara]

On Tue 04-10-16 09:39:48, Ross Zwisler wrote:
> > The gfp_mask that propagates from __do_fault() or do_page_mkwrite() is fine
> > because at that point it is correct. But once we grab filesystem locks
> > which are not reclaim safe, we should update vmf->gfp_mask we pass further
> > down into DAX code to not contain __GFP_FS (that's a bug we apparently have
> > there). And inside DAX code, we definitely are not generally safe to add
> > __GFP_FS to mapping_gfp_mask(). Maybe we'd be better off propagating struct
> > vm_fault into this function, using passed gfp_mask there and make sure
> > callers update gfp_mask as appropriate.
> 
> Yep, that makes sense to me.  In reviewing your set it also occurred to me 
> that
> we might want to stick a struct vm_area_struct *vma pointer in the vmf, since
> you always need a vma when you are using a vmf, but we pass them as a pair
> everywhere.

Actually, vma pointer will be in struct vm_fault after my DAX
write-protection series. So once that lands, we can clean up whatever
duplicit function parameters...

Honza

-- 
Jan Kara 
SUSE Labs, CR

Re: Regression in next with ext4 oops

[Jan Kara]

On Tue 04-10-16 15:56:39, Al Viro wrote:
> On Tue, Oct 04, 2016 at 11:00:41AM +0200, Jan Kara wrote:
> > Hi!
> > 
> > On Mon 03-10-16 16:30:55, Tony Lindgren wrote:
> > > I'm seeing a repeatable oops with Linux next while running
> > > update-initramfs, see below. I tried reverting commit 59aa5a3aeead
> > > ("fscrypto: make filename crypto functions return 0 on success")
> > > as that's the only commit changing ext4_htree_store_dirent, but
> > > that did not help.
> > > 
> > > Anybody else seeing something like this?
> > 
> > Never seen this but I suspect it is a fallout from Al's directory locking
> > changes. In particular ext4_htree_fill_tree() builds rb-tree of found
> > directory entries in file->private_data (and generally modifies the
> > structure stored there) but after Al's changes we don't have exclusive
> > access to struct file if I'm right so if two processes end up calling
> > getdents() for the same 'struct file' we are doomed.
> 
> RTFS.  We sure as hell *do* have exclusive access to struct file.  See
> /* POSIX.1-2008/SUSv4 Section XSI 2.9.7 */
> if (S_ISREG(inode->i_mode) || S_ISDIR(inode->i_mode))
> f->f_mode |= FMODE_ATOMIC_POS;
> in do_dentry_open() as well as
> if (file && (file->f_mode & FMODE_ATOMIC_POS)) {
> if (file_count(file) > 1) {
> v |= FDPUT_POS_UNLOCK;
> mutex_lock(>f_pos_lock);
> }
> }
> in __fdget_pos() and
> f = fdget_pos(fd);
> if (!f.file)
> return -EBADF;
> in getdents(2).

Yeah, sorry. I've misunderstood how the FMODE_ATOMIC_POS thing works...

Honza
-- 
Jan Kara 
SUSE Labs, CR

Re: Regression in next with ext4 oops

[Jan Kara]

On Tue 04-10-16 15:56:39, Al Viro wrote:
> On Tue, Oct 04, 2016 at 11:00:41AM +0200, Jan Kara wrote:
> > Hi!
> > 
> > On Mon 03-10-16 16:30:55, Tony Lindgren wrote:
> > > I'm seeing a repeatable oops with Linux next while running
> > > update-initramfs, see below. I tried reverting commit 59aa5a3aeead
> > > ("fscrypto: make filename crypto functions return 0 on success")
> > > as that's the only commit changing ext4_htree_store_dirent, but
> > > that did not help.
> > > 
> > > Anybody else seeing something like this?
> > 
> > Never seen this but I suspect it is a fallout from Al's directory locking
> > changes. In particular ext4_htree_fill_tree() builds rb-tree of found
> > directory entries in file->private_data (and generally modifies the
> > structure stored there) but after Al's changes we don't have exclusive
> > access to struct file if I'm right so if two processes end up calling
> > getdents() for the same 'struct file' we are doomed.
> 
> RTFS.  We sure as hell *do* have exclusive access to struct file.  See
> /* POSIX.1-2008/SUSv4 Section XSI 2.9.7 */
> if (S_ISREG(inode->i_mode) || S_ISDIR(inode->i_mode))
> f->f_mode |= FMODE_ATOMIC_POS;
> in do_dentry_open() as well as
> if (file && (file->f_mode & FMODE_ATOMIC_POS)) {
> if (file_count(file) > 1) {
> v |= FDPUT_POS_UNLOCK;
> mutex_lock(>f_pos_lock);
> }
> }
> in __fdget_pos() and
> f = fdget_pos(fd);
> if (!f.file)
> return -EBADF;
> in getdents(2).

Yeah, sorry. I've misunderstood how the FMODE_ATOMIC_POS thing works...

Honza
-- 
Jan Kara 
SUSE Labs, CR

Re: BUG_ON() in workingset_node_shadows_dec() triggers

[Willy Tarreau]

On Tue, Oct 04, 2016 at 08:29:00PM -0700, Linus Torvalds wrote:
> So what I think we should think about is:
> 
>  - extending the checkpatch warning to VM_BUG_ON too, to discourage new users.
> 
>  - look at making BUG_ON() simply be less lethal. Remove the
> unrechable(), reorganize how the string is stored, and make it act
> more like WARN_ON_ONCE() instead (it's the "rewind_stack_do_exit()"
> that ends up causing us to try to kill things, we *could* just try to
> stop doing that).
> 
>  - Instead of adding a BUG_ON_AND_HALT(), we could perhaps add a new
> FATAL_ERROR() thing that acts like the current BUG_ON, and *not* call
> it something similar (we don't want people doing mindless
> conversions!). And that's the one that would do the whole
> rewind_stack_do_exit() to kill the process.

I think instead we should completely remove any simple way to halt the
system and document how to do it. I've already seen some userland code
stuffed with thousands of assert() everywhere and their developers are
proud of this because their code looks clean and they show that they
care for all errors. But the cost of their stupidity doesn't seem to
affect them. Maybe they'll start to think about it the day they're
brought into a self-driven car and will realize that it'd better recover
from a failing flasher and not just crash in the middle of the highway.

Thus since their motives are just to easily write nice-looking code, I'd
simply force them to explicitly write their condition and the associated
printk() and panic() calls. It will become much more of a hassle and will
make their code less elegant, they should be much less tempted.

So I think that we'd rather run a huge sed all over the code to replace
BUG/BUG_ON with their WARN/WARN_ON equivalent. We'll very likely notice
a lot of new gcc warnings from code that was supposed not to every be
reachable, which will tell us a lot about some limited error checking
in these respective code parts.

Willy

Re: BUG_ON() in workingset_node_shadows_dec() triggers

[Willy Tarreau]

On Tue, Oct 04, 2016 at 08:29:00PM -0700, Linus Torvalds wrote:
> So what I think we should think about is:
> 
>  - extending the checkpatch warning to VM_BUG_ON too, to discourage new users.
> 
>  - look at making BUG_ON() simply be less lethal. Remove the
> unrechable(), reorganize how the string is stored, and make it act
> more like WARN_ON_ONCE() instead (it's the "rewind_stack_do_exit()"
> that ends up causing us to try to kill things, we *could* just try to
> stop doing that).
> 
>  - Instead of adding a BUG_ON_AND_HALT(), we could perhaps add a new
> FATAL_ERROR() thing that acts like the current BUG_ON, and *not* call
> it something similar (we don't want people doing mindless
> conversions!). And that's the one that would do the whole
> rewind_stack_do_exit() to kill the process.

I think instead we should completely remove any simple way to halt the
system and document how to do it. I've already seen some userland code
stuffed with thousands of assert() everywhere and their developers are
proud of this because their code looks clean and they show that they
care for all errors. But the cost of their stupidity doesn't seem to
affect them. Maybe they'll start to think about it the day they're
brought into a self-driven car and will realize that it'd better recover
from a failing flasher and not just crash in the middle of the highway.

Thus since their motives are just to easily write nice-looking code, I'd
simply force them to explicitly write their condition and the associated
printk() and panic() calls. It will become much more of a hassle and will
make their code less elegant, they should be much less tempted.

So I think that we'd rather run a huge sed all over the code to replace
BUG/BUG_ON with their WARN/WARN_ON equivalent. We'll very likely notice
a lot of new gcc warnings from code that was supposed not to every be
reachable, which will tell us a lot about some limited error checking
in these respective code parts.

Willy

[PATCH] watchdog: ath79_wdt: fix build failure

[Sudip Mukherjee]

The build of mips ath79_defconfig was failing with the error:
drivers/watchdog/ath79_wdt.c:164:5:
error: implicit declaration of function 'get_user'
drivers/watchdog/ath79_wdt.c:196:3:
error: implicit declaration of function 'copy_to_user'
drivers/watchdog/ath79_wdt.c:201:3:
error: implicit declaration of function 'put_user'

Quoting Al Viro - "another victim of indirect include chains"

Fixes: 58a8f3b69e07 ("mips: separate extable.h, switch module.h to it")
Signed-off-by: Sudip Mukherjee 
---

build log is at:
https://travis-ci.org/sudipm-mukherjee/parport/jobs/164834126

 drivers/watchdog/ath79_wdt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/watchdog/ath79_wdt.c b/drivers/watchdog/ath79_wdt.c
index 835d310..e2209bf 100644
--- a/drivers/watchdog/ath79_wdt.c
+++ b/drivers/watchdog/ath79_wdt.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define DRIVER_NAME"ath79-wdt"
 
-- 
1.9.1

[PATCH] watchdog: ath79_wdt: fix build failure

[Sudip Mukherjee]

The build of mips ath79_defconfig was failing with the error:
drivers/watchdog/ath79_wdt.c:164:5:
error: implicit declaration of function 'get_user'
drivers/watchdog/ath79_wdt.c:196:3:
error: implicit declaration of function 'copy_to_user'
drivers/watchdog/ath79_wdt.c:201:3:
error: implicit declaration of function 'put_user'

Quoting Al Viro - "another victim of indirect include chains"

Fixes: 58a8f3b69e07 ("mips: separate extable.h, switch module.h to it")
Signed-off-by: Sudip Mukherjee 
---

build log is at:
https://travis-ci.org/sudipm-mukherjee/parport/jobs/164834126

 drivers/watchdog/ath79_wdt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/watchdog/ath79_wdt.c b/drivers/watchdog/ath79_wdt.c
index 835d310..e2209bf 100644
--- a/drivers/watchdog/ath79_wdt.c
+++ b/drivers/watchdog/ath79_wdt.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define DRIVER_NAME"ath79-wdt"
 
-- 
1.9.1

Re: xrandr fails after resume from hibernation in kernels 4.7.4 and 4.8.0

[Greg KH]

On Tue, Oct 04, 2016 at 08:43:03PM -0300, Gaston Gonzalez wrote:
> Hi,
> 
> After hibernation I get the following error when I tried to connect to monitor
> through hdmi:
> 
> $ xrandr --output LVDS1 --off  --output  HDMI1 --auto
> xrandr: Configure crtc 1 failed
> 
> This does not happen in kernel in kernel v4.6.7 but do happen in kernels 
> v4.7.4
> and v4.8.0

Ah, can you use 'git bisect' to track down the offending patch?

Also, if you let the graphics driver authors know, they are probably the
best ones to help out with this, not the "generic" stable mailing list.

thanks,

greg k-h

Re: xrandr fails after resume from hibernation in kernels 4.7.4 and 4.8.0

[Greg KH]

On Tue, Oct 04, 2016 at 08:43:03PM -0300, Gaston Gonzalez wrote:
> Hi,
> 
> After hibernation I get the following error when I tried to connect to monitor
> through hdmi:
> 
> $ xrandr --output LVDS1 --off  --output  HDMI1 --auto
> xrandr: Configure crtc 1 failed
> 
> This does not happen in kernel in kernel v4.6.7 but do happen in kernels 
> v4.7.4
> and v4.8.0

Ah, can you use 'git bisect' to track down the offending patch?

Also, if you let the graphics driver authors know, they are probably the
best ones to help out with this, not the "generic" stable mailing list.

thanks,

greg k-h

Re: [PATCH 1/1] cpufreq: pcc-cpufreq: Re-introduce deadband effect to reduce number of frequency changes

[Viresh Kumar]

On 22-09-16, 19:54, Andreas Herrmann wrote:
> On Mon, Sep 19, 2016 at 10:39:18PM +0300, Stratos Karafotis wrote:
> > Just an idea. I would split the frequency range (max_freq - min_freq)
> > into ~10 steps. But I'm not familiar with the affected systems and
> > of course I can't prove this is an ideal approach.
> 
> I've modified the pcc-cpufreq specific map_load_to_freq function to do
> just that (map load values to 10 discrete frequency values) instead of
> falling back to the deadband (pre-commit-6393d6-version).

And in that you can remove the deadband frequencies from the table to
get almost the same results, as I already stated in an earlier email.

-- 
viresh

Re: [PATCH 1/1] cpufreq: pcc-cpufreq: Re-introduce deadband effect to reduce number of frequency changes

[Viresh Kumar]

On 22-09-16, 19:54, Andreas Herrmann wrote:
> On Mon, Sep 19, 2016 at 10:39:18PM +0300, Stratos Karafotis wrote:
> > Just an idea. I would split the frequency range (max_freq - min_freq)
> > into ~10 steps. But I'm not familiar with the affected systems and
> > of course I can't prove this is an ideal approach.
> 
> I've modified the pcc-cpufreq specific map_load_to_freq function to do
> just that (map load values to 10 discrete frequency values) instead of
> falling back to the deadband (pre-commit-6393d6-version).

And in that you can remove the deadband frequencies from the table to
get almost the same results, as I already stated in an earlier email.

-- 
viresh

Re: [PATCH 1/1] cpufreq: pcc-cpufreq: Re-introduce deadband effect to reduce number of frequency changes

[Viresh Kumar]

Sorry for being late Andreas :(

On 14-09-16, 16:56, Andreas Herrmann wrote:

First of all, thanks for your hardwork in getting these numbers out.
Really appreciate it.

> Below is some trace data. I hope it is of some help.
> 
> (A) - sampling 10s period when system is idle
> (B) - sampling 10s period when system partially loaded (kernel
>   compilation using 2 jobs)
> 
> (1) 4.8-rc5
> (2) 4.8-rc5 with my patch (reintro of deadband effect within
> pcc-cpufreq)
> (3) 4.8-rc5 with reversal of 6393d6a102 (cpufreq: ondemand: Eliminate
> the deadband effect)
> 
> Let me know whether you are looking for other trace data wrt this
> issue.
> 
> 
> Thanks,
> 
> Andreas
> 
> ---
> 
> (A)-(1)
> 
>  # Total Lost Samples: 0
>  # Samples: 41  of event 'power:cpu_frequency'
>  # Event count (approx.): 41
>  # Overhead  Command   Shared Object Symbol   
>  #       .
>  39.02%  kworker/14:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
>  29.27%  kworker/0:0   [kernel.vmlinux]  [k] cpufreq_notify_transition
>  19.51%  kworker/10:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
>   7.32%  kworker/5:2   [kernel.vmlinux]  [k] cpufreq_notify_transition
>   2.44%  kworker/23:2  [kernel.vmlinux]  [k] cpufreq_notify_transition
>   2.44%  kworker/40:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
> 
> (A)-(2)
> 
>  # Total Lost Samples: 0
>  # Samples: 6  of event 'power:cpu_frequency'
>  # Event count (approx.): 6
>  # Overhead  Command   Shared Object Symbol   
>  #       .
>  33.33%  kworker/1:2   [kernel.vmlinux]  [k] cpufreq_notify_transition
>  16.67%  kworker/16:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
>  16.67%  kworker/22:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
>  16.67%  kworker/26:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
>  16.67%  kworker/33:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
> 
> (A)-(3)
> 
>  # Total Lost Samples: 0
>  # Samples: 7  of event 'power:cpu_frequency'
>  # Event count (approx.): 7
>  # Overhead  Command   Shared Object Symbol   
>  #       .
>  28.57%  kworker/58:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
>  14.29%  kworker/19:2  [kernel.vmlinux]  [k] cpufreq_notify_transition
>  14.29%  kworker/20:2  [kernel.vmlinux]  [k] cpufreq_notify_transition
>  14.29%  kworker/22:2  [kernel.vmlinux]  [k] cpufreq_notify_transition
>  14.29%  kworker/23:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
>  14.29%  kworker/35:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
> 
> ---
> 
> (B)-(1)
> 
>  # Total Lost Samples: 0
>  # Samples: 2K of event 'power:cpu_frequency'
>  # Event count (approx.): 2382
>  # Overhead  Command   Shared Object Symbol   
>  #       .
>   5.75%  kworker/0:0   [kernel.vmlinux]  [k] cpufreq_notify_transition
>   4.16%  kworker/12:2  [kernel.vmlinux]  [k] cpufreq_notify_transition
>   3.11%  kworker/17:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
>   2.94%  kworker/2:1   [kernel.vmlinux]  [k] cpufreq_notify_transition
>   2.73%  kworker/19:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
>   ...
> 
> (B)-(2)
> 
>  # Total Lost Samples: 0
>  # Samples: 320  of event 'power:cpu_frequency'
>  # Event count (approx.): 320
>  # Overhead  Command   Shared Object Symbol   
>  #       .
>   4.69%  kworker/56:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
>   4.06%  kworker/12:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
>   4.06%  kworker/28:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
>   4.06%  kworker/6:2   [kernel.vmlinux]  [k] cpufreq_notify_transition
>   3.75%  kworker/32:2  [kernel.vmlinux]  [k] cpufreq_notify_transition
>   ...
> 
> (B)-(3)
> 
>  # Total Lost Samples: 0
>  # Samples: 333  of event 'power:cpu_frequency'
>  # Event count (approx.): 333
>  # Overhead  Command   Shared Object Symbol   
>  #       .
>   4.80%  kworker/51:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
>   4.50%  kworker/39:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
>   4.20%  kworker/47:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
>   3.90%  kworker/59:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
>   3.90%  kworker/7:2   [kernel.vmlinux]  [k] cpufreq_notify_transition
>   ...

I am worried by all of these.. So, its not the DVFS transition which
took time, but cpufreq_notify_transition(). And probably one of 

Re: [PATCH 1/1] cpufreq: pcc-cpufreq: Re-introduce deadband effect to reduce number of frequency changes

[Viresh Kumar]

Sorry for being late Andreas :(

On 14-09-16, 16:56, Andreas Herrmann wrote:

First of all, thanks for your hardwork in getting these numbers out.
Really appreciate it.

> Below is some trace data. I hope it is of some help.
> 
> (A) - sampling 10s period when system is idle
> (B) - sampling 10s period when system partially loaded (kernel
>   compilation using 2 jobs)
> 
> (1) 4.8-rc5
> (2) 4.8-rc5 with my patch (reintro of deadband effect within
> pcc-cpufreq)
> (3) 4.8-rc5 with reversal of 6393d6a102 (cpufreq: ondemand: Eliminate
> the deadband effect)
> 
> Let me know whether you are looking for other trace data wrt this
> issue.
> 
> 
> Thanks,
> 
> Andreas
> 
> ---
> 
> (A)-(1)
> 
>  # Total Lost Samples: 0
>  # Samples: 41  of event 'power:cpu_frequency'
>  # Event count (approx.): 41
>  # Overhead  Command   Shared Object Symbol   
>  #       .
>  39.02%  kworker/14:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
>  29.27%  kworker/0:0   [kernel.vmlinux]  [k] cpufreq_notify_transition
>  19.51%  kworker/10:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
>   7.32%  kworker/5:2   [kernel.vmlinux]  [k] cpufreq_notify_transition
>   2.44%  kworker/23:2  [kernel.vmlinux]  [k] cpufreq_notify_transition
>   2.44%  kworker/40:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
> 
> (A)-(2)
> 
>  # Total Lost Samples: 0
>  # Samples: 6  of event 'power:cpu_frequency'
>  # Event count (approx.): 6
>  # Overhead  Command   Shared Object Symbol   
>  #       .
>  33.33%  kworker/1:2   [kernel.vmlinux]  [k] cpufreq_notify_transition
>  16.67%  kworker/16:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
>  16.67%  kworker/22:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
>  16.67%  kworker/26:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
>  16.67%  kworker/33:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
> 
> (A)-(3)
> 
>  # Total Lost Samples: 0
>  # Samples: 7  of event 'power:cpu_frequency'
>  # Event count (approx.): 7
>  # Overhead  Command   Shared Object Symbol   
>  #       .
>  28.57%  kworker/58:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
>  14.29%  kworker/19:2  [kernel.vmlinux]  [k] cpufreq_notify_transition
>  14.29%  kworker/20:2  [kernel.vmlinux]  [k] cpufreq_notify_transition
>  14.29%  kworker/22:2  [kernel.vmlinux]  [k] cpufreq_notify_transition
>  14.29%  kworker/23:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
>  14.29%  kworker/35:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
> 
> ---
> 
> (B)-(1)
> 
>  # Total Lost Samples: 0
>  # Samples: 2K of event 'power:cpu_frequency'
>  # Event count (approx.): 2382
>  # Overhead  Command   Shared Object Symbol   
>  #       .
>   5.75%  kworker/0:0   [kernel.vmlinux]  [k] cpufreq_notify_transition
>   4.16%  kworker/12:2  [kernel.vmlinux]  [k] cpufreq_notify_transition
>   3.11%  kworker/17:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
>   2.94%  kworker/2:1   [kernel.vmlinux]  [k] cpufreq_notify_transition
>   2.73%  kworker/19:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
>   ...
> 
> (B)-(2)
> 
>  # Total Lost Samples: 0
>  # Samples: 320  of event 'power:cpu_frequency'
>  # Event count (approx.): 320
>  # Overhead  Command   Shared Object Symbol   
>  #       .
>   4.69%  kworker/56:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
>   4.06%  kworker/12:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
>   4.06%  kworker/28:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
>   4.06%  kworker/6:2   [kernel.vmlinux]  [k] cpufreq_notify_transition
>   3.75%  kworker/32:2  [kernel.vmlinux]  [k] cpufreq_notify_transition
>   ...
> 
> (B)-(3)
> 
>  # Total Lost Samples: 0
>  # Samples: 333  of event 'power:cpu_frequency'
>  # Event count (approx.): 333
>  # Overhead  Command   Shared Object Symbol   
>  #       .
>   4.80%  kworker/51:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
>   4.50%  kworker/39:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
>   4.20%  kworker/47:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
>   3.90%  kworker/59:1  [kernel.vmlinux]  [k] cpufreq_notify_transition
>   3.90%  kworker/7:2   [kernel.vmlinux]  [k] cpufreq_notify_transition
>   ...

I am worried by all of these.. So, its not the DVFS transition which
took time, but cpufreq_notify_transition(). And probably one of 

linux-next: Tree for Oct 5

[Stephen Rothwell]

Hi all,

There will be no linux-next release on Friday.

Please do *not* add any v4.10 material to your linux-next included trees
until v4.9-rc1 has been released i.e. the merge window closes.

Changes since 20161004:

Non-merge commits (relative to Linus' tree): 11868
 8531 files changed, 482011 insertions(+), 278917 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 243 trees (counting Linus' and 34 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (ce866e2d182b Merge tag 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma)
Merging fixes/master (d3396e1e4ec4 Merge tag 'fixes-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging kbuild-current/rc-fixes (d3e2773c4ede builddeb: Skip gcc-plugins when 
not configured)
Merging arc-current/for-curr (3eab887a5542 Linux 4.8-rc4)
Merging arm-current/fixes (117e5e9c4cfc ARM: 8618/1: decompressor: reset ttbcr 
fields to use TTBR0 on ARMv7)
Merging m68k-current/for-linus (6736e65effc3 m68k: Migrate exception table 
users off module.h and onto extable.h)
Merging metag-fixes/fixes (97b1d23f7bcb metag: Drop show_mem() from mem_init())
Merging powerpc-fixes/fixes (b79331a5eb9f powerpc/powernv/pci: Fix m64 checks 
for SR-IOV and window alignment)
Merging sparc/master (c8d2bc9bc39e Linux 4.8)
Merging net/master (c8d2bc9bc39e Linux 4.8)
Merging ipsec/master (b1f2beb87bb0 Merge tag 'media/v4.8-7' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media)
Merging netfilter/master (c8d2bc9bc39e Linux 4.8)
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (db64c5fa590b Merge tag 
'iwlwifi-for-kalle-2016-09-15' of 
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (c8d2bc9bc39e Linux 4.8)
Merging sound-current/for-linus (eeea8b40cd28 Merge tag 'asoc-v4.9' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next)
Merging pci-current/for-linus (035ee288ae7a PCI: Fix bridge_d3 update on device 
removal)
Merging driver-core.current/driver-core-linus (c6935931c189 Linux 4.8-rc5)
Merging tty.current/tty-linus (c6935931c189 Linux 4.8-rc5)
Merging usb.current/usb-linus (21f54ddae449 Using BUG_ON() as an assert() is 
_never_ acceptable)
Merging usb-gadget-fixes/fixes (d8a4100ddc75 usb: gadget: udc: atmel: fix 
endpoint name)
Merging usb-serial-fixes/usb-linus (f190fd92458d USB: serial: simple: add 
support for another Infineon flashloader)
Merging usb-chipidea-fixes/ci-for-usb-stable (6f3c4fb6d05e usb: chipidea: udc: 
fix NULL ptr dereference in isr_setup_status_phase)
Merging staging.current/staging-linus (9395452b4aab Linux 4.8-rc6)
Merging char-misc.current/char-misc-linus (c6935931c189 Linux 4.8-rc5)
Merging input-current/for-linus (c758f96a8c34 Merge branch 'next' into 
for-linus)
Merging crypto-current/master (80da44c29d99 crypto: vmx - Fix memory corruption 
caused by p8_ghash)
Merging ide/master (797cee982eef Merge branch 'stable-4.8' of 
git://git.infradead.org/users/pcmoore/audit)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (c8952a707556 vfio/pci: Fix NULL pointer oops in 
error interrupt setup handling)
Merging kselftest-fixes/fixes (29b4817d4018 Linux 4.8-rc1)
Merging backlight

linux-next: Tree for Oct 5

[Stephen Rothwell]

Hi all,

There will be no linux-next release on Friday.

Please do *not* add any v4.10 material to your linux-next included trees
until v4.9-rc1 has been released i.e. the merge window closes.

Changes since 20161004:

Non-merge commits (relative to Linus' tree): 11868
 8531 files changed, 482011 insertions(+), 278917 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 243 trees (counting Linus' and 34 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (ce866e2d182b Merge tag 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma)
Merging fixes/master (d3396e1e4ec4 Merge tag 'fixes-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging kbuild-current/rc-fixes (d3e2773c4ede builddeb: Skip gcc-plugins when 
not configured)
Merging arc-current/for-curr (3eab887a5542 Linux 4.8-rc4)
Merging arm-current/fixes (117e5e9c4cfc ARM: 8618/1: decompressor: reset ttbcr 
fields to use TTBR0 on ARMv7)
Merging m68k-current/for-linus (6736e65effc3 m68k: Migrate exception table 
users off module.h and onto extable.h)
Merging metag-fixes/fixes (97b1d23f7bcb metag: Drop show_mem() from mem_init())
Merging powerpc-fixes/fixes (b79331a5eb9f powerpc/powernv/pci: Fix m64 checks 
for SR-IOV and window alignment)
Merging sparc/master (c8d2bc9bc39e Linux 4.8)
Merging net/master (c8d2bc9bc39e Linux 4.8)
Merging ipsec/master (b1f2beb87bb0 Merge tag 'media/v4.8-7' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media)
Merging netfilter/master (c8d2bc9bc39e Linux 4.8)
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (db64c5fa590b Merge tag 
'iwlwifi-for-kalle-2016-09-15' of 
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (c8d2bc9bc39e Linux 4.8)
Merging sound-current/for-linus (eeea8b40cd28 Merge tag 'asoc-v4.9' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next)
Merging pci-current/for-linus (035ee288ae7a PCI: Fix bridge_d3 update on device 
removal)
Merging driver-core.current/driver-core-linus (c6935931c189 Linux 4.8-rc5)
Merging tty.current/tty-linus (c6935931c189 Linux 4.8-rc5)
Merging usb.current/usb-linus (21f54ddae449 Using BUG_ON() as an assert() is 
_never_ acceptable)
Merging usb-gadget-fixes/fixes (d8a4100ddc75 usb: gadget: udc: atmel: fix 
endpoint name)
Merging usb-serial-fixes/usb-linus (f190fd92458d USB: serial: simple: add 
support for another Infineon flashloader)
Merging usb-chipidea-fixes/ci-for-usb-stable (6f3c4fb6d05e usb: chipidea: udc: 
fix NULL ptr dereference in isr_setup_status_phase)
Merging staging.current/staging-linus (9395452b4aab Linux 4.8-rc6)
Merging char-misc.current/char-misc-linus (c6935931c189 Linux 4.8-rc5)
Merging input-current/for-linus (c758f96a8c34 Merge branch 'next' into 
for-linus)
Merging crypto-current/master (80da44c29d99 crypto: vmx - Fix memory corruption 
caused by p8_ghash)
Merging ide/master (797cee982eef Merge branch 'stable-4.8' of 
git://git.infradead.org/users/pcmoore/audit)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (c8952a707556 vfio/pci: Fix NULL pointer oops in 
error interrupt setup handling)
Merging kselftest-fixes/fixes (29b4817d4018 Linux 4.8-rc1)
Merging backlight

adm9240 error handling (was Re: [PATCHv1] hwmon: adm9240: handle temperature readings below 0)

[Chris Packham]

Hi Guenter,

On 10/05/2016 11:10 AM, Guenter Roeck wrote:
> On Tue, Oct 04, 2016 at 09:09:10PM +, Chris Packham wrote:
>>
>>>
>>> Of course, all that doesn't solve the real problem in this driver, which is
>>> that it ignores error codes from the smbus functions, but that is a 
>>> different
>>> problem.
>>
>> Yeah I'd noted that too. This patch is actually a port of changes we've
>> made to a custom LM81 driver based on the original adm9240 driver which
>> included some error handling. I'll look at bringing more of that code in
>> for a future patch.
>>
> Sounds good...
>

So on this. The as-yet unpublished changes we have basically consist of 
changing adm9240_update_device() to do something like this


 || !data->valid) {

 for (i = 0; i < 6; i++) { /* read voltages */
-   data->in[i] = i2c_smbus_read_byte_data(client,
+   ret = i2c_smbus_read_byte_data(client,
 ADM9240_REG_IN(i));
+   if (ret >= 0)
+   data->in[i] = ret;

The user is still none the wiser that there was an error but at least we 
haven't just attempted to write a error code to the data. Is this the 
direction you want to head? Are there other hwmon drivers that do 
something saner?

Another attempt we've made is to try to read something innocuous like 
the CONFIG register to check that the i2c bus is in a good state before 
reading the rest of the values.

As you can guess these "fixes" have piled up over time and because 
they're hard to test we haven't been brave enough to remove them.

Any thoughts?

adm9240 error handling (was Re: [PATCHv1] hwmon: adm9240: handle temperature readings below 0)

[Chris Packham]

Hi Guenter,

On 10/05/2016 11:10 AM, Guenter Roeck wrote:
> On Tue, Oct 04, 2016 at 09:09:10PM +, Chris Packham wrote:
>>
>>>
>>> Of course, all that doesn't solve the real problem in this driver, which is
>>> that it ignores error codes from the smbus functions, but that is a 
>>> different
>>> problem.
>>
>> Yeah I'd noted that too. This patch is actually a port of changes we've
>> made to a custom LM81 driver based on the original adm9240 driver which
>> included some error handling. I'll look at bringing more of that code in
>> for a future patch.
>>
> Sounds good...
>

So on this. The as-yet unpublished changes we have basically consist of 
changing adm9240_update_device() to do something like this


 || !data->valid) {

 for (i = 0; i < 6; i++) { /* read voltages */
-   data->in[i] = i2c_smbus_read_byte_data(client,
+   ret = i2c_smbus_read_byte_data(client,
 ADM9240_REG_IN(i));
+   if (ret >= 0)
+   data->in[i] = ret;

The user is still none the wiser that there was an error but at least we 
haven't just attempted to write a error code to the data. Is this the 
direction you want to head? Are there other hwmon drivers that do 
something saner?

Another attempt we've made is to try to read something innocuous like 
the CONFIG register to check that the i2c bus is in a good state before 
reading the rest of the values.

As you can guess these "fixes" have piled up over time and because 
they're hard to test we haven't been brave enough to remove them.

Any thoughts?

Re: pull-request: wireless-drivers-next 2016-09-29

[David Miller]

From: Kalle Valo 
Date: Wed, 05 Oct 2016 07:50:39 +0300

> net-next still fails to compile for me. I verified that these two
> patches fix it but I don't see them in net-next yet.

Pablo please get those fixes to me as soon as possible.

Re: pull-request: wireless-drivers-next 2016-09-29

[David Miller]

From: Kalle Valo 
Date: Wed, 05 Oct 2016 07:50:39 +0300

> net-next still fails to compile for me. I verified that these two
> patches fix it but I don't see them in net-next yet.

Pablo please get those fixes to me as soon as possible.

Re: pull-request: wireless-drivers-next 2016-09-29

[Kalle Valo]

Aaron Conole  writes:

> David Miller  writes:
>
>> From: Kalle Valo 
>> Date: Thu, 29 Sep 2016 19:57:28 +0300
>>
> ...
>>> Or actually I had one problem. While doing a test merge I noticed that
>>> net-next fails to compile for me, but I don't think this is anything
>>> wireless related:
>>> 
>>>   CC  net/netfilter/core.o
>>> net/netfilter/core.c: In function 'nf_set_hooks_head':
>>> net/netfilter/core.c:96:149: error: 'struct net_device' has no
>>> member named 'nf_hooks_ingress'
>>
>> Yes, I am aware of this build issue and will tackle it myself if someone
>> doesn't beat me to it.
>
> Sorry, I introduced this.  I posted a series targetted at nf-next to
> solve this, but it could be merged to net-next instead, if that makes
> sense.
>
> The patches are here:
>
> https://patchwork.ozlabs.org/patch/676287/
> https://patchwork.ozlabs.org/patch/676288/

net-next still fails to compile for me. I verified that these two
patches fix it but I don't see them in net-next yet.

-- 
Kalle Valo

Re: pull-request: wireless-drivers-next 2016-09-29

[Kalle Valo]

Aaron Conole  writes:

> David Miller  writes:
>
>> From: Kalle Valo 
>> Date: Thu, 29 Sep 2016 19:57:28 +0300
>>
> ...
>>> Or actually I had one problem. While doing a test merge I noticed that
>>> net-next fails to compile for me, but I don't think this is anything
>>> wireless related:
>>> 
>>>   CC  net/netfilter/core.o
>>> net/netfilter/core.c: In function 'nf_set_hooks_head':
>>> net/netfilter/core.c:96:149: error: 'struct net_device' has no
>>> member named 'nf_hooks_ingress'
>>
>> Yes, I am aware of this build issue and will tackle it myself if someone
>> doesn't beat me to it.
>
> Sorry, I introduced this.  I posted a series targetted at nf-next to
> solve this, but it could be merged to net-next instead, if that makes
> sense.
>
> The patches are here:
>
> https://patchwork.ozlabs.org/patch/676287/
> https://patchwork.ozlabs.org/patch/676288/

net-next still fails to compile for me. I verified that these two
patches fix it but I don't see them in net-next yet.

-- 
Kalle Valo

Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422

[Vivek Gautam]

Hi Anand,


On Tue, Oct 4, 2016 at 8:39 PM, Anand Moon  wrote:
> Hi Vivek,
>

[snip]

>
> What I feel is that their need to be some reset of usb phy so that
> device are assigned to respective bus ports.

The phy resets are what we do in the phy-exynos5-usbdrd driver. In
addition to what we
have currently in this phy driver, we just need the phy calibration
patch [1] for phy configurations.

[1] https://lkml.org/lkml/2015/2/2/259

> odroid@odroid:~$ lsusb -t
> /:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
> /:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
> |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=r8152, 480M

This shows the ethernet device gets detected on the high-speed port of one
of the controller.
The lsusb output for kernel v4.7.x posted by Michael show that the
ethernet device got detected on super-speed port of the controller.
So, there seems to be a difference between the two.
Or, is this how it is behaving ?

Is this lsusb output on 4.8 kernel with the patch [1] ?

> /:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 5000M
> |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
> |__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
> /:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 480M
> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M
> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=exynos-ehci/3p, 480M
> |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M
>
>
> Bus 06.Port should register the Realtek Ethernet r8153 device.
> But I am not able to trace out how it's should happen.

If i understand, below is how the configuration looks like on the board?

+---+
+-->|   |
|   |   Bus 6   |---+
+---+   |(super-speed)  |   |
|   |   +---+   |
|Controller |   | > Ethernet device
|2  |   |
|   |   +---+   |
+---+   |   |   |
|   |   Bus 5   |---+
+-->|   (high-speed)|
+---+


+---+
+-->|   |
|   |   Bus 4   |---+
+---+   |(super-speed)  |   |
|   |   +---+   |
|Controller |   | > (On board
hub ?? _OR_ external hub with downstream devices) ???
|1  |   |
|   |   +---+   |
+---+   |   |   |
|   |   Bus 3   |---+
+-->|   (high-speed)|
+---+


Thanks
Vivek


--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422

[Vivek Gautam]

Hi Anand,


On Tue, Oct 4, 2016 at 8:39 PM, Anand Moon  wrote:
> Hi Vivek,
>

[snip]

>
> What I feel is that their need to be some reset of usb phy so that
> device are assigned to respective bus ports.

The phy resets are what we do in the phy-exynos5-usbdrd driver. In
addition to what we
have currently in this phy driver, we just need the phy calibration
patch [1] for phy configurations.

[1] https://lkml.org/lkml/2015/2/2/259

> odroid@odroid:~$ lsusb -t
> /:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
> /:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
> |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=r8152, 480M

This shows the ethernet device gets detected on the high-speed port of one
of the controller.
The lsusb output for kernel v4.7.x posted by Michael show that the
ethernet device got detected on super-speed port of the controller.
So, there seems to be a difference between the two.
Or, is this how it is behaving ?

Is this lsusb output on 4.8 kernel with the patch [1] ?

> /:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 5000M
> |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
> |__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
> /:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 480M
> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M
> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=exynos-ehci/3p, 480M
> |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M
>
>
> Bus 06.Port should register the Realtek Ethernet r8153 device.
> But I am not able to trace out how it's should happen.

If i understand, below is how the configuration looks like on the board?

+---+
+-->|   |
|   |   Bus 6   |---+
+---+   |(super-speed)  |   |
|   |   +---+   |
|Controller |   | > Ethernet device
|2  |   |
|   |   +---+   |
+---+   |   |   |
|   |   Bus 5   |---+
+-->|   (high-speed)|
+---+


+---+
+-->|   |
|   |   Bus 4   |---+
+---+   |(super-speed)  |   |
|   |   +---+   |
|Controller |   | > (On board
hub ?? _OR_ external hub with downstream devices) ???
|1  |   |
|   |   +---+   |
+---+   |   |   |
|   |   Bus 3   |---+
+-->|   (high-speed)|
+---+


Thanks
Vivek


--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

RE: Re: [PATCH v2 2/5] ramoops: introduce generic init/free functions for prz

[岩松信洋 / IWAMATSU，NOBUHIRO]

Hi,


Thanks for youre review.

> -Original Message-
> From: keesc...@google.com [mailto:keesc...@google.com] On Behalf Of Kees
> Cook
> Sent: Friday, September 09, 2016 6:23 AM
> To: 岩松信洋 / IWAMATSU，NOBUHIRO
> Cc: Anton Vorontsov; Colin Cross; Tony Luck; LKML; Hiraku Toyooka; Mark
> Salyzyn; 阿口誠司 / AGUCHI，SEIJI
> Subject: [!]Re: [PATCH v2 2/5] ramoops: introduce generic init/free
> functions for prz
> 
> On Sun, Jul 24, 2016 at 8:56 PM, Nobuhiro Iwamatsu
>  wrote:
> > From: Hiraku Toyooka 
> >
> > We modifies initialization and freeing code for prz for generic usage.
> 
> Sorry for the delay in getting to this review, I've been catching up on
> pstore finally. :)
> 
> > This change
> >
> >  * add generic function __ramoops_init_prz() to reduce redundancy
> >between ramoops_init_prz() and ramoops_init_przs().
> 
> Can you split this into a separate patch?

OK, I will do.
> 
> >  * rename 'przs' member in struct ramoops_context to 'dprzs' so that
> >it stands for 'dump przs'.
> >  * rename ramoops_init_prz() to ramoops_init_dprzs().
> 
> And also these two into a separate patch, since it's just a renaming.
> And could you add comments for all the przs, it's getting harder to read
> these since they're just single-letter names. :)
> 
> >  * change parameter of ramoops_free_przs() from struct ramoops_context
> *
> >into struct persistent_ram_zone * in order to make it available for
> >all prz array.
> 
> I *think* this should be with the first change, so splitting this email's
> patch into two patches would make review easier (i.e. first do renamings,
> then make functional changes).

OK, I will do too.

> 
> > Signed-off-by: Hiraku Toyooka 
> > Signed-off-by: Nobuhiro Iwamatsu 
> > Cc: Mark Salyzyn 
> > Cc: Seiji Aguchi 



> 
> Thanks!
> 
> -Kees
> 
> --
> Kees Cook
> Nexus Security

Best regards,
  Nobuhiro

RE: Re: [PATCH v2 2/5] ramoops: introduce generic init/free functions for prz

[岩松信洋 / IWAMATSU，NOBUHIRO]

Hi,


Thanks for youre review.

> -Original Message-
> From: keesc...@google.com [mailto:keesc...@google.com] On Behalf Of Kees
> Cook
> Sent: Friday, September 09, 2016 6:23 AM
> To: 岩松信洋 / IWAMATSU，NOBUHIRO
> Cc: Anton Vorontsov; Colin Cross; Tony Luck; LKML; Hiraku Toyooka; Mark
> Salyzyn; 阿口誠司 / AGUCHI，SEIJI
> Subject: [!]Re: [PATCH v2 2/5] ramoops: introduce generic init/free
> functions for prz
> 
> On Sun, Jul 24, 2016 at 8:56 PM, Nobuhiro Iwamatsu
>  wrote:
> > From: Hiraku Toyooka 
> >
> > We modifies initialization and freeing code for prz for generic usage.
> 
> Sorry for the delay in getting to this review, I've been catching up on
> pstore finally. :)
> 
> > This change
> >
> >  * add generic function __ramoops_init_prz() to reduce redundancy
> >between ramoops_init_prz() and ramoops_init_przs().
> 
> Can you split this into a separate patch?

OK, I will do.
> 
> >  * rename 'przs' member in struct ramoops_context to 'dprzs' so that
> >it stands for 'dump przs'.
> >  * rename ramoops_init_prz() to ramoops_init_dprzs().
> 
> And also these two into a separate patch, since it's just a renaming.
> And could you add comments for all the przs, it's getting harder to read
> these since they're just single-letter names. :)
> 
> >  * change parameter of ramoops_free_przs() from struct ramoops_context
> *
> >into struct persistent_ram_zone * in order to make it available for
> >all prz array.
> 
> I *think* this should be with the first change, so splitting this email's
> patch into two patches would make review easier (i.e. first do renamings,
> then make functional changes).

OK, I will do too.

> 
> > Signed-off-by: Hiraku Toyooka 
> > Signed-off-by: Nobuhiro Iwamatsu 
> > Cc: Mark Salyzyn 
> > Cc: Seiji Aguchi 



> 
> Thanks!
> 
> -Kees
> 
> --
> Kees Cook
> Nexus Security

Best regards,
  Nobuhiro

RE: [PATCH v2 3/5] pstore: support multiple pmsg instances

[岩松信洋 / IWAMATSU，NOBUHIRO]

Hi,

> -Original Message-
> From: keesc...@google.com [mailto:keesc...@google.com] On Behalf Of Kees
> Cook
> Sent: Friday, September 09, 2016 6:34 AM
> To: 岩松信洋 / IWAMATSU，NOBUHIRO
> Cc: Anton Vorontsov; Colin Cross; Tony Luck; LKML; Hiraku Toyooka; Mark
> Salyzyn; 阿口誠司 / AGUCHI，SEIJI
> Subject: Re: [PATCH v2 3/5] pstore: support multiple pmsg instances
> 
> On Sun, Jul 24, 2016 at 8:56 PM, Nobuhiro Iwamatsu
>  wrote:
> > From: Hiraku Toyooka 
> >
> > This enables pmsg to deal with multiple instances. One possible use is
> > content priority control on limited persistent store space. By using
> > different buffers, we can prevent important messages from being
> > overwritten by less important messages.
> >
> > When pstore backend module specifies the number of instances
> > (num_pmsg) in pstore_info, multiple /dev/pmsg[ID] appear. (ID is an
> > integer starting at 0. It corresponds to minor number of the each char
> > device.) Writes to each /dev/pmsg[ID] are isolated each other. After
> > reboot, the contents are available in
> /sys/fs/pstore/pmsg-[backend]-[ID].
> >
> > Signed-off-by: Hiraku Toyooka 
> > Signed-off-by: Nobuhiro Iwamatsu 
> > Cc: Mark Salyzyn 
> > Cc: Seiji Aguchi 
> > ---
> >  fs/pstore/pmsg.c   | 20 ++--
> >  include/linux/pstore.h |  1 +
> >  2 files changed, 19 insertions(+), 2 deletions(-)
> >
> > diff --git a/fs/pstore/pmsg.c b/fs/pstore/pmsg.c index
> > 7de20cd..2e281ed 100644
> > --- a/fs/pstore/pmsg.c
> > +++ b/fs/pstore/pmsg.c
> > @@ -52,8 +52,8 @@ static ssize_t write_pmsg(struct file *file, const char
> __user *buf,
> > vfree(buffer);
> > return -EFAULT;
> > }
> > -   psinfo->write_buf(PSTORE_TYPE_PMSG, 0, , 0, buffer,
> 0, c,
> > - psinfo);
> > +   psinfo->write_buf(PSTORE_TYPE_PMSG, 0, ,
> > + iminor(file->f_inode), buffer, 0, c,
> > + psinfo);
> >
> > i += c;
> > }
> > @@ -85,6 +85,7 @@ static char *pmsg_devnode(struct device *dev,
> > umode_t *mode)  void pstore_register_pmsg(void)  {
> > struct device *pmsg_device;
> > +   int i = 0;
> >
> > pmsg_major = register_chrdev(0, PMSG_NAME, _fops);
> > if (pmsg_major < 0) {
> > @@ -105,9 +106,24 @@ void pstore_register_pmsg(void)
> > pr_err("failed to create device\n");
> > goto err_device;
> > }
> > +
> > +   /* allocate additional /dev/pmsg[ID] */
> > +   for (i = 1; i < psinfo->num_pmsg; i++) {
> > +   struct device *pmsg_device;
> > +
> > +   pmsg_device = device_create(pmsg_class, NULL,
> > +   MKDEV(pmsg_major, i), NULL,
> "%s%d",
> > +   PMSG_NAME, i);
> > +   if (IS_ERR(pmsg_device)) {
> > +   pr_err("failed to create device\n");
> > +   goto err_device;
> > +   }
> > +   }
> 
> This should just be merged into the first device_create call (i.e.
> drop the first one, keep your loop, but have "i" start at 0). There's no
> reason that I can see to do it separately.

Indeed, I will fix.
> 
> > return;
> >
> >  err_device:
> > +   for (i--; i >= 0; i--)
> > +   device_destroy(pmsg_class, MKDEV(pmsg_major, i));
> 
> Was the device_destroy() for /dev/pmsg0 missing before? (i.e. does
> class_destroy() or unregister_chrdev() already clean up the devices?)

Your are right.
I will fix as /dev/pmsg0 also treated with device_destroy().

> 
> > class_destroy(pmsg_class);
> >  err_class:
> > unregister_chrdev(pmsg_major, PMSG_NAME); diff --git
> > a/include/linux/pstore.h b/include/linux/pstore.h index
> > 831479f..b0c24cc 100644
> > --- a/include/linux/pstore.h
> > +++ b/include/linux/pstore.h
> > @@ -54,6 +54,7 @@ struct pstore_info {
> > size_t  bufsize;
> > struct mutexread_mutex; /* serialize open/read/close
> */
> > int flags;
> > +   unsigned intnum_pmsg;
> > int (*open)(struct pstore_info *psi);
> > int (*close)(struct pstore_info *psi);
> > ssize_t (*read)(u64 *id, enum pstore_type_id *type,
> > --
> > 2.8.1
> >
> >
> 
> -Kees
> 
> 
> --
> Kees Cook
> Nexus Security

Best regards,
  Nobuhiro

RE: [PATCH v2 3/5] pstore: support multiple pmsg instances

[岩松信洋 / IWAMATSU，NOBUHIRO]

Hi,

> -Original Message-
> From: keesc...@google.com [mailto:keesc...@google.com] On Behalf Of Kees
> Cook
> Sent: Friday, September 09, 2016 6:34 AM
> To: 岩松信洋 / IWAMATSU，NOBUHIRO
> Cc: Anton Vorontsov; Colin Cross; Tony Luck; LKML; Hiraku Toyooka; Mark
> Salyzyn; 阿口誠司 / AGUCHI，SEIJI
> Subject: Re: [PATCH v2 3/5] pstore: support multiple pmsg instances
> 
> On Sun, Jul 24, 2016 at 8:56 PM, Nobuhiro Iwamatsu
>  wrote:
> > From: Hiraku Toyooka 
> >
> > This enables pmsg to deal with multiple instances. One possible use is
> > content priority control on limited persistent store space. By using
> > different buffers, we can prevent important messages from being
> > overwritten by less important messages.
> >
> > When pstore backend module specifies the number of instances
> > (num_pmsg) in pstore_info, multiple /dev/pmsg[ID] appear. (ID is an
> > integer starting at 0. It corresponds to minor number of the each char
> > device.) Writes to each /dev/pmsg[ID] are isolated each other. After
> > reboot, the contents are available in
> /sys/fs/pstore/pmsg-[backend]-[ID].
> >
> > Signed-off-by: Hiraku Toyooka 
> > Signed-off-by: Nobuhiro Iwamatsu 
> > Cc: Mark Salyzyn 
> > Cc: Seiji Aguchi 
> > ---
> >  fs/pstore/pmsg.c   | 20 ++--
> >  include/linux/pstore.h |  1 +
> >  2 files changed, 19 insertions(+), 2 deletions(-)
> >
> > diff --git a/fs/pstore/pmsg.c b/fs/pstore/pmsg.c index
> > 7de20cd..2e281ed 100644
> > --- a/fs/pstore/pmsg.c
> > +++ b/fs/pstore/pmsg.c
> > @@ -52,8 +52,8 @@ static ssize_t write_pmsg(struct file *file, const char
> __user *buf,
> > vfree(buffer);
> > return -EFAULT;
> > }
> > -   psinfo->write_buf(PSTORE_TYPE_PMSG, 0, , 0, buffer,
> 0, c,
> > - psinfo);
> > +   psinfo->write_buf(PSTORE_TYPE_PMSG, 0, ,
> > + iminor(file->f_inode), buffer, 0, c,
> > + psinfo);
> >
> > i += c;
> > }
> > @@ -85,6 +85,7 @@ static char *pmsg_devnode(struct device *dev,
> > umode_t *mode)  void pstore_register_pmsg(void)  {
> > struct device *pmsg_device;
> > +   int i = 0;
> >
> > pmsg_major = register_chrdev(0, PMSG_NAME, _fops);
> > if (pmsg_major < 0) {
> > @@ -105,9 +106,24 @@ void pstore_register_pmsg(void)
> > pr_err("failed to create device\n");
> > goto err_device;
> > }
> > +
> > +   /* allocate additional /dev/pmsg[ID] */
> > +   for (i = 1; i < psinfo->num_pmsg; i++) {
> > +   struct device *pmsg_device;
> > +
> > +   pmsg_device = device_create(pmsg_class, NULL,
> > +   MKDEV(pmsg_major, i), NULL,
> "%s%d",
> > +   PMSG_NAME, i);
> > +   if (IS_ERR(pmsg_device)) {
> > +   pr_err("failed to create device\n");
> > +   goto err_device;
> > +   }
> > +   }
> 
> This should just be merged into the first device_create call (i.e.
> drop the first one, keep your loop, but have "i" start at 0). There's no
> reason that I can see to do it separately.

Indeed, I will fix.
> 
> > return;
> >
> >  err_device:
> > +   for (i--; i >= 0; i--)
> > +   device_destroy(pmsg_class, MKDEV(pmsg_major, i));
> 
> Was the device_destroy() for /dev/pmsg0 missing before? (i.e. does
> class_destroy() or unregister_chrdev() already clean up the devices?)

Your are right.
I will fix as /dev/pmsg0 also treated with device_destroy().

> 
> > class_destroy(pmsg_class);
> >  err_class:
> > unregister_chrdev(pmsg_major, PMSG_NAME); diff --git
> > a/include/linux/pstore.h b/include/linux/pstore.h index
> > 831479f..b0c24cc 100644
> > --- a/include/linux/pstore.h
> > +++ b/include/linux/pstore.h
> > @@ -54,6 +54,7 @@ struct pstore_info {
> > size_t  bufsize;
> > struct mutexread_mutex; /* serialize open/read/close
> */
> > int flags;
> > +   unsigned intnum_pmsg;
> > int (*open)(struct pstore_info *psi);
> > int (*close)(struct pstore_info *psi);
> > ssize_t (*read)(u64 *id, enum pstore_type_id *type,
> > --
> > 2.8.1
> >
> >
> 
> -Kees
> 
> 
> --
> Kees Cook
> Nexus Security

Best regards,
  Nobuhiro

Re: [RFC][PATCH] cgroup: Add new capability to allow a process to migrate other tasks between cgroups

[Serge E. Hallyn]

On Tue, Oct 04, 2016 at 08:00:18PM -0700, John Stultz wrote:
> On Tue, Oct 4, 2016 at 5:38 PM, Serge E. Hallyn  wrote:
> > Quoting John Stultz (john.stu...@linaro.org):
> >> So this patch, as suggested by Tejun,  simply adds a new process
> >> capability flag (CAP_CGROUP_MIGRATE_TASK), and uses it when checking
> >
> > So realistically, what all can this mean?  Freezing tasks, changing
> > cpu/memory limits, changing network and disk throughput, forbid forking,
> > and (most importantly) forbid access to certain devices.
> >
> > I think that's all ok.  (And we still separately check for inode write
> > perms.)
> 
> Sounds good.
> 
> > If anything I'd say the GLOBAL_ROOT_UID check could be taken out since
> > otherwise a host-root task effectively cannot drop this capability.
> 
> Is this ok to leave for a separate patch?

Yeah.  And I'm not sure whether Tejun would object to that idea.

> > Acked-by: Serge Hallyn 
> 
> Thanks for the review!
> 
> Unless there's other feedback, I'll sit on this until the merge window
> is over and then resubmit for consideration for 4.10.
> 
> thanks
> -john

Re: [RFC][PATCH] cgroup: Add new capability to allow a process to migrate other tasks between cgroups

[Serge E. Hallyn]

On Tue, Oct 04, 2016 at 08:00:18PM -0700, John Stultz wrote:
> On Tue, Oct 4, 2016 at 5:38 PM, Serge E. Hallyn  wrote:
> > Quoting John Stultz (john.stu...@linaro.org):
> >> So this patch, as suggested by Tejun,  simply adds a new process
> >> capability flag (CAP_CGROUP_MIGRATE_TASK), and uses it when checking
> >
> > So realistically, what all can this mean?  Freezing tasks, changing
> > cpu/memory limits, changing network and disk throughput, forbid forking,
> > and (most importantly) forbid access to certain devices.
> >
> > I think that's all ok.  (And we still separately check for inode write
> > perms.)
> 
> Sounds good.
> 
> > If anything I'd say the GLOBAL_ROOT_UID check could be taken out since
> > otherwise a host-root task effectively cannot drop this capability.
> 
> Is this ok to leave for a separate patch?

Yeah.  And I'm not sure whether Tejun would object to that idea.

> > Acked-by: Serge Hallyn 
> 
> Thanks for the review!
> 
> Unless there's other feedback, I'll sit on this until the merge window
> is over and then resubmit for consideration for 4.10.
> 
> thanks
> -john

RE: [PATCH v2 5/5] selftests/pstore: add testcases for multiple pmsg instances

[岩松信洋 / IWAMATSU，NOBUHIRO]

Hi,

> -Original Message-
> From: keesc...@google.com [mailto:keesc...@google.com] On Behalf Of Kees
> Cook
> Sent: Friday, September 09, 2016 6:56 AM
> To: 岩松信洋 / IWAMATSU，NOBUHIRO
> Cc: Anton Vorontsov; Colin Cross; Tony Luck; LKML; Hiraku Toyooka; Mark
> Salyzyn; 阿口誠司 / AGUCHI，SEIJI; Shuah Khan
> Subject: Re: [PATCH v2 5/5] selftests/pstore: add testcases for multiple
> pmsg instances
> 
> On Sun, Jul 24, 2016 at 8:56 PM, Nobuhiro Iwamatsu
>  wrote:
> > From: Hiraku Toyooka 
> >
> > To test multiple pmsg, we should check that /dev/pmsg[N] (N > 0) is
> > available. After reboot, we should check that pmsg-[backend]-[N] which
> > keeps content is detected even if pmsg-[backend]-[N-M] (0 < M <= N)
> > doesn't exist due to lack of contents.
> >
> > So this adds the following testcases.
> >  - pstore_tests
> >- Write unique string to the last /dev/pmsgN
> >  - pstore_post_reboot_tests
> >- Check the last pmsg area is detected
> >
> > Signed-off-by: Hiraku Toyooka 
> > Signed-off-by: Nobuhiro Iwamatsu 
> > Cc: Mark Salyzyn 
> > Cc: Seiji Aguchi 
> > Cc: Shuah Khan 
> > ---
> >  tools/testing/selftests/pstore/common_tests| 21
> +++--
> >  .../selftests/pstore/pstore_post_reboot_tests  | 27
> --
> >  tools/testing/selftests/pstore/pstore_tests| 16
> ++---
> >  3 files changed, 47 insertions(+), 17 deletions(-)
> >
> > diff --git a/tools/testing/selftests/pstore/common_tests
> > b/tools/testing/selftests/pstore/common_tests
> > index 3ea64d7..566a25d 100755
> > --- a/tools/testing/selftests/pstore/common_tests
> > +++ b/tools/testing/selftests/pstore/common_tests

 

> > +last_devpmsg=`ls -v /dev/pmsg* | tail -n1` prlog -n "Writing unique
> > +string to the last /dev/pmsgN "
> > +if [ "$last_devpmsg" = "/dev/pmsg0" ]; then
> > +prlog "... No multiple /dev/pmsg* exists. We skip this testcase."
> > +else
> > +prlog -n "(${last_devpmsg}) ... "
> > +echo "${TEST_STRING_PATTERN}""$UUID" > ${last_devpmsg}
> > +show_result $?
> > +
> 
> Blank line here can be dropped.
> 
> > +fi
> > +
> >  exit $rc
> > --
> > 2.8.1
> >
> >
> 
> Otherwise, this looks good. Thanks!
> 

OK, I will fix these.
And thanks again for review this patch series.

> -Kees
> 
> --
> Kees Cook
> Nexus Security


Best regards,
  Nobuhiro

RE: [PATCH v2 5/5] selftests/pstore: add testcases for multiple pmsg instances

[岩松信洋 / IWAMATSU，NOBUHIRO]

Hi,

> -Original Message-
> From: keesc...@google.com [mailto:keesc...@google.com] On Behalf Of Kees
> Cook
> Sent: Friday, September 09, 2016 6:56 AM
> To: 岩松信洋 / IWAMATSU，NOBUHIRO
> Cc: Anton Vorontsov; Colin Cross; Tony Luck; LKML; Hiraku Toyooka; Mark
> Salyzyn; 阿口誠司 / AGUCHI，SEIJI; Shuah Khan
> Subject: Re: [PATCH v2 5/5] selftests/pstore: add testcases for multiple
> pmsg instances
> 
> On Sun, Jul 24, 2016 at 8:56 PM, Nobuhiro Iwamatsu
>  wrote:
> > From: Hiraku Toyooka 
> >
> > To test multiple pmsg, we should check that /dev/pmsg[N] (N > 0) is
> > available. After reboot, we should check that pmsg-[backend]-[N] which
> > keeps content is detected even if pmsg-[backend]-[N-M] (0 < M <= N)
> > doesn't exist due to lack of contents.
> >
> > So this adds the following testcases.
> >  - pstore_tests
> >- Write unique string to the last /dev/pmsgN
> >  - pstore_post_reboot_tests
> >- Check the last pmsg area is detected
> >
> > Signed-off-by: Hiraku Toyooka 
> > Signed-off-by: Nobuhiro Iwamatsu 
> > Cc: Mark Salyzyn 
> > Cc: Seiji Aguchi 
> > Cc: Shuah Khan 
> > ---
> >  tools/testing/selftests/pstore/common_tests| 21
> +++--
> >  .../selftests/pstore/pstore_post_reboot_tests  | 27
> --
> >  tools/testing/selftests/pstore/pstore_tests| 16
> ++---
> >  3 files changed, 47 insertions(+), 17 deletions(-)
> >
> > diff --git a/tools/testing/selftests/pstore/common_tests
> > b/tools/testing/selftests/pstore/common_tests
> > index 3ea64d7..566a25d 100755
> > --- a/tools/testing/selftests/pstore/common_tests
> > +++ b/tools/testing/selftests/pstore/common_tests

 

> > +last_devpmsg=`ls -v /dev/pmsg* | tail -n1` prlog -n "Writing unique
> > +string to the last /dev/pmsgN "
> > +if [ "$last_devpmsg" = "/dev/pmsg0" ]; then
> > +prlog "... No multiple /dev/pmsg* exists. We skip this testcase."
> > +else
> > +prlog -n "(${last_devpmsg}) ... "
> > +echo "${TEST_STRING_PATTERN}""$UUID" > ${last_devpmsg}
> > +show_result $?
> > +
> 
> Blank line here can be dropped.
> 
> > +fi
> > +
> >  exit $rc
> > --
> > 2.8.1
> >
> >
> 
> Otherwise, this looks good. Thanks!
> 

OK, I will fix these.
And thanks again for review this patch series.

> -Kees
> 
> --
> Kees Cook
> Nexus Security


Best regards,
  Nobuhiro

RE: [PATCH v2 4/5] ramoops: support multiple pmsg instances

[岩松信洋 / IWAMATSU，NOBUHIRO]

Hi,

> -Original Message-
> From: keesc...@google.com [mailto:keesc...@google.com] On Behalf Of Kees
> Cook
> Sent: Friday, September 09, 2016 6:53 AM
> To: 岩松信洋 / IWAMATSU，NOBUHIRO
> Cc: Anton Vorontsov; Colin Cross; Tony Luck; LKML; Hiraku Toyooka; Mark
> Salyzyn; 阿口誠司 / AGUCHI，SEIJI
> Subject: Re: [PATCH v2 4/5] ramoops: support multiple pmsg instances
> 
> On Sun, Jul 24, 2016 at 8:56 PM, Nobuhiro Iwamatsu
>  wrote:
> > From: Hiraku Toyooka 
> >
> > This enables ramoops to deal with multiple pmsg instances.
> > A User can configure the size of each buffers by its module parameter
> > as follows.
> >
> >   pmsg_size=0x1000,0x2000,...
> >
> > Then, the ramoops allocates multiple buffers and tells the number of
> > buffers to pstore to create multiple /dev/pmsg[ID].
> >
> > Signed-off-by: Hiraku Toyooka 
> > Signed-off-by: Nobuhiro Iwamatsu 
> > Cc: Mark Salyzyn 
> > Cc: Seiji Aguchi 
> > ---
> >  Documentation/ramoops.txt  |  22 +++
> >  fs/pstore/ram.c| 146
> ++---
> >  include/linux/pstore_ram.h |   8 ++-
> >  3 files changed, 153 insertions(+), 23 deletions(-)
> >
> > diff --git a/Documentation/ramoops.txt b/Documentation/ramoops.txt
> > index 5d86756..cff6ac7 100644
> > --- a/Documentation/ramoops.txt
> > +++ b/Documentation/ramoops.txt
> > @@ -126,3 +126,25 @@ file. Here is an example of usage:
> >   0 811d9c54  8101a7a0  __const_udelay <-
> native_machine_emergency_restart+0x110/0x1e0
> >   0 811d9c34  811d9c80  __delay <-
> __const_udelay+0x30/0x40
> >   0 811d9d14  811d9c3f  delay_tsc <- __delay+0xf/0x20
> > +
> > +6. Pmsg support
> > +
> > +Ramoops supports pmsg - logging userspace mesages in persistent
> > +store. By default, one pmsg area becomes available in ramoops. You
> > +can write data into /dev/pmsg0, e.g.:
> > +
> > + # echo foo > /dev/pmsg0
> > +
> > +After reboot, the stored data can be read from pmsg-ramoops-0 on the
> > +pstore filesystem.
> > +
> > +You can specify size of the pmsg area by additional kernel command line,
> e.g.:
> > +
> > + "ramoops.pmsg_size=0x1000"
> > +
> > +You can also use multiple pmsg areas, e.g.:
> > +
> > + "ramoops.pmsg_size=0x1000,0x2000,..."
> > +
> > +Then, pmsg0, pmsg1, ... will appear on /dev. This is useful to
> > +control individual content aging or priority.
> 
> The documentation for the DT bindings will need updating too, in:
> Documentation/devicetree/bindings/reserved-memory/ramoops.txt

OK, I will add DT bindings to documentation.

> 
> > diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c index 288c5d0..2bf893f
> > 100644
> > --- a/fs/pstore/ram.c
> > +++ b/fs/pstore/ram.c
> > @@ -51,8 +51,8 @@ static ulong ramoops_ftrace_size = MIN_MEM_SIZE;
> > module_param_named(ftrace_size, ramoops_ftrace_size, ulong, 0400);
> > MODULE_PARM_DESC(ftrace_size, "size of ftrace log");
> >
> > -static ulong ramoops_pmsg_size = MIN_MEM_SIZE;
> > -module_param_named(pmsg_size, ramoops_pmsg_size, ulong, 0400);
> > +static char *ramoops_pmsg_size_str;
> > +module_param_named(pmsg_size, ramoops_pmsg_size_str, charp, 0400);
> >  MODULE_PARM_DESC(pmsg_size, "size of user space message log");
> >
> >  static unsigned long long mem_address; @@ -86,14 +86,14 @@ struct
> > ramoops_context {
> > struct persistent_ram_zone **dprzs;
> > struct persistent_ram_zone *cprz;
> > struct persistent_ram_zone *fprz;
> > -   struct persistent_ram_zone *mprz;
> > +   struct persistent_ram_zone **mprzs;
> > phys_addr_t phys_addr;
> > unsigned long size;
> > unsigned int memtype;
> > size_t record_size;
> > size_t console_size;
> > size_t ftrace_size;
> > -   size_t pmsg_size;
> > +   size_t *pmsg_size;
> > int dump_oops;
> > struct persistent_ram_ecc_info ecc_info;
> > unsigned int max_dump_cnt;
> > @@ -103,6 +103,7 @@ struct ramoops_context {
> > unsigned int console_read_cnt;
> > unsigned int ftrace_read_cnt;
> > unsigned int pmsg_read_cnt;
> > +   unsigned int num_pmsg;
> > struct pstore_info pstore;
> >  };
> >
> > @@ -220,9 +221,10 @@ static ssize_t ramoops_pstore_read(u64 *id, enum
> pstore_type_id *type,
> > if (!prz_ok(prz))
> > prz = ramoops_get_next_prz(>fprz,
> >ftrace_read_cnt,
> >1, id, type,
> PSTORE_TYPE_FTRACE, 0);
> > -   if (!prz_ok(prz))
> > -   prz = ramoops_get_next_prz(>mprz,
> >pmsg_read_cnt,
> > -  1, id, type,
> PSTORE_TYPE_PMSG, 0);
> > +   while (cxt->pmsg_read_cnt < cxt->num_pmsg && !prz)
> > +   prz = ramoops_get_next_prz(cxt->mprzs,
> >pmsg_read_cnt,
> > +   

RE: [PATCH v2 4/5] ramoops: support multiple pmsg instances

[岩松信洋 / IWAMATSU，NOBUHIRO]

Hi,

> -Original Message-
> From: keesc...@google.com [mailto:keesc...@google.com] On Behalf Of Kees
> Cook
> Sent: Friday, September 09, 2016 6:53 AM
> To: 岩松信洋 / IWAMATSU，NOBUHIRO
> Cc: Anton Vorontsov; Colin Cross; Tony Luck; LKML; Hiraku Toyooka; Mark
> Salyzyn; 阿口誠司 / AGUCHI，SEIJI
> Subject: Re: [PATCH v2 4/5] ramoops: support multiple pmsg instances
> 
> On Sun, Jul 24, 2016 at 8:56 PM, Nobuhiro Iwamatsu
>  wrote:
> > From: Hiraku Toyooka 
> >
> > This enables ramoops to deal with multiple pmsg instances.
> > A User can configure the size of each buffers by its module parameter
> > as follows.
> >
> >   pmsg_size=0x1000,0x2000,...
> >
> > Then, the ramoops allocates multiple buffers and tells the number of
> > buffers to pstore to create multiple /dev/pmsg[ID].
> >
> > Signed-off-by: Hiraku Toyooka 
> > Signed-off-by: Nobuhiro Iwamatsu 
> > Cc: Mark Salyzyn 
> > Cc: Seiji Aguchi 
> > ---
> >  Documentation/ramoops.txt  |  22 +++
> >  fs/pstore/ram.c| 146
> ++---
> >  include/linux/pstore_ram.h |   8 ++-
> >  3 files changed, 153 insertions(+), 23 deletions(-)
> >
> > diff --git a/Documentation/ramoops.txt b/Documentation/ramoops.txt
> > index 5d86756..cff6ac7 100644
> > --- a/Documentation/ramoops.txt
> > +++ b/Documentation/ramoops.txt
> > @@ -126,3 +126,25 @@ file. Here is an example of usage:
> >   0 811d9c54  8101a7a0  __const_udelay <-
> native_machine_emergency_restart+0x110/0x1e0
> >   0 811d9c34  811d9c80  __delay <-
> __const_udelay+0x30/0x40
> >   0 811d9d14  811d9c3f  delay_tsc <- __delay+0xf/0x20
> > +
> > +6. Pmsg support
> > +
> > +Ramoops supports pmsg - logging userspace mesages in persistent
> > +store. By default, one pmsg area becomes available in ramoops. You
> > +can write data into /dev/pmsg0, e.g.:
> > +
> > + # echo foo > /dev/pmsg0
> > +
> > +After reboot, the stored data can be read from pmsg-ramoops-0 on the
> > +pstore filesystem.
> > +
> > +You can specify size of the pmsg area by additional kernel command line,
> e.g.:
> > +
> > + "ramoops.pmsg_size=0x1000"
> > +
> > +You can also use multiple pmsg areas, e.g.:
> > +
> > + "ramoops.pmsg_size=0x1000,0x2000,..."
> > +
> > +Then, pmsg0, pmsg1, ... will appear on /dev. This is useful to
> > +control individual content aging or priority.
> 
> The documentation for the DT bindings will need updating too, in:
> Documentation/devicetree/bindings/reserved-memory/ramoops.txt

OK, I will add DT bindings to documentation.

> 
> > diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c index 288c5d0..2bf893f
> > 100644
> > --- a/fs/pstore/ram.c
> > +++ b/fs/pstore/ram.c
> > @@ -51,8 +51,8 @@ static ulong ramoops_ftrace_size = MIN_MEM_SIZE;
> > module_param_named(ftrace_size, ramoops_ftrace_size, ulong, 0400);
> > MODULE_PARM_DESC(ftrace_size, "size of ftrace log");
> >
> > -static ulong ramoops_pmsg_size = MIN_MEM_SIZE;
> > -module_param_named(pmsg_size, ramoops_pmsg_size, ulong, 0400);
> > +static char *ramoops_pmsg_size_str;
> > +module_param_named(pmsg_size, ramoops_pmsg_size_str, charp, 0400);
> >  MODULE_PARM_DESC(pmsg_size, "size of user space message log");
> >
> >  static unsigned long long mem_address; @@ -86,14 +86,14 @@ struct
> > ramoops_context {
> > struct persistent_ram_zone **dprzs;
> > struct persistent_ram_zone *cprz;
> > struct persistent_ram_zone *fprz;
> > -   struct persistent_ram_zone *mprz;
> > +   struct persistent_ram_zone **mprzs;
> > phys_addr_t phys_addr;
> > unsigned long size;
> > unsigned int memtype;
> > size_t record_size;
> > size_t console_size;
> > size_t ftrace_size;
> > -   size_t pmsg_size;
> > +   size_t *pmsg_size;
> > int dump_oops;
> > struct persistent_ram_ecc_info ecc_info;
> > unsigned int max_dump_cnt;
> > @@ -103,6 +103,7 @@ struct ramoops_context {
> > unsigned int console_read_cnt;
> > unsigned int ftrace_read_cnt;
> > unsigned int pmsg_read_cnt;
> > +   unsigned int num_pmsg;
> > struct pstore_info pstore;
> >  };
> >
> > @@ -220,9 +221,10 @@ static ssize_t ramoops_pstore_read(u64 *id, enum
> pstore_type_id *type,
> > if (!prz_ok(prz))
> > prz = ramoops_get_next_prz(>fprz,
> >ftrace_read_cnt,
> >1, id, type,
> PSTORE_TYPE_FTRACE, 0);
> > -   if (!prz_ok(prz))
> > -   prz = ramoops_get_next_prz(>mprz,
> >pmsg_read_cnt,
> > -  1, id, type,
> PSTORE_TYPE_PMSG, 0);
> > +   while (cxt->pmsg_read_cnt < cxt->num_pmsg && !prz)
> > +   prz = ramoops_get_next_prz(cxt->mprzs,
> >pmsg_read_cnt,
> > +  cxt->num_pmsg, id, type,
> > +  PSTORE_TYPE_PMSG, 0);
> > if (!prz_ok(prz))
> > return 0;
> >
> > @@ -286,9 

[PATCH v4 1/2] dt-bindings: display: Add Sharp LQ150X1LG11 panel binding

[Peter Rosin]

The Sharp 15" LQ150X1LG11 panel is an XGA TFT LCD panel.

Signed-off-by: Peter Rosin 
---
 .../bindings/display/panel/sharp,lq150x1lg11.txt   | 36 ++
 1 file changed, 36 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.txt 
b/Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.txt
new file mode 100644
index ..0f57c3143506
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.txt
@@ -0,0 +1,36 @@
+Sharp 15" LQ150X1LG11 XGA TFT LCD panel
+
+Required properties:
+- compatible: should be "sharp,lq150x1lg11"
+- power-supply: regulator to provide the VCC supply voltage (3.3 volts)
+
+Optional properties:
+- backlight: phandle of the backlight device
+- rlud-gpios: a single GPIO for the RL/UD (rotate 180 degrees) pin.
+- sellvds-gpios: a single GPIO for the SELLVDS pin.
+
+If rlud-gpios and/or sellvds-gpios are not specified, the RL/UD and/or SELLVDS
+pins are assumed to be handled appropriately by the hardware.
+
+Example:
+
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   pwms = < 0 10>;  /* VBR */
+
+   brightness-levels = <0 20 40 60 80 100>;
+   default-brightness-level = <2>;
+
+   power-supply = <_12v_reg>;   /* VDD */
+   enable-gpios = < 42 GPIO_ACTIVE_HIGH>;  /* XSTABY */
+   };
+
+   panel {
+   compatible = "sharp,lq150x1lg11";
+
+   power-supply = <_3v3_reg>;   /* VCC */
+
+   backlight = <>;
+   rlud-gpios = < 17 GPIO_ACTIVE_HIGH>;/* RL/UD */
+   sellvds-gpios = < 18 GPIO_ACTIVE_HIGH>; /* SELLVDS */
+   };
-- 
2.1.4

[PATCH v4 1/2] dt-bindings: display: Add Sharp LQ150X1LG11 panel binding

[Peter Rosin]

The Sharp 15" LQ150X1LG11 panel is an XGA TFT LCD panel.

Signed-off-by: Peter Rosin 
---
 .../bindings/display/panel/sharp,lq150x1lg11.txt   | 36 ++
 1 file changed, 36 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.txt 
b/Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.txt
new file mode 100644
index ..0f57c3143506
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.txt
@@ -0,0 +1,36 @@
+Sharp 15" LQ150X1LG11 XGA TFT LCD panel
+
+Required properties:
+- compatible: should be "sharp,lq150x1lg11"
+- power-supply: regulator to provide the VCC supply voltage (3.3 volts)
+
+Optional properties:
+- backlight: phandle of the backlight device
+- rlud-gpios: a single GPIO for the RL/UD (rotate 180 degrees) pin.
+- sellvds-gpios: a single GPIO for the SELLVDS pin.
+
+If rlud-gpios and/or sellvds-gpios are not specified, the RL/UD and/or SELLVDS
+pins are assumed to be handled appropriately by the hardware.
+
+Example:
+
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   pwms = < 0 10>;  /* VBR */
+
+   brightness-levels = <0 20 40 60 80 100>;
+   default-brightness-level = <2>;
+
+   power-supply = <_12v_reg>;   /* VDD */
+   enable-gpios = < 42 GPIO_ACTIVE_HIGH>;  /* XSTABY */
+   };
+
+   panel {
+   compatible = "sharp,lq150x1lg11";
+
+   power-supply = <_3v3_reg>;   /* VCC */
+
+   backlight = <>;
+   rlud-gpios = < 17 GPIO_ACTIVE_HIGH>;/* RL/UD */
+   sellvds-gpios = < 18 GPIO_ACTIVE_HIGH>; /* SELLVDS */
+   };
-- 
2.1.4

Re: [PATCH v2 1/2] cpufreq/ondemand: Introduce op to customize mapping of load to frequency

[Viresh Kumar]

On 23-09-16, 19:02, Andreas Herrmann wrote:
> Introduce op for ondemand governor that is used to map load to
> frequency. It allows a cpufreq driver to provide a specific mapping
> function if the generic function is not optimal for the driver.
> 
> Performance results (kernel compile with different number of jobs)
> based on 4.8.0-rc7 (with and w/o my patches on top) from
> an HP ProLiant DL580 Gen8 system using pcc-cpufreq:
>  - Intel(R) Xeon(R) CPU E7-4890 v2 @ 2.80GHz
>  - 60 CPUs, 128GB RAM
>  
> vanilla  generic_map_load_to_freq function
>  # of jobs  usersys   elapsed   % CPU  usersys   elapsed   % CPU
> 2  445.44  110.51  272.99   203.00445.56  111.22  273.35   203.00
> 4  444.41  126.20  142.81   399.00445.61  126.10  143.12   399.00
> 8  483.04  150.58   82.19   770.40483.51  150.84   82.17   771.40
>16  626.81  185.01   55.00  1475.40628.01  185.54   55.02  1477.80
>32  816.72  204.39   37.26  2740.00818.58  205.51   37.02  2765.40
>64  406.59   51.12   14.04  3257.80406.22   51.84   13.84  3308.80
>   120  413.00   48.39   14.36  3211.20413.61   49.06   14.54  3181.00
> 
> Similar tests on another system using acpi_cpufreq didn't show
> significant performance differences between these two kernel versions.
> 
> Link: https://marc.info/?i=20160819121814.GA17296%40suselix.suse.de
> Signed-off-by: Andreas Herrmann 
> ---
>  drivers/cpufreq/cpufreq_governor.h |  5 +
>  drivers/cpufreq/cpufreq_ondemand.c | 35 ++-
>  2 files changed, 35 insertions(+), 5 deletions(-)

NAK.

If we are absolutely required to hack it in some way, then I would
prefer your first patchset as the noise was limited to only your
driver.

We aren't going to provide such operations from the governors, sorry.

-- 
viresh

Re: [PATCH v2 1/2] cpufreq/ondemand: Introduce op to customize mapping of load to frequency

[Viresh Kumar]

On 23-09-16, 19:02, Andreas Herrmann wrote:
> Introduce op for ondemand governor that is used to map load to
> frequency. It allows a cpufreq driver to provide a specific mapping
> function if the generic function is not optimal for the driver.
> 
> Performance results (kernel compile with different number of jobs)
> based on 4.8.0-rc7 (with and w/o my patches on top) from
> an HP ProLiant DL580 Gen8 system using pcc-cpufreq:
>  - Intel(R) Xeon(R) CPU E7-4890 v2 @ 2.80GHz
>  - 60 CPUs, 128GB RAM
>  
> vanilla  generic_map_load_to_freq function
>  # of jobs  usersys   elapsed   % CPU  usersys   elapsed   % CPU
> 2  445.44  110.51  272.99   203.00445.56  111.22  273.35   203.00
> 4  444.41  126.20  142.81   399.00445.61  126.10  143.12   399.00
> 8  483.04  150.58   82.19   770.40483.51  150.84   82.17   771.40
>16  626.81  185.01   55.00  1475.40628.01  185.54   55.02  1477.80
>32  816.72  204.39   37.26  2740.00818.58  205.51   37.02  2765.40
>64  406.59   51.12   14.04  3257.80406.22   51.84   13.84  3308.80
>   120  413.00   48.39   14.36  3211.20413.61   49.06   14.54  3181.00
> 
> Similar tests on another system using acpi_cpufreq didn't show
> significant performance differences between these two kernel versions.
> 
> Link: https://marc.info/?i=20160819121814.GA17296%40suselix.suse.de
> Signed-off-by: Andreas Herrmann 
> ---
>  drivers/cpufreq/cpufreq_governor.h |  5 +
>  drivers/cpufreq/cpufreq_ondemand.c | 35 ++-
>  2 files changed, 35 insertions(+), 5 deletions(-)

NAK.

If we are absolutely required to hack it in some way, then I would
prefer your first patchset as the noise was limited to only your
driver.

We aren't going to provide such operations from the governors, sorry.

-- 
viresh

Re: [RFC][PATCH 1/4] futex: Cleanup variable names for futex_top_waiter()

[Davidlohr Bueso]

On Mon, 03 Oct 2016, Peter Zijlstra wrote:


futex_top_waiter() returns the top-waiter on the pi_mutex. Assinging
this to a variable 'match' totally obscures the code.

Signed-off-by: Peter Zijlstra (Intel) 


Reviewed-by: Davidlohr Bueso 

Re: [RFC][PATCH 1/4] futex: Cleanup variable names for futex_top_waiter()

[Davidlohr Bueso]

On Mon, 03 Oct 2016, Peter Zijlstra wrote:


futex_top_waiter() returns the top-waiter on the pi_mutex. Assinging
this to a variable 'match' totally obscures the code.

Signed-off-by: Peter Zijlstra (Intel) 


Reviewed-by: Davidlohr Bueso 

Re: [RFC][PATCH 2/4] futex: Use smp_store_release() in mark_wake_futex()

[Davidlohr Bueso]

On Mon, 03 Oct 2016, Peter Zijlstra wrote:


Since the futex_q can dissapear the instruction after assigning NULL,
this really should be a RELEASE barrier. That stops loads from hitting
dead memory too.

Signed-off-by: Peter Zijlstra (Intel) 
---
kernel/futex.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -1288,8 +1288,7 @@ static void mark_wake_futex(struct wake_
 * memory barrier is required here to prevent the following
 * store to lock_ptr from getting ahead of the plist_del.
 */
-   smp_wmb();
-   q->lock_ptr = NULL;
+   smp_store_release(>lock_ptr, NULL);
}


Hmm, what if we relied on the implicit barrier in the wake_q_add()
above and got rid of the smp_wmb altogether? We'd obviously have to
move up __unqueue_futex(), but all we care about is the publishing
store to lock_ptr being the last operation, or at least the plist_del,
such that the wakeup order is respected; ie:

  __unqueue_futex(q);
  wake_q_add(wake_q, p);
  q->lock_ptr = NULL;

Thanks,
Davidlohr

Re: [RFC][PATCH 2/4] futex: Use smp_store_release() in mark_wake_futex()

[Davidlohr Bueso]

On Mon, 03 Oct 2016, Peter Zijlstra wrote:


Since the futex_q can dissapear the instruction after assigning NULL,
this really should be a RELEASE barrier. That stops loads from hitting
dead memory too.

Signed-off-by: Peter Zijlstra (Intel) 
---
kernel/futex.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -1288,8 +1288,7 @@ static void mark_wake_futex(struct wake_
 * memory barrier is required here to prevent the following
 * store to lock_ptr from getting ahead of the plist_del.
 */
-   smp_wmb();
-   q->lock_ptr = NULL;
+   smp_store_release(>lock_ptr, NULL);
}


Hmm, what if we relied on the implicit barrier in the wake_q_add()
above and got rid of the smp_wmb altogether? We'd obviously have to
move up __unqueue_futex(), but all we care about is the publishing
store to lock_ptr being the last operation, or at least the plist_del,
such that the wakeup order is respected; ie:

  __unqueue_futex(q);
  wake_q_add(wake_q, p);
  q->lock_ptr = NULL;

Thanks,
Davidlohr

Re: [PATCH v14 2/4] CMDQ: Mediatek CMDQ driver

[Jassi Brar]

On 5 October 2016 at 08:24, Horng-Shyang Liao  wrote:
> On Fri, 2016-09-30 at 17:47 +0800, Horng-Shyang Liao wrote:
>> On Fri, 2016-09-30 at 17:11 +0800, CK Hu wrote:

>
> After I trace mailbox driver, I realize that CMDQ driver cannot use
> tx_done.
>
> CMDQ clients will flush many tasks into CMDQ driver, and then CMDQ
> driver will apply these tasks into GCE HW "immediately". These tasks,
> which are queued in GCE HW, may not execute immediately since they
> may need to wait event(s), e.g. vsync.
>
> However, in mailbox driver, mailbox uses a software buffer to queue
> sent messages. It only sends next message until previous message is
> done. This cannot fulfill CMDQ's requirement.
>
I understand
 a) GCE HW can internally queue many tasks in some 'FIFO'
 b) Execution of some task may have to wait until some external event
occurs (like vsync)
 c) GCE does not generate irq/flag for each task executed (?)

If so, may be your tx_done should return 'true' so long as the GCE HW
can accept tasks in its 'FIFO'. For mailbox api, any task that is
queued on GCE, is assumed to be transmitted.

> Quote some code from mailbox driver. Please notice "active_req" part.
>
> static void msg_submit(struct mbox_chan *chan)
> {
> ...
> if (!chan->msg_count || chan->active_req)
> goto exit;
> ...
> err = chan->mbox->ops->send_data(chan, data);
> if (!err) {
> chan->active_req = data;
> chan->msg_count--;
> }
> ...
> }
>
> static void tx_tick(struct mbox_chan *chan, int r)
> {
> ...
> spin_lock_irqsave(>lock, flags);
> mssg = chan->active_req;
> chan->active_req = NULL;
> spin_unlock_irqrestore(>lock, flags);
> ...
> }
>
> Current workable CMDQ driver uses mbox_client_txdone() to prevent
> this issue, and then uses self callback functions to handle done tasks.
>
> int cmdq_task_flush_async(struct cmdq_client *client, struct cmdq_task
> *task, cmdq_async_flush_cb cb, void *data)
> {
> ...
> mbox_send_message(client->chan, task);
> /* We can send next task immediately, so just call txdone. */
> mbox_client_txdone(client->chan, 0);
> ...
> }
>
> Another solution is to use rx_callback; i.e. CMDQ mailbox controller
> call mbox_chan_received_data() when CMDQ task is done. But, this may
> violate the design of mailbox. What do you think?
>
If my point (c) above does not hold, maybe look at implementing
tx_done() callback and submit next task from the callback of last
done.

Re: [PATCH v14 2/4] CMDQ: Mediatek CMDQ driver

[Jassi Brar]

On 5 October 2016 at 08:24, Horng-Shyang Liao  wrote:
> On Fri, 2016-09-30 at 17:47 +0800, Horng-Shyang Liao wrote:
>> On Fri, 2016-09-30 at 17:11 +0800, CK Hu wrote:

>
> After I trace mailbox driver, I realize that CMDQ driver cannot use
> tx_done.
>
> CMDQ clients will flush many tasks into CMDQ driver, and then CMDQ
> driver will apply these tasks into GCE HW "immediately". These tasks,
> which are queued in GCE HW, may not execute immediately since they
> may need to wait event(s), e.g. vsync.
>
> However, in mailbox driver, mailbox uses a software buffer to queue
> sent messages. It only sends next message until previous message is
> done. This cannot fulfill CMDQ's requirement.
>
I understand
 a) GCE HW can internally queue many tasks in some 'FIFO'
 b) Execution of some task may have to wait until some external event
occurs (like vsync)
 c) GCE does not generate irq/flag for each task executed (?)

If so, may be your tx_done should return 'true' so long as the GCE HW
can accept tasks in its 'FIFO'. For mailbox api, any task that is
queued on GCE, is assumed to be transmitted.

> Quote some code from mailbox driver. Please notice "active_req" part.
>
> static void msg_submit(struct mbox_chan *chan)
> {
> ...
> if (!chan->msg_count || chan->active_req)
> goto exit;
> ...
> err = chan->mbox->ops->send_data(chan, data);
> if (!err) {
> chan->active_req = data;
> chan->msg_count--;
> }
> ...
> }
>
> static void tx_tick(struct mbox_chan *chan, int r)
> {
> ...
> spin_lock_irqsave(>lock, flags);
> mssg = chan->active_req;
> chan->active_req = NULL;
> spin_unlock_irqrestore(>lock, flags);
> ...
> }
>
> Current workable CMDQ driver uses mbox_client_txdone() to prevent
> this issue, and then uses self callback functions to handle done tasks.
>
> int cmdq_task_flush_async(struct cmdq_client *client, struct cmdq_task
> *task, cmdq_async_flush_cb cb, void *data)
> {
> ...
> mbox_send_message(client->chan, task);
> /* We can send next task immediately, so just call txdone. */
> mbox_client_txdone(client->chan, 0);
> ...
> }
>
> Another solution is to use rx_callback; i.e. CMDQ mailbox controller
> call mbox_chan_received_data() when CMDQ task is done. But, this may
> violate the design of mailbox. What do you think?
>
If my point (c) above does not hold, maybe look at implementing
tx_done() callback and submit next task from the callback of last
done.

[PATCH] fsl-ifc: set extended addressing for systems whose bootloader doesn't

[David Singleton]

For 32bit systems whose bootloader doesn't set the extended 36-bit
addressing register for flash devices above the 4GB boundary
we can set up in the driver.

This patch checks the number of address-cells in the dts file
for the fsl-ifc flash controller.  If #address-cells is 2 then
it's a 36-bit address mapping, so set the extended address register
in the ccsr for the upper 0xf address, as specified in the dts file.

The code only sets the extended addressing register if the
dts defines 36-bit addressing for the flash devices AND
the register was not set by the boot loader.

If the bootloader has set the extended addressing register
the code does not update the register.

Cc: xe-ker...@external.cisco.com
Signed-off-by: David Singleton 
---
 drivers/memory/fsl_ifc.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/memory/fsl_ifc.c b/drivers/memory/fsl_ifc.c
index 1b182b1..a73b050 100644
--- a/drivers/memory/fsl_ifc.c
+++ b/drivers/memory/fsl_ifc.c
@@ -78,6 +78,31 @@ EXPORT_SYMBOL(fsl_ifc_find);
 static int fsl_ifc_ctrl_init(struct fsl_ifc_ctrl *ctrl)
 {
struct fsl_ifc_global __iomem *ifc = ctrl->gregs;
+   np = of_find_compatible_node(NULL, NULL, "fsl,ifc");
+   if (np) {
+   const u32 *prop;
+
+   prop = of_get_property(np, "#address-cells", NULL);
+   if (prop) {
+   u32 cells;
+   /*
+* #address-cells 2 means 36-bit addresses are used
+* and the if cspr_ext register is zero, the
+* bootloader didn't set it, we'll set it manually
+*/
+   cells = of_n_addr_cells(np);
+   if ((cells == 2) && 
!(ifc_in32(>cspr_cs[0].cspr_ext))) {
+   prop = of_get_property(np, "reg", NULL);
+   if (prop) {
+   u32 extaddr;
+
+   extaddr = *prop; /* get the top nibble 
for 36-bit */
+   pr_info("fsl-ifc extended 36-bit 
addressing\n");
+   ifc_out32(extaddr, 
>cspr_cs[0].cspr_ext);
+   }
+   }
+   }
+   }
 
/*
 * Clear all the common status and event registers
-- 
2.9.3

[PATCH] fsl-ifc: set extended addressing for systems whose bootloader doesn't

[David Singleton]

For 32bit systems whose bootloader doesn't set the extended 36-bit
addressing register for flash devices above the 4GB boundary
we can set up in the driver.

This patch checks the number of address-cells in the dts file
for the fsl-ifc flash controller.  If #address-cells is 2 then
it's a 36-bit address mapping, so set the extended address register
in the ccsr for the upper 0xf address, as specified in the dts file.

The code only sets the extended addressing register if the
dts defines 36-bit addressing for the flash devices AND
the register was not set by the boot loader.

If the bootloader has set the extended addressing register
the code does not update the register.

Cc: xe-ker...@external.cisco.com
Signed-off-by: David Singleton 
---
 drivers/memory/fsl_ifc.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/memory/fsl_ifc.c b/drivers/memory/fsl_ifc.c
index 1b182b1..a73b050 100644
--- a/drivers/memory/fsl_ifc.c
+++ b/drivers/memory/fsl_ifc.c
@@ -78,6 +78,31 @@ EXPORT_SYMBOL(fsl_ifc_find);
 static int fsl_ifc_ctrl_init(struct fsl_ifc_ctrl *ctrl)
 {
struct fsl_ifc_global __iomem *ifc = ctrl->gregs;
+   np = of_find_compatible_node(NULL, NULL, "fsl,ifc");
+   if (np) {
+   const u32 *prop;
+
+   prop = of_get_property(np, "#address-cells", NULL);
+   if (prop) {
+   u32 cells;
+   /*
+* #address-cells 2 means 36-bit addresses are used
+* and the if cspr_ext register is zero, the
+* bootloader didn't set it, we'll set it manually
+*/
+   cells = of_n_addr_cells(np);
+   if ((cells == 2) && 
!(ifc_in32(>cspr_cs[0].cspr_ext))) {
+   prop = of_get_property(np, "reg", NULL);
+   if (prop) {
+   u32 extaddr;
+
+   extaddr = *prop; /* get the top nibble 
for 36-bit */
+   pr_info("fsl-ifc extended 36-bit 
addressing\n");
+   ifc_out32(extaddr, 
>cspr_cs[0].cspr_ext);
+   }
+   }
+   }
+   }
 
/*
 * Clear all the common status and event registers
-- 
2.9.3

Re: [PATCH v2 3/4] ARM: dts: dra72-evm-revc: fix correct phy delay and impedance settings

[Mugunthan V N]

On Tuesday 04 October 2016 06:41 PM, Lokesh Vutla wrote:
> 
> On Tuesday 04 October 2016 06:26 PM, Mugunthan V N wrote:
>> > The default impedance settings of the phy is not the optimal
>> > value, due to this the second ethernet is not working. Fix it
>> > with correct values which makes the second ethernet port to work.
>> > 
>> > Signed-off-by: Mugunthan V N 
>> > ---
>> >  arch/arm/boot/dts/dra72-evm-revc.dts | 2 ++
>> >  1 file changed, 2 insertions(+)
>> > 
>> > diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts 
>> > b/arch/arm/boot/dts/dra72-evm-revc.dts
>> > index f9cfd3b..d626cd7 100644
>> > --- a/arch/arm/boot/dts/dra72-evm-revc.dts
>> > +++ b/arch/arm/boot/dts/dra72-evm-revc.dts
>> > @@ -62,6 +62,7 @@
>> >ti,rx-internal-delay = ;
>> >ti,tx-internal-delay = ;
>> >ti,fifo-depth = ;
>> > +  ti,min-output-imepdance;
> s/imepdance/impedance
> 

Thanks for quick catch. Will fix this in v3.

Regards
Mugunthan V N

Re: [PATCH v2 2/4] net: phy: dp83867: add support for MAC impedance configuration

[Mugunthan V N]

On Tuesday 04 October 2016 06:40 PM, Andrew Lunn wrote:
>> +if (of_property_read_bool(of_node, "ti,max-output-imepdance"))
>> +dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX;
>> +else if (of_property_read_bool(of_node, "ti,min-output-imepdance"))
> 
> Did you really test this? Or did you make the same typos in your device
> tree file?
> 

I have tested this and attached the log in cover letter. Since there is
a typo error on both dts and driver it worked as expected. Will send a
v3 ASAP.

Regards
Mugunthan V N

Re: [PATCH v2 3/4] ARM: dts: dra72-evm-revc: fix correct phy delay and impedance settings

[Mugunthan V N]

On Tuesday 04 October 2016 06:41 PM, Lokesh Vutla wrote:
> 
> On Tuesday 04 October 2016 06:26 PM, Mugunthan V N wrote:
>> > The default impedance settings of the phy is not the optimal
>> > value, due to this the second ethernet is not working. Fix it
>> > with correct values which makes the second ethernet port to work.
>> > 
>> > Signed-off-by: Mugunthan V N 
>> > ---
>> >  arch/arm/boot/dts/dra72-evm-revc.dts | 2 ++
>> >  1 file changed, 2 insertions(+)
>> > 
>> > diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts 
>> > b/arch/arm/boot/dts/dra72-evm-revc.dts
>> > index f9cfd3b..d626cd7 100644
>> > --- a/arch/arm/boot/dts/dra72-evm-revc.dts
>> > +++ b/arch/arm/boot/dts/dra72-evm-revc.dts
>> > @@ -62,6 +62,7 @@
>> >ti,rx-internal-delay = ;
>> >ti,tx-internal-delay = ;
>> >ti,fifo-depth = ;
>> > +  ti,min-output-imepdance;
> s/imepdance/impedance
> 

Thanks for quick catch. Will fix this in v3.

Regards
Mugunthan V N

Re: [PATCH v2 2/4] net: phy: dp83867: add support for MAC impedance configuration

[Mugunthan V N]

On Tuesday 04 October 2016 06:40 PM, Andrew Lunn wrote:
>> +if (of_property_read_bool(of_node, "ti,max-output-imepdance"))
>> +dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX;
>> +else if (of_property_read_bool(of_node, "ti,min-output-imepdance"))
> 
> Did you really test this? Or did you make the same typos in your device
> tree file?
> 

I have tested this and attached the log in cover letter. Since there is
a typo error on both dts and driver it worked as expected. Will send a
v3 ASAP.

Regards
Mugunthan V N

Re: BUG_ON() in workingset_node_shadows_dec() triggers

[Linus Torvalds]

On Tue, Oct 4, 2016 at 7:43 PM, Paul Gortmaker
 wrote:
>
> A couple years ago Ingo had an idea to kill  BUG_ON abuse that I made
> a 1st pass at.  Back then it seemed nobody cared.  Maybe that has since
> changed?
>
> https://lkml.org/lkml/2014/4/30/359

So we actually have the checkpatch warning already:

  # avoid BUG() or BUG_ON()
if ($line =~ /\b(?:BUG|BUG_ON)\b/) {
my $msg_type = \
$msg_type = \ if ($file);
&{$msg_type}("AVOID_BUG",
 "Avoid crashing the kernel - try
using WARN_ON & recovery code rather than BUG() or BUG_ON()\n" .
$herecurr);
}

but it doesn't trigger on VM_BUG_ON().

And I'm not convinced about replacing things with BUG_ON_AND_HALT(),
it simply doesn't fix the existing issue we have: people use BUG_ON(),
and worse, _when_ they use BUG_ON(), they use it instead of error
handling, so the code _around_ the BUG_ON() tends to then very much
depend on what the BUG_ON() checks.

This is actually one way that VM_BUG_ON() is better: it's very much by
design something that can be compiled away, so at least hopefully
nobody thinks of it as a security measure. So we could just say that
we will treat VM_BUG_ON() as a WARN_ON_ONCE(), and just not kill the
machine.

Because I could easily imagine that somebody *does* treat BUG_ON()
that way, thinking "well, if that BUG_ON() triggers at least it won't
then go off the rails later".

In fact, right now we mark BUG() in such a way that gcc can even take
advantage of the "crash the machine" semantics, because we explicitly
mark the BUG() with "unreachable()".

So what I think we should think about is:

 - extending the checkpatch warning to VM_BUG_ON too, to discourage new users.

 - look at making BUG_ON() simply be less lethal. Remove the
unrechable(), reorganize how the string is stored, and make it act
more like WARN_ON_ONCE() instead (it's the "rewind_stack_do_exit()"
that ends up causing us to try to kill things, we *could* just try to
stop doing that).

 - Instead of adding a BUG_ON_AND_HALT(), we could perhaps add a new
FATAL_ERROR() thing that acts like the current BUG_ON, and *not* call
it something similar (we don't want people doing mindless
conversions!). And that's the one that would do the whole
rewind_stack_do_exit() to kill the process.

But apart from the checkpatch thing, it's actually a pretty big change.

   Linus

Re: BUG_ON() in workingset_node_shadows_dec() triggers

[Linus Torvalds]

On Tue, Oct 4, 2016 at 7:43 PM, Paul Gortmaker
 wrote:
>
> A couple years ago Ingo had an idea to kill  BUG_ON abuse that I made
> a 1st pass at.  Back then it seemed nobody cared.  Maybe that has since
> changed?
>
> https://lkml.org/lkml/2014/4/30/359

So we actually have the checkpatch warning already:

  # avoid BUG() or BUG_ON()
if ($line =~ /\b(?:BUG|BUG_ON)\b/) {
my $msg_type = \
$msg_type = \ if ($file);
&{$msg_type}("AVOID_BUG",
 "Avoid crashing the kernel - try
using WARN_ON & recovery code rather than BUG() or BUG_ON()\n" .
$herecurr);
}

but it doesn't trigger on VM_BUG_ON().

And I'm not convinced about replacing things with BUG_ON_AND_HALT(),
it simply doesn't fix the existing issue we have: people use BUG_ON(),
and worse, _when_ they use BUG_ON(), they use it instead of error
handling, so the code _around_ the BUG_ON() tends to then very much
depend on what the BUG_ON() checks.

This is actually one way that VM_BUG_ON() is better: it's very much by
design something that can be compiled away, so at least hopefully
nobody thinks of it as a security measure. So we could just say that
we will treat VM_BUG_ON() as a WARN_ON_ONCE(), and just not kill the
machine.

Because I could easily imagine that somebody *does* treat BUG_ON()
that way, thinking "well, if that BUG_ON() triggers at least it won't
then go off the rails later".

In fact, right now we mark BUG() in such a way that gcc can even take
advantage of the "crash the machine" semantics, because we explicitly
mark the BUG() with "unreachable()".

So what I think we should think about is:

 - extending the checkpatch warning to VM_BUG_ON too, to discourage new users.

 - look at making BUG_ON() simply be less lethal. Remove the
unrechable(), reorganize how the string is stored, and make it act
more like WARN_ON_ONCE() instead (it's the "rewind_stack_do_exit()"
that ends up causing us to try to kill things, we *could* just try to
stop doing that).

 - Instead of adding a BUG_ON_AND_HALT(), we could perhaps add a new
FATAL_ERROR() thing that acts like the current BUG_ON, and *not* call
it something similar (we don't want people doing mindless
conversions!). And that's the one that would do the whole
rewind_stack_do_exit() to kill the process.

But apart from the checkpatch thing, it's actually a pretty big change.

   Linus

Re: [RESEND PATCH v2 1/3] dt: cpufreq: brcm: New binding document for brcmstb-avs-cpufreq

[Viresh Kumar]

On 30-09-16, 14:55, Markus Mayer wrote:
> Add the binding document for the new brcmstb-avs-cpufreq driver.
> 
> Signed-off-by: Markus Mayer 
> ---
>  .../bindings/cpufreq/brcm,stb-avs-cpu-freq.txt | 77 
> ++
>  MAINTAINERS|  7 ++
>  2 files changed, 84 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/cpufreq/brcm,stb-avs-cpu-freq.txt

Acked-by: Viresh Kumar 

-- 
viresh

Re: [RESEND PATCH v2 1/3] dt: cpufreq: brcm: New binding document for brcmstb-avs-cpufreq

[Viresh Kumar]

On 30-09-16, 14:55, Markus Mayer wrote:
> Add the binding document for the new brcmstb-avs-cpufreq driver.
> 
> Signed-off-by: Markus Mayer 
> ---
>  .../bindings/cpufreq/brcm,stb-avs-cpu-freq.txt | 77 
> ++
>  MAINTAINERS|  7 ++
>  2 files changed, 84 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/cpufreq/brcm,stb-avs-cpu-freq.txt

Acked-by: Viresh Kumar 

-- 
viresh

Re: [RESEND PATCH v2 3/3] cpufreq: brcmstb-avs-cpufreq: add debugfs support

[Viresh Kumar]

On 30-09-16, 14:56, Markus Mayer wrote:
> In order to aid debugging, we add a debugfs interface to the driver
> that allows direct interaction with the AVS co-processor.
> 
> The debugfs interface provides a means for reading all and writing some
> of the mailbox registers directly from the shell prompt and enables a
> user to execute the communications protocol between ARM CPU and AVS CPU
> step-by-step.
> 
> This interface should be used for debugging purposes only.
> 
> Signed-off-by: Markus Mayer 
> ---
>  drivers/cpufreq/brcmstb-avs-cpufreq.c | 319 
> ++
>  1 file changed, 319 insertions(+)

I am not sure how much useful this is going to be, but I don't have
any concerns against this as well.

Acked-by: Viresh Kumar 

-- 
viresh

Re: [RESEND PATCH v2 3/3] cpufreq: brcmstb-avs-cpufreq: add debugfs support

[Viresh Kumar]

On 30-09-16, 14:56, Markus Mayer wrote:
> In order to aid debugging, we add a debugfs interface to the driver
> that allows direct interaction with the AVS co-processor.
> 
> The debugfs interface provides a means for reading all and writing some
> of the mailbox registers directly from the shell prompt and enables a
> user to execute the communications protocol between ARM CPU and AVS CPU
> step-by-step.
> 
> This interface should be used for debugging purposes only.
> 
> Signed-off-by: Markus Mayer 
> ---
>  drivers/cpufreq/brcmstb-avs-cpufreq.c | 319 
> ++
>  1 file changed, 319 insertions(+)

I am not sure how much useful this is going to be, but I don't have
any concerns against this as well.

Acked-by: Viresh Kumar 

-- 
viresh

Re: [RESEND PATCH v2 2/3] cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver for Broadcom STB SoCs

[Viresh Kumar]

On 30-09-16, 14:56, Markus Mayer wrote:
> This driver supports voltage and frequency scaling on Broadcom STB SoCs
> using AVS firmware with DFS and DVFS support.
> 
> Actual frequency or voltage scaling is done exclusively by the AVS
> firmware. The driver merely provides a standard CPUfreq interface to
> other kernel components and userland, and instructs the AVS firmware to
> perform frequency or voltage changes on its behalf.
> 
> Signed-off-by: Markus Mayer 
> ---
>  Documentation/cpu-freq/brcmstb-avs-cpufreq.txt |  27 +
>  MAINTAINERS|   2 +
>  drivers/cpufreq/Kconfig.arm|  10 +
>  drivers/cpufreq/Makefile   |   1 +
>  drivers/cpufreq/brcmstb-avs-cpufreq.c  | 707 
> +
>  5 files changed, 747 insertions(+)
>  create mode 100644 Documentation/cpu-freq/brcmstb-avs-cpufreq.txt
>  create mode 100644 drivers/cpufreq/brcmstb-avs-cpufreq.c
> 
> diff --git a/Documentation/cpu-freq/brcmstb-avs-cpufreq.txt 
> b/Documentation/cpu-freq/brcmstb-avs-cpufreq.txt
> new file mode 100644
> index 000..c6503e1
> --- /dev/null
> +++ b/Documentation/cpu-freq/brcmstb-avs-cpufreq.txt
> @@ -0,0 +1,27 @@
> +Broadcom STB AVS CPUfreq driver
> +===
> +
> +"AVS" is the name of a firmware developed at Broadcom. It derives its
> +name from the technique called "Adaptive Voltage Scaling". Adaptive
> +voltage scaling was the original purpose of this firmware. The AVS
> +firmware still supports "AVS mode", where all it does is adaptive
> +voltage scaling. However, on some newer Broadcom SoCs, the AVS
> +Firmware, despite its unchanged name, also supports DFS mode and DVFS
> +mode.
> +
> +In the context of this document and the related driver, "AVS" by itself
> +always means the Broadcom firmware and never refers to the technique
> +called "Adaptive Voltage Scaling".
> +
> +The Broadcom STB AVS CPUfreq driver provides voltage and frequency
> +scaling on Broadcom SoCs using AVS firmware with support for DFS and
> +DVFS. The AVS firmware is running on its own co-processor. The driver
> +supports both uniprocessor (UP) and symmetric multiprocessor (SMP)
> +systems which share clock and voltage across all CPUs.
> +
> +Actual voltage and frequency scaling is done solely by the AVS firmware.
> +This driver does not change frequency or voltage itself. It provides a
> +standard CPUfreq interface to the rest of the kernel and to userland. It
> +interfaces with the AVS firmware to effect the requested changes and to
> +report back the current system status in a way that is expected by existing
> +tools.

Do we really need this file? Can't part of it go to the binding
document? I am not sure I see any useful information here which is
mandatory. If the DT file doesn't work well, a big comment at the top
of the driver's .c file should do..

> diff --git a/MAINTAINERS b/MAINTAINERS
> index 557f839..708b2bc 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2695,6 +2695,8 @@ M:  bcm-kernel-feedback-l...@broadcom.com
>  L:   linux...@vger.kernel.org
>  S:   Maintained
>  F:   Documentation/devicetree/bindings/cpufreq/brcm,stb-avs-cpu-freq.txt
> +F:   Documentation/cpu-freq/brcmstb-avs-cpufreq.txt
> +F:   drivers/cpufreq/brcm-avs-cpufreq.c
>  
>  BROADCOM SPECIFIC AMBA DRIVER (BCMA)
>  M:   Rafał Miłecki 
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index d89b8af..4177f45 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -12,6 +12,16 @@ config ARM_BIG_LITTLE_CPUFREQ
>   help
> This enables the Generic CPUfreq driver for ARM big.LITTLE platforms.
>  
> +config ARM_BRCMSTB_AVS_CPUFREQ
> + tristate "Broadcom STB AVS CPUfreq driver"
> + depends on ARCH_BRCMSTB || COMPILE_TEST
> + help
> +   Some Broadcom STB SoCs use a co-processor running proprietary firmware
> +   ("AVS") to handle voltage and frequency scaling. This driver provides
> +   a standard CPUfreq interface to to the firmware.
> +
> +   Say Y, if you have a Broadcom SoC with AVS support for DFS or DVFS.
> +
>  config ARM_DT_BL_CPUFREQ
>   tristate "Generic probing via DT for ARM big LITTLE CPUfreq driver"
>   depends on ARM_BIG_LITTLE_CPUFREQ && OF
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index 0a9b6a09..ac54f64 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -51,6 +51,7 @@ obj-$(CONFIG_ARM_BIG_LITTLE_CPUFREQ)+= 
> arm_big_little.o
>  # LITTLE drivers, so that it is probed last.
>  obj-$(CONFIG_ARM_DT_BL_CPUFREQ)  += arm_big_little_dt.o
>  
> +obj-$(CONFIG_ARM_BRCMSTB_AVS_CPUFREQ)+= brcmstb-avs-cpufreq.o
>  obj-$(CONFIG_ARCH_DAVINCI)   += davinci-cpufreq.o
>  obj-$(CONFIG_UX500_SOC_DB8500)   += dbx500-cpufreq.o
>  obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ) += exynos5440-cpufreq.o
> diff --git 

Re: [RESEND PATCH v2 2/3] cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver for Broadcom STB SoCs

[Viresh Kumar]

On 30-09-16, 14:56, Markus Mayer wrote:
> This driver supports voltage and frequency scaling on Broadcom STB SoCs
> using AVS firmware with DFS and DVFS support.
> 
> Actual frequency or voltage scaling is done exclusively by the AVS
> firmware. The driver merely provides a standard CPUfreq interface to
> other kernel components and userland, and instructs the AVS firmware to
> perform frequency or voltage changes on its behalf.
> 
> Signed-off-by: Markus Mayer 
> ---
>  Documentation/cpu-freq/brcmstb-avs-cpufreq.txt |  27 +
>  MAINTAINERS|   2 +
>  drivers/cpufreq/Kconfig.arm|  10 +
>  drivers/cpufreq/Makefile   |   1 +
>  drivers/cpufreq/brcmstb-avs-cpufreq.c  | 707 
> +
>  5 files changed, 747 insertions(+)
>  create mode 100644 Documentation/cpu-freq/brcmstb-avs-cpufreq.txt
>  create mode 100644 drivers/cpufreq/brcmstb-avs-cpufreq.c
> 
> diff --git a/Documentation/cpu-freq/brcmstb-avs-cpufreq.txt 
> b/Documentation/cpu-freq/brcmstb-avs-cpufreq.txt
> new file mode 100644
> index 000..c6503e1
> --- /dev/null
> +++ b/Documentation/cpu-freq/brcmstb-avs-cpufreq.txt
> @@ -0,0 +1,27 @@
> +Broadcom STB AVS CPUfreq driver
> +===
> +
> +"AVS" is the name of a firmware developed at Broadcom. It derives its
> +name from the technique called "Adaptive Voltage Scaling". Adaptive
> +voltage scaling was the original purpose of this firmware. The AVS
> +firmware still supports "AVS mode", where all it does is adaptive
> +voltage scaling. However, on some newer Broadcom SoCs, the AVS
> +Firmware, despite its unchanged name, also supports DFS mode and DVFS
> +mode.
> +
> +In the context of this document and the related driver, "AVS" by itself
> +always means the Broadcom firmware and never refers to the technique
> +called "Adaptive Voltage Scaling".
> +
> +The Broadcom STB AVS CPUfreq driver provides voltage and frequency
> +scaling on Broadcom SoCs using AVS firmware with support for DFS and
> +DVFS. The AVS firmware is running on its own co-processor. The driver
> +supports both uniprocessor (UP) and symmetric multiprocessor (SMP)
> +systems which share clock and voltage across all CPUs.
> +
> +Actual voltage and frequency scaling is done solely by the AVS firmware.
> +This driver does not change frequency or voltage itself. It provides a
> +standard CPUfreq interface to the rest of the kernel and to userland. It
> +interfaces with the AVS firmware to effect the requested changes and to
> +report back the current system status in a way that is expected by existing
> +tools.

Do we really need this file? Can't part of it go to the binding
document? I am not sure I see any useful information here which is
mandatory. If the DT file doesn't work well, a big comment at the top
of the driver's .c file should do..

> diff --git a/MAINTAINERS b/MAINTAINERS
> index 557f839..708b2bc 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2695,6 +2695,8 @@ M:  bcm-kernel-feedback-l...@broadcom.com
>  L:   linux...@vger.kernel.org
>  S:   Maintained
>  F:   Documentation/devicetree/bindings/cpufreq/brcm,stb-avs-cpu-freq.txt
> +F:   Documentation/cpu-freq/brcmstb-avs-cpufreq.txt
> +F:   drivers/cpufreq/brcm-avs-cpufreq.c
>  
>  BROADCOM SPECIFIC AMBA DRIVER (BCMA)
>  M:   Rafał Miłecki 
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index d89b8af..4177f45 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -12,6 +12,16 @@ config ARM_BIG_LITTLE_CPUFREQ
>   help
> This enables the Generic CPUfreq driver for ARM big.LITTLE platforms.
>  
> +config ARM_BRCMSTB_AVS_CPUFREQ
> + tristate "Broadcom STB AVS CPUfreq driver"
> + depends on ARCH_BRCMSTB || COMPILE_TEST
> + help
> +   Some Broadcom STB SoCs use a co-processor running proprietary firmware
> +   ("AVS") to handle voltage and frequency scaling. This driver provides
> +   a standard CPUfreq interface to to the firmware.
> +
> +   Say Y, if you have a Broadcom SoC with AVS support for DFS or DVFS.
> +
>  config ARM_DT_BL_CPUFREQ
>   tristate "Generic probing via DT for ARM big LITTLE CPUfreq driver"
>   depends on ARM_BIG_LITTLE_CPUFREQ && OF
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index 0a9b6a09..ac54f64 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -51,6 +51,7 @@ obj-$(CONFIG_ARM_BIG_LITTLE_CPUFREQ)+= 
> arm_big_little.o
>  # LITTLE drivers, so that it is probed last.
>  obj-$(CONFIG_ARM_DT_BL_CPUFREQ)  += arm_big_little_dt.o
>  
> +obj-$(CONFIG_ARM_BRCMSTB_AVS_CPUFREQ)+= brcmstb-avs-cpufreq.o
>  obj-$(CONFIG_ARCH_DAVINCI)   += davinci-cpufreq.o
>  obj-$(CONFIG_UX500_SOC_DB8500)   += dbx500-cpufreq.o
>  obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ) += exynos5440-cpufreq.o
> diff --git a/drivers/cpufreq/brcmstb-avs-cpufreq.c 
> 

Re: [RFC][PATCH] cgroup: Add new capability to allow a process to migrate other tasks between cgroups

[John Stultz]

On Tue, Oct 4, 2016 at 5:38 PM, Serge E. Hallyn  wrote:
> Quoting John Stultz (john.stu...@linaro.org):
>> So this patch, as suggested by Tejun,  simply adds a new process
>> capability flag (CAP_CGROUP_MIGRATE_TASK), and uses it when checking
>
> So realistically, what all can this mean?  Freezing tasks, changing
> cpu/memory limits, changing network and disk throughput, forbid forking,
> and (most importantly) forbid access to certain devices.
>
> I think that's all ok.  (And we still separately check for inode write
> perms.)

Sounds good.

> If anything I'd say the GLOBAL_ROOT_UID check could be taken out since
> otherwise a host-root task effectively cannot drop this capability.

Is this ok to leave for a separate patch?

> Acked-by: Serge Hallyn 

Thanks for the review!

Unless there's other feedback, I'll sit on this until the merge window
is over and then resubmit for consideration for 4.10.

thanks
-john

Re: [RFC][PATCH] cgroup: Add new capability to allow a process to migrate other tasks between cgroups

[John Stultz]

On Tue, Oct 4, 2016 at 5:38 PM, Serge E. Hallyn  wrote:
> Quoting John Stultz (john.stu...@linaro.org):
>> So this patch, as suggested by Tejun,  simply adds a new process
>> capability flag (CAP_CGROUP_MIGRATE_TASK), and uses it when checking
>
> So realistically, what all can this mean?  Freezing tasks, changing
> cpu/memory limits, changing network and disk throughput, forbid forking,
> and (most importantly) forbid access to certain devices.
>
> I think that's all ok.  (And we still separately check for inode write
> perms.)

Sounds good.

> If anything I'd say the GLOBAL_ROOT_UID check could be taken out since
> otherwise a host-root task effectively cannot drop this capability.

Is this ok to leave for a separate patch?

> Acked-by: Serge Hallyn 

Thanks for the review!

Unless there's other feedback, I'll sit on this until the merge window
is over and then resubmit for consideration for 4.10.

thanks
-john

Re: [PATCH 08/14] dt-bindings: sound: Add sun8i analog codec documentation

[Chen-Yu Tsai]

On Wed, Oct 5, 2016 at 12:24 AM, Maxime Ripard
 wrote:
> Hi,
>
> On Tue, Oct 04, 2016 at 11:46:21AM +0200, Mylène Josserand wrote:
>> Add the documentation for dt-binding of the analog audiocodec
>> driver for SUN8I SoC.
>>
>> Signed-off-by: Mylène Josserand 
>> ---
>>  .../devicetree/bindings/sound/sun8i-codec-analog.txt | 20 
>> 
>>  1 file changed, 20 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
>>
>> diff --git a/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt 
>> b/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
>> new file mode 100644
>> index 000..a03ec20
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
>> @@ -0,0 +1,20 @@
>> +* Allwinner A23/A33 Analog Codec
>> +
>> +This codec must be handled as a PRCM subnode.
>
> Like Mark was saying, you should probably reference the sun6i-prcm.txt
> binding here
>
>> +Required properties:
>> +- compatible: must be either "allwinner,sun8i-codec-analog"
>
> Our compatible prefix is -, and using the older SoC that
> introduced that block.
>
> In this case, that would be sun6i-a31, I think?

sun6i-a31s actually, but a31s has extra line out controls,
so the right one would be sun8i-a23. Both are listed in my
original driver.

ChenYu

>
> Thanks,
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

Re: [PATCH 08/14] dt-bindings: sound: Add sun8i analog codec documentation

[Chen-Yu Tsai]

On Wed, Oct 5, 2016 at 12:24 AM, Maxime Ripard
 wrote:
> Hi,
>
> On Tue, Oct 04, 2016 at 11:46:21AM +0200, Mylène Josserand wrote:
>> Add the documentation for dt-binding of the analog audiocodec
>> driver for SUN8I SoC.
>>
>> Signed-off-by: Mylène Josserand 
>> ---
>>  .../devicetree/bindings/sound/sun8i-codec-analog.txt | 20 
>> 
>>  1 file changed, 20 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
>>
>> diff --git a/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt 
>> b/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
>> new file mode 100644
>> index 000..a03ec20
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
>> @@ -0,0 +1,20 @@
>> +* Allwinner A23/A33 Analog Codec
>> +
>> +This codec must be handled as a PRCM subnode.
>
> Like Mark was saying, you should probably reference the sun6i-prcm.txt
> binding here
>
>> +Required properties:
>> +- compatible: must be either "allwinner,sun8i-codec-analog"
>
> Our compatible prefix is -, and using the older SoC that
> introduced that block.
>
> In this case, that would be sun6i-a31, I think?

sun6i-a31s actually, but a31s has extra line out controls,
so the right one would be sun8i-a23. Both are listed in my
original driver.

ChenYu

>
> Thanks,
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

[PATCH] timekeeping: Fix __ktime_get_fast_ns() regression

[John Stultz]

In commit 27727df240c7 ("Avoid taking lock in NMI path with
CONFIG_DEBUG_TIMEKEEPING"), I changed the logic to open-code
the timekeeping_get_ns() function, but I forgot to include
the unit conversion from cycles to nanoseconds, breaking the
function's output, which impacts users like perf.

This would result in bogus perf timestamps like:
 swapper 0 [000]   253.427536:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]   254.426573:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]   254.426687:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]   254.426800:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]   254.426905:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]   254.427022:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]   254.427127:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]   254.427239:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]   254.427346:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]   254.427463:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]   255.426572:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])

Instead of more reasonable expected timestamps like:
 swapper 0 [000]39.953768:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]40.064839:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]40.175956:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]40.287103:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]40.398217:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]40.509324:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]40.620437:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]40.731546:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]40.842654:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]40.953772:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]41.064881:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])

This patch adds the proper use of timekeeping_delta_to_ns()
to convert the cycle delta to nanoseconds as needed.

Thanks to Brendan and Alexei for finding this quickly after
the v4.8 release. Unfortunately the problematic commit has
landed in some -stable trees so they'll need this fix as
well.

Many apologies for this mistake. I'll be looking to add a
perf-clock sanity test to the kselftest timers tests soon.

Cc: Steven Rostedt 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: stable 
Cc: Brendan Gregg 
Cc: Alexei Starovoitov 
Fixes: 27727df240c7 "timekeeping: Avoid taking lock in NMI path with 
CONFIG_DEBUG_TIMEKEEPING"
Reported-by: Brendan Gregg 
Reported-by: Alexei Starovoitov 
Signed-off-by: John Stultz 
---
Thomas/Ingo:
I've reproduced the issue and validated this fixes it, but given my limited perf
usage so far, I'd appreciate waiting for a Tested-by: from one of the reporters
before considering for tip/timers/urgent.

 kernel/time/timekeeping.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index e07fb09..37dec7e 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -403,8 +403,11 @@ static __always_inline u64 __ktime_get_fast_ns(struct 
tk_fast *tkf)
tkr = tkf->base + (seq & 0x01);
now = ktime_to_ns(tkr->base);
 
-   now += clocksource_delta(tkr->read(tkr->clock),
-tkr->cycle_last, tkr->mask);
+   now += timekeeping_delta_to_ns(tkr,
+   clocksource_delta(
+   tkr->read(tkr->clock),
+   tkr->cycle_last,
+   tkr->mask));

[PATCH] timekeeping: Fix __ktime_get_fast_ns() regression

[John Stultz]

In commit 27727df240c7 ("Avoid taking lock in NMI path with
CONFIG_DEBUG_TIMEKEEPING"), I changed the logic to open-code
the timekeeping_get_ns() function, but I forgot to include
the unit conversion from cycles to nanoseconds, breaking the
function's output, which impacts users like perf.

This would result in bogus perf timestamps like:
 swapper 0 [000]   253.427536:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]   254.426573:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]   254.426687:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]   254.426800:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]   254.426905:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]   254.427022:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]   254.427127:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]   254.427239:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]   254.427346:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]   254.427463:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]   255.426572:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])

Instead of more reasonable expected timestamps like:
 swapper 0 [000]39.953768:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]40.064839:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]40.175956:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]40.287103:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]40.398217:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]40.509324:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]40.620437:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]40.731546:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]40.842654:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]40.953772:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])
 swapper 0 [000]41.064881:  1 cpu-clock:  810a0de6 
native_safe_halt+0x6 ([kernel.kallsyms])

This patch adds the proper use of timekeeping_delta_to_ns()
to convert the cycle delta to nanoseconds as needed.

Thanks to Brendan and Alexei for finding this quickly after
the v4.8 release. Unfortunately the problematic commit has
landed in some -stable trees so they'll need this fix as
well.

Many apologies for this mistake. I'll be looking to add a
perf-clock sanity test to the kselftest timers tests soon.

Cc: Steven Rostedt 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: stable 
Cc: Brendan Gregg 
Cc: Alexei Starovoitov 
Fixes: 27727df240c7 "timekeeping: Avoid taking lock in NMI path with 
CONFIG_DEBUG_TIMEKEEPING"
Reported-by: Brendan Gregg 
Reported-by: Alexei Starovoitov 
Signed-off-by: John Stultz 
---
Thomas/Ingo:
I've reproduced the issue and validated this fixes it, but given my limited perf
usage so far, I'd appreciate waiting for a Tested-by: from one of the reporters
before considering for tip/timers/urgent.

 kernel/time/timekeeping.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index e07fb09..37dec7e 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -403,8 +403,11 @@ static __always_inline u64 __ktime_get_fast_ns(struct 
tk_fast *tkf)
tkr = tkf->base + (seq & 0x01);
now = ktime_to_ns(tkr->base);
 
-   now += clocksource_delta(tkr->read(tkr->clock),
-tkr->cycle_last, tkr->mask);
+   now += timekeeping_delta_to_ns(tkr,
+   clocksource_delta(
+   tkr->read(tkr->clock),
+   tkr->cycle_last,
+   tkr->mask));
} while (read_seqcount_retry(>seq, seq));
 
return now;
-- 
1.9.1

Re: [PATCH v14 2/4] CMDQ: Mediatek CMDQ driver

[Horng-Shyang Liao]

On Fri, 2016-09-30 at 17:47 +0800, Horng-Shyang Liao wrote:
> On Fri, 2016-09-30 at 17:11 +0800, CK Hu wrote:
> > Hi, HS:
> > 
> > One comment inline
> > 
> > On Fri, 2016-09-30 at 16:56 +0800, Horng-Shyang Liao wrote:
> > > Hi CK,
> > > 
> > > Please see my inline reply.
> > > 
> > > On Fri, 2016-09-30 at 11:06 +0800, CK Hu wrote:
> > > > Hi, HS:
> > > > 
> > > > On Mon, 2016-09-05 at 09:44 +0800, HS Liao wrote:
> > > > > This patch is first version of Mediatek Command Queue(CMDQ) driver. 
> > > > > The
> > > > > CMDQ is used to help write registers with critical time limitation,
> > > > > such as updating display configuration during the vblank. It controls
> > > > > Global Command Engine (GCE) hardware to achieve this requirement.
> > > > > Currently, CMDQ only supports display related hardwares, but we expect
> > > > > it can be extended to other hardwares for future requirements.
> > > > > 
> > > > > Signed-off-by: HS Liao 
> > > > > Signed-off-by: CK Hu 
> > > > > ---
> > > > 
> > > > [snip...]
> > > > 
> > > > > +
> > > > > +struct cmdq_task {
> > > > > + struct cmdq *cmdq;
> > > > > + struct list_headlist_entry;
> > > > > + void*va_base;
> > > > > + dma_addr_t  pa_base;
> > > > > + size_t  cmd_buf_size; /* command occupied size 
> > > > > */
> > > > > + size_t  buf_size; /* real buffer size */
> > > > > + boolfinalized;
> > > > > + struct cmdq_thread  *thread;
> > > > 
> > > > I think thread info could be removed from cmdq_task. Only
> > > > cmdq_task_handle_error() and cmdq_task_insert_into_thread() use
> > > > task->thread and caller of both function has the thread info. So you
> > > > could just pass thread info into these two function and remove thread
> > > > info in cmdq_task.
> > > 
> > > This modification will remove 1 pointer but add 2 pointers. Moreover,
> > > more pointers will need to be delivered between functions for future
> > > extension. IMHO, it would be better to keep thread pointer inside
> > > cmdq_task.
> > > 
> > > > > + struct cmdq_task_cb cb;
> > > > 
> > > > I think this callback function is equal to mailbox client tx_done
> > > > callback. It's better to use already-defined interface rather than
> > > > creating your own.
> > > 
> > > This is because CMDQ driver allows different callback functions for
> > > different tasks, but mailbox only allows one callback function per
> > > channel. But, I think I can add a wrapper for tx_done to call CMDQ
> > > callback functions. So, I will use tx_done in CMDQ v15.
> > 
> > Up to now, one callback function for one channel is enough for DRM. So
> > 'different callback function for different sent-message' looks like an
> > advanced function. Maybe you should not include it in first patch. 
> > 
> > Regards,
> > CK
> 
> Hi CK,
> 
> OK. I will do it.
> 
> Thanks,
> HS
> 
> [snip...]


Hi CK,

After I trace mailbox driver, I realize that CMDQ driver cannot use
tx_done.

CMDQ clients will flush many tasks into CMDQ driver, and then CMDQ
driver will apply these tasks into GCE HW "immediately". These tasks,
which are queued in GCE HW, may not execute immediately since they
may need to wait event(s), e.g. vsync.

However, in mailbox driver, mailbox uses a software buffer to queue
sent messages. It only sends next message until previous message is
done. This cannot fulfill CMDQ's requirement.

Quote some code from mailbox driver. Please notice "active_req" part.

static void msg_submit(struct mbox_chan *chan)
{
...
if (!chan->msg_count || chan->active_req)
goto exit;
...
err = chan->mbox->ops->send_data(chan, data);
if (!err) {
chan->active_req = data;
chan->msg_count--;
}
...
}

static void tx_tick(struct mbox_chan *chan, int r)
{
...
spin_lock_irqsave(>lock, flags);
mssg = chan->active_req;
chan->active_req = NULL;
spin_unlock_irqrestore(>lock, flags);
...
}

Current workable CMDQ driver uses mbox_client_txdone() to prevent
this issue, and then uses self callback functions to handle done tasks.

int cmdq_task_flush_async(struct cmdq_client *client, struct cmdq_task
*task, cmdq_async_flush_cb cb, void *data)
{
...
mbox_send_message(client->chan, task);
/* We can send next task immediately, so just call txdone. */
mbox_client_txdone(client->chan, 0);
...
}

Another solution is to use rx_callback; i.e. CMDQ mailbox controller
call mbox_chan_received_data() when CMDQ task is done. But, this may
violate the design of mailbox. What do you think?

Thanks,
HS


Hi Jassi,

Do you have any suggestion about previous situation?

Thanks,
HS

Re: [PATCH v14 2/4] CMDQ: Mediatek CMDQ driver

[Horng-Shyang Liao]

On Fri, 2016-09-30 at 17:47 +0800, Horng-Shyang Liao wrote:
> On Fri, 2016-09-30 at 17:11 +0800, CK Hu wrote:
> > Hi, HS:
> > 
> > One comment inline
> > 
> > On Fri, 2016-09-30 at 16:56 +0800, Horng-Shyang Liao wrote:
> > > Hi CK,
> > > 
> > > Please see my inline reply.
> > > 
> > > On Fri, 2016-09-30 at 11:06 +0800, CK Hu wrote:
> > > > Hi, HS:
> > > > 
> > > > On Mon, 2016-09-05 at 09:44 +0800, HS Liao wrote:
> > > > > This patch is first version of Mediatek Command Queue(CMDQ) driver. 
> > > > > The
> > > > > CMDQ is used to help write registers with critical time limitation,
> > > > > such as updating display configuration during the vblank. It controls
> > > > > Global Command Engine (GCE) hardware to achieve this requirement.
> > > > > Currently, CMDQ only supports display related hardwares, but we expect
> > > > > it can be extended to other hardwares for future requirements.
> > > > > 
> > > > > Signed-off-by: HS Liao 
> > > > > Signed-off-by: CK Hu 
> > > > > ---
> > > > 
> > > > [snip...]
> > > > 
> > > > > +
> > > > > +struct cmdq_task {
> > > > > + struct cmdq *cmdq;
> > > > > + struct list_headlist_entry;
> > > > > + void*va_base;
> > > > > + dma_addr_t  pa_base;
> > > > > + size_t  cmd_buf_size; /* command occupied size 
> > > > > */
> > > > > + size_t  buf_size; /* real buffer size */
> > > > > + boolfinalized;
> > > > > + struct cmdq_thread  *thread;
> > > > 
> > > > I think thread info could be removed from cmdq_task. Only
> > > > cmdq_task_handle_error() and cmdq_task_insert_into_thread() use
> > > > task->thread and caller of both function has the thread info. So you
> > > > could just pass thread info into these two function and remove thread
> > > > info in cmdq_task.
> > > 
> > > This modification will remove 1 pointer but add 2 pointers. Moreover,
> > > more pointers will need to be delivered between functions for future
> > > extension. IMHO, it would be better to keep thread pointer inside
> > > cmdq_task.
> > > 
> > > > > + struct cmdq_task_cb cb;
> > > > 
> > > > I think this callback function is equal to mailbox client tx_done
> > > > callback. It's better to use already-defined interface rather than
> > > > creating your own.
> > > 
> > > This is because CMDQ driver allows different callback functions for
> > > different tasks, but mailbox only allows one callback function per
> > > channel. But, I think I can add a wrapper for tx_done to call CMDQ
> > > callback functions. So, I will use tx_done in CMDQ v15.
> > 
> > Up to now, one callback function for one channel is enough for DRM. So
> > 'different callback function for different sent-message' looks like an
> > advanced function. Maybe you should not include it in first patch. 
> > 
> > Regards,
> > CK
> 
> Hi CK,
> 
> OK. I will do it.
> 
> Thanks,
> HS
> 
> [snip...]


Hi CK,

After I trace mailbox driver, I realize that CMDQ driver cannot use
tx_done.

CMDQ clients will flush many tasks into CMDQ driver, and then CMDQ
driver will apply these tasks into GCE HW "immediately". These tasks,
which are queued in GCE HW, may not execute immediately since they
may need to wait event(s), e.g. vsync.

However, in mailbox driver, mailbox uses a software buffer to queue
sent messages. It only sends next message until previous message is
done. This cannot fulfill CMDQ's requirement.

Quote some code from mailbox driver. Please notice "active_req" part.

static void msg_submit(struct mbox_chan *chan)
{
...
if (!chan->msg_count || chan->active_req)
goto exit;
...
err = chan->mbox->ops->send_data(chan, data);
if (!err) {
chan->active_req = data;
chan->msg_count--;
}
...
}

static void tx_tick(struct mbox_chan *chan, int r)
{
...
spin_lock_irqsave(>lock, flags);
mssg = chan->active_req;
chan->active_req = NULL;
spin_unlock_irqrestore(>lock, flags);
...
}

Current workable CMDQ driver uses mbox_client_txdone() to prevent
this issue, and then uses self callback functions to handle done tasks.

int cmdq_task_flush_async(struct cmdq_client *client, struct cmdq_task
*task, cmdq_async_flush_cb cb, void *data)
{
...
mbox_send_message(client->chan, task);
/* We can send next task immediately, so just call txdone. */
mbox_client_txdone(client->chan, 0);
...
}

Another solution is to use rx_callback; i.e. CMDQ mailbox controller
call mbox_chan_received_data() when CMDQ task is done. But, this may
violate the design of mailbox. What do you think?

Thanks,
HS


Hi Jassi,

Do you have any suggestion about previous situation?

Thanks,
HS

Re: BUG_ON() in workingset_node_shadows_dec() triggers

[Paul Gortmaker]

On Tue, Oct 4, 2016 at 12:00 AM, Linus Torvalds
 wrote:

[...]

> I should have reacted to the damn added BUG_ON() lines. I suspect I
> will have to finally just remove the idiotic BUG_ON() concept once and
> for all, because there is NO F*CKING EXCUSE to knowingly kill the
> kernel.

A couple years ago Ingo had an idea to kill  BUG_ON abuse that I made
a 1st pass at.  Back then it seemed nobody cared.  Maybe that has since
changed?

https://lkml.org/lkml/2014/4/30/359

P.
--

Re: BUG_ON() in workingset_node_shadows_dec() triggers

[Paul Gortmaker]

On Tue, Oct 4, 2016 at 12:00 AM, Linus Torvalds
 wrote:

[...]

> I should have reacted to the damn added BUG_ON() lines. I suspect I
> will have to finally just remove the idiotic BUG_ON() concept once and
> for all, because there is NO F*CKING EXCUSE to knowingly kill the
> kernel.

A couple years ago Ingo had an idea to kill  BUG_ON abuse that I made
a 1st pass at.  Back then it seemed nobody cared.  Maybe that has since
changed?

https://lkml.org/lkml/2014/4/30/359

P.
--

Re: [1/3] bpf powerpc: introduce accessors for using the tmp local stack space

[Michael Ellerman]

On Fri, 2016-23-09 at 20:35:00 UTC, "Naveen N. Rao" wrote:
> While at it, ensure that the location of the local save area is
> consistent whether or not we setup our own stackframe. This property is
> utilised in the next patch that adds support for tail calls.
> 
> Signed-off-by: Naveen N. Rao 

Series applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/7b847f523fe07b4ad73a01cec49a4d

cheers

Re: [1/3] bpf powerpc: introduce accessors for using the tmp local stack space

[Michael Ellerman]

On Fri, 2016-23-09 at 20:35:00 UTC, "Naveen N. Rao" wrote:
> While at it, ensure that the location of the local save area is
> consistent whether or not we setup our own stackframe. This property is
> utilised in the next patch that adds support for tail calls.
> 
> Signed-off-by: Naveen N. Rao 

Series applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/7b847f523fe07b4ad73a01cec49a4d

cheers

Re: cxl: replace loop with for_each_child_of_node(), remove unneeded of_node_put()

[Michael Ellerman]

On Fri, 2016-29-07 at 03:55:34 UTC, Andrew Donnellan wrote:
> Rewrite the cxl_guest_init_afu() loop in cxl_of_probe() to use
> for_each_child_of_node() rather than a hand-coded for loop.
> 
> Remove the useless of_node_put(afu_np) call after the loop, where it's
> guaranteed that afu_np == NULL.
> 
> Reported-by: SF Markus Elfring 
> Reported-by: Julia Lawall 
> Signed-off-by: Andrew Donnellan 
> Reviewed-by: Frederic Barrat 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/735840b44bcc998e2574faf63d1aaa

cheers

Re: cxl: replace loop with for_each_child_of_node(), remove unneeded of_node_put()

[Michael Ellerman]

On Fri, 2016-29-07 at 03:55:34 UTC, Andrew Donnellan wrote:
> Rewrite the cxl_guest_init_afu() loop in cxl_of_probe() to use
> for_each_child_of_node() rather than a hand-coded for loop.
> 
> Remove the useless of_node_put(afu_np) call after the loop, where it's
> guaranteed that afu_np == NULL.
> 
> Reported-by: SF Markus Elfring 
> Reported-by: Julia Lawall 
> Signed-off-by: Andrew Donnellan 
> Reviewed-by: Frederic Barrat 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/735840b44bcc998e2574faf63d1aaa

cheers

Re: [PATCH 1/7] selftest: sync: basic tests for sw_sync framework

[Michael Ellerman]

Emilio López  writes:

> Hi,
>
> El 27/09/16 a las 01:23, Michael Ellerman escribió:
>> Emilio López  writes:
>>> El 22/09/16 a las 06:43, Michael Ellerman escribió:
 Emilio López  writes:

 Please don't include the *kernel* headers, they're really not meant to
 be used in userspace programs :)

> +CFLAGS += -I../../../../usr/include/

 That is the correct place to get them from. They'll have been put there
 by 'make headers_install'.
>>>
>>> My inspiration here has been tools/testing/selftests/memfd/Makefile,
>>> which does it this way. If I only include the ones on usr then it
>>> doesn't build, as there's no sync_file.h available, even after running
>>> make headers_install. How am I supposed to use the ioctls from there?
>>
>> It looks like it's missing from include/uapi/linux/Kbuild, you need to
>> add it to the list of exported headers:
>
> I tried that over the weekend and it worked, but I wondered if it was 
> the way to go. Thanks for the confirmation :) I've sent a patch for 
> that[0] now.

Great thanks.

> With that resolved, CFLAGS can just be
>
> CFLAGS += -O2 -g -std=gnu89 -pthread -Wall -Wextra
> CFLAGS += -I../../../../usr/include/

LGTM.

cheers

Re: [PATCH 1/7] selftest: sync: basic tests for sw_sync framework

[Michael Ellerman]

Emilio López  writes:

> Hi,
>
> El 27/09/16 a las 01:23, Michael Ellerman escribió:
>> Emilio López  writes:
>>> El 22/09/16 a las 06:43, Michael Ellerman escribió:
 Emilio López  writes:

 Please don't include the *kernel* headers, they're really not meant to
 be used in userspace programs :)

> +CFLAGS += -I../../../../usr/include/

 That is the correct place to get them from. They'll have been put there
 by 'make headers_install'.
>>>
>>> My inspiration here has been tools/testing/selftests/memfd/Makefile,
>>> which does it this way. If I only include the ones on usr then it
>>> doesn't build, as there's no sync_file.h available, even after running
>>> make headers_install. How am I supposed to use the ioctls from there?
>>
>> It looks like it's missing from include/uapi/linux/Kbuild, you need to
>> add it to the list of exported headers:
>
> I tried that over the weekend and it worked, but I wondered if it was 
> the way to go. Thanks for the confirmation :) I've sent a patch for 
> that[0] now.

Great thanks.

> With that resolved, CFLAGS can just be
>
> CFLAGS += -O2 -g -std=gnu89 -pthread -Wall -Wextra
> CFLAGS += -I../../../../usr/include/

LGTM.

cheers

Use of r10 in powerpc syscall entry

[Keno Fischer]

Hi Anton,

I was reading the powerpc syscall entry code and git points me at your commit
05b05f28 (powerpc: Relocatable system call no longer uses the LR) for one
part that confused me, so I hope you don't mind a quick question. In particular,
that commit removed the use of r10 to restore lr, but didn't touch the earlier
`mflr r10` to actually save the lr to r10. Is r10 still required there
for some reason
or is that just left over? Part of the reason I'm asking is because it seems
one could use r10, instead of r13 later, i.e.

  #define SYSCALL_PSERIES_2_DIRECT \
-  mflr r10 ; \
  ld r12,PACAKBASE(r13) ; \
  LOAD_HANDLER(r12, system_call_entry) ; \
  mtctr r12 ; \
  mfspr r12,SPRN_SRR1 ; \
- /* Re-use of r13... No spare regs to do this */ \
- li r13,MSR_RI ; \
- mtmsrd r13,1 ; \
+ li r10, MSR_RI ; \
+ mtmsrd r10,1 ; \
- GET_PACA(r13) ; /* get r13 back */ \
  bctr ;

Also only semi-relatedly, I was curious (if you, or anybody reading
happen to know) why
SRR0 and SRR1 are being moved to registers so early in the interrupt handler.
I had speculated that this was because of potential page faults on memory access
that would clobber those registers, but then I noticed the `ld
r12,PACAKBASE(r13)` before `mfspr r12,SPRN_SRR1`, which seemed like it
could touch memory, so I was confused again.

Hope the questions make sense, and sorry if I missed something obvious - I have
very little experience with ppc.

Thanks,
Keno

Use of r10 in powerpc syscall entry

[Keno Fischer]

Hi Anton,

I was reading the powerpc syscall entry code and git points me at your commit
05b05f28 (powerpc: Relocatable system call no longer uses the LR) for one
part that confused me, so I hope you don't mind a quick question. In particular,
that commit removed the use of r10 to restore lr, but didn't touch the earlier
`mflr r10` to actually save the lr to r10. Is r10 still required there
for some reason
or is that just left over? Part of the reason I'm asking is because it seems
one could use r10, instead of r13 later, i.e.

  #define SYSCALL_PSERIES_2_DIRECT \
-  mflr r10 ; \
  ld r12,PACAKBASE(r13) ; \
  LOAD_HANDLER(r12, system_call_entry) ; \
  mtctr r12 ; \
  mfspr r12,SPRN_SRR1 ; \
- /* Re-use of r13... No spare regs to do this */ \
- li r13,MSR_RI ; \
- mtmsrd r13,1 ; \
+ li r10, MSR_RI ; \
+ mtmsrd r10,1 ; \
- GET_PACA(r13) ; /* get r13 back */ \
  bctr ;

Also only semi-relatedly, I was curious (if you, or anybody reading
happen to know) why
SRR0 and SRR1 are being moved to registers so early in the interrupt handler.
I had speculated that this was because of potential page faults on memory access
that would clobber those registers, but then I noticed the `ld
r12,PACAKBASE(r13)` before `mfspr r12,SPRN_SRR1`, which seemed like it
could touch memory, so I was confused again.

Hope the questions make sense, and sorry if I missed something obvious - I have
very little experience with ppc.

Thanks,
Keno

Re: [PATCH 8/9] x86/fpu: remove __fpregs_(de)activate

[Andy Lutomirski]

On Tue, Oct 4, 2016 at 5:34 PM,   wrote:
> From: Rik van Riel 
>
> Now that fpregs_activate and fpregs_deactivate do nothing except
> call the double underscored versions of themselves, we can get
> rid of the double underscore version.

Reviewed-by: Andy Lutomirski 

Re: [PATCH 8/9] x86/fpu: remove __fpregs_(de)activate

[Andy Lutomirski]

On Tue, Oct 4, 2016 at 5:34 PM,   wrote:
> From: Rik van Riel 
>
> Now that fpregs_activate and fpregs_deactivate do nothing except
> call the double underscored versions of themselves, we can get
> rid of the double underscore version.

Reviewed-by: Andy Lutomirski 

Re: [PATCH 7/9] x86/fpu: rename lazy restore functions to "register state valid"

[Andy Lutomirski]

On Tue, Oct 4, 2016 at 5:34 PM,   wrote:
> From: Rik van Riel 
>
> Name the functions after the state they track, rather than the function
> they currently enable. This should make it more obvious when we use the
> fpu_register_state_valid function for something else in the future.

I like this.

Reviewed-by: Andy Lutomirski 

Re: [PATCH 7/9] x86/fpu: rename lazy restore functions to "register state valid"

[Andy Lutomirski]

On Tue, Oct 4, 2016 at 5:34 PM,   wrote:
> From: Rik van Riel 
>
> Name the functions after the state they track, rather than the function
> they currently enable. This should make it more obvious when we use the
> fpu_register_state_valid function for something else in the future.

I like this.

Reviewed-by: Andy Lutomirski 

[PATCH V2] OMAPDSS: Kconfig: Add HDMI for OMAP4 and OMAP5 dependencies

[Adam Ford]

Make "HDMI for OMAP4" and "HDMI for OMAP5" depend on ARCH_OMAP4
and SOC_OMAP5/DRA7XX respectively.

Signed-off-by: Adam Ford 

Changes in v2: Add dependancy for DRA7XX or OMAP5

diff --git a/drivers/gpu/drm/omapdrm/dss/Kconfig 
b/drivers/gpu/drm/omapdrm/dss/Kconfig
index d1fa730..befdd7a 100644
--- a/drivers/gpu/drm/omapdrm/dss/Kconfig
+++ b/drivers/gpu/drm/omapdrm/dss/Kconfig
@@ -69,13 +69,15 @@ config OMAP2_DSS_HDMI_COMMON
 
 config OMAP4_DSS_HDMI
bool "HDMI support for OMAP4"
-default y
+   depends on ARCH_OMAP4
+   default y
select OMAP2_DSS_HDMI_COMMON
help
  HDMI support for OMAP4 based SoCs.
 
 config OMAP5_DSS_HDMI
bool "HDMI support for OMAP5"
+   depends on SOC_OMAP5 || SOC_DRA7XX
default n
select OMAP2_DSS_HDMI_COMMON
help
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/Kconfig 
b/drivers/video/fbdev/omap2/omapfb/dss/Kconfig
index 27d2202..19e2e7b 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/Kconfig
+++ b/drivers/video/fbdev/omap2/omapfb/dss/Kconfig
@@ -65,13 +65,15 @@ config FB_OMAP2_DSS_HDMI_COMMON
 
 config FB_OMAP4_DSS_HDMI
bool "HDMI support for OMAP4"
-default y
+   depends on ARCH_OMAP4
+   default y
select FB_OMAP2_DSS_HDMI_COMMON
help
  HDMI support for OMAP4 based SoCs.
 
 config FB_OMAP5_DSS_HDMI
bool "HDMI support for OMAP5"
+   depends on SOC_OMAP5 || SOC_DRA7XX
default n
select FB_OMAP2_DSS_HDMI_COMMON
help
-- 
2.7.4

Re: [PATCH 5/9] x86/fpu: remove fpu.counter

[Andy Lutomirski]

On Tue, Oct 4, 2016 at 5:34 PM,   wrote:
> From: Rik van Riel 
>
> With the lazy FPU code gone, we no longer use the counter field
> in struct fpu for anything. Get rid it.

Reviewed-by: Andy Lutomirski 

[PATCH V2] OMAPDSS: Kconfig: Add HDMI for OMAP4 and OMAP5 dependencies

[Adam Ford]

Make "HDMI for OMAP4" and "HDMI for OMAP5" depend on ARCH_OMAP4
and SOC_OMAP5/DRA7XX respectively.

Signed-off-by: Adam Ford 

Changes in v2: Add dependancy for DRA7XX or OMAP5

diff --git a/drivers/gpu/drm/omapdrm/dss/Kconfig 
b/drivers/gpu/drm/omapdrm/dss/Kconfig
index d1fa730..befdd7a 100644
--- a/drivers/gpu/drm/omapdrm/dss/Kconfig
+++ b/drivers/gpu/drm/omapdrm/dss/Kconfig
@@ -69,13 +69,15 @@ config OMAP2_DSS_HDMI_COMMON
 
 config OMAP4_DSS_HDMI
bool "HDMI support for OMAP4"
-default y
+   depends on ARCH_OMAP4
+   default y
select OMAP2_DSS_HDMI_COMMON
help
  HDMI support for OMAP4 based SoCs.
 
 config OMAP5_DSS_HDMI
bool "HDMI support for OMAP5"
+   depends on SOC_OMAP5 || SOC_DRA7XX
default n
select OMAP2_DSS_HDMI_COMMON
help
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/Kconfig 
b/drivers/video/fbdev/omap2/omapfb/dss/Kconfig
index 27d2202..19e2e7b 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/Kconfig
+++ b/drivers/video/fbdev/omap2/omapfb/dss/Kconfig
@@ -65,13 +65,15 @@ config FB_OMAP2_DSS_HDMI_COMMON
 
 config FB_OMAP4_DSS_HDMI
bool "HDMI support for OMAP4"
-default y
+   depends on ARCH_OMAP4
+   default y
select FB_OMAP2_DSS_HDMI_COMMON
help
  HDMI support for OMAP4 based SoCs.
 
 config FB_OMAP5_DSS_HDMI
bool "HDMI support for OMAP5"
+   depends on SOC_OMAP5 || SOC_DRA7XX
default n
select FB_OMAP2_DSS_HDMI_COMMON
help
-- 
2.7.4

Re: [PATCH 5/9] x86/fpu: remove fpu.counter

[Andy Lutomirski]

On Tue, Oct 4, 2016 at 5:34 PM,   wrote:
> From: Rik van Riel 
>
> With the lazy FPU code gone, we no longer use the counter field
> in struct fpu for anything. Get rid it.

Reviewed-by: Andy Lutomirski 

Re: [PATCH 2/3] zram: support page-based parallel write

[Minchan Kim]

Hi Sergey,

On Tue, Oct 04, 2016 at 01:43:14PM +0900, Sergey Senozhatsky wrote:

< snip >

> TEST
> 
> 
> new tests results; same tests, same conditions, same .config.
> 4-way test:
> - BASE zram, fio direct=1
> - BASE zram, fio fsync_on_close=1
> - NEW zram, fio direct=1
> - NEW zram, fio fsync_on_close=1
> 
> 
> 
> and what I see is that:
>  - new zram is x3 times slower when we do a lot of direct=1 IO
> and
>  - 10% faster when we use buffered IO (fsync_on_close); but not always;
>for instance, test execution time is longer (a reproducible behavior)
>when the number of jobs equals the number of CPUs - 4.
> 
> 
> 
> if flushing is a problem for new zram during direct=1 test, then I would
> assume that writing a huge number of small files (creat/write 4k/close)
> would probably have same fsync_on_close=1 performance as direct=1.
> 
> 
> ENV
> ===
> 
>x86_64 SMP (4 CPUs), "bare zram" 3g, lzo, static compression buffer.
> 
> 
> TEST COMMAND
> 
> 
>   ZRAM_SIZE=3G ZRAM_COMP_ALG=lzo LOG_SUFFIX={NEW, OLD} FIO_LOOPS=2 
> ./zram-fio-test.sh
> 
> 
> EXECUTED TESTS
> ==
> 
>   - [seq-read]
>   - [rand-read]
>   - [seq-write]
>   - [rand-write]
>   - [mixed-seq]
>   - [mixed-rand]
> 
> 
> fio-perf-o-meter.sh test-fio-zram-OLD test-fio-zram-OLD-flush 
> test-fio-zram-NEW test-fio-zram-NEW-flush
> Processing test-fio-zram-OLD
> Processing test-fio-zram-OLD-flush
> Processing test-fio-zram-NEW
> Processing test-fio-zram-NEW-flush
> 
> BASE BASE  NEW NEW
> direct=1 fsync_on_close=1  direct=1
> fsync_on_close=1
> 
> #jobs1
> 
> READ:   2345.1MB/s 2177.2MB/s  2373.2MB/s  2185.8MB/s
> READ:   1948.2MB/s 1417.7MB/s  1987.7MB/s  1447.4MB/s
> WRITE:  1292.7MB/s 1406.1MB/s  275277KB/s  1521.1MB/s
> WRITE:  1047.5MB/s 1143.8MB/s  257140KB/s  1202.4MB/s
> READ:   429530KB/s 779523KB/s  175450KB/s  782237KB/s
> WRITE:  429840KB/s 780084KB/s  175576KB/s  782800KB/s
> READ:   414074KB/s 408214KB/s  164091KB/s  383426KB/s
> WRITE:  414402KB/s 408539KB/s  164221KB/s  383730KB/s


I tested your benchmark for job 1 on my 4 CPU mahcine with this diff.

Nothing different.

1. just changed ordering of test execution - hope to reduce testing time due to
   block population before the first reading or reading just zero pages
2. used sync_on_close instead of direct io
3. Don't use perf to avoid noise
4. echo 0 > /sys/block/zram0/use_aio to test synchronous IO for old behavior

diff --git a/conf/fio-template-static-buffer b/conf/fio-template-static-buffer
index 1a9a473..22ddee8 100644
--- a/conf/fio-template-static-buffer
+++ b/conf/fio-template-static-buffer
@@ -1,7 +1,7 @@
 [global]
 bs=${BLOCK_SIZE}k
 ioengine=sync
-direct=1
+fsync_on_close=1
 nrfiles=${NRFILES}
 size=${SIZE}
 numjobs=${NUMJOBS}
@@ -14,18 +14,18 @@ new_group
 group_reporting
 threads=1
 
-[seq-read]
-rw=read
-
-[rand-read]
-rw=randread
-
 [seq-write]
 rw=write
 
 [rand-write]
 rw=randwrite
 
+[seq-read]
+rw=read
+
+[rand-read]
+rw=randread
+
 [mixed-seq]
 rw=rw
 
diff --git a/zram-fio-test.sh b/zram-fio-test.sh
index 39c11b3..ca2d065 100755
--- a/zram-fio-test.sh
+++ b/zram-fio-test.sh
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
 
 
 # Sergey Senozhatsky. sergey.senozhat...@gmail.com
@@ -37,6 +37,7 @@ function create_zram
echo $ZRAM_COMP_ALG > /sys/block/zram0/comp_algorithm
cat /sys/block/zram0/comp_algorithm
 
+   echo 0 > /sys/block/zram0/use_aio
echo $ZRAM_SIZE > /sys/block/zram0/disksize
if [ $? != 0 ]; then
return -1
@@ -137,7 +138,7 @@ function main
echo "#jobs$i fio" >> $LOG
 
BLOCK_SIZE=4 SIZE=100% NUMJOBS=$i NRFILES=$i 
FIO_LOOPS=$FIO_LOOPS \
-   $PERF stat -o $LOG-perf-stat $FIO ./$FIO_TEMPLATE >> 
$LOG
+   $FIO ./$FIO_TEMPLATE > $LOG
 
echo -n "perfstat jobs$i" >> $LOG
cat $LOG-perf-stat >> $LOG

And got following result.

1. ZRAM_SIZE=3G ZRAM_COMP_ALG=lzo LOG_SUFFIX=async FIO_LOOPS=2 MAX_ITER=1 
./zram-fio-test.sh
2. modify script to disable aio via /sys/block/zram0/use_aio
   ZRAM_SIZE=3G ZRAM_COMP_ALG=lzo LOG_SUFFIX=sync FIO_LOOPS=2 MAX_ITER=1 
./zram-fio-test.sh

  seq-write 380930 474325 124.52%
 rand-write 286183 357469 124.91%
   seq-read 266813 265731  99.59%
  rand-read 211747 210670  99.49%
   mixed-seq(R) 145750 171232 117.48%
   mixed-seq(W) 145736 171215 117.48%
  mixed-rand(R) 115355 125239 108.57%
  mixed-rand(W) 115371 125256 108.57%

LZO compression is fast and a CPU for queueing while 3 CPU for compressing
it 

Re: [PATCH 2/3] zram: support page-based parallel write

[Minchan Kim]

Hi Sergey,

On Tue, Oct 04, 2016 at 01:43:14PM +0900, Sergey Senozhatsky wrote:

< snip >

> TEST
> 
> 
> new tests results; same tests, same conditions, same .config.
> 4-way test:
> - BASE zram, fio direct=1
> - BASE zram, fio fsync_on_close=1
> - NEW zram, fio direct=1
> - NEW zram, fio fsync_on_close=1
> 
> 
> 
> and what I see is that:
>  - new zram is x3 times slower when we do a lot of direct=1 IO
> and
>  - 10% faster when we use buffered IO (fsync_on_close); but not always;
>for instance, test execution time is longer (a reproducible behavior)
>when the number of jobs equals the number of CPUs - 4.
> 
> 
> 
> if flushing is a problem for new zram during direct=1 test, then I would
> assume that writing a huge number of small files (creat/write 4k/close)
> would probably have same fsync_on_close=1 performance as direct=1.
> 
> 
> ENV
> ===
> 
>x86_64 SMP (4 CPUs), "bare zram" 3g, lzo, static compression buffer.
> 
> 
> TEST COMMAND
> 
> 
>   ZRAM_SIZE=3G ZRAM_COMP_ALG=lzo LOG_SUFFIX={NEW, OLD} FIO_LOOPS=2 
> ./zram-fio-test.sh
> 
> 
> EXECUTED TESTS
> ==
> 
>   - [seq-read]
>   - [rand-read]
>   - [seq-write]
>   - [rand-write]
>   - [mixed-seq]
>   - [mixed-rand]
> 
> 
> fio-perf-o-meter.sh test-fio-zram-OLD test-fio-zram-OLD-flush 
> test-fio-zram-NEW test-fio-zram-NEW-flush
> Processing test-fio-zram-OLD
> Processing test-fio-zram-OLD-flush
> Processing test-fio-zram-NEW
> Processing test-fio-zram-NEW-flush
> 
> BASE BASE  NEW NEW
> direct=1 fsync_on_close=1  direct=1
> fsync_on_close=1
> 
> #jobs1
> 
> READ:   2345.1MB/s 2177.2MB/s  2373.2MB/s  2185.8MB/s
> READ:   1948.2MB/s 1417.7MB/s  1987.7MB/s  1447.4MB/s
> WRITE:  1292.7MB/s 1406.1MB/s  275277KB/s  1521.1MB/s
> WRITE:  1047.5MB/s 1143.8MB/s  257140KB/s  1202.4MB/s
> READ:   429530KB/s 779523KB/s  175450KB/s  782237KB/s
> WRITE:  429840KB/s 780084KB/s  175576KB/s  782800KB/s
> READ:   414074KB/s 408214KB/s  164091KB/s  383426KB/s
> WRITE:  414402KB/s 408539KB/s  164221KB/s  383730KB/s


I tested your benchmark for job 1 on my 4 CPU mahcine with this diff.

Nothing different.

1. just changed ordering of test execution - hope to reduce testing time due to
   block population before the first reading or reading just zero pages
2. used sync_on_close instead of direct io
3. Don't use perf to avoid noise
4. echo 0 > /sys/block/zram0/use_aio to test synchronous IO for old behavior

diff --git a/conf/fio-template-static-buffer b/conf/fio-template-static-buffer
index 1a9a473..22ddee8 100644
--- a/conf/fio-template-static-buffer
+++ b/conf/fio-template-static-buffer
@@ -1,7 +1,7 @@
 [global]
 bs=${BLOCK_SIZE}k
 ioengine=sync
-direct=1
+fsync_on_close=1
 nrfiles=${NRFILES}
 size=${SIZE}
 numjobs=${NUMJOBS}
@@ -14,18 +14,18 @@ new_group
 group_reporting
 threads=1
 
-[seq-read]
-rw=read
-
-[rand-read]
-rw=randread
-
 [seq-write]
 rw=write
 
 [rand-write]
 rw=randwrite
 
+[seq-read]
+rw=read
+
+[rand-read]
+rw=randread
+
 [mixed-seq]
 rw=rw
 
diff --git a/zram-fio-test.sh b/zram-fio-test.sh
index 39c11b3..ca2d065 100755
--- a/zram-fio-test.sh
+++ b/zram-fio-test.sh
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
 
 
 # Sergey Senozhatsky. sergey.senozhat...@gmail.com
@@ -37,6 +37,7 @@ function create_zram
echo $ZRAM_COMP_ALG > /sys/block/zram0/comp_algorithm
cat /sys/block/zram0/comp_algorithm
 
+   echo 0 > /sys/block/zram0/use_aio
echo $ZRAM_SIZE > /sys/block/zram0/disksize
if [ $? != 0 ]; then
return -1
@@ -137,7 +138,7 @@ function main
echo "#jobs$i fio" >> $LOG
 
BLOCK_SIZE=4 SIZE=100% NUMJOBS=$i NRFILES=$i 
FIO_LOOPS=$FIO_LOOPS \
-   $PERF stat -o $LOG-perf-stat $FIO ./$FIO_TEMPLATE >> 
$LOG
+   $FIO ./$FIO_TEMPLATE > $LOG
 
echo -n "perfstat jobs$i" >> $LOG
cat $LOG-perf-stat >> $LOG

And got following result.

1. ZRAM_SIZE=3G ZRAM_COMP_ALG=lzo LOG_SUFFIX=async FIO_LOOPS=2 MAX_ITER=1 
./zram-fio-test.sh
2. modify script to disable aio via /sys/block/zram0/use_aio
   ZRAM_SIZE=3G ZRAM_COMP_ALG=lzo LOG_SUFFIX=sync FIO_LOOPS=2 MAX_ITER=1 
./zram-fio-test.sh

  seq-write 380930 474325 124.52%
 rand-write 286183 357469 124.91%
   seq-read 266813 265731  99.59%
  rand-read 211747 210670  99.49%
   mixed-seq(R) 145750 171232 117.48%
   mixed-seq(W) 145736 171215 117.48%
  mixed-rand(R) 115355 125239 108.57%
  mixed-rand(W) 115371 125256 108.57%

LZO compression is fast and a CPU for queueing while 3 CPU for compressing
it 

Re: [RFC] fs: add userspace critical mounts event support

[Linus Torvalds]

On Tue, Oct 4, 2016 at 6:48 PM, Josh Triplett  wrote:
>
>I definitely don't think it
> should be a system-wide "mount event"; it should be a per-device "go
> direct-load your firmware" poke from userspace.

I don't disagree with that kind of interface. We already have things
like "rescan" for PCI bus devices to force a bus rescan. Iit's a
simple device attribute. Having a similar thing to trigger firmware
reload for a driver sounds entirely sane.

  Linus

Re: [RFC] fs: add userspace critical mounts event support

[Linus Torvalds]

On Tue, Oct 4, 2016 at 6:48 PM, Josh Triplett  wrote:
>
>I definitely don't think it
> should be a system-wide "mount event"; it should be a per-device "go
> direct-load your firmware" poke from userspace.

I don't disagree with that kind of interface. We already have things
like "rescan" for PCI bus devices to force a bus rescan. Iit's a
simple device attribute. Having a similar thing to trigger firmware
reload for a driver sounds entirely sane.

  Linus

Re: [RFC] fs: add userspace critical mounts event support

[Josh Triplett]

On Tue, Oct 04, 2016 at 05:12:58PM -0700, Linus Torvalds wrote:
> On Tue, Oct 4, 2016 at 5:00 PM, Luis R. Rodriguez  wrote:
> > I am not sure how/why a firmware loading daemon would be a better
> > idea now. What Marc describes that Josh proposed with signals for
> > userspcae seems more aligned with what we likely need
> 
> Quite frankly, I doubt you want a signal.
> 
> You will want to have some way to specify where the firmware files
> are. Right now we have "fw_path[]" which is hardcoded except for the
> first entry that can be set as a module parameter. But you'd probably
> want to expand on that, which implies some /sys or /proc interface.
> 
> And once you do that, wouldn't it make more sense to just make the
> "update the firmware path /proc/sys/kernel/fw_path file" make things
> re-search for firmware?

That could work, but it seems like overkill to allow changing the path,
rather than the simpler interface of just telling the one driver "go
ahead and direct-load your firmware now".  I definitely don't think it
should be a system-wide "mount event"; it should be a per-device "go
direct-load your firmware" poke from userspace.  That would solve the
"build-in the driver so it can start waking up slow monitors, but wait
to load the firmware until you have a filesystem" problem.  (And it
would avoid creating some unusual driver-specific late-firmware-load
mechanism.)

That said, the Chrome OS folks apparently have some mechanism where they
mount a tmpfs over /lib/firmware to let userspace choose firmware at
runtime, so perhaps the path-changing mechanism would help there.  Kees?

Re: [RFC] fs: add userspace critical mounts event support

[Josh Triplett]

On Tue, Oct 04, 2016 at 05:12:58PM -0700, Linus Torvalds wrote:
> On Tue, Oct 4, 2016 at 5:00 PM, Luis R. Rodriguez  wrote:
> > I am not sure how/why a firmware loading daemon would be a better
> > idea now. What Marc describes that Josh proposed with signals for
> > userspcae seems more aligned with what we likely need
> 
> Quite frankly, I doubt you want a signal.
> 
> You will want to have some way to specify where the firmware files
> are. Right now we have "fw_path[]" which is hardcoded except for the
> first entry that can be set as a module parameter. But you'd probably
> want to expand on that, which implies some /sys or /proc interface.
> 
> And once you do that, wouldn't it make more sense to just make the
> "update the firmware path /proc/sys/kernel/fw_path file" make things
> re-search for firmware?

That could work, but it seems like overkill to allow changing the path,
rather than the simpler interface of just telling the one driver "go
ahead and direct-load your firmware now".  I definitely don't think it
should be a system-wide "mount event"; it should be a per-device "go
direct-load your firmware" poke from userspace.  That would solve the
"build-in the driver so it can start waking up slow monitors, but wait
to load the firmware until you have a filesystem" problem.  (And it
would avoid creating some unusual driver-specific late-firmware-load
mechanism.)

That said, the Chrome OS folks apparently have some mechanism where they
mount a tmpfs over /lib/firmware to let userspace choose firmware at
runtime, so perhaps the path-changing mechanism would help there.  Kees?

Re: [RFC][PATCH 6/7] printk: use alternative printk buffers

[Sergey Senozhatsky]

On (10/04/16 14:22), Petr Mladek wrote:
[..]
>   if (retry && console_trylock())
>   goto again;
> 
> with a safe variant, something like
> 
>   if (retry) {
>   local_irq_save(flags);
>   alt_printk_enter();
>   lock_failed = console_trylock();
>   alt_printk_exit();
>   local_irq_restore(flags);
> 
>   if (!lock_failed)
>   goto again;
>   }
> 
> Or do I miss anything?

nope, you don't. that's close to what I do in v3.

> I am going to look at the second version of the patchset.

thanks a lot for your review!

I'll refresh the patch set a bit later this week. I think it's more
or less in shape now well, still under the old name: alt_printk.

-ss

Re: [RFC][PATCH 6/7] printk: use alternative printk buffers

[Sergey Senozhatsky]

On (10/04/16 14:22), Petr Mladek wrote:
[..]
>   if (retry && console_trylock())
>   goto again;
> 
> with a safe variant, something like
> 
>   if (retry) {
>   local_irq_save(flags);
>   alt_printk_enter();
>   lock_failed = console_trylock();
>   alt_printk_exit();
>   local_irq_restore(flags);
> 
>   if (!lock_failed)
>   goto again;
>   }
> 
> Or do I miss anything?

nope, you don't. that's close to what I do in v3.

> I am going to look at the second version of the patchset.

thanks a lot for your review!

I'll refresh the patch set a bit later this week. I think it's more
or less in shape now well, still under the old name: alt_printk.

-ss

Re: [PATCH 7/8] PM / OPP: Allow platform specific custom opp_set_rate() callbacks

[Viresh Kumar]

On 04-10-16, 17:26, Viresh Kumar wrote:
> diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
> +int dev_pm_opp_register_set_rate_helper(struct device *dev,
> + int (*set_rate)(struct device *dev, struct dev_pm_set_rate_data *data))
> +{
> + return -ENOTSUPP;
> +}

+ this to fix up a warning:

diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index ef882ed24b0e..483f33e70895 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -180,7 +180,7 @@ static inline int dev_pm_opp_set_supported_hw(struct device 
*dev,
 
 static inline void dev_pm_opp_put_supported_hw(struct device *dev) {}
 
-int dev_pm_opp_register_set_rate_helper(struct device *dev,
+static inline int dev_pm_opp_register_set_rate_helper(struct device *dev,
int (*set_rate)(struct device *dev, struct dev_pm_set_rate_data *data))
 {
return -ENOTSUPP;

-- 
viresh

Re: [PATCH 7/8] PM / OPP: Allow platform specific custom opp_set_rate() callbacks

[Viresh Kumar]

On 04-10-16, 17:26, Viresh Kumar wrote:
> diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
> +int dev_pm_opp_register_set_rate_helper(struct device *dev,
> + int (*set_rate)(struct device *dev, struct dev_pm_set_rate_data *data))
> +{
> + return -ENOTSUPP;
> +}

+ this to fix up a warning:

diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index ef882ed24b0e..483f33e70895 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -180,7 +180,7 @@ static inline int dev_pm_opp_set_supported_hw(struct device 
*dev,
 
 static inline void dev_pm_opp_put_supported_hw(struct device *dev) {}
 
-int dev_pm_opp_register_set_rate_helper(struct device *dev,
+static inline int dev_pm_opp_register_set_rate_helper(struct device *dev,
int (*set_rate)(struct device *dev, struct dev_pm_set_rate_data *data))
 {
return -ENOTSUPP;

-- 
viresh

Re: [RFC][PATCH 6/7] printk: use alternative printk buffers

[Sergey Senozhatsky]

On (10/04/16 16:52), Petr Mladek wrote:
> > 
> > Or is there any other catch that I do not see at the moment?
> 
> And there is :-( The above logic looked at the problem only from
> one side. It was about errors starting from the printk()
> code itself, for example:

yes, like I said - printk recursion and printk deadlock are different
things. and recursion cases are a subset of deadlock cases.

> The only thing that might help here is to call
> alt_printk_enter()/exit() in wake_up_process() itself. Otherwise,
> we still would need to keep the printk_deferred() stuff.

yes.
or
- combine alt_printk and DEFERRED_WARN/etc.
or
- rewrite printk() to be lock-less by default (for all invocations).

> By other words, we might need to put alt_printk_enter()/exit()
> into the scheduler and timekeeping code. In theory it might
> be easier to maintain than the separated printk_deferred() calls.
> But there might be some catches because we need to disable
> the interrupts, ...

right. and I have some doubts that people will be willing to put
alt_printk_enter/exit into those hot paths.


> Sigh, this 2nd scenario is much more likely than the 1st one.
> I guess that warnings in the scheduler/timekeeping code
> will be triggered outside printk() most of the time.

hm. may be. but the reports we received so far starts from printk()
and end up in printk() - IOW, recursion.

> It means that this approach might be much harder to sell
> after all :-(

well, it solves a number of problems that the existing implementation
cannot handle.

would have been nice to cover all of the cases, but that's a bit hard.

-ss

Re: [RFC][PATCH 6/7] printk: use alternative printk buffers

[Sergey Senozhatsky]

On (10/04/16 16:52), Petr Mladek wrote:
> > 
> > Or is there any other catch that I do not see at the moment?
> 
> And there is :-( The above logic looked at the problem only from
> one side. It was about errors starting from the printk()
> code itself, for example:

yes, like I said - printk recursion and printk deadlock are different
things. and recursion cases are a subset of deadlock cases.

> The only thing that might help here is to call
> alt_printk_enter()/exit() in wake_up_process() itself. Otherwise,
> we still would need to keep the printk_deferred() stuff.

yes.
or
- combine alt_printk and DEFERRED_WARN/etc.
or
- rewrite printk() to be lock-less by default (for all invocations).

> By other words, we might need to put alt_printk_enter()/exit()
> into the scheduler and timekeeping code. In theory it might
> be easier to maintain than the separated printk_deferred() calls.
> But there might be some catches because we need to disable
> the interrupts, ...

right. and I have some doubts that people will be willing to put
alt_printk_enter/exit into those hot paths.


> Sigh, this 2nd scenario is much more likely than the 1st one.
> I guess that warnings in the scheduler/timekeeping code
> will be triggered outside printk() most of the time.

hm. may be. but the reports we received so far starts from printk()
and end up in printk() - IOW, recursion.

> It means that this approach might be much harder to sell
> after all :-(

well, it solves a number of problems that the existing implementation
cannot handle.

would have been nice to cover all of the cases, but that's a bit hard.

-ss

Re: BUG_ON() in workingset_node_shadows_dec() triggers

[Linus Torvalds]

On Tue, Oct 4, 2016 at 2:32 AM, Johannes Weiner  wrote:
>
> In the workingset code, if we detect radix tree nodes in a state in
> which they shouldn't be on the shadow node LRU, we could simply warn,
> abort the reclaim process and leave them off the LRU. Something like
> the below patch.

I don't hate that patch, but I wonder why the counts get corrupted and
the workingset_node_shadows_dec() thing triggered in the first place.

So I do think that the BUG_ON()'s there in shadow_lru_isolate() should
be removed, but since they haven't triggered I worry more abut the one
that has.

I've tried to follow the counting, and I don't see any obvious bugs in
the counting per se.  I went as far as look where we even initialize
node->count.

Btw, whoever wrote that code liked the whole SLAB desctructor model a
lot too much. Initializing the fields as you free something is rather
silly from a cache use standpoint. You're just touching cachelines
that are almost guaranteed to be wasted. Why isn't that init code just
done at allocation time instead of in that radix_tree_node_rcu_free()
destructor?

But I couldn't see anything actively *buggy*, even if I think the code
is oddly structured.

So to debug that, I'd actually like to see something that adds a few
more warnings to try to catch *where* the count goes bad

For example, is it actually valid to free a radix_tree_node that has a
non-zero count? Shouldn't all the shadow entries have been removed?
The problem with the BUG_ON() at workingset_node_shadows_dec() time
isn't just that it killed the machine, it also doesn't actually give
very much information. The count has presumably been mis-done long
before..

  Linus

Re: BUG_ON() in workingset_node_shadows_dec() triggers

[Linus Torvalds]

On Tue, Oct 4, 2016 at 2:32 AM, Johannes Weiner  wrote:
>
> In the workingset code, if we detect radix tree nodes in a state in
> which they shouldn't be on the shadow node LRU, we could simply warn,
> abort the reclaim process and leave them off the LRU. Something like
> the below patch.

I don't hate that patch, but I wonder why the counts get corrupted and
the workingset_node_shadows_dec() thing triggered in the first place.

So I do think that the BUG_ON()'s there in shadow_lru_isolate() should
be removed, but since they haven't triggered I worry more abut the one
that has.

I've tried to follow the counting, and I don't see any obvious bugs in
the counting per se.  I went as far as look where we even initialize
node->count.

Btw, whoever wrote that code liked the whole SLAB desctructor model a
lot too much. Initializing the fields as you free something is rather
silly from a cache use standpoint. You're just touching cachelines
that are almost guaranteed to be wasted. Why isn't that init code just
done at allocation time instead of in that radix_tree_node_rcu_free()
destructor?

But I couldn't see anything actively *buggy*, even if I think the code
is oddly structured.

So to debug that, I'd actually like to see something that adds a few
more warnings to try to catch *where* the count goes bad

For example, is it actually valid to free a radix_tree_node that has a
non-zero count? Shouldn't all the shadow entries have been removed?
The problem with the BUG_ON() at workingset_node_shadows_dec() time
isn't just that it killed the machine, it also doesn't actually give
very much information. The count has presumably been mis-done long
before..

  Linus