recommended use of request_any_context_irq()

Hi Marc and Thomas, With the introduction of request_any_context_irq() routine, driver can deal with interrupt controllers using either threaded irq or normal irq. But I don't see many drivers that have been changed to use this function to request interrupt. For on-board devices, the driver

recommended use of request_any_context_irq()

Hi Marc and Thomas, With the introduction of request_any_context_irq() routine, driver can deal with interrupt controllers using either threaded irq or normal irq. But I don't see many drivers that have been changed to use this function to request interrupt. For on-board devices, the driver

[PATCH v6] soc: qcom: add l2 cache perf events driver

Adds perf events support for L2 cache PMU. The L2 cache PMU driver is named 'l2cache_0' and can be used with perf events to profile L2 events such as cache hits and misses. Signed-off-by: Neil Leeder --- v6: restore accidentally dropped Kconfig dependencies v5: Fold the

[PATCH v6] soc: qcom: add l2 cache perf events driver

Adds perf events support for L2 cache PMU. The L2 cache PMU driver is named 'l2cache_0' and can be used with perf events to profile L2 events such as cache hits and misses. Signed-off-by: Neil Leeder --- v6: restore accidentally dropped Kconfig dependencies v5: Fold the header and l2-accessors

Re: [PATCH] Fix chance of sign extension to nsec after its msb is set during calculation.

On Sat, Sep 10, 2016 at 11:31 PM, Liav Rehana wrote: >>> > > During the calculation of the nsec variable, "delta * tkr->mult" >> >> > may cause overflow to the msb, if the suspended time is too long. >> >> > In that case, we need to guarantee that the variable will not go >>

Re: [PATCH] Fix chance of sign extension to nsec after its msb is set during calculation.

On Sat, Sep 10, 2016 at 11:31 PM, Liav Rehana wrote: >>> > > During the calculation of the nsec variable, "delta * tkr->mult" >> >> > may cause overflow to the msb, if the suspended time is too long. >> >> > In that case, we need to guarantee that the variable will not go >> >> > through a sign

Re: [PATCH] i2c: i2c-mux-pca954x: retry updating the mux selection on failure

On Wed, Sep 14, 2016 at 03:24:12PM +0200, Peter Rosin wrote: > The cached value of the last selected channel prevents retries on the > next call, even on failure to update the selected channel. Fix that. > > Signed-off-by: Peter Rosin Applied to for-current and added stable,

Re: [PATCH] i2c: i2c-mux-pca954x: retry updating the mux selection on failure

On Wed, Sep 14, 2016 at 03:24:12PM +0200, Peter Rosin wrote: > The cached value of the last selected channel prevents retries on the > next call, even on failure to update the selected channel. Fix that. > > Signed-off-by: Peter Rosin Applied to for-current and added stable, thanks!

Re: [PATCH 1/5] mm/vmalloc.c: correct a few logic error for __insert_vmap_area()

On Wed, 21 Sep 2016, zijun_hu wrote: > From: zijun_hu > > correct a few logic error for __insert_vmap_area() since the else > if condition is always true and meaningless > > in order to fix this issue, if vmap_area inserted is lower than one > on rbtree then walk around left

Re: [PATCH 1/5] mm/vmalloc.c: correct a few logic error for __insert_vmap_area()

On Wed, 21 Sep 2016, zijun_hu wrote: > From: zijun_hu > > correct a few logic error for __insert_vmap_area() since the else > if condition is always true and meaningless > > in order to fix this issue, if vmap_area inserted is lower than one > on rbtree then walk around left branch; if higher

[PATCH] L2TP:Adjust intf MTU, add underlay L3, overlay L2

Take into account all of the tunnel encapsulation headers when setting up the MTU on the L2TP logical interface device. Otherwise, packets created by the applications on top of the L2TP layer are larger than they ought to be, relative to the underlay MTU, leading to needless fragmentation once

[PATCH] L2TP:Adjust intf MTU, add underlay L3, overlay L2

Take into account all of the tunnel encapsulation headers when setting up the MTU on the L2TP logical interface device. Otherwise, packets created by the applications on top of the L2TP layer are larger than they ought to be, relative to the underlay MTU, leading to needless fragmentation once

[PATCH v2 1/9] x86/entry/head/32: use local labels

Add the local label prefix to all non-function named labels in head_32.S and entry_32.S. In addition to decluttering the symbol table, it also will help stack traces to be more sensible. For example, the last reported function in the idle task stack trace will be startup_32_smp() instead of

[PATCH v2 1/9] x86/entry/head/32: use local labels

