[PATCH] perf lock: subcommands should include common options

From: Changbin Du When I use -i option for report subcommand, it doesn't accept it. We need add common options using OPT_PARENT macro. perf lock report -i lock_perf.data Error: unknown switch `i' Usage: perf lock report [] -f, --force don't complain,

[PATCH] perf lock: subcommands should include common options

From: Changbin Du When I use -i option for report subcommand, it doesn't accept it. We need add common options using OPT_PARENT macro. perf lock report -i lock_perf.data Error: unknown switch `i' Usage: perf lock report [] -f, --force don't complain, do it -k, --key

[PATCH V4 2/4] dt-bindings: arm: Add bindings for SP9860G

Added bindings for Spreadtrum SP9860G board and SC9860 SoC. This patch also revised bindings of SC9836 to make the format more clear. Signed-off-by: Chunyan Zhang --- Documentation/devicetree/bindings/arm/sprd.txt | 13 - 1 file changed, 8

[PATCH V4 4/4] serial: sprd: adjust TIMEOUT to a big value

From: Wei Qiao SPRD_TIMEOUT was 256, which is too small to wait until the status switched to workable in a while loop, so that the earlycon could not work correctly. Signed-off-by: Wei Qiao Signed-off-by: Chunyan Zhang

[PATCH V4 1/4] arm64: dts: Add basic DT to support Spreadtrum's SP9860G

From: Orson Zhai SC9860G is a 8 cores of A53 SoC with 4G LTE support SoC from Spreadtrum. According to regular hierarchy of sprd dts, whale2.dtsi contains SoC peripherals IP nodes, sc9860.dtsi contains stuff related to ARM core stuff and sp9860g dts is for the board

[PATCH V4 0/4] Add Spreadtrum SP9860G support

SC9860 is a Spreadtrum SoC with eight Cortex A53, which are divided into 4 Big cores and 4 little cores. This patch-set provides a basic configuration for SC9860 in device tree to make it run to console. After this we will continue to submit other device drivers step by step, which are using on

[PATCH V4 2/4] dt-bindings: arm: Add bindings for SP9860G

Added bindings for Spreadtrum SP9860G board and SC9860 SoC. This patch also revised bindings of SC9836 to make the format more clear. Signed-off-by: Chunyan Zhang --- Documentation/devicetree/bindings/arm/sprd.txt | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git

[PATCH V4 4/4] serial: sprd: adjust TIMEOUT to a big value

From: Wei Qiao SPRD_TIMEOUT was 256, which is too small to wait until the status switched to workable in a while loop, so that the earlycon could not work correctly. Signed-off-by: Wei Qiao Signed-off-by: Chunyan Zhang --- drivers/tty/serial/sprd_serial.c | 2 +- 1 file changed, 1

[PATCH V4 1/4] arm64: dts: Add basic DT to support Spreadtrum's SP9860G

From: Orson Zhai SC9860G is a 8 cores of A53 SoC with 4G LTE support SoC from Spreadtrum. According to regular hierarchy of sprd dts, whale2.dtsi contains SoC peripherals IP nodes, sc9860.dtsi contains stuff related to ARM core stuff and sp9860g dts is for the board level. Signed-off-by: Orson

[PATCH V4 0/4] Add Spreadtrum SP9860G support

SC9860 is a Spreadtrum SoC with eight Cortex A53, which are divided into 4 Big cores and 4 little cores. This patch-set provides a basic configuration for SC9860 in device tree to make it run to console. After this we will continue to submit other device drivers step by step, which are using on

[PATCH V4 3/4] dt-bindings: serial: add a new compatible string for SC9860

SC9860 use the same serial device which SC9836 uses, so added a new compatible string to support SC9860 as well, also added an example of how to describe this serial device in DT. Signed-off-by: Chunyan Zhang ---

[PATCH V4 3/4] dt-bindings: serial: add a new compatible string for SC9860

SC9860 use the same serial device which SC9836 uses, so added a new compatible string to support SC9860 as well, also added an example of how to describe this serial device in DT. Signed-off-by: Chunyan Zhang --- Documentation/devicetree/bindings/serial/sprd-uart.txt | 14 +- 1 file

[PATCH] PM / Domain: remove conditional from error case

There is no point running the conditional 'if' statement if the genpd isn't present. Signed-off-by: Viresh Kumar --- drivers/base/power/domain.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/base/power/domain.c

[PATCH] PM / Domain: remove conditional from error case

There is no point running the conditional 'if' statement if the genpd isn't present. Signed-off-by: Viresh Kumar --- drivers/base/power/domain.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c index

Re: [PATCH] ext4: Add statx support

