[PATCH v2 3/6] drm/fsl-dcu: move layer initialization to plane file

Move the initialization code for layers into a separate function in the plane file. This allows to reuse the function on resume. Also move it at the very beginning which may not matter but makes logically much more sense. Signed-off-by: Stefan Agner ---

[PATCH v2 6/6] drm/fsl-dcu: disable vblank events on CRTC disable

Disable vblank events when CRTC gets disabled. This avoids an external abort when entering suspend while disable_timer is still active: On resume the timer might fire immediately and cause a register access in fsl_dcu_drm_disable_vblank before clocks get enabled by the resume function.

[PATCH v2 3/6] drm/fsl-dcu: move layer initialization to plane file

Move the initialization code for layers into a separate function in the plane file. This allows to reuse the function on resume. Also move it at the very beginning which may not matter but makes logically much more sense. Signed-off-by: Stefan Agner ---

[PATCH v2 6/6] drm/fsl-dcu: disable vblank events on CRTC disable

Disable vblank events when CRTC gets disabled. This avoids an external abort when entering suspend while disable_timer is still active: On resume the timer might fire immediately and cause a register access in fsl_dcu_drm_disable_vblank before clocks get enabled by the resume function.

[PATCH v2 2/6] drm/fsl-dcu: store layer registers in soc_data

Store the number of registers per layer in soc_data. This is more consistent with how the rest of SoC specific data are handled. Signed-off-by: Stefan Agner --- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 8 ++-- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 2 ++

[PATCH v2 4/6] drm/fsl-dcu: use clk helpers

Use clk_prepare_enable and clk_disable_unprepare helpers. This also fixes a sequence issue in the enable path which lead to a warning on resume. Signed-off-by: Stefan Agner --- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 11 ++- 1 file changed, 2 insertions(+), 9

[PATCH v2 5/6] drm/fsl-dcu: implement suspend/resume using atomic helpers

Use the drm_atomic_helper_suspend() and drm_atomic_helper_resume() helpers to implement subsystem-level suspend/resume. This replaces the (non-functional) regmap cache based suspend resume functionality. Signed-off-by: Stefan Agner --- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c

[PATCH v2 2/6] drm/fsl-dcu: store layer registers in soc_data

Store the number of registers per layer in soc_data. This is more consistent with how the rest of SoC specific data are handled. Signed-off-by: Stefan Agner --- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 8 ++-- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 2 ++

[PATCH v2 4/6] drm/fsl-dcu: use clk helpers

Use clk_prepare_enable and clk_disable_unprepare helpers. This also fixes a sequence issue in the enable path which lead to a warning on resume. Signed-off-by: Stefan Agner --- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 11 ++- 1 file changed, 2 insertions(+), 9 deletions(-) diff

[PATCH v2 5/6] drm/fsl-dcu: implement suspend/resume using atomic helpers

Use the drm_atomic_helper_suspend() and drm_atomic_helper_resume() helpers to implement subsystem-level suspend/resume. This replaces the (non-functional) regmap cache based suspend resume functionality. Signed-off-by: Stefan Agner --- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 40

Re: fsl-dcu not works on latest "drm-next"

On 2016-05-26 02:11, Alexander Stein wrote: > On Thursday 26 May 2016 08:23:42, Meng Yi wrote: >> Hi Mark, >> >> > You've not specifically described the problem here - what are the >> > endiannesses of both the CPU and the device you're talking to? What >> > specifically is the endianess problem

Re: fsl-dcu not works on latest "drm-next"

On 2016-05-26 02:11, Alexander Stein wrote: > On Thursday 26 May 2016 08:23:42, Meng Yi wrote: >> Hi Mark, >> >> > You've not specifically described the problem here - what are the >> > endiannesses of both the CPU and the device you're talking to? What >> > specifically is the endianess problem

mmotm 2016-06-03-15-55 uploaded

The mm-of-the-moment snapshot 2016-06-03-15-55 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

mmotm 2016-06-03-15-55 uploaded

The mm-of-the-moment snapshot 2016-06-03-15-55 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

Re: [PATCH 00/10] Documentation/Sphinx

On Fri, Jun 3, 2016 at 11:04 PM, Jonathan Corbet wrote: > On Mon, 30 May 2016 23:05:34 +0300 > Jani Nikula wrote: > >> To be clear, the "sphinx-for-docs-next" branch of [1], [2] is what I >> propose to merge at this time. There's the Sphinx configuration,

Re: [PATCH 00/10] Documentation/Sphinx

