Re: [PATCH v1 1/2] x86/KASLR: Fix physical memory calculation on KASLR memory randomization

On Mon, Aug 8, 2016 at 11:40 AM, Thomas Garnier wrote: > Initialize KASLR memory randomization after max_pfn is initialized. Also > ensure the size is rounded up. Could have create problems on machines > with more than 1Tb of memory on certain random addresses. > >

Re: [PATCH v1 1/2] x86/KASLR: Fix physical memory calculation on KASLR memory randomization

On Mon, Aug 8, 2016 at 11:40 AM, Thomas Garnier wrote: > Initialize KASLR memory randomization after max_pfn is initialized. Also > ensure the size is rounded up. Could have create problems on machines > with more than 1Tb of memory on certain random addresses. > > Signed-off-by: Thomas Garnier

[PATCH] misc: mic: constify mic_smpt_ops structure

The mic_smpt_ops structure is never modified, so declare is as const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/misc/mic/host/mic_device.h |2 +- drivers/misc/mic/host/mic_x100.c |2 +- drivers/misc/mic/host/mic_x100.h |2

[PATCH] misc: mic: constify mic_smpt_ops structure

The mic_smpt_ops structure is never modified, so declare is as const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/misc/mic/host/mic_device.h |2 +- drivers/misc/mic/host/mic_x100.c |2 +- drivers/misc/mic/host/mic_x100.h |2 +- 3 files changed, 3

rtc regression [463a86304cae ("char/genrtc: x86: remove remnants of asm/rtc.h")]

Hi, commit 463a86304cae ("char/genrtc: x86: remove remnants of asm/rtc.h") broke rtc for me. Neither hwclock or rtcwake work anymore. This is just a very standard x86-64 IVB box, and it was reported that machines in our i915 test farm are having rtc related problems as well. The first time I run

rtc regression [463a86304cae ("char/genrtc: x86: remove remnants of asm/rtc.h")]

Hi, commit 463a86304cae ("char/genrtc: x86: remove remnants of asm/rtc.h") broke rtc for me. Neither hwclock or rtcwake work anymore. This is just a very standard x86-64 IVB box, and it was reported that machines in our i915 test farm are having rtc related problems as well. The first time I run

Re: [PATCH v2 00/10] usb: ulpi: remove "dev" field from struct ulpi_ops

