[linux-next] RCU: dyntick_idle warnings

Hello Paul, x86_64, linux-next 20161110 WARN_ON_ONCE(!(special & RCU_DYNTICK_CTRL_CTR)); [0.436242] [ cut here ] [0.436307] WARNING: CPU: 3 PID: 0 at kernel/rcu/tree.c:380 rcu_momentary_dyntick_idle+0xa7/0xb8 [0.436381] Modules linked in: [0.436437] CPU:

[linux-next] RCU: dyntick_idle warnings

Hello Paul, x86_64, linux-next 20161110 WARN_ON_ONCE(!(special & RCU_DYNTICK_CTRL_CTR)); [0.436242] [ cut here ] [0.436307] WARNING: CPU: 3 PID: 0 at kernel/rcu/tree.c:380 rcu_momentary_dyntick_idle+0xa7/0xb8 [0.436381] Modules linked in: [0.436437] CPU:

[PATCH v3 2/3] cpuidle:powernv: Add helper function to populate powernv idle states.

From: "Gautham R. Shenoy" In the current code for powernv_add_idle_states, there is a lot of code duplication while initializing an idle state in powernv_states table. Add an inline helper function to populate the powernv_states[] table for a given idle state. Invoke

[PATCH] z3fold: don't fail kernel build if z3fold_header is too big

Currently the whole kernel build will be stopped if the size of struct z3fold_header is greater than the size of one chunk, which is 64 bytes by default. This may stand in the way of automated test/debug builds so let's remove that and fail the z3fold initialization in such case instead.

[PATCH v3 1/3] powernv:idle: Add IDLE_STATE_ENTER_SEQ_NORET macro

From: "Gautham R. Shenoy" Currently all the low-power idle states are expected to wake up at reset vector 0x100. Which is why the macro IDLE_STATE_ENTER_SEQ that puts the CPU to an idle state and never returns. On ISA_300, when the ESL and EC bits in the PSSCR are zero,

[PATCH v3 2/3] cpuidle:powernv: Add helper function to populate powernv idle states.

From: "Gautham R. Shenoy" In the current code for powernv_add_idle_states, there is a lot of code duplication while initializing an idle state in powernv_states table. Add an inline helper function to populate the powernv_states[] table for a given idle state. Invoke this for populating the

[PATCH] z3fold: don't fail kernel build if z3fold_header is too big

Currently the whole kernel build will be stopped if the size of struct z3fold_header is greater than the size of one chunk, which is 64 bytes by default. This may stand in the way of automated test/debug builds so let's remove that and fail the z3fold initialization in such case instead.

[PATCH v3 1/3] powernv:idle: Add IDLE_STATE_ENTER_SEQ_NORET macro

From: "Gautham R. Shenoy" Currently all the low-power idle states are expected to wake up at reset vector 0x100. Which is why the macro IDLE_STATE_ENTER_SEQ that puts the CPU to an idle state and never returns. On ISA_300, when the ESL and EC bits in the PSSCR are zero, the CPU is expected to

[PATCH v3 0/3] powernv:stop: Use psscr_val,mask provided by firmware

From: "Gautham R. Shenoy" This is the third iteration of the patchset to use the psscr_val and psscr_mask provided by the firmware for each of the stop states. The previous version can be found here: [v2]: https://lkml.org/lkml/2016/10/27/143 [v1]:

[PATCH v3 3/3] powernv: Pass PSSCR value and mask to power9_idle_stop

From: "Gautham R. Shenoy" The power9_idle_stop method currently takes only the requested stop level as a parameter and picks up the rest of the PSSCR bits from a hand-coded macro. This is not a very flexible design, especially when the firmware has the capability to

[PATCH v3 3/3] powernv: Pass PSSCR value and mask to power9_idle_stop

From: "Gautham R. Shenoy" The power9_idle_stop method currently takes only the requested stop level as a parameter and picks up the rest of the PSSCR bits from a hand-coded macro. This is not a very flexible design, especially when the firmware has the capability to communicate the psscr value

[PATCH v3 0/3] powernv:stop: Use psscr_val,mask provided by firmware

From: "Gautham R. Shenoy" This is the third iteration of the patchset to use the psscr_val and psscr_mask provided by the firmware for each of the stop states. The previous version can be found here: [v2]: https://lkml.org/lkml/2016/10/27/143 [v1]: https://lkml.org/lkml/2016/9/29/45 This

[PATCH v4] z3fold: use per-page spinlock

Most of z3fold operations are in-page, such as modifying z3fold page header or moving z3fold objects within a page. Taking per-pool spinlock to protect per-page objects is therefore suboptimal, and the idea of having a per-page spinlock (or rwlock) has been around for some time. This patch

[PATCH v4] z3fold: use per-page spinlock

