Re: [PATCH V2 net-next 01/17] net: hns3: add support to query tqps number

On 2017/12/20 3:16, David Miller wrote: From: Lipeng Date: Tue, 19 Dec 2017 12:02:23 +0800 @@ -5002,6 +5002,26 @@ static void hclge_uninit_ae_dev(struct hnae3_ae_dev *ae_dev) ae_dev->priv = NULL; } +static u32 hclge_get_max_channels(struct hnae3_handle

Re: [PATCH V2 net-next 01/17] net: hns3: add support to query tqps number

On 2017/12/20 3:16, David Miller wrote: From: Lipeng Date: Tue, 19 Dec 2017 12:02:23 +0800 @@ -5002,6 +5002,26 @@ static void hclge_uninit_ae_dev(struct hnae3_ae_dev *ae_dev) ae_dev->priv = NULL; } +static u32 hclge_get_max_channels(struct hnae3_handle *handle) +{ +

Re: [ANNOUNCE] autofs 5.1.2 release

On 20/12/17 13:52, Ian Kent wrote: > On 20/12/17 11:29, NeilBrown wrote: >> >> Hi Ian, >> I've been looking at: >> >>> - add configuration option to use fqdn in mounts. >> >> (commit 9aeef772604) because using this new option causes a regression. >> If you are using the "replicated server"

Re: [ANNOUNCE] autofs 5.1.2 release

On 20/12/17 13:52, Ian Kent wrote: > On 20/12/17 11:29, NeilBrown wrote: >> >> Hi Ian, >> I've been looking at: >> >>> - add configuration option to use fqdn in mounts. >> >> (commit 9aeef772604) because using this new option causes a regression. >> If you are using the "replicated server"

Re: [PATCH v2 4/5] mm: use node_page_state_snapshot to avoid deviation

On 2017年12月19日 20:43, Michal Hocko wrote: > On Tue 19-12-17 14:39:25, Kemi Wang wrote: >> To avoid deviation, this patch uses node_page_state_snapshot instead of >> node_page_state for node page stats query. >> e.g. cat /proc/zoneinfo >> cat /sys/devices/system/node/node*/vmstat >> cat

Re: [PATCH v2 4/5] mm: use node_page_state_snapshot to avoid deviation

On 2017年12月19日 20:43, Michal Hocko wrote: > On Tue 19-12-17 14:39:25, Kemi Wang wrote: >> To avoid deviation, this patch uses node_page_state_snapshot instead of >> node_page_state for node page stats query. >> e.g. cat /proc/zoneinfo >> cat /sys/devices/system/node/node*/vmstat >> cat

Re: [PATCH v6 09/18] PCI: dwc: dra7xx: Help compiler to remove unused code

On Wednesday 20 December 2017 04:59 AM, Niklas Cassel wrote: > The dra7xx driver supports both host and ep mode. > When enabling support for only one of the modes, help the compiler > to remove code for the mode that we have not enabled in the driver. > > By adding if

Re: [PATCH v6 09/18] PCI: dwc: dra7xx: Help compiler to remove unused code

On Wednesday 20 December 2017 04:59 AM, Niklas Cassel wrote: > The dra7xx driver supports both host and ep mode. > When enabling support for only one of the modes, help the compiler > to remove code for the mode that we have not enabled in the driver. > > By adding if

Re: [PATCH v2 3/5] mm: enlarge NUMA counters threshold size

On 2017年12月19日 20:40, Michal Hocko wrote: > On Tue 19-12-17 14:39:24, Kemi Wang wrote: >> We have seen significant overhead in cache bouncing caused by NUMA counters >> update in multi-threaded page allocation. See 'commit 1d90ca897cb0 ("mm: >> update NUMA counter threshold size")' for more

Re: [PATCH v2 3/5] mm: enlarge NUMA counters threshold size

On 2017年12月19日 20:40, Michal Hocko wrote: > On Tue 19-12-17 14:39:24, Kemi Wang wrote: >> We have seen significant overhead in cache bouncing caused by NUMA counters >> update in multi-threaded page allocation. See 'commit 1d90ca897cb0 ("mm: >> update NUMA counter threshold size")' for more

Re: [ANNOUNCE] autofs 5.1.2 release

On 20/12/17 11:29, NeilBrown wrote: > > Hi Ian, > I've been looking at: > >> - add configuration option to use fqdn in mounts. > > (commit 9aeef772604) because using this new option causes a regression. > If you are using the "replicated server" functionality, then > use_hostname_for_mounts

Re: [ANNOUNCE] autofs 5.1.2 release

On 20/12/17 11:29, NeilBrown wrote: > > Hi Ian, > I've been looking at: > >> - add configuration option to use fqdn in mounts. > > (commit 9aeef772604) because using this new option causes a regression. > If you are using the "replicated server" functionality, then > use_hostname_for_mounts

Re: [PATCH v6 15/18] PCI: dwc: Make cpu_addr_fixup take struct dw_pcie as argument

On Wednesday 20 December 2017 04:59 AM, Niklas Cassel wrote: > The current cpu addr fixup mask for ARTPEC-6, GENMASK(27, 0), is wrong. > The correct cpu addr fixup mask for ARTPEC-6 is GENMASK(28, 0). > > However, having a hardcoded cpu addr fixup mask in each driver is > arguably wrong. > A

Re: [PATCH v6 15/18] PCI: dwc: Make cpu_addr_fixup take struct dw_pcie as argument

On Wednesday 20 December 2017 04:59 AM, Niklas Cassel wrote: > The current cpu addr fixup mask for ARTPEC-6, GENMASK(27, 0), is wrong. > The correct cpu addr fixup mask for ARTPEC-6 is GENMASK(28, 0). > > However, having a hardcoded cpu addr fixup mask in each driver is > arguably wrong. > A

Re: [PATCH v3 14/16] phy: Add notify_speed callback

Hi, On Tuesday 12 December 2017 08:54 PM, Manu Gautam wrote: > Hi, > > > On 12/12/2017 5:13 PM, Kishon Vijay Abraham I wrote: >> Hi, >> >> On Tuesday 21 November 2017 02:53 PM, Manu Gautam wrote: >>> QCOM USB PHYs can monitor resume/remote-wakeup event in >>> suspended state. However PHY driver

Re: [PATCH v3 14/16] phy: Add notify_speed callback

Hi, On Tuesday 12 December 2017 08:54 PM, Manu Gautam wrote: > Hi, > > > On 12/12/2017 5:13 PM, Kishon Vijay Abraham I wrote: >> Hi, >> >> On Tuesday 21 November 2017 02:53 PM, Manu Gautam wrote: >>> QCOM USB PHYs can monitor resume/remote-wakeup event in >>> suspended state. However PHY driver

[PATCH -next] mtd: sharpslpart: make local function sharpsl_nand_cleanup_ftl() static

Fixes the following sparse warnings: drivers/mtd/parsers/sharpslpart.c:222:6: warning: symbol 'sharpsl_nand_cleanup_ftl' was not declared. Should it be static? Signed-off-by: Wei Yongjun --- drivers/mtd/parsers/sharpslpart.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH -next] mtd: sharpslpart: make local function sharpsl_nand_cleanup_ftl() static

