Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On 06/29/2017 04:42 PM, Dan Williams wrote: > On Thu, Jun 29, 2017 at 12:20 PM, Linda Knippers > wrote: >> On 06/29/2017 01:54 PM, Dan Williams wrote: >>> Allow volatile nfit ranges to participate in all the same infrastructure >>> provided for persistent memory regions.

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On 06/29/2017 04:42 PM, Dan Williams wrote: > On Thu, Jun 29, 2017 at 12:20 PM, Linda Knippers > wrote: >> On 06/29/2017 01:54 PM, Dan Williams wrote: >>> Allow volatile nfit ranges to participate in all the same infrastructure >>> provided for persistent memory regions. >> >> This seems to be a

Re: [PATCH v3 7/7] acpi, nfit: override mask

On Thu, Jun 29, 2017 at 9:56 AM, Jerry Hoemann wrote: > Have module parameter override_dsm_mask override the dsm_mask for > root calls like it does for non-root dsm calls. > > Signed-off-by: Jerry Hoemann > --- > drivers/acpi/nfit/core.c | 7 ++-

Re: [PATCH v3 7/7] acpi, nfit: override mask

On Thu, Jun 29, 2017 at 9:56 AM, Jerry Hoemann wrote: > Have module parameter override_dsm_mask override the dsm_mask for > root calls like it does for non-root dsm calls. > > Signed-off-by: Jerry Hoemann > --- > drivers/acpi/nfit/core.c | 7 ++- > 1 file changed, 6 insertions(+), 1

Re: [PATCH 3/3] dts: RISC-V PLIC documentation

On Mon, Jun 26, 2017 at 10:21:24PM -0700, Palmer Dabbelt wrote: > This patch adds documentation for the platform-level interrupt > controller (PLIC) found in all RISC-V systems. This interrupt > controller routes interrupts from all the devices in the system to each > hart-local interrupt

Re: [PATCH 3/3] dts: RISC-V PLIC documentation

On Mon, Jun 26, 2017 at 10:21:24PM -0700, Palmer Dabbelt wrote: > This patch adds documentation for the platform-level interrupt > controller (PLIC) found in all RISC-V systems. This interrupt > controller routes interrupts from all the devices in the system to each > hart-local interrupt

Re: [PATCH v2 6/8] x86/entry: add unwind hint annotations

On Thu, Jun 29, 2017 at 12:05 PM, Josh Poimboeuf wrote: > On Thu, Jun 29, 2017 at 11:50:18AM -0700, Andy Lutomirski wrote: >> On Thu, Jun 29, 2017 at 10:53 AM, Josh Poimboeuf wrote: >> > There's a bug here that will need a small change to the entry code.

Re: [RESEND PATCH] drm/hisilicon: Ensure LDI regs are properly configured.

On Thu, Jun 29, 2017 at 1:54 PM, Peter Griffin wrote: > This patch fixes the following soft lockup: > BUG: soft lockup - CPU#0 stuck for 23s! [weston:307] > > On weston idle-timeout the IP is powered down and reset > asserted. On weston resume we get a massive vblank >

Re: [PATCH v2 6/8] x86/entry: add unwind hint annotations

On Thu, Jun 29, 2017 at 12:05 PM, Josh Poimboeuf wrote: > On Thu, Jun 29, 2017 at 11:50:18AM -0700, Andy Lutomirski wrote: >> On Thu, Jun 29, 2017 at 10:53 AM, Josh Poimboeuf wrote: >> > There's a bug here that will need a small change to the entry code. >> > >> > Mike Galbraith reported: >> >

Re: [RESEND PATCH] drm/hisilicon: Ensure LDI regs are properly configured.

On Thu, Jun 29, 2017 at 1:54 PM, Peter Griffin wrote: > This patch fixes the following soft lockup: > BUG: soft lockup - CPU#0 stuck for 23s! [weston:307] > > On weston idle-timeout the IP is powered down and reset > asserted. On weston resume we get a massive vblank > IRQ storm due to the LDI

Re: [PATCH] ARM: dts: BCM5301X: Add support for Linksys EA9500

Florian, >> I have managed to use DSA driver and was able detect both internal and >> external switches. However, I only get packets flowing only through the >> internal switch. I have used the ip & bridge commands to setup the vlan >> 101 & 102 for lan and wan respectively. >> >> VLAN101 = lan1

Re: [PATCH] ARM: dts: BCM5301X: Add support for Linksys EA9500

Florian, >> I have managed to use DSA driver and was able detect both internal and >> external switches. However, I only get packets flowing only through the >> internal switch. I have used the ip & bridge commands to setup the vlan >> 101 & 102 for lan and wan respectively. >> >> VLAN101 = lan1

Re: [PATCH] spmi: Include OF based modalias in device uevent

On 06/28, Bjorn Andersson wrote: > Include the OF-based modalias in the uevent sent when registering SPMI > devices, so that user space has a chance to autoload the kernel module > for the device. > > Reported-by: Rob Clark > Signed-off-by: Bjorn Andersson

