[PATCH] mmc: host: constify mmc_host_ops structures

Declare mmc_host_ops structures as const as they are only stored in the ops field of a mmc_host structure. This field is of type const, so mmc_host_ops structures having this property can be made const too. Done using Coccinelle: @r disable optional_qualifier@ identifier x; position p; @@ static

[PATCH] mmc: host: constify mmc_host_ops structures

Declare mmc_host_ops structures as const as they are only stored in the ops field of a mmc_host structure. This field is of type const, so mmc_host_ops structures having this property can be made const too. Done using Coccinelle: @r disable optional_qualifier@ identifier x; position p; @@ static

Re: How to ensure other module/driver is initialized?

On Tue, Jan 24, 2017 at 5:40 PM, Ian Pilcher wrote: > Device tree presents even greater problems. It's not clear to me that > device tree even works with x86_64, and even if it does, I'm almost > positive that none of the "generic" distributions are going to support > it.

Re: How to ensure other module/driver is initialized?

On Tue, Jan 24, 2017 at 5:40 PM, Ian Pilcher wrote: > Device tree presents even greater problems. It's not clear to me that > device tree even works with x86_64, and even if it does, I'm almost > positive that none of the "generic" distributions are going to support > it. > > If my

Re: [PATCH v2] openrisc: migrate exception table users off module.h and onto extable.h

[Re: [PATCH v2] openrisc: migrate exception table users off module.h and onto extable.h] On 26/01/2017 (Thu 14:53) Stafford Horne wrote: > On Wed, Jan 25, 2017 at 04:40:46PM -0500, Paul Gortmaker wrote: > > These files were only including module.h for exception table related > > functions.

Re: [PATCH v2] openrisc: migrate exception table users off module.h and onto extable.h

[Re: [PATCH v2] openrisc: migrate exception table users off module.h and onto extable.h] On 26/01/2017 (Thu 14:53) Stafford Horne wrote: > On Wed, Jan 25, 2017 at 04:40:46PM -0500, Paul Gortmaker wrote: > > These files were only including module.h for exception table related > > functions.

Re: [PATCH v2] drm: Clean up the 1366x768 fixup codes

On Mon, Jan 23, 2017 at 09:23:52AM +0100, Daniel Vetter wrote: > On Fri, Jan 20, 2017 at 09:46:17PM +0200, Ville Syrjälä wrote: > > On Tue, Jan 17, 2017 at 05:43:29PM +0100, Takashi Iwai wrote: > > > This is just a cleanup, no functional change. > > > > > > The fixup code for 1366x768 in

Re: [PATCH v2] drm: Clean up the 1366x768 fixup codes

On Mon, Jan 23, 2017 at 09:23:52AM +0100, Daniel Vetter wrote: > On Fri, Jan 20, 2017 at 09:46:17PM +0200, Ville Syrjälä wrote: > > On Tue, Jan 17, 2017 at 05:43:29PM +0100, Takashi Iwai wrote: > > > This is just a cleanup, no functional change. > > > > > > The fixup code for 1366x768 in

Re: [PATCH] drm/i915: fix use-after-free in page_flip_completed()

On Thu, Jan 26, 2017 at 05:32:11PM +0300, Andrey Ryabinin wrote: > page_flip_completed() dereferences 'work' variable after executing > queue_work(). This is not safe as the 'work' item might be already freed > by queued work: > > BUG: KASAN: use-after-free in page_flip_completed+0x3ff/0x490

Re: [PATCH] drm/i915: fix use-after-free in page_flip_completed()

On Thu, Jan 26, 2017 at 05:32:11PM +0300, Andrey Ryabinin wrote: > page_flip_completed() dereferences 'work' variable after executing > queue_work(). This is not safe as the 'work' item might be already freed > by queued work: > > BUG: KASAN: use-after-free in page_flip_completed+0x3ff/0x490

Re: [PATCH 5/7] x86/fpu: Change fpu->fpregs_active users to fpu->fpstate_active

On Thu, 2017-01-26 at 12:26 +0100, Ingo Molnar wrote: > We want to simplify the FPU state machine by eliminating fpu- > >fpregs_active, > and we can do that because the two state flags (::fpregs_active and > ::fpstate_active) are set essentially together. > > The old lazy FPU switching code used

Re: [PATCH 5/7] x86/fpu: Change fpu->fpregs_active users to fpu->fpstate_active

On Thu, 2017-01-26 at 12:26 +0100, Ingo Molnar wrote: > We want to simplify the FPU state machine by eliminating fpu- > >fpregs_active, > and we can do that because the two state flags (::fpregs_active and > ::fpstate_active) are set essentially together. > > The old lazy FPU switching code used

Re: [PATCH v7 2/4] dmaengine: Forward slave device pointer to of_xlate callback

Hi Lars, On 2017-01-25 14:12, Lars-Peter Clausen wrote: On 01/25/2017 11:28 AM, Marek Szyprowski wrote: Add pointer to slave device to of_dma_xlate to let DMA engine driver to know which slave device is using given DMA channel. This will be later used to implement non-irq-safe runtime PM for

