[PATCH v2 03/10] dt-bindings: perf: hisi: Add Devicetree bindings for Hisilicon SoC PMU

1) Device tree bindings for Hisilicon SoC PMU. 2) Add example for Hisilicon L3 cache and MN PMU. 3) Add child nodes of L3C and MN in djtag bindings example. Signed-off-by: Anurup M Signed-off-by: Shaokun Zhang ---

[PATCH v2 04/10] Documentation: perf: hisi: Documentation for HIP05/06/07 PMU event counting.

Documentation for perf usage and Hisilicon SoC PMU uncore events. The Hisilicon SOC has event counters for hardware modules like L3 cache, Miscellaneous node etc. These events are all uncore. Signed-off-by: Anurup M Signed-off-by: Shaokun Zhang

Re: [PATCH 3/9] arm64: dts: rockchip: add rk3399 eDP HPD pinctrl

Am Donnerstag, 1. Dezember 2016, 18:27:27 CET schrieb Brian Norris: > We haven't enabled eDP support yet, but we might as well describe the > pin now. > > Signed-off-by: Brian Norris applied for 4.11 Thanks Heiko

Re: [PATCH 3/9] arm64: dts: rockchip: add rk3399 eDP HPD pinctrl

Am Donnerstag, 1. Dezember 2016, 18:27:27 CET schrieb Brian Norris: > We haven't enabled eDP support yet, but we might as well describe the > pin now. > > Signed-off-by: Brian Norris applied for 4.11 Thanks Heiko

[PATCH v2 04/10] Documentation: perf: hisi: Documentation for HIP05/06/07 PMU event counting.

Documentation for perf usage and Hisilicon SoC PMU uncore events. The Hisilicon SOC has event counters for hardware modules like L3 cache, Miscellaneous node etc. These events are all uncore. Signed-off-by: Anurup M Signed-off-by: Shaokun Zhang --- Documentation/perf/hisi-pmu.txt | 75

[PATCH v2 03/10] dt-bindings: perf: hisi: Add Devicetree bindings for Hisilicon SoC PMU

1) Device tree bindings for Hisilicon SoC PMU. 2) Add example for Hisilicon L3 cache and MN PMU. 3) Add child nodes of L3C and MN in djtag bindings example. Signed-off-by: Anurup M Signed-off-by: Shaokun Zhang --- .../devicetree/bindings/arm/hisilicon/djtag.txt| 25 ++

[GIT PULL 00/10] perf/core improvements and fixes