Add the local label prefix to all non-function named labels in head_32.S and entry_32.S. In addition to decluttering the symbol table, it also will help stack traces to be more sensible. For example, the last reported function in the idle task stack trace will be startup_32_smp() instead of

[PATCH v2 4/9] x86/head/32: fix the end of the stack for idle tasks

The frame at the end of each idle task stack is inconsistent with real task stacks, which have a stack frame header and a real return address before the pt_regs area. This inconsistency can be confusing for stack unwinders. It also hides useful information about what asm code was involved in

[PATCH v2 5/9] x86/smp: fix initial idle stack location on 32-bit

On 32-bit, the initial idle stack calculation doesn't take into account the TOP_OF_KERNEL_STACK_PADDING, making the stack end address inconsistent with other tasks on 32-bit. Reviewed-by: Andy Lutomirski Signed-off-by: Josh Poimboeuf ---

[PATCH v2 3/9] x86/entry/32: fix the end of the stack for newly forked tasks

Thanks to all the recent x86 entry code refactoring, most tasks' kernel stacks start at the same offset right below their saved pt_regs, regardless of which syscall was used to enter the kernel. That creates a nice convention which makes it straightforward to identify the end of the stack, which

[PATCH v2 4/9] x86/head/32: fix the end of the stack for idle tasks

The frame at the end of each idle task stack is inconsistent with real task stacks, which have a stack frame header and a real return address before the pt_regs area. This inconsistency can be confusing for stack unwinders. It also hides useful information about what asm code was involved in

[PATCH v2 5/9] x86/smp: fix initial idle stack location on 32-bit

On 32-bit, the initial idle stack calculation doesn't take into account the TOP_OF_KERNEL_STACK_PADDING, making the stack end address inconsistent with other tasks on 32-bit. Reviewed-by: Andy Lutomirski Signed-off-by: Josh Poimboeuf --- arch/x86/kernel/smpboot.c | 4 +--- 1 file changed, 1

[PATCH v2 3/9] x86/entry/32: fix the end of the stack for newly forked tasks

Thanks to all the recent x86 entry code refactoring, most tasks' kernel stacks start at the same offset right below their saved pt_regs, regardless of which syscall was used to enter the kernel. That creates a nice convention which makes it straightforward to identify the end of the stack, which

[PATCH v2 7/9] x86/head: put real return address on idle task stack

The frame at the end of each idle task stack has a zeroed return address. This is inconsistent with real task stacks, which have a real return address at that spot. This inconsistency can be confusing for stack unwinders. It also hides useful information about what asm code was involved in

[PATCH v2 7/9] x86/head: put real return address on idle task stack

The frame at the end of each idle task stack has a zeroed return address. This is inconsistent with real task stacks, which have a real return address at that spot. This inconsistency can be confusing for stack unwinders. It also hides useful information about what asm code was involved in

[PATCH v2 9/9] x86: move _stext marker to before head code

When core_kernel_text() is used to determine whether an address on a task's stack trace is a kernel text address, it incorrectly returns false for early text addresses for the head code between the _text and _stext markers. Among other things, this can cause the unwinder to behave incorrectly

[PATCH v2 6/9] x86/asm/head: use a common function for starting CPUs

There are two different pieces of code for starting a CPU: start_cpu0() and the end of secondary_startup_64(). They're identical except for the stack setup. Combine the common parts into a shared start_cpu() function. Signed-off-by: Josh Poimboeuf ---

[PATCH v2 9/9] x86: move _stext marker to before head code

When core_kernel_text() is used to determine whether an address on a task's stack trace is a kernel text address, it incorrectly returns false for early text addresses for the head code between the _text and _stext markers. Among other things, this can cause the unwinder to behave incorrectly

[PATCH v2 6/9] x86/asm/head: use a common function for starting CPUs

There are two different pieces of code for starting a CPU: start_cpu0() and the end of secondary_startup_64(). They're identical except for the stack setup. Combine the common parts into a shared start_cpu() function. Signed-off-by: Josh Poimboeuf --- arch/x86/kernel/head_64.S | 22

[PATCH v2 2/9] x86/entry/32: rename 'error_code' to 'common_exception'

The 'error_code' label is awkwardly named, especially when it shows up in a stack trace. Move it to its own local function and rename it to 'common_exception', analagous to the existing 'common_interrupt'. This also makes related stack traces more sensible. Signed-off-by: Josh Poimboeuf

[PATCH v2 8/9] x86/head: fix the end of the stack for idle tasks