Re: [PATCH] spmi: Include OF based modalias in device uevent

On 06/28, Bjorn Andersson wrote: > Include the OF-based modalias in the uevent sent when registering SPMI > devices, so that user space has a chance to autoload the kernel module > for the device. > > Reported-by: Rob Clark > Signed-off-by: Bjorn Andersson > --- Reviewed-by: Stephen Boyd I

Re: linux-next: manual merge of the akpm-current tree with the random tree

On Wed, 28 Jun 2017 16:03:48 +1000 Stephen Rothwell wrote: > Hi Andrew, > > [Yes, top posting :-)] > > With the merge window approaching, just a reminder that this conflict > still exists. huh, it was only a teeny thing. I moved

Re: linux-next: manual merge of the akpm-current tree with the random tree

On Wed, 28 Jun 2017 16:03:48 +1000 Stephen Rothwell wrote: > Hi Andrew, > > [Yes, top posting :-)] > > With the merge window approaching, just a reminder that this conflict > still exists. huh, it was only a teeny thing. I moved

Re: [RFC 0/5] drivers: Add boot constraints core

On 06/29, Russell King - ARM Linux wrote: > On Thu, Jun 29, 2017 at 08:28:08PM +0530, Viresh Kumar wrote: > > On 29-06-17, 13:49, Russell King - ARM Linux wrote: > > > The thing that concerns me most about this is that typically the LCD > > > controller will be performing DMA to system RAM. > > >

Re: [RFC 0/5] drivers: Add boot constraints core

On 06/29, Russell King - ARM Linux wrote: > On Thu, Jun 29, 2017 at 08:28:08PM +0530, Viresh Kumar wrote: > > On 29-06-17, 13:49, Russell King - ARM Linux wrote: > > > The thing that concerns me most about this is that typically the LCD > > > controller will be performing DMA to system RAM. > > >

Re: [PATCH] cpuidle: menu: allow state 0 to be disabled

On Mon, Jun 26, 2017 at 7:38 AM, Nicholas Piggin wrote: > The menu driver does not allow state0 to be disabled completely. > If it is disabled but other enabled states don't meet latency > requirements, it is still used. > > Fix this by starting with the first enabled idle

Re: [PATCH 2/4] swait: add the missing killable swaits

On Thu, Jun 29, 2017 at 12:40 PM, Luis R. Rodriguez wrote: > On Thu, Jun 29, 2017 at 11:59:29AM -0700, Linus Torvalds wrote: >> > at a time... I'm probably missing your point here. >> >> The *reason* they wake up only one seems to be that there really is >> just one. It's some

Re: [PATCH] cpuidle: menu: allow state 0 to be disabled

On Mon, Jun 26, 2017 at 7:38 AM, Nicholas Piggin wrote: > The menu driver does not allow state0 to be disabled completely. > If it is disabled but other enabled states don't meet latency > requirements, it is still used. > > Fix this by starting with the first enabled idle state. Fall back > to

Re: [PATCH 2/4] swait: add the missing killable swaits

On Thu, Jun 29, 2017 at 12:40 PM, Luis R. Rodriguez wrote: > On Thu, Jun 29, 2017 at 11:59:29AM -0700, Linus Torvalds wrote: >> > at a time... I'm probably missing your point here. >> >> The *reason* they wake up only one seems to be that there really is >> just one. It's some per-cpu idle thread

Re: [PATCH 2/4] swait: add the missing killable swaits

On Thu, 29 Jun 2017 21:44:55 +0200, Luis R. Rodriguez wrote: > On Thu, Jun 29, 2017 at 09:40:15PM +0200, Luis R. Rodriguez wrote: > > On Thu, Jun 29, 2017 at 11:59:29AM -0700, Linus Torvalds wrote: > > > On Thu, Jun 29, 2017 at 11:33 AM, Davidlohr Bueso > > > wrote: > > >

Re: [PATCH 2/4] swait: add the missing killable swaits

On Thu, 29 Jun 2017 21:44:55 +0200, Luis R. Rodriguez wrote: > On Thu, Jun 29, 2017 at 09:40:15PM +0200, Luis R. Rodriguez wrote: > > On Thu, Jun 29, 2017 at 11:59:29AM -0700, Linus Torvalds wrote: > > > On Thu, Jun 29, 2017 at 11:33 AM, Davidlohr Bueso > > > wrote: > > > > On Thu, 29 Jun

[RESEND PATCH] drm/hisilicon: Ensure LDI regs are properly configured.

This patch fixes the following soft lockup: BUG: soft lockup - CPU#0 stuck for 23s! [weston:307] On weston idle-timeout the IP is powered down and reset asserted. On weston resume we get a massive vblank IRQ storm due to the LDI registers having lost some state. This state loss is caused by

[RESEND PATCH] drm/hisilicon: Ensure LDI regs are properly configured.

This patch fixes the following soft lockup: BUG: soft lockup - CPU#0 stuck for 23s! [weston:307] On weston idle-timeout the IP is powered down and reset asserted. On weston resume we get a massive vblank IRQ storm due to the LDI registers having lost some state. This state loss is caused by

