Re: [PATCH v1 1/1] gpio: of: provide option generic property for initial line states

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

Re: [PATCH v1 1/1] gpio: of: provide option generic property for initial line states

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: >

Re: linux-next: build failure after merge of the akpm-current tree

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.

Re: linux-next: build failure after merge of the akpm-current tree

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

[PATCH] ASoC: rockchip: Fix an error handling in 'rockchip_i2s_probe'

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 ---

[PATCH] ASoC: rockchip: Fix an error handling in 'rockchip_i2s_probe'

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

Re: [PATCH 10/18] spi: qup: Fix DMA mode interrupt handling

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:

Re: [PATCH 10/18] spi: qup: Fix DMA mode interrupt handling

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:

[PATCH kernel 1/3] PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag

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

[PATCH kernel 2/3] pci-ioda: Set PCI_BUS_FLAGS_MSI_REMAP for IODA host bridge

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 ---

[PATCH kernel 2/3] pci-ioda: Set PCI_BUS_FLAGS_MSI_REMAP for IODA host bridge

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

[PATCH kernel 1/3] PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag

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

[PATCH kernel 0/3 REPOST] vfio-pci: Add support for mmapping MSI-X table

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

[PATCH kernel 3/3] vfio-pci: Allow to expose MSI-X table to userspace if interrupt remapping is enabled

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

[PATCH kernel 0/3 REPOST] vfio-pci: Add support for mmapping MSI-X table

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

[PATCH kernel 3/3] vfio-pci: Allow to expose MSI-X table to userspace if interrupt remapping is enabled

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

Re: [PATCH kernel 0/3] vfio-pci: Add support for mmapping MSI-X table

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

Re: [PATCH kernel 0/3] vfio-pci: Add support for mmapping MSI-X table

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

Re: [PATCH 2/3] arm: dts: mt2701: Add display bls related nodes for MT2701

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

Re: [PATCH 2/3] arm: dts: mt2701: Add display bls related nodes for MT2701

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

Re: [PATCH 11/18] spi: qup: properly detect extra interrupts

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

Re: [PATCH 11/18] spi: qup: properly detect extra interrupts

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

Re: [PATCH linux] drivers/fsi: Add SBEFIFO FSI client device driver

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; > +

Re: [PATCH linux] drivers/fsi: Add SBEFIFO FSI client device driver

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; > +

Re: [PATCH linux] drivers/fsi: Add SBEFIFO FSI client device driver

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

Re: [PATCH linux] drivers/fsi: Add SBEFIFO FSI client device driver

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

Re: [PATCH linux] drivers/fsi: Add SBEFIFO FSI client device driver

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

Re: [PATCH linux] drivers/fsi: Add SBEFIFO FSI client device driver

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

Re: [PATCH linux] drivers/fsi: Add SBEFIFO FSI client device driver

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

Re: [PATCH linux] drivers/fsi: Add SBEFIFO FSI client device driver

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

Re: [PATCH linux] drivers/fsi: Add SBEFIFO FSI client device driver

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

xgetbv nondeterminism

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

Re: [PATCH linux] drivers/fsi: Add SBEFIFO FSI client device driver

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

xgetbv nondeterminism

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

Re: [PATCH 07/18] spi: qup: Fix transaction done signaling

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

Re: [PATCH 07/18] spi: qup: Fix transaction done signaling

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

Re: [PATCH] objtool: Add fortify_panic as __noreturn function

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

Re: [PATCH] objtool: Add fortify_panic as __noreturn function

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

[PATCH kernel 2/3] pci-ioda: Set PCI_BUS_FLAGS_MSI_REMAP for IODA host bridge

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

[PATCH kernel 3/3] vfio-pci: Allow to expose MSI-X table to userspace if interrupt remapping is enabled

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

[PATCH kernel 1/3] PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag

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

[PATCH kernel 0/3] vfio-pci: Add support for mmapping MSI-X table

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

[PATCH kernel 2/3] pci-ioda: Set PCI_BUS_FLAGS_MSI_REMAP for IODA host bridge

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 |

[PATCH kernel 3/3] vfio-pci: Allow to expose MSI-X table to userspace if interrupt remapping is enabled

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

[PATCH kernel 1/3] PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag

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

[PATCH kernel 0/3] vfio-pci: Add support for mmapping MSI-X table

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

Re: [PATCH] objtool: Add fortify_panic as __noreturn function

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

Re: [PATCH] objtool: Add fortify_panic as __noreturn function

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

linux-next: Tree for Jun 15

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

linux-next: Tree for Jun 15

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

Re: [PATCH] USB: gtco: remove unnecessary variable assignments

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 > --- >

Re: [PATCH] USB: gtco: remove unnecessary variable assignments

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 --

