RE: [PATCH v2 1/2] Documentation: DT: vdma: Add clock support for vdma

Hi Rob, Thanks for the review... > -Original Message- > From: Rob Herring [mailto:r...@kernel.org] > Sent: Saturday, April 23, 2016 1:07 AM > To: Appana Durga Kedareswara Rao > Cc: pawel.m...@arm.com; mark.rutl...@arm.com; > ijc+devicet...@hellion.org.uk;

RE: [PATCH v2 1/2] Documentation: DT: vdma: Add clock support for vdma

Hi Rob, Thanks for the review... > -Original Message- > From: Rob Herring [mailto:r...@kernel.org] > Sent: Saturday, April 23, 2016 1:07 AM > To: Appana Durga Kedareswara Rao > Cc: pawel.m...@arm.com; mark.rutl...@arm.com; > ijc+devicet...@hellion.org.uk; ga...@codeaurora.org;

Re: [PATCH 4/8] firmware: qcom: scm: Add support for ARM64 SoCs

On Fri, Apr 22, 2016 at 04:41:05PM -0700, Bjorn Andersson wrote: > On Fri 22 Apr 15:17 PDT 2016, Andy Gross wrote: > > [..] > > diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c > [..] > > + > > +/** > > + * struct qcom_scm_desc > > + * @arginfo: Metadata describing the

Re: [PATCH 4/8] firmware: qcom: scm: Add support for ARM64 SoCs

On Fri, Apr 22, 2016 at 04:41:05PM -0700, Bjorn Andersson wrote: > On Fri 22 Apr 15:17 PDT 2016, Andy Gross wrote: > > [..] > > diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c > [..] > > + > > +/** > > + * struct qcom_scm_desc > > + * @arginfo: Metadata describing the

Re: Warning triggered by lockdep checks for sock_owned_by_user on linux-next-20160420

On Fri, 2016-04-22 at 21:02 -0700, Shi, Yang wrote: > Hi David, > > When I ran some test on a nfs mounted rootfs, I got the below warning > with LOCKDEP enabled on linux-next-20160420: > > WARNING: CPU: 9 PID: 0 at include/net/sock.h:1408 > udp_queue_rcv_skb+0x3d0/0x660 > Modules linked in: >

Re: Warning triggered by lockdep checks for sock_owned_by_user on linux-next-20160420

On Fri, 2016-04-22 at 21:02 -0700, Shi, Yang wrote: > Hi David, > > When I ran some test on a nfs mounted rootfs, I got the below warning > with LOCKDEP enabled on linux-next-20160420: > > WARNING: CPU: 9 PID: 0 at include/net/sock.h:1408 > udp_queue_rcv_skb+0x3d0/0x660 > Modules linked in: >

Re: [PATCH 5/8] firmware: qcom: scm: Use atomic SCM for cold boot

On Fri, Apr 22, 2016 at 04:50:05PM -0700, Bjorn Andersson wrote: > On Fri 22 Apr 15:17 PDT 2016, Andy Gross wrote: > > > This patch changes the cold_set_boot_addr function to use atomic SCM > > calls. This removes the need for memory allocation and instead places > > all arguments in registers.

Re: [PATCH 5/8] firmware: qcom: scm: Use atomic SCM for cold boot

On Fri, Apr 22, 2016 at 04:50:05PM -0700, Bjorn Andersson wrote: > On Fri 22 Apr 15:17 PDT 2016, Andy Gross wrote: > > > This patch changes the cold_set_boot_addr function to use atomic SCM > > calls. This removes the need for memory allocation and instead places > > all arguments in registers.

Re: [PATCH 6/8] firmware: qcom: scm: Add memory allocation API

On Fri, Apr 22, 2016 at 04:23:31PM -0700, Bjorn Andersson wrote: > On Fri 22 Apr 15:17 PDT 2016, Andy Gross wrote: > > > This patch adds APIs for the scm-32 and scm-64 to use for coherent memory > > allocation. > > > > Signed-off-by: Andy Gross > > This patch must come

Re: [PATCH 6/8] firmware: qcom: scm: Add memory allocation API

On Fri, Apr 22, 2016 at 04:23:31PM -0700, Bjorn Andersson wrote: > On Fri 22 Apr 15:17 PDT 2016, Andy Gross wrote: > > > This patch adds APIs for the scm-32 and scm-64 to use for coherent memory > > allocation. > > > > Signed-off-by: Andy Gross > > This patch must come before the ARM64

Re: [PATCH 2/8] firmware: qcom: scm: Convert SCM to platform driver

On Fri, Apr 22, 2016 at 04:11:11PM -0700, Bjorn Andersson wrote: > On Fri 22 Apr 15:17 PDT 2016, Andy Gross wrote: > > [..] > > diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c > [..] > > +static struct qcom_scm *__scm; > > + > > +static int qcom_scm_clk_enable(void) > > +{

Re: [PATCH 2/8] firmware: qcom: scm: Convert SCM to platform driver

On Fri, Apr 22, 2016 at 04:11:11PM -0700, Bjorn Andersson wrote: > On Fri 22 Apr 15:17 PDT 2016, Andy Gross wrote: > > [..] > > diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c > [..] > > +static struct qcom_scm *__scm; > > + > > +static int qcom_scm_clk_enable(void) > > +{

Re: [PATCH 2/5] perf script: extend db-export api to include callchains for samples

On 04/22/2016 12:56 AM, Adrian Hunter wrote: The call_paths table already has symbol_id which belongs uniquely to a DSO, so why do we need dso_id as well? If the symbol_id is 0 because the IP could not be resolved to a symbol, this is not necessarily a valid assumption. Without a dso_id in

Re: [PATCH 2/5] perf script: extend db-export api to include callchains for samples

On 04/22/2016 12:56 AM, Adrian Hunter wrote: The call_paths table already has symbol_id which belongs uniquely to a DSO, so why do we need dso_id as well? If the symbol_id is 0 because the IP could not be resolved to a symbol, this is not necessarily a valid assumption. Without a dso_id in

[linux-next PATCH] sched: cgroup: enable interrupt before calling threadgroup_change_begin

When kernel oops happens in some kernel thread, i.e. kcompactd in the test, the below bug might be triggered by the oops handler: BUG: sleeping function called from invalid context at include/linux/sched.h:2858 in_atomic(): 0, irqs_disabled(): 1, pid: 110, name: kcompactd0 CPU: 6 PID: 110 Comm:

[linux-next PATCH] sched: cgroup: enable interrupt before calling threadgroup_change_begin

When kernel oops happens in some kernel thread, i.e. kcompactd in the test, the below bug might be triggered by the oops handler: BUG: sleeping function called from invalid context at include/linux/sched.h:2858 in_atomic(): 0, irqs_disabled(): 1, pid: 110, name: kcompactd0 CPU: 6 PID: 110 Comm:

Warning triggered by lockdep checks for sock_owned_by_user on linux-next-20160420

Hi David, When I ran some test on a nfs mounted rootfs, I got the below warning with LOCKDEP enabled on linux-next-20160420: WARNING: CPU: 9 PID: 0 at include/net/sock.h:1408 udp_queue_rcv_skb+0x3d0/0x660 Modules linked in: CPU: 9 PID: 0 Comm: swapper/9 Tainted: G D

Warning triggered by lockdep checks for sock_owned_by_user on linux-next-20160420

Hi David, When I ran some test on a nfs mounted rootfs, I got the below warning with LOCKDEP enabled on linux-next-20160420: WARNING: CPU: 9 PID: 0 at include/net/sock.h:1408 udp_queue_rcv_skb+0x3d0/0x660 Modules linked in: CPU: 9 PID: 0 Comm: swapper/9 Tainted: G D

Re: [RFC][PATCH 3/3] locking,arm64: Introduce cmpwait()

On Fri, Apr 22, 2016 at 05:53:11PM +0100, Will Deacon wrote: > On Sat, Apr 23, 2016 at 12:08:57AM +0800, Boqun Feng wrote: > > On Tue, Apr 12, 2016 at 05:59:41PM +0100, Will Deacon wrote: > > [...] > > > > +static inline void __cmpwait(volatile void *ptr, unsigned long val, > > > > int size) > >

Re: [RFC][PATCH 3/3] locking,arm64: Introduce cmpwait()

On Fri, Apr 22, 2016 at 05:53:11PM +0100, Will Deacon wrote: > On Sat, Apr 23, 2016 at 12:08:57AM +0800, Boqun Feng wrote: > > On Tue, Apr 12, 2016 at 05:59:41PM +0100, Will Deacon wrote: > > [...] > > > > +static inline void __cmpwait(volatile void *ptr, unsigned long val, > > > > int size) > >

Re: [PATCH v5 4/4] printk/nmi: flush NMI messages on the system panic

Hello Petr, On (04/21/16 13:48), Petr Mladek wrote: > extern void printk_nmi_flush(void); > +extern void printk_nmi_flush_on_panic(void); > #else > static inline void printk_nmi_flush(void) { } > +static inline void printk_nmi_flush_on_panic(void) { } [..] > +void

Re: [PATCH v5 4/4] printk/nmi: flush NMI messages on the system panic

Hello Petr, On (04/21/16 13:48), Petr Mladek wrote: > extern void printk_nmi_flush(void); > +extern void printk_nmi_flush_on_panic(void); > #else > static inline void printk_nmi_flush(void) { } > +static inline void printk_nmi_flush_on_panic(void) { } [..] > +void

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64 - LTP results

Hi, Yury On 2016/4/6 6:44, Yury Norov wrote: There are about 20 failing tests of 782 in lite scenario. float_bessel float_exp_log float_iperb float_power float_trigo pipeio_1 pipeio_3 pipeio_5 pipeio_8 abort01 clone02 kill11 mmap16 open12 pause01 rename11 rmdir02 umount2_01 umount2_02

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64 - LTP results

Hi, Yury On 2016/4/6 6:44, Yury Norov wrote: There are about 20 failing tests of 782 in lite scenario. float_bessel float_exp_log float_iperb float_power float_trigo pipeio_1 pipeio_3 pipeio_5 pipeio_8 abort01 clone02 kill11 mmap16 open12 pause01 rename11 rmdir02 umount2_01 umount2_02

Re: [RFC][PATCH 3/3] locking,arm64: Introduce cmpwait()

On Sat, Apr 23, 2016 at 04:37:36AM +0200, Peter Zijlstra wrote: > On Sat, Apr 23, 2016 at 12:08:57AM +0800, Boqun Feng wrote: > > How about replace smp_rmb() with a smp_acquire_barrier__after_cmpwait()? > > This barrier is designed to provide an ACQUIRE ordering when combining a > > cmpwait() . >

Re: [RFC][PATCH 3/3] locking,arm64: Introduce cmpwait()

On Sat, Apr 23, 2016 at 04:37:36AM +0200, Peter Zijlstra wrote: > On Sat, Apr 23, 2016 at 12:08:57AM +0800, Boqun Feng wrote: > > How about replace smp_rmb() with a smp_acquire_barrier__after_cmpwait()? > > This barrier is designed to provide an ACQUIRE ordering when combining a > > cmpwait() . >

Re: [PATCH 1/5] perf tools: fix incorrect ordering of callchain entries

Modifying perf script to print call trees in the opposite order or applying patch 2 from this series and comparing the results output from export-to-postgtresql.py are the easiest ways to see the bug, however it can still be seen in current builds using perf report. Here is how i can

Re: [PATCH 1/5] perf tools: fix incorrect ordering of callchain entries

Modifying perf script to print call trees in the opposite order or applying patch 2 from this series and comparing the results output from export-to-postgtresql.py are the easiest ways to see the bug, however it can still be seen in current builds using perf report. Here is how i can

Re: [RFC][PATCH 00/31] implement atomic_fetch_$op

On Fri, Apr 22, 2016 at 09:35:06PM +0300, Kalle Valo wrote: > Fengguang Wu writes: > > >> OK, weirdness. I received the "BUILD SUCCESS" email without any arm64 > >> builds listed, but I just received a build bot email telling me the > >> arm64 build was borked (which I

Re: [RFC][PATCH 00/31] implement atomic_fetch_$op

On Fri, Apr 22, 2016 at 09:35:06PM +0300, Kalle Valo wrote: > Fengguang Wu writes: > > >> OK, weirdness. I received the "BUILD SUCCESS" email without any arm64 > >> builds listed, but I just received a build bot email telling me the > >> arm64 build was borked (which I know it is). > > > >

Re: [RFC][PATCH 3/3] locking,arm64: Introduce cmpwait()

On Sat, Apr 23, 2016 at 12:08:57AM +0800, Boqun Feng wrote: > How about replace smp_rmb() with a smp_acquire_barrier__after_cmpwait()? > This barrier is designed to provide an ACQUIRE ordering when combining a > cmpwait() . That's a horrible name for a barrier :-) > And cmpwait() only has

Re: [RFC][PATCH 3/3] locking,arm64: Introduce cmpwait()

On Sat, Apr 23, 2016 at 12:08:57AM +0800, Boqun Feng wrote: > How about replace smp_rmb() with a smp_acquire_barrier__after_cmpwait()? > This barrier is designed to provide an ACQUIRE ordering when combining a > cmpwait() . That's a horrible name for a barrier :-) > And cmpwait() only has

Re: [PATCH 12/25] arm64: compat: change config dependences to aarch32

Hi, Yury On 2016/4/23 5:59, Yury Norov wrote: On Fri, Apr 22, 2016 at 04:58:18PM +0100, Catalin Marinas wrote: On Wed, Apr 06, 2016 at 01:08:34AM +0300, Yury Norov wrote: From: Bamvor Jian Zhang With the patches of ILP32, COMPAT is not equivalent to AARCH32 in

Re: [PATCH 12/25] arm64: compat: change config dependences to aarch32

Hi, Yury On 2016/4/23 5:59, Yury Norov wrote: On Fri, Apr 22, 2016 at 04:58:18PM +0100, Catalin Marinas wrote: On Wed, Apr 06, 2016 at 01:08:34AM +0300, Yury Norov wrote: From: Bamvor Jian Zhang With the patches of ILP32, COMPAT is not equivalent to AARCH32 in EL0. This patch fix this by

Re: [RFC][PATCH 18/31] locking,powerpc: Implement atomic{,64}_fetch_{add,sub,and,or,xor}{,_relaxed,_acquire,_release}()

On Sat, Apr 23, 2016 at 12:41:57AM +0800, Boqun Feng wrote: > > +#define ATOMIC_FETCH_OP_RELAXED(op, asm_op) > > \ > > +static inline int atomic_fetch_##op##_relaxed(int a, atomic_t *v) \ > > +{ \ > >

Re: [RFC][PATCH 18/31] locking,powerpc: Implement atomic{,64}_fetch_{add,sub,and,or,xor}{,_relaxed,_acquire,_release}()

On Sat, Apr 23, 2016 at 12:41:57AM +0800, Boqun Feng wrote: > > +#define ATOMIC_FETCH_OP_RELAXED(op, asm_op) > > \ > > +static inline int atomic_fetch_##op##_relaxed(int a, atomic_t *v) \ > > +{ \ > >

[PATCH] MAINTAINERS: Update the file list for the NCR 5380 entry

The file atari_NCR5380.c has been removed from the tree so remove it from the MAINTAINERS file as well. While we are here, add the file dtc3x80.txt as it is only relevant to the dtc driver. Signed-off-by: Finn Thain --- The patch which removed atari_NCR5380.c is

[PATCH] MAINTAINERS: Update the file list for the NCR 5380 entry

The file atari_NCR5380.c has been removed from the tree so remove it from the MAINTAINERS file as well. While we are here, add the file dtc3x80.txt as it is only relevant to the dtc driver. Signed-off-by: Finn Thain --- The patch which removed atari_NCR5380.c is queued in jejb-scsi/for-next

Re: [RFC][PATCH 10/31] locking,hexagon: Implement atomic_fetch_{add,sub,and,or,xor}()

On Fri, Apr 22, 2016 at 11:04:23AM +0200, Peter Zijlstra wrote: > +#define ATOMIC_FETCH_OP(op) \ > +static inline int atomic_fetch_##op(int i, atomic_t *v) > \ > +{\ >

Re: [PATCH] NBD: replace kill_bdev() with __invalidate_device()

Thanks for the review. Atleast for ext4 this crash happens on a sys_umount() call, timing of which is not in control of block driver. Block driver cannot force the filesystems to be unmounted, and the file system does not expect buffers to get unmapped under it. Ext4 can be fixed with the this

Re: [RFC][PATCH 10/31] locking,hexagon: Implement atomic_fetch_{add,sub,and,or,xor}()

On Fri, Apr 22, 2016 at 11:04:23AM +0200, Peter Zijlstra wrote: > +#define ATOMIC_FETCH_OP(op) \ > +static inline int atomic_fetch_##op(int i, atomic_t *v) > \ > +{\ >

Re: [PATCH] NBD: replace kill_bdev() with __invalidate_device()

Thanks for the review. Atleast for ext4 this crash happens on a sys_umount() call, timing of which is not in control of block driver. Block driver cannot force the filesystems to be unmounted, and the file system does not expect buffers to get unmapped under it. Ext4 can be fixed with the this

Re: [regression] linux318, linux41 - kernel stack is corrupted

On 04/22/2016 06:16 AM, Mike Galbraith wrote: > On Fri, 2016-04-22 at 17:23 +0900, Greg Kroah-Hartman wrote: >> On Fri, Apr 22, 2016 at 10:10:59AM +0200, Sebastian M. Bobrecki wrote: >>> W dniu 22.04.2016 o 09:55, Greg Kroah-Hartman pisze: On Fri, Apr 22, 2016 at 09:47:04AM +0200, Sebastian

Re: [regression] linux318, linux41 - kernel stack is corrupted

On 04/22/2016 06:16 AM, Mike Galbraith wrote: > On Fri, 2016-04-22 at 17:23 +0900, Greg Kroah-Hartman wrote: >> On Fri, Apr 22, 2016 at 10:10:59AM +0200, Sebastian M. Bobrecki wrote: >>> W dniu 22.04.2016 o 09:55, Greg Kroah-Hartman pisze: On Fri, Apr 22, 2016 at 09:47:04AM +0200, Sebastian

Re: [RFC][PATCH 00/31] implement atomic_fetch_$op

On Fri, Apr 22, 2016 at 04:23:03PM +0200, Peter Zijlstra wrote: > On Fri, Apr 22, 2016 at 08:56:56PM +0800, Fengguang Wu wrote: > > I'll add arm64-defconfig to P1 list to improve its coverage. > > Thanks; any more architectures missing from P1? Good question! Just double checked and find s390

Re: [RFC][PATCH 00/31] implement atomic_fetch_$op

On Fri, Apr 22, 2016 at 04:23:03PM +0200, Peter Zijlstra wrote: > On Fri, Apr 22, 2016 at 08:56:56PM +0800, Fengguang Wu wrote: > > I'll add arm64-defconfig to P1 list to improve its coverage. > > Thanks; any more architectures missing from P1? Good question! Just double checked and find s390

Re: [RFC][PATCH 02/31] locking,alpha: Implement atomic{,64}_fetch_{add,sub,and,andnot,or,xor}()

On Fri, Apr 22, 2016 at 09:57:04AM -0700, Richard Henderson wrote: > On 04/22/2016 02:04 AM, Peter Zijlstra wrote: > > + "1: ldl_l %0,%1\n" \ > > + " mov %0,%2\n"\ > > + " " #asm_op "

Re: [RFC][PATCH 02/31] locking,alpha: Implement atomic{,64}_fetch_{add,sub,and,andnot,or,xor}()

On Fri, Apr 22, 2016 at 09:57:04AM -0700, Richard Henderson wrote: > On 04/22/2016 02:04 AM, Peter Zijlstra wrote: > > + "1: ldl_l %0,%1\n" \ > > + " mov %0,%2\n"\ > > + " " #asm_op "

RE: SATA hot unplug question

Forwarding to mailing list. I think this is useful info so I like to share. -Original Message- From: Tejun Heo [mailto:hte...@gmail.com] On Behalf Of Tejun Heo Sent: Friday, April 22, 2016 1:29 PM To: m...@mkp.net; Soohoon Lee Cc: Ben Hutchings; Arnd Bergmann Subject: Re: SATA hot unplug

RE: SATA hot unplug question

Forwarding to mailing list. I think this is useful info so I like to share. -Original Message- From: Tejun Heo [mailto:hte...@gmail.com] On Behalf Of Tejun Heo Sent: Friday, April 22, 2016 1:29 PM To: m...@mkp.net; Soohoon Lee Cc: Ben Hutchings; Arnd Bergmann Subject: Re: SATA hot unplug

RE: [PATCH] tools: hv: lsvmbus: add pci pass-through UUID

> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > Sent: Saturday, April 23, 2016 0:21 > To: de...@linuxdriverproject.org > Cc: linux-kernel@vger.kernel.org; KY Srinivasan ; Haiyang > Zhang ; Dexuan Cui > Subject: [PATCH]

RE: [PATCH] tools: hv: lsvmbus: add pci pass-through UUID

> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > Sent: Saturday, April 23, 2016 0:21 > To: de...@linuxdriverproject.org > Cc: linux-kernel@vger.kernel.org; KY Srinivasan ; Haiyang > Zhang ; Dexuan Cui > Subject: [PATCH] tools: hv: lsvmbus: add pci pass-through UUID > > lsvmbus keeps its

[PATCH] ALSA: timer: remove legacy rtctimer

There are no users of rtctimer left. Remove its code as this is the in-kernel user of the legacy PC RTC driver that will hopefully be removed at some point. Signed-off-by: Alexandre Belloni --- Note that I've kept the definition of SNDRV_TIMER_GLOBAL_RTC as

[PATCH] ALSA: timer: remove legacy rtctimer

There are no users of rtctimer left. Remove its code as this is the in-kernel user of the legacy PC RTC driver that will hopefully be removed at some point. Signed-off-by: Alexandre Belloni --- Note that I've kept the definition of SNDRV_TIMER_GLOBAL_RTC as it is exposed to userspace. USerspace

Re: [PATCH v4 2/2] KVM: move vcpu id checking to archs

On Fri, Apr 22, 2016 at 11:30:45AM +0200, Greg Kurz wrote: >On Fri, 22 Apr 2016 17:21:03 +0800 >Wei Yang wrote: > >> Hi, Greg >> > >Hi Wei ! > >> One confusion. >> >> There are 5 kvm_arch_vcpu_create() while in this patch you changed 2 of them. >> Some particular

Re: [PATCH v4 2/2] KVM: move vcpu id checking to archs

On Fri, Apr 22, 2016 at 11:30:45AM +0200, Greg Kurz wrote: >On Fri, 22 Apr 2016 17:21:03 +0800 >Wei Yang wrote: > >> Hi, Greg >> > >Hi Wei ! > >> One confusion. >> >> There are 5 kvm_arch_vcpu_create() while in this patch you changed 2 of them. >> Some particular reason? >> > >Yes and the

[PATCH v4 0/2] Align mmap address for DAX pmd mappings

When CONFIG_FS_DAX_PMD is set, DAX supports mmap() using pmd page size. This feature relies on both mmap virtual address and FS block (i.e. physical address) to be aligned by the pmd page size. Users can use mkfs options to specify FS to align block allocations. However, aligning mmap address

[PATCH v4 0/2] Align mmap address for DAX pmd mappings

When CONFIG_FS_DAX_PMD is set, DAX supports mmap() using pmd page size. This feature relies on both mmap virtual address and FS block (i.e. physical address) to be aligned by the pmd page size. Users can use mkfs options to specify FS to align block allocations. However, aligning mmap address

[PATCH v4 1/2] thp, dax: add thp_get_unmapped_area for pmd mappings

When CONFIG_FS_DAX_PMD is set, DAX supports mmap() using pmd page size. This feature relies on both mmap virtual address and FS block (i.e. physical address) to be aligned by the pmd page size. Users can use mkfs options to specify FS to align block allocations. However, aligning mmap address

[PATCH v4 1/2] thp, dax: add thp_get_unmapped_area for pmd mappings

When CONFIG_FS_DAX_PMD is set, DAX supports mmap() using pmd page size. This feature relies on both mmap virtual address and FS block (i.e. physical address) to be aligned by the pmd page size. Users can use mkfs options to specify FS to align block allocations. However, aligning mmap address

[PATCH v4 2/2] ext2/4, xfs, blk: call thp_get_unmapped_area() for pmd mappings

To support DAX pmd mappings with unmodified applications, filesystems need to align an mmap address by the pmd size. Call thp_get_unmapped_area() from f_op->get_unmapped_area. Note, there is no change in behavior for a non-DAX file. Signed-off-by: Toshi Kani Cc: Andrew

[PATCH v4 2/2] ext2/4, xfs, blk: call thp_get_unmapped_area() for pmd mappings

To support DAX pmd mappings with unmodified applications, filesystems need to align an mmap address by the pmd size. Call thp_get_unmapped_area() from f_op->get_unmapped_area. Note, there is no change in behavior for a non-DAX file. Signed-off-by: Toshi Kani Cc: Andrew Morton Cc: Alexander

[PATCH 4/4] perf/x86/cqm: Support cqm/mbm only for perf events

The cgroup support for cqm is broken. Instead of mapping RMID to a cgroup currently its mapped to the task and then hence when task moves cgroup we get incorrect count. Also the conflict handling code which is meant to handle the case of co-existing cgroup and task events, is broken. It reports

[PATCH 2/4] perf/x86/mbm: Store bytes counted for mbm during recycle

For MBM, since we report total bytes for the duration the perf counts, we need to keep the total bytes counted every time we loose an RMID. Introduce rc_count(recycle count) per event keep this history count(all bytes counted before the current RMID). If we do not keep this count separately then

[PATCH 3/4] perf/x86/mbm: Fix mbm counting when RMIDs are reused

When multiple instances of perf reuse RMID, then we need to start counting for each instance rather than reporting the current RMID count. This patch adds a st_count(start count) per event to track the same. Signed-off-by: Vikas Shivappa ---

[PATCH 4/4] perf/x86/cqm: Support cqm/mbm only for perf events

The cgroup support for cqm is broken. Instead of mapping RMID to a cgroup currently its mapped to the task and then hence when task moves cgroup we get incorrect count. Also the conflict handling code which is meant to handle the case of co-existing cgroup and task events, is broken. It reports

[PATCH 2/4] perf/x86/mbm: Store bytes counted for mbm during recycle

For MBM, since we report total bytes for the duration the perf counts, we need to keep the total bytes counted every time we loose an RMID. Introduce rc_count(recycle count) per event keep this history count(all bytes counted before the current RMID). If we do not keep this count separately then

[PATCH 3/4] perf/x86/mbm: Fix mbm counting when RMIDs are reused

When multiple instances of perf reuse RMID, then we need to start counting for each instance rather than reporting the current RMID count. This patch adds a st_count(start count) per event to track the same. Signed-off-by: Vikas Shivappa --- arch/x86/events/intel/cqm.c | 71

[PATCH V1 0/4] Urgent fixes for Intel CQM/MBM counting

Sending some urgent fixes for the MBM(memory b/w monitoring) which is upstreamed from 4.6-rc1. Patches apply on 4.6-rc1. CQM and MBM counters reported some incorrect counts for different scenarios like interval mode or for multiple perf instances. The 1/4,2/4,3/4 address these issues. The last

[PATCH 1/4] perf/x86/cqm,mbm: Store cqm,mbm count for all events when RMID is recycled

During RMID recycling, when an event loses the RMID we saved the counter for group leader but it was not being saved for all the events in an event group. This would lead to a situation where if 2 perf instances are counting the same PID one of them would not see the updated count which other perf

[PATCH V1 0/4] Urgent fixes for Intel CQM/MBM counting

Sending some urgent fixes for the MBM(memory b/w monitoring) which is upstreamed from 4.6-rc1. Patches apply on 4.6-rc1. CQM and MBM counters reported some incorrect counts for different scenarios like interval mode or for multiple perf instances. The 1/4,2/4,3/4 address these issues. The last

[PATCH 1/4] perf/x86/cqm,mbm: Store cqm,mbm count for all events when RMID is recycled

During RMID recycling, when an event loses the RMID we saved the counter for group leader but it was not being saved for all the events in an event group. This would lead to a situation where if 2 perf instances are counting the same PID one of them would not see the updated count which other perf

[git pull] Input updates for 4.6-rc4

Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem. Just minor driver fixes. Changelog: - Charles Keepax (1): Input: arizona-haptic - don't assign input_dev parent Dmitry Torokhov

[git pull] Input updates for 4.6-rc4

Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem. Just minor driver fixes. Changelog: - Charles Keepax (1): Input: arizona-haptic - don't assign input_dev parent Dmitry Torokhov

Re: [PATCH 8/8] arm64: dts: msm8916: Add SCM firmware node

On Fri 22 Apr 15:17 PDT 2016, Andy Gross wrote: > This adds the devicetree node for the SCM firmware. > > Signed-off-by: Andy Gross Acked-by: Bjorn Andersson Regards, Bjorn

Re: [PATCH 8/8] arm64: dts: msm8916: Add SCM firmware node

On Fri 22 Apr 15:17 PDT 2016, Andy Gross wrote: > This adds the devicetree node for the SCM firmware. > > Signed-off-by: Andy Gross Acked-by: Bjorn Andersson Regards, Bjorn

Re: [PATCH 7/8] dts: qcom: apq8084: Add SCM firmware node

On Fri 22 Apr 15:17 PDT 2016, Andy Gross wrote: > This patch adds the firmware node for the SCM > > Signed-off-by: Andy Gross Acked-by: Bjorn Andersson Regards, Bjorn

Re: [PATCH 7/8] dts: qcom: apq8084: Add SCM firmware node

On Fri 22 Apr 15:17 PDT 2016, Andy Gross wrote: > This patch adds the firmware node for the SCM > > Signed-off-by: Andy Gross Acked-by: Bjorn Andersson Regards, Bjorn

Re: [PATCH 1/4] pnp: pnpbios: Add explicit X86_32 dependency to PNPBIOS

On 4/11/2016 3:25 PM, William Breathitt Gray wrote: The PNPBIOS driver requires preprocessor defines (located in include/asm/segment.h) only declared if the architecture is set to X86_32. If the architecture is set to X86_64, the PNPBIOS driver will not build properly. The X86 dependecy for the

Re: [PATCH 1/4] pnp: pnpbios: Add explicit X86_32 dependency to PNPBIOS

On 4/11/2016 3:25 PM, William Breathitt Gray wrote: The PNPBIOS driver requires preprocessor defines (located in include/asm/segment.h) only declared if the architecture is set to X86_32. If the architecture is set to X86_64, the PNPBIOS driver will not build properly. The X86 dependecy for the

Re: [PATCH 5/8] firmware: qcom: scm: Use atomic SCM for cold boot

On Fri 22 Apr 15:17 PDT 2016, Andy Gross wrote: > This patch changes the cold_set_boot_addr function to use atomic SCM > calls. This removes the need for memory allocation and instead places > all arguments in registers. > > Signed-off-by: Andy Gross > --- >

Re: [PATCH 5/8] firmware: qcom: scm: Use atomic SCM for cold boot

On Fri 22 Apr 15:17 PDT 2016, Andy Gross wrote: > This patch changes the cold_set_boot_addr function to use atomic SCM > calls. This removes the need for memory allocation and instead places > all arguments in registers. > > Signed-off-by: Andy Gross > --- > drivers/firmware/qcom_scm-32.c |

Re: [PATCH 6/6] rtc: rv3029: add alarm IRQ

On 21/04/2016 at 20:24:19 +0200, Mylène Josserand wrote : > @@ -731,11 +786,9 @@ static void rv3029_hwmon_register(struct device *dev, > const char *name) > > #endif /* CONFIG_RTC_DRV_RV3029_HWMON */ > > -static const struct rtc_class_ops rv3029_rtc_ops = { > +static struct rtc_class_ops

Re: [PATCH 6/6] rtc: rv3029: add alarm IRQ

On 21/04/2016 at 20:24:19 +0200, Mylène Josserand wrote : > @@ -731,11 +786,9 @@ static void rv3029_hwmon_register(struct device *dev, > const char *name) > > #endif /* CONFIG_RTC_DRV_RV3029_HWMON */ > > -static const struct rtc_class_ops rv3029_rtc_ops = { > +static struct rtc_class_ops

Re: [PATCH 4/8] firmware: qcom: scm: Add support for ARM64 SoCs

On Fri 22 Apr 15:17 PDT 2016, Andy Gross wrote: [..] > diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c [..] > + > +/** > + * struct qcom_scm_desc > + * @arginfo: Metadata describing the arguments in args[] > + * @args: The array of arguments for the secure syscall > +

Re: [PATCH 4/8] firmware: qcom: scm: Add support for ARM64 SoCs

On Fri 22 Apr 15:17 PDT 2016, Andy Gross wrote: [..] > diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c [..] > + > +/** > + * struct qcom_scm_desc > + * @arginfo: Metadata describing the arguments in args[] > + * @args: The array of arguments for the secure syscall > +

Re: [PATCH 5/6] rtc: rv3029: enable AE_x bits on set_alarm

On 21/04/2016 at 20:24:18 +0200, Mylène Josserand wrote : > The RTC RV3029 handles different types of alarms : seconds, minutes, ... > These alarms can be enabled or disabled individually using an AE_x bit > which is the last bit (BIT(7)) on each alarm registers. > > To prepare the alarm IRQ

Re: [PATCH 5/6] rtc: rv3029: enable AE_x bits on set_alarm

On 21/04/2016 at 20:24:18 +0200, Mylène Josserand wrote : > The RTC RV3029 handles different types of alarms : seconds, minutes, ... > These alarms can be enabled or disabled individually using an AE_x bit > which is the last bit (BIT(7)) on each alarm registers. > > To prepare the alarm IRQ

Re: [PATCH 4/6] rtc: rv3029: Removes some checks and warnings

On 23/04/2016 at 01:29:46 +0200, Alexandre Belloni wrote : > Hi, > > On 21/04/2016 at 20:24:17 +0200, Mylène Josserand wrote : > > @@ -829,8 +829,6 @@ static void rv3029_unregister_driver(void) > > > > static int rv3049_probe(struct spi_device *spi) > > { > > - int res; > > - unsigned int

Re: [PATCH 4/6] rtc: rv3029: Removes some checks and warnings

On 23/04/2016 at 01:29:46 +0200, Alexandre Belloni wrote : > Hi, > > On 21/04/2016 at 20:24:17 +0200, Mylène Josserand wrote : > > @@ -829,8 +829,6 @@ static void rv3029_unregister_driver(void) > > > > static int rv3049_probe(struct spi_device *spi) > > { > > - int res; > > - unsigned int

Re: [PATCH 4/6] rtc: rv3029: Removes some checks and warnings

Hi, On 21/04/2016 at 20:24:17 +0200, Mylène Josserand wrote : > @@ -829,8 +829,6 @@ static void rv3029_unregister_driver(void) > > static int rv3049_probe(struct spi_device *spi) > { > - int res; > - unsigned int tmp; Well, you just introduced those variables in the previous patch.

Re: [PATCH 4/6] rtc: rv3029: Removes some checks and warnings

Hi, On 21/04/2016 at 20:24:17 +0200, Mylène Josserand wrote : > @@ -829,8 +829,6 @@ static void rv3029_unregister_driver(void) > > static int rv3049_probe(struct spi_device *spi) > { > - int res; > - unsigned int tmp; Well, you just introduced those variables in the previous patch.

Re: [PATCH 6/8] firmware: qcom: scm: Add memory allocation API

On Fri 22 Apr 15:17 PDT 2016, Andy Gross wrote: > This patch adds APIs for the scm-32 and scm-64 to use for coherent memory > allocation. > > Signed-off-by: Andy Gross This patch must come before the ARM64 implementation. > --- > drivers/firmware/qcom_scm.c | 17

Re: [PATCH 6/8] firmware: qcom: scm: Add memory allocation API

On Fri 22 Apr 15:17 PDT 2016, Andy Gross wrote: > This patch adds APIs for the scm-32 and scm-64 to use for coherent memory > allocation. > > Signed-off-by: Andy Gross This patch must come before the ARM64 implementation. > --- > drivers/firmware/qcom_scm.c | 17 + >

Re: [v8, 6/7] MAINTAINERS: add entry for Freescale SoC specific driver

On Fri, 2016-04-22 at 14:27 +0800, Yangbo Lu wrote: > Add maintainer entry for Freescale SoC specific driver including > the QE library and the GUTS driver. Also add entry for GUTS driver > and add maintainer for QE library. > > Signed-off-by: Yangbo Lu > --- > Changes for v8:

Re: [v8, 6/7] MAINTAINERS: add entry for Freescale SoC specific driver

On Fri, 2016-04-22 at 14:27 +0800, Yangbo Lu wrote: > Add maintainer entry for Freescale SoC specific driver including > the QE library and the GUTS driver. Also add entry for GUTS driver > and add maintainer for QE library. > > Signed-off-by: Yangbo Lu > --- > Changes for v8: > - Added

Re: linux-next: build failure after merge of the net-next tree

On Fri, 2016-04-22 at 10:20 +0100, Mark Brown wrote: > On Wed, Apr 13, 2016 at 11:15:13AM -0400, David Miller wrote: > > From: Stephen Rothwell > > > > After merging the net-next tree, today's linux-next build (arm > > > allmodconfig) failed like thisi (this has actually

Re: linux-next: build failure after merge of the net-next tree

On Fri, 2016-04-22 at 10:20 +0100, Mark Brown wrote: > On Wed, Apr 13, 2016 at 11:15:13AM -0400, David Miller wrote: > > From: Stephen Rothwell > > > > After merging the net-next tree, today's linux-next build (arm > > > allmodconfig) failed like thisi (this has actually been failing > for a > >

Re: [PATCH] scsi: fc: force inlining of wwn conversion functions

Current kernel (4.6.0-rc4+) + GCC 5.3.0 definitely truncated qla2x00_get_host_fabric_name() routine. Just like Josh indicated, we’re dropping down to the next routine. root@mars:/sys/class/fc_host/host3 2016-04-22 16:07:30 > cat fabric_name Killed —— static void

Re: [PATCH] scsi: fc: force inlining of wwn conversion functions

Current kernel (4.6.0-rc4+) + GCC 5.3.0 definitely truncated qla2x00_get_host_fabric_name() routine. Just like Josh indicated, we’re dropping down to the next routine. root@mars:/sys/class/fc_host/host3 2016-04-22 16:07:30 > cat fabric_name Killed —— static void

  1   2   3   4   5   6   7   8   9   10   >