Most of z3fold operations are in-page, such as modifying z3fold page header or moving z3fold objects within a page. Taking per-pool spinlock to protect per-page objects is therefore suboptimal, and the idea of having a per-page spinlock (or rwlock) has been around for some time. This patch

Re: [PATCH v3 5/6] Documentation: bindings: add documentation for ir-spi device driver

On 11/09/2016 07:26 PM, Rob Herring wrote: On Thu, Nov 03, 2016 at 11:39:21AM +0100, Jacek Anaszewski wrote: On 11/03/2016 11:10 AM, Andi Shyti wrote: Hi Jacek, Only DT bindings of LED class drivers should be placed in Documentation/devicetree/bindings/leds. Please move it to the media

Re: [PATCH v3 5/6] Documentation: bindings: add documentation for ir-spi device driver

On 11/09/2016 07:26 PM, Rob Herring wrote: On Thu, Nov 03, 2016 at 11:39:21AM +0100, Jacek Anaszewski wrote: On 11/03/2016 11:10 AM, Andi Shyti wrote: Hi Jacek, Only DT bindings of LED class drivers should be placed in Documentation/devicetree/bindings/leds. Please move it to the media

[PATCH] ARM: dts: at91: sama5d3_uart: fix reg sizes to match documentation

The new size (0x100) also matches the size given in sama5d3.dtsi Documentation reference: section 43.6 "Universal Asynchronous Receiver Transmitter (UART) User Interface", table 43-4 "Register Mapping" in [1]. [1] Atmel-11121F-ATARM-SAMA5D3-Series-Datasheet_02-Feb-16 Signed-off-by: Peter Rosin

[PATCH] ARM: dts: at91: sama5d3_uart: fix reg sizes to match documentation

The new size (0x100) also matches the size given in sama5d3.dtsi Documentation reference: section 43.6 "Universal Asynchronous Receiver Transmitter (UART) User Interface", table 43-4 "Register Mapping" in [1]. [1] Atmel-11121F-ATARM-SAMA5D3-Series-Datasheet_02-Feb-16 Signed-off-by: Peter Rosin

Re: [PATCH v2] video: backlight: pwm_bl: Initialize fb_bl_on[x] and use_count during pwm_backlight_probe()

On Wed, 09 Nov 2016, Lukasz Majewski wrote: > Hi Lee, > > > On Tue, 08 Nov 2016, Lukasz Majewski wrote: > > > > > Dear All, > > > > > > > The commit a55944ca82d2 ("backlight: update bd state & fb_blank > > > > properties when necessary") has posed some extra restrictions on > > > > blanking

Re: [PATCH v2] video: backlight: pwm_bl: Initialize fb_bl_on[x] and use_count during pwm_backlight_probe()

On Wed, 09 Nov 2016, Lukasz Majewski wrote: > Hi Lee, > > > On Tue, 08 Nov 2016, Lukasz Majewski wrote: > > > > > Dear All, > > > > > > > The commit a55944ca82d2 ("backlight: update bd state & fb_blank > > > > properties when necessary") has posed some extra restrictions on > > > > blanking

Re: [PATCH 1/2] mfd: pm8921: add support to pm8821

/Srinivas-Kandagatla/mfd-pm8921-add-support-to-pm8821/20161109-013248 base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next config: arm-pxa_defconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https

Re: [PATCH 1/2] mfd: pm8921: add support to pm8821

/Srinivas-Kandagatla/mfd-pm8921-add-support-to-pm8821/20161109-013248 base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next config: arm-pxa_defconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https

[PATCH 0/3] PCI: hv: clean-up and 2 fixes to the hot-remove case

PATCH 1 is just a clean-up. There should be no functional change. PATCH 2 and 3 are for device hot-remove case. Currently the driver will stop working or even cause panic, if we do hot add/remove quickly a few times. With the 2 patches, everything works reliably in my tests now. There can be

[PATCH 0/3] PCI: hv: clean-up and 2 fixes to the hot-remove case

PATCH 1 is just a clean-up. There should be no functional change. PATCH 2 and 3 are for device hot-remove case. Currently the driver will stop working or even cause panic, if we do hot add/remove quickly a few times. With the 2 patches, everything works reliably in my tests now. There can be

Re: [PATCH v5 2/5] driver core: Functional dependencies tracking support

Hi Luis, On Wednesday 09 Nov 2016 16:59:30 Luis R. Rodriguez wrote: > On Wed, Nov 9, 2016 at 4:43 PM, Rafael J. Wysocki wrote: > > On Mon, Nov 7, 2016 at 10:22 PM, Luis R. Rodriguez wrote: > >> On Thu, Oct 27, 2016 at 05:25:51PM +0200, Greg Kroah-Hartman wrote: > >>> On Wed, Oct 26, 2016 at

Re: [PATCH v5 2/5] driver core: Functional dependencies tracking support

