[PATCH 3/3] misc: sram: Allow ARM64 to select SRAM_EXEC

Now that ARM64 also has a fncpy() implementation, allow selection SRAM_EXEC for ARM64 as well. Signed-off-by: Florian Fainelli --- drivers/misc/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index

[PATCH 3/3] misc: sram: Allow ARM64 to select SRAM_EXEC

Now that ARM64 also has a fncpy() implementation, allow selection SRAM_EXEC for ARM64 as well. Signed-off-by: Florian Fainelli --- drivers/misc/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index

[PATCH 2/3] arm64: Provide a fncpy implenentation

Utilize the asm-generic/fncpy.h implementation for ARM64 to allow the use of drivers/misc/sram*.c on these platforms as well. Signed-off-by: Florian Fainelli --- arch/arm64/include/asm/fncpy.h | 6 ++ 1 file changed, 6 insertions(+) create mode 100644

[PATCH 2/3] arm64: Provide a fncpy implenentation

Utilize the asm-generic/fncpy.h implementation for ARM64 to allow the use of drivers/misc/sram*.c on these platforms as well. Signed-off-by: Florian Fainelli --- arch/arm64/include/asm/fncpy.h | 6 ++ 1 file changed, 6 insertions(+) create mode 100644 arch/arm64/include/asm/fncpy.h diff

[PATCH 1/3] ARM: Generalize fncpy implementation

ARM's fncpy implementation is actually suitable for a large number of platforms since the only assumption it makes is just the function's alignment (8 bytes) which also happens to fulfil other architectures, including but not limited to ARM64. Signed-off-by: Florian Fainelli

[PATCH 1/3] ARM: Generalize fncpy implementation

ARM's fncpy implementation is actually suitable for a large number of platforms since the only assumption it makes is just the function's alignment (8 bytes) which also happens to fulfil other architectures, including but not limited to ARM64. Signed-off-by: Florian Fainelli ---

[PATCH 0/3] Generalize fncpy availability

Hi all, This patch series relocates ARM's fncpy to asm-generic in order for us to be able to use SRAM_EXEC on ARM64 platforms. Florian Fainelli (3): ARM: Generalize fncpy implementation arm64: Provide a fncpy implenentation misc: sram: Allow ARM64 to select SRAM_EXEC

[PATCH 0/3] Generalize fncpy availability

Hi all, This patch series relocates ARM's fncpy to asm-generic in order for us to be able to use SRAM_EXEC on ARM64 platforms. Florian Fainelli (3): ARM: Generalize fncpy implementation arm64: Provide a fncpy implenentation misc: sram: Allow ARM64 to select SRAM_EXEC

Re: [PATCH 0/5] perf: add support for capturing skid IP

> Looking at this approach, the user interface is straightforward, > implementation in the x86 code is a bit more hairy because of the way > the branch_stack is captured, via the cpuc->lbr_entries. If you assume > that SKID_IP cannot be used with any other branch stack mode, then it > is easy. It

Re: [PATCH 0/5] perf: add support for capturing skid IP

> Looking at this approach, the user interface is straightforward, > implementation in the x86 code is a bit more hairy because of the way > the branch_stack is captured, via the cpuc->lbr_entries. If you assume > that SKID_IP cannot be used with any other branch stack mode, then it > is easy. It

linux-next: manual merge of the clk tree with the reset tree

Hi all, Today's linux-next merge of the clk tree got a conflict in: MAINTAINERS between commits: 18a006203b88 ("dt-bindings: reset: Add TI SCI reset binding") 28df169b9afa ("reset: Add the TI SCI reset driver") from the reset tree and commits: 8f306cfe4383 ("Documentation: dt: Add TI

linux-next: manual merge of the clk tree with the reset tree

Hi all, Today's linux-next merge of the clk tree got a conflict in: MAINTAINERS between commits: 18a006203b88 ("dt-bindings: reset: Add TI SCI reset binding") 28df169b9afa ("reset: Add the TI SCI reset driver") from the reset tree and commits: 8f306cfe4383 ("Documentation: dt: Add TI

Re: [PATCH 1/2] remoteproc: Add remote processor coredump support

On 6/15/2017 11:48 AM, Suman Anna wrote: Hi Sarangdhar, Hi Suman, Thanks for reviewing the patch. On 06/14/2017 01:06 PM, Sarangdhar Joshi wrote: The remoteproc framework shuts down and immediately restarts the remote processor after fatal events (such as when remote crashes) during the

Re: [PATCH 1/2] remoteproc: Add remote processor coredump support

