[PATCH 09/10] blk-throttle: make sure expire time isn't too big

cgroup could be throttled to a limit but when other cgroups are idle, queue enters a higher state and so the group should be throttled to a higher limit. It's possible the cgroup is sleeping because of throttle and other cgroups don't dispatch IO any more. In this case, nobody can trigger current

RE: [PATCH][RFC] cpufreq: intel_pstate: Avoid time-costly synchronization if schedutil is not enabled

Hi, > -Original Message- > From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of > Rafael J. Wysocki > Sent: Wednesday, May 11, 2016 3:07 AM > To: Chen, Yu C > Cc: linux...@vger.kernel.org; Srinivas Pandruvada; Rafael J. Wysocki; Len > Brown; Viresh Kumar; Zhang, Rui; Linux

[PATCH 06/10] block-throttle: idle detection

A cgroup gets assigned a low limit, but the cgroup could never dispatch enough IO to cross the low limit. In such case, the queue state machine will remain in LIMIT_LOW state and all other cgroups will be throttled according to low limit. This is unfair for other cgroups. We will treat the cgroup

[PATCH 10/10] blk-throttle: add trace log

Add trace log in new low/high logic to help dignose issues. Signed-off-by: Shaohua Li --- block/blk-throttle.c | 43 +-- 1 file changed, 41 insertions(+), 2 deletions(-) diff --git a/block/blk-throttle.c b/block/blk-throttle.c index

[PATCH 01/10] block-throttle: prepare support multiple limits

We are going to support low/high limit, each cgroup will have 3 limits after that. This patch prepares for the multiple limits change. Signed-off-by: Shaohua Li --- block/blk-throttle.c | 109 --- 1 file changed, 68 insertions(+), 41

[PATCH 06/10] block-throttle: idle detection

A cgroup gets assigned a low limit, but the cgroup could never dispatch enough IO to cross the low limit. In such case, the queue state machine will remain in LIMIT_LOW state and all other cgroups will be throttled according to low limit. This is unfair for other cgroups. We will treat the cgroup

[PATCH 10/10] blk-throttle: add trace log

Add trace log in new low/high logic to help dignose issues. Signed-off-by: Shaohua Li --- block/blk-throttle.c | 43 +-- 1 file changed, 41 insertions(+), 2 deletions(-) diff --git a/block/blk-throttle.c b/block/blk-throttle.c index a5f3435..d35bbf1

[PATCH 01/10] block-throttle: prepare support multiple limits

We are going to support low/high limit, each cgroup will have 3 limits after that. This patch prepares for the multiple limits change. Signed-off-by: Shaohua Li --- block/blk-throttle.c | 109 --- 1 file changed, 68 insertions(+), 41 deletions(-)

linux-next: manual merge of the net-next tree with the net tree

Hi all, Today's linux-next merge of the net-next tree got a conflict in: net/netfilter/nf_conntrack_core.c between commit: 70d72b7e060e ("netfilter: conntrack: init all_locks to avoid debug warning") from the net tree and commit: a3efd81205b1 ("netfilter: conntrack: move generation

linux-next: manual merge of the net-next tree with the net tree

Hi all, Today's linux-next merge of the net-next tree got a conflict in: net/netfilter/nf_conntrack_core.c between commit: 70d72b7e060e ("netfilter: conntrack: init all_locks to avoid debug warning") from the net tree and commit: a3efd81205b1 ("netfilter: conntrack: move generation

Re: [PATCH] drivers/acpi: make evged.c explicitly non-modular

On Monday, May 09, 2016 03:59:29 PM Paul Gortmaker wrote: > [Re: [PATCH] drivers/acpi: make evged.c explicitly non-modular] On 09/05/2016 > (Mon 15:35) Sinan Kaya wrote: > > > +Rafael, > > > > On 5/9/2016 2:40 PM, Paul Gortmaker wrote: > > > The Makefile/Kconfig currently controlling

Re: [PATCH] drivers/acpi: make evged.c explicitly non-modular

On Monday, May 09, 2016 03:59:29 PM Paul Gortmaker wrote: > [Re: [PATCH] drivers/acpi: make evged.c explicitly non-modular] On 09/05/2016 > (Mon 15:35) Sinan Kaya wrote: > > > +Rafael, > > > > On 5/9/2016 2:40 PM, Paul Gortmaker wrote: > > > The Makefile/Kconfig currently controlling

Re: [PATCH v4 4/5] arm64: add support for ACPI Low Power Idle(LPI)

On Tuesday, April 19, 2016 01:30:12 PM Sudeep Holla wrote: > This patch adds appropriate callbacks to support ACPI Low Power Idle > (LPI) on ARM64. > > It also selects ARCH_SUPPORTS_ACPI_PROCESSOR_LPI if ACPI is enabled > on ARM64. Can you remind me why we need the