Fixes the following sparse warnings: drivers/mtd/parsers/sharpslpart.c:222:6: warning: symbol 'sharpsl_nand_cleanup_ftl' was not declared. Should it be static? Signed-off-by: Wei Yongjun --- drivers/mtd/parsers/sharpslpart.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [RFC PATCH 0/5] mm, hugetlb: allocation API and migration improvements

On 12/15/2017 06:33 PM, Michal Hocko wrote: > Naoya, > this has passed Mike's review (thanks for that!), you have mentioned > that you can pass this through your testing machinery earlier. While > I've done some testing already I would really appreciate if you could > do that as well. Review

Re: [RFC PATCH 0/5] mm, hugetlb: allocation API and migration improvements

On 12/15/2017 06:33 PM, Michal Hocko wrote: > Naoya, > this has passed Mike's review (thanks for that!), you have mentioned > that you can pass this through your testing machinery earlier. While > I've done some testing already I would really appreciate if you could > do that as well. Review

Re: [PATCH v2 1/5] mm: migrate NUMA stats from per-zone to per-node

On 2017年12月19日 20:28, Michal Hocko wrote: > On Tue 19-12-17 14:39:22, Kemi Wang wrote: >> There is not really any use to get NUMA stats separated by zone, and >> current per-zone NUMA stats is only consumed in /proc/zoneinfo. For code >> cleanup purpose, we move NUMA stats from per-zone to

Re: [PATCH v2 1/5] mm: migrate NUMA stats from per-zone to per-node

On 2017年12月19日 20:28, Michal Hocko wrote: > On Tue 19-12-17 14:39:22, Kemi Wang wrote: >> There is not really any use to get NUMA stats separated by zone, and >> current per-zone NUMA stats is only consumed in /proc/zoneinfo. For code >> cleanup purpose, we move NUMA stats from per-zone to

Re: proc_flush_task oops

On Tue, Dec 19, 2017 at 07:54:24PM -0600, Eric W. Biederman wrote: > > *Scratches my head* I am not seeing anything obvious. > > Can you try this patch as you reproduce this issue? > > diff --git a/kernel/pid.c b/kernel/pid.c > index b13b624e2c49..df9e5d4d8f83 100644 > ---

Re: proc_flush_task oops

On Tue, Dec 19, 2017 at 07:54:24PM -0600, Eric W. Biederman wrote: > > *Scratches my head* I am not seeing anything obvious. > > Can you try this patch as you reproduce this issue? > > diff --git a/kernel/pid.c b/kernel/pid.c > index b13b624e2c49..df9e5d4d8f83 100644 > ---

