Re: [RFC PATCH 0/8] Move task_struct::cpu back into thread_info

W, for the series: Acked-by: Mark Rutland Mark. > While collaborating with Keith on adding THREAD_INFO_IN_TASK support to > ARM, we noticed that keeping CPU in task_struct is problematic for > architectures that define raw_smp_processor_id() in terms of this field, > as it require

Re: [PATCH v1] powerpc: Include running function as first entry in save_stack_trace() and friends

On Tue, Mar 09, 2021 at 04:05:32PM -0600, Segher Boessenkool wrote: > Hi! > > On Tue, Mar 09, 2021 at 04:05:23PM +0000, Mark Rutland wrote: > > On Thu, Mar 04, 2021 at 03:54:48PM -0600, Segher Boessenkool wrote: > > > On Thu, Mar 04, 2021 at 02:57:30PM +, Mark Rutland

Re: [PATCH v1] powerpc: Include running function as first entry in save_stack_trace() and friends

On Thu, Mar 04, 2021 at 03:54:48PM -0600, Segher Boessenkool wrote: > Hi! Hi Segher, > On Thu, Mar 04, 2021 at 02:57:30PM +, Mark Rutland wrote: > > It looks like GCC is happy to give us the function-entry-time FP if we use > > __builtin_frame_address(1), >

Re: [PATCH v1] powerpc: Include running function as first entry in save_stack_trace() and friends

On Thu, Mar 04, 2021 at 08:01:29PM +0100, Marco Elver wrote: > On Thu, 4 Mar 2021 at 19:51, Mark Rutland wrote: > > On Thu, Mar 04, 2021 at 07:22:53PM +0100, Marco Elver wrote: > > > I was having this problem with KCSAN, where the compiler would > > > tail-call-optimi

Re: [PATCH v1] powerpc: Include running function as first entry in save_stack_trace() and friends

On Thu, Mar 04, 2021 at 07:22:53PM +0100, Marco Elver wrote: > On Thu, 4 Mar 2021 at 19:02, Mark Rutland wrote: > > On Thu, Mar 04, 2021 at 06:25:33PM +0100, Marco Elver wrote: > > > On Thu, Mar 04, 2021 at 04:59PM +, Mark Rutland wrote: > > > > On Thu, Mar 04, 2

Re: [PATCH v1] powerpc: Include running function as first entry in save_stack_trace() and friends