Hi Luis, On Wednesday 09 Nov 2016 16:59:30 Luis R. Rodriguez wrote: > On Wed, Nov 9, 2016 at 4:43 PM, Rafael J. Wysocki wrote: > > On Mon, Nov 7, 2016 at 10:22 PM, Luis R. Rodriguez wrote: > >> On Thu, Oct 27, 2016 at 05:25:51PM +0200, Greg Kroah-Hartman wrote: > >>> On Wed, Oct 26, 2016 at

[PATCH] ASoC: samsung: Makefile cleanup

> --- I found the issue running checkkconfigsymbols.py --diff next-20161109..next-20161110 sound/soc/samsung/Makefile | 3 --- 1 file changed, 3 deletions(-) diff --git a/sound/soc/samsung/Makefile b/sound/soc/samsung/Makefile index f3f4a32cd376..27956621c849 100644 --- a/sound/soc/samsung/Makefile

[PATCH] ASoC: samsung: Makefile cleanup

ue running checkkconfigsymbols.py --diff next-20161109..next-20161110 sound/soc/samsung/Makefile | 3 --- 1 file changed, 3 deletions(-) diff --git a/sound/soc/samsung/Makefile b/sound/soc/samsung/Makefile index f3f4a32cd376..27956621c849 100644 --- a/sound/soc/samsung/Makefile +++ b/sound/soc/samsung/Makefil

Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA

On Wed, 2016-11-09 at 11:20 +, Mark Rutland wrote: > The big change would be to handle !MMIO translations, for which we'd > need a runtime registry of ISA bus instance to find the relevant > accessor ops and instance-specific data. Yes. We do something a bit like that on ppc, we find the PCI

Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA

On Wed, 2016-11-09 at 11:20 +, Mark Rutland wrote: > The big change would be to handle !MMIO translations, for which we'd > need a runtime registry of ISA bus instance to find the relevant > accessor ops and instance-specific data. Yes. We do something a bit like that on ppc, we find the PCI

Re: [PATCH v5 2/5] driver core: Functional dependencies tracking support

Hi Luis, On Monday 07 Nov 2016 22:39:54 Luis R. Rodriguez wrote: > On Mon, Oct 10, 2016 at 02:51:04PM +0200, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > > > Currently, there is a problem with taking functional dependencies > > between devices into

Re: [PATCH v5 2/5] driver core: Functional dependencies tracking support

Hi Luis, On Monday 07 Nov 2016 22:39:54 Luis R. Rodriguez wrote: > On Mon, Oct 10, 2016 at 02:51:04PM +0200, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > > > Currently, there is a problem with taking functional dependencies > > between devices into account. > > > > What I mean by a

Re: [PATCH] firmware: fix async/manual firmware loading

On Wed, 2016-11-09 at 23:02 +0100, Luis R. Rodriguez wrote: > Actually... we also set the timeout to MAX_JIFFY_OFFSET when FW_OPT_UEVENT is > not set. This happens *only* when the UMH was explicitly requested on the > async call, when the second argument to request_firmware_nowait() is false. >

Re: [PATCH] firmware: fix async/manual firmware loading

On Wed, 2016-11-09 at 23:02 +0100, Luis R. Rodriguez wrote: > Actually... we also set the timeout to MAX_JIFFY_OFFSET when FW_OPT_UEVENT is > not set. This happens *only* when the UMH was explicitly requested on the > async call, when the second argument to request_firmware_nowait() is false. >

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

On Wed, 2016-11-09 at 03:05 -0800, Andy Lutomirski wrote: > On Tue, Nov 8, 2016 at 8:31 PM, Ricardo Neri > wrote: > > On Tue, 2016-11-08 at 07:34 -0800, Andy Lutomirski wrote: > >> > Would it not be better to emulate these instructions for them? What > >>

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

On Wed, 2016-11-09 at 03:05 -0800, Andy Lutomirski wrote: > On Tue, Nov 8, 2016 at 8:31 PM, Ricardo Neri > wrote: > > On Tue, 2016-11-08 at 07:34 -0800, Andy Lutomirski wrote: > >> > Would it not be better to emulate these instructions for them? What > >> way > >> > we can verify they're not

[PATCH] audit: skip sessionid sentinel value when auto-incrementing

The value (unsigned int)-1 is used as a sentinel to indicate the sessionID is unset. Skip this value when the session_id value wraps. Signed-off-by: Richard Guy Briggs --- kernel/auditsc.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git

[PATCH] audit: skip sessionid sentinel value when auto-incrementing

The value (unsigned int)-1 is used as a sentinel to indicate the sessionID is unset. Skip this value when the session_id value wraps. Signed-off-by: Richard Guy Briggs --- kernel/auditsc.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/kernel/auditsc.c

Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06

