Re: [PATCH v4 0/1] pstore/ram: add Device Tree bindings

2016-06-14 Thread Kees Cook
On Tue, Jun 14, 2016 at 2:59 PM, Rob Herring wrote: > On Fri, Jun 10, 2016 at 03:50:58PM -0700, Kees Cook wrote: >> This is a "v4" of Greg Hackmann's DT bindings for ramoops. This is >> what I'm going to land in the pstore tree unless there are strong and >> convincing arguments

Re: [PATCH v2] Add kernel parameter to blacklist modules

2016-06-14 Thread Rusty Russell
Prarit Bhargava writes: > Blacklisting a module in linux has long been a problem. The current > procedure is to use rd.blacklist=module_name, however, that doesn't > cover the case after the initramfs and before a boot prompt (where one > is supposed to use

Re: [PATCH 16/23] arm64: ilp32: introduce binfmt_ilp32.c

2016-06-14 Thread Yury Norov
On Thu, May 26, 2016 at 09:49:42PM +0800, Zhangjian (Bamvor) wrote: > Hi, yury > > The coredump is usable in our platform. It miss the following definition: > +#define compat_elf_greg_telf_greg_t > +#define compat_elf_gregset_t elf_gregset_t > > And it leads to the wrong register save in

Re: [PATCH 01/23] all: syscall wrappers: add documentation

2016-06-14 Thread Yury Norov
Hi Catalin, David, all > COMPAT_SYSCALL_WRAP2(creat, ...): > mov w0, w0 > b > > > > Cost wise, this seems like it all cancels out in the end, but what > > > do I know? > > > > I think you know something, and I also think Heiko and other s390 guys > > know something as

Re: [PATCH v4 0/1] pstore/ram: add Device Tree bindings

2016-06-14 Thread Rob Herring
On Fri, Jun 10, 2016 at 03:50:58PM -0700, Kees Cook wrote: > This is a "v4" of Greg Hackmann's DT bindings for ramoops. This is > what I'm going to land in the pstore tree unless there are strong and > convincing arguments against it. :) > > I made a number of changes based people's feedback, and

Re: [PATCH v16 6/6] ARM: socfpga: fpga bridge driver support

2016-06-14 Thread Trent Piepho
On Mon, 2016-06-13 at 14:35 -0500, atull wrote: > > > + > > > + /* Allow bridge to be visible to L3 masters or not */ > > > + if (priv->remap_mask) { > > > + priv->l3_remap_value |= ALT_L3_REMAP_MPUZERO_MSK; > > > > Doesn't seem like this belongs here. I realize the write-only register >

Re: [PATCH] Add kernel parameter to blacklist modules

2016-06-14 Thread Henrique de Moraes Holschuh
On Tue, 14 Jun 2016, Christoph Hellwig wrote: > On Mon, Jun 13, 2016 at 08:32:41AM -0400, Prarit Bhargava wrote: > > Blacklisting a module in linux has long been a problem. The process of > > blacklisting a module has changed over time, and it seems that every OS > > does it slightly differently

Re: [PATCH v2 00/38] Documentation/sphinx

2016-06-14 Thread Jonathan Corbet
On Tue, 14 Jun 2016 10:15:00 +0200 Daniel Vetter wrote: > Hi Jon, > > On Fri, Jun 10, 2016 at 10:41 PM, Dave Airlie wrote: > > > It would be best if Jon can give us a known tag that won't get rebased, > > and will end up in docs-next and drm-next,

Re: [PATCH] Add kernel parameter to blacklist modules

2016-06-14 Thread Prarit Bhargava
On 06/14/2016 01:17 PM, Christoph Hellwig wrote: > On Mon, Jun 13, 2016 at 08:32:41AM -0400, Prarit Bhargava wrote: >> Blacklisting a module in linux has long been a problem. The process of >> blacklisting a module has changed over time, and it seems that every OS >> does it slightly

Re: [PATCH] Add kernel parameter to blacklist modules

2016-06-14 Thread Christoph Hellwig
On Mon, Jun 13, 2016 at 08:32:41AM -0400, Prarit Bhargava wrote: > Blacklisting a module in linux has long been a problem. The process of > blacklisting a module has changed over time, and it seems that every OS > does it slightly differently and depends on the age of the init system > used on

[PATCH v2] Add kernel parameter to blacklist modules

2016-06-14 Thread Prarit Bhargava
Blacklisting a module in linux has long been a problem. The current procedure is to use rd.blacklist=module_name, however, that doesn't cover the case after the initramfs and before a boot prompt (where one is supposed to use /etc/modprobe.d/blacklist.conf to blacklist runtime loading). Using

Re: [RESEND PATCH v5 0/1] ARM64: ACPI: Update documentation for latest specification version

2016-06-14 Thread Catalin Marinas
On Tue, Jun 14, 2016 at 08:46:26AM -0600, Al Stone wrote: > On 06/14/2016 03:24 AM, Will Deacon wrote: > > On Tue, Jun 14, 2016 at 10:13:31AM +0100, Will Deacon wrote: > >> On Mon, Jun 13, 2016 at 03:41:54PM -0600, Al Stone wrote: > >>> This is a resend only: Ping? Last ping was 26 May; there has

Re: [RESEND PATCH v5 0/1] ARM64: ACPI: Update documentation for latest specification version

2016-06-14 Thread Al Stone
On 06/14/2016 03:24 AM, Will Deacon wrote: > On Tue, Jun 14, 2016 at 10:13:31AM +0100, Will Deacon wrote: >> On Mon, Jun 13, 2016 at 03:41:54PM -0600, Al Stone wrote: >>> This is a resend only: Ping? Last ping was 26 May; there has been zero >>> response since then. Already have one ACK from

Re: [PATCH 0/3] move visorbus out of staging to drivers/virt/visorbus

2016-06-14 Thread Neil Horman
On Fri, Jun 10, 2016 at 11:23:53PM -0400, David Kershner wrote: > This patchset is dependent on the previously-submitted patchset: > > staging: unisys: fix visorbus & visorinput issues raised by tglx > > This patchset moves drivers/staging/unisys/include to > include/linux/visorbus, and

Re: [RESEND PATCH v5 0/1] ARM64: ACPI: Update documentation for latest specification version

2016-06-14 Thread Will Deacon
On Tue, Jun 14, 2016 at 10:13:31AM +0100, Will Deacon wrote: > On Mon, Jun 13, 2016 at 03:41:54PM -0600, Al Stone wrote: > > This is a resend only: Ping? Last ping was 26 May; there has been zero > > response since then. Already have one ACK from Lorenzo; another from an > > arm64 maintainer