Re: linux-next: manual merge of the userns tree with the mips tree

On Tue, Aug 08, 2017 at 03:10:04PM +1000, Stephen Rothwell wrote: (Maciej added to cc.) > Hi Eric, > > Today's linux-next merge of the userns tree got a conflict in: > > arch/mips/kernel/traps.c > > between commit: > > 260a789828aa ("MIPS: signal: Remove unreachable code from >

Re: linux-next: manual merge of the userns tree with the mips tree

On Tue, Aug 08, 2017 at 03:10:04PM +1000, Stephen Rothwell wrote: (Maciej added to cc.) > Hi Eric, > > Today's linux-next merge of the userns tree got a conflict in: > > arch/mips/kernel/traps.c > > between commit: > > 260a789828aa ("MIPS: signal: Remove unreachable code from >

[PATCH] mmc: mxcmmc: Handle return value of clk_prepare_enable

clk_prepare_enable() can fail here and we must check its return value. Signed-off-by: Arvind Yadav --- drivers/mmc/host/mxcmmc.c | 25 +++-- 1 file changed, 19 insertions(+), 6 deletions(-) diff --git a/drivers/mmc/host/mxcmmc.c

[PATCH] mmc: mxcmmc: Handle return value of clk_prepare_enable

clk_prepare_enable() can fail here and we must check its return value. Signed-off-by: Arvind Yadav --- drivers/mmc/host/mxcmmc.c | 25 +++-- 1 file changed, 19 insertions(+), 6 deletions(-) diff --git a/drivers/mmc/host/mxcmmc.c b/drivers/mmc/host/mxcmmc.c index

Re: [lkp-robot] [mm] 7674270022: will-it-scale.per_process_ops -19.3% regression

Nadav Amit wrote: > Minchan Kim wrote: > >> Hi, >> >> On Tue, Aug 08, 2017 at 09:19:23AM +0800, kernel test robot wrote: >>> Greeting, >>> >>> FYI, we noticed a -19.3% regression of will-it-scale.per_process_ops due to >>> commit: >>> >>> >>>

Re: [lkp-robot] [mm] 7674270022: will-it-scale.per_process_ops -19.3% regression

Nadav Amit wrote: > Minchan Kim wrote: > >> Hi, >> >> On Tue, Aug 08, 2017 at 09:19:23AM +0800, kernel test robot wrote: >>> Greeting, >>> >>> FYI, we noticed a -19.3% regression of will-it-scale.per_process_ops due to >>> commit: >>> >>> >>> commit:

[PATCH] mmc: wmt-sdmmc: Handle return value of clk_prepare_enable

clk_prepare_enable() can fail here and we must check its return value. Signed-off-by: Arvind Yadav --- drivers/mmc/host/wmt-sdmmc.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/host/wmt-sdmmc.c b/drivers/mmc/host/wmt-sdmmc.c

[PATCH] mmc: wmt-sdmmc: Handle return value of clk_prepare_enable

clk_prepare_enable() can fail here and we must check its return value. Signed-off-by: Arvind Yadav --- drivers/mmc/host/wmt-sdmmc.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/host/wmt-sdmmc.c b/drivers/mmc/host/wmt-sdmmc.c index 21ebba8..e64f930 100644

[PATCH 1/4] usb: mtu3: add generic compatible string

The mtu3 driver is a generic driver for MediaTek usb3 DRD IP, add a generic compatible to avoid confusion when support new SoCs but use a compatible with specific SoC's name "mt8173". Signed-off-by: Chunfeng Yun --- drivers/usb/mtu3/mtu3_plat.c |1 + 1 file

[PATCH 1/4] usb: mtu3: add generic compatible string

The mtu3 driver is a generic driver for MediaTek usb3 DRD IP, add a generic compatible to avoid confusion when support new SoCs but use a compatible with specific SoC's name "mt8173". Signed-off-by: Chunfeng Yun --- drivers/usb/mtu3/mtu3_plat.c |1 + 1 file changed, 1 insertion(+) diff

[PATCH 2/4] usb: xhci-mtk: add generic compatible string

The xhci-mtk driver is a generic driver for MediaTek xHCI IP, add a generic compatible to avoid confusion when support new SoCs but use a compatible with specific SoC's name "mt8173". Signed-off-by: Chunfeng Yun --- drivers/usb/host/xhci-mtk.c |1 + 1 file

[PATCH 2/4] usb: xhci-mtk: add generic compatible string

