Re: [RFC PATCH 2/2] mtd: devices: m25p80: Enable spi-nor bounce buffer support

+ Mark Le 01/03/2017 à 12:46, Vignesh R a écrit : > > > On Wednesday 01 March 2017 04:13 PM, Cyrille Pitchen wrote: >> Le 01/03/2017 à 05:54, Vignesh R a écrit : >>> >>> >>> On Wednesday 01 March 2017 03:11 AM, Richard Weinberger wrote: Vignesh, Am 27.02.2017 um 13:08 schrieb

Re: [RFC PATCH 2/2] mtd: devices: m25p80: Enable spi-nor bounce buffer support

+ Mark Le 01/03/2017 à 12:46, Vignesh R a écrit : > > > On Wednesday 01 March 2017 04:13 PM, Cyrille Pitchen wrote: >> Le 01/03/2017 à 05:54, Vignesh R a écrit : >>> >>> >>> On Wednesday 01 March 2017 03:11 AM, Richard Weinberger wrote: Vignesh, Am 27.02.2017 um 13:08 schrieb

Re: [PATCH v2 2/3] perf annotate: Introduce the new source code view

Hi Peter, On Wed, Mar 01, 2017 at 03:08:33PM +0100, Peter Zijlstra wrote: > On Wed, Mar 01, 2017 at 10:58:05PM +0900, Namhyung Kim wrote: > > On Wed, Mar 01, 2017 at 04:59:52AM +0900, Taeung Song wrote: > > > The current source code view using 'objdump -S' > > > has several limitations regarding

Re: [PATCH v2 2/3] perf annotate: Introduce the new source code view

Hi Peter, On Wed, Mar 01, 2017 at 03:08:33PM +0100, Peter Zijlstra wrote: > On Wed, Mar 01, 2017 at 10:58:05PM +0900, Namhyung Kim wrote: > > On Wed, Mar 01, 2017 at 04:59:52AM +0900, Taeung Song wrote: > > > The current source code view using 'objdump -S' > > > has several limitations regarding

Re: [PATCH V5 6/6] proc: show MADV_FREE pages info in smaps

On Fri 24-02-17 13:31:49, Shaohua Li wrote: > show MADV_FREE pages info of each vma in smaps. The interface is for > diganose or monitoring purpose, userspace could use it to understand > what happens in the application. Since userspace could dirty MADV_FREE > pages without notice from kernel,

Re: [PATCH V5 6/6] proc: show MADV_FREE pages info in smaps

On Fri 24-02-17 13:31:49, Shaohua Li wrote: > show MADV_FREE pages info of each vma in smaps. The interface is for > diganose or monitoring purpose, userspace could use it to understand > what happens in the application. Since userspace could dirty MADV_FREE > pages without notice from kernel,

Re: [PATCH v5 02/11] phy: exynos-ufs: add UFS PHY driver for EXYNOS SoC

Hi, On Tuesday 28 February 2017 01:51 PM, Alim Akhtar wrote: > Hi Kishon, > > On 02/28/2017 09:04 AM, Kishon Vijay Abraham I wrote: >> Hi, >> >> On Monday 27 February 2017 07:40 PM, Alim Akhtar wrote: >>> Hi Kishon, >>> >>> On 02/27/2017 10:56 AM, Kishon Vijay Abraham I wrote: Hi,

Re: [PATCH v5 02/11] phy: exynos-ufs: add UFS PHY driver for EXYNOS SoC

Hi, On Tuesday 28 February 2017 01:51 PM, Alim Akhtar wrote: > Hi Kishon, > > On 02/28/2017 09:04 AM, Kishon Vijay Abraham I wrote: >> Hi, >> >> On Monday 27 February 2017 07:40 PM, Alim Akhtar wrote: >>> Hi Kishon, >>> >>> On 02/27/2017 10:56 AM, Kishon Vijay Abraham I wrote: Hi,

Re: tip.today - scheduler bam boom crash (cpu hotplug)

On Wed, Mar 01, 2017 at 09:39:18PM +0800, Wanpeng Li wrote: > 2017-02-28 16:11 GMT+08:00 Wanpeng Li : > > 2017-02-28 16:08 GMT+08:00 Peter Zijlstra : > >> On Tue, Feb 28, 2017 at 09:51:07AM +0800, Wanpeng Li wrote: > >>> diff --git

Re: tip.today - scheduler bam boom crash (cpu hotplug)

On Wed, Mar 01, 2017 at 09:39:18PM +0800, Wanpeng Li wrote: > 2017-02-28 16:11 GMT+08:00 Wanpeng Li : > > 2017-02-28 16:08 GMT+08:00 Peter Zijlstra : > >> On Tue, Feb 28, 2017 at 09:51:07AM +0800, Wanpeng Li wrote: > >>> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c > >>>

Re: [PATCH 3/3] watchdog: retu: restore MFD dependency

On 03/01/2017 01:15 AM, Arnd Bergmann wrote: The retu watchdog calls into the respective mfd driver, but fails to link if that is diabled: drivers/watchdog/built-in.o: In function `retu_wdt_set_timeout': ziirave_wdt.c:(.text+0x8c88): undefined reference to `retu_write'

