Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation

On 29.04.16 22:25, Ard Biesheuvel wrote: > >> On 29 apr. 2016, at 22:06, Bjorn Helgaas wrote: >> >>> On Fri, Apr 29, 2016 at 03:51:49PM +0200, Ard Biesheuvel wrote: On 29 April 2016 at 15:41, Bjorn Helgaas wrote: > On Thu, Apr 28, 2016 at

Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation

On 29.04.16 22:25, Ard Biesheuvel wrote: > >> On 29 apr. 2016, at 22:06, Bjorn Helgaas wrote: >> >>> On Fri, Apr 29, 2016 at 03:51:49PM +0200, Ard Biesheuvel wrote: On 29 April 2016 at 15:41, Bjorn Helgaas wrote: > On Thu, Apr 28, 2016 at 11:39:35PM +0200, Alexander Graf wrote: >

Re: [RFC PATCH v2 03/18] x86/asm/head: standardize the bottom of the stack for idle tasks

On Fri, Apr 29, 2016 at 12:39:16PM -0700, Andy Lutomirski wrote: > On Thu, Apr 28, 2016 at 1:44 PM, Josh Poimboeuf wrote: > > Thanks to all the recent x86 entry code refactoring, most tasks' kernel > > stacks start at the same offset right above their saved pt_regs, > >

Re: [PATCH 25/32] sched: introduce the finish_arch_pre_lock_switch() scheduler hook

That's a possibility, although it will increase the distance between pmu->add for other perf events and the effective time that CQM monitoring starts. On Fri, Apr 29, 2016 at 1:21 PM, Vikas Shivappa wrote: > > > On Fri, 29 Apr 2016, David Carrillo-Cisneros wrote:

Re: [RFC PATCH v2 03/18] x86/asm/head: standardize the bottom of the stack for idle tasks

On Fri, Apr 29, 2016 at 12:39:16PM -0700, Andy Lutomirski wrote: > On Thu, Apr 28, 2016 at 1:44 PM, Josh Poimboeuf wrote: > > Thanks to all the recent x86 entry code refactoring, most tasks' kernel > > stacks start at the same offset right above their saved pt_regs, > > regardless of which

Re: [PATCH 25/32] sched: introduce the finish_arch_pre_lock_switch() scheduler hook

That's a possibility, although it will increase the distance between pmu->add for other perf events and the effective time that CQM monitoring starts. On Fri, Apr 29, 2016 at 1:21 PM, Vikas Shivappa wrote: > > > On Fri, 29 Apr 2016, David Carrillo-Cisneros wrote: > >> (Re-sending in plain text)

