[PATCH] fix bash-isms in arch/x86/entry/syscalls/syscalltbl.sh

Fix the bash-isms in the x86 syscall table generator shell script. Signed-off-by: Sylvain BERTRAND --- diff --git a/arch/x86/entry/syscalls/syscalltbl.sh b/arch/x86/entry/syscalls/syscalltbl.sh index cd3d301..751d1f9 100644 --- a/arch/x86/entry/syscalls/syscalltbl.sh +++

[PATCH net-next 10/10] net: dsa: mv88e6xxx: add eeprom ops

Remove EEPROM flags in favor of new {get,set}_eeprom chip-wide functions in the mv88e6xxx_ops structure. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/chip.c | 34 +- drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 16 +--- 2 files changed,

[PATCH net-next 00/10] net: dsa: mv88e6xxx: Global (1) cosmetics

The Global (1) internal SMI device of Marvell switches is a set of registers providing support to different units for MAC addresses (ATU), VLANs (VTU), PHY polling (PPU), etc. Chips (like 88E6060) may use a different address for it, or have subtleties in the units (e.g. different number of

[PATCH net-next 00/10] net: dsa: mv88e6xxx: Global (1) cosmetics

The Global (1) internal SMI device of Marvell switches is a set of registers providing support to different units for MAC addresses (ATU), VLANs (VTU), PHY polling (PPU), etc. Chips (like 88E6060) may use a different address for it, or have subtleties in the units (e.g. different number of

[PATCH net-next 03/10] net: dsa: mv88e6xxx: add flags for FID registers

Add flags to describe the presence of Global 1 ATU FID register (0x01) and VTU FID register (0x02), instead of checking families. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/chip.c | 16 +++-

[PATCH net-next 03/10] net: dsa: mv88e6xxx: add flags for FID registers

Add flags to describe the presence of Global 1 ATU FID register (0x01) and VTU FID register (0x02), instead of checking families. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/chip.c | 16 +++- drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 24 2

Re: Regression in mobility grouping?

On Thu, Sep 29, 2016 at 03:14:33PM +0900, Joonsoo Kim wrote: > On Wed, Sep 28, 2016 at 10:25:40PM -0400, Johannes Weiner wrote: > > On Wed, Sep 28, 2016 at 11:39:25AM -0400, Johannes Weiner wrote: > > > On Wed, Sep 28, 2016 at 11:00:15AM +0200, Vlastimil Babka wrote: > > > > I guess testing revert

Re: Regression in mobility grouping?

On Thu, Sep 29, 2016 at 03:14:33PM +0900, Joonsoo Kim wrote: > On Wed, Sep 28, 2016 at 10:25:40PM -0400, Johannes Weiner wrote: > > On Wed, Sep 28, 2016 at 11:39:25AM -0400, Johannes Weiner wrote: > > > On Wed, Sep 28, 2016 at 11:00:15AM +0200, Vlastimil Babka wrote: > > > > I guess testing revert

Re: [PATCH v3 2/2] leds: Add driver for NCP5623 3-channel I2C LED driver

Hi Jacek, Thank you for your comments! Le 18. 09. 16 à 20:20, Jacek Anaszewski a écrit : > Hi Florian, > > Thanks for the updated patch set. I have few comments below. > > On 09/16/2016 01:34 PM, Florian Vaussard wrote: >> The NCP5623 is a 3-channel LED driver from On Semiconductor controlled

Re: [PATCH v3 2/2] leds: Add driver for NCP5623 3-channel I2C LED driver

Hi Jacek, Thank you for your comments! Le 18. 09. 16 à 20:20, Jacek Anaszewski a écrit : > Hi Florian, > > Thanks for the updated patch set. I have few comments below. > > On 09/16/2016 01:34 PM, Florian Vaussard wrote: >> The NCP5623 is a 3-channel LED driver from On Semiconductor controlled

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On 28/09/16 14:13, Vincent Guittot wrote: > Le Wednesday 28 Sep 2016 à 05:27:54 (-0700), Vincent Guittot a écrit : >> On 28 September 2016 at 04:31, Dietmar Eggemann >> wrote: >>> On 28/09/16 12:19, Peter Zijlstra wrote: On Wed, Sep 28, 2016 at 12:06:43PM +0100,

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On 28/09/16 14:13, Vincent Guittot wrote: > Le Wednesday 28 Sep 2016 à 05:27:54 (-0700), Vincent Guittot a écrit : >> On 28 September 2016 at 04:31, Dietmar Eggemann >> wrote: >>> On 28/09/16 12:19, Peter Zijlstra wrote: On Wed, Sep 28, 2016 at 12:06:43PM +0100, Dietmar Eggemann wrote: >

Re: [PATCH v2 1/3] fs/exec: don't force writing memory access

On 09/29, Jann Horn wrote: > > @@ -204,7 +204,7 @@ static struct page *get_arg_page(struct linux_binprm > *bprm, unsigned long pos, >* doing the exec and bprm->mm is the new process's mm. >*/ > ret = get_user_pages_remote(current, bprm->mm, pos, 1, write, > -

Re: [PATCH v2 1/3] fs/exec: don't force writing memory access

On 09/29, Jann Horn wrote: > > @@ -204,7 +204,7 @@ static struct page *get_arg_page(struct linux_binprm > *bprm, unsigned long pos, >* doing the exec and bprm->mm is the new process's mm. >*/ > ret = get_user_pages_remote(current, bprm->mm, pos, 1, write, > -

Re: [PATCH] clocksource: arm_arch_timer: Don't assume clock runs in suspend

On Tue, 27 Sep 2016 18:23:11 -0700 Brian Norris wrote: Hi Brian, > Hi Marc, > > Thanks again for the help. I was checking with Rockchip on the details. > > On Tue, Sep 20, 2016 at 08:47:07AM +0100, Marc Zyngier wrote: > > The counter is allowed to be clocked at a

Re: [PATCH] clocksource: arm_arch_timer: Don't assume clock runs in suspend

On Tue, 27 Sep 2016 18:23:11 -0700 Brian Norris wrote: Hi Brian, > Hi Marc, > > Thanks again for the help. I was checking with Rockchip on the details. > > On Tue, Sep 20, 2016 at 08:47:07AM +0100, Marc Zyngier wrote: > > The counter is allowed to be clocked at a different rate, as long as it

Re: [PATCH v5] powerpc: Do not make the entire heap executable

On 09/28, Kees Cook wrote: > > This is where the flags are actually built from what's coming in > through the newly created exported function vm_brk_flags() below. The > only flag we're acting on is VM_EXEC (passed in from set_brk() above). > I think do_brk_flags() should mask the valid flags, or

Re: [PATCH v5] powerpc: Do not make the entire heap executable

On 09/28, Kees Cook wrote: > > This is where the flags are actually built from what's coming in > through the newly created exported function vm_brk_flags() below. The > only flag we're acting on is VM_EXEC (passed in from set_brk() above). > I think do_brk_flags() should mask the valid flags, or

[RFC PATCH 1/1] mm/percpu.c: fix potential memory leakage for pcpu_embed_first_chunk()

From: zijun_hu it will cause memory leakage for pcpu_embed_first_chunk() to go to label @out_free if the chunk spans over 3/4 VMALLOC area. all memory are allocated and recorded into array @areas for each CPU group, but the memory allocated aren't be freed before returning

[RFC PATCH 1/1] mm/percpu.c: fix potential memory leakage for pcpu_embed_first_chunk()

From: zijun_hu it will cause memory leakage for pcpu_embed_first_chunk() to go to label @out_free if the chunk spans over 3/4 VMALLOC area. all memory are allocated and recorded into array @areas for each CPU group, but the memory allocated aren't be freed before returning after going to label

Re: [PATCH locking/Documentation 1/2] Add note of release-acquire store vulnerability

On Thu, Sep 29, 2016 at 05:58:17PM +0200, Peter Zijlstra wrote: > On Thu, Sep 29, 2016 at 08:54:01AM -0700, Paul E. McKenney wrote: > > If two processes are related by a RELEASE+ACQUIRE pair, ordering can be > > broken if a third process overwrites the value written by the RELEASE > > operation

Re: [PATCH locking/Documentation 1/2] Add note of release-acquire store vulnerability

On Thu, Sep 29, 2016 at 05:58:17PM +0200, Peter Zijlstra wrote: > On Thu, Sep 29, 2016 at 08:54:01AM -0700, Paul E. McKenney wrote: > > If two processes are related by a RELEASE+ACQUIRE pair, ordering can be > > broken if a third process overwrites the value written by the RELEASE > > operation

Re: Regression in 4.8 - CPU speed set very low

On Thu, 2016-09-29 at 14:19 +0200, Rafael J. Wysocki wrote: [...] > > My laptop was inadvertently put to sleep while I was gone. I forgot > > to leave a  > > note for my wife and she quieted the noisy cpu fan. :) > It looks like in 4.8-rc we made a change that caused the "high" trip > point to >

Re: Regression in 4.8 - CPU speed set very low

On Thu, 2016-09-29 at 14:19 +0200, Rafael J. Wysocki wrote: [...] > > My laptop was inadvertently put to sleep while I was gone. I forgot > > to leave a  > > note for my wife and she quieted the noisy cpu fan. :) > It looks like in 4.8-rc we made a change that caused the "high" trip > point to >

Re: [PATCH locking/Documentation 1/2] Add note of release-acquire store vulnerability

On Thu, Sep 29, 2016 at 08:54:01AM -0700, Paul E. McKenney wrote: > If two processes are related by a RELEASE+ACQUIRE pair, ordering can be > broken if a third process overwrites the value written by the RELEASE > operation before the ACQUIRE operation has a chance of reading it. > This commit

Re: [PATCH locking/Documentation 1/2] Add note of release-acquire store vulnerability

On Thu, Sep 29, 2016 at 08:54:01AM -0700, Paul E. McKenney wrote: > If two processes are related by a RELEASE+ACQUIRE pair, ordering can be > broken if a third process overwrites the value written by the RELEASE > operation before the ACQUIRE operation has a chance of reading it. > This commit

[PATCH locking/Documentation 2/2] No speculated stores

This commit reworks an erroneous example that claims that dependency barriers are needed to prevent speculation of dependent stores. Signed-off-by: Paul E. McKenney --- Documentation/memory-barriers.txt | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-)

[PATCH locking/Documentation 2/2] No speculated stores

This commit reworks an erroneous example that claims that dependency barriers are needed to prevent speculation of dependent stores. Signed-off-by: Paul E. McKenney --- Documentation/memory-barriers.txt | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git

RE: linux-next: build failure after merge of the tip tree

Hi, > -Original Message- > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Thursday, September 29, 2016 8:25 PM > To: Stephen Rothwell > Cc: Thomas Gleixner; Ingo Molnar; H. Peter Anvin; Peter Zijlstra; linux- > n...@vger.kernel.org; linux-kernel@vger.kernel.org; Denys

RE: linux-next: build failure after merge of the tip tree

Hi, > -Original Message- > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Thursday, September 29, 2016 8:25 PM > To: Stephen Rothwell > Cc: Thomas Gleixner; Ingo Molnar; H. Peter Anvin; Peter Zijlstra; linux- > n...@vger.kernel.org; linux-kernel@vger.kernel.org; Denys

mm/percpu.c: fix potential memory leakage for pcpu_embed_first_chunk()

From: zijun_hu it will cause memory leakage for pcpu_embed_first_chunk() to go to label @out_free if the chunk spans over 3/4 VMALLOC area. all memory are allocated and recorded into array @areas for each CPU group, but the memory allocated aren't be freed before returning

mm/percpu.c: fix potential memory leakage for pcpu_embed_first_chunk()

From: zijun_hu it will cause memory leakage for pcpu_embed_first_chunk() to go to label @out_free if the chunk spans over 3/4 VMALLOC area. all memory are allocated and recorded into array @areas for each CPU group, but the memory allocated aren't be freed before returning after going to label

[PATCH locking/Documentation 1/2] Add note of release-acquire store vulnerability

If two processes are related by a RELEASE+ACQUIRE pair, ordering can be broken if a third process overwrites the value written by the RELEASE operation before the ACQUIRE operation has a chance of reading it. This commit therefore updates the documentation to call this vulnerability out

[PATCH locking/Documentation 1/2] Add note of release-acquire store vulnerability

If two processes are related by a RELEASE+ACQUIRE pair, ordering can be broken if a third process overwrites the value written by the RELEASE operation before the ACQUIRE operation has a chance of reading it. This commit therefore updates the documentation to call this vulnerability out

[PATCH v2 0/1] s390 preparation for vcpu preempted check

This patch should enable s390 support for the upcoming vcpu preempt check support, but it should compile and work fine without that patch set as well. Christian Borntraeger (1): s390/spinlock: Provide vcpu_is_preempted arch/s390/include/asm/spinlock.h | 3 +++ arch/s390/kernel/smp.c

[PATCH v2 0/1] s390 preparation for vcpu preempted check

This patch should enable s390 support for the upcoming vcpu preempt check support, but it should compile and work fine without that patch set as well. Christian Borntraeger (1): s390/spinlock: Provide vcpu_is_preempted arch/s390/include/asm/spinlock.h | 3 +++ arch/s390/kernel/smp.c

[PATCH v2 1/1] s390/spinlock: Provide vcpu_is_preempted

this implements the s390 backend for commit "kernel/sched: introduce vcpu preempted check interface" by reworking the existing smp_vcpu_scheduled into arch_vcpu_is_preempted. We can then also get rid of the local cpu_is_preempted function by moving the CIF_ENABLED_WAIT test into

[PATCH v2 1/1] s390/spinlock: Provide vcpu_is_preempted

this implements the s390 backend for commit "kernel/sched: introduce vcpu preempted check interface" by reworking the existing smp_vcpu_scheduled into arch_vcpu_is_preempted. We can then also get rid of the local cpu_is_preempted function by moving the CIF_ENABLED_WAIT test into

Re: [PATCH v2 3/3] net: make net namespace sysctls belong to container's owner

Hi David, On Wed, Aug 10, 2016 at 2:36 PM, Dmitry Torokhov wrote: > If net namespace is attached to a user namespace let's make container's > root owner of sysctls affecting said network namespace instead of global > root. > > This also allows us to clean up

Re: [PATCH v2 3/3] net: make net namespace sysctls belong to container's owner

Hi David, On Wed, Aug 10, 2016 at 2:36 PM, Dmitry Torokhov wrote: > If net namespace is attached to a user namespace let's make container's > root owner of sysctls affecting said network namespace instead of global > root. > > This also allows us to clean up net_ctl_permissions() because we do

Re: [PATCH] dmaengine: pxa_dma: remove unused function

Baoyou Xie writes: > We get 1 warning when building kernel with W=1: > drivers/dma/pxa_dma.c:1525:5: warning: no previous prototype for > 'pxad_toggle_reserved_channel' [-Wmissing-prototypes] > > In fact, this function is called by no one, so this patch removes it. > >

Re: [PATCH] dmaengine: pxa_dma: remove unused function

Baoyou Xie writes: > We get 1 warning when building kernel with W=1: > drivers/dma/pxa_dma.c:1525:5: warning: no previous prototype for > 'pxad_toggle_reserved_channel' [-Wmissing-prototypes] > > In fact, this function is called by no one, so this patch removes it. > > Signed-off-by: Baoyou Xie

Re: [dm-devel] [PATCH 03/10] md/dm-crypt: Rename a jump label in crypt_message()

> In what bizzaro world is the "current Linux coding style convention" Do you look at the evolution for a document like "CodingStyle"? >> - >> -error: >> +show_warning: >> DMWARN("unrecognised message received."); >> return -EINVAL; >> } > > "show_warning" is better than "error" I

