[PATCH v11 40/60] PCI: Move comment to pci_need_to_release()

Move comment from caller to pci_need_to_release(), as we will have one new caller for alt_size support. Signed-off-by: Yinghai Lu --- drivers/pci/setup-bus.c | 27 +++ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/drivers/pci/setup-bus.c

[PATCH v11 35/60] PCI: Simplify res reference using in __assign_resources_sorted()

There are couples of dev_res->res reference, to make code more readable use res instead of dev_res->res directly. Signed-off-by: Yinghai Lu --- drivers/pci/setup-bus.c | 32 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/drivers/pci/setup-bus.c

[PATCH v11 51/60] PCI: Allow bridge optional only io port resource required size to be 0

When there is no child device under the non hotplug bridge, We can use 0 for required size, and do not use old size as required size. That will save some io port range for other bridges, as BIOS could do some partial assign, and we want to use those not used io port range. When there is child

[PATCH v11 55/60] PCI, x86: Allocate from high in available window for MMIO

Current code just use aligned start from avialable window, that could waste big alignment from start. We can align to the end from avialable window, so will save start with big align to others: like second try for pref mmio after first try already have non-pref assigned. pci tree:

[PATCH v11 16/60] PCI: Restore pref MMIO allocation logic for host bridge without mmio64

>From 5b2854155 (PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources), we change the logic for pref mmio allocation: When bridge pref support mmio64, we will only put children pref that support mmio64 into it, and will put children pref mmio32 into bridge's non-pref mmio32. That

[PATCH v11 16/60] PCI: Restore pref MMIO allocation logic for host bridge without mmio64

>From 5b2854155 (PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources), we change the logic for pref mmio allocation: When bridge pref support mmio64, we will only put children pref that support mmio64 into it, and will put children pref mmio32 into bridge's non-pref mmio32. That

[PATCH v11 60/60] PCI: Only try to assign io port only for root bus that support it

The PCI subsystem always assumes that I/O is supported on root bus and tries to assign an I/O window to each child bus even if that is not the case. The use cases is on Intel 8 socket system that have 8 root buses, last two root buses would not have io port resources from _CRS. Check if root bus

[PATCH v11 21/60] PCI: Treat optional as required in first try for bridge rescan

For rescan bridge/bus that children are removed before, we should treat optional as required just like root bus the boot time in 19aa7ee432ce (PCI: make re-allocation try harder by reassigning ranges higher in the heirarchy). The reason: allocate required and expand to optional path do not put

[PATCH v11 60/60] PCI: Only try to assign io port only for root bus that support it

The PCI subsystem always assumes that I/O is supported on root bus and tries to assign an I/O window to each child bus even if that is not the case. The use cases is on Intel 8 socket system that have 8 root buses, last two root buses would not have io port resources from _CRS. Check if root bus

[PATCH v11 21/60] PCI: Treat optional as required in first try for bridge rescan

For rescan bridge/bus that children are removed before, we should treat optional as required just like root bus the boot time in 19aa7ee432ce (PCI: make re-allocation try harder by reassigning ranges higher in the heirarchy). The reason: allocate required and expand to optional path do not put

[PATCH v11 47/60] PCI: Don't add too much optional size for hotplug bridge io