Hi David, On Thu, Mar 16, 2017 at 11:35:33AM +, David Howells wrote: > + > + ext4_get_inode_flags(ei); > + flags = ei->i_flags & EXT4_FL_USER_VISIBLE; > + if (flags & EXT4_APPEND_FL) > + stat->attributes |= STATX_ATTR_APPEND; > + if (flags & EXT4_COMPR_FL) > +

Re: [PATCH] ext4: Add statx support

Hi David, On Thu, Mar 16, 2017 at 11:35:33AM +, David Howells wrote: > + > + ext4_get_inode_flags(ei); > + flags = ei->i_flags & EXT4_FL_USER_VISIBLE; > + if (flags & EXT4_APPEND_FL) > + stat->attributes |= STATX_ATTR_APPEND; > + if (flags & EXT4_COMPR_FL) > +

Re: [rtc] 4cd8adb100: WARNING: CPU: 0 PID: 1 at lib/kobject.c:690 kobject_put

Hey, I think I see the issue here: in a couple of error conditions, the RTC code will not initialize and ask for the cdev. However, my change will always call cdev_add and cdev_del even though the rtc code did not call cdev_init. I'll have to add a guard around dev->devt in the new cdev_device

Re: [rtc] 4cd8adb100: WARNING: CPU: 0 PID: 1 at lib/kobject.c:690 kobject_put

Hey, I think I see the issue here: in a couple of error conditions, the RTC code will not initialize and ask for the cdev. However, my change will always call cdev_add and cdev_del even though the rtc code did not call cdev_init. I'll have to add a guard around dev->devt in the new cdev_device

Re: [PATCH] powerpc/pseries: Don't give a warning when HPT resizing isn't available

David Gibson writes: > As of 438cc81a41 "powerpc/pseries: Automatically resize HPT for memory hot > add/remove" when running on the pseries platform, we always attempt to > use the PAPR extension to resize the hashed page table (HPT) when we add > or remove memory. >

Re: [PATCH] powerpc/pseries: Don't give a warning when HPT resizing isn't available

David Gibson writes: > As of 438cc81a41 "powerpc/pseries: Automatically resize HPT for memory hot > add/remove" when running on the pseries platform, we always attempt to > use the PAPR extension to resize the hashed page table (HPT) when we add > or remove memory. > > This is fine, but when the

Re: [PATCH] tty: hvc: don't allocate a buffer for console print on stack

On Fri, Feb 17, 2017 at 11:42:45PM +0300, Jan Dakinevich wrote: > The buffer is used by virtio console driver as DMA buffer. Since v4.9 > (if VMAP_STACK is enabled) we shouldn't use the stack for DMA. You shouldn't use 'static' data either, that's not always guaranteed to be DMA-able, right? >

Re: [PATCH] tty: hvc: don't allocate a buffer for console print on stack

On Fri, Feb 17, 2017 at 11:42:45PM +0300, Jan Dakinevich wrote: > The buffer is used by virtio console driver as DMA buffer. Since v4.9 > (if VMAP_STACK is enabled) we shouldn't use the stack for DMA. You shouldn't use 'static' data either, that's not always guaranteed to be DMA-able, right? >

Re: tty: panic in tty_ldisc_restore

On Mon, Mar 13, 2017 at 11:15:29AM +0100, Dmitry Vyukov wrote: > On Thu, Feb 2, 2017 at 7:23 PM, Greg Kroah-Hartman > wrote: > > On Thu, Feb 02, 2017 at 07:03:41PM +0100, Dmitry Vyukov wrote: > >> On Thu, Feb 2, 2017 at 6:55 PM, Greg Kroah-Hartman > >>

Re: tty: panic in tty_ldisc_restore

On Mon, Mar 13, 2017 at 11:15:29AM +0100, Dmitry Vyukov wrote: > On Thu, Feb 2, 2017 at 7:23 PM, Greg Kroah-Hartman > wrote: > > On Thu, Feb 02, 2017 at 07:03:41PM +0100, Dmitry Vyukov wrote: > >> On Thu, Feb 2, 2017 at 6:55 PM, Greg Kroah-Hartman > >> wrote: > >> > On Thu, Feb 02, 2017 at

Re: [PATCH v3] Revert "tty: serial: pl011: add ttyAMA for matching pl011 console"

On Thu, Mar 16, 2017 at 12:31:53PM +0300, Aleksey Makarov wrote: > > > On 03/16/2017 10:11 AM, Jayachandran C. wrote: > > Hi Greg, > > > > On Tue, Mar 14, 2017 at 9:44 PM, Sudeep Holla wrote: > >> > >> > >> On 01/03/17 15:23, Aleksey Makarov wrote: > >>> The original

Re: [PATCH v3] Revert "tty: serial: pl011: add ttyAMA for matching pl011 console"

