Re: [PATCH] cpufreq: Drop the 'initialized' field from struct cpufreq_governor

On 18-05-16, 22:59, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > The 'initialized' field in struct cpufreq_governor is only used by > the conservative governor (as a usage counter) and the way that > happens is far from straightforward and arguably

Re: [PATCH] cpufreq: Drop the 'initialized' field from struct cpufreq_governor

On 18-05-16, 22:59, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > The 'initialized' field in struct cpufreq_governor is only used by > the conservative governor (as a usage counter) and the way that > happens is far from straightforward and arguably incorrect. > > Namely, the value of

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

On Wed, May 18, 2016 at 12:12:13PM -0700, Thomas Garnier wrote: > I thought the mix of slab_test & kernbench would show a diverse > picture on perf data. Is there another test that you think would be > useful? Single thread testing on slab_test would be meaningful because it also touch the

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

On Wed, May 18, 2016 at 12:12:13PM -0700, Thomas Garnier wrote: > I thought the mix of slab_test & kernbench would show a diverse > picture on perf data. Is there another test that you think would be > useful? Single thread testing on slab_test would be meaningful because it also touch the

Re: linux-next: manual merge of the vfs tree with Linus' tree

As noted below, it is easier to remove the obsolete comments and I just pushed the following trivial patch to cifs-2.6.git for-next to do that. https://git.samba.org/?p=sfrench/cifs-2.6.git;a=commit;h=fea17ae8ac1c8c44b2fd1c02ae2e15b847d327d1 On Wed, May 18, 2016 at 8:17 PM, Stephen Rothwell

Re: linux-next: manual merge of the vfs tree with Linus' tree

As noted below, it is easier to remove the obsolete comments and I just pushed the following trivial patch to cifs-2.6.git for-next to do that. https://git.samba.org/?p=sfrench/cifs-2.6.git;a=commit;h=fea17ae8ac1c8c44b2fd1c02ae2e15b847d327d1 On Wed, May 18, 2016 at 8:17 PM, Stephen Rothwell

Re: perf probe -L on ubuntu 16.04

On Mon, 16 May 2016 22:56:36 -0300 Arnaldo Carvalho de Melo wrote: > Hi Masami, > > Have you ever tried using 'perf probe' on ubuntu? > > acme@ubuntu:~/git/linux$ sudo apt-cache search linux-image-$(uname -r) > linux-image-4.4.0-21-generic - Linux kernel image for

Re: perf probe -L on ubuntu 16.04

On Mon, 16 May 2016 22:56:36 -0300 Arnaldo Carvalho de Melo wrote: > Hi Masami, > > Have you ever tried using 'perf probe' on ubuntu? > > acme@ubuntu:~/git/linux$ sudo apt-cache search linux-image-$(uname -r) > linux-image-4.4.0-21-generic - Linux kernel image for version 4.4.0 on > 64

RE: [RFC PATCH 1/2] ACPI / button: Send "open" state after boot/resume

Hi, > From: Bastien Nocera [mailto:had...@hadess.net] > Subject: Re: [RFC PATCH 1/2] ACPI / button: Send "open" state after > boot/resume > > On Tue, 2016-05-17 at 16:27 +0800, Lv Zheng wrote: > > (This patch hasn't been tested, it's sent for comments) > > > > Linux userspace (systemd-logind)

RE: [RFC PATCH 1/2] ACPI / button: Send "open" state after boot/resume

Hi, > From: Bastien Nocera [mailto:had...@hadess.net] > Subject: Re: [RFC PATCH 1/2] ACPI / button: Send "open" state after > boot/resume > > On Tue, 2016-05-17 at 16:27 +0800, Lv Zheng wrote: > > (This patch hasn't been tested, it's sent for comments) > > > > Linux userspace (systemd-logind)

linux-next: manual merge of the rdma tree with the nfs tree

Hi Doug, Today's linux-next merge of the rdma tree got a conflict in: net/sunrpc/xprtrdma/frwr_ops.c between commit: 55fdfce101a0 ("xprtrdma: Rename rpcrdma_frwr::sg and sg_nents") from the nfs tree and commits: ff2ba9936591 ("IB/core: Add passing an offset into the SG to

linux-next: manual merge of the rdma tree with the nfs tree

Hi Doug, Today's linux-next merge of the rdma tree got a conflict in: net/sunrpc/xprtrdma/frwr_ops.c between commit: 55fdfce101a0 ("xprtrdma: Rename rpcrdma_frwr::sg and sg_nents") from the nfs tree and commits: ff2ba9936591 ("IB/core: Add passing an offset into the SG to

Re: [PATCH v12 07/10] arm64: kprobes instruction simulation support

On Wed, Apr 27, 2016 at 02:53:02PM -0400, David Long wrote: > From: Sandeepa Prabhu > > Kprobes needs simulation of instructions that cannot be stepped > from a different memory location, e.g.: those instructions > that uses PC-relative addressing. In simulation, the

