[PATCH 09/10] fs, fsnotify: convert fsnotify_mark.refcnt from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by: Hans Liljestrand

[PATCH] cpufreq: mt8173: Add support for MT8176 and MT817x compatibles

The Mediatek MT8173 is just on of several SOCs from the same MT817x family, including the 6-core (4-little/2-big) MT8176. The mt8173-cpufreq driver supports all of these SOCs, however, machines using them may use a different machine compatible. Since this driver checks explicitly for the machine

[PATCH 2/2] vfio: type1: conditionally check MSI remapping at irq domain level

Check only if irq domains are available. Signed-off-by: Mian Yousaf Kaukab --- drivers/vfio/vfio_iommu_type1.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c index

[PATCH 2/2] vfio: type1: conditionally check MSI remapping at irq domain level

Check only if irq domains are available. Signed-off-by: Mian Yousaf Kaukab --- drivers/vfio/vfio_iommu_type1.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c index bd6f293c4ebd..e3ed50e40ead 100644 ---

[PATCH 1/2] irqdomain: add empty irq_domain_check_msi_remap

Fix following build error for s390: drivers/vfio/vfio_iommu_type1.c: In function 'vfio_iommu_type1_attach_group': drivers/vfio/vfio_iommu_type1.c:1290:25: error: implicit declaration of function 'irq_domain_check_msi_remap' Signed-off-by: Mian Yousaf Kaukab ---

[PATCH 1/2] irqdomain: add empty irq_domain_check_msi_remap

Fix following build error for s390: drivers/vfio/vfio_iommu_type1.c: In function 'vfio_iommu_type1_attach_group': drivers/vfio/vfio_iommu_type1.c:1290:25: error: implicit declaration of function 'irq_domain_check_msi_remap' Signed-off-by: Mian Yousaf Kaukab --- include/linux/irqdomain.h | 4

[PATCH v3 1/7] arm64: dts: exynos: Add the burst and esc clock frequency properties for exynos5433 dts

The OF graph is not needed because the panel is a child of dsi. So added the burst and esc clock frequency properties to the parent (DSI node), taking into account the bisectability problem so that remove the OF graph from DSI node. Signed-off-by: Hoegeun Kwon

[PATCH v3 1/7] arm64: dts: exynos: Add the burst and esc clock frequency properties for exynos5433 dts

The OF graph is not needed because the panel is a child of dsi. So added the burst and esc clock frequency properties to the parent (DSI node), taking into account the bisectability problem so that remove the OF graph from DSI node. Signed-off-by: Hoegeun Kwon Reviewed-by: Andrzej Hajda ---

[PATCH v3 0/7] Fix the parse_dt of exynos dsi and remove the OF graph

Hi All, The dsi + panel is a parental relationship, so OF grpah is not needed. Therefore, the current dsi_parse_dt function will throw an error, because there is no linked OF graph for case such as fimd + dsi + panel. So the 1/5 patch parse the Pll, burst and esc clock frequency properties in

[PATCH v3 0/7] Fix the parse_dt of exynos dsi and remove the OF graph

Hi All, The dsi + panel is a parental relationship, so OF grpah is not needed. Therefore, the current dsi_parse_dt function will throw an error, because there is no linked OF graph for case such as fimd + dsi + panel. So the 1/5 patch parse the Pll, burst and esc clock frequency properties in

[PATCH v3 3/7] arm: dts: Add the burst and esc clock frequency properties for exynos4412 dts

The OF graph is not needed because the panel is a child of dsi. So added the burst and esc clock frequency properties to the parent (DSI node), taking into account the bisectability problem so that remove the OF graph from DSI node. Signed-off-by: Hoegeun Kwon

[PATCH v3 4/7] arm: dts: Add the burst and esc clock frequency properties for exynos4210 dts

The OF graph is not needed because the panel is a child of dsi. So added the burst and esc clock frequency properties to the parent (DSI node), taking into account the bisectability problem so that remove the OF graph from DSI node. Signed-off-by: Hoegeun Kwon

[PATCH v3 3/7] arm: dts: Add the burst and esc clock frequency properties for exynos4412 dts

The OF graph is not needed because the panel is a child of dsi. So added the burst and esc clock frequency properties to the parent (DSI node), taking into account the bisectability problem so that remove the OF graph from DSI node. Signed-off-by: Hoegeun Kwon Reviewed-by: Andrzej Hajda ---

[PATCH v3 4/7] arm: dts: Add the burst and esc clock frequency properties for exynos4210 dts

The OF graph is not needed because the panel is a child of dsi. So added the burst and esc clock frequency properties to the parent (DSI node), taking into account the bisectability problem so that remove the OF graph from DSI node. Signed-off-by: Hoegeun Kwon Reviewed-by: Andrzej Hajda ---

Re: [PATCH 0/4] Improve intel-hid's self-consistency