Re: [PATCH v4 4/5] arm64: add support for ACPI Low Power Idle(LPI)

On Tuesday, April 19, 2016 01:30:12 PM Sudeep Holla wrote: > This patch adds appropriate callbacks to support ACPI Low Power Idle > (LPI) on ARM64. > > It also selects ARCH_SUPPORTS_ACPI_PROCESSOR_LPI if ACPI is enabled > on ARM64. Can you remind me why we need the

[PATCH 1/2] ARM64: dts: rockchip: add sdhci/emmc for rk3399

The bindings for rk3399's SDHCI + eMMC PHY have been accepted, so let's support eMMC now. Note that 'rockchip,rk3399-sdhci-5.1' is not documented, but per Heiko's previous suggestion, we don't want to clutter the arasan doc, and it's just a precautionary measure to have it. Signed-off-by: Brian

[PATCH 1/2] ARM64: dts: rockchip: add sdhci/emmc for rk3399

The bindings for rk3399's SDHCI + eMMC PHY have been accepted, so let's support eMMC now. Note that 'rockchip,rk3399-sdhci-5.1' is not documented, but per Heiko's previous suggestion, we don't want to clutter the arasan doc, and it's just a precautionary measure to have it. Signed-off-by: Brian

[PATCH 2/2] ARM64: dts: rockchip: enable eMMC for rk3399 EVB

The 'mmc-hs400-enhanced-strobe' property has been acked by Rob Herring, though it's still not merged. Signed-off-by: Brian Norris --- arch/arm64/boot/dts/rockchip/rk3399-evb.dts | 12 1 file changed, 12 insertions(+) diff --git

[PATCH 2/2] ARM64: dts: rockchip: enable eMMC for rk3399 EVB

The 'mmc-hs400-enhanced-strobe' property has been acked by Rob Herring, though it's still not merged. Signed-off-by: Brian Norris --- arch/arm64/boot/dts/rockchip/rk3399-evb.dts | 12 1 file changed, 12 insertions(+) diff --git a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts

Re: [PATCH v4 2/5] ACPI / processor_idle: Add support for Low Power Idle(LPI) states

On Tuesday, April 19, 2016 01:30:10 PM Sudeep Holla wrote: > ACPI 6.0 introduced an optional object _LPI that provides an alternate > method to describe Low Power Idle states. It defines the local power > states for each node in a hierarchical processor topology. The OSPM can > use _LPI object to

Re: [PATCH v4 2/5] ACPI / processor_idle: Add support for Low Power Idle(LPI) states

On Tuesday, April 19, 2016 01:30:10 PM Sudeep Holla wrote: > ACPI 6.0 introduced an optional object _LPI that provides an alternate > method to describe Low Power Idle states. It defines the local power > states for each node in a hierarchical processor topology. The OSPM can > use _LPI object to

[PATCH v6 09/13] x86/xsaves: Fix xstate_offsets, xstate_sizes for non-extended states

The arrays xstate_offsets[] and xstate_sizes[] record XSAVE standard- format offsets and sizes. Values for non-extended state components fpu and xmm's were not initialized or used. Ptrace format conversion needs them. Fix it. Signed-off-by: Yu-cheng Yu Reviewed-by: Dave

[PATCH v6 02/13] x86/xsaves: Rename xstate_size to fpu_kernel_xstate_size to distinguish from fpu_user_xstate_size

User space uses standard format xsave area. fpstate in signal frame should have standard format size. To explicitly distinguish between xstate size in kernel space and the one in user space, we rename xstate_size to fpu_kernel_xstate_size. This patch is not fixing a bug. It just makes kernel code

[PATCH v6 09/13] x86/xsaves: Fix xstate_offsets, xstate_sizes for non-extended states

The arrays xstate_offsets[] and xstate_sizes[] record XSAVE standard- format offsets and sizes. Values for non-extended state components fpu and xmm's were not initialized or used. Ptrace format conversion needs them. Fix it. Signed-off-by: Yu-cheng Yu Reviewed-by: Dave Hansen ---

[PATCH v6 02/13] x86/xsaves: Rename xstate_size to fpu_kernel_xstate_size to distinguish from fpu_user_xstate_size

User space uses standard format xsave area. fpstate in signal frame should have standard format size. To explicitly distinguish between xstate size in kernel space and the one in user space, we rename xstate_size to fpu_kernel_xstate_size. This patch is not fixing a bug. It just makes kernel code

[PATCH v6 12/13] x86/xsaves: Fix fpstate_init() for XRSTORS