Re: [PATCH v12 07/10] arm64: kprobes instruction simulation support

On Wed, Apr 27, 2016 at 02:53:02PM -0400, David Long wrote: > From: Sandeepa Prabhu > > Kprobes needs simulation of instructions that cannot be stepped > from a different memory location, e.g.: those instructions > that uses PC-relative addressing. In simulation, the behaviour > of the

Re: drivers/of: crash on boot

On Wed, May 18, 2016 at 7:23 PM, Rob Herring wrote: > On Wed, May 18, 2016 at 4:26 PM, Rhyland Klein wrote: >> On 5/18/2016 3:58 PM, Rhyland Klein wrote: >>> On 5/18/2016 3:36 PM, Rob Herring wrote: On Wed, May 18, 2016 at 10:34 AM, Sasha Levin

Re: drivers/of: crash on boot

On Wed, May 18, 2016 at 7:23 PM, Rob Herring wrote: > On Wed, May 18, 2016 at 4:26 PM, Rhyland Klein wrote: >> On 5/18/2016 3:58 PM, Rhyland Klein wrote: >>> On 5/18/2016 3:36 PM, Rob Herring wrote: On Wed, May 18, 2016 at 10:34 AM, Sasha Levin wrote: > Hi Rhyland, > >

RE: [RFC PATCH 1/2] ACPI / button: Send "open" state after boot/resume

Hi, > From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of > Rafael J. Wysocki > Subject: Re: [RFC PATCH 1/2] ACPI / button: Send "open" state after > boot/resume > > On Wed, May 18, 2016 at 3:25 AM, Zheng, Lv wrote: > > Hi, Rafael > > > > Thanks for the

RE: [RFC PATCH 1/2] ACPI / button: Send "open" state after boot/resume

Hi, > From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of > Rafael J. Wysocki > Subject: Re: [RFC PATCH 1/2] ACPI / button: Send "open" state after > boot/resume > > On Wed, May 18, 2016 at 3:25 AM, Zheng, Lv wrote: > > Hi, Rafael > > > > Thanks for the review. > > > >> From:

[PATCH RESEND v4 6/9] irqchip/ls1x-cpu: Move the CPU IRQ driver from arch/mips/loongson32/common/

Signed-off-by: Chunbo Cui Signed-off-by: Binbin Zhou Signed-off-by: Huacai Chen --- arch/mips/include/asm/irq_cpu.h | 1 + arch/mips/loongson32/common/irq.c | 128 +--- drivers/irqchip/Makefile | 1 +

[PATCH RESEND v4 6/9] irqchip/ls1x-cpu: Move the CPU IRQ driver from arch/mips/loongson32/common/

Signed-off-by: Chunbo Cui Signed-off-by: Binbin Zhou Signed-off-by: Huacai Chen --- arch/mips/include/asm/irq_cpu.h | 1 + arch/mips/loongson32/common/irq.c | 128 +--- drivers/irqchip/Makefile | 1 + drivers/irqchip/irq-ls1x-cpu.c| 242

linux-next: manual merge of the rdma tree with Linus' tree

Hi Doug, Today's linux-next merge of the rdma tree got a conflict in: include/linux/mlx5/driver.h between commit: 43a335e055bb ("net/mlx5_core: Flow counters infrastructure") from Linus' tree and commit: 94c6825e0ff7 ("net/mlx5_core: Use tasklet for user-space CQ completion events")

linux-next: manual merge of the rdma tree with Linus' tree

Hi Doug, Today's linux-next merge of the rdma tree got a conflict in: include/linux/mlx5/driver.h between commit: 43a335e055bb ("net/mlx5_core: Flow counters infrastructure") from Linus' tree and commit: 94c6825e0ff7 ("net/mlx5_core: Use tasklet for user-space CQ completion events")

Re: [PATCH] serial: 8250_early: Add earlycon support for Synopsys DesignWare ABP UART

+Cc Jon and arm-kernel mailist Any comments, thanks. Kefeng On 2016/5/11 14:06, Kefeng Wang wrote: > Some board like Hisilicon D02 uses Synopsys DesignWare ABP UART, declare an > OF early console for it, so early console device can be enabled with comand > line "earlycon"(without option) via

Re: [PATCH] serial: 8250_early: Add earlycon support for Synopsys DesignWare ABP UART

+Cc Jon and arm-kernel mailist Any comments, thanks. Kefeng On 2016/5/11 14:06, Kefeng Wang wrote: > Some board like Hisilicon D02 uses Synopsys DesignWare ABP UART, declare an > OF early console for it, so early console device can be enabled with comand > line "earlycon"(without option) via

[PATCH v2] kprobes: add a new module parameter

