[PATCH v5 7/8] drivers/fsi: occ: Add miscdevice

From: "Edward A. James" Add a miscdevice for the occ to allow userspace access through standard file operations. Signed-off-by: Edward A. James --- drivers/fsi/fsi-occ.c | 264 ++ 1 file changed, 264

[PATCH v5 7/8] drivers/fsi: occ: Add miscdevice

From: "Edward A. James" Add a miscdevice for the occ to allow userspace access through standard file operations. Signed-off-by: Edward A. James --- drivers/fsi/fsi-occ.c | 264 ++ 1 file changed, 264 insertions(+) diff --git

[PATCH v5 0/8] drivers/fsi: Add SBEFIFO and OCC client drivers

From: "Edward A. James" This series adds two FSI-based device drivers; one for the SBEFIFO and one for the On-Chip Controller (OCC). IBM POWER9 processors contain some embedded hardware and software bits collectively referred to as the self boot engine (SBE). One role of

[PATCH v5 6/8] drivers/fsi: Add On-Chip Controller (OCC) driver

From: "Edward A. James" The OCC is a device embedded on a POWER processor that collects and aggregates sensor data from the processor and system. The OCC can provide the raw sensor data as well as perform thermal and power management on the system. This driver provides an

[PATCH v5 0/8] drivers/fsi: Add SBEFIFO and OCC client drivers

From: "Edward A. James" This series adds two FSI-based device drivers; one for the SBEFIFO and one for the On-Chip Controller (OCC). IBM POWER9 processors contain some embedded hardware and software bits collectively referred to as the self boot engine (SBE). One role of the SBE is to act as

[PATCH v5 6/8] drivers/fsi: Add On-Chip Controller (OCC) driver

From: "Edward A. James" The OCC is a device embedded on a POWER processor that collects and aggregates sensor data from the processor and system. The OCC can provide the raw sensor data as well as perform thermal and power management on the system. This driver provides an atomic communications

Re: [PATCH] intel_ips: Convert timers to use timer_setup()

On Mon, Nov 20, 2017 at 11:45 AM, Darren Hart wrote: > On Fri, Nov 17, 2017 at 05:30:48PM -0800, Kees Cook wrote: >> On Fri, Nov 3, 2017 at 5:26 AM, Andy Shevchenko >> wrote: >> > On Thu, Nov 2, 2017 at 9:55 PM, Kees Cook

Re: [PATCH] intel_ips: Convert timers to use timer_setup()

On Mon, Nov 20, 2017 at 11:45 AM, Darren Hart wrote: > On Fri, Nov 17, 2017 at 05:30:48PM -0800, Kees Cook wrote: >> On Fri, Nov 3, 2017 at 5:26 AM, Andy Shevchenko >> wrote: >> > On Thu, Nov 2, 2017 at 9:55 PM, Kees Cook wrote: >> >> On Thu, Oct 5, 2017 at 1:41 AM, Andy Shevchenko >> >>

Re: [patches] Re: [PATCH v9 03/12] dt-bindings: RISC-V CPU Bindings

On Sun, 19 Nov 2017 23:35:28 PST (-0800), j.neuschae...@gmx.net wrote: Hi Palmer, On Thu, Oct 05, 2017 at 11:16:33AM +0100, Mark Rutland wrote: [...] I would *strongly* recommend that from day one, you determine the SMP bringup mechanism via an enable-method property, and document the contract

Re: [patches] Re: [PATCH v9 03/12] dt-bindings: RISC-V CPU Bindings

On Sun, 19 Nov 2017 23:35:28 PST (-0800), j.neuschae...@gmx.net wrote: Hi Palmer, On Thu, Oct 05, 2017 at 11:16:33AM +0100, Mark Rutland wrote: [...] I would *strongly* recommend that from day one, you determine the SMP bringup mechanism via an enable-method property, and document the contract

Re: [PATCH] intel_ips: Convert timers to use timer_setup()

On Fri, Nov 17, 2017 at 05:30:48PM -0800, Kees Cook wrote: > On Fri, Nov 3, 2017 at 5:26 AM, Andy Shevchenko > wrote: > > On Thu, Nov 2, 2017 at 9:55 PM, Kees Cook wrote: > >> On Thu, Oct 5, 2017 at 1:41 AM, Andy Shevchenko > >>

Re: [PATCH] intel_ips: Convert timers to use timer_setup()

On Fri, Nov 17, 2017 at 05:30:48PM -0800, Kees Cook wrote: > On Fri, Nov 3, 2017 at 5:26 AM, Andy Shevchenko > wrote: > > On Thu, Nov 2, 2017 at 9:55 PM, Kees Cook wrote: > >> On Thu, Oct 5, 2017 at 1:41 AM, Andy Shevchenko > >> wrote: > >>> On Thu, Oct 5, 2017 at 3:54 AM, Kees Cook wrote: >