The xhci-mtk driver is a generic driver for MediaTek xHCI IP, add a generic compatible to avoid confusion when support new SoCs but use a compatible with specific SoC's name "mt8173". Signed-off-by: Chunfeng Yun --- drivers/usb/host/xhci-mtk.c |1 + 1 file changed, 1 insertion(+) diff

[PATCH 3/4] dt-bindings: mt8173-mtu3: add generic compatible and rename file

The mt8173-mtu3.txt actually holds the bindings for all mediatek SoCs with usb3 DRD IP, so add a generic compatible and change the name to mtu3.txt. Signed-off-by: Chunfeng Yun --- .../bindings/usb/{mt8173-mtu3.txt => mtu3.txt} |6 -- 1 file changed, 4

[PATCH 3/4] dt-bindings: mt8173-mtu3: add generic compatible and rename file

The mt8173-mtu3.txt actually holds the bindings for all mediatek SoCs with usb3 DRD IP, so add a generic compatible and change the name to mtu3.txt. Signed-off-by: Chunfeng Yun --- .../bindings/usb/{mt8173-mtu3.txt => mtu3.txt} |6 -- 1 file changed, 4 insertions(+), 2 deletions(-)

[PATCH 4/4] dt-bindings: mt8173-xhci: add generic compatible and rename file

The mt8173-xhci.txt actually holds the bindings for all mediatek SoCs with xHCI controller, so add a generic compatible and change the name to xhci-mtk.txt to reflect that. Signed-off-by: Chunfeng Yun --- .../bindings/usb/{mt8173-xhci.txt => xhci-mtk.txt} | 10

[PATCH 4/4] dt-bindings: mt8173-xhci: add generic compatible and rename file

The mt8173-xhci.txt actually holds the bindings for all mediatek SoCs with xHCI controller, so add a generic compatible and change the name to xhci-mtk.txt to reflect that. Signed-off-by: Chunfeng Yun --- .../bindings/usb/{mt8173-xhci.txt => xhci-mtk.txt} | 10 +++--- 1 file changed, 7

[PATCH] ARM: dts: DRA7: Add pcie1 dt node for EP mode

Add pcie1 dt node in order for the controller to operate in endpoint mode. However since none of the dra7 based boards have slots configured to operate in endpoint mode, keep EP mode disabled. Signed-off-by: Kishon Vijay Abraham I --- arch/arm/boot/dts/am571x-idk.dts

[PATCH] ARM: dts: DRA7: Add pcie1 dt node for EP mode

Add pcie1 dt node in order for the controller to operate in endpoint mode. However since none of the dra7 based boards have slots configured to operate in endpoint mode, keep EP mode disabled. Signed-off-by: Kishon Vijay Abraham I --- arch/arm/boot/dts/am571x-idk.dts| 9

[PATCH] memory: mtk-smi: Handle return value of clk_prepare_enable

clk_prepare_enable() can fail here and we must check its return value. Signed-off-by: Arvind Yadav --- drivers/memory/mtk-smi.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c index

[PATCH] memory: mtk-smi: Handle return value of clk_prepare_enable

clk_prepare_enable() can fail here and we must check its return value. Signed-off-by: Arvind Yadav --- drivers/memory/mtk-smi.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c index 4afbc41..edf36f0 100644 ---

Re: [RFC PATCH 0/1] Add hugetlbfs support to memfd_create()

Hi, I am one foot out of office and will be offline for two days so I didn't get to review the patch yet but this information is an useful information about the usecase that should be in the patch directly for future reference. On Mon 07-08-17 16:47:51, Mike Kravetz wrote: > This patch came out

Re: [RFC PATCH 0/1] Add hugetlbfs support to memfd_create()

Hi, I am one foot out of office and will be offline for two days so I didn't get to review the patch yet but this information is an useful information about the usecase that should be in the patch directly for future reference. On Mon 07-08-17 16:47:51, Mike Kravetz wrote: > This patch came out

Re: [PATCH] mm: ratelimit PFNs busy info message

Andrew Morton writes: > On Wed, 2 Aug 2017 13:44:57 -0400 Jonathan Toppins > wrote: > >> The RDMA subsystem can generate several thousand of these messages per >> second eventually leading to a kernel crash. Ratelimit these messages >> to

Re: [PATCH] mm: ratelimit PFNs busy info message

Andrew Morton writes: > On Wed, 2 Aug 2017 13:44:57 -0400 Jonathan Toppins > wrote: > >> The RDMA subsystem can generate several thousand of these messages per >> second eventually leading to a kernel crash. Ratelimit these messages >> to prevent this crash. > > Well... why are all these

Re: [RESEND PATCH] bcache: Don't reinvent the wheel but use existing llist API