This patch adds a new module parameter which can be used as the symbol name. Without this patch, we can only test the "_do_fork" function with this kernel module. With this patch, the module becomes more flexable, we can test any functions with this module with: #insmod kprobe_example.ko

[PATCH v2] kprobes: add a new module parameter

This patch adds a new module parameter which can be used as the symbol name. Without this patch, we can only test the "_do_fork" function with this kernel module. With this patch, the module becomes more flexable, we can test any functions with this module with: #insmod kprobe_example.ko

Re: [PATCH v2] locking/rwsem: Add reader-owned state to the owner field

On Fri, May 06, 2016 at 08:20:24PM -0400, Waiman Long wrote: > Currently, it is not possible to determine for sure if a reader > owns a rwsem by looking at the content of the rwsem data structure. > This patch adds a new state RWSEM_READER_OWNED to the owner field > to indicate that readers

Re: [PATCH v2] locking/rwsem: Add reader-owned state to the owner field

On Fri, May 06, 2016 at 08:20:24PM -0400, Waiman Long wrote: > Currently, it is not possible to determine for sure if a reader > owns a rwsem by looking at the content of the rwsem data structure. > This patch adds a new state RWSEM_READER_OWNED to the owner field > to indicate that readers

[PATCH v2] kprobes: add a new module parameter

This patch adds a new module parameter which can be used as the symbol name. Without this patch, we can only test the "_do_fork" function with this kernel module. With this patch, the module becomes more flexable, we can test any functions with this module with: #insmod kprobe_example.ko

[PATCH v2] kprobes: add a new module parameter

This patch adds a new module parameter which can be used as the symbol name. Without this patch, we can only test the "_do_fork" function with this kernel module. With this patch, the module becomes more flexable, we can test any functions with this module with: #insmod kprobe_example.ko

Re: linux-next: manual merge of the nfs tree with Linus' tree

> On May 18, 2016, at 8:40 PM, Stephen Rothwell wrote: > > Hi Trond, > > Today's linux-next merge of the nfs tree got a conflict in: > > fs/nfs/direct.c > > between commit: > > c8b8e32d700f ("direct-io: eliminate the offset argument to ->direct_IO") > > from Linus'

Re: linux-next: manual merge of the nfs tree with Linus' tree

> On May 18, 2016, at 8:40 PM, Stephen Rothwell wrote: > > Hi Trond, > > Today's linux-next merge of the nfs tree got a conflict in: > > fs/nfs/direct.c > > between commit: > > c8b8e32d700f ("direct-io: eliminate the offset argument to ->direct_IO") > > from Linus' tree and commit: > >

Re: linux-next: manual merge of the vfs tree with the ext4 tree

Hi Arnd, On Wed, 18 May 2016 16:25:39 +0200 Arnd Bergmann wrote: > > I'm getting a warning here because the 'offset' variable is no longer > used, I've fixed it up on my test box like this: Thanks. I have applied that to linux-next today and fixed up the merge fix patch from

Re: linux-next: manual merge of the vfs tree with the ext4 tree

Hi Arnd, On Wed, 18 May 2016 16:25:39 +0200 Arnd Bergmann wrote: > > I'm getting a warning here because the 'offset' variable is no longer > used, I've fixed it up on my test box like this: Thanks. I have applied that to linux-next today and fixed up the merge fix patch from tomorrow. >

Re: [PATCH v5 00/11] serial: 8250: split LPSS to 8250_lpss, enable DMA on Quark

On Thu, 2016-05-12 at 18:06 +0300, Andy Shevchenko wrote: > On Fri, 2016-05-06 at 18:17 +0300, Andy Shevchenko wrote: > > This is combined series of two things: > > - split out the Intel LPSS specific driver from 8250_pci into > > 8250_lpss > > - enable DMA support on Intel Quark UART > > > > The

[lkp] [writeback] 074e46e1ad: fio.write_bw_MBps -10.5% regression

FYI, we noticed fio.write_bw_MBps -10.5% regression due to commit: commit 074e46e1aded0ac0474a5db4d50d514d9dc42e78 ("writeback: throttle buffered writeback") https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git wb-buf-throttle in testcase: fio-basic on test machine:

Re: [PATCH v5 00/11] serial: 8250: split LPSS to 8250_lpss, enable DMA on Quark

On Thu, 2016-05-12 at 18:06 +0300, Andy Shevchenko wrote: > On Fri, 2016-05-06 at 18:17 +0300, Andy Shevchenko wrote: > > This is combined series of two things: > > - split out the Intel LPSS specific driver from 8250_pci into > > 8250_lpss > > - enable DMA support on Intel Quark UART > > > > The

[lkp] [writeback] 074e46e1ad: fio.write_bw_MBps -10.5% regression

FYI, we noticed fio.write_bw_MBps -10.5% regression due to commit: commit 074e46e1aded0ac0474a5db4d50d514d9dc42e78 ("writeback: throttle buffered writeback") https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git wb-buf-throttle in testcase: fio-basic on test machine:

linux-next: manual merge of the vfs tree with Linus' tree

Hi Al, Today's linux-next merge of the vfs tree got a conflict in: fs/cifs/cifsfs.c between commit: a9ae008f407b ("cifs: Switch to generic xattr handlers") from Linus' tree and commit: 51085a1f913a ("cifs: use C99 syntax for inode_operations initializer") from the vfs tree. I fixed

linux-next: manual merge of the vfs tree with Linus' tree

Hi Al, Today's linux-next merge of the vfs tree got a conflict in: fs/cifs/cifsfs.c between commit: a9ae008f407b ("cifs: Switch to generic xattr handlers") from Linus' tree and commit: 51085a1f913a ("cifs: use C99 syntax for inode_operations initializer") from the vfs tree. I fixed

Re: [PATCH v11 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)

On Thu, May 19, 2016 at 12:59:09AM +, Dexuan Cui wrote: > > From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On > > Behalf > > Of Dexuan Cui > > Sent: Tuesday, May 17, 2016 10:46 > > To: David Miller > > Cc: o...@aepfle.de; gre...@linuxfoundation.org;

Re: [PATCH v11 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)

On Thu, May 19, 2016 at 12:59:09AM +, Dexuan Cui wrote: > > From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On > > Behalf > > Of Dexuan Cui > > Sent: Tuesday, May 17, 2016 10:46 > > To: David Miller > > Cc: o...@aepfle.de; gre...@linuxfoundation.org; jasow...@redhat.com;

RE: [PATCH v11 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)

> From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On Behalf > Of Dexuan Cui > Sent: Tuesday, May 17, 2016 10:46 > To: David Miller > Cc: o...@aepfle.de; gre...@linuxfoundation.org; jasow...@redhat.com; > linux-kernel@vger.kernel.org; j...@perches.com;

RE: [PATCH v11 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)

> From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On Behalf > Of Dexuan Cui > Sent: Tuesday, May 17, 2016 10:46 > To: David Miller > Cc: o...@aepfle.de; gre...@linuxfoundation.org; jasow...@redhat.com; > linux-kernel@vger.kernel.org; j...@perches.com; net...@vger.kernel.org; >

linux-next: build failure after merge of the nfs tree

Hi Trond, After merging the nfs tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from include/linux/fs.h:19:0, from fs/nfs/nfs42proc.c:4: fs/nfs/nfs42proc.c: In function 'nfs42_proc_copy': fs/nfs/nfs42proc.c:212:30: error: 'struct inode'

linux-next: build failure after merge of the nfs tree

Hi Trond, After merging the nfs tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from include/linux/fs.h:19:0, from fs/nfs/nfs42proc.c:4: fs/nfs/nfs42proc.c: In function 'nfs42_proc_copy': fs/nfs/nfs42proc.c:212:30: error: 'struct inode'

Re: + zram-introduce-per-device-debug_stat-sysfs-node-update-2.patch added to -mm tree

On (05/18/16 14:54), a...@linux-foundation.org wrote: > The patch titled > Subject: zram-introduce-per-device-debug_stat-sysfs-node-update-2 > has been added to the -mm tree. Its filename is > zram-introduce-per-device-debug_stat-sysfs-node-update-2.patch > > This patch should soon

Re: + zram-introduce-per-device-debug_stat-sysfs-node-update-2.patch added to -mm tree

On (05/18/16 14:54), a...@linux-foundation.org wrote: > The patch titled > Subject: zram-introduce-per-device-debug_stat-sysfs-node-update-2 > has been added to the -mm tree. Its filename is > zram-introduce-per-device-debug_stat-sysfs-node-update-2.patch > > This patch should soon

Re: malloc() size in CMA region seems to be aligned to CMA_ALIGNMENT

On Wed, May 18, 2016 at 09:15:13PM +0800, lunar12 lunartwix wrote: > 2016-05-18 16:48 GMT+08:00 Michal Hocko : > > [CC linux-mm and some usual suspects] Michal, Thanks. > > > > On Tue 17-05-16 23:37:55, lunar12 lunartwix wrote: > >> A 4MB dma_alloc_coherent in kernel after

Re: malloc() size in CMA region seems to be aligned to CMA_ALIGNMENT

On Wed, May 18, 2016 at 09:15:13PM +0800, lunar12 lunartwix wrote: > 2016-05-18 16:48 GMT+08:00 Michal Hocko : > > [CC linux-mm and some usual suspects] Michal, Thanks. > > > > On Tue 17-05-16 23:37:55, lunar12 lunartwix wrote: > >> A 4MB dma_alloc_coherent in kernel after malloc(2*1024) 40

Re: [PATCH perf/core v8 07/16] perf probe: Remove caches when --cache is given