Re: [RFC PATCH v3 for 4.15 08/24] Provide cpu_opv system call

On Mon, 20 Nov 2017, Mathieu Desnoyers wrote: > - On Nov 20, 2017, at 12:48 PM, Thomas Gleixner t...@linutronix.de wrote: > The use-case for 4k memcpy operation is a per-cpu ring buffer where > the rseq fast-path does the following: > > - ring buffer push: in the rseq asm instruction

Re: [RFC PATCH v3 for 4.15 08/24] Provide cpu_opv system call

On Mon, 20 Nov 2017, Mathieu Desnoyers wrote: > - On Nov 20, 2017, at 12:48 PM, Thomas Gleixner t...@linutronix.de wrote: > The use-case for 4k memcpy operation is a per-cpu ring buffer where > the rseq fast-path does the following: > > - ring buffer push: in the rseq asm instruction

Re: [PATCH 4.4 00/59] 4.4.100-stable review

On Mon, Nov 20, 2017 at 08:27:07PM +0100, Greg Kroah-Hartman wrote: > On Sun, Nov 19, 2017 at 12:48:51PM -0700, Nathan Chancellor wrote: > > On Sun, Nov 19, 2017 at 03:32:08PM +0100, Greg Kroah-Hartman wrote: > > > > Merged, compiled, and flashed onto my Pixel 2 XL. No initial issues > > noticed

Re: [PATCH 4.4 00/59] 4.4.100-stable review

On Mon, Nov 20, 2017 at 08:27:07PM +0100, Greg Kroah-Hartman wrote: > On Sun, Nov 19, 2017 at 12:48:51PM -0700, Nathan Chancellor wrote: > > On Sun, Nov 19, 2017 at 03:32:08PM +0100, Greg Kroah-Hartman wrote: > > > > Merged, compiled, and flashed onto my Pixel 2 XL. No initial issues > > noticed

[PATCH 1/1] mm/cma: fix alloc_contig_range ret code/potential leak

If the call __alloc_contig_migrate_range() in alloc_contig_range returns -EBUSY, processing continues so that test_pages_isolated() is called where there is a tracepoint to identify the busy pages. However, it is possible for busy pages to become available between the calls to these two routines.

[PATCH 1/1] mm/cma: fix alloc_contig_range ret code/potential leak

If the call __alloc_contig_migrate_range() in alloc_contig_range returns -EBUSY, processing continues so that test_pages_isolated() is called where there is a tracepoint to identify the busy pages. However, it is possible for busy pages to become available between the calls to these two routines.

[PATCH 0/1] mm/cma: fix alloc_contig_range ret code/potential leak

In an attempt to make contiguous allocation routines more available to drivers, I have been experimenting with code similar to that used by alloc_gigantic_page(). While stressing this code with many other allocations and frees in progress, I would sometimes notice large 'leaks' of page ranges. I

[PATCH 0/1] mm/cma: fix alloc_contig_range ret code/potential leak

In an attempt to make contiguous allocation routines more available to drivers, I have been experimenting with code similar to that used by alloc_gigantic_page(). While stressing this code with many other allocations and frees in progress, I would sometimes notice large 'leaks' of page ranges. I

[PATCH v15 2/5] net: e100: Replace PCI pool old API

From: Romain Perier The PCI pool API is deprecated. This commit replaces the PCI pool old API by the appropriate function with the DMA pool API. Signed-off-by: Romain Perier Acked-by: Peter Senna Tschudin

[PATCH v15 2/5] net: e100: Replace PCI pool old API

From: Romain Perier The PCI pool API is deprecated. This commit replaces the PCI pool old API by the appropriate function with the DMA pool API. Signed-off-by: Romain Perier Acked-by: Peter Senna Tschudin Acked-by: Jeff Kirsher Tested-by: Peter Senna Tschudin ---

Re: [PATCH v2 18/18] arm64: select ARCH_SUPPORTS_LTO_CLANG

On Mon, Nov 20, 2017 at 06:05:55PM +, Will Deacon wrote: > Although the current direction of the C++ committee is to prefer > that dependencies are explicitly "marked", this is not deemed to be > acceptable for the kernel (in other words, everything is always considered > "marked"). Yeah,

Re: [PATCH v2 18/18] arm64: select ARCH_SUPPORTS_LTO_CLANG

On Mon, Nov 20, 2017 at 06:05:55PM +, Will Deacon wrote: > Although the current direction of the C++ committee is to prefer > that dependencies are explicitly "marked", this is not deemed to be > acceptable for the kernel (in other words, everything is always considered > "marked"). Yeah,

[PATCH v15 1/5] block: DAC960: Replace PCI pool old API

From: Romain Perier The PCI pool API is deprecated. This commit replaces the PCI pool old API by the appropriate function with the DMA pool API. Signed-off-by: Romain Perier Acked-by: Peter Senna Tschudin