Re: [PATCH 2/3] arm64: dts: rockchip: Use vctrl regulators for dynamic CPU voltages on Gru/Kevin

Hi Heiko, On Wed, Jun 28, 2017 at 05:44:27PM +0200, Heiko Stuebner wrote: > Am Freitag, 23. Juni 2017, 10:07:36 CEST schrieb Brian Norris: > > From: Matthias Kaehlcke > > > > The Gru device tree currently contains entries for the regulators > > ppvar_bigcpu, ppvar_litcpu,

Re: [PATCH 2/3] arm64: dts: rockchip: Use vctrl regulators for dynamic CPU voltages on Gru/Kevin

Hi Heiko, On Wed, Jun 28, 2017 at 05:44:27PM +0200, Heiko Stuebner wrote: > Am Freitag, 23. Juni 2017, 10:07:36 CEST schrieb Brian Norris: > > From: Matthias Kaehlcke > > > > The Gru device tree currently contains entries for the regulators > > ppvar_bigcpu, ppvar_litcpu, ppvar_gpu and

[PATCH v3 1/4] firmware: fix batched requests - wake all waiters

The firmware cache mechanism serves two purposes, the secondary purpose is not well documented nor understood. This fixes a regression with the secondary purpose of the firmware cache mechanism: batched requests. The firmware cache is used for: 1) Addressing races with file lookups during the

[PATCH v3 1/4] firmware: fix batched requests - wake all waiters

The firmware cache mechanism serves two purposes, the secondary purpose is not well documented nor understood. This fixes a regression with the secondary purpose of the firmware cache mechanism: batched requests. The firmware cache is used for: 1) Addressing races with file lookups during the

[PATCH v3 2/4] test_firmware: add test case for SIGCHLD on sync fallback

It has been reported that SIGCHLD will trigger an immediate abort on sync firmware requests which rely on the sysfs interface for a trigger. This is unexpected behaviour, this reproduces this issue. This test case currenty fails. Reported-by: Martin Fuzzey Signed-off-by:

[PATCH v3 4/4] firmware: send -EINTR on signal abort on fallback mechanism

Right now we send -EAGAIN to a syfs write which got interrupted. Userspace can't tell what happened though, send -EINTR if we were killed due to a signal so userspace can tell things apart. This is only applicable to the fallback mechanism. Reported-by: Martin Fuzzey

[PATCH v3 3/4] firmware: avoid invalid fallback aborts by using killable wait

Commit 0cb64249ca500 ("firmware_loader: abort request if wait_for_completion is interrupted") added via 4.0 added support to abort the fallback mechanism when a signal was detected and wait_for_completion_interruptible() returned -ERESTARTSYS -- for instance when a user hits CTRL-C. The abort was

[PATCH v3 2/4] test_firmware: add test case for SIGCHLD on sync fallback

It has been reported that SIGCHLD will trigger an immediate abort on sync firmware requests which rely on the sysfs interface for a trigger. This is unexpected behaviour, this reproduces this issue. This test case currenty fails. Reported-by: Martin Fuzzey Signed-off-by: Luis R. Rodriguez ---

[PATCH v3 4/4] firmware: send -EINTR on signal abort on fallback mechanism

Right now we send -EAGAIN to a syfs write which got interrupted. Userspace can't tell what happened though, send -EINTR if we were killed due to a signal so userspace can tell things apart. This is only applicable to the fallback mechanism. Reported-by: Martin Fuzzey Signed-off-by: Luis R.

[PATCH v3 3/4] firmware: avoid invalid fallback aborts by using killable wait

Commit 0cb64249ca500 ("firmware_loader: abort request if wait_for_completion is interrupted") added via 4.0 added support to abort the fallback mechanism when a signal was detected and wait_for_completion_interruptible() returned -ERESTARTSYS -- for instance when a user hits CTRL-C. The abort was

[PATCH v3 0/4] firmware: few pending fixes

as you have suggested. These changes are available on my branch 20170629-fw-fixes-wait-v3 based on linux-next tag next-20170629 [2]. I've also tested applying them on Linus' tree and they apply cleanly there. I've gone ahead and re-tested this series with all the firmware selftests at tools/testing

[PATCH v3 0/4] firmware: few pending fixes

as you have suggested. These changes are available on my branch 20170629-fw-fixes-wait-v3 based on linux-next tag next-20170629 [2]. I've also tested applying them on Linus' tree and they apply cleanly there. I've gone ahead and re-tested this series with all the firmware selftests at tools/testing

Re: [PATCH] thp, mm: Fix crash due race in MADV_FREE handling