Re: [dm-devel] [PATCH 03/10] md/dm-crypt: Rename a jump label in crypt_message()

> In what bizzaro world is the "current Linux coding style convention" Do you look at the evolution for a document like "CodingStyle"? >> - >> -error: >> +show_warning: >> DMWARN("unrecognised message received."); >> return -EINVAL; >> } > > "show_warning" is better than "error" I

Re: [PATCH net v2] L2TP:Adjust intf MTU,factor underlay L3,overlay L2

On 29/09/16 03:36, R. Parameswaran wrote: > I agree that something like 2. below would be needed in the long run (it > will need some effort and redesign -e.g. how do I lookup the parent tunnel > from the socket when receiving a PMTU update, existing pointer chain runs > from tunnel to socket).

Re: [PATCH net v2] L2TP:Adjust intf MTU,factor underlay L3,overlay L2

On 29/09/16 03:36, R. Parameswaran wrote: > I agree that something like 2. below would be needed in the long run (it > will need some effort and redesign -e.g. how do I lookup the parent tunnel > from the socket when receiving a PMTU update, existing pointer chain runs > from tunnel to socket).

Re: [PATCH 2/6] ipr: use pci_irq_allocate_vectors

On Thu, Sep 29, 2016 at 09:01:44AM -0500, Brian King wrote: > Thanks Christoph. Very nice. As I was reviewing the patch, I noticed > the additional PCI_IRQ_AFFINITY flag, which is currently not being set > in this patch. Is the intention to set that globally by default, or > should I follow up