'perf-core-for-mingo-20161205' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core (2016-12-06 09:14:56 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo-20161207 for you to fetch

[PATCH 09/10] perf sched timehist: Cleanup idle_max_cpu handling

From: Namhyung Kim It treats the idle_max_cpu little bit confusingly IMHO. Let's make it more straight forward. Signed-off-by: Namhyung Kim Acked-by: David Ahern Cc: Andi Kleen Cc: Jiri Olsa

[PATCH v2 00/10] perf: arm64: Support for Hisilicon SoC Hardware event counters

Provide Support for Hisilicon SoC(HiP05/06/07) Hardware event counters. The Hisilicon SoC HiP0x series has many uncore or non-CPU performance events and counters units. This patch series is implemented refering to arm-cci, Intel/AMD uncore and also the cavium thunderX and xgene uncore pmu

[PATCH 09/10] perf sched timehist: Cleanup idle_max_cpu handling

From: Namhyung Kim It treats the idle_max_cpu little bit confusingly IMHO. Let's make it more straight forward. Signed-off-by: Namhyung Kim Acked-by: David Ahern Cc: Andi Kleen Cc: Jiri Olsa Cc: Minchan Kim Cc: Peter Zijlstra Link:

[PATCH v2 00/10] perf: arm64: Support for Hisilicon SoC Hardware event counters

Provide Support for Hisilicon SoC(HiP05/06/07) Hardware event counters. The Hisilicon SoC HiP0x series has many uncore or non-CPU performance events and counters units. This patch series is implemented refering to arm-cci, Intel/AMD uncore and also the cavium thunderX and xgene uncore pmu

[GIT PULL 00/10] perf/core improvements and fixes

'perf-core-for-mingo-20161205' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core (2016-12-06 09:14:56 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo-20161207 for you to fetch

[PATCH v2 02/10] dt-bindings: hisi: Add Hisilicon HiP05/06/07 Djtag dts bindings

From: Tan Xiaojun Add Hisilicon HiP05/06/07 Djtag dts bindings for CPU and IO Die Signed-off-by: Tan Xiaojun Signed-off-by: Anurup M --- .../devicetree/bindings/arm/hisilicon/djtag.txt| 41 ++ 1 file

Re: [PATCH 2/9] arm64: dts: rockchip: add rk3399 thermal_zones phandle

Am Donnerstag, 1. Dezember 2016, 18:27:26 CET schrieb Brian Norris: > We're going to need to amend this table in board files. > > Signed-off-by: Brian Norris applied for 4.11 Thanks Heiko

[PATCH v2 02/10] dt-bindings: hisi: Add Hisilicon HiP05/06/07 Djtag dts bindings

From: Tan Xiaojun Add Hisilicon HiP05/06/07 Djtag dts bindings for CPU and IO Die Signed-off-by: Tan Xiaojun Signed-off-by: Anurup M --- .../devicetree/bindings/arm/hisilicon/djtag.txt| 41 ++ 1 file changed, 41 insertions(+) create mode 100644

Re: [PATCH 2/9] arm64: dts: rockchip: add rk3399 thermal_zones phandle

Am Donnerstag, 1. Dezember 2016, 18:27:26 CET schrieb Brian Norris: > We're going to need to amend this table in board files. > > Signed-off-by: Brian Norris applied for 4.11 Thanks Heiko

Re: [PATCH] arm: dts: rockchip: add qos node for rk3288

Am Mittwoch, 7. Dezember 2016, 10:17:45 CET schrieb Elaine Zhang: > when pd power on/off, the qos regs need to save and restore. > > Signed-off-by: Elaine Zhang > --- > arch/arm/boot/dts/rk3288.dtsi | 84 > +++ 1 file changed, 84

Re: [PATCH] arm: dts: rockchip: add qos node for rk3288

Am Mittwoch, 7. Dezember 2016, 10:17:45 CET schrieb Elaine Zhang: > when pd power on/off, the qos regs need to save and restore. > > Signed-off-by: Elaine Zhang > --- > arch/arm/boot/dts/rk3288.dtsi | 84 > +++ 1 file changed, 84 > insertions(+) > > diff

[PATCH 03/10] perf tools: Force fixdep compilation at the start of the build

From: Jiri Olsa The fixdep tool needs to be built before everything else, because it fixes every object dependency file. We handle this currently by making all objects to depend on fixdep, which is error prone and is easily forgotten when new object is added. Instead of this,

[PATCH 01/10] perf build: Check LLVM version in feature check

From: Wang Nan Cancel builtin llvm and clang support when LLVM version is less than 3.9.0: following commits uses newer API. Since Clang/LLVM's API is not guaranteed to be stable, add a test-llvm-version.cpp feature checker, issue warning if LLVM found in compiling

[PATCH v4 4/5] ARM: dts: Add I2C1 support for STM32429 eval board

Signed-off-by: M'boumba Cedric Madianga --- arch/arm/boot/dts/stm32429i-eval.dts | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/boot/dts/stm32429i-eval.dts b/arch/arm/boot/dts/stm32429i-eval.dts index afb90bc..74e0045 100644 ---

[PATCH 08/10] perf sched timehist: Handle zero sample->tid properly

From: Namhyung Kim Sometimes samples have tid of 0 but non-0 pid. It ends up having a new thread of 0 tid/pid (instead of referring idle task) since tid is used to search matching task. But I guess it's wrong to use 0 as a tid when pid is set. This patch uses tid only if

[PATCH 03/10] perf tools: Force fixdep compilation at the start of the build

From: Jiri Olsa The fixdep tool needs to be built before everything else, because it fixes every object dependency file. We handle this currently by making all objects to depend on fixdep, which is error prone and is easily forgotten when new object is added. Instead of this, this patch force

[PATCH 01/10] perf build: Check LLVM version in feature check

From: Wang Nan Cancel builtin llvm and clang support when LLVM version is less than 3.9.0: following commits uses newer API. Since Clang/LLVM's API is not guaranteed to be stable, add a test-llvm-version.cpp feature checker, issue warning if LLVM found in compiling environment is not tested

[PATCH v4 4/5] ARM: dts: Add I2C1 support for STM32429 eval board

Signed-off-by: M'boumba Cedric Madianga --- arch/arm/boot/dts/stm32429i-eval.dts | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/boot/dts/stm32429i-eval.dts b/arch/arm/boot/dts/stm32429i-eval.dts index afb90bc..74e0045 100644 --- a/arch/arm/boot/dts/stm32429i-eval.dts +++

[PATCH 08/10] perf sched timehist: Handle zero sample->tid properly

From: Namhyung Kim Sometimes samples have tid of 0 but non-0 pid. It ends up having a new thread of 0 tid/pid (instead of referring idle task) since tid is used to search matching task. But I guess it's wrong to use 0 as a tid when pid is set. This patch uses tid only if it has a non-zero

[PATCH v4 2/5] i2c: Add STM32F4 I2C driver

This patch adds support for the STM32F4 I2C controller. Signed-off-by: M'boumba Cedric Madianga --- drivers/i2c/busses/Kconfig | 10 + drivers/i2c/busses/Makefile | 1 + drivers/i2c/busses/i2c-stm32f4.c | 857 +++ 3

[PATCH v4 2/5] i2c: Add STM32F4 I2C driver

This patch adds support for the STM32F4 I2C controller. Signed-off-by: M'boumba Cedric Madianga --- drivers/i2c/busses/Kconfig | 10 + drivers/i2c/busses/Makefile | 1 + drivers/i2c/busses/i2c-stm32f4.c | 857 +++ 3 files changed, 868

[PATCH v4 5/5] ARM: configs: Add I2C support for STM32 defconfig

Signed-off-by: M'boumba Cedric Madianga --- arch/arm/configs/stm32_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig index e7b56d4..9494eaf 100644 --- a/arch/arm/configs/stm32_defconfig

[PATCH v4 0/5] Add support for the STM32F4 I2C

This patchset adds support for the I2C controller embedded in STM32F4xx SoC. It enables I2C transfer in interrupt mode with Standard-mode and Fast-mode bus speed. Changes since v3 after Wolfram's review: - Add COMPILE_TEST flag in Kconfig - Use correct driver name in Kconfig i.e i2c-stm32f4

[PATCH v4 3/5] ARM: dts: Add I2C1 support for STM32F429 SoC

Signed-off-by: Patrice Chotard Signed-off-by: M'boumba Cedric Madianga --- arch/arm/boot/dts/stm32f429.dtsi | 23 +++ 1 file changed, 23 insertions(+) diff --git a/arch/arm/boot/dts/stm32f429.dtsi

[PATCH v4 5/5] ARM: configs: Add I2C support for STM32 defconfig

Signed-off-by: M'boumba Cedric Madianga --- arch/arm/configs/stm32_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig index e7b56d4..9494eaf 100644 --- a/arch/arm/configs/stm32_defconfig +++

[PATCH v4 0/5] Add support for the STM32F4 I2C

This patchset adds support for the I2C controller embedded in STM32F4xx SoC. It enables I2C transfer in interrupt mode with Standard-mode and Fast-mode bus speed. Changes since v3 after Wolfram's review: - Add COMPILE_TEST flag in Kconfig - Use correct driver name in Kconfig i.e i2c-stm32f4

[PATCH v4 3/5] ARM: dts: Add I2C1 support for STM32F429 SoC

Signed-off-by: Patrice Chotard Signed-off-by: M'boumba Cedric Madianga --- arch/arm/boot/dts/stm32f429.dtsi | 23 +++ 1 file changed, 23 insertions(+) diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi index 7de52ee..cbdece7 100644 ---

[PATCH v4 1/5] dt-bindings: Document the STM32 I2C bindings

This patch adds documentation of device tree bindings for the STM32 I2C controller. Signed-off-by: M'boumba Cedric Madianga Acked-by: Rob Herring --- .../devicetree/bindings/i2c/i2c-stm32.txt | 33 ++ 1 file changed, 33

[PATCH v4 1/5] dt-bindings: Document the STM32 I2C bindings

This patch adds documentation of device tree bindings for the STM32 I2C controller. Signed-off-by: M'boumba Cedric Madianga Acked-by: Rob Herring --- .../devicetree/bindings/i2c/i2c-stm32.txt | 33 ++ 1 file changed, 33 insertions(+) create mode 100644

[PATCH v2 00/10] perf: arm64: Support for Hisilicon SoC Hardware event counters

From: John Garry Provide Support for Hisilicon SoC(HiP05/06/07) Hardware event counters. The Hisilicon SoC HiP0x series has many uncore or non-CPU performance events and counters units. This patch series is implemented refering to arm-cci, Intel/AMD uncore and also the

[PATCH v2 00/10] perf: arm64: Support for Hisilicon SoC Hardware event counters

From: John Garry Provide Support for Hisilicon SoC(HiP05/06/07) Hardware event counters. The Hisilicon SoC HiP0x series has many uncore or non-CPU performance events and counters units. This patch series is implemented refering to arm-cci, Intel/AMD uncore and also the cavium thunderX and xgene

Re: Does anything ever enter through startup_64 in head_64.S?

Matt Fleming wrote: > > Does anything ever enter the kernel through startup_64 in head_64.S?[*] Do > > all 64-bit mode entries always enter through one of the EFI entry points? > > Which head_64.S? There are two ;-) > > Assuming you mean startup_64 in

Re: Does anything ever enter through startup_64 in head_64.S?

Matt Fleming wrote: > > Does anything ever enter the kernel through startup_64 in head_64.S?[*] Do > > all 64-bit mode entries always enter through one of the EFI entry points? > > Which head_64.S? There are two ;-) > > Assuming you mean startup_64 in boot/compressed/head_64.S, then the >