On 6/15/2017 11:48 AM, Suman Anna wrote: Hi Sarangdhar, Hi Suman, Thanks for reviewing the patch. On 06/14/2017 01:06 PM, Sarangdhar Joshi wrote: The remoteproc framework shuts down and immediately restarts the remote processor after fatal events (such as when remote crashes) during the

Re: xgetbv nondeterminism

On Thu, Jun 15, 2017 at 3:45 PM, Andy Lutomirski wrote: > On Thu, Jun 15, 2017 at 3:40 PM, H.J. Lu wrote: >> On Thu, Jun 15, 2017 at 3:18 PM, Andy Lutomirski wrote: >>> On Thu, Jun 15, 2017 at 7:33 AM, Dave Hansen

Re: xgetbv nondeterminism

On Thu, Jun 15, 2017 at 3:45 PM, Andy Lutomirski wrote: > On Thu, Jun 15, 2017 at 3:40 PM, H.J. Lu wrote: >> On Thu, Jun 15, 2017 at 3:18 PM, Andy Lutomirski wrote: >>> On Thu, Jun 15, 2017 at 7:33 AM, Dave Hansen wrote: On 06/14/2017 10:18 PM, Andy Lutomirski wrote: > Dave, why is

Re: LTS testing with latest kselftests - some failures

On Thu, Jun 15, 2017 at 11:26:53PM +0530, Sumit Semwal wrote: > > 4. bpf tests: These seem to have build failures in mainline as well - > I also tried to build kselftest-next, but a simple 'make -C > tools/testing/selftests/bpf' seems to error out. Are there any special > instructions to build

Re: LTS testing with latest kselftests - some failures

On Thu, Jun 15, 2017 at 11:26:53PM +0530, Sumit Semwal wrote: > > 4. bpf tests: These seem to have build failures in mainline as well - > I also tried to build kselftest-next, but a simple 'make -C > tools/testing/selftests/bpf' seems to error out. Are there any special > instructions to build

[RESEND PATCH v3 1/n] perf/core: addressing 4x slowdown during per-process profiling of STREAM benchmark on Intel Xeon Phi

perf/core: use rb trees for pinned/flexible groups By default, the userspace perf tool opens per-cpu task-bound events when sampling, so for N logical events requested by the user, the tool will open N * NR_CPUS events. In the kernel, we mux events with a hrtimer, periodically rotating the

Re: [PATCHv2 3/3] mm: Use updated pmdp_invalidate() inteface to track dirty/accessed bits

Hi Kirill, [auto build test ERROR on mmotm/master] [also build test ERROR on v4.12-rc5 next-20170615] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Kirill

[RESEND PATCH v3 1/n] perf/core: addressing 4x slowdown during per-process profiling of STREAM benchmark on Intel Xeon Phi

perf/core: use rb trees for pinned/flexible groups By default, the userspace perf tool opens per-cpu task-bound events when sampling, so for N logical events requested by the user, the tool will open N * NR_CPUS events. In the kernel, we mux events with a hrtimer, periodically rotating the

Re: [PATCHv2 3/3] mm: Use updated pmdp_invalidate() inteface to track dirty/accessed bits

Hi Kirill, [auto build test ERROR on mmotm/master] [also build test ERROR on v4.12-rc5 next-20170615] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Kirill

Re: xgetbv nondeterminism

On Thu, Jun 15, 2017 at 3:40 PM, H.J. Lu wrote: > On Thu, Jun 15, 2017 at 3:18 PM, Andy Lutomirski wrote: >> On Thu, Jun 15, 2017 at 7:33 AM, Dave Hansen wrote: >>> On 06/14/2017 10:18 PM, Andy Lutomirski wrote: Dave, why is

Re: xgetbv nondeterminism

On Thu, Jun 15, 2017 at 3:40 PM, H.J. Lu wrote: > On Thu, Jun 15, 2017 at 3:18 PM, Andy Lutomirski wrote: >> On Thu, Jun 15, 2017 at 7:33 AM, Dave Hansen wrote: >>> On 06/14/2017 10:18 PM, Andy Lutomirski wrote: Dave, why is XINUSE exposed at all to userspace? >>> >>> You need it for

Re: [patch] mm, oom: prevent additional oom kills before memory is freed

On Fri, 16 Jun 2017, Michal Hocko wrote: > I am sorry but I have really hard to make the oom reaper a reliable way > to stop all the potential oom lockups go away. I do not want to > reintroduce another potential lockup now. Please show where this "potential lockup" ever existed in a bug report

Re: [patch] mm, oom: prevent additional oom kills before memory is freed