Same as patch for MMIO (PCI: Don't add too much optional size for hotplug bridge MMIO), and this one is for io port. It will compare required+optional with min_sum_size to get smaller optional size. Signed-off-by: Yinghai Lu --- drivers/pci/setup-bus.c | 26

Re: [PATCH] mtd: nand: s3c2410: fix bug in s3c2410_nand_correct_data()

Hi Zeng, On Fri, 8 Apr 2016 00:48:17 +0800 zengzhao...@163.com wrote: > From: Zeng Zhaoxiu > > If there is only one bit difference in the ECC, the function should return 1. > The result of "diff0 & ~(1< actually returns

[PATCH v11 10/60] powerpc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in OF parsing

For device resource PREF bit setting under bridge 64-bit pref resource, we need to make sure only set PREF for 64bit resource. This patch set IORESOUCE_MEM_64 for 64bit resource during OF device resource flags parsing. Link: https://bugzilla.kernel.org/show_bug.cgi?id=96261 Link:

[PATCH v11 47/60] PCI: Don't add too much optional size for hotplug bridge io

Same as patch for MMIO (PCI: Don't add too much optional size for hotplug bridge MMIO), and this one is for io port. It will compare required+optional with min_sum_size to get smaller optional size. Signed-off-by: Yinghai Lu --- drivers/pci/setup-bus.c | 26 -- 1 file

Re: [PATCH] mtd: nand: s3c2410: fix bug in s3c2410_nand_correct_data()

Hi Zeng, On Fri, 8 Apr 2016 00:48:17 +0800 zengzhao...@163.com wrote: > From: Zeng Zhaoxiu > > If there is only one bit difference in the ECC, the function should return 1. > The result of "diff0 & ~(1< actually returns -1. > > Here, we can use the simple expression "(diff0 & (diff0 - 1)) ==

[PATCH v11 10/60] powerpc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in OF parsing

For device resource PREF bit setting under bridge 64-bit pref resource, we need to make sure only set PREF for 64bit resource. This patch set IORESOUCE_MEM_64 for 64bit resource during OF device resource flags parsing. Link: https://bugzilla.kernel.org/show_bug.cgi?id=96261 Link:

[PATCH v11 15/60] PCI: Only treat non-pref mmio64 as pref if host bridge has mmio64

If host bridge does not have mmio64 above 4G, We don't need to treat device non-pref mmio64 as as pref mmio64. Signed-off-by: Yinghai Lu Tested-by: Khalid Aziz --- drivers/pci/setup-bus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH v11 11/60] OF/PCI: Add IORESOURCE_MEM_64 for 64-bit resource

For device resource PREF bit setting under bridge 64-bit pref resource, we need to make sure only set PREF for 64bit resource. This patch set IORESOUCE_MEM_64 for 64bit resource during OF device resource flags parsing. Link: https://bugzilla.kernel.org/show_bug.cgi?id=96261 Link:

[PATCH v11 43/60] PCI: Move saved required resource list out of required+optional assigning

We will need to share saved required list for alt_size support, so move it out from required+optional assigning. Signed-off-by: Yinghai Lu --- drivers/pci/setup-bus.c | 30 -- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git

[PATCH v11 15/60] PCI: Only treat non-pref mmio64 as pref if host bridge has mmio64

If host bridge does not have mmio64 above 4G, We don't need to treat device non-pref mmio64 as as pref mmio64. Signed-off-by: Yinghai Lu Tested-by: Khalid Aziz --- drivers/pci/setup-bus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/setup-bus.c

[PATCH v11 11/60] OF/PCI: Add IORESOURCE_MEM_64 for 64-bit resource

For device resource PREF bit setting under bridge 64-bit pref resource, we need to make sure only set PREF for 64bit resource. This patch set IORESOUCE_MEM_64 for 64bit resource during OF device resource flags parsing. Link: https://bugzilla.kernel.org/show_bug.cgi?id=96261 Link:

[PATCH v11 43/60] PCI: Move saved required resource list out of required+optional assigning

We will need to share saved required list for alt_size support, so move it out from required+optional assigning. Signed-off-by: Yinghai Lu --- drivers/pci/setup-bus.c | 30 -- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git a/drivers/pci/setup-bus.c

[PATCH v11 07/60] sparc/PCI: Keep resource idx order with bridge register number

On one system found strange "no compatible bridge window" warning PCI: Claiming :00:01.0: Resource 14: 00020001..000200010fff [10220c] PCI: Claiming :01:00.0: Resource 1: 00020001..00020001 [100214] pci :01:00.0: can't claim BAR 1 [mem

[PATCH v11 07/60] sparc/PCI: Keep resource idx order with bridge register number

On one system found strange "no compatible bridge window" warning PCI: Claiming :00:01.0: Resource 14: 00020001..000200010fff [10220c] PCI: Claiming :01:00.0: Resource 1: 00020001..00020001 [100214] pci :01:00.0: can't claim BAR 1 [mem

Re: [PATCH] x86/hpet: Reduce HPET counter read contention

On Thu, Apr 7, 2016 at 8:07 AM, Waiman Long wrote: > On 04/07/2016 12:58 AM, Andy Lutomirski wrote: >> Reading the HPET is so slow that all the atomic ops in the world won't >> make a dent. Why not just turn this optimization on unconditionally? >> >> --Andy > > > I am

Re: [PATCH] x86/hpet: Reduce HPET counter read contention

On Thu, Apr 7, 2016 at 8:07 AM, Waiman Long wrote: > On 04/07/2016 12:58 AM, Andy Lutomirski wrote: >> Reading the HPET is so slow that all the atomic ops in the world won't >> make a dent. Why not just turn this optimization on unconditionally? >> >> --Andy > > > I am constantly on the alert

[PATCH v8 net-next 1/1] hv_sock: introduce Hyper-V Sockets

Hyper-V Sockets (hv_sock) supplies a byte-stream based communication mechanism between the host and the guest. It's somewhat like TCP over VMBus, but the transportation layer (VMBus) is much simpler than IP. With Hyper-V Sockets, applications between the host and the guest can talk to each other

[PATCH v8 net-next 1/1] hv_sock: introduce Hyper-V Sockets

Hyper-V Sockets (hv_sock) supplies a byte-stream based communication mechanism between the host and the guest. It's somewhat like TCP over VMBus, but the transportation layer (VMBus) is much simpler than IP. With Hyper-V Sockets, applications between the host and the guest can talk to each other

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

Hyper-V Sockets (hv_sock) supplies a byte-stream based communication mechanism between the host and the guest. It's somewhat like TCP over VMBus, but the transportation layer (VMBus) is much simpler than IP. With Hyper-V Sockets, applications between the host and the guest can talk to each other

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

Hyper-V Sockets (hv_sock) supplies a byte-stream based communication mechanism between the host and the guest. It's somewhat like TCP over VMBus, but the transportation layer (VMBus) is much simpler than IP. With Hyper-V Sockets, applications between the host and the guest can talk to each other

Re: [PATCH v1 05/12] serial: 8250_dma: switch to new dmaengine_terminate_* API

On 04/07/2016 01:37 PM, Andy Shevchenko wrote: > Convert dmaengine_terminate_all() calls to synchronous and asynchronous > versions where appropriate. Reviewed-by: Peter Hurley

Re: [PATCH v1 05/12] serial: 8250_dma: switch to new dmaengine_terminate_* API

On 04/07/2016 01:37 PM, Andy Shevchenko wrote: > Convert dmaengine_terminate_all() calls to synchronous and asynchronous > versions where appropriate. Reviewed-by: Peter Hurley

Re: [PATCH v1 06/12] serial: 8250_dma: stop ongoing RX DMA on exception

On 04/07/2016 01:37 PM, Andy Shevchenko wrote: > If we get an exeption interrupt. i.e. UART_IIR_RLSI, stop any ongoing RX DMA > transfer otherwise it might generates more spurious interrupts and make port > unavailable anymore. Then how to know which rx byte the error is for if dma continues

Re: [PATCH v1 06/12] serial: 8250_dma: stop ongoing RX DMA on exception

On 04/07/2016 01:37 PM, Andy Shevchenko wrote: > If we get an exeption interrupt. i.e. UART_IIR_RLSI, stop any ongoing RX DMA > transfer otherwise it might generates more spurious interrupts and make port > unavailable anymore. Then how to know which rx byte the error is for if dma continues

Re: [PATCH v1 08/12] serial: 8250: enable AFE on ports where FIFO is 16 bytes

On 04/07/2016 01:37 PM, Andy Shevchenko wrote: > Intel Quark has 16550A compatible UART with autoflow feature enabled. It has > only 16 bytes of FIFO. Currently serial8250_do_set_termios() prevents to > enable > autoflow since the minimum requirement of 32 bytes of FIFO size. > > Decrease a FIFO

Re: [PATCH v1 08/12] serial: 8250: enable AFE on ports where FIFO is 16 bytes

On 04/07/2016 01:37 PM, Andy Shevchenko wrote: > Intel Quark has 16550A compatible UART with autoflow feature enabled. It has > only 16 bytes of FIFO. Currently serial8250_do_set_termios() prevents to > enable > autoflow since the minimum requirement of 32 bytes of FIFO size. > > Decrease a FIFO

Re: 4.4, 4.6: camera and unlock buttons produce tons of interrupts (was Re: N900 sleep mode)

* Pavel Machek [160407 16:02]: > Hi! > > > > gzipped config is attached. > > > > > > Note that I'm still using NOLO. I enabled the sleep, then went to > > > runlevel 1. LEDs still stay on, 55mA power consumption. That was with > > > 1 in off_mode. > > > > Nothing idling for me

Re: 4.4, 4.6: camera and unlock buttons produce tons of interrupts (was Re: N900 sleep mode)

* Pavel Machek [160407 16:02]: > Hi! > > > > gzipped config is attached. > > > > > > Note that I'm still using NOLO. I enabled the sleep, then went to > > > runlevel 1. LEDs still stay on, 55mA power consumption. That was with > > > 1 in off_mode. > > > > Nothing idling for me with your

Re: [PATCH] extcon: usb-gpio: Don't miss event during suspend/resume

On 2016년 04월 06일 23:01, Roger Quadros wrote: > Pin state might have changed during suspend/resume while > our interrupts were disabled. Scan for change during resume. > > Signed-off-by: Roger Quadros > --- > drivers/extcon/extcon-usb-gpio.c | 1 + > 1 file changed, 1 insertion(+)

Re: [PATCH] extcon: usb-gpio: Don't miss event during suspend/resume

On 2016년 04월 06일 23:01, Roger Quadros wrote: > Pin state might have changed during suspend/resume while > our interrupts were disabled. Scan for change during resume. > > Signed-off-by: Roger Quadros > --- > drivers/extcon/extcon-usb-gpio.c | 1 + > 1 file changed, 1 insertion(+) > > diff

Re: [PATCH 1/2] clk: Add Oxford Semiconductor OXNAS Standard Clocks

On 04/03, Neil Armstrong wrote: > On 04/02/2016 02:50 AM, Stephen Boyd wrote: > > On 04/01, Neil Armstrong wrote: > >> + if (!onecell_data) > >> + return -ENOMEM; > >> + > >> + regmap = syscon_node_to_regmap(of_get_parent(np)); > > > > Can we use dev_get_regmap(>dev.parent) here

Re: [PATCH 1/2] clk: Add Oxford Semiconductor OXNAS Standard Clocks

On 04/03, Neil Armstrong wrote: > On 04/02/2016 02:50 AM, Stephen Boyd wrote: > > On 04/01, Neil Armstrong wrote: > >> + if (!onecell_data) > >> + return -ENOMEM; > >> + > >> + regmap = syscon_node_to_regmap(of_get_parent(np)); > > > > Can we use dev_get_regmap(>dev.parent) here

Re: [PATCH] block: make sure big bio is splitted into at most 256 bvecs

On Thu, 7 Apr 2016, Ming Lei wrote: > On Thu, Apr 7, 2016 at 9:56 AM, Eric Wheeler > wrote: > > On Thu, 7 Apr 2016, Ming Lei wrote: > > > >> On Thu, Apr 7, 2016 at 9:36 AM, Eric Wheeler > >> wrote: > >> > On Wed, 6 Apr 2016, Ming Lei

Re: [PATCH] block: make sure big bio is splitted into at most 256 bvecs

On Thu, 7 Apr 2016, Ming Lei wrote: > On Thu, Apr 7, 2016 at 9:56 AM, Eric Wheeler > wrote: > > On Thu, 7 Apr 2016, Ming Lei wrote: > > > >> On Thu, Apr 7, 2016 at 9:36 AM, Eric Wheeler > >> wrote: > >> > On Wed, 6 Apr 2016, Ming Lei wrote: > >> > > >> >> After arbitrary bio size is

Re: [PATCH] ARM: dts: r8a7791: Don't disable referenced optional clocks

On 04/06, Sjoerd Simons wrote: > On Wed, 2016-04-06 at 15:11 +0200, Geert Uytterhoeven wrote: > > CC Mike, Stephen, linux-clk (this time with the new Mike) > > > > On Wed, Apr 6, 2016 at 2:52 PM, Sjoerd Simons > > wrote: > > > > > > clk_get on a disabled clock

Re: [PATCH] ARM: dts: r8a7791: Don't disable referenced optional clocks

On 04/06, Sjoerd Simons wrote: > On Wed, 2016-04-06 at 15:11 +0200, Geert Uytterhoeven wrote: > > CC Mike, Stephen, linux-clk (this time with the new Mike) > > > > On Wed, Apr 6, 2016 at 2:52 PM, Sjoerd Simons > > wrote: > > > > > > clk_get on a disabled clock node will return EPROBE_DEFER,

Re: [PATCH net] lockdep: provide always true lockdep_is_held stub if lockdep disabled

On 08.04.2016 01:12, Hannes Frederic Sowa wrote: I need this to provide a generic lockdep_sock_is_held function which can be easily used in the kernel without using ifdef PROVEN macros. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Eric Dumazet

Re: [PATCH net] lockdep: provide always true lockdep_is_held stub if lockdep disabled

On 08.04.2016 01:12, Hannes Frederic Sowa wrote: I need this to provide a generic lockdep_sock_is_held function which can be easily used in the kernel without using ifdef PROVEN macros. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Eric Dumazet Cc: David Miller Signed-off-by: Hannes Frederic Sowa

Re: sched: horrible way to detect whether a task has been preempted

+++ Jiri Kosina [07/04/16 23:37 +0200]: On Thu, 7 Apr 2016, Jessica Yu wrote: Been sort of rattling my head over the scheduler code :-) Just following the calls in and out of __schedule() it doesn't look like there is a current flag/mechanism to tell whether or not a task has been preempted..

Re: sched: horrible way to detect whether a task has been preempted

+++ Jiri Kosina [07/04/16 23:37 +0200]: On Thu, 7 Apr 2016, Jessica Yu wrote: Been sort of rattling my head over the scheduler code :-) Just following the calls in and out of __schedule() it doesn't look like there is a current flag/mechanism to tell whether or not a task has been preempted..

