>> How do you think about to take another look at remaining update candidates
>> at other source code places for this Linux module?
>
> You mean the other patches in this patch-set?
Partly, yes. - Do you care for adjustments around numbered jump labels
(and suggestions from the script
>> How do you think about to take another look at remaining update candidates
>> at other source code places for this Linux module?
>
> You mean the other patches in this patch-set?
Partly, yes. - Do you care for adjustments around numbered jump labels
(and suggestions from the script
On Thu, Mar 30, 2017 at 08:08:00PM +0800, Wu Hao wrote:
> Hi All,
>
> Here is a patch-series adding drivers for Intel FPGA devices.
>
> The Intel FPGA driver provides interfaces for userspace applications to
> configure, enumerate, open, and access FPGA accelerators on platforms
> equipped with
On Thu, Mar 30, 2017 at 08:08:00PM +0800, Wu Hao wrote:
> Hi All,
>
> Here is a patch-series adding drivers for Intel FPGA devices.
>
> The Intel FPGA driver provides interfaces for userspace applications to
> configure, enumerate, open, and access FPGA accelerators on platforms
> equipped with
On Thu, 6 Apr 2017, Rafael J. Wysocki wrote:
> >>> Your swap partition may be located on an NVDIMM or be encrypted.
> >>
> >> An NVDIMM should be considered the same as any other persistent storage.
> >>
> >> It may be encrypted, but where's the key stored, how easy is it to retrieve
> >> and
On Thu, 6 Apr 2017, Rafael J. Wysocki wrote:
> >>> Your swap partition may be located on an NVDIMM or be encrypted.
> >>
> >> An NVDIMM should be considered the same as any other persistent storage.
> >>
> >> It may be encrypted, but where's the key stored, how easy is it to retrieve
> >> and
From: Colin King
Date: Wed, 5 Apr 2017 13:35:44 +0100
> From: Colin Ian King
>
> There seems to be a missing break on the OOO_LB_TC case, pq_id
> is being assigned and then re-assigned on the fall through default
> case and that seems
From: Colin King
Date: Wed, 5 Apr 2017 13:35:44 +0100
> From: Colin Ian King
>
> There seems to be a missing break on the OOO_LB_TC case, pq_id
> is being assigned and then re-assigned on the fall through default
> case and that seems suspect.
>
> Detected by CoverityScan, CID#1424402
On Thu, Apr 06, 2017 at 02:48:03PM -0400, Steven Rostedt wrote:
> On Thu, 6 Apr 2017 11:12:22 -0700
> "Paul E. McKenney" wrote:
>
> > On Thu, Apr 06, 2017 at 12:42:40PM -0400, Steven Rostedt wrote:
> > > From: "Steven Rostedt (VMware)"
> > >
> >
On Thu, Apr 06, 2017 at 02:48:03PM -0400, Steven Rostedt wrote:
> On Thu, 6 Apr 2017 11:12:22 -0700
> "Paul E. McKenney" wrote:
>
> > On Thu, Apr 06, 2017 at 12:42:40PM -0400, Steven Rostedt wrote:
> > > From: "Steven Rostedt (VMware)"
> > >
> > > There are certain parts of the kernel that can
Some operations must ensure that the guest is not running with stale
data, but if the guest is halted, then the update can wait until another
event happens. kvm_make_all_requests() currently doesn't wake up, so we
can mark all requests used with it.
First 8 bits were arbitrarily reserved for
Some operations must ensure that the guest is not running with stale
data, but if the guest is halted, then the update can wait until another
event happens. kvm_make_all_requests() currently doesn't wake up, so we
can mark all requests used with it.
First 8 bits were arbitrarily reserved for
Signed-off-by: Radim Krčmář
---
arch/x86/kvm/x86.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 71a019832df9..57e9989232e5 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2229,8
The #ifndef was protecting a missing halt_wakeup stat, but that is no
longer necessary.
Signed-off-by: Radim Krčmář
---
virt/kvm/kvm_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 2389e9c41cd2..a486c6ad27a6 100644
Signed-off-by: Radim Krčmář
---
arch/x86/kvm/x86.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 71a019832df9..57e9989232e5 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2229,8 +2229,7 @@ int
The #ifndef was protecting a missing halt_wakeup stat, but that is no
longer necessary.
Signed-off-by: Radim Krčmář
---
virt/kvm/kvm_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 2389e9c41cd2..a486c6ad27a6 100644
---
We want to have kvm_make_all_cpus_request() to be an optmized version of
kvm_for_each_vcpu(i, vcpu, kvm) {
kvm_make_request(vcpu, request);
kvm_vcpu_kick(vcpu);
}
and kvm_vcpu_kick() wakes up the target vcpu. We know which requests do
not need the wake up and use it to optimize the
We want to have kvm_make_all_cpus_request() to be an optmized version of
kvm_for_each_vcpu(i, vcpu, kvm) {
kvm_make_request(vcpu, request);
kvm_vcpu_kick(vcpu);
}
and kvm_vcpu_kick() wakes up the target vcpu. We know which requests do
not need the wake up and use it to optimize the
Users were expected to use kvm_check_request() for testing and clearing,
but request have expanded their use since then and some users want to
only test or do a faster clear.
Make sure that requests are not directly accessed with bit operations, because
we'll be clearing them later.
Users were expected to use kvm_check_request() for testing and clearing,
but request have expanded their use since then and some users want to
only test or do a faster clear.
Make sure that requests are not directly accessed with bit operations, because
we'll be clearing them later.
We have kvm_arch_vcpu_should_kick() to decide whether the target cpu
needs to be kicked. The previous condition was wrong, because
architectures that don't use vcpu->mode would not get interrupts and
also suboptimal, because it sent IPI in cases where none was necessary.
The situation is even
We have kvm_arch_vcpu_should_kick() to decide whether the target cpu
needs to be kicked. The previous condition was wrong, because
architectures that don't use vcpu->mode would not get interrupts and
also suboptimal, because it sent IPI in cases where none was necessary.
The situation is even
[1/6] makes a significant change for s390 and might be too dangerous
because of that.
I'm ok with returning 0 from s390's kvm_arch_vcpu_should_kick() until we
sort out architecture-specific kicks.
Adding kvm_vcpu_wake_up() in [6/6] is the reason why the other patches
were included.
Compile
[1/6] makes a significant change for s390 and might be too dangerous
because of that.
I'm ok with returning 0 from s390's kvm_arch_vcpu_should_kick() until we
sort out architecture-specific kicks.
Adding kvm_vcpu_wake_up() in [6/6] is the reason why the other patches
were included.
Compile
On Thu, Apr 06, 2017 at 02:13:29PM -0400, Steven Rostedt wrote:
> On Thu, 6 Apr 2017 11:05:53 -0700
> "Paul E. McKenney" wrote:
>
> > On Thu, Apr 06, 2017 at 12:42:38PM -0400, Steven Rostedt wrote:
> > > From: "Steven Rostedt (VMware)"
> > >
> >
On Thu, Apr 06, 2017 at 02:13:29PM -0400, Steven Rostedt wrote:
> On Thu, 6 Apr 2017 11:05:53 -0700
> "Paul E. McKenney" wrote:
>
> > On Thu, Apr 06, 2017 at 12:42:38PM -0400, Steven Rostedt wrote:
> > > From: "Steven Rostedt (VMware)"
> > >
> > > The function tracer needs to be more careful
We got need_resched() warnings in swap_cgroup_swapoff() because
swap_cgroup_ctrl[type].length is particularly large.
Reschedule when needed.
Signed-off-by: David Rientjes
---
mm/swap_cgroup.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/swap_cgroup.c
We got need_resched() warnings in swap_cgroup_swapoff() because
swap_cgroup_ctrl[type].length is particularly large.
Reschedule when needed.
Signed-off-by: David Rientjes
---
mm/swap_cgroup.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/swap_cgroup.c b/mm/swap_cgroup.c
---
On Thu, Apr 6, 2017 at 10:09 PM, Rafael J. Wysocki wrote:
> On Thu, Apr 6, 2017 at 10:41 AM, David Howells wrote:
>> Oliver Neukum wrote:
>>
>>> Your swap partition may be located on an NVDIMM or be encrypted.
>>
>> An NVDIMM should be
On Thu, Apr 6, 2017 at 10:09 PM, Rafael J. Wysocki wrote:
> On Thu, Apr 6, 2017 at 10:41 AM, David Howells wrote:
>> Oliver Neukum wrote:
>>
>>> Your swap partition may be located on an NVDIMM or be encrypted.
>>
>> An NVDIMM should be considered the same as any other persistent storage.
>>
>>
From: Markus Elfring
Date: Thu, 6 Apr 2017 21:45:33 +0200
A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus use the corresponding function "kcalloc".
This issue was detected by using
From: Markus Elfring
Date: Thu, 6 Apr 2017 21:45:33 +0200
A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus use the corresponding function "kcalloc".
This issue was detected by using the Coccinelle software.
From: Markus Elfring
Date: Thu, 6 Apr 2017 20:32:39 +0200
A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus use the corresponding function "kcalloc".
This issue was detected by using
From: Markus Elfring
Date: Thu, 6 Apr 2017 20:32:39 +0200
A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus use the corresponding function "kcalloc".
This issue was detected by using the Coccinelle software.
On Thu, Apr 6, 2017 at 10:41 AM, David Howells wrote:
> Oliver Neukum wrote:
>
>> Your swap partition may be located on an NVDIMM or be encrypted.
>
> An NVDIMM should be considered the same as any other persistent storage.
>
> It may be encrypted, but
On Thu, Apr 6, 2017 at 10:41 AM, David Howells wrote:
> Oliver Neukum wrote:
>
>> Your swap partition may be located on an NVDIMM or be encrypted.
>
> An NVDIMM should be considered the same as any other persistent storage.
>
> It may be encrypted, but where's the key stored, how easy is it to
On 03/19, Mars Cheng wrote:
> From: Kevin-CW Chen
>
> Add MT6797 clock support, include topckgen, apmixedsys, infracfg
> and subsystem clocks
>
> Signed-off-by: Kevin-CW Chen
> Signed-off-by: Mars Cheng
>
On 03/19, Mars Cheng wrote:
> From: Kevin-CW Chen
>
> Add MT6797 clock support, include topckgen, apmixedsys, infracfg
> and subsystem clocks
>
> Signed-off-by: Kevin-CW Chen
> Signed-off-by: Mars Cheng
> Tested-by: Matthias Brugger
Acked-by: Stephen Boyd
Looks fine to me except for the
From: Markus Elfring
Date: Thu, 6 Apr 2017 22:00:10 +0200
A few update suggestions were taken into account
from static source code analysis.
Markus Elfring (2):
Use kcalloc() in alloc_res_chunk_list()
Use kcalloc() in usnic_vnic_alloc_res_chunk()
From: Markus Elfring
Date: Thu, 6 Apr 2017 22:00:10 +0200
A few update suggestions were taken into account
from static source code analysis.
Markus Elfring (2):
Use kcalloc() in alloc_res_chunk_list()
Use kcalloc() in usnic_vnic_alloc_res_chunk()
The driver uses clock provider interface, and therefore
it fails to build when enabled for COMPILE_TEST, since
COMMON_CLK is not enabled at that time.
So, make PHY_QCOM_QMP depend on COMMON_CLK as well.
Cc: Fengguang Wu
Cc: Kishon Vijay Abraham I
The driver uses clock provider interface, and therefore
it fails to build when enabled for COMPILE_TEST, since
COMMON_CLK is not enabled at that time.
So, make PHY_QCOM_QMP depend on COMMON_CLK as well.
Cc: Fengguang Wu
Cc: Kishon Vijay Abraham I
Signed-off-by: Vivek Gautam
---
Hi Kishon,
On Thu, Apr 6, 2017 at 8:55 AM, David Howells wrote:
> Rafael J. Wysocki wrote:
>
>> You probably want to disable hibernation altogether in this case.
>
> See patch 10. Does that mean patch 11 is superfluous?
Yes, it does.
You can't open /dev/snapshot
On Thu, Apr 6, 2017 at 8:55 AM, David Howells wrote:
> Rafael J. Wysocki wrote:
>
>> You probably want to disable hibernation altogether in this case.
>
> See patch 10. Does that mean patch 11 is superfluous?
Yes, it does.
You can't open /dev/snapshot if hibernation_available() returns false.
On Thu, Apr 06, 2017 at 03:14:52PM -0400, Jeff Layton wrote:
> @@ -868,6 +869,7 @@ struct file {
> struct list_headf_tfile_llink;
> #endif /* #ifdef CONFIG_EPOLL */
> struct address_space*f_mapping;
> + u32 f_wb_err;
> }
On Thu, Apr 06, 2017 at 03:14:52PM -0400, Jeff Layton wrote:
> @@ -868,6 +869,7 @@ struct file {
> struct list_headf_tfile_llink;
> #endif /* #ifdef CONFIG_EPOLL */
> struct address_space*f_mapping;
> + u32 f_wb_err;
> }
On 2017-04-06 13:31, Michael Hennerich wrote:
> On 06.04.2017 10:39, Peter Rosin wrote:
>> Hi Michael,
>>
>> I would still like to hear from someone with more gpio experience.
>
> I'll ping Linus.
>
>>
>> Anyway, from my point of view, there's just a few minor things left,
>> with comments
On 2017-04-06 13:31, Michael Hennerich wrote:
> On 06.04.2017 10:39, Peter Rosin wrote:
>> Hi Michael,
>>
>> I would still like to hear from someone with more gpio experience.
>
> I'll ping Linus.
>
>>
>> Anyway, from my point of view, there's just a few minor things left,
>> with comments
From: Tobias Regnery
Date: Wed, 5 Apr 2017 11:11:10 +0200
> Commit 9008ae074885 ("net/mlx5e: Minimize mlx5e_{open/close}_locked")
> copied the calls to netif_set_real_num_{tx,rx}_queues from
> mlx5e_open_locked to mlx5e_activate_priv_channels and wraps them in an
> if
From: Tobias Regnery
Date: Wed, 5 Apr 2017 11:11:10 +0200
> Commit 9008ae074885 ("net/mlx5e: Minimize mlx5e_{open/close}_locked")
> copied the calls to netif_set_real_num_{tx,rx}_queues from
> mlx5e_open_locked to mlx5e_activate_priv_channels and wraps them in an
> if condition to test for
On Thu, Apr 06, 2017 at 12:32:24PM -0700, Florian Fainelli wrote:
> Make of_match_node() an inline function when CONFIG_OF=n which allows the
> compiler to eliminate warnings about unused variables.
>
> Suggested-by: Andrew Lunn
> Signed-off-by: Florian Fainelli
On Thu, Apr 06, 2017 at 12:32:24PM -0700, Florian Fainelli wrote:
> Make of_match_node() an inline function when CONFIG_OF=n which allows the
> compiler to eliminate warnings about unused variables.
>
> Suggested-by: Andrew Lunn
> Signed-off-by: Florian Fainelli
Thanks Florian,
Reviewed-by:
Hi Florian,
Florian Fainelli writes:
> The SMI clause 22 & 45 read/write operations are local to the global2.c file,
> so make them static. This eliminates the following warning:
>
> drivers/net/dsa/mv88e6xxx/global2.c:571:5: warning: no previous prototype for
>
Hi Florian,
Florian Fainelli writes:
> The SMI clause 22 & 45 read/write operations are local to the global2.c file,
> so make them static. This eliminates the following warning:
>
> drivers/net/dsa/mv88e6xxx/global2.c:571:5: warning: no previous prototype for
> 'mv88e6xxx_g2_smi_phy_read_c45'
On Wed, Apr 05, 2017 at 05:21:22PM +0200, SF Markus Elfring wrote:
> > I found that the fix brings no harm to the existing code.
>
> How do you think about to take another look at remaining update candidates
> at other source code places for this Linux module?
You mean the other patches in this
On Wed, Apr 05, 2017 at 05:21:22PM +0200, SF Markus Elfring wrote:
> > I found that the fix brings no harm to the existing code.
>
> How do you think about to take another look at remaining update candidates
> at other source code places for this Linux module?
You mean the other patches in this
On Wed, Apr 5, 2017 at 10:16 PM, David Howells wrote:
> From: Josh Boyer
>
> This option allows userspace to pass the RSDP address to the kernel, which
> makes it possible for a user to circumvent any restrictions imposed on
> loading modules. Ignore the
On Wed, Apr 5, 2017 at 10:16 PM, David Howells wrote:
> From: Josh Boyer
>
> This option allows userspace to pass the RSDP address to the kernel, which
> makes it possible for a user to circumvent any restrictions imposed on
> loading modules. Ignore the option when the kernel is locked down.
From: Kees Cook
Date: Tue, 4 Apr 2017 22:12:09 -0700
> Prepare to mark sensitive kernel structures for randomization by making
> sure they're using designated initializers. These were identified during
> allyesconfig builds of x86, arm, and arm64, and the initializer fixes
From: Kees Cook
Date: Tue, 4 Apr 2017 22:12:09 -0700
> Prepare to mark sensitive kernel structures for randomization by making
> sure they're using designated initializers. These were identified during
> allyesconfig builds of x86, arm, and arm64, and the initializer fixes
> were extracted from
The SMI clause 22 & 45 read/write operations are local to the global2.c file,
so make them static. This eliminates the following warning:
drivers/net/dsa/mv88e6xxx/global2.c:571:5: warning: no previous prototype for
'mv88e6xxx_g2_smi_phy_read_c45' [-Wmissing-prototypes]
int
The SMI clause 22 & 45 read/write operations are local to the global2.c file,
so make them static. This eliminates the following warning:
drivers/net/dsa/mv88e6xxx/global2.c:571:5: warning: no previous prototype for
'mv88e6xxx_g2_smi_phy_read_c45' [-Wmissing-prototypes]
int
On Thu, Apr 6, 2017 at 12:23 PM, Peter Zijlstra wrote:
>
> Something like so then. According to the SDM mwait is a no-op if we do
> not execute monitor first. So this variant should get the first
> iteration without expensive instructions.
No, the problem is that we *would*
On Thu, Apr 6, 2017 at 12:23 PM, Peter Zijlstra wrote:
>
> Something like so then. According to the SDM mwait is a no-op if we do
> not execute monitor first. So this variant should get the first
> iteration without expensive instructions.
No, the problem is that we *would* have executed a prior
> Il giorno 04 apr 2017, alle ore 17:28, Bart Van Assche
> ha scritto:
>
> On Tue, 2017-04-04 at 12:42 +0200, Paolo Valente wrote:
>>> Il giorno 31 mar 2017, alle ore 17:31, Bart Van Assche
>>> ha scritto:
>>>
>>> On Fri, 2017-03-31 at
> Il giorno 04 apr 2017, alle ore 17:28, Bart Van Assche
> ha scritto:
>
> On Tue, 2017-04-04 at 12:42 +0200, Paolo Valente wrote:
>>> Il giorno 31 mar 2017, alle ore 17:31, Bart Van Assche
>>> ha scritto:
>>>
>>> On Fri, 2017-03-31 at 14:47 +0200, Paolo Valente wrote:
+
On 04/06/2017 02:29 PM, Russell King - ARM Linux wrote:
On Thu, Apr 06, 2017 at 02:14:12PM -0500, Dave Gerlach wrote:
On 04/06/2017 02:07 PM, Russell King - ARM Linux wrote:
On Wed, Apr 05, 2017 at 02:22:33PM -0500, Dave Gerlach wrote:
Russell,
On 04/05/2017 02:21 PM, Dave Gerlach wrote:
On 04/06/2017 02:29 PM, Russell King - ARM Linux wrote:
On Thu, Apr 06, 2017 at 02:14:12PM -0500, Dave Gerlach wrote:
On 04/06/2017 02:07 PM, Russell King - ARM Linux wrote:
On Wed, Apr 05, 2017 at 02:22:33PM -0500, Dave Gerlach wrote:
Russell,
On 04/05/2017 02:21 PM, Dave Gerlach wrote:
Hi Arushi,
On Tue, Mar 28, 2017 at 04:03:27AM +0530, Arushi Singhal wrote:
> This patch removes multiple assignments to follow the kernel coding
> style as also reported by checkpatch.pl.
> Done using coccinelle.
> @@
> identifier i1,i2;
> constant c;
> @@
> - i1=i2=c;
> + i1=c;
> + i2=i1;
I see
Hi Arushi,
On Tue, Mar 28, 2017 at 04:03:27AM +0530, Arushi Singhal wrote:
> This patch removes multiple assignments to follow the kernel coding
> style as also reported by checkpatch.pl.
> Done using coccinelle.
> @@
> identifier i1,i2;
> constant c;
> @@
> - i1=i2=c;
> + i1=c;
> + i2=i1;
I see
On 04/06/17 04:01, Sricharan R wrote:
> Hi Frank,
>
> On 4/6/2017 12:31 PM, Frank Rowand wrote:
>> On 04/04/17 03:18, Sricharan R wrote:
>>> Size of the dma-range is calculated as coherent_dma_mask + 1
>>> and passed to arch_setup_dma_ops further. It overflows when
>>> the coherent_dma_mask is
On 04/06/17 04:01, Sricharan R wrote:
> Hi Frank,
>
> On 4/6/2017 12:31 PM, Frank Rowand wrote:
>> On 04/04/17 03:18, Sricharan R wrote:
>>> Size of the dma-range is calculated as coherent_dma_mask + 1
>>> and passed to arch_setup_dma_ops further. It overflows when
>>> the coherent_dma_mask is
On Thu, 6 Apr 2017 11:05:31 -0600
Alex Williamson wrote:
> On Thu, 6 Apr 2017 18:53:04 +0200
> Auger Eric wrote:
>
> > Hi Alex,
> >
> > On 06/04/2017 16:53, Alex Williamson wrote:
> > > If the mmap_sem is contented then the vfio type1 IOMMU
Make of_match_node() an inline function when CONFIG_OF=n which allows the
compiler to eliminate warnings about unused variables.
Suggested-by: Andrew Lunn
Signed-off-by: Florian Fainelli
---
include/linux/of.h | 6 +-
1 file changed, 5 insertions(+), 1
On Thu, 6 Apr 2017 11:05:31 -0600
Alex Williamson wrote:
> On Thu, 6 Apr 2017 18:53:04 +0200
> Auger Eric wrote:
>
> > Hi Alex,
> >
> > On 06/04/2017 16:53, Alex Williamson wrote:
> > > If the mmap_sem is contented then the vfio type1 IOMMU backend will
> > > defer locked page accounting
Make of_match_node() an inline function when CONFIG_OF=n which allows the
compiler to eliminate warnings about unused variables.
Suggested-by: Andrew Lunn
Signed-off-by: Florian Fainelli
---
include/linux/of.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
Fix kernel Oops NULL pointer deference
Call dev_dbg_obj only after checking if gobj->mdev is not NULL
Signed-off-by: Helen Koike
---
drivers/media/media-entity.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/media-entity.c
Fix kernel Oops NULL pointer deference
Call dev_dbg_obj only after checking if gobj->mdev is not NULL
Signed-off-by: Helen Koike
---
drivers/media/media-entity.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
On Thu, Apr 06, 2017 at 02:14:12PM -0500, Dave Gerlach wrote:
> On 04/06/2017 02:07 PM, Russell King - ARM Linux wrote:
> >On Wed, Apr 05, 2017 at 02:22:33PM -0500, Dave Gerlach wrote:
> >>Russell,
> >>On 04/05/2017 02:21 PM, Dave Gerlach wrote:
> >>>Currently the sram-exec functionality, which
On Thu, Apr 06, 2017 at 02:14:12PM -0500, Dave Gerlach wrote:
> On 04/06/2017 02:07 PM, Russell King - ARM Linux wrote:
> >On Wed, Apr 05, 2017 at 02:22:33PM -0500, Dave Gerlach wrote:
> >>Russell,
> >>On 04/05/2017 02:21 PM, Dave Gerlach wrote:
> >>>Currently the sram-exec functionality, which
On Thu, Apr 6, 2017 at 5:57 AM, Wu Hao wrote:
> On Wed, Apr 05, 2017 at 10:39:05AM -0500, Alan Tull wrote:
>> On Wed, Apr 5, 2017 at 10:26 AM, Alan Tull wrote:
>> > On Wed, Apr 5, 2017 at 6:40 AM, Wu, Hao wrote:
>> >>> >> The
On Thu, Apr 6, 2017 at 5:57 AM, Wu Hao wrote:
> On Wed, Apr 05, 2017 at 10:39:05AM -0500, Alan Tull wrote:
>> On Wed, Apr 5, 2017 at 10:26 AM, Alan Tull wrote:
>> > On Wed, Apr 5, 2017 at 6:40 AM, Wu, Hao wrote:
>> >>> >> The fpga_image_info struct started life as just image specific info,
>>
From: Florian Fainelli
Date: Tue, 4 Apr 2017 18:16:57 -0700
> With GCC 6.3, we can get the following warning:
>
> drivers/net/usb/usbnet.c:85:19: warning: 'driver_name' defined but not
> used [-Wunused-const-variable=]
> static const char driver_name [] = "usbnet";
>
From: Florian Fainelli
Date: Tue, 4 Apr 2017 18:16:57 -0700
> With GCC 6.3, we can get the following warning:
>
> drivers/net/usb/usbnet.c:85:19: warning: 'driver_name' defined but not
> used [-Wunused-const-variable=]
> static const char driver_name [] = "usbnet";
>
Hi Johannes,
thanks for your comments
El Thu, Apr 06, 2017 at 09:11:18PM +0200 Johannes Berg ha dit:
> On Thu, 2017-04-06 at 11:56 -0700, Matthias Kaehlcke wrote:
> > Clang raises a warning about the expression 'strlen(CONFIG_XXX)'
> > being
> > used in a logical operation. Clangs' builtin
Hi Johannes,
thanks for your comments
El Thu, Apr 06, 2017 at 09:11:18PM +0200 Johannes Berg ha dit:
> On Thu, 2017-04-06 at 11:56 -0700, Matthias Kaehlcke wrote:
> > Clang raises a warning about the expression 'strlen(CONFIG_XXX)'
> > being
> > used in a logical operation. Clangs' builtin
On 04/06/17 03:24, Robin Murphy wrote:
> On 06/04/17 08:01, Frank Rowand wrote:
>> On 04/04/17 03:18, Sricharan R wrote:
>>> Size of the dma-range is calculated as coherent_dma_mask + 1
>>> and passed to arch_setup_dma_ops further. It overflows when
>>> the coherent_dma_mask is set for full 64
On 04/06/17 03:24, Robin Murphy wrote:
> On 06/04/17 08:01, Frank Rowand wrote:
>> On 04/04/17 03:18, Sricharan R wrote:
>>> Size of the dma-range is calculated as coherent_dma_mask + 1
>>> and passed to arch_setup_dma_ops further. It overflows when
>>> the coherent_dma_mask is set for full 64
On Thu, Apr 06, 2017 at 10:31:46AM -0700, Linus Torvalds wrote:
> And we'd probably want to make it even more strict, in that soem mwait
> implementations might simply not be very good for short waits.
Yeah, we need to find something that works; assuming its beneficial at
all on modern chips.
>
On Thu, Apr 06, 2017 at 10:31:46AM -0700, Linus Torvalds wrote:
> And we'd probably want to make it even more strict, in that soem mwait
> implementations might simply not be very good for short waits.
Yeah, we need to find something that works; assuming its beneficial at
all on modern chips.
>
On 03/24/2017 02:55 AM, Nikolay Borisov wrote:
> register_shrinker allocates dynamic memory and thus is susceptible to failures
> under low-memory situation. Currently,get_userns ignores the return value of
> register_shrinker, potentially exposing not fully initialised object. This
> can lead
On 03/24/2017 02:55 AM, Nikolay Borisov wrote:
> register_shrinker allocates dynamic memory and thus is susceptible to failures
> under low-memory situation. Currently,get_userns ignores the return value of
> register_shrinker, potentially exposing not fully initialised object. This
> can lead
On Thu, Apr 06, 2017 at 07:58:57PM +0100, Sean Young wrote:
> On Thu, Apr 06, 2017 at 01:34:20PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the staging tree got conflicts in:
> >
> > drivers/staging/media/lirc/lirc_sasem.c
> >
On Thu, Apr 06, 2017 at 07:58:57PM +0100, Sean Young wrote:
> On Thu, Apr 06, 2017 at 01:34:20PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the staging tree got conflicts in:
> >
> > drivers/staging/media/lirc/lirc_sasem.c
> >
On 04/06/2017 09:43 PM, Dmitry Safonov wrote:
Hi Kirill,
On 04/06/2017 05:01 PM, Kirill A. Shutemov wrote:
On x86, 5-level paging enables 56-bit userspace virtual address space.
Not all user space is ready to handle wide addresses. It's known that
at least some JIT compilers use higher bits in
On 04/06/2017 09:43 PM, Dmitry Safonov wrote:
Hi Kirill,
On 04/06/2017 05:01 PM, Kirill A. Shutemov wrote:
On x86, 5-level paging enables 56-bit userspace virtual address space.
Not all user space is ready to handle wide addresses. It's known that
at least some JIT compilers use higher bits in
On Thu, 2017-04-06 at 10:02 +1000, NeilBrown wrote:
> >
> On Thu, Apr 06 2017, Jeff Layton wrote:
>
> > On Tue, 2017-04-04 at 10:09 -0700, Matthew Wilcox wrote:
> > > On Tue, Apr 04, 2017 at 12:25:46PM -0400, Jeff Layton wrote:
> > > > That said, I think giving more specific errors where we can
On 04/06/2017 02:07 PM, Russell King - ARM Linux wrote:
On Wed, Apr 05, 2017 at 02:22:33PM -0500, Dave Gerlach wrote:
Russell,
On 04/05/2017 02:21 PM, Dave Gerlach wrote:
Currently the sram-exec functionality, which allows allocation of
executable memory and provides an API to move code to it,
On 04/06/2017 02:07 PM, Russell King - ARM Linux wrote:
On Wed, Apr 05, 2017 at 02:22:33PM -0500, Dave Gerlach wrote:
Russell,
On 04/05/2017 02:21 PM, Dave Gerlach wrote:
Currently the sram-exec functionality, which allows allocation of
executable memory and provides an API to move code to it,
On Thu, 2017-04-06 at 10:02 +1000, NeilBrown wrote:
> >
> On Thu, Apr 06 2017, Jeff Layton wrote:
>
> > On Tue, 2017-04-04 at 10:09 -0700, Matthew Wilcox wrote:
> > > On Tue, Apr 04, 2017 at 12:25:46PM -0400, Jeff Layton wrote:
> > > > That said, I think giving more specific errors where we can
301 - 400 of 1976 matches
Mail list logo