[PATCH 3/7] metag: remove arch specific early DT functions

Now that the DT core code handles bootmem arches, we can remove the metag specific early_init_dt_alloc_memory_arch function. As the default early_init_dt_add_memory_arch just does a WARN, we can remove it too. Cc: James Hogan Cc: linux-me...@vger.kernel.org Signed-off-by: Rob

[PATCH 5/7] nios2: remove arch specific early_init_dt_alloc_memory_arch

Now that the DT core code handles bootmem arches, we can remove the nios2 specific early_init_dt_alloc_memory_arch function. Cc: Ley Foon Tan Cc: nios2-...@lists.rocketboards.org Signed-off-by: Rob Herring --- This is dependent on patch 1. Please ack and I'll

[PATCH 0/7] DT: consolidate bootmem support

This series adds support for bootmem to the DT core code and removes the remaining arch specific early_init_dt_alloc_memory_arch implementations. Compile tested only on arm64, mips, x86, and xtensa. Rob Rob Herring (7): of/fdt: use memblock_virt_alloc for early alloc cris: remove arch

[PATCH 2/7] cris: remove arch specific early DT functions

Now that the DT core code handles bootmem arches, we can remove the cris specific early_init_dt_alloc_memory_arch function. As the default early_init_dt_add_memory_arch just does a WARN, we can just remove the entire devicetree.c file. Cc: Mikael Starvik Cc: Jesper Nilsson

[PATCH 6/7] x86: remove arch specific early_init_dt_alloc_memory_arch

Now that the DT core code handles bootmem arches, we can remove the x86 specific early_init_dt_alloc_memory_arch function. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org Signed-off-by: Rob Herring

[PATCH 3/7] metag: remove arch specific early DT functions

Now that the DT core code handles bootmem arches, we can remove the metag specific early_init_dt_alloc_memory_arch function. As the default early_init_dt_add_memory_arch just does a WARN, we can remove it too. Cc: James Hogan Cc: linux-me...@vger.kernel.org Signed-off-by: Rob Herring --- This

[PATCH 5/7] nios2: remove arch specific early_init_dt_alloc_memory_arch

Now that the DT core code handles bootmem arches, we can remove the nios2 specific early_init_dt_alloc_memory_arch function. Cc: Ley Foon Tan Cc: nios2-...@lists.rocketboards.org Signed-off-by: Rob Herring --- This is dependent on patch 1. Please ack and I'll take or apply after 4.16-rc1.

[PATCH 0/7] DT: consolidate bootmem support

This series adds support for bootmem to the DT core code and removes the remaining arch specific early_init_dt_alloc_memory_arch implementations. Compile tested only on arm64, mips, x86, and xtensa. Rob Rob Herring (7): of/fdt: use memblock_virt_alloc for early alloc cris: remove arch

[PATCH 2/7] cris: remove arch specific early DT functions

Now that the DT core code handles bootmem arches, we can remove the cris specific early_init_dt_alloc_memory_arch function. As the default early_init_dt_add_memory_arch just does a WARN, we can just remove the entire devicetree.c file. Cc: Mikael Starvik Cc: Jesper Nilsson Cc:

[PATCH 6/7] x86: remove arch specific early_init_dt_alloc_memory_arch

Now that the DT core code handles bootmem arches, we can remove the x86 specific early_init_dt_alloc_memory_arch function. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org Signed-off-by: Rob Herring --- This is dependent on patch 1. Please ack and I'll take or

[PATCH 4/7] mips: remove arch specific early_init_dt_alloc_memory_arch

Now that the DT core code handles bootmem arches, we can remove the MIPS specific early_init_dt_alloc_memory_arch function. Cc: Ralf Baechle Cc: linux-m...@linux-mips.org Signed-off-by: Rob Herring --- This is dependent on patch 1. Please ack and I'll take

[PATCH 1/7] of/fdt: use memblock_virt_alloc for early alloc

memblock_virt_alloc() works for both memblock and bootmem, so use it and make early_init_dt_alloc_memory_arch a static function. The arches using bootmem define early_init_dt_alloc_memory_arch as either: __alloc_bootmem(size, align, __pa(MAX_DMA_ADDRESS)) or: alloc_bootmem_align(size, align)

[PATCH 1/7] of/fdt: use memblock_virt_alloc for early alloc

memblock_virt_alloc() works for both memblock and bootmem, so use it and make early_init_dt_alloc_memory_arch a static function. The arches using bootmem define early_init_dt_alloc_memory_arch as either: __alloc_bootmem(size, align, __pa(MAX_DMA_ADDRESS)) or: alloc_bootmem_align(size, align)

[PATCH 4/7] mips: remove arch specific early_init_dt_alloc_memory_arch