Thanks to all the recent x86 entry code refactoring, most tasks' kernel stacks start at the same offset right below their saved pt_regs, regardless of which syscall was used to enter the kernel. That creates a nice convention which makes it straightforward to identify the end of the stack, which

[PATCH v2 0/9] x86/entry/head: standardize the end of the stack

v2: - keep 'restore_all' label in "x86/entry/head/32: use local labels" --- Thanks to all the recent x86 entry code refactoring, most tasks' kernel stacks start at the same offset right below their saved pt_regs, regardless of which syscall was used to enter the kernel. That creates a nice

[PATCH v2 2/9] x86/entry/32: rename 'error_code' to 'common_exception'

The 'error_code' label is awkwardly named, especially when it shows up in a stack trace. Move it to its own local function and rename it to 'common_exception', analagous to the existing 'common_interrupt'. This also makes related stack traces more sensible. Signed-off-by: Josh Poimboeuf ---

[PATCH v2 8/9] x86/head: fix the end of the stack for idle tasks

Thanks to all the recent x86 entry code refactoring, most tasks' kernel stacks start at the same offset right below their saved pt_regs, regardless of which syscall was used to enter the kernel. That creates a nice convention which makes it straightforward to identify the end of the stack, which

[PATCH v2 0/9] x86/entry/head: standardize the end of the stack

v2: - keep 'restore_all' label in "x86/entry/head/32: use local labels" --- Thanks to all the recent x86 entry code refactoring, most tasks' kernel stacks start at the same offset right below their saved pt_regs, regardless of which syscall was used to enter the kernel. That creates a nice

Re: [PATCH 5/5] i2c: octeon,thunderx: Limit register access retries

On Wed, Sep 21, 2016 at 08:51:06AM +0200, Jan Glauber wrote: > Do not infinitely retry register readq and writeq operations > in order to not lock up the CPU in case the TWSI gets stuck. > > Return -EIO in case of a failed data read. For all other > cases just return so subsequent operations will

Re: [PATCH 5/5] i2c: octeon,thunderx: Limit register access retries

On Wed, Sep 21, 2016 at 08:51:06AM +0200, Jan Glauber wrote: > Do not infinitely retry register readq and writeq operations > in order to not lock up the CPU in case the TWSI gets stuck. > > Return -EIO in case of a failed data read. For all other > cases just return so subsequent operations will

Re: [PATCH] drm/sun4i: rgb: Enable panel after controller

Hi, On Wed, Sep 21, 2016 at 11:03:04PM +1000, Jonathan Liu wrote: > The panel should be enabled after the controller so that the panel > prepare/enable delays are properly taken into account. Similarly, the > panel should be disabled before the controller so that the panel > unprepare/disable

Re: [PATCH] drm/sun4i: rgb: Enable panel after controller

Hi, On Wed, Sep 21, 2016 at 11:03:04PM +1000, Jonathan Liu wrote: > The panel should be enabled after the controller so that the panel > prepare/enable delays are properly taken into account. Similarly, the > panel should be disabled before the controller so that the panel > unprepare/disable

Re: [PATCH 1/1 linux-next] netfilter: conntrack: fix kmemleak false positive

Fabian Frederick wrote: > Since commit f330a7fdbe16 > ("netfilter: conntrack: get rid of conntrack timer") > > closed connections remain longer in /proc/net/nf_conntrack > > Running current kernel; just after boot: > cat /proc/net/nf_conntrack | wc -l = 5 > 4 minutes required to

Re: [PATCH 1/1 linux-next] netfilter: conntrack: fix kmemleak false positive

Fabian Frederick wrote: > Since commit f330a7fdbe16 > ("netfilter: conntrack: get rid of conntrack timer") > > closed connections remain longer in /proc/net/nf_conntrack > > Running current kernel; just after boot: > cat /proc/net/nf_conntrack | wc -l = 5 > 4 minutes required to clean up the

Re: [PATCH 3/5] i2c: octeon,thunderx: Fix high-level controller status check

On Wed, Sep 21, 2016 at 08:51:04AM +0200, Jan Glauber wrote: > In case the high-level controller (HLC) is used the status code is > reported at a different location. Check that location after HLC > write operations if the ready bit is not set and return an appropriate > error code instead of

Re: [PATCH 3/5] i2c: octeon,thunderx: Fix high-level controller status check

On Wed, Sep 21, 2016 at 08:51:04AM +0200, Jan Glauber wrote: > In case the high-level controller (HLC) is used the status code is > reported at a different location. Check that location after HLC > write operations if the ready bit is not set and return an appropriate > error code instead of