Re: [PATCH net 0/3] Few mvneta fixes

Hi Arnd, On Tue, Dec 19, 2017 at 09:18:35PM +0100, Arnd Bergmann wrote: > On Tue, Dec 19, 2017 at 5:59 PM, Gregory CLEMENT > wrote: > > Hello, > > > > here it is a small series of fixes found on the mvneta driver. They > > had been already used in the vendor

Re: r8169 regression: UDP packets dropped intermittantly

On Tue, Dec 19, 2017 at 01:25:23PM +0100, Michal Kubecek wrote: > On Tue, Dec 19, 2017 at 04:15:32PM +1030, Jonathan Woithe wrote: > > This clearly indicates that not every card using the r8169 driver is > > vulnerable to the problem. It also explains why Holger was unable to > > reproduce the

Re: [PATCH net 0/3] Few mvneta fixes

Hi Arnd, On Tue, Dec 19, 2017 at 09:18:35PM +0100, Arnd Bergmann wrote: > On Tue, Dec 19, 2017 at 5:59 PM, Gregory CLEMENT > wrote: > > Hello, > > > > here it is a small series of fixes found on the mvneta driver. They > > had been already used in the vendor kernel and are now ported to > >

Re: r8169 regression: UDP packets dropped intermittantly

On Tue, Dec 19, 2017 at 01:25:23PM +0100, Michal Kubecek wrote: > On Tue, Dec 19, 2017 at 04:15:32PM +1030, Jonathan Woithe wrote: > > This clearly indicates that not every card using the r8169 driver is > > vulnerable to the problem. It also explains why Holger was unable to > > reproduce the

Re: [PATCH] kfree_rcu() should use the new kfree_bulk() interface for freeing rcu structures

On Tue, Dec 19, 2017 at 05:53:36PM -0800, Matthew Wilcox wrote: > On Tue, Dec 19, 2017 at 04:20:51PM -0800, Paul E. McKenney wrote: > > If we are going to make this sort of change, we should do so in a way > > that allows the slab code to actually do the optimizations that might > > make this sort

Re: [PATCH] kfree_rcu() should use the new kfree_bulk() interface for freeing rcu structures

On Tue, Dec 19, 2017 at 05:53:36PM -0800, Matthew Wilcox wrote: > On Tue, Dec 19, 2017 at 04:20:51PM -0800, Paul E. McKenney wrote: > > If we are going to make this sort of change, we should do so in a way > > that allows the slab code to actually do the optimizations that might > > make this sort

Re: [PATCH v3 02/16] phy: qcom-qmp: Adapt to clk_bulk_* APIs

On 12/20/2017 8:07 AM, Vivek Gautam wrote: > Hi Manu, > > [snip] > >> @@ -998,29 +992,17 @@ static int qcom_qmp_phy_reset_init(struct device *dev) >> static int qcom_qmp_phy_clk_init(struct device *dev) >> { >> struct qcom_qmp *qmp = dev_get_drvdata(dev); >> - int ret, i; >> +

Re: [PATCH v3 02/16] phy: qcom-qmp: Adapt to clk_bulk_* APIs

On 12/20/2017 8:07 AM, Vivek Gautam wrote: > Hi Manu, > > [snip] > >> @@ -998,29 +992,17 @@ static int qcom_qmp_phy_reset_init(struct device *dev) >> static int qcom_qmp_phy_clk_init(struct device *dev) >> { >> struct qcom_qmp *qmp = dev_get_drvdata(dev); >> - int ret, i; >> +

Re: [PATCH v5 7/8] pwm: pwm-omap-dmtimer: Adapt driver to utilize dmtimer pdata ops

On Tuesday 19 December 2017 08:51 PM, Ladislav Michl wrote: > On Tue, Dec 19, 2017 at 01:55:48PM +0530, Keerthy wrote: >> On Tuesday 19 December 2017 10:28 AM, Keerthy wrote: >>> On Monday 18 December 2017 06:25 PM, Keerthy wrote: On Monday 18 December 2017 03:01 PM, Ladislav Michl wrote:

[PATCH] RISC-V: Support built-in dtb

Build the dtb into the kernel image. If the DTB is given via bootloader, the external DTB is adopted first. Signed-off-by: Zong Li --- arch/riscv/Kconfig | 4 arch/riscv/Makefile | 9 + arch/riscv/boot/Makefile | 17 +

Re: [PATCH v5 7/8] pwm: pwm-omap-dmtimer: Adapt driver to utilize dmtimer pdata ops

On Tuesday 19 December 2017 08:51 PM, Ladislav Michl wrote: > On Tue, Dec 19, 2017 at 01:55:48PM +0530, Keerthy wrote: >> On Tuesday 19 December 2017 10:28 AM, Keerthy wrote: >>> On Monday 18 December 2017 06:25 PM, Keerthy wrote: On Monday 18 December 2017 03:01 PM, Ladislav Michl wrote:

[PATCH] RISC-V: Support built-in dtb

Build the dtb into the kernel image. If the DTB is given via bootloader, the external DTB is adopted first. Signed-off-by: Zong Li --- arch/riscv/Kconfig | 4 arch/riscv/Makefile | 9 + arch/riscv/boot/Makefile | 17 +

linux-next: Tree for Dec 20

Hi all, Changes since 20171219: The usb tree gained a conflict against the usb.current tree. The staging tree gained a conflict against the char-misc-next tree. The akpm tree lost a patch that turned up elsewhere. Non-merge commits (relative to Linus' tree): 5152 5400 files changed, 193652

linux-next: Tree for Dec 20

Hi all, Changes since 20171219: The usb tree gained a conflict against the usb.current tree. The staging tree gained a conflict against the char-misc-next tree. The akpm tree lost a patch that turned up elsewhere. Non-merge commits (relative to Linus' tree): 5152 5400 files changed, 193652

RE: [PATCH v2] arm64: dts: ls1088a: Add USB support

-Original Message- From: Shawn Guo [mailto:shawn...@kernel.org] Sent: Wednesday, December 20, 2017 10:53 AM To: Yinbo Zhu Cc: Rob Herring ; Mark Rutland ; Catalin Marinas ) ; Will Deacon )

RE: [PATCH v2] arm64: dts: ls1088a: Add USB support

-Original Message- From: Shawn Guo [mailto:shawn...@kernel.org] Sent: Wednesday, December 20, 2017 10:53 AM To: Yinbo Zhu Cc: Rob Herring ; Mark Rutland ; Catalin Marinas ) ; Will Deacon ) ; Harninder Rai ; Raghav Dogra ; Ashish Kumar ; Andy Tang ; open list:OPEN FIRMWARE AND

