Re: linux-next - lockdep whine in MMC/SDHC code

ly 10 > > [2.623472] == > [2.623548] [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ] > [2.623638] 4.7.0-rc4-next-20160627-dirty #303 Not tainted > [2.623733] -- > [2.623817] kworker/2:1/49

Re: linux-next - lockdep whine in MMC/SDHC code

ly 10 > > [2.623472] == > [2.623548] [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ] > [2.623638] 4.7.0-rc4-next-20160627-dirty #303 Not tainted > [2.623733] -- > [2.623817] kworker/2:1/49

RE: [PATCH 2/4] dmaengine: vdma: Add support for mulit-channel dma mode

Hi Vinod, Thanks for the review... > > > > > > /** > > > > > > + * struct xilinx_mcdma_config - DMA Multi channel > > > > > > +configuration structure > > > > > > + * @tdest: Channel to operate on > > > > > > + * @tid: Channel configuration > > > > > > + * @tuser: Tuser configuration

RE: [PATCH 2/4] dmaengine: vdma: Add support for mulit-channel dma mode

Hi Vinod, Thanks for the review... > > > > > > /** > > > > > > + * struct xilinx_mcdma_config - DMA Multi channel > > > > > > +configuration structure > > > > > > + * @tdest: Channel to operate on > > > > > > + * @tid: Channel configuration > > > > > > + * @tuser: Tuser configuration

[PATCH v2 4/9] tty: serial: fsl_lpuart: fix clearing of receive flag

From: Stefan Agner Commit 8e4934c6d6c6 ("tty: serial: fsl_lpuart: clear receive flag on FIFO flush") implemented clearing of the receive flag by reading the status register only. It turned out that even though we flush the FIFO afterwards, a explicit read of the data register is

[PATCH v2 4/9] tty: serial: fsl_lpuart: fix clearing of receive flag

From: Stefan Agner Commit 8e4934c6d6c6 ("tty: serial: fsl_lpuart: clear receive flag on FIFO flush") implemented clearing of the receive flag by reading the status register only. It turned out that even though we flush the FIFO afterwards, a explicit read of the data register is still required.

[PATCH v2 1/9] tty: serial: fsl_lpuart: consider TX FIFO too in tx_empty

From: Stefan Agner Currently the tx_empty callback only considers the Transmit Complete Flag (TC). The reference manual is not quite clear if the TC flag covers the TX FIFO too. Debug prints on real hardware have shown that from time to time the TC flag is asserted (indicating

[PATCH v2 1/9] tty: serial: fsl_lpuart: consider TX FIFO too in tx_empty

From: Stefan Agner Currently the tx_empty callback only considers the Transmit Complete Flag (TC). The reference manual is not quite clear if the TC flag covers the TX FIFO too. Debug prints on real hardware have shown that from time to time the TC flag is asserted (indicating Transmitter idle)

Re: [PATCH net-next 6/9] net: hns: normalize two different loop

On 2016/6/27 20:13, Andy Shevchenko wrote: On Mon, 2016-06-27 at 05:08 -0700, Joe Perches wrote: On Mon, 2016-06-27 at 15:00 +0300, Andy Shevchenko wrote: On Mon, 2016-06-27 at 04:49 -0700, Joe Perches wrote: On Mon, 2016-06-27 at 17:54 +0800, Yisen Zhuang wrote: From: Daode Huang

Re: [PATCH net-next 6/9] net: hns: normalize two different loop

On 2016/6/27 20:13, Andy Shevchenko wrote: On Mon, 2016-06-27 at 05:08 -0700, Joe Perches wrote: On Mon, 2016-06-27 at 15:00 +0300, Andy Shevchenko wrote: On Mon, 2016-06-27 at 04:49 -0700, Joe Perches wrote: On Mon, 2016-06-27 at 17:54 +0800, Yisen Zhuang wrote: From: Daode Huang There

Re: [PATCH v3 1/3]nbd: fix might_sleep warning on socket shutdown

Hi Markus, On Fri, Jun 24, 2016 at 3:39 PM, Pranay Kr. Srivastava wrote: > spinlocked ranges should be small and not contain calls into huge > subfunctions. Fix my mistake and just get the pointer to the socket > instead of doing everything with spinlock held. > > Reported-by:

Re: [PATCH v3 1/3]nbd: fix might_sleep warning on socket shutdown

Hi Markus, On Fri, Jun 24, 2016 at 3:39 PM, Pranay Kr. Srivastava wrote: > spinlocked ranges should be small and not contain calls into huge > subfunctions. Fix my mistake and just get the pointer to the socket > instead of doing everything with spinlock held. > > Reported-by: Mikulas Patocka >

Re: [PATCH] arc: warn only once if DW2_UNWIND is disabled

Hi Vineet, On Tue, 2016-06-28 at 10:00 +0530, Vineet Gupta wrote: > On Thursday 23 June 2016 01:30 PM, Alexey Brodkin wrote: > > > > If CONFIG_ARC_DW2_UNWIND is disabled every time arc_unwind_core() > > gets called following message gets printed in debug console: > >

Re: [PATCH 2/3] powerpc/spinlock: support vcpu preempted check

On 2016年06月28日 13:03, Boqun Feng wrote: On Tue, Jun 28, 2016 at 11:39:18AM +0800, xinhui wrote: [snip] +{ + struct lppaca *lp = _of(cpu); + + if (unlikely(!(lppaca_shared_proc(lp) || + lppaca_dedicated_proc(lp Do you want to detect whether we are

Re: [PATCH 2/3] powerpc/spinlock: support vcpu preempted check

On 2016年06月28日 13:03, Boqun Feng wrote: On Tue, Jun 28, 2016 at 11:39:18AM +0800, xinhui wrote: [snip] +{ + struct lppaca *lp = _of(cpu); + + if (unlikely(!(lppaca_shared_proc(lp) || + lppaca_dedicated_proc(lp Do you want to detect whether we are

Re: [PATCH] arc: warn only once if DW2_UNWIND is disabled

Hi Vineet, On Tue, 2016-06-28 at 10:00 +0530, Vineet Gupta wrote: > On Thursday 23 June 2016 01:30 PM, Alexey Brodkin wrote: > > > > If CONFIG_ARC_DW2_UNWIND is disabled every time arc_unwind_core() > > gets called following message gets printed in debug console: > >

Re: [PATCH 5/8] KEYS: Provide software public key query function [ver #2]

On Mon, Jun 27, 2016 at 03:27:13PM +0100, David Howells wrote: > > I have some patches I need to finish revamping. I had it kind of working > (though with a slightly different user interface) - then TPMv2 support was > added to the TPM driver before I finished and I need to redo the patches. In

Re: [PATCH 5/8] KEYS: Provide software public key query function [ver #2]

On Mon, Jun 27, 2016 at 03:27:13PM +0100, David Howells wrote: > > I have some patches I need to finish revamping. I had it kind of working > (though with a slightly different user interface) - then TPMv2 support was > added to the TPM driver before I finished and I need to redo the patches. In

[RFC/PATCH v2] ftrace: Reduce size of function graph entries

Currently ftrace_graph_ent{,_entry} and ftrace_graph_ret{,_entry} struct can have padding bytes at the end due to alignment in 64-bit data type. As these data are recorded so frequently, those paddings waste non-negligible space. As some archs can have efficient unaligned accesses, reducing the

[RFC/PATCH v2] ftrace: Reduce size of function graph entries

Currently ftrace_graph_ent{,_entry} and ftrace_graph_ret{,_entry} struct can have padding bytes at the end due to alignment in 64-bit data type. As these data are recorded so frequently, those paddings waste non-negligible space. As some archs can have efficient unaligned accesses, reducing the

Re: [PATCH 1/2] ipc/sem.c: Fix complex_count vs. simple op race

On Thu, 23 Jun 2016, Manfred Spraul wrote: What I'm not sure yet is if smp_load_acquire() is sufficient: Thread A: if (!READ_ONCE(sma->complex_mode)) { The code is test_and_test, no barrier requirements for first test Yeah, it would just make us take the big lock unnecessarily,

Re: [PATCH 1/2] ipc/sem.c: Fix complex_count vs. simple op race

On Thu, 23 Jun 2016, Manfred Spraul wrote: What I'm not sure yet is if smp_load_acquire() is sufficient: Thread A: if (!READ_ONCE(sma->complex_mode)) { The code is test_and_test, no barrier requirements for first test Yeah, it would just make us take the big lock unnecessarily,

Re: [PATCH 0/4] ftrace: One more check on x86 and some small fixes

On Mon, Jun 27, 2016 at 10:54 PM, Petr Mladek wrote: > 1st patch adds one more paranoid check of the modified function on x86. > > Plus there are 3 small changes that appeared when hunting down > the 1st patch. For the series, Acked-by: Namhyung Kim

Re: [PATCH 0/4] ftrace: One more check on x86 and some small fixes

On Mon, Jun 27, 2016 at 10:54 PM, Petr Mladek wrote: > 1st patch adds one more paranoid check of the modified function on x86. > > Plus there are 3 small changes that appeared when hunting down > the 1st patch. For the series, Acked-by: Namhyung Kim Thanks, Namhyung > > Petr Mladek (4): >

Re: [PATCH V3] tracing: Make latency tracers fully support the set_graph_notrace

Hello, On Fri, Jun 24, 2016 at 7:55 PM, Chunyu Hu wrote: > latency tracers(wakeup, wakeup_rt, wakeup_dl, irqsoff) can use the > function_graph trace when display_graph trace option is set by user > via tracefs. And currently the set_graph_notrace filter is not fully > supported

Re: [PATCH V3] tracing: Make latency tracers fully support the set_graph_notrace

Hello, On Fri, Jun 24, 2016 at 7:55 PM, Chunyu Hu wrote: > latency tracers(wakeup, wakeup_rt, wakeup_dl, irqsoff) can use the > function_graph trace when display_graph trace option is set by user > via tracefs. And currently the set_graph_notrace filter is not fully > supported in latency

[PATCH v2 0/2] Add mt6755 basic chip support

This patch adds basic support for Mediatek's new 8-core chip, mt6755. Based on 4.7-rc1 Changes in v2: 1. use evb as project suffix 2. add "disable" property for uart dts nodes 3. only alias uart0 as serial0, since we don't enable uart1 Mars Cheng (2): Document: DT: Add bindings for mediatek

[PATCH v2 0/2] Add mt6755 basic chip support

This patch adds basic support for Mediatek's new 8-core chip, mt6755. Based on 4.7-rc1 Changes in v2: 1. use evb as project suffix 2. add "disable" property for uart dts nodes 3. only alias uart0 as serial0, since we don't enable uart1 Mars Cheng (2): Document: DT: Add bindings for mediatek

[PATCH v2 1/2] Document: DT: Add bindings for mediatek MT6755 SoC Platform

This adds DT binding documentation for Mediatek MT6755. Signed-off-by: Mars Cheng --- Documentation/devicetree/bindings/arm/mediatek.txt |4 .../interrupt-controller/mediatek,sysirq.txt |1 + .../devicetree/bindings/serial/mtk-uart.txt|1 +

[PATCH v2 2/2] arm64: dts: mediatek: add mt6755 support

This adds basic chip support for MT6755 SoC. Signed-off-by: Mars Cheng --- arch/arm64/boot/dts/mediatek/Makefile |1 + arch/arm64/boot/dts/mediatek/mt6755-evb.dts | 38 +++ arch/arm64/boot/dts/mediatek/mt6755.dtsi| 145 +++ 3

[PATCH v2 1/2] Document: DT: Add bindings for mediatek MT6755 SoC Platform

This adds DT binding documentation for Mediatek MT6755. Signed-off-by: Mars Cheng --- Documentation/devicetree/bindings/arm/mediatek.txt |4 .../interrupt-controller/mediatek,sysirq.txt |1 + .../devicetree/bindings/serial/mtk-uart.txt|1 + 3 files changed, 6

[PATCH v2 2/2] arm64: dts: mediatek: add mt6755 support

This adds basic chip support for MT6755 SoC. Signed-off-by: Mars Cheng --- arch/arm64/boot/dts/mediatek/Makefile |1 + arch/arm64/boot/dts/mediatek/mt6755-evb.dts | 38 +++ arch/arm64/boot/dts/mediatek/mt6755.dtsi| 145 +++ 3 files changed, 184

RE: [PATCH v3 2/3] iio: Add driver for Broadcom iproc-static-adc

> -Original Message- > From: Jonathan Cameron [mailto:ji...@kernel.org] > Sent: 28 June 2016 00:41 > To: Raveendra Padasalagi > Cc: Peter Meerwald-Stadler; Rob Herring; Russell King; Arnd Bergmann; > linux- > i...@vger.kernel.org; devicet...@vger.kernel.org; linux-arm- >

RE: [PATCH v3 2/3] iio: Add driver for Broadcom iproc-static-adc

> -Original Message- > From: Jonathan Cameron [mailto:ji...@kernel.org] > Sent: 28 June 2016 00:41 > To: Raveendra Padasalagi > Cc: Peter Meerwald-Stadler; Rob Herring; Russell King; Arnd Bergmann; > linux- > i...@vger.kernel.org; devicet...@vger.kernel.org; linux-arm- >

Re: [PATCH v2] notifier: Fix soft lockup for notifier_call_chain().

On Tue, 2016-06-28 at 12:56 +0800, Ding Tianhong wrote: > The problem was occurs in my system that a lot of drviers register > its own handler to the notifiler call chain for netdev_chain, and > then create 4095 vlan dev for one nic, and add several ipv6 address > on each one of them, just like

Re: [PATCH v2] notifier: Fix soft lockup for notifier_call_chain().

On Tue, 2016-06-28 at 12:56 +0800, Ding Tianhong wrote: > The problem was occurs in my system that a lot of drviers register > its own handler to the notifiler call chain for netdev_chain, and > then create 4095 vlan dev for one nic, and add several ipv6 address > on each one of them, just like

RE: acpi: broken suspend to RAM with v4.7-rc1

Hi, > From: Andrey Skvortsov [mailto:andrej.skvort...@gmail.com] > Subject: Re: acpi: broken suspend to RAM with v4.7-rc1 > > On 27 Jun, Zheng, Lv wrote: > > Hi, > > > > > From: Andrey Skvortsov [mailto:andrej.skvort...@gmail.com] > > > Subject: Re: acpi: broken suspend to RAM with v4.7-rc1 > >

RE: acpi: broken suspend to RAM with v4.7-rc1

Hi, > From: Andrey Skvortsov [mailto:andrej.skvort...@gmail.com] > Subject: Re: acpi: broken suspend to RAM with v4.7-rc1 > > On 27 Jun, Zheng, Lv wrote: > > Hi, > > > > > From: Andrey Skvortsov [mailto:andrej.skvort...@gmail.com] > > > Subject: Re: acpi: broken suspend to RAM with v4.7-rc1 > >

Re: [PATCH] capabilities: add capability cgroup controller

Topi Miettinen writes: > On 06/24/16 17:21, Eric W. Biederman wrote: >> "Serge E. Hallyn" writes: >> >>> Quoting Tejun Heo (t...@kernel.org): Hello, On Fri, Jun 24, 2016 at 10:59:16AM -0500, Serge E. Hallyn wrote: > Quoting Tejun Heo

Re: [PATCH] capabilities: add capability cgroup controller

Topi Miettinen writes: > On 06/24/16 17:21, Eric W. Biederman wrote: >> "Serge E. Hallyn" writes: >> >>> Quoting Tejun Heo (t...@kernel.org): Hello, On Fri, Jun 24, 2016 at 10:59:16AM -0500, Serge E. Hallyn wrote: > Quoting Tejun Heo (t...@kernel.org): >> But isn't being

Re: [PATCH 2/2] dt-bindings: pinctrl: Add MDM9615 TLMM bindings

On Fri 17 Jun 03:15 PDT 2016, Neil Armstrong wrote: > Signed-off-by: Neil Armstrong Acked-by: Bjorn Andersson Regards, Bjorn

Re: [PATCH 2/2] dt-bindings: pinctrl: Add MDM9615 TLMM bindings

On Fri 17 Jun 03:15 PDT 2016, Neil Armstrong wrote: > Signed-off-by: Neil Armstrong Acked-by: Bjorn Andersson Regards, Bjorn

[PATCH V1] regulator: da9211: add descriptions for da9212/da9214

From: James Ban This is a patch for adding description for da9212/da9214. Signed-off-by: James Ban --- This patch applies against linux-next and next-20160624 .../devicetree/bindings/regulator/da9211.txt | 44

[PATCH V1] regulator: da9211: add descriptions for da9212/da9214

From: James Ban This is a patch for adding description for da9212/da9214. Signed-off-by: James Ban --- This patch applies against linux-next and next-20160624 .../devicetree/bindings/regulator/da9211.txt | 44 ++-- drivers/regulator/da9211-regulator.c

Re: [PATCH 1/2] pinctrl: qcom: Add support for MDM9615 TLMM

On Fri 17 Jun 03:15 PDT 2016, Neil Armstrong wrote: > In order to support the Qualcomm MDM9615 SoC, add support for the TLMM > using the Qualcomm pinctrl generic driver. > > Note: the pinctrl is partial, need Documentation to complete all the groups. > Signed-off-by: Neil Armstrong

Re: [PATCH 1/2] pinctrl: qcom: Add support for MDM9615 TLMM

On Fri 17 Jun 03:15 PDT 2016, Neil Armstrong wrote: > In order to support the Qualcomm MDM9615 SoC, add support for the TLMM > using the Qualcomm pinctrl generic driver. > > Note: the pinctrl is partial, need Documentation to complete all the groups. > Signed-off-by: Neil Armstrong

Re: [PATCH 2/3] powerpc/spinlock: support vcpu preempted check

On Tue, Jun 28, 2016 at 11:39:18AM +0800, xinhui wrote: [snip] > > > +{ > > > + struct lppaca *lp = _of(cpu); > > > + > > > + if (unlikely(!(lppaca_shared_proc(lp) || > > > + lppaca_dedicated_proc(lp > > > > Do you want to detect whether we are running in a guest(ie. pseries >

Re: [PATCH 2/3] powerpc/spinlock: support vcpu preempted check

On Tue, Jun 28, 2016 at 11:39:18AM +0800, xinhui wrote: [snip] > > > +{ > > > + struct lppaca *lp = _of(cpu); > > > + > > > + if (unlikely(!(lppaca_shared_proc(lp) || > > > + lppaca_dedicated_proc(lp > > > > Do you want to detect whether we are running in a guest(ie. pseries >

Re: IP ID check (flush_id) in inet_gro_receive is necessary or not？

On Tue, 2016-06-28 at 12:40 +0800, Tan Xiaojun wrote: > Hi everyone, > > I'm sorry to bother you. But I was confused. > > The IP ID check (flush_id) in inet_gro_receive is only used by > tcp_gro_receive, and in tcp_gro_receive we have tcphdr check to ensure > the order of skbs, >

Re: IP ID check (flush_id) in inet_gro_receive is necessary or not？

On Tue, 2016-06-28 at 12:40 +0800, Tan Xiaojun wrote: > Hi everyone, > > I'm sorry to bother you. But I was confused. > > The IP ID check (flush_id) in inet_gro_receive is only used by > tcp_gro_receive, and in tcp_gro_receive we have tcphdr check to ensure > the order of skbs, >

[PATCH v2] notifier: Fix soft lockup for notifier_call_chain().

The problem was occurs in my system that a lot of drviers register its own handler to the notifiler call chain for netdev_chain, and then create 4095 vlan dev for one nic, and add several ipv6 address on each one of them, just like this: for i in `seq 1 4095`; do ip link add link eth0 name

[PATCH v2] notifier: Fix soft lockup for notifier_call_chain().

The problem was occurs in my system that a lot of drviers register its own handler to the notifiler call chain for netdev_chain, and then create 4095 vlan dev for one nic, and add several ipv6 address on each one of them, just like this: for i in `seq 1 4095`; do ip link add link eth0 name

RE: [PATCH] usb: otg-fsm: Cancel HNP polling work when not used

Hi > -Original Message- > From: Stephen Boyd [mailto:stephen.b...@linaro.org] > Sent: Tuesday, June 28, 2016 9:18 AM > To: Peter Chen ; Felipe Balbi > Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; >

RE: [PATCH] usb: otg-fsm: Cancel HNP polling work when not used

Hi > -Original Message- > From: Stephen Boyd [mailto:stephen.b...@linaro.org] > Sent: Tuesday, June 28, 2016 9:18 AM > To: Peter Chen ; Felipe Balbi > Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; > linux-...@vger.kernel.org; Jun Li ; Greg Kroah-Hartman > >

[PATCH] regulator: pwm: Fix regulator ramp delay for continuous mode

The original commit adding support for continuous voltage mode didn't handle the regulator ramp delay properly. It treated the delay as a fixed delay in uS despite the property being defined as uV / uS. Let's adjust it. Luckily there appear to be no users of this ramp delay for PWM regulators

[PATCH] regulator: pwm: Fix regulator ramp delay for continuous mode

The original commit adding support for continuous voltage mode didn't handle the regulator ramp delay properly. It treated the delay as a fixed delay in uS despite the property being defined as uV / uS. Let's adjust it. Luckily there appear to be no users of this ramp delay for PWM regulators

Re: [PATCH 15/21] usb: chipidea: msm: Mux over secondary phy at the right time

On Sun 26 Jun 00:28 PDT 2016, Stephen Boyd wrote: > We need to pick the correct phy at runtime based on how the SoC > has been wired onto the board. If the secondary phy is used, take > it out of reset and mux over to it by writing into the TCSR > register. Make sure to do this on reset too,

[PATCH v1 3/5] ARM: dts: rockchip: add eDP/panel display device nodes for rk3288-evb

The default eDP panel on RK3288 EVB board is LG LP079QX1-SP0V TFT LCD, we haven't declared the panel regulator in the 'panel-simple' device node here, so the specific board like ACT8846 / RK8080 need to support the panel power supply. Signed-off-by: Yakir Yang ---

Re: [PATCH 15/21] usb: chipidea: msm: Mux over secondary phy at the right time

On Sun 26 Jun 00:28 PDT 2016, Stephen Boyd wrote: > We need to pick the correct phy at runtime based on how the SoC > has been wired onto the board. If the secondary phy is used, take > it out of reset and mux over to it by writing into the TCSR > register. Make sure to do this on reset too,

[PATCH v1 3/5] ARM: dts: rockchip: add eDP/panel display device nodes for rk3288-evb

The default eDP panel on RK3288 EVB board is LG LP079QX1-SP0V TFT LCD, we haven't declared the panel regulator in the 'panel-simple' device node here, so the specific board like ACT8846 / RK8080 need to support the panel power supply. Signed-off-by: Yakir Yang ---

[PATCH v1 4/5] ARM: dts: rockchip: add the panel power supply for rk3288-evb board with act8846 pmu

Panel regulator is controller by a normal GPIO, so we need to write a regulator-fixed node for it. Signed-off-by: Yakir Yang --- arch/arm/boot/dts/rk3288-evb-act8846.dts | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/boot/dts/rk3288-evb-act8846.dts

[PATCH v1 2/5] drm/panel: simple: Add support for LG LP079QX1-SP0V 1536x2048 panel

The LG LP079QX1-SP0V is an 7.9" QXGA TFT with LED Backlight unit and 32 pins eDP interface. This module supports 1536x2048 mode. Signed-off-by: Yakir Yang --- drivers/gpu/drm/panel/panel-simple.c | 26 ++ 1 file changed, 26 insertions(+) diff --git

[PATCH v1 4/5] ARM: dts: rockchip: add the panel power supply for rk3288-evb board with act8846 pmu

Panel regulator is controller by a normal GPIO, so we need to write a regulator-fixed node for it. Signed-off-by: Yakir Yang --- arch/arm/boot/dts/rk3288-evb-act8846.dts | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/boot/dts/rk3288-evb-act8846.dts

[PATCH v1 2/5] drm/panel: simple: Add support for LG LP079QX1-SP0V 1536x2048 panel

The LG LP079QX1-SP0V is an 7.9" QXGA TFT with LED Backlight unit and 32 pins eDP interface. This module supports 1536x2048 mode. Signed-off-by: Yakir Yang --- drivers/gpu/drm/panel/panel-simple.c | 26 ++ 1 file changed, 26 insertions(+) diff --git

[PATCH v1 1/5] dt-bindings: Add support for LG LP079QX1-SP0V 1536x2048 panel

The LG LP079QX1-SP0V is an 7.9" QXGA TFT with LED Backlight unit and 32 pins eDP interface. This module supports 1536x2048 mode. Signed-off-by: Yakir Yang --- .../devicetree/bindings/display/panel/lg,lp079qx1-sp0v.txt | 7 +++ 1 file changed, 7 insertions(+)

[PATCH v1 5/5] ARM: dts: rockchip: add the panel power supply for rk3288-evb board with rk808 pmu

Panel regulator is controller by a normal GPIO, so we need to write a regulator-fixed node for it. Signed-off-by: Yakir Yang --- arch/arm/boot/dts/rk3288-evb-rk808.dts | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/boot/dts/rk3288-evb-rk808.dts

[PATCH v1 1/5] dt-bindings: Add support for LG LP079QX1-SP0V 1536x2048 panel

The LG LP079QX1-SP0V is an 7.9" QXGA TFT with LED Backlight unit and 32 pins eDP interface. This module supports 1536x2048 mode. Signed-off-by: Yakir Yang --- .../devicetree/bindings/display/panel/lg,lp079qx1-sp0v.txt | 7 +++ 1 file changed, 7 insertions(+) create mode 100644

[PATCH v1 5/5] ARM: dts: rockchip: add the panel power supply for rk3288-evb board with rk808 pmu

Panel regulator is controller by a normal GPIO, so we need to write a regulator-fixed node for it. Signed-off-by: Yakir Yang --- arch/arm/boot/dts/rk3288-evb-rk808.dts | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/boot/dts/rk3288-evb-rk808.dts

[PATCH v1 0/5] Enable graphic support on RK3288 EVB boards

Hi Heiko, This series just want to enable the graphic support on RK3288 EVB boards, most of them are DTS changes, but still have one change about new eDP panel support. Thanks, - Yakir Yakir Yang (5): dt-bindings: Add support for LG LP079QX1-SP0V 1536x2048 panel drm/panel: simple: Add

[PATCH v1 0/5] Enable graphic support on RK3288 EVB boards

Hi Heiko, This series just want to enable the graphic support on RK3288 EVB boards, most of them are DTS changes, but still have one change about new eDP panel support. Thanks, - Yakir Yakir Yang (5): dt-bindings: Add support for LG LP079QX1-SP0V 1536x2048 panel drm/panel: simple: Add

[PATCH V4 2/3] powerpc/opal: Add #define to get rc from an ASYNC_COMP opal_msg

An opal_msg of type OPAL_MSG_ASYNC_COMP contains the return code in the params[1] struct member. However this isn't intuitive or obvious when reading the code and requires that a user look at the skiboot documentation or opal-api.h to verify this. Add a #define to get the return code from an

[PATCH V4 2/3] powerpc/opal: Add #define to get rc from an ASYNC_COMP opal_msg

An opal_msg of type OPAL_MSG_ASYNC_COMP contains the return code in the params[1] struct member. However this isn't intuitive or obvious when reading the code and requires that a user look at the skiboot documentation or opal-api.h to verify this. Add a #define to get the return code from an

[PATCH V4 3/3] powerpc/drivers: Add driver for operator panel on FSP machines

Implement new character device driver to allow access from user space to the operator panel display present on IBM Power Systems machines with FSPs. This will allow status information to be presented on the display which is visible to a user. The driver implements a character buffer which a user

[PATCH V4 1/3] devicetree/bindings: Add binding for operator panel on FSP machines

Add a binding to Documentation/devicetree/bindings/powerpc/opal (oppanel-opal.txt) for the operator panel which is present on IBM Power Systems machines with FSPs. Signed-off-by: Suraj Jitindar Singh Acked-by: Rob Herring Acked-by: Stewart Smith

[PATCH V4 3/3] powerpc/drivers: Add driver for operator panel on FSP machines

Implement new character device driver to allow access from user space to the operator panel display present on IBM Power Systems machines with FSPs. This will allow status information to be presented on the display which is visible to a user. The driver implements a character buffer which a user

[PATCH V4 1/3] devicetree/bindings: Add binding for operator panel on FSP machines

Add a binding to Documentation/devicetree/bindings/powerpc/opal (oppanel-opal.txt) for the operator panel which is present on IBM Power Systems machines with FSPs. Signed-off-by: Suraj Jitindar Singh Acked-by: Rob Herring Acked-by: Stewart Smith --- Change Log: V1 -> V2: - Nothing

IP ID check (flush_id) in inet_gro_receive is necessary or not？

Hi everyone, I'm sorry to bother you. But I was confused. The IP ID check (flush_id) in inet_gro_receive is only used by tcp_gro_receive, and in tcp_gro_receive we have tcphdr check to ensure the order of skbs, like below: flush |= (__force int)(th->ack_seq ^

IP ID check (flush_id) in inet_gro_receive is necessary or not？

Hi everyone, I'm sorry to bother you. But I was confused. The IP ID check (flush_id) in inet_gro_receive is only used by tcp_gro_receive, and in tcp_gro_receive we have tcphdr check to ensure the order of skbs, like below: flush |= (__force int)(th->ack_seq ^

RE: [PATCH 1/1] regulator: max77620: check for valid regulator info

> * PGP Signed by an unknown key > > On Mon, Jun 27, 2016 at 05:13:44PM +0530, Venkat Reddy Talla wrote: > > Check for valid regulator information data before configuring FPS > > source and FPS power up/down period to avoid NULL pointer exception if > > entries for PMIC regulators not provided

RE: [PATCH 1/1] regulator: max77620: check for valid regulator info

> * PGP Signed by an unknown key > > On Mon, Jun 27, 2016 at 05:13:44PM +0530, Venkat Reddy Talla wrote: > > Check for valid regulator information data before configuring FPS > > source and FPS power up/down period to avoid NULL pointer exception if > > entries for PMIC regulators not provided

[RESEND PATCH 2/2] ARM: cache-l2x0.c: Do not clear bit 23 in prefetch control register

As per L2C-310 TRM[1]: "... You can control this feature using bits 30,27 and 23 of the Prefetch Control Register. Bit 23 and 27 are only used if you set bit 30 HIGH..." which means there is no need to clear bit 23 if bit 30 is being cleared. [1]

[RESEND PATCH 2/2] ARM: cache-l2x0.c: Do not clear bit 23 in prefetch control register

As per L2C-310 TRM[1]: "... You can control this feature using bits 30,27 and 23 of the Prefetch Control Register. Bit 23 and 27 are only used if you set bit 30 HIGH..." which means there is no need to clear bit 23 if bit 30 is being cleared. [1]

[RESEND PATCH 1/2] ARM: cache-l2x0.c: Replace magic numbers

Replace magic numbers used for L310 Prefetch Control Register Acked-by: Arnd Bergmann Signed-off-by: Andrey Smirnov --- arch/arm/mm/cache-l2x0.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/mm/cache-l2x0.c

[PATCH 4/5] mmu: remove is_present_gpte()

We have two versions of the above function. To prevent confusion and bugs in the future, remove the non-FNAME version entirely and replace all calls with the actual check. Signed-off-by: Bandan Das --- arch/x86/kvm/mmu.c | 2 +- arch/x86/kvm/mmu.h | 5 -

[RESEND PATCH 1/2] ARM: cache-l2x0.c: Replace magic numbers

Replace magic numbers used for L310 Prefetch Control Register Acked-by: Arnd Bergmann Signed-off-by: Andrey Smirnov --- arch/arm/mm/cache-l2x0.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c index 9f9d542..30e2012

[PATCH 4/5] mmu: remove is_present_gpte()

We have two versions of the above function. To prevent confusion and bugs in the future, remove the non-FNAME version entirely and replace all calls with the actual check. Signed-off-by: Bandan Das --- arch/x86/kvm/mmu.c | 2 +- arch/x86/kvm/mmu.h | 5 -

[PATCH 2/5] mmu: pass execonly value when initializing rsvd bits

In reset_tdp_shadow_zero_bits_mask, we always pass false when initializing the reserved bits. By initializing with the correct value of ept exec only, the host can correctly identify if the guest pte is valid. Note that kvm_init_shadow_ept_mmu() already knows about execonly. Signed-off-by: Bandan

[PATCH 5/5] nvmx: advertise support for ept execute only

KVM MMU now knows about execute only mappings, so advertise the feature to L1 hypervisors Signed-off-by: Bandan Das --- arch/x86/kvm/vmx.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 417debc..0fe61a3 100644 ---

[PATCH 2/5] mmu: pass execonly value when initializing rsvd bits

In reset_tdp_shadow_zero_bits_mask, we always pass false when initializing the reserved bits. By initializing with the correct value of ept exec only, the host can correctly identify if the guest pte is valid. Note that kvm_init_shadow_ept_mmu() already knows about execonly. Signed-off-by: Bandan

[PATCH 5/5] nvmx: advertise support for ept execute only

KVM MMU now knows about execute only mappings, so advertise the feature to L1 hypervisors Signed-off-by: Bandan Das --- arch/x86/kvm/vmx.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 417debc..0fe61a3 100644 --- a/arch/x86/kvm/vmx.c +++

[PATCH 0/5] Add support for EPT execute only for nested hypervisors

These patches are based on reviews to my RFC http://www.spinics.net/lists/kvm/msg134440.html Changes since RFC: - Remove shadow_xonly_valid, it's not needed - Remove checks from is_shadow_present_pte() - In reset_tdp_shadow_zero_bits_mask, pass correct execonly to __reset_rsvds_bits_mask_ept

[PATCH 0/5] Add support for EPT execute only for nested hypervisors

These patches are based on reviews to my RFC http://www.spinics.net/lists/kvm/msg134440.html Changes since RFC: - Remove shadow_xonly_valid, it's not needed - Remove checks from is_shadow_present_pte() - In reset_tdp_shadow_zero_bits_mask, pass correct execonly to __reset_rsvds_bits_mask_ept

[PATCH 3/5] mmu: don't set the present bit unconditionally

To support execute only mappings on behalf of L1 hypervisors, we teach set_spte() to honor L1's valid XWR bits. This is only if host supports EPT execute only. Reuse ACC_USER_MASK to signify if the L1 hypervisor has the R bit set Signed-off-by: Bandan Das --- arch/x86/kvm/mmu.c

[PATCH 1/5] mmu: mark spte present if the x bit is set

This is safe because is_shadow_present_pte() is called on host controlled page table and we know the spte is valid Signed-off-by: Bandan Das --- arch/x86/kvm/mmu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c

[PATCH 3/5] mmu: don't set the present bit unconditionally

To support execute only mappings on behalf of L1 hypervisors, we teach set_spte() to honor L1's valid XWR bits. This is only if host supports EPT execute only. Reuse ACC_USER_MASK to signify if the L1 hypervisor has the R bit set Signed-off-by: Bandan Das --- arch/x86/kvm/mmu.c | 9

[PATCH 1/5] mmu: mark spte present if the x bit is set

This is safe because is_shadow_present_pte() is called on host controlled page table and we know the spte is valid Signed-off-by: Bandan Das --- arch/x86/kvm/mmu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index

Re: [PATCH] arc: warn only once if DW2_UNWIND is disabled

On Thursday 23 June 2016 01:30 PM, Alexey Brodkin wrote: > If CONFIG_ARC_DW2_UNWIND is disabled every time arc_unwind_core() > gets called following message gets printed in debug console: > ->8--- > CONFIG_ARC_DW2_UNWIND needs to be enabled >

Re: [PATCH] arc: warn only once if DW2_UNWIND is disabled

On Thursday 23 June 2016 01:30 PM, Alexey Brodkin wrote: > If CONFIG_ARC_DW2_UNWIND is disabled every time arc_unwind_core() > gets called following message gets printed in debug console: > ->8--- > CONFIG_ARC_DW2_UNWIND needs to be enabled >

Re: [PATCH v3 0/3] toshiba_acpi: Accelerometer updates

On Mon, Jun 27, 2016 at 07:46:42PM -0600, Azael Avalos wrote: > These series of patches update the accelerometer axis data > reporting to use the IIO subsystem, deprecating the custom > position sysfs entry, and finally bumping the driver version > to 0.24. > Thanks Azael, queued to testing for

Re: [PATCH v3 0/3] toshiba_acpi: Accelerometer updates

On Mon, Jun 27, 2016 at 07:46:42PM -0600, Azael Avalos wrote: > These series of patches update the accelerometer axis data > reporting to use the IIO subsystem, deprecating the custom > position sysfs entry, and finally bumping the driver version > to 0.24. > Thanks Azael, queued to testing for

  1   2   3   4   5   6   7   8   9   10   >