Re: [PATCH 1/2] drivers: pwm: pwm-atmel: switch to atomic PWM

Hi Claudiu, On Wed, 1 Mar 2017 15:56:26 +0200 m18063 wrote: > Hi Boris, > > Thank you for the closer review. Please see my answers > inline. > > Thank you, > Claudiu > > > On 28.02.2017 23:07, Boris Brezillon wrote: > > Hi Claudiu, > > > > On Tue, 28 Feb 2017

Re: [PATCH 2/3] watchdog: db8500: add back prmcu dependency

On 03/01/2017 01:15 AM, Arnd Bergmann wrote: When the db8500 watchdog is enabled without the PRCMU, we get a lot of warnings about duplicate or missing helper functions: In file included from drivers/watchdog/ux500_wdt.c:21:0: include/linux/mfd/dbx500-prcmu.h:422:19: error: redefinition of

Re: [PATCH 3/3] watchdog: retu: restore MFD dependency

On 03/01/2017 01:15 AM, Arnd Bergmann wrote: The retu watchdog calls into the respective mfd driver, but fails to link if that is diabled: drivers/watchdog/built-in.o: In function `retu_wdt_set_timeout': ziirave_wdt.c:(.text+0x8c88): undefined reference to `retu_write'

Re: [PATCH 1/2] drivers: pwm: pwm-atmel: switch to atomic PWM

Hi Claudiu, On Wed, 1 Mar 2017 15:56:26 +0200 m18063 wrote: > Hi Boris, > > Thank you for the closer review. Please see my answers > inline. > > Thank you, > Claudiu > > > On 28.02.2017 23:07, Boris Brezillon wrote: > > Hi Claudiu, > > > > On Tue, 28 Feb 2017 12:40:14 +0200 > > Claudiu

Re: [PATCH 2/3] watchdog: db8500: add back prmcu dependency

On 03/01/2017 01:15 AM, Arnd Bergmann wrote: When the db8500 watchdog is enabled without the PRCMU, we get a lot of warnings about duplicate or missing helper functions: In file included from drivers/watchdog/ux500_wdt.c:21:0: include/linux/mfd/dbx500-prcmu.h:422:19: error: redefinition of

Re: [PATCH v3 20/25] ARM: owl: Implement CPU enable-method for S500

git tree, please drop us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Andreas-F-rber/ARM-Initial-Actions-Semi-S500-and-S900-enablement/20170301-110028 > config: arm-allmodconfig (attached as .config) > compiler: arm-linux-gnue

Re: [PATCH v3 20/25] ARM: owl: Implement CPU enable-method for S500

git tree, please drop us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Andreas-F-rber/ARM-Initial-Actions-Semi-S500-and-S900-enablement/20170301-110028 > config: arm-allmodconfig (attached as .config) > compiler: arm-linux-gnue

Re: [PATCH 1/3] watchdog: kempld: fix gcc-4.3 build

On 03/01/2017 01:15 AM, Arnd Bergmann wrote: gcc-4.3 can't decide whether the constant value in kempld_prescaler[PRESCALER_21] is built-time constant or not, and gets confused by the logic in do_div(): drivers/watchdog/kempld_wdt.o: In function `kempld_wdt_set_stage_timeout':

Re: [PATCH 1/3] watchdog: kempld: fix gcc-4.3 build

On 03/01/2017 01:15 AM, Arnd Bergmann wrote: gcc-4.3 can't decide whether the constant value in kempld_prescaler[PRESCALER_21] is built-time constant or not, and gets confused by the logic in do_div(): drivers/watchdog/kempld_wdt.o: In function `kempld_wdt_set_stage_timeout':

Re: [PATCH 4/5] x86/intel_rdt: Reset the cbm MSR during rmdir

On Fri, 17 Feb 2017, Vikas Shivappa wrote: > During rmdir reset the ctrl values to all 1s in the QOS_MSR for the > directory's closid. This is done so that that next time when the closid > is reused they dont reflect old values. Sigh. > +static int reset_all_ctrls(struct rdt_resource *r, u32

Re: [PATCH 4/5] x86/intel_rdt: Reset the cbm MSR during rmdir

On Fri, 17 Feb 2017, Vikas Shivappa wrote: > During rmdir reset the ctrl values to all 1s in the QOS_MSR for the > directory's closid. This is done so that that next time when the closid > is reused they dont reflect old values. Sigh. > +static int reset_all_ctrls(struct rdt_resource *r, u32

Re: [PATCH v2] sched/rt: Add comments describing the RT IPI pull method

On Wed, 1 Mar 2017 10:44:09 +0100 Peter Zijlstra wrote: > On Tue, Feb 28, 2017 at 03:50:30PM -0500, Steven Rostedt wrote: > > + * The overloaded RT CPU, wher receiving an IPI, will try to push off its > > "wher" isn't in my dictionary, I'm thinking you mean: "when".

Re: [PATCH v2] sched/rt: Add comments describing the RT IPI pull method