In XSAVES mode if fpstate_init() is used to initialize a task's extended state area, xsave.header.xcomp_bv[63] must be set. Otherwise, when the task is scheduled, a warning is triggered from copy_kernel_to_xregs(). One such test case is: setting an invalid extended state through PTRACE. When

[PATCH v6 08/13] x86/xsaves: Fix XSTATE component offset print out

Component offset print out was incorrect for XSAVES. Correct it and move to a separate function. Signed-off-by: Yu-cheng Yu Reviewed-by: Dave Hansen --- arch/x86/kernel/fpu/xstate.c | 18 -- 1 file changed, 16 insertions(+), 2

[PATCH v6 12/13] x86/xsaves: Fix fpstate_init() for XRSTORS

In XSAVES mode if fpstate_init() is used to initialize a task's extended state area, xsave.header.xcomp_bv[63] must be set. Otherwise, when the task is scheduled, a warning is triggered from copy_kernel_to_xregs(). One such test case is: setting an invalid extended state through PTRACE. When

[PATCH v6 08/13] x86/xsaves: Fix XSTATE component offset print out

Component offset print out was incorrect for XSAVES. Correct it and move to a separate function. Signed-off-by: Yu-cheng Yu Reviewed-by: Dave Hansen --- arch/x86/kernel/fpu/xstate.c | 18 -- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git

Re: [RFC v2 PATCH 0/8] VFS:userns: support portable root filesystems

On Thu, 2016-05-05 at 18:08 -0400, James Bottomley wrote: > On Thu, 2016-05-05 at 22:49 +0100, Djalal Harouni wrote: > > On Thu, May 05, 2016 at 07:56:28AM -0400, James Bottomley wrote: > > > On Thu, 2016-05-05 at 08:36 +0100, Djalal Harouni wrote: > > > > On Wed, May 04, 2016 at 05:06:19PM -0400,

Re: [RFC v2 PATCH 0/8] VFS:userns: support portable root filesystems

On Thu, 2016-05-05 at 18:08 -0400, James Bottomley wrote: > On Thu, 2016-05-05 at 22:49 +0100, Djalal Harouni wrote: > > On Thu, May 05, 2016 at 07:56:28AM -0400, James Bottomley wrote: > > > On Thu, 2016-05-05 at 08:36 +0100, Djalal Harouni wrote: > > > > On Wed, May 04, 2016 at 05:06:19PM -0400,

Re: [PATCH v2 2/4] Documentation: Add documentation for APM X-Gene SoC PMU DTS binding

Hi Rob/Mark, Do you have any more comments, please? Thanks, Tai On Mon, May 2, 2016 at 2:46 PM, Tai Tri Nguyen wrote: > Hi Rob, > > On Mon, May 2, 2016 at 1:56 PM, Rob Herring wrote: >> On Wed, Apr 20, 2016 at 12:31:22PM +0100, Will Deacon wrote: >>> On Mon,

Re: [PATCH v2 2/4] Documentation: Add documentation for APM X-Gene SoC PMU DTS binding

Hi Rob/Mark, Do you have any more comments, please? Thanks, Tai On Mon, May 2, 2016 at 2:46 PM, Tai Tri Nguyen wrote: > Hi Rob, > > On Mon, May 2, 2016 at 1:56 PM, Rob Herring wrote: >> On Wed, Apr 20, 2016 at 12:31:22PM +0100, Will Deacon wrote: >>> On Mon, Apr 18, 2016 at 01:04:53PM -0700,

[PATCH v6 10/13] x86/xsaves: Fix __fpu_restore_sig() for XSAVES

When the kernel is using XSAVES compacted format, we cannot do __copy_from_user() from a signal frame, which has standard-format data. Fix it by using copyin_to_xsaves(), which converts between formats and filters out all supervisor states that we do not allow userspace to write. Signed-off-by:

[PATCH v6 10/13] x86/xsaves: Fix __fpu_restore_sig() for XSAVES

When the kernel is using XSAVES compacted format, we cannot do __copy_from_user() from a signal frame, which has standard-format data. Fix it by using copyin_to_xsaves(), which converts between formats and filters out all supervisor states that we do not allow userspace to write. Signed-off-by:

[PATCH v6 11/13] x86/xsaves: When a disabled xstate component offset is requested, return NULL

It is an error to request a disabled XSAVE/XSAVES component address. For that case, make __raw_xsave_addr() return a NULL and issue a warning. Signed-off-by: Yu-cheng Yu --- arch/x86/kernel/fpu/xstate.c | 5 + 1 file changed, 5 insertions(+) diff --git

[PATCH v6 11/13] x86/xsaves: When a disabled xstate component offset is requested, return NULL