On Wed, 28 Jun 2017 13:15:50 +0300 "Kirill A. Shutemov" wrote: > > Signed-off-by: Kirill A. Shutemov > > Reported-by: Reinette Chatre > > Fixes: 9818b8cde622 ("madvise_free, thp: fix madvise_free_huge_pmd return

Re: [PATCH] thp, mm: Fix crash due race in MADV_FREE handling

On Wed, 28 Jun 2017 13:15:50 +0300 "Kirill A. Shutemov" wrote: > > Signed-off-by: Kirill A. Shutemov > > Reported-by: Reinette Chatre > > Fixes: 9818b8cde622 ("madvise_free, thp: fix madvise_free_huge_pmd return > > value after splitting") > > Sorry, the wrong Fixes. The right one: > >

Re: [PATCH] leds: lp55xx: make various arrays static const

Hi! > Thanks for the patch. > > Do you have some profiling results showing the benefit of these changes? > It seems that these functions are called only on driver initialization. > Making the local arrays static will prevent releasing this memory even > though it will be no longer needed. > >

Re: [PATCH] leds: lp55xx: make various arrays static const

Hi! > Thanks for the patch. > > Do you have some profiling results showing the benefit of these changes? > It seems that these functions are called only on driver initialization. > Making the local arrays static will prevent releasing this memory even > though it will be no longer needed. > >

Re: [PATCH] cma: fix calculation of aligned offset

On Wed, 28 Jun 2017 10:07:41 -0700 Doug Berger wrote: > The align_offset parameter is used by bitmap_find_next_zero_area_off() > to represent the offset of map's base from the previous alignment > boundary; the function ensures that the returned index, plus the > align_offset,

Re: [PATCH] cma: fix calculation of aligned offset

On Wed, 28 Jun 2017 10:07:41 -0700 Doug Berger wrote: > The align_offset parameter is used by bitmap_find_next_zero_area_off() > to represent the offset of map's base from the previous alignment > boundary; the function ensures that the returned index, plus the > align_offset, honors the

Re: spin_unlock_wait() in ata_scsi_cmd_error_handler()?

On Thu, Jun 29, 2017 at 04:17:54PM -0400, Tejun Heo wrote: > Hello, > > On Thu, Jun 29, 2017 at 01:14:43PM -0700, Paul E. McKenney wrote: > > On Thu, Jun 29, 2017 at 03:53:22PM -0400, Tejun Heo wrote: > > > Hello, Paul. > > > > > > On Thu, Jun 29, 2017 at 11:10:57AM -0700, Paul E. McKenney

Re: spin_unlock_wait() in ata_scsi_cmd_error_handler()?

On Thu, Jun 29, 2017 at 04:17:54PM -0400, Tejun Heo wrote: > Hello, > > On Thu, Jun 29, 2017 at 01:14:43PM -0700, Paul E. McKenney wrote: > > On Thu, Jun 29, 2017 at 03:53:22PM -0400, Tejun Heo wrote: > > > Hello, Paul. > > > > > > On Thu, Jun 29, 2017 at 11:10:57AM -0700, Paul E. McKenney

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On Thu, Jun 29, 2017 at 12:20 PM, Linda Knippers wrote: > On 06/29/2017 01:54 PM, Dan Williams wrote: >> Allow volatile nfit ranges to participate in all the same infrastructure >> provided for persistent memory regions. > > This seems to be a bit more than "other rework".

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On Thu, Jun 29, 2017 at 12:20 PM, Linda Knippers wrote: > On 06/29/2017 01:54 PM, Dan Williams wrote: >> Allow volatile nfit ranges to participate in all the same infrastructure >> provided for persistent memory regions. > > This seems to be a bit more than "other rework". It's part of the

Re: [1/3] cpuidle: powerpc: cpuidle set polling before enabling irqs

On Thu, Jun 29, 2017 at 2:21 PM, Michael Ellerman wrote: > On Wed, 2017-06-14 at 13:02:39 UTC, Nicholas Piggin wrote: >> local_irq_enable can cause interrupts to be taken which could >> take significant amount of processing time. The idle process >> should set

Re: [1/3] cpuidle: powerpc: cpuidle set polling before enabling irqs

On Thu, Jun 29, 2017 at 2:21 PM, Michael Ellerman wrote: > On Wed, 2017-06-14 at 13:02:39 UTC, Nicholas Piggin wrote: >> local_irq_enable can cause interrupts to be taken which could >> take significant amount of processing time. The idle process >> should set its polling flag before this, so

[tip:x86/mm] x86/ftrace: Exclude functions in head64.c from function-tracing

Commit-ID: bb43dbc5e09d52c6085dfee65f4f923b3fbcd1d4 Gitweb: http://git.kernel.org/tip/bb43dbc5e09d52c6085dfee65f4f923b3fbcd1d4 Author: Kirill A. Shutemov AuthorDate: Tue, 27 Jun 2017 14:59:48 +0300 Committer: Thomas Gleixner

[tip:x86/mm] x86/ftrace: Exclude functions in head64.c from function-tracing

Commit-ID: bb43dbc5e09d52c6085dfee65f4f923b3fbcd1d4 Gitweb: http://git.kernel.org/tip/bb43dbc5e09d52c6085dfee65f4f923b3fbcd1d4 Author: Kirill A. Shutemov AuthorDate: Tue, 27 Jun 2017 14:59:48 +0300 Committer: Thomas Gleixner CommitDate: Thu, 29 Jun 2017 22:33:27 +0200 x86/ftrace:

Re: [PATCH 1/3] dts: RISC-V vendor prefix

On Mon, Jun 26, 2017 at 10:21:22PM -0700, Palmer Dabbelt wrote: > RISC-V systems use device tree to specify the memory layout of the > system. This patch reserves the "riscv" vendor prefix, which will be > used for devices that are specified by the various RISC-V ISA > specifications. > >

Re: [PATCH 1/3] dts: RISC-V vendor prefix

On Mon, Jun 26, 2017 at 10:21:22PM -0700, Palmer Dabbelt wrote: > RISC-V systems use device tree to specify the memory layout of the > system. This patch reserves the "riscv" vendor prefix, which will be > used for devices that are specified by the various RISC-V ISA > specifications. > >

Re: [PATCH] cpufreq: Find transition latency dynamically

On Thu, Jun 29, 2017 at 6:28 AM, Viresh Kumar wrote: > On 02-06-17, 16:59, Viresh Kumar wrote: >> The transition_latency_ns represents the maximum time it can take for >> the hardware to switch from/to any frequency for a CPU. >> >> The transition_latency_ns is used

Re: [PATCH] cpufreq: Find transition latency dynamically

On Thu, Jun 29, 2017 at 6:28 AM, Viresh Kumar wrote: > On 02-06-17, 16:59, Viresh Kumar wrote: >> The transition_latency_ns represents the maximum time it can take for >> the hardware to switch from/to any frequency for a CPU. >> >> The transition_latency_ns is used currently for two purposes: >>

Re: [PATCH 2/4] ARM: aspeed: g5: Add USB functions to pinctrl bindings

On Thu, Jun 29, 2017 at 03:13:24PM -0500, Rob Herring wrote: > On Tue, Jun 27, 2017 at 11:42:12AM +0930, Andrew Jeffery wrote: > > The Aspeed AST2500 SoC contains a number of USB controllers: > > > > * USB 1.1 Host Controller > > * USB 2.0 Host Controller (x2) > > * Combined USB 2.0 Virtual Hub

Re: [PATCH 2/4] ARM: aspeed: g5: Add USB functions to pinctrl bindings

On Thu, Jun 29, 2017 at 03:13:24PM -0500, Rob Herring wrote: > On Tue, Jun 27, 2017 at 11:42:12AM +0930, Andrew Jeffery wrote: > > The Aspeed AST2500 SoC contains a number of USB controllers: > > > > * USB 1.1 Host Controller > > * USB 2.0 Host Controller (x2) > > * Combined USB 2.0 Virtual Hub

Re: [PATCH V2 0/4] sched: cpufreq: Allow remote callbacks

Hi, On Thu, Jun 29, 2017 at 7:26 AM, Viresh Kumar wrote: > Hi, > > Here is the second version of this series. The first [1] version was > sent several months back. > > With Android UI and benchmarks the latency of cpufreq response to > certain scheduling events can

Re: [PATCH V2 0/4] sched: cpufreq: Allow remote callbacks

Hi, On Thu, Jun 29, 2017 at 7:26 AM, Viresh Kumar wrote: > Hi, > > Here is the second version of this series. The first [1] version was > sent several months back. > > With Android UI and benchmarks the latency of cpufreq response to > certain scheduling events can become very critical.

Re: [PATCH 2/3] dts: RISC-V local interrupt controller docs

On Mon, Jun 26, 2017 at 10:21:23PM -0700, Palmer Dabbelt wrote: > This patch adds documentation on the RISC-V local interrupt controller, > which is a per-hart interrupt controller that manages all interrupts > entering a RISC-V hart. This interrupt controller is present on all > RISC-V systems.

Re: [PATCH 2/3] dts: RISC-V local interrupt controller docs

On Mon, Jun 26, 2017 at 10:21:23PM -0700, Palmer Dabbelt wrote: > This patch adds documentation on the RISC-V local interrupt controller, > which is a per-hart interrupt controller that manages all interrupts > entering a RISC-V hart. This interrupt controller is present on all > RISC-V systems.

Re: [PATCH V4 10/12] block: call __bio_free in bio_endio

On Thu, Jun 29, 2017 at 11:35:44AM -0700, Shaohua Li wrote: > > - > > /* Auto-generate integrity metadata if this is a write */ > > if (bio_data_dir(bio) == WRITE) > > bio_integrity_process(bio, bi->profile->generate_fn); > > @@ -370,14 +364,12 @@ static void

Re: [PATCH v2] ACPI: surface3_power: MSHW0011 rev-eng implementation

On Thu, Jun 29, 2017 at 4:22 PM, Andy Shevchenko wrote: > +Cc: Hans (he might give some advice regarding to the below) > > On Thu, Jun 29, 2017 at 3:10 PM, Benjamin Tissoires > wrote: >> MSHW0011 replaces the battery firmware by using

Re: [PATCH V4 10/12] block: call __bio_free in bio_endio

On Thu, Jun 29, 2017 at 11:35:44AM -0700, Shaohua Li wrote: > > - > > /* Auto-generate integrity metadata if this is a write */ > > if (bio_data_dir(bio) == WRITE) > > bio_integrity_process(bio, bi->profile->generate_fn); > > @@ -370,14 +364,12 @@ static void

Re: [PATCH v2] ACPI: surface3_power: MSHW0011 rev-eng implementation

On Thu, Jun 29, 2017 at 4:22 PM, Andy Shevchenko wrote: > +Cc: Hans (he might give some advice regarding to the below) > > On Thu, Jun 29, 2017 at 3:10 PM, Benjamin Tissoires > wrote: >> MSHW0011 replaces the battery firmware by using ACPI operation regions. >> The values have been obtained by

Re: [PATCH] selftests: ftrace: Use md5sum to take less time of checking logs

On 06/28/2017 09:30 AM, Shuah Khan wrote: > On 06/28/2017 08:59 AM, Steven Rostedt wrote: >> On Wed, 28 Jun 2017 08:30:24 -0600 >> Shuah Khan wrote: >> >>> On 06/28/2017 08:17 AM, Steven Rostedt wrote: On Tue, 27 Jun 2017 19:28:32 +0900 Masami Hiramatsu

Re: [PATCH] selftests: ftrace: Use md5sum to take less time of checking logs

On 06/28/2017 09:30 AM, Shuah Khan wrote: > On 06/28/2017 08:59 AM, Steven Rostedt wrote: >> On Wed, 28 Jun 2017 08:30:24 -0600 >> Shuah Khan wrote: >> >>> On 06/28/2017 08:17 AM, Steven Rostedt wrote: On Tue, 27 Jun 2017 19:28:32 +0900 Masami Hiramatsu wrote: > Use md5sum

Re: [RFC v2 6/9] Creation of "pagefault_handler_x86" LSM hook

On Thu, Jun 29, 2017 at 12:30 PM, Salvatore Mesoraca wrote: > 2017-06-28 1:07 GMT+02:00 Kees Cook : >> On Thu, Jun 15, 2017 at 9:42 AM, Salvatore Mesoraca >> wrote: >>> Creation of a new hook to let LSM modules handle

Re: [RFC v2 6/9] Creation of "pagefault_handler_x86" LSM hook

On Thu, Jun 29, 2017 at 12:30 PM, Salvatore Mesoraca wrote: > 2017-06-28 1:07 GMT+02:00 Kees Cook : >> On Thu, Jun 15, 2017 at 9:42 AM, Salvatore Mesoraca >> wrote: >>> Creation of a new hook to let LSM modules handle user-space pagefaults on >>> x86. >>> It can be used to avoid segfaulting the

[GIT] Networking

1) Need to access netdev->num_rx_queues behind an accessor in netvsc driver otherwise the build breaks with some configs, from Arnd Bergmann. 2) Add dummy xfrm_dev_event() so that build doesn't fail when CONFIG_XFRM_OFFLOAD is not set. From Hangbin Liu. 3) Don't OOPS when