On Thu, Mar 04, 2021 at 06:25:33PM +0100, Marco Elver wrote: > On Thu, Mar 04, 2021 at 04:59PM +0000, Mark Rutland wrote: > > On Thu, Mar 04, 2021 at 04:30:34PM +0100, Marco Elver wrote: > > > On Thu, 4 Mar 2021 at 15:57, Mark Rutland wrote: > > > > [adding Mark Bro

Re: [PATCH v1] powerpc: Include running function as first entry in save_stack_trace() and friends

On Thu, Mar 04, 2021 at 04:30:34PM +0100, Marco Elver wrote: > On Thu, 4 Mar 2021 at 15:57, Mark Rutland wrote: > > [adding Mark Brown] > > > > The bigger problem here is that skipping is dodgy to begin with, and > > this is still liable to break in

Re: [PATCH v1] powerpc: Include running function as first entry in save_stack_trace() and friends

[adding Mark Brown] On Wed, Mar 03, 2021 at 04:20:43PM +0100, Marco Elver wrote: > On Wed, Mar 03, 2021 at 03:52PM +0100, Christophe Leroy wrote: > > Le 03/03/2021 � 15:38, Marco Elver a �crit�: > > > On Wed, 3 Mar 2021 at 15:09, Christophe Leroy > > > wrote: > > > > > > > > It seems like

Re: [PATCH v2 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

On Tue, Jul 14, 2020 at 03:01:09PM +0200, Peter Zijlstra wrote: > On Tue, Jul 14, 2020 at 03:19:24PM +0300, Ard Biesheuvel wrote: > > So perhaps the answer is to have text_alloc() not with a 'where' > > argument but with a 'why' argument. Or more simply, just have separate > > alloc/free APIs for

Re: [RFC][PATCH 0/2] Add support for using reserved memory for ima buffer pass

Hi Prakhar, On Mon, May 04, 2020 at 01:38:27PM -0700, Prakhar Srivastava wrote: > IMA during kexec(kexec file load) verifies the kernel signature and measures > the signature of the kernel. The signature in the logs can be used to verfiy > the > authenticity of the kernel. The logs don not get

Re: [PATCH 18/28] mm: enforce that vmap can't map pages executable

On Wed, Apr 08, 2020 at 01:59:16PM +0200, Christoph Hellwig wrote: > To help enforcing the W^X protection don't allow remapping existing > pages as executable. > > Based on patch from Peter Zijlstra . > > Signed-off-by: Christoph Hellwig > --- > arch/x86/include/asm/pgtable_types.h | 6 ++

Re: [PATCH 26/28] arm64: use __vmalloc_node in arch_alloc_vmap_stack

On Wed, Apr 08, 2020 at 01:59:24PM +0200, Christoph Hellwig wrote: > arch_alloc_vmap_stack can use a slightly higher level vmalloc function. > > Signed-off-by: Christoph Hellwig Acked-by: Mark Rutland Mark. > --- > arch/arm64/include/asm/vmap_stack.h | 6 ++ >

Re: [RFC 02/11] perf/core: Data structure to present hazard data

On Mon, Mar 02, 2020 at 10:53:46AM +0530, Ravi Bangoria wrote: > From: Madhavan Srinivasan > > Introduce new perf sample_type PERF_SAMPLE_PIPELINE_HAZ to request kernel > to provide cpu pipeline hazard data. Also, introduce arch independent > structure 'perf_pipeline_haz_data' to pass hazard

Re: [RFC 02/11] perf/core: Data structure to present hazard data

On Mon, Mar 02, 2020 at 10:53:46AM +0530, Ravi Bangoria wrote: > From: Madhavan Srinivasan > > Introduce new perf sample_type PERF_SAMPLE_PIPELINE_HAZ to request kernel > to provide cpu pipeline hazard data. Also, introduce arch independent > structure 'perf_pipeline_haz_data' to pass hazard

Re: [PATCH v8 1/5] kasan: support backing vmalloc space with real shadow memory

Hi Andrey, On Wed, Oct 16, 2019 at 03:19:50PM +0300, Andrey Ryabinin wrote: > On 10/14/19 4:57 PM, Daniel Axtens wrote: > >>> + /* > >>> + * Ensure poisoning is visible before the shadow is made visible > >>> + * to other CPUs. > >>> + */ > >>> + smp_wmb(); > >> > >> I'm not quite understand

Re: [PATCH v8 1/5] kasan: support backing vmalloc space with real shadow memory

ful for architectures > that do not have a separate module space (e.g. powerpc64, which I am > currently working on). It also allows relaxing the module alignment > back to PAGE_SIZE. > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=202009 > Acked-by: Vasily Gorbik > Sign

Re: [PATCH v8 1/5] kasan: support backing vmalloc space with real shadow memory

On Tue, Oct 15, 2019 at 12:57:44AM +1100, Daniel Axtens wrote: > Hi Andrey, > > > >> + /* > >> + * Ensure poisoning is visible before the shadow is made visible > >> + * to other CPUs. > >> + */ > >> + smp_wmb(); > > > > I'm not quite understand what this barrier do and why it needed. >

Re: [PATCH v6 1/5] kasan: support backing vmalloc space with real shadow memory

On Tue, Sep 03, 2019 at 12:32:49AM +1000, Daniel Axtens wrote: > Hi Mark, > > >> +static int kasan_depopulate_vmalloc_pte(pte_t *ptep, unsigned long addr, > >> + void *unused) > >> +{ > >> + unsigned long page; > >> + > >> + page = (unsigned

Re: [PATCH v6 1/5] kasan: support backing vmalloc space with real shadow memory

ful for architectures > that do not have a separate module space (e.g. powerpc64, which I am > currently working on). It also allows relaxing the module alignment > back to PAGE_SIZE. > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=202009 > Acked-by: Vasily Gorbik > Sign

Re: [PATCH v4 1/3] kasan: support backing vmalloc space with real shadow memory

On Fri, Aug 16, 2019 at 10:41:00AM -0700, Andy Lutomirski wrote: > On Fri, Aug 16, 2019 at 10:08 AM Mark Rutland wrote: > > > > Hi Christophe, > > > > On Fri, Aug 16, 2019 at 09:47:00AM +0200, Christophe Leroy wrote: > > > Le 15/08/2019 à 02:16, Daniel Axtens

Re: [PATCH 6/6] arm64: document the choice of page attributes for pgprot_dmacoherent

s access size, requires strict > alignment and can also force write responses to come from the endpoint. > > ? It's a small change, but it better fits with the arm64 terminology > ("strongly ordered" is no longer used in the architecture). > > If you're happy with that, I can make the change and queue this patch > for 5.4. FWIW, with that wording: Acked-by: Mark Rutland Mark.

Re: [PATCH v4 1/3] kasan: support backing vmalloc space with real shadow memory

Hi Christophe, On Fri, Aug 16, 2019 at 09:47:00AM +0200, Christophe Leroy wrote: > Le 15/08/2019 à 02:16, Daniel Axtens a écrit : > > Hook into vmalloc and vmap, and dynamically allocate real shadow > > memory to back the mappings. > > > > Most mappings in vmalloc space are small, requiring less

Re: [PATCH v4 0/3] kasan: support backing vmalloc space with real shadow memory

exhaustion after a week of Syzkaller fuzzing with the last patchset, across 3 machines, so that sounds fine to me. Otherwise, this looks good to me now! For the x86 and fork patch, feel free to add: Acked-by: Mark Rutland Mark. > > v1: https://lore.kernel.org/linux-mm/20190725055503.19507

Re: [RFC V2 0/1] mm/debug: Add tests for architecture exported page table helpers

On Fri, Aug 09, 2019 at 03:16:33AM -0700, Matthew Wilcox wrote: > On Fri, Aug 09, 2019 at 01:03:17PM +0530, Anshuman Khandual wrote: > > Should alloc_gigantic_page() be made available as an interface for general > > use in the kernel. The test module here uses very similar implementation > > from

Re: [PATCH 4/4] mm/vmalloc: Hugepage vmalloc mappings

Hi, On Mon, Jun 10, 2019 at 02:38:38PM +1000, Nicholas Piggin wrote: > For platforms that define HAVE_ARCH_HUGE_VMAP, have vmap allow vmalloc to > allocate huge pages and map them > > This brings dTLB misses for linux kernel tree `git diff` from 45,000 to > 8,000 on a Kaby Lake KVM guest with

Re: [PATCH 04/15] arm64: switch to generic version of pte allocation

Hi, On Thu, May 02, 2019 at 06:28:31PM +0300, Mike Rapoport wrote: > The PTE allocations in arm64 are identical to the generic ones modulo the > GFP flags. > > Using the generic pte_alloc_one() functions ensures that the user page > tables are allocated with __GFP_ACCOUNT set. > > The arm64

Re: [PATCH v12 04/31] arm64/mm: define ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT

On Tue, Apr 23, 2019 at 05:36:31PM +0200, Laurent Dufour wrote: > Le 18/04/2019 à 23:51, Jerome Glisse a écrit : > > On Tue, Apr 16, 2019 at 03:41:56PM +0100, Mark Rutland wrote: > > > On Tue, Apr 16, 2019 at 04:31:27PM +0200, Laurent Dufour wrote: > > > > Le 16

Re: [RESEND PATCH v3 02/11] arm64: mark (__)cpus_have_const_cap as __always_inline

built and booted this atop of defconfig and my usual suite of debug options for fuzzing, at EL1 under QEMU/KVM, and at EL2 under QEMU/TCG, with no issues in either case, so FWIW: Tested-by: Mark Rutland Thanks, Mark. > --- > > Changes in v3: None > Changes in v2: > - split

Re: [PATCH v12 04/31] arm64/mm: define ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT

On Tue, Apr 16, 2019 at 04:31:27PM +0200, Laurent Dufour wrote: > Le 16/04/2019 à 16:27, Mark Rutland a écrit : > > On Tue, Apr 16, 2019 at 03:44:55PM +0200, Laurent Dufour wrote: > > > From: Mahendran Ganesh > > > > > > Set ARCH_SUPPORTS_SPECULATIVE_PAGE

Re: [PATCH v12 04/31] arm64/mm: define ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT

On Tue, Apr 16, 2019 at 03:44:55PM +0200, Laurent Dufour wrote: > From: Mahendran Ganesh > > Set ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT for arm64. This > enables Speculative Page Fault handler. > > Signed-off-by: Ganesh Mahendran This is missing your S-o-B. The first patch noted that the

Re: [PATCH 1/6] mm: change locked_vm's type from unsigned long to atomic64_t

On Thu, Apr 11, 2019 at 02:22:23PM +1000, Alexey Kardashevskiy wrote: > On 03/04/2019 07:41, Daniel Jordan wrote: > > - dev_dbg(dev, "[%d] RLIMIT_MEMLOCK %c%ld %ld/%ld%s\n", current->pid, > > + dev_dbg(dev, "[%d] RLIMIT_MEMLOCK %c%ld %lld/%lu%s\n", current->pid, > > incr ? '+' :

Re: [PATCH 3/7] powerpc/mm: Add a framework for Kernel Userspace Access Protection

On Thu, Feb 21, 2019 at 11:46:06AM +0100, Christophe Leroy wrote: > > > Le 21/02/2019 à 10:35, Russell Currey a écrit : > > From: Christophe Leroy > > > > This patch implements a framework for Kernel Userspace Access > > Protection. > > > > Then subarches will have to possibility to provide

Re: [PATCH v14 02/12] powerpc/irq: use memblock functions returning virtual address

On Thu, Jan 24, 2019 at 07:25:53PM +0200, Mike Rapoport wrote: > On Thu, Jan 24, 2019 at 04:51:53PM +0000, Mark Rutland wrote: > > On Thu, Jan 24, 2019 at 04:19:33PM +, Christophe Leroy wrote: > > > Since only the virtual address of allocated blocks is used, > > > l

Re: [PATCH v14 07/12] powerpc: Activate CONFIG_THREAD_INFO_IN_TASK

On Thu, Jan 24, 2019 at 04:19:43PM +, Christophe Leroy wrote: > This patch activates CONFIG_THREAD_INFO_IN_TASK which > moves the thread_info into task_struct. > > Moving thread_info into task_struct has the following advantages: > - It protects thread_info from corruption in the case of

Re: [PATCH v14 05/12] powerpc: prep stack walkers for THREAD_INFO_IN_TASK

CONFIG_THREAD_INFO_IN_TASK is not selected these perform no > refcounting, and this should only be a structural change that does not > affect behaviour. > > Signed-off-by: Christophe Leroy I'm not familiar with the powerpc code, but AFAICT this is analagous to the arm64 code, and I'm not awar

Re: [PATCH v14 02/12] powerpc/irq: use memblock functions returning virtual address

y_nid() will panic itself rather than returning NULL. Otherwise, this looks like a nice cleanup. With the panics removed (or using the _nopanic() allocators), feel free to add: Acked-by: Mark Rutland Thanks, Mark.

Re: [PATCH 09/10] drivers/perf: perf/core: generalise event exclusion checking with perf macro

rs/perf/qcom_l3_pmu.c > - drivers/perf/arm_pmu.c > > And exclude_idle and exclude_hv are added in these files: > > - drivers/perf/xgene_pmu.c FWIW, that all sounds fine to me. Assuming you fix up the 'macro' nit: Acked-by: Mark Rutland ... unless we go for Peter's core cap fo

Re: [PATCH 01/10] perf/core: Add macro to test for event exclusion flags

fix that up here and in subsequent commit messages, for this patch feel free to add: Acked-by: Mark Rutland Mark. > --- > include/linux/perf_event.h | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h >

Re: [RFC PATCH] lib: Introduce generic __cmpxchg_u64() and use it where needed

[adding the atomic maintainers] On Thu, Nov 01, 2018 at 12:17:31AM +, Trond Myklebust wrote: > On Wed, 2018-10-31 at 23:32 +, Paul Burton wrote: > > (Copying SunRPC & net maintainers.) > > > > Hi Guenter, > > > > On Wed, Oct 31, 2018 at 03:02:53PM -0700, Guenter Roeck wrote: > > > The

Re: [RFC PATCH v1 1/9] timer: fix circular header dependency

On Tue, Sep 25, 2018 at 07:34:15AM +0200, Christophe LEROY wrote: > > > Le 24/09/2018 à 17:52, Christophe Leroy a écrit : > > When switching powerpc to CONFIG_THREAD_INFO_IN_TASK, include/sched.h > > has to be included in asm/smp.h for the following change, in order > > to avoid uncomplete

Re: [PATCH 1/5] arm64: entry: isb in el1_irq

On Fri, Apr 06, 2018 at 06:22:11PM +0100, Mark Rutland wrote: > Digging a bit, I also thing that our ct_user_exit and ct_user_enter > usage is on dodgy ground today. > > For example, in el0_dbg we call do_debug_exception() *before* calling > ct_user_exit. Which I believe means we'

Re: [PATCH 1/5] arm64: entry: isb in el1_irq

On Fri, Apr 06, 2018 at 06:30:50PM +0100, James Morse wrote: > Hi Mark, > > On 06/04/18 18:22, Mark Rutland wrote: > > Digging a bit, I also thing that our ct_user_exit and ct_user_enter > > usage is on dodgy ground today. > > [...] > > > I think similar

Re: [PATCH 1/5] arm64: entry: isb in el1_irq

On Fri, Apr 06, 2018 at 07:54:02PM +0300, Yury Norov wrote: > In general, kick_all_cpus_sync() is needed to switch contexts. But exit from > userspace is anyway the switch of context. And while in userspace, we cannot > do something wrong on kernel side. For me it means that we can safely drop >

Re: [PATCH 3/5] arm64: early ISB at exit from extended quiescent state

On Thu, Apr 05, 2018 at 08:17:58PM +0300, Yury Norov wrote: > This series enables delaying of kernel memory synchronization > for CPUs running in extended quiescent state (EQS) till the exit > of that state. > > ARM64 uses IPI mechanism to notify all cores in SMP system that > kernel text is

Re: [PATCH 1/5] arm64: entry: isb in el1_irq

On Thu, Apr 05, 2018 at 08:17:56PM +0300, Yury Norov wrote: > Kernel text patching framework relies on IPI to ensure that other > SMP cores observe the change. Target core calls isb() in IPI handler > path, but not at the beginning of el1_irq entry. There's a chance > that modified instruction

Re: [PATCH 2/2] smp: introduce kick_active_cpus_sync()

On Wed, Apr 04, 2018 at 06:36:25AM +0300, Yury Norov wrote: > On Tue, Apr 03, 2018 at 02:48:32PM +0100, Mark Rutland wrote: > > On Sun, Apr 01, 2018 at 02:11:08PM +0300, Yury Norov wrote: > > > @@ -840,8 +861,10 @@ el0_svc: > > > mov wsc_nr, #__NR_sy

Re: [PATCH 2/2] smp: introduce kick_active_cpus_sync()

Hi Yury, On Sun, Apr 01, 2018 at 02:11:08PM +0300, Yury Norov wrote: > +/* > + * Flush I-cache if CPU is in extended quiescent state > + */ This comment is misleading. An ISB doesn't touch the I-cache; it forces a context synchronization event. > + .macro isb_if_eqs > +#ifndef

Re: [PATCH v11 7/9] arm64/kasan: add and use kasan_map_populate()

Hi, On Fri, Oct 13, 2017 at 03:43:19PM +0100, Will Deacon wrote: > On Fri, Oct 13, 2017 at 10:10:09AM -0400, Pavel Tatashin wrote: > > I am getting the following panic during boot: > > > > [0.012637] pid_max: default: 32768 minimum: 301 > > [0.016037] Security Framework initialized > > [

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

Hi Pavel, On Wed, Sep 20, 2017 at 04:17:11PM -0400, Pavel Tatashin wrote: > During early boot, kasan uses vmemmap_populate() to establish its shadow > memory. But, that interface is intended for struct pages use. > > Because of the current project, vmemmap won't be zeroed during allocation, >

Re: [PATCH v8 10/11] arm64/kasan: explicitly zero kasan shadow memory

On Fri, Sep 15, 2017 at 05:20:59PM -0400, Pavel Tatashin wrote: > Hi Mark, > > I had this option  back upto version 3, where zero flag was passed into > vmemmap_alloc_block(), but I was asked to remove it, because it required too > many changes in other places. Ok. Sorry for bringing back a

Re: [PATCH v8 10/11] arm64/kasan: explicitly zero kasan shadow memory

On Thu, Sep 14, 2017 at 09:30:28PM -0400, Pavel Tatashin wrote: > Hi Mark, > > Thank you for looking at this. We can't do this because page table is not > set until cpu_replace_ttbr1() is called. So, we can't do memset() on this > memory until then. I see. Sorry, I had missed that we were on the

Re: [PATCH v8 10/11] arm64/kasan: explicitly zero kasan shadow memory

On Thu, Sep 14, 2017 at 06:35:16PM -0400, Pavel Tatashin wrote: > To optimize the performance of struct page initialization, > vmemmap_populate() will no longer zero memory. > > We must explicitly zero the memory that is allocated by vmemmap_populate() > for kasan, as this memory does not go

Re: [RFC 2/4] libnvdimm: Add a device-tree interface

Hi, On Tue, Jun 27, 2017 at 08:28:49PM +1000, Oliver O'Halloran wrote: > A fairly bare-bones set of device-tree bindings so libnvdimm can be used > on powerpc and other, less cool, device-tree based platforms. ;) > Cc: devicet...@vger.kernel.org > Signed-off-by: Oliver O'Halloran

Re: [PATCH] of/irq: improve error message on irq discovery process failure

On Fri, Nov 11, 2016 at 08:30:43AM +1100, Benjamin Herrenschmidt wrote: > On Wed, 2016-11-09 at 19:04 +0000, Mark Rutland wrote: > > > > If we don't have an interrupt-map on a PCI controller, why don't we > > instead log a message regarding that being missing, and give u

Re: [PATCH] of/irq: improve error message on irq discovery process failure

On Wed, Nov 09, 2016 at 12:05:08PM -0200, Guilherme G. Piccoli wrote: > On PowerPC machines some PCI slots might not have Level-triggered > interrupts capability (also know as Level Signaled Interrupts - LSI), > leading of_irq_parse_pci() to complain by presenting error messages > on the kernel

Re: [PATCH v2 0/2] extend kexec_file_load system call

On Thu, Aug 11, 2016 at 08:03:56PM -0300, Thiago Jung Bauermann wrote: > This patch series is from AKASHI Takahiro. I will use it in my next > version of the kexec_file_load implementation for powerpc, so I am > rebasing it on top of v4.8-rc1. [...] > Original cover letter: > > Device tree blob

Re: [RFC 3/3] kexec: extend kexec_file_load system call

On Tue, Jul 19, 2016 at 08:24:06AM -0400, Vivek Goyal wrote: > On Tue, Jul 19, 2016 at 11:52:00AM +0100, Mark Rutland wrote: > > Regardless, this extended syscall changes some underlying assumptions > > made with the development of kexec_file_load, and I think treating this >

Re: [RFC 3/3] kexec: extend kexec_file_load system call

On Tue, Jul 19, 2016 at 08:55:56AM +0800, Dave Young wrote: > On 07/18/16 at 11:07am, Mark Rutland wrote: > > On Mon, Jul 18, 2016 at 10:30:24AM +0800, Dave Young wrote: > > > I do not think it is worth to add another syscall for extra fds. > > > We have open(2) as an ex

Re: [RFC 3/3] kexec: extend kexec_file_load system call

On Mon, Jul 18, 2016 at 10:30:24AM +0800, Dave Young wrote: > On 07/15/16 at 02:19pm, Mark Rutland wrote: > > On Fri, Jul 15, 2016 at 09:09:55AM -0400, Vivek Goyal wrote: > > > On Tue, Jul 12, 2016 at 10:42:01AM +0900, AKASHI Takahiro wrote: > > > > >

Re: [RFC 0/3] extend kexec_file_load system call

On Fri, Jul 15, 2016 at 12:29:09PM -0300, Thiago Jung Bauermann wrote: > Am Freitag, 15 Juli 2016, 14:33:47 schrieb Mark Rutland: > > On Fri, Jul 15, 2016 at 09:26:10AM -0400, Vivek Goyal wrote: > > > I don't know anything about DTB. So here comes a very basic question. &g

Re: [RFC 0/3] extend kexec_file_load system call

On Fri, Jul 15, 2016 at 09:26:10AM -0400, Vivek Goyal wrote: > On Fri, Jul 15, 2016 at 09:31:02AM +0200, Arnd Bergmann wrote: > > On Thursday, July 14, 2016 10:44:14 PM CEST Thiago Jung Bauermann wrote: > > > Am Donnerstag, 14 Juli 2016, 10:29:11 schrieb Arnd Bergmann: > > > > > > > > > > Right,

Re: [RFC 3/3] kexec: extend kexec_file_load system call

On Fri, Jul 15, 2016 at 09:09:55AM -0400, Vivek Goyal wrote: > On Tue, Jul 12, 2016 at 10:42:01AM +0900, AKASHI Takahiro wrote: > > [..] > > -SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, initrd_fd, > > +SYSCALL_DEFINE6(kexec_file_load, int, kernel_fd, int, initrd_fd, > >

Re: [RFC 0/3] extend kexec_file_load system call

On Wed, Jul 13, 2016 at 09:57:28PM +0200, Arnd Bergmann wrote: > On Wednesday, July 13, 2016 6:58:32 PM CEST Mark Rutland wrote: > > > > > we may want to remove unnecessary devices and even add a dedicated > > > storage device for storing a core dump image. > >

Re: [RFC 0/3] extend kexec_file_load system call

On Thu, Jul 14, 2016 at 02:38:06AM +0900, AKASHI Takahiro wrote: > Apologies for the slow response. I'm attending LinuxCon this week. > > On Wed, Jul 13, 2016 at 10:34:47AM +0100, Mark Rutland wrote: > > On Wed, Jul 13, 2016 at 10:36:14AM +0800, Dave Young wrote: > > > B

Re: [RFC 0/3] extend kexec_file_load system call

On Wed, Jul 13, 2016 at 10:01:33AM +0200, Arnd Bergmann wrote: > On Wednesday, July 13, 2016 10:36:14 AM CEST Dave Young wrote: > > On 07/12/16 at 03:50pm, Mark Rutland wrote: > > > On Tue, Jul 12, 2016 at 04:24:10PM +0200, Arnd Bergmann wrote: > > > > On Tuesday,

Re: [RFC 0/3] extend kexec_file_load system call

On Wed, Jul 13, 2016 at 10:36:14AM +0800, Dave Young wrote: > But consider we can kexec to a different kernel and a different initrd so > there > will be use cases to pass a total different dtb as well. It depends on what you mean by "a different kernel", and what this implies for the DTB. I

Re: [RFC 0/3] extend kexec_file_load system call

On Tue, Jul 12, 2016 at 04:24:10PM +0200, Arnd Bergmann wrote: > On Tuesday, July 12, 2016 10:18:11 AM CEST Vivek Goyal wrote: > > > > > > On Open Firmware, the DT is extracted from running firmware and copied > > > into dynamically allocated data structures. After a kexec, the runtime > > >

Re: [PATCH 4/9] arm64/uaccess: Enable hardened usercopy

Hi, On Wed, Jul 06, 2016 at 03:25:23PM -0700, Kees Cook wrote: > Enables CONFIG_HARDENED_USERCOPY checks on arm64. As done by KASAN in -next, > renames the low-level functions to __arch_copy_*_user() so a static inline > can do additional work before the copy. The checks themselves look fine,

Re: [v8, 1/7] Documentation: DT: update Freescale DCFG compatible

On Fri, Apr 22, 2016 at 02:27:38PM +0800, Yangbo Lu wrote: > Update Freescale DCFG compatible with 'fsl,-dcfg' instead > of 'fsl,ls1021a-dcfg' to include more chips. > > Signed-off-by: Yangbo Lu > --- > Changes for v8: > - Added this patch > --- >

Re: [PATCH V2] tick-broadcast: Register for hrtimer based broadcast as the fallback broadcast mode

entering and exiting idle states where the cpu-local timers lose state. So: Tested-by: Mark Rutland mark.rutl...@arm.com One minor thing I noticed when testing was that /sys/devices/system/clockevents/broadcast/name contained (null), because we never set the name field on the clock_event_device. It's

Re: [PATCH V2] tick-broadcast: Register for hrtimer based broadcast as the fallback broadcast mode

On Mon, Dec 08, 2014 at 12:02:55PM +, Preeti U Murthy wrote: On 12/08/2014 04:18 PM, Mark Rutland wrote: Hi Preeti, On Mon, Dec 08, 2014 at 06:55:43AM +, Preeti U Murthy wrote: Commit 5d1638acb9f6 ('tick: Introduce hrtimer based broadcast') added a hrtimer based broadcast mode

Re: [PATCH] tick-broadcast: Register for hrtimer based broadcast as the default broadcast mode

Hi Preeti, Moving this out of the architecture code looks good to me! I have a couple of minor comments below. On Fri, Dec 05, 2014 at 12:47:57PM +, Preeti U Murthy wrote: Commit 5d1638acb9f62fa7 added a hrtimer based broadcast mode for those platforms in which local timers stop when CPUs

Re: [PATCH 2/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan portal(s)

On Wed, Oct 22, 2014 at 09:04:54PM +0100, Emil Medve wrote: Hello Mark, Thanks for having a look at this On 10/22/2014 09:29 AM, Mark Rutland wrote: On Wed, Oct 22, 2014 at 03:09:30PM +0100, Emil Medve wrote: Portals are used by software running on processor cores, accelerators

Re: [PATCH 3/4] dt/bindings: Introduce the FSL QorIQ DPAA QMan

[...] +QMan Node + +PROPERTIES + +- compatible + Usage: Required + Value type: stringlist + Definition: Must include fsl,qman + May include fsl,SoC-qman + +- reg + Usage: Required + Value type: prop-encoded-array +

Re: [PATCH 2/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan portal(s)

On Wed, Oct 22, 2014 at 03:09:30PM +0100, Emil Medve wrote: Portals are used by software running on processor cores, accelerators and network interfaces to communicate with the BMan What exactly is a portal? Is it a region of shared memory? A device? I only received emails 2 and 3 of this

Re: [PATCH 3/4] dt/bindings: Introduce the FSL QorIQ DPAA QMan

On Wed, Oct 22, 2014 at 03:09:31PM +0100, Emil Medve wrote: The Queue Manager is part of the Data-Path Acceleration Architecture (DPAA). QMan supports queuing and QoS scheduling of frames to CPUs, network interfaces and DPAA logic modules, maintains packet ordering within flows. Besides

Re: [PATCH 05/44] mfd: as3722: Drop reference to pm_power_off from devicetree bindings

: Mark Rutland mark.rutl...@arm.com Signed-off-by: Guenter Roeck li...@roeck-us.net --- Documentation/devicetree/bindings/mfd/as3722.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) Thanks for the fix-up! Acked-by: Mark Rutland mark.rutl...@arm.com Mark. diff --git a/Documentation

Re: [PATCH 07/44] qnap-poweroff: Drop reference to pm_power_off from devicetree bindings

. +microcontroller to turn the power off. This driver installs a handler +to power off the system. I'd remove the last sentence -- the driver is also independent of the HW, and the description of how the power off works at the HW level is sufficient. With that: Acked-by: Mark Rutland mark.rutl...@arm.com Thanks

Re: [PATCH 06/44] gpio-poweroff: Drop reference to pm_power_off from devicetree bindings

On Tue, Oct 07, 2014 at 06:28:08AM +0100, Guenter Roeck wrote: pm_power_off is an implementation detail. Replace it with a more generic description of the driver's functionality. Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com

Re: [PATCH 05/44] mfd: as3722: Drop reference to pm_power_off from devicetree bindings

On Tue, Oct 07, 2014 at 05:21:11PM +0100, Rob Landley wrote: On 10/07/14 00:28, Guenter Roeck wrote: Devicetree bindings are supposed to be operating system independent and should thus not describe how a specific functionality is implemented in Linux. So your argument is that

Re: [RFC PATCH] dt:numa: adding numa node mapping for memory nodes.

On Wed, Sep 17, 2014 at 04:37:30PM +0100, Kumar Gala wrote: On Sep 17, 2014, at 1:56 AM, Ganapatrao Kulkarni ganapatrao.kulka...@caviumnetworks.com wrote: From: Ganapatrao Kulkarni ganapatrao.kulka...@cavium.com This patch adds property nid to memory node to provide the memory range

Re: [PATCH] devicetree/bindings: Add binding for micron n25q512a memory

On Mon, Jul 07, 2014 at 10:25:54PM +0100, Scott Wood wrote: On Thu, 2014-07-03 at 23:08 -0500, Jain Priyanka-B32167 wrote: -Original Message- From: Wood Scott-B07421 Sent: Friday, July 04, 2014 3:40 AM To: Jain Priyanka-B32167 Cc: devicet...@vger.kernel.org;

Re: [PATCH v3 2/2] ASoC: fsl_asrc: Add ASRC ASoC CPU DAI and platform drivers

+ - big-endian : If this property is absent, the native endian mode will + be in use as default, or the big endian mode will be in use + for all the device registers. Native endian is meaningless. If a CPU supports both BE and LE, there is no native

Re: [PATCH v2 1/3] dmaengine: mpc512x: add device tree binding document

Hi Alexander, Apologies for the late reply. DT-related email is somewhat a firehose and unfortunately I lose track of things. On Thu, Jun 19, 2014 at 02:59:19PM +0100, Alexander Popov wrote: 2014-06-18 18:56 GMT+04:00 Alexander Popov a13xp0p0...@gmail.com: 2014-06-18 17:37 GMT+04:00 Mark

Re: [RFC PATCH v2 4/6] mmc: sdhci: host: add new f_sdh30

On Fri, Jun 27, 2014 at 04:32:21AM +0100, Vincent Yang wrote: 2014-06-26 19:03 GMT+08:00 Mark Rutland mark.rutl...@arm.com: On Thu, Jun 26, 2014 at 07:23:30AM +0100, Vincent Yang wrote: This patch adds new host controller driver for Fujitsu SDHCI controller f_sdh30. Signed-off

Re: [RFC PATCH v2 4/6] mmc: sdhci: host: add new f_sdh30

On Thu, Jun 26, 2014 at 07:23:30AM +0100, Vincent Yang wrote: This patch adds new host controller driver for Fujitsu SDHCI controller f_sdh30. Signed-off-by: Vincent Yang vincent.y...@tw.fujitsu.com --- .../devicetree/bindings/mmc/sdhci-fujitsu.txt | 35 +++ drivers/mmc/host/Kconfig

Re: [PATCH v2 1/3] dmaengine: mpc512x: add device tree binding document

On Wed, Jun 18, 2014 at 11:48:10AM +0100, Alexander Popov wrote: Introduce a device tree binding document for the MPC512x DMA controller Signed-off-by: Alexander Popov a13xp0p0...@gmail.com --- .../devicetree/bindings/dma/mpc512x-dma.txt| 31 ++ 1 file

Re: [PATCH 3/3] of: Handle memory@0 node on PPC32 only

On Tue, Apr 22, 2014 at 02:35:15PM +0100, Grant Likely wrote: On Fri, 18 Apr 2014 13:59:24 +0100, Leif Lindholm leif.lindh...@linaro.org wrote: Hi Geert, On Fri, Apr 18, 2014 at 10:04:15AM +0200, Geert Uytterhoeven wrote: On Thu, Apr 17, 2014 at 7:42 PM, Leif Lindholm

Re: [PATCH 3/3] of: Handle memory@0 node on PPC32 only

Hi, diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig index 889005f..230c747 100644 --- a/drivers/of/Kconfig +++ b/drivers/of/Kconfig @@ -77,4 +77,7 @@ config OF_RESERVED_MEM help Helpers to allow for reservation of memory regions +config

Re: [PATCH RFC v9 5/6] dma: mpc512x: add device tree binding document

On Wed, Mar 12, 2014 at 11:47:54AM +, Alexander Popov wrote: From: Gerhard Sittig g...@denx.de introduce a device tree binding document for the MPC512x DMA controller Signed-off-by: Gerhard Sittig g...@denx.de [ a13xp0p0...@gmail.com: turn this into a separate patch ] ---

Re: [PATCH 2/7] IBM Akebono: Add support for a new PHY interface to the IBM emac driver

On Fri, Feb 21, 2014 at 06:31:28AM +, Alistair Popple wrote: The IBM PPC476GTR SoC that is used on the Akebono board uses a different ethernet PHY interface that has wake on lan (WOL) support with the IBM emac. This patch adds support to the IBM emac driver for this new PHY interface.

Re: [PATCH 4/7] ECHI Platform: Merge ppc-of EHCI driver into the ehci-platform driver

[Adding Tony Prisk to Cc] On Fri, Feb 21, 2014 at 06:31:30AM +, Alistair Popple wrote: Currently the ppc-of driver uses the compatibility string usb-ehci. This means platforms that use device-tree and implement an EHCI compatible interface have to either use the ppc-of driver or add a

Re: 答复: [v7] clk: corenet: Adds the clock binding

On Wed, Jan 08, 2014 at 08:53:56AM +, Yuantian Tang wrote: 发件人: Wood Scott-B07421 发送时间: 2014年1月8日 8:21 收件人: Tang Yuantian-B29983 抄送: ga...@kernel.crashing.org; mark.rutl...@arm.com; devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org 主题:

Re: [PATCH 1/2] powerpc/dts: fix lbc lack of error interrupt

On Tue, Jan 07, 2014 at 06:26:42AM +, Dongsheng Wang wrote: From: Wang Dongsheng dongsheng.w...@freescale.com P1020, P1021, P1022, P1023 when the lbc get error, the error interrupt will be triggered. The corresponding interrupt is internal IRQ0. So system have to process the lbc IRQ0

Re: [PATCH v6 02/17] dts: mpc512x: introduce dt-bindings/clock/ header

with this, pointing out that this include file defines the set of clock IDs for the MPC512x clocks. Otherwise, this looks fine to me. Mark. Cc: Rob Herring rob.herr...@calxeda.com Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Stephen Warren swar...@wwwdotorg.org Cc: Ian

Re: [PATCH v6 08/17] spi: mpc512x: adjust to OF based clock lookup

On Sat, Nov 30, 2013 at 10:51:28PM +, Gerhard Sittig wrote: after device tree based clock lookup became available, the peripheral driver need no longer construct clock names which include the PSC index, remove the psc%d_mclk template and unconditionally use 'mclk' acquire and release the

Re: [PATCH RFC v5 4/5] dma: mpc512x: register for device tree channel lookup

On Fri, Nov 01, 2013 at 07:19:33AM +, Alexander Popov wrote: From: Gerhard Sittig g...@denx.de register the controller for device tree based lookup of DMA channels (non-fatal for backwards compatibility with older device trees), provide the '#dma-cells' property in the shared

Re: [PATCH RFC v5 4/5] dma: mpc512x: register for device tree channel lookup

On Mon, Nov 18, 2013 at 02:31:54PM +, Arnd Bergmann wrote: On Monday 18 November 2013, Mark Rutland wrote: +++ b/Documentation/devicetree/bindings/dma/mpc512x-dma.txt @@ -0,0 +1,55 @@ +* Freescale MPC512x DMA Controller + +The DMA controller in the Freescale MPC512x SoC can

Re: [PATCH] powerpc/85xx: typo in dts: interupt (four devices)

On Mon, Nov 11, 2013 at 09:52:07PM +, Adam Borowski wrote: These lines were inoperative for four years, which puts some doubt into their importance, and it's possible the fixed version will regress, but at the very least they should be removed instead. Signed-off-by: Adam Borowski

Re: [PATCH v6] clk: corenet: Adds the clock binding

On Mon, Nov 11, 2013 at 09:41:46AM +, yuantian.t...@freescale.com wrote: From: Tang Yuantian yuantian.t...@freescale.com Adds the clock bindings for Freescale PowerPC CoreNet platforms Signed-off-by: Tang Yuantian yuantian.t...@freescale.com Signed-off-by: Li Yang le...@freescale.com

<    1   2   3   >