On Fri, 16 Jun 2017, Michal Hocko wrote: > I am sorry but I have really hard to make the oom reaper a reliable way > to stop all the potential oom lockups go away. I do not want to > reintroduce another potential lockup now. Please show where this "potential lockup" ever existed in a bug report

Re: [PATCH] drm: atmel-hlcdc: sama5d4 does not have overlay2

On 2017-06-15 11:37, Boris Brezillon wrote: > On Thu, 15 Jun 2017 11:24:13 +0200 > Peter Rosin wrote: > >> From: Peter Rosin >> >> Remove the layer. > > Duh. It was present in the datasheet I had. Just downloaded last > version of the datasheet and it's no

Re: [PATCH] drm: atmel-hlcdc: sama5d4 does not have overlay2

On 2017-06-15 11:37, Boris Brezillon wrote: > On Thu, 15 Jun 2017 11:24:13 +0200 > Peter Rosin wrote: > >> From: Peter Rosin >> >> Remove the layer. > > Duh. It was present in the datasheet I had. Just downloaded last > version of the datasheet and it's no longer there. Heh. > Nicolas,

Re: xgetbv nondeterminism

On Thu, Jun 15, 2017 at 3:18 PM, Andy Lutomirski wrote: > On Thu, Jun 15, 2017 at 7:33 AM, Dave Hansen wrote: >> On 06/14/2017 10:18 PM, Andy Lutomirski wrote: >>> Dave, why is XINUSE exposed at all to userspace? >> >> You need it for XSAVEOPT when it is

Re: xgetbv nondeterminism

On Thu, Jun 15, 2017 at 3:18 PM, Andy Lutomirski wrote: > On Thu, Jun 15, 2017 at 7:33 AM, Dave Hansen wrote: >> On 06/14/2017 10:18 PM, Andy Lutomirski wrote: >>> Dave, why is XINUSE exposed at all to userspace? >> >> You need it for XSAVEOPT when it is using the init optimization to be >> able

[PATCH] drm/radeon: remove unnecessary variable in si_enable_smc_cac

Remove unnecessary variable smc_result and simplify the logic related. Variable smc_result is only being used to store the return value of function si_send_msg_to_smc() and then compare this value against constant PPSMC_Result_OK. In other cases this variable is not even used after storing a

Re: ath9k_htc - Division by zero in kernel (as well as firmware panic)

Yeah, this is basically mostly copy-pasted from the sboot code, would need some cleaning up. I've been playing more a little with other bits of the hardware, writing some test fw from scratch, mostly without using the builtin rom (except for interrupts). Oleksij Rempel wrote: > Am 08.06.2017 um

[PATCH] drm/radeon: remove unnecessary variable in si_enable_smc_cac

Remove unnecessary variable smc_result and simplify the logic related. Variable smc_result is only being used to store the return value of function si_send_msg_to_smc() and then compare this value against constant PPSMC_Result_OK. In other cases this variable is not even used after storing a

Re: ath9k_htc - Division by zero in kernel (as well as firmware panic)

Yeah, this is basically mostly copy-pasted from the sboot code, would need some cleaning up. I've been playing more a little with other bits of the hardware, writing some test fw from scratch, mostly without using the builtin rom (except for interrupts). Oleksij Rempel wrote: > Am 08.06.2017 um

[PATCH RFC 1/3] arm64: Gate inclusion of asm/sysreg.h by __EMITTING_BPF__

Compilation to eBPF chokes on the inline asm in asm/sysreg.h, so don't include it when compiling to a BPF target. Signed-off-by: David Daney --- arch/arm64/include/asm/sysreg.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git

[PATCH RFC 1/3] arm64: Gate inclusion of asm/sysreg.h by __EMITTING_BPF__

Compilation to eBPF chokes on the inline asm in asm/sysreg.h, so don't include it when compiling to a BPF target. Signed-off-by: David Daney --- arch/arm64/include/asm/sysreg.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm64/include/asm/sysreg.h

[PATCH RFC 2/3] samples/bpf: Add define __EMITTING_BPF__ when building BPF

... this allows gating of inline assembly code that causes llvm to fail when emitting BPF. Signed-off-by: David Daney --- samples/bpf/Makefile | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile index

[PATCH RFC 2/3] samples/bpf: Add define __EMITTING_BPF__ when building BPF

... this allows gating of inline assembly code that causes llvm to fail when emitting BPF. Signed-off-by: David Daney --- samples/bpf/Makefile | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile index a0561dc762fe..4979e6b56662

[PATCH RFC 0/3] bpf/arm64/mips: Avoid inline asm in BPF

To build samples/bpf on MIPS we need to avoid some inline asm that causes llvm to fail. Looking at the code, it seems that arm64 had the same problem and avoided it by defining the header guard symbol. This approach does not scale, so I invented a preprocessor define to identify the case of