[GIT] Networking

1) Need to access netdev->num_rx_queues behind an accessor in netvsc driver otherwise the build breaks with some configs, from Arnd Bergmann. 2) Add dummy xfrm_dev_event() so that build doesn't fail when CONFIG_XFRM_OFFLOAD is not set. From Hangbin Liu. 3) Don't OOPS when

Re: spin_unlock_wait() in ata_scsi_cmd_error_handler()?

Hello, On Thu, Jun 29, 2017 at 01:14:43PM -0700, Paul E. McKenney wrote: > On Thu, Jun 29, 2017 at 03:53:22PM -0400, Tejun Heo wrote: > > Hello, Paul. > > > > On Thu, Jun 29, 2017 at 11:10:57AM -0700, Paul E. McKenney wrote: > > > If this code fragment doesn't deadlock, then CPU 0's

Re: spin_unlock_wait() in ata_scsi_cmd_error_handler()?

Hello, On Thu, Jun 29, 2017 at 01:14:43PM -0700, Paul E. McKenney wrote: > On Thu, Jun 29, 2017 at 03:53:22PM -0400, Tejun Heo wrote: > > Hello, Paul. > > > > On Thu, Jun 29, 2017 at 11:10:57AM -0700, Paul E. McKenney wrote: > > > If this code fragment doesn't deadlock, then CPU 0's