Hi Masami, On 05/15/2016 08:50 AM, Masami Hiramatsu wrote: From: Masami Hiramatsu perf-probe --del removes caches when --cache is given. Note that the delete pattern is not same as normal events. If you cached probes with event name, --del "eventname" works

Re: [PATCH perf/core v8 07/16] perf probe: Remove caches when --cache is given

Hi Masami, On 05/15/2016 08:50 AM, Masami Hiramatsu wrote: From: Masami Hiramatsu perf-probe --del removes caches when --cache is given. Note that the delete pattern is not same as normal events. If you cached probes with event name, --del "eventname" works as expected. However, if you

linux-next: manual merge of the nfs tree with Linus' tree

Hi Trond, Today's linux-next merge of the nfs tree got a conflict in: fs/nfs/direct.c between commit: c8b8e32d700f ("direct-io: eliminate the offset argument to ->direct_IO") from Linus' tree and commit: ed3743a6d4f3 ("nfs: add debug to directio "good_bytes" counting") from the nfs

linux-next: manual merge of the nfs tree with Linus' tree

Hi Trond, Today's linux-next merge of the nfs tree got a conflict in: fs/nfs/direct.c between commit: c8b8e32d700f ("direct-io: eliminate the offset argument to ->direct_IO") from Linus' tree and commit: ed3743a6d4f3 ("nfs: add debug to directio "good_bytes" counting") from the nfs

Re: usb: dwc2: regression on MyBook Live Duo / Canyonlands since 4.3.0-rc4

On 5/18/2016 12:15 PM, Christian Lamparter wrote: > On Tuesday, May 17, 2016 04:50:48 PM John Youn wrote: >> On 5/14/2016 6:11 AM, Christian Lamparter wrote: >>> On Thursday, May 12, 2016 11:40:28 AM John Youn wrote: On 5/12/2016 6:30 AM, Christian Lamparter wrote: > On Thursday, May 12,

Re: usb: dwc2: regression on MyBook Live Duo / Canyonlands since 4.3.0-rc4

On 5/18/2016 12:15 PM, Christian Lamparter wrote: > On Tuesday, May 17, 2016 04:50:48 PM John Youn wrote: >> On 5/14/2016 6:11 AM, Christian Lamparter wrote: >>> On Thursday, May 12, 2016 11:40:28 AM John Youn wrote: On 5/12/2016 6:30 AM, Christian Lamparter wrote: > On Thursday, May 12,

Re: [PATCH] mm: page_is_guard return false when page_ext arrays are not allocated yet

Vlastiml, thanks for ccing me on original bug report. On Wed, May 18, 2016 at 03:23:45PM -0700, Yang Shi wrote: > When enabling the below kernel configs: > > CONFIG_DEFERRED_STRUCT_PAGE_INIT > CONFIG_DEBUG_PAGEALLOC > CONFIG_PAGE_EXTENSION > CONFIG_DEBUG_VM > > kernel bootup may fail due to the

Re: [PATCH] mm: page_is_guard return false when page_ext arrays are not allocated yet

Vlastiml, thanks for ccing me on original bug report. On Wed, May 18, 2016 at 03:23:45PM -0700, Yang Shi wrote: > When enabling the below kernel configs: > > CONFIG_DEFERRED_STRUCT_PAGE_INIT > CONFIG_DEBUG_PAGEALLOC > CONFIG_PAGE_EXTENSION > CONFIG_DEBUG_VM > > kernel bootup may fail due to the

Re: [PATCH] tty: vt: Fix soft lockup in fbcon cursor blink timer.

On Thu, May 19, 2016 at 4:24 AM, Scot Doyle wrote: > On Wed, 18 May 2016, Ming Lei wrote: >> On Wed, May 18, 2016 at 4:49 AM, Pavel Machek wrote: >> > On Tue 2016-05-17 11:41:04, David Daney wrote: >> >> From: David Daney >> >> >> >>

Re: [PATCH] tty: vt: Fix soft lockup in fbcon cursor blink timer.

On Thu, May 19, 2016 at 4:24 AM, Scot Doyle wrote: > On Wed, 18 May 2016, Ming Lei wrote: >> On Wed, May 18, 2016 at 4:49 AM, Pavel Machek wrote: >> > On Tue 2016-05-17 11:41:04, David Daney wrote: >> >> From: David Daney >> >> >> >> We are getting somewhat random soft lockups with this

Re: [RFC PATCH 00/15] Provide atomics and bitops implemented with ISO C++11 atomics

On Wed, May 18, 2016 at 04:10:37PM +0100, David Howells wrote: > > Here's a set of patches to provide kernel atomics and bitops implemented > with ISO C++11 atomic intrinsics. The second part of the set makes the x86 > arch use the implementation. > > Note that the x86 patches are very rough.

Re: drivers/of: crash on boot