[PATCH RFC 0/3] bpf/arm64/mips: Avoid inline asm in BPF

To build samples/bpf on MIPS we need to avoid some inline asm that causes llvm to fail. Looking at the code, it seems that arm64 had the same problem and avoided it by defining the header guard symbol. This approach does not scale, so I invented a preprocessor define to identify the case of

[PATCH RFC 3/3] MIPS: Include file changes to enable building BPF code with llvm

When building for the eBPF target archecture. Inline asm cannot be used as MIPS instructions are fundamentally incompatible with eBPF bytecode. The preprocessor symbol __EMITTING_BPF__ is used to gate the inclusion of inline asm in constructs used the by the BPF programs. Also make the Makefile

Re: [PATCHv2 2/3] mm: Do not loose dirty and access bits in pmdp_invalidate()

Hi Kirill, [auto build test ERROR on mmotm/master] [also build test ERROR on v4.12-rc5 next-20170615] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Kirill

[PATCH RFC 3/3] MIPS: Include file changes to enable building BPF code with llvm

When building for the eBPF target archecture. Inline asm cannot be used as MIPS instructions are fundamentally incompatible with eBPF bytecode. The preprocessor symbol __EMITTING_BPF__ is used to gate the inclusion of inline asm in constructs used the by the BPF programs. Also make the Makefile

Re: [PATCHv2 2/3] mm: Do not loose dirty and access bits in pmdp_invalidate()

Hi Kirill, [auto build test ERROR on mmotm/master] [also build test ERROR on v4.12-rc5 next-20170615] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Kirill

[RESEND PATCH 2/2] Input: xpad - sync supported devices with XBCD

XBCD [0][1] is an OpenSource driver for Xbox controllers on Windows. Later it also started supporting Xbox360 controllers (presumably before the official Windows driver was released). It contains a couple device IDs unknown to the Linux driver, so I extracted those from xbcd.inf and added them to

[RESEND PATCH 2/2] Input: xpad - sync supported devices with XBCD

XBCD [0][1] is an OpenSource driver for Xbox controllers on Windows. Later it also started supporting Xbox360 controllers (presumably before the official Windows driver was released). It contains a couple device IDs unknown to the Linux driver, so I extracted those from xbcd.inf and added them to

[RESEND PATCHv4 1/2] Input: xpad - sync supported devices with 360Controller

360Controller [0] is an OpenSource driver for Xbox/Xbox360/XboxOne controllers on macOS. It contains a couple device IDs unknown to the Linux driver, so I wrote a small Python script [1] to extract them and feed them into my previous script [2] to compare them with the IDs known to Linux. For

[RESEND PATCHv4 1/2] Input: xpad - sync supported devices with 360Controller

360Controller [0] is an OpenSource driver for Xbox/Xbox360/XboxOne controllers on macOS. It contains a couple device IDs unknown to the Linux driver, so I wrote a small Python script [1] to extract them and feed them into my previous script [2] to compare them with the IDs known to Linux. For

Re: [PATCH] reconnect_one(): fix a missing error code

