Re: [PATCH V2 25/37] perf script: Add synthesized Intel PT power and ptwrite events

Em Thu, Jun 29, 2017 at 05:13:54PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Thu, Jun 29, 2017 at 10:56:25PM +0300, Adrian Hunter escreveu: > > On 06/28/2017 11:26 PM, Arnaldo Carvalho de Melo wrote: > > > Right, and I've not been able to focus on this, but I think the problem > > > is with

Re: [PATCH V2 25/37] perf script: Add synthesized Intel PT power and ptwrite events

Em Thu, Jun 29, 2017 at 05:13:54PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Thu, Jun 29, 2017 at 10:56:25PM +0300, Adrian Hunter escreveu: > > On 06/28/2017 11:26 PM, Arnaldo Carvalho de Melo wrote: > > > Right, and I've not been able to focus on this, but I think the problem > > > is with

linux-next: manual merge of the block tree with Linus' tree

Hi Jens, Today's linux-next merge of the block tree got a conflict in: fs/block_dev.c between commit: 9ae3b3f52c62 ("block: provide bio_uninit() free freeing integrity/task associations") from Linus' tree and commit: 4e4cbee93d56 ("block: switch bios to blk_status_t") from the block

linux-next: manual merge of the block tree with Linus' tree

Hi Jens, Today's linux-next merge of the block tree got a conflict in: fs/block_dev.c between commit: 9ae3b3f52c62 ("block: provide bio_uninit() free freeing integrity/task associations") from Linus' tree and commit: 4e4cbee93d56 ("block: switch bios to blk_status_t") from the block

[PATCH] f2fs: introduce __check_sit_bitmap

After we introduce discard thread, discard command can be issued concurrently with data allocating, this patch adds new function to heck sit bitmap to ensure that userdata was invalid in which on-going discard command covered. Signed-off-by: Chao Yu --- fs/f2fs/segment.c |

[PATCH] f2fs: introduce __check_sit_bitmap

After we introduce discard thread, discard command can be issued concurrently with data allocating, this patch adds new function to heck sit bitmap to ensure that userdata was invalid in which on-going discard command covered. Signed-off-by: Chao Yu --- fs/f2fs/segment.c | 28

[RFC][PATCH] sched: attach extra runtime to the right avg

From: Josef Bacik We only track the load avg of a se in 1024 ns chunks, so in order to make up for the loss of the < 1024 ns part of a run/sleep delta we only add the time we processed to the se->avg.last_update_time. The problem is there is no way to know if this extra time was

[RFC][PATCH] sched: attach extra runtime to the right avg

From: Josef Bacik We only track the load avg of a se in 1024 ns chunks, so in order to make up for the loss of the < 1024 ns part of a run/sleep delta we only add the time we processed to the se->avg.last_update_time. The problem is there is no way to know if this extra time was while we were

Re: [PATCH 5/5] sched: Accumulate vtime on top of nsec clocksource

2017-06-30 1:15 GMT+08:00 Frederic Weisbecker : > From: Wanpeng Li From: Wanpeng Li > > Currently the cputime source used by vtime is jiffies. When we cross > a context boundary and jiffies have changed since the last snapshot,

Re: [PATCH 5/5] sched: Accumulate vtime on top of nsec clocksource

2017-06-30 1:15 GMT+08:00 Frederic Weisbecker : > From: Wanpeng Li From: Wanpeng Li > > Currently the cputime source used by vtime is jiffies. When we cross > a context boundary and jiffies have changed since the last snapshot, the > pending cputime is accounted to the switching out context. >

Re: linux-next: build failure after merge of the sound-asoc tree

Hi Bard, On Thu, 29 Jun 2017 02:01:16 + Bard Liao wrote: > > > -Original Message- > > From: Stephen Rothwell [mailto:s...@canb.auug.org.au] > > Sent: Thursday, June 29, 2017 9:54 AM > > To: Mark Brown; Liam Girdwood > > Cc: Linux-Next Mailing List; Linux Kernel

Re: linux-next: build failure after merge of the sound-asoc tree

Hi Bard, On Thu, 29 Jun 2017 02:01:16 + Bard Liao wrote: > > > -Original Message- > > From: Stephen Rothwell [mailto:s...@canb.auug.org.au] > > Sent: Thursday, June 29, 2017 9:54 AM > > To: Mark Brown; Liam Girdwood > > Cc: Linux-Next Mailing List; Linux Kernel Mailing List; Bard

RE: [PATCH v3] acpi/nfit: Issue Start ARS to retrieve existing records

> > ACPI 6.2 defines in section 9.20.7.2 that the OSPM may call a Start > > ARS with Flags Bit [1] set upon receiving the 0x81 notification. > > > > Upon receiving the notification, the OSPM may decide to issue > > a Start ARS with Flags Bit [1] set to prepare for the retrieval > > of

RE: [PATCH v3] acpi/nfit: Issue Start ARS to retrieve existing records