On Wed, May 18, 2016 at 4:26 PM, Rhyland Klein wrote: > On 5/18/2016 3:58 PM, Rhyland Klein wrote: >> On 5/18/2016 3:36 PM, Rob Herring wrote: >>> On Wed, May 18, 2016 at 10:34 AM, Sasha Levin >>> wrote: Hi Rhyland, I'm seeing a crash on

Re: [RFC PATCH 00/15] Provide atomics and bitops implemented with ISO C++11 atomics

On Wed, May 18, 2016 at 04:10:37PM +0100, David Howells wrote: > > Here's a set of patches to provide kernel atomics and bitops implemented > with ISO C++11 atomic intrinsics. The second part of the set makes the x86 > arch use the implementation. > > Note that the x86 patches are very rough.

Re: drivers/of: crash on boot

On Wed, May 18, 2016 at 4:26 PM, Rhyland Klein wrote: > On 5/18/2016 3:58 PM, Rhyland Klein wrote: >> On 5/18/2016 3:36 PM, Rob Herring wrote: >>> On Wed, May 18, 2016 at 10:34 AM, Sasha Levin >>> wrote: Hi Rhyland, I'm seeing a crash on boot that seems to have been caused by

Re: incoming merge conflict to linux-next

Hi Chris, On Wed, 18 May 2016 17:10:43 -0400 Chris Mason wrote: > > Dave Sterba's tree in linux-next has a few btrfs patches that we're not > sending yet into Linus. We've got an update for Josef's enospc work > that'll get sent in next week. > > So he prepped a pull for me that

Re: incoming merge conflict to linux-next

Hi Chris, On Wed, 18 May 2016 17:10:43 -0400 Chris Mason wrote: > > Dave Sterba's tree in linux-next has a few btrfs patches that we're not > sending yet into Linus. We've got an update for Josef's enospc work > that'll get sent in next week. > > So he prepped a pull for me that merged up a

[RESEND PATCH] arm64: defconfig: Enable Cadence MACB/GEM support

This patch enables the cadence MACB/GEM support that is needed by lg1312 SoC. Signed-off-by: Chanho Min --- arch/arm64/configs/defconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 14dbe27..ed11cb6

[RESEND PATCH] arm64: defconfig: Enable Cadence MACB/GEM support

This patch enables the cadence MACB/GEM support that is needed by lg1312 SoC. Signed-off-by: Chanho Min --- arch/arm64/configs/defconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 14dbe27..ed11cb6 100644 ---

[PATCH] x86, signals: add missing signal_compat code for x86 features

Sending this out early so folks can have a look. I haven't let it run through a full set of tests, so buyer beware, but it would have a hard time hurting anything other than the already-broken 32-bit compat signal code. --- From: Dave Hansen The 32-bit siginfo is

[PATCH] x86, signals: add missing signal_compat code for x86 features

Sending this out early so folks can have a look. I haven't let it run through a full set of tests, so buyer beware, but it would have a hard time hurting anything other than the already-broken 32-bit compat signal code. --- From: Dave Hansen The 32-bit siginfo is a different binary format

Re: [PATCH 0/2] Add Opal unlock support to NVMe.

On Tue, Apr 26, 2016 at 02:33:49PM -0700, Rafael Antognolli wrote: > On Mon, Apr 25, 2016 at 08:29:22PM -0700, Elliott, Robert (Persistent Memory) > wrote: > > > > > > > -Original Message- > > > From: linux-block-ow...@vger.kernel.org [mailto:linux-block- > > > ow...@vger.kernel.org] On

Re: [PATCH 0/2] Add Opal unlock support to NVMe.

On Tue, Apr 26, 2016 at 02:33:49PM -0700, Rafael Antognolli wrote: > On Mon, Apr 25, 2016 at 08:29:22PM -0700, Elliott, Robert (Persistent Memory) > wrote: > > > > > > > -Original Message- > > > From: linux-block-ow...@vger.kernel.org [mailto:linux-block- > > > ow...@vger.kernel.org] On

Re: [RFC v2 7/7] iio: inv_mpu6050: Expose channels from slave sensors

On Wed, May 18, 2016 at 06:00:54PM +0300, Crestez Dan Leonard wrote: > This works by copying the iio_chan_specs from the slave device and > republishing them as if they belonged to the MPU itself. All > read/write_raw operations are forwarded to the other driver. > > The original device is still

Re: [RFC v2 5/7] iio: inv_mpu6050: Add support for auxiliary I2C master

On Wed, May 18, 2016 at 06:00:52PM +0300, Crestez Dan Leonard wrote: > The MPU has an auxiliary I2C bus for connecting external > sensors. This bus has two operating modes: > * bypasss: which connects the primary and auxiliary busses > together. This is already supported via an i2c mux. > *

Re: [RFC v2 7/7] iio: inv_mpu6050: Expose channels from slave sensors