On Thu, Mar 2, 2017 at 7:03 AM, Andy Shevchenko wrote: > On Fri, Feb 24, 2017 at 12:33 PM, Michał Kępień wrote: >> Commit 2cfa4b311acc ("platform/x86: intel-hid: Support 5 button array") >> contains some coding style cleanups compared to the code it

Re: [PATCH 0/4] Improve intel-hid's self-consistency

On Thu, Mar 2, 2017 at 7:03 AM, Andy Shevchenko wrote: > On Fri, Feb 24, 2017 at 12:33 PM, Michał Kępień wrote: >> Commit 2cfa4b311acc ("platform/x86: intel-hid: Support 5 button array") >> contains some coding style cleanups compared to the code it was based >> on. This patch series

Re: [PATCH 2/2] vfio: type1: conditionally check MSI remapping at irq domain level

Hi, On 02/03/2017 11:01, Mian Yousaf Kaukab wrote: > Check only if irq domains are available. > > Signed-off-by: Mian Yousaf Kaukab > --- > drivers/vfio/vfio_iommu_type1.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git

Re: [PATCH 2/2] vfio: type1: conditionally check MSI remapping at irq domain level

Hi, On 02/03/2017 11:01, Mian Yousaf Kaukab wrote: > Check only if irq domains are available. > > Signed-off-by: Mian Yousaf Kaukab > --- > drivers/vfio/vfio_iommu_type1.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/vfio/vfio_iommu_type1.c

[PATCH v3 7/7] arm: dts: Remove the OF graph from DSI node

The OF graph is not needed because the panel is a child of dsi. So removed the ports node in DSI node, and port node in panel node. Signed-off-by: Hoegeun Kwon Reviewed-by: Andrzej Hajda --- arch/arm/boot/dts/exynos3250-rinato.dts | 21

[PATCH v3 7/7] arm: dts: Remove the OF graph from DSI node

The OF graph is not needed because the panel is a child of dsi. So removed the ports node in DSI node, and port node in panel node. Signed-off-by: Hoegeun Kwon Reviewed-by: Andrzej Hajda --- arch/arm/boot/dts/exynos3250-rinato.dts | 21 -

Re: [PATCH 1/2] irqdomain: add empty irq_domain_check_msi_remap

Hi Mian Yousaf, On 02/03/2017 11:01, Mian Yousaf Kaukab wrote: > Fix following build error for s390: > drivers/vfio/vfio_iommu_type1.c: In function 'vfio_iommu_type1_attach_group': > drivers/vfio/vfio_iommu_type1.c:1290:25: error: implicit declaration of > function 'irq_domain_check_msi_remap' >

Re: [PATCH 1/2] irqdomain: add empty irq_domain_check_msi_remap

Hi Mian Yousaf, On 02/03/2017 11:01, Mian Yousaf Kaukab wrote: > Fix following build error for s390: > drivers/vfio/vfio_iommu_type1.c: In function 'vfio_iommu_type1_attach_group': > drivers/vfio/vfio_iommu_type1.c:1290:25: error: implicit declaration of > function 'irq_domain_check_msi_remap' >

Re: [PATCH 2/2] vfio: type1: conditionally check MSI remapping at irq domain level

On 02/03/17 10:01, Mian Yousaf Kaukab wrote: > Check only if irq domains are available. > > Signed-off-by: Mian Yousaf Kaukab > --- > drivers/vfio/vfio_iommu_type1.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git

Re: [PATCH 2/2] vfio: type1: conditionally check MSI remapping at irq domain level

On 02/03/17 10:01, Mian Yousaf Kaukab wrote: > Check only if irq domains are available. > > Signed-off-by: Mian Yousaf Kaukab > --- > drivers/vfio/vfio_iommu_type1.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/vfio/vfio_iommu_type1.c

Re: [PATCH 1/2] irqdomain: add empty irq_domain_check_msi_remap

On 02/03/17 10:01, Mian Yousaf Kaukab wrote: > Fix following build error for s390: > drivers/vfio/vfio_iommu_type1.c: In function 'vfio_iommu_type1_attach_group': > drivers/vfio/vfio_iommu_type1.c:1290:25: error: implicit declaration of > function 'irq_domain_check_msi_remap' > > Signed-off-by:

Re: [PATCH 1/2] irqdomain: add empty irq_domain_check_msi_remap

On 02/03/17 10:01, Mian Yousaf Kaukab wrote: > Fix following build error for s390: > drivers/vfio/vfio_iommu_type1.c: In function 'vfio_iommu_type1_attach_group': > drivers/vfio/vfio_iommu_type1.c:1290:25: error: implicit declaration of > function 'irq_domain_check_msi_remap' > > Signed-off-by:

[PATCHv2] omap3isp: add support for CSI1 bus