Re: Tearing down DMA transfer setup after DMA client has finished

Vinod Koul writes: > On Tue, Dec 06, 2016 at 01:14:20PM +, Måns Rullgård wrote: >> >> That's not going to work very well. Device drivers typically request >> dma channels in their probe functions or when the device is opened. >> This means that reserving one of the

Re: Tearing down DMA transfer setup after DMA client has finished

Vinod Koul writes: > On Tue, Dec 06, 2016 at 01:14:20PM +, Måns Rullgård wrote: >> >> That's not going to work very well. Device drivers typically request >> dma channels in their probe functions or when the device is opened. >> This means that reserving one of the few channels there will

Re: [PATCH] mm: page_alloc: High-order per-cpu page allocator v7

On Wed, Dec 07, 2016 at 10:40:47AM -0600, Christoph Lameter wrote: > On Wed, 7 Dec 2016, Mel Gorman wrote: > > > Which is related to the fundamentals of fragmentation control in > > general. At some point there will have to be a revisit to get back to > > the type of reliability that existed in

Re: [PATCH] mm: page_alloc: High-order per-cpu page allocator v7

On Wed, Dec 07, 2016 at 10:40:47AM -0600, Christoph Lameter wrote: > On Wed, 7 Dec 2016, Mel Gorman wrote: > > > Which is related to the fundamentals of fragmentation control in > > general. At some point there will have to be a revisit to get back to > > the type of reliability that existed in