On Thu, Mar 16, 2017 at 12:31:53PM +0300, Aleksey Makarov wrote: > > > On 03/16/2017 10:11 AM, Jayachandran C. wrote: > > Hi Greg, > > > > On Tue, Mar 14, 2017 at 9:44 PM, Sudeep Holla wrote: > >> > >> > >> On 01/03/17 15:23, Aleksey Makarov wrote: > >>> The original patch makes the condition

Re: [lkp-robot] [mm] bae58218d8: WARNING:at_mm/page_alloc.c:#drain_all_pages

On 03/16, Michal Hocko wrote: >On Thu 16-03-17 10:38:49, kernel test robot wrote: >> >> FYI, we noticed the following commit: >> >> commit: bae58218d80c6beffd5c96c0fcae372a0e63ca32 ("mm: move pcp and lru-pcp >> draining into single wq") >>

Re: [lkp-robot] [mm] bae58218d8: WARNING:at_mm/page_alloc.c:#drain_all_pages

On 03/16, Michal Hocko wrote: >On Thu 16-03-17 10:38:49, kernel test robot wrote: >> >> FYI, we noticed the following commit: >> >> commit: bae58218d80c6beffd5c96c0fcae372a0e63ca32 ("mm: move pcp and lru-pcp >> draining into single wq") >>

Re: [patch 1/3] procfs: fdinfo -- Extend information about epoll target files

