On Sat, Mar 11, 2017 at 07:31:18PM -0800, Steve Longerbeam wrote:
>
>
> On 03/11/2017 10:59 AM, Russell King - ARM Linux wrote:
> >On Sat, Mar 11, 2017 at 10:54:55AM -0800, Steve Longerbeam wrote:
> >>
> >>
> >>On 03/11/2017 10:45 AM, Russell King - ARM Linux wrote:
> >>>I really don't think
On Sat, Mar 11, 2017 at 07:31:18PM -0800, Steve Longerbeam wrote:
>
>
> On 03/11/2017 10:59 AM, Russell King - ARM Linux wrote:
> >On Sat, Mar 11, 2017 at 10:54:55AM -0800, Steve Longerbeam wrote:
> >>
> >>
> >>On 03/11/2017 10:45 AM, Russell King - ARM Linux wrote:
> >>>I really don't think
On 03/11/2017 08:11 AM, Krzysztof Kozlowski wrote:
> Add Krzysztof Kozlowski and Vladimir Zapolskiy as maintainers of s5p-sss
> driver for handling reviews, testing and getting bug reports from the
> users.
>
> Cc: Vladimir Zapolskiy
> Cc: Herbert Xu
On 03/11/2017 08:11 AM, Krzysztof Kozlowski wrote:
> Add Krzysztof Kozlowski and Vladimir Zapolskiy as maintainers of s5p-sss
> driver for handling reviews, testing and getting bug reports from the
> users.
>
> Cc: Vladimir Zapolskiy
> Cc: Herbert Xu
> Signed-off-by: Krzysztof Kozlowski
>
From: Eric Biggers
I found that statx() was significantly slower than stat(). As a
microbenchmark, I compared 10,000,000 invocations of fstat() on a tmpfs
file to the same with statx() passed a NULL path:
$ time ./stat_benchmark
real0m1.464s
From: Eric Biggers
I found that statx() was significantly slower than stat(). As a
microbenchmark, I compared 10,000,000 invocations of fstat() on a tmpfs
file to the same with statx() passed a NULL path:
$ time ./stat_benchmark
real0m1.464s
user0m0.275s
Hi Stephen,
On 02/23/17 15:08, Frank Rowand wrote:
> On 02/13/17 18:50, Stephen Boyd wrote:
>> The 'blob' we pass into populate_properties() is marked as const,
>> but we cast that const away when we assign the result of
>> fdt_getprop_by_offset() to pp->value. Let's mark value as const
>>
Hi Stephen,
On 02/23/17 15:08, Frank Rowand wrote:
> On 02/13/17 18:50, Stephen Boyd wrote:
>> The 'blob' we pass into populate_properties() is marked as const,
>> but we cast that const away when we assign the result of
>> fdt_getprop_by_offset() to pp->value. Let's mark value as const
>>
On Sat, Mar 11, 2017 at 08:02:06PM -0800, Eric Biggers wrote:
> On Sun, Mar 12, 2017 at 02:29:27AM +, Al Viro wrote:
> >
> > Oh, I agree that multiple __put_user() are wrong; I also agree that bulk
> > copy is
> > the right approach (when we get the unsafe stuff right, we can revisit
> >
On Sat, Mar 11, 2017 at 08:02:06PM -0800, Eric Biggers wrote:
> On Sun, Mar 12, 2017 at 02:29:27AM +, Al Viro wrote:
> >
> > Oh, I agree that multiple __put_user() are wrong; I also agree that bulk
> > copy is
> > the right approach (when we get the unsafe stuff right, we can revisit
> >
From: Magnus Damm
Support the r8a7796 IPMMU by sharing feature flags between
r8a7795 and r8a7796. Also update IOMMU_OF_DECLARE to hook
up the updated compat string.
Signed-off-by: Magnus Damm
---
Changes since V2:
- Updated to include
From: Magnus Damm
Support the r8a7796 IPMMU by sharing feature flags between
r8a7795 and r8a7796. Also update IOMMU_OF_DECLARE to hook
up the updated compat string.
Signed-off-by: Magnus Damm
---
Changes since V2:
- Updated to include white list suppport
Changes since V1:
- None
From: Magnus Damm
Bump up the maximum numbers of micro-TLBS to 48.
Each IPMMU device instance get micro-TLB assignment via
the "iommus" property in DT. Older SoCs tend to use a
maximum number of 32 micro-TLBs per IPMMU instance however
newer SoCs such as r8a7796 make
From: Magnus Damm
Bump up the maximum numbers of micro-TLBS to 48.
Each IPMMU device instance get micro-TLB assignment via
the "iommus" property in DT. Older SoCs tend to use a
maximum number of 32 micro-TLBs per IPMMU instance however
newer SoCs such as r8a7796 make use of up to 48 micro-TLBs.
iommu/ipmmu-vmsa: r8a7796 support V3
[PATCH v3 1/3] iommu/ipmmu-vmsa: Add r8a7796 DT binding
[PATCH v3 2/3] iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48
[PATCH v3 3/3] iommu/ipmmu-vmsa: Hook up r8a7796 DT matching code
This series adds r8a7796 support to the IPMMU driver. The DT binding
From: Magnus Damm
Update the IPMMU DT binding documentation to include the r8a7796 compat
string for R-Car M3-W.
Signed-off-by: Magnus Damm
Acked-by: Laurent Pinchart
Acked-by: Rob Herring
iommu/ipmmu-vmsa: r8a7796 support V3
[PATCH v3 1/3] iommu/ipmmu-vmsa: Add r8a7796 DT binding
[PATCH v3 2/3] iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48
[PATCH v3 3/3] iommu/ipmmu-vmsa: Hook up r8a7796 DT matching code
This series adds r8a7796 support to the IPMMU driver. The DT binding
From: Magnus Damm
Update the IPMMU DT binding documentation to include the r8a7796 compat
string for R-Car M3-W.
Signed-off-by: Magnus Damm
Acked-by: Laurent Pinchart
Acked-by: Rob Herring
Acked-by: Simon Horman
Acked-by: Geert Uytterhoeven
---
Changes since V2:
- None
Changes since
Hello list,
Here's a photo of the panic, on imgur to be kind to vger:
http://imgur.com/a/wZI32
I'm out on a sailboat so can't really do much, but had a chance with internet
to send this FYI. I don't even know if this happens always or not yet.
Never seen this before, up to and including
Hello list,
Here's a photo of the panic, on imgur to be kind to vger:
http://imgur.com/a/wZI32
I'm out on a sailboat so can't really do much, but had a chance with internet
to send this FYI. I don't even know if this happens always or not yet.
Never seen this before, up to and including
When I was running my testcase which may block hundreds of threads
on fs locks, I got lockup due to output from debug_show_all_locks()
added by commit b2d4c2edb2e4f89a ("locking/hung_task: Show all locks").
For example, if 1000 threads were blocked in TASK_UNINTERRUPTIBLE state
and 500 out of
When I was running my testcase which may block hundreds of threads
on fs locks, I got lockup due to output from debug_show_all_locks()
added by commit b2d4c2edb2e4f89a ("locking/hung_task: Show all locks").
For example, if 1000 threads were blocked in TASK_UNINTERRUPTIBLE state
and 500 out of
On Fri, Mar 10, 2017 at 03:24:52PM -0800, Kevin Hilman wrote:
> kernelci.org bot writes:
>
> > stable-rc boot: 541 boots: 6 failed, 500 passed with 34 offline, 1 conflict
> > (v4.10.1-168-gcdc1f9d24aac)
> >
> > Full Boot Summary:
> >
On Fri, Mar 10, 2017 at 03:24:52PM -0800, Kevin Hilman wrote:
> kernelci.org bot writes:
>
> > stable-rc boot: 541 boots: 6 failed, 500 passed with 34 offline, 1 conflict
> > (v4.10.1-168-gcdc1f9d24aac)
> >
> > Full Boot Summary:
> >
On Fri, Mar 10, 2017 at 10:36:55AM -0800, Guenter Roeck wrote:
> On Fri, Mar 10, 2017 at 10:07:23AM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.10.2 release.
> > There are 167 patches in this series, all will be posted as a response
> > to this one.
On Fri, Mar 10, 2017 at 10:36:55AM -0800, Guenter Roeck wrote:
> On Fri, Mar 10, 2017 at 10:07:23AM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.10.2 release.
> > There are 167 patches in this series, all will be posted as a response
> > to this one.
On Fri, Mar 10, 2017 at 04:48:52PM +, Ben Hutchings wrote:
> On Fri, 2017-03-10 at 10:08 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch. If anyone has any objections, please let me
> > know.
> >
> > --
> >
> > From: Theodore Ts'o
> >
> > commit
On Fri, Mar 10, 2017 at 12:14:35PM -0700, Shuah Khan wrote:
> On 03/10/2017 02:07 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.10.2 release.
> > There are 167 patches in this series, all will be posted as a response
> > to this one. If anyone has any
On Fri, Mar 10, 2017 at 04:48:52PM +, Ben Hutchings wrote:
> On Fri, 2017-03-10 at 10:08 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch. If anyone has any objections, please let me
> > know.
> >
> > --
> >
> > From: Theodore Ts'o
> >
> > commit
On Fri, Mar 10, 2017 at 12:14:35PM -0700, Shuah Khan wrote:
> On 03/10/2017 02:07 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.10.2 release.
> > There are 167 patches in this series, all will be posted as a response
> > to this one. If anyone has any
On Sun, Mar 12, 2017 at 08:04:02AM +0530, Arushi Singhal wrote:
> New variables are added to make the code more readable.
> Also fixed the checkpatch issue: "Alignment should match open
> parenthesis".
When you have to say "also" in a commit message, that is a huge red-flag
that you need to break
On Sun, Mar 12, 2017 at 08:04:02AM +0530, Arushi Singhal wrote:
> New variables are added to make the code more readable.
> Also fixed the checkpatch issue: "Alignment should match open
> parenthesis".
When you have to say "also" in a commit message, that is a huge red-flag
that you need to break
On Sat, Mar 11, 2017 at 2:52 PM, Jens Axboe wrote:
>
> Talked to Tejun about this as well, and we both agree that the splitting
> this into separate init/alloc paths would be much cleaner. I can't
> apply the current patch, sorry, it's just too ugly to live.
Do you mean, you
On Sat, Mar 11, 2017 at 2:52 PM, Jens Axboe wrote:
>
> Talked to Tejun about this as well, and we both agree that the splitting
> this into separate init/alloc paths would be much cleaner. I can't
> apply the current patch, sorry, it's just too ugly to live.
Do you mean, you prefer the approach
On Sun, Mar 12, 2017 at 01:59:54AM +, Wang, Wei W wrote:
> On 03/11/2017 10:10 PM, Matthew Wilcox wrote:
> > On Sat, Mar 11, 2017 at 07:59:31PM +0800, Wei Wang wrote:
> > > I'm thinking what if the guest needs to transfer these much physically
> > > continuous memory to host:
On Sun, Mar 12, 2017 at 01:59:54AM +, Wang, Wei W wrote:
> On 03/11/2017 10:10 PM, Matthew Wilcox wrote:
> > On Sat, Mar 11, 2017 at 07:59:31PM +0800, Wei Wang wrote:
> > > I'm thinking what if the guest needs to transfer these much physically
> > > continuous memory to host:
On Sun, Mar 12, 2017 at 02:29:27AM +, Al Viro wrote:
>
> Oh, I agree that multiple __put_user() are wrong; I also agree that bulk copy
> is
> the right approach (when we get the unsafe stuff right, we can revisit that,
> but
> I suspect that on quite a few architectures a bulk copy will
On Sun, Mar 12, 2017 at 02:29:27AM +, Al Viro wrote:
>
> Oh, I agree that multiple __put_user() are wrong; I also agree that bulk copy
> is
> the right approach (when we get the unsafe stuff right, we can revisit that,
> but
> I suspect that on quite a few architectures a bulk copy will
On 03/11/2017 10:59 AM, Russell King - ARM Linux wrote:
On Sat, Mar 11, 2017 at 10:54:55AM -0800, Steve Longerbeam wrote:
On 03/11/2017 10:45 AM, Russell King - ARM Linux wrote:
I really don't think expecting the user to understand and configure
the pipeline is a sane way forward. Think
On 03/11/2017 10:59 AM, Russell King - ARM Linux wrote:
On Sat, Mar 11, 2017 at 10:54:55AM -0800, Steve Longerbeam wrote:
On 03/11/2017 10:45 AM, Russell King - ARM Linux wrote:
I really don't think expecting the user to understand and configure
the pipeline is a sane way forward. Think
Hi Julia,
[auto build test ERROR on gpio/for-next]
[also build test ERROR on v4.11-rc1 next-20170309]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
On Sun, Mar 12, 2017 at 03:29:59AM +0100, Shiva Kerdel wrote:
> Fix prefer kernel type 'u8' over 'uint8_t' checks.
>
> Signed-off-by: Shiva Kerdel
> ---
> drivers/staging/ks7010/ks_hostif.c | 4 +-
> drivers/staging/ks7010/ks_hostif.h | 114
>
On Sun, Mar 12, 2017 at 03:29:59AM +0100, Shiva Kerdel wrote:
> Fix prefer kernel type 'u8' over 'uint8_t' checks.
>
> Signed-off-by: Shiva Kerdel
> ---
> drivers/staging/ks7010/ks_hostif.c | 4 +-
> drivers/staging/ks7010/ks_hostif.h | 114
> +--
>
Hi Julia,
[auto build test ERROR on gpio/for-next]
[also build test ERROR on v4.11-rc1 next-20170309]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
New variables are added to make the code more readable.
Also fixed the checkpatch issue: "Alignment should match open
parenthesis".
Signed-off-by: Arushi Singhal
---
drivers/staging/sm750fb/ddk750_mode.c | 112 --
1 file changed,
New variables are added to make the code more readable.
Also fixed the checkpatch issue: "Alignment should match open
parenthesis".
Signed-off-by: Arushi Singhal
---
drivers/staging/sm750fb/ddk750_mode.c | 112 --
1 file changed, 53 insertions(+), 59 deletions(-)
On Sat, Mar 11, 2017 at 06:16:55PM -0800, Eric Biggers wrote:
> Hi Al,
>
> On Sun, Mar 12, 2017 at 01:24:15AM +, Al Viro wrote:
> > On Sat, Mar 11, 2017 at 01:45:55PM -0800, Eric Biggers wrote:
> > > From: Eric Biggers
> > >
> > > I found that statx() was significantly
On Sat, Mar 11, 2017 at 06:16:55PM -0800, Eric Biggers wrote:
> Hi Al,
>
> On Sun, Mar 12, 2017 at 01:24:15AM +, Al Viro wrote:
> > On Sat, Mar 11, 2017 at 01:45:55PM -0800, Eric Biggers wrote:
> > > From: Eric Biggers
> > >
> > > I found that statx() was significantly slower than stat().
Le 03/11/17 à 13:12, Vivien Didelot a écrit :
> The purpose of this patch series is to rework the code related to the
> Address Translation Unit (ATU), and bring support for it to the 88E6390
> family of switch chips.
>
> All Global (1) ATU related code have been reworked and moved to its own
>
Le 03/11/17 à 13:12, Vivien Didelot a écrit :
> The purpose of this patch series is to rework the code related to the
> Address Translation Unit (ATU), and bring support for it to the 88E6390
> family of switch chips.
>
> All Global (1) ATU related code have been reworked and moved to its own
>
When a sysadmin wishes to monitor module unloading with a syscall rule such as:
-a always,exit -F arch=x86_64 -S delete_module -F key=mod-unload
the SYSCALL record doesn't tell us what module was requested for unloading.
Use the new KERN_MODULE auxiliary record to record it.
The SYSCALL record
When a sysadmin wishes to monitor module unloading with a syscall rule such as:
-a always,exit -F arch=x86_64 -S delete_module -F key=mod-unload
the SYSCALL record doesn't tell us what module was requested for unloading.
Use the new KERN_MODULE auxiliary record to record it.
The SYSCALL record
Le 03/11/17 à 13:12, Vivien Didelot a écrit :
> Introduce a dsa_is_normal_port helper to check if a given port is a
> normal user port as opposed to a CPU port or DSA link.
net/dsa/dsa2.c uses the "user" terminology should we use something like
that here?
>
> Signed-off-by: Vivien Didelot
Le 03/11/17 à 13:12, Vivien Didelot a écrit :
> Introduce a dsa_is_normal_port helper to check if a given port is a
> normal user port as opposed to a CPU port or DSA link.
net/dsa/dsa2.c uses the "user" terminology should we use something like
that here?
>
> Signed-off-by: Vivien Didelot
>
Hi Al,
On Sun, Mar 12, 2017 at 01:24:15AM +, Al Viro wrote:
> On Sat, Mar 11, 2017 at 01:45:55PM -0800, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > I found that statx() was significantly slower than stat(). As a
> > microbenchmark, I compared 10,000,000
Hi Al,
On Sun, Mar 12, 2017 at 01:24:15AM +, Al Viro wrote:
> On Sat, Mar 11, 2017 at 01:45:55PM -0800, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > I found that statx() was significantly slower than stat(). As a
> > microbenchmark, I compared 10,000,000 invocations of fstat() on a
On Sun, Mar 12, 2017 at 01:54:38AM +, Al Viro wrote:
> On Tue, Mar 07, 2017 at 12:05:16AM +0100, Alexey Gladkov wrote:
>
> > diff --git a/include/linux/fs.h b/include/linux/fs.h
> > index 83de8b6..5bd1b84 100644
> > --- a/include/linux/fs.h
> > +++ b/include/linux/fs.h
> > @@ -1759,6 +1759,8
On Sun, Mar 12, 2017 at 01:54:38AM +, Al Viro wrote:
> On Tue, Mar 07, 2017 at 12:05:16AM +0100, Alexey Gladkov wrote:
>
> > diff --git a/include/linux/fs.h b/include/linux/fs.h
> > index 83de8b6..5bd1b84 100644
> > --- a/include/linux/fs.h
> > +++ b/include/linux/fs.h
> > @@ -1759,6 +1759,8
On 03/11/2017 05:55 PM, Cameron Gutman wrote:
>
> The affected machine is an XPS 13 9443 running Fedora 25 with 4.11-rc1
> and libinput 1.6.3-3.fc25 (latest in F25).
>
Oops, that's 9343, not 9443.
DMI: Dell Inc. XPS 13 9343/0TM99H, BIOS A11 12/08/2016
On 03/11/2017 05:55 PM, Cameron Gutman wrote:
>
> The affected machine is an XPS 13 9443 running Fedora 25 with 4.11-rc1
> and libinput 1.6.3-3.fc25 (latest in F25).
>
Oops, that's 9343, not 9443.
DMI: Dell Inc. XPS 13 9343/0TM99H, BIOS A11 12/08/2016
On 03/11/2017 10:10 PM, Matthew Wilcox wrote:
> On Sat, Mar 11, 2017 at 07:59:31PM +0800, Wei Wang wrote:
> > I'm thinking what if the guest needs to transfer these much physically
> > continuous memory to host: 1GB+2MB+64KB+32KB+16KB+4KB.
> > Is it going to use Six 64-bit chunks? Would it be
On 03/11/2017 10:10 PM, Matthew Wilcox wrote:
> On Sat, Mar 11, 2017 at 07:59:31PM +0800, Wei Wang wrote:
> > I'm thinking what if the guest needs to transfer these much physically
> > continuous memory to host: 1GB+2MB+64KB+32KB+16KB+4KB.
> > Is it going to use Six 64-bit chunks? Would it be
Hi,
Beginning in 4.11-rc1, it looks like RMI4 is binding to my XPS 13 9443's
Synaptics touchpad and dropping some errors into dmesg. Here are the
messages that seem RMI-related:
rmi4_f34 rmi4-00.fn34: rmi_f34v7_probe: Unrecognized bootloader version
rmi4_f34: probe of rmi4-00.fn34 failed with
Hi,
Beginning in 4.11-rc1, it looks like RMI4 is binding to my XPS 13 9443's
Synaptics touchpad and dropping some errors into dmesg. Here are the
messages that seem RMI-related:
rmi4_f34 rmi4-00.fn34: rmi_f34v7_probe: Unrecognized bootloader version
rmi4_f34: probe of rmi4-00.fn34 failed with
On Tue, Mar 07, 2017 at 12:05:16AM +0100, Alexey Gladkov wrote:
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 83de8b6..5bd1b84 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -1759,6 +1759,8 @@ struct super_operations {
> int (*thaw_super) (struct
On Tue, Mar 07, 2017 at 12:05:16AM +0100, Alexey Gladkov wrote:
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 83de8b6..5bd1b84 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -1759,6 +1759,8 @@ struct super_operations {
> int (*thaw_super) (struct
Fix prefer kernel type 'u16' over 'uint16_t' checks.
Signed-off-by: Shiva Kerdel
---
drivers/staging/ks7010/ks_hostif.c | 20 +++---
drivers/staging/ks7010/ks_hostif.h | 134 ++---
2 files changed, 77 insertions(+), 77 deletions(-)
diff --git
Fix prefer kernel type 'u16' over 'uint16_t' checks.
Signed-off-by: Shiva Kerdel
---
drivers/staging/ks7010/ks_hostif.c | 20 +++---
drivers/staging/ks7010/ks_hostif.h | 134 ++---
2 files changed, 77 insertions(+), 77 deletions(-)
diff --git
Fix prefer kernel type 'u32' over 'uint32_t' checks.
Signed-off-by: Shiva Kerdel
---
drivers/staging/ks7010/ks_hostif.c | 18 +-
drivers/staging/ks7010/ks_hostif.h | 30 +++---
2 files changed, 24 insertions(+), 24 deletions(-)
diff --git
Fix prefer kernel type 'u8' over 'uint8_t' checks.
Signed-off-by: Shiva Kerdel
---
drivers/staging/ks7010/ks_hostif.c | 4 +-
drivers/staging/ks7010/ks_hostif.h | 114 +--
drivers/staging/ks7010/ks_wlan_net.c | 2 +-
3 files changed, 60
Fix prefer kernel type 'u32' over 'uint32_t' checks.
Signed-off-by: Shiva Kerdel
---
drivers/staging/ks7010/ks_hostif.c | 18 +-
drivers/staging/ks7010/ks_hostif.h | 30 +++---
2 files changed, 24 insertions(+), 24 deletions(-)
diff --git
Fix prefer kernel type 'u8' over 'uint8_t' checks.
Signed-off-by: Shiva Kerdel
---
drivers/staging/ks7010/ks_hostif.c | 4 +-
drivers/staging/ks7010/ks_hostif.h | 114 +--
drivers/staging/ks7010/ks_wlan_net.c | 2 +-
3 files changed, 60 insertions(+), 60
On Sat, Mar 11, 2017 at 01:45:55PM -0800, Eric Biggers wrote:
> From: Eric Biggers
>
> I found that statx() was significantly slower than stat(). As a
> microbenchmark, I compared 10,000,000 invocations of fstat() on a tmpfs
> file to the same with statx() passed a NULL
On Sat, Mar 11, 2017 at 01:45:55PM -0800, Eric Biggers wrote:
> From: Eric Biggers
>
> I found that statx() was significantly slower than stat(). As a
> microbenchmark, I compared 10,000,000 invocations of fstat() on a tmpfs
> file to the same with statx() passed a NULL path:
Umm...
> +
sound/soc/codecs/cs35l35.c:706:2-3: Unneeded semicolon
sound/soc/codecs/cs35l35.c:543:4-5: Unneeded semicolon
sound/soc/codecs/cs35l35.c:553:4-5: Unneeded semicolon
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
CC: Brian Austin
On Sat, Mar 11, 2017 at 09:47:30PM +0100, Julia Lawall wrote:
>
>
> On Sun, 12 Mar 2017, simran singhal wrote:
>
> > Replace strcpy with strlcpy as strcpy does not check for buffer
> > overflow.
> > This is found using Flawfinder.
> >
> > Signed-off-by: simran singhal
On Sat, Mar 11, 2017 at 09:47:30PM +0100, Julia Lawall wrote:
>
>
> On Sun, 12 Mar 2017, simran singhal wrote:
>
> > Replace strcpy with strlcpy as strcpy does not check for buffer
> > overflow.
> > This is found using Flawfinder.
> >
> > Signed-off-by: simran singhal
> > ---
> >
sound/soc/codecs/cs35l35.c:706:2-3: Unneeded semicolon
sound/soc/codecs/cs35l35.c:543:4-5: Unneeded semicolon
sound/soc/codecs/cs35l35.c:553:4-5: Unneeded semicolon
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
CC: Brian Austin
Signed-off-by: Fengguang Wu
On Sun, Mar 12, 2017 at 02:10:01AM +0530, simran singhal wrote:
> Replace strcpy with strlcpy as strcpy does not check for buffer
> overflow.
> This is found using Flawfinder.
>
> Signed-off-by: simran singhal
> ---
> drivers/staging/android/ashmem.c | 3 ++-
> 1 file
On Sun, Mar 12, 2017 at 02:10:01AM +0530, simran singhal wrote:
> Replace strcpy with strlcpy as strcpy does not check for buffer
> overflow.
> This is found using Flawfinder.
>
> Signed-off-by: simran singhal
> ---
> drivers/staging/android/ashmem.c | 3 ++-
> 1 file changed, 2 insertions(+),
Very possible it affects other devices attached, but all consumer
reports and test systems here all have NVME drives on m2 and when in
RAID mode. Listing PCI data linux will show Intel SATA controller
detected in RAID mode, but no drives detected, all you get is your
/dev/sda USB boot device. A
Very possible it affects other devices attached, but all consumer
reports and test systems here all have NVME drives on m2 and when in
RAID mode. Listing PCI data linux will show Intel SATA controller
detected in RAID mode, but no drives detected, all you get is your
/dev/sda USB boot device. A
On 03/10/2017 12:13 PM, Russell King - ARM Linux wrote:
Version 5 gives me no v4l2 controls exposed through the video device
interface.
Just like with version 4, version 5 is completely useless with IMX219:
imx6-mipi-csi2: LP-11 timeout, phy_state = 0x0200
ipu1_csi0: pipeline start
On 03/10/2017 12:13 PM, Russell King - ARM Linux wrote:
Version 5 gives me no v4l2 controls exposed through the video device
interface.
Just like with version 4, version 5 is completely useless with IMX219:
imx6-mipi-csi2: LP-11 timeout, phy_state = 0x0200
ipu1_csi0: pipeline start
On 03/11/2017 03:14 PM, Russell King - ARM Linux wrote:
On Sat, Mar 11, 2017 at 08:25:49AM -0300, Mauro Carvalho Chehab wrote:
This situation is there since 2009. If I remember well, you tried to write
such generic plugin in the past, but never finished it, apparently because
it is too
On 03/11/2017 03:14 PM, Russell King - ARM Linux wrote:
On Sat, Mar 11, 2017 at 08:25:49AM -0300, Mauro Carvalho Chehab wrote:
This situation is there since 2009. If I remember well, you tried to write
such generic plugin in the past, but never finished it, apparently because
it is too
On Sat, Mar 11, 2017 at 07:59:31PM +0800, Wei Wang wrote:
> On 03/11/2017 01:11 AM, Matthew Wilcox wrote:
> > On Fri, Mar 10, 2017 at 05:58:28PM +0200, Michael S. Tsirkin wrote:
> > > One of the issues of current balloon is the 4k page size
> > > assumption. For example if you free a huge page you
On Sat, Mar 11, 2017 at 07:59:31PM +0800, Wei Wang wrote:
> On 03/11/2017 01:11 AM, Matthew Wilcox wrote:
> > On Fri, Mar 10, 2017 at 05:58:28PM +0200, Michael S. Tsirkin wrote:
> > > One of the issues of current balloon is the 4k page size
> > > assumption. For example if you free a huge page you
On Fri, Mar 10, 2017 at 01:25:41PM -0800, Matthew Wilcox wrote:
> On Fri, Mar 10, 2017 at 09:35:21PM +0200, Michael S. Tsirkin wrote:
> > > bit 0 clear => bits 1-11 encode a page count, bits 12-63 encode a PFN,
> > > page size 4k.
> > > bit 0 set, bit 1 clear => bits 2-12 encode a page count,
On Fri, Mar 10, 2017 at 01:25:41PM -0800, Matthew Wilcox wrote:
> On Fri, Mar 10, 2017 at 09:35:21PM +0200, Michael S. Tsirkin wrote:
> > > bit 0 clear => bits 1-11 encode a page count, bits 12-63 encode a PFN,
> > > page size 4k.
> > > bit 0 set, bit 1 clear => bits 2-12 encode a page count,
On Fri, Mar 10, 2017 at 03:46:45PM -0800, Jim Mattson wrote:
> On Thu, Mar 9, 2017 at 2:29 PM, Michael S. Tsirkin wrote:
> > Some guests call mwait without checking the cpu flags. We currently
>
> "Some guests"? What guests other than Mac OS X are so ill-behaved?
I heard about
On Fri, Mar 10, 2017 at 03:46:45PM -0800, Jim Mattson wrote:
> On Thu, Mar 9, 2017 at 2:29 PM, Michael S. Tsirkin wrote:
> > Some guests call mwait without checking the cpu flags. We currently
>
> "Some guests"? What guests other than Mac OS X are so ill-behaved?
I heard about Mac OSX only but
On some architectures, such as arm64, KBUILD_IMAGE is not a full path
but instead just the build target. The builddeb script handles this
case correctly today and will try arch/$ARCH/boot/$KBUILD_IMAGE so we
can just borrow that logic and adapt it slightly for spec file syntax.
Cc: Michal Marek
On some architectures, such as arm64, KBUILD_IMAGE is not a full path
but instead just the build target. The builddeb script handles this
case correctly today and will try arch/$ARCH/boot/$KBUILD_IMAGE so we
can just borrow that logic and adapt it slightly for spec file syntax.
Cc: Michal Marek
On Sat, Mar 11, 2017 at 04:12:49PM -0500, Vivien Didelot wrote:
> Move the configuration of the default ageing time in a new
> mv88e6xxx_atu_setup function.
>
> That function will be extended later to contain all ATU related
> configuration bits.
>
> Signed-off-by: Vivien Didelot
On Sat, Mar 11, 2017 at 04:12:49PM -0500, Vivien Didelot wrote:
> Move the configuration of the default ageing time in a new
> mv88e6xxx_atu_setup function.
>
> That function will be extended later to contain all ATU related
> configuration bits.
>
> Signed-off-by: Vivien Didelot
Reviewed-by:
On Sat, Mar 11, 2017 at 04:13:03PM -0500, Vivien Didelot wrote:
> eth_addr_greater() was introduced for the mv88e6xxx driver, but is not
> used anymore. There is no other user, thus remove this function.
>
> Signed-off-by: Vivien Didelot
Reviewed-by: Andrew
On Fri, 2017-03-10 at 13:10 +0100, Geert Uytterhoeven wrote:
> Hi Ben,
>
> > On Fri, Mar 10, 2017 at 12:46 PM, Ben Hutchings
> > wrote:
> > 3.16.42-rc1 review patch. If anyone has any objections, please let me know.
>
> No objections, but you also want
>
> commit
On Sat, Mar 11, 2017 at 04:13:03PM -0500, Vivien Didelot wrote:
> eth_addr_greater() was introduced for the mv88e6xxx driver, but is not
> used anymore. There is no other user, thus remove this function.
>
> Signed-off-by: Vivien Didelot
Reviewed-by: Andrew Lunn
Andrew
On Fri, 2017-03-10 at 13:10 +0100, Geert Uytterhoeven wrote:
> Hi Ben,
>
> > On Fri, Mar 10, 2017 at 12:46 PM, Ben Hutchings
> > wrote:
> > 3.16.42-rc1 review patch. If anyone has any objections, please let me know.
>
> No objections, but you also want
>
> commit
1 - 100 of 550 matches
Mail list logo