On Thu, Jun 15 2017, J. Bruce Fields wrote: > On Thu, Jun 15, 2017 at 07:54:57AM +1000, NeilBrown wrote: >> On Wed, Jun 14 2017, J. Bruce Fields wrote: >> >> > On Wed, Jun 14, 2017 at 12:30:02PM +0300, Dan Carpenter wrote: >> >> I found this bug by reviewing places where we do ERR_PTR(0) (which

Re: [PATCH] reconnect_one(): fix a missing error code

On Thu, Jun 15 2017, J. Bruce Fields wrote: > On Thu, Jun 15, 2017 at 07:54:57AM +1000, NeilBrown wrote: >> On Wed, Jun 14 2017, J. Bruce Fields wrote: >> >> > On Wed, Jun 14, 2017 at 12:30:02PM +0300, Dan Carpenter wrote: >> >> I found this bug by reviewing places where we do ERR_PTR(0) (which

Re: [PATCH 0/5] perf: add support for capturing skid IP

On Thu, Jun 15, 2017 at 1:20 PM, Stephane Eranian wrote: > On Thu, Jun 15, 2017 at 1:02 PM, Andi Kleen wrote: >> On Thu, Jun 15, 2017 at 12:35:39PM -0700, Stephane Eranian wrote: >>> On Thu, Jun 15, 2017 at 10:23 AM, Andi Kleen

Re: [PATCH 0/5] perf: add support for capturing skid IP

On Thu, Jun 15, 2017 at 1:20 PM, Stephane Eranian wrote: > On Thu, Jun 15, 2017 at 1:02 PM, Andi Kleen wrote: >> On Thu, Jun 15, 2017 at 12:35:39PM -0700, Stephane Eranian wrote: >>> On Thu, Jun 15, 2017 at 10:23 AM, Andi Kleen wrote: >>> > On Thu, Jun 15, 2017 at 09:44:07AM -0700, Stephane

Re: [RFC PATCH v2] pci: Concurrency issue in NVMe Init through PCIe switch

Hi Srinath, On Tue, May 30, 2017 at 02:38:17PM +0530, Srinath Mannam wrote: > We found a concurrency issue in NVMe Init when we initialize > multiple NVMe connected over PCIe switch. > > Setup details: > - SMP system with 8 ARMv8 cores running Linux kernel(4.11). > - Two NVMe cards are

Re: [RFC PATCH v2] pci: Concurrency issue in NVMe Init through PCIe switch

Hi Srinath, On Tue, May 30, 2017 at 02:38:17PM +0530, Srinath Mannam wrote: > We found a concurrency issue in NVMe Init when we initialize > multiple NVMe connected over PCIe switch. > > Setup details: > - SMP system with 8 ARMv8 cores running Linux kernel(4.11). > - Two NVMe cards are

linux-next: build warning after merge of the wireless-drivers tree

Hi all, After merging the wireless-drivers tree, today's linux-next build (x86_64 allmodconfig) produced this warning: drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c: In function 'brcmf_usb_probe_phase2': drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c:1198:2: warning: 'devinfo'

linux-next: build warning after merge of the wireless-drivers tree

Hi all, After merging the wireless-drivers tree, today's linux-next build (x86_64 allmodconfig) produced this warning: drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c: In function 'brcmf_usb_probe_phase2': drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c:1198:2: warning: 'devinfo'

Re: [PATCH 4.11 00/13] 4.11.6-stable review

On 06/15/2017 11:54 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.11.6 release. > There are 13 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.11 00/13] 4.11.6-stable review

On 06/15/2017 11:54 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.11.6 release. > There are 13 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.4 00/46] 4.4.73-stable review

On 06/15/2017 11:52 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.73 release. > There are 46 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.4 00/46] 4.4.73-stable review

On 06/15/2017 11:52 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.73 release. > There are 46 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

[PATCH] omap3isp: fix compilation

Fix compilation of isp.c Signed-off-by: Pavel Machek diff --git a/drivers/media/platform/omap3isp/isp.c b/drivers/media/platform/omap3isp/isp.c index 4ca3fc9..b80debf 100644 --- a/drivers/media/platform/omap3isp/isp.c +++ b/drivers/media/platform/omap3isp/isp.c @@ -2026,7

[PATCH] omap3isp: fix compilation

Fix compilation of isp.c Signed-off-by: Pavel Machek diff --git a/drivers/media/platform/omap3isp/isp.c b/drivers/media/platform/omap3isp/isp.c index 4ca3fc9..b80debf 100644 --- a/drivers/media/platform/omap3isp/isp.c +++ b/drivers/media/platform/omap3isp/isp.c @@ -2026,7 +2026,7 @@

Re: [PATCH 4.9 000/108] 4.9.33-stable review

On 06/15/2017 11:52 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.33 release. > There are 108 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.9 000/108] 4.9.33-stable review

On 06/15/2017 11:52 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.33 release. > There are 108 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

n900 camera on v4.12-rc (was Re: v4l2-fwnode: status, plans for merge, any branch to merge against?)

Hi! Ok, so I played a bit, and now I have working camera in v4.12-rc3. https://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-n900.git/ camera-fw5-3 is recommended branch to play with. Sakari, should I attempt to clean/send you patches, or would it be better to wait till ccp2 branch is

n900 camera on v4.12-rc (was Re: v4l2-fwnode: status, plans for merge, any branch to merge against?)

Hi! Ok, so I played a bit, and now I have working camera in v4.12-rc3. https://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-n900.git/ camera-fw5-3 is recommended branch to play with. Sakari, should I attempt to clean/send you patches, or would it be better to wait till ccp2 branch is

Re: xgetbv nondeterminism

On Thu, Jun 15, 2017 at 7:33 AM, Dave Hansen wrote: > On 06/14/2017 10:18 PM, Andy Lutomirski wrote: >> Dave, why is XINUSE exposed at all to userspace? > > You need it for XSAVEOPT when it is using the init optimization to be > able to tell which state was written and

Re: xgetbv nondeterminism

