[PATCH v2] usb: dwc3: gadget: Wait for end transfer complete before free irq

When we change the USB function with configfs frequently, sometimes it will hang the system to crash. The reason is the gadget driver can not hanle the end transfer complete event after free the gadget irq (since the xHCI will share the same interrupt number with gadget, thus when free the gadget

[PATCH v2] usb: dwc3: gadget: Wait for end transfer complete before free irq

When we change the USB function with configfs frequently, sometimes it will hang the system to crash. The reason is the gadget driver can not hanle the end transfer complete event after free the gadget irq (since the xHCI will share the same interrupt number with gadget, thus when free the gadget

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

>>> On 12.10.16 at 12:33, wrote: > The layout is shown as the following diagram. > > +---+---+---+--+--+ > | whatever used | Partition | Super | Reserved | /dev/pmem0p1 | > | by kernel| Table | Block | for Xen |

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

>>> On 12.10.16 at 12:33, wrote: > The layout is shown as the following diagram. > > +---+---+---+--+--+ > | whatever used | Partition | Super | Reserved | /dev/pmem0p1 | > | by kernel| Table | Block | for Xen | | >

[PATCH v2] f2fs: split free nid list

During free nid allocation, in order to do preallocation, we will tag free nid entry as allocated one and still leave it in free nid list, for other allocators who want to grab free nids, it needs to traverse the free nid list for lookup. It becomes overhead in scenario of allocating free nid

[PATCH v2] f2fs: split free nid list

During free nid allocation, in order to do preallocation, we will tag free nid entry as allocated one and still leave it in free nid list, for other allocators who want to grab free nids, it needs to traverse the free nid list for lookup. It becomes overhead in scenario of allocating free nid

Re: [PATCH]"drm: change DRM_MIPI_DSI module type from "bool" to "tristate".

On 11 October 2016 at 10:33, Jani Nikula wrote: > On Tue, 11 Oct 2016, "Sun, Jing A" wrote: >> It's needed that DRM Driver module could be removed and reloaded after >> kernel booting on the projects that I have been working on, and I hope >>

Re: [PATCH]"drm: change DRM_MIPI_DSI module type from "bool" to "tristate".

On 11 October 2016 at 10:33, Jani Nikula wrote: > On Tue, 11 Oct 2016, "Sun, Jing A" wrote: >> It's needed that DRM Driver module could be removed and reloaded after >> kernel booting on the projects that I have been working on, and I hope >> such module type change could be accepted. Looks like

Re: [PATCH 0/2] ARM: at91: properly handle LPDDR poweroff

On 10/10/2016 at 08:00:30 +0200, Alexander Stein wrote : > Hi Alexandre, > > On Friday 07 October 2016 18:34:25, Alexandre Belloni wrote: > > Hi, > > > > This patch set improves LPDDR support on SoCs using the Atmel MPDDR > > controller. > > > > LPDDR memoris can only handle up to 400

Re: [PATCH 0/2] ARM: at91: properly handle LPDDR poweroff

On 10/10/2016 at 08:00:30 +0200, Alexander Stein wrote : > Hi Alexandre, > > On Friday 07 October 2016 18:34:25, Alexandre Belloni wrote: > > Hi, > > > > This patch set improves LPDDR support on SoCs using the Atmel MPDDR > > controller. > > > > LPDDR memoris can only handle up to 400

Re: [PATCH v3 4/4] MIPS: Deprecate VPE Loader

This interface is currently used by the Intel / Lantiq voice Firmware. This firmware is used by all Intel / Lantiq MIPS SoCs when they should support analog voice. What is the proposed timeline for the removal of this interface? Hauke On 10/11/2016 03:42 PM, Matt Redfearn wrote: > The MIPS

Re: [PATCH v3 4/4] MIPS: Deprecate VPE Loader

This interface is currently used by the Intel / Lantiq voice Firmware. This firmware is used by all Intel / Lantiq MIPS SoCs when they should support analog voice. What is the proposed timeline for the removal of this interface? Hauke On 10/11/2016 03:42 PM, Matt Redfearn wrote: > The MIPS

Re: [PATCH 3/4] arm64: Allow hw watchpoint of length 3,5,6 and 7

On Wed, Oct 12, 2016 at 6:58 AM, Pratyush Anand wrote: > Since, arm64 can support all offset within a double word limit. Therefore, > now support other lengths within that range as well. How does ptracer (like GDB) detect kernel has already supported all byte address select

Re: [PATCH 3/4] arm64: Allow hw watchpoint of length 3,5,6 and 7

On Wed, Oct 12, 2016 at 6:58 AM, Pratyush Anand wrote: > Since, arm64 can support all offset within a double word limit. Therefore, > now support other lengths within that range as well. How does ptracer (like GDB) detect kernel has already supported all byte address select values? I suppose

[PATCH] acpi: don't register acpi_pad driver if running as xen dom0

When running as Xen dom0 a special processor_aggregator driver is needed. Don't register the standard driver in this case. Without that check an error message: "Error: Driver 'processor_aggregator' is already registered, aborting..." will be displayed. Signed-off-by: Juergen Gross

Re: [PATCH 1/7 v4] sched: factorize attach entity

On 12/10/16 11:59, Vincent Guittot wrote: > On 7 October 2016 at 01:11, Vincent Guittot > wrote: >> >> On 5 October 2016 at 11:38, Dietmar Eggemann >> wrote: >>> On 09/26/2016 01:19 PM, Vincent Guittot wrote: [...] -static void

[PATCH] acpi: don't register acpi_pad driver if running as xen dom0

When running as Xen dom0 a special processor_aggregator driver is needed. Don't register the standard driver in this case. Without that check an error message: "Error: Driver 'processor_aggregator' is already registered, aborting..." will be displayed. Signed-off-by: Juergen Gross ---

Re: [PATCH 1/7 v4] sched: factorize attach entity

On 12/10/16 11:59, Vincent Guittot wrote: > On 7 October 2016 at 01:11, Vincent Guittot > wrote: >> >> On 5 October 2016 at 11:38, Dietmar Eggemann >> wrote: >>> On 09/26/2016 01:19 PM, Vincent Guittot wrote: [...] -static void attach_task_cfs_rq(struct task_struct *p) +static void

Re: [PATCH RESEND] ARM: dts: keystone-k2*: Increase SPI Flash partition size for U-Boot

Hi, On Monday 10 October 2016 09:31 PM, Santosh Shilimkar wrote: > Vignesh, > > On 10/10/2016 7:31 AM, Russell King - ARM Linux wrote: >> On Mon, Oct 10, 2016 at 07:41:41PM +0530, Vignesh R wrote: >>> U-Boot SPI Boot image is now more than 512KB for Keystone2 devices and >>> cannot fit into

Re: [PATCH RESEND] ARM: dts: keystone-k2*: Increase SPI Flash partition size for U-Boot

Hi, On Monday 10 October 2016 09:31 PM, Santosh Shilimkar wrote: > Vignesh, > > On 10/10/2016 7:31 AM, Russell King - ARM Linux wrote: >> On Mon, Oct 10, 2016 at 07:41:41PM +0530, Vignesh R wrote: >>> U-Boot SPI Boot image is now more than 512KB for Keystone2 devices and >>> cannot fit into

Re: [Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)

On ke, 2016-10-12 at 11:56 +0200, Paul Bolle wrote: > On a laptop that tracks the latest stable release (Ie, it now runs > v4.8.1) I see this WARNING >     WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock) > > Full trace pasted below. I never saw this WARNING before v4.8. Since > v4.8 I've had it

Re: [Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)

On ke, 2016-10-12 at 11:56 +0200, Paul Bolle wrote: > On a laptop that tracks the latest stable release (Ie, it now runs > v4.8.1) I see this WARNING >     WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock) > > Full trace pasted below. I never saw this WARNING before v4.8. Since > v4.8 I've had it