[PATCH net] lockdep: provide always true lockdep_is_held stub if lockdep disabled

I need this to provide a generic lockdep_sock_is_held function which can be easily used in the kernel without using ifdef PROVEN macros. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Eric Dumazet Cc: David Miller

[PATCH net] lockdep: provide always true lockdep_is_held stub if lockdep disabled

I need this to provide a generic lockdep_sock_is_held function which can be easily used in the kernel without using ifdef PROVEN macros. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Eric Dumazet Cc: David Miller Signed-off-by: Hannes Frederic Sowa --- Hello Peter and Ingo, if it is possible coud

Re: 4.4, 4.6: camera and unlock buttons produce tons of interrupts (was Re: N900 sleep mode)

Hi! > > gzipped config is attached. > > > > Note that I'm still using NOLO. I enabled the sleep, then went to > > runlevel 1. LEDs still stay on, 55mA power consumption. That was with > > 1 in off_mode. > > Nothing idling for me with your .config.. And it seems slower to boot > compared to

Re: 4.4, 4.6: camera and unlock buttons produce tons of interrupts (was Re: N900 sleep mode)

Hi! > > gzipped config is attached. > > > > Note that I'm still using NOLO. I enabled the sleep, then went to > > runlevel 1. LEDs still stay on, 55mA power consumption. That was with > > 1 in off_mode. > > Nothing idling for me with your .config.. And it seems slower to boot > compared to