Re: [PATCH v7 2/4] dmaengine: Forward slave device pointer to of_xlate callback

Hi Lars, On 2017-01-25 14:12, Lars-Peter Clausen wrote: On 01/25/2017 11:28 AM, Marek Szyprowski wrote: Add pointer to slave device to of_dma_xlate to let DMA engine driver to know which slave device is using given DMA channel. This will be later used to implement non-irq-safe runtime PM for

Re: [PATCH v6 0/2] enhance TPM 2.0 extend function to support multiple PCR banks

On 01/26/2017 05:03 AM, Jarkko Sakkinen wrote: On Wed, Jan 25, 2017 at 10:45:35PM +0200, Jarkko Sakkinen wrote: On Fri, Jan 20, 2017 at 12:05:11PM -0500, Nayna Jain wrote: IMA extends its hash measurements in the TPM PCRs, based on policy. The existing in-kernel TPM extend function extends

Re: [PATCH v6 0/2] enhance TPM 2.0 extend function to support multiple PCR banks

On 01/26/2017 05:03 AM, Jarkko Sakkinen wrote: On Wed, Jan 25, 2017 at 10:45:35PM +0200, Jarkko Sakkinen wrote: On Fri, Jan 20, 2017 at 12:05:11PM -0500, Nayna Jain wrote: IMA extends its hash measurements in the TPM PCRs, based on policy. The existing in-kernel TPM extend function extends

Re: [PATCH] net, bpf: use kvzalloc helper