> > ACPI 6.2 defines in section 9.20.7.2 that the OSPM may call a Start > > ARS with Flags Bit [1] set upon receiving the 0x81 notification. > > > > Upon receiving the notification, the OSPM may decide to issue > > a Start ARS with Flags Bit [1] set to prepare for the retrieval > > of

[PATCH -mm -v2 0/6] mm, swap: VMA based swap readahead

The swap readahead is an important mechanism to reduce the swap in latency. Although pure sequential memory access pattern isn't very popular for anonymous memory, the space locality is still considered valid. In the original swap readahead implementation, the consecutive blocks in swap device

[PATCH -mm -v2 0/6] mm, swap: VMA based swap readahead

The swap readahead is an important mechanism to reduce the swap in latency. Although pure sequential memory access pattern isn't very popular for anonymous memory, the space locality is still considered valid. In the original swap readahead implementation, the consecutive blocks in swap device

[PATCH -mm -v2 5/6] mm, swap: Add sysfs interface for VMA based swap readahead

From: Huang Ying The sysfs interface to control the VMA based swap readahead is added as follow, /sys/kernel/mm/swap/vma_ra_enabled Enable the VMA based swap readahead algorithm, or use the original global swap readahead algorithm. /sys/kernel/mm/swap/vma_ra_max_order

[PATCH -mm -v2 5/6] mm, swap: Add sysfs interface for VMA based swap readahead

From: Huang Ying The sysfs interface to control the VMA based swap readahead is added as follow, /sys/kernel/mm/swap/vma_ra_enabled Enable the VMA based swap readahead algorithm, or use the original global swap readahead algorithm. /sys/kernel/mm/swap/vma_ra_max_order Set the max order of

[PATCH -mm -v2 1/6] mm, swap: Add swap cache statistics sysfs interface

From: Huang Ying The swap cache stats could be gotten only via sysrq, which isn't convenient in some situation. So the sysfs interface of swap cache stats is added for that. The added sysfs directories/files are as follow, /sys/kernel/mm/swap

[PATCH -mm -v2 1/6] mm, swap: Add swap cache statistics sysfs interface

From: Huang Ying The swap cache stats could be gotten only via sysrq, which isn't convenient in some situation. So the sysfs interface of swap cache stats is added for that. The added sysfs directories/files are as follow, /sys/kernel/mm/swap /sys/kernel/mm/swap/cache_find_total

[PATCH -mm -v2 4/6] mm, swap: VMA based swap readahead

From: Huang Ying The swap readahead is an important mechanism to reduce the swap in latency. Although pure sequential memory access pattern isn't very popular for anonymous memory, the space locality is still considered valid. In the original swap readahead

[PATCH -mm -v2 4/6] mm, swap: VMA based swap readahead

From: Huang Ying The swap readahead is an important mechanism to reduce the swap in latency. Although pure sequential memory access pattern isn't very popular for anonymous memory, the space locality is still considered valid. In the original swap readahead implementation, the consecutive

[PATCH -mm -v2 6/6] mm, swap: Don't use VMA based swap readahead if HDD is used as swap

From: Huang Ying VMA based swap readahead will readahead the virtual pages that is continuous in the virtual address space. While the original swap readahead will readahead the swap slots that is continuous in the swap device. Although VMA based swap readahead is more

[PATCH -mm -v2 2/6] mm, swap: Add swap readahead hit statistics

From: Huang Ying The statistics for total readahead pages and total readahead hits are recorded and exported via the following sysfs interface. /sys/kernel/mm/swap/ra_hits /sys/kernel/mm/swap/ra_total With them, the efficiency of the swap readahead could be measured, so

[PATCH -mm -v2 3/6] mm, swap: Fix swap readahead marking

From: Huang Ying In the original implementation, it is possible that the existing pages in the swap cache (not newly readahead) could be marked as the readahead pages. This will cause the statistics of swap readahead be wrong and influence the swap readahead algorithm too.

Re: [PATCH V1 7/9] clk: sprd: add adjustable pll support

On 06/22, Chunyan Zhang wrote: > On 20 June 2017 at 09:37, Stephen Boyd wrote: > > On 06/18, Chunyan Zhang wrote: > >> diff --git a/drivers/clk/sprd/Makefile b/drivers/clk/sprd/Makefile > >> index 83232e5..c593a93 100644 > >> --- a/drivers/clk/sprd/Makefile > >> +++

[PATCH -mm -v2 6/6] mm, swap: Don't use VMA based swap readahead if HDD is used as swap

From: Huang Ying VMA based swap readahead will readahead the virtual pages that is continuous in the virtual address space. While the original swap readahead will readahead the swap slots that is continuous in the swap device. Although VMA based swap readahead is more correct for the swap

[PATCH -mm -v2 2/6] mm, swap: Add swap readahead hit statistics

