On Tue, Oct 30, 2018 at 10:58:15AM -0400, Steven Rostedt wrote:
On Tue, 30 Oct 2018 09:28:22 -0400
Sasha Levin wrote:
From: Masami Hiramatsu
[ Upstream commit ba0e41ca81b935b958006c7120466e2217357827 ]
Add a testcase to check the syntax and field types for
synthetic_events interface.
On Tue, Oct 30, 2018 at 10:58:15AM -0400, Steven Rostedt wrote:
On Tue, 30 Oct 2018 09:28:22 -0400
Sasha Levin wrote:
From: Masami Hiramatsu
[ Upstream commit ba0e41ca81b935b958006c7120466e2217357827 ]
Add a testcase to check the syntax and field types for
synthetic_events interface.
We should never assume to get a reply from the firmware otherwise
the call could block forever and the user don't get informed. So
define a timeout of 1 sec and print a stacktrace once in the unlikely
case the timeout expired.
Signed-off-by: Stefan Wahren
---
drivers/firmware/raspberrypi.c | 8
We should never assume to get a reply from the firmware otherwise
the call could block forever and the user don't get informed. So
define a timeout of 1 sec and print a stacktrace once in the unlikely
case the timeout expired.
Signed-off-by: Stefan Wahren
---
drivers/firmware/raspberrypi.c | 8
[...]
> > > For example, index printing. Please, remove it. I completely
> > > forgot
> > > about userspace powerful tools. At least two very old and nice
> > > can
> > > enumerate lines for you.
> > > Obviously the index printing is redundant.
> >
> > Index printing is required here (for LTR
[...]
> > > For example, index printing. Please, remove it. I completely
> > > forgot
> > > about userspace powerful tools. At least two very old and nice
> > > can
> > > enumerate lines for you.
> > > Obviously the index printing is redundant.
> >
> > Index printing is required here (for LTR
Access to timerslack_ns is controlled by a process having CAP_SYS_NICE
in its effective capability set, but the current check looks in the root
namespace instead of the process' user namespace. Since a process is
allowed to do other activities controlled by CAP_SYS_NICE inside a
namespace, it
Access to timerslack_ns is controlled by a process having CAP_SYS_NICE
in its effective capability set, but the current check looks in the root
namespace instead of the process' user namespace. Since a process is
allowed to do other activities controlled by CAP_SYS_NICE inside a
namespace, it
On Tue, 2018-10-30 at 08:04 -0400, Jeff Layton wrote:
> On Mon, 2018-10-29 at 08:38 -0400, Jeff Layton wrote:
> > On Mon, 2018-10-29 at 12:56 +1100, NeilBrown wrote:
> > > On Fri, Oct 26 2018, Jeff Layton wrote:
> > >
> > > > On Wed, 2018-10-24 at 09:43 +1100, NeilBrown wrote:
> > > > > This took
On Tue, 2018-10-30 at 08:04 -0400, Jeff Layton wrote:
> On Mon, 2018-10-29 at 08:38 -0400, Jeff Layton wrote:
> > On Mon, 2018-10-29 at 12:56 +1100, NeilBrown wrote:
> > > On Fri, Oct 26 2018, Jeff Layton wrote:
> > >
> > > > On Wed, 2018-10-24 at 09:43 +1100, NeilBrown wrote:
> > > > > This took
On Tue, Oct 30, 2018 at 8:56 AM Roman Gushchin wrote:
>
> On Tue, Oct 30, 2018 at 07:12:49AM +0100, Michal Hocko wrote:
> > On Mon 29-10-18 21:51:55, Roman Gushchin wrote:
> > > Mike Galbraith reported a regression caused by the commit 9b6f7e163cd0
> > > ("mm: rework memcg kernel stack
On Tue, Oct 30, 2018 at 8:56 AM Roman Gushchin wrote:
>
> On Tue, Oct 30, 2018 at 07:12:49AM +0100, Michal Hocko wrote:
> > On Mon 29-10-18 21:51:55, Roman Gushchin wrote:
> > > Mike Galbraith reported a regression caused by the commit 9b6f7e163cd0
> > > ("mm: rework memcg kernel stack
On Mon, Oct 22, 2018 at 06:14:40PM +0200, Oleg Nesterov wrote:
> On 10/22, Paul E. McKenney wrote:
> >
> > > > @@ -125,12 +125,12 @@ void rcu_sync_enter(struct rcu_sync *rsp)
> > > > rsp->gp_state = GP_PENDING;
> > > > spin_unlock_irq(>rss_lock);
> > > >
> > > > -
On Mon, Oct 22, 2018 at 06:14:40PM +0200, Oleg Nesterov wrote:
> On 10/22, Paul E. McKenney wrote:
> >
> > > > @@ -125,12 +125,12 @@ void rcu_sync_enter(struct rcu_sync *rsp)
> > > > rsp->gp_state = GP_PENDING;
> > > > spin_unlock_irq(>rss_lock);
> > > >
> > > > -
> Factor out the code to change index from x86_fsbase_write_cpu() and
> x86_gsbase_write_cpu_inactive(). Now the code is located in
> do_arch_prctl_64().
>
> The helper functions that purport to write the base register should just
> write the
> base register only. It shouldn't have magic
> Factor out the code to change index from x86_fsbase_write_cpu() and
> x86_gsbase_write_cpu_inactive(). Now the code is located in
> do_arch_prctl_64().
>
> The helper functions that purport to write the base register should just
> write the
> base register only. It shouldn't have magic
Yongqin reported that /proc/zoneinfo format is broken in 4.14
due to commit 7aaf77272358 ("mm: don't show nr_indirectly_reclaimable
in /proc/vmstat")
Node 0, zone DMA
per-node stats
nr_inactive_anon 403
nr_active_anon 89123
nr_inactive_file 128887
nr_active_file
Yongqin reported that /proc/zoneinfo format is broken in 4.14
due to commit 7aaf77272358 ("mm: don't show nr_indirectly_reclaimable
in /proc/vmstat")
Node 0, zone DMA
per-node stats
nr_inactive_anon 403
nr_active_anon 89123
nr_inactive_file 128887
nr_active_file
Thanks for the analysis, Peter.
On Mon, 29 Oct 2018 at 23:27, Peter Hutterer wrote:
> IMO this is a lost battle because you cannot know when the ratchet is
> enabled or not (at least not on all mice). Users switch between ratchet and
> freewheeling time and once you're out of one mode, you have
Thanks for the analysis, Peter.
On Mon, 29 Oct 2018 at 23:27, Peter Hutterer wrote:
> IMO this is a lost battle because you cannot know when the ratchet is
> enabled or not (at least not on all mice). Users switch between ratchet and
> freewheeling time and once you're out of one mode, you have
> Subject: Re: [PATCH] Choose CPU based on allocated IRQs
>
> Long,
>
> On Tue, 23 Oct 2018, Long Li wrote:
>
> thanks for this patch.
>
> A trivial formal thing ahead. The subject line
>
>[PATCH] Choose CPU based on allocated IRQs
>
> is lacking a proper subsystem prefix. In most cases
> Subject: Re: [PATCH] Choose CPU based on allocated IRQs
>
> Long,
>
> On Tue, 23 Oct 2018, Long Li wrote:
>
> thanks for this patch.
>
> A trivial formal thing ahead. The subject line
>
>[PATCH] Choose CPU based on allocated IRQs
>
> is lacking a proper subsystem prefix. In most cases
On 10/22/18 5:30 AM, Kees Cook wrote:
> The arm compiler internally interprets an inline assembly label
> as an unsigned long value, not a pointer. As a result, under
> CONFIG_FORTIFY_SOURCE, the size of the array pointed to by an address
> of a label is 4 bytes, which was tripping the runtime
On 10/22/18 5:30 AM, Kees Cook wrote:
> The arm compiler internally interprets an inline assembly label
> as an unsigned long value, not a pointer. As a result, under
> CONFIG_FORTIFY_SOURCE, the size of the array pointed to by an address
> of a label is 4 bytes, which was tripping the runtime
Factor out the code to change index from x86_fsbase_write_cpu() and
x86_gsbase_write_cpu_inactive(). Now the code is located in
do_arch_prctl_64().
The helper functions that purport to write the base register should just
write the base register only. It shouldn't have magic optimizations to
Factor out the code to change index from x86_fsbase_write_cpu() and
x86_gsbase_write_cpu_inactive(). Now the code is located in
do_arch_prctl_64().
The helper functions that purport to write the base register should just
write the base register only. It shouldn't have magic optimizations to
Add device bindings for cpuidle states for cpu devices.
Cc:
Signed-off-by: Raju P.L.S.S.S.N
---
Changes in v2
- Address comments from Doug
---
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 62
1 file changed, 62 insertions(+)
diff --git
Add device bindings for cpuidle states for cpu devices.
Cc:
Signed-off-by: Raju P.L.S.S.S.N
---
Changes in v2
- Address comments from Doug
---
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 62
1 file changed, 62 insertions(+)
diff --git
On Tue, Oct 30, 2018 at 05:39:26PM +0100, Oleg Nesterov wrote:
> On 10/30, Oleg Nesterov wrote:
> >
> > On 10/30, Tycho Andersen wrote:
> > >
> > > @@ -828,6 +823,11 @@ static int __seccomp_filter(int this_syscall, const
> > > struct seccomp_data *sd,
> > >*/
> > > rmb();
> > >
> > > + if
On Tue, Oct 30, 2018 at 05:39:26PM +0100, Oleg Nesterov wrote:
> On 10/30, Oleg Nesterov wrote:
> >
> > On 10/30, Tycho Andersen wrote:
> > >
> > > @@ -828,6 +823,11 @@ static int __seccomp_filter(int this_syscall, const
> > > struct seccomp_data *sd,
> > >*/
> > > rmb();
> > >
> > > + if
Hi Greg,
On 10/30/2018 4:11 AM, Marc Zyngier wrote:
The Keystone QMSS driver is pretty damaged, in the sense that it
does things like this:
irq_set_affinity_hint(irq, to_cpumask(_map));
where cpu_map is a local variable. As we leave the function, this
will point to nowhere-land, and
Hi Greg,
On 10/30/2018 4:11 AM, Marc Zyngier wrote:
The Keystone QMSS driver is pretty damaged, in the sense that it
does things like this:
irq_set_affinity_hint(irq, to_cpumask(_map));
where cpu_map is a local variable. As we leave the function, this
will point to nowhere-land, and
Hi Arnd, Olof,
On 10/30/2018 4:11 AM, Marc Zyngier wrote:
The Keystone QMSS driver is pretty damaged, in the sense that it
does things like this:
irq_set_affinity_hint(irq, to_cpumask(_map));
where cpu_map is a local variable. As we leave the function, this
will point to nowhere-land,
Hi Arnd, Olof,
On 10/30/2018 4:11 AM, Marc Zyngier wrote:
The Keystone QMSS driver is pretty damaged, in the sense that it
does things like this:
irq_set_affinity_hint(irq, to_cpumask(_map));
where cpu_map is a local variable. As we leave the function, this
will point to nowhere-land,
10/30/2018 4:11 AM, Marc Zyngier wrote:
The Keystone QMSS driver is pretty damaged, in the sense that it
does things like this:
irq_set_affinity_hint(irq, to_cpumask(_map));
where cpu_map is a local variable. As we leave the function, this
will point to nowhere-land, and things will
10/30/2018 4:11 AM, Marc Zyngier wrote:
The Keystone QMSS driver is pretty damaged, in the sense that it
does things like this:
irq_set_affinity_hint(irq, to_cpumask(_map));
where cpu_map is a local variable. As we leave the function, this
will point to nowhere-land, and things will
On 10/30/18 4:11 AM, Marc Zyngier wrote:
> The Keystone QMSS driver is pretty damaged, in the sense that it
> does things like this:
>
> irq_set_affinity_hint(irq, to_cpumask(_map));
>
> where cpu_map is a local variable. As we leave the function, this
> will point to nowhere-land, and
On Tue, Oct 30, 2018 at 6:37 AM Steven Rostedt wrote:
>
> The biggest change here is the updates to kprobes
Pulled.
However, a little note:
> - Added support for SDT in uprobes
As an explanation, the above kind of sucks. "SDT"? I had to look it
up. I added a note to the commit message, but
On Tue, Oct 30, 2018 at 6:37 AM Steven Rostedt wrote:
>
> The biggest change here is the updates to kprobes
Pulled.
However, a little note:
> - Added support for SDT in uprobes
As an explanation, the above kind of sucks. "SDT"? I had to look it
up. I added a note to the commit message, but
On 10/30/18 4:11 AM, Marc Zyngier wrote:
> The Keystone QMSS driver is pretty damaged, in the sense that it
> does things like this:
>
> irq_set_affinity_hint(irq, to_cpumask(_map));
>
> where cpu_map is a local variable. As we leave the function, this
> will point to nowhere-land, and
On Tue, Oct 30, 2018 at 1:50 AM Daniel Colascione wrote:
>
> On Tue, Oct 30, 2018 at 3:21 AM, Joel Fernandes wrote:
> > On Mon, Oct 29, 2018 at 3:11 PM Daniel Colascione wrote:
> >>
> >> Add a simple proc-based kill interface. To use /proc/pid/kill, just
> >> write the signal number in base-10
On Tue, Oct 30, 2018 at 1:50 AM Daniel Colascione wrote:
>
> On Tue, Oct 30, 2018 at 3:21 AM, Joel Fernandes wrote:
> > On Mon, Oct 29, 2018 at 3:11 PM Daniel Colascione wrote:
> >>
> >> Add a simple proc-based kill interface. To use /proc/pid/kill, just
> >> write the signal number in base-10
On Sun, Oct 28, 2018 at 1:52 PM Jonathan Cameron wrote:
>
> On Fri, 26 Oct 2018 22:59:59 -0300
> Matheus Tavares wrote:
>
> > This patch set adds scale info to ad2s90's single channel, improve
> > error handling in it's functions and fix a possible race condition
> > issue.
> >
> > The goal with
On Sun, Oct 28, 2018 at 1:52 PM Jonathan Cameron wrote:
>
> On Fri, 26 Oct 2018 22:59:59 -0300
> Matheus Tavares wrote:
>
> > This patch set adds scale info to ad2s90's single channel, improve
> > error handling in it's functions and fix a possible race condition
> > issue.
> >
> > The goal with
Hello,
I have a client from Syrian who will like to invest with your
company. My client is willing to invest $4 Million. Can I have
your company website to show to my client your company so that
they will check and decide if they will invest there funds with
you as joint partner.
This
Hello,
I have a client from Syrian who will like to invest with your
company. My client is willing to invest $4 Million. Can I have
your company website to show to my client your company so that
they will check and decide if they will invest there funds with
you as joint partner.
This
On 30/10/2018 17:08, Julia Lawall wrote:
> Using devm_thermal_zone_of_sensor_register allows to simplify some
> error handling code, drop a label, and drop the remove function.
>
> Signed-off-by: Julia Lawall
Reviewed-by: Daniel Lezcano
> ---
>
> This patch is completely orthogonal to the
On 30/10/2018 17:08, Julia Lawall wrote:
> Using devm_thermal_zone_of_sensor_register allows to simplify some
> error handling code, drop a label, and drop the remove function.
>
> Signed-off-by: Julia Lawall
Reviewed-by: Daniel Lezcano
> ---
>
> This patch is completely orthogonal to the
Resending since I accidentally clicked back to HTML and lists all bounced. :(
On Tue, Oct 30, 2018 at 9:24 AM Raju P L S S S N wrote:
>
> On 10/24/2018 12:06 AM, Doug Anderson wrote:
> > Hi,
> >
> > On Mon, Oct 15, 2018 at 10:02 AM Raju P.L.S.S.S.N
> > wrote:
> >> + idle-states {
Resending since I accidentally clicked back to HTML and lists all bounced. :(
On Tue, Oct 30, 2018 at 9:24 AM Raju P L S S S N wrote:
>
> On 10/24/2018 12:06 AM, Doug Anderson wrote:
> > Hi,
> >
> > On Mon, Oct 15, 2018 at 10:02 AM Raju P.L.S.S.S.N
> > wrote:
> >> + idle-states {
On Tue, Oct 30, 2018 at 6:15 AM Steven Rostedt wrote:
>
> This is not my 4.20 pull request (that will be coming shortly). This
> is just some last minute fixes that Masami sent me that I finally got
> around to test.
Pulled. Real pull request is next,
Linus
On Tue, Oct 30, 2018 at 6:15 AM Steven Rostedt wrote:
>
> This is not my 4.20 pull request (that will be coming shortly). This
> is just some last minute fixes that Masami sent me that I finally got
> around to test.
Pulled. Real pull request is next,
Linus
On 10/29, Enke Chen wrote:
>
> Reviewed-by: Oleg Nesterov
Hmm. I didn't say this ;)
But OK, feel free to keep this tag.
I do not like this feauture. But I see no technical problems in this version
and I never pretented I understand the user-space needs, so I won't argue.
Oleg.
On 10/29, Enke Chen wrote:
>
> Reviewed-by: Oleg Nesterov
Hmm. I didn't say this ;)
But OK, feel free to keep this tag.
I do not like this feauture. But I see no technical problems in this version
and I never pretented I understand the user-space needs, so I won't argue.
Oleg.
Using devm_thermal_zone_of_sensor_register allows to simplify some
error handling code, drop a label, and drop the remove function.
Signed-off-by: Julia Lawall
---
This patch is completely orthogonal to the recent constification
patch.
drivers/thermal/broadcom/brcmstb_thermal.c | 24
Using devm_thermal_zone_of_sensor_register allows to simplify some
error handling code, drop a label, and drop the remove function.
Signed-off-by: Julia Lawall
---
This patch is completely orthogonal to the recent constification
patch.
drivers/thermal/broadcom/brcmstb_thermal.c | 24
Hi Vladimir,
On 08/10/18 23:12, Vladimir Zapolskiy wrote:
> From: Vladimir Zapolskiy
>
> TI DS90Ux9xx de-/serializers are capable to route I2C messages to
> I2C slave devices connected to a remote de-/serializer in a pair,
> the change adds description of device tree bindings of the
Hi Vladimir,
On 08/10/18 23:12, Vladimir Zapolskiy wrote:
> From: Vladimir Zapolskiy
>
> TI DS90Ux9xx de-/serializers are capable to route I2C messages to
> I2C slave devices connected to a remote de-/serializer in a pair,
> the change adds description of device tree bindings of the
On Thu, Oct 25, 2018 at 01:56:27PM -0500, Eric W. Biederman wrote:
> > Access to timerslack_ns is controlled by a process having CAP_SYS_NICE
> > in its effective capability set, but the current check looks in the root
> > namespace instead of the process' user namespace. Since a process is
> >
On Thu, Oct 25, 2018 at 01:56:27PM -0500, Eric W. Biederman wrote:
> > Access to timerslack_ns is controlled by a process having CAP_SYS_NICE
> > in its effective capability set, but the current check looks in the root
> > namespace instead of the process' user namespace. Since a process is
> >
On 10/30, Oleg Nesterov wrote:
>
> On 10/30, Tycho Andersen wrote:
> >
> > @@ -828,6 +823,11 @@ static int __seccomp_filter(int this_syscall, const
> > struct seccomp_data *sd,
> > */
> > rmb();
> >
> > + if (!sd) {
> > + populate_seccomp_data(_local);
> > + sd =
On 10/30, Oleg Nesterov wrote:
>
> On 10/30, Tycho Andersen wrote:
> >
> > @@ -828,6 +823,11 @@ static int __seccomp_filter(int this_syscall, const
> > struct seccomp_data *sd,
> > */
> > rmb();
> >
> > + if (!sd) {
> > + populate_seccomp_data(_local);
> > + sd =
On Sat, Oct 27, 2018 at 02:19:59AM +, Wei Yongjun wrote:
> sizeof() when applied to a pointer typed expression gives the
> size of the pointer, not that of the pointed data.
Someone else already sent a fix for this.
signature.asc
Description: PGP signature
On Sat, Oct 27, 2018 at 02:19:59AM +, Wei Yongjun wrote:
> sizeof() when applied to a pointer typed expression gives the
> size of the pointer, not that of the pointed data.
Someone else already sent a fix for this.
signature.asc
Description: PGP signature
Quoting Taniya Das (2018-10-29 23:01:44)
> On 10/30/2018 12:13 AM, Stephen Boyd wrote:
> > Quoting Taniya Das (2018-10-28 03:34:55)
> >> On 2018-10-19 16:04, Taniya Das wrote:
> >>> On 10/10/2018 2:04 AM, Stephen Boyd wrote:
> Quoting Taniya Das (2018-10-09 06:57:47)
> > diff --git
Quoting Taniya Das (2018-10-29 23:01:44)
> On 10/30/2018 12:13 AM, Stephen Boyd wrote:
> > Quoting Taniya Das (2018-10-28 03:34:55)
> >> On 2018-10-19 16:04, Taniya Das wrote:
> >>> On 10/10/2018 2:04 AM, Stephen Boyd wrote:
> Quoting Taniya Das (2018-10-09 06:57:47)
> > diff --git
On Mon, Oct 29, 2018 at 11:27 PM Peter Hutterer
wrote:
>
> Other issues I found with an MX Anywhere 2S is that on slow scroll and in
> ratchet mode we get some scroll jitter. In ratchet mode we can get this
> sequence if you scroll just past the notch and it snaps back:
> [1, 1, 1, 1, 1, 1,
On Mon, Oct 29, 2018 at 11:27 PM Peter Hutterer
wrote:
>
> Other issues I found with an MX Anywhere 2S is that on slow scroll and in
> ratchet mode we get some scroll jitter. In ratchet mode we can get this
> sequence if you scroll just past the notch and it snaps back:
> [1, 1, 1, 1, 1, 1,
On Tue, Oct 30, 2018 at 04:58:41PM +0100, Peter Zijlstra wrote:
> On Mon, Oct 29, 2018 at 11:17:14PM +0200, Igor Stoppa wrote:
> >
> >
> > On 25/10/2018 01:13, Peter Zijlstra wrote:
> > > On Wed, Oct 24, 2018 at 12:35:03AM +0300, Igor Stoppa wrote:
> > > > +static __always_inline
> > > > +bool
Thank you Juergen for your comments.
I will soon send v2 patch.
-Thanks,
Manjunath
On 10/30/2018 12:04 AM, Juergen Gross wrote:
On 29/10/2018 19:31, Manjunath Patil wrote:
info->nr_rings isn't adjusted in case of ENOMEM error from
negotiate_mq(). This leads to kernel panic in error path.
On Tue, Oct 30, 2018 at 04:58:41PM +0100, Peter Zijlstra wrote:
> On Mon, Oct 29, 2018 at 11:17:14PM +0200, Igor Stoppa wrote:
> >
> >
> > On 25/10/2018 01:13, Peter Zijlstra wrote:
> > > On Wed, Oct 24, 2018 at 12:35:03AM +0300, Igor Stoppa wrote:
> > > > +static __always_inline
> > > > +bool
Thank you Juergen for your comments.
I will soon send v2 patch.
-Thanks,
Manjunath
On 10/30/2018 12:04 AM, Juergen Gross wrote:
On 29/10/2018 19:31, Manjunath Patil wrote:
info->nr_rings isn't adjusted in case of ENOMEM error from
negotiate_mq(). This leads to kernel panic in error path.
On 10/30, Tycho Andersen wrote:
>
> @@ -828,6 +823,11 @@ static int __seccomp_filter(int this_syscall, const
> struct seccomp_data *sd,
>*/
> rmb();
>
> + if (!sd) {
> + populate_seccomp_data(_local);
> + sd = _local;
> + }
> +
To me it would be
On 10/30/18 11:02 AM, Hans de Goede wrote:
Hi,
On 30-10-18 16:46, Hans de Goede wrote:
Hi,
On 30-10-18 16:04, Pierre-Louis Bossart wrote:
On 10/30/18 9:38 AM, Dean Wallace wrote:
On 30-10-18, Hans de Goede wrote:
Hi Dean,
Attached are 2 different attempts at fixing this.
When trying
On 10/30, Tycho Andersen wrote:
>
> @@ -828,6 +823,11 @@ static int __seccomp_filter(int this_syscall, const
> struct seccomp_data *sd,
>*/
> rmb();
>
> + if (!sd) {
> + populate_seccomp_data(_local);
> + sd = _local;
> + }
> +
To me it would be
On 10/30/18 11:02 AM, Hans de Goede wrote:
Hi,
On 30-10-18 16:46, Hans de Goede wrote:
Hi,
On 30-10-18 16:04, Pierre-Louis Bossart wrote:
On 10/30/18 9:38 AM, Dean Wallace wrote:
On 30-10-18, Hans de Goede wrote:
Hi Dean,
Attached are 2 different attempts at fixing this.
When trying
During simultaneous running of playback and capture, we
got hit by incorrect value write on common register. This was due
to race condition between 2 streams.
Fixing this by locking the common register access.
Signed-off-by: Akshu Agrawal
---
v2: Added 2 helper functions, removed locking in ch
During simultaneous running of playback and capture, we
got hit by incorrect value write on common register. This was due
to race condition between 2 streams.
Fixing this by locking the common register access.
Signed-off-by: Akshu Agrawal
---
v2: Added 2 helper functions, removed locking in ch
Quoting wang.y...@zte.com.cn (2018-10-29 23:13:24)
> > Quoting Yi Wang (2018-10-29 01:31:47)
> > > 'onecell' is malloced in clk_boston_setup(), but is not freed
> > > before leaving from the error handling cases.
> >
> > How did you find this? Visual inspection? Some coccinelle script?
>
> Smatch
Quoting wang.y...@zte.com.cn (2018-10-29 23:13:24)
> > Quoting Yi Wang (2018-10-29 01:31:47)
> > > 'onecell' is malloced in clk_boston_setup(), but is not freed
> > > before leaving from the error handling cases.
> >
> > How did you find this? Visual inspection? Some coccinelle script?
>
> Smatch
On Tue, Oct 30, 2018 at 1:05 PM Hans de Goede wrote:
> for i in /sys/kernel/debug/clk/pmc_plt_clk_?; do echo -n "$i: "; cat
> $i/clk_flags; echo; done
Just a side note about nice tool, called `grep` :-)
grep -H . /sys/kernel/debug/clk/pmc_plt_clk_*/clk_flags
does above in one call.
--
With
On Tue, Oct 30, 2018 at 1:05 PM Hans de Goede wrote:
> for i in /sys/kernel/debug/clk/pmc_plt_clk_?; do echo -n "$i: "; cat
> $i/clk_flags; echo; done
Just a side note about nice tool, called `grep` :-)
grep -H . /sys/kernel/debug/clk/pmc_plt_clk_*/clk_flags
does above in one call.
--
With
On 10/24/2018 12:06 AM, Doug Anderson wrote:
Hi,
On Mon, Oct 15, 2018 at 10:02 AM Raju P.L.S.S.S.N
wrote:
+ idle-states {
+ entry-method = "psci";
+
+ C0_CPU_SPC: c0_spc {
nit: all these nodes should have dashes instead of spaces
On 10/24/2018 12:06 AM, Doug Anderson wrote:
Hi,
On Mon, Oct 15, 2018 at 10:02 AM Raju P.L.S.S.S.N
wrote:
+ idle-states {
+ entry-method = "psci";
+
+ C0_CPU_SPC: c0_spc {
nit: all these nodes should have dashes instead of spaces
Hi,
On Tue, 2018-10-30 at 18:00 +0200, Igor Stoppa wrote:
> Hi,
> I'm getting the following build error:
>
> /home/igor/dev/kernel/linux/drivers/cpufreq/intel_pstate.c: In
> function
> ‘show_base_frequency’:
> /home/igor/dev/kernel/linux/drivers/cpufreq/intel_pstate.c:726:10:
> error: implicit
Hi,
On Tue, 2018-10-30 at 18:00 +0200, Igor Stoppa wrote:
> Hi,
> I'm getting the following build error:
>
> /home/igor/dev/kernel/linux/drivers/cpufreq/intel_pstate.c: In
> function
> ‘show_base_frequency’:
> /home/igor/dev/kernel/linux/drivers/cpufreq/intel_pstate.c:726:10:
> error: implicit
On 30/10/2018 16:15, Julia Lawall wrote:
> The thermal_zone_of_device_ops structure can be const as it is only
> passed as the last argument of thermal_zone_of_sensor_register
> and the corresponding parameter is declared as const.
>
> Done with the help of Coccinelle.
>
> Signed-off-by: Julia
On 30/10/2018 16:15, Julia Lawall wrote:
> The thermal_zone_of_device_ops structure can be const as it is only
> passed as the last argument of thermal_zone_of_sensor_register
> and the corresponding parameter is declared as const.
>
> Done with the help of Coccinelle.
>
> Signed-off-by: Julia
On 30/10/2018 16:14, Julia Lawall wrote:
> The thermal_zone_of_device_ops structure can be const as it is only
> passed as the last argument of devm_thermal_zone_of_sensor_register
> and the corresponding parameter is declared as const.
>
> Done with the help of Coccinelle.
>
> Signed-off-by:
On 30/10/2018 16:14, Julia Lawall wrote:
> The thermal_zone_of_device_ops structure can be const as it is only
> passed as the last argument of devm_thermal_zone_of_sensor_register
> and the corresponding parameter is declared as const.
>
> Done with the help of Coccinelle.
>
> Signed-off-by:
On 10/29/2018 11:45 PM, Bjorn Andersson wrote:
GPIOs 0 through 3 and 81 through 84 are configured to not be accessible
from the application CPUs. Mark them as reserved to allow the MSM8998
MTP to boot after the introduction of 3edfb7bd76bd ("gpiolib: Show
correct direction from the beginning").
On 10/29/2018 11:45 PM, Bjorn Andersson wrote:
GPIOs 0 through 3 and 81 through 84 are configured to not be accessible
from the application CPUs. Mark them as reserved to allow the MSM8998
MTP to boot after the introduction of 3edfb7bd76bd ("gpiolib: Show
correct direction from the beginning").
On Tue, Oct 30, 2018 at 1:30 AM Rafael J. Wysocki wrote:
>
> These rework the handling of the P-unit semaphore on Intel
> Baytrail and Cherrytrail systems to avoid race conditions and
> excessive overhead related to it (Hans de Goede).
Pulled,
Linus
On Tue, Oct 30, 2018 at 1:30 AM Rafael J. Wysocki wrote:
>
> These rework the handling of the P-unit semaphore on Intel
> Baytrail and Cherrytrail systems to avoid race conditions and
> excessive overhead related to it (Hans de Goede).
Pulled,
Linus
I guess it being an example doesn't make it strictly a recommendation, but
I wonder if we should avoid giving examples that use mappings which we
discourage.
Well, yes, that is example for top0 – but I agree, giving examples that
do not make much sense is not very productive.
So currently
I guess it being an example doesn't make it strictly a recommendation, but
I wonder if we should avoid giving examples that use mappings which we
discourage.
Well, yes, that is example for top0 – but I agree, giving examples that
do not make much sense is not very productive.
So currently
On 30-10-18, Hans de Goede wrote:
> Hi,
>
> On 30-10-18 16:46, Hans de Goede wrote:
> > Hi,
> >
> > On 30-10-18 16:04, Pierre-Louis Bossart wrote:
> > > In addition I am not aware of any baytrail device using plt_clk_0,
> > > so moving a common machine driver such a cht_bsw_max98090_ti to use
>
On 30-10-18, Hans de Goede wrote:
> Hi,
>
> On 30-10-18 16:46, Hans de Goede wrote:
> > Hi,
> >
> > On 30-10-18 16:04, Pierre-Louis Bossart wrote:
> > > In addition I am not aware of any baytrail device using plt_clk_0,
> > > so moving a common machine driver such a cht_bsw_max98090_ti to use
>
A ~10% regression has been reported for UnixBench's execl throughput
test:
Message-ID: <20180402032000.GD3101@yexl-desktop>
Message-ID: <20181024064100.ga27...@intel.com>
That test is pretty simple, it does a "recursive" execve syscall on the
same binary. Starting from the syscall, this
A ~10% regression has been reported for UnixBench's execl throughput
test:
Message-ID: <20180402032000.GD3101@yexl-desktop>
Message-ID: <20181024064100.ga27...@intel.com>
That test is pretty simple, it does a "recursive" execve syscall on the
same binary. Starting from the syscall, this
401 - 500 of 1220 matches
Mail list logo