Now that the DT core code handles bootmem arches, we can remove the MIPS specific early_init_dt_alloc_memory_arch function. Cc: Ralf Baechle Cc: linux-m...@linux-mips.org Signed-off-by: Rob Herring --- This is dependent on patch 1. Please ack and I'll take or apply after 4.16-rc1.

[PATCH 7/7] xtensa: remove arch specific early DT functions

Now that the DT core code handles bootmem arches, we can remove the xtensa specific early_init_dt_alloc_memory_arch function. The common early_init_dt_add_memory_arch can be used too now that xtensa switched to memblock. Cc: Chris Zankel Cc: Max Filippov

Re: [PATCH v4 1/2] ARM64: dts: meson-axg: add ethernet mac controller

Yixun Lan writes: > Add DT info for the stmmac ethernet MAC which found in > the Amlogic's Meson-AXG SoC, also describe the ethernet > pinctrl & clock information here. > > Reviewed-by: Neil Armstrong > Signed-off-by: Yixun Lan

[PATCH 7/7] xtensa: remove arch specific early DT functions

Now that the DT core code handles bootmem arches, we can remove the xtensa specific early_init_dt_alloc_memory_arch function. The common early_init_dt_add_memory_arch can be used too now that xtensa switched to memblock. Cc: Chris Zankel Cc: Max Filippov Cc: linux-xte...@linux-xtensa.org

Re: [PATCH v4 1/2] ARM64: dts: meson-axg: add ethernet mac controller

Yixun Lan writes: > Add DT info for the stmmac ethernet MAC which found in > the Amlogic's Meson-AXG SoC, also describe the ethernet > pinctrl & clock information here. > > Reviewed-by: Neil Armstrong > Signed-off-by: Yixun Lan Applied to v4.16/dt64, Kevin

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Fri, Jan 5, 2018 at 1:03 PM, Pavel Tatashin wrote: > The hardware works :) I meant that before the patch linked in > https://lkml.org/lkml/2018/1/5/534, I was never able to boot 4.4.110. But > with that patch applied, I was able to boot it at least once, but it could

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Fri, Jan 5, 2018 at 1:03 PM, Pavel Tatashin wrote: > The hardware works :) I meant that before the patch linked in > https://lkml.org/lkml/2018/1/5/534, I was never able to boot 4.4.110. But > with that patch applied, I was able to boot it at least once, but it could > be accidental. The

[PATCH 1/7] of/fdt: use memblock_virt_alloc for early alloc

memblock_virt_alloc() works for both memblock and bootmem, so use it and make early_init_dt_alloc_memory_arch a static function. The arches using bootmem define early_init_dt_alloc_memory_arch as either: __alloc_bootmem(size, align, __pa(MAX_DMA_ADDRESS)) or: alloc_bootmem_align(size, align)

[PATCH 1/7] of/fdt: use memblock_virt_alloc for early alloc

memblock_virt_alloc() works for both memblock and bootmem, so use it and make early_init_dt_alloc_memory_arch a static function. The arches using bootmem define early_init_dt_alloc_memory_arch as either: __alloc_bootmem(size, align, __pa(MAX_DMA_ADDRESS)) or: alloc_bootmem_align(size, align)

[PATCH 3/7] metag: remove arch specific early DT functions

Now that the DT core code handles bootmem arches, we can remove the metag specific early_init_dt_alloc_memory_arch function. As the default early_init_dt_add_memory_arch just does a WARN, we can remove it too. Cc: James Hogan Cc: linux-me...@vger.kernel.org Signed-off-by: Rob

[PATCH 3/7] metag: remove arch specific early DT functions

Now that the DT core code handles bootmem arches, we can remove the metag specific early_init_dt_alloc_memory_arch function. As the default early_init_dt_add_memory_arch just does a WARN, we can remove it too. Cc: James Hogan Cc: linux-me...@vger.kernel.org Signed-off-by: Rob Herring --- This

[PATCH 0/7] DT: consolidate bootmem support

This series adds support for bootmem to the DT core code and removes the remaining arch specific early_init_dt_alloc_memory_arch implementations. Compile tested only on arm64, mips, x86, and xtensa. Rob Rob Herring (7): of/fdt: use memblock_virt_alloc for early alloc cris: remove arch

[PATCH 4/7] mips: remove arch specific early_init_dt_alloc_memory_arch

Now that the DT core code handles bootmem arches, we can remove the MIPS specific early_init_dt_alloc_memory_arch function. Cc: Ralf Baechle Cc: linux-m...@linux-mips.org Signed-off-by: Rob Herring --- This is dependent on patch 1. Please ack and I'll take

[PATCH 2/7] cris: remove arch specific early DT functions