On 2017/8/8 下午12:12, Byungchul Park wrote: > On Mon, Aug 07, 2017 at 06:18:35PM +0800, Coly Li wrote: >> On 2017/8/7 下午4:38, Byungchul Park wrote: >>> Although llist provides proper APIs, they are not used. Make them used. >>> >>> Signed-off-by: Byungchul Park > Only have

Re: [RESEND PATCH] bcache: Don't reinvent the wheel but use existing llist API

On 2017/8/8 下午12:12, Byungchul Park wrote: > On Mon, Aug 07, 2017 at 06:18:35PM +0800, Coly Li wrote: >> On 2017/8/7 下午4:38, Byungchul Park wrote: >>> Although llist provides proper APIs, they are not used. Make them used. >>> >>> Signed-off-by: Byungchul Park > Only have a question about why not

Re: [PATCH] arm64: correct modules range of kernel virtual memory layout

On Tue, 2017-08-08 at 12:44 +0800, Miles Chen wrote: > On Mon, 2017-08-07 at 15:01 +0100, Will Deacon wrote: > > On Mon, Aug 07, 2017 at 02:18:00PM +0100, Ard Biesheuvel wrote: > > > On 7 August 2017 at 14:16, Will Deacon wrote: > > > > On Mon, Aug 07, 2017 at 07:04:46PM

Re: [PATCH] arm64: correct modules range of kernel virtual memory layout

On Tue, 2017-08-08 at 12:44 +0800, Miles Chen wrote: > On Mon, 2017-08-07 at 15:01 +0100, Will Deacon wrote: > > On Mon, Aug 07, 2017 at 02:18:00PM +0100, Ard Biesheuvel wrote: > > > On 7 August 2017 at 14:16, Will Deacon wrote: > > > > On Mon, Aug 07, 2017 at 07:04:46PM +0800, Miles Chen wrote:

[PATCH 2/2] ARM: dts: am572x-idk: Fix GPIO polarity for MMC1 card detect

The GPIO polarity for MMC1 card detect is set to '0' which means active-high. However the polarity should be active-low. Fix it here. Signed-off-by: Kishon Vijay Abraham I --- arch/arm/boot/dts/am572x-idk.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 1/2] ARM: dts: am571x-idk: Fix GPIO polarity for MMC1 card detect

The GPIO polarity for MMC1 card detect is set to '0' which means active-high. However the polarity should be active-low. Fix it here. Signed-off-by: Kishon Vijay Abraham I --- arch/arm/boot/dts/am571x-idk.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 2/2] ARM: dts: am572x-idk: Fix GPIO polarity for MMC1 card detect

The GPIO polarity for MMC1 card detect is set to '0' which means active-high. However the polarity should be active-low. Fix it here. Signed-off-by: Kishon Vijay Abraham I --- arch/arm/boot/dts/am572x-idk.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 1/2] ARM: dts: am571x-idk: Fix GPIO polarity for MMC1 card detect

The GPIO polarity for MMC1 card detect is set to '0' which means active-high. However the polarity should be active-low. Fix it here. Signed-off-by: Kishon Vijay Abraham I --- arch/arm/boot/dts/am571x-idk.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] mmc: host: omap_hsmmc: Add CMD23 capability to omap_hsmmc driver

omap_hsmmc driver always relied on CMD12 to stop transmission. However if CMD12 is not issued at the correct timing, the card will indicate a out of range error. With certain cards in some of the DRA7 based boards, -EIO error is observed. By Adding CMD23 capability, the MMC core will send

[PATCH] mmc: host: omap_hsmmc: Add CMD23 capability to omap_hsmmc driver

omap_hsmmc driver always relied on CMD12 to stop transmission. However if CMD12 is not issued at the correct timing, the card will indicate a out of range error. With certain cards in some of the DRA7 based boards, -EIO error is observed. By Adding CMD23 capability, the MMC core will send

linux-next: manual merge of the userns tree with the mips tree

Hi Eric, Today's linux-next merge of the userns tree got a conflict in: arch/mips/kernel/traps.c between commit: 260a789828aa ("MIPS: signal: Remove unreachable code from force_fcr31_sig().") from the mips tree and commit: ea1b75cf9138 ("signal/mips: Document a conflict with SI_USER

linux-next: manual merge of the userns tree with the mips tree

Hi Eric, Today's linux-next merge of the userns tree got a conflict in: arch/mips/kernel/traps.c between commit: 260a789828aa ("MIPS: signal: Remove unreachable code from force_fcr31_sig().") from the mips tree and commit: ea1b75cf9138 ("signal/mips: Document a conflict with SI_USER

