Re: [PATCH] clk: fixed-factor: add optional dt-binding clock-flags

Hi, [auto build test WARNING on robh/for-next] [also build test WARNING on v4.7-rc4 next-20160623] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Jongsung-Kim/clk-fixed-factor-add-optional-dt

Re: [PATCH] clk: fixed-factor: add optional dt-binding clock-flags

Hi, [auto build test WARNING on robh/for-next] [also build test WARNING on v4.7-rc4 next-20160623] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Jongsung-Kim/clk-fixed-factor-add-optional-dt

Re: [PATCH v5 2/2] [media] atmel-isc: DT binding for Image Sensor Controller driver

Hi Rob, Thank you for your comments. On 6/20/2016 21:25, Rob Herring wrote: On Fri, Jun 17, 2016 at 04:57:14PM +0800, Songjun Wu wrote: DT binding documentation for ISC driver. Signed-off-by: Songjun Wu --- Changes in v5: - Add clock names. Changes in v4: - Remove

Re: [PATCH v5 2/2] [media] atmel-isc: DT binding for Image Sensor Controller driver

Hi Rob, Thank you for your comments. On 6/20/2016 21:25, Rob Herring wrote: On Fri, Jun 17, 2016 at 04:57:14PM +0800, Songjun Wu wrote: DT binding documentation for ISC driver. Signed-off-by: Songjun Wu --- Changes in v5: - Add clock names. Changes in v4: - Remove the isc clock nodes.

Re: [PATCH v3] Doc/memory-barriers: Add Korean translation

Hello, Byungchul, I guess the review is ongoing yet and maybe it requires more days. Can you let me know your estimated time for the review if it doesn't bother you? Thanks, SeongJae Park On Fri, Jun 17, 2016 at 3:24 PM, Minchan Kim wrote: > On Wed, Jun 15, 2016 at

Re: [PATCH v3] Doc/memory-barriers: Add Korean translation

Hello, Byungchul, I guess the review is ongoing yet and maybe it requires more days. Can you let me know your estimated time for the review if it doesn't bother you? Thanks, SeongJae Park On Fri, Jun 17, 2016 at 3:24 PM, Minchan Kim wrote: > On Wed, Jun 15, 2016 at 03:47:34PM +0900,

Re: linux-next: manual merge of the audit tree with the security tree

On Thu, Jun 23, 2016 at 12:14:11PM -0400, Paul Moore wrote: > On Thu, Jun 23, 2016 at 2:01 AM, Heiko Carstens > wrote: > > On Thu, Jun 23, 2016 at 02:18:14PM +1000, Stephen Rothwell wrote: > >> Hi Paul, > >> > >> Today's linux-next merge of the audit tree got a conflict

Re: linux-next: manual merge of the audit tree with the security tree

On Thu, Jun 23, 2016 at 12:14:11PM -0400, Paul Moore wrote: > On Thu, Jun 23, 2016 at 2:01 AM, Heiko Carstens > wrote: > > On Thu, Jun 23, 2016 at 02:18:14PM +1000, Stephen Rothwell wrote: > >> Hi Paul, > >> > >> Today's linux-next merge of the audit tree got a conflict in: > >> > >>

Re: [PATCH 2/6] virtio-balloon: speed up inflate/deflate process