Re: Tearing down DMA transfer setup after DMA client has finished

Vinod Koul writes: > On Tue, Dec 06, 2016 at 01:42:31PM +0100, Mason wrote: >> On 06/12/2016 06:12, Vinod Koul wrote: >> >> > On Tue, Nov 29, 2016 at 07:25:02PM +0100, Mason wrote: >> > >> >> Is there a way to write a driver within the existing framework? >> > >> > I

Re: Tearing down DMA transfer setup after DMA client has finished

Vinod Koul writes: > On Tue, Dec 06, 2016 at 01:42:31PM +0100, Mason wrote: >> On 06/12/2016 06:12, Vinod Koul wrote: >> >> > On Tue, Nov 29, 2016 at 07:25:02PM +0100, Mason wrote: >> > >> >> Is there a way to write a driver within the existing framework? >> > >> > I think so, looking back at

Re: [net-next][PATCH v2 18/18] RDS: IB: add missing connection cache usage info

On 12/7/2016 7:55 AM, David Miller wrote: From: Santosh Shilimkar Date: Tue, 6 Dec 2016 20:01:56 -0800 rds-tools already support it. Signed-off-by: Santosh Shilimkar --- include/uapi/linux/rds.h | 1 + net/rds/ib.c |

Re: [Question] New mmap64 syscall?

Catalin, > On 07 Dec 2016, at 17:32, Catalin Marinas wrote: > >>> In other words: Why not keep ILP32 simple an ask users that need a 16TB+ >>> offset >>> to use LP64? It seems much more consistent with the other choices takes so >>> far. >> >> If user can switch to

Re: [net-next][PATCH v2 18/18] RDS: IB: add missing connection cache usage info

On 12/7/2016 7:55 AM, David Miller wrote: From: Santosh Shilimkar Date: Tue, 6 Dec 2016 20:01:56 -0800 rds-tools already support it. Signed-off-by: Santosh Shilimkar --- include/uapi/linux/rds.h | 1 + net/rds/ib.c | 1 + 2 files changed, 2 insertions(+) diff --git

Re: [Question] New mmap64 syscall?

Catalin, > On 07 Dec 2016, at 17:32, Catalin Marinas wrote: > >>> In other words: Why not keep ILP32 simple an ask users that need a 16TB+ >>> offset >>> to use LP64? It seems much more consistent with the other choices takes so >>> far. >> >> If user can switch to lp64, he doesn't need

Re: [PATCH] mm: page_alloc: High-order per-cpu page allocator v7

On Wed, 7 Dec 2016, Mel Gorman wrote: > Which is related to the fundamentals of fragmentation control in > general. At some point there will have to be a revisit to get back to > the type of reliability that existed in 3.0-era without the massive > overhead it incurred. As stated before, I agree

Re: [PATCH] mm: page_alloc: High-order per-cpu page allocator v7