[PATCH v15 1/5] block: DAC960: Replace PCI pool old API

From: Romain Perier The PCI pool API is deprecated. This commit replaces the PCI pool old API by the appropriate function with the DMA pool API. Signed-off-by: Romain Perier Acked-by: Peter Senna Tschudin Tested-by: Peter Senna Tschudin --- drivers/block/DAC960.c | 38

[PATCH v15 4/5] scsi: mpt3sas: Replace PCI pool old API

The PCI pool API is deprecated. This commit replaces the PCI pool old API by the appropriate function with the DMA pool API. Signed-off-by: Romain Perier --- drivers/scsi/mpt3sas/mpt3sas_base.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff

[PATCH v15 4/5] scsi: mpt3sas: Replace PCI pool old API

The PCI pool API is deprecated. This commit replaces the PCI pool old API by the appropriate function with the DMA pool API. Signed-off-by: Romain Perier --- drivers/scsi/mpt3sas/mpt3sas_base.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git

[PATCH v15 3/5] hinic: Replace PCI pool old API

From: Romain Perier The PCI pool API is deprecated. This commit replaces the PCI pool old API by the appropriate function with the DMA pool API. Signed-off-by: Romain Perier --- drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c | 10

[PATCH v15 3/5] hinic: Replace PCI pool old API

From: Romain Perier The PCI pool API is deprecated. This commit replaces the PCI pool old API by the appropriate function with the DMA pool API. Signed-off-by: Romain Perier --- drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c | 10 +-

[PATCH v15 0/5] Replace PCI pool by DMA pool API

by the dma pool API and remove the defines. Changes in v15: - Rebased series onto next-20171120 - Added patch 04/05 for mpt3sas scsi driver Changes in v14: - Rebased series onto next-20171018 - Rebased patch 03/05 on latest driver Changes in v13: - Rebased series onto next-20170906 - Added a new

[PATCH v15 0/5] Replace PCI pool by DMA pool API

by the dma pool API and remove the defines. Changes in v15: - Rebased series onto next-20171120 - Added patch 04/05 for mpt3sas scsi driver Changes in v14: - Rebased series onto next-20171018 - Rebased patch 03/05 on latest driver Changes in v13: - Rebased series onto next-20170906 - Added a new

[PATCH v15 5/5] PCI: Remove PCI pool macro functions

From: Romain Perier Now that all the drivers use dma pool API, we can remove the macro functions for PCI pool. Signed-off-by: Romain Perier Reviewed-by: Peter Senna Tschudin --- include/linux/pci.h | 9

[PATCH v15 5/5] PCI: Remove PCI pool macro functions

From: Romain Perier Now that all the drivers use dma pool API, we can remove the macro functions for PCI pool. Signed-off-by: Romain Perier Reviewed-by: Peter Senna Tschudin --- include/linux/pci.h | 9 - 1 file changed, 9 deletions(-) diff --git a/include/linux/pci.h

Re: Prototype patch for Linux-kernel memory model

On Mon, Nov 20, 2017 at 05:35:04PM +0100, Andrea Parri wrote: > On Fri, Nov 17, 2017 at 07:27:46PM +0800, Boqun Feng wrote: > > On Wed, Nov 15, 2017 at 08:37:49AM -0800, Paul E. McKenney wrote: > > > On Tue, Nov 14, 2017 at 09:15:05AM -0800, Paul E. McKenney wrote: > > > > On Tue, Nov 14, 2017 at

Re: Prototype patch for Linux-kernel memory model

On Mon, Nov 20, 2017 at 05:35:04PM +0100, Andrea Parri wrote: > On Fri, Nov 17, 2017 at 07:27:46PM +0800, Boqun Feng wrote: > > On Wed, Nov 15, 2017 at 08:37:49AM -0800, Paul E. McKenney wrote: > > > On Tue, Nov 14, 2017 at 09:15:05AM -0800, Paul E. McKenney wrote: > > > > On Tue, Nov 14, 2017 at

Re: [PATCH v2 18/18] arm64: select ARCH_SUPPORTS_LTO_CLANG

On Mon, Nov 20, 2017 at 06:05:55PM +, Will Deacon wrote: > This is a thorny issue, but RCU (specifically rcu_dereference but probably > also some READ_ONCEs) relies on being able to utilise syntactic dependency > chains to order local accesses to shared variables. Well, we used to have

Re: [PATCH v2 18/18] arm64: select ARCH_SUPPORTS_LTO_CLANG

On Mon, Nov 20, 2017 at 06:05:55PM +, Will Deacon wrote: > This is a thorny issue, but RCU (specifically rcu_dereference but probably > also some READ_ONCEs) relies on being able to utilise syntactic dependency > chains to order local accesses to shared variables. Well, we used to have