Re: BUG: bad usercopy in memdup_user

On Tue, Dec 19, 2017 at 8:05 PM, Linus Torvalds wrote: > > And yes, we had a few cases where the hashing actually did hide the > values, and I've been applying patches to turn those from %p to %px. So far at least: 10a7e9d84915 Do not hash userspace addresses in

Re: BUG: bad usercopy in memdup_user

On Tue, Dec 19, 2017 at 8:05 PM, Linus Torvalds wrote: > > And yes, we had a few cases where the hashing actually did hide the > values, and I've been applying patches to turn those from %p to %px. So far at least: 10a7e9d84915 Do not hash userspace addresses in fault handlers 85c3e4a5a185

Re: [PATCH 3/4] sched: Comment on why sync wakeups try to run on the current CPU

On Wed, 2017-12-20 at 05:09 +0100, Mike Galbraith wrote: >  Nope, stacking based upon that > hint is most definitely not a good idea :) Except when heavily loaded. The only thing worse for communicating hogs being stacked is communicating hogs talking with another hog between them.

Re: [PATCH 3/4] sched: Comment on why sync wakeups try to run on the current CPU

On Wed, 2017-12-20 at 05:09 +0100, Mike Galbraith wrote: >  Nope, stacking based upon that > hint is most definitely not a good idea :) Except when heavily loaded. The only thing worse for communicating hogs being stacked is communicating hogs talking with another hog between them.

[PATCH net-next v4 6/6] net: dccp: Remove dccpprobe module

Remove DCCP probe module since jprobe has been deprecated. That function is now replaced by dccp/dccp_probe trace-event. You can use it via ftrace or perftools. Signed-off-by: Masami Hiramatsu --- net/dccp/Kconfig | 17 net/dccp/Makefile |2 - net/dccp/probe.c

[PATCH net-next v4 6/6] net: dccp: Remove dccpprobe module

Remove DCCP probe module since jprobe has been deprecated. That function is now replaced by dccp/dccp_probe trace-event. You can use it via ftrace or perftools. Signed-off-by: Masami Hiramatsu --- net/dccp/Kconfig | 17 net/dccp/Makefile |2 - net/dccp/probe.c | 203

[PATCH net-next v4 5/6] net: dccp: Add DCCP sendmsg trace event

Add DCCP sendmsg trace event (dccp/dccp_probe) for replacing dccpprobe. User can trace this event via ftrace or perftools. Signed-off-by: Masami Hiramatsu --- net/dccp/proto.c |5 +++ net/dccp/trace.h | 105 ++ 2

[PATCH net-next v4 5/6] net: dccp: Add DCCP sendmsg trace event

Add DCCP sendmsg trace event (dccp/dccp_probe) for replacing dccpprobe. User can trace this event via ftrace or perftools. Signed-off-by: Masami Hiramatsu --- net/dccp/proto.c |5 +++ net/dccp/trace.h | 105 ++ 2 files changed, 110

[PATCH net-next v4 4/6] net: sctp: Remove debug SCTP probe module

