Adds comments explaining what are the spinlock and mutex used for.
Signed-off-by: Leonardo Brás
---
drivers/staging/fbtft/fbtft.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h
index
Adds comments explaining what are the spinlock and mutex used for.
Signed-off-by: Leonardo Brás
---
drivers/staging/fbtft/fbtft.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h
index
On 2018-08-06 01:53, Rafael J. Wysocki wrote:
On Fri, Aug 3, 2018 at 12:20 AM, Sodagudi Prasad
wrote:
From: RAFAEL J. WYSOCKI
Date: Wed, Aug 1, 2018 at 2:21 PM
Subject: Re: [PATCH] dd: Invoke one probe retry cycle after every
initcall level
To: Rishabh Bhatnagar
Cc: "Rafael J. Wysocki" ,
On 2018-08-06 01:53, Rafael J. Wysocki wrote:
On Fri, Aug 3, 2018 at 12:20 AM, Sodagudi Prasad
wrote:
From: RAFAEL J. WYSOCKI
Date: Wed, Aug 1, 2018 at 2:21 PM
Subject: Re: [PATCH] dd: Invoke one probe retry cycle after every
initcall level
To: Rishabh Bhatnagar
Cc: "Rafael J. Wysocki" ,
On Thu, Aug 09 2018, J. Bruce Fields wrote:
> On Thu, Aug 09, 2018 at 12:04:41PM +1000, NeilBrown wrote:
>> When we find an existing lock which conflicts with a request,
>> and the request wants to wait, we currently add the request
>> to a list. When the lock is removed, the whole list is
On Thu, Aug 09 2018, J. Bruce Fields wrote:
> On Thu, Aug 09, 2018 at 12:04:41PM +1000, NeilBrown wrote:
>> When we find an existing lock which conflicts with a request,
>> and the request wants to wait, we currently add the request
>> to a list. When the lock is removed, the whole list is
2018-08-10 5:05 GMT+08:00 Tyler Baicar :
> On Thu, Aug 9, 2018 at 8:32 AM, gengdongjiu wrote:
>>
>> 2018-08-08 0:26 GMT+08:00 Dongjiu Geng :
>> > In order to remove the additional check before calling the
>> > ghes_notify_sea(), make stub definition when !CONFIG_ACPI_APEI_SEA.
>> >
>> > After
2018-08-10 5:05 GMT+08:00 Tyler Baicar :
> On Thu, Aug 9, 2018 at 8:32 AM, gengdongjiu wrote:
>>
>> 2018-08-08 0:26 GMT+08:00 Dongjiu Geng :
>> > In order to remove the additional check before calling the
>> > ghes_notify_sea(), make stub definition when !CONFIG_ACPI_APEI_SEA.
>> >
>> > After
Hi Stephen,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.18-rc8 next-20180809]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
Hi Stephen,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.18-rc8 next-20180809]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
On Thu, Aug 09 2018, J. Bruce Fields wrote:
> I think there's also a problem with multiple tasks sharing the same
> lock owner.
>
> So, all locks are exclusive locks for the same range. We have four
> tasks. Tasks 1 and 4 share the same owner, the others' owners are
> distinct.
>
> - Task
On Thu, Aug 09 2018, J. Bruce Fields wrote:
> I think there's also a problem with multiple tasks sharing the same
> lock owner.
>
> So, all locks are exclusive locks for the same range. We have four
> tasks. Tasks 1 and 4 share the same owner, the others' owners are
> distinct.
>
> - Task
We just found that you need image editing.
We are an image studio, we do all kinds of image editing such as for
e-commerce photos, jewelry images
and portrait mages.
Our service includes cutting out and clipping path etc , we also do
retouching.
You may send us a photo, testing will be
We just found that you need image editing.
We are an image studio, we do all kinds of image editing such as for
e-commerce photos, jewelry images
and portrait mages.
Our service includes cutting out and clipping path etc , we also do
retouching.
You may send us a photo, testing will be
Quoting Julius Werner (2018-08-09 11:24:29)
> One thing to note is that we still want this space to be mappable by
> userspace applications via /dev/mem, so we need to make sure that
> there's no weird memory type mismatch that causes problems with that.
> Adding Aaron to see if he has any
Quoting Julius Werner (2018-08-09 11:24:29)
> One thing to note is that we still want this space to be mappable by
> userspace applications via /dev/mem, so we need to make sure that
> there's no weird memory type mismatch that causes problems with that.
> Adding Aaron to see if he has any
From: Rajendra Nayak
Add a few missing gcc clks for msm8996
Signed-off-by: Rajendra Nayak
[bjorn: omit aggre0_noc_qosgen_extref_clk]
Signed-off-by: Bjorn Andersson
---
Changes since v1:
- Dropped LPASS SMMU clocks already introduced by Srinivas
drivers/clk/qcom/gcc-msm8996.c
From: Rajendra Nayak
Add a few missing gcc clks for msm8996
Signed-off-by: Rajendra Nayak
[bjorn: omit aggre0_noc_qosgen_extref_clk]
Signed-off-by: Bjorn Andersson
---
Changes since v1:
- Dropped LPASS SMMU clocks already introduced by Srinivas
drivers/clk/qcom/gcc-msm8996.c
Hi!
> > Following node would describe strings connected to the outputs
> > HVLED1 and HVLED2 controlled by bank A.
> >
> > led@0 {
> > reg = <0>;
> > led-sources = <0>. <1>;
> > label = "white:first_backlight_cluster";
> > linux,default-trigger = "backlight";
> > };
> >
> >
> >
Hi!
> > Following node would describe strings connected to the outputs
> > HVLED1 and HVLED2 controlled by bank A.
> >
> > led@0 {
> > reg = <0>;
> > led-sources = <0>. <1>;
> > label = "white:first_backlight_cluster";
> > linux,default-trigger = "backlight";
> > };
> >
> >
> >
On Tuesday, July 24, 2018 2:25:10 PM CEST Quentin Perret wrote:
> Several subsystems in the kernel (task scheduler and/or thermal at the
> time of writing) can benefit from knowing about the energy consumed by
> CPUs. Yet, this information can come from different sources (DT or
> firmware for
On Tuesday, July 24, 2018 2:25:10 PM CEST Quentin Perret wrote:
> Several subsystems in the kernel (task scheduler and/or thermal at the
> time of writing) can benefit from knowing about the energy consumed by
> CPUs. Yet, this information can come from different sources (DT or
> firmware for
The argument to nsinfo__copy() was assumed to be valid, but some code paths
exist that will lead to NULL being passed.
In particular, running 'perf script -D' on a perf.data file containing an
PERF_RECORD_MMAP event associating the '[vdso]' dso with pid 0 earlier in
the event stream will lead to
The argument to nsinfo__copy() was assumed to be valid, but some code paths
exist that will lead to NULL being passed.
In particular, running 'perf script -D' on a perf.data file containing an
PERF_RECORD_MMAP event associating the '[vdso]' dso with pid 0 earlier in
the event stream will lead to
On Thu, Aug 09, 2018 at 05:45:38PM +0300, Abel Vesa wrote:
> From: Lucas Stach
>
> This adds the binding for the i.MX8MQ Clock Controller Module.
>
> Signed-off-by: Lucas Stach
> Signed-off-by: Abel Vesa
> ---
> .../devicetree/bindings/clock/imx8mq-clock.txt | 20 +
>
On Thu, Aug 09, 2018 at 05:45:38PM +0300, Abel Vesa wrote:
> From: Lucas Stach
>
> This adds the binding for the i.MX8MQ Clock Controller Module.
>
> Signed-off-by: Lucas Stach
> Signed-off-by: Abel Vesa
> ---
> .../devicetree/bindings/clock/imx8mq-clock.txt | 20 +
>
On Tue, Aug 07, 2018 at 05:52:16PM +0300, Stefan Popa wrote:
> Add the device tree binding documentation for the ADXL372 3-axis digital
> accelerometer.
>
> Signed-off-by: Stefan Popa
> ---
> .../devicetree/bindings/iio/accel/adxl372.txt | 22
> ++
> MAINTAINERS
On Tue, Aug 07, 2018 at 05:52:16PM +0300, Stefan Popa wrote:
> Add the device tree binding documentation for the ADXL372 3-axis digital
> accelerometer.
>
> Signed-off-by: Stefan Popa
> ---
> .../devicetree/bindings/iio/accel/adxl372.txt | 22
> ++
> MAINTAINERS
On Thursday, August 9, 2018 6:43:55 PM CEST Rafael J. Wysocki wrote:
> On Thu, Aug 9, 2018 at 6:29 PM, wrote:
> > On Thu, Aug 09, 2018 at 05:42:30PM +0200, Rafael J. Wysocki wrote:
> >
> > [...]
> >
> >> >> This issue can be easily reproduce with the case on Arm Hikey board: use
> >> >> CPU0 to
On Thursday, August 9, 2018 6:43:55 PM CEST Rafael J. Wysocki wrote:
> On Thu, Aug 9, 2018 at 6:29 PM, wrote:
> > On Thu, Aug 09, 2018 at 05:42:30PM +0200, Rafael J. Wysocki wrote:
> >
> > [...]
> >
> >> >> This issue can be easily reproduce with the case on Arm Hikey board: use
> >> >> CPU0 to
Hi,
On Tue, Jul 31, 2018 at 11:59 AM, Matthias Kaehlcke wrote:
> There are three thermal stages defined in the PMIC:
>
> stage 1: warning
> stage 2: system should shut down
> stage 3: emergency shut down
>
> By default the PMIC assumes that the OS isn't doing anything and thus
> at stage 2 it
Hi,
On Tue, Jul 31, 2018 at 11:59 AM, Matthias Kaehlcke wrote:
> There are three thermal stages defined in the PMIC:
>
> stage 1: warning
> stage 2: system should shut down
> stage 3: emergency shut down
>
> By default the PMIC assumes that the OS isn't doing anything and thus
> at stage 2 it
On Thu, Aug 09, 2018 at 01:25:24PM -0700, Palmer Dabbelt wrote:
> This file is expected to be included multiple times in the same file in
> order to allow the __SYSCALL macro to generate system call tables. With
> a global include guard we end up missing __NR_riscv_flush_icache in the
> syscall
On Thu, Aug 09, 2018 at 01:25:24PM -0700, Palmer Dabbelt wrote:
> This file is expected to be included multiple times in the same file in
> order to allow the __SYSCALL macro to generate system call tables. With
> a global include guard we end up missing __NR_riscv_flush_icache in the
> syscall
On Thu, Aug 09, 2018 at 01:25:23PM -0700, Palmer Dabbelt wrote:
> This would be necessary to make non-SMP builds work, but there is
> another error in the implementation of our syscall linkage that actually
> just causes sys_riscv_flush_icache to never build. I've build tested
> this on
On Thu, Aug 09, 2018 at 01:25:23PM -0700, Palmer Dabbelt wrote:
> This would be necessary to make non-SMP builds work, but there is
> another error in the implementation of our syscall linkage that actually
> just causes sys_riscv_flush_icache to never build. I've build tested
> this on
On Thu, Aug 09, 2018 at 06:02:42PM +0530, Amit Kucheria wrote:
> Create an entry for the TSENS drivers and mark them as maintained
>
> Signed-off-by: Amit Kucheria
> ---
> MAINTAINERS | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index
On Thu, Aug 09, 2018 at 06:02:42PM +0530, Amit Kucheria wrote:
> Create an entry for the TSENS drivers and mark them as maintained
>
> Signed-off-by: Amit Kucheria
> ---
> MAINTAINERS | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index
On Thu, Aug 9, 2018 at 10:17 AM Stephen Boyd wrote:
>
> Call request_mem_region() on the entire coreboot table to make sure
> other devices don't attempt to map the coreboot table in their drivers.
> If drivers need that support, it would be better to provide bus APIs
> they can use to do that
On Thu, Aug 9, 2018 at 10:17 AM Stephen Boyd wrote:
>
> Call request_mem_region() on the entire coreboot table to make sure
> other devices don't attempt to map the coreboot table in their drivers.
> If drivers need that support, it would be better to provide bus APIs
> they can use to do that
From: "Steven Rostedt (VMware)"
Joel Fernandes created a nice patch that cleaned up the duplicate hooks used
by lockdep and irqsoff latency tracer. It made both use tracepoints. But it
caused lockdep to trigger several false positives. We have not figured out
why yet, but removing lockdep from
From: "Steven Rostedt (VMware)"
Joel Fernandes created a nice patch that cleaned up the duplicate hooks used
by lockdep and irqsoff latency tracer. It made both use tracepoints. But it
caused lockdep to trigger several false positives. We have not figured out
why yet, but removing lockdep from
Joel,
These are the last minute updates I have on top of your changes.
A couple of them I may have already posted to you. I'm trying to
get my tests to all pass without errors or new warnings. My tests
are still running, and hopefully this will have all the fixes.
-- Steve
From: "Steven Rostedt (VMware)"
I was hitting the following warning:
WARNING: CPU: 0 PID: 1 at kernel/trace/trace_irqsoff.c:631
tracer_hardirqs_off+0x15/0x2a
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.0-rc6-test+ #13
Hardware name: MSI MS-7823/CSM-H87M-G43 (MS-7823),
From: Colin Ian King
Pointer ftrace_swapper_pid is defined but is never used hence it is
redundant and can be removed. The use of this variable was removed
in commit 345ddcc882d8 ("ftrace: Have set_ftrace_pid use the bitmap
like events do").
Cleans up clang warning:
warning:
Joel,
These are the last minute updates I have on top of your changes.
A couple of them I may have already posted to you. I'm trying to
get my tests to all pass without errors or new warnings. My tests
are still running, and hopefully this will have all the fixes.
-- Steve
From: "Steven Rostedt (VMware)"
I was hitting the following warning:
WARNING: CPU: 0 PID: 1 at kernel/trace/trace_irqsoff.c:631
tracer_hardirqs_off+0x15/0x2a
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.0-rc6-test+ #13
Hardware name: MSI MS-7823/CSM-H87M-G43 (MS-7823),
From: Colin Ian King
Pointer ftrace_swapper_pid is defined but is never used hence it is
redundant and can be removed. The use of this variable was removed
in commit 345ddcc882d8 ("ftrace: Have set_ftrace_pid use the bitmap
like events do").
Cleans up clang warning:
warning:
From: "Steven Rostedt (VMware)"
Now that some trace events can be protected by srcu_read_lock(tracepoint_srcu),
we need to make sure all locations that depend on this are also protected.
There were many places that did a synchronize_sched() thinking that it was
enough to protect againts access
From: "Steven Rostedt (VMware)"
Joel Fernandes created a nice patch that cleaned up the duplicate hooks used
by lockdep and irqsoff latency tracer. It made both use tracepoints. But the
latency tracer is triggering warnings when using tracepoints to call into
the latency tracer's routines.
From: "Steven Rostedt (VMware)"
While debugging another bug, I was looking at all the synchronize*()
functions being used in kernel/trace, and noticed that trace_uprobes was
using synchronize_sched(), with a comment to synchronize with
{u,ret}_probe_trace_func(). When looking at those functions,
From: "Steven Rostedt (VMware)"
While debugging another bug, I was looking at all the synchronize*()
functions being used in kernel/trace, and noticed that trace_uprobes was
using synchronize_sched(), with a comment to synchronize with
{u,ret}_probe_trace_func(). When looking at those functions,
From: "Steven Rostedt (VMware)"
Now that some trace events can be protected by srcu_read_lock(tracepoint_srcu),
we need to make sure all locations that depend on this are also protected.
There were many places that did a synchronize_sched() thinking that it was
enough to protect againts access
From: "Steven Rostedt (VMware)"
Joel Fernandes created a nice patch that cleaned up the duplicate hooks used
by lockdep and irqsoff latency tracer. It made both use tracepoints. But the
latency tracer is triggering warnings when using tracepoints to call into
the latency tracer's routines.
On Thu, Aug 9, 2018 at 7:20 PM, Leo Yan wrote:
> If the idle duration predictor detects the tick is triggered, and with
> meeting the condition 'data->next_timer_us > TICK_USEC', it will give a
> big compensation for the 'measured' interval; this is purposed to avoid
> artificially small
On Thu, Aug 9, 2018 at 7:20 PM, Leo Yan wrote:
> If the idle duration predictor detects the tick is triggered, and with
> meeting the condition 'data->next_timer_us > TICK_USEC', it will give a
> big compensation for the 'measured' interval; this is purposed to avoid
> artificially small
On Thu, Aug 09, 2018 at 06:02:41PM +0530, Amit Kucheria wrote:
> Instead of showing up as thermal-sensor@, the nodes will show up as
> tsens0_tm, tsen1_tm, tsens1_srot, etc. in /proc/iomem making it easier to
> read.
>
> IOW,
>
> 0c222000-0c2221fe : thermal-sensor@c263000
> 0c223000-0c2231fe :
On Thu, Aug 09, 2018 at 06:02:41PM +0530, Amit Kucheria wrote:
> Instead of showing up as thermal-sensor@, the nodes will show up as
> tsens0_tm, tsen1_tm, tsens1_srot, etc. in /proc/iomem making it easier to
> read.
>
> IOW,
>
> 0c222000-0c2221fe : thermal-sensor@c263000
> 0c223000-0c2231fe :
On 2018/08/10 0:07, Michal Hocko wrote:
> On Thu 09-08-18 22:57:43, Tetsuo Handa wrote:
>> >From b1f38168f14397c7af9c122cd8207663d96e02ec Mon Sep 17 00:00:00 2001
>> From: Tetsuo Handa
>> Date: Thu, 9 Aug 2018 22:49:40 +0900
>> Subject: [PATCH] mm, oom: task_will_free_mem(current) should retry
On 2018/08/10 0:07, Michal Hocko wrote:
> On Thu 09-08-18 22:57:43, Tetsuo Handa wrote:
>> >From b1f38168f14397c7af9c122cd8207663d96e02ec Mon Sep 17 00:00:00 2001
>> From: Tetsuo Handa
>> Date: Thu, 9 Aug 2018 22:49:40 +0900
>> Subject: [PATCH] mm, oom: task_will_free_mem(current) should retry
On Thu, Aug 9, 2018 at 10:17 AM Stephen Boyd wrote:
>
> This function checks the header for sanity, registers a bus, and
> populates devices for each coreboot table entry. Let's just populate
> devices here and pull the other bits up into the caller so that this
> function can be repurposed for
On Thu, Aug 9, 2018 at 10:17 AM Stephen Boyd wrote:
>
> This function checks the header for sanity, registers a bus, and
> populates devices for each coreboot table entry. Let's just populate
> devices here and pull the other bits up into the caller so that this
> function can be repurposed for
On Wed, 08 Aug 2018 22:58:30 PDT (-0700), Christoph Hellwig wrote:
This actually seems to break the compilation for me in for-next:
hch@carbon:~/work/linux$ make ARCH=riscv
CALLscripts/checksyscalls.sh
:1335:2: warning: #warning syscall rseq not implemented [-Wcpp]
CHK
On Wed, 08 Aug 2018 22:58:30 PDT (-0700), Christoph Hellwig wrote:
This actually seems to break the compilation for me in for-next:
hch@carbon:~/work/linux$ make ARCH=riscv
CALLscripts/checksyscalls.sh
:1335:2: warning: #warning syscall rseq not implemented [-Wcpp]
CHK
On Thu, 09 Aug 2018 06:26:12 PDT (-0700), li...@roeck-us.net wrote:
On Fri, Aug 03, 2018 at 12:53:44PM -0700, Palmer Dabbelt wrote:
This file is expected to be included multiple times in the same file in
order to allow the __SYSCALL macro to generate system call tables. With
a global include
On Thu, 09 Aug 2018 06:26:12 PDT (-0700), li...@roeck-us.net wrote:
On Fri, Aug 03, 2018 at 12:53:44PM -0700, Palmer Dabbelt wrote:
This file is expected to be included multiple times in the same file in
order to allow the __SYSCALL macro to generate system call tables. With
a global include
On Thu, Aug 09, 2018 at 06:02:40PM +0530, Amit Kucheria wrote:
> The hw_id field in 'struct tsens_sensor' can do the job of tracking
> unique ids for each sensor connected to each tsens device instance. It
> also allows hw_ids to be overridden (e.g. 8916) in cases where some
> sensors in a
On Thu, Aug 09, 2018 at 06:02:40PM +0530, Amit Kucheria wrote:
> The hw_id field in 'struct tsens_sensor' can do the job of tracking
> unique ids for each sensor connected to each tsens device instance. It
> also allows hw_ids to be overridden (e.g. 8916) in cases where some
> sensors in a
On Thu, Aug 09, 2018 at 12:58:21PM -0400, Jerome Glisse wrote:
> > I would really prefer to be explicit about these requirements rather
> > than having subtle side effects quite deep in the memory hotplug code
> > and checks for zone device sprinkled at places for special handling.
>
> I agree, i
On Thu, Aug 09, 2018 at 12:58:21PM -0400, Jerome Glisse wrote:
> > I would really prefer to be explicit about these requirements rather
> > than having subtle side effects quite deep in the memory hotplug code
> > and checks for zone device sprinkled at places for special handling.
>
> I agree, i
Devicetree bindings should be their own patch as documented in
Documentation/devicetree/bindings/submitting-patches.txt section I.1.
This is because bindings are logically independent from a driver
implementation, they have a different maintainer (even though they often
are applied via the same
Devicetree bindings should be their own patch as documented in
Documentation/devicetree/bindings/submitting-patches.txt section I.1.
This is because bindings are logically independent from a driver
implementation, they have a different maintainer (even though they often
are applied via the same
On Thu, Aug 9, 2018 at 7:20 PM, Leo Yan wrote:
> The criteria for keeping tick running is the prediction duration is less
> than TICK_USEC,
Yes, because if the predicted idle duration is less than the tick
period, stopping the tick is pointless overhead (if the governor
predicts a CPU wakeup
On Thu, Aug 9, 2018 at 7:20 PM, Leo Yan wrote:
> The criteria for keeping tick running is the prediction duration is less
> than TICK_USEC,
Yes, because if the predicted idle duration is less than the tick
period, stopping the tick is pointless overhead (if the governor
predicts a CPU wakeup
It turns out that we weren't actually hooking sys_riscv_flush_icache
into the syscall table, which results in any flush_icache() call that
escapes the vDSO to silently do nothing.
Changes since v1:
* sys_riscv_flush_icache is now defined even when SMP=n, which allows
this patch set to build
This would be necessary to make non-SMP builds work, but there is
another error in the implementation of our syscall linkage that actually
just causes sys_riscv_flush_icache to never build. I've build tested
this on allnoconfig and allnoconfig+SMP=y, as well as defconfig like
normal.
CC:
It turns out that we weren't actually hooking sys_riscv_flush_icache
into the syscall table, which results in any flush_icache() call that
escapes the vDSO to silently do nothing.
Changes since v1:
* sys_riscv_flush_icache is now defined even when SMP=n, which allows
this patch set to build
This would be necessary to make non-SMP builds work, but there is
another error in the implementation of our syscall linkage that actually
just causes sys_riscv_flush_icache to never build. I've build tested
this on allnoconfig and allnoconfig+SMP=y, as well as defconfig like
normal.
CC:
This file is expected to be included multiple times in the same file in
order to allow the __SYSCALL macro to generate system call tables. With
a global include guard we end up missing __NR_riscv_flush_icache in the
syscall table, which results in icache flushes that escape the vDSO call
to not
This file is expected to be included multiple times in the same file in
order to allow the __SYSCALL macro to generate system call tables. With
a global include guard we end up missing __NR_riscv_flush_icache in the
syscall table, which results in icache flushes that escape the vDSO call
to not
On Thu, Aug 09, 2018 at 06:02:39PM +0530, Amit Kucheria wrote:
> The SROT registers are initialised by the secure firmware at boot. We
> don't have write access to the registers. Check if the block is enabled
> before continuing.
>
> Signed-off-by: Amit Kucheria
> ---
>
On Thu, Aug 09, 2018 at 06:02:39PM +0530, Amit Kucheria wrote:
> The SROT registers are initialised by the secure firmware at boot. We
> don't have write access to the registers. Check if the block is enabled
> before continuing.
>
> Signed-off-by: Amit Kucheria
> ---
>
GCC considers the number of statements in inlined assembly blocks,
according to new-lines and semicolons, as an indication to the cost of
the block in time and space. This data is distorted by the kernel code,
which puts information in alternative sections. As a result, the
compiler may perform
GCC considers the number of statements in inlined assembly blocks,
according to new-lines and semicolons, as an indication to the cost of
the block in time and space. This data is distorted by the kernel code,
which puts information in alternative sections. As a result, the
compiler may perform
GCC considers the number of statements in inlined assembly blocks,
according to new-lines and semicolons, as an indication to the cost of
the block in time and space. This data is distorted by the kernel code,
which puts information in alternative sections. As a result, the
compiler may perform
GCC considers the number of statements in inlined assembly blocks,
according to new-lines and semicolons, as an indication to the cost of
the block in time and space. This data is distorted by the kernel code,
which puts information in alternative sections. As a result, the
compiler may perform
On 08/09/2018 04:17 AM, David Hildenbrand wrote:
On 08.08.2018 16:44, Tony Krowiak wrote:
From: Tony Krowiak
Introduces a new CPU model feature and two CPU model
facilities to support AP virtualization for KVM guests.
CPU model feature:
The KVM_S390_VM_CPU_FEAT_AP feature indicates that
AP
On 08/09/2018 04:17 AM, David Hildenbrand wrote:
On 08.08.2018 16:44, Tony Krowiak wrote:
From: Tony Krowiak
Introduces a new CPU model feature and two CPU model
facilities to support AP virtualization for KVM guests.
CPU model feature:
The KVM_S390_VM_CPU_FEAT_AP feature indicates that
AP
On Thu, Aug 9, 2018 at 1:15 PM, Nadav Amit wrote:
> Defining the LINKER_SCRIPT when building the linker script as being done
> in other architectures. This is required for the next Makefile changes
> would otherwise break things.
>
> Cc: Chris Zankel
> Cc: Max Filippov
> Cc:
On Thu, Aug 9, 2018 at 1:15 PM, Nadav Amit wrote:
> Defining the LINKER_SCRIPT when building the linker script as being done
> in other architectures. This is required for the next Makefile changes
> would otherwise break things.
>
> Cc: Chris Zankel
> Cc: Max Filippov
> Cc:
On Thu, Aug 09, 2018 at 02:04:03PM -0600, Alex Williamson wrote:
> v4: Fix 0-day i386 build error for readq, simply use readl
> instead, the bits we're interested in are 24:31 and the NVMe
> spec indicates that smaller, aligned accesses are allowed.
> Update bz links for both device
On Thu, Aug 09, 2018 at 02:04:03PM -0600, Alex Williamson wrote:
> v4: Fix 0-day i386 build error for readq, simply use readl
> instead, the bits we're interested in are 24:31 and the NVMe
> spec indicates that smaller, aligned accesses are allowed.
> Update bz links for both device
Makes membarrier_test compatible with older kernels (LTS) by checking if
the membarrier features exist before running the tests.
Link: https://bugs.linaro.org/show_bug.cgi?id=3771
Signed-off-by: Rafael David Tinoco
Cc: #v4.17
---
.../selftests/membarrier/membarrier_test.c| 71
Makes membarrier_test compatible with older kernels (LTS) by checking if
the membarrier features exist before running the tests.
Link: https://bugs.linaro.org/show_bug.cgi?id=3771
Signed-off-by: Rafael David Tinoco
Cc: #v4.17
---
.../selftests/membarrier/membarrier_test.c| 71
Defining the LINKER_SCRIPT when building the linker script as being done
in other architectures. This is required for the next Makefile changes
would otherwise break things.
Cc: Chris Zankel
Cc: Max Filippov
Cc: linux-xte...@linux-xtensa.org
Signed-off-by: Nadav Amit
---
Defining the LINKER_SCRIPT when building the linker script as being done
in other architectures. This is required for the next Makefile changes
would otherwise break things.
Cc: Chris Zankel
Cc: Max Filippov
Cc: linux-xte...@linux-xtensa.org
Signed-off-by: Nadav Amit
---
GCC considers the number of statements in inlined assembly blocks,
according to new-lines and semicolons, as an indication to the cost of
the block in time and space. This data is distorted by the kernel code,
which puts information in alternative sections. As a result, the
compiler may perform
On 07/09/2018 01:08 PM, Sujeev Dias wrote:
> For accurate synchronizations between external modem and
> host processor, mhi host will capture modem time relative
> to host time. Client may use time measurements for adjusting
> any drift between host and modem.
>
> Signed-off-by: Sujeev Dias
>
GCC considers the number of statements in inlined assembly blocks,
according to new-lines and semicolons, as an indication to the cost of
the block in time and space. This data is distorted by the kernel code,
which puts information in alternative sections. As a result, the
compiler may perform
On 07/09/2018 01:08 PM, Sujeev Dias wrote:
> For accurate synchronizations between external modem and
> host processor, mhi host will capture modem time relative
> to host time. Client may use time measurements for adjusting
> any drift between host and modem.
>
> Signed-off-by: Sujeev Dias
>
201 - 300 of 1264 matches
Mail list logo