Re: [PATCH 4.4 00/59] 4.4.100-stable review

On Sun, Nov 19, 2017 at 12:48:51PM -0700, Nathan Chancellor wrote: > On Sun, Nov 19, 2017 at 03:32:08PM +0100, Greg Kroah-Hartman wrote: > > Merged, compiled, and flashed onto my Pixel 2 XL. No initial issues > noticed in either dmesg or general usage. Wonderful, thanks for testing. Just a side

Re: [PATCH 4.4 00/59] 4.4.100-stable review

On Sun, Nov 19, 2017 at 12:48:51PM -0700, Nathan Chancellor wrote: > On Sun, Nov 19, 2017 at 03:32:08PM +0100, Greg Kroah-Hartman wrote: > > Merged, compiled, and flashed onto my Pixel 2 XL. No initial issues > noticed in either dmesg or general usage. Wonderful, thanks for testing. Just a side

Re: [PATCH] mmc: sdhci-msm: Optionally wait for signal level changes

On 11/20, Bjorn Andersson wrote: > Not all instances of the SDCC core supports changing signal voltage and > as such will not generate a power interrupt when the software attempts > to change the voltage. This results in probing the eMMC on some devices > to take over 2 minutes. > > Check that

Re: [PATCH] mmc: sdhci-msm: Optionally wait for signal level changes

On 11/20, Bjorn Andersson wrote: > Not all instances of the SDCC core supports changing signal voltage and > as such will not generate a power interrupt when the software attempts > to change the voltage. This results in probing the eMMC on some devices > to take over 2 minutes. > > Check that

Re: [PATCH 4.9 00/72] 4.9.64-stable review

On Mon, Nov 20, 2017 at 11:52:32AM +0530, Naresh Kamboju wrote: > On 19 November 2017 at 20:08, Greg Kroah-Hartman > wrote: > > This is the start of the stable review cycle for the 4.9.64 release. > > There are 72 patches in this series, all will be posted as a

Re: [PATCH 4.9 00/72] 4.9.64-stable review

On Mon, Nov 20, 2017 at 11:52:32AM +0530, Naresh Kamboju wrote: > On 19 November 2017 at 20:08, Greg Kroah-Hartman > wrote: > > This is the start of the stable review cycle for the 4.9.64 release. > > There are 72 patches in this series, all will be posted as a response > > to this one. If

Re: [PATCH v2 18/18] arm64: select ARCH_SUPPORTS_LTO_CLANG

On Mon, Nov 20, 2017 at 06:05:55PM +, Will Deacon wrote: > Please don't confuse this with a reluctance to support clang; I'm keen to > see that supported, As an aside; as long as clang doesn't do asm-goto and asm-flag-output (as examples of features that clang lacks and developers have at

Re: [PATCH v2 18/18] arm64: select ARCH_SUPPORTS_LTO_CLANG

On Mon, Nov 20, 2017 at 06:05:55PM +, Will Deacon wrote: > Please don't confuse this with a reluctance to support clang; I'm keen to > see that supported, As an aside; as long as clang doesn't do asm-goto and asm-flag-output (as examples of features that clang lacks and developers have at

Re: [PATCH 4.4 00/59] 4.4.100-stable review

On Mon, Nov 20, 2017 at 08:31:47AM -0800, Guenter Roeck wrote: > On Sun, Nov 19, 2017 at 03:32:08PM +0100, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.4.100 release. > > There are 59 patches in this series, all will be posted as a response > > to this one.

Re: [PATCH 4.4 00/59] 4.4.100-stable review

On Mon, Nov 20, 2017 at 08:31:47AM -0800, Guenter Roeck wrote: > On Sun, Nov 19, 2017 at 03:32:08PM +0100, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.4.100 release. > > There are 59 patches in this series, all will be posted as a response > > to this one.

Re: [PATCH 3.18 00/38] 3.18.83-stable review

On Mon, Nov 20, 2017 at 08:25:14AM -0800, Guenter Roeck wrote: > On Mon, Nov 20, 2017 at 03:48:18PM +0100, Greg Kroah-Hartman wrote: > > On Mon, Nov 20, 2017 at 06:06:57AM -0800, Guenter Roeck wrote: > > > On 11/19/2017 06:29 AM, Greg Kroah-Hartman wrote: > > > > This is the start of the stable

Re: [PATCH 3.18 00/38] 3.18.83-stable review

On Mon, Nov 20, 2017 at 08:25:14AM -0800, Guenter Roeck wrote: > On Mon, Nov 20, 2017 at 03:48:18PM +0100, Greg Kroah-Hartman wrote: > > On Mon, Nov 20, 2017 at 06:06:57AM -0800, Guenter Roeck wrote: > > > On 11/19/2017 06:29 AM, Greg Kroah-Hartman wrote: > > > > This is the start of the stable