Now that the DT core code handles bootmem arches, we can remove the cris specific early_init_dt_alloc_memory_arch function. As the default early_init_dt_add_memory_arch just does a WARN, we can just remove the entire devicetree.c file. Cc: Mikael Starvik Cc: Jesper Nilsson

[PATCH 0/7] DT: consolidate bootmem support

This series adds support for bootmem to the DT core code and removes the remaining arch specific early_init_dt_alloc_memory_arch implementations. Compile tested only on arm64, mips, x86, and xtensa. Rob Rob Herring (7): of/fdt: use memblock_virt_alloc for early alloc cris: remove arch

[PATCH 4/7] mips: remove arch specific early_init_dt_alloc_memory_arch

Now that the DT core code handles bootmem arches, we can remove the MIPS specific early_init_dt_alloc_memory_arch function. Cc: Ralf Baechle Cc: linux-m...@linux-mips.org Signed-off-by: Rob Herring --- This is dependent on patch 1. Please ack and I'll take or apply after 4.16-rc1.

[PATCH 2/7] cris: remove arch specific early DT functions

Now that the DT core code handles bootmem arches, we can remove the cris specific early_init_dt_alloc_memory_arch function. As the default early_init_dt_add_memory_arch just does a WARN, we can just remove the entire devicetree.c file. Cc: Mikael Starvik Cc: Jesper Nilsson Cc:

[PATCH] ia64: Fix syntax error introduced by e2339a4caa5e

Remove extra parentheses. Signed-off-by: Valentin Ilie --- arch/ia64/kernel/time.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/ia64/kernel/time.c b/arch/ia64/kernel/time.c index c6ecb97..9025699 100644 --- a/arch/ia64/kernel/time.c +++

[PATCH] ia64: Fix syntax error introduced by e2339a4caa5e

Remove extra parentheses. Signed-off-by: Valentin Ilie --- arch/ia64/kernel/time.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/ia64/kernel/time.c b/arch/ia64/kernel/time.c index c6ecb97..9025699 100644 --- a/arch/ia64/kernel/time.c +++ b/arch/ia64/kernel/time.c @@

Re: Failing S3 resume since "Add missing irqflags tracing to native_load_gs_index()"

> On Jan 5, 2018, at 1:51 PM, Harry Wentland wrote: > >> On 2018-01-05 04:28 PM, Andy Lutomirski wrote: >> It's a known issue, and it should be fixed in newer -rc kernels. >> > > I'm still seeing this on v4.15-rc6. Will I need rc7 or the latest x86 merges > in

Re: Failing S3 resume since "Add missing irqflags tracing to native_load_gs_index()"

> On Jan 5, 2018, at 1:51 PM, Harry Wentland wrote: > >> On 2018-01-05 04:28 PM, Andy Lutomirski wrote: >> It's a known issue, and it should be fixed in newer -rc kernels. >> > > I'm still seeing this on v4.15-rc6. Will I need rc7 or the latest x86 merges > in linus's master? > No, it

Re: [V4, 01/11] Documentation: Add license-rules.rst to describe how to properly identify file licenses

On 05/01/2018 at 14:48:04 -0800, Frank Rowand wrote: > On 01/05/18 05:05, Alexandre Belloni wrote: > > Hi, > > > > I'm definitively late to the party but... > > > > On 17/11/2017 at 11:00:33 +0100, Thomas Gleixner wrote: > >> +2. Style: > >> + > >> + The SPDX license identifier is added in

Re: [V4, 01/11] Documentation: Add license-rules.rst to describe how to properly identify file licenses

On 05/01/2018 at 14:48:04 -0800, Frank Rowand wrote: > On 01/05/18 05:05, Alexandre Belloni wrote: > > Hi, > > > > I'm definitively late to the party but... > > > > On 17/11/2017 at 11:00:33 +0100, Thomas Gleixner wrote: > >> +2. Style: > >> + > >> + The SPDX license identifier is added in

Re: [PATCH v2] ARM64: dts: meson-axg: add the SPICC controller

Yixun Lan writes: > From: Sunny Luo > > Add DT info for the SPICC controller which found in > the Amlogic's Meson-AXG SoC. > > Signed-off-by: Sunny Luo > Signed-off-by: Yixun Lan Applied with Neil's

Re: [PATCH v2] ARM64: dts: meson-axg: add the SPICC controller

Yixun Lan writes: > From: Sunny Luo > > Add DT info for the SPICC controller which found in > the Amlogic's Meson-AXG SoC. > > Signed-off-by: Sunny Luo > Signed-off-by: Yixun Lan Applied with Neil's tag. Kevin

Re: [PATCH v8] arm64: dts: meson-axg: switch uart_ao clock to CLK81