On Wed, 7 Dec 2016, Mel Gorman wrote: > Which is related to the fundamentals of fragmentation control in > general. At some point there will have to be a revisit to get back to > the type of reliability that existed in 3.0-era without the massive > overhead it incurred. As stated before, I agree

Re: Perf hotplug lockup in v4.9-rc8

On Wed, Dec 07, 2016 at 02:30:58PM +, Mark Rutland wrote: > On Wed, Dec 07, 2016 at 01:52:17PM +, Mark Rutland wrote: > > Hi all > > > > Jeremy noticed a kernel lockup on arm64 when the perf tool was used in > > parallel with hotplug, which I've reproduced on arm64 and x86(-64) with > >

Re: Perf hotplug lockup in v4.9-rc8

On Wed, Dec 07, 2016 at 02:30:58PM +, Mark Rutland wrote: > On Wed, Dec 07, 2016 at 01:52:17PM +, Mark Rutland wrote: > > Hi all > > > > Jeremy noticed a kernel lockup on arm64 when the perf tool was used in > > parallel with hotplug, which I've reproduced on arm64 and x86(-64) with > >

Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel

On Wed, Dec 07, KY Srinivasan wrote: > May be a better solution might be to have a new mechanism to indicate > to the host that all state of the previous incarnation of the kernel > needs to be cleaned up. This will be close to what we have on > hardware. That would be cool, but until this

Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel

On Wed, Dec 07, KY Srinivasan wrote: > May be a better solution might be to have a new mechanism to indicate > to the host that all state of the previous incarnation of the kernel > needs to be cleaned up. This will be close to what we have on > hardware. That would be cool, but until this

Re: [Question] New mmap64 syscall?

On Wed, Dec 07, 2016 at 06:09:44PM +0530, Yury Norov wrote: > On Wed, Dec 07, 2016 at 12:07:24PM +0100, Dr.Philipp Tomsich wrote: > > [Resend, as my mail-client had insisted on using the wrong MIME type…] > > > > > On 07 Dec 2016, at 11:34, Yury Norov wrote: > > > > >

Re: [Question] New mmap64 syscall?

On Wed, Dec 07, 2016 at 06:09:44PM +0530, Yury Norov wrote: > On Wed, Dec 07, 2016 at 12:07:24PM +0100, Dr.Philipp Tomsich wrote: > > [Resend, as my mail-client had insisted on using the wrong MIME type…] > > > > > On 07 Dec 2016, at 11:34, Yury Norov wrote: > > > > > >> If there is a use case

Re: Tearing down DMA transfer setup after DMA client has finished

On Tue, Dec 06, 2016 at 01:42:31PM +0100, Mason wrote: > On 06/12/2016 06:12, Vinod Koul wrote: > > > On Tue, Nov 29, 2016 at 07:25:02PM +0100, Mason wrote: > > > >> Is there a way to write a driver within the existing framework? > > > > I think so, looking back at comments from Russell, I do

Re: Tearing down DMA transfer setup after DMA client has finished

On Tue, Dec 06, 2016 at 01:42:31PM +0100, Mason wrote: > On 06/12/2016 06:12, Vinod Koul wrote: > > > On Tue, Nov 29, 2016 at 07:25:02PM +0100, Mason wrote: > > > >> Is there a way to write a driver within the existing framework? > > > > I think so, looking back at comments from Russell, I do

Re: Tearing down DMA transfer setup after DMA client has finished

On Tue, Dec 06, 2016 at 01:14:20PM +, Måns Rullgård wrote: > > That's not going to work very well. Device drivers typically request > dma channels in their probe functions or when the device is opened. > This means that reserving one of the few channels there will inevitably > make some

Re: Tearing down DMA transfer setup after DMA client has finished

On Tue, Dec 06, 2016 at 01:14:20PM +, Måns Rullgård wrote: > > That's not going to work very well. Device drivers typically request > dma channels in their probe functions or when the device is opened. > This means that reserving one of the few channels there will inevitably > make some

Re: [PATCH 2/2] mtd: spi-nor: add a stateless method to support memory size above 128Mib

On 12/07/2016 05:29 PM, Cyrille Pitchen wrote: > Le 07/12/2016 à 17:20, Marek Vasut a écrit : >> On 12/06/2016 05:52 PM, Cyrille Pitchen wrote: >>> This patch provides an alternative mean to support memory above 16MiB >>> (128Mib) by replacing 3byte address op codes by their associated 4byte >>>

Re: [PATCH 2/2] mtd: spi-nor: add a stateless method to support memory size above 128Mib

On 12/07/2016 05:29 PM, Cyrille Pitchen wrote: > Le 07/12/2016 à 17:20, Marek Vasut a écrit : >> On 12/06/2016 05:52 PM, Cyrille Pitchen wrote: >>> This patch provides an alternative mean to support memory above 16MiB >>> (128Mib) by replacing 3byte address op codes by their associated 4byte >>>