Re: [PATCH 4.14 00/31] 4.14.1-stable review

On Mon, Nov 20, 2017 at 10:21:24AM -0800, Guenter Roeck wrote: > On Sun, Nov 19, 2017 at 03:59:34PM +0100, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.14.1 release. > > There are 31 patches in this series, all will be posted as a response > > to this one.

Re: [PATCH 4.14 00/31] 4.14.1-stable review

On Mon, Nov 20, 2017 at 10:21:24AM -0800, Guenter Roeck wrote: > On Sun, Nov 19, 2017 at 03:59:34PM +0100, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.14.1 release. > > There are 31 patches in this series, all will be posted as a response > > to this one.

Re: [PATCH] Check all .c files for bad kernel-doc comments

On Mon, 20 Nov 2017 10:40:40 -0800 Matthew Wilcox wrote: > > ifeq ($(KBUILD_ENABLE_EXTRA_GCC_CHECKS),) > > cmd_checkdoc = $(srctree)/scripts/kernel-doc -none $< ; > > endif > > Thanks! v2 below. Jon, could you apply? Done, thanks. jon

Re: [PATCH] Check all .c files for bad kernel-doc comments

On Mon, 20 Nov 2017 10:40:40 -0800 Matthew Wilcox wrote: > > ifeq ($(KBUILD_ENABLE_EXTRA_GCC_CHECKS),) > > cmd_checkdoc = $(srctree)/scripts/kernel-doc -none $< ; > > endif > > Thanks! v2 below. Jon, could you apply? Done, thanks. jon

[PATCH] powerpc/vas, export chip_to_vas_id()

>From 958f8db089f4b89407fc4b89bccd3eaef585aa96 Mon Sep 17 00:00:00 2001 From: Sukadev Bhattiprolu Date: Mon, 20 Nov 2017 12:53:15 -0600 Subject: [PATCH 1/1] powerpc/vas, export chip_to_vas_id() Export the symbol chip_to_vas_id() to fix a build failure when

[PATCH] powerpc/vas, export chip_to_vas_id()

>From 958f8db089f4b89407fc4b89bccd3eaef585aa96 Mon Sep 17 00:00:00 2001 From: Sukadev Bhattiprolu Date: Mon, 20 Nov 2017 12:53:15 -0600 Subject: [PATCH 1/1] powerpc/vas, export chip_to_vas_id() Export the symbol chip_to_vas_id() to fix a build failure when

Re: [PATCH] clk: fix a panic error caused by accessing NULL pointer

On 11/20, Chunyan Zhang wrote: > From: Cai Li > > In some cases the clock parent would be set NULL when doing re-parent, > it will cause a NULL pointer accessing if clk_set trace event is enabled, > since the trace event function would not check the input parameter. > >

[PATCH] scsi_error: ensure EH wakes up on error to prevent host getting stuck

When a command is added to the host's error handler command queue, there is a chance that the error handler will not be woken up. This can happen when one CPU is running scsi_eh_scmd_add() at the same time as another CPU is running scsi_device_unbusy() for a different command on the same host.

Re: [PATCH] clk: fix a panic error caused by accessing NULL pointer

On 11/20, Chunyan Zhang wrote: > From: Cai Li > > In some cases the clock parent would be set NULL when doing re-parent, > it will cause a NULL pointer accessing if clk_set trace event is enabled, > since the trace event function would not check the input parameter. > > Signed-off-by: Cai Li >

[PATCH] scsi_error: ensure EH wakes up on error to prevent host getting stuck

When a command is added to the host's error handler command queue, there is a chance that the error handler will not be woken up. This can happen when one CPU is running scsi_eh_scmd_add() at the same time as another CPU is running scsi_device_unbusy() for a different command on the same host.

[PATCH] ARM: dts: imx6qdl-udoo: disable AC'97 input pins pad drivers

AC'97 interface RXD and TXC pins are only used as SoC inputs, let's disable pad drivers for them so we will be protected if, for example, TCLKDIR is set by mistake in AUDMUX and causes TXC pin to be configured as an output. This also changes pull direction on these pins from pull-up to pull-down

[PATCH] ARM: dts: imx6qdl-udoo: disable AC'97 input pins pad drivers

AC'97 interface RXD and TXC pins are only used as SoC inputs, let's disable pad drivers for them so we will be protected if, for example, TCLKDIR is set by mistake in AUDMUX and causes TXC pin to be configured as an output. This also changes pull direction on these pins from pull-up to pull-down

Re: [GIT PULL] platform-drivers-x86 for 4.15-1

On Sat, Nov 18, 2017 at 10:37:55AM -0800, Linus Torvalds wrote: > On Sat, Nov 18, 2017 at 10:09 AM, Andy Shevchenko > wrote: > > > > Here is the collected material against Platform Drivers x86 subsystem. > > It's rather bit busy cycle for PDx86, mostly due to