From: Huang Ying The statistics for total readahead pages and total readahead hits are recorded and exported via the following sysfs interface. /sys/kernel/mm/swap/ra_hits /sys/kernel/mm/swap/ra_total With them, the efficiency of the swap readahead could be measured, so that the swap readahead

[PATCH -mm -v2 3/6] mm, swap: Fix swap readahead marking

From: Huang Ying In the original implementation, it is possible that the existing pages in the swap cache (not newly readahead) could be marked as the readahead pages. This will cause the statistics of swap readahead be wrong and influence the swap readahead algorithm too. This is fixed via

Re: [PATCH V1 7/9] clk: sprd: add adjustable pll support

On 06/22, Chunyan Zhang wrote: > On 20 June 2017 at 09:37, Stephen Boyd wrote: > > On 06/18, Chunyan Zhang wrote: > >> diff --git a/drivers/clk/sprd/Makefile b/drivers/clk/sprd/Makefile > >> index 83232e5..c593a93 100644 > >> --- a/drivers/clk/sprd/Makefile > >> +++ b/drivers/clk/sprd/Makefile >

Re: WARNING: CPU: 3 PID: 0 at kernel/cgroup/cgroup.c:441 cgroup_get+0x4b/0x50

On Thu, Jun 29, 2017 at 12:26 AM, Justin Piszcz wrote: > Hello, > > Kernel: 4.11.0 > Arch: x86_64 > > First time I have run into a WARN in a while, .config is attached: > > $ cp /proc/config.gz . > > Snippet: > > [22606.516656] [ cut here ] >

Re: WARNING: CPU: 3 PID: 0 at kernel/cgroup/cgroup.c:441 cgroup_get+0x4b/0x50

On Thu, Jun 29, 2017 at 12:26 AM, Justin Piszcz wrote: > Hello, > > Kernel: 4.11.0 > Arch: x86_64 > > First time I have run into a WARN in a while, .config is attached: > > $ cp /proc/config.gz . > > Snippet: > > [22606.516656] [ cut here ] > [22606.516669] WARNING: CPU: 3

Re: [PATCH V1 3/9] clk: sprd: add gate clock support

On 06/22, Chunyan Zhang wrote: > On 20 June 2017 at 09:31, Stephen Boyd wrote: > > On 06/18, Chunyan Zhang wrote: > >> diff --git a/drivers/clk/sprd/Makefile b/drivers/clk/sprd/Makefile > >> index 8f802b2..333e2b2 100644 > >> --- a/drivers/clk/sprd/Makefile > >> +++

Re: [PATCH V1 3/9] clk: sprd: add gate clock support

On 06/22, Chunyan Zhang wrote: > On 20 June 2017 at 09:31, Stephen Boyd wrote: > > On 06/18, Chunyan Zhang wrote: > >> diff --git a/drivers/clk/sprd/Makefile b/drivers/clk/sprd/Makefile > >> index 8f802b2..333e2b2 100644 > >> --- a/drivers/clk/sprd/Makefile > >> +++ b/drivers/clk/sprd/Makefile >

Re: [kernel-hardening] [RFC PATCH 1/4] Provide linux/set_memory.h

Kees Cook writes: > On Thu, Jun 29, 2017 at 2:03 AM, Daniel Borkmann wrote: >> On 06/29/2017 08:29 AM, Michael Ellerman wrote: >>> >>> Currently code that wants to use set_memory_ro() etc, needs to include >>> asm/set_memory.h, which doesn't exist on

Re: [kernel-hardening] [RFC PATCH 1/4] Provide linux/set_memory.h

Kees Cook writes: > On Thu, Jun 29, 2017 at 2:03 AM, Daniel Borkmann wrote: >> On 06/29/2017 08:29 AM, Michael Ellerman wrote: >>> >>> Currently code that wants to use set_memory_ro() etc, needs to include >>> asm/set_memory.h, which doesn't exist on all arches. Some code knows >>> it only

Re: [PATCH V1 8/9] clk: sprd: add clocks support for SC9860