It is an error to request a disabled XSAVE/XSAVES component address. For that case, make __raw_xsave_addr() return a NULL and issue a warning. Signed-off-by: Yu-cheng Yu --- arch/x86/kernel/fpu/xstate.c | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/x86/kernel/fpu/xstate.c

Re: [GIT PULL] overlayfs fixes for 4.6-rc7

Hi Al, Hopefully this addresses your concerns. I couldn't find a better name for lookup_hash(), after all it's just that. Please pull: git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git overlayfs-linus --- Miklos Szeredi (4): vfs: add vfs_select_inode() helper vfs:

Re: [GIT PULL] overlayfs fixes for 4.6-rc7

Hi Al, Hopefully this addresses your concerns. I couldn't find a better name for lookup_hash(), after all it's just that. Please pull: git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git overlayfs-linus --- Miklos Szeredi (4): vfs: add vfs_select_inode() helper vfs:

[PATCH v6 03/13] x86/xsaves: Keep init_fpstate.xsave.header.xfeatures as zero for init optimization

Keep init_fpstate.xsave.header.xfeatures as zero for init optimization. This is important for init optimization that is implemented in processor. If a bit corresponding to an xstate in xstate_bv is 0, it means the xstate is in init status and will not be read from memory to the processor during

[PATCH v6 00/13] x86/xsaves: Fix XSAVES issues

XSAVES is a kernel-mode instruction. It offers a compacted format and memory-write optimization. These patches fix issues in the first implementation. Changes since Version 5: Patch 1, 2 - Change names to fpu_user_xstate_size and fpu_kernel_xstate_size; fix some comments, etc.

[PATCH v6 01/13] x86/xsaves: Define and use fpu_user_xstate_size

The XSAVE area of kernel can be in standard or compacted format; it is always in standard format for user mode. When XSAVES is enabled, the kernel uses the compacted format and it is necessary to use a separate fpu_user_xstate_size for signal/ptrace frames. Based on an earlier patch from Fenghua

[PATCH v6 13/13] x86/xsaves: Re-enable XSAVES

We did not handle XSAVES instructions correctly. There were issues in converting between standard and compacted format when interfacing with user-space. These issues have been corrected. Add a WARN_ONCE() to make it clear that XSAVES supervisor states are not yet implemented. Signed-off-by:

[PATCH v6 04/13] x86/xsaves: Introduce a new check that allows correct xstates copy from kernel to user directly

XSAVES is a kernel instruction and uses a compacted format. When working with user space, the kernel should provide standard-format, non-supervisor state data. We cannot do __copy_to_user() from a compacted- format kernel xstate area to a signal frame. Dave Hansen proposes this method to simplify

[PATCH v6 06/13] x86/xsaves: Supervisor state component offset

CPUID function 0x0d, sub function (i, i > 1) returns in ebx the offset of xstate component i. Zero is returned for a supervisor state. A supervisor state can only be saved by XSAVES and XSAVES uses a compacted format. There is no fixed offset for a supervisor state. This patch checks and makes

[PATCH v6 07/13] x86/xsaves: Fix PTRACE frames for XSAVES

XSAVES uses compacted format and is a kernel instruction. The kernel should use standard-format, non-supervisor state data for PTRACE. Signed-off-by: Yu-cheng Yu --- arch/x86/include/asm/fpu/xstate.h | 5 +- arch/x86/kernel/fpu/regset.c | 56 +

[PATCH v6 03/13] x86/xsaves: Keep init_fpstate.xsave.header.xfeatures as zero for init optimization

Keep init_fpstate.xsave.header.xfeatures as zero for init optimization. This is important for init optimization that is implemented in processor. If a bit corresponding to an xstate in xstate_bv is 0, it means the xstate is in init status and will not be read from memory to the processor during

[PATCH v6 00/13] x86/xsaves: Fix XSAVES issues

XSAVES is a kernel-mode instruction. It offers a compacted format and memory-write optimization. These patches fix issues in the first implementation. Changes since Version 5: Patch 1, 2 - Change names to fpu_user_xstate_size and fpu_kernel_xstate_size; fix some comments, etc.

[PATCH v6 01/13] x86/xsaves: Define and use fpu_user_xstate_size

The XSAVE area of kernel can be in standard or compacted format; it is always in standard format for user mode. When XSAVES is enabled, the kernel uses the compacted format and it is necessary to use a separate fpu_user_xstate_size for signal/ptrace frames. Based on an earlier patch from Fenghua

[PATCH v6 13/13] x86/xsaves: Re-enable XSAVES

We did not handle XSAVES instructions correctly. There were issues in converting between standard and compacted format when interfacing with user-space. These issues have been corrected. Add a WARN_ONCE() to make it clear that XSAVES supervisor states are not yet implemented. Signed-off-by:

[PATCH v6 04/13] x86/xsaves: Introduce a new check that allows correct xstates copy from kernel to user directly

XSAVES is a kernel instruction and uses a compacted format. When working with user space, the kernel should provide standard-format, non-supervisor state data. We cannot do __copy_to_user() from a compacted- format kernel xstate area to a signal frame. Dave Hansen proposes this method to simplify

[PATCH v6 06/13] x86/xsaves: Supervisor state component offset

CPUID function 0x0d, sub function (i, i > 1) returns in ebx the offset of xstate component i. Zero is returned for a supervisor state. A supervisor state can only be saved by XSAVES and XSAVES uses a compacted format. There is no fixed offset for a supervisor state. This patch checks and makes

[PATCH v6 07/13] x86/xsaves: Fix PTRACE frames for XSAVES

XSAVES uses compacted format and is a kernel instruction. The kernel should use standard-format, non-supervisor state data for PTRACE. Signed-off-by: Yu-cheng Yu --- arch/x86/include/asm/fpu/xstate.h | 5 +- arch/x86/kernel/fpu/regset.c | 56 + arch/x86/kernel/fpu/xstate.c

Re: [PATCH 3/3] blk-throttle: don't parse cgroup path if trace isn't enabled

On Tue, 10 May 2016 11:52:15 -0400 Jeff Moyer wrote: > > +static inline bool blk_trace_note_message_enabled(struct request_queue *q) > > +{ > > + struct blk_trace *bt = q->blk_trace; > > + if (likely(!bt)) > > + return false; > > + return bt->act_mask &

[PATCH v6 05/13] x86/xsaves: Align xstate components according to CPUID

CPUID function 0x0d, sub function (i, i > 1) returns in ecx[1] the alignment requirement of component i when the compacted format is used. If ecx[1] is 0, component i is located immediately following the preceding component. If ecx[1] is 1, component i is located on the next 64-byte boundary

Re: [PATCH 3/3] blk-throttle: don't parse cgroup path if trace isn't enabled

On Tue, 10 May 2016 11:52:15 -0400 Jeff Moyer wrote: > > +static inline bool blk_trace_note_message_enabled(struct request_queue *q) > > +{ > > + struct blk_trace *bt = q->blk_trace; > > + if (likely(!bt)) > > + return false; > > + return bt->act_mask & BLK_TC_NOTIFY; > > Do

[PATCH v6 05/13] x86/xsaves: Align xstate components according to CPUID

CPUID function 0x0d, sub function (i, i > 1) returns in ecx[1] the alignment requirement of component i when the compacted format is used. If ecx[1] is 0, component i is located immediately following the preceding component. If ecx[1] is 1, component i is located on the next 64-byte boundary

mmotm 2016-05-10-16-31 uploaded

The mm-of-the-moment snapshot 2016-05-10-16-31 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

mmotm 2016-05-10-16-31 uploaded

The mm-of-the-moment snapshot 2016-05-10-16-31 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

Re: [PATCH 1/2] [v4] net: emac: emac gigabit ethernet controller driver

On 05/10/2016 04:18 PM, Timur Tabi wrote: > Florian Fainelli wrote: >> Are you utilizing the PHYLIB APIs properly? You need at least a >> phy_start() to start the PHY state machine, and an adjust_link callback >> to be provided to phy_connect() (or of_phy_connect()) to manage link >> state

Re: [PATCH 1/2] [v4] net: emac: emac gigabit ethernet controller driver

On 05/10/2016 04:18 PM, Timur Tabi wrote: > Florian Fainelli wrote: >> Are you utilizing the PHYLIB APIs properly? You need at least a >> phy_start() to start the PHY state machine, and an adjust_link callback >> to be provided to phy_connect() (or of_phy_connect()) to manage link >> state

Re: [PATCH] workqueue: fix rebind bound workers warning

Hi Tejun, 2016-05-10 5:50 GMT+08:00 Wanpeng Li : > Cc Thomas, the new state machine author, > 2016-05-10 1:00 GMT+08:00 Tejun Heo : >> Hello, >> >> On Thu, May 05, 2016 at 09:41:31AM +0800, Wanpeng Li wrote: >>> The boot CPU handles housekeeping duty(unbound

Re: [PATCH] workqueue: fix rebind bound workers warning

Hi Tejun, 2016-05-10 5:50 GMT+08:00 Wanpeng Li : > Cc Thomas, the new state machine author, > 2016-05-10 1:00 GMT+08:00 Tejun Heo : >> Hello, >> >> On Thu, May 05, 2016 at 09:41:31AM +0800, Wanpeng Li wrote: >>> The boot CPU handles housekeeping duty(unbound timers, workqueues, >>> timekeeping,

linux-next: manual merge of the vfs tree with the overlayfs tree

Hi Al, Today's linux-next merge of the vfs tree got a conflict in: fs/overlayfs/super.c between commit: 420598d5bf9c ("ovl: ignore permissions on underlying lookup") from the overlayfs tree and commit: b9e1d435fdf4 ("ovl_lookup_real(): use lookup_one_len_unlocked()") from the vfs

linux-next: manual merge of the vfs tree with the overlayfs tree

Hi Al, Today's linux-next merge of the vfs tree got a conflict in: fs/overlayfs/super.c between commit: 420598d5bf9c ("ovl: ignore permissions on underlying lookup") from the overlayfs tree and commit: b9e1d435fdf4 ("ovl_lookup_real(): use lookup_one_len_unlocked()") from the vfs

Re: [PATCH 1/2] [v4] net: emac: emac gigabit ethernet controller driver

Florian Fainelli wrote: Are you utilizing the PHYLIB APIs properly? You need at least a phy_start() to start the PHY state machine, and an adjust_link callback to be provided to phy_connect() (or of_phy_connect()) to manage link state changes. And that's the very basic minimum here, there could

Re: [PATCH 1/2] [v4] net: emac: emac gigabit ethernet controller driver

Florian Fainelli wrote: Are you utilizing the PHYLIB APIs properly? You need at least a phy_start() to start the PHY state machine, and an adjust_link callback to be provided to phy_connect() (or of_phy_connect()) to manage link state changes. And that's the very basic minimum here, there could

How are you doing today Dear.

Hello. My Name is Precious,i saw your profile and became interested to know you, hope i will not be embarrassed. i am very happy to contact you for us to know ourselves distance, age doesn't matter at all.i have important thing to share with you. i will like you to send Email to my private Email

How are you doing today Dear.

Hello. My Name is Precious,i saw your profile and became interested to know you, hope i will not be embarrassed. i am very happy to contact you for us to know ourselves distance, age doesn't matter at all.i have important thing to share with you. i will like you to send Email to my private Email

Re: [RFC PATCH 0/2] net: threadable napi poll loop

On Wed, 2016-05-11 at 00:32 +0200, Hannes Frederic Sowa wrote: > Not only did we want to present this solely as a bugfix but also as as > performance enhancements in case of virtio (as you can see in the cover > letter). Given that a long time ago there was a tendency to remove > softirqs

Re: [RFC PATCH 0/2] net: threadable napi poll loop

On Wed, 2016-05-11 at 00:32 +0200, Hannes Frederic Sowa wrote: > Not only did we want to present this solely as a bugfix but also as as > performance enhancements in case of virtio (as you can see in the cover > letter). Given that a long time ago there was a tendency to remove > softirqs

Re: [PATCH v1] ION: Sys_heap: Add cached pool to spead up cached buffer alloc

On 05/09/2016 04:35 AM, Chen Feng wrote: Add ion cached pool in system heap. This patch add a cached pool in system heap. It has a great improvement of alloc for cached buffer. Can you give some benchmark numbers here? v1: Makes the cached buffer zeroed before going to pool Signed-off-by:

Re: [PATCH v1] ION: Sys_heap: Add cached pool to spead up cached buffer alloc

On 05/09/2016 04:35 AM, Chen Feng wrote: Add ion cached pool in system heap. This patch add a cached pool in system heap. It has a great improvement of alloc for cached buffer. Can you give some benchmark numbers here? v1: Makes the cached buffer zeroed before going to pool Signed-off-by:

[PATCH 1/2] ARM: dts: qcom: Enable RPM regulators on apq8074 dragonboard

Add the appropriate min/max voltages for the regulators on the apq8074 dragonboard so that they can be used by clients properly. Signed-off-by: Stephen Boyd --- arch/arm/boot/dts/qcom-apq8074-dragonboard.dts | 199 + 1 file changed, 199

[PATCH 1/2] ARM: dts: qcom: Enable RPM regulators on apq8074 dragonboard

Add the appropriate min/max voltages for the regulators on the apq8074 dragonboard so that they can be used by clients properly. Signed-off-by: Stephen Boyd --- arch/arm/boot/dts/qcom-apq8074-dragonboard.dts | 199 + 1 file changed, 199 insertions(+) diff --git

[PATCH 2/2] ARM: dts: qcom: Enable sdcard and emmc on apq8074 dragonboard

Enable the sdcard slot and wire up the regulators for the two storage controllers found on the apq8074 dragonboard. Signed-off-by: Stephen Boyd --- arch/arm/boot/dts/qcom-apq8074-dragonboard.dts | 48 ++ 1 file changed, 48 insertions(+) diff --git

[PATCH 2/2] ARM: dts: qcom: Enable sdcard and emmc on apq8074 dragonboard

Enable the sdcard slot and wire up the regulators for the two storage controllers found on the apq8074 dragonboard. Signed-off-by: Stephen Boyd --- arch/arm/boot/dts/qcom-apq8074-dragonboard.dts | 48 ++ 1 file changed, 48 insertions(+) diff --git

Re: [RFC PATCH 0/2] net: threadable napi poll loop

On Tue, 2016-05-10 at 15:02 -0700, Eric Dumazet wrote: > On Tue, 2016-05-10 at 14:53 -0700, Eric Dumazet wrote: > > On Tue, 2016-05-10 at 17:35 -0400, Rik van Riel wrote: > > > > > You might need another one of these in invoke_softirq() > > > > > > > Excellent. > > > > I gave it a quick try

Re: [RFC PATCH 0/2] net: threadable napi poll loop

On Tue, 2016-05-10 at 15:02 -0700, Eric Dumazet wrote: > On Tue, 2016-05-10 at 14:53 -0700, Eric Dumazet wrote: > > On Tue, 2016-05-10 at 17:35 -0400, Rik van Riel wrote: > > > > > You might need another one of these in invoke_softirq() > > > > > > > Excellent. > > > > I gave it a quick try

Re: [PATCH 3/4] drm: Add helper for simple display pipeline

On Tue, May 10, 2016 at 8:59 AM, Daniel Vetter wrote: >> if (ret) >> return ret; >> >> /* How to handle !visible, is it even possible? */ > > if (!visible) > return -EINVAL; > > You can't, so need to reject it. Ok, on further thought I

Re: [PATCH 3/4] drm: Add helper for simple display pipeline

On Tue, May 10, 2016 at 8:59 AM, Daniel Vetter wrote: >> if (ret) >> return ret; >> >> /* How to handle !visible, is it even possible? */ > > if (!visible) > return -EINVAL; > > You can't, so need to reject it. Ok, on further thought I think we need a bit

Re: [RFC PATCH 0/2] net: threadable napi poll loop

On 10.05.2016 23:09, Eric Dumazet wrote: > On Tue, May 10, 2016 at 1:46 PM, Hannes Frederic Sowa > wrote: > >> I agree here, but I don't think this patch particularly is a lot of >> bloat and something very interesting people can play with and extend upon. >> > >

Re: [RFC PATCH 0/2] net: threadable napi poll loop

On 10.05.2016 23:09, Eric Dumazet wrote: > On Tue, May 10, 2016 at 1:46 PM, Hannes Frederic Sowa > wrote: > >> I agree here, but I don't think this patch particularly is a lot of >> bloat and something very interesting people can play with and extend upon. >> > > Sure, very rarely patch authors

Re: [PATCH -v2] x86/hweight: Get rid of the special calling convention

On 05/10/16 12:10, Borislav Petkov wrote: > On Tue, May 10, 2016 at 12:03:48PM -0700, H. Peter Anvin wrote: >> Also, to be fair... if the problem is with these being in C then we >> could just do it in assembly easily enough. > > I thought about converting the __sw_hweight* variants to asm but >

Re: [PATCH -v2] x86/hweight: Get rid of the special calling convention

On 05/10/16 12:10, Borislav Petkov wrote: > On Tue, May 10, 2016 at 12:03:48PM -0700, H. Peter Anvin wrote: >> Also, to be fair... if the problem is with these being in C then we >> could just do it in assembly easily enough. > > I thought about converting the __sw_hweight* variants to asm but >

Re: [PATCH] arm64: dts: qcom: Add msm8916 PMU node

I think you should be sending your patches to linux-arm-kernel rather than linux-arm... On Tue, May 10, 2016 at 03:01:49PM -0700, Stephen Boyd wrote: > Add the PMU so we can get proper perf event support on this SoC. > > Signed-off-by: Stephen Boyd > --- >

Re: [PATCH] arm64: dts: qcom: Add msm8916 PMU node

I think you should be sending your patches to linux-arm-kernel rather than linux-arm... On Tue, May 10, 2016 at 03:01:49PM -0700, Stephen Boyd wrote: > Add the PMU so we can get proper perf event support on this SoC. > > Signed-off-by: Stephen Boyd > --- > arch/arm64/boot/dts/qcom/msm8916.dtsi

[RFC/PATCHv3 v3 2/3] firmware: Provide infrastructure to make fw caching optional

From: Vikram Mulukutla Some low memory systems with complex peripherals cannot afford to have the relatively large firmware images taking up valuable memory during suspend and resume. Change the internal implementation of firmware_class to disallow caching based on a

[RFC/PATCHv3 v3 2/3] firmware: Provide infrastructure to make fw caching optional

From: Vikram Mulukutla Some low memory systems with complex peripherals cannot afford to have the relatively large firmware images taking up valuable memory during suspend and resume. Change the internal implementation of firmware_class to disallow caching based on a configurable option. In the

[RFC/PATCHv3 v3 3/3] firmware: Support loading into a pre-allocated buffer

Some systems are memory constrained but they need to load very large firmwares. The firmware subsystem allows drivers to request this firmware be loaded from the filesystem, but this requires that the entire firmware be loaded into kernel memory first before it's provided to the driver. This can

[RFC/PATCHv3 v3 0/3] request_firmware() into pre-allocated buffers

Some systems are memory constrained but they need to load very large firmwares. The firmware subsystem allows drivers to request this firmware be loaded from the filesystem, but this requires that the entire firmware be loaded into kernel memory first before it's provided to the driver. This can

[RFC/PATCHv3 v3 3/3] firmware: Support loading into a pre-allocated buffer

Some systems are memory constrained but they need to load very large firmwares. The firmware subsystem allows drivers to request this firmware be loaded from the filesystem, but this requires that the entire firmware be loaded into kernel memory first before it's provided to the driver. This can

[RFC/PATCHv3 v3 0/3] request_firmware() into pre-allocated buffers

Some systems are memory constrained but they need to load very large firmwares. The firmware subsystem allows drivers to request this firmware be loaded from the filesystem, but this requires that the entire firmware be loaded into kernel memory first before it's provided to the driver. This can

[RFC/PATCHv3 v3 1/3] firmware: Consolidate kmap/read/write logic

We use similar structured code to read and write the kmapped firmware pages. The only difference is read copies from the kmap region and write copies to it. Consolidate this into one function to reduce duplication. Cc: Vikram Mulukutla Signed-off-by: Stephen Boyd

[RFC/PATCHv3 v3 1/3] firmware: Consolidate kmap/read/write logic

We use similar structured code to read and write the kmapped firmware pages. The only difference is read copies from the kmap region and write copies to it. Consolidate this into one function to reduce duplication. Cc: Vikram Mulukutla Signed-off-by: Stephen Boyd ---

Re: [PATCH] kbuild: move -Wunused-const-variable to W=1 warning level

On Tue, May 10, 2016 at 2:30 PM, Arnd Bergmann wrote: > gcc-6 started warning by default about variables that are not > used anywhere and that are marked 'const', generating many > false positives in an allmodconfig build, e.g.: > > arch/arm/mach-davinci/board-da830-evm.c:282:20:

Re: [PATCH] kbuild: move -Wunused-const-variable to W=1 warning level

On Tue, May 10, 2016 at 2:30 PM, Arnd Bergmann wrote: > gcc-6 started warning by default about variables that are not > used anywhere and that are marked 'const', generating many > false positives in an allmodconfig build, e.g.: > > arch/arm/mach-davinci/board-da830-evm.c:282:20: warning: >

Re: [PATCH 2/3] sched,fair: Fix local starvation

On Tue, May 10, 2016 at 10:21:39PM +0200, Ingo Molnar wrote: > > * Peter Zijlstra wrote: > > > Mike reported that the recent commit 3a47d5124a95 ("sched/fair: Fix > > fairness issue on migration") broke interactivity and the signal > > starve test. > > This looks pretty

Re: [PATCH 2/3] sched,fair: Fix local starvation

On Tue, May 10, 2016 at 10:21:39PM +0200, Ingo Molnar wrote: > > * Peter Zijlstra wrote: > > > Mike reported that the recent commit 3a47d5124a95 ("sched/fair: Fix > > fairness issue on migration") broke interactivity and the signal > > starve test. > > This looks pretty dangerous for v4.6 -

Re: [PATCH] media: dvb_ringbuffer: Add memory barriers

On 05/07/16 15:26, Mauro Carvalho Chehab wrote: Em Sat, 7 May 2016 10:22:35 -0300 Mauro Carvalho Chehab escreveu: Hi Soeren, Em Sun, 7 Feb 2016 20:22:36 +0100 Soeren Moch escreveu: On 27.12.2015 21:41, Soeren Moch wrote: Implement memory barriers

Re: [PATCH] media: dvb_ringbuffer: Add memory barriers

On 05/07/16 15:26, Mauro Carvalho Chehab wrote: Em Sat, 7 May 2016 10:22:35 -0300 Mauro Carvalho Chehab escreveu: Hi Soeren, Em Sun, 7 Feb 2016 20:22:36 +0100 Soeren Moch escreveu: On 27.12.2015 21:41, Soeren Moch wrote: Implement memory barriers according to

<    1   2   3   4   5   6   7   8   9   10   >