[PATCH REBASE 2/3] media: s5p-mfc fix memory leak in s5p_mfc_remove()

s5p_mfc_remove() fails to release encoder and decoder video devices. Signed-off-by: Shuah Khan Reviewed-by: Javier Martinez Canillas --- drivers/media/platform/s5p-mfc/s5p_mfc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

[PATCH REBASE 2/3] media: s5p-mfc fix memory leak in s5p_mfc_remove()

s5p_mfc_remove() fails to release encoder and decoder video devices. Signed-off-by: Shuah Khan Reviewed-by: Javier Martinez Canillas --- drivers/media/platform/s5p-mfc/s5p_mfc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c

Re: [PATCH 0/4] ftrace: One more check on x86 and some small fixes

On Mon, 27 Jun 2016 15:54:33 +0200 Petr Mladek wrote: > 1st patch adds one more paranoid check of the modified function on x86. > > Plus there are 3 small changes that appeared when hunting down > the 1st patch. > > Petr Mladek (4): > ftrace/x86: Make sure to modify 5-bite

Re: [PATCH 0/4] ftrace: One more check on x86 and some small fixes

On Mon, 27 Jun 2016 15:54:33 +0200 Petr Mladek wrote: > 1st patch adds one more paranoid check of the modified function on x86. > > Plus there are 3 small changes that appeared when hunting down > the 1st patch. > > Petr Mladek (4): > ftrace/x86: Make sure to modify 5-bite instructions >

[PATCH REBASE 1/3] media: s5p-mfc fix video device release double release in probe error path

Fix Decoder and encoder video device double release in probe error path. video_device_release(dev->vfd_dec) get called twice if decoder register fails. Also, video_device_release(dev->vfd_enc) get called twice if encoder register fails. Signed-off-by: Shuah Khan ---

[PATCH REBASE 1/3] media: s5p-mfc fix video device release double release in probe error path

Fix Decoder and encoder video device double release in probe error path. video_device_release(dev->vfd_dec) get called twice if decoder register fails. Also, video_device_release(dev->vfd_enc) get called twice if encoder register fails. Signed-off-by: Shuah Khan ---

[PATCH REBASE 0/3] Rebased on linuxtv/master

Rebased on linuxtv/master latest with the top commit: commit 80aa26593e3eb48f16c4222aa27ff40806f57c45 Author: Ulrich Hecht Date: Wed May 11 11:02:53 2016 -0300 Shuah Khan (3): media: s5p-mfc fix video device release double release in probe error path

[PATCH REBASE 0/3] Rebased on linuxtv/master

Rebased on linuxtv/master latest with the top commit: commit 80aa26593e3eb48f16c4222aa27ff40806f57c45 Author: Ulrich Hecht Date: Wed May 11 11:02:53 2016 -0300 Shuah Khan (3): media: s5p-mfc fix video device release double release in probe error path media: s5p-mfc fix memory leak in

[PATCH REBASE 3/3] media: s5p-mfc fix null pointer deference in clk_core_enable()

Fix null pointer deference in clk_core_enable() when driver unbind is run when there is an application has an active pipeline playing. s5p_mfc_release() gets called after s5p_mfc_final_pm() disables and does clk_put() and s5p_mfc_release() attempts to enable clock and runs into null pointer

[PATCH REBASE 3/3] media: s5p-mfc fix null pointer deference in clk_core_enable()

Fix null pointer deference in clk_core_enable() when driver unbind is run when there is an application has an active pipeline playing. s5p_mfc_release() gets called after s5p_mfc_final_pm() disables and does clk_put() and s5p_mfc_release() attempts to enable clock and runs into null pointer

Re: kthread_stop insanity (Re: [[DEBUG] force] 2642458962: BUG: unable to handle kernel paging request at ffffc90000997f18)

On Tue, Jun 28, 2016 at 11:58 AM, Oleg Nesterov wrote: > On 06/27, Oleg Nesterov wrote: >> >> On 06/27, Andy Lutomirski wrote: >> > >> > Want to send a patch? I could do it, but you understand this code >> > much better than I do. >> >> Well, I'll try to do this tomorrow unless

Re: kthread_stop insanity (Re: [[DEBUG] force] 2642458962: BUG: unable to handle kernel paging request at ffffc90000997f18)

On Tue, Jun 28, 2016 at 11:58 AM, Oleg Nesterov wrote: > On 06/27, Oleg Nesterov wrote: >> >> On 06/27, Andy Lutomirski wrote: >> > >> > Want to send a patch? I could do it, but you understand this code >> > much better than I do. >> >> Well, I'll try to do this tomorrow unless you do it. > > I

Re: [PATCH 18/23] [AARCH64] ILP32: support stat syscall family

On Tue, Jun 28, 2016 at 05:15:13PM +, Joseph Myers wrote: > still > applies. Unify implementations instead of proliferating variants. I think on it. I don't see simple way to unify it right now. And I plan to take a vacation in

Re: [PATCH 18/23] [AARCH64] ILP32: support stat syscall family