Hi, Arnd, On 2016/11/10 5:34, Arnd Bergmann wrote: > On Wednesday, November 9, 2016 12:10:43 PM CET Gabriele Paoloni wrote: >>> On Tuesday, November 8, 2016 11:47:09 AM CET zhichang.yuan wrote: + /* +* The first PCIBIOS_MIN_IO is reserved specifically for >>> indirectIO.

Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06

Hi, Arnd, On 2016/11/10 5:34, Arnd Bergmann wrote: > On Wednesday, November 9, 2016 12:10:43 PM CET Gabriele Paoloni wrote: >>> On Tuesday, November 8, 2016 11:47:09 AM CET zhichang.yuan wrote: + /* +* The first PCIBIOS_MIN_IO is reserved specifically for >>> indirectIO.

[PATCH] audit: tame initialization warning len_abuf in audit_log_execve_info

Tame initialization warning of len_abuf in audit_log_execve_info even though there isn't presently a bug introduced by commit 43761473c254 ("audit: fix a double fetch in audit_log_single_execve_arg()"). Using UNINITIALIZED_VAR instead may mask future bugs. Signed-off-by: Richard Guy Briggs

[PATCH] audit: tame initialization warning len_abuf in audit_log_execve_info

Tame initialization warning of len_abuf in audit_log_execve_info even though there isn't presently a bug introduced by commit 43761473c254 ("audit: fix a double fetch in audit_log_single_execve_arg()"). Using UNINITIALIZED_VAR instead may mask future bugs. Signed-off-by: Richard Guy Briggs ---

Re: [PATCH v3] mailbox: PCC: Fix lockdep warning when request PCC channel

Hi All, On Thu, Oct 27, 2016 at 3:34 PM, Hoan Tran wrote: > This patch fixes the lockdep warning below > > [7.229767] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)) > [7.229776] [ cut here ] > [7.229787] WARNING: CPU: 1 PID: 1 at >

Re: [PATCH v3] mailbox: PCC: Fix lockdep warning when request PCC channel

Hi All, On Thu, Oct 27, 2016 at 3:34 PM, Hoan Tran wrote: > This patch fixes the lockdep warning below > > [7.229767] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)) > [7.229776] [ cut here ] > [7.229787] WARNING: CPU: 1 PID: 1 at >

Re: [PATCH] drivers: mfd: ti_am335x_tscadc: increase ADC ref clock to 24MHz

Hi, On Thursday 10 November 2016 05:23 AM, John Syne wrote: > OK, then back to my original question. Given that these DT properties are > supported in the driver > Below properties are supported by only by ti_am3335x_adc driver and not ti_am335x_tsc driver. As author of this patch pointed out

Re: [PATCH] drivers: mfd: ti_am335x_tscadc: increase ADC ref clock to 24MHz

Hi, On Thursday 10 November 2016 05:23 AM, John Syne wrote: > OK, then back to my original question. Given that these DT properties are > supported in the driver > Below properties are supported by only by ti_am3335x_adc driver and not ti_am335x_tsc driver. As author of this patch pointed out

Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA

Hi,Liviu, Thanks for your comments! On 2016/11/10 0:50, liviu.du...@arm.com wrote: > On Wed, Nov 09, 2016 at 04:16:17PM +, Gabriele Paoloni wrote: >> Hi Liviu >> >> Thanks for reviewing >> > > [removed some irrelevant part of discussion, avoid crazy formatting] > +/** + *

Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA

Hi,Liviu, Thanks for your comments! On 2016/11/10 0:50, liviu.du...@arm.com wrote: > On Wed, Nov 09, 2016 at 04:16:17PM +, Gabriele Paoloni wrote: >> Hi Liviu >> >> Thanks for reviewing >> > > [removed some irrelevant part of discussion, avoid crazy formatting] > +/** + *

Re: [Intel-wired-lan] [PATCH v2] e1000e: free IRQ regardless of __E1000_DOWN

On 11/9/2016 11:41 PM, Tyler Baicar wrote: > Move IRQ free code so that it will happen regardless of the > __E1000_DOWN bit. Currently the e1000e driver only releases its IRQ > if the __E1000_DOWN bit is cleared. This is not sufficient because > it is possible for __E1000_DOWN to be set without

Re: [Intel-wired-lan] [PATCH v2] e1000e: free IRQ regardless of __E1000_DOWN

On 11/9/2016 11:41 PM, Tyler Baicar wrote: > Move IRQ free code so that it will happen regardless of the > __E1000_DOWN bit. Currently the e1000e driver only releases its IRQ > if the __E1000_DOWN bit is cleared. This is not sufficient because > it is possible for __E1000_DOWN to be set without

Re: [PATCH 1/10] clk: sunxi-ng: multiplier: Add fractionnal support

On Wed, Nov 9, 2016 at 1:23 AM, Maxime Ripard wrote: > Signed-off-by: Maxime Ripard Nit: Typo in the subject ("fractional"). Maybe mention what clock on what SoC needs this in the commit message? Otherwise, Acked-by: Chen-Yu

Re: [PATCH 1/10] clk: sunxi-ng: multiplier: Add fractionnal support

On Wed, Nov 9, 2016 at 1:23 AM, Maxime Ripard wrote: > Signed-off-by: Maxime Ripard Nit: Typo in the subject ("fractional"). Maybe mention what clock on what SoC needs this in the commit message? Otherwise, Acked-by: Chen-Yu Tsai > --- > drivers/clk/sunxi-ng/ccu_mult.c | 8 >

Re: [PATCH v2 2/3] firmware: qcom: scm: Remove core, iface and bus clocks dependency

On Wed 09 Nov 17:47 PST 2016, Stephen Boyd wrote: > On 11/03, Sarangdhar Joshi wrote: > > diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c > > index d79fecd..844e90d 100644 > > --- a/drivers/firmware/qcom_scm.c > > +++ b/drivers/firmware/qcom_scm.c > > @@ -380,32 +384,40 @@

Re: [PATCH v2 2/3] firmware: qcom: scm: Remove core, iface and bus clocks dependency

On Wed 09 Nov 17:47 PST 2016, Stephen Boyd wrote: > On 11/03, Sarangdhar Joshi wrote: > > diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c > > index d79fecd..844e90d 100644 > > --- a/drivers/firmware/qcom_scm.c > > +++ b/drivers/firmware/qcom_scm.c > > @@ -380,32 +384,40 @@

Re: [PATCH 1/2] skd: fix msix error handling

On 11/09/2016 05:55 AM, Arnd Bergmann wrote: As reported by gcc -Wmaybe-uninitialized, the cleanup path for skd_acquire_msix tries to free the already allocated msi-x vectors in reverse order, but the index variable may not have been used yet: drivers/block/skd_main.c: In function

Re: [PATCH 1/2] skd: fix msix error handling

On 11/09/2016 05:55 AM, Arnd Bergmann wrote: As reported by gcc -Wmaybe-uninitialized, the cleanup path for skd_acquire_msix tries to free the already allocated msi-x vectors in reverse order, but the index variable may not have been used yet: drivers/block/skd_main.c: In function

Re: [kernel-hardening] [RFC PATCH v3 1/2] Add support for eXclusive Page Frame Ownership (XPFO)

This patch adds support for XPFO which protects against 'ret2dir' kernel attacks. The basic idea is to enforce exclusive ownership of page frames by either the kernel or userspace, unless explicitly requested by the kernel. Whenever a page destined for userspace is allocated, it is unmapped from

Re: [kernel-hardening] [RFC PATCH v3 1/2] Add support for eXclusive Page Frame Ownership (XPFO)

This patch adds support for XPFO which protects against 'ret2dir' kernel attacks. The basic idea is to enforce exclusive ownership of page frames by either the kernel or userspace, unless explicitly requested by the kernel. Whenever a page destined for userspace is allocated, it is unmapped from

Re: [PATCH v4] USB hub_probe: rework ugly goto-into-compound-statement

Hi, On 9 November 2016 at 23:35, Eugene Korenevsky wrote: > Rework smelling code (goto inside compound statement). Perhaps this is > legacy. Anyway such code is not appropriate for Linux kernel. > > Changes since v3: fix typo > Changes since v2: extract the code to static

Re: [PATCH v4] USB hub_probe: rework ugly goto-into-compound-statement

Hi, On 9 November 2016 at 23:35, Eugene Korenevsky wrote: > Rework smelling code (goto inside compound statement). Perhaps this is > legacy. Anyway such code is not appropriate for Linux kernel. > > Changes since v3: fix typo > Changes since v2: extract the code to static function > Changes

[PATCH] dt-binding: remoteproc: Introduce ADSP loader binding

This document defines the binding for a component that loads firmware and control the life cycle of the Qualcomm ADSP Hexagon core. Cc: Sarangdhar Joshi Signed-off-by: Bjorn Andersson --- Changes since v2: - Added the required "xo" clock,

[PATCH] dt-binding: remoteproc: Introduce ADSP loader binding

This document defines the binding for a component that loads firmware and control the life cycle of the Qualcomm ADSP Hexagon core. Cc: Sarangdhar Joshi Signed-off-by: Bjorn Andersson --- Changes since v2: - Added the required "xo" clock, from Sarangdhar - Added smd-edge node - Corrected

[PATCH v2 3/5] mfd: palmas: Reset the POWERHOLD mux during power off

POWERHOLD signal has higher priority over the DEV_ON bit. So power off will not happen if the POWERHOLD is held high. Hence reset the MUX to GPIO_7 mode to release the POWERHOLD and the DEV_ON bit to take effect to power off the PMIC. PMIC Power off happens in dire situations like thermal

[PATCH v2 3/5] mfd: palmas: Reset the POWERHOLD mux during power off

POWERHOLD signal has higher priority over the DEV_ON bit. So power off will not happen if the POWERHOLD is held high. Hence reset the MUX to GPIO_7 mode to release the POWERHOLD and the DEV_ON bit to take effect to power off the PMIC. PMIC Power off happens in dire situations like thermal

[PATCH v1] mtk-vcodec: add index check in decoder vidioc_qbuf.

From: Wu-Cheng Li vb2_qbuf will check the buffer index. If a driver overrides vidioc_qbuf and use the buffer index, the driver needs to check the index. Signed-off-by: Wu-Cheng Li --- drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 4 1

[PATCH v1] mtk-vcodec: add index check in decoder vidioc_qbuf.

From: Wu-Cheng Li vb2_qbuf will check the buffer index. If a driver overrides vidioc_qbuf and use the buffer index, the driver needs to check the index. Signed-off-by: Wu-Cheng Li --- drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 4 1 file changed, 4 insertions(+) diff --git

[PATCH v1] mtk-vcodec: add index check in decoder vidioc_qbuf

From: Wu-Cheng Li This patch adds a buffer index check in decoder vidioc_qbuf. Wu-Cheng Li (1): mtk-vcodec: add index check in decoder vidioc_qbuf. drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 4 1 file changed, 4 insertions(+) -- 2.8.0.rc3.226.g39d4020

[PATCH v1] mtk-vcodec: add index check in decoder vidioc_qbuf

From: Wu-Cheng Li This patch adds a buffer index check in decoder vidioc_qbuf. Wu-Cheng Li (1): mtk-vcodec: add index check in decoder vidioc_qbuf. drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 4 1 file changed, 4 insertions(+) -- 2.8.0.rc3.226.g39d4020

Re: [v16, 0/7] Fix eSDHC host version register bug

On Thu, 2016-11-10 at 04:11 +, Y.B. Lu wrote: > > > > -Original Message- > > From: Y.B. Lu > > Sent: Thursday, November 10, 2016 12:06 PM > > To: 'Scott Wood'; Ulf Hansson > > Cc: linux-mmc; Arnd Bergmann; linuxppc-...@lists.ozlabs.org; > > devicet...@vger.kernel.org;

Re: [v16, 0/7] Fix eSDHC host version register bug

On Thu, 2016-11-10 at 04:11 +, Y.B. Lu wrote: > > > > -Original Message- > > From: Y.B. Lu > > Sent: Thursday, November 10, 2016 12:06 PM > > To: 'Scott Wood'; Ulf Hansson > > Cc: linux-mmc; Arnd Bergmann; linuxppc-...@lists.ozlabs.org; > > devicet...@vger.kernel.org;

[PATCH V4 9/9] PM / OPP: Don't assume platform doesn't have regulators

If the regulators aren't set explicitly by the platform, the OPP core assumes that the platform doesn't have any regulator and uses the clk-only callback. If the platform failed to register a regulator with the core, then this can turn out to be a dangerous assumption as the OPP core will try to

[PATCH V4 9/9] PM / OPP: Don't assume platform doesn't have regulators

If the regulators aren't set explicitly by the platform, the OPP core assumes that the platform doesn't have any regulator and uses the clk-only callback. If the platform failed to register a regulator with the core, then this can turn out to be a dangerous assumption as the OPP core will try to

[PATCH v2 5/5] arm: dts: am57xx-idk-common: Add overide powerhold property

The PMICs have POWERHOLD set by default which prevents PMIC shutdown even on DEV_CTRL On bit set to 0 as the Powerhold has higher priority. So to enable pmic power off this property lets one over ride the default value and enable pmic power off. Signed-off-by: Keerthy ---

Re: task isolation discussion at Linux Plumbers

On Wed, Nov 09, 2016 at 08:52:13PM -0800, Paul E. McKenney wrote: > On Wed, Nov 09, 2016 at 05:44:02PM -0800, Andy Lutomirski wrote: > > On Wed, Nov 9, 2016 at 9:38 AM, Paul E. McKenney > > wrote: > > > > Are you planning on changing rcu_nmi_enter()? It would make it

[PATCH v2 1/5] Documentation: pinctrl: palmas: Add ti,palmas-powerhold-override property definition

GPIO7 is configured in POWERHOLD mode which has higher priority over DEV_ON bit and keeps the PMIC supplies on even after the DEV_ON bit is turned off. This property enables driver to over ride the POWERHOLD value to GPIO7 so as to turn off the PMIC in power off scenarios. Signed-off-by: Keerthy

[PATCH v2 5/5] arm: dts: am57xx-idk-common: Add overide powerhold property

The PMICs have POWERHOLD set by default which prevents PMIC shutdown even on DEV_CTRL On bit set to 0 as the Powerhold has higher priority. So to enable pmic power off this property lets one over ride the default value and enable pmic power off. Signed-off-by: Keerthy ---

Re: task isolation discussion at Linux Plumbers

On Wed, Nov 09, 2016 at 08:52:13PM -0800, Paul E. McKenney wrote: > On Wed, Nov 09, 2016 at 05:44:02PM -0800, Andy Lutomirski wrote: > > On Wed, Nov 9, 2016 at 9:38 AM, Paul E. McKenney > > wrote: > > > > Are you planning on changing rcu_nmi_enter()? It would make it easier > > to figure out

[PATCH v2 1/5] Documentation: pinctrl: palmas: Add ti,palmas-powerhold-override property definition

GPIO7 is configured in POWERHOLD mode which has higher priority over DEV_ON bit and keeps the PMIC supplies on even after the DEV_ON bit is turned off. This property enables driver to over ride the POWERHOLD value to GPIO7 so as to turn off the PMIC in power off scenarios. Signed-off-by: Keerthy

[PATCH v2 2/5] mfd: palmas: Remove redundant check in palmas_power_off

palmas_dev and palmas_power_off are always assigned together. So the check for palmas_dev inside palmas_power_off function is redundant. Removing the same. Signed-off-by: Keerthy --- drivers/mfd/palmas.c | 3 --- 1 file changed, 3 deletions(-) diff --git

[PATCH v2 2/5] mfd: palmas: Remove redundant check in palmas_power_off

palmas_dev and palmas_power_off are always assigned together. So the check for palmas_dev inside palmas_power_off function is redundant. Removing the same. Signed-off-by: Keerthy --- drivers/mfd/palmas.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/mfd/palmas.c

[PATCH v2 4/5] arm: dts: am57xx-beagle-x15-common: Add overide powerhold property

The PMICs have POWERHOLD set by default which prevents PMIC shutdown even on DEV_CTRL On bit set to 0 as the Powerhold has higher priority. So to enable pmic power off this property lets one over ride the default value and enable pmic power off. Signed-off-by: Keerthy ---

[PATCH v2 0/5] mfd: palmas: add powerhold overriding during power off

The series lets one over powerhold for pmic. The powerhold is used to keep the pmic power on even after the DEV_CTRL On bit is set to off. Tested on am572x-idk board, dra72-evm, dra7-evm for poweroff. Keerthy (5): Documentation: pinctrl: palmas: Add ti,palmas-powerhold-override property

[PATCH v2 4/5] arm: dts: am57xx-beagle-x15-common: Add overide powerhold property

The PMICs have POWERHOLD set by default which prevents PMIC shutdown even on DEV_CTRL On bit set to 0 as the Powerhold has higher priority. So to enable pmic power off this property lets one over ride the default value and enable pmic power off. Signed-off-by: Keerthy ---

[PATCH v2 0/5] mfd: palmas: add powerhold overriding during power off

The series lets one over powerhold for pmic. The powerhold is used to keep the pmic power on even after the DEV_CTRL On bit is set to off. Tested on am572x-idk board, dra72-evm, dra7-evm for poweroff. Keerthy (5): Documentation: pinctrl: palmas: Add ti,palmas-powerhold-override property

Re: task isolation discussion at Linux Plumbers

On Wed, Nov 09, 2016 at 05:44:02PM -0800, Andy Lutomirski wrote: > On Wed, Nov 9, 2016 at 9:38 AM, Paul E. McKenney > wrote: > > Are you planning on changing rcu_nmi_enter()? It would make it easier > to figure out how they interact if I could see the code. It

Re: task isolation discussion at Linux Plumbers

On Wed, Nov 09, 2016 at 05:44:02PM -0800, Andy Lutomirski wrote: > On Wed, Nov 9, 2016 at 9:38 AM, Paul E. McKenney > wrote: > > Are you planning on changing rcu_nmi_enter()? It would make it easier > to figure out how they interact if I could see the code. It already calls

[PATCH][RFC v7] timekeeping: Ignore the bogus sleep time if pm_trace is enabled

Previously we encountered some memory overflow issues due to the bogus sleep time brought by inconsistent rtc, which is triggered when pm_trace is enabled, and we have fixed it in recent kernel. However it's improper in the first place to call __timekeeping_inject_sleeptime() in case that pm_trace

[PATCH][RFC v7] timekeeping: Ignore the bogus sleep time if pm_trace is enabled

Previously we encountered some memory overflow issues due to the bogus sleep time brought by inconsistent rtc, which is triggered when pm_trace is enabled, and we have fixed it in recent kernel. However it's improper in the first place to call __timekeeping_inject_sleeptime() in case that pm_trace

[GIT PULL] xfs: updates for 4.9-rc5

Hi Linus, Can you please pull the XFS fix from the tag below. It's a fix for an unmount hang (regression) when the filesystem is shutdown. It was supposed to go to you for -rc3, but I accidentally tagged the commit prior to it in that pullreq. Thanks, -Dave. The following changes since commit

[GIT PULL] xfs: updates for 4.9-rc5

Hi Linus, Can you please pull the XFS fix from the tag below. It's a fix for an unmount hang (regression) when the filesystem is shutdown. It was supposed to go to you for -rc3, but I accidentally tagged the commit prior to it in that pullreq. Thanks, -Dave. The following changes since commit

Re: [PATCH 1/4] Documentation: pinctrl: palmas: Add ti,palmas-powerhold-override property definition

On Wednesday 09 November 2016 09:40 PM, Lee Jones wrote: On Thu, 27 Oct 2016, Keerthy wrote: GPIO7 is configured in POWERHOLD mode which has higher priority over DEV_ON bit and keeps the PMIC supplies on even after the DEV_ON bit is turned off. This property enables driver to over ride the

Re: [PATCH 1/4] Documentation: pinctrl: palmas: Add ti,palmas-powerhold-override property definition

On Wednesday 09 November 2016 09:40 PM, Lee Jones wrote: On Thu, 27 Oct 2016, Keerthy wrote: GPIO7 is configured in POWERHOLD mode which has higher priority over DEV_ON bit and keeps the PMIC supplies on even after the DEV_ON bit is turned off. This property enables driver to over ride the

Re: [PATCH v3 0/3] modversions: Fix CRC mangling under CONFIG_RELOCATABLE=y

Ard Biesheuvel writes: > On 27 October 2016 at 17:27, Ard Biesheuvel wrote: >> This series is a followup to the single patch 'modversions: treat symbol >> CRCs as 32 bit quantities on 64 bit archs', of which two versions have >> been sent

Re: [PATCH v3 0/3] modversions: Fix CRC mangling under CONFIG_RELOCATABLE=y

Ard Biesheuvel writes: > On 27 October 2016 at 17:27, Ard Biesheuvel wrote: >> This series is a followup to the single patch 'modversions: treat symbol >> CRCs as 32 bit quantities on 64 bit archs', of which two versions have >> been sent out so far [0][1] >> >> As pointed out by Michael, GNU

Re: [PATCH 2/4] mfd: palmas: Reset the POWERHOLD mux during power off

On Wednesday 09 November 2016 09:44 PM, Lee Jones wrote: On Thu, 27 Oct 2016, Keerthy wrote: POWERHOLD signal has higher priority over the DEV_ON bit. So power off will not happen if the POWERHOLD is held high. Hence reset the MUX to GPIO_7 mode to release the POWERHOLD and the DEV_ON bit

Re: [PATCH 2/4] mfd: palmas: Reset the POWERHOLD mux during power off

On Wednesday 09 November 2016 09:44 PM, Lee Jones wrote: On Thu, 27 Oct 2016, Keerthy wrote: POWERHOLD signal has higher priority over the DEV_ON bit. So power off will not happen if the POWERHOLD is held high. Hence reset the MUX to GPIO_7 mode to release the POWERHOLD and the DEV_ON bit

Re: [PATCH V3 0/9] PM / OPP: Multiple regulator support

On 09-11-16, 17:19, Stephen Boyd wrote: > On 11/02, Viresh Kumar wrote: > > On 26-10-16, 12:02, Viresh Kumar wrote: > > > Hi, > > > > > > Some platforms (like TI) have complex DVFS configuration for CPU > > > devices, where multiple regulators are required to be configured to > > > change DVFS

Re: [PATCH V3 0/9] PM / OPP: Multiple regulator support

On 09-11-16, 17:19, Stephen Boyd wrote: > On 11/02, Viresh Kumar wrote: > > On 26-10-16, 12:02, Viresh Kumar wrote: > > > Hi, > > > > > > Some platforms (like TI) have complex DVFS configuration for CPU > > > devices, where multiple regulators are required to be configured to > > > change DVFS

Re: [PATCH] usbnet: prevent device rpm suspend in usbnet_probe function

Hi, On Wed, Nov 9, 2016 at 8:32 PM, Bjørn Mork wrote: > Oliver Neukum writes: > >> On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote: >> >>> These problems could very well be caused by running at SuperSpeed >>> (USB-3) instead of high speed (USB-2). Yes, it's

Re: [PATCH] usbnet: prevent device rpm suspend in usbnet_probe function

Hi, On Wed, Nov 9, 2016 at 8:32 PM, Bjørn Mork wrote: > Oliver Neukum writes: > >> On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote: >> >>> These problems could very well be caused by running at SuperSpeed >>> (USB-3) instead of high speed (USB-2). Yes, it's running at SuperSpeed, on a

  1   2   3   4   5   6   7   8   9   10   >