Re: [GIT PULL] platform-drivers-x86 for 4.15-1

On Sat, Nov 18, 2017 at 10:37:55AM -0800, Linus Torvalds wrote: > On Sat, Nov 18, 2017 at 10:09 AM, Andy Shevchenko > wrote: > > > > Here is the collected material against Platform Drivers x86 subsystem. > > It's rather bit busy cycle for PDx86, mostly due to Dell SMBIOS driver > > activity. > >

Re: [PATCH v3 1/3] dt-bindings: mailbox: Introduce Hi3660 controller binding

On Fri, Nov 17, 2017 at 05:24:30PM +0800, Xu YiPing wrote: > From: Leo Yan > > Introduce a binding for the Hi3660 mailbox controller, the mailbox is > used within application processor (AP), communication processor (CP), > HIFI and MCU, etc. > > Signed-off-by: Leo Yan

Re: [PATCH v3 1/3] dt-bindings: mailbox: Introduce Hi3660 controller binding

On Fri, Nov 17, 2017 at 05:24:30PM +0800, Xu YiPing wrote: > From: Leo Yan > > Introduce a binding for the Hi3660 mailbox controller, the mailbox is > used within application processor (AP), communication processor (CP), > HIFI and MCU, etc. > > Signed-off-by: Leo Yan > --- >

RISC-V: User-Visible ABI Cleanup

This patch set contains all the user-visible ABI changes that we currently know about. There might be a few more as we get through the glibc upstreaming process, though. Most of the changes are pretty minor: * Some VDSO symbols that weren't defined were versioned, which doesn't make any

RISC-V: User-Visible ABI Cleanup

This patch set contains all the user-visible ABI changes that we currently know about. There might be a few more as we get through the glibc upstreaming process, though. Most of the changes are pretty minor: * Some VDSO symbols that weren't defined were versioned, which doesn't make any

[PATCH 4/4] RISC-V: Allow userspace to flush the instruction cache