On Tue, Jun 28, 2016 at 05:15:13PM +, Joseph Myers wrote: > still > applies. Unify implementations instead of proliferating variants. I think on it. I don't see simple way to unify it right now. And I plan to take a vacation in

Re: [PATCH v4 04/29] x86/cpa: In populate_pgd, don't set the pgd entry until it's populated

On Tue, Jun 28, 2016 at 11:48 AM, Borislav Petkov wrote: > On Sun, Jun 26, 2016 at 02:55:26PM -0700, Andy Lutomirski wrote: >> This avoids pointless races in which another CPU or task might see a >> partially populated global pgd entry. These races should normally >> be harmless,

Re: [PATCH 01/10] Documentation: dt-bindings: mailbox: tegra: Add binding for HSP mailbox

On 06/28/2016 03:15 AM, Joseph Lo wrote: On 06/27/2016 11:55 PM, Stephen Warren wrote: On 06/27/2016 03:02 AM, Joseph Lo wrote: Add DT binding for the Hardware Synchronization Primitives (HSP). The HSP is designed for the processors to share resources and communicate together. It provides a

Re: [PATCH 01/10] Documentation: dt-bindings: mailbox: tegra: Add binding for HSP mailbox

On 06/28/2016 03:15 AM, Joseph Lo wrote: On 06/27/2016 11:55 PM, Stephen Warren wrote: On 06/27/2016 03:02 AM, Joseph Lo wrote: Add DT binding for the Hardware Synchronization Primitives (HSP). The HSP is designed for the processors to share resources and communicate together. It provides a

Re: [PATCH v4 04/29] x86/cpa: In populate_pgd, don't set the pgd entry until it's populated

On Tue, Jun 28, 2016 at 11:48 AM, Borislav Petkov wrote: > On Sun, Jun 26, 2016 at 02:55:26PM -0700, Andy Lutomirski wrote: >> This avoids pointless races in which another CPU or task might see a >> partially populated global pgd entry. These races should normally >> be harmless, but, if another

Re: [GIT PULL] doc: sphinx-4.8 DocBook to reST movement on Jon's docs-next

On Tue, 28 Jun 2016, Markus Heiser wrote: > Hi Jonathan, hi Mauro, > > here is my DocBook to reST movement on top of Jon's docs-next branch. It > includes: > > * kernel-doc parser & directive > * flat-table directive > * man page builder 'kernel-doc-man' > * the

Re: [GIT PULL] doc: sphinx-4.8 DocBook to reST movement on Jon's docs-next

On Tue, 28 Jun 2016, Markus Heiser wrote: > Hi Jonathan, hi Mauro, > > here is my DocBook to reST movement on top of Jon's docs-next branch. It > includes: > > * kernel-doc parser & directive > * flat-table directive > * man page builder 'kernel-doc-man' > * the kernel-doc-HOWTO > * guides for

Re: [PATCH v1 0/2] Introduce the initify gcc plugin