Re: [PATCH 2/6] ipr: use pci_irq_allocate_vectors

On Thu, Sep 29, 2016 at 09:01:44AM -0500, Brian King wrote: > Thanks Christoph. Very nice. As I was reviewing the patch, I noticed > the additional PCI_IRQ_AFFINITY flag, which is currently not being set > in this patch. Is the intention to set that globally by default, or > should I follow up

Re: [PATCH net v2] L2TP:Adjust intf MTU,factor underlay L3,overlay L2

On 22/09/16 21:52, R. Parameswaran wrote: > From ed585bdd6d3d2b3dec58d414f514cd764d89159d Mon Sep 17 00:00:00 2001 > From: "R. Parameswaran" > Date: Thu, 22 Sep 2016 13:19:25 -0700 > Subject: [PATCH] L2TP:Adjust intf MTU,factor underlay L3,overlay L2 > > Take into account

Re: [PATCH net v2] L2TP:Adjust intf MTU,factor underlay L3,overlay L2

On 22/09/16 21:52, R. Parameswaran wrote: > From ed585bdd6d3d2b3dec58d414f514cd764d89159d Mon Sep 17 00:00:00 2001 > From: "R. Parameswaran" > Date: Thu, 22 Sep 2016 13:19:25 -0700 > Subject: [PATCH] L2TP:Adjust intf MTU,factor underlay L3,overlay L2 > > Take into account all of the tunnel