On 06/22, Chunyan Zhang wrote: > Hi Stephen, > > On 20 June 2017 at 09:41, Stephen Boyd wrote: > > On 06/18, Chunyan Zhang wrote: > >> +++ b/include/dt-bindings/clock/sc9860-ccu.h > >> @@ -0,0 +1,19 @@ > >> +/* > >> + * Spreadtrum SC9860 platform clocks > >> + * > >> + *

Re: [PATCH V1 8/9] clk: sprd: add clocks support for SC9860

On 06/22, Chunyan Zhang wrote: > Hi Stephen, > > On 20 June 2017 at 09:41, Stephen Boyd wrote: > > On 06/18, Chunyan Zhang wrote: > >> +++ b/include/dt-bindings/clock/sc9860-ccu.h > >> @@ -0,0 +1,19 @@ > >> +/* > >> + * Spreadtrum SC9860 platform clocks > >> + * > >> + * Copyright (C) 2017,

Re: [RFC PATCH 0/5] vtime: Fix wrong user and system time accounting

Hi Luiz, 2017-06-30 1:15 GMT+08:00 Frederic Weisbecker : > Hi, > > This is a proposition to fix > "[BUG nohz]: wrong user and system time accounting": > http://lkml.kernel.org/r/20170323165512.60945...@redhat.com > > I took Wanpeng Li's last patch and enhanced around

Re: [RFC PATCH 0/5] vtime: Fix wrong user and system time accounting

Hi Luiz, 2017-06-30 1:15 GMT+08:00 Frederic Weisbecker : > Hi, > > This is a proposition to fix > "[BUG nohz]: wrong user and system time accounting": > http://lkml.kernel.org/r/20170323165512.60945...@redhat.com > > I took Wanpeng Li's last patch and enhanced around it. > >

Re: [PATCH] libnvdimm, btt: fix btt_rw_page not returning errors

On Thu, Jun 29, 2017 at 3:59 PM, Vishal Verma wrote: > btt_rw_page was not propagating errors frm btt_do_bvec, resulting in any > IO errors via the rw_page path going unnoticed. the pmem driver recently > fixed this in e10624f pmem: fail io-requests to known bad blocks >

Re: [PATCH] libnvdimm, btt: fix btt_rw_page not returning errors

On Thu, Jun 29, 2017 at 3:59 PM, Vishal Verma wrote: > btt_rw_page was not propagating errors frm btt_do_bvec, resulting in any > IO errors via the rw_page path going unnoticed. the pmem driver recently > fixed this in e10624f pmem: fail io-requests to known bad blocks > but same problem in BTT

Re: [PATCH 0/3] KVM: lapic: optimize injection of already-expired timer

2017-06-30 0:58 GMT+08:00 Paolo Bonzini : > This is my take on Wanpeng's optimization, whose effect I've now measured > with vmexit.flat. Indeed, without patch 3 the new tscdeadline_immed > benchmark is 50% slower with preemption_timer=1 than with preemption_timer=0. > >

Re: [PATCH 0/3] KVM: lapic: optimize injection of already-expired timer

2017-06-30 0:58 GMT+08:00 Paolo Bonzini : > This is my take on Wanpeng's optimization, whose effect I've now measured > with vmexit.flat. Indeed, without patch 3 the new tscdeadline_immed > benchmark is 50% slower with preemption_timer=1 than with preemption_timer=0. > > Patch 1 refactors

Re: [RFC PATCH] pinctrl: rockchip: add irq_shutdown

On Fri, Jun 30, 2017 at 09:24:54AM +0800, Jeffy Chen wrote: > On 06/30/2017 06:05 AM, Brian Norris wrote: > >On Fri, Jun 23, 2017 at 09:03:39PM +0800, Jeffy Chen wrote: > >>Currently the rockchip pinctrl driver would try to enable/disable the > >>gpio bank clk when enable/disable an irq. > >> >

Re: [RFC PATCH] pinctrl: rockchip: add irq_shutdown

On Fri, Jun 30, 2017 at 09:24:54AM +0800, Jeffy Chen wrote: > On 06/30/2017 06:05 AM, Brian Norris wrote: > >On Fri, Jun 23, 2017 at 09:03:39PM +0800, Jeffy Chen wrote: > >>Currently the rockchip pinctrl driver would try to enable/disable the > >>gpio bank clk when enable/disable an irq. > >> >

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On Thu, Jun 29, 2017 at 4:14 PM, Linda Knippers wrote: > On 06/29/2017 06:58 PM, Dan Williams wrote: >> On Thu, Jun 29, 2017 at 3:49 PM, Linda Knippers >> wrote: The parent region of the namespace will have a 'volatile' type: # cat

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On Thu, Jun 29, 2017 at 4:14 PM, Linda Knippers wrote: > On 06/29/2017 06:58 PM, Dan Williams wrote: >> On Thu, Jun 29, 2017 at 3:49 PM, Linda Knippers >> wrote: The parent region of the namespace will have a 'volatile' type: # cat /sys/bus/nd/devices/region0/devtype

Inconsistency in scripts/checkpatch.pl

Andy and Joe, In some new rtlwifi code, I get the following for one of the new macros: CHECK: Macro argument '__h2c' may be better as '(__h2c)' to avoid precedence issues #45005: FILE: drivers/net/wireless/realtek/rtlwifi/halmac/halmac_original_h2c_nic.h:1163: +#define

Inconsistency in scripts/checkpatch.pl

Andy and Joe, In some new rtlwifi code, I get the following for one of the new macros: CHECK: Macro argument '__h2c' may be better as '(__h2c)' to avoid precedence issues #45005: FILE: drivers/net/wireless/realtek/rtlwifi/halmac/halmac_original_h2c_nic.h:1163: +#define

Re: [PATCH v3 4/7] acpi, nfit: Use bus_dsm_mask for passthru

On Thu, Jun 29, 2017 at 4:26 PM, Jerry Hoemann wrote: > On Thu, Jun 29, 2017 at 02:55:55PM -0700, Dan Williams wrote: >> On Thu, Jun 29, 2017 at 2:47 PM, Jerry Hoemann wrote: >> > On Thu, Jun 29, 2017 at 02:35:14PM -0700, Dan Williams wrote: >> >> On

Re: [PATCH v3 4/7] acpi, nfit: Use bus_dsm_mask for passthru

On Thu, Jun 29, 2017 at 4:26 PM, Jerry Hoemann wrote: > On Thu, Jun 29, 2017 at 02:55:55PM -0700, Dan Williams wrote: >> On Thu, Jun 29, 2017 at 2:47 PM, Jerry Hoemann wrote: >> > On Thu, Jun 29, 2017 at 02:35:14PM -0700, Dan Williams wrote: >> >> On Thu, Jun 29, 2017 at 9:56 AM, Jerry Hoemann

[PATCH] mwifiex: correct channel stat buffer overflows

mwifiex records information about various channels as it receives scan information. It does this by appending to a buffer that was sized to the max number of supported channels on any band, but there are numerous problems: (a) scans can return info from more than one band (e.g., both 2.4 and 5

[PATCH] mwifiex: correct channel stat buffer overflows

mwifiex records information about various channels as it receives scan information. It does this by appending to a buffer that was sized to the max number of supported channels on any band, but there are numerous problems: (a) scans can return info from more than one band (e.g., both 2.4 and 5

Re: [RFC PATCH] pinctrl: rockchip: add irq_shutdown

Hi brian, On 06/30/2017 06:05 AM, Brian Norris wrote: On Fri, Jun 23, 2017 at 09:03:39PM +0800, Jeffy Chen wrote: Currently the rockchip pinctrl driver would try to enable/disable the gpio bank clk when enable/disable an irq. So when the irq core trying to shutdown an already disabled irq, it

Re: [PATCH 0/4] pinctrl: Add USB support for Aspeed SoCs

On Thu, 2017-06-29 at 14:53 +0200, Linus Walleij wrote: > > On Tue, Jun 27, 2017 at 4:12 AM, Andrew Jeffery wrote: > > > With recent interest in the USB virtual hub in the Aspeed SoCs[1] it is a > > good > > time to add pinmux support for the USB ports and controllers. The

Re: [RFC PATCH] pinctrl: rockchip: add irq_shutdown

Hi brian, On 06/30/2017 06:05 AM, Brian Norris wrote: On Fri, Jun 23, 2017 at 09:03:39PM +0800, Jeffy Chen wrote: Currently the rockchip pinctrl driver would try to enable/disable the gpio bank clk when enable/disable an irq. So when the irq core trying to shutdown an already disabled irq, it

Re: [PATCH 0/4] pinctrl: Add USB support for Aspeed SoCs

On Thu, 2017-06-29 at 14:53 +0200, Linus Walleij wrote: > > On Tue, Jun 27, 2017 at 4:12 AM, Andrew Jeffery wrote: > > > With recent interest in the USB virtual hub in the Aspeed SoCs[1] it is a > > good > > time to add pinmux support for the USB ports and controllers. The earlier > > series of

Re: [PATCH] mm/zsmalloc: simplify zs_max_alloc_size handling

Hi Jerome, On Wed, Jun 28, 2017 at 10:14:20AM +0200, Jerome Marchand wrote: > Commit 40f9fb8cffc6 ("mm/zsmalloc: support allocating obj with size of > ZS_MAX_ALLOC_SIZE") fixes a size calculation error that prevented > zsmalloc to allocate an object of the maximal size > (ZS_MAX_ALLOC_SIZE). I

Re: [PATCH] mm/zsmalloc: simplify zs_max_alloc_size handling

Hi Jerome, On Wed, Jun 28, 2017 at 10:14:20AM +0200, Jerome Marchand wrote: > Commit 40f9fb8cffc6 ("mm/zsmalloc: support allocating obj with size of > ZS_MAX_ALLOC_SIZE") fixes a size calculation error that prevented > zsmalloc to allocate an object of the maximal size > (ZS_MAX_ALLOC_SIZE). I

[PATCH v2] moduleparam: fix doc: hwparam_irq configures an IRQ

v2: Add Cc in commit message Signed-off-by: Sylvain 'ythier' Hitier Cc: triv...@kernel.org --- include/linux/moduleparam.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h index

[PATCH v2] moduleparam: fix doc: hwparam_irq configures an IRQ

v2: Add Cc in commit message Signed-off-by: Sylvain 'ythier' Hitier Cc: triv...@kernel.org --- include/linux/moduleparam.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h index 6be1949..1ee7b30 100644 ---

Re: [PATCH 1/4] ARM: aspeed: g4: Add USB functions to pinctrl bindings

On Mon, 2017-06-26 at 22:53 -0500, Benjamin Herrenschmidt wrote: > On Tue, 2017-06-27 at 11:42 +0930, Andrew Jeffery wrote: > > The AST2400 contains several USB controllers: > > > > * USB 1.1 Host Controller > > * USB 2.0 Host Controller > > * Combined USB 2.0 Virtual Hub and USB 1.1 HID

Re: [PATCH 1/4] ARM: aspeed: g4: Add USB functions to pinctrl bindings

On Mon, 2017-06-26 at 22:53 -0500, Benjamin Herrenschmidt wrote: > On Tue, 2017-06-27 at 11:42 +0930, Andrew Jeffery wrote: > > The AST2400 contains several USB controllers: > > > > * USB 1.1 Host Controller > > * USB 2.0 Host Controller > > * Combined USB 2.0 Virtual Hub and USB 1.1 HID

Re: [PATCH 2/4] ARM: aspeed: g5: Add USB functions to pinctrl bindings

On Thu, 2017-06-29 at 15:32 -0500, Rob Herring wrote: > On Thu, Jun 29, 2017 at 03:13:24PM -0500, Rob Herring wrote: > > On Tue, Jun 27, 2017 at 11:42:12AM +0930, Andrew Jeffery wrote: > > > The Aspeed AST2500 SoC contains a number of USB controllers: > > > > > > * USB 1.1 Host Controller > > > *

Re: [PATCH 2/4] ARM: aspeed: g5: Add USB functions to pinctrl bindings

On Thu, 2017-06-29 at 15:32 -0500, Rob Herring wrote: > On Thu, Jun 29, 2017 at 03:13:24PM -0500, Rob Herring wrote: > > On Tue, Jun 27, 2017 at 11:42:12AM +0930, Andrew Jeffery wrote: > > > The Aspeed AST2500 SoC contains a number of USB controllers: > > > > > > * USB 1.1 Host Controller > > > *

Re: [PATCH 2/2] mm, memory_hotplug: remove zone restrictions

On Thu, Jun 29, 2017 at 09:35:09AM +0200, Michal Hocko wrote: > From: Michal Hocko > > Historically we have enforced that any kernel zone (e.g ZONE_NORMAL) has > to precede the Movable zone in the physical memory range. The purpose of > the movable zone is, however, not bound to

Re: [PATCH 2/2] mm, memory_hotplug: remove zone restrictions

On Thu, Jun 29, 2017 at 09:35:09AM +0200, Michal Hocko wrote: > From: Michal Hocko > > Historically we have enforced that any kernel zone (e.g ZONE_NORMAL) has > to precede the Movable zone in the physical memory range. The purpose of > the movable zone is, however, not bound to any physical

Re: [PATCH v1 1/2] dt-binding: ptp: add bindings document for dte based ptp clock

Hi Rob, On 17-06-29 03:40 PM, Rob Herring wrote: On Tue, Jun 27, 2017 at 12:10 AM, Scott Branden wrote: Hi Rob/Florian, Thanks for input but still don't see any need for SoC specific compatible stings. IP revision specific yes. On 17-06-22 06:04 PM, Florian

Re: [PATCH v1 1/2] dt-binding: ptp: add bindings document for dte based ptp clock

Hi Rob, On 17-06-29 03:40 PM, Rob Herring wrote: On Tue, Jun 27, 2017 at 12:10 AM, Scott Branden wrote: Hi Rob/Florian, Thanks for input but still don't see any need for SoC specific compatible stings. IP revision specific yes. On 17-06-22 06:04 PM, Florian Fainelli wrote: On 06/22/2017

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

Hi all, Today's linux-next merge of the net-next tree got a conflict in: drivers/net/ethernet/rocker/rocker_ofdpa.c between commit: acb4b7df48b5 ("rocker: move dereference before free") from Linus' tree and commit: 00fc0c51e35b ("rocker: Change world_ops API and implementation to be

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

Hi all, Today's linux-next merge of the net-next tree got a conflict in: drivers/net/ethernet/rocker/rocker_ofdpa.c between commit: acb4b7df48b5 ("rocker: move dereference before free") from Linus' tree and commit: 00fc0c51e35b ("rocker: Change world_ops API and implementation to be

Re: [PATCH V1 9/9] arm64: dts: add ccu for SC9860

On 06/22, Chunyan Zhang wrote: > Hi Stephen, > > On 20 June 2017 at 09:24, Stephen Boyd wrote: > > On 06/18, Chunyan Zhang wrote: > > > > >> + compatible = "sprd,sc9860-ccu"; > >> + #clock-cells = <1>; > >> + reg = <0 0x2000 0

Re: [PATCH V1 9/9] arm64: dts: add ccu for SC9860

On 06/22, Chunyan Zhang wrote: > Hi Stephen, > > On 20 June 2017 at 09:24, Stephen Boyd wrote: > > On 06/18, Chunyan Zhang wrote: > > > > >> + compatible = "sprd,sc9860-ccu"; > >> + #clock-cells = <1>; > >> + reg = <0 0x2000 0 0x400>, > >> +

[PATCH 6/6] i2c: pca-platform: drop gpio from platform data

Now that the i2c-pca-plaform driver is using the device managed API for gpios there is no need for the reset gpio to be specified via i2c_pca9564_pf_platform_data. Signed-off-by: Chris Packham --- arch/blackfin/mach-bf561/boards/acvilon.c | 1 -

[PATCH 6/6] i2c: pca-platform: drop gpio from platform data

Now that the i2c-pca-plaform driver is using the device managed API for gpios there is no need for the reset gpio to be specified via i2c_pca9564_pf_platform_data. Signed-off-by: Chris Packham --- arch/blackfin/mach-bf561/boards/acvilon.c | 1 - arch/sh/boards/board-sh7785lcr.c | 1 -

[PATCH 1/6] sh: sh7785lcr: add GPIO lookup table for i2c controller reset

Define the GPIO connected to the PCA9564 using a GPIO lookup table. This will allow the i2c-pca-platform driver to use the device managed APIs to lookup the gpio instead of using platform_data. Signed-off-by: Chris Packham --- arch/sh/boards/board-sh7785lcr.c

[PATCH 5/6] i2c: pca-platform: use device_property_read_u32

Use device_property_read_u32 instead of of_property_read_u32_index to lookup the "clock-frequency" property. Signed-off-by: Chris Packham --- drivers/i2c/busses/i2c-pca-platform.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git

[PATCH 1/6] sh: sh7785lcr: add GPIO lookup table for i2c controller reset

Define the GPIO connected to the PCA9564 using a GPIO lookup table. This will allow the i2c-pca-platform driver to use the device managed APIs to lookup the gpio instead of using platform_data. Signed-off-by: Chris Packham --- arch/sh/boards/board-sh7785lcr.c | 10 ++ 1 file changed, 10

[PATCH 5/6] i2c: pca-platform: use device_property_read_u32

Use device_property_read_u32 instead of of_property_read_u32_index to lookup the "clock-frequency" property. Signed-off-by: Chris Packham --- drivers/i2c/busses/i2c-pca-platform.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/i2c/busses/i2c-pca-platform.c

[PATCH 3/6] i2c: pca-platform: propagate error from i2c_pca_add_numbered_bus

Rather than returning -ENODEV if i2c_pca_add_numbered_bus() fails, propagate the error to aid debugging. Signed-off-by: Chris Packham --- drivers/i2c/busses/i2c-pca-platform.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

[PATCH 2/6] i2c: pca-platform: correctly set algo_data.reset_chip

When device tree support was added the setting of algo_data.reset_chip was moved. There were two problems with this. The first being that i2c_pca_pf_resetchip was only used if platform data was provided. The second that it was unconditionally overridden with i2c_pca_pf_dummyreset. Ensure that

[PATCH 3/6] i2c: pca-platform: propagate error from i2c_pca_add_numbered_bus

Rather than returning -ENODEV if i2c_pca_add_numbered_bus() fails, propagate the error to aid debugging. Signed-off-by: Chris Packham --- drivers/i2c/busses/i2c-pca-platform.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/busses/i2c-pca-platform.c

[PATCH 2/6] i2c: pca-platform: correctly set algo_data.reset_chip

When device tree support was added the setting of algo_data.reset_chip was moved. There were two problems with this. The first being that i2c_pca_pf_resetchip was only used if platform data was provided. The second that it was unconditionally overridden with i2c_pca_pf_dummyreset. Ensure that

[PATCH 4/6] i2c: pca-platform: unconditionally use devm_gpiod_get_optional

Allow for the reset-gpios property to be defined in the device tree or via a GPIO lookup table. Signed-off-by: Chris Packham --- drivers/i2c/busses/i2c-pca-platform.c | 21 - 1 file changed, 4 insertions(+), 17 deletions(-) diff --git

[PATCH 4/6] i2c: pca-platform: unconditionally use devm_gpiod_get_optional

Allow for the reset-gpios property to be defined in the device tree or via a GPIO lookup table. Signed-off-by: Chris Packham --- drivers/i2c/busses/i2c-pca-platform.c | 21 - 1 file changed, 4 insertions(+), 17 deletions(-) diff --git a/drivers/i2c/busses/i2c-pca-platform.c

Re: [PATCH] cma: fix calculation of aligned offset

On Thu, 29 Jun 2017 17:43:18 -0700 Doug Berger wrote: > On 06/29/2017 01:48 PM, Andrew Morton wrote: > > On Wed, 28 Jun 2017 10:07:41 -0700 Doug Berger wrote: > > > >> The align_offset parameter is used by bitmap_find_next_zero_area_off() > >> to represent

Re: [PATCH] cma: fix calculation of aligned offset

On Thu, 29 Jun 2017 17:43:18 -0700 Doug Berger wrote: > On 06/29/2017 01:48 PM, Andrew Morton wrote: > > On Wed, 28 Jun 2017 10:07:41 -0700 Doug Berger wrote: > > > >> The align_offset parameter is used by bitmap_find_next_zero_area_off() > >> to represent the offset of map's base from the

Re: wake_wide mechanism clarification

On Thu, Jun 29, 2017 at 05:19:14PM -0700, Joel Fernandes wrote: > Dear Mike, > > I wanted your kind help to understand your patch "sched: beef up > wake_wide()"[1] which is a modification to the original patch from > Michael Wang [2]. > > In particular, I didn't following the following comment:

Re: wake_wide mechanism clarification

On Thu, Jun 29, 2017 at 05:19:14PM -0700, Joel Fernandes wrote: > Dear Mike, > > I wanted your kind help to understand your patch "sched: beef up > wake_wide()"[1] which is a modification to the original patch from > Michael Wang [2]. > > In particular, I didn't following the following comment:

Re: [PATCH 1/2] mm, memory_hotplug: display allowed zones in the preferred ordering

On Thu, Jun 29, 2017 at 09:35:08AM +0200, Michal Hocko wrote: > From: Michal Hocko > > Prior to "mm, memory_hotplug: do not associate hotadded memory to zones > until online" we used to allow to change the valid zone types of a > memory block if it is adjacent to a different

Re: [PATCH 1/2] mm, memory_hotplug: display allowed zones in the preferred ordering

On Thu, Jun 29, 2017 at 09:35:08AM +0200, Michal Hocko wrote: > From: Michal Hocko > > Prior to "mm, memory_hotplug: do not associate hotadded memory to zones > until online" we used to allow to change the valid zone types of a > memory block if it is adjacent to a different zone type. This fact

Re: [PATCH V1 0/9] add clock driver for Spreadtrum platforms

On 06/22, Chunyan Zhang wrote: > Hi Stephen, > > On 20 June 2017 at 09:25, Stephen Boyd wrote: > > On 06/18, Chunyan Zhang wrote: > >> In the last cycle, the patches support Whale2 sc9860 mobile chip have been > >> merged. This patchset adds clock driver which is used on

Re: [PATCH V1 0/9] add clock driver for Spreadtrum platforms

On 06/22, Chunyan Zhang wrote: > Hi Stephen, > > On 20 June 2017 at 09:25, Stephen Boyd wrote: > > On 06/18, Chunyan Zhang wrote: > >> In the last cycle, the patches support Whale2 sc9860 mobile chip have been > >> merged. This patchset adds clock driver which is used on almost all > >>

Re: [PATCH] cma: fix calculation of aligned offset

On 06/29/2017 01:48 PM, Andrew Morton wrote: > On Wed, 28 Jun 2017 10:07:41 -0700 Doug Berger wrote: > >> The align_offset parameter is used by bitmap_find_next_zero_area_off() >> to represent the offset of map's base from the previous alignment >> boundary; the function

Re: [PATCH] cma: fix calculation of aligned offset

On 06/29/2017 01:48 PM, Andrew Morton wrote: > On Wed, 28 Jun 2017 10:07:41 -0700 Doug Berger wrote: > >> The align_offset parameter is used by bitmap_find_next_zero_area_off() >> to represent the offset of map's base from the previous alignment >> boundary; the function ensures that the

[for-next][PATCH 03/12] ftrace: Add :mod: caching infrastructure to trace_array

From: "Steven Rostedt (VMware)" This is the start of the infrastructure work to allow for tracing module functions before it is loaded. Currently the following command: # echo :mod:some-mod > set_ftrace_filter will enable tracing of all functions within the module

[for-next][PATCH 03/12] ftrace: Add :mod: caching infrastructure to trace_array

From: "Steven Rostedt (VMware)" This is the start of the infrastructure work to allow for tracing module functions before it is loaded. Currently the following command: # echo :mod:some-mod > set_ftrace_filter will enable tracing of all functions within the module "some-mod" if it is

[for-next][PATCH 04/12] ftrace: Have the cached module list show in set_ftrace_filter

From: "Steven Rostedt (VMware)" When writing in a module filter into set_ftrace_filter for a module that is not yet loaded, it it cached, and will be executed when the module is loaded (although that is not implemented yet at this commit). Display the list of cached modules

[for-next][PATCH 08/12] ftrace: Remove unused function ftrace_arch_read_dyn_info()

From: "Steven Rostedt (VMware)" ftrace_arch_read_dyn_info() was used so that archs could add its own debug information into the dyn_ftrace_total_info in the tracefs file system. That file is for debugging usage of dynamic ftrace. No arch uses that function anymore, so just

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