On Wed, 1 Mar 2017 10:44:09 +0100 Peter Zijlstra wrote: > On Tue, Feb 28, 2017 at 03:50:30PM -0500, Steven Rostedt wrote: > > + * The overloaded RT CPU, wher receiving an IPI, will try to push off its > > "wher" isn't in my dictionary, I'm thinking you mean: "when". Fixed that > for you.

Re: [PATCH 1/4] MIPS: Handle non word sized instructions when examining frame

Hi Maciej On 28/02/17 20:54, Maciej W. Rozycki wrote: On Tue, 28 Feb 2017, Matt Redfearn wrote: Since the instruction modifying the stack pointer is usually the first in the function, that one is ususally handled correctly. But the s/ususally/usually/ oops diff --git

Re: [PATCH 1/4] MIPS: Handle non word sized instructions when examining frame

Hi Maciej On 28/02/17 20:54, Maciej W. Rozycki wrote: On Tue, 28 Feb 2017, Matt Redfearn wrote: Since the instruction modifying the stack pointer is usually the first in the function, that one is ususally handled correctly. But the s/ususally/usually/ oops diff --git

[PATCH 4/7] ARM: OMAP4460: Thermal: Add slope and offset values

Currently the slope and offset values for calculating the hot spot temperature of a particular thermal zone is part of driver data. Pass them here instead and obtain the values while of node parsing. Signed-off-by: Keerthy --- arch/arm/boot/dts/omap4460.dtsi | 4 1 file

[PATCH 4/7] ARM: OMAP4460: Thermal: Add slope and offset values

Currently the slope and offset values for calculating the hot spot temperature of a particular thermal zone is part of driver data. Pass them here instead and obtain the values while of node parsing. Signed-off-by: Keerthy --- arch/arm/boot/dts/omap4460.dtsi | 4 1 file changed, 4

Re: [PATCH 2/5] x86/intel_rdt: Improvements to parsing schemata

On Fri, 17 Feb 2017, Vikas Shivappa wrote: > The schemata file requires all RDT (Resource director technology) > resources be entered in the same order they are shown in the root > schemata file. > Hence remove the looping through all resources while parsing each > schemata and get the next

Re: [PATCH 2/5] x86/intel_rdt: Improvements to parsing schemata

On Fri, 17 Feb 2017, Vikas Shivappa wrote: > The schemata file requires all RDT (Resource director technology) > resources be entered in the same order they are shown in the root > schemata file. > Hence remove the looping through all resources while parsing each > schemata and get the next

Re: [PATCH 1/2] drivers: pwm: pwm-atmel: switch to atomic PWM

Hi Boris, Thank you for the closer review. Please see my answers inline. Thank you, Claudiu On 28.02.2017 23:07, Boris Brezillon wrote: > Hi Claudiu, > > On Tue, 28 Feb 2017 12:40:14 +0200 > Claudiu Beznea wrote: > >> The currently Atmel PWM controllers supported

Re: [PATCH 1/2] drivers: pwm: pwm-atmel: switch to atomic PWM

Hi Boris, Thank you for the closer review. Please see my answers inline. Thank you, Claudiu On 28.02.2017 23:07, Boris Brezillon wrote: > Hi Claudiu, > > On Tue, 28 Feb 2017 12:40:14 +0200 > Claudiu Beznea wrote: > >> The currently Atmel PWM controllers supported by this driver >> could

[PATCH v3 1/2] crypto: vmx - Use skcipher for cbc fallback

Signed-off-by: Paulo Flabiano Smorigo --- drivers/crypto/vmx/aes_cbc.c | 47 ++-- 1 file changed, 24 insertions(+), 23 deletions(-) diff --git a/drivers/crypto/vmx/aes_cbc.c b/drivers/crypto/vmx/aes_cbc.c index

How to handle quirky behavior with boards.

Hey all, We found a bug in the design of a board that we use. This board (Olimex OLinuXino Lime2) features a PMIC (AXP209) and has an LDO, LDO3, that needs special treatment. The bug is, that there is too much capacitance on the output of LDO3, which causes the PMIC to shutdown when

[PATCH v3 1/2] crypto: vmx - Use skcipher for cbc fallback

Signed-off-by: Paulo Flabiano Smorigo --- drivers/crypto/vmx/aes_cbc.c | 47 ++-- 1 file changed, 24 insertions(+), 23 deletions(-) diff --git a/drivers/crypto/vmx/aes_cbc.c b/drivers/crypto/vmx/aes_cbc.c index 94ad5c0..72a26eb 100644 ---

How to handle quirky behavior with boards.

Hey all, We found a bug in the design of a board that we use. This board (Olimex OLinuXino Lime2) features a PMIC (AXP209) and has an LDO, LDO3, that needs special treatment. The bug is, that there is too much capacitance on the output of LDO3, which causes the PMIC to shutdown when

Re: [PATCH v2 2/3] perf annotate: Introduce the new source code view

On Wed, Mar 01, 2017 at 04:59:52AM +0900, Taeung Song wrote: > The current source code view using 'objdump -S' > has several limitations regarding line numbers of each soure > code line and confusing mixed soure code & diassembly view. > > So not use the '-S' option any more and > add the new