On Fri, Mar 10, 2017 at 11:16:56AM +0300, Cyrill Gorcunov wrote: > Since it is possbile to have same number in tfd field (say > file added, closed, then nother file dup'ed to same number > and added back) it is imposible to distinguish such target > files solely by their numbers. > > Strictly

Re: [patch 1/3] procfs: fdinfo -- Extend information about epoll target files

On Fri, Mar 10, 2017 at 11:16:56AM +0300, Cyrill Gorcunov wrote: > Since it is possbile to have same number in tfd field (say > file added, closed, then nother file dup'ed to same number > and added back) it is imposible to distinguish such target > files solely by their numbers. > > Strictly

Re: [PATCH v3 4/7] xen/9pfs: connect to the backend

On 16/03/17 19:03, Stefano Stabellini wrote: > On Thu, 16 Mar 2017, Juergen Gross wrote: >> On 15/03/17 19:44, Stefano Stabellini wrote: >>> On Wed, 15 Mar 2017, Juergen Gross wrote: On 14/03/17 22:22, Stefano Stabellini wrote: > Hi Juergen, > > thank you for the review! >

Re: [PATCH v3 4/7] xen/9pfs: connect to the backend

On 16/03/17 19:03, Stefano Stabellini wrote: > On Thu, 16 Mar 2017, Juergen Gross wrote: >> On 15/03/17 19:44, Stefano Stabellini wrote: >>> On Wed, 15 Mar 2017, Juergen Gross wrote: On 14/03/17 22:22, Stefano Stabellini wrote: > Hi Juergen, > > thank you for the review! >

Re: [HMM 07/16] mm/migrate: new memory migration helper for use with device memory v4

On 17/03/17 14:42, Balbir Singh wrote: >>> Or make the HMM Kconfig feature 64BIT only by making it depend on 64BIT? >>> >> >> Yes, that was my first reaction too, but these particular routines are >> aspiring to be generic routines--in fact, you have had an influence there, >> because these

Re: [HMM 07/16] mm/migrate: new memory migration helper for use with device memory v4

On 17/03/17 14:42, Balbir Singh wrote: >>> Or make the HMM Kconfig feature 64BIT only by making it depend on 64BIT? >>> >> >> Yes, that was my first reaction too, but these particular routines are >> aspiring to be generic routines--in fact, you have had an influence there, >> because these

Re: [PATCH v5 0/7] perf/sdt: Directly record SDT events with 'perf record'

Hi Ravi, On Thu, 16 Mar 2017 16:57:52 +0530 Ravi Bangoria wrote: > Hi Masami, > > On Thursday 16 March 2017 03:21 PM, Masami Hiramatsu wrote: > > On Tue, 14 Mar 2017 20:36:51 +0530 > > Ravi Bangoria wrote: > > > >> Changes in

Re: [PATCH v5 0/7] perf/sdt: Directly record SDT events with 'perf record'

Hi Ravi, On Thu, 16 Mar 2017 16:57:52 +0530 Ravi Bangoria wrote: > Hi Masami, > > On Thursday 16 March 2017 03:21 PM, Masami Hiramatsu wrote: > > On Tue, 14 Mar 2017 20:36:51 +0530 > > Ravi Bangoria wrote: > > > >> Changes in v5: > >> - Patch 2/7 is new. New option introduced in this patch

[PATCH net-next v3 2/2]L2TP:Adjust intf MTU, add underlay L3, L2 hdrs

In existing kernel code, when setting up the L2TP interface, all of the tunnel encapsulation headers are not taken into account when setting up the MTU on the L2TP logical interface device. Due to this, the packets created by the applications on top of the L2TP layer are larger than they ought

[PATCH net-next v3 2/2]L2TP:Adjust intf MTU, add underlay L3, L2 hdrs

In existing kernel code, when setting up the L2TP interface, all of the tunnel encapsulation headers are not taken into account when setting up the MTU on the L2TP logical interface device. Due to this, the packets created by the applications on top of the L2TP layer are larger than they ought

[git pull] drm fixes for v4.10-rc3.

Hi Linus, Bunch of fixes across the drivers, in a St Patrick's day pull request. (please turn terminal colors to green on black or black on green for full effect). On the arm side, tilcdc, omap and malidp got fixes, while amd has some powermanagement fixes, and intel has a set of fixes across

[git pull] drm fixes for v4.10-rc3.

Hi Linus, Bunch of fixes across the drivers, in a St Patrick's day pull request. (please turn terminal colors to green on black or black on green for full effect). On the arm side, tilcdc, omap and malidp got fixes, while amd has some powermanagement fixes, and intel has a set of fixes across

Re: [PATCH net] rxrpc: Ignore BUSY packets on old calls

From: David Howells Date: Thu, 16 Mar 2017 16:27:10 + > If we receive a BUSY packet for a call we think we've just completed, the > packet is handed off to the connection processor to deal with - but the > connection processor doesn't expect a BUSY packet and so flags a

Re: [PATCH net] rxrpc: Ignore BUSY packets on old calls

From: David Howells Date: Thu, 16 Mar 2017 16:27:10 + > If we receive a BUSY packet for a call we think we've just completed, the > packet is handed off to the connection processor to deal with - but the > connection processor doesn't expect a BUSY packet and so flags a protocol > error. >

[PATCH net-next v3 1/2]L2TP:Adjust intf MTU, add underlay L3, L2 hdrs

In existing kernel code, when setting up the L2TP interface, all of the tunnel encapsulation headers are not taken into account when setting up the MTU on the L2TP logical interface device. Due to this, the packets created by the applications on top of the L2TP layer are larger than they ought

[PATCH net-next v3 1/2]L2TP:Adjust intf MTU, add underlay L3, L2 hdrs

In existing kernel code, when setting up the L2TP interface, all of the tunnel encapsulation headers are not taken into account when setting up the MTU on the L2TP logical interface device. Due to this, the packets created by the applications on top of the L2TP layer are larger than they ought

[PATCH v3 1/4] drm/rockchip/dsi: check phy_cfg_clk only for RK3399

For RK3399, the phy_cfg_clk is a required clock, if phy_cfg_clk is disabled, MIPI phy can not work. Let's return a error if there is no phy_cfg_clk in dts property, when the pdata match RK3399. Signed-off-by: Chris Zhong --- Changes in v3: - add a DW_MIPI_NEEDS_PHY_CFG_CLK

[PATCH v3 1/4] drm/rockchip/dsi: check phy_cfg_clk only for RK3399

For RK3399, the phy_cfg_clk is a required clock, if phy_cfg_clk is disabled, MIPI phy can not work. Let's return a error if there is no phy_cfg_clk in dts property, when the pdata match RK3399. Signed-off-by: Chris Zhong --- Changes in v3: - add a DW_MIPI_NEEDS_PHY_CFG_CLK for RK3399 Changes

[PATCH v3 0/4] RK3399 dw-mipi-dsi patches

Hi all This series set the phy_cfg_clk to be a required clock for RK3399, and add a grf clock control in dw-mipi-dsi driver. And then correct a register name. Changes in v3: - add a DW_MIPI_NEEDS_PHY_CFG_CLK for RK3399 - add a DW_MIPI_NEEDS_GRF_CLK for RK3399 Changes in v2: - check the grf_clk

[PATCH v3 0/4] RK3399 dw-mipi-dsi patches

Hi all This series set the phy_cfg_clk to be a required clock for RK3399, and add a grf clock control in dw-mipi-dsi driver. And then correct a register name. Changes in v3: - add a DW_MIPI_NEEDS_PHY_CFG_CLK for RK3399 - add a DW_MIPI_NEEDS_GRF_CLK for RK3399 Changes in v2: - check the grf_clk

[PATCH v3 3/4] drm/rockchip/dsi: enable the grf clk before writing grf registers

For RK3399, the grf clk should be enabled before writing grf registers, otherwise the register value can not be changed. Signed-off-by: Chris Zhong --- Changes in v3: - add a DW_MIPI_NEEDS_GRF_CLK for RK3399 Changes in v2: - check the grf_clk only for RK3399

[PATCH v3 3/4] drm/rockchip/dsi: enable the grf clk before writing grf registers

For RK3399, the grf clk should be enabled before writing grf registers, otherwise the register value can not be changed. Signed-off-by: Chris Zhong --- Changes in v3: - add a DW_MIPI_NEEDS_GRF_CLK for RK3399 Changes in v2: - check the grf_clk only for RK3399

[PATCH v3 2/4] dt-bindings: add the grf clock for dw-mipi-dsi

For RK3399, the grf clock should be controlled by dw-mipi-dsi driver, add the description for this clock. Signed-off-by: Chris Zhong --- Changes in v3: None Changes in v2: None .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt | 2 +- 1 file changed,

[PATCH v3 4/4] drm/rockchip/dsi: correct the grf_switch_reg name

For the RK3399, the grf_switch_reg name should be RK3399_GRF_SOC_CON20, not RK3399_GRF_SOC_CON19. Signed-off-by: Chris Zhong --- Changes in v3: None Changes in v2: None drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff

[PATCH v3 2/4] dt-bindings: add the grf clock for dw-mipi-dsi

For RK3399, the grf clock should be controlled by dw-mipi-dsi driver, add the description for this clock. Signed-off-by: Chris Zhong --- Changes in v3: None Changes in v2: None .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH v3 4/4] drm/rockchip/dsi: correct the grf_switch_reg name

For the RK3399, the grf_switch_reg name should be RK3399_GRF_SOC_CON20, not RK3399_GRF_SOC_CON19. Signed-off-by: Chris Zhong --- Changes in v3: None Changes in v2: None drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH] phy: cpcap-usb: Add CPCAP PMIC USB support