Re: [PATCH 2/5] i2c: octeon,thunderx: Avoid sending STOP during recovery

On Wed, Sep 21, 2016 at 08:51:03AM +0200, Jan Glauber wrote: > From: Dmitry Bazhenov > > Due to a bug in the ThunderX I2C hardware sending STOP during > a recovery attempt could lock up the hardware. To work around > this problem do not send STOP at the beginning of

RE: [PATCH v2 1/4] samples: move misc-devices/mei example code from Documentation

> > Move misc-devices/mei examples to samples/mei and remove it from > Documentation Makefile. Delete misc-devices/Makefile. > > Create a new Makefile to build samples/mei. It can be built from top level > directory or from mei directory: > > Run make -C samples/mei or cd samples/mei; make > >

Re: [PATCH 2/5] i2c: octeon,thunderx: Avoid sending STOP during recovery

On Wed, Sep 21, 2016 at 08:51:03AM +0200, Jan Glauber wrote: > From: Dmitry Bazhenov > > Due to a bug in the ThunderX I2C hardware sending STOP during > a recovery attempt could lock up the hardware. To work around > this problem do not send STOP at the beginning of the recovery > but use the

RE: [PATCH v2 1/4] samples: move misc-devices/mei example code from Documentation

> > Move misc-devices/mei examples to samples/mei and remove it from > Documentation Makefile. Delete misc-devices/Makefile. > > Create a new Makefile to build samples/mei. It can be built from top level > directory or from mei directory: > > Run make -C samples/mei or cd samples/mei; make > >

Re: [PATCH 1/5] i2c: octeon,thunderx: Fix set SCL recovery function

On Wed, Sep 21, 2016 at 08:51:02AM +0200, Jan Glauber wrote: > From: Dmitry Bazhenov > > The set SCL recovery function unconditionally pulls the SCL line low. > Only pull SCL line low according to val parameter. > > Signed-off-by: Dmitry Bazhenov

Re: [PATCH 1/5] i2c: octeon,thunderx: Fix set SCL recovery function