On Fri, Jun 3, 2016 at 11:04 PM, Jonathan Corbet wrote: > On Mon, 30 May 2016 23:05:34 +0300 > Jani Nikula wrote: > >> To be clear, the "sphinx-for-docs-next" branch of [1], [2] is what I >> propose to merge at this time. There's the Sphinx configuration, kernel >> build integration, Sphinx

Re: Dcache oops

On Jun 3, 2016, at 6:37 PM, Al Viro wrote: > On Fri, Jun 03, 2016 at 11:23:55PM +0100, Al Viro wrote: > >> It's not that. It's explicit put_link() in do_last(), followed by >> ESTALEOPEN and subsequent misbegotten "retry the last step on ESTALEOPEN" >> looking at now-freed nd->last.name. IOW,

Re: Dcache oops

On Jun 3, 2016, at 6:37 PM, Al Viro wrote: > On Fri, Jun 03, 2016 at 11:23:55PM +0100, Al Viro wrote: > >> It's not that. It's explicit put_link() in do_last(), followed by >> ESTALEOPEN and subsequent misbegotten "retry the last step on ESTALEOPEN" >> looking at now-freed nd->last.name. IOW,

Re: Dcache oops

On Fri, Jun 03, 2016 at 03:36:22PM -0700, Linus Torvalds wrote: > Happy to hear that you seem to have figured it out. > > But why did it apparently only start happening now? Oleg has started to use Lustre torture tests on NFS, that's all. Note, BTW, that first they'd triggered an oopsable bug

Re: Dcache oops

On Fri, Jun 03, 2016 at 03:36:22PM -0700, Linus Torvalds wrote: > Happy to hear that you seem to have figured it out. > > But why did it apparently only start happening now? Oleg has started to use Lustre torture tests on NFS, that's all. Note, BTW, that first they'd triggered an oopsable bug

Re: Dcache oops

On Jun 3, 2016, at 6:36 PM, Linus Torvalds wrote: > On Fri, Jun 3, 2016 at 3:23 PM, Al Viro wrote: >> On Fri, Jun 03, 2016 at 03:00:02PM -0700, Linus Torvalds wrote: >>> Normally it's done at terminate_walk() time. But I note that in >>> walk_component(), we do

Re: Dcache oops

On Jun 3, 2016, at 6:36 PM, Linus Torvalds wrote: > On Fri, Jun 3, 2016 at 3:23 PM, Al Viro wrote: >> On Fri, Jun 03, 2016 at 03:00:02PM -0700, Linus Torvalds wrote: >>> Normally it's done at terminate_walk() time. But I note that in >>> walk_component(), we do put_link(nd) which does a

Re: Dcache oops

On Fri, Jun 03, 2016 at 11:23:55PM +0100, Al Viro wrote: > It's not that. It's explicit put_link() in do_last(), followed by > ESTALEOPEN and subsequent misbegotten "retry the last step on ESTALEOPEN" > looking at now-freed nd->last.name. IOW, the bug predates delayed_call > stuff. EOPENSTALE,

Re: Dcache oops

On Fri, Jun 03, 2016 at 11:23:55PM +0100, Al Viro wrote: > It's not that. It's explicit put_link() in do_last(), followed by > ESTALEOPEN and subsequent misbegotten "retry the last step on ESTALEOPEN" > looking at now-freed nd->last.name. IOW, the bug predates delayed_call > stuff. EOPENSTALE,

Re: Dcache oops

On Fri, Jun 3, 2016 at 3:23 PM, Al Viro wrote: > On Fri, Jun 03, 2016 at 03:00:02PM -0700, Linus Torvalds wrote: >>> >> Normally it's done at terminate_walk() time. But I note that in >> walk_component(), we do put_link(nd) which does a do_delayed_call(), >> but does

Re: Dcache oops

On Fri, Jun 3, 2016 at 3:23 PM, Al Viro wrote: > On Fri, Jun 03, 2016 at 03:00:02PM -0700, Linus Torvalds wrote: >>> >> Normally it's done at terminate_walk() time. But I note that in >> walk_component(), we do put_link(nd) which does a do_delayed_call(), >> but does *not* do a

Re: [RFC][PATCH 0/7] locking/rwsem: Convert rwsem count to atomic_long_t