Re: [PATCH 06/16] ntb: add check and comment for link up to mw_count and mw_get_align

On 6/29/2017 2:13 PM, Allen Hubbe wrote: Unfortunately, it is to work around hardware errata. That is not so trivial to fix. Can you describe more what the work around is doing? Can you share the code? It seems odd that a workaround is based on the alignment restrictions of the mws.

Re: [PATCH 06/16] ntb: add check and comment for link up to mw_count and mw_get_align

On 6/29/2017 2:13 PM, Allen Hubbe wrote: Unfortunately, it is to work around hardware errata. That is not so trivial to fix. Can you describe more what the work around is doing? Can you share the code? It seems odd that a workaround is based on the alignment restrictions of the mws.

Re: BUG: Dentry ffff9f795a08fe60{i=af565f,n=lo} still in use (1) [unmount of proc proc]

On Thu, Jun 29, 2017 at 12:06 PM, Eric W. Biederman wrote: > Andrei Vagin writes: > >> Hello, >> >> We run CRIU tests on linus' tree and today we found this issue. >> >> CRIU tests are the set of small programs to check checkpoint/restore >> of different

Re: BUG: Dentry ffff9f795a08fe60{i=af565f,n=lo} still in use (1) [unmount of proc proc]

On Thu, Jun 29, 2017 at 12:06 PM, Eric W. Biederman wrote: > Andrei Vagin writes: > >> Hello, >> >> We run CRIU tests on linus' tree and today we found this issue. >> >> CRIU tests are the set of small programs to check checkpoint/restore >> of different primitives (files, sockets, signals,