Re: [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues

On Fri, Apr 29, 2016 at 1:40 PM, Dave Hansen wrote: > On 04/29/2016 01:25 PM, Andy Lutomirski wrote: >> On Fri, Apr 29, 2016 at 1:07 PM, Yu-cheng Yu wrote: >>> On Fri, Apr 29, 2016 at 01:03:43PM -0700, Dave Hansen wrote: That's not

[PATCH 1/3] ext4: Add alignment check for DAX mount

When a partition is not aligned by 4KB, mount -o dax succeeds, but any read/write access to the filesystem fails, except for metadata update. Add alignment check to ext4_fill_super() when -o dax is specified. Reported-by: Micah Parrish Signed-off-by: Toshi Kani

Re: [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues

On Fri, Apr 29, 2016 at 1:40 PM, Dave Hansen wrote: > On 04/29/2016 01:25 PM, Andy Lutomirski wrote: >> On Fri, Apr 29, 2016 at 1:07 PM, Yu-cheng Yu wrote: >>> On Fri, Apr 29, 2016 at 01:03:43PM -0700, Dave Hansen wrote: That's not feasible. Think of dynamic libraries or just-in-time

[PATCH 1/3] ext4: Add alignment check for DAX mount

When a partition is not aligned by 4KB, mount -o dax succeeds, but any read/write access to the filesystem fails, except for metadata update. Add alignment check to ext4_fill_super() when -o dax is specified. Reported-by: Micah Parrish Signed-off-by: Toshi Kani Cc: "Theodore Ts'o" Cc: Andreas

[PATCH 3/3] xfs: Add alignment check for DAX mount

When a partition is not aligned by 4KB, mount -o dax succeeds, but any read/write access to the filesystem fails, except for metadata update. Add alignment check to xfs_fs_fill_super() when -o dax is specified. Signed-off-by: Toshi Kani Cc: Dave Chinner

[PATCH 3/3] xfs: Add alignment check for DAX mount

When a partition is not aligned by 4KB, mount -o dax succeeds, but any read/write access to the filesystem fails, except for metadata update. Add alignment check to xfs_fs_fill_super() when -o dax is specified. Signed-off-by: Toshi Kani Cc: Dave Chinner (supporter:XFS FILESYSTEM) Cc: Dan

[PATCH 2/3] ext2: Add alignment check for DAX mount

When a partition is not aligned by 4KB, mount -o dax succeeds, but any read/write access to the filesystem fails, except for metadata update. Add alignment check to ext2_fill_super() when -o dax is specified. Signed-off-by: Toshi Kani Cc: Jan Kara Cc: Dan

[PATCH 0/3] Add alignment check for DAX mount

When a partition is not aligned by 4KB, mount -o dax succeeds, but any read/write access to the filesystem fails, except for metadata update. Add alignment check to ext4, ext2, and xfs. --- Toshi Kani (3): 1/3 ext4: Add alignment check for DAX mount 2/3 ext2: Add alignment check for DAX mount

[PATCH 2/3] ext2: Add alignment check for DAX mount

When a partition is not aligned by 4KB, mount -o dax succeeds, but any read/write access to the filesystem fails, except for metadata update. Add alignment check to ext2_fill_super() when -o dax is specified. Signed-off-by: Toshi Kani Cc: Jan Kara Cc: Dan Williams Cc: Ross Zwisler ---

[PATCH 0/3] Add alignment check for DAX mount

When a partition is not aligned by 4KB, mount -o dax succeeds, but any read/write access to the filesystem fails, except for metadata update. Add alignment check to ext4, ext2, and xfs. --- Toshi Kani (3): 1/3 ext4: Add alignment check for DAX mount 2/3 ext2: Add alignment check for DAX mount

Re: [PATCH 26/32] perf/x86/intel/cqm: integrate CQM cgroups with scheduler

Not sure I see the problem you point here. In step 3, PQR_ASSOC is updated with RMID1, __pqr_update is the one called using the scheduler hook, right after perf sched_in . On Fri, Apr 29, 2016 at 1:25 PM, Vikas Shivappa wrote: > > > On Thu, 28 Apr 2016, David

Re: [PATCH 26/32] perf/x86/intel/cqm: integrate CQM cgroups with scheduler

Not sure I see the problem you point here. In step 3, PQR_ASSOC is updated with RMID1, __pqr_update is the one called using the scheduler hook, right after perf sched_in . On Fri, Apr 29, 2016 at 1:25 PM, Vikas Shivappa wrote: > > > On Thu, 28 Apr 2016, David Carrillo-Cisneros wrote: > >> Allow

Re: [PATCH v4 07/10] x86/xsaves: Fix PTRACE frames for XSAVES

On Fri, Apr 29, 2016 at 01:40:51PM -0700, Dave Hansen wrote: > I think we do some instruction patching based on it, so I was just > suggesting the software X86_FEATURE because it would plug in to the > existing scheme easier. Ah ok, that's fine then. -- Regards/Gruss, Boris. SUSE Linux

Re: [PATCH v4 07/10] x86/xsaves: Fix PTRACE frames for XSAVES

On Fri, Apr 29, 2016 at 01:40:51PM -0700, Dave Hansen wrote: > I think we do some instruction patching based on it, so I was just > suggesting the software X86_FEATURE because it would plug in to the > existing scheme easier. Ah ok, that's fine then. -- Regards/Gruss, Boris. SUSE Linux

[PATCH 1/2] ARM: imx_v6_v7_defconfig: add CONFIG_I2C_GPIO

The GPIO-based bitbanging I2C driver is required to make HDMI work on the Apalis iMX6 module plugged into a Ixora carrier board featuring a DDC channel to read a screen's EDID being hooked up to regular GPIOs. Signed-off-by: Marcel Ziswiler ---

[PATCH 1/2] ARM: imx_v6_v7_defconfig: add CONFIG_I2C_GPIO

The GPIO-based bitbanging I2C driver is required to make HDMI work on the Apalis iMX6 module plugged into a Ixora carrier board featuring a DDC channel to read a screen's EDID being hooked up to regular GPIOs. Signed-off-by: Marcel Ziswiler --- arch/arm/configs/imx_v6_v7_defconfig | 1 + 1

Re: [PATCH v4 07/10] x86/xsaves: Fix PTRACE frames for XSAVES

On 04/29/2016 01:38 PM, Borislav Petkov wrote: > On Fri, Apr 29, 2016 at 01:16:59PM -0700, Dave Hansen wrote: >> > We probably want a software X86_FEATURE_OS_XSAVES or something. > ... or a simple variable. I think we do some instruction patching based on it, so I was just suggesting the software

[PATCH 2/2] ARM: imx_v6_v7_defconfig: add CONFIG_MICREL_PHY

The driver for Micrel PHYs is required for the Apalis iMX6 module plugged into a Ixora carrier board featuring an on-module Micrel KSZ9031 Gigabit PHY. Signed-off-by: Marcel Ziswiler --- arch/arm/configs/imx_v6_v7_defconfig | 1 + 1 file changed, 1 insertion(+)

[PATCH 2/2] ARM: imx_v6_v7_defconfig: add CONFIG_MICREL_PHY

The driver for Micrel PHYs is required for the Apalis iMX6 module plugged into a Ixora carrier board featuring an on-module Micrel KSZ9031 Gigabit PHY. Signed-off-by: Marcel Ziswiler --- arch/arm/configs/imx_v6_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git

Re: [PATCH v4 07/10] x86/xsaves: Fix PTRACE frames for XSAVES

On 04/29/2016 01:38 PM, Borislav Petkov wrote: > On Fri, Apr 29, 2016 at 01:16:59PM -0700, Dave Hansen wrote: >> > We probably want a software X86_FEATURE_OS_XSAVES or something. > ... or a simple variable. I think we do some instruction patching based on it, so I was just suggesting the software

Re: [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues

On 04/29/2016 01:25 PM, Andy Lutomirski wrote: > On Fri, Apr 29, 2016 at 1:07 PM, Yu-cheng Yu wrote: >> On Fri, Apr 29, 2016 at 01:03:43PM -0700, Dave Hansen wrote: >>> That's not feasible. Think of dynamic libraries or just-in-time >>> compilers. What instruction set

Re: [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues

On 04/29/2016 01:25 PM, Andy Lutomirski wrote: > On Fri, Apr 29, 2016 at 1:07 PM, Yu-cheng Yu wrote: >> On Fri, Apr 29, 2016 at 01:03:43PM -0700, Dave Hansen wrote: >>> That's not feasible. Think of dynamic libraries or just-in-time >>> compilers. What instruction set does /usr/bin/java use,

Re: [PATCH v4 07/10] x86/xsaves: Fix PTRACE frames for XSAVES

On Fri, Apr 29, 2016 at 01:16:59PM -0700, Dave Hansen wrote: > We probably want a software X86_FEATURE_OS_XSAVES or something. ... or a simple variable. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --

Re: [PATCH v4 07/10] x86/xsaves: Fix PTRACE frames for XSAVES

On Fri, Apr 29, 2016 at 01:16:59PM -0700, Dave Hansen wrote: > We probably want a software X86_FEATURE_OS_XSAVES or something. ... or a simple variable. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --

Re: [PATCH 4/5] crypto: Use dma_pool_zalloc

On Fri, 29 Apr 2016 22:09:11 +0200 Julia Lawall wrote: > Dma_pool_zalloc combines dma_pool_alloc and memset 0. The semantic patch > that makes this transformation is as follows: (http://coccinelle.lip6.fr/) > > // > @@ > expression d,e; > statement S; > @@ > > d

Re: [PATCH 4/5] crypto: Use dma_pool_zalloc

On Fri, 29 Apr 2016 22:09:11 +0200 Julia Lawall wrote: > Dma_pool_zalloc combines dma_pool_alloc and memset 0. The semantic patch > that makes this transformation is as follows: (http://coccinelle.lip6.fr/) > > // > @@ > expression d,e; > statement S; > @@ > > d = > -

Re: [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues

On 04/29/2016 01:07 PM, Yu-cheng Yu wrote: > On Fri, Apr 29, 2016 at 01:03:43PM -0700, Dave Hansen wrote: >>> That's not feasible. Think of dynamic libraries or just-in-time >>> compilers. What instruction set does /usr/bin/java use, for >>> instance? :) > The java argument is true. In that

Re: [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues

On 04/29/2016 01:07 PM, Yu-cheng Yu wrote: > On Fri, Apr 29, 2016 at 01:03:43PM -0700, Dave Hansen wrote: >>> That's not feasible. Think of dynamic libraries or just-in-time >>> compilers. What instruction set does /usr/bin/java use, for >>> instance? :) > The java argument is true. In that

Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking

On Fri, Apr 29, 2016 at 1:27 PM, Josh Poimboeuf wrote: > On Fri, Apr 29, 2016 at 01:19:23PM -0700, Andy Lutomirski wrote: >> On Fri, Apr 29, 2016 at 1:11 PM, Josh Poimboeuf wrote: >> > On Fri, Apr 29, 2016 at 11:06:53AM -0700, Andy Lutomirski wrote: >>

Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking

On Fri, Apr 29, 2016 at 1:27 PM, Josh Poimboeuf wrote: > On Fri, Apr 29, 2016 at 01:19:23PM -0700, Andy Lutomirski wrote: >> On Fri, Apr 29, 2016 at 1:11 PM, Josh Poimboeuf wrote: >> > On Fri, Apr 29, 2016 at 11:06:53AM -0700, Andy Lutomirski wrote: >> >> On Thu, Apr 28, 2016 at 1:44 PM, Josh

Re: [PATCH v4 10/10] x86/xsaves: Re-enable XSAVES

On 03/04/2016 10:12 AM, Yu-cheng Yu wrote: > We did not handle XSAVES* instructions correctly. There were issues in > converting between standard and compacted format when interfacing with > user-space. These issues have been corrected. > > Add a WARN_ONCE() to make it clear that XSAVES

Re: [PATCH v4 10/10] x86/xsaves: Re-enable XSAVES

On 03/04/2016 10:12 AM, Yu-cheng Yu wrote: > We did not handle XSAVES* instructions correctly. There were issues in > converting between standard and compacted format when interfacing with > user-space. These issues have been corrected. > > Add a WARN_ONCE() to make it clear that XSAVES

Re: [RFC PATCH v2 03/18] x86/asm/head: standardize the bottom of the stack for idle tasks

On Fri, Apr 29, 2016 at 02:46:10PM -0400, Brian Gerst wrote: > On Thu, Apr 28, 2016 at 4:44 PM, Josh Poimboeuf wrote: > > Thanks to all the recent x86 entry code refactoring, most tasks' kernel > > stacks start at the same offset right above their saved pt_regs, > >

Re: [RFC PATCH v2 03/18] x86/asm/head: standardize the bottom of the stack for idle tasks

On Fri, Apr 29, 2016 at 02:46:10PM -0400, Brian Gerst wrote: > On Thu, Apr 28, 2016 at 4:44 PM, Josh Poimboeuf wrote: > > Thanks to all the recent x86 entry code refactoring, most tasks' kernel > > stacks start at the same offset right above their saved pt_regs, > > regardless of which syscall

Re: [PATCH v4 09/10] x86/xsaves: Fix xstate_offsets, xstate_sizes for legacy components

On 03/04/2016 10:12 AM, Yu-cheng Yu wrote: > The arrays xstate_offsets[] and xstate_sizes[] record XSAVE area > offsets and sizes. Values for legacy components i387 and XMMs were > not initialized. Fix it. Is this just a completeness thing or does it actually break something? In any case:

Re: [PATCH v4 09/10] x86/xsaves: Fix xstate_offsets, xstate_sizes for legacy components

On 03/04/2016 10:12 AM, Yu-cheng Yu wrote: > The arrays xstate_offsets[] and xstate_sizes[] record XSAVE area > offsets and sizes. Values for legacy components i387 and XMMs were > not initialized. Fix it. Is this just a completeness thing or does it actually break something? In any case:

Re: [PATCH v4 08/10] x86/xsaves: Fix XSTATE component offset print out

On 03/04/2016 10:12 AM, Yu-cheng Yu wrote: > Component offset print out was incorrect for XSAVES. Correct it and move > to a separate function. Reviewed-by: Dave Hansen

Re: [PATCH v4 08/10] x86/xsaves: Fix XSTATE component offset print out

On 03/04/2016 10:12 AM, Yu-cheng Yu wrote: > Component offset print out was incorrect for XSAVES. Correct it and move > to a separate function. Reviewed-by: Dave Hansen

Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking

On Fri, Apr 29, 2016 at 01:19:23PM -0700, Andy Lutomirski wrote: > On Fri, Apr 29, 2016 at 1:11 PM, Josh Poimboeuf wrote: > > On Fri, Apr 29, 2016 at 11:06:53AM -0700, Andy Lutomirski wrote: > >> On Thu, Apr 28, 2016 at 1:44 PM, Josh Poimboeuf > >>

Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking

On Fri, Apr 29, 2016 at 01:19:23PM -0700, Andy Lutomirski wrote: > On Fri, Apr 29, 2016 at 1:11 PM, Josh Poimboeuf wrote: > > On Fri, Apr 29, 2016 at 11:06:53AM -0700, Andy Lutomirski wrote: > >> On Thu, Apr 28, 2016 at 1:44 PM, Josh Poimboeuf > >> wrote: > >> > A preempted function might not

Re: [PATCH 26/32] perf/x86/intel/cqm: integrate CQM cgroups with scheduler

On Thu, 28 Apr 2016, David Carrillo-Cisneros wrote: Allow monitored cgroups to update the PQR MSR during task switch even without an associated perf_event. The package RMID for the current monr associated with a monitored cgroup is written to hw during task switch (after perf_events is run)

[PATCH 1/5] dmaengine: mmp_pdma: Use dma_pool_zalloc

Dma_pool_zalloc combines dma_pool_alloc and memset 0. The semantic patch that makes this transformation is as follows: (http://coccinelle.lip6.fr/) // @@ expression d,e; statement S; @@ d = -dma_pool_alloc +dma_pool_zalloc (...); if (!d) S -

[PATCH 2/5] dmaengine: vdma: Use dma_pool_zalloc

Dma_pool_zalloc combines dma_pool_alloc and memset 0. The semantic patch that makes this transformation is as follows: (http://coccinelle.lip6.fr/) // @@ expression d,e; statement S; @@ d = -dma_pool_alloc +dma_pool_zalloc (...); if (!d) S -

Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation

> On 29 apr. 2016, at 22:06, Bjorn Helgaas wrote: > >> On Fri, Apr 29, 2016 at 03:51:49PM +0200, Ard Biesheuvel wrote: >>> On 29 April 2016 at 15:41, Bjorn Helgaas wrote: On Thu, Apr 28, 2016 at 11:39:35PM +0200, Alexander Graf wrote: On

Re: [PATCH 26/32] perf/x86/intel/cqm: integrate CQM cgroups with scheduler

On Thu, 28 Apr 2016, David Carrillo-Cisneros wrote: Allow monitored cgroups to update the PQR MSR during task switch even without an associated perf_event. The package RMID for the current monr associated with a monitored cgroup is written to hw during task switch (after perf_events is run)

[PATCH 1/5] dmaengine: mmp_pdma: Use dma_pool_zalloc

Dma_pool_zalloc combines dma_pool_alloc and memset 0. The semantic patch that makes this transformation is as follows: (http://coccinelle.lip6.fr/) // @@ expression d,e; statement S; @@ d = -dma_pool_alloc +dma_pool_zalloc (...); if (!d) S -

[PATCH 2/5] dmaengine: vdma: Use dma_pool_zalloc

Dma_pool_zalloc combines dma_pool_alloc and memset 0. The semantic patch that makes this transformation is as follows: (http://coccinelle.lip6.fr/) // @@ expression d,e; statement S; @@ d = -dma_pool_alloc +dma_pool_zalloc (...); if (!d) S -

Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation

> On 29 apr. 2016, at 22:06, Bjorn Helgaas wrote: > >> On Fri, Apr 29, 2016 at 03:51:49PM +0200, Ard Biesheuvel wrote: >>> On 29 April 2016 at 15:41, Bjorn Helgaas wrote: On Thu, Apr 28, 2016 at 11:39:35PM +0200, Alexander Graf wrote: On 28.04.16 20:06, Bjorn Helgaas wrote: > >

Re: [PATCH v4 07/10] x86/xsaves: Fix PTRACE frames for XSAVES

On 03/04/2016 10:12 AM, Yu-cheng Yu wrote: > + for (i = 0; i < XFEATURE_MAX; i++) { > + /* > + * Copy only in-use xstates. > + */ > + if (((header.xfeatures >> i) & 1) && xfeature_enabled(i)) { > + void *src =

Re: [PATCH v4 07/10] x86/xsaves: Fix PTRACE frames for XSAVES

On 03/04/2016 10:12 AM, Yu-cheng Yu wrote: > + for (i = 0; i < XFEATURE_MAX; i++) { > + /* > + * Copy only in-use xstates. > + */ > + if (((header.xfeatures >> i) & 1) && xfeature_enabled(i)) { > + void *src =

Re: [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues

On Fri, Apr 29, 2016 at 1:07 PM, Yu-cheng Yu wrote: > On Fri, Apr 29, 2016 at 01:03:43PM -0700, Dave Hansen wrote: >> That's not feasible. Think of dynamic libraries or just-in-time >> compilers. What instruction set does /usr/bin/java use, for instance? :) > > The java

Re: [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues

On Fri, Apr 29, 2016 at 1:07 PM, Yu-cheng Yu wrote: > On Fri, Apr 29, 2016 at 01:03:43PM -0700, Dave Hansen wrote: >> That's not feasible. Think of dynamic libraries or just-in-time >> compilers. What instruction set does /usr/bin/java use, for instance? :) > > The java argument is true. In

[PATCH 4/5] crypto: Use dma_pool_zalloc

Dma_pool_zalloc combines dma_pool_alloc and memset 0. The semantic patch that makes this transformation is as follows: (http://coccinelle.lip6.fr/) // @@ expression d,e; statement S; @@ d = -dma_pool_alloc +dma_pool_zalloc (...); if (!d) S -

[PATCH 3/5] dmaengine: ioatdma: Use dma_pool_zalloc

Dma_pool_zalloc combines dma_pool_alloc and memset 0. The semantic patch that makes this transformation is as follows: (http://coccinelle.lip6.fr/) // @@ expression d,e; statement S; @@ d = -dma_pool_alloc +dma_pool_zalloc (...); if (!d) S -

[PATCH 4/5] crypto: Use dma_pool_zalloc

Dma_pool_zalloc combines dma_pool_alloc and memset 0. The semantic patch that makes this transformation is as follows: (http://coccinelle.lip6.fr/) // @@ expression d,e; statement S; @@ d = -dma_pool_alloc +dma_pool_zalloc (...); if (!d) S -

[PATCH 3/5] dmaengine: ioatdma: Use dma_pool_zalloc

Dma_pool_zalloc combines dma_pool_alloc and memset 0. The semantic patch that makes this transformation is as follows: (http://coccinelle.lip6.fr/) // @@ expression d,e; statement S; @@ d = -dma_pool_alloc +dma_pool_zalloc (...); if (!d) S -

[PATCH 0/5] Use dma_pool_zalloc

Dma_pool_zalloc combines dma_pool_alloc and memset 0. The semantic patch that makes this transformation is as follows: (http://coccinelle.lip6.fr/) // @@ type T; T *d; expression e; statement S; @@ d = -dma_pool_alloc +dma_pool_zalloc (...);

[PATCH 5/5] dmaengine: fsldma: Use dma_pool_zalloc

Dma_pool_zalloc combines dma_pool_alloc and memset 0. The semantic patch that makes this transformation is as follows: (http://coccinelle.lip6.fr/) // @@ expression d,e; statement S; @@ d = -dma_pool_alloc +dma_pool_zalloc (...); if (!d) S -

[PATCH 0/5] Use dma_pool_zalloc

Dma_pool_zalloc combines dma_pool_alloc and memset 0. The semantic patch that makes this transformation is as follows: (http://coccinelle.lip6.fr/) // @@ type T; T *d; expression e; statement S; @@ d = -dma_pool_alloc +dma_pool_zalloc (...);

[PATCH 5/5] dmaengine: fsldma: Use dma_pool_zalloc

Dma_pool_zalloc combines dma_pool_alloc and memset 0. The semantic patch that makes this transformation is as follows: (http://coccinelle.lip6.fr/) // @@ expression d,e; statement S; @@ d = -dma_pool_alloc +dma_pool_zalloc (...); if (!d) S -

[PATCH] ARM: dts: imx6: apalis: parallel lcd display support on ixora

Add parallel LCD display support for the EDT ET057090DHU 5.7" LCD TFT panel. Signed-off-by: Marcel Ziswiler --- arch/arm/boot/dts/imx6q-apalis-ixora.dts | 45 1 file changed, 45 insertions(+) diff --git

[PATCH] ARM: dts: imx6: apalis: parallel lcd display support on ixora

Add parallel LCD display support for the EDT ET057090DHU 5.7" LCD TFT panel. Signed-off-by: Marcel Ziswiler --- arch/arm/boot/dts/imx6q-apalis-ixora.dts | 45 1 file changed, 45 insertions(+) diff --git a/arch/arm/boot/dts/imx6q-apalis-ixora.dts

Re: [PATCH 25/32] sched: introduce the finish_arch_pre_lock_switch() scheduler hook

On Fri, 29 Apr 2016, David Carrillo-Cisneros wrote: (Re-sending in plain text) This hook is used in the following patch in the series to write to PQR_ASSOC_MSR, a msr that is utilized both by CQM/CMT and by CAT. Since CAT is not dependent on perf, I created this hook to start CQM monitoring

Re: [PATCH 25/32] sched: introduce the finish_arch_pre_lock_switch() scheduler hook

On Fri, 29 Apr 2016, David Carrillo-Cisneros wrote: (Re-sending in plain text) This hook is used in the following patch in the series to write to PQR_ASSOC_MSR, a msr that is utilized both by CQM/CMT and by CAT. Since CAT is not dependent on perf, I created this hook to start CQM monitoring

Re: [PATCH 01/32] perf/x86/intel/cqm: temporarily remove MBM from CQM and cleanup

On Thu, 28 Apr 2016, David Carrillo-Cisneros wrote: Removing MBM code from arch/x86/events/intel/cqm.c. MBM will be added using the new RMID infrastucture introduced in this patch series. I am still working on to rebase mbm on top of the new cqm series (probably with the new quick fixes i

Re: [PATCH 01/32] perf/x86/intel/cqm: temporarily remove MBM from CQM and cleanup

On Thu, 28 Apr 2016, David Carrillo-Cisneros wrote: Removing MBM code from arch/x86/events/intel/cqm.c. MBM will be added using the new RMID infrastucture introduced in this patch series. I am still working on to rebase mbm on top of the new cqm series (probably with the new quick fixes i

Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking

On Fri, Apr 29, 2016 at 1:11 PM, Josh Poimboeuf wrote: > On Fri, Apr 29, 2016 at 11:06:53AM -0700, Andy Lutomirski wrote: >> On Thu, Apr 28, 2016 at 1:44 PM, Josh Poimboeuf wrote: >> > A preempted function might not have had a chance to save the frame >>

Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking

On Fri, Apr 29, 2016 at 1:11 PM, Josh Poimboeuf wrote: > On Fri, Apr 29, 2016 at 11:06:53AM -0700, Andy Lutomirski wrote: >> On Thu, Apr 28, 2016 at 1:44 PM, Josh Poimboeuf wrote: >> > A preempted function might not have had a chance to save the frame >> > pointer to the stack yet, which can

Re: [PATCH v2 3/3] ACPI/device_sysfs: Clean up checkpatch errors

On Fri, Apr 29, 2016 at 9:21 PM, Betty Dall wrote: > Cleaning up five existing checkpatch errors in device_sysfs.c since the > file is being changed. > > Signed-off-by: Betty Dall > --- > drivers/acpi/device_sysfs.c | 22 ++ > 1 file

Re: [PATCH v2 3/3] ACPI/device_sysfs: Clean up checkpatch errors

On Fri, Apr 29, 2016 at 9:21 PM, Betty Dall wrote: > Cleaning up five existing checkpatch errors in device_sysfs.c since the > file is being changed. > > Signed-off-by: Betty Dall > --- > drivers/acpi/device_sysfs.c | 22 ++ > 1 file changed, 14 insertions(+), 8 deletions(-)

Re: [RFC PATCH v2 09/18] livepatch/x86: add TIF_PATCH_PENDING thread flag

On Fri, Apr 29, 2016 at 11:08:04AM -0700, Andy Lutomirski wrote: > On Thu, Apr 28, 2016 at 1:44 PM, Josh Poimboeuf wrote: > > Add the TIF_PATCH_PENDING thread flag to enable the new livepatch > > per-task consistency model for x86_64. The bit getting set indicates > > the

Re: [RFC PATCH v2 09/18] livepatch/x86: add TIF_PATCH_PENDING thread flag

On Fri, Apr 29, 2016 at 11:08:04AM -0700, Andy Lutomirski wrote: > On Thu, Apr 28, 2016 at 1:44 PM, Josh Poimboeuf wrote: > > Add the TIF_PATCH_PENDING thread flag to enable the new livepatch > > per-task consistency model for x86_64. The bit getting set indicates > > the thread has a pending

Re: [PATCH 0/6] Intel Secure Guard Extensions

On Tue, Apr 26, 2016 at 09:00:10PM +0200, Pavel Machek wrote: > On Mon 2016-04-25 20:34:07, Jarkko Sakkinen wrote: > > Intel(R) SGX is a set of CPU instructions that can be used by > > applications to set aside private regions of code and data. The code > > outside the enclave is disallowed to

Re: [PATCH 0/6] Intel Secure Guard Extensions

On Tue, Apr 26, 2016 at 09:00:10PM +0200, Pavel Machek wrote: > On Mon 2016-04-25 20:34:07, Jarkko Sakkinen wrote: > > Intel(R) SGX is a set of CPU instructions that can be used by > > applications to set aside private regions of code and data. The code > > outside the enclave is disallowed to

Re: [PATCH v4 07/10] x86/xsaves: Fix PTRACE frames for XSAVES

On 03/04/2016 10:12 AM, Yu-cheng Yu wrote: > + if (boot_cpu_has(X86_FEATURE_XSAVES)) { > + ret = copyout_from_xsaves(pos, count, kbuf, ubuf, xsave); On a higher level, we really should stop using "boot_cpu_has(X86_FEATURE_XSAVES)" as a proxy for "the kernel XSAVE buffer is in the

Re: [PATCH v4 07/10] x86/xsaves: Fix PTRACE frames for XSAVES

On 03/04/2016 10:12 AM, Yu-cheng Yu wrote: > + if (boot_cpu_has(X86_FEATURE_XSAVES)) { > + ret = copyout_from_xsaves(pos, count, kbuf, ubuf, xsave); On a higher level, we really should stop using "boot_cpu_has(X86_FEATURE_XSAVES)" as a proxy for "the kernel XSAVE buffer is in the

Re: [PATCH v4 05/10] x86/xsaves: Align xstate components according to CPUID

On 03/04/2016 10:12 AM, Yu-cheng Yu wrote: > CPUID function 0x0d, sub function (i, i > 1) returns in ecx[1] the > alignment requirement of component i when the compacted format is used. > > If ecx[1] is 0, component i is located immediately following the preceding > component. If ecx[1] is 1,

Re: [PATCH v4 05/10] x86/xsaves: Align xstate components according to CPUID

On 03/04/2016 10:12 AM, Yu-cheng Yu wrote: > CPUID function 0x0d, sub function (i, i > 1) returns in ecx[1] the > alignment requirement of component i when the compacted format is used. > > If ecx[1] is 0, component i is located immediately following the preceding > component. If ecx[1] is 1,

Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking

On Fri, Apr 29, 2016 at 11:06:53AM -0700, Andy Lutomirski wrote: > On Thu, Apr 28, 2016 at 1:44 PM, Josh Poimboeuf wrote: > > A preempted function might not have had a chance to save the frame > > pointer to the stack yet, which can result in its caller getting skipped > > on

Re: [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues

On Fri, Apr 29, 2016 at 01:03:43PM -0700, Dave Hansen wrote: > That's not feasible. Think of dynamic libraries or just-in-time > compilers. What instruction set does /usr/bin/java use, for instance? :) The java argument is true. In that case or when the bitmask is missing, we can allocate for

Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking

On Fri, Apr 29, 2016 at 11:06:53AM -0700, Andy Lutomirski wrote: > On Thu, Apr 28, 2016 at 1:44 PM, Josh Poimboeuf wrote: > > A preempted function might not have had a chance to save the frame > > pointer to the stack yet, which can result in its caller getting skipped > > on a stack trace. > > >

Re: [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues

On Fri, Apr 29, 2016 at 01:03:43PM -0700, Dave Hansen wrote: > That's not feasible. Think of dynamic libraries or just-in-time > compilers. What instruction set does /usr/bin/java use, for instance? :) The java argument is true. In that case or when the bitmask is missing, we can allocate for

Re: [PATCH v4 04/10] x86/xsaves: Introduce a new check that allows correct xstates copy from kernel to user directly

On 03/04/2016 10:12 AM, Yu-cheng Yu wrote: > diff --git a/arch/x86/kernel/fpu/signal.c b/arch/x86/kernel/fpu/signal.c > index 0fbf60c..09945f1 100644 > --- a/arch/x86/kernel/fpu/signal.c > +++ b/arch/x86/kernel/fpu/signal.c > @@ -130,6 +130,45 @@ static inline int copy_fpregs_to_sigframe(struct >

Re: [PATCH v4 04/10] x86/xsaves: Introduce a new check that allows correct xstates copy from kernel to user directly

On 03/04/2016 10:12 AM, Yu-cheng Yu wrote: > diff --git a/arch/x86/kernel/fpu/signal.c b/arch/x86/kernel/fpu/signal.c > index 0fbf60c..09945f1 100644 > --- a/arch/x86/kernel/fpu/signal.c > +++ b/arch/x86/kernel/fpu/signal.c > @@ -130,6 +130,45 @@ static inline int copy_fpregs_to_sigframe(struct >

Re: random(4) changes

> What I am saying that the bits in one given time stamp are mutually > independent. I.e. bit 0 of one time stamp does not depend on bit 1 of that > very same time stamp. And I'm saying that's wrong. We are interested in the correlation from the point of view of someone who knows all previous

Re: random(4) changes

> What I am saying that the bits in one given time stamp are mutually > independent. I.e. bit 0 of one time stamp does not depend on bit 1 of that > very same time stamp. And I'm saying that's wrong. We are interested in the correlation from the point of view of someone who knows all previous

Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation

On Fri, Apr 29, 2016 at 03:51:49PM +0200, Ard Biesheuvel wrote: > On 29 April 2016 at 15:41, Bjorn Helgaas wrote: > > On Thu, Apr 28, 2016 at 11:39:35PM +0200, Alexander Graf wrote: > >> On 28.04.16 20:06, Bjorn Helgaas wrote: > >> > If firmware is giving us a bare address of

Re: Nokia N900 retention mode in v4.6, camera buttons fun

Hi, On Thu, Apr 21, 2016 at 03:04:50PM +0200, Pali Rohár wrote: > > CONFIG_HSI breaks power management completely, so power management > > with modem will be another topic. > > Sebastian, any idea why power management does not work for HSI? I wasn't aware, that pm_runtime_irq_safe() basically

Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation

On Fri, Apr 29, 2016 at 03:51:49PM +0200, Ard Biesheuvel wrote: > On 29 April 2016 at 15:41, Bjorn Helgaas wrote: > > On Thu, Apr 28, 2016 at 11:39:35PM +0200, Alexander Graf wrote: > >> On 28.04.16 20:06, Bjorn Helgaas wrote: > >> > If firmware is giving us a bare address of something, that

Re: Nokia N900 retention mode in v4.6, camera buttons fun

Hi, On Thu, Apr 21, 2016 at 03:04:50PM +0200, Pali Rohár wrote: > > CONFIG_HSI breaks power management completely, so power management > > with modem will be another topic. > > Sebastian, any idea why power management does not work for HSI? I wasn't aware, that pm_runtime_irq_safe() basically

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

Russell, On Fri, Apr 29, 2016 at 12:57 PM, Russell King - ARM Linux wrote: >> * Presumably on a PC you've got an extra bit in the middle (like grub >> or something like that) that can help you resolve your UUIDs even if >> you get your kernel from somewhere else. > > You

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

Russell, On Fri, Apr 29, 2016 at 12:57 PM, Russell King - ARM Linux wrote: >> * Presumably on a PC you've got an extra bit in the middle (like grub >> or something like that) that can help you resolve your UUIDs even if >> you get your kernel from somewhere else. > > You are over-estimating what

Re: [PATCH 3/6] intel_sgx: driver for Intel Secure Guard eXtensions

On Wed, Apr 27, 2016 at 04:32:23PM -0700, Jethro Beekman wrote: > On 27-04-16 05:40, Jarkko Sakkinen wrote: > >> The hardware supports calling EEXTEND on only a part of a page, I think the > >> driver should also support that. > > > > Why would you want to do that? > > You might have segments in

Re: [PATCH 3/6] intel_sgx: driver for Intel Secure Guard eXtensions

On Wed, Apr 27, 2016 at 04:32:23PM -0700, Jethro Beekman wrote: > On 27-04-16 05:40, Jarkko Sakkinen wrote: > >> The hardware supports calling EEXTEND on only a part of a page, I think the > >> driver should also support that. > > > > Why would you want to do that? > > You might have segments in

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