Some Motorola phones like droid 4 use a custom CPCAP PMIC that has a multiplexing USB PHY. This USB PHY can operate at least in four modes using pin multiplexing and two control GPIOS: - Pass through companion PHY for the SoC USB PHY - ULPI PHY for the SoC - Pass through USB for the modem - UART

[PATCH] phy: cpcap-usb: Add CPCAP PMIC USB support

Some Motorola phones like droid 4 use a custom CPCAP PMIC that has a multiplexing USB PHY. This USB PHY can operate at least in four modes using pin multiplexing and two control GPIOS: - Pass through companion PHY for the SoC USB PHY - ULPI PHY for the SoC - Pass through USB for the modem - UART

Re: [PATCH v2] net: sun: sungem: rix a possible null dereference

From: Philippe Reynes Date: Wed, 15 Mar 2017 22:51:13 +0100 > The function gem_begin_auto_negotiation dereference > the pointer ep before testing if it's null. This > patch add a check on ep before dereferencing it. > > Fixes: 92552fdd557 ("net: sun: sungem: use new api

Re: [PATCH v2] net: sun: sungem: rix a possible null dereference

From: Philippe Reynes Date: Wed, 15 Mar 2017 22:51:13 +0100 > The function gem_begin_auto_negotiation dereference > the pointer ep before testing if it's null. This > patch add a check on ep before dereferencing it. > > Fixes: 92552fdd557 ("net: sun: sungem: use new api [davem@localhost

[PATCH] sched/core: Fix rq lock pinning warning after call balance callbacks

From: Wanpeng Li This can be reproduced by running rt-migrate-test: WARNING: CPU: 2 PID: 2195 at kernel/locking/lockdep.c:3670 lock_unpin_lock+0x172/0x180 unpinning an unpinned lock CPU: 2 PID: 2195 Comm: rt-migrate-test Tainted: GW 4.11.0-rc2+ #1 Call

[PATCH] sched/core: Fix rq lock pinning warning after call balance callbacks

From: Wanpeng Li This can be reproduced by running rt-migrate-test: WARNING: CPU: 2 PID: 2195 at kernel/locking/lockdep.c:3670 lock_unpin_lock+0x172/0x180 unpinning an unpinned lock CPU: 2 PID: 2195 Comm: rt-migrate-test Tainted: GW 4.11.0-rc2+ #1 Call Trace:

[PATCH v2 2/3] arm64: dts: rockchip: add i2s nodes support for RK3368 SoCs

I2S of RK3368 SoCs keep same as RK3066 SoCs found on Rockchip, add nodes to support them. Signed-off-by: Jianqun Xu --- changes since v1: - fix compile error caused by dumplicate label 'i2s1' arch/arm64/boot/dts/rockchip/rk3368.dtsi | 38

Re: [PATCH 7/15] dt-bindings: display: sun4i: Add allwinner,tcon-channel property