On Mon, Jun 13, 2016 at 05:47:09PM +0800, Liang Li wrote: > The implementation of the current virtio-balloon is not very efficient, > Bellow is test result of time spends on inflating the balloon to 3GB of > a 4GB idle guest: > > a. allocating pages (6.5%, 103ms) > b. sending PFNs to host (68.3%,

Re: [PATCH 2/6] virtio-balloon: speed up inflate/deflate process

On Mon, Jun 13, 2016 at 05:47:09PM +0800, Liang Li wrote: > The implementation of the current virtio-balloon is not very efficient, > Bellow is test result of time spends on inflating the balloon to 3GB of > a 4GB idle guest: > > a. allocating pages (6.5%, 103ms) > b. sending PFNs to host (68.3%,

RE: [PATCH] Maxim/driver: Add driver for maxim ds26522

On Thu, 2016-06-23 at 10:59PM, David Miller wrote: > -Original Message- > From: David Miller [mailto:da...@davemloft.net] > Sent: Thursday, June 23, 2016 10:59 PM > To: Qiang Zhao > Cc: o...@buserror.net; linux-kernel@vger.kernel.org; net...@vger.kernel.org; > Xiaobo

RE: [PATCH] Maxim/driver: Add driver for maxim ds26522

On Thu, 2016-06-23 at 10:59PM, David Miller wrote: > -Original Message- > From: David Miller [mailto:da...@davemloft.net] > Sent: Thursday, June 23, 2016 10:59 PM > To: Qiang Zhao > Cc: o...@buserror.net; linux-kernel@vger.kernel.org; net...@vger.kernel.org; > Xiaobo Xie > Subject: Re:

[PATCH] libnvdimm, pfn, dax: fix initialization vs autodetect for mode + alignment

The updated ndctl unit tests discovered that if a pfn configuration with a 4K alignment is read from the namespace, that alignment will be ignored in favor of the default 2M alignment. The result is that the configuration will fail initialization with a message like: dax6.1: bad offset:

[PATCH] libnvdimm, pfn, dax: fix initialization vs autodetect for mode + alignment

The updated ndctl unit tests discovered that if a pfn configuration with a 4K alignment is read from the namespace, that alignment will be ignored in favor of the default 2M alignment. The result is that the configuration will fail initialization with a message like: dax6.1: bad offset:

Re: [v2,1/2] refactor code parsing size based on memory range

On Wed, 2016-22-06 at 19:25:26 UTC, Hari Bathini wrote: > Currently, crashkernel parameter supports the below syntax to parse size > based on memory range: > > crashkernel=:[,:,...] > > While such parsing is implemented for crashkernel parameter, it applies to > other parameters with

Re: [v2,1/2] refactor code parsing size based on memory range

On Wed, 2016-22-06 at 19:25:26 UTC, Hari Bathini wrote: > Currently, crashkernel parameter supports the below syntax to parse size > based on memory range: > > crashkernel=:[,:,...] > > While such parsing is implemented for crashkernel parameter, it applies to > other parameters with

[PATCH v2 5/5] dmaengine: dma: Use different channel names for each dma

Current driver assumes that child node channel name is either "xlnx,axi-vdma-mm2s-channel" or "xlnx,axi-vdma-s2mm-channel" which is confusing the users of AXI DMA and CDMA. This patch fixes this issue by using different channel names for the AXI DMA and AXI CDMA child nodes. Signed-off-by:

[PATCH v2 5/5] dmaengine: dma: Use different channel names for each dma

Current driver assumes that child node channel name is either "xlnx,axi-vdma-mm2s-channel" or "xlnx,axi-vdma-s2mm-channel" which is confusing the users of AXI DMA and CDMA. This patch fixes this issue by using different channel names for the AXI DMA and AXI CDMA child nodes. Signed-off-by:

[PATCH v2 4/5] dmaengine: dma: Rename driver and config

In the existing vdma driver support for AXI DMA and CDMA got added so the driver is no longer VDMA specific. This patch renames the driver and DT binding doc to xilinx_dma and updates the Kconfig description for all the DMAS. Signed-off-by: Kedareswara rao Appana --- Changes

[PATCH v2 0/5] dmaengine: vdma: AXI DMAS Enhancments

This patch series does the following thing. ---> Add support for AXI DMA Multi-channel DMA mode. ---> Delete AXI DMA binding doc. ---> Rename the driver and update config options. Kedareswara rao Appana (5): Documentation: DT: vdma: Update binding doc for multi-channel dma mode dmaengine:

[PATCH v2 1/5] Documentation: DT: vdma: Update binding doc for multi-channel dma mode

This patch updates the device-tree binding doc for AXI DMA multi channel dma mode. Acked-by: Rob Herring Signed-off-by: Kedareswara rao Appana --- Changes for v2: ---> Added Rob Acked-by. .../devicetree/bindings/dma/xilinx/xilinx_vdma.txt |4 1

[PATCH v2 2/5] dmaengine: vdma: Add support for mulit-channel dma mode

This patch adds support for AXI DMA multi-channel dma mode Multichannel mode enables DMA to connect to multiple masters and slaves on the streaming side. In Multichannel mode AXI DMA supports 2D transfers. Signed-off-by: Kedareswara rao Appana --- Changes for v2: --->

[PATCH v2 4/5] dmaengine: dma: Rename driver and config

In the existing vdma driver support for AXI DMA and CDMA got added so the driver is no longer VDMA specific. This patch renames the driver and DT binding doc to xilinx_dma and updates the Kconfig description for all the DMAS. Signed-off-by: Kedareswara rao Appana --- Changes for v2: ---> None.

[PATCH v2 0/5] dmaengine: vdma: AXI DMAS Enhancments

This patch series does the following thing. ---> Add support for AXI DMA Multi-channel DMA mode. ---> Delete AXI DMA binding doc. ---> Rename the driver and update config options. Kedareswara rao Appana (5): Documentation: DT: vdma: Update binding doc for multi-channel dma mode dmaengine:

[PATCH v2 1/5] Documentation: DT: vdma: Update binding doc for multi-channel dma mode

This patch updates the device-tree binding doc for AXI DMA multi channel dma mode. Acked-by: Rob Herring Signed-off-by: Kedareswara rao Appana --- Changes for v2: ---> Added Rob Acked-by. .../devicetree/bindings/dma/xilinx/xilinx_vdma.txt |4 1 files changed, 4 insertions(+), 0

[PATCH v2 2/5] dmaengine: vdma: Add support for mulit-channel dma mode

This patch adds support for AXI DMA multi-channel dma mode Multichannel mode enables DMA to connect to multiple masters and slaves on the streaming side. In Multichannel mode AXI DMA supports 2D transfers. Signed-off-by: Kedareswara rao Appana --- Changes for v2: ---> Removed mcdma_config as

[PATCH v2 3/5] Documentation: DT: dma: Delete binding doc for AXI DMA

The AXI DMA support is added to the existing AXI VDMA driver. Device tree binding information also updated in the VDMA binding doc. Acked-by: Rob Herring Signed-off-by: Kedareswara rao Appana --- --> Added Rob Acked-by.

[PATCH v2 3/5] Documentation: DT: dma: Delete binding doc for AXI DMA

The AXI DMA support is added to the existing AXI VDMA driver. Device tree binding information also updated in the VDMA binding doc. Acked-by: Rob Herring Signed-off-by: Kedareswara rao Appana --- --> Added Rob Acked-by. .../devicetree/bindings/dma/xilinx/xilinx_dma.txt | 65

Re: [PATCH] clk: fixed-factor: add optional dt-binding clock-flags

Hi, [auto build test ERROR on robh/for-next] [also build test ERROR on v4.7-rc4 next-20160623] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Jongsung-Kim/clk-fixed-factor-add-optional-dt

Re: [PATCH] clk: fixed-factor: add optional dt-binding clock-flags

Hi, [auto build test ERROR on robh/for-next] [also build test ERROR on v4.7-rc4 next-20160623] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Jongsung-Kim/clk-fixed-factor-add-optional-dt

RE: [PATCH] usb: ohci-at91: Suspend the ports while USB suspending

Hi Alan, Sorry for late answer. > -Original Message- > From: Alan Stern [mailto:st...@rowland.harvard.edu] > Sent: 2016年5月13日 2:11 > To: Yang, Wenyou > Cc: Greg Kroah-Hartman ; Ferre, Nicolas > ;

RE: [PATCH] usb: ohci-at91: Suspend the ports while USB suspending

Hi Alan, Sorry for late answer. > -Original Message- > From: Alan Stern [mailto:st...@rowland.harvard.edu] > Sent: 2016年5月13日 2:11 > To: Yang, Wenyou > Cc: Greg Kroah-Hartman ; Ferre, Nicolas > ; linux-...@vger.kernel.org; linux- > ker...@vger.kernel.org;

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

Hi Eric, Today's linux-next merge of the userns tree got a conflict in: fs/proc/root.c between commit: e54ad7f1ee26 ("proc: prevent stacking filesystems on top") from Linus' tree and commit: e94591d0d90c ("proc: Convert proc_mount to use mount_ns") from the userns tree. I fixed it up

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

Hi Eric, Today's linux-next merge of the userns tree got a conflict in: fs/proc/root.c between commit: e54ad7f1ee26 ("proc: prevent stacking filesystems on top") from Linus' tree and commit: e94591d0d90c ("proc: Convert proc_mount to use mount_ns") from the userns tree. I fixed it up

Re: [PATCH 6/7] of_graph: add of_graph_get_top_port()

Hi, [auto build test WARNING on robh/for-next] [also build test WARNING on v4.7-rc4 next-20160623] [cannot apply to glikely/devicetree/next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits

Re: [PATCH 6/7] of_graph: add of_graph_get_top_port()

Hi, [auto build test WARNING on robh/for-next] [also build test WARNING on v4.7-rc4 next-20160623] [cannot apply to glikely/devicetree/next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits

Re: [RESEND][PATCH 0/2] Add pl031 RTC support for Hi6220/HiKey

On Thu, Jun 23, 2016 at 3:39 PM, John Stultz wrote: > This patchset enables the pl031 RTC on the Hi6220 SoC. > > I'd like to submit it for review and consideration to be merged. > (But I've not gotten much feedback on it. Do I have the right > people cc'ed?) Yes. One

Re: [RESEND][PATCH 0/2] Add pl031 RTC support for Hi6220/HiKey

On Thu, Jun 23, 2016 at 3:39 PM, John Stultz wrote: > This patchset enables the pl031 RTC on the Hi6220 SoC. > > I'd like to submit it for review and consideration to be merged. > (But I've not gotten much feedback on it. Do I have the right > people cc'ed?) Yes. One issue is the DT header

Re: mmc: dw_mmc: warning with CONFIG_DMA_API_DEBUG

On 06/24/2016 10:25 AM, Shawn Lin wrote: > Hi Jaehoon, > > On 2016/6/23 19:39, Jaehoon Chung wrote: >> Hi Shawn, >> >> On 06/21/2016 04:39 PM, Shawn Lin wrote: >>> 在 2016/6/21 13:32, Jaehoon Chung 写道: Hi guys, On 06/21/2016 11:31 AM, Shawn Lin wrote: > On 2016/6/21 10:24,

Re: mmc: dw_mmc: warning with CONFIG_DMA_API_DEBUG

On 06/24/2016 10:25 AM, Shawn Lin wrote: > Hi Jaehoon, > > On 2016/6/23 19:39, Jaehoon Chung wrote: >> Hi Shawn, >> >> On 06/21/2016 04:39 PM, Shawn Lin wrote: >>> 在 2016/6/21 13:32, Jaehoon Chung 写道: Hi guys, On 06/21/2016 11:31 AM, Shawn Lin wrote: > On 2016/6/21 10:24,

[PATCH v4 04/16] x86/cpa: In populate_pgd, don't set the pgd entry until it's populated

This avoids pointless races in which another CPU or task might see a partially populated global pgd entry. These races should normally be harmless, but, if another CPU propagates the entry via vmalloc_fault and then populate_pgd fails (due to memory allocation failure, for example), this prevents

[PATCH v4 03/16] x86/mm/hotplug: Don't remove PGD entries in remove_pagetable()

From: Ingo Molnar So when memory hotplug removes a piece of physical memory from pagetable mappings, it also frees the underlying PGD entry. This complicates PGD management, so don't do this. We can keep the PGD mapped and the PUD table all clear - it's only a single 4K page

[PATCH v4 04/16] x86/cpa: In populate_pgd, don't set the pgd entry until it's populated

This avoids pointless races in which another CPU or task might see a partially populated global pgd entry. These races should normally be harmless, but, if another CPU propagates the entry via vmalloc_fault and then populate_pgd fails (due to memory allocation failure, for example), this prevents

[PATCH v4 03/16] x86/mm/hotplug: Don't remove PGD entries in remove_pagetable()

From: Ingo Molnar So when memory hotplug removes a piece of physical memory from pagetable mappings, it also frees the underlying PGD entry. This complicates PGD management, so don't do this. We can keep the PGD mapped and the PUD table all clear - it's only a single 4K page per 512 GB of

[PATCH v4 05/16] x86/mm: Remove kernel_unmap_pages_in_pgd() and efi_cleanup_page_tables()

kernel_unmap_pages_in_pgd() is dangerous: if a pgd entry in init_mm.pgd were to be cleared, callers would need to ensure that the pgd entry hadn't been propagated to any other pgd. Its only caller was efi_cleanup_page_tables(), and that, in turn, was unused, so just delete both functions. This

[PATCH v4 02/16] rxrpc: Avoid using stack memory in SG lists in rxkad

From: Herbert Xu rxkad uses stack memory in SG lists which would not work if stacks were allocated from vmalloc memory. In fact, in most cases this isn't even necessary as the stack memory ends up getting copied over to kmalloc memory. This patch eliminates all the

[PATCH v4 05/16] x86/mm: Remove kernel_unmap_pages_in_pgd() and efi_cleanup_page_tables()

kernel_unmap_pages_in_pgd() is dangerous: if a pgd entry in init_mm.pgd were to be cleared, callers would need to ensure that the pgd entry hadn't been propagated to any other pgd. Its only caller was efi_cleanup_page_tables(), and that, in turn, was unused, so just delete both functions. This

[PATCH v4 02/16] rxrpc: Avoid using stack memory in SG lists in rxkad

From: Herbert Xu rxkad uses stack memory in SG lists which would not work if stacks were allocated from vmalloc memory. In fact, in most cases this isn't even necessary as the stack memory ends up getting copied over to kmalloc memory. This patch eliminates all the unnecessary stack memory

[PATCH v4 00/16] Virtually mapped stacks with guard pages (x86, core)

Since the dawn of time, a kernel stack overflow has been a real PITA to debug, has caused nondeterministic crashes some time after the actual overflow, and has generally been easy to exploit for root. With this series, arches can enable HAVE_ARCH_VMAP_STACK. Arches that enable it (just x86 for

[PATCH v4 00/16] Virtually mapped stacks with guard pages (x86, core)

Since the dawn of time, a kernel stack overflow has been a real PITA to debug, has caused nondeterministic crashes some time after the actual overflow, and has generally been easy to exploit for root. With this series, arches can enable HAVE_ARCH_VMAP_STACK. Arches that enable it (just x86 for

[PATCH v4 01/16] bluetooth: Switch SMP to crypto_cipher_encrypt_one()

SMP does ECB crypto on stack buffers. This is complicated and fragile, and it will not work if the stack is virtually allocated. Switch to the crypto_cipher interface, which is simpler and safer. Cc: Marcel Holtmann Cc: Gustavo Padovan Cc: Johan

[PATCH v4 07/16] mm: Fix memcg stack accounting for sub-page stacks

We should account for stacks regardless of stack size, and we need to account in sub-page units if THREAD_SIZE < PAGE_SIZE. Change the units to kilobytes and Move it into account_kernel_stack(). Fixes: 12580e4b54ba8 ("mm: memcontrol: report kernel stack usage in cgroup2 memory.stat") Cc:

[PATCH v4 01/16] bluetooth: Switch SMP to crypto_cipher_encrypt_one()

SMP does ECB crypto on stack buffers. This is complicated and fragile, and it will not work if the stack is virtually allocated. Switch to the crypto_cipher interface, which is simpler and safer. Cc: Marcel Holtmann Cc: Gustavo Padovan Cc: Johan Hedberg Cc: "David S. Miller" Cc:

[PATCH v4 07/16] mm: Fix memcg stack accounting for sub-page stacks

We should account for stacks regardless of stack size, and we need to account in sub-page units if THREAD_SIZE < PAGE_SIZE. Change the units to kilobytes and Move it into account_kernel_stack(). Fixes: 12580e4b54ba8 ("mm: memcontrol: report kernel stack usage in cgroup2 memory.stat") Cc:

[PATCH v4 10/16] x86/die: Don't try to recover from an OOPS on a non-default stack

It's not going to work, because the scheduler will explode if we try to schedule when running on an IST stack or similar. This will matter when we let kernel stack overflows (which are #DF) call die(). Signed-off-by: Andy Lutomirski --- arch/x86/kernel/dumpstack.c | 3 +++ 1

[PATCH v4 09/16] fork: Add generic vmalloced stack support

If CONFIG_VMAP_STACK is selected, kernel stacks are allocated with vmalloc_node. Signed-off-by: Andy Lutomirski --- arch/Kconfig| 29 + arch/ia64/include/asm/thread_info.h | 2 +- include/linux/sched.h | 15 +++

[PATCH v4 10/16] x86/die: Don't try to recover from an OOPS on a non-default stack

It's not going to work, because the scheduler will explode if we try to schedule when running on an IST stack or similar. This will matter when we let kernel stack overflows (which are #DF) call die(). Signed-off-by: Andy Lutomirski --- arch/x86/kernel/dumpstack.c | 3 +++ 1 file changed, 3

[PATCH v4 09/16] fork: Add generic vmalloced stack support

If CONFIG_VMAP_STACK is selected, kernel stacks are allocated with vmalloc_node. Signed-off-by: Andy Lutomirski --- arch/Kconfig| 29 + arch/ia64/include/asm/thread_info.h | 2 +- include/linux/sched.h | 15 +++ kernel/fork.c

[PATCH v4 14/16] x86/dumpstack/64: Handle faults when printing the "Stack:" part of an OOPS

If we overflow the stack into a guard page, we'll recursively fault when trying to dump the contents of the guard page. Use probe_kernel_address so we can recover if this happens. Signed-off-by: Andy Lutomirski --- arch/x86/kernel/dumpstack_64.c | 12 ++-- 1 file

[PATCH v4 14/16] x86/dumpstack/64: Handle faults when printing the "Stack:" part of an OOPS

If we overflow the stack into a guard page, we'll recursively fault when trying to dump the contents of the guard page. Use probe_kernel_address so we can recover if this happens. Signed-off-by: Andy Lutomirski --- arch/x86/kernel/dumpstack_64.c | 12 ++-- 1 file changed, 10

[PATCH v4 13/16] x86/dumpstack: Try harder to get a call trace on stack overflow

If we overflow the stack, print_context_stack will abort. Detect this case and rewind back into the valid part of the stack so that we can trace it. Signed-off-by: Andy Lutomirski --- arch/x86/kernel/dumpstack.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-)

[PATCH v4 13/16] x86/dumpstack: Try harder to get a call trace on stack overflow

If we overflow the stack, print_context_stack will abort. Detect this case and rewind back into the valid part of the stack so that we can trace it. Signed-off-by: Andy Lutomirski --- arch/x86/kernel/dumpstack.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git

[PATCH v4 15/16] x86/mm/64: Enable vmapped stacks

This allows x86_64 kernels to enable vmapped stacks. There are a couple of interesting bits. First, x86 lazily faults in top-level paging entries for the vmalloc area. This won't work if we get a page fault while trying to access the stack: the CPU will promote it to a double-fault and we'll

[PATCH v4 12/16] x86/dumpstack: When dumping stack bytes due to OOPS, start with regs->sp

The comment suggests that show_stack(NULL, NULL) should backtrace the current context, but the code doesn't match the comment. If regs are given, start the "Stack:" hexdump at regs->sp. Signed-off-by: Andy Lutomirski --- arch/x86/kernel/dumpstack_32.c | 4 +++-

[PATCH v4 16/16] x86/mm: Improve stack-overflow #PF handling

If we get a page fault indicating kernel stack overflow, invoke handle_stack_overflow(). To prevent us from overflowing the stack again while handling the overflow (because we are likely to have very little stack space left), call handle_stack_overflow() on the double-fault stack Signed-off-by:

[PATCH v4 11/16] x86/dumpstack: When OOPSing, rewind the stack before do_exit

If we call do_exit with a clean stack, we greatly reduce the risk of recursive oopses due to stack overflow in do_exit, and we allow do_exit to work even if we OOPS from an IST stack. The latter gives us a much better chance of surviving long enough after we detect a stack overflow to write out

[PATCH v4 15/16] x86/mm/64: Enable vmapped stacks

This allows x86_64 kernels to enable vmapped stacks. There are a couple of interesting bits. First, x86 lazily faults in top-level paging entries for the vmalloc area. This won't work if we get a page fault while trying to access the stack: the CPU will promote it to a double-fault and we'll

[PATCH v4 12/16] x86/dumpstack: When dumping stack bytes due to OOPS, start with regs->sp

The comment suggests that show_stack(NULL, NULL) should backtrace the current context, but the code doesn't match the comment. If regs are given, start the "Stack:" hexdump at regs->sp. Signed-off-by: Andy Lutomirski --- arch/x86/kernel/dumpstack_32.c | 4 +++- arch/x86/kernel/dumpstack_64.c |

[PATCH v4 16/16] x86/mm: Improve stack-overflow #PF handling

If we get a page fault indicating kernel stack overflow, invoke handle_stack_overflow(). To prevent us from overflowing the stack again while handling the overflow (because we are likely to have very little stack space left), call handle_stack_overflow() on the double-fault stack Signed-off-by:

[PATCH v4 11/16] x86/dumpstack: When OOPSing, rewind the stack before do_exit

If we call do_exit with a clean stack, we greatly reduce the risk of recursive oopses due to stack overflow in do_exit, and we allow do_exit to work even if we OOPS from an IST stack. The latter gives us a much better chance of surviving long enough after we detect a stack overflow to write out

[PATCH v4 06/16] mm: Track NR_KERNEL_STACK in KiB instead of number of stacks

Currently, NR_KERNEL_STACK tracks the number of kernel stacks in a zone. This only makes sense if each kernel stack exists entirely in one zone, and allowing vmapped stacks could break this assumption. Since frv has THREAD_SIZE < PAGE_SIZE, we need to track kernel stack allocations in a unit

[PATCH v4 06/16] mm: Track NR_KERNEL_STACK in KiB instead of number of stacks

Currently, NR_KERNEL_STACK tracks the number of kernel stacks in a zone. This only makes sense if each kernel stack exists entirely in one zone, and allowing vmapped stacks could break this assumption. Since frv has THREAD_SIZE < PAGE_SIZE, we need to track kernel stack allocations in a unit

[PATCH v4 08/16] dma-api: Teach the "DMA-from-stack" check about vmapped stacks

If we're using CONFIG_VMAP_STACK and we manage to point an sg entry at the stack, then either the sg page will be in highmem or sg_virt will return the direct-map alias. In neither case will the existing check_for_stack() implementation realize that it's a stack page. Fix it by explicitly

[PATCH v4 08/16] dma-api: Teach the "DMA-from-stack" check about vmapped stacks

If we're using CONFIG_VMAP_STACK and we manage to point an sg entry at the stack, then either the sg page will be in highmem or sg_virt will return the direct-map alias. In neither case will the existing check_for_stack() implementation realize that it's a stack page. Fix it by explicitly

Re: [PATCH v6 2/2] mtd: nand: sunxi: add reset line support

On Fri, 24 Jun 2016 07:20:38 +0800 Icenowy Zheng wrote: > In my opinion, return directly PTR_ERR(nfc->reset) is OK here. > If devm_reset_control_get_optional() return -EPROBE_DEFER, the code here will > also return it. However, if we get other error, why should it return >

Re: [PATCH v6 2/2] mtd: nand: sunxi: add reset line support

On Fri, 24 Jun 2016 07:20:38 +0800 Icenowy Zheng wrote: > In my opinion, return directly PTR_ERR(nfc->reset) is OK here. > If devm_reset_control_get_optional() return -EPROBE_DEFER, the code here will > also return it. However, if we get other error, why should it return > -EPROBE_DEFER again?

Re: [PATCH] capabilities: add capability cgroup controller

On Thu, Jun 23, 2016 at 6:14 PM, Topi Miettinen wrote: > On 06/23/16 23:46, Andrew Morton wrote: >> On Thu, 23 Jun 2016 18:07:10 +0300 Topi Miettinen wrote: >> >>> There are many basic ways to control processes, including capabilities, >>> cgroups and

Re: [PATCH] capabilities: add capability cgroup controller

On Thu, Jun 23, 2016 at 6:14 PM, Topi Miettinen wrote: > On 06/23/16 23:46, Andrew Morton wrote: >> On Thu, 23 Jun 2016 18:07:10 +0300 Topi Miettinen wrote: >> >>> There are many basic ways to control processes, including capabilities, >>> cgroups and resource limits. However, there are far

[PATCH v2] clk: fixed-factor: add optional dt-binding clock-flags

There is no way to set additional flags for a DT-initialized fixed- factor-clock, and it can be problematic i.e., when the clock rate needs to be changed. [1][2] This patch introduces an optional dt-binding named "clock-flags" to be used for passing any needed flags from dts. [1]

[PATCH v2] clk: fixed-factor: add optional dt-binding clock-flags

There is no way to set additional flags for a DT-initialized fixed- factor-clock, and it can be problematic i.e., when the clock rate needs to be changed. [1][2] This patch introduces an optional dt-binding named "clock-flags" to be used for passing any needed flags from dts. [1]

RE: [PATCH v4] vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Friday, June 24, 2016 11:37 AM > > On Fri, 24 Jun 2016 10:52:58 +0800 > Yongji Xie wrote: > > On 2016/6/24 0:12, Alex Williamson wrote: > > > On Mon, 30 May 2016 21:06:37 +0800 > > > Yongji Xie

RE: [PATCH v4] vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Friday, June 24, 2016 11:37 AM > > On Fri, 24 Jun 2016 10:52:58 +0800 > Yongji Xie wrote: > > On 2016/6/24 0:12, Alex Williamson wrote: > > > On Mon, 30 May 2016 21:06:37 +0800 > > > Yongji Xie wrote: > > >> +static void

Re: [PATCH V3] clocksource/drivers/arc: Convert init function to return error

On Friday 17 June 2016 03:39 PM, Daniel Lezcano wrote: > The init functions do not return any error. They behave as the following: > > - panic, thus leading to a kernel crash while another timer may work and >make the system boot up correctly > > or > > - print an error and let

Re: [PATCH V3] clocksource/drivers/arc: Convert init function to return error

On Friday 17 June 2016 03:39 PM, Daniel Lezcano wrote: > The init functions do not return any error. They behave as the following: > > - panic, thus leading to a kernel crash while another timer may work and >make the system boot up correctly > > or > > - print an error and let

[PATCH] clk: fixed-factor: add optional dt-binding clock-flags

There is no way to set additional flags for a DT-initialized fixed- factor-clock, and it can be problematic i.e., when the clock rate needs to be changed. [1][2] This patch introduces an optional dt-binding named "clock-flags" to be used for passing any needed flags from dts. [1]

[PATCH] clk: fixed-factor: add optional dt-binding clock-flags

There is no way to set additional flags for a DT-initialized fixed- factor-clock, and it can be problematic i.e., when the clock rate needs to be changed. [1][2] This patch introduces an optional dt-binding named "clock-flags" to be used for passing any needed flags from dts. [1]

Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

On Fri, Jun 24, 2016 at 3:20 AM, wrote: > From: Ondrej Jirman > > Add label to the first cpu so that it can be referenced > from derived dts files. > > Signed-off-by: Ondrej Jirman > --- > arch/arm/boot/dts/sun8i-h3.dtsi | 2 +- > 1

Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

On Fri, Jun 24, 2016 at 3:20 AM, wrote: > From: Ondrej Jirman > > Add label to the first cpu so that it can be referenced > from derived dts files. > > Signed-off-by: Ondrej Jirman > --- > arch/arm/boot/dts/sun8i-h3.dtsi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

[PATCH V3] printk: Create pr_ functions

Using functions instead of macros can reduce overall code size by eliminating unnecessary "KERN_SOH" prefixes from format strings. defconfig x86-64: $ size vmlinux* textdata bss dec hex filename 10193570 4331464 1105920 15630954 ee826a vmlinux.new 10192623 4335560 1105920

[PATCH V3] printk: Create pr_ functions

Using functions instead of macros can reduce overall code size by eliminating unnecessary "KERN_SOH" prefixes from format strings. defconfig x86-64: $ size vmlinux* textdata bss dec hex filename 10193570 4331464 1105920 15630954 ee826a vmlinux.new 10192623 4335560 1105920

Re: [PATCH 07/14] regulator: SY8106A regulator driver

On Fri, Jun 24, 2016 at 3:20 AM, wrote: > From: Ondrej Jirman > > SY8106A is I2C attached single output voltage regulator > made by Silergy. > > Signed-off-by: Ondrej Jirman > --- > drivers/regulator/Kconfig | 8 +- >

Re: [PATCH 07/14] regulator: SY8106A regulator driver

On Fri, Jun 24, 2016 at 3:20 AM, wrote: > From: Ondrej Jirman > > SY8106A is I2C attached single output voltage regulator > made by Silergy. > > Signed-off-by: Ondrej Jirman > --- > drivers/regulator/Kconfig | 8 +- > drivers/regulator/Makefile| 2 +- >

[PATCH] powercap/intel_rapl: Add support for Ivy Bridge server

It's confirmed that RAPL works as expected on Ivy Bridge servers. Tested against processor: Intel(R) Xeon(R) CPU E5-2697 v2 @2.70GHz Signed-off-by: Xiaolong Wang --- drivers/powercap/intel_rapl.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH] powercap/intel_rapl: Add support for Ivy Bridge server

It's confirmed that RAPL works as expected on Ivy Bridge servers. Tested against processor: Intel(R) Xeon(R) CPU E5-2697 v2 @2.70GHz Signed-off-by: Xiaolong Wang --- drivers/powercap/intel_rapl.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/powercap/intel_rapl.c

Re: [PATCH v4] vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive

On Fri, 24 Jun 2016 10:52:58 +0800 Yongji Xie wrote: > On 2016/6/24 0:12, Alex Williamson wrote: > > On Mon, 30 May 2016 21:06:37 +0800 > > Yongji Xie wrote: > >> +static void vfio_pci_probe_mmaps(struct vfio_pci_device *vdev) > >> +{ > >> +

Re: [PATCH v4] vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive

On Fri, 24 Jun 2016 10:52:58 +0800 Yongji Xie wrote: > On 2016/6/24 0:12, Alex Williamson wrote: > > On Mon, 30 May 2016 21:06:37 +0800 > > Yongji Xie wrote: > >> +static void vfio_pci_probe_mmaps(struct vfio_pci_device *vdev) > >> +{ > >> + struct resource *res; > >> + int bar; > >> + struct

Re: [PATCH] powerpc/mm: update arch_{add,remove}_memory() for radix

On 24/06/16 03:17, Aneesh Kumar K.V wrote: > Reza Arbab writes: > >> These functions are making direct calls to the hash table APIs, >> leading to a BUG() on systems using radix. >> >> Switch them to the vmemmap_{create,remove}_mapping() wrappers, and >> move to the

Re: [PATCH] powerpc/mm: update arch_{add,remove}_memory() for radix

On 24/06/16 03:17, Aneesh Kumar K.V wrote: > Reza Arbab writes: > >> These functions are making direct calls to the hash table APIs, >> leading to a BUG() on systems using radix. >> >> Switch them to the vmemmap_{create,remove}_mapping() wrappers, and >> move to the __meminit section. > > >

Re: [PATCH 03/14] thermal: Add support for sun8i THS on Allwinner H3

Hi, On Fri, Jun 24, 2016 at 3:20 AM, wrote: > From: Ondrej Jirman > The subject could read: thermal: sun8i_ths: Add support for the thermal sensor on Allwinner H3 > This patch adds support for the sun8i thermal sensor on > Allwinner H3 SoC. > >

Re: [PATCH 03/14] thermal: Add support for sun8i THS on Allwinner H3

Hi, On Fri, Jun 24, 2016 at 3:20 AM, wrote: > From: Ondrej Jirman > The subject could read: thermal: sun8i_ths: Add support for the thermal sensor on Allwinner H3 > This patch adds support for the sun8i thermal sensor on > Allwinner H3 SoC. > > Signed-off-by: Ondřej Jirman > --- >

  1   2   3   4   5   6   7   8   9   10   >