Re: [PATCH v6 0/3] spi-nor: Add support for Intel SPI serial flash controller

On 12/07/2016 09:53 AM, Mika Westerberg wrote: > On Tue, Dec 06, 2016 at 09:45:25AM +, Lee Jones wrote: >> I'm happy either way. However if you take them, I will require a >> pull-request to an immutable branch containing only these patches. >> >> If I take them, it won't be until v4.11,

Re: [PATCH v6 0/3] spi-nor: Add support for Intel SPI serial flash controller

On 12/07/2016 09:53 AM, Mika Westerberg wrote: > On Tue, Dec 06, 2016 at 09:45:25AM +, Lee Jones wrote: >> I'm happy either way. However if you take them, I will require a >> pull-request to an immutable branch containing only these patches. >> >> If I take them, it won't be until v4.11,

Re: [PATCH 1/2] mtd: spi-nor: rename SPINOR_OP_* macros of the 4-byte address op codes

On 12/07/2016 10:51 AM, Mark Brown wrote: > On Tue, Dec 06, 2016 at 05:52:31PM +0100, Cyrille Pitchen wrote: >> This patch renames the SPINOR_OP_* macros of the 4-byte address >> instruction set so the new names all share a common pattern: the 4-byte >> address name is built from the 3-byte

Re: [PATCH 1/2] mtd: spi-nor: rename SPINOR_OP_* macros of the 4-byte address op codes

On 12/07/2016 10:51 AM, Mark Brown wrote: > On Tue, Dec 06, 2016 at 05:52:31PM +0100, Cyrille Pitchen wrote: >> This patch renames the SPINOR_OP_* macros of the 4-byte address >> instruction set so the new names all share a common pattern: the 4-byte >> address name is built from the 3-byte

Re: [PATCH] staging/lustre/osc: Revert erroneous list_for_each_entry_safe use

On Dec 7, 2016, at 5:40 AM, Greg Kroah-Hartman wrote: > On Tue, Dec 06, 2016 at 10:53:48PM -0500, Oleg Drokin wrote: >> I have been having a lot of unexplainable crashes in osc_lru_shrink >> lately that I could not see a good explanation for and then I found >> this patch that slip under the

Re: [PATCH] staging/lustre/osc: Revert erroneous list_for_each_entry_safe use

On Dec 7, 2016, at 5:40 AM, Greg Kroah-Hartman wrote: > On Tue, Dec 06, 2016 at 10:53:48PM -0500, Oleg Drokin wrote: >> I have been having a lot of unexplainable crashes in osc_lru_shrink >> lately that I could not see a good explanation for and then I found >> this patch that slip under the

Re: [PATCH 2/2] mtd: spi-nor: add a stateless method to support memory size above 128Mib

Le 07/12/2016 à 17:20, Marek Vasut a écrit : > On 12/06/2016 05:52 PM, Cyrille Pitchen wrote: >> This patch provides an alternative mean to support memory above 16MiB >> (128Mib) by replacing 3byte address op codes by their associated 4byte >> address versions. >> >> Using the dedicated 4byte

Re: [PATCH 2/2] mtd: spi-nor: add a stateless method to support memory size above 128Mib

Le 07/12/2016 à 17:20, Marek Vasut a écrit : > On 12/06/2016 05:52 PM, Cyrille Pitchen wrote: >> This patch provides an alternative mean to support memory above 16MiB >> (128Mib) by replacing 3byte address op codes by their associated 4byte >> address versions. >> >> Using the dedicated 4byte

Re: [net-next][PATCH v2 10/18] RDS: IB: track and log active side endpoint in connection