Yixun Lan writes: > Switch the uart_ao pclk to CLK81 since the clock driver is ready. > > Signed-off-by: Yixun Lan Applied to v4.16/dt64 with Neil's tag. Kevin

Re: [PATCH v8] arm64: dts: meson-axg: switch uart_ao clock to CLK81

Yixun Lan writes: > Switch the uart_ao pclk to CLK81 since the clock driver is ready. > > Signed-off-by: Yixun Lan Applied to v4.16/dt64 with Neil's tag. Kevin

[PATCH] leaking_addresses: add files to skip

Script currently times out when parsing the following files: /proc/kallsyms /proc/sched_debug /proc/PID/smaps None of these files leak kernel addresses. We can skip parsing them. Add entries to list of files to skip. Signed-off-by: Tobin C. Harding ---

[PATCH] leaking_addresses: add files to skip

Script currently times out when parsing the following files: /proc/kallsyms /proc/sched_debug /proc/PID/smaps None of these files leak kernel addresses. We can skip parsing them. Add entries to list of files to skip. Signed-off-by: Tobin C. Harding ---

Re: [PATCH v7 2/6] perf record: Get the first sample time and last sample time

On 1/5/2018 8:53 PM, Arnaldo Carvalho de Melo wrote: Em Fri, Jan 05, 2018 at 09:15:03AM +0800, Jin, Yao escreveu: On 1/5/2018 3:09 AM, Arnaldo Carvalho de Melo wrote: Em Fri, Dec 08, 2017 at 09:13:42PM +0800, Jin Yao escreveu: In the default 'perf record' configuration, all samples are

Re: [PATCH] tools/power/x86/intel_pstate_tracer: Free the trace buffer memory

On Fri, Jan 5, 2018 at 11:31 PM, Doug Smythies wrote: > The trace buffer memory should be, mostly, freed after > the buffer has been output. > > This patch is required before a future patch that will allow > the user to override the default, and specify the trace buffer >

Re: [PATCH 6/6] add test for aio poll and io_pgetevents