On Thu, Jun 15, 2017 at 7:33 AM, Dave Hansen wrote: > On 06/14/2017 10:18 PM, Andy Lutomirski wrote: >> Dave, why is XINUSE exposed at all to userspace? > > You need it for XSAVEOPT when it is using the init optimization to be > able to tell which state was written and which state in the XSAVE

Re: [patch] mm, oom: prevent additional oom kills before memory is freed

On Thu 15-06-17 15:03:17, David Rientjes wrote: > On Thu, 15 Jun 2017, Michal Hocko wrote: > > > > Yes, quite a bit in testing. > > > > > > One oom kill shows the system to be oom: > > > > > > [22999.488705] Node 0 Normal free:90484kB min:90500kB ... > > > [22999.488711] Node 1 Normal

Re: [patch] mm, oom: prevent additional oom kills before memory is freed

On Thu 15-06-17 15:03:17, David Rientjes wrote: > On Thu, 15 Jun 2017, Michal Hocko wrote: > > > > Yes, quite a bit in testing. > > > > > > One oom kill shows the system to be oom: > > > > > > [22999.488705] Node 0 Normal free:90484kB min:90500kB ... > > > [22999.488711] Node 1 Normal

Re: [PATCH 2/2] drm/vc4: Add get/set tiling ioctls.

Boris Brezillon writes: > Hi Eric, > > On Wed, 7 Jun 2017 17:13:36 -0700 > Eric Anholt wrote: > >> This allows mesa to set the tiling format for a BO and have that >> tiling format be respected by mesa on the other side of an >>

Re: [PATCH 2/2] drm/vc4: Add get/set tiling ioctls.

Boris Brezillon writes: > Hi Eric, > > On Wed, 7 Jun 2017 17:13:36 -0700 > Eric Anholt wrote: > >> This allows mesa to set the tiling format for a BO and have that >> tiling format be respected by mesa on the other side of an >> import/export (and by vc4 scanout in the kernel), without

Re: [PATCH v3 1/n] perf/core: addressing 4x slowdown during per-process profiling of STREAM benchmark on Intel Xeon Phi

Hi, On 15.06.2017 22:56, Mark Rutland wrote: Hi, On Thu, Jun 15, 2017 at 08:41:42PM +0300, Alexey Budankov wrote: This series of patches continues v2 and addresses captured comments. As a general note, please keep any change log stuff out of the commit message, and mvoe that just before the

Re: [PATCH v3 1/n] perf/core: addressing 4x slowdown during per-process profiling of STREAM benchmark on Intel Xeon Phi

Hi, On 15.06.2017 22:56, Mark Rutland wrote: Hi, On Thu, Jun 15, 2017 at 08:41:42PM +0300, Alexey Budankov wrote: This series of patches continues v2 and addresses captured comments. As a general note, please keep any change log stuff out of the commit message, and mvoe that just before the

Re: v4l2-fwnode: status, plans for merge, any branch to merge against?

On Wed, Jun 14, 2017 at 09:41:29PM +0200, Pavel Machek wrote: > diff --git a/drivers/media/platform/omap3isp/isp.c > b/drivers/media/platform/omap3isp/isp.c > index 4ca3fc9..b80debf 100644 > --- a/drivers/media/platform/omap3isp/isp.c > +++ b/drivers/media/platform/omap3isp/isp.c > @@ -2026,7

Re: v4l2-fwnode: status, plans for merge, any branch to merge against?

On Wed, Jun 14, 2017 at 09:41:29PM +0200, Pavel Machek wrote: > diff --git a/drivers/media/platform/omap3isp/isp.c > b/drivers/media/platform/omap3isp/isp.c > index 4ca3fc9..b80debf 100644 > --- a/drivers/media/platform/omap3isp/isp.c > +++ b/drivers/media/platform/omap3isp/isp.c > @@ -2026,7

Re: [PATCH v2 2/2] acpi/nfit: Issue Start ARS to retrieve existing records

Thanks for this. I think it's going in the right direction, but one comment below. On Thu, Jun 8, 2017 at 11:36 AM, Toshi Kani wrote: > ACPI 6.2 defines in section 9.20.7.2 that the OSPM may call a Start > ARS with Flags Bit [1] set upon receiving the 0x81 notification. > >

Re: [PATCH v2 2/2] acpi/nfit: Issue Start ARS to retrieve existing records

Thanks for this. I think it's going in the right direction, but one comment below. On Thu, Jun 8, 2017 at 11:36 AM, Toshi Kani wrote: > ACPI 6.2 defines in section 9.20.7.2 that the OSPM may call a Start > ARS with Flags Bit [1] set upon receiving the 0x81 notification. > > Upon receiving the