On Tue, Jun 28 2016, Joe Perches wrote: >> What happens to string deduplication when one string >> is in an init function and the same string is also used >> in a non-init function in the same compilation unit? >> >> foo.c >> >> __init void initfunc(void) >> { >>

Re: [PATCH v1 0/2] Introduce the initify gcc plugin

On Tue, Jun 28 2016, Joe Perches wrote: >> What happens to string deduplication when one string >> is in an init function and the same string is also used >> in a non-init function in the same compilation unit? >> >> foo.c >> >> __init void initfunc(void) >> { >> pr_info("%s: I'm here\n",

Re: [PATCH v2] clk: Provide notifier stubs when !COMMON_CLK

On Tue, Jun 28, 2016 at 10:26:53AM -0700, Stephen Boyd wrote: > On 06/28, Krzysztof Kozlowski wrote: > > The clk notifier symbols are hidden by COMMON_CLK. However on some > > platforms HAVE_CLK might be set while COMMON_CLK not which leads to > > compile test build errors like: > > > > $

Re: [PATCH v2] clk: Provide notifier stubs when !COMMON_CLK

On Tue, Jun 28, 2016 at 10:26:53AM -0700, Stephen Boyd wrote: > On 06/28, Krzysztof Kozlowski wrote: > > The clk notifier symbols are hidden by COMMON_CLK. However on some > > platforms HAVE_CLK might be set while COMMON_CLK not which leads to > > compile test build errors like: > > > > $

Re: [PATCH v4 04/29] x86/cpa: In populate_pgd, don't set the pgd entry until it's populated

On Sun, Jun 26, 2016 at 02:55:26PM -0700, Andy Lutomirski wrote: > This avoids pointless races in which another CPU or task might see a > partially populated global pgd entry. These races should normally > be harmless, but, if another CPU propagates the entry via > vmalloc_fault and then

Re: [PATCH v4 04/29] x86/cpa: In populate_pgd, don't set the pgd entry until it's populated

On Sun, Jun 26, 2016 at 02:55:26PM -0700, Andy Lutomirski wrote: > This avoids pointless races in which another CPU or task might see a > partially populated global pgd entry. These races should normally > be harmless, but, if another CPU propagates the entry via > vmalloc_fault and then

Re: kthread_stop insanity (Re: [[DEBUG] force] 2642458962: BUG: unable to handle kernel paging request at ffffc90000997f18)

On 06/27, Oleg Nesterov wrote: > > On 06/27, Andy Lutomirski wrote: > > > > Want to send a patch? I could do it, but you understand this code > > much better than I do. > > Well, I'll try to do this tomorrow unless you do it. I have cloned luto/linux.git to see if kthread_stop() can pin ->stack

Re: kthread_stop insanity (Re: [[DEBUG] force] 2642458962: BUG: unable to handle kernel paging request at ffffc90000997f18)

On 06/27, Oleg Nesterov wrote: > > On 06/27, Andy Lutomirski wrote: > > > > Want to send a patch? I could do it, but you understand this code > > much better than I do. > > Well, I'll try to do this tomorrow unless you do it. I have cloned luto/linux.git to see if kthread_stop() can pin ->stack

Re: [PATCH] regulator: pwm: Fix regulator ramp delay for continuous mode

On Mon, Jun 27, 2016 at 09:53:11PM -0700, Douglas Anderson wrote: > Note that this patch is atop Boris's recent PWM regulator fixes. If > desired it wouldn't be too hard to write it atop the old code, though > quite honestly anyone using a PWM regulator should probably be using his > new code.

Re: [PATCH] regulator: pwm: Fix regulator ramp delay for continuous mode

On Mon, Jun 27, 2016 at 09:53:11PM -0700, Douglas Anderson wrote: > Note that this patch is atop Boris's recent PWM regulator fixes. If > desired it wouldn't be too hard to write it atop the old code, though > quite honestly anyone using a PWM regulator should probably be using his > new code.

[PATCH v6 0/4] perf: Add APM X-Gene SoC Performance Monitoring Unit driver

In addition to the X-Gene ARM CPU performance monitoring unit (PMU), there are PMU for the SoC system devices such as L3 cache(s), I/O bridge(s), memory controller bridges and memory. These PMU devices are loosely architected to follow the same model as the PMU for ARM cores. Signed-off-by: Tai

[PATCH v6 0/4] perf: Add APM X-Gene SoC Performance Monitoring Unit driver

In addition to the X-Gene ARM CPU performance monitoring unit (PMU), there are PMU for the SoC system devices such as L3 cache(s), I/O bridge(s), memory controller bridges and memory. These PMU devices are loosely architected to follow the same model as the PMU for ARM cores. Signed-off-by: Tai

[PATCH v6 2/4] Documentation: Add documentation for APM X-Gene SoC PMU DTS binding

Signed-off-by: Tai Nguyen Acked-by: Rob Herring --- .../devicetree/bindings/perf/apm-xgene-pmu.txt | 112 + 1 file changed, 112 insertions(+) create mode 100644 Documentation/devicetree/bindings/perf/apm-xgene-pmu.txt diff --git

[PATCH v6 2/4] Documentation: Add documentation for APM X-Gene SoC PMU DTS binding

Signed-off-by: Tai Nguyen Acked-by: Rob Herring --- .../devicetree/bindings/perf/apm-xgene-pmu.txt | 112 + 1 file changed, 112 insertions(+) create mode 100644 Documentation/devicetree/bindings/perf/apm-xgene-pmu.txt diff --git

Re: [PATCH v1 0/2] Introduce the initify gcc plugin

On Tue, 2016-06-28 at 09:35 -0700, Joe Perches wrote: > (adding Mathias Krause who did something similar via macros in 2014) > > https://lkml.org/lkml/2014/6/22/149 > > On Tue, 2016-06-28 at 13:34 +0200, Emese Revfy wrote: > > > > I would like to introduce the initify gcc plugin. The kernel

Re: [PATCH v1 0/2] Introduce the initify gcc plugin

On Tue, 2016-06-28 at 09:35 -0700, Joe Perches wrote: > (adding Mathias Krause who did something similar via macros in 2014) > > https://lkml.org/lkml/2014/6/22/149 > > On Tue, 2016-06-28 at 13:34 +0200, Emese Revfy wrote: > > > > I would like to introduce the initify gcc plugin. The kernel

[PATCH v6 4/4] arm64: dts: apm: Add APM X-Gene SoC PMU DTS entries

Signed-off-by: Tai Nguyen --- arch/arm64/boot/dts/apm/apm-storm.dtsi | 58 ++ 1 file changed, 58 insertions(+) diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi b/arch/arm64/boot/dts/apm/apm-storm.dtsi index fe30f76..62806e0 100644 ---

[PATCH v6 3/4] perf: xgene: Add APM X-Gene SoC Performance Monitoring Unit driver

Signed-off-by: Tai Nguyen --- Documentation/perf/xgene-pmu.txt | 48 ++ drivers/perf/Kconfig |7 + drivers/perf/Makefile|1 + drivers/perf/xgene_pmu.c | 1360 ++ 4 files changed, 1416 insertions(+)

[PATCH v6 4/4] arm64: dts: apm: Add APM X-Gene SoC PMU DTS entries

Signed-off-by: Tai Nguyen --- arch/arm64/boot/dts/apm/apm-storm.dtsi | 58 ++ 1 file changed, 58 insertions(+) diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi b/arch/arm64/boot/dts/apm/apm-storm.dtsi index fe30f76..62806e0 100644 ---

[PATCH v6 3/4] perf: xgene: Add APM X-Gene SoC Performance Monitoring Unit driver

Signed-off-by: Tai Nguyen --- Documentation/perf/xgene-pmu.txt | 48 ++ drivers/perf/Kconfig |7 + drivers/perf/Makefile|1 + drivers/perf/xgene_pmu.c | 1360 ++ 4 files changed, 1416 insertions(+) create mode 100644

[PATCH v6 1/4] MAINTAINERS: Add entry for APM X-Gene SoC PMU driver

Signed-off-by: Tai Nguyen --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4978dc1..3bd4143 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8593,6 +8593,14 @@ L: linux-s...@vger.kernel.org S: Supported F:

[PATCH v6 1/4] MAINTAINERS: Add entry for APM X-Gene SoC PMU driver

Signed-off-by: Tai Nguyen --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4978dc1..3bd4143 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8593,6 +8593,14 @@ L: linux-s...@vger.kernel.org S: Supported F:

Re: [PATCH] regulator: pwm: Fix regulator ramp delay for continuous mode

On Mon, Jun 27, 2016 at 09:53:11PM -0700, Douglas Anderson wrote: > Note also that the upper bound of usleep_range probably shouldn't be a > full 1 ms longer than the lower bound since I've seen plenty of hardware > with a ramp rate of ~5000 uS / uV and for small jumps the total delays > are in

Re: [PATCH] regulator: pwm: Fix regulator ramp delay for continuous mode

On Mon, Jun 27, 2016 at 09:53:11PM -0700, Douglas Anderson wrote: > Note also that the upper bound of usleep_range probably shouldn't be a > full 1 ms longer than the lower bound since I've seen plenty of hardware > with a ramp rate of ~5000 uS / uV and for small jumps the total delays > are in

[PATCH] Drivers: block: fixed a code style issue

Fixed the most wanrings in the file --- drivers/block/loop.c | 32 +--- 1 file changed, 17 insertions(+), 15 deletions(-) diff --git a/drivers/block/loop.c b/drivers/block/loop.c index 1fa8cc2..943ad45 100644 --- a/drivers/block/loop.c +++ b/drivers/block/loop.c @@

[PATCH] Drivers: block: fixed a code style issue

Fixed the most wanrings in the file --- drivers/block/loop.c | 32 +--- 1 file changed, 17 insertions(+), 15 deletions(-) diff --git a/drivers/block/loop.c b/drivers/block/loop.c index 1fa8cc2..943ad45 100644 --- a/drivers/block/loop.c +++ b/drivers/block/loop.c @@

Re: [PATCH] KVM: vmx: fix underflow in TSC deadline calculation

On Tue, 28 Jun 2016 13:56:38 -0400 (EDT) Paolo Bonzini wrote: > > > > > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c > > > index fdc05ae..b15e32a 100644 > > > --- a/arch/x86/kvm/lapic.c > > > +++ b/arch/x86/kvm/lapic.c > > > @@ -1454,11 +1454,18 @@ static void

Re: [PATCH] KVM: vmx: fix underflow in TSC deadline calculation

On Tue, 28 Jun 2016 13:56:38 -0400 (EDT) Paolo Bonzini wrote: > > > > > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c > > > index fdc05ae..b15e32a 100644 > > > --- a/arch/x86/kvm/lapic.c > > > +++ b/arch/x86/kvm/lapic.c > > > @@ -1454,11 +1454,18 @@ static void

Re: [PATCH v2 3/3] drivers core: allow id match override when manually binding driver

On Tue, Jun 28, 2016 at 06:24:58PM +0200, Michal Suchanek wrote: > No, no, no! > This is NOT about loading an overlay. This is about talking on the bus > without loading an overlay. This is the solution you want to adopt because you've decided that it's what you want. You've said this quite a

Re: [PATCH v2 3/3] drivers core: allow id match override when manually binding driver

On Tue, Jun 28, 2016 at 06:24:58PM +0200, Michal Suchanek wrote: > No, no, no! > This is NOT about loading an overlay. This is about talking on the bus > without loading an overlay. This is the solution you want to adopt because you've decided that it's what you want. You've said this quite a

Re: [PATCH v4] power_supply: power_supply_read_temp only if use_cnt > 0

Hi, On Thu, Jun 23, 2016 at 01:43:47PM -0400, Rhyland Klein wrote: > On 6/22/2016 10:23 AM, Sebastian Reichel wrote: > Is this also going to go into linux-next? https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=02184c60eba8491ea574cd17b8ba766c86d468f2 -- Sebastian

Re: [PATCH v4] power_supply: power_supply_read_temp only if use_cnt > 0

Hi, On Thu, Jun 23, 2016 at 01:43:47PM -0400, Rhyland Klein wrote: > On 6/22/2016 10:23 AM, Sebastian Reichel wrote: > Is this also going to go into linux-next? https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=02184c60eba8491ea574cd17b8ba766c86d468f2 -- Sebastian

Re: [RESEND][PATCH 2/2] arm64: dts: hi6220: Add pl031 RTC support

Hi John, On 23/06/2016 21:39, John Stultz wrote: > From: Zhangfei Gao > > Add pl031 rtc0 and rtc1 support to hi6220 dtsi > > Cc: Michael Turquette > Cc: Stephen Boyd > Cc: Rob Herring > Cc: Pawel

Re: [RESEND][PATCH 2/2] arm64: dts: hi6220: Add pl031 RTC support

Hi John, On 23/06/2016 21:39, John Stultz wrote: > From: Zhangfei Gao > > Add pl031 rtc0 and rtc1 support to hi6220 dtsi > > Cc: Michael Turquette > Cc: Stephen Boyd > Cc: Rob Herring > Cc: Pawel Moll > Cc: Wei Xu > Cc: Guodong Xu > Signed-off-by: Zhangfei Gao > [jstultz: Forward ported

Re: [PATCH v5 0/7] max8903: Add device tree support and misc fixes

Hi Chris, On Fri, Jun 24, 2016 at 12:26:05PM +1000, Chris Lapa wrote: > This patch set adds device tree support for the MAX8903 battery charger. > It also cleans up logic with dc_valid, dok and dcm pins as well as > fixing up validity checking of gpios. > > I verified these patches work on a

Re: [PATCH v5 0/7] max8903: Add device tree support and misc fixes

Hi Chris, On Fri, Jun 24, 2016 at 12:26:05PM +1000, Chris Lapa wrote: > This patch set adds device tree support for the MAX8903 battery charger. > It also cleans up logic with dc_valid, dok and dcm pins as well as > fixing up validity checking of gpios. > > I verified these patches work on a

[PATCHv3 0/2] libfs,xenfs: replace /proc/xen/xenbus with a symlink

Using /proc/xen/xenbus can cause deadlocks on the atomic file position mutex since this file should behave like a character device and not a regular file. This is easiest to achive by making it a symlink to the existing /dev/xen/xenbus device. This requires extending simple_fill_super() to add

[PATCHv3 0/2] libfs,xenfs: replace /proc/xen/xenbus with a symlink

Using /proc/xen/xenbus can cause deadlocks on the atomic file position mutex since this file should behave like a character device and not a regular file. This is easiest to achive by making it a symlink to the existing /dev/xen/xenbus device. This requires extending simple_fill_super() to add

Re: [PATCH v2] drm: bridge/dw-hdmi: Add support for DWC Phy

On Tue, Jun 28, 2016 at 04:44:12PM +0100, Jose Abreu wrote: > This patch adds support for the Synopsys HDMI TX Phy in > bridge dw-hdmi. > > The init flow is the same as the Rockchip Phy so we > only need to add one define and one if statement. > > Also, the audio infoframe was fixed to sampling

Re: [PATCH v2] drm: bridge/dw-hdmi: Add support for DWC Phy

On Tue, Jun 28, 2016 at 04:44:12PM +0100, Jose Abreu wrote: > This patch adds support for the Synopsys HDMI TX Phy in > bridge dw-hdmi. > > The init flow is the same as the Rockchip Phy so we > only need to add one define and one if statement. > > Also, the audio infoframe was fixed to sampling

[PATCHv3 2/2] xenfs: replace xenbus and privcmd with symlinks

/proc/xen/xenbus does not work correctly. A read blocked waiting for a xenstore message holds the mutex needed for atomic file position updates. This blocks any writes on the same file handle, which can deadlock if the write is needed to unblock the read. /proc/xen/xenbus is supposed to be

[GIT PULL] libata fixes for v4.7-rc5

Hello, Linus. Two trivial fixes - one for a bug in the allocation failure path and the other a compiler warning fix. Thanks. The following changes since commit db06d759d6cf903aeda8c107fd3abd366dd80200: Merge branch 'for-4.7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu

[PATCHv3 2/2] xenfs: replace xenbus and privcmd with symlinks

/proc/xen/xenbus does not work correctly. A read blocked waiting for a xenstore message holds the mutex needed for atomic file position updates. This blocks any writes on the same file handle, which can deadlock if the write is needed to unblock the read. /proc/xen/xenbus is supposed to be

[GIT PULL] libata fixes for v4.7-rc5

Hello, Linus. Two trivial fixes - one for a bug in the allocation failure path and the other a compiler warning fix. Thanks. The following changes since commit db06d759d6cf903aeda8c107fd3abd366dd80200: Merge branch 'for-4.7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu

[PATCHv3 1/2] libfs: allow simple_fill_super() to add symlinks

simple_fill_super() will add symlinks if an entry has mode & S_IFLNK. The target is provided in the new "link" field. Signed-off-by: David Vrabel --- v2: - simplified. --- fs/libfs.c | 15 +-- include/linux/fs.h | 2 +- 2 files changed, 14

[PATCHv3 1/2] libfs: allow simple_fill_super() to add symlinks

simple_fill_super() will add symlinks if an entry has mode & S_IFLNK. The target is provided in the new "link" field. Signed-off-by: David Vrabel --- v2: - simplified. --- fs/libfs.c | 15 +-- include/linux/fs.h | 2 +- 2 files changed, 14 insertions(+), 3 deletions(-)

Re: [PATCH v4 3/4] perf: xgene: Add APM X-Gene SoC Performance Monitoring Unit driver

Hi Mark, On Tue, Jun 28, 2016 at 9:59 AM, Mark Rutland wrote: > On Tue, Jun 28, 2016 at 09:39:36AM -0700, Tai Tri Nguyen wrote: >> Hi Mark, >> >> On Tue, Jun 28, 2016 at 7:14 AM, Mark Rutland wrote: >> > On Tue, Jun 28, 2016 at 02:21:38PM +0100, Marc

Re: [PATCH v4 3/4] perf: xgene: Add APM X-Gene SoC Performance Monitoring Unit driver

Hi Mark, On Tue, Jun 28, 2016 at 9:59 AM, Mark Rutland wrote: > On Tue, Jun 28, 2016 at 09:39:36AM -0700, Tai Tri Nguyen wrote: >> Hi Mark, >> >> On Tue, Jun 28, 2016 at 7:14 AM, Mark Rutland wrote: >> > On Tue, Jun 28, 2016 at 02:21:38PM +0100, Marc Zyngier wrote: >> >> On 28/06/16 12:13, Mark

Re: [PATCH] clk: qcom: Remove gcc_aggre1_pnoc_ahb_clk from msm8996

On 06/21, Stephen Boyd wrote: > This clk is critical to operation of the SoC and should never be > turned off. Furthermore, there are no consumers of this clk so > let's just delete it so things like eMMC work. > > Reported-by: Srinivas Kandagatla > Signed-off-by:

Re: [PATCH] clk: qcom: Remove gcc_aggre1_pnoc_ahb_clk from msm8996

On 06/21, Stephen Boyd wrote: > This clk is critical to operation of the SoC and should never be > turned off. Furthermore, there are no consumers of this clk so > let's just delete it so things like eMMC work. > > Reported-by: Srinivas Kandagatla > Signed-off-by: Stephen Boyd > --- Applied to

Re: [PATCH v3 1/2] clk: fixed-factor: Convert into a module platform driver

On 06/21, Ricardo Ribalda Delgado wrote: > @@ -145,23 +146,24 @@ EXPORT_SYMBOL_GPL(clk_hw_unregister_fixed_factor); > /** > * of_fixed_factor_clk_setup() - Setup function for simple fixed factor clock > */ > -void __init of_fixed_factor_clk_setup(struct device_node *node) > +struct clk

Re: [PATCH v3 1/2] clk: fixed-factor: Convert into a module platform driver

On 06/21, Ricardo Ribalda Delgado wrote: > @@ -145,23 +146,24 @@ EXPORT_SYMBOL_GPL(clk_hw_unregister_fixed_factor); > /** > * of_fixed_factor_clk_setup() - Setup function for simple fixed factor clock > */ > -void __init of_fixed_factor_clk_setup(struct device_node *node) > +struct clk

Re: [PATCH 23/23] [AARCH64] Take utmp{,x}.h from s390 port

On Tue, Jun 28, 2016 at 05:18:04PM +, Joseph Myers wrote: > On Tue, 28 Jun 2016, Yury Norov wrote: > > > aarch64 and ilp32 has different size of time_t. So to have common > > layout for struct utmp and utmpx, corresponding headers are taken > > from s390 port. > > You can't #include

Re: [PATCH 23/23] [AARCH64] Take utmp{,x}.h from s390 port

On Tue, Jun 28, 2016 at 05:18:04PM +, Joseph Myers wrote: > On Tue, 28 Jun 2016, Yury Norov wrote: > > > aarch64 and ilp32 has different size of time_t. So to have common > > layout for struct utmp and utmpx, corresponding headers are taken > > from s390 port. > > You can't #include

Re: [RESEND PATCH] x86/mm: only allow memmap=XX!YY over existing RAM

On 06/28/16 09:33, Dan Williams wrote: > On Tue, Jun 28, 2016 at 1:31 AM, Yigal Korman wrote: >> Before this patch, passing a range that is beyond the physical memory >> range will succeed, the user will see a /dev/pmem0 and will be able to >> access it. Reads will always

Re: [RESEND PATCH] x86/mm: only allow memmap=XX!YY over existing RAM

On 06/28/16 09:33, Dan Williams wrote: > On Tue, Jun 28, 2016 at 1:31 AM, Yigal Korman wrote: >> Before this patch, passing a range that is beyond the physical memory >> range will succeed, the user will see a /dev/pmem0 and will be able to >> access it. Reads will always return 0 and writes will

Re: [PATCH] KVM: vmx: fix underflow in TSC deadline calculation

> > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c > > index fdc05ae..b15e32a 100644 > > --- a/arch/x86/kvm/lapic.c > > +++ b/arch/x86/kvm/lapic.c > > @@ -1454,11 +1454,18 @@ static void start_apic_timer(struct kvm_lapic > > *apic) /* lapic timer in tsc deadline mode */ > >

Re: [PATCH] KVM: vmx: fix underflow in TSC deadline calculation

> > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c > > index fdc05ae..b15e32a 100644 > > --- a/arch/x86/kvm/lapic.c > > +++ b/arch/x86/kvm/lapic.c > > @@ -1454,11 +1454,18 @@ static void start_apic_timer(struct kvm_lapic > > *apic) /* lapic timer in tsc deadline mode */ > >

Re: [PATCH] drm/exynos: Remove deprecated create_singlethread_workqueue

Please ignore this mail. On Tue, Jun 28, 2016 at 10:48 PM, Bhaktipriya Shridhar wrote: > The workqueue g2d_workq has only a single workitem(>runqueue_work) > and hence doesn't require ordering. Also, it is not being used on a > memory reclaim path. Hence, the

Re: [PATCH] drm/exynos: Remove deprecated create_singlethread_workqueue

Please ignore this mail. On Tue, Jun 28, 2016 at 10:48 PM, Bhaktipriya Shridhar wrote: > The workqueue g2d_workq has only a single workitem(>runqueue_work) > and hence doesn't require ordering. Also, it is not being used on a > memory reclaim path. Hence, the singlethreaded workqueue has been

Re: [PATCH 2/2] ipc/sem: sem_lock with hysteresis

On Sat, 25 Jun 2016, Manfred Spraul wrote: - Only simple ops: patch has no impact (the first 10 semops do not matter) Agreed. - sleeping complex ops: patch has no impact, we are always in complex mode - not sleeping complex ops: depends on the size of the array. With a 4.000 semaphore

Re: [PATCH 2/2] ipc/sem: sem_lock with hysteresis

On Sat, 25 Jun 2016, Manfred Spraul wrote: - Only simple ops: patch has no impact (the first 10 semops do not matter) Agreed. - sleeping complex ops: patch has no impact, we are always in complex mode - not sleeping complex ops: depends on the size of the array. With a 4.000 semaphore

Re: [BUG] perf test 29 crashing

On 6/28/16 10:59 AM, Arnaldo Carvalho de Melo wrote: Em Tue, Jun 28, 2016 at 02:34:10PM +0200, Jiri Olsa escreveu: hi, I'm having test 29 crashing on latest Arnaldo's perf/core: [jolsa@krava perf]$ ./perf test hist 15: Test matching and linking multiple hists : Ok 25: Test

Re: [BUG] perf test 29 crashing

On 6/28/16 10:59 AM, Arnaldo Carvalho de Melo wrote: Em Tue, Jun 28, 2016 at 02:34:10PM +0200, Jiri Olsa escreveu: hi, I'm having test 29 crashing on latest Arnaldo's perf/core: [jolsa@krava perf]$ ./perf test hist 15: Test matching and linking multiple hists : Ok 25: Test

Re: [PATCH] KVM: vmx: fix underflow in TSC deadline calculation

On Tue, 28 Jun 2016 14:54:19 +0800 Wanpeng Li wrote: > INFO: rcu_sched detected stalls on CPUs/tasks: > 1-...: (11800 GPs behind) idle=45d/140/0 softirq=0/0 > fqs=21663 (detected by 0, t=65016 jiffies, g=11500, c=11499, q=719) > Task dump for CPU 1: >

Re: [PATCH] KVM: vmx: fix underflow in TSC deadline calculation

On Tue, 28 Jun 2016 14:54:19 +0800 Wanpeng Li wrote: > INFO: rcu_sched detected stalls on CPUs/tasks: > 1-...: (11800 GPs behind) idle=45d/140/0 softirq=0/0 > fqs=21663 (detected by 0, t=65016 jiffies, g=11500, c=11499, q=719) > Task dump for CPU 1: > qemu-system-x86 R running task

Re: [PATCH 0/2] fujitsu-laptop: Debugging cleanup

On Thu, Jun 23, 2016 at 08:05:35PM +0930, Jonathan Woithe wrote: > On Thu, Jun 23, 2016 at 12:02:46PM +0200, Micha?? K??pie?? wrote: > > vdbg_printk() was introduced by 20b9373, which is the same commit that > > adds FUJ02E3 support, so it has been the way it is now from the start. > > This patch

Re: [PATCH v3] fujitsu-laptop: Support touchpad toggle hotkey on Skylake-based models

On Tue, Jun 28, 2016 at 08:49:22PM +0930, Jonathan Woithe wrote: > On Tue, Jun 28, 2016 at 09:25:50AM +0200, Micha?? K??pie?? wrote: > > Haswell-based Fujitsu laptops (Lifebook E734/E744/E754) have a touchpad > > toggle hotkey (Fn+F4) which is handled transparently to the operating > > system:

Re: [PATCH 0/2] fujitsu-laptop: Debugging cleanup

On Thu, Jun 23, 2016 at 08:05:35PM +0930, Jonathan Woithe wrote: > On Thu, Jun 23, 2016 at 12:02:46PM +0200, Micha?? K??pie?? wrote: > > vdbg_printk() was introduced by 20b9373, which is the same commit that > > adds FUJ02E3 support, so it has been the way it is now from the start. > > This patch

Re: [PATCH v3] fujitsu-laptop: Support touchpad toggle hotkey on Skylake-based models

On Tue, Jun 28, 2016 at 08:49:22PM +0930, Jonathan Woithe wrote: > On Tue, Jun 28, 2016 at 09:25:50AM +0200, Micha?? K??pie?? wrote: > > Haswell-based Fujitsu laptops (Lifebook E734/E744/E754) have a touchpad > > toggle hotkey (Fn+F4) which is handled transparently to the operating > > system:

Re: [PATCH 01/23] [AARCH64] define word size for lp64 and ilp32

On Tue, 28 Jun 2016, Joseph Myers wrote: > On Tue, 28 Jun 2016, Yury Norov wrote: > > > diff --git a/sysdeps/aarch64/bits/wordsize.h > > b/sysdeps/aarch64/bits/wordsize.h > > See what I said in > about "make > other bits/wordsize.h

Re: [PATCH 01/23] [AARCH64] define word size for lp64 and ilp32

On Tue, 28 Jun 2016, Joseph Myers wrote: > On Tue, 28 Jun 2016, Yury Norov wrote: > > > diff --git a/sysdeps/aarch64/bits/wordsize.h > > b/sysdeps/aarch64/bits/wordsize.h > > See what I said in > about "make > other bits/wordsize.h

Re: [PATCH] drm/omap: panel-dsi-cm: Remove deprecated create_singlethread_workqueue

Please ignore this mail. Thanks, Bhaktipriya On Tue, Jun 28, 2016 at 10:53 PM, Bhaktipriya Shridhar wrote: > The workqueue "workqueue" has only a single workitem(>ulps_work) per > panel_drv_data and hence doesn't require ordering. > Also, it is not being used on a

Re: [PATCH] drm/exynos: Remove deprecated create_singlethread_workqueue

Please ignore this mail. Thanks, Bhaktipriya On Tue, Jun 28, 2016 at 10:48 PM, Bhaktipriya Shridhar wrote: > The workqueue g2d_workq has only a single workitem(>runqueue_work) > and hence doesn't require ordering. Also, it is not being used on a > memory reclaim path.

Re: [PATCH] drm/omap: panel-dsi-cm: Remove deprecated create_singlethread_workqueue

Please ignore this mail. Thanks, Bhaktipriya On Tue, Jun 28, 2016 at 10:53 PM, Bhaktipriya Shridhar wrote: > The workqueue "workqueue" has only a single workitem(>ulps_work) per > panel_drv_data and hence doesn't require ordering. > Also, it is not being used on a memory reclaim path. Hence,

Re: [PATCH] drm/exynos: Remove deprecated create_singlethread_workqueue

Please ignore this mail. Thanks, Bhaktipriya On Tue, Jun 28, 2016 at 10:48 PM, Bhaktipriya Shridhar wrote: > The workqueue g2d_workq has only a single workitem(>runqueue_work) > and hence doesn't require ordering. Also, it is not being used on a > memory reclaim path. Hence, the singlethreaded

Re: [PATCH] drm/radeon: Remove deprecated create_singlethread_workqueue

Please ignore this mail. Thanks, Bhaktipriya On Tue, Jun 28, 2016 at 10:56 PM, Bhaktipriya Shridhar wrote: > alloc_workqueue replaces deprecated create_singlethread_workqueue(). > > A dedicated workqueue has been used since work items need to be flushed > as a group

Re: [PATCH] drm/radeon: Remove deprecated create_singlethread_workqueue

Please ignore this mail. Thanks, Bhaktipriya On Tue, Jun 28, 2016 at 10:56 PM, Bhaktipriya Shridhar wrote: > alloc_workqueue replaces deprecated create_singlethread_workqueue(). > > A dedicated workqueue has been used since work items need to be flushed > as a group rather than individually. >

Re: [PATCH v2 10/11] clk: Show CRITICAL clks in clk_summary output

On 06/22, Rhyland Klein wrote: > On 6/22/2016 8:24 AM, Thierry Reding wrote: > > > > Maybe output " " instead of "" for CLK_IS_CRITICAL, that way you can > > omit the second conditional. > > > > I wonder if it might be easier to read if this flag was at the end of > > the line. There's also the

Re: [PATCH v2 10/11] clk: Show CRITICAL clks in clk_summary output

On 06/22, Rhyland Klein wrote: > On 6/22/2016 8:24 AM, Thierry Reding wrote: > > > > Maybe output " " instead of "" for CLK_IS_CRITICAL, that way you can > > omit the second conditional. > > > > I wonder if it might be easier to read if this flag was at the end of > > the line. There's also the

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