Re: [PATCH] extcon: usb-gpio: switch to use pm wakeirq apis

On 2016년 04월 07일 02:32, Grygorii Strashko wrote: > Switch to use PM wakeirq APIs which automates wakeup IRQs > enabling/disabling and so allows to make code simpler. > > Signed-off-by: Grygorii Strashko Applied it. Thanks, Chanwoo Choi > --- > Unfortunately this

Re: [PATCH] extcon: usb-gpio: switch to use pm wakeirq apis

On 2016년 04월 07일 02:32, Grygorii Strashko wrote: > Switch to use PM wakeirq APIs which automates wakeup IRQs > enabling/disabling and so allows to make code simpler. > > Signed-off-by: Grygorii Strashko Applied it. Thanks, Chanwoo Choi > --- > Unfortunately this simple patch depends on: >

Re: sched: horrible way to detect whether a task has been preempted

On Thu, 7 Apr 2016, Josh Poimboeuf wrote: > To do that from C code, I guess we'd still need some arch-specific code > in an asm() statement to do the actual push? This could potentially be worked around I believe (thinking for example of a onstack-allocated local variable with predefined

Re: sched: horrible way to detect whether a task has been preempted

On Thu, 7 Apr 2016, Josh Poimboeuf wrote: > To do that from C code, I guess we'd still need some arch-specific code > in an asm() statement to do the actual push? This could potentially be worked around I believe (thinking for example of a onstack-allocated local variable with predefined