Re: [patch] mm, oom: prevent additional oom kills before memory is freed

On Thu, 15 Jun 2017, Michal Hocko wrote: > > Yes, quite a bit in testing. > > > > One oom kill shows the system to be oom: > > > > [22999.488705] Node 0 Normal free:90484kB min:90500kB ... > > [22999.488711] Node 1 Normal free:91536kB min:91948kB ... > > > > followed up by one or more

Re: [patch] mm, oom: prevent additional oom kills before memory is freed

On Thu, 15 Jun 2017, Michal Hocko wrote: > > Yes, quite a bit in testing. > > > > One oom kill shows the system to be oom: > > > > [22999.488705] Node 0 Normal free:90484kB min:90500kB ... > > [22999.488711] Node 1 Normal free:91536kB min:91948kB ... > > > > followed up by one or more

Re: [RFC v2 0/2] swait: add idle to make idle-hacks on kthreads explicit

On Thu, Jun 15, 2017 at 11:48:18AM -0700, Luis R. Rodriguez wrote: > While reviewing RCU's interruptible swaits I noticed signals were actually > not expected. Paul explained that the reason signals are not expected is > we use kthreads, which don't get signals, furthermore the code avoided the >

Re: [RFC v2 0/2] swait: add idle to make idle-hacks on kthreads explicit

On Thu, Jun 15, 2017 at 11:48:18AM -0700, Luis R. Rodriguez wrote: > While reviewing RCU's interruptible swaits I noticed signals were actually > not expected. Paul explained that the reason signals are not expected is > we use kthreads, which don't get signals, furthermore the code avoided the >

Re: [PATCHv2 3/3] mm: Use updated pmdp_invalidate() inteface to track dirty/accessed bits

Hi Kirill, [auto build test ERROR on mmotm/master] [also build test ERROR on v4.12-rc5 next-20170615] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Kirill

Re: [PATCHv2 3/3] mm: Use updated pmdp_invalidate() inteface to track dirty/accessed bits

Hi Kirill, [auto build test ERROR on mmotm/master] [also build test ERROR on v4.12-rc5 next-20170615] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Kirill

Re: [PATCH] Convert multiple netdev_info messages to netdev_dbg

On Thu, 2017-06-15 at 19:14 +0100, Michael J Dilmore wrote: > Multiple netdev_info messages clutter kernel output. Also add netdev_dbg for > packets per slave. [] > diff --git a/drivers/net/bonding/bond_options.c > b/drivers/net/bonding/bond_options.c [] > @@ -9,6 +9,8 @@ > * (at your option)

Re: [PATCH] Convert multiple netdev_info messages to netdev_dbg

On Thu, 2017-06-15 at 19:14 +0100, Michael J Dilmore wrote: > Multiple netdev_info messages clutter kernel output. Also add netdev_dbg for > packets per slave. [] > diff --git a/drivers/net/bonding/bond_options.c > b/drivers/net/bonding/bond_options.c [] > @@ -9,6 +9,8 @@ > * (at your option)

Re: [PATCH v7 18/26] x86/insn-eval: Add support to resolve 16-bit addressing encodings

On Wed, 2017-06-07 at 18:28 +0200, Borislav Petkov wrote: > On Fri, May 05, 2017 at 11:17:16AM -0700, Ricardo Neri wrote: > > Tasks running in virtual-8086 mode or in protected mode with code > > segment descriptors that specify 16-bit default address sizes via the > > D bit will use 16-bit

Re: [PATCH v7 18/26] x86/insn-eval: Add support to resolve 16-bit addressing encodings

On Wed, 2017-06-07 at 18:28 +0200, Borislav Petkov wrote: > On Fri, May 05, 2017 at 11:17:16AM -0700, Ricardo Neri wrote: > > Tasks running in virtual-8086 mode or in protected mode with code > > segment descriptors that specify 16-bit default address sizes via the > > D bit will use 16-bit

Re: [PATCH 3/4] of: Custom printk format specifier for device node

On Thu, 2017-06-15 at 16:26 -0500, Rob Herring wrote: > On Wed, Jun 14, 2017 at 01:56:48PM -0700, Joe Perches wrote: > > On Wed, 2017-06-14 at 15:30 -0500, Rob Herring wrote: > > > From: Pantelis Antoniou [] > > > diff --git a/lib/vsprintf.c b/lib/vsprintf.c > > >

Re: [PATCH 3/4] of: Custom printk format specifier for device node