[PATCH v2] scheduler: enhancement to show_state_filter

Sometimes we want to get tasks in TASK_RUNNING sepcifically, instead of dump all tasks. For example, when the loadavg are high, we want to dump tasks in TASK_RUNNING and TASK_UNINTERRUPTIBLE, which contribute to system load. But mostly there're lots of tasks in Sleep state, which occupies almost

[PATCH v2] scheduler: enhancement to show_state_filter

Sometimes we want to get tasks in TASK_RUNNING sepcifically, instead of dump all tasks. For example, when the loadavg are high, we want to dump tasks in TASK_RUNNING and TASK_UNINTERRUPTIBLE, which contribute to system load. But mostly there're lots of tasks in Sleep state, which occupies almost

[PATCH] spi/bcm63xx-hspi: fix error return code in bcm63xx_hsspi_probe()

platform_get_irq() returns an error code, but the spi-bcm63xx-hsspi driver ignores it and always returns -ENXIO. This is not correct and, prevents -EPROBE_DEFER from being propagated properly. Notice that platform_get_irq() no longer returns 0 on error:

[PATCH] spi/bcm63xx-hspi: fix error return code in bcm63xx_hsspi_probe()

platform_get_irq() returns an error code, but the spi-bcm63xx-hsspi driver ignores it and always returns -ENXIO. This is not correct and, prevents -EPROBE_DEFER from being propagated properly. Notice that platform_get_irq() no longer returns 0 on error:

[PATCH] spi/bcm63xx: fix error return code in bcm63xx_spi_probe()

platform_get_irq() returns an error code, but the spi-bcm63xx driver ignores it and always returns -ENXIO. This is not correct and, prevents -EPROBE_DEFER from being propagated properly. Notice that platform_get_irq() no longer returns 0 on error:

[PATCH] spi/bcm63xx: fix error return code in bcm63xx_spi_probe()

platform_get_irq() returns an error code, but the spi-bcm63xx driver ignores it and always returns -ENXIO. This is not correct and, prevents -EPROBE_DEFER from being propagated properly. Notice that platform_get_irq() no longer returns 0 on error:

Re: [MD] Crash with 4.12+ kernel and high disk load -- bisected to 4ad23a976413: MD: use per-cpu counter for writes_pending

On Mon, Aug 07, 2017 at 01:20:25PM +0200, Dominik Brodowski wrote: > Neil, Shaohua, > > following up on David R's bug message: I have observed something similar > on v4.12.[345] and v4.13-rc4, but not on v4.11. This is a RAID1 (on bare > metal partitions, /dev/sdaX and /dev/sdbY linked together).

Re: [MD] Crash with 4.12+ kernel and high disk load -- bisected to 4ad23a976413: MD: use per-cpu counter for writes_pending

On Mon, Aug 07, 2017 at 01:20:25PM +0200, Dominik Brodowski wrote: > Neil, Shaohua, > > following up on David R's bug message: I have observed something similar > on v4.12.[345] and v4.13-rc4, but not on v4.11. This is a RAID1 (on bare > metal partitions, /dev/sdaX and /dev/sdbY linked together).

Re: linux-next: Signed-off-by missing for commit in the scsi-mkp tree

On Tue, 8 Aug 2017, Stephen Rothwell wrote: > Hi Martin, > > Commit > > facfc963ae92 ("scsi: g_NCR5380: Two DTC436 PDMA workarounds") > > is missing a Signed-off-by from its author. > Sorry about that. The patch was a joint effort. Ondrej, would you please send your "Signed-off-by" tag so

Re: linux-next: Signed-off-by missing for commit in the scsi-mkp tree

On Tue, 8 Aug 2017, Stephen Rothwell wrote: > Hi Martin, > > Commit > > facfc963ae92 ("scsi: g_NCR5380: Two DTC436 PDMA workarounds") > > is missing a Signed-off-by from its author. > Sorry about that. The patch was a joint effort. Ondrej, would you please send your "Signed-off-by" tag so

[PATCH] usb: dwc3: omap: fix error return code in dwc3_omap_probe()

platform_get_irq() returns an error code, but the dwc3-omap driver ignores it and always returns -EINVAL. This is not correct and, prevents -EPROBE_DEFER from being propagated properly. Notice that platform_get_irq() no longer returns 0 on error:

[PATCH] usb: dwc3: omap: fix error return code in dwc3_omap_probe()