On Thu, Mar 16, 2017 at 1:37 AM, Rob Herring wrote: > On Tue, Mar 07, 2017 at 09:56:26AM +0100, Maxime Ripard wrote: >> The Allwinner Timings Controller has two, mutually exclusive, channels. >> When the binding has been introduced, it was assumed that there would be >> only a

[PATCH v2 2/3] arm64: dts: rockchip: add i2s nodes support for RK3368 SoCs

I2S of RK3368 SoCs keep same as RK3066 SoCs found on Rockchip, add nodes to support them. Signed-off-by: Jianqun Xu --- changes since v1: - fix compile error caused by dumplicate label 'i2s1' arch/arm64/boot/dts/rockchip/rk3368.dtsi | 38 1 file changed, 38

Re: [PATCH 7/15] dt-bindings: display: sun4i: Add allwinner,tcon-channel property

On Thu, Mar 16, 2017 at 1:37 AM, Rob Herring wrote: > On Tue, Mar 07, 2017 at 09:56:26AM +0100, Maxime Ripard wrote: >> The Allwinner Timings Controller has two, mutually exclusive, channels. >> When the binding has been introduced, it was assumed that there would be >> only a single user per

[PATCH v2 1/3] arm64: dts: rockchip: add amba node support for RK3368 SoCs

There are two dmacs found on RK3368 SoCs, peripher dmac and bus dmac, and the dmacs are same as previous SoCs' dmac. Signed-off-by: Jianqun Xu --- changes since v1: - none arch/arm64/boot/dts/rockchip/rk3368.dtsi | 31 +++ 1 file changed, 31

[PATCH 0/3] arm64: dts: rockchip: rk3368 add dmac and i2s nodes

These patches add dmac, i2s nodes, and disable mailbox. Jianqun Xu (3): arm64: dts: rockchip: add amba node support for RK3368 SoCs arm64: dts: rockchip: add i2s nodes support for RK3368 SoCs arm64: dts: rockchip: disable mailbox of RK3368 SoCs defaultly

[PATCH 0/3] arm64: dts: rockchip: rk3368 add dmac and i2s nodes

These patches add dmac, i2s nodes, and disable mailbox. Jianqun Xu (3): arm64: dts: rockchip: add amba node support for RK3368 SoCs arm64: dts: rockchip: add i2s nodes support for RK3368 SoCs arm64: dts: rockchip: disable mailbox of RK3368 SoCs defaultly

[PATCH v2 1/3] arm64: dts: rockchip: add amba node support for RK3368 SoCs

There are two dmacs found on RK3368 SoCs, peripher dmac and bus dmac, and the dmacs are same as previous SoCs' dmac. Signed-off-by: Jianqun Xu --- changes since v1: - none arch/arm64/boot/dts/rockchip/rk3368.dtsi | 31 +++ 1 file changed, 31 insertions(+) diff

[PATCH v2] kexec: Introduce vmcoreinfo signature verification

Currently vmcoreinfo data is updated at boot time subsys_initcall(), it has the risk of being modified by some wrong code during system is running. As a result, vmcore dumped may contain the wrong vmcoreinfo. Later on, when using "crash" or "makedumpfile"(etc) utility to parse this vmcore, we

[PATCH v2] kexec: Introduce vmcoreinfo signature verification

Currently vmcoreinfo data is updated at boot time subsys_initcall(), it has the risk of being modified by some wrong code during system is running. As a result, vmcore dumped may contain the wrong vmcoreinfo. Later on, when using "crash" or "makedumpfile"(etc) utility to parse this vmcore, we

Re: [HMM 07/16] mm/migrate: new memory migration helper for use with device memory v4

>> Or make the HMM Kconfig feature 64BIT only by making it depend on 64BIT? >> > > Yes, that was my first reaction too, but these particular routines are > aspiring to be generic routines--in fact, you have had an influence there, > because these might possibly help with NUMA migrations. :) >

Re: [HMM 07/16] mm/migrate: new memory migration helper for use with device memory v4

>> Or make the HMM Kconfig feature 64BIT only by making it depend on 64BIT? >> > > Yes, that was my first reaction too, but these particular routines are > aspiring to be generic routines--in fact, you have had an influence there, > because these might possibly help with NUMA migrations. :) >

[PATCH v2 3/3] arm64: dts: rockchip: disable mailbox of RK3368 SoCs defaultly

Default to disable mailbox in rk3368 core dts file. Signed-off-by: Jianqun Xu --- changes since v1: - none arch/arm64/boot/dts/rockchip/rk3368.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi

[PATCH v2 3/3] arm64: dts: rockchip: disable mailbox of RK3368 SoCs defaultly