Re: [PATCH 4.7 00/69] 4.7.6-stable review

On Thu, Sep 29, 2016 at 07:46:05AM -0700, Kevin Hilman wrote: > Greg Kroah-Hartman writes: > > > On Thu, Sep 29, 2016 at 01:22:06AM -0700, Kevin Hilman wrote: > >> kernelci.org bot writes: > >> > >> > stable-rc boot: 105 boots: 1 failed, 100

Re: [PATCH 4.7 00/69] 4.7.6-stable review

On Thu, Sep 29, 2016 at 07:46:05AM -0700, Kevin Hilman wrote: > Greg Kroah-Hartman writes: > > > On Thu, Sep 29, 2016 at 01:22:06AM -0700, Kevin Hilman wrote: > >> kernelci.org bot writes: > >> > >> > stable-rc boot: 105 boots: 1 failed, 100 passed with 4 offline > >> >

[PATCH] driver-core: add test module for asynchronous probing

From: Dmitry Torokhov This test module tries to test asynchronous driver probing by having a driver that sleeps for an extended period of time (5 secs) in its probe() method. It measures the time needed to register this driver (with device already registered) and a new device

[PATCH] driver-core: add test module for asynchronous probing

From: Dmitry Torokhov This test module tries to test asynchronous driver probing by having a driver that sleeps for an extended period of time (5 secs) in its probe() method. It measures the time needed to register this driver (with device already registered) and a new device (with driver

Re: Regression in 4.8 - CPU speed set very low

On 09/29/2016 07:19 AM, Rafael J. Wysocki wrote: On Wednesday, September 28, 2016 09:22:59 PM Larry Finger wrote: On 09/27/2016 06:46 AM, Rafael J. Wysocki wrote: On Tue, Sep 27, 2016 at 10:48 AM, Larry Finger wrote: On 09/26/2016 10:12 PM, Doug Smythies wrote:

Re: Regression in 4.8 - CPU speed set very low

On 09/29/2016 07:19 AM, Rafael J. Wysocki wrote: On Wednesday, September 28, 2016 09:22:59 PM Larry Finger wrote: On 09/27/2016 06:46 AM, Rafael J. Wysocki wrote: On Tue, Sep 27, 2016 at 10:48 AM, Larry Finger wrote: On 09/26/2016 10:12 PM, Doug Smythies wrote: On 2016.09.26 18:31 Srinivas

Re: [PATCH v2 2/8] pipe: move limit checking logic into pipe_set_size()

On Thu, 2016-09-29 at 13:26 +0200, Vegard Nossum wrote: > On 08/29/2016 02:21 AM, Michael Kerrisk (man-pages) wrote: > > This is a preparatory patch for following work. Move the F_SETPIPE_SZ > > limit-checking logic from pipe_fcntl() into pipe_set_size(). This > > simplifies the code a little,

Re: [PATCH v2 2/8] pipe: move limit checking logic into pipe_set_size()

On Thu, 2016-09-29 at 13:26 +0200, Vegard Nossum wrote: > On 08/29/2016 02:21 AM, Michael Kerrisk (man-pages) wrote: > > This is a preparatory patch for following work. Move the F_SETPIPE_SZ > > limit-checking logic from pipe_fcntl() into pipe_set_size(). This > > simplifies the code a little,

Re: [PATCH 01/10] dm snapshot: Use kmalloc_array() in init_origin_hash()

On Thu, 2016-09-29 at 13:45 +0200, Paul Bolle wrote: > On Thu, 2016-09-29 at 13:12 +0200, Paul Bolle wrote: > > Or did I misread that test? > I finally did some digging: commit e367455a9f25 ("checkpatch: emit > fewer kmalloc_array/kcalloc conversion warnings") shows I didn't. You still misread it

Re: [PATCH 01/10] dm snapshot: Use kmalloc_array() in init_origin_hash()

On Thu, 2016-09-29 at 13:45 +0200, Paul Bolle wrote: > On Thu, 2016-09-29 at 13:12 +0200, Paul Bolle wrote: > > Or did I misread that test? > I finally did some digging: commit e367455a9f25 ("checkpatch: emit > fewer kmalloc_array/kcalloc conversion warnings") shows I didn't. You still misread it

Re: [PATCH -v2 3/9] sched/deadline/rtmutex: Dont miss the dl_runtime/dl_period update

On Mon, 26 Sep 2016, Peter Zijlstra wrote: > Currently dl tasks will actually return at the very beginning > of rt_mutex_adjust_prio_chain() in !detect_deadlock cases: > > if (waiter->prio == task->prio) { > if (!detect_deadlock) > goto out_unlock_pi; // out here >

Re: [PATCH -v2 3/9] sched/deadline/rtmutex: Dont miss the dl_runtime/dl_period update

On Mon, 26 Sep 2016, Peter Zijlstra wrote: > Currently dl tasks will actually return at the very beginning > of rt_mutex_adjust_prio_chain() in !detect_deadlock cases: > > if (waiter->prio == task->prio) { > if (!detect_deadlock) > goto out_unlock_pi; // out here >

Re: [PATCHv4 00/57] perf c2c: Add new tool to analyze cacheline contention on NUMA systems

Em Thu, Sep 29, 2016 at 11:19:12AM +0200, Peter Zijlstra escreveu: > On Thu, Sep 22, 2016 at 05:36:28PM +0200, Jiri Olsa wrote: > > sending new version of c2c patches (v3) originally posted in here: > > http://lwn.net/Articles/588866/ > I'll just keep repeating; this is not the tool I want :-(

Re: [PATCHv4 00/57] perf c2c: Add new tool to analyze cacheline contention on NUMA systems

Em Thu, Sep 29, 2016 at 11:19:12AM +0200, Peter Zijlstra escreveu: > On Thu, Sep 22, 2016 at 05:36:28PM +0200, Jiri Olsa wrote: > > sending new version of c2c patches (v3) originally posted in here: > > http://lwn.net/Articles/588866/ > I'll just keep repeating; this is not the tool I want :-(

Re: [PATCH -v2 5/9] rtmutex: Clean up

On Mon, 26 Sep 2016, Steven Rostedt wrote: > Peter Zijlstra wrote: > > Can this be rephrased to: "Returns true if preemption has been > disabled and a call to rt_mutex_postunlock() is required (which will > re-enable preemption)" I agree with Steven that the comments

Re: [PATCH -v2 5/9] rtmutex: Clean up

On Mon, 26 Sep 2016, Steven Rostedt wrote: > Peter Zijlstra wrote: > > Can this be rephrased to: "Returns true if preemption has been > disabled and a call to rt_mutex_postunlock() is required (which will > re-enable preemption)" I agree with Steven that the comments should be rephrased.

Re: [PATCH -v2 1/9] rtmutex: Deboost before waking up the top waiter

On Mon, 26 Sep 2016, Peter Zijlstra wrote: > On Mon, Sep 26, 2016 at 11:37:27AM -0400, Steven Rostedt wrote: > > On Mon, 26 Sep 2016 11:35:03 -0400 > > Steven Rostedt wrote: > > > > > Especially now that the code after the spin_unlock(>lock) is now a > > > critical section

Re: [PATCH -v2 1/9] rtmutex: Deboost before waking up the top waiter

On Mon, 26 Sep 2016, Peter Zijlstra wrote: > On Mon, Sep 26, 2016 at 11:37:27AM -0400, Steven Rostedt wrote: > > On Mon, 26 Sep 2016 11:35:03 -0400 > > Steven Rostedt wrote: > > > > > Especially now that the code after the spin_unlock(>lock) is now a > > > critical section (preemption is

[PATCH v1 4/4] drm: bridge/analogix: switch Main-link and eDP PHY when enable/disable psr

turn off Main-link and power down eDP PHY when enable psr, turn on Main-link and power up eDP PHY when disable psr. Signed-off-by: zain wang --- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 105 ++--- 1 file changed, 52 insertions(+), 53

[PATCH v1 4/4] drm: bridge/analogix: switch Main-link and eDP PHY when enable/disable psr

turn off Main-link and power down eDP PHY when enable psr, turn on Main-link and power up eDP PHY when disable psr. Signed-off-by: zain wang --- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 105 ++--- 1 file changed, 52 insertions(+), 53 deletions(-) diff --git

Re: [PATCH -v2 2/9] sched/rtmutex/deadline: Fix a PI crash for deadline tasks

On Mon, 26 Sep 2016, Peter Zijlstra wrote: > This is because rt_mutex_enqueue_pi() and rt_mutex_dequeue_pi() > are only protected by pi_lock when operating pi waiters, while > rt_mutex_get_top_task(), will access them with rq lock held but > not holding pi_lock. > > In order to tackle it, we

Re: [PATCH -v2 2/9] sched/rtmutex/deadline: Fix a PI crash for deadline tasks

On Mon, 26 Sep 2016, Peter Zijlstra wrote: > This is because rt_mutex_enqueue_pi() and rt_mutex_dequeue_pi() > are only protected by pi_lock when operating pi waiters, while > rt_mutex_get_top_task(), will access them with rq lock held but > not holding pi_lock. > > In order to tackle it, we

Re: [PATCH -v2 4/9] rtmutex: Remove rt_mutex_fastunlock()

On Mon, 26 Sep 2016, Peter Zijlstra wrote: > There is but a single user and the previous patch mandates slowfn must > be rt_mutex_slowunlock(), so fold the lot together and save a few > lines. We might have to bring that back for RT, but ok :) Reviewed-by: Thomas Gleixner

Re: [PATCH -v2 4/9] rtmutex: Remove rt_mutex_fastunlock()

On Mon, 26 Sep 2016, Peter Zijlstra wrote: > There is but a single user and the previous patch mandates slowfn must > be rt_mutex_slowunlock(), so fold the lot together and save a few > lines. We might have to bring that back for RT, but ok :) Reviewed-by: Thomas Gleixner

Re: [PATCH -v2 1/9] rtmutex: Deboost before waking up the top waiter

On Thu, Sep 29, 2016 at 10:43:54AM -0400, Thomas Gleixner wrote: > On Mon, 26 Sep 2016, Peter Zijlstra wrote: > > > On Mon, Sep 26, 2016 at 11:37:27AM -0400, Steven Rostedt wrote: > > > On Mon, 26 Sep 2016 11:35:03 -0400 > > > Steven Rostedt wrote: > > > > > > > Especially

Re: [PATCH -v2 1/9] rtmutex: Deboost before waking up the top waiter

On Thu, Sep 29, 2016 at 10:43:54AM -0400, Thomas Gleixner wrote: > On Mon, 26 Sep 2016, Peter Zijlstra wrote: > > > On Mon, Sep 26, 2016 at 11:37:27AM -0400, Steven Rostedt wrote: > > > On Mon, 26 Sep 2016 11:35:03 -0400 > > > Steven Rostedt wrote: > > > > > > > Especially now that the code

[PATCH v1 3/4] drm/bridge: analogix_dp: detect Sink PSR state after configuring the PSR

From: Yakir Yang Make sure the request PSR state takes effect in analogix_dp_send_psr_spd() function, or print the sink PSR error state if we failed to apply the requested PSR setting. Signed-off-by: Yakir Yang Signed-off-by: Zain Wang

[PATCH v1 3/4] drm/bridge: analogix_dp: detect Sink PSR state after configuring the PSR

From: Yakir Yang Make sure the request PSR state takes effect in analogix_dp_send_psr_spd() function, or print the sink PSR error state if we failed to apply the requested PSR setting. Signed-off-by: Yakir Yang Signed-off-by: Zain Wang --- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c

[PATCH v1 0/4] Misc changes to Rockchip PSR drivers

1. prevent runing enable_psr when disabled bridge 2. get sync PM when init eDP 3. detect Sink PSR state after configuring the PSR 4. switch Main-Link and eDP phy when enable/disable psr BR, - Zain Yakir Yang (1): drm/bridge: analogix_dp: detect Sink PSR state after configuring the PSR

[PATCH v1 1/4] drm/bridge: analogix_dp: prevent runing enable_psr when disabled bridge.

When disabled bridge, analogix_dp_enable_psr() may run due to timer was set by rockchip_drm_do_flush(), in this case we should return -EBUSY. Signed-off-by: zain wang --- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 10 -- 1 file changed, 8 insertions(+),

[PATCH v1 2/4] drm/bridge: analogix_dp: get sync PM when init eDP

Signed-off-by: zain wang --- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c index 206529a..026ec91 100644 ---

[PATCH v1 0/4] Misc changes to Rockchip PSR drivers

1. prevent runing enable_psr when disabled bridge 2. get sync PM when init eDP 3. detect Sink PSR state after configuring the PSR 4. switch Main-Link and eDP phy when enable/disable psr BR, - Zain Yakir Yang (1): drm/bridge: analogix_dp: detect Sink PSR state after configuring the PSR

[PATCH v1 1/4] drm/bridge: analogix_dp: prevent runing enable_psr when disabled bridge.

When disabled bridge, analogix_dp_enable_psr() may run due to timer was set by rockchip_drm_do_flush(), in this case we should return -EBUSY. Signed-off-by: zain wang --- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff

[PATCH v1 2/4] drm/bridge: analogix_dp: get sync PM when init eDP

Signed-off-by: zain wang --- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c index 206529a..026ec91 100644 ---

Re: [PATCH 4.7 00/69] 4.7.6-stable review

Greg Kroah-Hartman writes: > On Thu, Sep 29, 2016 at 01:22:06AM -0700, Kevin Hilman wrote: >> kernelci.org bot writes: >> >> > stable-rc boot: 105 boots: 1 failed, 100 passed with 4 offline >> > (v4.7.5-70-g64e4c0f6d4b1) >> > >> > Full Boot

Re: [PATCH 4.7 00/69] 4.7.6-stable review

Greg Kroah-Hartman writes: > On Thu, Sep 29, 2016 at 01:22:06AM -0700, Kevin Hilman wrote: >> kernelci.org bot writes: >> >> > stable-rc boot: 105 boots: 1 failed, 100 passed with 4 offline >> > (v4.7.5-70-g64e4c0f6d4b1) >> > >> > Full Boot Summary: >> >

Re: 4.7 regression: ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off

On 9/29/2016 10:28 AM, Sinan Kaya wrote: > + if (irq < ACPI_MAX_ISA_IRQS) BTW, can you change this line to if (link->irq.active < ACPI_MAX_ISA_IRQS) after applying. > + acpi_isa_irq_penalty[link->irq.active] += > +

Re: 4.7 regression: ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off

On 9/29/2016 10:28 AM, Sinan Kaya wrote: > + if (irq < ACPI_MAX_ISA_IRQS) BTW, can you change this line to if (link->irq.active < ACPI_MAX_ISA_IRQS) after applying. > + acpi_isa_irq_penalty[link->irq.active] += > +

[PATCH 23/27] perf probe: Ignore the error of finding inline instance

From: Masami Hiramatsu Ignore the error when the perf probe failed to find inline function instances. This can happen when we search a method in C++ debuginfo. If there is completely no instance in target, perf probe can return an error. E.g. without this fix: $

[PATCH 14/27] perf probe: Increase debug level of SDT debug messages

From: Adrian Hunter Two SDT debug messages can occur for every DSO which is too noisy. Consequently, increase debug level of SDT messages. Signed-off-by: Adrian Hunter Acked-by: Masami Hiramatsu Cc: Jiri Olsa

[PATCH 20/27] perf intel-pt: Read address filter from AUXTRACE_INFO event

From: Adrian Hunter Read the address filter from the AUXTRACE_INFO event in preparation for using it to assist in decoding. Signed-off-by: Adrian Hunter Cc: Jiri Olsa Cc: Masami Hiramatsu Cc: Mathieu

[PATCH 21/27] perf intel-pt: Enable decoder to handle TIP.PGD with missing IP

From: Adrian Hunter When address filters are used, the decoder must detect the end of a filter region (or a branch into a tracestop region) by matching Packet Generation Disabled (TIP.PGD) packets against the object code using the IP given in the packet. However, due to

[PATCH 25/27] perf probe: Fix to cut off incompatible chars from group name

From: Masami Hiramatsu Cut off the characters which can not use for group name of uprobes when making it based on executable filename. For example, if the exec name is libstdc++.so, without this fix perf probe generates "probe_libstdc++" as the group name, but it is failed

[PATCH 24/27] perf probe: Skip if the function address is 0

From: Masami Hiramatsu Skip probes if the entry address of the target function is 0. This can happen when we're handling C++ debuginfo files. E.g. without this fix, below case still fail. $ ./perf probe -x /usr/lib64/libstdc++.so.6 -vD is_open

[PATCH 17/27] perf intel-pt: Fix missing error codes processing auxtrace_info

From: Adrian Hunter Fix 2 places where the err variable was not being set. Signed-off-by: Adrian Hunter Cc: Jiri Olsa Cc: Masami Hiramatsu Cc: Mathieu Poirier Link:

[PATCH 23/27] perf probe: Ignore the error of finding inline instance

From: Masami Hiramatsu Ignore the error when the perf probe failed to find inline function instances. This can happen when we search a method in C++ debuginfo. If there is completely no instance in target, perf probe can return an error. E.g. without this fix: $ perf probe -x

[PATCH 14/27] perf probe: Increase debug level of SDT debug messages

From: Adrian Hunter Two SDT debug messages can occur for every DSO which is too noisy. Consequently, increase debug level of SDT messages. Signed-off-by: Adrian Hunter Acked-by: Masami Hiramatsu Cc: Jiri Olsa Cc: Mathieu Poirier Link:

[PATCH 20/27] perf intel-pt: Read address filter from AUXTRACE_INFO event

From: Adrian Hunter Read the address filter from the AUXTRACE_INFO event in preparation for using it to assist in decoding. Signed-off-by: Adrian Hunter Cc: Jiri Olsa Cc: Masami Hiramatsu Cc: Mathieu Poirier Link:

[PATCH 24/27] perf probe: Skip if the function address is 0

From: Masami Hiramatsu Skip probes if the entry address of the target function is 0. This can happen when we're handling C++ debuginfo files. E.g. without this fix, below case still fail. $ ./perf probe -x /usr/lib64/libstdc++.so.6 -vD is_open probe-definition(0): is_open

[PATCH 17/27] perf intel-pt: Fix missing error codes processing auxtrace_info

From: Adrian Hunter Fix 2 places where the err variable was not being set. Signed-off-by: Adrian Hunter Cc: Jiri Olsa Cc: Masami Hiramatsu Cc: Mathieu Poirier Link: http://lkml.kernel.org/r/1474641528-18776-12-git-send-email-adrian.hun...@intel.com Signed-off-by: Arnaldo Carvalho de Melo

<    3   4   5   6   7   8   9   10   11   12   >