Remove SCTP probe module since jprobe has been deprecated. That function is now replaced by sctp/sctp_probe and sctp/sctp_probe_path trace-events. You can use it via ftrace or perftools. Signed-off-by: Masami Hiramatsu --- net/sctp/Kconfig | 12 --- net/sctp/Makefile |

[PATCH net-next v4 4/6] net: sctp: Remove debug SCTP probe module

Remove SCTP probe module since jprobe has been deprecated. That function is now replaced by sctp/sctp_probe and sctp/sctp_probe_path trace-events. You can use it via ftrace or perftools. Signed-off-by: Masami Hiramatsu --- net/sctp/Kconfig | 12 --- net/sctp/Makefile |3 -

Re: [PATCH 1/4] pci: dwc: pci-dra7xx: Enable errata i870 for both EP and RC mode

On Tuesday 19 December 2017 09:54 PM, Lorenzo Pieralisi wrote: > On Fri, Dec 01, 2017 at 11:43:08AM +0530, Vignesh R wrote: >> Errata i870 is applicable in both EP and RC mode. Therefore rename >> function dra7xx_pcie_ep_unaligned_memaccess(), that implements errata >> workaround, to

Re: [PATCH 1/4] pci: dwc: pci-dra7xx: Enable errata i870 for both EP and RC mode

On Tuesday 19 December 2017 09:54 PM, Lorenzo Pieralisi wrote: > On Fri, Dec 01, 2017 at 11:43:08AM +0530, Vignesh R wrote: >> Errata i870 is applicable in both EP and RC mode. Therefore rename >> function dra7xx_pcie_ep_unaligned_memaccess(), that implements errata >> workaround, to

[PATCH net-next v4 3/6] net: sctp: Add SCTP ACK tracking trace event

Add SCTP ACK tracking trace event to trace the changes of SCTP association state in response to incoming packets. It is used for debugging SCTP congestion control algorithms, and will replace sctp_probe module. Note that this event a bit tricky. Since this consists of 2 events (sctp_probe and

[PATCH net-next v4 3/6] net: sctp: Add SCTP ACK tracking trace event

Add SCTP ACK tracking trace event to trace the changes of SCTP association state in response to incoming packets. It is used for debugging SCTP congestion control algorithms, and will replace sctp_probe module. Note that this event a bit tricky. Since this consists of 2 events (sctp_probe and

[PATCH net-next v4 1/6] net: tcp: Add trace events for TCP congestion window tracing

This adds an event to trace TCP stat variables with slightly intrusive trace-event. This uses ftrace/perf event log buffer to trace those state, no needs to prepare own ring-buffer, nor custom user apps. User can use ftrace to trace this event as below; # cd /sys/kernel/debug/tracing # echo

[PATCH net-next v4 1/6] net: tcp: Add trace events for TCP congestion window tracing

This adds an event to trace TCP stat variables with slightly intrusive trace-event. This uses ftrace/perf event log buffer to trace those state, no needs to prepare own ring-buffer, nor custom user apps. User can use ftrace to trace this event as below; # cd /sys/kernel/debug/tracing # echo

[PATCH net-next v4 2/6] net: tcp: Remove TCP probe module

Remove TCP probe module since jprobe has been deprecated. That function is now replaced by tcp/tcp_probe trace-event. You can use it via ftrace or perftools. Signed-off-by: Masami Hiramatsu --- net/Kconfig | 17 --- net/ipv4/Makefile|1

[PATCH net-next v4 2/6] net: tcp: Remove TCP probe module

Remove TCP probe module since jprobe has been deprecated. That function is now replaced by tcp/tcp_probe trace-event. You can use it via ftrace or perftools. Signed-off-by: Masami Hiramatsu --- net/Kconfig | 17 --- net/ipv4/Makefile|1 net/ipv4/tcp_probe.c | 301

[PATCH net-next v4 0/6] net: tcp: sctp: dccp: Replace jprobe usage with trace events

Hi, This series is v4 of the replacement of jprobe usage with trace events. This version is rebased on net-next, fixes a build warning and moves a temporal variable definition in a block. Previous version is here; https://lkml.org/lkml/2017/12/19/153 Changes from v3: All: Rebased on net-next

[PATCH net-next v4 0/6] net: tcp: sctp: dccp: Replace jprobe usage with trace events

Hi, This series is v4 of the replacement of jprobe usage with trace events. This version is rebased on net-next, fixes a build warning and moves a temporal variable definition in a block. Previous version is here; https://lkml.org/lkml/2017/12/19/153 Changes from v3: All: Rebased on net-next

Re: [PATCH] lib: add module unload support to sort tests

[Re: [PATCH] lib: add module unload support to sort tests] On 19/12/2017 (Tue 23:10) Pravin Shedge wrote: > On Tue, Dec 19, 2017 at 3:51 AM, Andrew Morton > wrote: > > On Sun, 17 Dec 2017 15:19:27 +0530 Pravin Shedge > > wrote: > > >

Re: [PATCH] lib: add module unload support to sort tests

[Re: [PATCH] lib: add module unload support to sort tests] On 19/12/2017 (Tue 23:10) Pravin Shedge wrote: > On Tue, Dec 19, 2017 at 3:51 AM, Andrew Morton > wrote: > > On Sun, 17 Dec 2017 15:19:27 +0530 Pravin Shedge > > wrote: > > > >> test_sort.c perform array-based and linked list sort

Re: [PATCH 03/15] staging: lustre: replace simple cases of LIBCFS_ALLOC with kzalloc.

Hi NeilBrown, Thank you for the patch! Yet something to improve: [auto build test ERROR on staging/staging-testing] [also build test ERROR on next-20171219] [cannot apply to v4.15-rc4] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url

Re: [PATCH 03/15] staging: lustre: replace simple cases of LIBCFS_ALLOC with kzalloc.

Hi NeilBrown, Thank you for the patch! Yet something to improve: [auto build test ERROR on staging/staging-testing] [also build test ERROR on next-20171219] [cannot apply to v4.15-rc4] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url

Re: [PATCH 3/4] sched: Comment on why sync wakeups try to run on the current CPU

On Tue, 2017-12-19 at 20:06 +0100, Peter Zijlstra wrote: > > Our SYNC hint does promise the caller will go away 'soon', although I'm > not sure how many of the current users actually honor that. The sync hint is not a lie, or even a damn lie, it's a statistic :) It's very useful for...

Re: [PATCH 3/4] sched: Comment on why sync wakeups try to run on the current CPU

On Tue, 2017-12-19 at 20:06 +0100, Peter Zijlstra wrote: > > Our SYNC hint does promise the caller will go away 'soon', although I'm > not sure how many of the current users actually honor that. The sync hint is not a lie, or even a damn lie, it's a statistic :) It's very useful for...