On Tue, Aug 9, 2016 at 5:04 PM, Greg KH wrote: > On Mon, Aug 01, 2016 at 09:15:48PM +0300, Tal Shorer wrote: >> struct ulpi_ops is defined as follows: >> >> struct ulpi_ops { >> struct device *dev; >> int (*read)(struct ulpi_ops *ops, u8 addr); >>

Re: [PATCH v2 00/10] usb: ulpi: remove "dev" field from struct ulpi_ops

On Tue, Aug 9, 2016 at 5:04 PM, Greg KH wrote: > On Mon, Aug 01, 2016 at 09:15:48PM +0300, Tal Shorer wrote: >> struct ulpi_ops is defined as follows: >> >> struct ulpi_ops { >> struct device *dev; >> int (*read)(struct ulpi_ops *ops, u8 addr); >> int (*write)(struct

Re: [PATCH v2] mm/slub: Run free_partial() outside of the kmem_cache_node->list_lock

On Tue, Aug 09, 2016 at 06:45:39PM +0300, Vladimir Davydov wrote: > On Tue, Aug 09, 2016 at 04:27:46PM +0100, Chris Wilson wrote: > ... > > diff --git a/mm/slub.c b/mm/slub.c > > index 825ff45..58f0eb6 100644 > > --- a/mm/slub.c > > +++ b/mm/slub.c > > @@ -3479,6 +3479,7 @@ static void

Re: [PATCH v2] mm/slub: Run free_partial() outside of the kmem_cache_node->list_lock

On Tue, Aug 09, 2016 at 06:45:39PM +0300, Vladimir Davydov wrote: > On Tue, Aug 09, 2016 at 04:27:46PM +0100, Chris Wilson wrote: > ... > > diff --git a/mm/slub.c b/mm/slub.c > > index 825ff45..58f0eb6 100644 > > --- a/mm/slub.c > > +++ b/mm/slub.c > > @@ -3479,6 +3479,7 @@ static void

Re: drivers/pinctrl/intel/pinctrl-merrifield.c:518:10: error: implicit declaration of function 'readl'

On Mon, 2016-08-08 at 09:41 +0800, kbuild test robot wrote: > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux > .git master > head:   29b4817d4018df78086157ea3a55c1d9424a7cfc > commit: 4e80c8f505741cbdef3e10862ea36057e8d85e7c pinctrl: intel: Add > Intel Merrifield pin

Re: drivers/pinctrl/intel/pinctrl-merrifield.c:518:10: error: implicit declaration of function 'readl'

On Mon, 2016-08-08 at 09:41 +0800, kbuild test robot wrote: > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux > .git master > head:   29b4817d4018df78086157ea3a55c1d9424a7cfc > commit: 4e80c8f505741cbdef3e10862ea36057e8d85e7c pinctrl: intel: Add > Intel Merrifield pin

perf: fuzzer: spinlock hang

So still haswell/4.8-rc1, after 6 hours of fuzzing this is where the system finally locked up permanently. It looks like some sort of spinlock error. The logs continued being spammed with this stuff overnight until I finally put it out of its misery, but I think just the beginning here is the

perf: fuzzer: spinlock hang

So still haswell/4.8-rc1, after 6 hours of fuzzing this is where the system finally locked up permanently. It looks like some sort of spinlock error. The logs continued being spammed with this stuff overnight until I finally put it out of its misery, but I think just the beginning here is the

Re: [PATCH] mm/slub: Run free_partial() outside of the kmem_cache_node->list_lock

On Tue, Aug 09, 2016 at 03:46:32PM +0100, Chris Wilson wrote: ... > diff --git a/mm/slub.c b/mm/slub.c > index 850737bdfbd8..22b2c1f3db0e 100644 > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -3629,11 +3629,15 @@ static void list_slab_objects(struct kmem_cache *s, > struct page *page, > */ > static

Re: [PATCH] mm/slub: Run free_partial() outside of the kmem_cache_node->list_lock

On Tue, Aug 09, 2016 at 03:46:32PM +0100, Chris Wilson wrote: ... > diff --git a/mm/slub.c b/mm/slub.c > index 850737bdfbd8..22b2c1f3db0e 100644 > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -3629,11 +3629,15 @@ static void list_slab_objects(struct kmem_cache *s, > struct page *page, > */ > static

[PATCH] pci: adding support for PCI_MSI_IRQ_DOMAIN in ARC arch

To fix this, this patch adds ARC as a PCI_MSI_IRQ_DOMAIN supportive platform and adds the generation of msi.h in the ARC arch. Signed-off-by: Joao Pinto --- arch/arc/include/asm/Kbuild | 1 + drivers/pci/Kconfig | 2 +- 2 files changed, 2 insertions(+), 1

[PATCH] pci: adding support for PCI_MSI_IRQ_DOMAIN in ARC arch

To fix this, this patch adds ARC as a PCI_MSI_IRQ_DOMAIN supportive platform and adds the generation of msi.h in the ARC arch. Signed-off-by: Joao Pinto --- arch/arc/include/asm/Kbuild | 1 + drivers/pci/Kconfig | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git

Re: [PATCH] tpm: fix a race condition tpm2_unseal_trusted()

On Tue, Aug 09, 2016 at 01:36:29PM +0300, Jarkko Sakkinen wrote: > Functionally my patch should not break anything. I understand the need > for clean up of locking but why doing this now to make the driver > non-racy would make clean up later on any harder? Then rename the functions so they

Re: [PATCH] tpm: fix a race condition tpm2_unseal_trusted()

On Tue, Aug 09, 2016 at 01:36:29PM +0300, Jarkko Sakkinen wrote: > Functionally my patch should not break anything. I understand the need > for clean up of locking but why doing this now to make the driver > non-racy would make clean up later on any harder? Then rename the functions so they

Re: [PATCH v2 00/14] net: ethernet: ti: cpsw: split driver data and per ndev data

On 08/06/2016 01:48 PM, Ivan Khoronzhuk wrote: In dual_emac mode the driver can handle 2 network devices. Each of them can use its own private data and common data/resources. This patchset splits common driver data/resources and private per net device data. It leads to: - reduce memory usage -

Re: [PATCH v2 00/14] net: ethernet: ti: cpsw: split driver data and per ndev data

On 08/06/2016 01:48 PM, Ivan Khoronzhuk wrote: In dual_emac mode the driver can handle 2 network devices. Each of them can use its own private data and common data/resources. This patchset splits common driver data/resources and private per net device data. It leads to: - reduce memory usage -

Re: [PATCH v2 10/14] net; ethernet: ti: cpsw: move irq stuff under cpsw_common

On 08/06/2016 01:48 PM, Ivan Khoronzhuk wrote: The irq data are common per net device. So no need to hold these May be rephrase it a bit. data per net dev, move it under cpsw_common. Also delete irq_num var, as after optimization it's not needed. Correct number of irqs to 2, as anyway,

Re: [PATCH v2 10/14] net; ethernet: ti: cpsw: move irq stuff under cpsw_common

On 08/06/2016 01:48 PM, Ivan Khoronzhuk wrote: The irq data are common per net device. So no need to hold these May be rephrase it a bit. data per net dev, move it under cpsw_common. Also delete irq_num var, as after optimization it's not needed. Correct number of irqs to 2, as anyway,

Re: [PATCH v2 0/3] Add DSP control nodes for K2G

On 8/9/2016 7:33 AM, Andrew F. Davis wrote: Hello all, This series adds the nodes needed to control the DSP available on this SoC. These are similar to the nodes already present the other K2x SoCs. Thanks, Andrew Andrew F. Davis (3): ARM: dts: keystone-k2g: Add device state controller node

Re: [PATCH v2 0/3] Add DSP control nodes for K2G

On 8/9/2016 7:33 AM, Andrew F. Davis wrote: Hello all, This series adds the nodes needed to control the DSP available on this SoC. These are similar to the nodes already present the other K2x SoCs. Thanks, Andrew Andrew F. Davis (3): ARM: dts: keystone-k2g: Add device state controller node

[PACTH v4 1/2] usb: xhci: plat: Enable runtime PM

From: Robert Foss Enable runtime PM for the xhci-plat device so that the parent device may implement runtime PM. Signed-off-by: Robert Foss Tested-by: Robert Foss --- drivers/usb/host/xhci-plat.c | 26

[PACTH v4 1/2] usb: xhci: plat: Enable runtime PM

From: Robert Foss Enable runtime PM for the xhci-plat device so that the parent device may implement runtime PM. Signed-off-by: Robert Foss Tested-by: Robert Foss --- drivers/usb/host/xhci-plat.c | 26 -- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git

[PACTH v4 0/2] usb: xhci: plat: Enable PM, async resume/suspend

From: Robert Foss This series enables runtime PM and asynchronous resume/suspend support for xhci-plat devices. Changes since v1: - Added Signed-off-by: Robert Foss - Added proper metadata tags to series Changes since v2: - Added missing

[PACTH v4 2/2] usb: xhci: plat: Enable async suspend/resume

From: Andrew Bresticker USB host controllers can take a significant amount of time to suspend and resume, adding several hundred miliseconds to the kernel resume time. Since the XHCI controller has no outside dependencies (other than clocks, which are suspended

[PACTH v4 0/2] usb: xhci: plat: Enable PM, async resume/suspend

From: Robert Foss This series enables runtime PM and asynchronous resume/suspend support for xhci-plat devices. Changes since v1: - Added Signed-off-by: Robert Foss - Added proper metadata tags to series Changes since v2: - Added missing changelog to cover-letter - Added error checking to

[PACTH v4 2/2] usb: xhci: plat: Enable async suspend/resume

From: Andrew Bresticker USB host controllers can take a significant amount of time to suspend and resume, adding several hundred miliseconds to the kernel resume time. Since the XHCI controller has no outside dependencies (other than clocks, which are suspended late/resumed early), allow it to

Re: [PATCH 2/4] kernfs: make kernfs_path*() behave in the style of strlcpy()

Quoting Tejun Heo (t...@kernel.org): > kernfs_path*() functions always return the length of the full path but > the path content is undefined if the length is larger than the > provided buffer. This makes its behavior different from strlcpy() and > requires error handling in all its users even

Re: [PATCH 2/4] kernfs: make kernfs_path*() behave in the style of strlcpy()

Quoting Tejun Heo (t...@kernel.org): > kernfs_path*() functions always return the length of the full path but > the path content is undefined if the length is larger than the > provided buffer. This makes its behavior different from strlcpy() and > requires error handling in all its users even

Re: [PACTH v3 1/2] usb: xhci: plat: Enable runtime PM

On 2016-08-09 05:19 AM, Felipe Balbi wrote: Hi, robert.f...@collabora.com writes: From: Andrew Bresticker Enable runtime PM for the xhci-plat device so that the parent device may implement runtime PM. Signed-off-by: Andrew Bresticker

Re: [PACTH v3 1/2] usb: xhci: plat: Enable runtime PM

On 2016-08-09 05:19 AM, Felipe Balbi wrote: Hi, robert.f...@collabora.com writes: From: Andrew Bresticker Enable runtime PM for the xhci-plat device so that the parent device may implement runtime PM. Signed-off-by: Andrew Bresticker Tested-by: Robert Foss Signed-off-by: Robert Foss

Re: [lkp] [fs] 6141b4d642: xfstests.generic.079.fail

On Tue, Aug 09, 2016 at 11:14:38PM +0800, kernel test robot wrote: > > FYI, we noticed the following commit: > > https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus > commit 6141b4d64295ec08a1b48c7fcac8a566658cd64f ("fs: return EPERM on > immutable inode") > > in testcase:

Re: [lkp] [fs] 6141b4d642: xfstests.generic.079.fail

On Tue, Aug 09, 2016 at 11:14:38PM +0800, kernel test robot wrote: > > FYI, we noticed the following commit: > > https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus > commit 6141b4d64295ec08a1b48c7fcac8a566658cd64f ("fs: return EPERM on > immutable inode") > > in testcase:

Re: [PATCH v4 2/4] mfd: Add Samsung Exynos Low Power Audio Subsystem driver

On 08/09/2016 05:05 PM, Lee Jones wrote: >> +static SIMPLE_DEV_PM_OPS(lpass_pm_ops, exynos_lpass_suspend, >> > + exynos_lpass_resume); > Put this up by the PM functions. Sorry, I don't understand this comment, which PM functions do you mean exactly? -- Thanks,

Re: [PATCH v4 2/4] mfd: Add Samsung Exynos Low Power Audio Subsystem driver

On 08/09/2016 05:05 PM, Lee Jones wrote: >> +static SIMPLE_DEV_PM_OPS(lpass_pm_ops, exynos_lpass_suspend, >> > + exynos_lpass_resume); > Put this up by the PM functions. Sorry, I don't understand this comment, which PM functions do you mean exactly? -- Thanks,

Re: [PATCH 2/2] befs: fix typo in befs_sb_info

On 09/08/16 14:46, Salah Triki wrote: > Fixing jornal to Journal. > > Signed-off-by: Salah Triki > --- > fs/befs/befs.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/befs/befs.h b/fs/befs/befs.h > index 511d16d..55f3ea2 100644 > ---

Re: [PATCH 2/2] befs: fix typo in befs_sb_info

On 09/08/16 14:46, Salah Triki wrote: > Fixing jornal to Journal. > > Signed-off-by: Salah Triki > --- > fs/befs/befs.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/befs/befs.h b/fs/befs/befs.h > index 511d16d..55f3ea2 100644 > --- a/fs/befs/befs.h > +++

Re: [PATCH 1/2] befs: add flags field to validate superblock state

On 09/08/16 14:46, Salah Triki wrote: > For validating superblock state, add flags field to befs_sb_info, read the > state from the disk > and check if it is equal to BEFS_DIRTY. > > Signed-off-by: Salah Triki > --- > fs/befs/befs.h | 3 +++ > fs/befs/super.c | 4 +++- >

Re: [PATCH 1/2] befs: add flags field to validate superblock state

On 09/08/16 14:46, Salah Triki wrote: > For validating superblock state, add flags field to befs_sb_info, read the > state from the disk > and check if it is equal to BEFS_DIRTY. > > Signed-off-by: Salah Triki > --- > fs/befs/befs.h | 3 +++ > fs/befs/super.c | 4 +++- > 2 files changed, 6

Re: [PATCH V3 1/3] tracing: add a possibility of exporting function trace to other places instead of ring buffer only

On Tue, 9 Aug 2016 14:32:39 +0800 Chunyan Zhang wrote: > Currently ring buffer is the only output of Function traces, this patch > added trace_export concept which would process the traces and export > traces to a registered destination which can be ring buffer or some

Re: [PATCH V3 1/3] tracing: add a possibility of exporting function trace to other places instead of ring buffer only

On Tue, 9 Aug 2016 14:32:39 +0800 Chunyan Zhang wrote: > Currently ring buffer is the only output of Function traces, this patch > added trace_export concept which would process the traces and export > traces to a registered destination which can be ring buffer or some other > storage, in this

Re: [PATCH v4] mfd: dm355evm_msp: Refactoring for add_child()

On Tue, 09 Aug 2016, SF Markus Elfring wrote: > > But the change-log in this patch says "I did some stuff". > > What stuff did you change? Which review comments did you > > tend to? > > I imagine that I could increase the description granularity > to a detail level which you might also not

Re: [PATCH v4] mfd: dm355evm_msp: Refactoring for add_child()

On Tue, 09 Aug 2016, SF Markus Elfring wrote: > > But the change-log in this patch says "I did some stuff". > > What stuff did you change? Which review comments did you > > tend to? > > I imagine that I could increase the description granularity > to a detail level which you might also not

Re: [PATCH] iommu/exynos: Modify error handling

On Mon, Aug 01, 2016 at 11:48:38AM +0530, Amitoj Kaur Chawla wrote: > of_platform_device_create returns NULL on error so an IS_ERR test is > incorrect here and a NULL check is required. > > The Coccinelle semantic patch used to make this change is as follows: > @@ > expression e; > @@ > > e =

Re: [PATCH] iommu/exynos: Modify error handling

On Mon, Aug 01, 2016 at 11:48:38AM +0530, Amitoj Kaur Chawla wrote: > of_platform_device_create returns NULL on error so an IS_ERR test is > incorrect here and a NULL check is required. > > The Coccinelle semantic patch used to make this change is as follows: > @@ > expression e; > @@ > > e =

Re: [PATCH v5 2/2] mfd: Add Samsung Exynos Low Power Audio Subsystem driver

On Tue, 09 Aug 2016, Sylwester Nawrocki wrote: > This patch adds common driver for the Top block of the Samsung Exynos SoC > Low Power Audio Subsystem. This is a minimal driver which prepares resources > for IP blocks like I2S, audio DMA and UART and exposes a regmap for the Top > block

Re: [PATCH v5 2/2] mfd: Add Samsung Exynos Low Power Audio Subsystem driver

On Tue, 09 Aug 2016, Sylwester Nawrocki wrote: > This patch adds common driver for the Top block of the Samsung Exynos SoC > Low Power Audio Subsystem. This is a minimal driver which prepares resources > for IP blocks like I2S, audio DMA and UART and exposes a regmap for the Top > block

[PATCH v2] mm/slub: Run free_partial() outside of the kmem_cache_node->list_lock

With debugobjects enabled and using SLAB_DESTROY_BY_RCU, when a kmem_cache_node is destroyed the call_rcu() may trigger a slab allocation to fill the debug object pool (__debug_object_init:fill_pool). Everywhere but during kmem_cache_destroy(), discard_slab() is performed outside of the

[PATCH v2] mm/slub: Run free_partial() outside of the kmem_cache_node->list_lock

With debugobjects enabled and using SLAB_DESTROY_BY_RCU, when a kmem_cache_node is destroyed the call_rcu() may trigger a slab allocation to fill the debug object pool (__debug_object_init:fill_pool). Everywhere but during kmem_cache_destroy(), discard_slab() is performed outside of the

Re: [Patch v3 10/11] driver/edac/layerscape_edac: Add Layerscape EDAC support

On 08/09/2016 04:12 AM, Will Deacon wrote: > On Mon, Aug 08, 2016 at 07:56:04PM +, york sun wrote: >> On 08/08/2016 11:07 AM, Marc Zyngier wrote: >>> On Thu, 4 Aug 2016 15:58:35 -0700 >>> York Sun wrote: >>> Add DDR EDAC for ARM-based compatible controllers. Both

Re: [Patch v3 10/11] driver/edac/layerscape_edac: Add Layerscape EDAC support

On 08/09/2016 04:12 AM, Will Deacon wrote: > On Mon, Aug 08, 2016 at 07:56:04PM +, york sun wrote: >> On 08/08/2016 11:07 AM, Marc Zyngier wrote: >>> On Thu, 4 Aug 2016 15:58:35 -0700 >>> York Sun wrote: >>> Add DDR EDAC for ARM-based compatible controllers. Both big-endian and

Re: [PATCH 1/3] radix-tree: 'slot' can be NULL in radix_tree_next_slot()

On Mon, Aug 08, 2016 at 10:21:39PM +0300, Konstantin Khlebnikov wrote: <> > NAK. This is fast path and it's already bloated. > I want to revert most changes here and rework "multiorder" entries. > > Here you can find almost ready patchset for that >

Re: [PATCH 1/3] radix-tree: 'slot' can be NULL in radix_tree_next_slot()

On Mon, Aug 08, 2016 at 10:21:39PM +0300, Konstantin Khlebnikov wrote: <> > NAK. This is fast path and it's already bloated. > I want to revert most changes here and rework "multiorder" entries. > > Here you can find almost ready patchset for that >

Re: [PATCH v4 1/2] mfd: ti-smusbdig: Add support for the TI SM-USB-DIG

On Tue, 09 Aug 2016, Andrew F. Davis wrote: > The TI SM-USB-DIG is a USB to SPI/I2C/1Wire/GPIO adapter. > Add MFD core support. > > Signed-off-by: Andrew F. Davis > --- > drivers/mfd/Kconfig | 9 +++ > drivers/mfd/Makefile| 2 + >

Re: [PATCH v4 1/2] mfd: ti-smusbdig: Add support for the TI SM-USB-DIG

On Tue, 09 Aug 2016, Andrew F. Davis wrote: > The TI SM-USB-DIG is a USB to SPI/I2C/1Wire/GPIO adapter. > Add MFD core support. > > Signed-off-by: Andrew F. Davis > --- > drivers/mfd/Kconfig | 9 +++ > drivers/mfd/Makefile| 2 + > drivers/mfd/ti-smusbdig.c |

[PATCH v2] console: Don't prefer first registered if DT specifies stdout-path

If a device tree specifies a preferred device for kernel console output via the stdout-path or linux,stdout-path chosen node properties or the stdout alias then the kernel ought to honor it & output the kernel console to that device. As it stands, this isn't the case. Whilst we parse the

Re: [PATCH] drivers: net: cpsw: fix kmemleak false-positive reports for sk buffers

On Tue, Aug 09, 2016 at 03:09:44PM +0300, Grygorii Strashko wrote: > diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c > index 0805855..0456e0e 100644 > --- a/drivers/net/ethernet/ti/cpsw.c > +++ b/drivers/net/ethernet/ti/cpsw.c > @@ -732,6 +732,7 @@ static void

[PATCH v2] console: Don't prefer first registered if DT specifies stdout-path

If a device tree specifies a preferred device for kernel console output via the stdout-path or linux,stdout-path chosen node properties or the stdout alias then the kernel ought to honor it & output the kernel console to that device. As it stands, this isn't the case. Whilst we parse the

Re: [PATCH] drivers: net: cpsw: fix kmemleak false-positive reports for sk buffers

On Tue, Aug 09, 2016 at 03:09:44PM +0300, Grygorii Strashko wrote: > diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c > index 0805855..0456e0e 100644 > --- a/drivers/net/ethernet/ti/cpsw.c > +++ b/drivers/net/ethernet/ti/cpsw.c > @@ -732,6 +732,7 @@ static void

Re: [PATCH -next] iommu/amd: Fix non static symbol warning

On Thu, Jul 28, 2016 at 02:09:53AM +, Wei Yongjun wrote: > Fixes the following sparse warning: > > drivers/iommu/amd_iommu.c:106:1: warning: > symbol '__pcpu_scope_flush_queue' was not declared. Should it be static? > > Signed-off-by: Wei Yongjun Applied, thanks.

Re: [PATCH -next] iommu/amd: Fix non static symbol warning

On Thu, Jul 28, 2016 at 02:09:53AM +, Wei Yongjun wrote: > Fixes the following sparse warning: > > drivers/iommu/amd_iommu.c:106:1: warning: > symbol '__pcpu_scope_flush_queue' was not declared. Should it be static? > > Signed-off-by: Wei Yongjun Applied, thanks.

Re: [PATCH -next] iommu/amd: Fix error return code in irq_remapping_alloc()

On Thu, Jul 28, 2016 at 02:10:26AM +, Wei Yongjun wrote: > Fix to return a negative error code from the alloc_irq_index() error > handling case instead of 0, as done elsewhere in this function. > > Signed-off-by: Wei Yongjun Applied, thanks.

Re: [PATCH -next] iommu/amd: Fix error return code in irq_remapping_alloc()

On Thu, Jul 28, 2016 at 02:10:26AM +, Wei Yongjun wrote: > Fix to return a negative error code from the alloc_irq_index() error > handling case instead of 0, as done elsewhere in this function. > > Signed-off-by: Wei Yongjun Applied, thanks.

perf: fuzzer general protection fault

still processing all the fallout from yesterday's fuzzer run on Haswell/4.8-rc1. This one was a general protection fault, you can see in RAX that it read in some slab poisoning. Not sure if it is related to the other issues. It looks like it is coming through _perf_event_disable() via

perf: fuzzer general protection fault

still processing all the fallout from yesterday's fuzzer run on Haswell/4.8-rc1. This one was a general protection fault, you can see in RAX that it read in some slab poisoning. Not sure if it is related to the other issues. It looks like it is coming through _perf_event_disable() via

[PATCH v3 0/2] Add board support for TS-4900

This patch serie adds support for TS-4900 System on Module (SoM). This board, manufactured by Technologic Systems, is based on an i.MX6. The i.MX6 exists in 2 flavours: single/dualcore or quadcore. I've added TS-4900 device tree files for both flavour of the i.MX6. The current device tree does

[PATCH v3 0/2] Add board support for TS-4900

This patch serie adds support for TS-4900 System on Module (SoM). This board, manufactured by Technologic Systems, is based on an i.MX6. The i.MX6 exists in 2 flavours: single/dualcore or quadcore. I've added TS-4900 device tree files for both flavour of the i.MX6. The current device tree does

[PATCH v3 2/2] ARM: dts: TS-4900: add basic device tree

These device trees add support for TS-4900 by Technologic Systems. More details here: http://wiki.embeddedarm.com/wiki/TS-4900 Signed-off-by: Lucile Quirion --- arch/arm/boot/dts/Makefile| 2 + arch/arm/boot/dts/imx6dl-ts4900.dts | 49

[PATCH v3 1/2] of: documentation: add bindings documentation for TS-4900

This adds the documentation for the TS-4900 by Technologic Systems. Signed-off-by: Lucile Quirion Acked-by: Rob Herring --- Documentation/devicetree/bindings/arm/technologic.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git

[PATCH v3 2/2] ARM: dts: TS-4900: add basic device tree

These device trees add support for TS-4900 by Technologic Systems. More details here: http://wiki.embeddedarm.com/wiki/TS-4900 Signed-off-by: Lucile Quirion --- arch/arm/boot/dts/Makefile| 2 + arch/arm/boot/dts/imx6dl-ts4900.dts | 49

[PATCH v3 1/2] of: documentation: add bindings documentation for TS-4900

This adds the documentation for the TS-4900 by Technologic Systems. Signed-off-by: Lucile Quirion Acked-by: Rob Herring --- Documentation/devicetree/bindings/arm/technologic.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/technologic.txt

Re: [PATCH 4.4 00/68] 4.4.17-stable review

On 08/08/2016 01:10 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.17 release. > There are 68 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

[lkp] [net] 2647cffb2b: general protection fault: 0000 [#1] SMP

pend 'ip=vm-intel12-1G-1::dhcp root=/dev/ram0 user=lkp job=/lkp/scheduled/vm-intel12-1G-1/boot-1-debian-x86_64-2015-02-07.cgz-2647cffb2bc6fbed163d377390eb7ca552c7c1cb-20160809-29283-1s4umfr-0.yaml ARCH=x86_64 kconfig=x86_64-nfsroot branch=linux-devel/devel-ca

Re: [PATCH 4.6 00/96] 4.6.6-stable review

On 08/08/2016 01:10 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.6.6 release. > There are 96 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.4 00/68] 4.4.17-stable review

On 08/08/2016 01:10 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.17 release. > There are 68 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

[lkp] [net] 2647cffb2b: general protection fault: 0000 [#1] SMP

pend 'ip=vm-intel12-1G-1::dhcp root=/dev/ram0 user=lkp job=/lkp/scheduled/vm-intel12-1G-1/boot-1-debian-x86_64-2015-02-07.cgz-2647cffb2bc6fbed163d377390eb7ca552c7c1cb-20160809-29283-1s4umfr-0.yaml ARCH=x86_64 kconfig=x86_64-nfsroot branch=linux-devel/devel-ca

Re: [PATCH 4.6 00/96] 4.6.6-stable review

On 08/08/2016 01:10 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.6.6 release. > There are 96 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH] console: Don't prefer first registered if DT specifies stdout-path

Hi Paul, [auto build test WARNING on linus/master] [also build test WARNING on v4.8-rc1 next-20160809] [cannot apply to linux/master] [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/Paul-Burton

Re: [PATCH] console: Don't prefer first registered if DT specifies stdout-path

Hi Paul, [auto build test WARNING on linus/master] [also build test WARNING on v4.8-rc1 next-20160809] [cannot apply to linux/master] [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/Paul-Burton

Re: [Intel-wired-lan] e1000e: PHY cann't be initialized correctly on some I218 controllers

On 8/7/2016 11:56, Denis Turischev wrote: Hi Raanan, On 08/04/2016 07:18 PM, Raanan Avargil wrote: It is hard to determine what is exactly the problem here and what causes the -3 error, but this is not the place to perform hw reset and retry to init the phy. I agree that may be this is not

[lkp] [x86/KASLR] 20067c4c13: kernel BUG at arch/x86/mm/physaddr.c:26!

FYI, we noticed the following commit: https://github.com/0day-ci/linux Thomas-Garnier/x86-KASLR-Fix-physical-memory-calculation-on-KASLR-memory-randomization/20160809-024226 commit 20067c4c139c7213205acd1c4b6f3e6d68327267 ("x86/KASLR: Fix physical memory calculation on KASLR m

Re: [Intel-wired-lan] e1000e: PHY cann't be initialized correctly on some I218 controllers

On 8/7/2016 11:56, Denis Turischev wrote: Hi Raanan, On 08/04/2016 07:18 PM, Raanan Avargil wrote: It is hard to determine what is exactly the problem here and what causes the -3 error, but this is not the place to perform hw reset and retry to init the phy. I agree that may be this is not

[lkp] [x86/KASLR] 20067c4c13: kernel BUG at arch/x86/mm/physaddr.c:26!

FYI, we noticed the following commit: https://github.com/0day-ci/linux Thomas-Garnier/x86-KASLR-Fix-physical-memory-calculation-on-KASLR-memory-randomization/20160809-024226 commit 20067c4c139c7213205acd1c4b6f3e6d68327267 ("x86/KASLR: Fix physical memory calculation on KASLR m

Re: [PATCH 3.14 00/21] 3.14.75-stable review

On 08/08/2016 01:09 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.14.75 release. > There are 21 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 3.14 00/21] 3.14.75-stable review

On 08/08/2016 01:09 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.14.75 release. > There are 21 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH v4 2/4] mfd: Add Samsung Exynos Low Power Audio Subsystem driver

On Tue, 05 Jul 2016, Sylwester Nawrocki wrote: > This patch adds common driver for the Top block of the Samsung Exynos > SoC Low Power Audio Subsystem. This is a minimal driver which prepares > resources for IP blocks like I2S, audio DMA and UART and exposes a regmap > for the Top block

Re: [PATCH v4 2/4] mfd: Add Samsung Exynos Low Power Audio Subsystem driver

On Tue, 05 Jul 2016, Sylwester Nawrocki wrote: > This patch adds common driver for the Top block of the Samsung Exynos > SoC Low Power Audio Subsystem. This is a minimal driver which prepares > resources for IP blocks like I2S, audio DMA and UART and exposes a regmap > for the Top block

Re: [PATCH 2/2] perf ppc64le: Fix probe location when using DWARF

Em Tue, Aug 09, 2016 at 11:02:40PM +0900, Masami Hiramatsu escreveu: > On Tue, 9 Aug 2016 01:23:25 -0500 > Ravi Bangoria wrote: > > > Powerpc has Global Entry Point and Local Entry Point for functions. > > LEP catches call from both the GEP and the LEP. Symbol

Re: [PATCH 2/2] perf ppc64le: Fix probe location when using DWARF

Em Tue, Aug 09, 2016 at 11:02:40PM +0900, Masami Hiramatsu escreveu: > On Tue, 9 Aug 2016 01:23:25 -0500 > Ravi Bangoria wrote: > > > Powerpc has Global Entry Point and Local Entry Point for functions. > > LEP catches call from both the GEP and the LEP. Symbol table of ELF > > contains GEP and

Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons

On 09/08/16 14:20, Jon Hunter wrote: > > On 09/08/16 05:25, John Stultz wrote: > > ... > >> So actually no. We usually call irqd_set_trigger_type() but something >> still doesn't work. >> >> Interestingly, just adding irq_set_irq_type(virq, type); to the top of >> that block (leaving the rest

Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons

On 09/08/16 14:20, Jon Hunter wrote: > > On 09/08/16 05:25, John Stultz wrote: > > ... > >> So actually no. We usually call irqd_set_trigger_type() but something >> still doesn't work. >> >> Interestingly, just adding irq_set_irq_type(virq, type); to the top of >> that block (leaving the rest

Re: "Failed to create /dev/root: -14" after commit e6978e4bf1 ("ARM: save and reset the address limit when entering an exception")

Hi Russell King, On jeu., août 04 2016, Russell King - ARM Linux wrote: > On Wed, Aug 03, 2016 at 08:07:02AM -0700, Guenter Roeck wrote: >> On 08/03/2016 01:38 AM, Russell King - ARM Linux wrote: >> >On Tue, Aug 02, 2016 at 07:51:45PM -0700, Guenter Roeck wrote: >>

Re: "Failed to create /dev/root: -14" after commit e6978e4bf1 ("ARM: save and reset the address limit when entering an exception")

Hi Russell King, On jeu., août 04 2016, Russell King - ARM Linux wrote: > On Wed, Aug 03, 2016 at 08:07:02AM -0700, Guenter Roeck wrote: >> On 08/03/2016 01:38 AM, Russell King - ARM Linux wrote: >> >On Tue, Aug 02, 2016 at 07:51:45PM -0700, Guenter Roeck wrote: >> >>Hi, >> >> >> >>I see the

Re: [PATCH 1/4] media: pci: netup_unidvb: don't print error when adding adapter fails

> Sometimes it better to show more message - especially in error conditions :) Sure, if they contain additional information. > btw, do you make sanity check for "duplicate" log messages ? I checked all error messages if they contain additional information. >         ret =

Re: [PATCH 1/4] media: pci: netup_unidvb: don't print error when adding adapter fails

> Sometimes it better to show more message - especially in error conditions :) Sure, if they contain additional information. > btw, do you make sanity check for "duplicate" log messages ? I checked all error messages if they contain additional information. >         ret =

<    5   6   7   8   9   10   11   12   13   14   >