On 12/7/2016 7:53 AM, David Miller wrote: From: Santosh Shilimkar Date: Tue, 6 Dec 2016 20:01:48 -0800 @@ -181,6 +181,9 @@ struct rds_ib_connection { /* Batched completions */ unsigned inti_unsignaled_wrs; + + /* Endpoint role

Re: [net-next][PATCH v2 10/18] RDS: IB: track and log active side endpoint in connection

On 12/7/2016 7:53 AM, David Miller wrote: From: Santosh Shilimkar Date: Tue, 6 Dec 2016 20:01:48 -0800 @@ -181,6 +181,9 @@ struct rds_ib_connection { /* Batched completions */ unsigned inti_unsignaled_wrs; + + /* Endpoint role in connection */ + int

Re: [PATCH] i2c: rk3x: keep i2c irq ON in suspend

On 12/06/2016 09:37 PM, David.Wu wrote: > Hi Doug, > > 在 2016/12/7 0:31, Doug Anderson 写道: >> Hi, >> >> On Tue, Dec 6, 2016 at 12:12 AM, David.Wu >> wrote: >>> Hi Heiko, >>> >>> 在 2016/12/5 18:54, Heiko Stuebner 写道: Hi David, Am Montag, 5. Dezember

Re: [PATCH] i2c: rk3x: keep i2c irq ON in suspend

On 12/06/2016 09:37 PM, David.Wu wrote: > Hi Doug, > > 在 2016/12/7 0:31, Doug Anderson 写道: >> Hi, >> >> On Tue, Dec 6, 2016 at 12:12 AM, David.Wu >> wrote: >>> Hi Heiko, >>> >>> 在 2016/12/5 18:54, Heiko Stuebner 写道: Hi David, Am Montag, 5. Dezember 2016, 16:02:59 CET

RE: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel

> -Original Message- > From: Olaf Hering [mailto:o...@aepfle.de] > Sent: Wednesday, December 7, 2016 8:19 AM > To: KY Srinivasan > Cc: vkuzn...@redhat.com; gre...@linuxfoundation.org; linux- > ker...@vger.kernel.org; de...@linuxdriverproject.org > Subject: Re: move

RE: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel

> -Original Message- > From: Olaf Hering [mailto:o...@aepfle.de] > Sent: Wednesday, December 7, 2016 8:19 AM > To: KY Srinivasan > Cc: vkuzn...@redhat.com; gre...@linuxfoundation.org; linux- > ker...@vger.kernel.org; de...@linuxdriverproject.org > Subject: Re: move hyperv

Re: [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

I did something similar. Filled the balloon with 15GB for a 16GB idle guest, by using bitmap, the madvise count was reduced to 605. when using the PFNs, the madvise count was 3932160. It means there are quite a lot consecutive bits in the bitmap. I didn't test for a guest with heavy memory

Re: [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

I did something similar. Filled the balloon with 15GB for a 16GB idle guest, by using bitmap, the madvise count was reduced to 605. when using the PFNs, the madvise count was 3932160. It means there are quite a lot consecutive bits in the bitmap. I didn't test for a guest with heavy memory

Re: [PATCH v2.5 2/3] watchdog: loongson1: Add Loongson1 SoC watchdog driver

On Thu, Dec 08, 2016 at 12:10:58AM +0800, Yang Ling wrote: > Add watchdog timer specific driver for Loongson1 SoC. > > Signed-off-by: Yang Ling Reviewed-by: Guenter Roeck > > --- > V2.5: > Set DEFAULT_HEARTBEAT to 30. > Set heartbeat to 0. > V2.4:

Re: [PATCH v2.5 2/3] watchdog: loongson1: Add Loongson1 SoC watchdog driver

On Thu, Dec 08, 2016 at 12:10:58AM +0800, Yang Ling wrote: > Add watchdog timer specific driver for Loongson1 SoC. > > Signed-off-by: Yang Ling Reviewed-by: Guenter Roeck > > --- > V2.5: > Set DEFAULT_HEARTBEAT to 30. > Set heartbeat to 0. > V2.4: > Set DEFAULT_HEARTBEAT to 0. > V2.3:

Re: [PATCH 2/2] mtd: spi-nor: add a stateless method to support memory size above 128Mib

On 12/06/2016 05:52 PM, Cyrille Pitchen wrote: > This patch provides an alternative mean to support memory above 16MiB > (128Mib) by replacing 3byte address op codes by their associated 4byte > address versions. > > Using the dedicated 4byte address op codes doesn't change the internal > state of

Re: [PATCH 2/2] mtd: spi-nor: add a stateless method to support memory size above 128Mib

On 12/06/2016 05:52 PM, Cyrille Pitchen wrote: > This patch provides an alternative mean to support memory above 16MiB > (128Mib) by replacing 3byte address op codes by their associated 4byte > address versions. > > Using the dedicated 4byte address op codes doesn't change the internal > state of

Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel

On Wed, Dec 07, KY Srinivasan wrote: > Is there a mechanism for stashing away state that can be retrieved in > the context of the execed kernel. I have to find out. To simplify things the new approach may only be used in the kdump case, which already passes various info in cmdline. Most likely

Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel

On Wed, Dec 07, KY Srinivasan wrote: > Is there a mechanism for stashing away state that can be retrieved in > the context of the execed kernel. I have to find out. To simplify things the new approach may only be used in the kdump case, which already passes various info in cmdline. Most likely

Re: [PATCH V1] rtc: ds1307: Add ACPI support

Hi, On 30/11/2016 at 09:57:31 +0700, Tin Huynh wrote : > This patch enables ACPI support for rtc-ds1307 driver. > > Signed-off-by: Tin Huynh > --- > drivers/rtc/rtc-ds1307.c | 51 ++--- > 1 files changed, 43 insertions(+), 8

Re: [PATCH V1] rtc: ds1307: Add ACPI support

Hi, On 30/11/2016 at 09:57:31 +0700, Tin Huynh wrote : > This patch enables ACPI support for rtc-ds1307 driver. > > Signed-off-by: Tin Huynh > --- > drivers/rtc/rtc-ds1307.c | 51 ++--- > 1 files changed, 43 insertions(+), 8 deletions(-) > Applied

Re: [PATCH 4.4 00/13] 4.4.37-stable review

On Wed, Dec 07, 2016 at 08:07:39AM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.37 release. > There are 13 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

Re: [PATCH 4.4 00/13] 4.4.37-stable review

On Wed, Dec 07, 2016 at 08:07:39AM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.37 release. > There are 13 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

Re: [PATCH v5 00/13] net: ethernet: ti: cpts: update and fixes

From: Grygorii Strashko Date: Tue, 6 Dec 2016 18:00:32 -0600 > It is preparation series intended to clean up and optimize TI CPTS driver to > facilitate further integration with other TI's SoCs like Keystone 2. ... Series applied.

Re: [PATCH v5 00/13] net: ethernet: ti: cpts: update and fixes

From: Grygorii Strashko Date: Tue, 6 Dec 2016 18:00:32 -0600 > It is preparation series intended to clean up and optimize TI CPTS driver to > facilitate further integration with other TI's SoCs like Keystone 2. ... Series applied.

Re: [PATCH 6/7] arm: Add livepatch to build if CONFIG_LIVEPATCH

On Wed, Dec 07, 2016 at 04:05:25PM +0100, Petr Mladek wrote: > On Tue 2016-12-06 17:06:06, Abel Vesa wrote: > > Necessary livepatch file added to makefile. > > > > Signed-off-by: Abel Vesa > > --- > > arch/arm/kernel/Makefile | 1 + > > 1 file changed, 1 insertion(+) > > >

Re: [PATCH 6/7] arm: Add livepatch to build if CONFIG_LIVEPATCH

On Wed, Dec 07, 2016 at 04:05:25PM +0100, Petr Mladek wrote: > On Tue 2016-12-06 17:06:06, Abel Vesa wrote: > > Necessary livepatch file added to makefile. > > > > Signed-off-by: Abel Vesa > > --- > > arch/arm/kernel/Makefile | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git

[PATCH v2.5 2/3] watchdog: loongson1: Add Loongson1 SoC watchdog driver

Add watchdog timer specific driver for Loongson1 SoC. Signed-off-by: Yang Ling --- V2.5: Set DEFAULT_HEARTBEAT to 30. Set heartbeat to 0. V2.4: Set DEFAULT_HEARTBEAT to 0. V2.3: Set DEFAULT_HEARTBEAT value to ls1x_wdt->timeout. V2.2: Remove the wide character.

[PATCH v2.5 2/3] watchdog: loongson1: Add Loongson1 SoC watchdog driver

Add watchdog timer specific driver for Loongson1 SoC. Signed-off-by: Yang Ling --- V2.5: Set DEFAULT_HEARTBEAT to 30. Set heartbeat to 0. V2.4: Set DEFAULT_HEARTBEAT to 0. V2.3: Set DEFAULT_HEARTBEAT value to ls1x_wdt->timeout. V2.2: Remove the wide character. Check the return value

RE: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel

> -Original Message- > From: Olaf Hering [mailto:o...@aepfle.de] > Sent: Wednesday, December 7, 2016 7:47 AM > To: KY Srinivasan ; vkuzn...@redhat.com > Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > de...@linuxdriverproject.org > Subject: RE: move

RE: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel

> -Original Message- > From: Olaf Hering [mailto:o...@aepfle.de] > Sent: Wednesday, December 7, 2016 7:47 AM > To: KY Srinivasan ; vkuzn...@redhat.com > Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > de...@linuxdriverproject.org > Subject: RE: move hyperv

Re: [PATCH 4.8 00/35] 4.8.13-stable review

On Wed, Dec 07, 2016 at 08:08:16AM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.8.13 release. > There are 35 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

Re: [Intel-gfx] [PATCH] drm/i915: Remove instructions to file a bug report.

On Mon, Dec 05, 2016 at 04:55:47PM -0800, Matt Turner wrote: > On Sat, Dec 3, 2016 at 1:52 AM, Jani Nikula > wrote: > > On Sat, 03 Dec 2016, Matt Turner wrote: > >> From these instructions, users assume that /sys/class/drm/card0/error > >>

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