[PATCH] Revert "Input: atmel_mxt_ts - disable interrupt for 50ms after reset"

This reverts commit 885f3fb9fa1f9e185e8a4e905157087495734349 due to this change breaking the touchpad on the Chromebook Pixel 2015 on resume from sleep or warm resets. Cc: Olof Johansson Cc: Nick Dyer Cc: Dmitry Torokhov Cc:

[PATCH] Revert "Input: atmel_mxt_ts - disable interrupt for 50ms after reset"

This reverts commit 885f3fb9fa1f9e185e8a4e905157087495734349 due to this change breaking the touchpad on the Chromebook Pixel 2015 on resume from sleep or warm resets. Cc: Olof Johansson Cc: Nick Dyer Cc: Dmitry Torokhov Cc: Henrik Rydberg Signed-off-by: Tom Rini ---

Re: [PATCH v4 01/14] x86/boot: enumerate documentation for the x86 hardware_subarch

On Thu, Apr 07, 2016 at 02:25:38PM +0300, Andy Shevchenko wrote: > On Wed, 2016-04-06 at 17:06 -0700, Luis R. Rodriguez wrote: > > Although hardware_subarch has been in place since the x86 boot > > protocol 2.07 it hasn't been used much. Enumerate current possible > > values to avoid misuses and

Re: [PATCH v4 01/14] x86/boot: enumerate documentation for the x86 hardware_subarch

On Thu, Apr 07, 2016 at 02:25:38PM +0300, Andy Shevchenko wrote: > On Wed, 2016-04-06 at 17:06 -0700, Luis R. Rodriguez wrote: > > Although hardware_subarch has been in place since the x86 boot > > protocol 2.07 it hasn't been used much. Enumerate current possible > > values to avoid misuses and

Re: sched: horrible way to detect whether a task has been preempted

On Thu, Apr 07, 2016 at 11:37:19PM +0200, Jiri Kosina wrote: > On Thu, 7 Apr 2016, Jessica Yu wrote: > > > Been sort of rattling my head over the scheduler code :-) Just following > > the calls in and out of __schedule() it doesn't look like there is a > > current flag/mechanism to tell whether