On Wed, May 18, 2016 at 06:00:54PM +0300, Crestez Dan Leonard wrote: > This works by copying the iio_chan_specs from the slave device and > republishing them as if they belonged to the MPU itself. All > read/write_raw operations are forwarded to the other driver. > > The original device is still

Re: [RFC v2 5/7] iio: inv_mpu6050: Add support for auxiliary I2C master

On Wed, May 18, 2016 at 06:00:52PM +0300, Crestez Dan Leonard wrote: > The MPU has an auxiliary I2C bus for connecting external > sensors. This bus has two operating modes: > * bypasss: which connects the primary and auxiliary busses > together. This is already supported via an i2c mux. > *

[PATCH 1/2] libnvdimm, dax: autodetect support

For autodetecting a previously established dax configuration we need the info block to indicate block-device vs device-dax mode, and we need to have the default namespace probe hand-off the configuration to the dax_pmem driver. Signed-off-by: Dan Williams ---

Re: [PATCH] powercap/rapl: Do not load in virtualized environments

On Thu, May 19, 2016 at 1:36 AM, Prarit Bhargava wrote: > > > On 05/18/2016 07:06 PM, Rafael J. Wysocki wrote: >> On Wed, May 18, 2016 at 2:38 PM, Prarit Bhargava wrote: >>> >>> >>> On 05/17/2016 08:50 PM, Rafael J. Wysocki wrote: On Tue, May 17, 2016

Re: [PATCH] powercap/rapl: Do not load in virtualized environments

On Thu, May 19, 2016 at 1:36 AM, Prarit Bhargava wrote: > > > On 05/18/2016 07:06 PM, Rafael J. Wysocki wrote: >> On Wed, May 18, 2016 at 2:38 PM, Prarit Bhargava wrote: >>> >>> >>> On 05/17/2016 08:50 PM, Rafael J. Wysocki wrote: On Tue, May 17, 2016 at 1:34 PM, Prarit Bhargava wrote:

[PATCH 1/2] libnvdimm, dax: autodetect support

For autodetecting a previously established dax configuration we need the info block to indicate block-device vs device-dax mode, and we need to have the default namespace probe hand-off the configuration to the dax_pmem driver. Signed-off-by: Dan Williams --- drivers/nvdimm/dax_devs.c | 35

[PATCH 0/2] libnvdimm, dax: autodetect fixes

Now that the base device-DAX implementation is settling I am circling back to further flesh out the ndctl unit tests. These 2 fixes fell out as a result. --- Dan Williams (2): libnvdimm, dax: autodetect support libnvdimm, dax: fix alignment validation drivers/nvdimm/dax_devs.c |

[PATCH 0/2] libnvdimm, dax: autodetect fixes

Now that the base device-DAX implementation is settling I am circling back to further flesh out the ndctl unit tests. These 2 fixes fell out as a result. --- Dan Williams (2): libnvdimm, dax: autodetect support libnvdimm, dax: fix alignment validation drivers/nvdimm/dax_devs.c |

Re: [PATCH 5/5] cpufreq: schedutil: do not update rate limit ts when freq is unchanged

On Mon, May 9, 2016 at 11:20 PM, Steve Muckle wrote: > The rate limit timestamp (last_freq_update_time) is currently advanced > anytime schedutil re-evaluates the policy regardless of whether the CPU > frequency is changed or not. This means that utilization updates which

Re: [PATCH 5/5] cpufreq: schedutil: do not update rate limit ts when freq is unchanged

On Mon, May 9, 2016 at 11:20 PM, Steve Muckle wrote: > The rate limit timestamp (last_freq_update_time) is currently advanced > anytime schedutil re-evaluates the policy regardless of whether the CPU > frequency is changed or not. This means that utilization updates which > have no effect can

[PATCH 2/2] libnvdimm, dax: fix alignment validation

Testing the dax-device autodetect support revealed a probe failure with the following result: dax0.1: bad offset: 0x820 dax disabled The original pfn-device implementation inferred the alignment from ilog2(offset), now that the alignment is explicit the is_power_of_2() needs replacing

[PATCH 2/2] libnvdimm, dax: fix alignment validation

Testing the dax-device autodetect support revealed a probe failure with the following result: dax0.1: bad offset: 0x820 dax disabled The original pfn-device implementation inferred the alignment from ilog2(offset), now that the alignment is explicit the is_power_of_2() needs replacing

[PATCH v3] Force cppc_cpufreq to report values in KHz to fix user space reporting

When CPPC is being used by ACPI on arm64, user space tools such as cpupower report CPU frequency values from sysfs that are incorrect. What the driver was doing was reporting the values given by ACPI tables in whatever scale was used to provide them. However, the ACPI spec defines the CPPC

[PATCH v3] Force cppc_cpufreq to report values in KHz to fix user space reporting