Hi! > > > >> +++ b/drivers/media/platform/omap3isp/ispccp2.c > > > >> @@ -160,6 +163,33 @@ static int ccp2_if_enable(struct isp_ccp2_device > > > >> *ccp2, u8 enable) return ret; > > > >> > > > >>} > > > >> > > > >> + if (isp->revision == ISP_REVISION_2_0) { > > > > > > > > The

[PATCHv2] omap3isp: add support for CSI1 bus

Hi! > > > >> +++ b/drivers/media/platform/omap3isp/ispccp2.c > > > >> @@ -160,6 +163,33 @@ static int ccp2_if_enable(struct isp_ccp2_device > > > >> *ccp2, u8 enable) return ret; > > > >> > > > >>} > > > >> > > > >> + if (isp->revision == ISP_REVISION_2_0) { > > > > > > > > The

Re: [WIP BRANCH] cgroups support in bfq-mq WIP branch

> Il giorno 25 feb 2017, alle ore 19:52, Jens Axboe ha > scritto: > > On 02/25/2017 10:44 AM, Paolo Valente wrote: >> Hi, >> I've just completed cgroups support, and I'd like to highlight the >> main blk-mq issue that I have found along the way. I have pushed the >> commit

Re: [WIP BRANCH] cgroups support in bfq-mq WIP branch

> Il giorno 25 feb 2017, alle ore 19:52, Jens Axboe ha > scritto: > > On 02/25/2017 10:44 AM, Paolo Valente wrote: >> Hi, >> I've just completed cgroups support, and I'd like to highlight the >> main blk-mq issue that I have found along the way. I have pushed the >> commit that completes the

Re: boot failure, module: overflow in relocation

Nevermind, it got fixed now i think. On Thu, Mar 02, 2017 at 05:51:27PM +0800, Xiong Zhou wrote: > Hi, > > One host failed to boot while merge going on, > > [ 13.076303] module: overflow in relocation type 10 val a0060e58 > [ 13.076338] module: overflow in relocation type 10 val

Re: boot failure, module: overflow in relocation

Nevermind, it got fixed now i think. On Thu, Mar 02, 2017 at 05:51:27PM +0800, Xiong Zhou wrote: > Hi, > > One host failed to boot while merge going on, > > [ 13.076303] module: overflow in relocation type 10 val a0060e58 > [ 13.076338] module: overflow in relocation type 10 val

Re: [PATCH] usb: dwc3: ep0: Fix the possible missed request for handling delay STATUS phase

Hi, On 28 February 2017 at 06:11, Alan Stern wrote: > On Tue, 21 Feb 2017, Baolin Wang wrote: > >> On 17 February 2017 at 16:04, Felipe Balbi wrote: >> > >> > Hi, >> > >> > Baolin Wang writes: >> (One possible approach

Re: [PATCH] usb: dwc3: ep0: Fix the possible missed request for handling delay STATUS phase

Hi, On 28 February 2017 at 06:11, Alan Stern wrote: > On Tue, 21 Feb 2017, Baolin Wang wrote: > >> On 17 February 2017 at 16:04, Felipe Balbi wrote: >> > >> > Hi, >> > >> > Baolin Wang writes: >> (One possible approach would be to have the setup routine return >> different values for

[PATCH 3/6] staging: wlan-ng: Fix sparse warnings in hfa384x_usb.c

drivers/staging/wlan-ng/hfa384x_usb.c:3520:34: warning: incorrect type in assignment (different base types) drivers/staging/wlan-ng/hfa384x_usb.c:3520:34:expected unsigned int [unsigned] [usertype] datarate drivers/staging/wlan-ng/hfa384x_usb.c:3520:34:got restricted __be32 [usertype]

[PATCH 3/6] staging: wlan-ng: Fix sparse warnings in hfa384x_usb.c

drivers/staging/wlan-ng/hfa384x_usb.c:3520:34: warning: incorrect type in assignment (different base types) drivers/staging/wlan-ng/hfa384x_usb.c:3520:34:expected unsigned int [unsigned] [usertype] datarate drivers/staging/wlan-ng/hfa384x_usb.c:3520:34:got restricted __be32 [usertype]

Re: [PATCH v4 1/1] drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC

On Thu, Mar 02, 2017 at 08:12:02AM +0100, Daniel Vetter wrote: > On Tue, Feb 28, 2017 at 04:36:51PM +0100, Maxime Ripard wrote: > > Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic > > framebuffer emulation driver. Legacy framebuffer users like non kms/drm > > based

Re: [PATCH v4 1/1] drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC

On Thu, Mar 02, 2017 at 08:12:02AM +0100, Daniel Vetter wrote: > On Tue, Feb 28, 2017 at 04:36:51PM +0100, Maxime Ripard wrote: > > Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic > > framebuffer emulation driver. Legacy framebuffer users like non kms/drm > > based

Re: [PATCH v4 1/1] drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC

On Tue, Feb 28, 2017 at 04:36:51PM +0100, Maxime Ripard wrote: > Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic > framebuffer emulation driver. Legacy framebuffer users like non kms/drm > based OpenGL(ES)/EGL implementations may require the ioctl to > synchronize drawing or

Re: [PATCH v4 1/1] drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC

On Tue, Feb 28, 2017 at 04:36:51PM +0100, Maxime Ripard wrote: > Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic > framebuffer emulation driver. Legacy framebuffer users like non kms/drm > based OpenGL(ES)/EGL implementations may require the ioctl to > synchronize drawing or

Re: [GIT PULL] vfs patches for 4.11

On Thu, Mar 02, 2017 at 10:32:08AM +0200, Amir Goldstein wrote: > On Mon, Feb 20, 2017 at 7:17 PM, Al Viro wrote: > > On Mon, Feb 20, 2017 at 05:19:00PM +0100, Miklos Szeredi wrote: > >> Hi Al, > >> > >> Please pull from: > >> > >>

Re: [GIT PULL] vfs patches for 4.11

On Thu, Mar 02, 2017 at 10:32:08AM +0200, Amir Goldstein wrote: > On Mon, Feb 20, 2017 at 7:17 PM, Al Viro wrote: > > On Mon, Feb 20, 2017 at 05:19:00PM +0100, Miklos Szeredi wrote: > >> Hi Al, > >> > >> Please pull from: > >> > >> git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git

Re: [PATCH] [media] ad5820: remove incorrect __exit markups

On Wed 2017-03-01 15:41:23, Dmitry Torokhov wrote: > Even if bus is not hot-pluggable, devices can be unbound from the > driver via sysfs, so we should not be using __exit annotations on > remove() methods. The only exception is drivers registered with > platform_driver_probe() which specifically

Re: [PATCH] [media] ad5820: remove incorrect __exit markups

On Wed 2017-03-01 15:41:23, Dmitry Torokhov wrote: > Even if bus is not hot-pluggable, devices can be unbound from the > driver via sysfs, so we should not be using __exit annotations on > remove() methods. The only exception is drivers registered with > platform_driver_probe() which specifically

boot failure, module: overflow in relocation

Hi, One host failed to boot while merge going on, [ 13.076303] module: overflow in relocation type 10 val a0060e58 [ 13.076338] module: overflow in relocation type 10 val a01ac96b [ 13.076340] module: `scsi_transport_sas' likely not compiled with -mcmodel=kernel [

boot failure, module: overflow in relocation

Hi, One host failed to boot while merge going on, [ 13.076303] module: overflow in relocation type 10 val a0060e58 [ 13.076338] module: overflow in relocation type 10 val a01ac96b [ 13.076340] module: `scsi_transport_sas' likely not compiled with -mcmodel=kernel [

Re: [Outreachy kernel] [PATCH 1/6] staging: wlan-ng: Fix sparse warning of restricted __le16

On Thu, 2 Mar 2017, Julia Lawall wrote: > > > On Thu, 2 Mar 2017, simran singhal wrote: > > > This patch fixes the following sparse warning: > > warning: cast to restricted __le16 > > You commit message should not say just fix X. What have you done to carry > out the fix and why is this the

Re: [Outreachy kernel] [PATCH 1/6] staging: wlan-ng: Fix sparse warning of restricted __le16

On Thu, 2 Mar 2017, Julia Lawall wrote: > > > On Thu, 2 Mar 2017, simran singhal wrote: > > > This patch fixes the following sparse warning: > > warning: cast to restricted __le16 > > You commit message should not say just fix X. What have you done to carry > out the fix and why is this the

Re: [PATCH V2 3/4] drm/bridge: Drivers for megachips-stdpxxxx-ge-b850v3-fw (LVDS-DP++)

Hi Peter, On 3/1/2017 4:08 PM, Peter Senna Tschudin wrote: Hi Archit, Thank you for the review! On Wed, Mar 01, 2017 at 09:38:48AM +0530, Archit Taneja wrote: On 02/28/2017 07:58 PM, Peter Senna Tschudin wrote: The video processing pipeline on the second output on the GE B850v3: Host

Re: [PATCH V2 3/4] drm/bridge: Drivers for megachips-stdpxxxx-ge-b850v3-fw (LVDS-DP++)

Hi Peter, On 3/1/2017 4:08 PM, Peter Senna Tschudin wrote: Hi Archit, Thank you for the review! On Wed, Mar 01, 2017 at 09:38:48AM +0530, Archit Taneja wrote: On 02/28/2017 07:58 PM, Peter Senna Tschudin wrote: The video processing pipeline on the second output on the GE B850v3: Host

Re: net/ipv4: deadlock in ip_ra_control

On Wed, Mar 1, 2017 at 6:18 PM, Cong Wang wrote: > On Wed, Mar 1, 2017 at 2:44 AM, Dmitry Vyukov wrote: >> Hello, >> >> I've got the following deadlock report while running syzkaller fuzzer >> on linux-next/51788aebe7cae79cb334ad50641347465fc188fd:

Re: net/ipv4: deadlock in ip_ra_control

On Wed, Mar 1, 2017 at 6:18 PM, Cong Wang wrote: > On Wed, Mar 1, 2017 at 2:44 AM, Dmitry Vyukov wrote: >> Hello, >> >> I've got the following deadlock report while running syzkaller fuzzer >> on linux-next/51788aebe7cae79cb334ad50641347465fc188fd: >> >>

Re: [PATCH V11 10/10] arm/arm64: KVM: add guest SEA support

On 01/03/17 02:31, Xiongfeng Wang wrote: [lot of things] > If an SEA is injected into guest OS, the guest OS will jump to the SEA > exception entry when the context switched to guest OS. And the CPSR and > FAR_EL1 are recovered according to the content of vcpu. Then the guest > OS can signal a

Re: [PATCH V11 10/10] arm/arm64: KVM: add guest SEA support

On 01/03/17 02:31, Xiongfeng Wang wrote: [lot of things] > If an SEA is injected into guest OS, the guest OS will jump to the SEA > exception entry when the context switched to guest OS. And the CPSR and > FAR_EL1 are recovered according to the content of vcpu. Then the guest > OS can signal a

BUSINESS REQUEST………

Greetings, I am a banker with Bank of Africa (BOA) Ouagadougou Burkina Faso. I am in a better position to transfer about $22.3 million US Dollars into a foreign account. If you are willing and capable to work with me to receive this fund into a personal or company's account, I will give you

BUSINESS REQUEST………

Greetings, I am a banker with Bank of Africa (BOA) Ouagadougou Burkina Faso. I am in a better position to transfer about $22.3 million US Dollars into a foreign account. If you are willing and capable to work with me to receive this fund into a personal or company's account, I will give you

[PATCH 1/3] cpufreq: schedutil: move cached_raw_freq to struct sugov_policy

cached_raw_freq applies to the entire cpufreq policy and not individual CPUs. Apart from wasting per-cpu memory, it is actually wrong to keep it in struct sugov_cpu as we may end up comparing next_freq with a stale cached_raw_freq of a random CPU. Move cached_raw_freq to struct sugov_policy.

[PATCH 1/3] cpufreq: schedutil: move cached_raw_freq to struct sugov_policy

cached_raw_freq applies to the entire cpufreq policy and not individual CPUs. Apart from wasting per-cpu memory, it is actually wrong to keep it in struct sugov_cpu as we may end up comparing next_freq with a stale cached_raw_freq of a random CPU. Move cached_raw_freq to struct sugov_policy.

Re: [PATCH/RFC] arm64: pmu: add Qualcomm Technologies extensions

On 01/03/17 21:36, Leeder, Neil wrote: > Hi Mark, > Thanks for the quick response. > > On 3/1/2017 1:10 PM, Mark Rutland wrote: >> Hi Neil, >> >> On Wed, Mar 01, 2017 at 11:18:05AM -0500, Neil Leeder wrote: >>> Adds CPU PMU perf events support for Qualcomm Technologies' Falkor CPU. >>> >>> The

[PATCH] radix tree test suite: Fix build with --as-needed

Currently the radix tree test suite doesn't build with toolchains that use --as-needed by default, for example Ubuntu's: cc -I. -I../../include -g -O2 -Wall -D_LGPL_SOURCE -fsanitize=address -lpthread -lurcu main.o ... -o main /usr/bin/ld: regression1.o: undefined reference to symbol

[PATCH] radix tree test suite: Fix build with --as-needed

Currently the radix tree test suite doesn't build with toolchains that use --as-needed by default, for example Ubuntu's: cc -I. -I../../include -g -O2 -Wall -D_LGPL_SOURCE -fsanitize=address -lpthread -lurcu main.o ... -o main /usr/bin/ld: regression1.o: undefined reference to symbol

Re: [PATCH/RFC] arm64: pmu: add Qualcomm Technologies extensions

On 01/03/17 21:36, Leeder, Neil wrote: > Hi Mark, > Thanks for the quick response. > > On 3/1/2017 1:10 PM, Mark Rutland wrote: >> Hi Neil, >> >> On Wed, Mar 01, 2017 at 11:18:05AM -0500, Neil Leeder wrote: >>> Adds CPU PMU perf events support for Qualcomm Technologies' Falkor CPU. >>> >>> The

Re: mm allocation failure and hang when running xfstests generic/269 on xfs

On Thu, Mar 02, 2017 at 09:42:23AM +0100, Michal Hocko wrote: > On Thu 02-03-17 12:17:47, Anshuman Khandual wrote: > > On 03/02/2017 10:49 AM, Xiong Zhou wrote: > > > On Wed, Mar 01, 2017 at 04:37:31PM -0800, Christoph Hellwig wrote: > > >> On Wed, Mar 01, 2017 at 12:46:34PM +0800, Xiong Zhou

Re: mm allocation failure and hang when running xfstests generic/269 on xfs

On Thu, Mar 02, 2017 at 09:42:23AM +0100, Michal Hocko wrote: > On Thu 02-03-17 12:17:47, Anshuman Khandual wrote: > > On 03/02/2017 10:49 AM, Xiong Zhou wrote: > > > On Wed, Mar 01, 2017 at 04:37:31PM -0800, Christoph Hellwig wrote: > > >> On Wed, Mar 01, 2017 at 12:46:34PM +0800, Xiong Zhou

Re: [PATCH] tpm: select CONFIG_CRYPTO

On Tue, Feb 28, 2017 at 10:24:45PM +0100, Peter Huewe wrote: > > > Am 28. Februar 2017 22:12:55 MEZ schrieb Arnd Bergmann : > >We get a newly introduced harmless warning when CONFIG_CRYPTO is > >disabled: > > > >warning: (TCG_TPM && TRUSTED_KEYS && IMA) selects CRYPTO_HASH_INFO >

Re: [PATCH] tpm: select CONFIG_CRYPTO

On Tue, Feb 28, 2017 at 10:24:45PM +0100, Peter Huewe wrote: > > > Am 28. Februar 2017 22:12:55 MEZ schrieb Arnd Bergmann : > >We get a newly introduced harmless warning when CONFIG_CRYPTO is > >disabled: > > > >warning: (TCG_TPM && TRUSTED_KEYS && IMA) selects CRYPTO_HASH_INFO > >which has

pull-request: wireless-drivers 2017-03-02

Hi Dave, only one patch this time, the new version of ath10k patch we reverted earlier. I was supposed to send you this earlier but it got delayed because I'm on vacation, so sorry about that. I'm hoping this is ok to take also even the merge window is closed as the changes to the first version

pull-request: wireless-drivers 2017-03-02

Hi Dave, only one patch this time, the new version of ath10k patch we reverted earlier. I was supposed to send you this earlier but it got delayed because I'm on vacation, so sorry about that. I'm hoping this is ok to take also even the merge window is closed as the changes to the first version

Re: [PATCH v2 1/5] pinctrl: sunxi: refactor pinctrl choice selecting for ARM64

On Thu, Mar 02, 2017 at 02:01:07AM +0800, Icenowy Zheng wrote: > ARM64 Allwinner SoCs used to have every pinctrl driver selected in > ARCH_SUNXI. Change this to make their default value to (ARM64 && > ARCH_SUNXI). > > Signed-off-by: Icenowy Zheng > Reviewed-by: Andre Przywara

Re: [PATCH v2 1/5] pinctrl: sunxi: refactor pinctrl choice selecting for ARM64

On Thu, Mar 02, 2017 at 02:01:07AM +0800, Icenowy Zheng wrote: > ARM64 Allwinner SoCs used to have every pinctrl driver selected in > ARCH_SUNXI. Change this to make their default value to (ARM64 && > ARCH_SUNXI). > > Signed-off-by: Icenowy Zheng > Reviewed-by: Andre Przywara Acked-by: Maxime

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

On 01/03/2017 17:55, Boris Brezillon wrote: > On Wed, 1 Mar 2017 17:16:30 +0530 > Vignesh R wrote: > >> 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

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

On 01/03/2017 17:55, Boris Brezillon wrote: > On Wed, 1 Mar 2017 17:16:30 +0530 > Vignesh R wrote: > >> 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: >

subdevice config into pointer (was Re: [PATCH 1/4] v4l2: device_register_subdev_nodes: allow calling multiple times)

Hi! > Making the sub-device bus configuration a pointer should be in a separate > patch. It makes sense since the entire configuration is not valid for all > sub-devices attached to the ISP anymore. I think it originally was a > separate patch, but they probably have been merged at some point. I

subdevice config into pointer (was Re: [PATCH 1/4] v4l2: device_register_subdev_nodes: allow calling multiple times)

Hi! > Making the sub-device bus configuration a pointer should be in a separate > patch. It makes sense since the entire configuration is not valid for all > sub-devices attached to the ISP anymore. I think it originally was a > separate patch, but they probably have been merged at some point. I

Re: [PATCH] omap3isp: add support for CSI1 bus

Hi! > > >> + > > >> +static int isp_of_parse_node_endpoint(struct device *dev, > > >> + struct device_node *node, > > >> + struct isp_async_subdev *isd) > > >> +{ > > >> +struct isp_bus_cfg *buscfg; > > >> +

Re: [PATCH] omap3isp: add support for CSI1 bus

Hi! > > >> + > > >> +static int isp_of_parse_node_endpoint(struct device *dev, > > >> + struct device_node *node, > > >> + struct isp_async_subdev *isd) > > >> +{ > > >> +struct isp_bus_cfg *buscfg; > > >> +

Re: [PATCH] devicetree: Add video bus switch

On Mon 2017-02-13 12:20:35, Sakari Ailus wrote: > Hi Pavel, > > On Mon, Feb 13, 2017 at 10:54:20AM +0100, Pavel Machek wrote: > > Hi! > > > > > > Take a look at the wikipedia. If you do "one at a time" at 100Hz, you > > > > can claim it is time-domain multiplex. But we are plain switching the >

Re: [PATCH] devicetree: Add video bus switch

On Mon 2017-02-13 12:20:35, Sakari Ailus wrote: > Hi Pavel, > > On Mon, Feb 13, 2017 at 10:54:20AM +0100, Pavel Machek wrote: > > Hi! > > > > > > Take a look at the wikipedia. If you do "one at a time" at 100Hz, you > > > > can claim it is time-domain multiplex. But we are plain switching the >

[PATCH resend] timers, sched_clock: Update timeout for clock wrap

The scheduler clock framework may not use the correct timeout for the clock wrap. This happens when a new clock driver calls sched_clock_register() after the kernel called sched_clock_postinit(). In this case the clock wrap timeout is too long thus sched_clock_poll() is called too late and the

[PATCH resend] timers, sched_clock: Update timeout for clock wrap

The scheduler clock framework may not use the correct timeout for the clock wrap. This happens when a new clock driver calls sched_clock_register() after the kernel called sched_clock_postinit(). In this case the clock wrap timeout is too long thus sched_clock_poll() is called too late and the

Re: [PATCH fixes v3] pinctrl: Really force states during suspend/resume

On Wed, Mar 1, 2017 at 8:32 PM, Florian Fainelli wrote: > In case a platform only defaults a "default" set of pins, but not a > "sleep" set of pins, and this particular platform suspends and resumes > in a way that the pin states are not preserved by the hardware, when we >

Re: [PATCH fixes v3] pinctrl: Really force states during suspend/resume

On Wed, Mar 1, 2017 at 8:32 PM, Florian Fainelli wrote: > In case a platform only defaults a "default" set of pins, but not a > "sleep" set of pins, and this particular platform suspends and resumes > in a way that the pin states are not preserved by the hardware, when we > resume, we would call

Re: [PATCH v2 1/2] pinctrl: rockchip：Add input schmitt support

Hi David, On 03/02/2017 03:11 PM, David Wu wrote: From: "david.wu" You do not need to add this when you send mail for yourself, it's need when you send mail for others. To prevent external signal crosstalk, some pins need to enable input schmitt, like i2c pins,

Re: [PATCH v2 3/5] dt-bindings: fix for Allwinner H5 pinctrl's compatible

On Thu, Mar 02, 2017 at 02:01:09AM +0800, Icenowy Zheng wrote: > The compatible for Allwinner H5 pin controller is wrong written as > allwinner,sun50i-h5-r-pinctrl, however, it's really a generic pinctrl > rather than a "r" one. > > Fix this compatible string. > > Signed-off-by: Icenowy Zheng

Re: [PATCH v2 1/2] pinctrl: rockchip：Add input schmitt support

Hi David, On 03/02/2017 03:11 PM, David Wu wrote: From: "david.wu" You do not need to add this when you send mail for yourself, it's need when you send mail for others. To prevent external signal crosstalk, some pins need to enable input schmitt, like i2c pins, 32k-input pin and so on.

Re: [PATCH v2 3/5] dt-bindings: fix for Allwinner H5 pinctrl's compatible

On Thu, Mar 02, 2017 at 02:01:09AM +0800, Icenowy Zheng wrote: > The compatible for Allwinner H5 pin controller is wrong written as > allwinner,sun50i-h5-r-pinctrl, however, it's really a generic pinctrl > rather than a "r" one. > > Fix this compatible string. > > Signed-off-by: Icenowy Zheng

Re: [PATCH 2/2 RESEND] drm/vc4: Fix OOPSes from trying to cache a partially constructed BO.

On Wed, 1 Mar 2017 10:56:02 -0800 Eric Anholt wrote: > If a CMA allocation failed, the partially constructed BO would be > unreferenced through the normal path, and we might choose to put it in > the BO cache. If we then reused it before it expired from the cache, > the kernel

Re: [PATCH 2/2 RESEND] drm/vc4: Fix OOPSes from trying to cache a partially constructed BO.

On Wed, 1 Mar 2017 10:56:02 -0800 Eric Anholt wrote: > If a CMA allocation failed, the partially constructed BO would be > unreferenced through the normal path, and we might choose to put it in > the BO cache. If we then reused it before it expired from the cache, > the kernel would OOPS. > >

[PATCH V3 0/4] Add Spreadtrum SP9860G support

SC9860 is a Spreadtrum SoC with eight Cortex A53, which are divided into 4 Big cores and 4 little cores. This patch-set provides a basic configuration for SC9860 in device tree to make it run to console. After this we will continue to submit other device drivers step by step, which are using on

[PATCH V3 0/4] Add Spreadtrum SP9860G support

SC9860 is a Spreadtrum SoC with eight Cortex A53, which are divided into 4 Big cores and 4 little cores. This patch-set provides a basic configuration for SC9860 in device tree to make it run to console. After this we will continue to submit other device drivers step by step, which are using on

RE: [PATCH 3/3] PCI: Xilinx NWL PCIe: Fix Error for multi function device for legacy interrupts.

Hi, Any one is working on fix for this issue ? Regards, Bharat > -Original Message- > From: Bjorn Helgaas [mailto:helg...@kernel.org] > Sent: Tuesday, September 13, 2016 8:35 PM > To: Marc Zyngier > Cc: Bharat Kumar Gogada ; r...@kernel.org;

RE: [PATCH 3/3] PCI: Xilinx NWL PCIe: Fix Error for multi function device for legacy interrupts.

Hi, Any one is working on fix for this issue ? Regards, Bharat > -Original Message- > From: Bjorn Helgaas [mailto:helg...@kernel.org] > Sent: Tuesday, September 13, 2016 8:35 PM > To: Marc Zyngier > Cc: Bharat Kumar Gogada ; r...@kernel.org; > bhelg...@google.com;

Re: [PATCH 1/2 RESEND] drm/vc4: Fulfill user BO creation requests from the kernel BO cache.

On Wed, 1 Mar 2017 10:56:01 -0800 Eric Anholt wrote: > The from_cache flag was actually "the BO is invisible to userspace", > so we can repurpose it to just zero out a cached BO and return it to > userspace. > > Improves wall time for a loop of 5 glsl-algebraic-add-add-1 by >

Re: [PATCH 1/2 RESEND] drm/vc4: Fulfill user BO creation requests from the kernel BO cache.

On Wed, 1 Mar 2017 10:56:01 -0800 Eric Anholt wrote: > The from_cache flag was actually "the BO is invisible to userspace", > so we can repurpose it to just zero out a cached BO and return it to > userspace. > > Improves wall time for a loop of 5 glsl-algebraic-add-add-1 by > -1.44989% +/-

[PATCH] Revert "usb: gadget: uvc: Add missing call for additional setup data"

This reverts commit 4fbac5206afd01b717d4bdc58793d471f3391b4b. This commit breaks g_webcam when used with uvc-gadget [1]. The user space application (e.g. uvc-gadget) is responsible for sending response to UVC class specific requests on control endpoint in uvc_send_response() in uvc_v4l2.c. The

[PATCH] Revert "usb: gadget: uvc: Add missing call for additional setup data"

This reverts commit 4fbac5206afd01b717d4bdc58793d471f3391b4b. This commit breaks g_webcam when used with uvc-gadget [1]. The user space application (e.g. uvc-gadget) is responsible for sending response to UVC class specific requests on control endpoint in uvc_send_response() in uvc_v4l2.c. The

Re: [PATCH] ARM: dump: Add domain to output

On Wed, Mar 1, 2017 at 11:55 PM, Kees Cook wrote: > This adds the memory domain (on non-LPAE) to the PMD and PTE dumps. This > isn't in the regular PMD bits because I couldn't find a clean way to > fall back to retain some of the PMD bits when reporting PTE. So this is >

Re: [PATCH] ARM: dump: Add domain to output

On Wed, Mar 1, 2017 at 11:55 PM, Kees Cook wrote: > This adds the memory domain (on non-LPAE) to the PMD and PTE dumps. This > isn't in the regular PMD bits because I couldn't find a clean way to > fall back to retain some of the PMD bits when reporting PTE. So this is > special-cased currently.

[PATCH v2] staging: speakup: Comparison to NULL could be written

Fixed coding style for null comparisons in speakup driver to be more consistant with the rest of the kernel coding style. Signed-off-by: Arushi Singhal --- changes in v2 - fixed coding style error and upto the coding style. drivers/staging/speakup/fakekey.c

Re: mm allocation failure and hang when running xfstests generic/269 on xfs

On Thu 02-03-17 12:17:47, Anshuman Khandual wrote: > On 03/02/2017 10:49 AM, Xiong Zhou wrote: > > On Wed, Mar 01, 2017 at 04:37:31PM -0800, Christoph Hellwig wrote: > >> On Wed, Mar 01, 2017 at 12:46:34PM +0800, Xiong Zhou wrote: > >>> Hi, > >>> > >>> It's reproduciable, not everytime though.

<    12   13   14   15   16   17   18   >