Re: sched: horrible way to detect whether a task has been preempted

On Thu, Apr 07, 2016 at 11:37:19PM +0200, Jiri Kosina wrote: > On Thu, 7 Apr 2016, Jessica Yu wrote: > > > Been sort of rattling my head over the scheduler code :-) Just following > > the calls in and out of __schedule() it doesn't look like there is a > > current flag/mechanism to tell whether

[PATCH v2] libnvdimm, test: add mock SMART data payload

Provide simulated SMART data to enable the ndctl implementation of SMART data retrieval and parsing. The payload is defined here, "Section 4.1 SMART and Health Info (Function Index 1)": http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf Signed-off-by: Dan Williams

[PATCH v2] libnvdimm, test: add mock SMART data payload

Provide simulated SMART data to enable the ndctl implementation of SMART data retrieval and parsing. The payload is defined here, "Section 4.1 SMART and Health Info (Function Index 1)": http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf Signed-off-by: Dan Williams --- Changes in v2:

Re: [PATCH v4 08/14] apm32: remove paravirt_enabled() use

On Thu, Apr 07, 2016 at 09:08:36AM -0400, Boris Ostrovsky wrote: > On 04/06/2016 08:06 PM, Luis R. Rodriguez wrote: > >There is already a check for apm_info.bios == 0, the > >apm_info.bios is set from the boot_params.apm_bios_info. > >Both Xen and lguest, which are also the only ones that set >

Re: [PATCH v4 08/14] apm32: remove paravirt_enabled() use

On Thu, Apr 07, 2016 at 09:08:36AM -0400, Boris Ostrovsky wrote: > On 04/06/2016 08:06 PM, Luis R. Rodriguez wrote: > >There is already a check for apm_info.bios == 0, the > >apm_info.bios is set from the boot_params.apm_bios_info. > >Both Xen and lguest, which are also the only ones that set >

Re: [PATCH v4] ARM: dts: kirkwood: Add DTS for Linksys EA4200v2/EA4500\

Hi Bert, On mar., avril 05 2016, "Imre Kaloz" wrote: > On Mon, 04 Apr 2016 16:55:28 +0200, Andrew Lunn wrote: > >> On Mon, Apr 04, 2016 at 04:46:07PM +0200, Bert Vermeulen wrote: >>> This platform is based on a Marvell 88E6282 SoC and 88E6171 switch. >>>

Re: [PATCH v4] ARM: dts: kirkwood: Add DTS for Linksys EA4200v2/EA4500\

Hi Bert, On mar., avril 05 2016, "Imre Kaloz" wrote: > On Mon, 04 Apr 2016 16:55:28 +0200, Andrew Lunn wrote: > >> On Mon, Apr 04, 2016 at 04:46:07PM +0200, Bert Vermeulen wrote: >>> This platform is based on a Marvell 88E6282 SoC and 88E6171 switch. >>> >>> Signed-off-by: Bert Vermeulen >>

Re: [PATCH] clocksource: Add missing include of of.h.

On Wed, Mar 9, 2016 at 4:16 PM, David Lechner wrote: > This header uses OF_DELCARE_1 which is defined in linux/of.h. > > This fixes getting unhelpful compiler error messages about missing ')' > before a string constant. > > Signed-off-by: David Lechner

Re: [PATCH] clocksource: use clocksource_freq2mult() helper

On Wed, Mar 16, 2016 at 3:21 AM, Alexander Kuleshov wrote: > which is introduced in the 7aca0c072 commit to simplify calculation of > the mult and shift in the clocks_calc_mult_shift(). > > Signed-off-by: Alexander Kuleshov Queued for testing.

Re: [PATCH] clocksource: Add missing include of of.h.

On Wed, Mar 9, 2016 at 4:16 PM, David Lechner wrote: > This header uses OF_DELCARE_1 which is defined in linux/of.h. > > This fixes getting unhelpful compiler error messages about missing ')' > before a string constant. > > Signed-off-by: David Lechner Queued for testing. thanks -john

Re: [PATCH] clocksource: use clocksource_freq2mult() helper

On Wed, Mar 16, 2016 at 3:21 AM, Alexander Kuleshov wrote: > which is introduced in the 7aca0c072 commit to simplify calculation of > the mult and shift in the clocks_calc_mult_shift(). > > Signed-off-by: Alexander Kuleshov Queued for testing. thanks -john

Greetings My Dear Friend

Greetings My Dear Friend I had no other means to contact you for this business transaction other than through email. I am sorry if you will be offended by my message. I am Mrs. Hayati Al-Mashood the Head of Accounting Audit Department of Empire Bank here in Dubai, United Arab Emirates. I

Greetings My Dear Friend

