[PATCH v2 0/3] PCI hotplug feature

These patches bring in PCI hotplug support for iproc family chipsets. It includes DT binding documentation update and, implementation in iproc pcie RC driver. These patch set is made on top of following patches. [PATCH v6 2/2] PCI: iproc: add device shutdown for PCI RC [PATCH v6 1/2] PCI: iproc:

[PATCH v2 3/3] PCI: iproc: Implement optional property prsnt-gpios

Add description for optional device tree property 'prsnt-gpios' for PCI hotplug feature. Signed-off-by: Oza Pawandeep Reviewed-by: Ray Jui diff --git a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt

[PATCH v2 2/3] Documentation/devicetree: Add PCIe hotplug property

Host drivers have the requirement of implementing PCI hotplug based on the how their SOC supports PCI hotplug. Couple of properties have been added. the one to enable the hotplug feature itself, and the other caters to the PCI hotplug implementation with the use of gpios. Signed-off-by: Oza

[PATCH v2 0/3] PCI hotplug feature

These patches bring in PCI hotplug support for iproc family chipsets. It includes DT binding documentation update and, implementation in iproc pcie RC driver. These patch set is made on top of following patches. [PATCH v6 2/2] PCI: iproc: add device shutdown for PCI RC [PATCH v6 1/2] PCI: iproc:

[PATCH v2 3/3] PCI: iproc: Implement optional property prsnt-gpios

Add description for optional device tree property 'prsnt-gpios' for PCI hotplug feature. Signed-off-by: Oza Pawandeep Reviewed-by: Ray Jui diff --git a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt index b8e48b4..0c5f631

[PATCH v2 2/3] Documentation/devicetree: Add PCIe hotplug property

Host drivers have the requirement of implementing PCI hotplug based on the how their SOC supports PCI hotplug. Couple of properties have been added. the one to enable the hotplug feature itself, and the other caters to the PCI hotplug implementation with the use of gpios. Signed-off-by: Oza

[PATCH v5] clk: sunxi-ng: support R40 SoC

Allwinner R40 SoC have a clock controller module in the style of the SoCs beyond sun6i, however, it's more rich and complex. Add support for it. Signed-off-by: Icenowy Zheng --- Changes in v5: - Added TODO's for PLL constraints. - Forced OHCI12M mux to 0. - Changed "adda" clock

[PATCH v2 1/3] PCI: iproc: Implement PCI hotplug support

This patch implements PCI hotplug support for iproc family chipsets. iproc based SOC (e.g. Stingray) does not have hotplug controller integrated. Hence, standard PCI hotplug framework hooks can-not be used. e.g. controlled power up/down of slot. The mechanism, for e.g. Stingray has adopted for

[PATCH v2 1/3] PCI: iproc: Implement PCI hotplug support

This patch implements PCI hotplug support for iproc family chipsets. iproc based SOC (e.g. Stingray) does not have hotplug controller integrated. Hence, standard PCI hotplug framework hooks can-not be used. e.g. controlled power up/down of slot. The mechanism, for e.g. Stingray has adopted for

[PATCH v5] clk: sunxi-ng: support R40 SoC

Allwinner R40 SoC have a clock controller module in the style of the SoCs beyond sun6i, however, it's more rich and complex. Add support for it. Signed-off-by: Icenowy Zheng --- Changes in v5: - Added TODO's for PLL constraints. - Forced OHCI12M mux to 0. - Changed "adda" clock to "codec" to be

Re: [patch] mm, oom: remove unused mmput_async

On Mon 14-08-17 17:34:32, David Rientjes wrote: > After "mm: oom: let oom_reap_task and exit_mmap to run concurrently", > mmput_async() is no longer used. Remove it. > > Cc: Andrea Arcangeli > Signed-off-by: David Rientjes Acked-by: Michal Hocko

Re: [PATCH] swap: choose swap device according to numa node

On Mon, Aug 14, 2017 at 04:33:37PM -0700, Andrew Morton wrote: > On Mon, 14 Aug 2017 13:31:30 +0800 Aaron Lu wrote: > > > --- /dev/null > > +++ b/Documentation/vm/swap_numa.txt > > @@ -0,0 +1,18 @@ > > +If the system has more than one swap device and swap device has the node

Re: [patch] mm, oom: remove unused mmput_async

On Mon 14-08-17 17:34:32, David Rientjes wrote: > After "mm: oom: let oom_reap_task and exit_mmap to run concurrently", > mmput_async() is no longer used. Remove it. > > Cc: Andrea Arcangeli > Signed-off-by: David Rientjes Acked-by: Michal Hocko Thanks! > --- > include/linux/sched/mm.h |

Re: [PATCH] swap: choose swap device according to numa node