platform_get_irq() returns an error code, but the dwc3-omap driver ignores it and always returns -EINVAL. This is not correct and, prevents -EPROBE_DEFER from being propagated properly. Notice that platform_get_irq() no longer returns 0 on error:

Re: [PATCH 0/6] In-kernel QMI handling

On Mon 07 Aug 12:19 PDT 2017, Marcel Holtmann wrote: > Hi Bjorn, > > >>> This series starts by moving the common definitions of the QMUX > >>> protocol to the > >>> uapi header, as they are shared with clients - both in kernel and > >>> userspace. > >>> > >>> This series then introduces

[PATCH] spi: xlp: fix error return code in xlp_spi_probe()

platform_get_irq() returns an error code, but the spi-xlp driver ignores it and always returns -EINVAL. This is not correct and, prevents -EPROBE_DEFER from being propagated properly. Notice that platform_get_irq() no longer returns 0 on error:

Re: [PATCH 0/6] In-kernel QMI handling

On Mon 07 Aug 12:19 PDT 2017, Marcel Holtmann wrote: > Hi Bjorn, > > >>> This series starts by moving the common definitions of the QMUX > >>> protocol to the > >>> uapi header, as they are shared with clients - both in kernel and > >>> userspace. > >>> > >>> This series then introduces

[PATCH] spi: xlp: fix error return code in xlp_spi_probe()

platform_get_irq() returns an error code, but the spi-xlp driver ignores it and always returns -EINVAL. This is not correct and, prevents -EPROBE_DEFER from being propagated properly. Notice that platform_get_irq() no longer returns 0 on error:

[PATCH 1/2] 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 0/2] 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 1/2] 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 0/2] 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 2/2] PCI: iproc: Add optional brcm,pci-hotplug

Add description for optional device tree property 'brcm,pci-hotplug' 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 2/2] PCI: iproc: Add optional brcm,pci-hotplug

Add description for optional device tree property 'brcm,pci-hotplug' 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

Re: [PATCH] arm64: correct modules range of kernel virtual memory layout

