From: "Steven Rostedt (VMware)"
Instead of just waiting for a page to be full before waking up a pending
reader, allow the reader to pass in a "percentage" of pages that have
content before waking up a reader. This should help keep the process of
reading the events not cause wake ups that
From: "Steven Rostedt (VMware)"
When the function profiler is not configured, the "graph_time" option is
meaningless, as the function profiler is the only thing that makes use of
it. Do not expose it if the profiler is not configured.
Link:
From: Masami Hiramatsu
Add unified dynamic event framework for ftrace kprobes, uprobes
and synthetic events. Those dynamic events can be co-exist on
same file because those syntax doesn't overlap.
This introduces a framework part which provides a unified tracefs
interface and operations.
Link:
From: Masami Hiramatsu
Use dyn_event framework for uprobe events. This shows
uprobe events on "dynamic_events" file.
User can also define new uprobe events via dynamic_events.
Link:
http://lkml.kernel.org/r/154140858481.17322.9091293846515154065.stgit@devbox
Reviewed-by: Tom Zanussi
From: Masami Hiramatsu
Use dyn_event framework for uprobe events. This shows
uprobe events on "dynamic_events" file.
User can also define new uprobe events via dynamic_events.
Link:
http://lkml.kernel.org/r/154140858481.17322.9091293846515154065.stgit@devbox
Reviewed-by: Tom Zanussi
From: Masami Hiramatsu
Add unified dynamic event framework for ftrace kprobes, uprobes
and synthetic events. Those dynamic events can be co-exist on
same file because those syntax doesn't overlap.
This introduces a framework part which provides a unified tracefs
interface and operations.
Link:
From: "Steven Rostedt (VMware)"
The trace_add/remove_event_call_nolock() functions were added to allow
the tace_add/remove_event_call() code be called when the event_mutex
lock was already taken. Now that all callers are done within the
event_mutex, there's no reason to have two different
From: "Steven Rostedt (VMware)"
The trace_add/remove_event_call_nolock() functions were added to allow
the tace_add/remove_event_call() code be called when the event_mutex
lock was already taken. Now that all callers are done within the
event_mutex, there's no reason to have two different
From: "Steven Rostedt (VMware)"
Functions in the set_graph_notrace no longer subtract FTRACE_NOTRACE_DEPTH
from curr_ret_stack, as that is now implemented via the trace_recursion
flags. Access to curr_ret_stack no longer needs to worry about checking for
this. curr_ret_stack is still initialized
From: "Steven Rostedt (VMware)"
Functions in the set_graph_notrace no longer subtract FTRACE_NOTRACE_DEPTH
from curr_ret_stack, as that is now implemented via the trace_recursion
flags. Access to curr_ret_stack no longer needs to worry about checking for
this. curr_ret_stack is still initialized
Roman Penyaev wrote:
> Hi all,
>
> The goal of this patch is to reduce contention of ep_poll_callback() which
> can be called concurrently from different CPUs in case of high events
> rates and many fds per epoll. Problem can be very well reproduced by
> generating events (write to pipe or
Roman Penyaev wrote:
> Hi all,
>
> The goal of this patch is to reduce contention of ep_poll_callback() which
> can be called concurrently from different CPUs in case of high events
> rates and many fds per epoll. Problem can be very well reproduced by
> generating events (write to pipe or
> I can't help you on that. I never tried to force errors by grounding the
> signals. You have read the driver. Do you see panic? The idea is to
> report the error and let upper layer to decide what to do. Sometimes
> limping forward is better than reset or panic. Again, it is not driver's
>
> I can't help you on that. I never tried to force errors by grounding the
> signals. You have read the driver. Do you see panic? The idea is to
> report the error and let upper layer to decide what to do. Sometimes
> limping forward is better than reset or panic. Again, it is not driver's
>
On Wed, Dec 5, 2018 at 3:20 PM Sean Christopherson
wrote:
>
> Intel Software Guard Extensions (SGX) SGX introduces a new CPL3-only
> enclave mode that runs as a sort of black box shared object that is
> hosted by an untrusted normal CPL3 process.
>
> Enclave transitions have semantics that are a
On Wed, Dec 5, 2018 at 3:20 PM Sean Christopherson
wrote:
>
> Intel Software Guard Extensions (SGX) SGX introduces a new CPL3-only
> enclave mode that runs as a sort of black box shared object that is
> hosted by an untrusted normal CPL3 process.
>
> Enclave transitions have semantics that are a
On Wed, Dec 05, 2018 at 02:03:10PM -0800, Linus Torvalds wrote:
> On Wed, Dec 5, 2018 at 12:40 PM Andrea Arcangeli wrote:
> >
> > So ultimately we decided that the saner behavior that gives the least
> > risk of regression for the short term, until we can do something
> > better, was the one that
>> On Dec 5, 2018, at 7:04 AM, Josh Poimboeuf wrote:
>
>
>> Anyway, I have a new objection to Josh’s create_gap proposal: what on
>> Earth will kernel CET do to it? Maybe my longjmp-like hack is
>> actually better.
>
> Does CET even care about iret? I assumed it didn't. If it does, your
>
On Wed, Dec 05, 2018 at 02:03:10PM -0800, Linus Torvalds wrote:
> On Wed, Dec 5, 2018 at 12:40 PM Andrea Arcangeli wrote:
> >
> > So ultimately we decided that the saner behavior that gives the least
> > risk of regression for the short term, until we can do something
> > better, was the one that
>> On Dec 5, 2018, at 7:04 AM, Josh Poimboeuf wrote:
>
>
>> Anyway, I have a new objection to Josh’s create_gap proposal: what on
>> Earth will kernel CET do to it? Maybe my longjmp-like hack is
>> actually better.
>
> Does CET even care about iret? I assumed it didn't. If it does, your
>
Hello,
My name is ms. Reem Al-Hashimi. The UAE minister of state for international
cooperation. I got your contact from an email database from your country. I
have a financial transaction i would like to discuss with you. Please reply to
reem2...@daum.net, for more details if you are
Hello,
My name is ms. Reem Al-Hashimi. The UAE minister of state for international
cooperation. I got your contact from an email database from your country. I
have a financial transaction i would like to discuss with you. Please reply to
reem2...@daum.net, for more details if you are
>From a081e783383adf1179c71bc37b4e199d087af643 Mon Sep 17 00:00:00 2001
From: Alek Du
Date: Fri, 30 Nov 2018 14:02:28 +0800
Subject: [PATCH] mmc: sdhci: fix the timeout check window for clock and reset
We observed some premature timeouts on a virtualization platform, the log
is like this:
case
>From a081e783383adf1179c71bc37b4e199d087af643 Mon Sep 17 00:00:00 2001
From: Alek Du
Date: Fri, 30 Nov 2018 14:02:28 +0800
Subject: [PATCH] mmc: sdhci: fix the timeout check window for clock and reset
We observed some premature timeouts on a virtualization platform, the log
is like this:
case
On Mon, Dec 3, 2018 at 12:14 PM Luis Chamberlain wrote:
> Since this worked before I do agree that we need to keep it working now,
> and I can't think of an issue with returning 0 now. Since this is about
> semantics though I'd like a bit more review from at last one more
> person.
>
> Kees,
On Mon, Dec 3, 2018 at 12:14 PM Luis Chamberlain wrote:
> Since this worked before I do agree that we need to keep it working now,
> and I can't think of an issue with returning 0 now. Since this is about
> semantics though I'd like a bit more review from at last one more
> person.
>
> Kees,
On Wed, Dec 05, 2018 at 04:23:42PM -0700, Logan Gunthorpe wrote:
>
>
> On 2018-12-05 4:20 p.m., Jerome Glisse wrote:
> > And my proposal is under /sys/bus and have symlink to all existing
> > device it agregate in there.
>
> That's so not the point. Use the existing buses don't invent some
>
On Wed, Dec 05, 2018 at 04:23:42PM -0700, Logan Gunthorpe wrote:
>
>
> On 2018-12-05 4:20 p.m., Jerome Glisse wrote:
> > And my proposal is under /sys/bus and have symlink to all existing
> > device it agregate in there.
>
> That's so not the point. Use the existing buses don't invent some
>
On Wed, Dec 5, 2018 at 12:53 PM Christian Brauner wrote:
> On Wed, Dec 05, 2018 at 12:20:43PM -0600, Eric W. Biederman wrote:
> > Christian Brauner writes:
> > > [1]: https://lkml.org/lkml/2018/11/18/130
> > > [2]:
> > > https://lore.kernel.org/lkml/874lbtjvtd@oldenburg2.str.redhat.com/
>
On Wed, Dec 5, 2018 at 12:53 PM Christian Brauner wrote:
> On Wed, Dec 05, 2018 at 12:20:43PM -0600, Eric W. Biederman wrote:
> > Christian Brauner writes:
> > > [1]: https://lkml.org/lkml/2018/11/18/130
> > > [2]:
> > > https://lore.kernel.org/lkml/874lbtjvtd@oldenburg2.str.redhat.com/
>
On 2018-12-05 4:20 p.m., Jerome Glisse wrote:
> And my proposal is under /sys/bus and have symlink to all existing
> device it agregate in there.
That's so not the point. Use the existing buses don't invent some
virtual tree. I don't know how many times I have to say this or in how
many ways.
On 2018-12-05 4:20 p.m., Jerome Glisse wrote:
> And my proposal is under /sys/bus and have symlink to all existing
> device it agregate in there.
That's so not the point. Use the existing buses don't invent some
virtual tree. I don't know how many times I have to say this or in how
many ways.
On 12/5/18 4:15 PM, Anders Roxell wrote:
On Wed, 5 Dec 2018 at 22:50, Linus Walleij wrote:
Sorry for top-posting,
I don't understand the selftest environment very well so I do not know
if this is the right thing to do.
I can merge the patch through the GPIO tree but I need a nod from
On 12/5/18 4:15 PM, Anders Roxell wrote:
On Wed, 5 Dec 2018 at 22:50, Linus Walleij wrote:
Sorry for top-posting,
I don't understand the selftest environment very well so I do not know
if this is the right thing to do.
I can merge the patch through the GPIO tree but I need a nod from
Call fixup_vdso_exception() to attempt to fixup exceptions in vDSO code
before generating a signal for userspace faults. This allows vDSO
functions to utilize exception fixup to report unhandled exceptions
directly to userspace for specific flows in lieu of generating a signal.
Suggested-by:
Call fixup_vdso_exception() to attempt to fixup exceptions in vDSO code
before generating a signal for userspace faults. This allows vDSO
functions to utilize exception fixup to report unhandled exceptions
directly to userspace for specific flows in lieu of generating a signal.
Suggested-by:
The basic concept and implementation is very similar to the kernel's
exception fixup mechanism. The key differences are that the kernel
handler is hardcoded and the fixup entry addresses are relative to
the overall table as opposed to individual entries.
Hardcoding the kernel handler avoids the
Call fixup_vdso_exception() in the SIGSEGV and SIGBUS paths to attempt
to fixup page faults in vDSO. This allows vDSO functions to utilize
exception fixup to report unhandled page faults directly to userspace
for specific flows in lieu of generating a signal.
In the SIGSEGV flow, make sure to
The basic concept and implementation is very similar to the kernel's
exception fixup mechanism. The key differences are that the kernel
handler is hardcoded and the fixup entry addresses are relative to
the overall table as opposed to individual entries.
Hardcoding the kernel handler avoids the
Call fixup_vdso_exception() in the SIGSEGV and SIGBUS paths to attempt
to fixup page faults in vDSO. This allows vDSO functions to utilize
exception fixup to report unhandled page faults directly to userspace
for specific flows in lieu of generating a signal.
In the SIGSEGV flow, make sure to
When dumping out binder transactions via a debug node,
the output is too verbose if a process has many nodes.
Change the output for transaction dumps to only display
nodes with pending async transactions.
Signed-off-by: Todd Kjos
---
v2: no change, just resubmitted as #3 of 3 patches instead of
On Wed, Dec 05, 2018 at 04:09:29PM -0700, Logan Gunthorpe wrote:
>
>
> On 2018-12-05 3:58 p.m., Jerome Glisse wrote:
> > So just to be clear here is how i understand your position:
> > "Single coherent sysfs hierarchy to describe something is useless
> > let's git rm drivers/base/"
>
> I have
When dumping out binder transactions via a debug node,
the output is too verbose if a process has many nodes.
Change the output for transaction dumps to only display
nodes with pending async transactions.
Signed-off-by: Todd Kjos
---
v2: no change, just resubmitted as #3 of 3 patches instead of
On Wed, Dec 05, 2018 at 04:09:29PM -0700, Logan Gunthorpe wrote:
>
>
> On 2018-12-05 3:58 p.m., Jerome Glisse wrote:
> > So just to be clear here is how i understand your position:
> > "Single coherent sysfs hierarchy to describe something is useless
> > let's git rm drivers/base/"
>
> I have
Intel Software Guard Extensions (SGX) SGX introduces a new CPL3-only
enclave mode that runs as a sort of black box shared object that is
hosted by an untrusted normal CPL3 process.
Enclave transitions have semantics that are a lovely blend of SYCSALL,
SYSRET and VM-Exit. In a non-faulting
First things first, this RFC is not intended to address whether or not
vDSO is the appropriate method for supporting SGX enclaves, but rather
its purpose is to hammer out the vDSO implementation *if* we decide it
is the best approach.
Though the code technically stands alone, the intent is to
Intel Software Guard Extensions (SGX) SGX introduces a new CPL3-only
enclave mode that runs as a sort of black box shared object that is
hosted by an untrusted normal CPL3 process.
Enclave transitions have semantics that are a lovely blend of SYCSALL,
SYSRET and VM-Exit. In a non-faulting
First things first, this RFC is not intended to address whether or not
vDSO is the appropriate method for supporting SGX enclaves, but rather
its purpose is to hammer out the vDSO implementation *if* we decide it
is the best approach.
Though the code technically stands alone, the intent is to
On Wed, Dec 5, 2018 at 2:59 PM Stefan Agner wrote:
>
> On 05.12.2018 19:41, Nick Desaulniers wrote:
> > On Wed, Dec 5, 2018 at 10:40 AM Ard Biesheuvel
> > wrote:
> >>
> >> On Wed, 5 Dec 2018 at 19:36, Nathan Chancellor
> >> wrote:
> >> >
> >> > On Wed, Dec 05, 2018 at 09:09:56AM +0100, Ard
Add __acquire()/__release() annnotations to fix warnings
in sparse context checking
There is one case where the warning was due to a lack of
a "default:" case in a switch statement where a lock was
being released in each of the cases, so the default
case was added.
Signed-off-by: Todd Kjos
---
Fix the incomplete kerneldoc header for struct binder_buffer.
Signed-off-by: Todd Kjos
---
v2: no code change. Removed needless "Change-Id:"
There is no dependancy on patch 1/3
drivers/android/binder_alloc.h | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff
On Wed, Dec 5, 2018 at 2:59 PM Stefan Agner wrote:
>
> On 05.12.2018 19:41, Nick Desaulniers wrote:
> > On Wed, Dec 5, 2018 at 10:40 AM Ard Biesheuvel
> > wrote:
> >>
> >> On Wed, 5 Dec 2018 at 19:36, Nathan Chancellor
> >> wrote:
> >> >
> >> > On Wed, Dec 05, 2018 at 09:09:56AM +0100, Ard
Add __acquire()/__release() annnotations to fix warnings
in sparse context checking
There is one case where the warning was due to a lack of
a "default:" case in a switch statement where a lock was
being released in each of the cases, so the default
case was added.
Signed-off-by: Todd Kjos
---
Fix the incomplete kerneldoc header for struct binder_buffer.
Signed-off-by: Todd Kjos
---
v2: no code change. Removed needless "Change-Id:"
There is no dependancy on patch 1/3
drivers/android/binder_alloc.h | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff
On Wed, 5 Dec 2018 at 22:50, Linus Walleij wrote:
>
> Sorry for top-posting,
>
> I don't understand the selftest environment very well so I do not know
> if this is the right thing to do.
>
> I can merge the patch through the GPIO tree but I need a nod from
> someone wise, like Shuah Khan or
On Wed, 5 Dec 2018 at 22:50, Linus Walleij wrote:
>
> Sorry for top-posting,
>
> I don't understand the selftest environment very well so I do not know
> if this is the right thing to do.
>
> I can merge the patch through the GPIO tree but I need a nod from
> someone wise, like Shuah Khan or
I added some s390 and powerpc people.
On Tue, Dec 4, 2018 at 4:18 AM Igor Stoppa wrote:
>
> Implementation of write rare for statically allocated data, located in a
> specific memory section through the use of the __write_rare label.
>
> The basic functions are:
> - wr_memset(): write rare
I added some s390 and powerpc people.
On Tue, Dec 4, 2018 at 4:18 AM Igor Stoppa wrote:
>
> Implementation of write rare for statically allocated data, located in a
> specific memory section through the use of the __write_rare label.
>
> The basic functions are:
> - wr_memset(): write rare
Hi Lukasz/Rob,
On Tue, Oct 9, 2018 at 7:50 AM Lukasz Majewski wrote:
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_dspi3>;
> + bus-num = <3>;
> + status = "okay";
> + spi-slave;
> +
> + slave@0 {
> + compatible = "lwn,bk4";
> +
Hi Lukasz/Rob,
On Tue, Oct 9, 2018 at 7:50 AM Lukasz Majewski wrote:
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_dspi3>;
> + bus-num = <3>;
> + status = "okay";
> + spi-slave;
> +
> + slave@0 {
> + compatible = "lwn,bk4";
> +
On Wed, Dec 05, 2018 at 04:58:31PM +0800, Xunlei Pang wrote:
> Hi Roman,
>
> On 2018/12/4 AM 2:00, Roman Gushchin wrote:
> > On Mon, Dec 03, 2018 at 04:01:17PM +0800, Xunlei Pang wrote:
> >> When usage exceeds min, min usage should be min other than 0.
> >> Apply the same for low.
> >>
> >>
On Wed, Dec 05, 2018 at 04:58:31PM +0800, Xunlei Pang wrote:
> Hi Roman,
>
> On 2018/12/4 AM 2:00, Roman Gushchin wrote:
> > On Mon, Dec 03, 2018 at 04:01:17PM +0800, Xunlei Pang wrote:
> >> When usage exceeds min, min usage should be min other than 0.
> >> Apply the same for low.
> >>
> >>
On Mon, Dec 3, 2018 at 1:31 AM KarimAllah Ahmed wrote:
>
> Copy the VMCS12 directly from guest memory instead of the map->copy->unmap
> sequence. This also avoids using kvm_vcpu_gpa_to_page() and kmap() which
> assumes that there is a "struct page" for guest memory.
>
> Signed-off-by: KarimAllah
On Mon, Dec 3, 2018 at 1:31 AM KarimAllah Ahmed wrote:
>
> Copy the VMCS12 directly from guest memory instead of the map->copy->unmap
> sequence. This also avoids using kvm_vcpu_gpa_to_page() and kmap() which
> assumes that there is a "struct page" for guest memory.
>
> Signed-off-by: KarimAllah
On 2018-12-05 3:58 p.m., Jerome Glisse wrote:
> So just to be clear here is how i understand your position:
> "Single coherent sysfs hierarchy to describe something is useless
> let's git rm drivers/base/"
I have no idea what you're talking about. I'm saying the existing sysfs
hierarchy
On 2018-12-05 3:58 p.m., Jerome Glisse wrote:
> So just to be clear here is how i understand your position:
> "Single coherent sysfs hierarchy to describe something is useless
> let's git rm drivers/base/"
I have no idea what you're talking about. I'm saying the existing sysfs
hierarchy
Hi,
On Mon, Nov 12, 2018 at 06:52:35PM +0800, Baolin Wang wrote:
> Since the USB notifier context is atomic, we can not start or stop charging
> in atomic context. Thus this patch adds one work to help to charge or
> discharge.
>
> Signed-off-by: Baolin Wang
> ---
Thanks, patchset queued.
--
Hi,
On Mon, Nov 12, 2018 at 06:52:35PM +0800, Baolin Wang wrote:
> Since the USB notifier context is atomic, we can not start or stop charging
> in atomic context. Thus this patch adds one work to help to charge or
> discharge.
>
> Signed-off-by: Baolin Wang
> ---
Thanks, patchset queued.
--
On 2018.12.03 03:48 Rafael J. Wysocki wrote:
>>> There is an additional issue where if idle state 0 is disabled (with the
>>> above suggested code patch),
>>> idle state usage seems to fall to deeper states than idle state 1.
>>> This is not the expected behaviour.
>>
>> No, it isn't.
>>
>>>
On 2018.12.03 03:48 Rafael J. Wysocki wrote:
>>> There is an additional issue where if idle state 0 is disabled (with the
>>> above suggested code patch),
>>> idle state usage seems to fall to deeper states than idle state 1.
>>> This is not the expected behaviour.
>>
>> No, it isn't.
>>
>>>
ABS_RESERVED was added in d9ca1c990a7 and accidentally removed as part of
ffe0e7cf290f5c9 when the high-resolution scrolling code was removed.
Signed-off-by: Peter Hutterer
---
include/uapi/linux/input-event-codes.h | 9 +
1 file changed, 9 insertions(+)
diff --git
ABS_RESERVED was added in d9ca1c990a7 and accidentally removed as part of
ffe0e7cf290f5c9 when the high-resolution scrolling code was removed.
Signed-off-by: Peter Hutterer
---
include/uapi/linux/input-event-codes.h | 9 +
1 file changed, 9 insertions(+)
diff --git
On 05.12.2018 19:41, Nick Desaulniers wrote:
> On Wed, Dec 5, 2018 at 10:40 AM Ard Biesheuvel
> wrote:
>>
>> On Wed, 5 Dec 2018 at 19:36, Nathan Chancellor
>> wrote:
>> >
>> > On Wed, Dec 05, 2018 at 09:09:56AM +0100, Ard Biesheuvel wrote:
>> > > (+ Arnd)
>> > >
>> > > On Wed, 5 Dec 2018 at
On 05.12.2018 19:41, Nick Desaulniers wrote:
> On Wed, Dec 5, 2018 at 10:40 AM Ard Biesheuvel
> wrote:
>>
>> On Wed, 5 Dec 2018 at 19:36, Nathan Chancellor
>> wrote:
>> >
>> > On Wed, Dec 05, 2018 at 09:09:56AM +0100, Ard Biesheuvel wrote:
>> > > (+ Arnd)
>> > >
>> > > On Wed, 5 Dec 2018 at
On Wed, Dec 05, 2018 at 12:10:10PM -0700, Logan Gunthorpe wrote:
>
>
> On 2018-12-05 11:55 a.m., Jerome Glisse wrote:
> > So now once next type of device shows up with the exact same thing
> > let say FPGA, we have to create a new subsystem for them too. Also
> > this make the userspace life
On Wed, Dec 05, 2018 at 12:10:10PM -0700, Logan Gunthorpe wrote:
>
>
> On 2018-12-05 11:55 a.m., Jerome Glisse wrote:
> > So now once next type of device shows up with the exact same thing
> > let say FPGA, we have to create a new subsystem for them too. Also
> > this make the userspace life
Hi Guy,
On Wed, 5 Dec 2018 12:25:57 + "Guy Levi(SW)" wrote:
>
> >
> > Huh. So apparently every compiler that tested this patch (0-day, mine,
> > the submitters) optimized this call away because is_atomic_response()
> > always returns 0: meaning mlx5_get_atomic_laddr is never callable and
>
Hi Guy,
On Wed, 5 Dec 2018 12:25:57 + "Guy Levi(SW)" wrote:
>
> >
> > Huh. So apparently every compiler that tested this patch (0-day, mine,
> > the submitters) optimized this call away because is_atomic_response()
> > always returns 0: meaning mlx5_get_atomic_laddr is never callable and
>
On Wed, Dec 5, 2018 at 1:41 AM Sasha Levin wrote:
>
> From: Kees Cook
>
> [ Upstream commit 89d328f637b9904b6d4c9af73c8a608b8dd4d6f8 ]
>
> The actual number of bytes stored in a PRZ is smaller than the
> bytes requested by platform data, since there is a header on each
> PRZ. Additionally, if
On Wed, Dec 5, 2018 at 1:41 AM Sasha Levin wrote:
>
> From: Kees Cook
>
> [ Upstream commit 89d328f637b9904b6d4c9af73c8a608b8dd4d6f8 ]
>
> The actual number of bytes stored in a PRZ is smaller than the
> bytes requested by platform data, since there is a header on each
> PRZ. Additionally, if
On 12/5/18 2:54 PM, Tracy Smith wrote:
>>> Question 4) If so, will a panic ever be called if there is a hardware
>>> uncorrectable memory failure?
>
>> No. It is up to upper layer of EDAC driver. Layerscape driver only reports
>> CEs and UEs.
>
> Just to be clear, the upper layer of the EDAC
On 12/5/18 2:54 PM, Tracy Smith wrote:
>>> Question 4) If so, will a panic ever be called if there is a hardware
>>> uncorrectable memory failure?
>
>> No. It is up to upper layer of EDAC driver. Layerscape driver only reports
>> CEs and UEs.
>
> Just to be clear, the upper layer of the EDAC
On Wed, 21 Nov 2018 02:38:28 +0530, Sibi Sankar wrote:
> Add power-domain bindings for Q6V5 MSS on SDM845 SoCs.
>
> Signed-off-by: Sibi Sankar
> ---
>
> Add dt-binding corresponding to https://patchwork.kernel.org/patch/10586893/
> (remoteproc: q6v5: Add support to vote for rpmh power domains)
On Wed, 21 Nov 2018 02:38:28 +0530, Sibi Sankar wrote:
> Add power-domain bindings for Q6V5 MSS on SDM845 SoCs.
>
> Signed-off-by: Sibi Sankar
> ---
>
> Add dt-binding corresponding to https://patchwork.kernel.org/patch/10586893/
> (remoteproc: q6v5: Add support to vote for rpmh power domains)
On Wed, 21 Nov 2018 02:32:07 +0530, Sibi Sankar wrote:
> Add optional shutdown-irq binding required for sysmon shutdown on
> SDM845/MSM8996/QCS404 SoCs.
>
> Signed-off-by: Sibi Sankar
> ---
> Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt | 5 +++--
> 1 file changed, 3
On Wed, 21 Nov 2018 02:32:07 +0530, Sibi Sankar wrote:
> Add optional shutdown-irq binding required for sysmon shutdown on
> SDM845/MSM8996/QCS404 SoCs.
>
> Signed-off-by: Sibi Sankar
> ---
> Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt | 5 +++--
> 1 file changed, 3
>> Question 4) If so, will a panic ever be called if there is a hardware
>> uncorrectable memory failure?
>No. It is up to upper layer of EDAC driver. Layerscape driver only reports CEs
>and UEs.
Just to be clear, the upper layer of the EDAC driver will or will not
panic when a UE is detected
>> Question 4) If so, will a panic ever be called if there is a hardware
>> uncorrectable memory failure?
>No. It is up to upper layer of EDAC driver. Layerscape driver only reports CEs
>and UEs.
Just to be clear, the upper layer of the EDAC driver will or will not
panic when a UE is detected
On Wed, Dec 5, 2018 at 11:32 PM Sven Van Asbroeck wrote:
> On Wed, Dec 5, 2018 at 2:17 PM Greg KH wrote:
> >
> > Great, then call it a 'fieldbus' class, not "fieldbus_dev' class.
>
> Small nit:
>
> Hardware connected to a fieldbus comes in two distinct flavours:
> - clients (e.g. thermometer,
On Wed, Dec 5, 2018 at 11:32 PM Sven Van Asbroeck wrote:
> On Wed, Dec 5, 2018 at 2:17 PM Greg KH wrote:
> >
> > Great, then call it a 'fieldbus' class, not "fieldbus_dev' class.
>
> Small nit:
>
> Hardware connected to a fieldbus comes in two distinct flavours:
> - clients (e.g. thermometer,
On Wed, Dec 5, 2018 at 2:02 PM Konrad Rzeszutek Wilk
wrote:
>
> On Wed, Dec 05, 2018 at 05:19:56PM -0200, Eduardo Habkost wrote:
> > Months ago, we have added code to allow direct access to MSR_IA32_SPEC_CTRL
> > to the guest, which makes STIBP available to guests. This was implemented
> > by
On Wed, Dec 5, 2018 at 2:02 PM Konrad Rzeszutek Wilk
wrote:
>
> On Wed, Dec 05, 2018 at 05:19:56PM -0200, Eduardo Habkost wrote:
> > Months ago, we have added code to allow direct access to MSR_IA32_SPEC_CTRL
> > to the guest, which makes STIBP available to guests. This was implemented
> > by
This is a full revert of ac5b2c18911f ("mm: thp: relax __GFP_THISNODE for
MADV_HUGEPAGE mappings") and a partial revert of 89c83fb539f9 ("mm, thp:
consolidate THP gfp handling into alloc_hugepage_direct_gfpmask").
By not setting __GFP_THISNODE, applications can allocate remote hugepages
when the
This is a full revert of ac5b2c18911f ("mm: thp: relax __GFP_THISNODE for
MADV_HUGEPAGE mappings") and a partial revert of 89c83fb539f9 ("mm, thp:
consolidate THP gfp handling into alloc_hugepage_direct_gfpmask").
By not setting __GFP_THISNODE, applications can allocate remote hugepages
when the
On Wed, Dec 05, 2018 at 09:37:21AM -0800, Bjorn Andersson wrote:
> + linux-arm-msm
>
> On Wed 21 Nov 18:32 PST 2018, Jonathan Marek wrote:
>
> > This fixes the case when CONFIG_QCOM_SCM is not enabled, and linux/errno.h
> > has not been included previously.
> >
> > Signed-off-by: Jonathan Marek
On Wed, Dec 05, 2018 at 09:37:21AM -0800, Bjorn Andersson wrote:
> + linux-arm-msm
>
> On Wed 21 Nov 18:32 PST 2018, Jonathan Marek wrote:
>
> > This fixes the case when CONFIG_QCOM_SCM is not enabled, and linux/errno.h
> > has not been included previously.
> >
> > Signed-off-by: Jonathan Marek
Hello,
My name is ms. Reem Al-Hashimi. The UAE minister of state for international
cooperation. I got your contact from an email database from your country. I
have a financial transaction i would like to discuss with you. Please reply to
reem2...@daum.net, for more details if you are
Hello,
My name is ms. Reem Al-Hashimi. The UAE minister of state for international
cooperation. I got your contact from an email database from your country. I
have a financial transaction i would like to discuss with you. Please reply to
reem2...@daum.net, for more details if you are
On Wed, Dec 5, 2018 at 4:38 PM Rob Herring wrote:
>
> On Tue, Nov 20, 2018 at 09:27:51AM +, Z.q. Hou wrote:
> > From: Hou Zhiqiang
> >
> > Add PCIe Gen4 controller DT bindings of NXP Layerscape SoCs.
> >
> > Signed-off-by: Hou Zhiqiang
> > ---
> > V2:
> > - Change to use the
On Wed, Dec 5, 2018 at 4:38 PM Rob Herring wrote:
>
> On Tue, Nov 20, 2018 at 09:27:51AM +, Z.q. Hou wrote:
> > From: Hou Zhiqiang
> >
> > Add PCIe Gen4 controller DT bindings of NXP Layerscape SoCs.
> >
> > Signed-off-by: Hou Zhiqiang
> > ---
> > V2:
> > - Change to use the
401 - 500 of 2376 matches
Mail list logo