On Mon, Aug 14, 2017 at 04:33:37PM -0700, Andrew Morton wrote: > On Mon, 14 Aug 2017 13:31:30 +0800 Aaron Lu wrote: > > > --- /dev/null > > +++ b/Documentation/vm/swap_numa.txt > > @@ -0,0 +1,18 @@ > > +If the system has more than one swap device and swap device has the node > > +information, we

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

On Mon, 2017-08-14 at 14:12 +0100, Robin Murphy wrote: > On the other hand, if the check is not so much to mitigate malicious > guests attacking the system as to prevent dumb guests breaking > themselves (e.g. if some or all of the MSI-X capability is actually > emulated), then allowing things to

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

On Mon, 2017-08-14 at 14:12 +0100, Robin Murphy wrote: > On the other hand, if the check is not so much to mitigate malicious > guests attacking the system as to prevent dumb guests breaking > themselves (e.g. if some or all of the MSI-X capability is actually > emulated), then allowing things to

Re: [PATCH 07/10] cpufreq: dt: Add support for some new Allwinner SoCs

On Mon, Jul 24, 2017 at 7:46 PM, Rafael J. Wysocki wrote: > On Monday, July 24, 2017 02:23:49 PM Viresh Kumar wrote: >> On 23-07-17, 18:27, Icenowy Zheng wrote: >> > Some new Allwinner SoCs get supported in the kernel after the >> > compatibles are added to cpufreq-dt-platdev

Re: [PATCH 07/10] cpufreq: dt: Add support for some new Allwinner SoCs

On Mon, Jul 24, 2017 at 7:46 PM, Rafael J. Wysocki wrote: > On Monday, July 24, 2017 02:23:49 PM Viresh Kumar wrote: >> On 23-07-17, 18:27, Icenowy Zheng wrote: >> > Some new Allwinner SoCs get supported in the kernel after the >> > compatibles are added to cpufreq-dt-platdev driver. >> > >> >

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

On Tue, 2017-08-15 at 09:47 +0800, Jike Song wrote: > On 08/15/2017 09:33 AM, Benjamin Herrenschmidt wrote: > > On Tue, 2017-08-15 at 09:16 +0800, Jike Song wrote: > > > > Taking a step back, though, why does vfio-pci perform this check in the > > > > first place? If a malicious guest already has

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

On Tue, 2017-08-15 at 09:47 +0800, Jike Song wrote: > On 08/15/2017 09:33 AM, Benjamin Herrenschmidt wrote: > > On Tue, 2017-08-15 at 09:16 +0800, Jike Song wrote: > > > > Taking a step back, though, why does vfio-pci perform this check in the > > > > first place? If a malicious guest already has

[PATCH] x86/xen/64: Fix the reported SS and CS in SYSCALL

When I cleaned up the Xen SYSCALL entries, I inadvertently changed the reported segment registers. Before my patch, regs->ss was __USER(32)_DS and regs->cs was __USER(32)_CS. After the patch, they are FLAT_USER_CS/DS(32). This had a couple unfortunate effects. It confused the opportunistic

[PATCH] x86/xen/64: Fix the reported SS and CS in SYSCALL

When I cleaned up the Xen SYSCALL entries, I inadvertently changed the reported segment registers. Before my patch, regs->ss was __USER(32)_DS and regs->cs was __USER(32)_CS. After the patch, they are FLAT_USER_CS/DS(32). This had a couple unfortunate effects. It confused the opportunistic

[PATCH 3/3] thunderbolt: Allow clearing the key

If secure authentication of a devices fails, either because the device already has another key uploaded, or there is some other error sending challenge to the device, and the user only wants to approve the device just once (without a new key being uploaded to the device) the current implementation

[PATCH 3/3] thunderbolt: Allow clearing the key

If secure authentication of a devices fails, either because the device already has another key uploaded, or there is some other error sending challenge to the device, and the user only wants to approve the device just once (without a new key being uploaded to the device) the current implementation

[PATCH 2/3] thunderbolt: Make key root-only accessible

Non-root user may read the key back after root wrote it there. This removes read access to everyone but root. Signed-off-by: Yehezkel Bernat --- drivers/thunderbolt/switch.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 2/3] thunderbolt: Make key root-only accessible

Non-root user may read the key back after root wrote it there. This removes read access to everyone but root. Signed-off-by: Yehezkel Bernat --- drivers/thunderbolt/switch.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thunderbolt/switch.c

[PATCH 1/3] thunderbolt: Remove superfluous check