Default to disable mailbox in rk3368 core dts file. Signed-off-by: Jianqun Xu --- changes since v1: - none arch/arm64/boot/dts/rockchip/rk3368.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi b/arch/arm64/boot/dts/rockchip/rk3368.dtsi index

RE: [PATCH net-next] r8152: simply the arguments

David Laight [mailto:david.lai...@aculab.com] > Sent: Thursday, March 16, 2017 10:28 PM [...] > If you are really lucky the compiler will optimise it away. > Otherwise it will generate another local variable and possibly > a register spill to stack. However, I could reduce the time for

RE: [PATCH net-next] r8152: simply the arguments

David Laight [mailto:david.lai...@aculab.com] > Sent: Thursday, March 16, 2017 10:28 PM [...] > If you are really lucky the compiler will optimise it away. > Otherwise it will generate another local variable and possibly > a register spill to stack. However, I could reduce the time for

[PATCH] f2fs: don't allow volatile writes for non-regular file

Now f2fs only supports volatile writes for journal db regular file. Signed-off-by: Chao Yu --- fs/f2fs/file.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index d486e02b43c2..e090d34f732d 100644 --- a/fs/f2fs/file.c +++

[PATCH] f2fs: don't allow volatile writes for non-regular file

Now f2fs only supports volatile writes for journal db regular file. Signed-off-by: Chao Yu --- fs/f2fs/file.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index d486e02b43c2..e090d34f732d 100644 --- a/fs/f2fs/file.c +++ b/fs/f2fs/file.c @@ -1593,6

Re: [HMM 07/16] mm/migrate: new memory migration helper for use with device memory v4

On Thu, 16 Mar 2017 21:52:23 -0400 (EDT) Jerome Glisse wrote: > The original intention was for it to be 64bit only, 32bit is a dying > species and before splitting out hmm_ prefix from this code and moving > it to be generic it was behind a 64bit flag. > > If latter one

[PATCH net-next] r8152: check hw version first

Check hw version first in probe(). Do nothing if the driver doesn't support the chip. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 102 ++-- 1 file changed, 63 insertions(+), 39 deletions(-) diff --git

Re: [HMM 07/16] mm/migrate: new memory migration helper for use with device memory v4

On Thu, 16 Mar 2017 21:52:23 -0400 (EDT) Jerome Glisse wrote: > The original intention was for it to be 64bit only, 32bit is a dying > species and before splitting out hmm_ prefix from this code and moving > it to be generic it was behind a 64bit flag. > > If latter one someone really care

[PATCH net-next] r8152: check hw version first

Check hw version first in probe(). Do nothing if the driver doesn't support the chip. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 102 ++-- 1 file changed, 63 insertions(+), 39 deletions(-) diff --git a/drivers/net/usb/r8152.c

Re: [PATCH v2 net-next 0/5] sunvnet: better connection management

From: Shannon Nelson Date: Tue, 14 Mar 2017 10:24:38 -0700 > These patches remove some problems in handling of carrier state > with the ldmvsw vswitch, remove an xoff misuse in sunvnet, and > add stats for debug and tracking of point-to-point connections > between the

Re: [PATCH v2 net-next 0/5] sunvnet: better connection management

From: Shannon Nelson Date: Tue, 14 Mar 2017 10:24:38 -0700 > These patches remove some problems in handling of carrier state > with the ldmvsw vswitch, remove an xoff misuse in sunvnet, and > add stats for debug and tracking of point-to-point connections > between the ldom VMs. > > v2: > -

Re: [PATCH] cpufreq: Restore policy min/max limits on CPU online

On 16-03-17, 23:42, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > On CPU online the cpufreq core restores the previous governor (or > the previous "policy" setting for ->setpolicy drivers), but it does > not restore the min/max limits at the same time, which

Re: [PATCH net-next] bonding: add 802.3ad support for 25G speeds

From: Jarod Wilson Date: Tue, 14 Mar 2017 11:48:32 -0400 > Cut-n-paste enablement of 802.3ad bonding on 25G NICs, which currently > report 0 as their bandwidth. > > CC: Jay Vosburgh > CC: Veaceslav Falico > CC: Andy Gospodarek

Re: [PATCH] cpufreq: Restore policy min/max limits on CPU online

On 16-03-17, 23:42, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > On CPU online the cpufreq core restores the previous governor (or > the previous "policy" setting for ->setpolicy drivers), but it does > not restore the min/max limits at the same time, which is confusing, > inconsistent

Re: [PATCH net-next] bonding: add 802.3ad support for 25G speeds

From: Jarod Wilson Date: Tue, 14 Mar 2017 11:48:32 -0400 > Cut-n-paste enablement of 802.3ad bonding on 25G NICs, which currently > report 0 as their bandwidth. > > CC: Jay Vosburgh > CC: Veaceslav Falico > CC: Andy Gospodarek > CC: net...@vger.kernel.org > Signed-off-by: Jarod Wilson