Re: [PATCH] x86/apic: Fix suspicious RCU usage in smp_trace_call_function_interrupt

2016-09-19 16:10 GMT+08:00 Peter Zijlstra : > On Thu, Sep 15, 2016 at 10:58:04AM +0200, Thomas Gleixner wrote: >> On Thu, 15 Sep 2016, Wanpeng Li wrote: >> > --- >> > arch/x86/include/asm/apic.h | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > diff --git

Re: [PATCH] x86/apic: Fix suspicious RCU usage in smp_trace_call_function_interrupt

2016-09-19 16:10 GMT+08:00 Peter Zijlstra : > On Thu, Sep 15, 2016 at 10:58:04AM +0200, Thomas Gleixner wrote: >> On Thu, 15 Sep 2016, Wanpeng Li wrote: >> > --- >> > arch/x86/include/asm/apic.h | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > diff --git

Re: MPOL_BIND on memory only nodes

On Wed 12-10-16 16:08:48, Anshuman Khandual wrote: > On 10/12/2016 03:13 PM, Michal Hocko wrote: > > On Wed 12-10-16 14:55:24, Anshuman Khandual wrote: > >> Hi, > >> > >> We have the following function policy_zonelist() which selects a zonelist > >> during various allocation paths. With this,

Re: [PATCH RESEND] ARM: dts: keystone-k2*: Increase SPI Flash partition size for U-Boot

Hi, On Monday 10 October 2016 08:01 PM, Russell King - ARM Linux wrote: > On Mon, Oct 10, 2016 at 07:41:41PM +0530, Vignesh R wrote: >> U-Boot SPI Boot image is now more than 512KB for Keystone2 devices and >> cannot fit into existing partition. So, increase the SPI Flash partition >> for U-Boot

Re: MPOL_BIND on memory only nodes

On Wed 12-10-16 16:08:48, Anshuman Khandual wrote: > On 10/12/2016 03:13 PM, Michal Hocko wrote: > > On Wed 12-10-16 14:55:24, Anshuman Khandual wrote: > >> Hi, > >> > >> We have the following function policy_zonelist() which selects a zonelist > >> during various allocation paths. With this,