The key size is tested by hex2bin() already (as '\0' isn't an hex digit) Suggested-by: Andy Shevchenko Signed-off-by: Yehezkel Bernat --- drivers/thunderbolt/switch.c | 3 --- 1 file changed, 3 deletions(-) diff --git

[PATCH 1/3] thunderbolt: Remove superfluous check

The key size is tested by hex2bin() already (as '\0' isn't an hex digit) Suggested-by: Andy Shevchenko Signed-off-by: Yehezkel Bernat --- drivers/thunderbolt/switch.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c index

Re: [PATCH v11 0/5] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

From: Ding Tianhong Date: Tue, 15 Aug 2017 11:23:22 +0800 > Some devices have problems with Transaction Layer Packets with the Relaxed > Ordering Attribute set. This patch set adds a new PCIe Device Flag, > PCI_DEV_FLAGS_NO_RELAXED_ORDERING, a set of PCI Quirks to catch

Re: [PATCH v11 0/5] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

From: Ding Tianhong Date: Tue, 15 Aug 2017 11:23:22 +0800 > Some devices have problems with Transaction Layer Packets with the Relaxed > Ordering Attribute set. This patch set adds a new PCIe Device Flag, > PCI_DEV_FLAGS_NO_RELAXED_ORDERING, a set of PCI Quirks to catch some known > devices

Re: [PATCH v5 18/19] crypto: mediatek: move to generic async completion

On Mon, 2017-08-14 at 18:21 +0300, Gilad Ben-Yossef wrote: > The mediatek driver starts several async crypto ops and waits for their > completions. Move it over to generic code doing the same. > > Signed-off-by: Gilad Ben-Yossef > --- Acked-by: Ryder Lee

Re: [PATCH v5 18/19] crypto: mediatek: move to generic async completion

On Mon, 2017-08-14 at 18:21 +0300, Gilad Ben-Yossef wrote: > The mediatek driver starts several async crypto ops and waits for their > completions. Move it over to generic code doing the same. > > Signed-off-by: Gilad Ben-Yossef > --- Acked-by: Ryder Lee > drivers/crypto/mediatek/mtk-aes.c |

Re: [PATCH] Input: ati_remote2: constify usb_device_id

On Tue, Aug 08, 2017 at 10:24:12PM +0530, Arvind Yadav wrote: > usb_device_id are not supposed to change at runtime. All functions > working with usb_device_id provided by work with > const usb_device_id. So mark the non-const structs as const. > > Signed-off-by: Arvind Yadav

Re: [PATCH] Input: ati_remote2: constify usb_device_id

On Tue, Aug 08, 2017 at 10:24:12PM +0530, Arvind Yadav wrote: > usb_device_id are not supposed to change at runtime. All functions > working with usb_device_id provided by work with > const usb_device_id. So mark the non-const structs as const. > > Signed-off-by: Arvind Yadav Applied, thank

Re: [PATCH 6/9 v2] Input: sun4i-ts - constify thermal_zone_of_device_ops structures

On Tue, Aug 08, 2017 at 05:09:00PM +0200, Julia Lawall wrote: > The thermal_zone_of_device_ops structure is only passed as the fourth > argument to devm_thermal_zone_of_sensor_register, which is declared > as const. Thus the thermal_zone_of_device_ops structure itself can > be const. > > Done

Re: [PATCH 6/9 v2] Input: sun4i-ts - constify thermal_zone_of_device_ops structures

On Tue, Aug 08, 2017 at 05:09:00PM +0200, Julia Lawall wrote: > The thermal_zone_of_device_ops structure is only passed as the fourth > argument to devm_thermal_zone_of_sensor_register, which is declared > as const. Thus the thermal_zone_of_device_ops structure itself can > be const. > > Done

Re: [PATCH net-next V2 3/3] tap: XDP support

On 2017年08月15日 00:01, Michael S. Tsirkin wrote: On Sat, Aug 12, 2017 at 10:48:49AM +0800, Jason Wang wrote: On 2017年08月12日 07:12, Jakub Kicinski wrote: On Fri, 11 Aug 2017 19:41:18 +0800, Jason Wang wrote: This patch tries to implement XDP for tun. The implementation was split into two

Re: [PATCH v7 7/9] mm: Add address parameter to arch_validate_prot()

Khalid Aziz writes: > On 08/10/2017 07:20 AM, Michael Ellerman wrote: >> Khalid Aziz writes: >> >>> A protection flag may not be valid across entire address space and >>> hence arch_validate_prot() might need the address a protection bit is >>>

Re: [PATCH net-next V2 3/3] tap: XDP support

On 2017年08月15日 00:01, Michael S. Tsirkin wrote: On Sat, Aug 12, 2017 at 10:48:49AM +0800, Jason Wang wrote: On 2017年08月12日 07:12, Jakub Kicinski wrote: On Fri, 11 Aug 2017 19:41:18 +0800, Jason Wang wrote: This patch tries to implement XDP for tun. The implementation was split into two

Re: [PATCH v7 7/9] mm: Add address parameter to arch_validate_prot()

Khalid Aziz writes: > On 08/10/2017 07:20 AM, Michael Ellerman wrote: >> Khalid Aziz writes: >> >>> A protection flag may not be valid across entire address space and >>> hence arch_validate_prot() might need the address a protection bit is >>> being set on to ensure it is a valid protection

[PATCH v2] gpio: add gpio_add_lookup_tables() to add several tables at once

When converting legacy board to use gpiod API() there might be several lookup tables in board file, let's provide a way to register them all at once. Reviewed-by: Andy Shevchenko Reviewed-by: Mika Westerberg Signed-off-by:

[PATCH v2] gpio: add gpio_add_lookup_tables() to add several tables at once

When converting legacy board to use gpiod API() there might be several lookup tables in board file, let's provide a way to register them all at once. Reviewed-by: Andy Shevchenko Reviewed-by: Mika Westerberg Signed-off-by: Dmitry Torokhov --- V2: - added the !CONFIG_GPIOLIB stub (Andy) -

Re: [PATCH net-next V2 3/3] tap: XDP support

On 2017年08月14日 16:43, Daniel Borkmann wrote: On 08/11/2017 01:41 PM, Jason Wang wrote: This patch tries to implement XDP for tun. The implementation was split into two parts: [...] @@ -1402,6 +1521,22 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,

Re: [PATCH net-next V2 3/3] tap: XDP support

On 2017年08月14日 16:43, Daniel Borkmann wrote: On 08/11/2017 01:41 PM, Jason Wang wrote: This patch tries to implement XDP for tun. The implementation was split into two parts: [...] @@ -1402,6 +1521,22 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,

Re: [PATCH] Input: elan_i2c - add ELAN0608 to the ACPI table

On Thu, Aug 10, 2017 at 04:53:52PM +0800, Kai-Heng Feng wrote: > Similar to commit 722c5ac708b4f ("Input: elan_i2c - add ELAN0605 to the > ACPI table"), ELAN0608 should be handled by elan_i2c. > > This touchpad can be found in Lenovo ideapad 320-14IKB. > > BugLink:

Re: [PATCH] Input: elan_i2c - add ELAN0608 to the ACPI table

On Thu, Aug 10, 2017 at 04:53:52PM +0800, Kai-Heng Feng wrote: > Similar to commit 722c5ac708b4f ("Input: elan_i2c - add ELAN0605 to the > ACPI table"), ELAN0608 should be handled by elan_i2c. > > This touchpad can be found in Lenovo ideapad 320-14IKB. > > BugLink:

Re: [PATCH v2] watchdog: dw_wdt: fix overflow issue in dw_wdt_top_in_seconds

On 08/14/2017 07:45 PM, Huibin Hong wrote: If top is 15, (1 << (16 + top)) may be negative. Signed-off-by: Huibin Hong --- Changes in v2: - Rebase mainline Linux 4.13-rc5 drivers/watchdog/dw_wdt.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)

Re: [PATCH v2] watchdog: dw_wdt: fix overflow issue in dw_wdt_top_in_seconds

On 08/14/2017 07:45 PM, Huibin Hong wrote: If top is 15, (1 << (16 + top)) may be negative. Signed-off-by: Huibin Hong --- Changes in v2: - Rebase mainline Linux 4.13-rc5 drivers/watchdog/dw_wdt.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git

RE: [PATCH 0/5] cramfs refresh for embedded usage

On Mon, 14 Aug 2017, Chris Brandt wrote: > On Monday, August 14, 2017, Nicolas Pitre wrote: > > > However, now with your mkcramfs tool, I can no longer mount my cramfs > > > image as the rootfs on boot. I was able to do that before (ie, 30 > > minutes > > > ago) when using the community mkcramfs

Re: [linux-sunxi] [PATCH v6] arm64: allwinner: a64: Add initial NanoPi A64 support

On Tue, Aug 15, 2017 at 11:51 AM, Jagan Teki wrote: > On Tue, Aug 15, 2017 at 9:14 AM, Chen-Yu Tsai wrote: >> On Mon, Aug 14, 2017 at 6:36 PM, Jagan Teki wrote: [...] >>> +/* i2c1 connected with gpio headers like pine64,

Re: [PATCH v2] f2fs: introduce cur_reserved_blocks in sysfs

ping... On 2017/8/11 19:43, Yunlong Song wrote: In this patch, we add a new sysfs interface, we can use it to gradually achieve the reserved_blocks finally, even when reserved_blocks is initially set over user_block_count - total_valid_block_count. This is very useful, especially when we

RE: [PATCH 0/5] cramfs refresh for embedded usage

On Mon, 14 Aug 2017, Chris Brandt wrote: > On Monday, August 14, 2017, Nicolas Pitre wrote: > > > However, now with your mkcramfs tool, I can no longer mount my cramfs > > > image as the rootfs on boot. I was able to do that before (ie, 30 > > minutes > > > ago) when using the community mkcramfs

Re: [linux-sunxi] [PATCH v6] arm64: allwinner: a64: Add initial NanoPi A64 support

On Tue, Aug 15, 2017 at 11:51 AM, Jagan Teki wrote: > On Tue, Aug 15, 2017 at 9:14 AM, Chen-Yu Tsai wrote: >> On Mon, Aug 14, 2017 at 6:36 PM, Jagan Teki wrote: [...] >>> +/* i2c1 connected with gpio headers like pine64, bananapi */ >>> + { >>> + pinctrl-names = "default"; >>> +

Re: [PATCH v2] f2fs: introduce cur_reserved_blocks in sysfs

ping... On 2017/8/11 19:43, Yunlong Song wrote: In this patch, we add a new sysfs interface, we can use it to gradually achieve the reserved_blocks finally, even when reserved_blocks is initially set over user_block_count - total_valid_block_count. This is very useful, especially when we

Re: [PATCH v3] arm64: allwinner: a64: Add A64-OLinuXino initial support

On Mon, Aug 14, 2017 at 6:46 PM, Jagan Teki wrote: > From: Jagan Teki > > OLimex A64-OLinuXino is an open-source hardware board > using the Allwinner A64 SOC. > > OLimex A64-OLinuXino has > - A64 Quad-core Cortex-A53 64bit > - 1GB or 2GB RAM

Re: [PATCH v3] arm64: allwinner: a64: Add A64-OLinuXino initial support

On Mon, Aug 14, 2017 at 6:46 PM, Jagan Teki wrote: > From: Jagan Teki > > OLimex A64-OLinuXino is an open-source hardware board > using the Allwinner A64 SOC. > > OLimex A64-OLinuXino has > - A64 Quad-core Cortex-A53 64bit > - 1GB or 2GB RAM DDR3L @ 672Mhz > - microSD slot and 4/8/16GB eMMC > -

Re: [linux-sunxi] [PATCH v6] arm64: allwinner: a64: Add initial NanoPi A64 support

On Tue, Aug 15, 2017 at 9:14 AM, Chen-Yu Tsai wrote: > On Mon, Aug 14, 2017 at 6:36 PM, Jagan Teki wrote: >> From: Jagan Teki >> >> NanoPi A64 is a new board of high performance with low cost >> designed by FriendlyElec.,

Re: [linux-sunxi] [PATCH v6] arm64: allwinner: a64: Add initial NanoPi A64 support

On Tue, Aug 15, 2017 at 9:14 AM, Chen-Yu Tsai wrote: > On Mon, Aug 14, 2017 at 6:36 PM, Jagan Teki wrote: >> From: Jagan Teki >> >> NanoPi A64 is a new board of high performance with low cost >> designed by FriendlyElec., using the Allwinner A64 SOC. >> >> Nanopi A64 features >> - Allwinner

Re: [PATCH v5 02/10] mm, x86: Add support for eXclusive Page Frame Ownership (XPFO)

On Mon, Aug 14, 2017 at 09:47:18PM -0600, Tycho Andersen wrote: > I'll do that for the next version Actually looking closer, I think we just need to mirror the debug_pagealloc_enabled() checks in set_kpte() from split_large_page(), diff --git a/arch/x86/mm/xpfo.c b/arch/x86/mm/xpfo.c index

Re: [PATCH v5 02/10] mm, x86: Add support for eXclusive Page Frame Ownership (XPFO)

On Mon, Aug 14, 2017 at 09:47:18PM -0600, Tycho Andersen wrote: > I'll do that for the next version Actually looking closer, I think we just need to mirror the debug_pagealloc_enabled() checks in set_kpte() from split_large_page(), diff --git a/arch/x86/mm/xpfo.c b/arch/x86/mm/xpfo.c index

[PATCH v5 2/3] ARM: dts: Add LVDS info for rk3288

add LVDS info in rk3288.dtsi for LVDS driver This based on the patches from Mark yao and Heiko Stuebner. Signed-off-by: Sandy Huang Signed-off-by: Mark yao Signed-off-by: Heiko Stuebner --- arch/arm/boot/dts/rk3288.dtsi | 52

[PATCH v5 2/3] ARM: dts: Add LVDS info for rk3288

add LVDS info in rk3288.dtsi for LVDS driver This based on the patches from Mark yao and Heiko Stuebner. Signed-off-by: Sandy Huang Signed-off-by: Mark yao Signed-off-by: Heiko Stuebner --- arch/arm/boot/dts/rk3288.dtsi | 52 +++ 1 file changed, 52

Re: [PATCH v4 3/3] drm/rockchip: Add support for Rockchip Soc LVDS

Hi mark, Thanks for you review. 在 2017/8/15 9:53, Mark yao 写道: Hi Sandy On 2017年08月15日 08:56, Sandy Huang wrote: This adds support for Rockchip soc lvds found on rk3288 Based on the patches from Mark yao and Heiko Stuebner Signed-off-by: Sandy Huang Signed-off-by:

Re: [PATCH v4 3/3] drm/rockchip: Add support for Rockchip Soc LVDS

Hi mark, Thanks for you review. 在 2017/8/15 9:53, Mark yao 写道: Hi Sandy On 2017年08月15日 08:56, Sandy Huang wrote: This adds support for Rockchip soc lvds found on rk3288 Based on the patches from Mark yao and Heiko Stuebner Signed-off-by: Sandy Huang Signed-off-by: Mark yao

[PATCH v5 1/3] dt-bindings: display: Add Document for Rockchip Soc LVDS

This patch add Document for Rockchip Soc RK3288 LVDS, This based on the patches from Mark yao and Heiko Stuebner. Signed-off-by: Sandy Huang Signed-off-by: Mark yao Signed-off-by: Heiko Stuebner --- Changes according to Mark Yao

[PATCH v5 1/3] dt-bindings: display: Add Document for Rockchip Soc LVDS

This patch add Document for Rockchip Soc RK3288 LVDS, This based on the patches from Mark yao and Heiko Stuebner. Signed-off-by: Sandy Huang Signed-off-by: Mark yao Signed-off-by: Heiko Stuebner --- Changes according to Mark Yao reviews. .../bindings/display/rockchip/rockchip-lvds.txt|

[PATCH v5 3/3] drm/rockchip: Add support for Rockchip Soc LVDS

This adds support for Rockchip soc lvds found on rk3288 Based on the patches from Mark yao and Heiko Stuebner Signed-off-by: Sandy Huang Signed-off-by: Mark Yao Signed-off-by: Heiko Stuebner --- drivers/gpu/drm/rockchip/Kconfig

[PATCH v5 3/3] drm/rockchip: Add support for Rockchip Soc LVDS

This adds support for Rockchip soc lvds found on rk3288 Based on the patches from Mark yao and Heiko Stuebner Signed-off-by: Sandy Huang Signed-off-by: Mark Yao Signed-off-by: Heiko Stuebner --- drivers/gpu/drm/rockchip/Kconfig| 9 + drivers/gpu/drm/rockchip/Makefile |

[PATCH v5 0/3] Add support Rockchip Soc LVDS

[0]: https://github.com/RockchipOpensourceCommunity/popmetal-kernel-3.14 ]: http://lists.infradead.org/pipermail/linux-rockchip/2015-April/002830.html Changes: - Update rockchip_lvds_encoder_helper_funcs to atomic API - Add bridge function for RGB/LVDS convert to other output type - Fix some

[PATCH v5 0/3] Add support Rockchip Soc LVDS

[0]: https://github.com/RockchipOpensourceCommunity/popmetal-kernel-3.14 ]: http://lists.infradead.org/pipermail/linux-rockchip/2015-April/002830.html Changes: - Update rockchip_lvds_encoder_helper_funcs to atomic API - Add bridge function for RGB/LVDS convert to other output type - Fix some

Re: [PATCH v5 02/10] mm, x86: Add support for eXclusive Page Frame Ownership (XPFO)

Hi Laura, On Mon, Aug 14, 2017 at 03:30:00PM -0700, Laura Abbott wrote: > On 08/09/2017 01:07 PM, Tycho Andersen wrote: > > +/* Update a single kernel page table entry */ > > +inline void set_kpte(void *kaddr, struct page *page, pgprot_t prot) > > +{ > > + unsigned int level; > > + pgprot_t

Re: [PATCH v5 02/10] mm, x86: Add support for eXclusive Page Frame Ownership (XPFO)

Hi Laura, On Mon, Aug 14, 2017 at 03:30:00PM -0700, Laura Abbott wrote: > On 08/09/2017 01:07 PM, Tycho Andersen wrote: > > +/* Update a single kernel page table entry */ > > +inline void set_kpte(void *kaddr, struct page *page, pgprot_t prot) > > +{ > > + unsigned int level; > > + pgprot_t

Re: [PATCH v4] f2fs: introduce discard_granularity sysfs entry

On 08/07, Chao Yu wrote: > From: Chao Yu > > Commit d618ebaf0aa8 ("f2fs: enable small discard by default") enables > f2fs to issue 4K size discard in real-time discard mode. However, issuing > smaller discard may cost more lifetime but releasing less free space in > flash

Re: [PATCH v4] f2fs: introduce discard_granularity sysfs entry

On 08/07, Chao Yu wrote: > From: Chao Yu > > Commit d618ebaf0aa8 ("f2fs: enable small discard by default") enables > f2fs to issue 4K size discard in real-time discard mode. However, issuing > smaller discard may cost more lifetime but releasing less free space in > flash device. Since f2fs has

Re: [linux-sunxi] [PATCH v6] arm64: allwinner: a64: Add initial NanoPi A64 support

On Mon, Aug 14, 2017 at 6:36 PM, Jagan Teki wrote: > From: Jagan Teki > > NanoPi A64 is a new board of high performance with low cost > designed by FriendlyElec., using the Allwinner A64 SOC. > > Nanopi A64 features > - Allwinner A64, 64-bit

Re: [linux-sunxi] [PATCH v6] arm64: allwinner: a64: Add initial NanoPi A64 support

On Mon, Aug 14, 2017 at 6:36 PM, Jagan Teki wrote: > From: Jagan Teki > > NanoPi A64 is a new board of high performance with low cost > designed by FriendlyElec., using the Allwinner A64 SOC. > > Nanopi A64 features > - Allwinner A64, 64-bit Quad-core Cortex-A53@648MHz to 1.152GHz, DVFS > - 1GB

Re: [PATCH] f2fs: free_user_blocks should use reserved_segments instead

On 08/14, Yunlong Song wrote: > The part (overprovision_segments - reserved_segments) can still be used for > LFS, > so free_use_blocks should use reserved_segments instead, rather than use > overprovision_segments. > > Signed-off-by: Yunlong Song > --- > fs/f2fs/gc.h

Re: [PATCH] f2fs: free_user_blocks should use reserved_segments instead

On 08/14, Yunlong Song wrote: > The part (overprovision_segments - reserved_segments) can still be used for > LFS, > so free_use_blocks should use reserved_segments instead, rather than use > overprovision_segments. > > Signed-off-by: Yunlong Song > --- > fs/f2fs/gc.h | 4 ++-- > 1 file

Re: [PATCH 1/2] sched/wait: Break up long wake list walk

On Mon, Aug 14, 2017 at 8:15 PM, Andi Kleen wrote: > But what should we do when some other (non page) wait queue runs into the > same problem? Hopefully the same: root-cause it. Once you have a test-case, it should generally be fairly simple to do with profiles, just

Re: [PATCH 1/2] sched/wait: Break up long wake list walk

On Mon, Aug 14, 2017 at 8:15 PM, Andi Kleen wrote: > But what should we do when some other (non page) wait queue runs into the > same problem? Hopefully the same: root-cause it. Once you have a test-case, it should generally be fairly simple to do with profiles, just seeing who the caller is

[PATCH v11 5/5] net/cxgb4vf: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

From: Casey Leedom cxgb4vf Ethernet driver now queries PCIe configuration space to determine if it can send TLPs to it with the Relaxed Ordering Attribute set, just like the pf did. Signed-off-by: Casey Leedom Signed-off-by: Ding Tianhong

[PATCH v11 5/5] net/cxgb4vf: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

From: Casey Leedom cxgb4vf Ethernet driver now queries PCIe configuration space to determine if it can send TLPs to it with the Relaxed Ordering Attribute set, just like the pf did. Signed-off-by: Casey Leedom Signed-off-by: Ding Tianhong Reviewed-by: Casey Leedom ---

[PATCH v11 2/5] PCI: Disable Relaxed Ordering for some Intel processors

According to the Intel spec section 3.9.1 said: 3.9.1 Optimizing PCIe Performance for Accesses Toward Coherent Memory and Toward MMIO Regions (P2P) In order to maximize performance for PCIe devices in the processors listed in Table 3-6 below, the soft- ware should determine

[PATCH v11 2/5] PCI: Disable Relaxed Ordering for some Intel processors

According to the Intel spec section 3.9.1 said: 3.9.1 Optimizing PCIe Performance for Accesses Toward Coherent Memory and Toward MMIO Regions (P2P) In order to maximize performance for PCIe devices in the processors listed in Table 3-6 below, the soft- ware should determine

[PATCH v11 4/5] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

From: Casey Leedom cxgb4 Ethernet driver now queries PCIe configuration space to determine if it can send TLPs to it with the Relaxed Ordering Attribute set. Remove the enable_pcie_relaxed_ordering() to avoid enable PCIe Capability Device Control[Relaxed Ordering Enable] at

[PATCH v11 4/5] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

From: Casey Leedom cxgb4 Ethernet driver now queries PCIe configuration space to determine if it can send TLPs to it with the Relaxed Ordering Attribute set. Remove the enable_pcie_relaxed_ordering() to avoid enable PCIe Capability Device Control[Relaxed Ordering Enable] at probe routine, to

[PATCH v11 3/5] PCI: Disable Relaxed Ordering Attributes for AMD A1100

Casey reported that the AMD ARM A1100 SoC has a bug in its PCIe Root Port where Upstream Transaction Layer Packets with the Relaxed Ordering Attribute clear are allowed to bypass earlier TLPs with Relaxed Ordering set, it would cause Data Corruption, so we need to disable Relaxed Ordering

[PATCH v11 3/5] PCI: Disable Relaxed Ordering Attributes for AMD A1100

Casey reported that the AMD ARM A1100 SoC has a bug in its PCIe Root Port where Upstream Transaction Layer Packets with the Relaxed Ordering Attribute clear are allowed to bypass earlier TLPs with Relaxed Ordering set, it would cause Data Corruption, so we need to disable Relaxed Ordering

[PATCH v11 1/5] PCI: Disable PCIe Relaxed Ordering if unsupported

When bit4 is set in the PCIe Device Control register, it indicates whether the device is permitted to use relaxed ordering. On some platforms using relaxed ordering can have performance issues or due to erratum can cause data-corruption. In such cases devices must avoid using relaxed ordering.

[PATCH v11 1/5] PCI: Disable PCIe Relaxed Ordering if unsupported

When bit4 is set in the PCIe Device Control register, it indicates whether the device is permitted to use relaxed ordering. On some platforms using relaxed ordering can have performance issues or due to erratum can cause data-corruption. In such cases devices must avoid using relaxed ordering.

[PATCH v11 0/5] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

Some devices have problems with Transaction Layer Packets with the Relaxed Ordering Attribute set. This patch set adds a new PCIe Device Flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING, a set of PCI Quirks to catch some known devices with Relaxed Ordering issues, and a use of this new flag by the cxgb4

Re: [PATCH] f2fs-tools: the overprovision should be 0 as default

On 08/11, Yunlong Song wrote: > The usage message gives a wrong number, so fix it. > > Signed-off-by: Yunlong Song > --- > mkfs/f2fs_format_main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mkfs/f2fs_format_main.c b/mkfs/f2fs_format_main.c

[PATCH v11 0/5] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

Some devices have problems with Transaction Layer Packets with the Relaxed Ordering Attribute set. This patch set adds a new PCIe Device Flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING, a set of PCI Quirks to catch some known devices with Relaxed Ordering issues, and a use of this new flag by the cxgb4

Re: [PATCH] f2fs-tools: the overprovision should be 0 as default

On 08/11, Yunlong Song wrote: > The usage message gives a wrong number, so fix it. > > Signed-off-by: Yunlong Song > --- > mkfs/f2fs_format_main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mkfs/f2fs_format_main.c b/mkfs/f2fs_format_main.c > index a3652a9..6712b5c

Re: [PATCH] f2fs: let fill_super handle roll-forward errors

On 08/15, Chao Yu wrote: > Hi Jaegeuk, > > On 2017/8/11 8:42, Jaegeuk Kim wrote: > > If we set CP_ERROR_FLAG in roll-forward error, f2fs is no longer to proceed > > any IOs due to f2fs_cp_error(). But, for example, if some stale data is > > involved > > on roll-forward process, we're able to get

Re: [PATCH] f2fs: let fill_super handle roll-forward errors

On 08/15, Chao Yu wrote: > Hi Jaegeuk, > > On 2017/8/11 8:42, Jaegeuk Kim wrote: > > If we set CP_ERROR_FLAG in roll-forward error, f2fs is no longer to proceed > > any IOs due to f2fs_cp_error(). But, for example, if some stale data is > > involved > > on roll-forward process, we're able to get

Re: [PATCH] perf report: calculate the average cycles of iterations

On Mon, Aug 14, 2017 at 01:30:29AM +, Jin, Yao wrote: > Hi Andi, > > Do you have any comments for this patch? Patch looks good to me. Reviewed-by: Andi Kleen -Andi

Re: [PATCH] perf report: calculate the average cycles of iterations

On Mon, Aug 14, 2017 at 01:30:29AM +, Jin, Yao wrote: > Hi Andi, > > Do you have any comments for this patch? Patch looks good to me. Reviewed-by: Andi Kleen -Andi

Re: [PATCH] Input: elan_i2c - Add antoher Lenovo ACPI ID for upcoming Lenovo NB Add 2 ACPI IC ELAN0609, ELAN060B in the ACPI mapping table Signed-off-by: KT Liao <kt.l...@emc.com.tw>

On Fri, Aug 11, 2017 at 03:10:04PM +0800, KT Liao wrote: Applied, however please make sure that there is a blank line in your commit messages between the first line (subject) and the subsequent lines comprising the patch description: it will allow the tools work properly and not create emails

Re: [PATCH] Input: elan_i2c - Add antoher Lenovo ACPI ID for upcoming Lenovo NB Add 2 ACPI IC ELAN0609, ELAN060B in the ACPI mapping table Signed-off-by: KT Liao

On Fri, Aug 11, 2017 at 03:10:04PM +0800, KT Liao wrote: Applied, however please make sure that there is a blank line in your commit messages between the first line (subject) and the subsequent lines comprising the patch description: it will allow the tools work properly and not create emails

  1   2   3   4   5   6   7   8   9   10   >