On Mon, 2017-08-07 at 15:01 +0100, Will Deacon wrote: > On Mon, Aug 07, 2017 at 02:18:00PM +0100, Ard Biesheuvel wrote: > > On 7 August 2017 at 14:16, Will Deacon wrote: > > > On Mon, Aug 07, 2017 at 07:04:46PM +0800, Miles Chen wrote: > > >> The commit f80fb3a3d508 ("arm64:

Re: [PATCH] arm64: correct modules range of kernel virtual memory layout

On Mon, 2017-08-07 at 15:01 +0100, Will Deacon wrote: > On Mon, Aug 07, 2017 at 02:18:00PM +0100, Ard Biesheuvel wrote: > > On 7 August 2017 at 14:16, Will Deacon wrote: > > > On Mon, Aug 07, 2017 at 07:04:46PM +0800, Miles Chen wrote: > > >> The commit f80fb3a3d508 ("arm64: add support for

[PATCH v2] perf/core: Avoid context switch overheads

From: "leilei.lin" A performance issue caused by less strickly check in task sched when these tasks were once attached by per-task perf_event. A task will alloc task->perf_event_ctxp[ctxn] when it was called by perf_event_open, and task->perf_event_ctxp[ctxn] would

[PATCH v2] perf/core: Avoid context switch overheads

From: "leilei.lin" A performance issue caused by less strickly check in task sched when these tasks were once attached by per-task perf_event. A task will alloc task->perf_event_ctxp[ctxn] when it was called by perf_event_open, and task->perf_event_ctxp[ctxn] would not ever be freed to NULL.

[PATCH 2/3] autofs - make disc device user accessible

The autofs miscellanous device ioctls that shouldn't require CAP_SYS_ADMIN need to be accessible to user space applications in order to be able to get information about autofs mounts. The module checks capabilities so the miscelaneous device should be fine with broad permissions. Signed-off-by:

[PATCH 2/3] autofs - make disc device user accessible

The autofs miscellanous device ioctls that shouldn't require CAP_SYS_ADMIN need to be accessible to user space applications in order to be able to get information about autofs mounts. The module checks capabilities so the miscelaneous device should be fine with broad permissions. Signed-off-by:

[PATCH 1/3] autofs - fix AT_NO_AUTOMOUNT not being honored

The fstatat(2) and statx() calls can pass the flag AT_NO_AUTOMOUNT which is meant to clear the LOOKUP_AUTOMOUNT flag and prevent triggering of an automount by the call. But this flag is unconditionally cleared for all stat family system calls except statx(). stat family system calls have always

[PATCH 3/3] autofs - make dev ioctl version and ismountpoint user accessible

Some of the autofs miscellaneous device ioctls need to be accessable to user space applications without CAP_SYS_ADMIN to get information about autofs mounts. Signed-off-by: Ian Kent Cc: Colin Walters Cc: Ondrej Holy ---

[PATCH 1/3] autofs - fix AT_NO_AUTOMOUNT not being honored

The fstatat(2) and statx() calls can pass the flag AT_NO_AUTOMOUNT which is meant to clear the LOOKUP_AUTOMOUNT flag and prevent triggering of an automount by the call. But this flag is unconditionally cleared for all stat family system calls except statx(). stat family system calls have always

[PATCH 3/3] autofs - make dev ioctl version and ismountpoint user accessible

Some of the autofs miscellaneous device ioctls need to be accessable to user space applications without CAP_SYS_ADMIN to get information about autofs mounts. Signed-off-by: Ian Kent Cc: Colin Walters Cc: Ondrej Holy --- fs/autofs4/dev-ioctl.c | 12

[PATCH] thermal: rockchip: fix error return code in rockchip_thermal_probe()

platform_get_irq() returns an error code, but the rockchip_thermal driver ignores it and always returns -EINVAL. This is not correct and, prevents -EPROBE_DEFER from being propagated properly. Notice that platform_get_irq() no longer returns 0 on error:

[PATCH] thermal: rockchip: fix error return code in rockchip_thermal_probe()

platform_get_irq() returns an error code, but the rockchip_thermal driver ignores it and always returns -EINVAL. This is not correct and, prevents -EPROBE_DEFER from being propagated properly. Notice that platform_get_irq() no longer returns 0 on error:

Re: [PATCH 3/3] IPI: Avoid to use 2 cache lines for one call_single_data

Peter Zijlstra writes: > On Sat, Aug 05, 2017 at 08:47:02AM +0800, Huang, Ying wrote: >> Yes. That looks good. So you will prepare the final patch? Or you >> hope me to do that? > > I was hoping you'd do it ;-) Thanks! Here is the updated patch Best Regards, Huang,

Re: [PATCH 3/3] IPI: Avoid to use 2 cache lines for one call_single_data

Peter Zijlstra writes: > On Sat, Aug 05, 2017 at 08:47:02AM +0800, Huang, Ying wrote: >> Yes. That looks good. So you will prepare the final patch? Or you >> hope me to do that? > > I was hoping you'd do it ;-) Thanks! Here is the updated patch Best Regards, Huang, Ying

[PATCH v5 1/1] usb:host:xhci support option to disable the xHCI USB2 HW LPM

XHCI specification 1.1 does not require xHCI-compliant controllers to always enable hardware USB2 LPM. However, the current xHCI driver always enable it when seeing HLC=1. This patch supports an option for users to control disabling USB2 Hardware LPM via DT/ACPI attribute. This option is needed in

[PATCH v5 1/1] usb:host:xhci support option to disable the xHCI USB2 HW LPM

XHCI specification 1.1 does not require xHCI-compliant controllers to always enable hardware USB2 LPM. However, the current xHCI driver always enable it when seeing HLC=1. This patch supports an option for users to control disabling USB2 Hardware LPM via DT/ACPI attribute. This option is needed in

Re: [PATCH -mm] mm: Clear to access sub-page last when clearing huge page

Mike Kravetz writes: > On 08/07/2017 12:21 AM, Huang, Ying wrote: >> From: Huang Ying >> >> Huge page helps to reduce TLB miss rate, but it has higher cache >> footprint, sometimes this may cause some issue. For example, when >> clearing huge

Re: [PATCH -mm] mm: Clear to access sub-page last when clearing huge page

Mike Kravetz writes: > On 08/07/2017 12:21 AM, Huang, Ying wrote: >> From: Huang Ying >> >> Huge page helps to reduce TLB miss rate, but it has higher cache >> footprint, sometimes this may cause some issue. For example, when >> clearing huge page on x86_64 platform, the cache footprint is

Re: [lkp-robot] [mm] 7674270022: will-it-scale.per_process_ops -19.3% regression

Minchan Kim wrote: > Hi, > > On Tue, Aug 08, 2017 at 09:19:23AM +0800, kernel test robot wrote: >> Greeting, >> >> FYI, we noticed a -19.3% regression of will-it-scale.per_process_ops due to >> commit: >> >> >> commit: 76742700225cad9df49f05399381ac3f1ec3dc60 ("mm: fix

Re: [lkp-robot] [mm] 7674270022: will-it-scale.per_process_ops -19.3% regression

Minchan Kim wrote: > Hi, > > On Tue, Aug 08, 2017 at 09:19:23AM +0800, kernel test robot wrote: >> Greeting, >> >> FYI, we noticed a -19.3% regression of will-it-scale.per_process_ops due to >> commit: >> >> >> commit: 76742700225cad9df49f05399381ac3f1ec3dc60 ("mm: fix >>

Re: [v5] wlcore: add missing nvs file name info for wilink8

* Reizer, Eyal [170807 00:47]: > Hi Tony, > > > > * Reizer, Eyal [170807 00:32]: > > > The following commits: > > > c815fde wlcore: spi: Populate config firmware data > > > d776fc8 wlcore: sdio: Populate config firmware data > > > > > > Populated the nvs entry for

Re: [v5] wlcore: add missing nvs file name info for wilink8

* Reizer, Eyal [170807 00:47]: > Hi Tony, > > > > * Reizer, Eyal [170807 00:32]: > > > The following commits: > > > c815fde wlcore: spi: Populate config firmware data > > > d776fc8 wlcore: sdio: Populate config firmware data > > > > > > Populated the nvs entry for wilink6 and wilink7 only while

Re: [PATCH] gpio: uniphier: add UniPhier GPIO controller driver

On Tuesday 08 August 2017 06:36 AM, Masahiro Yamada wrote: > Hi Linus, > > 2017-08-08 0:37 GMT+09:00 Linus Walleij : >> On Mon, Aug 7, 2017 at 3:50 PM, Masahiro Yamada >> wrote: >> >>> Adding "interrupts" property in DT causes >>>

Re: [PATCH] gpio: uniphier: add UniPhier GPIO controller driver

On Tuesday 08 August 2017 06:36 AM, Masahiro Yamada wrote: > Hi Linus, > > 2017-08-08 0:37 GMT+09:00 Linus Walleij : >> On Mon, Aug 7, 2017 at 3:50 PM, Masahiro Yamada >> wrote: >> >>> Adding "interrupts" property in DT causes >>> of_pupulate_default_populate() to assign virtual IRQ numbers

Re: [PATCH 13/18] power: supply: bq24190_charger: Export 5V boost converter as regulator

* Hans de Goede [170806 05:37]: > Register the 5V boost converter as a regulator named > "regulator-bq24190-usb-vbus". Note the name includes "bq24190" because > the bq24190 family is also used on ACPI devices where there are no > device-tree phandles, so regulator_get will

Re: [PATCH 13/18] power: supply: bq24190_charger: Export 5V boost converter as regulator

* Hans de Goede [170806 05:37]: > Register the 5V boost converter as a regulator named > "regulator-bq24190-usb-vbus". Note the name includes "bq24190" because > the bq24190 family is also used on ACPI devices where there are no > device-tree phandles, so regulator_get will fallback to the name

[PATCH] usb: imx21-hcd: fix error return code in imx21_probe()

platform_get_irq() returns an error code, but the imx21-hcd driver ignores it and always returns -ENXIO. This is not correct, and prevents -EPROBE_DEFER from being propagated properly. Notice that platform_get_irq() no longer returns 0 on error:

Re: [RESEND PATCH] bcache: Don't reinvent the wheel but use existing llist API

On Mon, Aug 07, 2017 at 06:18:35PM +0800, Coly Li wrote: > On 2017/8/7 下午4:38, Byungchul Park wrote: > > Although llist provides proper APIs, they are not used. Make them used. > > > > Signed-off-by: Byungchul Park Only have a question about why not using

[PATCH] usb: imx21-hcd: fix error return code in imx21_probe()

platform_get_irq() returns an error code, but the imx21-hcd driver ignores it and always returns -ENXIO. This is not correct, and prevents -EPROBE_DEFER from being propagated properly. Notice that platform_get_irq() no longer returns 0 on error:

Re: [RESEND PATCH] bcache: Don't reinvent the wheel but use existing llist API

On Mon, Aug 07, 2017 at 06:18:35PM +0800, Coly Li wrote: > On 2017/8/7 下午4:38, Byungchul Park wrote: > > Although llist provides proper APIs, they are not used. Make them used. > > > > Signed-off-by: Byungchul Park Only have a question about why not using llist_for_each_entry(), it's Hello,

Re: [PATCH 3.18 00/50] 3.18.64-stable review

On 08/07/2017 12:34 PM, Greg Kroah-Hartman wrote: On Sat, Aug 05, 2017 at 12:11:19PM -0700, Guenter Roeck wrote: On 08/05/2017 08:43 AM, Greg Kroah-Hartman wrote: On Sat, Aug 05, 2017 at 08:02:17AM +0200, Willy Tarreau wrote: On Sat, Aug 05, 2017 at 07:55:11AM +0200, Willy Tarreau wrote: On

Re: [PATCH 3.18 00/50] 3.18.64-stable review

On 08/07/2017 12:34 PM, Greg Kroah-Hartman wrote: On Sat, Aug 05, 2017 at 12:11:19PM -0700, Guenter Roeck wrote: On 08/05/2017 08:43 AM, Greg Kroah-Hartman wrote: On Sat, Aug 05, 2017 at 08:02:17AM +0200, Willy Tarreau wrote: On Sat, Aug 05, 2017 at 07:55:11AM +0200, Willy Tarreau wrote: On

[PATCH] f2fs: fix some cases with reserved_blocks

Signed-off-by: Yunlong Song --- fs/f2fs/recovery.c | 3 ++- fs/f2fs/super.c| 9 + 2 files changed, 7 insertions(+), 5 deletions(-) diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c index a3d0261..e288319 100644 --- a/fs/f2fs/recovery.c +++

[PATCH] f2fs: fix some cases with reserved_blocks

Signed-off-by: Yunlong Song --- fs/f2fs/recovery.c | 3 ++- fs/f2fs/super.c| 9 + 2 files changed, 7 insertions(+), 5 deletions(-) diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c index a3d0261..e288319 100644 --- a/fs/f2fs/recovery.c +++ b/fs/f2fs/recovery.c @@ -51,7 +51,8 @@

Re: Possible race in pc87413_wdt.ko

On 08/07/2017 06:22 AM, Anton Volkov wrote: Hello. While searching for races in the Linux kernel I've come across "drivers/watchdog/pc87413_wdt.ko" module. Here is a question that I came up with while analyzing results. Lines are given using the info from Linux v4.12. Consider the following

Re: Possible race in pc87413_wdt.ko

On 08/07/2017 06:22 AM, Anton Volkov wrote: Hello. While searching for races in the Linux kernel I've come across "drivers/watchdog/pc87413_wdt.ko" module. Here is a question that I came up with while analyzing results. Lines are given using the info from Linux v4.12. Consider the following

Re: [PATCH -mm] mm: Clear to access sub-page last when clearing huge page

On 08/07/2017 12:21 AM, Huang, Ying wrote: > From: Huang Ying > > Huge page helps to reduce TLB miss rate, but it has higher cache > footprint, sometimes this may cause some issue. For example, when > clearing huge page on x86_64 platform, the cache footprint is 2M. But >

Re: [PATCH -mm] mm: Clear to access sub-page last when clearing huge page

On 08/07/2017 12:21 AM, Huang, Ying wrote: > From: Huang Ying > > Huge page helps to reduce TLB miss rate, but it has higher cache > footprint, sometimes this may cause some issue. For example, when > clearing huge page on x86_64 platform, the cache footprint is 2M. But > on a Xeon E5 v3 2699

[PATCH v2 3/4] KVM: s390: implements the kvm_arch_vcpu_in_kernel()

This implements the kvm_arch_vcpu_in_kernel() for s390. Signed-off-by: Longpeng(Mike) --- arch/s390/kvm/kvm-s390.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c index 0b0c689..e46177b 100644 ---

[PATCH v2 2/4] KVM: X86: implement the logic for spinlock optimization

1. Implements the kvm_arch_vcpu_in_kernel(), because get_cpl requires vcpu_load, so we must cache the result(whether the vcpu was preempted when its cpl=0) in kvm_vcpu_arch. 2. Add ->spin_in_kernel hook, because we can get benefit from VMX. Signed-off-by: Longpeng(Mike)

[PATCH v2 3/4] KVM: s390: implements the kvm_arch_vcpu_in_kernel()

This implements the kvm_arch_vcpu_in_kernel() for s390. Signed-off-by: Longpeng(Mike) --- arch/s390/kvm/kvm-s390.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c index 0b0c689..e46177b 100644 --- a/arch/s390/kvm/kvm-s390.c

[PATCH v2 2/4] KVM: X86: implement the logic for spinlock optimization

1. Implements the kvm_arch_vcpu_in_kernel(), because get_cpl requires vcpu_load, so we must cache the result(whether the vcpu was preempted when its cpl=0) in kvm_vcpu_arch. 2. Add ->spin_in_kernel hook, because we can get benefit from VMX. Signed-off-by: Longpeng(Mike) ---

  1   2   3   4   5   6   7   8   9   10   >