Hi Vladimir,
On Sun, Jun 11, 2017 at 10:57:18PM +0300, Vladimir Zapolskiy wrote:
> Hi Oleksij,
>
> On 06/11/2017 09:19 AM, Oleksij Rempel wrote:
> > Hi Rob,
> >
> > On Fri, Jun 09, 2017 at 10:41:30AM -0500, Rob Herring wrote:
> >> On Fri, Jun 9, 2017 at 9:16 AM, Oleksij Rempel
Hi Vladimir,
On Sun, Jun 11, 2017 at 10:57:18PM +0300, Vladimir Zapolskiy wrote:
> Hi Oleksij,
>
> On 06/11/2017 09:19 AM, Oleksij Rempel wrote:
> > Hi Rob,
> >
> > On Fri, Jun 09, 2017 at 10:41:30AM -0500, Rob Herring wrote:
> >> On Fri, Jun 9, 2017 at 9:16 AM, Oleksij Rempel
> >> wrote:
>
Daniel Micay writes:
> ...
>
> The arch mailing list was pinged about this which is how the powerpc
> folks got involved and fixed the issues there, including at least one
> runtime one. Not sure where (if anywhere) those are queued up, but Kees
> could pick those up too.
Daniel Micay writes:
> ...
>
> The arch mailing list was pinged about this which is how the powerpc
> folks got involved and fixed the issues there, including at least one
> runtime one. Not sure where (if anywhere) those are queued up, but Kees
> could pick those up too.
I was expecting Kees to
If this memory allocation fail, we must disable what has been enabled.
Do not return immediately but go thrue the error handling path instead.
Also use 'devm_kmemdup' instead of 'devm_kzalloc+memcpy' to simplify code.
Signed-off-by: Christophe JAILLET
---
If this memory allocation fail, we must disable what has been enabled.
Do not return immediately but go thrue the error handling path instead.
Also use 'devm_kmemdup' instead of 'devm_kzalloc+memcpy' to simplify code.
Signed-off-by: Christophe JAILLET
---
sound/soc/rockchip/rockchip_i2s.c | 9
Hi Andy,
On 6/15/2017 1:36 AM, Andy Gross wrote:
> On Wed, Jun 14, 2017 at 12:51:11PM +0530, Sricharan R wrote:
>> Hi Varada,
>>
>> On 6/14/2017 11:22 AM, Varadarajan Narayanan wrote:
>>> This is needed for v1, where the i/o completion is not
>>> handled in the dma driver.
>>>
>>> Signed-off-by:
Hi Andy,
On 6/15/2017 1:36 AM, Andy Gross wrote:
> On Wed, Jun 14, 2017 at 12:51:11PM +0530, Sricharan R wrote:
>> Hi Varada,
>>
>> On 6/14/2017 11:22 AM, Varadarajan Narayanan wrote:
>>> This is needed for v1, where the i/o completion is not
>>> handled in the dma driver.
>>>
>>> Signed-off-by:
From: Yongji Xie
We introduce a new pci_bus_flags, PCI_BUS_FLAGS_MSI_REMAP
which indicates interrupts of all devices on the bus are
managed by the hardware enabling IRQ remapping(intel naming).
When the capability is enabled, a given PCI device can only
shoot the MSIs
From: Yongji Xie
Any IODA host bridge have the capability of IRQ remapping.
So we set PCI_BUS_FLAGS_MSI_REMAP when this kind of host birdge
is detected.
Signed-off-by: Yongji Xie
Signed-off-by: Alexey Kardashevskiy
---
From: Yongji Xie
Any IODA host bridge have the capability of IRQ remapping.
So we set PCI_BUS_FLAGS_MSI_REMAP when this kind of host birdge
is detected.
Signed-off-by: Yongji Xie
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/platforms/powernv/pci-ioda.c | 8
1 file changed, 8
From: Yongji Xie
We introduce a new pci_bus_flags, PCI_BUS_FLAGS_MSI_REMAP
which indicates interrupts of all devices on the bus are
managed by the hardware enabling IRQ remapping(intel naming).
When the capability is enabled, a given PCI device can only
shoot the MSIs assigned for it. In other
Here is a patchset which Yongji was working on before
leaving IBM LTC. Since we still want to have this functionality
in the kernel (DPDK is the first user), here is a rebase
on the current upstream.
Current vfio-pci implementation disallows to mmap the page
containing MSI-X table in case that
From: Yongji Xie
This patch tries to expose MSI-X tables to userspace if hardware
enables interrupt remapping which can ensure that a given PCI
device can only shoot the MSIs assigned for it. So we could
never worry that userspace driver can hurt other devices by
writing to
Here is a patchset which Yongji was working on before
leaving IBM LTC. Since we still want to have this functionality
in the kernel (DPDK is the first user), here is a rebase
on the current upstream.
Current vfio-pci implementation disallows to mmap the page
containing MSI-X table in case that
From: Yongji Xie
This patch tries to expose MSI-X tables to userspace if hardware
enables interrupt remapping which can ensure that a given PCI
device can only shoot the MSIs assigned for it. So we could
never worry that userspace driver can hurt other devices by
writing to the exposed MSI-X
Ouch, this is a wrong one, please ignore. I'll repost in a sec.
On 15/06/17 15:06, Alexey Kardashevskiy wrote:
> Here is a patchset which Yongji was working on before
> leaving IBM LTC. Since we still want to have this functionality
> in the kernel (DPDK is the first user), here is a rebase
> on
Ouch, this is a wrong one, please ignore. I'll repost in a sec.
On 15/06/17 15:06, Alexey Kardashevskiy wrote:
> Here is a patchset which Yongji was working on before
> leaving IBM LTC. Since we still want to have this functionality
> in the kernel (DPDK is the first user), here is a rebase
> on
On Fri, 2017-06-09 at 10:12 +0200, Matthias Brugger wrote:
>
> On 01/06/17 08:08, Erin Lo wrote:
> > From: YT Shen
>
> I miss the Singed-off-by from YT Shen.
>
> >
> > This patch adds the device node of display backlight for MT2701
> >
> > Signed-off-by: Weiqing Kong
On Fri, 2017-06-09 at 10:12 +0200, Matthias Brugger wrote:
>
> On 01/06/17 08:08, Erin Lo wrote:
> > From: YT Shen
>
> I miss the Singed-off-by from YT Shen.
>
> >
> > This patch adds the device node of display backlight for MT2701
> >
> > Signed-off-by: Weiqing Kong
> > Signed-off-by: Erin
Hi Andy,
On 6/15/2017 1:29 AM, Andy Gross wrote:
> On Wed, Jun 14, 2017 at 12:57:25PM +0530, Sricharan R wrote:
>> Hi Varada,
>>
>> On 6/14/2017 11:22 AM, Varadarajan Narayanan wrote:
>>> It's possible for a SPI transaction to complete and get another
>>> interrupt and have it processed on the
Hi Andy,
On 6/15/2017 1:29 AM, Andy Gross wrote:
> On Wed, Jun 14, 2017 at 12:57:25PM +0530, Sricharan R wrote:
>> Hi Varada,
>>
>> On 6/14/2017 11:22 AM, Varadarajan Narayanan wrote:
>>> It's possible for a SPI transaction to complete and get another
>>> interrupt and have it processed on the
On Wed, Jun 14, 2017 at 02:47:27PM -0500, Edward A. James wrote:
> +struct sbefifo {
> + struct timer_list poll_timer;
> + struct fsi_device *fsi_dev;
> + struct miscdevice mdev;
> + wait_queue_head_t wait;
> + struct list_head link;
> + struct list_head xfrs;
> +
On Wed, Jun 14, 2017 at 02:47:27PM -0500, Edward A. James wrote:
> +struct sbefifo {
> + struct timer_list poll_timer;
> + struct fsi_device *fsi_dev;
> + struct miscdevice mdev;
> + wait_queue_head_t wait;
> + struct list_head link;
> + struct list_head xfrs;
> +
On Wed, Jun 14, 2017 at 02:47:27PM -0500, Edward A. James wrote:
> +static ssize_t sbefifo_read(struct file *file, char __user *buf,
> + size_t len, loff_t *offset)
> +{
> + struct sbefifo_client *client = file->private_data;
> +
> + WARN_ON(*offset);
Huh? Why?
> + if
On Wed, Jun 14, 2017 at 02:47:27PM -0500, Edward A. James wrote:
> +static ssize_t sbefifo_read(struct file *file, char __user *buf,
> + size_t len, loff_t *offset)
> +{
> + struct sbefifo_client *client = file->private_data;
> +
> + WARN_ON(*offset);
Huh? Why?
> + if
On Wed, Jun 14, 2017 at 02:47:27PM -0500, Edward A. James wrote:
> + dev_info(dev, "Found sbefifo device\n");
Don't be chatty, this isn't needed at all, right?
thanks,
greg k-h
On Wed, Jun 14, 2017 at 02:47:27PM -0500, Edward A. James wrote:
> + dev_info(dev, "Found sbefifo device\n");
Don't be chatty, this isn't needed at all, right?
thanks,
greg k-h
On Wed, Jun 14, 2017 at 02:47:27PM -0500, Edward A. James wrote:
> --- /dev/null
> +++ b/include/linux/fsi-sbefifo.h
> @@ -0,0 +1,30 @@
> +/*
> + * SBEFIFO FSI Client device driver
> + *
> + * Copyright (C) IBM Corporation 2017
> + *
> + * This program is free software; you can redistribute it
On Wed, Jun 14, 2017 at 02:47:27PM -0500, Edward A. James wrote:
> --- /dev/null
> +++ b/include/linux/fsi-sbefifo.h
> @@ -0,0 +1,30 @@
> +/*
> + * SBEFIFO FSI Client device driver
> + *
> + * Copyright (C) IBM Corporation 2017
> + *
> + * This program is free software; you can redistribute it
On Wed, Jun 14, 2017 at 02:47:27PM -0500, Edward A. James wrote:
> +static DEFINE_IDA(sbefifo_ida);
WHen your module exits, you don't clean up this structure. Common
mistake :)
thanks,
greg k-h
I saw your post about XGETBV
(http://robert.ocallahan.org/2017/06/another-case-of-obscure-cpu.html),
and it sounds like it could plausibly be a kernel bug. What kernel
are you on?
I wonder if CPUs have an optimization in which, if a given register
set is in the init state but XINUSE=1, then
On Wed, Jun 14, 2017 at 02:47:27PM -0500, Edward A. James wrote:
> +static DEFINE_IDA(sbefifo_ida);
WHen your module exits, you don't clean up this structure. Common
mistake :)
thanks,
greg k-h
I saw your post about XGETBV
(http://robert.ocallahan.org/2017/06/another-case-of-obscure-cpu.html),
and it sounds like it could plausibly be a kernel bug. What kernel
are you on?
I wonder if CPUs have an optimization in which, if a given register
set is in the init state but XINUSE=1, then
Hi Andy,
On 6/15/2017 1:21 AM, Andy Gross wrote:
> On Wed, Jun 14, 2017 at 12:43:43PM +0530, Sricharan R wrote:
>> Hi Varada,
>>
>> On 6/14/2017 11:22 AM, Varadarajan Narayanan wrote:
>>> Wait to signal done until we get all of the interrupts we are expecting
>>> to get for a transaction. If we
Hi Andy,
On 6/15/2017 1:21 AM, Andy Gross wrote:
> On Wed, Jun 14, 2017 at 12:43:43PM +0530, Sricharan R wrote:
>> Hi Varada,
>>
>> On 6/14/2017 11:22 AM, Varadarajan Narayanan wrote:
>>> Wait to signal done until we get all of the interrupts we are expecting
>>> to get for a transaction. If we
Hi Daniel,
On Thu, 15 Jun 2017 00:49:21 -0400 Daniel Micay wrote:
>
> > So after that the errors (x86_64 allmodconfig build) are only:
> >
> > In file included from include/linux/bitmap.h:8:0,
> > from include/linux/cpumask.h:11,
> > from
Hi Daniel,
On Thu, 15 Jun 2017 00:49:21 -0400 Daniel Micay wrote:
>
> > So after that the errors (x86_64 allmodconfig build) are only:
> >
> > In file included from include/linux/bitmap.h:8:0,
> > from include/linux/cpumask.h:11,
> > from
From: Yongji Xie
Any IODA host bridge have the capability of IRQ remapping.
So we set PCI_BUS_FLAGS_MSI_REMAP when this kind of host birdge
is detected.
Signed-off-by: Yongji Xie
Reviewed-by: Alexey Kardashevskiy
From: Yongji Xie
This patch tries to expose MSI-X tables to userspace if hardware
enables interrupt remapping which can ensure that a given PCI
device can only shoot the MSIs assigned for it. So we could
never worry that userspace driver can hurt other devices by
From: Yongji Xie
We introduce a new pci_bus_flags, PCI_BUS_FLAGS_MSI_REMAP
which indicates interrupts of all devices on the bus are
managed by the hardware enabling IRQ remapping(intel naming).
When the capability is enabled, a given PCI device can only
shoot the MSIs
Here is a patchset which Yongji was working on before
leaving IBM LTC. Since we still want to have this functionality
in the kernel (DPDK is the first user), here is a rebase
on the current upstream.
Current vfio-pci implementation disallows to mmap the page
containing MSI-X table in case that
From: Yongji Xie
Any IODA host bridge have the capability of IRQ remapping.
So we set PCI_BUS_FLAGS_MSI_REMAP when this kind of host birdge
is detected.
Signed-off-by: Yongji Xie
Reviewed-by: Alexey Kardashevskiy
Signed-off-by: Paul Mackerras
---
arch/powerpc/platforms/powernv/pci-ioda.c |
From: Yongji Xie
This patch tries to expose MSI-X tables to userspace if hardware
enables interrupt remapping which can ensure that a given PCI
device can only shoot the MSIs assigned for it. So we could
never worry that userspace driver can hurt other devices by
writing to the exposed MSI-X
From: Yongji Xie
We introduce a new pci_bus_flags, PCI_BUS_FLAGS_MSI_REMAP
which indicates interrupts of all devices on the bus are
managed by the hardware enabling IRQ remapping(intel naming).
When the capability is enabled, a given PCI device can only
shoot the MSIs assigned for it. In other
Here is a patchset which Yongji was working on before
leaving IBM LTC. Since we still want to have this functionality
in the kernel (DPDK is the first user), here is a rebase
on the current upstream.
Current vfio-pci implementation disallows to mmap the page
containing MSI-X table in case that
Hi Kees,
On Wed, 14 Jun 2017 19:18:51 -0700 Kees Cook wrote:
>
> CONFIG_FORTIFY_SOURCE implements fortify_panic() as a __noreturn function,
> so objtool needs to know about it too.
>
> Suggested-by: Daniel Micay
> Signed-off-by: Kees Cook
Hi Kees,
On Wed, 14 Jun 2017 19:18:51 -0700 Kees Cook wrote:
>
> CONFIG_FORTIFY_SOURCE implements fortify_panic() as a __noreturn function,
> so objtool needs to know about it too.
>
> Suggested-by: Daniel Micay
> Signed-off-by: Kees Cook
> Cc: Josh Poimboeuf
Tested-by: Stephen Rothwell
Hi all,
Changes since 20170614:
The sound-asoc tree lost its build failure.
The driver-core tree lost its build failure.
The akpm (was akpm-current) tree still had its build failure for which
I reverted a commit.
Non-merge commits (relative to Linus' tree): 6467
6462 files changed, 288178
Hi all,
Changes since 20170614:
The sound-asoc tree lost its build failure.
The driver-core tree lost its build failure.
The akpm (was akpm-current) tree still had its build failure for which
I reverted a commit.
Non-merge commits (relative to Linus' tree): 6467
6462 files changed, 288178
On Wed, 2017-06-14 at 20:50 -0500, Gustavo A. R. Silva wrote:
> Remove unnecessary variable assignments.
> Variable _val_ is overwritten before the value stored in it can be used.
>
> Addresses-Coverity-ID: 1397695
> Signed-off-by: Gustavo A. R. Silva
> ---
>
On Wed, 2017-06-14 at 20:50 -0500, Gustavo A. R. Silva wrote:
> Remove unnecessary variable assignments.
> Variable _val_ is overwritten before the value stored in it can be used.
>
> Addresses-Coverity-ID: 1397695
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/input/tablet/gtco.c | 2 --
On Thu, Jun 15, 2017 at 06:52:21AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jun 14, 2017 at 11:15:38PM +0200, Arnd Bergmann wrote:
> > As reported by kernelci, some functions in the VT code use significant
> > amounts of kernel stack when local variables get inlined into the caller
> > multiple
On Thu, Jun 15, 2017 at 06:52:21AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jun 14, 2017 at 11:15:38PM +0200, Arnd Bergmann wrote:
> > As reported by kernelci, some functions in the VT code use significant
> > amounts of kernel stack when local variables get inlined into the caller
> > multiple
On Wed, Jun 14, 2017 at 11:15:38PM +0200, Arnd Bergmann wrote:
> As reported by kernelci, some functions in the VT code use significant
> amounts of kernel stack when local variables get inlined into the caller
> multiple times:
>
> drivers/tty/vt/keyboard.c: In function 'kbd_keycode':
>
On Wed, Jun 14, 2017 at 11:15:38PM +0200, Arnd Bergmann wrote:
> As reported by kernelci, some functions in the VT code use significant
> amounts of kernel stack when local variables get inlined into the caller
> multiple times:
>
> drivers/tty/vt/keyboard.c: In function 'kbd_keycode':
>
On Thu, Jun 15, 2017 at 7:50 AM, Shawn Guo wrote:
> On Wed, Jun 14, 2017 at 08:17:04PM +0530, Jagan Teki wrote:
>> On Fri, Apr 7, 2017 at 6:46 PM, Shawn Guo wrote:
>> > On Thu, Apr 06, 2017 at 11:32:07PM +0530, Jagan Teki wrote:
>> >> From: Jagan Teki
On Thu, Jun 15, 2017 at 7:50 AM, Shawn Guo wrote:
> On Wed, Jun 14, 2017 at 08:17:04PM +0530, Jagan Teki wrote:
>> On Fri, Apr 7, 2017 at 6:46 PM, Shawn Guo wrote:
>> > On Thu, Apr 06, 2017 at 11:32:07PM +0530, Jagan Teki wrote:
>> >> From: Jagan Teki
>> >>
>> >> Add support for Sound card and
clk_prepare_enable() can fail here and we must check its return value.
Signed-off-by: Arvind Yadav
Changes in v2:
Remove useless initialization of retval.
---
drivers/usb/host/ohci-pxa27x.c | 10 +++---
1 file changed, 7 insertions(+), 3
clk_prepare_enable() can fail here and we must check its return value.
Signed-off-by: Arvind Yadav
Changes in v2:
Remove useless initialization of retval.
---
drivers/usb/host/ohci-pxa27x.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git
> So after that the errors (x86_64 allmodconfig build) are only:
>
> In file included from include/linux/bitmap.h:8:0,
> from include/linux/cpumask.h:11,
> from arch/x86/include/asm/cpumask.h:4,
> from arch/x86/include/asm/msr.h:10,
>
> So after that the errors (x86_64 allmodconfig build) are only:
>
> In file included from include/linux/bitmap.h:8:0,
> from include/linux/cpumask.h:11,
> from arch/x86/include/asm/cpumask.h:4,
> from arch/x86/include/asm/msr.h:10,
>
Hi Kirill,
[auto build test ERROR on mmotm/master]
[also build test ERROR on v4.12-rc5 next-20170614]
[cannot apply to tip/x86/core]
[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/linux/commits/Kirill
Hi Kirill,
[auto build test ERROR on mmotm/master]
[also build test ERROR on v4.12-rc5 next-20170614]
[cannot apply to tip/x86/core]
[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/linux/commits/Kirill
On Wed, 14 Jun 2017 16:11:41 -0400
Jérôme Glisse wrote:
> Unlike unaddressable memory, coherent device memory has a real
> resource associated with it on the system (as CPU can address
> it). Add a new helper to hotplug such memory within the HMM
> framework.
>
>
On Wed, 14 Jun 2017 16:11:41 -0400
Jérôme Glisse wrote:
> Unlike unaddressable memory, coherent device memory has a real
> resource associated with it on the system (as CPU can address
> it). Add a new helper to hotplug such memory within the HMM
> framework.
>
> Signed-off-by: Jérôme Glisse
>
Hi all,
On Thu, 15 Jun 2017 14:05:22 +1000 Stephen Rothwell
wrote:
>
> On Wed, 14 Jun 2017 19:18:51 -0700 Kees Cook wrote:
> >
> > CONFIG_FORTIFY_SOURCE implements fortify_panic() as a __noreturn function,
> > so objtool needs to know about it too.
Hi all,
On Thu, 15 Jun 2017 14:05:22 +1000 Stephen Rothwell
wrote:
>
> On Wed, 14 Jun 2017 19:18:51 -0700 Kees Cook wrote:
> >
> > CONFIG_FORTIFY_SOURCE implements fortify_panic() as a __noreturn function,
> > so objtool needs to know about it too.
> >
> > Suggested-by: Daniel Micay
> >
Le 14/06/2017 à 12:54, Bartlomiej Zolnierkiewicz a écrit :
Hi,
On Monday, May 08, 2017 08:11:16 AM Christophe JAILLET wrote:
According to surrounding goto, it is likely that 'goto err_probed_panel' is
expected here.
This change is just done in order to silence some coccinelle scripts
which try
Le 14/06/2017 à 12:54, Bartlomiej Zolnierkiewicz a écrit :
Hi,
On Monday, May 08, 2017 08:11:16 AM Christophe JAILLET wrote:
According to surrounding goto, it is likely that 'goto err_probed_panel' is
expected here.
This change is just done in order to silence some coccinelle scripts
which try
On Mon, Jun 12, 2017 at 6:23 PM, Andrey Smirnov
wrote:
> Add a driver for RAVE Supervisory Processor, an MCU implementing
> varoius bits of housekeeping functionality (watchdoging, backlight
> control, LED control, etc) on RAVE family of products by Zodiac
> Inflight
On Mon, Jun 12, 2017 at 6:23 PM, Andrey Smirnov
wrote:
> Add a driver for RAVE Supervisory Processor, an MCU implementing
> varoius bits of housekeeping functionality (watchdoging, backlight
> control, LED control, etc) on RAVE family of products by Zodiac
> Inflight Innovations.
>
> This driver
1) The netlink attribute passed in to dev_set_alias() is not
necessarily NULL terminated, don't use strlcpy() on it.
From Alexander Potapenko.
2) Fix implementation of atomics in arm64 bpf JIT, from Daniel
Borkmann.
3) Correct the release of netdevs and driver private data in
1) The netlink attribute passed in to dev_set_alias() is not
necessarily NULL terminated, don't use strlcpy() on it.
From Alexander Potapenko.
2) Fix implementation of atomics in arm64 bpf JIT, from Daniel
Borkmann.
3) Correct the release of netdevs and driver private data in
On Wed, Jun 14, 2017 at 09:25:58AM -0700, Krister Johansen wrote:
> On Wed, Jun 14, 2017 at 11:02:40AM -0400, Steven Rostedt wrote:
> > On Wed, 14 Jun 2017 09:10:15 -0400
> > Steven Rostedt wrote:
> >
> > > Now let's make it simpler. I'll even add the READ_ONCE and
On Wed, Jun 14, 2017 at 09:25:58AM -0700, Krister Johansen wrote:
> On Wed, Jun 14, 2017 at 11:02:40AM -0400, Steven Rostedt wrote:
> > On Wed, 14 Jun 2017 09:10:15 -0400
> > Steven Rostedt wrote:
> >
> > > Now let's make it simpler. I'll even add the READ_ONCE and WRITE_ONCE
> > > where
On 06/14/2017 05:45 PM, Frank Rowand wrote:
On 06/14/17 15:35, Guenter Roeck wrote:
On Wed, Jun 14, 2017 at 02:31:58PM -0700, Frank Rowand wrote:
Hi Guenter,
< snip >
Can you also include the console messages before the "[ cut here ]" line?
http://kerneltests.org/builders
Check qemu
On 06/14/2017 05:45 PM, Frank Rowand wrote:
On 06/14/17 15:35, Guenter Roeck wrote:
On Wed, Jun 14, 2017 at 02:31:58PM -0700, Frank Rowand wrote:
Hi Guenter,
< snip >
Can you also include the console messages before the "[ cut here ]" line?
http://kerneltests.org/builders
Check qemu
Hi Kees,
On Wed, 14 Jun 2017 19:18:51 -0700 Kees Cook wrote:
>
> CONFIG_FORTIFY_SOURCE implements fortify_panic() as a __noreturn function,
> so objtool needs to know about it too.
>
> Suggested-by: Daniel Micay
> Signed-off-by: Kees Cook
Hi Kees,
On Wed, 14 Jun 2017 19:18:51 -0700 Kees Cook wrote:
>
> CONFIG_FORTIFY_SOURCE implements fortify_panic() as a __noreturn function,
> so objtool needs to know about it too.
>
> Suggested-by: Daniel Micay
> Signed-off-by: Kees Cook
> Cc: Josh Poimboeuf
> ---
>
On Wed, Jun 07, 2017 at 05:59:07PM +0530, Sricharan R wrote:
> The bam dmaengine has a circular FIFO to which we
> add hw descriptors that describes the transaction.
> The FIFO has space for about 4096 hw descriptors.
>
> Currently we add one descriptor and wait for it to
> complete with
On Wed, Jun 07, 2017 at 05:59:07PM +0530, Sricharan R wrote:
> The bam dmaengine has a circular FIFO to which we
> add hw descriptors that describes the transaction.
> The FIFO has space for about 4096 hw descriptors.
>
> Currently we add one descriptor and wait for it to
> complete with
于 2017年6月15日 GMT+08:00 上午11:54:08, Vinod Koul 写到:
>On Wed, Jun 14, 2017 at 11:04:39AM +0200, Maxime Ripard wrote:
>> On Wed, Jun 14, 2017 at 02:15:29PM +0530, Vinod Koul wrote:
>> > > SoC info is in compatible, so there's no reason to make it a
>property.
>> >
>> > that's
于 2017年6月15日 GMT+08:00 上午11:54:08, Vinod Koul 写到:
>On Wed, Jun 14, 2017 at 11:04:39AM +0200, Maxime Ripard wrote:
>> On Wed, Jun 14, 2017 at 02:15:29PM +0530, Vinod Koul wrote:
>> > > SoC info is in compatible, so there's no reason to make it a
>property.
>> >
>> > that's why it would need to
On Thu, 15 Jun 2017 10:30:29 +0800
Haishuang Yan wrote:
> Same as ip_gre, geneve and vxlan, use key->tos as tos value.
>
> CC: Peter Dawson
> Fixes: 0e9a709560db ("ip6_tunnel, ip6_gre: fix setting of DSCP on
> encapsulated packets”)
>
On Thu, 15 Jun 2017 10:30:29 +0800
Haishuang Yan wrote:
> Same as ip_gre, geneve and vxlan, use key->tos as tos value.
>
> CC: Peter Dawson
> Fixes: 0e9a709560db ("ip6_tunnel, ip6_gre: fix setting of DSCP on
> encapsulated packets”)
> Suggested-by: Daniel Borkmann
> Signed-off-by: Haishuang
On Wed, Jun 14, 2017 at 11:04:39AM +0200, Maxime Ripard wrote:
> On Wed, Jun 14, 2017 at 02:15:29PM +0530, Vinod Koul wrote:
> > > SoC info is in compatible, so there's no reason to make it a property.
> >
> > that's why it would need to be optional for the SoC's that needs these..
>
> There's
On Wed, Jun 14, 2017 at 11:04:39AM +0200, Maxime Ripard wrote:
> On Wed, Jun 14, 2017 at 02:15:29PM +0530, Vinod Koul wrote:
> > > SoC info is in compatible, so there's no reason to make it a property.
> >
> > that's why it would need to be optional for the SoC's that needs these..
>
> There's
On 2017/5/25 1:20, Jérôme Glisse wrote:
> HMM (heterogeneous memory management) need struct page to support migration
> from system main memory to device memory. Reasons for HMM and migration to
> device memory is explained with HMM core patch.
>
> This patch deals with device memory that is
On 2017/5/25 1:20, Jérôme Glisse wrote:
> HMM (heterogeneous memory management) need struct page to support migration
> from system main memory to device memory. Reasons for HMM and migration to
> device memory is explained with HMM core patch.
>
> This patch deals with device memory that is
On Wed, 14 Jun 2017 16:11:42 -0400
Jérôme Glisse wrote:
> HMM pages (private or public device pages) are ZONE_DEVICE page and
> thus you can not use page->lru fields of those pages. This patch
> re-arrange the uncharge to allow single page to be uncharge without
> modifying
On Wed, 14 Jun 2017 16:11:42 -0400
Jérôme Glisse wrote:
> HMM pages (private or public device pages) are ZONE_DEVICE page and
> thus you can not use page->lru fields of those pages. This patch
> re-arrange the uncharge to allow single page to be uncharge without
> modifying the lru field of the
On Thu, Jun 08, 2017 at 02:23:18PM +0200, Michal Hocko wrote:
>From: Michal Hocko
>
>movable_node kernel parameter allows to make hotplugable NUMA
>nodes to put all the hotplugable memory into movable zone which
>allows more or less reliable memory hotremove. At least this
>is
On Thu, Jun 08, 2017 at 02:23:18PM +0200, Michal Hocko wrote:
>From: Michal Hocko
>
>movable_node kernel parameter allows to make hotplugable NUMA
>nodes to put all the hotplugable memory into movable zone which
>allows more or less reliable memory hotremove. At least this
>is the case for the
Any comments? Can we get this merged, or some variation? It affects a
lot more than just all my machines. Google shows this traceback is
occurring for others as well.
On Mon, May 29, 2017 at 12:57 AM, Tim Savannah wrote:
> Oops, sent last one without patch on accident.
Any comments? Can we get this merged, or some variation? It affects a
lot more than just all my machines. Google shows this traceback is
occurring for others as well.
On Mon, May 29, 2017 at 12:57 AM, Tim Savannah wrote:
> Oops, sent last one without patch on accident. Attached this time.
>
>
>
+Leonard, in case he wants to have a look.
One small comment below ...
On Fri, Jun 09, 2017 at 04:07:35PM +0200, Oleksij Rempel wrote:
> One of the Freescale recommended sequences for power off with external
> PMIC is the following:
> ...
> 3. SoC is programming PMIC for power off when standby
+Leonard, in case he wants to have a look.
One small comment below ...
On Fri, Jun 09, 2017 at 04:07:35PM +0200, Oleksij Rempel wrote:
> One of the Freescale recommended sequences for power off with external
> PMIC is the following:
> ...
> 3. SoC is programming PMIC for power off when standby
Hello,
How are you today?
we have the financial capability to finance any investment portfolio as far as
is it genuine, all we need is a capable business partner that possesses
investment strategies or profitable business information for good turn over
within 10-20years.
We can provide proof
Hello,
How are you today?
we have the financial capability to finance any investment portfolio as far as
is it genuine, all we need is a capable business partner that possesses
investment strategies or profitable business information for good turn over
within 10-20years.
We can provide proof
1 - 100 of 2098 matches
Mail list logo