Re: [PATCH RESEND] ARM: dts: keystone-k2*: Increase SPI Flash partition size for U-Boot

Hi, On Monday 10 October 2016 08:01 PM, Russell King - ARM Linux wrote: > On Mon, Oct 10, 2016 at 07:41:41PM +0530, Vignesh R wrote: >> U-Boot SPI Boot image is now more than 512KB for Keystone2 devices and >> cannot fit into existing partition. So, increase the SPI Flash partition >> for U-Boot

Re: [PATCH 1/7 v4] sched: factorize attach entity

On 7 October 2016 at 01:11, Vincent Guittot wrote: > > On 5 October 2016 at 11:38, Dietmar Eggemann wrote: > > On 09/26/2016 01:19 PM, Vincent Guittot wrote: > >> > >> Factorize post_init_entity_util_avg and part of attach_task_cfs_rq > >> in

Re: [PATCH 1/7 v4] sched: factorize attach entity

On 7 October 2016 at 01:11, Vincent Guittot wrote: > > On 5 October 2016 at 11:38, Dietmar Eggemann wrote: > > On 09/26/2016 01:19 PM, Vincent Guittot wrote: > >> > >> Factorize post_init_entity_util_avg and part of attach_task_cfs_rq > >> in one function attach_entity_cfs_rq > >> > >>

RE: [PATCH]"drm: change DRM_MIPI_DSI module type from "bool" to "tristate".

On Wed, 12 Oct 2016, "Sun, Jing A" wrote: > I think "installing a kernel with my changes for both drm and i915" > takes more time and effort to complete than "only updating DRM/i915 > modules without rebuilding the whole kernel". In some cases, that's > beneficial. It's

RE: [PATCH]"drm: change DRM_MIPI_DSI module type from "bool" to "tristate".

On Wed, 12 Oct 2016, "Sun, Jing A" wrote: > I think "installing a kernel with my changes for both drm and i915" > takes more time and effort to complete than "only updating DRM/i915 > modules without rebuilding the whole kernel". In some cases, that's > beneficial. It's possible to change and

Re: [PATCH] mm: kmemleak: Ensure that the task stack is not freed during scanning