Re: [PATCH v2 03/11] tty: kbd: reduce stack size with KASAN

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

Re: [PATCH v2 03/11] tty: kbd: reduce stack size with KASAN

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

Re: [PATCH v2 03/11] tty: kbd: reduce stack size with KASAN

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': >

Re: [PATCH v2 03/11] tty: kbd: reduce stack size with KASAN

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': >

Re: [PATCH v3 1/9] ARM: dts: imx6ul-isiot: Add Sound card with codec node

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

Re: [PATCH v3 1/9] ARM: dts: imx6ul-isiot: Add Sound card with codec node

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

[PATCH v2] usb: host: ohci-pxa27x: Handle return value of clk_prepare_enable

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

[PATCH v2] usb: host: ohci-pxa27x: Handle return value of clk_prepare_enable

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

Re: [PATCH] objtool: Add fortify_panic as __noreturn function

> 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, >

Re: [PATCH] objtool: Add fortify_panic as __noreturn function

> 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, >

Re: [PATCH 1/3] x86/mm: Provide pmdp_mknotpresent() helper

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

Re: [PATCH 1/3] x86/mm: Provide pmdp_mknotpresent() helper

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

Re: [HMM-CDM 2/5] mm/hmm: add new helper to hotplug CDM memory region

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. > >

Re: [HMM-CDM 2/5] mm/hmm: add new helper to hotplug CDM memory region

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 >

Re: [PATCH] objtool: Add fortify_panic as __noreturn function

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.

Re: [PATCH] objtool: Add fortify_panic as __noreturn function

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 > >

Re: [PATCH] sm501fb: Silence a coccinelle script warning.

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

Re: [PATCH] sm501fb: Silence a coccinelle script warning.

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

Re: [PATCH v2] mfd: Add driver for RAVE Supervisory Processor

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

Re: [PATCH v2] mfd: Add driver for RAVE Supervisory Processor

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

[GIT] Networking

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

[GIT] Networking

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

Re: [PATCH tip/sched/core] Add comments to aid in safer usage of swake_up.

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

Re: [PATCH tip/sched/core] Add comments to aid in safer usage of swake_up.

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

Re: Qemu crashes in -next due to 'of: remove *phandle properties from expanded device tree'

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

Re: Qemu crashes in -next due to 'of: remove *phandle properties from expanded device tree'

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

Re: [PATCH] objtool: Add fortify_panic as __noreturn function

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

Re: [PATCH] objtool: Add fortify_panic as __noreturn function

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 > --- >

Re: [PATCH] dmaengine: qcom-bam: Process multiple pending descriptors

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

Re: [PATCH] dmaengine: qcom-bam: Process multiple pending descriptors

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

Re: [linux-sunxi] Re: [PATCH 1/2] dmaengine: sun6i: make gate bit in sun8i's DMA engines a common quirk

于 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

Re: [linux-sunxi] Re: [PATCH 1/2] dmaengine: sun6i: make gate bit in sun8i's DMA engines a common quirk

于 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

Re: [PATCH v2] ip6_tunnel: Correct tos value in collect_md mode

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”) >

Re: [PATCH v2] ip6_tunnel: Correct tos value in collect_md mode

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

Re: [linux-sunxi] Re: [PATCH 1/2] dmaengine: sun6i: make gate bit in sun8i's DMA engines a common quirk

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

Re: [linux-sunxi] Re: [PATCH 1/2] dmaengine: sun6i: make gate bit in sun8i's DMA engines a common quirk

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

Re: [HMM 07/15] mm/ZONE_DEVICE: new type of ZONE_DEVICE for unaddressable memory v3

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

Re: [HMM 07/15] mm/ZONE_DEVICE: new type of ZONE_DEVICE for unaddressable memory v3

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

Re: [HMM-CDM 3/5] mm/memcontrol: allow to uncharge page without using page->lru field

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

Re: [HMM-CDM 3/5] mm/memcontrol: allow to uncharge page without using page->lru field

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

Re: [PATCH] mm, memory_hotplug: support movable_node for hotplugable nodes

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

Re: [PATCH] mm, memory_hotplug: support movable_node for hotplugable nodes

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

Re: [PATCH 1/1] - Fix reiserfs WARNING in dquot_writeback_dquots

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.

Re: [PATCH 1/1] - Fix reiserfs WARNING in dquot_writeback_dquots

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. > > >

Re: [PATCH v4 2/6] ARM: imx6: register pm_power_off handler if "fsl,pmic-stby-poweroff" is set

+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

Re: [PATCH v4 2/6] ARM: imx6: register pm_power_off handler if "fsl,pmic-stby-poweroff" is set

+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

Investment portfolio

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

Investment portfolio

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   2   3   4   5   6   7   8   9   10   >