Christoph Hellwig writes: > + p = fork(); > + switch (p) { [snip] > + default: > + close(pipe1[0]); > + close(pipe2[1]); > + > + io_prep_poll(, pipe2[0], POLLIN); > + > + ret = io_setup(1, ); > + if (ret) { > +

Re: [PATCH 6/6] add test for aio poll and io_pgetevents

Christoph Hellwig writes: > + p = fork(); > + switch (p) { [snip] > + default: > + close(pipe1[0]); > + close(pipe2[1]); > + > + io_prep_poll(, pipe2[0], POLLIN); > + > + ret = io_setup(1, ); > + if (ret) { > +

Re: [PATCH v7 2/6] perf record: Get the first sample time and last sample time

On 1/5/2018 8:53 PM, Arnaldo Carvalho de Melo wrote: Em Fri, Jan 05, 2018 at 09:15:03AM +0800, Jin, Yao escreveu: On 1/5/2018 3:09 AM, Arnaldo Carvalho de Melo wrote: Em Fri, Dec 08, 2017 at 09:13:42PM +0800, Jin Yao escreveu: In the default 'perf record' configuration, all samples are

Re: [PATCH] tools/power/x86/intel_pstate_tracer: Free the trace buffer memory

On Fri, Jan 5, 2018 at 11:31 PM, Doug Smythies wrote: > The trace buffer memory should be, mostly, freed after > the buffer has been output. > > This patch is required before a future patch that will allow > the user to override the default, and specify the trace buffer > memory allocation as a

Re: libaio: resurrect aio poll and add io_pgetevents support

Christoph Hellwig writes: > Hi all, > > this series resurrects IOCB_CMD_POLL support and adds support for the > new io_pgetevents system call, as well as adding a test case. This looks good to me. There may be a couple of changes to the syscall bits, but I can take care of that.

Re: libaio: resurrect aio poll and add io_pgetevents support

Christoph Hellwig writes: > Hi all, > > this series resurrects IOCB_CMD_POLL support and adds support for the > new io_pgetevents system call, as well as adding a test case. This looks good to me. There may be a couple of changes to the syscall bits, but I can take care of that. I'll review

Re: [PATCH V4] cpufreq: intel_pstate: allow trace in passive mode

On Fri, Jan 5, 2018 at 11:14 PM, Doug Smythies wrote: > Allow use of the trace_pstate_sample trace function > when the intel_pstate driver is in passive mode. > Since the core_busy and scaled_busy fields are not > used, and it might be desirable to know which path >

Re: [PATCH V4] cpufreq: intel_pstate: allow trace in passive mode

On Fri, Jan 5, 2018 at 11:14 PM, Doug Smythies wrote: > Allow use of the trace_pstate_sample trace function > when the intel_pstate driver is in passive mode. > Since the core_busy and scaled_busy fields are not > used, and it might be desirable to know which path > through the driver was used,

Re: [PATCH 2/6] move _body_io_syscall to the generic syscall.h

Hi, Ben, Thanks for the quick reply. Benjamin LaHaise writes: > On Fri, Jan 05, 2018 at 11:25:17AM -0500, Jeff Moyer wrote: >> Christoph Hellwig writes: >> >> > This way it can be used for the fallback 6-argument version on >> > all architectures. >> > >>

Re: [PATCH 2/6] move _body_io_syscall to the generic syscall.h

Hi, Ben, Thanks for the quick reply. Benjamin LaHaise writes: > On Fri, Jan 05, 2018 at 11:25:17AM -0500, Jeff Moyer wrote: >> Christoph Hellwig writes: >> >> > This way it can be used for the fallback 6-argument version on >> > all architectures. >> > >> > Signed-off-by: Christoph Hellwig

Re: [V4, 01/11] Documentation: Add license-rules.rst to describe how to properly identify file licenses

On 01/05/18 05:05, Alexandre Belloni wrote: > Hi, > > I'm definitively late to the party but... > > On 17/11/2017 at 11:00:33 +0100, Thomas Gleixner wrote: >> +2. Style: >> + >> + The SPDX license identifier is added in form of a comment. The comment >> + style depends on the file type:: >>

Re: [V4, 01/11] Documentation: Add license-rules.rst to describe how to properly identify file licenses

On 01/05/18 05:05, Alexandre Belloni wrote: > Hi, > > I'm definitively late to the party but... > > On 17/11/2017 at 11:00:33 +0100, Thomas Gleixner wrote: >> +2. Style: >> + >> + The SPDX license identifier is added in form of a comment. The comment >> + style depends on the file type:: >>

Re: [PATCH 05/23] x86, kaiser: unmap kernel from userspace page tables (core patch)

On Fri, Jan 5, 2018 at 1:14 PM, Jiri Kosina wrote: > On Fri, 5 Jan 2018, Dave Hansen wrote: > >> >>> --- a/arch/x86/platform/efi/efi_64.c >> >>> +++ b/arch/x86/platform/efi/efi_64.c >> >>> @@ -95,6 +95,12 @@ pgd_t * __init efi_call_phys_prolog(void >> >>> save_pgd[pgd]

Re: [PATCH 05/23] x86, kaiser: unmap kernel from userspace page tables (core patch)

On Fri, Jan 5, 2018 at 1:14 PM, Jiri Kosina wrote: > On Fri, 5 Jan 2018, Dave Hansen wrote: > >> >>> --- a/arch/x86/platform/efi/efi_64.c >> >>> +++ b/arch/x86/platform/efi/efi_64.c >> >>> @@ -95,6 +95,12 @@ pgd_t * __init efi_call_phys_prolog(void >> >>> save_pgd[pgd] =

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Fri, Jan 05, 2018 at 10:16:54PM +, Woodhouse, David wrote: > You'd still want a RETPOLINE_AMD flag to enable that lfence; it's not > just K8. I think you're forgetting that we set K8 on everything >= K8 on AMD. So this: + if (c->x86_vendor == X86_VENDOR_AMD) +

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Fri, Jan 05, 2018 at 10:16:54PM +, Woodhouse, David wrote: > You'd still want a RETPOLINE_AMD flag to enable that lfence; it's not > just K8. I think you're forgetting that we set K8 on everything >= K8 on AMD. So this: + if (c->x86_vendor == X86_VENDOR_AMD) +

[PATCH] tools/power/x86/intel_pstate_tracer: Free the trace buffer memory

The trace buffer memory should be, mostly, freed after the buffer has been output. This patch is required before a future patch that will allow the user to override the default, and specify the trace buffer memory allocation as a command line option. Signed-off-by: Doug Smythies

[PATCH] tools/power/x86/intel_pstate_tracer: Free the trace buffer memory

The trace buffer memory should be, mostly, freed after the buffer has been output. This patch is required before a future patch that will allow the user to override the default, and specify the trace buffer memory allocation as a command line option. Signed-off-by: Doug Smythies ---

Re: [PATCH] Remove silentoldconfig from "make help"; fix kconfig/conf's help

On 04/01/2018 09:21, Masahiro Yamada wrote: > (+CC Michal's new address) > > 2017-12-19 10:26 GMT+09:00 Marc Herbert : >> As explained by Michal Marek at https://lkml.org/lkml/2011/8/31/189 >> silentoldconfig has become a misnomer. It has become an internal >> interface

Re: [PATCH] Remove silentoldconfig from "make help"; fix kconfig/conf's help

On 04/01/2018 09:21, Masahiro Yamada wrote: > (+CC Michal's new address) > > 2017-12-19 10:26 GMT+09:00 Marc Herbert : >> As explained by Michal Marek at https://lkml.org/lkml/2011/8/31/189 >> silentoldconfig has become a misnomer. It has become an internal >> interface and "oldconfig" is just as

Re: [PATCH V8 3/3] OPP: Allow "opp-hz" and "opp-microvolt" to contain magic values

On 12/29, Viresh Kumar wrote: > On 28-12-17, 16:32, Stephen Boyd wrote: > > On 12/28, Viresh Kumar wrote: > > > > So what we need now is: > > > > > > - Stephen to start responding and clarify all the doubts he had as being > > > silent > > > isn't helping. > > > > What can I reply to

Re: [PATCH V8 3/3] OPP: Allow "opp-hz" and "opp-microvolt" to contain magic values

On 12/29, Viresh Kumar wrote: > On 28-12-17, 16:32, Stephen Boyd wrote: > > On 12/28, Viresh Kumar wrote: > > > > So what we need now is: > > > > > > - Stephen to start responding and clarify all the doubts he had as being > > > silent > > > isn't helping. > > > > What can I reply to

Re: [BUG] schedutil governor produces regular max freq spikes because of lockup detector watchdog threads

On Fri, Jan 5, 2018 at 9:37 PM, Leonard Crestez wrote: > Hello, > > When using the schedutil governor together with the softlockup detector > all CPUs go to their maximum frequency on a regular basis. This seems > to be because the watchdog creates a RT thread on each CPU

Re: [BUG] schedutil governor produces regular max freq spikes because of lockup detector watchdog threads

On Fri, Jan 5, 2018 at 9:37 PM, Leonard Crestez wrote: > Hello, > > When using the schedutil governor together with the softlockup detector > all CPUs go to their maximum frequency on a regular basis. This seems > to be because the watchdog creates a RT thread on each CPU and this > causes

Re: [RFC patch] ioremap: don't set up huge I/O mappings when p4d/pud/pmd is zero

On Thu, 2017-12-28 at 19:24 +0800, Hanjun Guo wrote: > From: Hanjun Guo > > When we using iounmap() to free the 4K mapping, it just clear the PTEs > but leave P4D/PUD/PMD unchanged, also will not free the memory of page > tables. > > This will cause issues on ARM64

Re: [RFC patch] ioremap: don't set up huge I/O mappings when p4d/pud/pmd is zero

On Thu, 2017-12-28 at 19:24 +0800, Hanjun Guo wrote: > From: Hanjun Guo > > When we using iounmap() to free the 4K mapping, it just clear the PTEs > but leave P4D/PUD/PMD unchanged, also will not free the memory of page > tables. > > This will cause issues on ARM64 platform (not sure if other

Re: INFO: rcu detected stall in do_softirq

On Fri, Jan 5, 2018 at 11:10 PM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 8a4816cad00bf14642f0ed6043b32d29a05006ce > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master > compiler: gcc (GCC) 7.1.1

RE: [PATCH v3 2/2] dt-bindings: mailbox: Add Xilinx IPI Mailbox

> -Original Message- > From: Rob Herring [mailto:r...@kernel.org] > Sent: Friday, January 05, 2018 7:32 AM > To: Jiaying Liang > Cc: jassisinghb...@gmail.com; michal.si...@xilinx.com; > mark.rutl...@arm.com; linux-arm-ker...@lists.infradead.org; >

RE: [PATCH v3 2/2] dt-bindings: mailbox: Add Xilinx IPI Mailbox

> -Original Message- > From: Rob Herring [mailto:r...@kernel.org] > Sent: Friday, January 05, 2018 7:32 AM > To: Jiaying Liang > Cc: jassisinghb...@gmail.com; michal.si...@xilinx.com; > mark.rutl...@arm.com; linux-arm-ker...@lists.infradead.org; > devicet...@vger.kernel.org;

Re: INFO: rcu detected stall in do_softirq

On Fri, Jan 5, 2018 at 11:10 PM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 8a4816cad00bf14642f0ed6043b32d29a05006ce > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is

[PATCH V4] cpufreq: intel_pstate: allow trace in passive mode

Allow use of the trace_pstate_sample trace function when the intel_pstate driver is in passive mode. Since the core_busy and scaled_busy fields are not used, and it might be desirable to know which path through the driver was used, either intel_cpufreq_target or intel_cpufreq_fast_switch, re-task

[PATCH V4] cpufreq: intel_pstate: allow trace in passive mode

Allow use of the trace_pstate_sample trace function when the intel_pstate driver is in passive mode. Since the core_busy and scaled_busy fields are not used, and it might be desirable to know which path through the driver was used, either intel_cpufreq_target or intel_cpufreq_fast_switch, re-task

[BISECTED] v4.15-rc: Boot regression on x86_64/AMD

Hi, After v4.14, I've been unable to boot my AMD compilation box with the v4.15-rc mainline Linux. It just ends up in a silent reboot loop. I bisected this to: commit fa564ad9636651fd11ec2c79c48dee844066f73a Author: Christian König Date: Tue Oct 24 14:40:29 2017

[BISECTED] v4.15-rc: Boot regression on x86_64/AMD

Hi, After v4.14, I've been unable to boot my AMD compilation box with the v4.15-rc mainline Linux. It just ends up in a silent reboot loop. I bisected this to: commit fa564ad9636651fd11ec2c79c48dee844066f73a Author: Christian König Date: Tue Oct 24 14:40:29 2017 -0500 x86/PCI: Enable a

[PATCH] ASoC: rockchip: i2s: Support mono capture

The Rockchip I2S controller only allows to configure even numbers of capture channels. It is still possible to capture monophonic audio by using dual-channel mode and ignoring the 'data' from the second channel. Signed-off-by: Matthias Kaehlcke ---

[PATCH] ASoC: rockchip: i2s: Support mono capture

The Rockchip I2S controller only allows to configure even numbers of capture channels. It is still possible to capture monophonic audio by using dual-channel mode and ignoring the 'data' from the second channel. Signed-off-by: Matthias Kaehlcke --- sound/soc/rockchip/rockchip_i2s.c | 5 +++-- 1

Re: [PATCH v5] leaking_addresses: add generic 32-bit support

Hi Kaiwan, Thanks for the patch On Thu, Jan 04, 2018 at 05:51:25PM +0530, kaiwan.billimo...@gmail.com wrote: > The script now attempts to detect the architecture it's running upon; as of > now, > we explicitly support x86_64, PPC64, ARM64, MIPS64 and x86_32. This is incorrect. We do not

Re: [PATCH v5] leaking_addresses: add generic 32-bit support

Hi Kaiwan, Thanks for the patch On Thu, Jan 04, 2018 at 05:51:25PM +0530, kaiwan.billimo...@gmail.com wrote: > The script now attempts to detect the architecture it's running upon; as of > now, > we explicitly support x86_64, PPC64, ARM64, MIPS64 and x86_32. This is incorrect. We do not

RE: [RFC] rpmsg: virtio rpmsg: Add RPMsg char driver support

> -Original Message- > From: Arnaud Pouliquen [mailto:arnaud.pouliq...@st.com] > Sent: Friday, January 05, 2018 6:48 AM > To: Jiaying Liang ; o...@wizery.com; > bjorn.anders...@linaro.org > Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org; Jiaying >

RE: [RFC] rpmsg: virtio rpmsg: Add RPMsg char driver support

> -Original Message- > From: Arnaud Pouliquen [mailto:arnaud.pouliq...@st.com] > Sent: Friday, January 05, 2018 6:48 AM > To: Jiaying Liang ; o...@wizery.com; > bjorn.anders...@linaro.org > Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org; Jiaying > Liang > Subject:

[GIT PULL] IOMMU fixes for v4.15-rc7

Hi Linus, No sign of Joerg returning from paternity leave yet this year, so please accept this pull request including fixes via Will Deacon for arm-smmu-v3. Thanks, Alex The following changes since commit 30a7acd573899fd8b8ac39236eff6468b195ac7d: Linux 4.15-rc6 (2017-12-31 14:47:43 -0800)

Re: [J-core] [PATCH v5 00/22] sh: LANDISK and R2Dplus convert to device tree

On 01/05/2018 11:00 PM, Rich Felker wrote: >> It's a simple bootloader which works with blocklists. > > OK, it's good to know that the lilo program is just stock lilo. So > is the provided boot.b-selk file (and an appropriate lilo.conf) all > you need to get it installed on a disk? If I remember

[GIT PULL] IOMMU fixes for v4.15-rc7

Hi Linus, No sign of Joerg returning from paternity leave yet this year, so please accept this pull request including fixes via Will Deacon for arm-smmu-v3. Thanks, Alex The following changes since commit 30a7acd573899fd8b8ac39236eff6468b195ac7d: Linux 4.15-rc6 (2017-12-31 14:47:43 -0800)

Re: [J-core] [PATCH v5 00/22] sh: LANDISK and R2Dplus convert to device tree

On 01/05/2018 11:00 PM, Rich Felker wrote: >> It's a simple bootloader which works with blocklists. > > OK, it's good to know that the lilo program is just stock lilo. So > is the provided boot.b-selk file (and an appropriate lilo.conf) all > you need to get it installed on a disk? If I remember

[PATCH v2] RISC-V: Make __NR_riscv_flush_icache visible to userspace

From: Palmer Dabbelt We were hoping to avoid making this visible to userspace, but it looks like we're going to have to because QEMU's user-mode emulation doesn't want to emulate a vDSO. Having vDSO-only system calls was a bit unothodox anyway, so I think in this case it's

[PATCH v2] RISC-V: Make __NR_riscv_flush_icache visible to userspace

From: Palmer Dabbelt We were hoping to avoid making this visible to userspace, but it looks like we're going to have to because QEMU's user-mode emulation doesn't want to emulate a vDSO. Having vDSO-only system calls was a bit unothodox anyway, so I think in this case it's OK to just make the

Re: [PATCH v5 3/9] ACPI: Enable PPTT support on ARM64

On Fri, Jan 5, 2018 at 10:58 PM, Jeremy Linton wrote: > Hi, > > > On 12/13/2017 11:26 AM, Lorenzo Pieralisi wrote: >> >> On Fri, Dec 01, 2017 at 04:23:24PM -0600, Jeremy Linton wrote: >>> >>> Now that we have a PPTT parser, in preparation for its use >>> on arm64, lets

Re: [PATCH v5 3/9] ACPI: Enable PPTT support on ARM64

On Fri, Jan 5, 2018 at 10:58 PM, Jeremy Linton wrote: > Hi, > > > On 12/13/2017 11:26 AM, Lorenzo Pieralisi wrote: >> >> On Fri, Dec 01, 2017 at 04:23:24PM -0600, Jeremy Linton wrote: >>> >>> Now that we have a PPTT parser, in preparation for its use >>> on arm64, lets build it. >>> >>>

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Fri, Jan 05, 2018 at 10:00:19PM +, Woodhouse, David wrote: > OK, this one looks saner, and I think I've tested all the 32/64 bit Dunno, I think Brian's suggestion will make this even simpler: ALTERNATIVE(NOP, K8: lfence) ALTERNATIVE(jmp indirect, RETPOLINE: jmp thunk) Hmm? --

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Fri, Jan 05, 2018 at 10:00:19PM +, Woodhouse, David wrote: > OK, this one looks saner, and I think I've tested all the 32/64 bit Dunno, I think Brian's suggestion will make this even simpler: ALTERNATIVE(NOP, K8: lfence) ALTERNATIVE(jmp indirect, RETPOLINE: jmp thunk) Hmm? --

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Fri, 2018-01-05 at 09:28 -0800, Linus Torvalds wrote: > That said, I honestly like the inline version (the one that is in the > google paper first) of the retpoline more than the out-of-line one. > And that one shouldn't have any relocagtion issues, because all the > offsets are relative. > >

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Fri, 2018-01-05 at 09:28 -0800, Linus Torvalds wrote: > That said, I honestly like the inline version (the one that is in the > google paper first) of the retpoline more than the out-of-line one. > And that one shouldn't have any relocagtion issues, because all the > offsets are relative. > >

Re: [J-core] [PATCH v5 00/22] sh: LANDISK and R2Dplus convert to device tree

On Fri, Jan 05, 2018 at 10:47:34PM +0100, John Paul Adrian Glaubitz wrote: > On 01/05/2018 10:28 PM, Rich Felker wrote: > > I'm trying to reproduce this but can't find any documentation for > > cross-LILO in [2], much less any code except possibly the binary > > "lilo.x86" in [1]. Googling

Re: [J-core] [PATCH v5 00/22] sh: LANDISK and R2Dplus convert to device tree

On Fri, Jan 05, 2018 at 10:47:34PM +0100, John Paul Adrian Glaubitz wrote: > On 01/05/2018 10:28 PM, Rich Felker wrote: > > I'm trying to reproduce this but can't find any documentation for > > cross-LILO in [2], much less any code except possibly the binary > > "lilo.x86" in [1]. Googling

4.4.110 build failure: undefined reference to `pvclock_pvti_cpu0_va'

Hi, I have just tried to build 4.4.110 but it failed with following message: arch/x86/built-in.o: In function `map_vdso': vma.c:(.text+0x8a3): undefined reference to `pvclock_pvti_cpu0_va' make: *** [Makefile:953: vmlinux] Error 1 I found https://patchwork.kernel.org/patch/7906831/ which has a

4.4.110 build failure: undefined reference to `pvclock_pvti_cpu0_va'

Hi, I have just tried to build 4.4.110 but it failed with following message: arch/x86/built-in.o: In function `map_vdso': vma.c:(.text+0x8a3): undefined reference to `pvclock_pvti_cpu0_va' make: *** [Makefile:953: vmlinux] Error 1 I found https://patchwork.kernel.org/patch/7906831/ which has a

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