/commits/Michal-Hocko/net-bpf-use-kvzalloc-helper/20170126-221904 config: x86_64-randconfig-x017-201704 (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All error/warnings (new ones prefixed

Re: [PATCH] net, bpf: use kvzalloc helper

/commits/Michal-Hocko/net-bpf-use-kvzalloc-helper/20170126-221904 config: x86_64-randconfig-x017-201704 (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All error/warnings (new ones prefixed

Re: [PATCH 1/2] qla2xxx: Fix a recently introduced memory leak

On Wed, Jan 25, 2017 at 03:47:20PM +, Bart Van Assche wrote: > = > BUG kmalloc-16 (Not tainted): Redzone overwritten > - > > Disabling lock

Re: [PATCH 1/2] qla2xxx: Fix a recently introduced memory leak

On Wed, Jan 25, 2017 at 03:47:20PM +, Bart Van Assche wrote: > = > BUG kmalloc-16 (Not tainted): Redzone overwritten > - > > Disabling lock

[PATCH] drm/i915: fix use-after-free in page_flip_completed()

page_flip_completed() dereferences 'work' variable after executing queue_work(). This is not safe as the 'work' item might be already freed by queued work: BUG: KASAN: use-after-free in page_flip_completed+0x3ff/0x490 at addr 8803dc010f90 Call Trace:

[PATCH] drm/i915: fix use-after-free in page_flip_completed()

page_flip_completed() dereferences 'work' variable after executing queue_work(). This is not safe as the 'work' item might be already freed by queued work: BUG: KASAN: use-after-free in page_flip_completed+0x3ff/0x490 at addr 8803dc010f90 Call Trace:

Re: [PATCH v2 0/8] Pad retentions support for Exynos5433

On Thu, Jan 26, 2017 at 11:50 AM, Linus Walleij wrote: > On Thu, Jan 26, 2017 at 9:33 AM, Marek Szyprowski > wrote: > >> Patches in this patchset depends on each other. They are order in such a >> way to make the changes bisectable. >> >> Patch

Re: [PATCH v2 0/8] Pad retentions support for Exynos5433

On Thu, Jan 26, 2017 at 11:50 AM, Linus Walleij wrote: > On Thu, Jan 26, 2017 at 9:33 AM, Marek Szyprowski > wrote: > >> Patches in this patchset depends on each other. They are order in such a >> way to make the changes bisectable. >> >> Patch #3 has runtime dependency on #1. >> Patch #5 has

[PATCH v2 2/7] iio: adc: stm32: Enable use of stm32 timer triggers

STM32 ADC has external timer trigger sources. Use stm32 timer triggers API (e.g. is_stm32_timer_trigger()) with local ADC lookup table to validate a trigger can be used. This also provides correct trigger selection value (e.g. extsel). Signed-off-by: Fabrice Gasnier ---

[PATCH v2 2/7] iio: adc: stm32: Enable use of stm32 timer triggers

STM32 ADC has external timer trigger sources. Use stm32 timer triggers API (e.g. is_stm32_timer_trigger()) with local ADC lookup table to validate a trigger can be used. This also provides correct trigger selection value (e.g. extsel). Signed-off-by: Fabrice Gasnier --- Changes in v2: - Add

[PATCH v2 5/7] iio: adc: stm32: add optional dma support

Add DMA optional support to STM32 ADC, as there is a limited number DMA channels (request lines) that can be assigned to ADC. This way, driver may fall back using interrupts when all DMA channels are in use for other IPs. Use dma cyclic mode with two periods. Allow to tune period length by using

[PATCH v2 5/7] iio: adc: stm32: add optional dma support

Add DMA optional support to STM32 ADC, as there is a limited number DMA channels (request lines) that can be assigned to ADC. This way, driver may fall back using interrupts when all DMA channels are in use for other IPs. Use dma cyclic mode with two periods. Allow to tune period length by using

[PATCH v2 0/7] Add support for triggered buffer mode to STM32 ADC

The following patches add support for triggered buffer mode. These are based on top of "Add PWM and IIO timer drivers for STM32" series. Reference: https://lkml.org/lkml/2017/1/20/116 STM32 ADC, can use either interrupts or DMA to collect data. Either timer trigger output (TRGO) or PWM can be

[PATCH v2 0/7] Add support for triggered buffer mode to STM32 ADC

The following patches add support for triggered buffer mode. These are based on top of "Add PWM and IIO timer drivers for STM32" series. Reference: https://lkml.org/lkml/2017/1/20/116 STM32 ADC, can use either interrupts or DMA to collect data. Either timer trigger output (TRGO) or PWM can be

[PATCH v2 4/7] Documentation: dt: iio: stm32-adc: optional dma support

STM32 ADC can use dma. Add dt documentation for optional dma support. Signed-off-by: Fabrice Gasnier Acked-by: Rob Herring --- Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt | 7 +++ 1 file changed, 7 insertions(+) diff --git

[PATCH v2 4/7] Documentation: dt: iio: stm32-adc: optional dma support

STM32 ADC can use dma. Add dt documentation for optional dma support. Signed-off-by: Fabrice Gasnier Acked-by: Rob Herring --- Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt | 7 +++ 1 file changed, 7 insertions(+) diff --git

[PATCH v2 7/7] ARM: dts: stm32: Enable pwm1 and pwm3 on stm32f429i-eval

Define and enable pwm1 and pwm3, timers1 & 3 trigger outputs on on stm32f429i-eval board. Signed-off-by: Fabrice Gasnier --- Changes in v2: - Fix typo - Sort phandles --- arch/arm/boot/dts/stm32429i-eval.dts | 28 1 file changed, 28

[PATCH v2 7/7] ARM: dts: stm32: Enable pwm1 and pwm3 on stm32f429i-eval

Define and enable pwm1 and pwm3, timers1 & 3 trigger outputs on on stm32f429i-eval board. Signed-off-by: Fabrice Gasnier --- Changes in v2: - Fix typo - Sort phandles --- arch/arm/boot/dts/stm32429i-eval.dts | 28 1 file changed, 28 insertions(+) diff --git

[PATCH v2 3/7] iio: adc: stm32: add trigger polarity extended attribute

Define extended attribute so that user may choose rising, falling or both edges for external trigger sources. Default to rising edge in case it isn't set. Signed-off-by: Fabrice Gasnier --- Changes in v2: - Rename and document new trigger_polarity custom attribute ---

[PATCH v2 3/7] iio: adc: stm32: add trigger polarity extended attribute

Define extended attribute so that user may choose rising, falling or both edges for external trigger sources. Default to rising edge in case it isn't set. Signed-off-by: Fabrice Gasnier --- Changes in v2: - Rename and document new trigger_polarity custom attribute ---

[PATCH v2 1/7] iio: adc: stm32: add support for triggered buffer mode

STM32 ADC conversions can be launched using hardware triggers. It can be used to start conversion sequences (group of channels). Selected channels are select via sequence registers. Trigger source is selected via 'extsel' (external trigger mux). Trigger polarity is set to rising edge by default.

[PATCH v2 1/7] iio: adc: stm32: add support for triggered buffer mode

STM32 ADC conversions can be launched using hardware triggers. It can be used to start conversion sequences (group of channels). Selected channels are select via sequence registers. Trigger source is selected via 'extsel' (external trigger mux). Trigger polarity is set to rising edge by default.

Re: [PATCH v2 3/3] pinctrl / gpio: Introduce .set_config() callback for GPIO chips

On Wed, Jan 25, 2017 at 11:09 AM, Mika Westerberg wrote: > On Tue, Jan 24, 2017 at 04:22:20PM +0200, Mika Westerberg wrote: >> On Tue, Jan 24, 2017 at 02:45:04PM +0100, Johan Hovold wrote: >> > Good, that's the one I knew about. But I also got another conflict >>

Re: [PATCH v2 3/3] pinctrl / gpio: Introduce .set_config() callback for GPIO chips

On Wed, Jan 25, 2017 at 11:09 AM, Mika Westerberg wrote: > On Tue, Jan 24, 2017 at 04:22:20PM +0200, Mika Westerberg wrote: >> On Tue, Jan 24, 2017 at 02:45:04PM +0100, Johan Hovold wrote: >> > Good, that's the one I knew about. But I also got another conflict >> > against pinctrl when applying

[PATCH v2 6/7] ARM: dts: stm32: Enable dma by default on stm32f4 adc

Configure STM32F4 ADC to use dma by default. Signed-off-by: Fabrice Gasnier --- arch/arm/boot/dts/stm32f429.dtsi | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi index 8bf650d..ab42b58 100644

[PATCH v2 6/7] ARM: dts: stm32: Enable dma by default on stm32f4 adc

Configure STM32F4 ADC to use dma by default. Signed-off-by: Fabrice Gasnier --- arch/arm/boot/dts/stm32f429.dtsi | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi index 8bf650d..ab42b58 100644 ---

[PATCH] platform/x86: intel_pmc_core: fix out-of-bounds accesses on stack

pmc_core_mtpmc_link_status() an pmc_core_check_read_lock_bit() use test_bit() on local 32-bit variable. This causes out-of-bounds access since test_bit() expects object at least of 'unsigned long' size: BUG: KASAN: stack-out-of-bounds in pmc_core_probe+0x3aa/0x3b0 Call Trace:

[PATCH] platform/x86: intel_pmc_core: fix out-of-bounds accesses on stack

pmc_core_mtpmc_link_status() an pmc_core_check_read_lock_bit() use test_bit() on local 32-bit variable. This causes out-of-bounds access since test_bit() expects object at least of 'unsigned long' size: BUG: KASAN: stack-out-of-bounds in pmc_core_probe+0x3aa/0x3b0 Call Trace:

Re: [PATCH 04/13] Input: keyboard - Use local variables consistently

On 01/26/2017 02:31 AM, Linus Walleij wrote: On Sat, Jan 21, 2017 at 7:45 PM, Guenter Roeck wrote: If a function declares a variable to access a structure element, use it conssistently. Weird spelling :) Call id sssnaky :-) Guenter Signed-off-by: Guenter Roeck

Re: [PATCH 04/13] Input: keyboard - Use local variables consistently

On 01/26/2017 02:31 AM, Linus Walleij wrote: On Sat, Jan 21, 2017 at 7:45 PM, Guenter Roeck wrote: If a function declares a variable to access a structure element, use it conssistently. Weird spelling :) Call id sssnaky :-) Guenter Signed-off-by: Guenter Roeck - error