Greetings My Dear Friend I had no other means to contact you for this business transaction other than through email. I am sorry if you will be offended by my message. I am Mrs. Hayati Al-Mashood the Head of Accounting Audit Department of Empire Bank here in Dubai, United Arab Emirates. I

Deadlock related to file permissions and/or cgroup, 4.4.6+

This is from a modified 4.4.6+ kernel, with local patches. Git tree found below, but I don't think this lockup is related to any local changes we have made. http://dmz2.candelatech.com/?p=linux-4.4.dev.y/.git;a=summary The test case involves using a libcurl based application that is making an

Deadlock related to file permissions and/or cgroup, 4.4.6+

This is from a modified 4.4.6+ kernel, with local patches. Git tree found below, but I don't think this lockup is related to any local changes we have made. http://dmz2.candelatech.com/?p=linux-4.4.dev.y/.git;a=summary The test case involves using a libcurl based application that is making an

Re: [RFT PATCH 0/4] usb: dwc2: Fix core reset and force mode delay problems

On 4/7/2016 1:36 PM, Michael Niewoehner wrote: > > Am 07.04.2016 um 20:41 schrieb John Youn : > >> On 3/31/2016 2:44 PM, Michael Niewoehner wrote: >>> Hi John, >>> >>> Am 29.03.2016 um 04:36 schrieb John Youn : >>> Hi, The following

Re: [RFT PATCH 0/4] usb: dwc2: Fix core reset and force mode delay problems

On 4/7/2016 1:36 PM, Michael Niewoehner wrote: > > Am 07.04.2016 um 20:41 schrieb John Youn : > >> On 3/31/2016 2:44 PM, Michael Niewoehner wrote: >>> Hi John, >>> >>> Am 29.03.2016 um 04:36 schrieb John Youn : >>> Hi, The following patch series addresses the core reset and force

Re: [PATCH] pinctrl: tegra: clear park bit for all pins