When CPPC is being used by ACPI on arm64, user space tools such as cpupower report CPU frequency values from sysfs that are incorrect. What the driver was doing was reporting the values given by ACPI tables in whatever scale was used to provide them. However, the ACPI spec defines the CPPC

Re: [PATCH 4/5] cpufreq: schedutil: map raw required frequency to CPU-supported frequency

On Mon, May 9, 2016 at 11:20 PM, Steve Muckle wrote: > The mechanisms for remote CPU updates and slow-path frequency > transitions are relatively expensive - the former is an IPI while the > latter requires waking up a thread to do work. These activities should > be

Re: [PATCH 4/5] cpufreq: schedutil: map raw required frequency to CPU-supported frequency

On Mon, May 9, 2016 at 11:20 PM, Steve Muckle wrote: > The mechanisms for remote CPU updates and slow-path frequency > transitions are relatively expensive - the former is an IPI while the > latter requires waking up a thread to do work. These activities should > be avoided if they are not

Re: [PATCH] powercap/rapl: Do not load in virtualized environments

On 05/18/2016 07:06 PM, Rafael J. Wysocki wrote: > On Wed, May 18, 2016 at 2:38 PM, Prarit Bhargava wrote: >> >> >> On 05/17/2016 08:50 PM, Rafael J. Wysocki wrote: >>> On Tue, May 17, 2016 at 1:34 PM, Prarit Bhargava wrote: intel_rapl is currently

Re: [PATCH] powercap/rapl: Do not load in virtualized environments

On 05/18/2016 07:06 PM, Rafael J. Wysocki wrote: > On Wed, May 18, 2016 at 2:38 PM, Prarit Bhargava wrote: >> >> >> On 05/17/2016 08:50 PM, Rafael J. Wysocki wrote: >>> On Tue, May 17, 2016 at 1:34 PM, Prarit Bhargava wrote: intel_rapl is currently not supported in virtualized

Re: [PATCH 3/5] sched: cpufreq: call cpufreq hook from remote CPUs

On Mon, May 9, 2016 at 11:20 PM, Steve Muckle wrote: > Without calling the cpufreq hook for a remote wakeup it is possible > for such a wakeup to go unnoticed by cpufreq on the target CPU for up > to a full tick. This can occur if the target CPU is running a > CPU-bound

Re: [PATCH 3/5] sched: cpufreq: call cpufreq hook from remote CPUs

On Mon, May 9, 2016 at 11:20 PM, Steve Muckle wrote: > Without calling the cpufreq hook for a remote wakeup it is possible > for such a wakeup to go unnoticed by cpufreq on the target CPU for up > to a full tick. This can occur if the target CPU is running a > CPU-bound task and preemption does

Re: [PATCH 14/14] ASoC: omap-mcpdm: Add support for pdmclk clock handling

On Wed, May 18, 2016 at 04:46:36PM +0300, Peter Ujfalusi wrote: > McPDM module receives it's functional clock from external source. This > clock is the pdmclk provided by the twl6040 audio IC. If the clock is not > available all register accesses to McPDM fails and the module is not > operational.

Re: [PATCH 14/14] ASoC: omap-mcpdm: Add support for pdmclk clock handling

On Wed, May 18, 2016 at 04:46:36PM +0300, Peter Ujfalusi wrote: > McPDM module receives it's functional clock from external source. This > clock is the pdmclk provided by the twl6040 audio IC. If the clock is not > available all register accesses to McPDM fails and the module is not > operational.

[PATCH 1/2] Documentation: dt: add bindings for ti-cpufreq

Add the device tree bindings document for the TI CPUFreq/OPP driver on AM33xx and AM43xx SoCs. The operating-points-v2 binding allows us to provide an opp-supported-hw property for each OPP to define when it is available. This driver is responsible for reading and parsing registers to determine

[PATCH 1/2] Documentation: dt: add bindings for ti-cpufreq

Add the device tree bindings document for the TI CPUFreq/OPP driver on AM33xx and AM43xx SoCs. The operating-points-v2 binding allows us to provide an opp-supported-hw property for each OPP to define when it is available. This driver is responsible for reading and parsing registers to determine

[PATCH 0/2] cpufreq: Introduce TI CPUFreq/OPP Driver

Hi, This series introduces the ti-cpufreq driver which parses SoC data and provides opp-supported-hw data to the OPP core in order to enable the proper OPPs for the silicon in use. It still relies on the cpufreq-dt driver to actually provide cpufreq and creates the "cpufreq-dt" platform driver

[PATCH 0/2] cpufreq: Introduce TI CPUFreq/OPP Driver

Hi, This series introduces the ti-cpufreq driver which parses SoC data and provides opp-supported-hw data to the OPP core in order to enable the proper OPPs for the silicon in use. It still relies on the cpufreq-dt driver to actually provide cpufreq and creates the "cpufreq-dt" platform driver

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