Re: [PATCH] clk: meson8b: fix clk81 register address

On Wed, 2017-01-25 at 11:53 +0100, Jerome Brunet wrote: > During meson8b clock probe, clk81 register address is fixed twice. > First using the meson8b_clk_gates array, then by directly changing > meson8b_clk81 register. > > As a result meson8b_clk81.reg = HHI_MPEG_CLK_CNTL + clk_base + >

Re: [PATCH] clk: meson8b: fix clk81 register address

On Wed, 2017-01-25 at 11:53 +0100, Jerome Brunet wrote: > During meson8b clock probe, clk81 register address is fixed twice. > First using the meson8b_clk_gates array, then by directly changing > meson8b_clk81 register. > > As a result meson8b_clk81.reg = HHI_MPEG_CLK_CNTL + clk_base + >

[PATCH 1/1] asus-wireless: Fix identation

Signed-off-by: João Paulo Rechi Vita --- drivers/platform/x86/asus-wireless.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/platform/x86/asus-wireless.c b/drivers/platform/x86/asus-wireless.c index 9f31bc1a47d0..c9b5ac152cf1 100644 ---

[PATCH 1/1] asus-wireless: Fix identation

Signed-off-by: João Paulo Rechi Vita --- drivers/platform/x86/asus-wireless.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/platform/x86/asus-wireless.c b/drivers/platform/x86/asus-wireless.c index 9f31bc1a47d0..c9b5ac152cf1 100644 ---

Re: [PATCHSET v4] blk-mq-scheduling framework

> Il giorno 25 gen 2017, alle ore 17:13, Jens Axboe ha scritto: > > On 01/25/2017 01:46 AM, Paolo Valente wrote: >> >>> Il giorno 23 gen 2017, alle ore 18:42, Jens Axboe ha scritto: >>> >>> On 01/23/2017 10:04 AM, Paolo Valente wrote: > Il giorno 18 gen

Re: [PATCHSET v4] blk-mq-scheduling framework

> Il giorno 25 gen 2017, alle ore 17:13, Jens Axboe ha scritto: > > On 01/25/2017 01:46 AM, Paolo Valente wrote: >> >>> Il giorno 23 gen 2017, alle ore 18:42, Jens Axboe ha scritto: >>> >>> On 01/23/2017 10:04 AM, Paolo Valente wrote: > Il giorno 18 gen 2017, alle ore 17:21, Jens

Re: [PATCH v2 0/3] pinctrl / gpio: Allow GPIO chips to use generic pinconfig