Re: [f2fs-dev] [PATCH 2/2] f2fs: don't allow atomic writes for not regular files

On 2017/3/17 10:09, Jaegeuk Kim wrote: > The atomic writes only supports regular files for database. > > Signed-off-by: Jaegeuk Kim > --- > fs/f2fs/file.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c > index

Re: [f2fs-dev] [PATCH 2/2] f2fs: don't allow atomic writes for not regular files

On 2017/3/17 10:09, Jaegeuk Kim wrote: > The atomic writes only supports regular files for database. > > Signed-off-by: Jaegeuk Kim > --- > fs/f2fs/file.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c > index da6d33d1bb34..d486e02b43c2 100644 > ---

Re: [RESEND PATCH -net] cpsw/netcp: work around reverse cpts dependency

From: Arnd Bergmann Date: Mon, 13 Mar 2017 17:59:04 +0100 > The dependency is reversed: cpsw and netcp call into cpts, > but cpts depends on the other two in Kconfig. This can lead > to cpts being a loadable module and its callers built-in: > > drivers/net/ethernet/ti/cpsw.o: In

Re: [RESEND PATCH -net] cpsw/netcp: work around reverse cpts dependency

From: Arnd Bergmann Date: Mon, 13 Mar 2017 17:59:04 +0100 > The dependency is reversed: cpsw and netcp call into cpts, > but cpts depends on the other two in Kconfig. This can lead > to cpts being a loadable module and its callers built-in: > > drivers/net/ethernet/ti/cpsw.o: In function

Re: [PATCH v2 0/5] mm: support parallel free of memory

On Wed, Mar 15, 2017 at 03:56:02PM +0100, Vlastimil Babka wrote: > I wonder if the difference would be larger if the parallelism was done > on a higher level, something around unmap_page_range(). IIUC the current I guess I misunderstand you in my last email - doing it at unmap_page_range() level

Re: [PATCH v2 0/5] mm: support parallel free of memory

On Wed, Mar 15, 2017 at 03:56:02PM +0100, Vlastimil Babka wrote: > I wonder if the difference would be larger if the parallelism was done > on a higher level, something around unmap_page_range(). IIUC the current I guess I misunderstand you in my last email - doing it at unmap_page_range() level

Re: [net-next PATCH 1/5] net: Do not record sender_cpu as napi_id in socket receive paths

On Thu, 2017-03-16 at 19:40 -0700, Alexander Duyck wrote: > What I probably can do is go through and replace all the spots where > we where checking for sk_napi_id being 0, and instead replace it with > a check against NR_CPUS. This seems a good idea.

Re: [net-next PATCH 1/5] net: Do not record sender_cpu as napi_id in socket receive paths

On Thu, 2017-03-16 at 19:40 -0700, Alexander Duyck wrote: > What I probably can do is go through and replace all the spots where > we where checking for sk_napi_id being 0, and instead replace it with > a check against NR_CPUS. This seems a good idea.

Re: [net-next PATCH 1/5] net: Do not record sender_cpu as napi_id in socket receive paths

On Thu, Mar 16, 2017 at 7:57 PM, Eric Dumazet wrote: > On Thu, 2017-03-16 at 19:40 -0700, Alexander Duyck wrote: > >> What I probably can do is go through and replace all the spots where >> we where checking for sk_napi_id being 0, and instead replace it with >> a check

Re: [net-next PATCH 1/5] net: Do not record sender_cpu as napi_id in socket receive paths

On Thu, Mar 16, 2017 at 7:57 PM, Eric Dumazet wrote: > On Thu, 2017-03-16 at 19:40 -0700, Alexander Duyck wrote: > >> What I probably can do is go through and replace all the spots where >> we where checking for sk_napi_id being 0, and instead replace it with >> a check against NR_CPUS. > > This

Re: [net-next PATCH 1/5] net: Do not record sender_cpu as napi_id in socket receive paths

On Thu, 2017-03-16 at 19:40 -0700, Alexander Duyck wrote: > I don't know. My concern here is about the cost of going through all > that code just for something that we know shouldn't be valid. If > nothing else I might update sk_can_busy_loop so that it doesn't try > busy looping on a

Re: [net-next PATCH 1/5] net: Do not record sender_cpu as napi_id in socket receive paths

On Thu, 2017-03-16 at 19:40 -0700, Alexander Duyck wrote: > I don't know. My concern here is about the cost of going through all > that code just for something that we know shouldn't be valid. If > nothing else I might update sk_can_busy_loop so that it doesn't try > busy looping on a

  1   2   3   4   5   6   7   8   9   10   >