Re: [PATCH v2 2/3] perf annotate: Introduce the new source code view

On Wed, Mar 01, 2017 at 04:59:52AM +0900, Taeung Song wrote: > The current source code view using 'objdump -S' > has several limitations regarding line numbers of each soure > code line and confusing mixed soure code & diassembly view. > > So not use the '-S' option any more and > add the new

[PATCH 5/9] mm: don't avoid high-priority reclaim on unreclaimable nodes

246e87a93934 ("memcg: fix get_scan_count() for small targets") sought to avoid high reclaim priorities for kswapd by forcing it to scan a minimum amount of pages when lru_pages >> priority yielded nothing. b95a2f2d486d ("mm: vmscan: convert global reclaim to per-memcg LRU lists"), due to

[PATCH 5/9] mm: don't avoid high-priority reclaim on unreclaimable nodes

246e87a93934 ("memcg: fix get_scan_count() for small targets") sought to avoid high reclaim priorities for kswapd by forcing it to scan a minimum amount of pages when lru_pages >> priority yielded nothing. b95a2f2d486d ("mm: vmscan: convert global reclaim to per-memcg LRU lists"), due to

Re: [PATCH] HID: Accutouch: Add driver for ELO Accutouch 2216 USB Touchscreens

Hi, On Feb 28 2017 or thereabouts, Martyn Welch wrote: > This patch has been sitting on the list for about 2 weeks. Is there > anything wrong with this patch? The only wrong thing with the patch (I haven't started reviewing it yet) is the timing. It was sent shortly before or at the time of the

Re: [PATCH] tpm: do not suspend/resume if power stays on

On Wed, Mar 01, 2017 at 12:51:16PM +0100, Enric Balletbo i Serra wrote: > From: Sonny Rao > > The suspend/resume behavior of the TPM can be controlled > by setting "powered-while-suspended" in the DTS. > > Signed-off-by: Sonny Rao > Signed-off-by:

Re: [PATCH] HID: Accutouch: Add driver for ELO Accutouch 2216 USB Touchscreens

Hi, On Feb 28 2017 or thereabouts, Martyn Welch wrote: > This patch has been sitting on the list for about 2 weeks. Is there > anything wrong with this patch? The only wrong thing with the patch (I haven't started reviewing it yet) is the timing. It was sent shortly before or at the time of the

Re: [PATCH] tpm: do not suspend/resume if power stays on

On Wed, Mar 01, 2017 at 12:51:16PM +0100, Enric Balletbo i Serra wrote: > From: Sonny Rao > > The suspend/resume behavior of the TPM can be controlled > by setting "powered-while-suspended" in the DTS. > > Signed-off-by: Sonny Rao > Signed-off-by: Enric Balletbo i Serra > --- >

Re: [PATCH] Revert "tty: serial: pl011: add ttyAMA for matching pl011 console"

On 01/03/17 13:01, Aleksey Makarov wrote: > > > On 03/01/2017 03:59 PM, Robin Murphy wrote: >> On 01/03/17 12:26, Aleksey Makarov wrote: >>> The original patch makes condition always true, so it is wrong. >>> >>> This reverts commit aea9a80ba98a0c9b4de88850260e9fbdcc98360b. >> >> It seems fairly

[PATCH 9/9] mm: remove unnecessary back-off function when retrying page reclaim

The backoff mechanism is not needed. If we have MAX_RECLAIM_RETRIES loops without progress, we'll OOM anyway; backing off might cut one or two iterations off that in the rare OOM case. If we have intermittent success reclaiming a few pages, the backoff function gets reset also, and so is of little

Re: [PATCH] Revert "tty: serial: pl011: add ttyAMA for matching pl011 console"

On 01/03/17 13:01, Aleksey Makarov wrote: > > > On 03/01/2017 03:59 PM, Robin Murphy wrote: >> On 01/03/17 12:26, Aleksey Makarov wrote: >>> The original patch makes condition always true, so it is wrong. >>> >>> This reverts commit aea9a80ba98a0c9b4de88850260e9fbdcc98360b. >> >> It seems fairly

[PATCH 9/9] mm: remove unnecessary back-off function when retrying page reclaim

The backoff mechanism is not needed. If we have MAX_RECLAIM_RETRIES loops without progress, we'll OOM anyway; backing off might cut one or two iterations off that in the rare OOM case. If we have intermittent success reclaiming a few pages, the backoff function gets reset also, and so is of little

Re: [PATCH] x86/apic: Remove the extra judgement of skipped IO APIC setup

Dear Ingo, At 03/01/2017 05:04 PM, Ingo Molnar wrote: [...] + pr_info("Not init interrupt remapping due to skipped IO-APIC setup\n"); So you replaced a perfectly readable kernel message: - pr_info("Not enabling interrupt remapping due to skipped IO-APIC

Re: [PATCH] x86/apic: Remove the extra judgement of skipped IO APIC setup

Dear Ingo, At 03/01/2017 05:04 PM, Ingo Molnar wrote: [...] + pr_info("Not init interrupt remapping due to skipped IO-APIC setup\n"); So you replaced a perfectly readable kernel message: - pr_info("Not enabling interrupt remapping due to skipped IO-APIC

Re: [PATCH v6 2/2] [media] s5p-mfc: Handle 'v4l2_pix_format:field' in try_fmt and g_fmt

Hello, On 03/01/2017 10:12 AM, Andrzej Hajda wrote: On 01.03.2017 12:51, Thibault Saunier wrote: It is required by the standard that the field order is set by the driver, default to NONE in case any is provided, but we can basically accept any value provided by the userspace as we will anyway

Re: [PATCH v6 2/2] [media] s5p-mfc: Handle 'v4l2_pix_format:field' in try_fmt and g_fmt

Hello, On 03/01/2017 10:12 AM, Andrzej Hajda wrote: On 01.03.2017 12:51, Thibault Saunier wrote: It is required by the standard that the field order is set by the driver, default to NONE in case any is provided, but we can basically accept any value provided by the userspace as we will anyway

[PATCH 0/5] fs, xfs atomic_t to refcount_t conversions version 2

changes in v2: * removed two patches that actually caused problems in testing and there didn't seem to be a resonable way to convert them to refcount_t based on all the triggered issues. * run xfstests with TEST and SCRATCH partitions enabled, XFS_DEBUG on, and WARNs on refcount_t API on.

[PATCH 0/5] fs, xfs atomic_t to refcount_t conversions version 2

changes in v2: * removed two patches that actually caused problems in testing and there didn't seem to be a resonable way to convert them to refcount_t based on all the triggered issues. * run xfstests with TEST and SCRATCH partitions enabled, XFS_DEBUG on, and WARNs on refcount_t API on.

Re: tip.today - scheduler bam boom crash (cpu hotplug)

2017-02-28 16:11 GMT+08:00 Wanpeng Li : > 2017-02-28 16:08 GMT+08:00 Peter Zijlstra : >> On Tue, Feb 28, 2017 at 09:51:07AM +0800, Wanpeng Li wrote: >>> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c >>> index 4e95b2e..ed8eda4 100644

Re: tip.today - scheduler bam boom crash (cpu hotplug)

2017-02-28 16:11 GMT+08:00 Wanpeng Li : > 2017-02-28 16:08 GMT+08:00 Peter Zijlstra : >> On Tue, Feb 28, 2017 at 09:51:07AM +0800, Wanpeng Li wrote: >>> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c >>> index 4e95b2e..ed8eda4 100644 >>> --- a/arch/x86/kernel/cpu/amd.c >>> +++

Re: [PATCH v2 1/3] perf annotate: Get correct line numbers matched with addr

Hi Taeung, On Wed, Mar 01, 2017 at 04:59:51AM +0900, Taeung Song wrote: > Currently perf-annotate show wrong line numbers. > > For example, > Actual source code is as below > > ... > 21 }; > 22 > 23 unsigned int limited_wgt; > 24 > 25 unsigned int get_cond_maxprice(int wgt) > 26 { >

Re: [PATCH v2 1/3] perf annotate: Get correct line numbers matched with addr

Hi Taeung, On Wed, Mar 01, 2017 at 04:59:51AM +0900, Taeung Song wrote: > Currently perf-annotate show wrong line numbers. > > For example, > Actual source code is as below > > ... > 21 }; > 22 > 23 unsigned int limited_wgt; > 24 > 25 unsigned int get_cond_maxprice(int wgt) > 26 { >

[tip:core/urgent] objtool, compiler.h: Fix __unreachable section relocation size

Commit-ID: 55149d06534ae2a7ba5f7a078353deb89b3fe891 Gitweb: http://git.kernel.org/tip/55149d06534ae2a7ba5f7a078353deb89b3fe891 Author: Josh Poimboeuf AuthorDate: Wed, 1 Mar 2017 00:05:04 -0600 Committer: Ingo Molnar CommitDate: Wed, 1 Mar 2017

[tip:core/urgent] objtool, compiler.h: Fix __unreachable section relocation size

Commit-ID: 55149d06534ae2a7ba5f7a078353deb89b3fe891 Gitweb: http://git.kernel.org/tip/55149d06534ae2a7ba5f7a078353deb89b3fe891 Author: Josh Poimboeuf AuthorDate: Wed, 1 Mar 2017 00:05:04 -0600 Committer: Ingo Molnar CommitDate: Wed, 1 Mar 2017 14:20:18 +0100 objtool, compiler.h: Fix

Re: [PATCH v3] lockdep: Teach lockdep about memalloc_noio_save

On Wed 01-03-17 13:29:57, Nikolay Borisov wrote: > Commit 21caf2fc1931 ("mm: teach mm by current context info to not do I/O > during memory allocation") added the memalloc_noio_(save|restore) functions > to enable people to modify the MM behavior by disbaling I/O during memory > allocation. This

Re: [PATCH v3] lockdep: Teach lockdep about memalloc_noio_save

On Wed 01-03-17 13:29:57, Nikolay Borisov wrote: > Commit 21caf2fc1931 ("mm: teach mm by current context info to not do I/O > during memory allocation") added the memalloc_noio_(save|restore) functions > to enable people to modify the MM behavior by disbaling I/O during memory > allocation. This

Re: [PATCH v6 2/2] [media] s5p-mfc: Handle 'v4l2_pix_format:field' in try_fmt and g_fmt

On 01.03.2017 12:51, Thibault Saunier wrote: > It is required by the standard that the field order is set by the > driver, default to NONE in case any is provided, but we can basically > accept any value provided by the userspace as we will anyway not > be able to do any deinterlacing. > > In this

Re: [PATCH v6 2/2] [media] s5p-mfc: Handle 'v4l2_pix_format:field' in try_fmt and g_fmt

On 01.03.2017 12:51, Thibault Saunier wrote: > It is required by the standard that the field order is set by the > driver, default to NONE in case any is provided, but we can basically > accept any value provided by the userspace as we will anyway not > be able to do any deinterlacing. > > In this

Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt

2017-03-01 13:42 GMT+01:00 Gilad Ben-Yossef : > It really is an observation about overhead of context switches between > dm-crypt and > whatever/wherever you handle crypto - be it an off CPU hardware engine > or a bunch > of parallel kernel threads running on other cores. You

Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt

2017-03-01 13:42 GMT+01:00 Gilad Ben-Yossef : > It really is an observation about overhead of context switches between > dm-crypt and > whatever/wherever you handle crypto - be it an off CPU hardware engine > or a bunch > of parallel kernel threads running on other cores. You really want to >

Re: [PATCH v2 3/3] media: dt-bindings: vpif: new optional property

On Tuesday 28 February 2017 04:30 PM, Bartosz Golaszewski wrote: > 2017-02-28 6:36 GMT+01:00 Sekhar Nori : >> On Tuesday 28 February 2017 04:22 AM, Rob Herring wrote: >>> On Wed, Feb 22, 2017 at 02:43:47PM +0100, Bartosz Golaszewski wrote: Add an optional property -

Re: [PATCH v2 3/3] media: dt-bindings: vpif: new optional property

On Tuesday 28 February 2017 04:30 PM, Bartosz Golaszewski wrote: > 2017-02-28 6:36 GMT+01:00 Sekhar Nori : >> On Tuesday 28 February 2017 04:22 AM, Rob Herring wrote: >>> On Wed, Feb 22, 2017 at 02:43:47PM +0100, Bartosz Golaszewski wrote: Add an optional property - enable-gpios - which can

Re: [PATCH] Revert "tty: serial: pl011: add ttyAMA for matching pl011 console"

On 01/03/17 12:26, Aleksey Makarov wrote: > The original patch makes condition always true, so it is wrong. > > This reverts commit aea9a80ba98a0c9b4de88850260e9fbdcc98360b. It seems fairly clear that the intent of the code merely warrants s/||/&&/ - wouldn't it be more straightforward to just

Re: [f2fs-dev] [PATCH RFC] f2fs: combine nat_bits and free_nid_bitmap cache

On 3/1/2017 17:10, Chao Yu wrote: > Both nat_bits cache and free_nid_bitmap cache provide same functionality > as a intermediate cache between free nid cache and disk, but with > different granularity of indicating free nid range, and different > persistence policy. nat_bits cache provides better

Re: [PATCH] Revert "tty: serial: pl011: add ttyAMA for matching pl011 console"

On 01/03/17 12:26, Aleksey Makarov wrote: > The original patch makes condition always true, so it is wrong. > > This reverts commit aea9a80ba98a0c9b4de88850260e9fbdcc98360b. It seems fairly clear that the intent of the code merely warrants s/||/&&/ - wouldn't it be more straightforward to just

Re: [f2fs-dev] [PATCH RFC] f2fs: combine nat_bits and free_nid_bitmap cache

On 3/1/2017 17:10, Chao Yu wrote: > Both nat_bits cache and free_nid_bitmap cache provide same functionality > as a intermediate cache between free nid cache and disk, but with > different granularity of indicating free nid range, and different > persistence policy. nat_bits cache provides better

Re: [PATCH] mm, add_memory_resource: hold device_hotplug lock over mem_hotplug_{begin, done}

On Tue, Feb 28, 2017 at 12:57:29PM +0100, Heiko Carstens wrote: > On Mon, Feb 27, 2017 at 05:20:31PM +0100, Michal Hocko wrote: > > [CC Rafael] > > > > I've got lost in the acpi indirection (again). I can see > > acpi_device_hotplug calling lock_device_hotplug() but i cannot find a > > path down

Re: [PATCH] mm, add_memory_resource: hold device_hotplug lock over mem_hotplug_{begin, done}

On Tue, Feb 28, 2017 at 12:57:29PM +0100, Heiko Carstens wrote: > On Mon, Feb 27, 2017 at 05:20:31PM +0100, Michal Hocko wrote: > > [CC Rafael] > > > > I've got lost in the acpi indirection (again). I can see > > acpi_device_hotplug calling lock_device_hotplug() but i cannot find a > > path down

Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt

On 03/01/2017 01:42 PM, Gilad Ben-Yossef wrote: ... > I can certainly understand if you don't wont to take the patch until > we have results with > dm-crypt itself but the difference between 8 separate invocation of > the engine for 512 > bytes of XTS and a single invocation for 4KB are pretty

Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt

On 03/01/2017 01:42 PM, Gilad Ben-Yossef wrote: ... > I can certainly understand if you don't wont to take the patch until > we have results with > dm-crypt itself but the difference between 8 separate invocation of > the engine for 512 > bytes of XTS and a single invocation for 4KB are pretty

Re: [PATCH] Revert "tty: serial: pl011: add ttyAMA for matching pl011 console"

On 03/01/2017 03:59 PM, Robin Murphy wrote: > On 01/03/17 12:26, Aleksey Makarov wrote: >> The original patch makes condition always true, so it is wrong. >> >> This reverts commit aea9a80ba98a0c9b4de88850260e9fbdcc98360b. > > It seems fairly clear that the intent of the code merely warrants >

Re: [PATCH] Revert "tty: serial: pl011: add ttyAMA for matching pl011 console"

On 03/01/2017 03:59 PM, Robin Murphy wrote: > On 01/03/17 12:26, Aleksey Makarov wrote: >> The original patch makes condition always true, so it is wrong. >> >> This reverts commit aea9a80ba98a0c9b4de88850260e9fbdcc98360b. > > It seems fairly clear that the intent of the code merely warrants >

[PATCH v4] net: don't call strlen() on the user buffer in packet_bind_spkt()

KMSAN (KernelMemorySanitizer, a new error detection tool) reports use of uninitialized memory in packet_bind_spkt(): == BUG: KMSAN: use of unitialized memory CPU: 0 PID: 1074 Comm: packet Not tainted 4.8.0-rc6+ #1891 Hardware name:

[PATCH v4] net: don't call strlen() on the user buffer in packet_bind_spkt()

KMSAN (KernelMemorySanitizer, a new error detection tool) reports use of uninitialized memory in packet_bind_spkt(): == BUG: KMSAN: use of unitialized memory CPU: 0 PID: 1074 Comm: packet Not tainted 4.8.0-rc6+ #1891 Hardware name:

Re: [PATCH] objtool, compiler.h: Fix __unreachable section relocation size

On Wed, Mar 01, 2017 at 01:44:01PM +0100, Ingo Molnar wrote: > > * Josh Poimboeuf wrote: > > > On Wed, Mar 01, 2017 at 12:15:38AM -0800, h...@zytor.com wrote: > > > On March 1, 2017 12:10:59 AM PST, tip-bot for Josh Poimboeuf > > > wrote: > > >

Re: [PATCH] objtool, compiler.h: Fix __unreachable section relocation size

On Wed, Mar 01, 2017 at 01:44:01PM +0100, Ingo Molnar wrote: > > * Josh Poimboeuf wrote: > > > On Wed, Mar 01, 2017 at 12:15:38AM -0800, h...@zytor.com wrote: > > > On March 1, 2017 12:10:59 AM PST, tip-bot for Josh Poimboeuf > > > wrote: > > > >Commit-ID:

Re: [PATCH v5 06/13] lockdep: Implement crossrelease feature

On Wed, Mar 01, 2017 at 11:45:48AM +0100, Peter Zijlstra wrote: > On Wed, Mar 01, 2017 at 01:40:33PM +0900, Byungchul Park wrote: > > > Right. I decided to force MAX_XHLOCKS_NR to be power of 2 and everything > > became easy. Thank you very much. > > Something like: > >

Re: [PATCH v5 06/13] lockdep: Implement crossrelease feature

On Wed, Mar 01, 2017 at 11:45:48AM +0100, Peter Zijlstra wrote: > On Wed, Mar 01, 2017 at 01:40:33PM +0900, Byungchul Park wrote: > > > Right. I decided to force MAX_XHLOCKS_NR to be power of 2 and everything > > became easy. Thank you very much. > > Something like: > >

Re: [tip:core/urgent] objtool: Fix __unreachable section relocation size

On Wed, Mar 01, 2017 at 11:37:12AM +0100, Ingo Molnar wrote: > > * tip-bot for Josh Poimboeuf wrote: > > > Commit-ID: 90a7e63a31b8f7d630d12ef0d8d37d3ab87f76e5 > > Gitweb: > > http://git.kernel.org/tip/90a7e63a31b8f7d630d12ef0d8d37d3ab87f76e5 > > Author: Josh

Re: [tip:core/urgent] objtool: Fix __unreachable section relocation size

On Wed, Mar 01, 2017 at 11:37:12AM +0100, Ingo Molnar wrote: > > * tip-bot for Josh Poimboeuf wrote: > > > Commit-ID: 90a7e63a31b8f7d630d12ef0d8d37d3ab87f76e5 > > Gitweb: > > http://git.kernel.org/tip/90a7e63a31b8f7d630d12ef0d8d37d3ab87f76e5 > > Author: Josh Poimboeuf > > AuthorDate:

Re: [tip:core/urgent] objtool: Fix __unreachable section relocation size

On Wed, Mar 01, 2017 at 12:15:38AM -0800, h...@zytor.com wrote: > On March 1, 2017 12:10:59 AM PST, tip-bot for Josh Poimboeuf > wrote: > >Commit-ID: 90a7e63a31b8f7d630d12ef0d8d37d3ab87f76e5 > >Gitweb: > >http://git.kernel.org/tip/90a7e63a31b8f7d630d12ef0d8d37d3ab87f76e5 >

[PATCH] objtool, compiler.h: Fix __unreachable section relocation size

* Josh Poimboeuf wrote: > On Wed, Mar 01, 2017 at 12:15:38AM -0800, h...@zytor.com wrote: > > On March 1, 2017 12:10:59 AM PST, tip-bot for Josh Poimboeuf > > wrote: > > >Commit-ID: 90a7e63a31b8f7d630d12ef0d8d37d3ab87f76e5 > > >Gitweb: > >

Re: [tip:core/urgent] objtool: Fix __unreachable section relocation size

On Wed, Mar 01, 2017 at 12:15:38AM -0800, h...@zytor.com wrote: > On March 1, 2017 12:10:59 AM PST, tip-bot for Josh Poimboeuf > wrote: > >Commit-ID: 90a7e63a31b8f7d630d12ef0d8d37d3ab87f76e5 > >Gitweb: > >http://git.kernel.org/tip/90a7e63a31b8f7d630d12ef0d8d37d3ab87f76e5 > >Author: Josh

[PATCH] objtool, compiler.h: Fix __unreachable section relocation size

* Josh Poimboeuf wrote: > On Wed, Mar 01, 2017 at 12:15:38AM -0800, h...@zytor.com wrote: > > On March 1, 2017 12:10:59 AM PST, tip-bot for Josh Poimboeuf > > wrote: > > >Commit-ID: 90a7e63a31b8f7d630d12ef0d8d37d3ab87f76e5 > > >Gitweb: > >

Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt

On Wed, Mar 1, 2017 at 11:29 AM, Milan Broz wrote: > > On 03/01/2017 09:30 AM, Gilad Ben-Yossef wrote: > > On Tue, Feb 28, 2017 at 11:05 PM, Milan Broz wrote: > >> > >> On 02/22/2017 07:12 AM, Binoy Jayan wrote: > >>> > >>> I was wondering if this is

Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt

On Wed, Mar 1, 2017 at 11:29 AM, Milan Broz wrote: > > On 03/01/2017 09:30 AM, Gilad Ben-Yossef wrote: > > On Tue, Feb 28, 2017 at 11:05 PM, Milan Broz wrote: > >> > >> On 02/22/2017 07:12 AM, Binoy Jayan wrote: > >>> > >>> I was wondering if this is near to be ready for submission (apart from >

Re: [PATCH 2/2] x86: wire up fchmodat2() syscall

-fchmodat2-syscall/20170301-150213 config: xtensa-allyesconfig (attached as .config) compiler: xtensa-linux-gcc (GCC) 4.9.0 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save

Re: [PATCH 2/2] x86: wire up fchmodat2() syscall

-fchmodat2-syscall/20170301-150213 config: xtensa-allyesconfig (attached as .config) compiler: xtensa-linux-gcc (GCC) 4.9.0 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save

[PATCH 2/4] qxl: limit monitor config read retries

When reading the monitor config fails, don't retry forever. If it fails ten times in a row just give up to avoid the driver hangs. Also add a small delay after each attempt, so the host has a chance to complete a partial update. Signed-off-by: Gerd Hoffmann ---

[PATCH] Revert "tty: serial: pl011: add ttyAMA for matching pl011 console"

The original patch makes condition always true, so it is wrong. This reverts commit aea9a80ba98a0c9b4de88850260e9fbdcc98360b. --- drivers/tty/serial/amba-pl011.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c

[PATCH 2/4] qxl: limit monitor config read retries

When reading the monitor config fails, don't retry forever. If it fails ten times in a row just give up to avoid the driver hangs. Also add a small delay after each attempt, so the host has a chance to complete a partial update. Signed-off-by: Gerd Hoffmann ---

[PATCH] Revert "tty: serial: pl011: add ttyAMA for matching pl011 console"

The original patch makes condition always true, so it is wrong. This reverts commit aea9a80ba98a0c9b4de88850260e9fbdcc98360b. --- drivers/tty/serial/amba-pl011.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c

[PATCH 3/4] qxl: read monitors config at boot

Try to read the client monitors config at driver load time, even without explicit notification. So in case that info was filled before the driver loaded and we've missed the notifications because of that the settings will still be used. With that place we now have to take care to properly handle

[PATCH 3/4] qxl: read monitors config at boot

Try to read the client monitors config at driver load time, even without explicit notification. So in case that info was filled before the driver loaded and we've missed the notifications because of that the settings will still be used. With that place we now have to take care to properly handle

<    8   9   10   11   12   13   14   15   16   17   >