Re: BUG: bad usercopy in memdup_user

On Tue, Dec 19, 2017 at 7:50 PM, Matthew Wilcox wrote: > On Tue, Dec 19, 2017 at 09:48:49PM +, Al Viro wrote: >> Well, for example seeing a 0xfff4 where a pointer to object >> must have been is a pretty strong hint to start looking for a way for >> that

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On 19-12-17, 20:25, Peter Zijlstra wrote: > Yeah, not happy about this either; we had code that did the right thing > without this extra tracking I think. Sure, but how do you suggest we fix the problems we are facing with the current design? Patrick had a completely different proposal for

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On 19-12-17, 20:25, Peter Zijlstra wrote: > Yeah, not happy about this either; we had code that did the right thing > without this extra tracking I think. Sure, but how do you suggest we fix the problems we are facing with the current design? Patrick had a completely different proposal for

Re: BUG: bad usercopy in memdup_user

On Tue, Dec 19, 2017 at 7:50 PM, Matthew Wilcox wrote: > On Tue, Dec 19, 2017 at 09:48:49PM +, Al Viro wrote: >> Well, for example seeing a 0xfff4 where a pointer to object >> must have been is a pretty strong hint to start looking for a way for >> that ERR_PTR(-ENOMEM) having

[RESEND][PATCH] tools/power: Don't make man pages executable

rpm-lint flagged these as being executable: kernel-tools.x86_64: W: spurious-executable-perm /usr/share/man/man8/turbostat.8.gz kernel-tools.x86_64: W: spurious-executable-perm /usr/share/man/man8/x86_energy_perf_policy.8.gz Fix this Signed-off-by: Laura Abbott --- Resent

[RESEND][PATCH] tools/power: Don't make man pages executable

rpm-lint flagged these as being executable: kernel-tools.x86_64: W: spurious-executable-perm /usr/share/man/man8/turbostat.8.gz kernel-tools.x86_64: W: spurious-executable-perm /usr/share/man/man8/x86_energy_perf_policy.8.gz Fix this Signed-off-by: Laura Abbott --- Resent for linux-pm cc ---

[PATCH v15 4/5] watchdog: Add RAVE SP watchdog driver

This driver provides access to RAVE SP watchdog functionality. Cc: linux-kernel@vger.kernel.org Cc: linux-watch...@vger.kernel.org Cc: cphe...@gmail.com Cc: Lucas Stach Cc: Nikita Yushchenko Cc: Lee Jones Cc: Greg

[PATCH v15 4/5] watchdog: Add RAVE SP watchdog driver

This driver provides access to RAVE SP watchdog functionality. Cc: linux-kernel@vger.kernel.org Cc: linux-watch...@vger.kernel.org Cc: cphe...@gmail.com Cc: Lucas Stach Cc: Nikita Yushchenko Cc: Lee Jones Cc: Greg Kroah-Hartman Cc: Pavel Machek Cc: Andy Shevchenko Cc: Guenter Roeck Cc: Rob