On Mon, Jan 23, 2017 at 1:34 PM, Mika Westerberg wrote: > This series makes it possible to configure pins from GPIO chip drivers by > implementing a new callback .set_config(). This callback replaces the > existing .set_single_ended() and .set_debounce() simply

Re: [PATCH v2 0/3] pinctrl / gpio: Allow GPIO chips to use generic pinconfig

On Mon, Jan 23, 2017 at 1:34 PM, Mika Westerberg wrote: > This series makes it possible to configure pins from GPIO chip drivers by > implementing a new callback .set_config(). This callback replaces the > existing .set_single_ended() and .set_debounce() simply because adding new > callbacks for

Re: [PATCH 1/7] x86/fpu: Simplify the fpu->last_cpu logic and rename it to fpu->fpregs_cached

On Thu, 2017-01-26 at 12:26 +0100, Ingo Molnar wrote: > > @@ -322,6 +308,16 @@ struct fpu { >   unsigned char fpregs_active; >   >   /* > +  * @fpregs_cached: > +  * > +  * This flag tells us whether this context is loaded into a > CPU > +  * right now.

Re: [PATCH 1/7] x86/fpu: Simplify the fpu->last_cpu logic and rename it to fpu->fpregs_cached

On Thu, 2017-01-26 at 12:26 +0100, Ingo Molnar wrote: > > @@ -322,6 +308,16 @@ struct fpu { >   unsigned char fpregs_active; >   >   /* > +  * @fpregs_cached: > +  * > +  * This flag tells us whether this context is loaded into a > CPU > +  * right now.

Re: linux-next: Tree for Jan 19

On 01/25/2017 09:38 PM, Stafford Horne wrote: On Wed, Jan 25, 2017 at 08:54:53PM -0800, Guenter Roeck wrote: On 01/25/2017 08:37 AM, Paul Gortmaker wrote: [Re: linux-next: Tree for Jan 19] On 23/01/2017 (Mon 23:11) Stafford Horne wrote: [...] Are all of these builds using the tests from

Re: linux-next: Tree for Jan 19

On 01/25/2017 09:38 PM, Stafford Horne wrote: On Wed, Jan 25, 2017 at 08:54:53PM -0800, Guenter Roeck wrote: On 01/25/2017 08:37 AM, Paul Gortmaker wrote: [Re: linux-next: Tree for Jan 19] On 23/01/2017 (Mon 23:11) Stafford Horne wrote: [...] Are all of these builds using the tests from

[char-misc-next V3] mei: simplify error handling via devres function.

Use devm_ and pcim_ functions to make error handling simpler and code smaller and tidier. Based on original patch by mei: me: use managed functions pcim_* and devm_* https://lkml.org/lkml/2016/2/1/339 Signed-off-by: Tomas Winkler Signed-off-by: Alexander Usyskin

[char-misc-next V3] mei: simplify error handling via devres function.

Use devm_ and pcim_ functions to make error handling simpler and code smaller and tidier. Based on original patch by mei: me: use managed functions pcim_* and devm_* https://lkml.org/lkml/2016/2/1/339 Signed-off-by: Tomas Winkler Signed-off-by: Alexander Usyskin Signed-off-by: Andy Shevchenko

Re: [PATCH] mm: vmscan: do not pass reclaimed slab to vmpressure

Hi Vinayak, On Thu, Jan 26, 2017 at 10:53:38AM +0530, vinayak menon wrote: > Hi Minchan > > On Thu, Jan 26, 2017 at 4:57 AM, Minchan Kim wrote: > > Hello Vinayak, > > > > On Wed, Jan 25, 2017 at 05:08:38PM +0530, Vinayak Menon wrote: > >> It is noticed that during a global

Re: [PATCH] mm: vmscan: do not pass reclaimed slab to vmpressure

Hi Vinayak, On Thu, Jan 26, 2017 at 10:53:38AM +0530, vinayak menon wrote: > Hi Minchan > > On Thu, Jan 26, 2017 at 4:57 AM, Minchan Kim wrote: > > Hello Vinayak, > > > > On Wed, Jan 25, 2017 at 05:08:38PM +0530, Vinayak Menon wrote: > >> It is noticed that during a global reclaim the memory >

Re: [PATCH] pinctrl: mvebu: remove unused variable

On Mon, Jan 23, 2017 at 1:17 PM, Arnd Bergmann wrote: > A cleanup caused a harmless warning: > > drivers/pinctrl/mvebu/pinctrl-kirkwood.c: In function > 'kirkwood_pinctrl_probe': > drivers/pinctrl/mvebu/pinctrl-kirkwood.c:460:19: error: unused variable 'res' >

Re: [PATCH] pinctrl: mvebu: remove unused variable

On Mon, Jan 23, 2017 at 1:17 PM, Arnd Bergmann wrote: > A cleanup caused a harmless warning: > > drivers/pinctrl/mvebu/pinctrl-kirkwood.c: In function > 'kirkwood_pinctrl_probe': > drivers/pinctrl/mvebu/pinctrl-kirkwood.c:460:19: error: unused variable 'res' > [-Werror=unused-variable] > > The

Re: [PATCH v5 0/5] Update LZ4 compressor module

On Thu, Jan 26, 2017 at 01:19:53AM -0800, Eric Biggers wrote: > On Thu, Jan 26, 2017 at 08:57:30AM +0100, Sven Schmidt wrote: > > > > This patchset is for updating the LZ4 compression module to a version based > > on LZ4 v1.7.3 allowing to use the fast compression algorithm aka LZ4 fast > > which

Re: [PATCH v5 0/5] Update LZ4 compressor module

On Thu, Jan 26, 2017 at 01:19:53AM -0800, Eric Biggers wrote: > On Thu, Jan 26, 2017 at 08:57:30AM +0100, Sven Schmidt wrote: > > > > This patchset is for updating the LZ4 compression module to a version based > > on LZ4 v1.7.3 allowing to use the fast compression algorithm aka LZ4 fast > > which

Re: [PATCH 0/6 v3] kvmalloc

On Thu 26-01-17 14:40:04, Michal Hocko wrote: > On Thu 26-01-17 14:10:06, Daniel Borkmann wrote: > > On 01/26/2017 12:58 PM, Michal Hocko wrote: > > > On Thu 26-01-17 12:33:55, Daniel Borkmann wrote: > > > > On 01/26/2017 11:08 AM, Michal Hocko wrote: > > > [...] > > > > > If you disagree I can

Re: [PATCH 0/6 v3] kvmalloc

On Thu 26-01-17 14:40:04, Michal Hocko wrote: > On Thu 26-01-17 14:10:06, Daniel Borkmann wrote: > > On 01/26/2017 12:58 PM, Michal Hocko wrote: > > > On Thu 26-01-17 12:33:55, Daniel Borkmann wrote: > > > > On 01/26/2017 11:08 AM, Michal Hocko wrote: > > > [...] > > > > > If you disagree I can

Understanding stop_machine() use for cpu_down()

Hi, I'm trying to understand why stop_machine() is necessary for cpu_down() operation. I see that multi_cpu_stop() on every online cpu (which hogs the cpu and then triggers state changes state) and then, take_cpu_down is invoked on the outgoing cpu. This happens by every cpu decrementing the

Understanding stop_machine() use for cpu_down()

Hi, I'm trying to understand why stop_machine() is necessary for cpu_down() operation. I see that multi_cpu_stop() on every online cpu (which hogs the cpu and then triggers state changes state) and then, take_cpu_down is invoked on the outgoing cpu. This happens by every cpu decrementing the

Re: [PATCHv4 3/5] pinctrl: mvebu: pinctrl driver for 98DX3236 SoC

On Mon, Jan 23, 2017 at 9:18 AM, Chris Packham wrote: > I noticed the mvebu pinctrl series isn't in Linus's (Torvalds) tree. Is > this on the cards for v4.10 or is it waiting for the next merge window? Next merge window. > In other words should I send v5 or

Re: [PATCHv4 3/5] pinctrl: mvebu: pinctrl driver for 98DX3236 SoC

On Mon, Jan 23, 2017 at 9:18 AM, Chris Packham wrote: > I noticed the mvebu pinctrl series isn't in Linus's (Torvalds) tree. Is > this on the cards for v4.10 or is it waiting for the next merge window? Next merge window. > In other words should I send v5 or my series now or wait for this to be

Re: [PATCH] pinctrl: berlin-bg4ct: fix the value for "sd1a" of pin SCRD0_CRD_PRES

On Mon, Jan 23, 2017 at 8:15 AM, Jisheng Zhang wrote: > This should be a typo. > > Signed-off-by: Jisheng Zhang Patch applied to fixes. Yours, Linus Walleij

Re: [PATCH] pinctrl: berlin-bg4ct: fix the value for "sd1a" of pin SCRD0_CRD_PRES

On Mon, Jan 23, 2017 at 8:15 AM, Jisheng Zhang wrote: > This should be a typo. > > Signed-off-by: Jisheng Zhang Patch applied to fixes. Yours, Linus Walleij

Re: [PATCH v4 01/15] stacktrace/x86: add function for detecting reliable stack traces

On Thu 2017-01-19 09:46:09, Josh Poimboeuf wrote: > For live patching and possibly other use cases, a stack trace is only > useful if it can be assured that it's completely reliable. Add a new > save_stack_trace_tsk_reliable() function to achieve that. > diff --git a/arch/x86/kernel/stacktrace.c

Re: [PATCH v4 01/15] stacktrace/x86: add function for detecting reliable stack traces

On Thu 2017-01-19 09:46:09, Josh Poimboeuf wrote: > For live patching and possibly other use cases, a stack trace is only > useful if it can be assured that it's completely reliable. Add a new > save_stack_trace_tsk_reliable() function to achieve that. > diff --git a/arch/x86/kernel/stacktrace.c

Re: [PATCH 5/5] mm: vmscan: move dirty pages out of the way until they're flushed

On Mon 23-01-17 13:16:41, Johannes Weiner wrote: > We noticed a performance regression when moving hadoop workloads from > 3.10 kernels to 4.0 and 4.6. This is accompanied by increased pageout > activity initiated by kswapd as well as frequent bursts of allocation > stalls and direct reclaim

Re: [PATCH 5/5] mm: vmscan: move dirty pages out of the way until they're flushed

On Mon 23-01-17 13:16:41, Johannes Weiner wrote: > We noticed a performance regression when moving hadoop workloads from > 3.10 kernels to 4.0 and 4.6. This is accompanied by increased pageout > activity initiated by kswapd as well as frequent bursts of allocation > stalls and direct reclaim

Re: [PATCH v2 2/2] gpio: aspeed: Add banks Y, Z, AA, AB and AC

On Tue, Jan 24, 2017 at 7:16 AM, Andrew Jeffery wrote: > This is less straight-forward than one would hope, as some banks only > have 4 pins rather than 8, others are output only, yet more (W and > X, already supported) are input-only, and in the case of the g4 SoC bank > AC

Re: 4.10-rc5+ WARNING: CPU: 3 PID: 1 at ./include/drm/drm_crtc.h:857 drm_kms_helper_poll_enable.part.4+0xa8/0xc0

On Thu, 26 Jan 2017, Borislav Petkov wrote: > Hi all, > > I see this brand new warning when booting here. > > Top commit is v4.10-rc5-107-g883af14e67e8 from Linus' master. Please try [1]. BR, Jani. [1]

Re: [PATCH v2 2/2] gpio: aspeed: Add banks Y, Z, AA, AB and AC

On Tue, Jan 24, 2017 at 7:16 AM, Andrew Jeffery wrote: > This is less straight-forward than one would hope, as some banks only > have 4 pins rather than 8, others are output only, yet more (W and > X, already supported) are input-only, and in the case of the g4 SoC bank > AC doesn't exist. > >

Re: 4.10-rc5+ WARNING: CPU: 3 PID: 1 at ./include/drm/drm_crtc.h:857 drm_kms_helper_poll_enable.part.4+0xa8/0xc0

On Thu, 26 Jan 2017, Borislav Petkov wrote: > Hi all, > > I see this brand new warning when booting here. > > Top commit is v4.10-rc5-107-g883af14e67e8 from Linus' master. Please try [1]. BR, Jani. [1]

Re: [PATCH V11 2/3] ACPI: Add support for ResourceSource/IRQ domain mapping

On Thu, Jan 26, 2017 at 11:43:43AM +0100, Rafael J. Wysocki wrote: > On Thursday, January 26, 2017 10:15:21 AM Lorenzo Pieralisi wrote: > > On Thu, Jan 26, 2017 at 03:01:18AM +0200, Andy Shevchenko wrote: > > > On Fri, Jan 20, 2017 at 4:34 AM, Agustin Vega-Frias > > >

Re: [PATCH V11 2/3] ACPI: Add support for ResourceSource/IRQ domain mapping

On Thu, Jan 26, 2017 at 11:43:43AM +0100, Rafael J. Wysocki wrote: > On Thursday, January 26, 2017 10:15:21 AM Lorenzo Pieralisi wrote: > > On Thu, Jan 26, 2017 at 03:01:18AM +0200, Andy Shevchenko wrote: > > > On Fri, Jan 20, 2017 at 4:34 AM, Agustin Vega-Frias > > > wrote: > > > > ACPI extended

Re: [PATCH v2 1/2] gpio: aspeed: Make bank names strings

On Tue, Jan 24, 2017 at 7:16 AM, Andrew Jeffery wrote: > From: Joel Stanley > > The Aspeed SoCs have more GPIOs than can be represented with A-Z. The > documentation uses two letter names such as AA and AB, so make the names > a three-character array in the bank

Re: [PATCH v2 1/2] gpio: aspeed: Make bank names strings

On Tue, Jan 24, 2017 at 7:16 AM, Andrew Jeffery wrote: > From: Joel Stanley > > The Aspeed SoCs have more GPIOs than can be represented with A-Z. The > documentation uses two letter names such as AA and AB, so make the names > a three-character array in the bank struct to accommodate this. > >

[GIT PULL] pin control fixes for v4.10

Hi Linus, here is a bunch of pin control fixes for v4.10 that didn't get sent off until now, sorry for the delay. Please pull them in, it's only driver fixes. Yours, Linus Walleij The following changes since commit a121103c922847ba5010819a3f250f1f7fc84ab8: Linux 4.10-rc3 (2017-01-08

[GIT PULL] pin control fixes for v4.10

Hi Linus, here is a bunch of pin control fixes for v4.10 that didn't get sent off until now, sorry for the delay. Please pull them in, it's only driver fixes. Yours, Linus Walleij The following changes since commit a121103c922847ba5010819a3f250f1f7fc84ab8: Linux 4.10-rc3 (2017-01-08

Re: [PATCH] pinctrl: aspeed: g4: Fix mux configuration for GPIOs AA[4-7], AB[0-7]

On Mon, Jan 23, 2017 at 6:27 AM, Andrew Jeffery wrote: > Incorrect video output configuration bits were being tested on pins in > GPIO banks AA and AB for the ROM{8,16} mux functions. The ROM{8,16} > functions are the highest priority for the relevant pins and also the > default

Re: [PATCH] pinctrl: aspeed: g4: Fix mux configuration for GPIOs AA[4-7], AB[0-7]

On Mon, Jan 23, 2017 at 6:27 AM, Andrew Jeffery wrote: > Incorrect video output configuration bits were being tested on pins in > GPIO banks AA and AB for the ROM{8,16} mux functions. The ROM{8,16} > functions are the highest priority for the relevant pins and also the > default function, so we

[PATCH v2 2/2] scsi: storvsc: Add support for FC lightweight host.

Included in the current storvsc driver for Hyper-V is the ability to access luns on an FC fabric via a virtualized fiber channel adapter exposed by the Hyper-V host. This was done to provide an interface for existing customer tools that was more consistent with a conventional FC device. The driver

[PATCH v2 0/2] scsi: storvsc: Add support for FC lightweight host.

This patch set is based on the following patch submission and email exchange: [PATCH 1/1] scsi: storvsc: Support manual scan of FC hosts on Hyper-V K. Y. Srinivasan kys at microsoft.com Sat Mar 12 21:52:48 UTC 2016

[PATCH v2 1/2] scsi: scsi_transport_fc: Provide a lightweight option for Virtual FC Hosts.

This patch provides a means to offer a lightweight option to the current FC transport class. This new transport option is more suitable for FC transports running on a VM that virtualizes their FCs and that do not possess rports or vports whereas the heavyweight option maintains the standard

[PATCH v2 2/2] scsi: storvsc: Add support for FC lightweight host.

Included in the current storvsc driver for Hyper-V is the ability to access luns on an FC fabric via a virtualized fiber channel adapter exposed by the Hyper-V host. This was done to provide an interface for existing customer tools that was more consistent with a conventional FC device. The driver

[PATCH v2 0/2] scsi: storvsc: Add support for FC lightweight host.

This patch set is based on the following patch submission and email exchange: [PATCH 1/1] scsi: storvsc: Support manual scan of FC hosts on Hyper-V K. Y. Srinivasan kys at microsoft.com Sat Mar 12 21:52:48 UTC 2016

[PATCH v2 1/2] scsi: scsi_transport_fc: Provide a lightweight option for Virtual FC Hosts.

This patch provides a means to offer a lightweight option to the current FC transport class. This new transport option is more suitable for FC transports running on a VM that virtualizes their FCs and that do not possess rports or vports whereas the heavyweight option maintains the standard

Re: [PATCH 0/6 v3] kvmalloc

On Thu 26-01-17 14:10:06, Daniel Borkmann wrote: > On 01/26/2017 12:58 PM, Michal Hocko wrote: > > On Thu 26-01-17 12:33:55, Daniel Borkmann wrote: > > > On 01/26/2017 11:08 AM, Michal Hocko wrote: > > [...] > > > > If you disagree I can drop the bpf part of course... > > > > > > If we could

Re: [PATCH 0/6 v3] kvmalloc

On Thu 26-01-17 14:10:06, Daniel Borkmann wrote: > On 01/26/2017 12:58 PM, Michal Hocko wrote: > > On Thu 26-01-17 12:33:55, Daniel Borkmann wrote: > > > On 01/26/2017 11:08 AM, Michal Hocko wrote: > > [...] > > > > If you disagree I can drop the bpf part of course... > > > > > > If we could

Re: [PATCH 08/22] power: supply: add AC power supply driver for AXP20X and AXP22X PMICs

Hi Sebastian, On 17/01/2017 04:00, Sebastian Reichel wrote: > Hi Quentin, > > The driver looks mostly fine. I do have a two comments, though. > > On Mon, Jan 02, 2017 at 05:37:08PM +0100, Quentin Schulz wrote: >> [...] >> >> +static int axp20x_ac_power_probe(struct platform_device *pdev) >> +{

Re: [PATCH 08/22] power: supply: add AC power supply driver for AXP20X and AXP22X PMICs

Hi Sebastian, On 17/01/2017 04:00, Sebastian Reichel wrote: > Hi Quentin, > > The driver looks mostly fine. I do have a two comments, though. > > On Mon, Jan 02, 2017 at 05:37:08PM +0100, Quentin Schulz wrote: >> [...] >> >> +static int axp20x_ac_power_probe(struct platform_device *pdev) >> +{

<    5   6   7   8   9   10   11   12   13   14   >