On Wed, Oct 12, 2016 at 06:16:46PM +0800, Hillf Danton wrote: > > @@ -1453,8 +1453,11 @@ static void kmemleak_scan(void) > > > > read_lock(_lock); > > do_each_thread(g, p) { > > Take a look at this commit please. > 1da4db0cd5 ("oom_kill: change oom_kill.c to use

Re: [PATCH] mm: kmemleak: Ensure that the task stack is not freed during scanning

On Wed, Oct 12, 2016 at 06:16:46PM +0800, Hillf Danton wrote: > > @@ -1453,8 +1453,11 @@ static void kmemleak_scan(void) > > > > read_lock(_lock); > > do_each_thread(g, p) { > > Take a look at this commit please. > 1da4db0cd5 ("oom_kill: change oom_kill.c to use

Re: [PATCH] ext4: super.c: Update logging style using PR_CONT

On Tue 11-10-16 18:57:58, Joe Perches wrote: > Recent commit require line continuing printks to use PR_CONT. > > Update super.c to use PR_CONT and use vsprintf extension %pV > to avoid a printk/vprintk/printk("\n") sequence as well. Looks good. You can add: Reviewed-by: Jan Kara

Re: [PATCH] ext4: super.c: Update logging style using PR_CONT

On Tue 11-10-16 18:57:58, Joe Perches wrote: > Recent commit require line continuing printks to use PR_CONT. > > Update super.c to use PR_CONT and use vsprintf extension %pV > to avoid a printk/vprintk/printk("\n") sequence as well. Looks good. You can add: Reviewed-by: Jan Kara

Re: [PATCH] mm: kmemleak: Ensure that the task stack is not freed during scanning

On Wed 12-10-16 10:57:03, Catalin Marinas wrote: > Commit 68f24b08ee89 ("sched/core: Free the stack early if > CONFIG_THREAD_INFO_IN_TASK") may cause the task->stack to be freed > during kmemleak_scan() execution, leading to either a NULL pointer > fault (if task->stack is NULL) or kmemleak

Re: [PATCH] mm: kmemleak: Ensure that the task stack is not freed during scanning

On Wed 12-10-16 10:57:03, Catalin Marinas wrote: > Commit 68f24b08ee89 ("sched/core: Free the stack early if > CONFIG_THREAD_INFO_IN_TASK") may cause the task->stack to be freed > during kmemleak_scan() execution, leading to either a NULL pointer > fault (if task->stack is NULL) or kmemleak

Re: MPOL_BIND on memory only nodes

On 10/12/2016 03:13 PM, Michal Hocko wrote: > On Wed 12-10-16 14:55:24, Anshuman Khandual wrote: >> Hi, >> >> We have the following function policy_zonelist() which selects a zonelist >> during various allocation paths. With this, general user space allocations >> (IIUC might not have

Re: MPOL_BIND on memory only nodes

On 10/12/2016 03:13 PM, Michal Hocko wrote: > On Wed 12-10-16 14:55:24, Anshuman Khandual wrote: >> Hi, >> >> We have the following function policy_zonelist() which selects a zonelist >> during various allocation paths. With this, general user space allocations >> (IIUC might not have

Re: [PATCH] mm: page_alloc: Use KERN_CONT where appropriate

(resending as lkml bounced) On Wed, 2016-10-12 at 11:10 +0200, Michal Hocko wrote: > On Tue 11-10-16 19:24:55, Joe Perches wrote: > > Recent changes to printk require KERN_CONT uses to continue logging > > messages. So add KERN_CONT where necessary. > > > > I was really wondering what

Re: [PATCH] mm: page_alloc: Use KERN_CONT where appropriate

(resending as lkml bounced) On Wed, 2016-10-12 at 11:10 +0200, Michal Hocko wrote: > On Tue 11-10-16 19:24:55, Joe Perches wrote: > > Recent changes to printk require KERN_CONT uses to continue logging > > messages. So add KERN_CONT where necessary. > > > > I was really wondering what

Re: [PATCH v1 2/4] Add enabling of the R3 MWAIT during boot for KNL

On Wed, Oct 12, 2016 at 12:13:08PM +0200, Grzegorz Andrejczuk wrote: > If processor is Intel Xeon Phi we enable user-level mwait feature. > Enabling this feature suppreses invalid-opcode error, when MONITOR/MWAIT > is called from ring 3. > > Change-Id: I1c7defb99296b022790a068a6c725b3e860cd68c >

Re: [PATCH v1 2/4] Add enabling of the R3 MWAIT during boot for KNL

On Wed, Oct 12, 2016 at 12:13:08PM +0200, Grzegorz Andrejczuk wrote: > If processor is Intel Xeon Phi we enable user-level mwait feature. > Enabling this feature suppreses invalid-opcode error, when MONITOR/MWAIT > is called from ring 3. > > Change-Id: I1c7defb99296b022790a068a6c725b3e860cd68c >

[PATCH] qede: fix CONFIG_INFINIBAND_QEDR=m build error

The newly introduced INFINIBAND_QEDR option is 'tristate' but fails to build when set to 'm': drivers/net/built-in.o: In function `qed_hw_init': (.text+0x1c0e17): undefined reference to `qed_rdma_dpm_bar' drivers/net/built-in.o: In function `qed_eq_completion': (.text+0x1d185b): undefined

[PATCH] qede: fix CONFIG_INFINIBAND_QEDR=m build error

The newly introduced INFINIBAND_QEDR option is 'tristate' but fails to build when set to 'm': drivers/net/built-in.o: In function `qed_hw_init': (.text+0x1c0e17): undefined reference to `qed_rdma_dpm_bar' drivers/net/built-in.o: In function `qed_eq_completion': (.text+0x1d185b): undefined

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

On 10/11/16 13:17 -0700, Dan Williams wrote: On Tue, Oct 11, 2016 at 12:48 PM, Konrad Rzeszutek Wilk wrote: On Tue, Oct 11, 2016 at 12:28:56PM -0700, Dan Williams wrote: On Tue, Oct 11, 2016 at 11:33 AM, Konrad Rzeszutek Wilk wrote: > On Tue,

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

On 10/11/16 13:17 -0700, Dan Williams wrote: On Tue, Oct 11, 2016 at 12:48 PM, Konrad Rzeszutek Wilk wrote: On Tue, Oct 11, 2016 at 12:28:56PM -0700, Dan Williams wrote: On Tue, Oct 11, 2016 at 11:33 AM, Konrad Rzeszutek Wilk wrote: > On Tue, Oct 11, 2016 at 10:51:19AM -0700, Dan Williams

Re: [PATCH v8 3/6] x86/intel-ivi: Add Intel In-Vehicle Infotainment (IVI) systems used in cars support

On Wed, 2016-10-12 at 14:51 +0800, Tan Jui Nee wrote: > Add support for non ACPI system, such as system that uses Advanced > Boot > Loader (ABL) whereby a platform device has to be created in order to > bind > with PINCTRL/GPIO. > > At the moment, Intel Apollo Lake SoC requires P2SB driver to

Re: [PATCH v8 3/6] x86/intel-ivi: Add Intel In-Vehicle Infotainment (IVI) systems used in cars support

On Wed, 2016-10-12 at 14:51 +0800, Tan Jui Nee wrote: > Add support for non ACPI system, such as system that uses Advanced > Boot > Loader (ABL) whereby a platform device has to be created in order to > bind > with PINCTRL/GPIO. > > At the moment, Intel Apollo Lake SoC requires P2SB driver to

Re: [PATCH v1 4/4] Add R3MWAIT to CPU features

On Wed, Oct 12, 2016 at 12:13:10PM +0200, Grzegorz Andrejczuk wrote: > Add cpu feature for ring 3 monitor/mwait. > > Change-Id: Iba4d20639efd8d3637d37db9294cbc43a98f009a Please no internal IDs in upstream submission. > Signed-off-by: Grzegorz Andrejczuk ... >

Re: [PATCH v1 4/4] Add R3MWAIT to CPU features

On Wed, Oct 12, 2016 at 12:13:10PM +0200, Grzegorz Andrejczuk wrote: > Add cpu feature for ring 3 monitor/mwait. > > Change-Id: Iba4d20639efd8d3637d37db9294cbc43a98f009a Please no internal IDs in upstream submission. > Signed-off-by: Grzegorz Andrejczuk ... > diff --git

Re: [PATCH v7 2/8] power: add power sequence library

Hi, Am Dienstag, 20. September 2016, 11:36:41 CEST schrieb Peter Chen: > We have an well-known problem that the device needs to do some power > sequence before it can be recognized by related host, the typical > example like hard-wired mmc devices and usb devices. > > This power sequence is hard

Re: [PATCH v7 2/8] power: add power sequence library

Hi, Am Dienstag, 20. September 2016, 11:36:41 CEST schrieb Peter Chen: > We have an well-known problem that the device needs to do some power > sequence before it can be recognized by related host, the typical > example like hard-wired mmc devices and usb devices. > > This power sequence is hard

[PATCH 3/4] Add hwcap2 for x86

Add hwcap2 attribute for x86. Reserve 1st bit of HWCAP2 for exposing Xeon Phi ring 3 monitor/mwait. With this userspace apps can detect Ring 3 MONITOR/MWAIT instructions. Change-Id: I37d0354d1e2b9594d7feebc2bacda30b68163efe Signed-off-by: Grzegorz Andrejczuk ---

[PATCH 3/4] Add hwcap2 for x86

Add hwcap2 attribute for x86. Reserve 1st bit of HWCAP2 for exposing Xeon Phi ring 3 monitor/mwait. With this userspace apps can detect Ring 3 MONITOR/MWAIT instructions. Change-Id: I37d0354d1e2b9594d7feebc2bacda30b68163efe Signed-off-by: Grzegorz Andrejczuk --- arch/x86/include/asm/elf.h

Re: [PATCH v8 4/6] mfd: move enum lpc_chipsets into lpc_ich.h

On Wed, 2016-10-12 at 14:51 +0800, Tan Jui Nee wrote: > Move the enum's definition into a standalone header file which can be > used > wherever its definition is needed. > > --- a/include/linux/mfd/lpc_ich.h > +++ b/include/linux/mfd/lpc_ich.h > @@ -43,4 +43,75 @@ struct lpc_ich_info { >   u8

Re: [PATCH v8 4/6] mfd: move enum lpc_chipsets into lpc_ich.h

On Wed, 2016-10-12 at 14:51 +0800, Tan Jui Nee wrote: > Move the enum's definition into a standalone header file which can be > used > wherever its definition is needed. > > --- a/include/linux/mfd/lpc_ich.h > +++ b/include/linux/mfd/lpc_ich.h > @@ -43,4 +43,75 @@ struct lpc_ich_info { >   u8

Re: [PATCH v8 6/6] mfd: lpc_ich: Add support for Intel Apollo Lake GPIO pinctrl in non-ACPI system

On Wed, 2016-10-12 at 14:51 +0800, Tan Jui Nee wrote: > This driver uses the P2SB hide/unhide mechanism cooperatively > to pass the PCI BAR address to the gpio platform driver. > Almost minor issues below. > --- a/drivers/mfd/Makefile > +++ b/drivers/mfd/Makefile > @@ -161,6 +161,10 @@

Re: [PATCH v8 6/6] mfd: lpc_ich: Add support for Intel Apollo Lake GPIO pinctrl in non-ACPI system

On Wed, 2016-10-12 at 14:51 +0800, Tan Jui Nee wrote: > This driver uses the P2SB hide/unhide mechanism cooperatively > to pass the PCI BAR address to the gpio platform driver. > Almost minor issues below. > --- a/drivers/mfd/Makefile > +++ b/drivers/mfd/Makefile > @@ -161,6 +161,10 @@

Re: [PATCH] mm: kmemleak: Ensure that the task stack is not freed during scanning

> @@ -1453,8 +1453,11 @@ static void kmemleak_scan(void) > > read_lock(_lock); > do_each_thread(g, p) { Take a look at this commit please. 1da4db0cd5 ("oom_kill: change oom_kill.c to use for_each_thread()") > -

Re: [PATCH] mm: kmemleak: Ensure that the task stack is not freed during scanning

> @@ -1453,8 +1453,11 @@ static void kmemleak_scan(void) > > read_lock(_lock); > do_each_thread(g, p) { Take a look at this commit please. 1da4db0cd5 ("oom_kill: change oom_kill.c to use for_each_thread()") > -

[PATCH v1 2/4] Add enabling of the R3 MWAIT during boot for KNL

If processor is Intel Xeon Phi we enable user-level mwait feature. Enabling this feature suppreses invalid-opcode error, when MONITOR/MWAIT is called from ring 3. Change-Id: I1c7defb99296b022790a068a6c725b3e860cd68c Signed-off-by: Grzegorz Andrejczuk ---

[PATCH v1 1/4] Add R3MWAIT register and bit to msr-info.h

Intel Xeon Phi x200 (codenamed Knights Landing) has MSR MISC_THD_FEATURE_ENABLE 0x140. Setting its 2nd bit make MONITOR and MWAIT instructions do not cause invalid-opcode exception. This commit adds this register prefixed by PHI and bit to msr-info.h Reference:

[PATCH v1 2/4] Add enabling of the R3 MWAIT during boot for KNL

If processor is Intel Xeon Phi we enable user-level mwait feature. Enabling this feature suppreses invalid-opcode error, when MONITOR/MWAIT is called from ring 3. Change-Id: I1c7defb99296b022790a068a6c725b3e860cd68c Signed-off-by: Grzegorz Andrejczuk --- arch/x86/kernel/cpu/intel.c | 26

[PATCH v1 1/4] Add R3MWAIT register and bit to msr-info.h

Intel Xeon Phi x200 (codenamed Knights Landing) has MSR MISC_THD_FEATURE_ENABLE 0x140. Setting its 2nd bit make MONITOR and MWAIT instructions do not cause invalid-opcode exception. This commit adds this register prefixed by PHI and bit to msr-info.h Reference:

[PATCH v1 0/4] Enabling Ring 3 MONITOR/MWAIT feature for Knights Landing

These patches enable Intel Xeon Phi x200 feature to use MONITOR/MWAIT instruction in ring 3 (userspace) Patches set MSR 0x140 for all logical CPUs. Then expose it as CPU feature and introduces elf HWCAP capability for x86. Reference:

[PATCH v1 4/4] Add R3MWAIT to CPU features

Add cpu feature for ring 3 monitor/mwait. Change-Id: Iba4d20639efd8d3637d37db9294cbc43a98f009a Signed-off-by: Grzegorz Andrejczuk --- arch/x86/include/asm/cpufeature.h| 6 -- arch/x86/include/asm/cpufeatures.h | 6 +-

[PATCH v1 0/4] Enabling Ring 3 MONITOR/MWAIT feature for Knights Landing

These patches enable Intel Xeon Phi x200 feature to use MONITOR/MWAIT instruction in ring 3 (userspace) Patches set MSR 0x140 for all logical CPUs. Then expose it as CPU feature and introduces elf HWCAP capability for x86. Reference:

[PATCH v1 4/4] Add R3MWAIT to CPU features

Add cpu feature for ring 3 monitor/mwait. Change-Id: Iba4d20639efd8d3637d37db9294cbc43a98f009a Signed-off-by: Grzegorz Andrejczuk --- arch/x86/include/asm/cpufeature.h| 6 -- arch/x86/include/asm/cpufeatures.h | 6 +- arch/x86/include/asm/disabled-features.h | 3 ++-

Re: Intermittent perf build failures

On Tue, Oct 11, 2016 at 02:18:49PM -0700, Laura Abbott wrote: > On 10/11/2016 01:59 PM, Jiri Olsa wrote: > > On Tue, Oct 11, 2016 at 01:43:36PM -0700, Laura Abbott wrote: > > > Hi, > > > > > > While building today's Fedora rawhide kernel, there was a failure > > > building perf with -j4 [1]: ok,

Re: Intermittent perf build failures

On Tue, Oct 11, 2016 at 02:18:49PM -0700, Laura Abbott wrote: > On 10/11/2016 01:59 PM, Jiri Olsa wrote: > > On Tue, Oct 11, 2016 at 01:43:36PM -0700, Laura Abbott wrote: > > > Hi, > > > > > > While building today's Fedora rawhide kernel, there was a failure > > > building perf with -j4 [1]: ok,

[RESEND RFC PATCH v2 1/1] mm/vmalloc.c: simplify /proc/vmallocinfo implementation

From: zijun_hu many seq_file helpers exist for simplifying implementation of virtual files especially, for /proc nodes. however, the helpers for iteration over list_head are available but aren't adopted to implement /proc/vmallocinfo currently. simplify /proc/vmallocinfo

[RESEND RFC PATCH v2 1/1] mm/vmalloc.c: simplify /proc/vmallocinfo implementation

From: zijun_hu many seq_file helpers exist for simplifying implementation of virtual files especially, for /proc nodes. however, the helpers for iteration over list_head are available but aren't adopted to implement /proc/vmallocinfo currently. simplify /proc/vmallocinfo implementation by

[PATCH v1 3/4] Add hwcap2 for x86

Add hwcap2 attribute for x86. Reserve 1st bit of HWCAP2 for exposing Xeon Phi ring 3 monitor/mwait. With this userspace apps can detect Ring 3 MONITOR/MWAIT instructions. Change-Id: I37d0354d1e2b9594d7feebc2bacda30b68163efe Signed-off-by: Grzegorz Andrejczuk ---

[PATCH v1 3/4] Add hwcap2 for x86

Add hwcap2 attribute for x86. Reserve 1st bit of HWCAP2 for exposing Xeon Phi ring 3 monitor/mwait. With this userspace apps can detect Ring 3 MONITOR/MWAIT instructions. Change-Id: I37d0354d1e2b9594d7feebc2bacda30b68163efe Signed-off-by: Grzegorz Andrejczuk --- arch/x86/include/asm/elf.h

Re: [PATCH v2] z3fold: add shrinker

On Wed, 12 Oct 2016 09:52:06 +1100 Dave Chinner wrote: > > > +static unsigned long z3fold_shrink_scan(struct shrinker *shrink, > > + struct shrink_control *sc) > > +{ > > + struct z3fold_pool *pool = container_of(shrink, struct z3fold_pool, > >

Re: [PATCH v2] z3fold: add shrinker

On Wed, 12 Oct 2016 09:52:06 +1100 Dave Chinner wrote: > > > +static unsigned long z3fold_shrink_scan(struct shrinker *shrink, > > + struct shrink_control *sc) > > +{ > > + struct z3fold_pool *pool = container_of(shrink, struct z3fold_pool, > > +

Re: [PATCH v3 07/11] arm64/tracing: fix compat syscall handling

On Wed, Oct 12, 2016 at 09:07:03AM +0200, Marcin Nowakowski wrote: > On 11.10.2016 15:36, Will Deacon wrote: > >On Tue, Oct 11, 2016 at 12:42:52PM +0200, Marcin Nowakowski wrote: > >>diff --git a/arch/arm64/include/asm/unistd.h > >>b/arch/arm64/include/asm/unistd.h > >>index e78ac26..276d049

Re: [PATCH v3 07/11] arm64/tracing: fix compat syscall handling

On Wed, Oct 12, 2016 at 09:07:03AM +0200, Marcin Nowakowski wrote: > On 11.10.2016 15:36, Will Deacon wrote: > >On Tue, Oct 11, 2016 at 12:42:52PM +0200, Marcin Nowakowski wrote: > >>diff --git a/arch/arm64/include/asm/unistd.h > >>b/arch/arm64/include/asm/unistd.h > >>index e78ac26..276d049

[PATCH] drm/bridge: analogix: protect power when get_modes or detect

The drm callback ->detect and ->get_modes seems is not power safe, they may be called when device is power off, do register access on detect or get_modes will cause system die. Here is the path call ->detect before analogix_dp power on [] analogix_dp_detect+0x44/0xdc []

[PATCH] drm/bridge: analogix: protect power when get_modes or detect

The drm callback ->detect and ->get_modes seems is not power safe, they may be called when device is power off, do register access on detect or get_modes will cause system die. Here is the path call ->detect before analogix_dp power on [] analogix_dp_detect+0x44/0xdc []

Re: [PATCH v3 08/11] powerpc/tracing: fix compat syscall handling

Marcin Nowakowski writes: > Adapt the code to make use of new syscall handling interface > > Signed-off-by: Marcin Nowakowski > Cc: Steven Rostedt > Cc: Ingo Molnar > Cc: Benjamin Herrenschmidt

Re: [PATCH v3 08/11] powerpc/tracing: fix compat syscall handling

Marcin Nowakowski writes: > Adapt the code to make use of new syscall handling interface > > Signed-off-by: Marcin Nowakowski > Cc: Steven Rostedt > Cc: Ingo Molnar > Cc: Benjamin Herrenschmidt > Cc: Paul Mackerras > Cc: Michael Ellerman > Cc: linuxppc-...@lists.ozlabs.org > --- >

Re: [RFC PATCH 1/1] mm/percpu.c: fix memory leakage issue when allocate a odd alignment area

On 10/12/2016 05:54 PM, Michal Hocko wrote: > On Wed 12-10-16 16:44:31, zijun_hu wrote: >> On 10/12/2016 04:25 PM, Michal Hocko wrote: >>> On Wed 12-10-16 15:24:33, zijun_hu wrote: > [...] i found the following code segments in mm/vmalloc.c static struct vmap_area

Re: [RFC PATCH 1/1] mm/percpu.c: fix memory leakage issue when allocate a odd alignment area

On 10/12/2016 05:54 PM, Michal Hocko wrote: > On Wed 12-10-16 16:44:31, zijun_hu wrote: >> On 10/12/2016 04:25 PM, Michal Hocko wrote: >>> On Wed 12-10-16 15:24:33, zijun_hu wrote: > [...] i found the following code segments in mm/vmalloc.c static struct vmap_area

[PATCH] mm: kmemleak: Ensure that the task stack is not freed during scanning

Commit 68f24b08ee89 ("sched/core: Free the stack early if CONFIG_THREAD_INFO_IN_TASK") may cause the task->stack to be freed during kmemleak_scan() execution, leading to either a NULL pointer fault (if task->stack is NULL) or kmemleak accessing already freed memory. This patch uses the new

[PATCH] mm: kmemleak: Ensure that the task stack is not freed during scanning

Commit 68f24b08ee89 ("sched/core: Free the stack early if CONFIG_THREAD_INFO_IN_TASK") may cause the task->stack to be freed during kmemleak_scan() execution, leading to either a NULL pointer fault (if task->stack is NULL) or kmemleak accessing already freed memory. This patch uses the new

drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)

On a laptop that tracks the latest stable release (Ie, it now runs v4.8.1) I see this WARNING     WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock) Full trace pasted below. I never saw this WARNING before v4.8. Since v4.8 I've had it in all (four, actually) boots. What am I expected to do about

drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)

On a laptop that tracks the latest stable release (Ie, it now runs v4.8.1) I see this WARNING     WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock) Full trace pasted below. I never saw this WARNING before v4.8. Since v4.8 I've had it in all (four, actually) boots. What am I expected to do about

Re: [RFC PATCH 1/1] mm/percpu.c: fix memory leakage issue when allocate a odd alignment area

On Wed 12-10-16 16:44:31, zijun_hu wrote: > On 10/12/2016 04:25 PM, Michal Hocko wrote: > > On Wed 12-10-16 15:24:33, zijun_hu wrote: [...] > >> i found the following code segments in mm/vmalloc.c > >> static struct vmap_area *alloc_vmap_area(unsigned long size, > >>

Re: [RFC PATCH 1/1] mm/percpu.c: fix memory leakage issue when allocate a odd alignment area

On Wed 12-10-16 16:44:31, zijun_hu wrote: > On 10/12/2016 04:25 PM, Michal Hocko wrote: > > On Wed 12-10-16 15:24:33, zijun_hu wrote: [...] > >> i found the following code segments in mm/vmalloc.c > >> static struct vmap_area *alloc_vmap_area(unsigned long size, > >>

Re: MPOL_BIND on memory only nodes

On Wed 12-10-16 14:55:24, Anshuman Khandual wrote: > Hi, > > We have the following function policy_zonelist() which selects a zonelist > during various allocation paths. With this, general user space allocations > (IIUC might not have __GFP_THISNODE) fails while trying to get memory from > a

Re: MPOL_BIND on memory only nodes

On Wed 12-10-16 14:55:24, Anshuman Khandual wrote: > Hi, > > We have the following function policy_zonelist() which selects a zonelist > during various allocation paths. With this, general user space allocations > (IIUC might not have __GFP_THISNODE) fails while trying to get memory from > a

Re: [RFC] net: phy: smsc: Disable auto-negotiation on startup

On 10/10/2016 10:41 AM, Kyle Roeschley wrote: > Because the SMSC PHY completes auto-negotiation before the driver is > ready to handle interrupts, the PHY state machine never realizes that we > have a link. Clear the ANENABLE bit on initialization, which lets > genphy_config_aneg do its thing when

Re: [RFC] net: phy: smsc: Disable auto-negotiation on startup

On 10/10/2016 10:41 AM, Kyle Roeschley wrote: > Because the SMSC PHY completes auto-negotiation before the driver is > ready to handle interrupts, the PHY state machine never realizes that we > have a link. Clear the ANENABLE bit on initialization, which lets > genphy_config_aneg do its thing when

Re: [PATCH v8 2/2] clocksource: add J-Core timer/clocksource driver

On Tue, Oct 11, 2016 at 04:28:50PM -0400, Rich Felker wrote: > On Tue, Oct 11, 2016 at 08:18:12PM +0200, Daniel Lezcano wrote: > > > > Hi Rich, > > > > On Sun, Oct 09, 2016 at 05:34:22AM +, Rich Felker wrote: > > > At the hardware level, the J-Core PIT is integrated with the interrupt > > >

Re: [PATCH v8 2/2] clocksource: add J-Core timer/clocksource driver

On Tue, Oct 11, 2016 at 04:28:50PM -0400, Rich Felker wrote: > On Tue, Oct 11, 2016 at 08:18:12PM +0200, Daniel Lezcano wrote: > > > > Hi Rich, > > > > On Sun, Oct 09, 2016 at 05:34:22AM +, Rich Felker wrote: > > > At the hardware level, the J-Core PIT is integrated with the interrupt > > >

[PATCH v6 1/2] serial: xuartps: Add new compatible string for ZynqMP

This patch Adds the new compatible string for ZynqMP SoC. Signed-off-by: Nava kishore Manne --- Changes for v6: -Added New patch. drivers/tty/serial/xilinx_uartps.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/tty/serial/xilinx_uartps.c

[PATCH v6 1/2] serial: xuartps: Add new compatible string for ZynqMP

This patch Adds the new compatible string for ZynqMP SoC. Signed-off-by: Nava kishore Manne --- Changes for v6: -Added New patch. drivers/tty/serial/xilinx_uartps.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/tty/serial/xilinx_uartps.c

<    7   8   9   10   11   12   13   14   >