Re: Regression on ARMs in next-20170531

from -next, could you test > the -mm tree at git://git.cmpxchg.org/linux-mmots.git and verify that > this patch below fixes the issue? Looks like next-20170605 is broken for ARMs again.. And the patch below does not apply for me against mmots/master or next. Care to update? Regards, Tony

Re: Regression on ARMs in next-20170531

> the -mm tree at git://git.cmpxchg.org/linux-mmots.git and verify that > this patch below fixes the issue? Looks like next-20170605 is broken for ARMs again.. And the patch below does not apply for me against mmots/master or next. Care to update? Regards, Tony

linux-next: Tree for Jun 6

Hi all, Changes since 20170605: The clk tree lost its build failure. The net-next tree gained a conflict against the net tree. The mfd tree lost its build failure. The akpm-current tree still had its build failure for which I reverted a commit. Non-merge commits (relative to Linus' tree

linux-next: Tree for Jun 6

Hi all, Changes since 20170605: The clk tree lost its build failure. The net-next tree gained a conflict against the net tree. The mfd tree lost its build failure. The akpm-current tree still had its build failure for which I reverted a commit. Non-merge commits (relative to Linus' tree

Re: [PATCH] checkpatch: Change format of --color argument to --color[=WHEN]

On Mon, Jun 05, 2017 at 04:10:30PM -0700, Joe Perches wrote: > On Mon, 2017-06-05 at 18:27 -0400, John Brooks wrote: > > The boolean --color argument did not offer the ability to force colourized > > output even if stdout is not a terminal. > > OK, but why is colorizing output not to terminals

Re: [PATCH] checkpatch: Change format of --color argument to --color[=WHEN]

On Mon, Jun 05, 2017 at 04:10:30PM -0700, Joe Perches wrote: > On Mon, 2017-06-05 at 18:27 -0400, John Brooks wrote: > > The boolean --color argument did not offer the ability to force colourized > > output even if stdout is not a terminal. > > OK, but why is colorizing output not to terminals

Re: Stmmac: fix for hw timestamp of GMAC 3 unit

Hi Mario thanks for your tests, and, at first glance, your patches seem to be sensible so, please, send the changes as patches for net.git kernel. Regards Peppe On 6/6/2017 12:11 AM, Mario Molitor wrote: Dear stmmac maintainer group, I have found an problem in stmmac driver of linux

Re: Stmmac: fix for hw timestamp of GMAC 3 unit

Hi Mario thanks for your tests, and, at first glance, your patches seem to be sensible so, please, send the changes as patches for net.git kernel. Regards Peppe On 6/6/2017 12:11 AM, Mario Molitor wrote: Dear stmmac maintainer group, I have found an problem in stmmac driver of linux

Re: [PATCH v3 0/2] ARM: dts: imx7: add NAND support

On 2017-06-02 13:09, Han Xu wrote: > On 06/01/2017 08:48 PM, Stefan Agner wrote: >> Hi Han, >> >> On 2017-06-01 14:14, Han Xu wrote: >>> On 06/01/2017 02:20 PM, Stefan Agner wrote: This are the missing device tree parts to add NAND support for i.MX 7. See previous patchset:

Re: [PATCH v3 0/2] ARM: dts: imx7: add NAND support

On 2017-06-02 13:09, Han Xu wrote: > On 06/01/2017 08:48 PM, Stefan Agner wrote: >> Hi Han, >> >> On 2017-06-01 14:14, Han Xu wrote: >>> On 06/01/2017 02:20 PM, Stefan Agner wrote: This are the missing device tree parts to add NAND support for i.MX 7. See previous patchset:

Re: [PATCH v3 02/13] random: add get_random_{bytes,u32,u64,int,long,once}_wait family

On Mon, Jun 5, 2017 at 8:50 PM, Jason A. Donenfeld wrote: > These functions are simple convenience wrappers that call > wait_for_random_bytes before calling the respective get_random_* > function. It may be advantageous to add a timeout, too. There's been a number of times I

Re: [PATCH v3 02/13] random: add get_random_{bytes,u32,u64,int,long,once}_wait family

On Mon, Jun 5, 2017 at 8:50 PM, Jason A. Donenfeld wrote: > These functions are simple convenience wrappers that call > wait_for_random_bytes before calling the respective get_random_* > function. It may be advantageous to add a timeout, too. There's been a number of times I did not want to

Re: [PATCH] kernel/module.c: fix warning about unused nowarn variable

+++ Corentin Labbe [02/06/17 14:05 +0200]: This patch fix the following warning: kernel/module.c: In function 'add_usage_links': kernel/module.c:1653:6: warning: variable 'nowarn' set but not used [-Wunused-but-set-variable] int nowarn; Signed-off-by: Corentin Labbe

Re: [PATCH] kernel/module.c: fix warning about unused nowarn variable

+++ Corentin Labbe [02/06/17 14:05 +0200]: This patch fix the following warning: kernel/module.c: In function 'add_usage_links': kernel/module.c:1653:6: warning: variable 'nowarn' set but not used [-Wunused-but-set-variable] int nowarn; Signed-off-by: Corentin Labbe --- kernel/module.c | 13

Re: [PATCH] perf: fix perf test case 14 result reporting

On 06/02/2017 04:11 PM, Arnaldo Carvalho de Melo wrote: [] >> >> If you have specific patches in Jiri's branch that you think are good to >> go, just point me to them and I'll cherry-pick them. >> >> I'm looking now at the one you pointed out above (070b9644981e). > > Just looked, but the

Re: [PATCH] perf: fix perf test case 14 result reporting

On 06/02/2017 04:11 PM, Arnaldo Carvalho de Melo wrote: [] >> >> If you have specific patches in Jiri's branch that you think are good to >> go, just point me to them and I'll cherry-pick them. >> >> I'm looking now at the one you pointed out above (070b9644981e). > > Just looked, but the

Re: [PATCH 4/7] RISC-V: arch/riscv/include

On Thu, 01 Jun 2017 02:00:22 PDT (-0700), Arnd Bergmann wrote: > On Thu, Jun 1, 2017 at 2:56 AM, Palmer Dabbelt wrote: >> On Tue, 23 May 2017 05:55:15 PDT (-0700), Arnd Bergmann wrote: >>> On Tue, May 23, 2017 at 2:41 AM, Palmer Dabbelt wrote: > >

Re: [PATCH 5/7] RISC-V: arch/riscv/lib

On Fri, 26 May 2017 02:06:58 PDT (-0700), Arnd Bergmann wrote: > On Thu, May 25, 2017 at 3:59 AM, Palmer Dabbelt wrote: >> On Tue, 23 May 2017 04:19:42 PDT (-0700), Arnd Bergmann wrote: >>> On Tue, May 23, 2017 at 2:41 AM, Palmer Dabbelt wrote: > >>> Also,

Re: [PATCH 1/7] RISC-V: Top-Level Makefile for riscv{32,64}

On Mon, 29 May 2017 03:50:47 PDT (-0700), Arnd Bergmann wrote: > On Sat, May 27, 2017 at 2:57 AM, Palmer Dabbelt wrote: >> On Tue, 23 May 2017 04:30:50 PDT (-0700), Arnd Bergmann wrote: >>> On Tue, May 23, 2017 at 2:41 AM, Palmer Dabbelt wrote: RISC-V

Re: [PATCH 5/7] RISC-V: arch/riscv/lib

On Fri, 26 May 2017 02:06:58 PDT (-0700), Arnd Bergmann wrote: > On Thu, May 25, 2017 at 3:59 AM, Palmer Dabbelt wrote: >> On Tue, 23 May 2017 04:19:42 PDT (-0700), Arnd Bergmann wrote: >>> On Tue, May 23, 2017 at 2:41 AM, Palmer Dabbelt wrote: > >>> Also, it would be good to replace the

Re: [PATCH 1/7] RISC-V: Top-Level Makefile for riscv{32,64}

On Mon, 29 May 2017 03:50:47 PDT (-0700), Arnd Bergmann wrote: > On Sat, May 27, 2017 at 2:57 AM, Palmer Dabbelt wrote: >> On Tue, 23 May 2017 04:30:50 PDT (-0700), Arnd Bergmann wrote: >>> On Tue, May 23, 2017 at 2:41 AM, Palmer Dabbelt wrote: RISC-V has both 32-bit and 64-bit base ISAs,

Re: [PATCH 4/7] RISC-V: arch/riscv/include

On Thu, 01 Jun 2017 02:00:22 PDT (-0700), Arnd Bergmann wrote: > On Thu, Jun 1, 2017 at 2:56 AM, Palmer Dabbelt wrote: >> On Tue, 23 May 2017 05:55:15 PDT (-0700), Arnd Bergmann wrote: >>> On Tue, May 23, 2017 at 2:41 AM, Palmer Dabbelt wrote: > > +#ifndef _ASM_RISCV_CACHE_H +#define

Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs

On Mon, 29 May 2017 04:17:40 PDT (-0700), Arnd Bergmann wrote: > On Sat, May 27, 2017 at 2:57 AM, Palmer Dabbelt wrote: >> On Tue, 23 May 2017 04:46:22 PDT (-0700), Arnd Bergmann wrote: >>> On Tue, May 23, 2017 at 2:41 AM, Palmer Dabbelt wrote: diff

Re: [PATCH 6/7] RISC-V: arch/riscv/kernel

On Thu, 25 May 2017 12:51:54 PDT (-0700), Arnd Bergmann wrote: > On Thu, May 25, 2017 at 3:59 AM, Palmer Dabbelt wrote: >> On Mon, 22 May 2017 19:11:35 PDT (-0700), o...@lixom.net wrote: > >> * Parens around single-statement __asm__ macros. For these I also get a >>

Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs

On Mon, 29 May 2017 04:17:40 PDT (-0700), Arnd Bergmann wrote: > On Sat, May 27, 2017 at 2:57 AM, Palmer Dabbelt wrote: >> On Tue, 23 May 2017 04:46:22 PDT (-0700), Arnd Bergmann wrote: >>> On Tue, May 23, 2017 at 2:41 AM, Palmer Dabbelt wrote: diff --git a/arch/riscv/Kconfig

Re: [PATCH 6/7] RISC-V: arch/riscv/kernel

On Thu, 25 May 2017 12:51:54 PDT (-0700), Arnd Bergmann wrote: > On Thu, May 25, 2017 at 3:59 AM, Palmer Dabbelt wrote: >> On Mon, 22 May 2017 19:11:35 PDT (-0700), o...@lixom.net wrote: > >> * Parens around single-statement __asm__ macros. For these I also get a >>message when they're

[PATCH 4/6] kexec_file: Adjust declaration of kexec_purgatory

Defining kexec_purgatory as a zero-length char array upsets compile time size checking. Since this is built on a per-arch basis, define it as an unsized char array (like is done for other similar things, e.g. linker sections). This silences the warning generated by the future

[PATCH 2/6] efi: Avoid fortify checks in EFI stub

This avoids CONFIG_FORTIFY_SOURCE from being enabled during the EFI stub build, as adding a panic() implementation may not work well. This can be adjusted in the future. Suggested-by: Daniel Micay Signed-off-by: Kees Cook Cc; Matt Fleming

[PATCH 4/6] kexec_file: Adjust declaration of kexec_purgatory

Defining kexec_purgatory as a zero-length char array upsets compile time size checking. Since this is built on a per-arch basis, define it as an unsized char array (like is done for other similar things, e.g. linker sections). This silences the warning generated by the future

[PATCH 2/6] efi: Avoid fortify checks in EFI stub

This avoids CONFIG_FORTIFY_SOURCE from being enabled during the EFI stub build, as adding a panic() implementation may not work well. This can be adjusted in the future. Suggested-by: Daniel Micay Signed-off-by: Kees Cook Cc; Matt Fleming Cc: Ard Biesheuvel ---

[PATCH 1/6] arm64, vdso: Define vdso_{start,end} as array

Adjust vdso_{start|end} to be char arrays to avoid compile-time analysis that flags "too large" memcmp() calls with CONFIG_FORTIFY_SOURCE. Suggested-by: Mark Rutland Signed-off-by: Kees Cook Cc: Catalin Marinas Cc: Will

[PATCH 1/6] arm64, vdso: Define vdso_{start,end} as array

Adjust vdso_{start|end} to be char arrays to avoid compile-time analysis that flags "too large" memcmp() calls with CONFIG_FORTIFY_SOURCE. Suggested-by: Mark Rutland Signed-off-by: Kees Cook Cc: Catalin Marinas Cc: Will Deacon Cc: Jisheng Zhang --- arch/arm64/kernel/vdso.c | 10 +-

[PATCH 5/6] staging/rts5208: Fix read overflow in memcpy

From: Daniel Micay Noticed by FORTIFY_SOURCE, this swaps memcpy() for strncpy() to zero-value fill the end of the buffer instead of over-reading a string from .rodata. Signed-off-by: Daniel Micay [kees: wrote commit log] Signed-off-by: Kees Cook

[PATCH 5/6] staging/rts5208: Fix read overflow in memcpy

From: Daniel Micay Noticed by FORTIFY_SOURCE, this swaps memcpy() for strncpy() to zero-value fill the end of the buffer instead of over-reading a string from .rodata. Signed-off-by: Daniel Micay [kees: wrote commit log] Signed-off-by: Kees Cook Cc: Greg Kroah-Hartman Cc: Wayne Porter ---

[PATCH 6/6] IB/rxe: Do not copy extra stack memory to skb

This fixes a over-read condition detected by FORTIFY_SOURCE for this line: memcpy(SKB_TO_PKT(skb), _pkt, sizeof(skb->cb)); The error was: In file included from ./include/linux/bitmap.h:8:0, from ./include/linux/cpumask.h:11, from

[PATCH 3/6] x86/power/64: Use char arrays for asm function names

This switches the hibernate_64.S function names into character arrays to match other areas of the kernel where this is done (e.g., linker scripts). Specifically this fixes a compile-time error noticed by the future CONFIG_FORTIFY_SOURCE routines that complained about PAGE_SIZE being copied out of

[PATCH 6/6] IB/rxe: Do not copy extra stack memory to skb

This fixes a over-read condition detected by FORTIFY_SOURCE for this line: memcpy(SKB_TO_PKT(skb), _pkt, sizeof(skb->cb)); The error was: In file included from ./include/linux/bitmap.h:8:0, from ./include/linux/cpumask.h:11, from

[PATCH 3/6] x86/power/64: Use char arrays for asm function names

This switches the hibernate_64.S function names into character arrays to match other areas of the kernel where this is done (e.g., linker scripts). Specifically this fixes a compile-time error noticed by the future CONFIG_FORTIFY_SOURCE routines that complained about PAGE_SIZE being copied out of

[PATCH] FORTIFY_SOURCE build fixes

I was originally carrying these patches in my KSPP tree, but akpm is taking the FORTIFY_SOURCE patch into -mm. As such, these fixes should be included as well. -Kees

[PATCH] FORTIFY_SOURCE build fixes

I was originally carrying these patches in my KSPP tree, but akpm is taking the FORTIFY_SOURCE patch into -mm. As such, these fixes should be included as well. -Kees

Re: [PATCH 2/5] Protectable Memory Allocator

Igor Stoppa wrote: > +int pmalloc_protect_pool(struct pmalloc_pool *pool) > +{ > + struct pmalloc_node *node; > + > + if (!pool) > + return -EINVAL; > + mutex_lock(>nodes_list_mutex); > + hlist_for_each_entry(node, >nodes_list_head, nodes_list) { > +

Re: [PATCH 2/5] Protectable Memory Allocator

Igor Stoppa wrote: > +int pmalloc_protect_pool(struct pmalloc_pool *pool) > +{ > + struct pmalloc_node *node; > + > + if (!pool) > + return -EINVAL; > + mutex_lock(>nodes_list_mutex); > + hlist_for_each_entry(node, >nodes_list_head, nodes_list) { > +

Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

On Tue, Jun 06, 2017 at 05:56:20AM +0200, Jason A. Donenfeld wrote: > Hey Ted, > > On Tue, Jun 6, 2017 at 5:00 AM, Theodore Ts'o wrote: > > Note that crypto_rng_reset() is called by big_key_init() in > > security/keys/big_key.c as a late_initcall(). So if we are on a > > system

Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

On Tue, Jun 06, 2017 at 05:56:20AM +0200, Jason A. Donenfeld wrote: > Hey Ted, > > On Tue, Jun 6, 2017 at 5:00 AM, Theodore Ts'o wrote: > > Note that crypto_rng_reset() is called by big_key_init() in > > security/keys/big_key.c as a late_initcall(). So if we are on a > > system where the crng

Re: [PATCH 2/6] mm: vmstat: move slab statistics from zone to node counters

the node counters because the > zones have special boot pagesets, whereas the nodes do not. > > Add boot nodestats against which we account until the dynamic per-cpu > allocator is available. This isn't working for me. I applied it on top of next-20170605, I still get an oops:

Re: [PATCH 2/6] mm: vmstat: move slab statistics from zone to node counters

ial boot pagesets, whereas the nodes do not. > > Add boot nodestats against which we account until the dynamic per-cpu > allocator is available. This isn't working for me. I applied it on top of next-20170605, I still get an oops: $ qemu-system-ppc64 -M pseries -m 1G -kernel build/vmlinu

[PATCH v7 1/1] clk: bcm: Add clocks for Stingray SOC

From: Sandeep Tripathy This patch adds support for Stingray clocks in iproc ccf. The Stingray SOC has various plls based on iproc pll architecture. Signed-off-by: Sandeep Tripathy Signed-off-by: Anup Patel

[PATCH v7 1/1] clk: bcm: Add clocks for Stingray SOC

From: Sandeep Tripathy This patch adds support for Stingray clocks in iproc ccf. The Stingray SOC has various plls based on iproc pll architecture. Signed-off-by: Sandeep Tripathy Signed-off-by: Anup Patel Reviewed-by: Ray Jui Reviewed-by: Scott Branden --- drivers/clk/bcm/Kconfig | 8

[PATCH v7 0/1] Broadcom Stingray SOC Initial Support

This patchset adds initial support of Broadcom Stingray SOC by reusing existing Broadcom iProc device drivers. Most of the patches in this patchset are DT patches except the Stingray clock tree support which just one patch. This patchset is based on Linux-4.12-rc4 and it is also available at

[PATCH v7 0/1] Broadcom Stingray SOC Initial Support

This patchset adds initial support of Broadcom Stingray SOC by reusing existing Broadcom iProc device drivers. Most of the patches in this patchset are DT patches except the Stingray clock tree support which just one patch. This patchset is based on Linux-4.12-rc4 and it is also available at

Re: [PATCH v6 03/11] clk: bcm: Add clocks for Stingray SOC

On Sat, Jun 3, 2017 at 3:40 AM, Stephen Boyd wrote: > On 06/02, Anup Patel wrote: >> diff --git a/drivers/clk/bcm/clk-sr.c b/drivers/clk/bcm/clk-sr.c >> new file mode 100644 >> index 000..342f702 >> --- /dev/null >> +++ b/drivers/clk/bcm/clk-sr.c >> @@ -0,0 +1,320 @@ >>

Re: [PATCH v6 03/11] clk: bcm: Add clocks for Stingray SOC

On Sat, Jun 3, 2017 at 3:40 AM, Stephen Boyd wrote: > On 06/02, Anup Patel wrote: >> diff --git a/drivers/clk/bcm/clk-sr.c b/drivers/clk/bcm/clk-sr.c >> new file mode 100644 >> index 000..342f702 >> --- /dev/null >> +++ b/drivers/clk/bcm/clk-sr.c >> @@ -0,0 +1,320 @@ >> + >> +static const

Re: [PATCH 0/7] dra7: Fixes for MMC devicetree node

Hi, On Friday 02 June 2017 04:20 PM, Ulf Hansson wrote: > On 1 June 2017 at 16:33, Kishon Vijay Abraham I wrote: >> There are the set of fixes that were sent initially as part >> of [1]. >> >> These are mostly fixes w.r.t populating regulators in >> mmc dt node. It was working

Re: [PATCH 0/7] dra7: Fixes for MMC devicetree node

Hi, On Friday 02 June 2017 04:20 PM, Ulf Hansson wrote: > On 1 June 2017 at 16:33, Kishon Vijay Abraham I wrote: >> There are the set of fixes that were sent initially as part >> of [1]. >> >> These are mostly fixes w.r.t populating regulators in >> mmc dt node. It was working before because the

Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

Hey Ted, On Tue, Jun 6, 2017 at 5:00 AM, Theodore Ts'o wrote: > Note that crypto_rng_reset() is called by big_key_init() in > security/keys/big_key.c as a late_initcall(). So if we are on a > system where the crng doesn't get initialized until during the system > boot scripts,

Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

Hey Ted, On Tue, Jun 6, 2017 at 5:00 AM, Theodore Ts'o wrote: > Note that crypto_rng_reset() is called by big_key_init() in > security/keys/big_key.c as a late_initcall(). So if we are on a > system where the crng doesn't get initialized until during the system > boot scripts, and big_key is

Re: [PATCH RFC 1/2] thermal/cpu idle cooling: Introduce cpu idle cooling driver

+ Daniel On 05-06-17, 17:07, Tao Wang wrote: > cpu idle cooling driver performs synchronized idle injection across > all cpu in same cluster, offers a new method to cooling down cpu, > that is similar to intel_power_clamp driver, but is basically > designed for ARM platform. > Each cluster has

Re: [PATCH RFC 1/2] thermal/cpu idle cooling: Introduce cpu idle cooling driver

+ Daniel On 05-06-17, 17:07, Tao Wang wrote: > cpu idle cooling driver performs synchronized idle injection across > all cpu in same cluster, offers a new method to cooling down cpu, > that is similar to intel_power_clamp driver, but is basically > designed for ARM platform. > Each cluster has

Re: [PATCH v2] arch/sparc: support NR_CPUS = 4096

From: jane@oracle.com Date: Mon, 5 Jun 2017 20:03:28 -0700 > On sun4v sparc, it looks like kzalloc(64, GFP_KERNEL) ends up > allocating from kmalloc_caches[6] - a 64-byte kmem-cache allocated > by kmem_cache_init() with SLAB_HWCACHE_ALIGN flag set, so it's in > l3-cache-line-size alignment,

Re: [PATCH v2] arch/sparc: support NR_CPUS = 4096

From: jane@oracle.com Date: Mon, 5 Jun 2017 20:03:28 -0700 > On sun4v sparc, it looks like kzalloc(64, GFP_KERNEL) ends up > allocating from kmalloc_caches[6] - a 64-byte kmem-cache allocated > by kmem_cache_init() with SLAB_HWCACHE_ALIGN flag set, so it's in > l3-cache-line-size alignment,

Re: [PATCH v6 00/11] Broadcom Stingray SOC Initial Support

On Tue, Jun 6, 2017 at 7:38 AM, Florian Fainelli wrote: > > > On 06/05/2017 09:51 AM, Florian Fainelli wrote: >> On 06/01/2017 11:34 PM, Anup Patel wrote: >>> This patchset adds initial support of Broadcom Stingray SOC >>> by reusing existing Broadcom iProc device drivers.

Re: [PATCH v6 00/11] Broadcom Stingray SOC Initial Support

On Tue, Jun 6, 2017 at 7:38 AM, Florian Fainelli wrote: > > > On 06/05/2017 09:51 AM, Florian Fainelli wrote: >> On 06/01/2017 11:34 PM, Anup Patel wrote: >>> This patchset adds initial support of Broadcom Stingray SOC >>> by reusing existing Broadcom iProc device drivers. >>> >>> Most of the

[PATCH v2] platform/x86: wmi-bmof: New driver to expose embedded Binary WMI MOF metadata

Many laptops (and maybe servers?) have embedded WMI Binary MOF metadata. We do not yet have open-source tools for processing the data, although one is in the works thanks to Pali: https://github.com/pali/bmfdec There is currently no interface to get the data in the first place. By

[PATCH v2] platform/x86: wmi-bmof: New driver to expose embedded Binary WMI MOF metadata

Many laptops (and maybe servers?) have embedded WMI Binary MOF metadata. We do not yet have open-source tools for processing the data, although one is in the works thanks to Pali: https://github.com/pali/bmfdec There is currently no interface to get the data in the first place. By

Re: [PATCH V2 0/3] Refine numa_emulation

Ping~ Willing to hear some feed back :-) On Tue, May 02, 2017 at 09:04:50PM +0800, Wei Yang wrote: >My previous patch "x86/mm/numa: Remove numa_nodemask_from_meminfo()" hits a >problem in numa_emulation. The reason is numa_nodes_parsed is not set >correctly after emulation. > >This patch set

Re: [PATCH V2 0/3] Refine numa_emulation

Ping~ Willing to hear some feed back :-) On Tue, May 02, 2017 at 09:04:50PM +0800, Wei Yang wrote: >My previous patch "x86/mm/numa: Remove numa_nodemask_from_meminfo()" hits a >problem in numa_emulation. The reason is numa_nodes_parsed is not set >correctly after emulation. > >This patch set

Re: [PATCH] EDAC: mv64x60 calculate memory size correctly

On 06/06/17 14:41, Chris Packham wrote: > The #address-cells and #size-cells properties need to be accounted for > when dealing with the "memory" device tree node. > > Signed-off-by: Chris Packham > --- > drivers/edac/mv64x60_edac.c | 30

Re: [PATCH] EDAC: mv64x60 calculate memory size correctly

On 06/06/17 14:41, Chris Packham wrote: > The #address-cells and #size-cells properties need to be accounted for > when dealing with the "memory" device tree node. > > Signed-off-by: Chris Packham > --- > drivers/edac/mv64x60_edac.c | 30 +- > 1 file changed, 21

Re: [PATCH 4/4] arm64: dts: uniphier: add nodes of thermal monitor and thermal zone for LD20

2017-05-29 18:15 GMT+09:00 Kunihiko Hayashi : > Add nodes of thermal monitor and thermal zone for UniPhier LD20 SoC. > The thermal monitor is included in sysctrl. > > Furthermore, since SoC installed in the reference board doesn't have a > calibrated value of

Re: [PATCH 16/16] platform/x86: dell-wmi: Convert to the WMI bus infrastructure

On Mon, May 29, 2017 at 07:45:05PM -0700, Dmitry Torokhov wrote: > On Sat, May 27, 2017 at 11:40:52AM -0700, Andy Lutomirski wrote: > > On Sat, May 27, 2017 at 9:17 AM, Dmitry Torokhov > > wrote: > > > On May 27, 2017 9:04:38 AM PDT, Andy Lutomirski

Re: [PATCH 4/4] arm64: dts: uniphier: add nodes of thermal monitor and thermal zone for LD20

2017-05-29 18:15 GMT+09:00 Kunihiko Hayashi : > Add nodes of thermal monitor and thermal zone for UniPhier LD20 SoC. > The thermal monitor is included in sysctrl. > > Furthermore, since SoC installed in the reference board doesn't have a > calibrated value of thermal monitor, this patch gives the

Re: [PATCH 16/16] platform/x86: dell-wmi: Convert to the WMI bus infrastructure

On Mon, May 29, 2017 at 07:45:05PM -0700, Dmitry Torokhov wrote: > On Sat, May 27, 2017 at 11:40:52AM -0700, Andy Lutomirski wrote: > > On Sat, May 27, 2017 at 9:17 AM, Dmitry Torokhov > > wrote: > > > On May 27, 2017 9:04:38 AM PDT, Andy Lutomirski wrote: > > >>On Sat, May 27, 2017 at 3:50 AM,

Re: [RFC PATCH 2/4] mm, tree wide: replace __GFP_REPEAT by __GFP_RETRY_MAYFAIL with more useful semantic

On Mon, Jun 05, 2017 at 08:43:43AM +0200, Michal Hocko wrote: >On Sat 03-06-17 10:24:40, Wei Yang wrote: >> Hi, Michal >> >> Just go through your patch. >> >> I have one question and one suggestion as below. >> >> One suggestion: >> >> This patch does two things to me: >> 1. Replace

Re: [RFC PATCH 2/4] mm, tree wide: replace __GFP_REPEAT by __GFP_RETRY_MAYFAIL with more useful semantic

On Mon, Jun 05, 2017 at 08:43:43AM +0200, Michal Hocko wrote: >On Sat 03-06-17 10:24:40, Wei Yang wrote: >> Hi, Michal >> >> Just go through your patch. >> >> I have one question and one suggestion as below. >> >> One suggestion: >> >> This patch does two things to me: >> 1. Replace

Re: [PATCH v2] arch/sparc: support NR_CPUS = 4096

On 06/05/2017 05:57 PM, David Miller wrote: From: Jane Chu Date: Mon, 5 Jun 2017 16:48:31 -0600 Linux SPARC64 limits NR_CPUS to 4064 because init_cpu_send_mondo_info() only allocates a single page for NR_CPUS mondo entries. Thus we cannot use all 4096 CPUs on some SPARC

Re: [PATCH v2] arch/sparc: support NR_CPUS = 4096

On 06/05/2017 05:57 PM, David Miller wrote: From: Jane Chu Date: Mon, 5 Jun 2017 16:48:31 -0600 Linux SPARC64 limits NR_CPUS to 4064 because init_cpu_send_mondo_info() only allocates a single page for NR_CPUS mondo entries. Thus we cannot use all 4096 CPUs on some SPARC platforms. To fix,

Re: [PATCH 09/16] platform/x86: wmi: Instantiate all devices before adding them

On Thu, Jun 01, 2017 at 10:43:39PM +0200, Michał Kępień wrote: > I know I have probably started sounding like a broken record by now, but > I still have not seen any response (apart from the typos getting fixed) > to my comments on this patch which I posted in January 2016 [1]. > > None of the

Re: [PATCH 09/16] platform/x86: wmi: Instantiate all devices before adding them

On Thu, Jun 01, 2017 at 10:43:39PM +0200, Michał Kępień wrote: > I know I have probably started sounding like a broken record by now, but > I still have not seen any response (apart from the typos getting fixed) > to my comments on this patch which I posted in January 2016 [1]. > > None of the

Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

On Tue, Jun 06, 2017 at 02:50:59AM +0200, Jason A. Donenfeld wrote: > Otherwise, we might be seeding the RNG using bad randomness, which is > dangerous. > > Cc: Herbert Xu > Signed-off-by: Jason A. Donenfeld > --- > crypto/rng.c | 6 -- > 1

Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

On Tue, Jun 06, 2017 at 02:50:59AM +0200, Jason A. Donenfeld wrote: > Otherwise, we might be seeding the RNG using bad randomness, which is > dangerous. > > Cc: Herbert Xu > Signed-off-by: Jason A. Donenfeld > --- > crypto/rng.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) >

Re: [PATCH 4/5] ARM: sun8i: a83t: Add dt node for the syscon control module

On Tue, Jun 6, 2017 at 3:21 AM, Corentin Labbe wrote: > This patch add the dt node for the syscon register present on the > Allwinner A83T > > Signed-off-by: Corentin Labbe > --- > arch/arm/boot/dts/sun8i-a83t.dtsi | 6 ++ > 1 file

Re: [PATCH 4/5] ARM: sun8i: a83t: Add dt node for the syscon control module

On Tue, Jun 6, 2017 at 3:21 AM, Corentin Labbe wrote: > This patch add the dt node for the syscon register present on the > Allwinner A83T > > Signed-off-by: Corentin Labbe > --- > arch/arm/boot/dts/sun8i-a83t.dtsi | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git

Re: [Qemu-devel] [PATCH 0/7] KVM: MMU: fast write protect

On 06/05/2017 03:36 PM, Jay Zhou wrote: /* enable ucontrol for s390 */ struct kvm_s390_ucas_mapping { diff --git a/memory.c b/memory.c index 4c95aaf..b836675 100644 --- a/memory.c +++ b/memory.c @@ -809,6 +809,13 @@ static void address_space_update_ioeventfds(AddressSpace *as)

Re: [Qemu-devel] [PATCH 0/7] KVM: MMU: fast write protect

On 06/05/2017 03:36 PM, Jay Zhou wrote: /* enable ucontrol for s390 */ struct kvm_s390_ucas_mapping { diff --git a/memory.c b/memory.c index 4c95aaf..b836675 100644 --- a/memory.c +++ b/memory.c @@ -809,6 +809,13 @@ static void address_space_update_ioeventfds(AddressSpace *as)

Re: [PATCH 2/4] dt-bindings: thermal: add binding documentation for UniPhier thermal monitor

2017-05-29 18:15 GMT+09:00 Kunihiko Hayashi : > Add devicetree binding documentation for thermal monitor implemented on > Socionext UniPhier SoCs. > > Signed-off-by: Kunihiko Hayashi > --- > .../bindings/thermal/uniphier-thermal.txt

Re: [PATCH 2/4] dt-bindings: thermal: add binding documentation for UniPhier thermal monitor

2017-05-29 18:15 GMT+09:00 Kunihiko Hayashi : > Add devicetree binding documentation for thermal monitor implemented on > Socionext UniPhier SoCs. > > Signed-off-by: Kunihiko Hayashi > --- > .../bindings/thermal/uniphier-thermal.txt | 54 > ++ > 1 file changed, 54

[PATCH] EDAC: mv64x60 calculate memory size correctly

The #address-cells and #size-cells properties need to be accounted for when dealing with the "memory" device tree node. Signed-off-by: Chris Packham --- drivers/edac/mv64x60_edac.c | 30 +- 1 file changed, 21 insertions(+), 9

[PATCH] EDAC: mv64x60 calculate memory size correctly

The #address-cells and #size-cells properties need to be accounted for when dealing with the "memory" device tree node. Signed-off-by: Chris Packham --- drivers/edac/mv64x60_edac.c | 30 +- 1 file changed, 21 insertions(+), 9 deletions(-) diff --git

Re: [PATCH 15/16] platform/x86: wmi-mof: New driver to expose embedded WMI MOF metadata

On Tue, Jun 06, 2017 at 12:19:26AM +0200, Pali Rohár wrote: > On Tuesday 06 June 2017 00:14:56 Darren Hart wrote: > > On Sat, May 27, 2017 at 01:14:15PM +0200, Pali Rohár wrote: > > > > metadata. I think that Samba has tools to interpret it, but there > > > > is currently no interface to get the

Re: [PATCH 15/16] platform/x86: wmi-mof: New driver to expose embedded WMI MOF metadata

On Tue, Jun 06, 2017 at 12:19:26AM +0200, Pali Rohár wrote: > On Tuesday 06 June 2017 00:14:56 Darren Hart wrote: > > On Sat, May 27, 2017 at 01:14:15PM +0200, Pali Rohár wrote: > > > > metadata. I think that Samba has tools to interpret it, but there > > > > is currently no interface to get the

w1_therm should not unlock bus if strong pullup is forced

Hi, If strong pullup is forced (=2) a strong pullup is placed for 750ms. Is also external power detected the bus will be unlocked and a additional 750ms sleep is performed. This 2nd sleep should be avoided. Kind regards, Ingo Flaschberger --- w1_therm.c_org 2017-06-06

w1_therm should not unlock bus if strong pullup is forced

Hi, If strong pullup is forced (=2) a strong pullup is placed for 750ms. Is also external power detected the bus will be unlocked and a additional 750ms sleep is performed. This 2nd sleep should be avoided. Kind regards, Ingo Flaschberger --- w1_therm.c_org 2017-06-06

Re: [PATCH] arm: aspeed: Add clock-names property to timer node

On Tue, Jun 6, 2017 at 6:41 AM, Daniel Lezcano wrote: > On Mon, Jun 05, 2017 at 06:29:53PM +0930, Joel Stanley wrote: >> On Mon, Jun 5, 2017 at 5:18 PM, Andrew Jeffery wrote: >> > The merging of a number of clocksource drivers into fttmr010 means we >>

Re: [PATCH] arm: aspeed: Add clock-names property to timer node

On Tue, Jun 6, 2017 at 6:41 AM, Daniel Lezcano wrote: > On Mon, Jun 05, 2017 at 06:29:53PM +0930, Joel Stanley wrote: >> On Mon, Jun 5, 2017 at 5:18 PM, Andrew Jeffery wrote: >> > The merging of a number of clocksource drivers into fttmr010 means we >> > require clock-names to be specified in

Re: [PATCH v6 00/11] Broadcom Stingray SOC Initial Support

On 06/05/2017 09:51 AM, Florian Fainelli wrote: > On 06/01/2017 11:34 PM, Anup Patel wrote: >> This patchset adds initial support of Broadcom Stingray SOC >> by reusing existing Broadcom iProc device drivers. >> >> Most of the patches in this patchset are DT patches except >> the Stingray clock

Re: [PATCH v6 00/11] Broadcom Stingray SOC Initial Support

On 06/05/2017 09:51 AM, Florian Fainelli wrote: > On 06/01/2017 11:34 PM, Anup Patel wrote: >> This patchset adds initial support of Broadcom Stingray SOC >> by reusing existing Broadcom iProc device drivers. >> >> Most of the patches in this patchset are DT patches except >> the Stingray clock

Re: [PATCH v3 32/37] mtd: nand: denali: support hardware-assisted erased page detection

Hi Boris, 2017-03-31 1:30 GMT+09:00 Boris Brezillon : > On Thu, 30 Mar 2017 17:15:03 +0900 > Masahiro Yamada wrote: > >> Recent versions of this IP support automatic erased page detection. >> If an erased page is detected on

Re: [PATCH v3 32/37] mtd: nand: denali: support hardware-assisted erased page detection

Hi Boris, 2017-03-31 1:30 GMT+09:00 Boris Brezillon : > On Thu, 30 Mar 2017 17:15:03 +0900 > Masahiro Yamada wrote: > >> Recent versions of this IP support automatic erased page detection. >> If an erased page is detected on reads, the controller does not set >> INTR__ECC_UNCOR_ERR, but

Re: [RFC] usb-phy-generic: Add support to SMSC USB3315

On Mon, Jun 05, 2017 at 11:52:26AM +0200, Fabien Lahoudere wrote: > On Mon, 2017-06-05 at 17:43 +0800, Peter Chen wrote: > > On Mon, Jun 05, 2017 at 10:57:00AM +0200, Fabien Lahoudere wrote: > > > On Fri, 2017-06-02 at 15:00 -0700, Stephen Boyd wrote: > > > > On 05/26, Fabien Lahoudere wrote: > >

Re: [RFC] usb-phy-generic: Add support to SMSC USB3315

On Mon, Jun 05, 2017 at 11:52:26AM +0200, Fabien Lahoudere wrote: > On Mon, 2017-06-05 at 17:43 +0800, Peter Chen wrote: > > On Mon, Jun 05, 2017 at 10:57:00AM +0200, Fabien Lahoudere wrote: > > > On Fri, 2017-06-02 at 15:00 -0700, Stephen Boyd wrote: > > > > On 05/26, Fabien Lahoudere wrote: > >

  1   2   3   4   5   6   7   8   9   10   >