On 04/07/2016 03:37 PM, Rhyland Klein wrote: Parking bits might not be cleared by the bootloader properly (if for instance it doesn't use the device configured by that pin). Clear the park bits for all the pins during pinctrl probe. This is present on T210 platforms but not earlier ones, so for

Re: [PATCH] pinctrl: tegra: clear park bit for all pins

On 04/07/2016 03:37 PM, Rhyland Klein wrote: Parking bits might not be cleared by the bootloader properly (if for instance it doesn't use the device configured by that pin). Clear the park bits for all the pins during pinctrl probe. This is present on T210 platforms but not earlier ones, so for

Re: [RFC PATCH 0/3] restartable sequences v2: fast user-space percpu critical sections

On Thu, Apr 7, 2016 at 1:11 PM, Peter Zijlstra wrote: > On Thu, Apr 07, 2016 at 09:43:33AM -0700, Andy Lutomirski wrote: >> More concretely, this looks like (using totally arbitrary register >> assingments -- probably far from ideal, especially given how GCC's >> constraints

Re: [RFC PATCH 0/3] restartable sequences v2: fast user-space percpu critical sections

On Thu, Apr 7, 2016 at 1:11 PM, Peter Zijlstra wrote: > On Thu, Apr 07, 2016 at 09:43:33AM -0700, Andy Lutomirski wrote: >> More concretely, this looks like (using totally arbitrary register >> assingments -- probably far from ideal, especially given how GCC's >> constraints work): >> >> enter

Re: [PATCH] staging: android: ion: dummy: fix dereference of ERR_PTR

On 04/07/2016 09:32 AM, Sudip Mukherjee wrote: ion_device_create() can fail and if it fails then it returns the error value in ERR_PTR. Reviewed-by: Laura Abbott Signed-off-by: Sudip Mukherjee ---

Re: [PATCH] staging: android: ion: dummy: fix dereference of ERR_PTR

On 04/07/2016 09:32 AM, Sudip Mukherjee wrote: ion_device_create() can fail and if it fails then it returns the error value in ERR_PTR. Reviewed-by: Laura Abbott Signed-off-by: Sudip Mukherjee --- drivers/staging/android/ion/ion_dummy_driver.c | 2 ++ 1 file changed, 2 insertions(+)

Re: [PATCH] cpufreq: Skip all governor-related actions for cpufreq_suspended set

On Thursday, April 07, 2016 05:35:03 PM Viresh Kumar wrote: > On 07-04-16, 13:44, Rafael J. Wysocki wrote: > > I'm not sure I'm following. > > > > Without this patch fast switch is disabled when we offline the nonboot > > CPUs during suspend, because cpufreq_exit_governor() runs then, but > > the

Re: [PATCH] cpufreq: Skip all governor-related actions for cpufreq_suspended set

On Thursday, April 07, 2016 05:35:03 PM Viresh Kumar wrote: > On 07-04-16, 13:44, Rafael J. Wysocki wrote: > > I'm not sure I'm following. > > > > Without this patch fast switch is disabled when we offline the nonboot > > CPUs during suspend, because cpufreq_exit_governor() runs then, but > > the

Re: [PATCH V2 5/8] net: mediatek: fix mtk_pending_work

Hi John, [auto build test ERROR on net-next/master] [also build test ERROR on v4.6-rc2 next-20160407] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/John-Crispin/net-mediatek-make-the-driver

Re: [PATCH V2 5/8] net: mediatek: fix mtk_pending_work

Hi John, [auto build test ERROR on net-next/master] [also build test ERROR on v4.6-rc2 next-20160407] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/John-Crispin/net-mediatek-make-the-driver

Re: [PATCH 5/5] max44000: Initial triggered buffer support

Hi Crestez, [auto build test WARNING on iio/togreg] [also build test WARNING on v4.6-rc2 next-20160407] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Crestez-Dan-Leonard/Support-for-max44000

Re: [PATCH 5/5] max44000: Initial triggered buffer support

Hi Crestez, [auto build test WARNING on iio/togreg] [also build test WARNING on v4.6-rc2 next-20160407] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Crestez-Dan-Leonard/Support-for-max44000

Re: [PATCH v5 30/46] regulator: pwm: retrieve correct voltage

Hi Mark, On Wed, 30 Mar 2016 14:24:10 -0700 Mark Brown wrote: > On Wed, Mar 30, 2016 at 10:03:53PM +0200, Boris Brezillon wrote: > > The continuous PWM voltage regulator is caching the voltage value in > > the ->volt_uV field. While most of the time this value should reflect

Re: [PATCH v5 30/46] regulator: pwm: retrieve correct voltage

Hi Mark, On Wed, 30 Mar 2016 14:24:10 -0700 Mark Brown wrote: > On Wed, Mar 30, 2016 at 10:03:53PM +0200, Boris Brezillon wrote: > > The continuous PWM voltage regulator is caching the voltage value in > > the ->volt_uV field. While most of the time this value should reflect the > > real

Re: [PATCH 17/19] perf tools: Build syscall table .c header from kernel's syscall_64.tbl

Em Thu, Apr 07, 2016 at 03:49:56PM -0600, David Ahern escreveu: > Upon further review ... > > On 4/7/16 2:58 PM, Arnaldo Carvalho de Melo wrote: > >From: Arnaldo Carvalho de Melo > > > >We used libaudit to map ids to syscall names and vice-versa, but that > >imposes a delay in

Re: [PATCH 17/19] perf tools: Build syscall table .c header from kernel's syscall_64.tbl

Em Thu, Apr 07, 2016 at 03:49:56PM -0600, David Ahern escreveu: > Upon further review ... > > On 4/7/16 2:58 PM, Arnaldo Carvalho de Melo wrote: > >From: Arnaldo Carvalho de Melo > > > >We used libaudit to map ids to syscall names and vice-versa, but that > >imposes a delay in supporting new

Re: [PATCH 17/19] perf tools: Build syscall table .c header from kernel's syscall_64.tbl

Em Thu, Apr 07, 2016 at 03:39:21PM -0600, David Ahern escreveu: > On 4/7/16 2:58 PM, Arnaldo Carvalho de Melo wrote: > >We used libaudit to map ids to syscall names and vice-versa, but that > >imposes a delay in supporting new syscalls, having to wait for libaudit > >to get those new syscalls on

Re: [PATCH v3] ARM64: ACPI: Update documentation for latest specification version

On 03/28/2016 06:06 PM, Al Stone wrote: > The ACPI 6.1 specification was recently released at the end of January > 2016, but the arm64 kernel documentation for the use of ACPI was written > for the 5.1 version of the spec. There were significant additions to the > spec that had not yet been

Re: [PATCH 17/19] perf tools: Build syscall table .c header from kernel's syscall_64.tbl

Em Thu, Apr 07, 2016 at 03:39:21PM -0600, David Ahern escreveu: > On 4/7/16 2:58 PM, Arnaldo Carvalho de Melo wrote: > >We used libaudit to map ids to syscall names and vice-versa, but that > >imposes a delay in supporting new syscalls, having to wait for libaudit > >to get those new syscalls on

Re: [PATCH v3] ARM64: ACPI: Update documentation for latest specification version

On 03/28/2016 06:06 PM, Al Stone wrote: > The ACPI 6.1 specification was recently released at the end of January > 2016, but the arm64 kernel documentation for the use of ACPI was written > for the 5.1 version of the spec. There were significant additions to the > spec that had not yet been

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