Re: spin_unlock_wait() in ata_scsi_cmd_error_handler()?

On Thu, Jun 29, 2017 at 03:53:22PM -0400, Tejun Heo wrote: > Hello, Paul. > > On Thu, Jun 29, 2017 at 11:10:57AM -0700, Paul E. McKenney wrote: > > If this code fragment doesn't deadlock, then CPU 0's spin_unlock_wait() > > must have executed before CPU 1's spin_lock(). However, even on x86, > >

Re: spin_unlock_wait() in ata_scsi_cmd_error_handler()?

On Thu, Jun 29, 2017 at 03:53:22PM -0400, Tejun Heo wrote: > Hello, Paul. > > On Thu, Jun 29, 2017 at 11:10:57AM -0700, Paul E. McKenney wrote: > > If this code fragment doesn't deadlock, then CPU 0's spin_unlock_wait() > > must have executed before CPU 1's spin_lock(). However, even on x86, > >

RE: [PATCH 06/16] ntb: add check and comment for link up to mw_count and mw_get_align

From: Logan Gunthorpe > On 6/29/2017 12:11 PM, Allen Hubbe wrote: > > Nak. This breaks a work around for stability issues on some hardware. I > > am ok with changing the > comment to say, this is only supported when called after link up. I would > still like to allow these > to be called at

Re: [PATCH V2 25/37] perf script: Add synthesized Intel PT power and ptwrite events

Em Thu, Jun 29, 2017 at 10:56:25PM +0300, Adrian Hunter escreveu: > On 06/28/2017 11:26 PM, Arnaldo Carvalho de Melo wrote: > > Em Wed, Jun 28, 2017 at 08:21:37PM +, Hunter, Adrian escreveu: > >> Sorry for the top-post... > >> > >> Yeah, I've now mixed up the variable attribute: > >> > >>

RE: [PATCH 06/16] ntb: add check and comment for link up to mw_count and mw_get_align

From: Logan Gunthorpe > On 6/29/2017 12:11 PM, Allen Hubbe wrote: > > Nak. This breaks a work around for stability issues on some hardware. I > > am ok with changing the > comment to say, this is only supported when called after link up. I would > still like to allow these > to be called at

Re: [PATCH V2 25/37] perf script: Add synthesized Intel PT power and ptwrite events

Em Thu, Jun 29, 2017 at 10:56:25PM +0300, Adrian Hunter escreveu: > On 06/28/2017 11:26 PM, Arnaldo Carvalho de Melo wrote: > > Em Wed, Jun 28, 2017 at 08:21:37PM +, Hunter, Adrian escreveu: > >> Sorry for the top-post... > >> > >> Yeah, I've now mixed up the variable attribute: > >> > >>

Re: [PATCH v3 0/8] [media] s5p-jpeg: Various fixes and improvements

Hi Thierry, For the whole series: Acked-by: Jacek Anaszewski Best regards, Jacek Anaszewski On 06/27/2017 06:08 PM, Thierry Escande wrote: > Hi, > > This series contains various fixes and improvements for the Samsung > s5p-jpeg driver. Most of these patches come

Re: [PATCH v3 0/8] [media] s5p-jpeg: Various fixes and improvements

Hi Thierry, For the whole series: Acked-by: Jacek Anaszewski Best regards, Jacek Anaszewski On 06/27/2017 06:08 PM, Thierry Escande wrote: > Hi, > > This series contains various fixes and improvements for the Samsung > s5p-jpeg driver. Most of these patches come from the Chromium v3.8 >

Re: [v3 1/6] mm, oom: use oom_victims counter to synchronize oom victim selection

Roman Gushchin wrote: > On Fri, Jun 23, 2017 at 06:52:20AM +0900, Tetsuo Handa wrote: > > Tetsuo Handa wrote: > > Oops, I misinterpreted. This is where a multithreaded OOM victim with or > > without > > the OOM reaper can get stuck forever. Think about a process with two > > threads is > >

Re: [v3 1/6] mm, oom: use oom_victims counter to synchronize oom victim selection

Roman Gushchin wrote: > On Fri, Jun 23, 2017 at 06:52:20AM +0900, Tetsuo Handa wrote: > > Tetsuo Handa wrote: > > Oops, I misinterpreted. This is where a multithreaded OOM victim with or > > without > > the OOM reaper can get stuck forever. Think about a process with two > > threads is > >