From: Andrew Waterman Despite RISC-V having a direct 'fence.i' instruction available to userspace (which we can't trap!), that's not actually viable when running on Linux because the kernel might schedule a process on another hart. There is no way for userspace to handle this

[PATCH 2/4] RISC-V: Add VDSO entries for clock_get/gettimeofday/getcpu

From: Andrew Waterman For now these are just placeholders that execute the syscall. We will later optimize them to avoid kernel crossings, but we'd like to have the VDSO entries from the first released kernel version to make the ABI simpler. Signed-off-by: Andrew Waterman

Re: [RFC v2 1/2] backlight: pwm_bl: linear interpolation between values of brightness-levels

On Thu, Nov 16, 2017 at 03:11:50PM +0100, Enric Balletbo i Serra wrote: > Setting use-linear-interpolation in the dts will allow you to have linear > interpolation between values of brightness-levels. > > There are now 256 between each of the values of brightness-levels. If > something is

[PATCH 4/4] RISC-V: Allow userspace to flush the instruction cache

From: Andrew Waterman Despite RISC-V having a direct 'fence.i' instruction available to userspace (which we can't trap!), that's not actually viable when running on Linux because the kernel might schedule a process on another hart. There is no way for userspace to handle this without invoking

[PATCH 2/4] RISC-V: Add VDSO entries for clock_get/gettimeofday/getcpu

From: Andrew Waterman For now these are just placeholders that execute the syscall. We will later optimize them to avoid kernel crossings, but we'd like to have the VDSO entries from the first released kernel version to make the ABI simpler. Signed-off-by: Andrew Waterman Signed-off-by:

Re: [RFC v2 1/2] backlight: pwm_bl: linear interpolation between values of brightness-levels

On Thu, Nov 16, 2017 at 03:11:50PM +0100, Enric Balletbo i Serra wrote: > Setting use-linear-interpolation in the dts will allow you to have linear > interpolation between values of brightness-levels. > > There are now 256 between each of the values of brightness-levels. If > something is

[PATCH 1/4] RISC-V: Remove __vdso_cmpxchg{32,64} symbol versions

These were left over from an earlier version of the port. Signed-off-by: Palmer Dabbelt --- arch/riscv/kernel/vdso/vdso.lds.S | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/riscv/kernel/vdso/vdso.lds.S b/arch/riscv/kernel/vdso/vdso.lds.S index

[PATCH 3/4] RISC-V: Flush I$ when making a dirty page executable

From: Andrew Waterman The RISC-V ISA allows for instruction caches that are not coherent WRT stores, even on a single hart. As a result, we need to explicitly flush the instruction cache whenever marking a dirty page as executable in order to preserve the correct system

[PATCH 1/4] RISC-V: Remove __vdso_cmpxchg{32,64} symbol versions

These were left over from an earlier version of the port. Signed-off-by: Palmer Dabbelt --- arch/riscv/kernel/vdso/vdso.lds.S | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/riscv/kernel/vdso/vdso.lds.S b/arch/riscv/kernel/vdso/vdso.lds.S index 8c9dce95c11d..3ac08eebd11d 100644 ---

[PATCH 3/4] RISC-V: Flush I$ when making a dirty page executable

From: Andrew Waterman The RISC-V ISA allows for instruction caches that are not coherent WRT stores, even on a single hart. As a result, we need to explicitly flush the instruction cache whenever marking a dirty page as executable in order to preserve the correct system behavior. Local

Re: [PATCH] fs: Safe rcu access to hlist.

On Sun, Nov 19, 2017 at 09:28:49PM +, Al Viro wrote: > On Sun, Nov 19, 2017 at 03:02:10PM -0500, Tim Hansen wrote: > > Adds hlist_first_rcu and hlist_next_rcu for safe access > > to the hlist in seq_hlist_next_rcu. > > > > Found on linux-next branch, tag next-20171117 with sparse. > >

Re: [PATCH] fs: Safe rcu access to hlist.

On Sun, Nov 19, 2017 at 09:28:49PM +, Al Viro wrote: > On Sun, Nov 19, 2017 at 03:02:10PM -0500, Tim Hansen wrote: > > Adds hlist_first_rcu and hlist_next_rcu for safe access > > to the hlist in seq_hlist_next_rcu. > > > > Found on linux-next branch, tag next-20171117 with sparse. > >

Re: [PATCH] [RFC] time: Make sure jiffies_to_msecs() preserves non-zero time periods

On Tue, Nov 14, 2017 at 06:36:26PM +0100, Geert Uytterhoeven wrote: > For the common cases where 1000 is a multiple of HZ, or HZ is a multiple > of 1000, jiffies_to_msecs() never returns zero when passed a non-zero > time period. > > However, if HZ > 1000 and not an integer multiple of 1000 (e.g.

Re: [PATCH] [RFC] time: Make sure jiffies_to_msecs() preserves non-zero time periods

On Tue, Nov 14, 2017 at 06:36:26PM +0100, Geert Uytterhoeven wrote: > For the common cases where 1000 is a multiple of HZ, or HZ is a multiple > of 1000, jiffies_to_msecs() never returns zero when passed a non-zero > time period. > > However, if HZ > 1000 and not an integer multiple of 1000 (e.g.

Re: mm/percpu.c: use smarter memory allocation for struct pcpu_alloc_info (crisv32 hang)

On Mon, Nov 20, 2017 at 01:18:38PM -0500, Nicolas Pitre wrote: > On Sun, 19 Nov 2017, Guenter Roeck wrote: > > > On 11/19/2017 08:08 PM, Nicolas Pitre wrote: > > > On Sun, 19 Nov 2017, Guenter Roeck wrote: > > > > On 11/19/2017 12:36 PM, Nicolas Pitre wrote: > > > > > On Sat, 18 Nov 2017, Guenter

Re: mm/percpu.c: use smarter memory allocation for struct pcpu_alloc_info (crisv32 hang)

On Mon, Nov 20, 2017 at 01:18:38PM -0500, Nicolas Pitre wrote: > On Sun, 19 Nov 2017, Guenter Roeck wrote: > > > On 11/19/2017 08:08 PM, Nicolas Pitre wrote: > > > On Sun, 19 Nov 2017, Guenter Roeck wrote: > > > > On 11/19/2017 12:36 PM, Nicolas Pitre wrote: > > > > > On Sat, 18 Nov 2017, Guenter

Re: [RFC PATCH v3 for 4.15 08/24] Provide cpu_opv system call

> Having cpu_opv do a 4k memcpy allow it to handle scenarios where > rseq fails to progress. If anybody ever gets that right. It will be really hard to just test such a path. It also seems fairly theoretical to me. Do you even have a test case where the normal path stops making forward

Re: [RFC PATCH v3 for 4.15 08/24] Provide cpu_opv system call

> Having cpu_opv do a 4k memcpy allow it to handle scenarios where > rseq fails to progress. If anybody ever gets that right. It will be really hard to just test such a path. It also seems fairly theoretical to me. Do you even have a test case where the normal path stops making forward

Re: [PATCH 00/16] Entry stuff, in decent shape now

On Mon, Nov 20, 2017 at 9:07 AM, Andy Lutomirski wrote: > This sets up stack switching, including for SYSCALL. I think it's > in decent shape. > > - 32-bit kernels are failing the sigreturn_32 test. But they're also >failing without the patches, so I'm not sure this is a

Re: [PATCH 00/16] Entry stuff, in decent shape now

On Mon, Nov 20, 2017 at 9:07 AM, Andy Lutomirski wrote: > This sets up stack switching, including for SYSCALL. I think it's > in decent shape. > > - 32-bit kernels are failing the sigreturn_32 test. But they're also >failing without the patches, so I'm not sure this is a bug in the >

Re: [v5 RESEND 07/17] regulator: arizona-micsupp: Add support for Cirrus Logic Madera codecs

On Mon, Nov 20, 2017 at 02:10:41PM +, Richard Fitzgerald wrote: > From: Richard Fitzgerald > > This adds a new driver identity "madera-micsupp" and probe function > so that this driver can be used to control the micsupp regulator on > Cirrus Logic Madera

Re: [v5 RESEND 07/17] regulator: arizona-micsupp: Add support for Cirrus Logic Madera codecs

On Mon, Nov 20, 2017 at 02:10:41PM +, Richard Fitzgerald wrote: > From: Richard Fitzgerald > > This adds a new driver identity "madera-micsupp" and probe function > so that this driver can be used to control the micsupp regulator on > Cirrus Logic Madera codecs. > > Signed-off-by: Richard

Re: [PATCH] au0828: fix use-after-free at USB probing

On Fri, Nov 10, 2017 at 6:35 PM, Gustavo A. R. Silva wrote: > > Quoting Andrey Konovalov : > >> On Fri, Nov 10, 2017 at 1:21 AM, Gustavo A. R. Silva >> wrote: >>> >>> Hi Andrey, >>> >>> Could you please try this patch? >>>

Re: [PATCH] au0828: fix use-after-free at USB probing

On Fri, Nov 10, 2017 at 6:35 PM, Gustavo A. R. Silva wrote: > > Quoting Andrey Konovalov : > >> On Fri, Nov 10, 2017 at 1:21 AM, Gustavo A. R. Silva >> wrote: >>> >>> Hi Andrey, >>> >>> Could you please try this patch? >>> >>> Thank you Hi! Sorry for the delay. With this patch I still see the

Re: [v5 RESEND 02/17] mfd: madera: Add DT bindings for Cirrus Logic Madera codecs

On Mon, Nov 20, 2017 at 02:10:36PM +, Richard Fitzgerald wrote: > From: Richard Fitzgerald > > Specification of the bindings for the parent MFD driver component > of the Cirrus Logic Madera codec drivers. > > Note that although the interrupt controller and

Re: [v5 RESEND 02/17] mfd: madera: Add DT bindings for Cirrus Logic Madera codecs

On Mon, Nov 20, 2017 at 02:10:36PM +, Richard Fitzgerald wrote: > From: Richard Fitzgerald > > Specification of the bindings for the parent MFD driver component > of the Cirrus Logic Madera codec drivers. > > Note that although the interrupt controller and GPIO are child > drivers their

[PATCH v2 08/31] net: Convert sysctl_pernet_ops

This patch starts to convert pernet_subsys, registered from core initcalls. Methods sysctl_net_init() and sysctl_net_exit() initialize net::sysctls table of a namespace. pernet_operations::init()/exit() methods from the rest of the list do not touch net::sysctls of strangers, so it's safe to

[PATCH v2 08/31] net: Convert sysctl_pernet_ops

This patch starts to convert pernet_subsys, registered from core initcalls. Methods sysctl_net_init() and sysctl_net_exit() initialize net::sysctls table of a namespace. pernet_operations::init()/exit() methods from the rest of the list do not touch net::sysctls of strangers, so it's safe to

Re: [PATCH] Check all .c files for bad kernel-doc comments

On Mon, Oct 30, 2017 at 12:40:20PM +0900, Masahiro Yamada wrote: > 2017-10-28 4:41 GMT+09:00 Matthew Wilcox : > > From: Matthew Wilcox > > > > Implement a '-none' output mode for kernel-doc which will only output > > warning messages, and suppresses

Re: [PATCH] Check all .c files for bad kernel-doc comments

On Mon, Oct 30, 2017 at 12:40:20PM +0900, Masahiro Yamada wrote: > 2017-10-28 4:41 GMT+09:00 Matthew Wilcox : > > From: Matthew Wilcox > > > > Implement a '-none' output mode for kernel-doc which will only output > > warning messages, and suppresses the warning message about there being > > no

[PATCH v2 16/31] net: Convert uevent_net_ops

uevent_net_init() and uevent_net_exit() create and destroy netlink socket, and these actions serialized in netlink code. Parallel execution with other pernet_operations makes the socket disappear earlier from uevent_sock_list on ->exit. As userspace can't be interested in broadcast messages of

[PATCH v2 16/31] net: Convert uevent_net_ops

uevent_net_init() and uevent_net_exit() create and destroy netlink socket, and these actions serialized in netlink code. Parallel execution with other pernet_operations makes the socket disappear earlier from uevent_sock_list on ->exit. As userspace can't be interested in broadcast messages of

<    3   4   5   6   7   8   9   10   11   12   >