On Wed, Sep 21, 2016 at 08:51:02AM +0200, Jan Glauber wrote: > From: Dmitry Bazhenov > > The set SCL recovery function unconditionally pulls the SCL line low. > Only pull SCL line low according to val parameter. > > Signed-off-by: Dmitry Bazhenov > Signed-off-by: Jan Glauber > [Changed commit

[PATCH 3/3] ARM: BCM5301X: Specify USB 3.0 PHY in DT

From: Rafał Miłecki Driver for Northstar USB 3.0 PHY has been recently added under the name phy-bcm-ns-usb3. Add binding for it into the DT files. The only slightly tricky part is BCM47094 which uses different PHY version and requires different compatible value. Signed-off-by:

[PATCH 1/3] ARM: BCM5301X: Add separated DTS include file for BCM47094

From: Rafał Miłecki Use it to store BCM47094 specific properties/values and avoid repeating them in device DTS files. Signed-off-by: Rafał Miłecki --- arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts | 3 +-- arch/arm/boot/dts/bcm47094-netgear-r8500.dts | 3

[PATCH 2/3] ARM: BCM5301X: Enable UART on Netgear R8000

From: Rafał Miłecki It was tested by LEDE users, all we need is to adjust clock frequency. While we're at it create a separated DTS include file to share code with other BCM4709 devices easier. Signed-off-by: Rafał Miłecki ---

[PATCH 3/3] ARM: BCM5301X: Specify USB 3.0 PHY in DT

From: Rafał Miłecki Driver for Northstar USB 3.0 PHY has been recently added under the name phy-bcm-ns-usb3. Add binding for it into the DT files. The only slightly tricky part is BCM47094 which uses different PHY version and requires different compatible value. Signed-off-by: Rafał Miłecki

[PATCH 1/3] ARM: BCM5301X: Add separated DTS include file for BCM47094

From: Rafał Miłecki Use it to store BCM47094 specific properties/values and avoid repeating them in device DTS files. Signed-off-by: Rafał Miłecki --- arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts | 3 +-- arch/arm/boot/dts/bcm47094-netgear-r8500.dts | 3 +--

[PATCH 2/3] ARM: BCM5301X: Enable UART on Netgear R8000

From: Rafał Miłecki It was tested by LEDE users, all we need is to adjust clock frequency. While we're at it create a separated DTS include file to share code with other BCM4709 devices easier. Signed-off-by: Rafał Miłecki --- arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts | 2 +-

Re: [PATCH] clk: mvebu: Add clk support for the orion5x SoC mv88f5181

On 09/21, Gregory CLEMENT wrote: > Hi Stephen, > > On mar., sept. 20 2016, Stephen Boyd wrote: > > > On 09/20, Gregory CLEMENT wrote: > >> From: Jamie Lentin > >> > >> Referring to the u-boot sources for the Netgear WNR854T, add support > >> for the

Re: [PATCH] clk: mvebu: Add clk support for the orion5x SoC mv88f5181

On 09/21, Gregory CLEMENT wrote: > Hi Stephen, > > On mar., sept. 20 2016, Stephen Boyd wrote: > > > On 09/20, Gregory CLEMENT wrote: > >> From: Jamie Lentin > >> > >> Referring to the u-boot sources for the Netgear WNR854T, add support > >> for the mv88f5181. > >> > >>

Re: [PATCH 4/5] i2c: octeon,thunderx: Check bus state before starting a transaction

On Wed, Sep 21, 2016 at 08:51:05AM +0200, Jan Glauber wrote: > Add an additional status check before starting a transaction and, > if required, trigger the recovery if the check fails. > > Signed-off-by: Jan Glauber Won't this break multi-master setups? signature.asc

Re: [PATCH 4/5] i2c: octeon,thunderx: Check bus state before starting a transaction

On Wed, Sep 21, 2016 at 08:51:05AM +0200, Jan Glauber wrote: > Add an additional status check before starting a transaction and, > if required, trigger the recovery if the check fails. > > Signed-off-by: Jan Glauber Won't this break multi-master setups? signature.asc Description: PGP

Re: [PATCH] fs/proc/array.c: slightly improve render_sigset_t

On Wed, Sep 21 2016, Kees Cook wrote: > On Tue, Sep 20, 2016 at 3:28 PM, Rasmus Villemoes > wrote: >> format_decode and vsnprintf occasionally show up in perf top, so I >> went looking for places that might not need the full printf >> power. With

Re: [PATCH] fs/proc/array.c: slightly improve render_sigset_t

On Wed, Sep 21 2016, Kees Cook wrote: > On Tue, Sep 20, 2016 at 3:28 PM, Rasmus Villemoes > wrote: >> format_decode and vsnprintf occasionally show up in perf top, so I >> went looking for places that might not need the full printf >> power. With the help of kprobes, I gathered some statistics

Re: [PATCH v4 0/2] ARM: cleanup PCI specific configs

On Wednesday, September 14, 2016 3:49:04 PM CEST Kishon Vijay Abraham I wrote: > This series was initially sent to add support for two PCIe > ports in dra7. This included selecting PCI_DOMAINS config > in SOC_DRA7XX. > > However from the review, PCI_DOMAINS can instead be selected > from

Re: [PATCH v4 0/2] ARM: cleanup PCI specific configs

On Wednesday, September 14, 2016 3:49:04 PM CEST Kishon Vijay Abraham I wrote: > This series was initially sent to add support for two PCIe > ports in dra7. This included selecting PCI_DOMAINS config > in SOC_DRA7XX. > > However from the review, PCI_DOMAINS can instead be selected > from

Re: [PATCH] usb: musb: fix error handling message in probe

Hi, On Sat, Sep 17, 2016 at 12:21:25AM +0200, Arnd Bergmann wrote: > We print an error message when platform_device_register_full() > fails, but the initialization of the argument has been removed, > as shown in this warning: > > drivers/usb/musb/da8xx.c: In function 'da8xx_probe': >

Re: [PATCH] usb: musb: fix error handling message in probe

Hi, On Sat, Sep 17, 2016 at 12:21:25AM +0200, Arnd Bergmann wrote: > We print an error message when platform_device_register_full() > fails, but the initialization of the argument has been removed, > as shown in this warning: > > drivers/usb/musb/da8xx.c: In function 'da8xx_probe': >

[PATCH] dmaengine: k3dma: fix off by one

In k3_of_dma_simple_xlate(), the d->chans[] array has d->dma_requests elements so > should be >=. Fixes: 8e6152bc660e69f5 ("dmaengine: Add hisilicon k3 DMA engine driver") Signed-off-by: Vincent Stehlé Cc: Zhangfei Gao Cc: Vinod Koul

[PATCH] dmaengine: k3dma: fix off by one

In k3_of_dma_simple_xlate(), the d->chans[] array has d->dma_requests elements so > should be >=. Fixes: 8e6152bc660e69f5 ("dmaengine: Add hisilicon k3 DMA engine driver") Signed-off-by: Vincent Stehlé Cc: Zhangfei Gao Cc: Vinod Koul Cc: sta...@vger.kernel.org --- drivers/dma/k3dma.c | 2 +-

Re: [PATCH v4 07/10] x86/sched: Add SD_ASYM_PACKING flags to x86 ITMT CPU

On Wed, Sep 21, 2016 at 9:19 PM, Srinivas Pandruvada wrote: > From: Tim Chen > > Some Intel cores in a package can be boosted to a higher turbo frequency > with ITMT 3.0 technology. The scheduler can use the asymmetric packing >

Re: [PATCH v4 07/10] x86/sched: Add SD_ASYM_PACKING flags to x86 ITMT CPU

On Wed, Sep 21, 2016 at 9:19 PM, Srinivas Pandruvada wrote: > From: Tim Chen > > Some Intel cores in a package can be boosted to a higher turbo frequency > with ITMT 3.0 technology. The scheduler can use the asymmetric packing > feature to move tasks to the more capable cores. > > If ITMT is

Re: [PATCH v4 10/10] cpufreq: intel_pstate: Use CPPC to get max performance

On Wed, Sep 21, 2016 at 9:19 PM, Srinivas Pandruvada wrote: > This change uses acpi cppc_lib interface to get CPPC performance limits. > Once CPPC limits of all online cores are read, first check if there is > difference in max performance. If there is a

Re: [PATCH v4 10/10] cpufreq: intel_pstate: Use CPPC to get max performance

On Wed, Sep 21, 2016 at 9:19 PM, Srinivas Pandruvada wrote: > This change uses acpi cppc_lib interface to get CPPC performance limits. > Once CPPC limits of all online cores are read, first check if there is > difference in max performance. If there is a difference, then the > scheduler interface

Re: [PATCH v4 07/10] x86/sched: Add SD_ASYM_PACKING flags to x86 ITMT CPU

Hi Tim, [auto build test ERROR on pm/linux-next] [also build test ERROR on v4.8-rc7 next-20160921] [cannot apply to tip/x86/core tip/sched/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git(>=2.9.0) format-patch --b

Re: [PATCH v4 07/10] x86/sched: Add SD_ASYM_PACKING flags to x86 ITMT CPU

Hi Tim, [auto build test ERROR on pm/linux-next] [also build test ERROR on v4.8-rc7 next-20160921] [cannot apply to tip/x86/core tip/sched/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git(>=2.9.0) format-patch --b

Re: [PATCH] x86: fix kdump, cleanup aborted E820_PRAM max_pfn manipulation

Dan Williams writes: > In commit ec776ef6bbe1 "x86/mm: Add support for the non-standard > protected e820 type" Christoph references the original patch I wrote > implementing pmem support. The intent of the 'max_pfn' changes in that > commit were to enable persistent

Re: [PATCH] x86: fix kdump, cleanup aborted E820_PRAM max_pfn manipulation

Dan Williams writes: > In commit ec776ef6bbe1 "x86/mm: Add support for the non-standard > protected e820 type" Christoph references the original patch I wrote > implementing pmem support. The intent of the 'max_pfn' changes in that > commit were to enable persistent memory ranges to be covered

Re: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06

On Wednesday, September 21, 2016 4:20:55 PM CEST Gabriele Paoloni wrote: > > -Original Message- > > From: zhichang [mailto:zhichang.yua...@gmail.com] > > On 2016年09月15日 20:24, Arnd Bergmann wrote: > > > On Thursday, September 15, 2016 12:05:51 PM CEST Gabriele Paoloni > > wrote: > > >>>

Re: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06

On Wednesday, September 21, 2016 4:20:55 PM CEST Gabriele Paoloni wrote: > > -Original Message- > > From: zhichang [mailto:zhichang.yua...@gmail.com] > > On 2016年09月15日 20:24, Arnd Bergmann wrote: > > > On Thursday, September 15, 2016 12:05:51 PM CEST Gabriele Paoloni > > wrote: > > >>>

Re: [BUG] perf report --pid not reporting correctly

On Wed, Sep 21, 2016 at 9:34 AM, Jiri Olsa wrote: > On Wed, Sep 21, 2016 at 12:37:53PM -0300, Arnaldo Carvalho de Melo wrote: >> Em Tue, Sep 20, 2016 at 06:29:59PM -0700, Stephane Eranian escreveu: >> > Hi Arnaldo, >> > >> > I ran into an issue trying to use the --pid filtering

Re: [BUG] perf report --pid not reporting correctly

On Wed, Sep 21, 2016 at 9:34 AM, Jiri Olsa wrote: > On Wed, Sep 21, 2016 at 12:37:53PM -0300, Arnaldo Carvalho de Melo wrote: >> Em Tue, Sep 20, 2016 at 06:29:59PM -0700, Stephane Eranian escreveu: >> > Hi Arnaldo, >> > >> > I ran into an issue trying to use the --pid filtering option of perf >>

Re: [PATCH v2 0/4] Move runnable examples code from Documentation to samples

On Wed, 21 Sep 2016 13:47:29 -0600 Shuah Khan wrote: > Move runnable examples code from Documentation to samples. I moved > just the example code, and left documentation files as is. > > I dropped accounting, laptops, and pcmcia from this v2 series as per > the v1

Re: [PATCH v2 0/4] Move runnable examples code from Documentation to samples

On Wed, 21 Sep 2016 13:47:29 -0600 Shuah Khan wrote: > Move runnable examples code from Documentation to samples. I moved > just the example code, and left documentation files as is. > > I dropped accounting, laptops, and pcmcia from this v2 series as per > the v1 feedback on these being a

Re: [PATCH v5] soc: qcom: add l2 cache perf events driver

Hi Neil, [auto build test ERROR on next-20160921] [cannot apply to linus/master linux/master v4.8-rc7 v4.8-rc6 v4.8-rc5 v4.8-rc7] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git(>=2.9.0) format-patch --base= (or --base=a

Re: [PATCH v5] soc: qcom: add l2 cache perf events driver

Hi Neil, [auto build test ERROR on next-20160921] [cannot apply to linus/master linux/master v4.8-rc7 v4.8-rc6 v4.8-rc5 v4.8-rc7] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git(>=2.9.0) format-patch --base= (or --base=a

Re: [PATCH] percpu: improve generic percpu modify-return implementation

On Wed, 21 Sep 2016, Tejun Heo wrote: > Hello, Nick. > > How have you been? :) > He is baack. Are we getting SL!B? ;-)

[PATCH v4 2/2] iio: 104-quad-8: Add IIO support for the ACCES 104-QUAD-8

The ACCES 104-QUAD-8 is a general purpose quadrature encoder counter/interface board. The 104-QUAD-8 is capable of monitoring the outputs of eight encoders via four on-board LSI/CSI LS7266R1 24-bit dual-axis quadrature counter chips. Core functions handled by the LS7266R1, such as direction and

Re: [PATCH] percpu: improve generic percpu modify-return implementation

On Wed, 21 Sep 2016, Tejun Heo wrote: > Hello, Nick. > > How have you been? :) > He is baack. Are we getting SL!B? ;-)

[PATCH v4 2/2] iio: 104-quad-8: Add IIO support for the ACCES 104-QUAD-8

The ACCES 104-QUAD-8 is a general purpose quadrature encoder counter/interface board. The 104-QUAD-8 is capable of monitoring the outputs of eight encoders via four on-board LSI/CSI LS7266R1 24-bit dual-axis quadrature counter chips. Core functions handled by the LS7266R1, such as direction and

[PATCH v4 1/2] iio: Implement counter channel type and info constants

Quadrature encoders, such as rotary encoders and linear encoders, are devices which are capable of encoding the relative position and direction of motion of a shaft. This patch introduces several IIO constants for supporting quadrature encoder counter devices. IIO_COUNT: Current count (main

[PATCH v4 1/2] iio: Implement counter channel type and info constants

Quadrature encoders, such as rotary encoders and linear encoders, are devices which are capable of encoding the relative position and direction of motion of a shaft. This patch introduces several IIO constants for supporting quadrature encoder counter devices. IIO_COUNT: Current count (main

[PATCH v4 0/2] Add IIO support for counter devices

Changes in v4: - Append documentation for new IIO counter attributes to end of Documentation/ABI/testing/sysfs-bus-iio file - Return raw index input value for IIO_CHAN_INFO_RAW of IIO_INDEX; previously, index function (IDX) operation signal was returned - Remove borrow, carry,

[PATCH v4 0/2] Add IIO support for counter devices

Changes in v4: - Append documentation for new IIO counter attributes to end of Documentation/ABI/testing/sysfs-bus-iio file - Return raw index input value for IIO_CHAN_INFO_RAW of IIO_INDEX; previously, index function (IDX) operation signal was returned - Remove borrow, carry,

Re: [PATCH 1/2] config: move x86 kvm_guest.config to a common locaton

On Thu, Sep 8, 2016 at 1:41 PM, Rob Herring wrote: > kvm_guest.config is useful for KVM guests on other arches, and nothing > in it appears to be x86 specific, so just move the whole file. Kbuild > will find it in either location. > > Signed-off-by: Rob Herring

Re: [PATCH 1/2] config: move x86 kvm_guest.config to a common locaton

On Thu, Sep 8, 2016 at 1:41 PM, Rob Herring wrote: > kvm_guest.config is useful for KVM guests on other arches, and nothing > in it appears to be x86 specific, so just move the whole file. Kbuild > will find it in either location. > > Signed-off-by: Rob Herring > Cc: Christoffer Dall > Cc: Marc

Re: [PATCH v4 2/2] rtc-cmos: Restore alarm after resume

On 20/09/2016 at 01:12:44 +0200, Gabriele Mazzotta wrote : > Some platform firmware may interfere with the RTC alarm over suspend, > resulting in the kernel and hardware having different ideas about system > state but also potentially causing problems with firmware that assumes the > OS will clean

Re: [PATCH v4 2/2] rtc-cmos: Restore alarm after resume

On 20/09/2016 at 01:12:44 +0200, Gabriele Mazzotta wrote : > Some platform firmware may interfere with the RTC alarm over suspend, > resulting in the kernel and hardware having different ideas about system > state but also potentially causing problems with firmware that assumes the > OS will clean

Re: [PATCH v4 1/2] rtc-cmos: Clear ACPI-driven alarms upon resume

Hi, Thank you for your perseverance. On 20/09/2016 at 01:12:43 +0200, Gabriele Mazzotta wrote : > Currently ACPI-driven alarms are not cleared when they wake the > system. As consequence, expired alarms must be manually cleared to > program a new alarm. Fix this by correctly handling ACPI-driven

Re: [PATCH v4 1/2] rtc-cmos: Clear ACPI-driven alarms upon resume

Hi, Thank you for your perseverance. On 20/09/2016 at 01:12:43 +0200, Gabriele Mazzotta wrote : > Currently ACPI-driven alarms are not cleared when they wake the > system. As consequence, expired alarms must be manually cleared to > program a new alarm. Fix this by correctly handling ACPI-driven

Re: [PATCH] arm64: Correctly bounds check virt_addr_valid

On Wed, Sep 21, 2016 at 12:34:46PM -0700, Laura Abbott wrote: > On 09/21/2016 10:58 AM, Mark Rutland wrote: > >Are there other potentially-broken users of virt_addr_valid? It's not > >clear to me what some drivers are doing with this, and therefore whether > >we need to cc stable. > > The number

Re: [PATCH] arm64: Correctly bounds check virt_addr_valid

On Wed, Sep 21, 2016 at 12:34:46PM -0700, Laura Abbott wrote: > On 09/21/2016 10:58 AM, Mark Rutland wrote: > >Are there other potentially-broken users of virt_addr_valid? It's not > >clear to me what some drivers are doing with this, and therefore whether > >we need to cc stable. > > The number

[PATCH] x86: fix kdump, cleanup aborted E820_PRAM max_pfn manipulation

In commit ec776ef6bbe1 "x86/mm: Add support for the non-standard protected e820 type" Christoph references the original patch I wrote implementing pmem support. The intent of the 'max_pfn' changes in that commit were to enable persistent memory ranges to be covered by the struct page memmap by

[PATCH] x86: fix kdump, cleanup aborted E820_PRAM max_pfn manipulation

In commit ec776ef6bbe1 "x86/mm: Add support for the non-standard protected e820 type" Christoph references the original patch I wrote implementing pmem support. The intent of the 'max_pfn' changes in that commit were to enable persistent memory ranges to be covered by the struct page memmap by

[PATCH] ata: Replace BUG() with BUG_ON().

Replace BUG() with BUG_ON(). Caught by coccinelle. Signed-off-by: Harman Kalra --- drivers/ata/pata_octeon_cf.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/ata/pata_octeon_cf.c b/drivers/ata/pata_octeon_cf.c index 2724595..475a006

[PATCH] ata: Replace BUG() with BUG_ON().

Replace BUG() with BUG_ON(). Caught by coccinelle. Signed-off-by: Harman Kalra --- drivers/ata/pata_octeon_cf.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/ata/pata_octeon_cf.c b/drivers/ata/pata_octeon_cf.c index 2724595..475a006 100644 ---

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