On Thu, 2017-06-15 at 16:26 -0500, Rob Herring wrote: > On Wed, Jun 14, 2017 at 01:56:48PM -0700, Joe Perches wrote: > > On Wed, 2017-06-14 at 15:30 -0500, Rob Herring wrote: > > > From: Pantelis Antoniou [] > > > diff --git a/lib/vsprintf.c b/lib/vsprintf.c > > > [] > > > @@ -1470,6 +1471,123 @@

Re: [PATCH] PCI: rockchip: Handle return value of clk_prepare_enable

On Thu, Jun 01, 2017 at 03:51:45PM +0530, Arvind Yadav wrote: > clk_prepare_enable() can fail here and we must check its return value. > > Signed-off-by: Arvind Yadav Applied with ack/reviewed-by from Shawn and Heiko to pci/host-rockchip for v4.13, thanks! I had to

Re: [PATCH] PCI: rockchip: Handle return value of clk_prepare_enable

On Thu, Jun 01, 2017 at 03:51:45PM +0530, Arvind Yadav wrote: > clk_prepare_enable() can fail here and we must check its return value. > > Signed-off-by: Arvind Yadav Applied with ack/reviewed-by from Shawn and Heiko to pci/host-rockchip for v4.13, thanks! I had to apply it manually because of

Re: [PATCH v1 1/1] gpio: gpio-crystalcove: Skip IRQ CTRL register update for virtual GPIOs

Hi Andy, On 06/15/2017 02:19 AM, Andy Shevchenko wrote: On Thu, Jun 15, 2017 at 2:21 AM, wrote: From: Kuppuswamy Sathyanarayanan Commit 9a752b4c9ab9 ("gpio: crystalcove: Do not write regular gpio

Re: [PATCH v1 1/1] gpio: gpio-crystalcove: Skip IRQ CTRL register update for virtual GPIOs

Hi Andy, On 06/15/2017 02:19 AM, Andy Shevchenko wrote: On Thu, Jun 15, 2017 at 2:21 AM, wrote: From: Kuppuswamy Sathyanarayanan Commit 9a752b4c9ab9 ("gpio: crystalcove: Do not write regular gpio registers for virtual GPIOs") added support to skip GPIO register update for virtual GPIOs,

Re: [RFC] KVM: SVM: do not drop VMCB CPL to 0 if SS is not present

On Tue, May 30, 2017 at 9:05 AM, Paolo Bonzini wrote: > > > On 30/05/2017 17:58, Roman Penyaev wrote: >> Indeed, what is left is eventually take it from SS.RPL. J. > > Ahah! :) But I only suggested that in specific cases. > >> But jokes aside, with your last patch you seems

Re: [RFC] KVM: SVM: do not drop VMCB CPL to 0 if SS is not present

On Tue, May 30, 2017 at 9:05 AM, Paolo Bonzini wrote: > > > On 30/05/2017 17:58, Roman Penyaev wrote: >> Indeed, what is left is eventually take it from SS.RPL. J. > > Ahah! :) But I only suggested that in specific cases. > >> But jokes aside, with your last patch you seems fixed a race problem

Re: [PATCH v2 1/2] acpi/nfit: Add support of NVDIMM memory error notification in ACPI 6.2

On Thu, Jun 8, 2017 at 11:36 AM, Toshi Kani wrote: > ACPI 6.2 defines a new ACPI notification value to NVDIMM Root Device > in Table 5-169. > > 0x81 Unconsumed Uncorrectable Memory Error Detected > Used to pro-actively notify OSPM of uncorrectable memory errors >

Re: [PATCH v2 1/2] acpi/nfit: Add support of NVDIMM memory error notification in ACPI 6.2

On Thu, Jun 8, 2017 at 11:36 AM, Toshi Kani wrote: > ACPI 6.2 defines a new ACPI notification value to NVDIMM Root Device > in Table 5-169. > > 0x81 Unconsumed Uncorrectable Memory Error Detected > Used to pro-actively notify OSPM of uncorrectable memory errors > detected (for

Re: [PATCH] atm: solos-pci: remove useless variable assignments

Hi David, Quoting David Miller : From: "Gustavo A. R. Silva" Date: Thu, 15 Jun 2017 14:56:21 -0500 Value assigned to variable _data32_ at lines 1254 and 1257 is overwritten at line 1260 before it can be used. This makes such variable assignments

Re: [PATCH] atm: solos-pci: remove useless variable assignments

Hi David, Quoting David Miller : From: "Gustavo A. R. Silva" Date: Thu, 15 Jun 2017 14:56:21 -0500 Value assigned to variable _data32_ at lines 1254 and 1257 is overwritten at line 1260 before it can be used. This makes such variable assignments useless. Addresses-Coverity-ID: 1227049

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