On Fri, Jun 03, 2016 at 11:09:54AM -0700, Jason Low wrote: > --- a/arch/alpha/include/asm/rwsem.h > +++ b/arch/alpha/include/asm/rwsem.h > @@ -25,8 +25,8 @@ static inline void __down_read(struct rw_semaphore *sem) > { > long oldcount; > #ifndef CONFIG_SMP > - oldcount =

Re: [RFC][PATCH 0/7] locking/rwsem: Convert rwsem count to atomic_long_t

On Fri, Jun 03, 2016 at 11:09:54AM -0700, Jason Low wrote: > --- a/arch/alpha/include/asm/rwsem.h > +++ b/arch/alpha/include/asm/rwsem.h > @@ -25,8 +25,8 @@ static inline void __down_read(struct rw_semaphore *sem) > { > long oldcount; > #ifndef CONFIG_SMP > - oldcount =

[PATCH] [media] radio-maxiradio: fix memory leak when device is removed

Memory allocated for maxiradio device is not deallocated when the device is removed. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov --- drivers/media/radio/radio-maxiradio.c | 1 + 1 file changed, 1 insertion(+) diff

[PATCH] [media] radio-maxiradio: fix memory leak when device is removed

Memory allocated for maxiradio device is not deallocated when the device is removed. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov --- drivers/media/radio/radio-maxiradio.c | 1 + 1 file changed, 1 insertion(+) diff --git

Re: [RFC 10/12] x86, rwsem: simplify __down_write

On Fri, Jun 03, 2016 at 06:13:39PM +0200, Peter Zijlstra wrote: > So I've been playing with this again because Jason's atomic_long_t > patches made a mess of things. > > (similar findings for both ia64 and s390, suggesting killing all > arch/*/include/asm/rwsem.h might actuyally be an option). >

Re: [RFC 10/12] x86, rwsem: simplify __down_write

On Fri, Jun 03, 2016 at 06:13:39PM +0200, Peter Zijlstra wrote: > So I've been playing with this again because Jason's atomic_long_t > patches made a mess of things. > > (similar findings for both ia64 and s390, suggesting killing all > arch/*/include/asm/rwsem.h might actuyally be an option). >

[PATCH 2/3] ext4: Make cache hits/misses per-cpu counts

This patch changes the es_stats_cache_hits and es_stats_cache_misses statistics counts to percpu counters to reduce cacheline contention issues whem multiple threads are trying to update those counts simultaneously. With a 38-threads fio I/O test with 2 shared files (on DAX-mount ext4 formatted

[PATCH 0/3] dax, ext4: Improve DAX performance in ext4

This is a follow-up of the patch series [PATCH v5 0/2] ext4: Improve parallel I/O performance on NVDIMM https://lkml.org/lkml/2016/4/29/583 It is rebased to the latest 4.7-rc1 release. It has an additional patch to advantage of the fact that the inode i_mutex is now an i_rwsem. Patch 1

[PATCH 3/3] Drivers: hv: don't leak memory in vmbus_establish_gpadl()

From: Vitaly Kuznetsov In some cases create_gpadl_header() allocates submessages but we never free them. Signed-off-by: Vitaly Kuznetsov Signed-off-by: K. Y. Srinivasan --- drivers/hv/channel.c |6 +- 1 files changed, 5

[PATCH 0/3] dax, ext4: Improve DAX performance in ext4

This is a follow-up of the patch series [PATCH v5 0/2] ext4: Improve parallel I/O performance on NVDIMM https://lkml.org/lkml/2016/4/29/583 It is rebased to the latest 4.7-rc1 release. It has an additional patch to advantage of the fact that the inode i_mutex is now an i_rwsem. Patch 1

[PATCH 3/3] Drivers: hv: don't leak memory in vmbus_establish_gpadl()

From: Vitaly Kuznetsov In some cases create_gpadl_header() allocates submessages but we never free them. Signed-off-by: Vitaly Kuznetsov Signed-off-by: K. Y. Srinivasan --- drivers/hv/channel.c |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/drivers/hv/channel.c

[PATCH 2/3] ext4: Make cache hits/misses per-cpu counts

This patch changes the es_stats_cache_hits and es_stats_cache_misses statistics counts to percpu counters to reduce cacheline contention issues whem multiple threads are trying to update those counts simultaneously. With a 38-threads fio I/O test with 2 shared files (on DAX-mount ext4 formatted

[PATCH 1/3] dax: Take shared lock in dax_do_io()

With the change from i_mutex to i_rwsem in 4.7 kernel, the locking scheme in dax_do_io() can now be changed to take a shared lock for read so that multiple readers can access the same file concurrently. With a 38-threads fio I/O test with 2 shared files (on DAX-mount, ext4 formatted NVDIMM)

Re: Dcache oops

On Fri, Jun 03, 2016 at 11:23:55PM +0100, Al Viro wrote: > It's not that. It's explicit put_link() in do_last(), followed by > ESTALEOPEN and subsequent misbegotten "retry the last step on ESTALEOPEN" > looking at now-freed nd->last.name. IOW, the bug predates delayed_call > stuff. FWIW, I'd

[PATCH 3/3] ext4: Pass DIO_SKIP_DIO_COUNT to dax_do_io

Since all the DAX I/Os are synchronous, there is no need to update the DIO count in dax_do_io() when the count has already been updated or the i_rwsem lock (read or write) has or will be taken. This patch passes in the DIO_SKIP_DIO_COUNT flag to dax_do_io() to disable two unneeded atomic

[PATCH 1/3] dax: Take shared lock in dax_do_io()

With the change from i_mutex to i_rwsem in 4.7 kernel, the locking scheme in dax_do_io() can now be changed to take a shared lock for read so that multiple readers can access the same file concurrently. With a 38-threads fio I/O test with 2 shared files (on DAX-mount, ext4 formatted NVDIMM)

Re: Dcache oops

On Fri, Jun 03, 2016 at 11:23:55PM +0100, Al Viro wrote: > It's not that. It's explicit put_link() in do_last(), followed by > ESTALEOPEN and subsequent misbegotten "retry the last step on ESTALEOPEN" > looking at now-freed nd->last.name. IOW, the bug predates delayed_call > stuff. FWIW, I'd

[PATCH 3/3] ext4: Pass DIO_SKIP_DIO_COUNT to dax_do_io

Since all the DAX I/Os are synchronous, there is no need to update the DIO count in dax_do_io() when the count has already been updated or the i_rwsem lock (read or write) has or will be taken. This patch passes in the DIO_SKIP_DIO_COUNT flag to dax_do_io() to disable two unneeded atomic

[PATCH 1/3] Drivers: hv: avoid vfree() on crash

From: Vitaly Kuznetsov When we crash from NMI context (e.g. after NMI injection from host when 'sysctl -w kernel.unknown_nmi_panic=1' is set) we hit kernel BUG at mm/vmalloc.c:1530! as vfree() is denied. While the issue could be solved with in_nmi() check instead I

[PATCH 1/3] Drivers: hv: avoid vfree() on crash

From: Vitaly Kuznetsov When we crash from NMI context (e.g. after NMI injection from host when 'sysctl -w kernel.unknown_nmi_panic=1' is set) we hit kernel BUG at mm/vmalloc.c:1530! as vfree() is denied. While the issue could be solved with in_nmi() check instead I opted for skipping vfree

[PATCH 2/3] Drivers: hv: get rid of redundant messagecount in create_gpadl_header()

From: Vitaly Kuznetsov We use messagecount only once in vmbus_establish_gpadl() to check if it is safe to iterate through the submsglist. We can just initialize the list header in all cases in create_gpadl_header() instead. Signed-off-by: Vitaly Kuznetsov

[PATCH 2/3] Drivers: hv: get rid of redundant messagecount in create_gpadl_header()

From: Vitaly Kuznetsov We use messagecount only once in vmbus_establish_gpadl() to check if it is safe to iterate through the submsglist. We can just initialize the list header in all cases in create_gpadl_header() instead. Signed-off-by: Vitaly Kuznetsov Signed-off-by: K. Y. Srinivasan ---

[PATCH 0/3] Drivers: hv: vmbus: Some miscellaneous fixes

Some miscellaneous fixes. Vitaly Kuznetsov (3): Drivers: hv: avoid vfree() on crash Drivers: hv: get rid of redundant messagecount in create_gpadl_header() Drivers: hv: don't leak memory in vmbus_establish_gpadl() drivers/hv/channel.c | 44

[PATCH 0/3] Drivers: hv: vmbus: Some miscellaneous fixes

Some miscellaneous fixes. Vitaly Kuznetsov (3): Drivers: hv: avoid vfree() on crash Drivers: hv: get rid of redundant messagecount in create_gpadl_header() Drivers: hv: don't leak memory in vmbus_establish_gpadl() drivers/hv/channel.c | 44

Re: Dcache oops

On Fri, Jun 03, 2016 at 03:00:02PM -0700, Linus Torvalds wrote: > Is perhaps the "delayed_call" logic broken, and the symlink is free'd too > early? > > That whole set_delayed_call/do_delayed_call thing came in 4.5. Maybe > something broke that logic, and we've executed the delayed freeing >

Re: Dcache oops

On Fri, Jun 03, 2016 at 03:00:02PM -0700, Linus Torvalds wrote: > Is perhaps the "delayed_call" logic broken, and the symlink is free'd too > early? > > That whole set_delayed_call/do_delayed_call thing came in 4.5. Maybe > something broke that logic, and we've executed the delayed freeing >

Re: [lkp] [mm] 795ae7a0de: pixz.throughput -9.1% regression

On Thu, Jun 02, 2016 at 12:07:06PM -0400, Johannes Weiner wrote: > Hi, > > On Thu, Jun 02, 2016 at 02:45:07PM +0800, kernel test robot wrote: > > FYI, we noticed pixz.throughput -9.1% regression due to commit: > > > > commit 795ae7a0de6b834a0cc202aa55c190ef81496665 ("mm: scale kswapd > >

Re: [lkp] [mm] 795ae7a0de: pixz.throughput -9.1% regression

On Thu, Jun 02, 2016 at 12:07:06PM -0400, Johannes Weiner wrote: > Hi, > > On Thu, Jun 02, 2016 at 02:45:07PM +0800, kernel test robot wrote: > > FYI, we noticed pixz.throughput -9.1% regression due to commit: > > > > commit 795ae7a0de6b834a0cc202aa55c190ef81496665 ("mm: scale kswapd > >

Re: Dcache oops

On Fri, Jun 03, 2016 at 10:46:31PM +0100, Al Viro wrote: > On Fri, Jun 03, 2016 at 05:17:06PM -0400, Oleg Drokin wrote: > > > > Can the same thing be reproduced (with NFS fix) on v4.6, ede4090, 7f427d3, > > > 4e8440b? > > > > Well, that was faster than I expected. 4e8440b triggers right away, so

Re: Dcache oops

On Fri, Jun 03, 2016 at 10:46:31PM +0100, Al Viro wrote: > On Fri, Jun 03, 2016 at 05:17:06PM -0400, Oleg Drokin wrote: > > > > Can the same thing be reproduced (with NFS fix) on v4.6, ede4090, 7f427d3, > > > 4e8440b? > > > > Well, that was faster than I expected. 4e8440b triggers right away, so

Re: [PATCH] b43: Remove unused phy_a code

On Fri, 3 Jun 2016 14:32:46 -0700 Guenter Roeck wrote: > gcc-6 reports the following error with -Werror=unused-const-variable. > > drivers/net/wireless/broadcom/b43/phy_a.c:576:40: error: > 'b43_phyops_a' defined but not used > > Turns out a lot of code in this file

Re: Build failure in -next due to 'rtc: cmos: move mc146818rtc code out of asm-generic/rtc.h'

Hi, On 03/06/2016 at 07:44:55 -0700, Guenter Roeck wrote : > On 06/03/2016 05:11 AM, Arnd Bergmann wrote: > > I have trouble reproducing this, but I think the problem here is that there > > are two definitions of CMOS_READ() in sparc, and we pick up the wrong one > > here: there is no 'rtc_port'

Re: [PATCH] b43: Remove unused phy_a code

On Fri, 3 Jun 2016 14:32:46 -0700 Guenter Roeck wrote: > gcc-6 reports the following error with -Werror=unused-const-variable. > > drivers/net/wireless/broadcom/b43/phy_a.c:576:40: error: > 'b43_phyops_a' defined but not used > > Turns out a lot of code in this file is unused, so let's

Re: Build failure in -next due to 'rtc: cmos: move mc146818rtc code out of asm-generic/rtc.h'

Hi, On 03/06/2016 at 07:44:55 -0700, Guenter Roeck wrote : > On 06/03/2016 05:11 AM, Arnd Bergmann wrote: > > I have trouble reproducing this, but I think the problem here is that there > > are two definitions of CMOS_READ() in sparc, and we pick up the wrong one > > here: there is no 'rtc_port'

Re: [PATCH] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot for X-Gene v1

On Fri, May 27, 2016 at 3:52 AM, Lorenzo Pieralisi wrote: > > [+ Rafael] > > On Thu, May 26, 2016 at 01:49:23PM -0700, Duc Dang wrote: > > Hi Lorenzo, > > > > On Thu, May 26, 2016 at 5:34 AM, Lorenzo Pieralisi > > wrote: > > > Hi Duc, > > > >

Re: [PATCH] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot for X-Gene v1

On Fri, May 27, 2016 at 3:52 AM, Lorenzo Pieralisi wrote: > > [+ Rafael] > > On Thu, May 26, 2016 at 01:49:23PM -0700, Duc Dang wrote: > > Hi Lorenzo, > > > > On Thu, May 26, 2016 at 5:34 AM, Lorenzo Pieralisi > > wrote: > > > Hi Duc, > > > > > > On Wed, May 25, 2016 at 04:13:35PM -0700, Duc

[PATCH 1/5] dts: bindings: Add binding documentation for hisilicon,hi6552-powerkey

Adds binding documentation for hi6552 pmic powerkey button. Cc: Dmitry Torokhov Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala

[PATCH 1/5] dts: bindings: Add binding documentation for hisilicon,hi6552-powerkey

Adds binding documentation for hi6552 pmic powerkey button. Cc: Dmitry Torokhov Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Cc: Lee Jones Cc: Jorge Ramirez-Ortiz Cc: Wei Xu Cc: Guodong Xu Signed-off-by: John Stultz ---

[PATCH 4/5] drivers: input: powerkey for HISI 65xx SoC

From: Jorge Ramirez-Ortiz This driver provides a input driver for the power button on the HiSi 65xx SoC for boards like HiKey. This driver was originally by Zhiliang Xue then basically rewritten by Jorge, but preserving the original

[PATCH 4/5] drivers: input: powerkey for HISI 65xx SoC

From: Jorge Ramirez-Ortiz This driver provides a input driver for the power button on the HiSi 65xx SoC for boards like HiKey. This driver was originally by Zhiliang Xue then basically rewritten by Jorge, but preserving the original module author credits. Cc: Dmitry Torokhov Cc: Rob Herring

[PATCH 3/5] hi655x-pmic: Fixup issue with un-acked interrupts

While trying to get the powerkey to function, I found when pressing the key, I would get infinitely repeating interrupts. After digging around a bit, it seems we didn't set the ack_base value for the regmap irqchip logic, so nothing was acking the interrupt. This patch adds the ack_base, which

[PATCH 3/5] hi655x-pmic: Fixup issue with un-acked interrupts

While trying to get the powerkey to function, I found when pressing the key, I would get infinitely repeating interrupts. After digging around a bit, it seems we didn't set the ack_base value for the regmap irqchip logic, so nothing was acking the interrupt. This patch adds the ack_base, which

[PATCH 0/5] Hi655x powerkey support for HiKey (v2)

This patchset enables the pmic powerkey to function on HiKey. I wanted to submit it for some initial review. Feedback would be greatly appreciated! New in v2: * Larger rework to the powerkey driver, integrating feedback from Dmitry * Minor dts cleanup suggested by Rob thanks -john Cc: Dmitry

[PATCH 2/5] hi655x-pmic: Make hi655x pmic logic probe child nodes in the dt

In trying to wire up the powerkey driver, I found I needed to add this to get the pmic logic to probe child nodes in the dt data. With this patch, child nodes get properly probed. Cc: Dmitry Torokhov Cc: Rob Herring Cc: Pawel Moll

[PATCH 5/5] arm64: dts: Add powerkey info to pmic for hi6220-hikey

From: Guodong Xu Add powerkey entry to the HiKey dts. Cc: Dmitry Torokhov Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc:

[PATCH 0/5] Hi655x powerkey support for HiKey (v2)

This patchset enables the pmic powerkey to function on HiKey. I wanted to submit it for some initial review. Feedback would be greatly appreciated! New in v2: * Larger rework to the powerkey driver, integrating feedback from Dmitry * Minor dts cleanup suggested by Rob thanks -john Cc: Dmitry

[PATCH 2/5] hi655x-pmic: Make hi655x pmic logic probe child nodes in the dt

In trying to wire up the powerkey driver, I found I needed to add this to get the pmic logic to probe child nodes in the dt data. With this patch, child nodes get properly probed. Cc: Dmitry Torokhov Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Cc: Lee

[PATCH 5/5] arm64: dts: Add powerkey info to pmic for hi6220-hikey

From: Guodong Xu Add powerkey entry to the HiKey dts. Cc: Dmitry Torokhov Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Cc: Lee Jones Cc: Jorge Ramirez-Ortiz Cc: Wei Xu Cc: Guodong Xu Signed-off-by: Guodong Xu Signed-off-by: John Stultz ---

Re: [PATCH] mn10300: Add missing include file to proc-init.c

On 02/06/2016 at 17:38:28 -0700, Guenter Roeck wrote : > mn10300:asb2303_defconfig fails to build as follows. > > arch/mn10300/proc-mn103e010/proc-init.c: In function 'processor_init': > arch/mn10300/proc-mn103e010/proc-init.c:59:24: error: 'NR_IRQS' undeclared > > Fixes: 458b5b44

Re: [PATCH] mn10300: Add missing include file to proc-init.c

On 02/06/2016 at 17:38:28 -0700, Guenter Roeck wrote : > mn10300:asb2303_defconfig fails to build as follows. > > arch/mn10300/proc-mn103e010/proc-init.c: In function 'processor_init': > arch/mn10300/proc-mn103e010/proc-init.c:59:24: error: 'NR_IRQS' undeclared > > Fixes: 458b5b44

[git pull] drm fixes for rc2

Hi Linus, A bunch of ARM drivers got into the fixes vibe this time around, so this contains a bunch of fixes for imx, atmel hlcdc, arm hdlcd (only so many combos of hlcd), mediatek and omap drm. Other than that there is one mgag200 fix and a few core drm regression fixes. Dave. The following

[git pull] drm fixes for rc2

Hi Linus, A bunch of ARM drivers got into the fixes vibe this time around, so this contains a bunch of fixes for imx, atmel hlcdc, arm hdlcd (only so many combos of hlcd), mediatek and omap drm. Other than that there is one mgag200 fix and a few core drm regression fixes. Dave. The following

Re: [PATCH v7 00/15] ACPI NUMA support for ARM64

On Tuesday, May 24, 2016 03:35:30 PM David Daney wrote: > From: David Daney > > Rebased to Linus' master branch at commit 1d6da87a3241 ("Merge branch > 'drm-next' of git://people.freedesktop.org/~airlied/linux") > > ACPI 5.1 already introduced NUMA support for ARM64,

Re: [PATCH v7 00/15] ACPI NUMA support for ARM64

On Tuesday, May 24, 2016 03:35:30 PM David Daney wrote: > From: David Daney > > Rebased to Linus' master branch at commit 1d6da87a3241 ("Merge branch > 'drm-next' of git://people.freedesktop.org/~airlied/linux") > > ACPI 5.1 already introduced NUMA support for ARM64, which can get the > NUMA

Re: [kernel-hardening] [PATCH 2/2] arm: apply more __ro_after_init

On Fri, Jun 3, 2016 at 2:54 PM, Greg KH wrote: > On Fri, Jun 03, 2016 at 02:26:54PM -0700, Kees Cook wrote: >> On Fri, Jun 3, 2016 at 11:51 AM, Greg KH wrote: >> > On Fri, Jun 03, 2016 at 11:40:24AM -0700, Kees Cook wrote: >> >> Guided by

Re: [kernel-hardening] [PATCH 2/2] arm: apply more __ro_after_init

On Fri, Jun 3, 2016 at 2:54 PM, Greg KH wrote: > On Fri, Jun 03, 2016 at 02:26:54PM -0700, Kees Cook wrote: >> On Fri, Jun 3, 2016 at 11:51 AM, Greg KH wrote: >> > On Fri, Jun 03, 2016 at 11:40:24AM -0700, Kees Cook wrote: >> >> Guided by grsecurity's analogous __read_only markings in arch/arm,

Re: Dcache oops

On Fri, Jun 3, 2016 at 2:26 PM, Al Viro wrote: >> >> in the __d_lookup() disassembly. And %rdi contains 2, so there were >> supposed to be two more characters at 'ct' (which is %rdx). > > ... and since r8 and rsi are 0, we couldn't have consumed anything. Right you are.

Re: Dcache oops

On Fri, Jun 3, 2016 at 2:26 PM, Al Viro wrote: >> >> in the __d_lookup() disassembly. And %rdi contains 2, so there were >> supposed to be two more characters at 'ct' (which is %rdx). > > ... and since r8 and rsi are 0, we couldn't have consumed anything. Right you are. So it really started out

Re: perf crash with tip/perf/core

Em Fri, Jun 03, 2016 at 11:37:05PM +0200, Peter Zijlstra escreveu: > On Fri, Jun 03, 2016 at 06:27:40PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Fri, Jun 03, 2016 at 06:15:15PM -0300, Arnaldo Carvalho de Melo escreveu: > > > Hi Peter, > > > > > > I built what is in tip/perf/core to test

Re: perf crash with tip/perf/core

Em Fri, Jun 03, 2016 at 11:37:05PM +0200, Peter Zijlstra escreveu: > On Fri, Jun 03, 2016 at 06:27:40PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Fri, Jun 03, 2016 at 06:15:15PM -0300, Arnaldo Carvalho de Melo escreveu: > > > Hi Peter, > > > > > > I built what is in tip/perf/core to test

Re: [kernel-hardening] [PATCH 2/2] arm: apply more __ro_after_init

On Fri, Jun 03, 2016 at 02:26:54PM -0700, Kees Cook wrote: > On Fri, Jun 3, 2016 at 11:51 AM, Greg KH wrote: > > On Fri, Jun 03, 2016 at 11:40:24AM -0700, Kees Cook wrote: > >> Guided by grsecurity's analogous __read_only markings in arch/arm, > >> this applies several

Re: [kernel-hardening] [PATCH 2/2] arm: apply more __ro_after_init

On Fri, Jun 03, 2016 at 02:26:54PM -0700, Kees Cook wrote: > On Fri, Jun 3, 2016 at 11:51 AM, Greg KH wrote: > > On Fri, Jun 03, 2016 at 11:40:24AM -0700, Kees Cook wrote: > >> Guided by grsecurity's analogous __read_only markings in arch/arm, > >> this applies several uses of __ro_after_init to

RE: [PATCH 3/3] ntb_tool: Add memory window debug support

From: Logan Gunthorpe > We allocate some memory window buffers when the link comes up, then we > provide debugfs files to read/write each side of the link. > > This is useful for debugging the mapping when writing new drivers. > > Signed-off-by: Logan Gunthorpe Thanks!

[added to the 3.18 stable tree] MIPS: math-emu: Fix jalr emulation when rd == $0

From: Paul Burton This patch has been added to the 3.18 stable tree. If you have any objections, please let us know. === [ Upstream commit ab4a92e66741b35ca12f8497896bafbe579c28a1 ] When emulating a jalr instruction with rd == $0, the code in isBranchInstr

RE: [PATCH 3/3] ntb_tool: Add memory window debug support

From: Logan Gunthorpe > We allocate some memory window buffers when the link comes up, then we > provide debugfs files to read/write each side of the link. > > This is useful for debugging the mapping when writing new drivers. > > Signed-off-by: Logan Gunthorpe Thanks! This was on my wish

[added to the 3.18 stable tree] MIPS: math-emu: Fix jalr emulation when rd == $0

From: Paul Burton This patch has been added to the 3.18 stable tree. If you have any objections, please let us know. === [ Upstream commit ab4a92e66741b35ca12f8497896bafbe579c28a1 ] When emulating a jalr instruction with rd == $0, the code in isBranchInstr was incorrectly writing

[added to the 3.18 stable tree] MIPS: Fix siginfo.h to use strict posix types

From: James Hogan This patch has been added to the 3.18 stable tree. If you have any objections, please let us know. === [ Upstream commit 5daebc477da4dfeb31ae193d83084def58fd2697 ] Commit 85efde6f4e0d ("make exported headers use strict posix types")

[added to the 3.18 stable tree] MIPS: Fix siginfo.h to use strict posix types

From: James Hogan This patch has been added to the 3.18 stable tree. If you have any objections, please let us know. === [ Upstream commit 5daebc477da4dfeb31ae193d83084def58fd2697 ] Commit 85efde6f4e0d ("make exported headers use strict posix types") changed the asm-generic

Re: Dcache oops

On Fri, Jun 03, 2016 at 05:17:06PM -0400, Oleg Drokin wrote: > > Can the same thing be reproduced (with NFS fix) on v4.6, ede4090, 7f427d3, > > 4e8440b? > > Well, that was faster than I expected. 4e8440b triggers right away, so I guess > there's no point in trying the later ones? > BTW, just to

Re: Dcache oops

On Fri, Jun 03, 2016 at 05:17:06PM -0400, Oleg Drokin wrote: > > Can the same thing be reproduced (with NFS fix) on v4.6, ede4090, 7f427d3, > > 4e8440b? > > Well, that was faster than I expected. 4e8440b triggers right away, so I guess > there's no point in trying the later ones? > BTW, just to

[added to the 4.1 stable tree] MIPS64: R6: R2 emulation bugfix

From: Leonid Yegoshin This patch has been added to the 4.1 stable tree. If you have any objections, please let us know. === [ Upstream commit 41fa29e4d8cf4150568a0fe9bb4d62229f9caed5 ] Error recovery pointers for fixups was improperly set as ".word"

[added to the 4.1 stable tree] MIPS64: R6: R2 emulation bugfix

From: Leonid Yegoshin This patch has been added to the 4.1 stable tree. If you have any objections, please let us know. === [ Upstream commit 41fa29e4d8cf4150568a0fe9bb4d62229f9caed5 ] Error recovery pointers for fixups was improperly set as ".word" which is unsuitable for MIPS64.

Re: [PATCH 0/3] sched/debug: schedstats bug fix and cleanups

On Fri, Jun 03, 2016 at 03:44:38PM -0500, Josh Poimboeuf wrote: > A /proc/sched_debug bug fix and a couple of other schedstats-related > cleanups. > > Josh Poimboeuf (3): > sched/debug: fix /proc/sched_debug regression > sched/debug: always show nr_migrations > sched/debug: remove

Re: [PATCH 0/3] sched/debug: schedstats bug fix and cleanups

On Fri, Jun 03, 2016 at 03:44:38PM -0500, Josh Poimboeuf wrote: > A /proc/sched_debug bug fix and a couple of other schedstats-related > cleanups. > > Josh Poimboeuf (3): > sched/debug: fix /proc/sched_debug regression > sched/debug: always show nr_migrations > sched/debug: remove

<    1   2   3   4   5   6   7   8   9   10   >