[PATCH v15 2/5] serdev: Introduce devm_serdev_device_open()

Add code implementing managed version of serdev_device_open() for serdev device drivers that "open" the device during driver's lifecycle only once (e.g. opened in .probe() and closed in .remove()). Cc: linux-kernel@vger.kernel.org Cc: linux-ser...@vger.kernel.org Cc: Rob Herring

[PATCH v15 2/5] serdev: Introduce devm_serdev_device_open()

Add code implementing managed version of serdev_device_open() for serdev device drivers that "open" the device during driver's lifecycle only once (e.g. opened in .probe() and closed in .remove()). Cc: linux-kernel@vger.kernel.org Cc: linux-ser...@vger.kernel.org Cc: Rob Herring Cc:

[PATCH v15 1/5] serdev: Make .remove in struct serdev_device_driver optional

Using devres infrastructure it is possible to write a serdev driver that doesn't have any code that needs to be called as a part of .remove. Add code to make .remove optional. Cc: linux-kernel@vger.kernel.org Cc: linux-ser...@vger.kernel.org Cc: Rob Herring Cc: cphe...@gmail.com

[PATCH v15 5/5] dt-bindings: watchdog: Add bindings for RAVE SP watchdog driver

Add Device Tree bindings for RAVE SP watchdog drvier - an MFD cell of parent RAVE SP driver (documented in Documentation/devicetree/bindings/mfd/zii,rave-sp.txt). Cc: linux-kernel@vger.kernel.org Cc: devicet...@vger.kernel.org Cc: linux-watch...@vger.kernel.org Cc: cphe...@gmail.com Cc: Lucas

[PATCH v15 1/5] serdev: Make .remove in struct serdev_device_driver optional

Using devres infrastructure it is possible to write a serdev driver that doesn't have any code that needs to be called as a part of .remove. Add code to make .remove optional. Cc: linux-kernel@vger.kernel.org Cc: linux-ser...@vger.kernel.org Cc: Rob Herring Cc: cphe...@gmail.com Cc: Guenter

[PATCH v15 5/5] dt-bindings: watchdog: Add bindings for RAVE SP watchdog driver

Add Device Tree bindings for RAVE SP watchdog drvier - an MFD cell of parent RAVE SP driver (documented in Documentation/devicetree/bindings/mfd/zii,rave-sp.txt). Cc: linux-kernel@vger.kernel.org Cc: devicet...@vger.kernel.org Cc: linux-watch...@vger.kernel.org Cc: cphe...@gmail.com Cc: Lucas

[PATCH v15 3/5] mfd: Add driver for RAVE Supervisory Processor

Add a driver for RAVE Supervisory Processor, an MCU implementing various bits of housekeeping functionality (watchdoging, backlight control, LED control, etc) on RAVE family of products by Zodiac Inflight Innovations. This driver implementes core MFD/serdev device as well as communication

[PATCH v15 3/5] mfd: Add driver for RAVE Supervisory Processor

Add a driver for RAVE Supervisory Processor, an MCU implementing various bits of housekeeping functionality (watchdoging, backlight control, LED control, etc) on RAVE family of products by Zodiac Inflight Innovations. This driver implementes core MFD/serdev device as well as communication

[PATCH v15 0/5] ZII RAVE platform driver

Everyone: This patch series is v15 of the driver for supervisory processor found on RAVE series of devices from ZII. Supervisory processor is a PIC microcontroller connected to various electrical subsystems on RAVE devices whose firmware implements protocol to command/qery them. NOTE: * This

[PATCH v15 0/5] ZII RAVE platform driver

Everyone: This patch series is v15 of the driver for supervisory processor found on RAVE series of devices from ZII. Supervisory processor is a PIC microcontroller connected to various electrical subsystems on RAVE devices whose firmware implements protocol to command/qery them. NOTE: * This

Re: PROBLEM: 4.15.0-rc3 APIC causes lockups on Core 2 Duo laptop

Hi Thomas, At 12/20/2017 08:31 AM, Thomas Gleixner wrote: On Tue, 19 Dec 2017, Alexandru Chirvasitu wrote: I had never heard of 'bisect' before this casual mention (you might tell I am a bit out of my depth). I've since applied it to Linus' tree between bebc608 Linux 4.14 (good) and

Re: PROBLEM: 4.15.0-rc3 APIC causes lockups on Core 2 Duo laptop

Hi Thomas, At 12/20/2017 08:31 AM, Thomas Gleixner wrote: On Tue, 19 Dec 2017, Alexandru Chirvasitu wrote: I had never heard of 'bisect' before this casual mention (you might tell I am a bit out of my depth). I've since applied it to Linus' tree between bebc608 Linux 4.14 (good) and

Re: BUG: bad usercopy in memdup_user