Re: [PATCH 2/4] ARM: aspeed: g5: Add USB functions to pinctrl bindings

On Tue, Jun 27, 2017 at 11:42:12AM +0930, Andrew Jeffery wrote: > The Aspeed AST2500 SoC contains a number of USB controllers: > > * USB 1.1 Host Controller > * USB 2.0 Host Controller (x2) > * Combined USB 2.0 Virtual Hub and USB 1.1 HID Controller > > The controllers are exposed via two USB

Re: [PATCH 2/4] ARM: aspeed: g5: Add USB functions to pinctrl bindings

On Tue, Jun 27, 2017 at 11:42:12AM +0930, Andrew Jeffery wrote: > The Aspeed AST2500 SoC contains a number of USB controllers: > > * USB 1.1 Host Controller > * USB 2.0 Host Controller (x2) > * Combined USB 2.0 Virtual Hub and USB 1.1 HID Controller > > The controllers are exposed via two USB

Re: [PATCH v3 4/8] [media] s5p-jpeg: Don't use temporary structure in s5p_jpeg_buf_queue

Hi Thierry, On 06/27/2017 06:08 PM, Thierry Escande wrote: > If s5p_jpeg_parse_hdr() fails to parse the JPEG header, the passed > s5p_jpeg_q_data structure is not modify so there is no need to use a s/modify/modified/ > temporary structure and the field-by-field copy can be avoided. > >

Re: [PATCH v3 4/8] [media] s5p-jpeg: Don't use temporary structure in s5p_jpeg_buf_queue

Hi Thierry, On 06/27/2017 06:08 PM, Thierry Escande wrote: > If s5p_jpeg_parse_hdr() fails to parse the JPEG header, the passed > s5p_jpeg_q_data structure is not modify so there is no need to use a s/modify/modified/ > temporary structure and the field-by-field copy can be avoided. > >

Genius "Wizard Stick" wireless joystick not working properly

Hello, I tried to connect a Genius "Wizard Stick" wireless joystick to my PC. The device is identified as Bus 003 Device 122: ID 0458:00d9 KYE Systems Corp. (Mouse Systems) /dev/input/event13: KYE RF Game controller /dev/input/event14: KYE RF Game controller (no events on this) evtest

Genius "Wizard Stick" wireless joystick not working properly

Hello, I tried to connect a Genius "Wizard Stick" wireless joystick to my PC. The device is identified as Bus 003 Device 122: ID 0458:00d9 KYE Systems Corp. (Mouse Systems) /dev/input/event13: KYE RF Game controller /dev/input/event14: KYE RF Game controller (no events on this) evtest

Re: [PATCH 1/4] ARM: aspeed: g4: Add USB functions to pinctrl bindings

On Tue, Jun 27, 2017 at 11:42:11AM +0930, Andrew Jeffery wrote: > The AST2400 contains several USB controllers: > > * USB 1.1 Host Controller > * USB 2.0 Host Controller > * Combined USB 2.0 Virtual Hub and USB 1.1 HID Controller > > Pins for three ports are routed to the three controllers such

Re: [PATCH 1/4] ARM: aspeed: g4: Add USB functions to pinctrl bindings

On Tue, Jun 27, 2017 at 11:42:11AM +0930, Andrew Jeffery wrote: > The AST2400 contains several USB controllers: > > * USB 1.1 Host Controller > * USB 2.0 Host Controller > * Combined USB 2.0 Virtual Hub and USB 1.1 HID Controller > > Pins for three ports are routed to the three controllers such

Re: [PATCH 4/6] dt-bindings: serial: Document RDA Micro UART

On Tue, Jun 27, 2017 at 02:55:18AM +0200, Andreas Färber wrote: > Add an initial binding for the RDA8810PL UART. > > Signed-off-by: Andreas Färber > --- > Documentation/devicetree/bindings/serial/rda-uart.txt | 13 + > 1 file changed, 13 insertions(+) > create

Re: [PATCH 4/6] dt-bindings: serial: Document RDA Micro UART

On Tue, Jun 27, 2017 at 02:55:18AM +0200, Andreas Färber wrote: > Add an initial binding for the RDA8810PL UART. > > Signed-off-by: Andreas Färber > --- > Documentation/devicetree/bindings/serial/rda-uart.txt | 13 + > 1 file changed, 13 insertions(+) > create mode 100644

[PATCH v2 3/4] btrfs: Add zstd support

Add zstd compression and decompression support to BtrFS. zstd at its fastest level compresses almost as well as zlib, while offering much faster compression and decompression, approaching lzo speeds. I benchmarked btrfs with zstd compression against no compression, lzo compression, and zlib

[PATCH v2 3/4] btrfs: Add zstd support

Add zstd compression and decompression support to BtrFS. zstd at its fastest level compresses almost as well as zlib, while offering much faster compression and decompression, approaching lzo speeds. I benchmarked btrfs with zstd compression against no compression, lzo compression, and zlib

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