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 against it. :)
>>
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 /etc/modprobe.d/blacklist.conf to black
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 core
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 well
On 06/14/2016 04:51 PM, Henrique de Moraes Holschuh wrote:
>
> And if such a module blacklist feature ends up being invoked by the
> "nuke_module_from_orbit=" parameter, I will pay the author
> (and the subsystem maintainer that manages to get that merged) a couple
> beers should we ever meet i
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
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
>
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 a
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, then we can arranage for
> > docs-next
> > to
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 differently
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 tha
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 rd.s
On 06/14/2016 08:50 AM, Catalin Marinas wrote:
> 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 re
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
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 Lore
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 mov
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 woul
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 would be really helpful.
I thought there were outstanding comments on v4
Hi Jon,
On Fri, Jun 10, 2016 at 10:41 PM, Dave Airlie wrote:
> On 11 June 2016 at 04:17, Daniel Vetter wrote:
>> On Thu, Jun 9, 2016 at 9:55 PM, Jonathan Corbet wrote:
>>> On Sat, 4 Jun 2016 14:37:01 +0300
>>> Jani Nikula wrote:
>>>
When this lands in docs-next and we can backmerge to dr
19 matches
Mail list logo