On Tue, Dec 19, 2017 at 09:48:49PM +, Al Viro wrote: > Well, for example seeing a 0xfff4 where a pointer to object > must have been is a pretty strong hint to start looking for a way for > that ERR_PTR(-ENOMEM) having ended up there... Something like > 0x6e69622f7273752f is almost

Re: BUG: bad usercopy in memdup_user

On Tue, Dec 19, 2017 at 09:48:49PM +, Al Viro wrote: > Well, for example seeing a 0xfff4 where a pointer to object > must have been is a pretty strong hint to start looking for a way for > that ERR_PTR(-ENOMEM) having ended up there... Something like > 0x6e69622f7273752f is almost

Re: [PATCH v6 1/5] clk: Add clock driver for ASPEED BMC SoCs

On Tue, Nov 28, 2017 at 5:49 PM, Joel Stanley wrote: > This adds the stub of a driver for the ASPEED SoCs. The clocks are > defined and the static registration is set up. > > Reviewed-by: Andrew Jeffery > Signed-off-by: Joel Stanley > --- > v6: >

Re: [PATCH v6 1/5] clk: Add clock driver for ASPEED BMC SoCs

On Tue, Nov 28, 2017 at 5:49 PM, Joel Stanley wrote: > This adds the stub of a driver for the ASPEED SoCs. The clocks are > defined and the static registration is set up. > > Reviewed-by: Andrew Jeffery > Signed-off-by: Joel Stanley > --- > v6: > - Add SPDX copyright notices > v5: > - Add

Re: [PATCH v3 00/19] ARM: dts: aspeed: updates and new machines

On Wed, Dec 20, 2017 at 1:53 PM, Joel Stanley wrote: > This series of device tree patches for the ASPEED BMC machines > moves all systems to use the soon to be merged clk driver, and > updates machines to use all of the drivers we have upstream. > > v3: Address review from Rob

Re: [PATCH v3 00/19] ARM: dts: aspeed: updates and new machines

On Wed, Dec 20, 2017 at 1:53 PM, Joel Stanley wrote: > This series of device tree patches for the ASPEED BMC machines > moves all systems to use the soon to be merged clk driver, and > updates machines to use all of the drivers we have upstream. > > v3: Address review from Rob and Cedric > -

Re: [PATCH v5 14/15] cpufreq: Add module to register cpufreq on Krait CPUs

On 19-12-17, 21:24, Sricharan R wrote: > From: Stephen Boyd > > Register a cpufreq-generic device whenever we detect that a > "qcom,krait" compatible CPU is present in DT. > > Cc: > [Sricharan: updated to use dev_pm_opp_set_prop_name] >

Re: [PATCH v5 14/15] cpufreq: Add module to register cpufreq on Krait CPUs

On 19-12-17, 21:24, Sricharan R wrote: > From: Stephen Boyd > > Register a cpufreq-generic device whenever we detect that a > "qcom,krait" compatible CPU is present in DT. > > Cc: > [Sricharan: updated to use dev_pm_opp_set_prop_name] > Signed-off-by: Sricharan R > Signed-off-by: Stephen Boyd

Re: [v2] arm: dts: ls1021a: fix the value of TMR_FIPER1

On Mon, Dec 18, 2017 at 02:51:06AM +, Y.b. Lu wrote: > Hi Shawn, > > Sorry for bother. I just couldn’t find this patch on your git tree. > Could you help to check? Sorry. I forgot to push the update. Just pushed now. Shawn

Re: [v2] arm: dts: ls1021a: fix the value of TMR_FIPER1

On Mon, Dec 18, 2017 at 02:51:06AM +, Y.b. Lu wrote: > Hi Shawn, > > Sorry for bother. I just couldn’t find this patch on your git tree. > Could you help to check? Sorry. I forgot to push the update. Just pushed now. Shawn

Re: [ANNOUNCE] autofs 5.1.2 release

Hi Ian, I've been looking at: > - add configuration option to use fqdn in mounts. (commit 9aeef772604) because using this new option causes a regression. If you are using the "replicated server" functionality, then use_hostname_for_mounts = yes completely disables it. This is caused by:

Re: [ANNOUNCE] autofs 5.1.2 release

Hi Ian, I've been looking at: > - add configuration option to use fqdn in mounts. (commit 9aeef772604) because using this new option causes a regression. If you are using the "replicated server" functionality, then use_hostname_for_mounts = yes completely disables it. This is caused by:

[PATCH v3 20/20] ARM: dts: aspeed-evb: Add unit name to memory node

Fixes a warning when building with W=1. All of the ASPEED device trees build without warnings now. Signed-off-by: Joel Stanley --- arch/arm/boot/dts/aspeed-ast2500-evb.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v3 20/20] ARM: dts: aspeed-evb: Add unit name to memory node

Fixes a warning when building with W=1. All of the ASPEED device trees build without warnings now. Signed-off-by: Joel Stanley --- arch/arm/boot/dts/aspeed-ast2500-evb.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/aspeed-ast2500-evb.dts

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