Re: [PATCH 2/2] ocfs2: fix deadlocks when taking inode lock at vfs entry points

On 01/16/2017 11:06 AM, Eric Ren wrote: > Hi Junxiao, > > On 01/16/2017 10:46 AM, Junxiao Bi wrote: If had_lock==true, it is a bug? I think we should BUG_ON for it, that can help us catch bug at the first time. >>> Good idea! But I'm not sure if "ocfs2_setattr" is always the first one

Re: [PATCH 2/2] ocfs2: fix deadlocks when taking inode lock at vfs entry points

On 01/16/2017 11:06 AM, Eric Ren wrote: > Hi Junxiao, > > On 01/16/2017 10:46 AM, Junxiao Bi wrote: If had_lock==true, it is a bug? I think we should BUG_ON for it, that can help us catch bug at the first time. >>> Good idea! But I'm not sure if "ocfs2_setattr" is always the first one

RE: eMMC boot problem: switch to bus width 8 ddr failed

> -Original Message- > From: Ulf Hansson [mailto:ulf.hans...@linaro.org] > Sent: Friday, January 13, 2017 7:23 PM > To: Bough Chen > Cc: Shawn Lin ; Clemens Gruber > ; linux-...@vger.kernel.org; Linus Walleij >

RE: eMMC boot problem: switch to bus width 8 ddr failed

> -Original Message- > From: Ulf Hansson [mailto:ulf.hans...@linaro.org] > Sent: Friday, January 13, 2017 7:23 PM > To: Bough Chen > Cc: Shawn Lin ; Clemens Gruber > ; linux-...@vger.kernel.org; Linus Walleij > ; Adrian Hunter ; A.S. > Dong ; linux-kernel@vger.kernel.org; Gary Bisson > ;

RE: [PATCH] hv: use substraction to update ring buffer index

> From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On > Behalf Of Long Li > Sent: Thursday, January 5, 2017 12:08 > To: KY Srinivasan ; Haiyang Zhang > > Cc: de...@linuxdriverproject.org; linux-kernel@vger.kernel.org > Subject:

RE: [PATCH] hv: use substraction to update ring buffer index

> From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On > Behalf Of Long Li > Sent: Thursday, January 5, 2017 12:08 > To: KY Srinivasan ; Haiyang Zhang > > Cc: de...@linuxdriverproject.org; linux-kernel@vger.kernel.org > Subject: [PATCH] hv: use substraction to update ring buffer

Re: [PATCH 2/2] ocfs2: fix deadlocks when taking inode lock at vfs entry points

Hi Junxiao, On 01/16/2017 10:46 AM, Junxiao Bi wrote: If had_lock==true, it is a bug? I think we should BUG_ON for it, that can help us catch bug at the first time. Good idea! But I'm not sure if "ocfs2_setattr" is always the first one who takes the cluster lock. It's harder for me to name all

Re: [PATCH 2/2] ocfs2: fix deadlocks when taking inode lock at vfs entry points

Hi Junxiao, On 01/16/2017 10:46 AM, Junxiao Bi wrote: If had_lock==true, it is a bug? I think we should BUG_ON for it, that can help us catch bug at the first time. Good idea! But I'm not sure if "ocfs2_setattr" is always the first one who takes the cluster lock. It's harder for me to name all

Re: [PATCH] checkpatch: update $logFunctions

On Fri, 2017-01-13 at 00:14 -0800, Joe Perches wrote: > On Fri, 2017-01-13 at 15:38 +0800, miles.c...@mediatek.com wrote: > > From: Miles Chen > > > > Currently checkpatch.pl does not recognize printk_deferred* functions as > > log functions and complains about the line

Re: [PATCH] checkpatch: update $logFunctions

On Fri, 2017-01-13 at 00:14 -0800, Joe Perches wrote: > On Fri, 2017-01-13 at 15:38 +0800, miles.c...@mediatek.com wrote: > > From: Miles Chen > > > > Currently checkpatch.pl does not recognize printk_deferred* functions as > > log functions and complains about the line length of

Re: [PATCH DEBUG] x86, pat/mtrr: MTRR/PAT init earlier for each APs

Hi experts, do you have any clue on this? thanks. On Tue, Dec 20, 2016 at 06:21:28PM +0800, Chen Yu wrote: > This is a debug patch to descibe/workaround the issue > we encountered recently. > > Problem and the cause: > Currently we are suffering from *extremely* slow CPU online > speed during

Re: [PATCH DEBUG] x86, pat/mtrr: MTRR/PAT init earlier for each APs

Hi experts, do you have any clue on this? thanks. On Tue, Dec 20, 2016 at 06:21:28PM +0800, Chen Yu wrote: > This is a debug patch to descibe/workaround the issue > we encountered recently. > > Problem and the cause: > Currently we are suffering from *extremely* slow CPU online > speed during

Re: [PATCH 2/4] efi/x86: move efi bgrt init code to early init code

On 01/13/17 at 01:21pm, Nicolai Stange wrote: > On Fri, Jan 13 2017, Dave Young wrote: > > > On 01/13/17 at 10:21am, Dave Young wrote: > >> On 01/13/17 at 12:11am, Nicolai Stange wrote: > >> > On Fri, Jan 13 2017, Dave Young wrote: > >> > > >> > > On 01/12/17 at 12:54pm, Nicolai Stange wrote: >

Re: [PATCH 2/4] efi/x86: move efi bgrt init code to early init code

On 01/13/17 at 01:21pm, Nicolai Stange wrote: > On Fri, Jan 13 2017, Dave Young wrote: > > > On 01/13/17 at 10:21am, Dave Young wrote: > >> On 01/13/17 at 12:11am, Nicolai Stange wrote: > >> > On Fri, Jan 13 2017, Dave Young wrote: > >> > > >> > > On 01/12/17 at 12:54pm, Nicolai Stange wrote: >

Re: [PATCH v2 2/6] arm: dts: mt2701: Add iommu/smi device node

On Fri, 2017-01-13 at 16:05 +0100, Matthias Brugger wrote: > Hi Erin, > > I just took the patch from Honghui he send in june. > Please see my comment inline. > > On 13/01/17 09:42, Erin Lo wrote: > > From: Honghui Zhang > > > > Add the device node of iommu and smi

Re: [PATCH v2 2/6] arm: dts: mt2701: Add iommu/smi device node

On Fri, 2017-01-13 at 16:05 +0100, Matthias Brugger wrote: > Hi Erin, > > I just took the patch from Honghui he send in june. > Please see my comment inline. > > On 13/01/17 09:42, Erin Lo wrote: > > From: Honghui Zhang > > > > Add the device node of iommu and smi for MT2701. > > > >

[PATCH V2 4/4] efi/x86: make efi_memmap_reserve only insert into boot mem areas

efi_mem_reserve cares only about boot services regions, for making sure later efi_free_boot_services does not free areas which are still useful, such as bgrt image buffer. So add a new argument to efi_memmap_insert for this purpose. Signed-off-by: Dave Young --- v1->v2:

[PATCH V2 4/4] efi/x86: make efi_memmap_reserve only insert into boot mem areas

efi_mem_reserve cares only about boot services regions, for making sure later efi_free_boot_services does not free areas which are still useful, such as bgrt image buffer. So add a new argument to efi_memmap_insert for this purpose. Signed-off-by: Dave Young --- v1->v2: only check

[PATCH V2 3/4] efi/x86: add debug code to print cooked memmap

It is not obvious if the reserved boot area are added correctly, add a efi_print_memmap to print the new memmap. Signed-off-by: Dave Young Acked-by: Ard Biesheuvel --- arch/x86/platform/efi/efi.c |5 + 1 file changed, 5 insertions(+) ---

[PATCH V2 0/4] efi/x86: move efi bgrt init code to early init

Hi, Here the the update of the series for moving bgrt init code to early init. Main changes is: - Move the 1st patch to the last because it does not block the 2nd patch any more with Peter's patch to prune invlid memmap entries:

[PATCH V2 3/4] efi/x86: add debug code to print cooked memmap

It is not obvious if the reserved boot area are added correctly, add a efi_print_memmap to print the new memmap. Signed-off-by: Dave Young Acked-by: Ard Biesheuvel --- arch/x86/platform/efi/efi.c |5 + 1 file changed, 5 insertions(+) --- linux-x86.orig/arch/x86/platform/efi/efi.c +++

[PATCH V2 0/4] efi/x86: move efi bgrt init code to early init

Hi, Here the the update of the series for moving bgrt init code to early init. Main changes is: - Move the 1st patch to the last because it does not block the 2nd patch any more with Peter's patch to prune invlid memmap entries:

[PATCH V2 2/4] efi/x86: move efi_print_memmap to drivers/firmware/efi/memmap.c

Signed-off-by: Dave Young --- v1->v2: move efi_print_memmap declaration to general header file arch/x86/include/asm/efi.h|1 - arch/x86/platform/efi/efi.c | 16 drivers/firmware/efi/memmap.c | 16 include/linux/efi.h |

[PATCH V2 1/4] efi/x86: move efi bgrt init code to early init code

Before invoking the arch specific handler, efi_mem_reserve() reserves the given memory region through memblock. efi_bgrt_init will call efi_mem_reserve after mm_init(), at that time memblock is dead and it should not be used any more. efi bgrt code depend on acpi intialization to get the bgrt

[PATCH V2 2/4] efi/x86: move efi_print_memmap to drivers/firmware/efi/memmap.c

Signed-off-by: Dave Young --- v1->v2: move efi_print_memmap declaration to general header file arch/x86/include/asm/efi.h|1 - arch/x86/platform/efi/efi.c | 16 drivers/firmware/efi/memmap.c | 16 include/linux/efi.h |1 + 4 files

[PATCH V2 1/4] efi/x86: move efi bgrt init code to early init code

Before invoking the arch specific handler, efi_mem_reserve() reserves the given memory region through memblock. efi_bgrt_init will call efi_mem_reserve after mm_init(), at that time memblock is dead and it should not be used any more. efi bgrt code depend on acpi intialization to get the bgrt

Re: [PATCH v4 5/5] ARM: dts: mt2701: add iommu/smi dtsi node for mt2701

On Fri, 2017-01-13 at 15:54 +0100, Matthias Brugger wrote: > > On 04/07/16 10:00, Matthias Brugger wrote: > > > > > > On 04/07/16 03:32, Honghui Zhang wrote: > >> On Sun, 2016-07-03 at 21:12 +0200, Matthias Brugger wrote: > >>> > >>> On 07/03/2016 08:24 AM, Matthias Brugger wrote: > > >

Re: [PATCH v4 5/5] ARM: dts: mt2701: add iommu/smi dtsi node for mt2701

On Fri, 2017-01-13 at 15:54 +0100, Matthias Brugger wrote: > > On 04/07/16 10:00, Matthias Brugger wrote: > > > > > > On 04/07/16 03:32, Honghui Zhang wrote: > >> On Sun, 2016-07-03 at 21:12 +0200, Matthias Brugger wrote: > >>> > >>> On 07/03/2016 08:24 AM, Matthias Brugger wrote: > > >

Re: [PATCH 2/2] ocfs2: fix deadlocks when taking inode lock at vfs entry points

On 01/13/2017 02:19 PM, Eric Ren wrote: > Hi! > > On 01/13/2017 12:22 PM, Junxiao Bi wrote: >> On 01/05/2017 11:31 PM, Eric Ren wrote: >>> Commit 743b5f1434f5 ("ocfs2: take inode lock in >>> ocfs2_iop_set/get_acl()") >>> results in a deadlock, as the author "Tariq Saeed" realized shortly >>>

Re: [PATCH 2/2] ocfs2: fix deadlocks when taking inode lock at vfs entry points

On 01/13/2017 02:19 PM, Eric Ren wrote: > Hi! > > On 01/13/2017 12:22 PM, Junxiao Bi wrote: >> On 01/05/2017 11:31 PM, Eric Ren wrote: >>> Commit 743b5f1434f5 ("ocfs2: take inode lock in >>> ocfs2_iop_set/get_acl()") >>> results in a deadlock, as the author "Tariq Saeed" realized shortly >>>

Re: [PATCH 1/2] ocfs2/dlmglue: prepare tracking logic to avoid recursive cluster lock

On 01/13/2017 02:12 PM, Eric Ren wrote: > Hi Junxiao! > > On 01/13/2017 11:59 AM, Junxiao Bi wrote: >> On 01/05/2017 11:31 PM, Eric Ren wrote: >>> We are in the situation that we have to avoid recursive cluster locking, >>> but there is no way to check if a cluster lock has been taken by a >>>

Re: [PATCH 1/2] ocfs2/dlmglue: prepare tracking logic to avoid recursive cluster lock

On 01/13/2017 02:12 PM, Eric Ren wrote: > Hi Junxiao! > > On 01/13/2017 11:59 AM, Junxiao Bi wrote: >> On 01/05/2017 11:31 PM, Eric Ren wrote: >>> We are in the situation that we have to avoid recursive cluster locking, >>> but there is no way to check if a cluster lock has been taken by a >>>

Re: [PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip

On 2017/1/16 5:41, Matt Ranostay wrote: On Thu, Jan 12, 2017 at 11:16 PM, Shawn Lin wrote: On 2017/1/13 13:29, Matt Ranostay wrote: Allow power sequencing for the Marvell SD8787 Wifi/BT chip. This can be abstracted to other chipsets if needed in the future. Cc:

Re: [PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip

On 2017/1/16 5:41, Matt Ranostay wrote: On Thu, Jan 12, 2017 at 11:16 PM, Shawn Lin wrote: On 2017/1/13 13:29, Matt Ranostay wrote: Allow power sequencing for the Marvell SD8787 Wifi/BT chip. This can be abstracted to other chipsets if needed in the future. Cc: Tony Lindgren Cc: Ulf

Re: [RFC PATCH 2/3] mmc: sdhci-msm: Implement platform_dumpregs callback in sdhci-msm

Hi Jeremy, On 1/14/2017 4:01 AM, Jeremy McNicoll wrote: On Fri, Dec 30, 2016 at 05:02:10PM +0530, Ritesh Harjani wrote: From: Sahitya Tummala Implement ->platform_dumpregs host operation to print the platform specific registers in addition to standard SDHC register

Re: [RFC PATCH 2/3] mmc: sdhci-msm: Implement platform_dumpregs callback in sdhci-msm

Hi Jeremy, On 1/14/2017 4:01 AM, Jeremy McNicoll wrote: On Fri, Dec 30, 2016 at 05:02:10PM +0530, Ritesh Harjani wrote: From: Sahitya Tummala Implement ->platform_dumpregs host operation to print the platform specific registers in addition to standard SDHC register during error conditions.

Re: [RFC PATCH 1/3] mmc: sdhci: Add platform_dumpregs callback support to sdhci_ops.

Hi Jeremy, Thanks for the review. On 1/14/2017 3:51 AM, Jeremy McNicoll wrote: On Fri, Dec 30, 2016 at 05:02:09PM +0530, Ritesh Harjani wrote: From: Sahitya Tummala Add new host operation ->platform_dumpregs to provide a mechanism through which host drivers can dump

Re: [RFC PATCH 1/3] mmc: sdhci: Add platform_dumpregs callback support to sdhci_ops.

Hi Jeremy, Thanks for the review. On 1/14/2017 3:51 AM, Jeremy McNicoll wrote: On Fri, Dec 30, 2016 at 05:02:09PM +0530, Ritesh Harjani wrote: From: Sahitya Tummala Add new host operation ->platform_dumpregs to provide a mechanism through which host drivers can dump platform specific

[v2 1/3] usb: dwc2: Add support for STM32F429/439/469 USB OTG HS/FS in FS mode (internal PHY)

This patch introduces a new parameter to activate USB OTG HS/FS core embedded phy transciver. The STM32F4x9 SoC uses the GGPIO register to enable the transciver. Signed-off-by: Bruno Herrera --- drivers/usb/dwc2/core.h | 4 drivers/usb/dwc2/hcd.c| 21

[v2 2/3] ARM: dts: STM32 Add USB FS host mode support

This patch adds the USB pins and nodes for USB HS/FS cores working at FS speed, using embedded PHY. Signed-off-by: Bruno Herrera --- arch/arm/boot/dts/stm32f429-disco.dts | 30 ++ arch/arm/boot/dts/stm32f429.dtsi | 35

[v2 1/3] usb: dwc2: Add support for STM32F429/439/469 USB OTG HS/FS in FS mode (internal PHY)

This patch introduces a new parameter to activate USB OTG HS/FS core embedded phy transciver. The STM32F4x9 SoC uses the GGPIO register to enable the transciver. Signed-off-by: Bruno Herrera --- drivers/usb/dwc2/core.h | 4 drivers/usb/dwc2/hcd.c| 21 ++-

[v2 2/3] ARM: dts: STM32 Add USB FS host mode support

This patch adds the USB pins and nodes for USB HS/FS cores working at FS speed, using embedded PHY. Signed-off-by: Bruno Herrera --- arch/arm/boot/dts/stm32f429-disco.dts | 30 ++ arch/arm/boot/dts/stm32f429.dtsi | 35 ++-

[v2 3/3] dt-bindings: Document the STM32 USB OTG DWC2 core binding

This patch adds the documentation for STM32F4x9 USB OTG FS/HS compatible strings. Signed-off-by: Bruno Herrera --- Documentation/devicetree/bindings/usb/dwc2.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt

[v2 3/3] dt-bindings: Document the STM32 USB OTG DWC2 core binding

This patch adds the documentation for STM32F4x9 USB OTG FS/HS compatible strings. Signed-off-by: Bruno Herrera --- Documentation/devicetree/bindings/usb/dwc2.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt

Re: Fixing tools using UAPI headers?

On Sat, 2017-01-14 at 16:16 +, Jonathan Cameron wrote: > On 14/01/17 00:24, Laura Abbott wrote: > > Hi, > > > > I submitted https://marc.info/?l=linux-kernel=147343473231192=2 > > a while ago and it was suggested postponing any discussion until > > after ksummit > >

Re: Fixing tools using UAPI headers?

On Sat, 2017-01-14 at 16:16 +, Jonathan Cameron wrote: > On 14/01/17 00:24, Laura Abbott wrote: > > Hi, > > > > I submitted https://marc.info/?l=linux-kernel=147343473231192=2 > > a while ago and it was suggested postponing any discussion until > > after ksummit > >

[lkp-developer] [perf/core] 49c04ee1a7: WARNING:at_kernel/events/core.c:#perf_iterate_ctx_matching

FYI, we noticed the following commit: commit: 49c04ee1a704ad7fe785474d9d17a4341dcb50a3 ("perf/core: use rb-tree index to optimize filtered perf_iterate_ctx") url: https://github.com/0day-ci/linux/commits/David-Carrillo-Cisneros/optimize-ctx-switch-with-rb-tree/20170110-203936 in testcase:

[lkp-developer] [perf/core] 49c04ee1a7: WARNING:at_kernel/events/core.c:#perf_iterate_ctx_matching

FYI, we noticed the following commit: commit: 49c04ee1a704ad7fe785474d9d17a4341dcb50a3 ("perf/core: use rb-tree index to optimize filtered perf_iterate_ctx") url: https://github.com/0day-ci/linux/commits/David-Carrillo-Cisneros/optimize-ctx-switch-with-rb-tree/20170110-203936 in testcase:

[lkp-developer] [perf/core] 33da94bd89: BUG:unable_to_handle_kernel

FYI, we noticed the following commit: commit: 33da94bd89b485777e253cf48ebc4638cf844022 ("perf/core: add a rb-tree index to inactive_groups") url: https://github.com/0day-ci/linux/commits/David-Carrillo-Cisneros/optimize-ctx-switch-with-rb-tree/20170110-203936 in testcase: boot on test

[lkp-developer] [perf/core] 33da94bd89: BUG:unable_to_handle_kernel

FYI, we noticed the following commit: commit: 33da94bd89b485777e253cf48ebc4638cf844022 ("perf/core: add a rb-tree index to inactive_groups") url: https://github.com/0day-ci/linux/commits/David-Carrillo-Cisneros/optimize-ctx-switch-with-rb-tree/20170110-203936 in testcase: boot on test

[lkp-developer] [perf] 3fe1a9f7f2: BUG:unable_to_handle_kernel

FYI, we noticed the following commit: commit: 3fe1a9f7f214a59c6cb2eba04847ef6d4c326be0 ("perf: Container-aware tracing support") url: https://github.com/0day-ci/linux/commits/Aravinda-Prasad/perf-Container-aware-tracing-support/20170113-095325 in testcase: trinity with following parameters:

[lkp-developer] [perf] 3fe1a9f7f2: BUG:unable_to_handle_kernel

FYI, we noticed the following commit: commit: 3fe1a9f7f214a59c6cb2eba04847ef6d4c326be0 ("perf: Container-aware tracing support") url: https://github.com/0day-ci/linux/commits/Aravinda-Prasad/perf-Container-aware-tracing-support/20170113-095325 in testcase: trinity with following parameters:

RE: [PATCH] rcu: Narrow early boot window of illegal synchronous grace periods

Hi, > From: Borislav Petkov [mailto:b...@alien8.de] > Subject: Re: [PATCH] rcu: Narrow early boot window of illegal synchronous > grace periods > > On Sat, Jan 14, 2017 at 01:27:40PM +0100, Rafael J. Wysocki wrote: > > OK, so this fixes the problem with synchronize_rcu_expedited() in > >

RE: [PATCH] rcu: Narrow early boot window of illegal synchronous grace periods

Hi, > From: Borislav Petkov [mailto:b...@alien8.de] > Subject: Re: [PATCH] rcu: Narrow early boot window of illegal synchronous > grace periods > > On Sat, Jan 14, 2017 at 01:27:40PM +0100, Rafael J. Wysocki wrote: > > OK, so this fixes the problem with synchronize_rcu_expedited() in > >

Re: Duplicate inode number when mount --bind some directories to same mountpoint. (from Fedora18 to 4.10-rc3)

> 120 116 252:1 /home/b /mnt rw,relatime shared:1 - ext4 /dev/vda1 rw,data=ordered > 121 61 252:1 /home/b /home/a rw,relatime shared:1 - ext4 /dev/vda1 rw,data=ordered Thanks for your polite explanation. I can understand this is correct kernel specification and above Fedora18 and RHEL7.0 is

Re: Duplicate inode number when mount --bind some directories to same mountpoint. (from Fedora18 to 4.10-rc3)

> 120 116 252:1 /home/b /mnt rw,relatime shared:1 - ext4 /dev/vda1 rw,data=ordered > 121 61 252:1 /home/b /home/a rw,relatime shared:1 - ext4 /dev/vda1 rw,data=ordered Thanks for your polite explanation. I can understand this is correct kernel specification and above Fedora18 and RHEL7.0 is

Re: [PATCH 1/2] sched: Introduce rcuwait machinery

On Thu, 22 Dec 2016, Bueso wrote: + WARN_ON(current->exit_state); \ While not related to this patch, but per 3245d6acab9 (exit: fix race between wait_consider_task() and wait_task_zombie()), should we not *_ONCE() all things ->exit_state? I'm not really

Re: [PATCH 1/2] sched: Introduce rcuwait machinery

On Thu, 22 Dec 2016, Bueso wrote: + WARN_ON(current->exit_state); \ While not related to this patch, but per 3245d6acab9 (exit: fix race between wait_consider_task() and wait_task_zombie()), should we not *_ONCE() all things ->exit_state? I'm not really

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

Hello, Sorry about the delay. Some fire fighthing followed the holidays. On Tue, Jan 03, 2017 at 11:25:59AM +0100, Michal Hocko wrote: > > So from what I understand the proposed cgroup is not in fact > > hierarchical at all. > > > > @TJ, I thought you were enforcing all new cgroups to be

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

Hello, Sorry about the delay. Some fire fighthing followed the holidays. On Tue, Jan 03, 2017 at 11:25:59AM +0100, Michal Hocko wrote: > > So from what I understand the proposed cgroup is not in fact > > hierarchical at all. > > > > @TJ, I thought you were enforcing all new cgroups to be

Re: [PATCH 3/3] cpuidle/menu: add per cpu pm_qos_resume_latency consideration

Thanks a lot, Rik! Anyone like to give more comments or pick it up? Regards Alex On 01/13/2017 04:03 AM, Rik van Riel wrote: > Acked-by: Rik van Riel

Re: [PATCH 3/3] cpuidle/menu: add per cpu pm_qos_resume_latency consideration

Thanks a lot, Rik! Anyone like to give more comments or pick it up? Regards Alex On 01/13/2017 04:03 AM, Rik van Riel wrote: > Acked-by: Rik van Riel

Re: [PATCH v11 02/12] drm/mediatek: add helpers for coverting from the generic components

On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote: > define helpers for converting from 'mtk_ddp_comp' to 'mtk_disp_ovl' > define helpers for converting from 'mtk_ddp_comp' to 'mtk_disp_rdma' > > Signed-off-by: YT Shen Acked-by CK Hu > --- >

Re: [PATCH v11 02/12] drm/mediatek: add helpers for coverting from the generic components

On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote: > define helpers for converting from 'mtk_ddp_comp' to 'mtk_disp_ovl' > define helpers for converting from 'mtk_ddp_comp' to 'mtk_disp_rdma' > > Signed-off-by: YT Shen Acked-by CK Hu > --- > drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 15

Re: [PATCH v2 3/3] Input: pwm-beeper: add optional amplifier regulator

On 01/15/2017 06:34 PM, Dmitry Torokhov wrote: On Sun, Jan 15, 2017 at 06:12:29PM -0600, David Lechner wrote: On 01/14/2017 01:19 PM, Dmitry Torokhov wrote: On Wed, Jan 11, 2017 at 02:02:01PM -0600, David Lechner wrote: This adds an optional regulator to the pwm-beeper device. This regulator

Re: [PATCH v2 3/3] Input: pwm-beeper: add optional amplifier regulator

On 01/15/2017 06:34 PM, Dmitry Torokhov wrote: On Sun, Jan 15, 2017 at 06:12:29PM -0600, David Lechner wrote: On 01/14/2017 01:19 PM, Dmitry Torokhov wrote: On Wed, Jan 11, 2017 at 02:02:01PM -0600, David Lechner wrote: This adds an optional regulator to the pwm-beeper device. This regulator

Re: [PATCH v2 2/3] mwifiex: pcie: don't loop/retry interrupt status checks

On Fri, Jan 13, 2017 at 03:35:37PM -0800, Brian Norris wrote: > The following sequence occurs when using IEEE power-save on 8997: > (a) driver sees SLEEP event > (b) driver issues SLEEP CONFIRM > (c) driver recevies CMD interrupt; within the interrupt processing loop, > we do (d) and (e): >

Re: [PATCH v2 2/3] mwifiex: pcie: don't loop/retry interrupt status checks

On Fri, Jan 13, 2017 at 03:35:37PM -0800, Brian Norris wrote: > The following sequence occurs when using IEEE power-save on 8997: > (a) driver sees SLEEP event > (b) driver issues SLEEP CONFIRM > (c) driver recevies CMD interrupt; within the interrupt processing loop, > we do (d) and (e): >

Re: [PATCH v18 00/15] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

Hi Mark, On 14 January 2017 at 19:34, Fu Wei wrote: > Hi Mark, > > On 14 January 2017 at 03:29, Mark Rutland wrote: >> Hi, >> >> On Fri, Dec 09, 2016 at 01:33:04AM +0800, fu@linaro.org wrote: >>> From: Fu Wei >>> >>> This

Re: [PATCH v18 00/15] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

Hi Mark, On 14 January 2017 at 19:34, Fu Wei wrote: > Hi Mark, > > On 14 January 2017 at 03:29, Mark Rutland wrote: >> Hi, >> >> On Fri, Dec 09, 2016 at 01:33:04AM +0800, fu@linaro.org wrote: >>> From: Fu Wei >>> >>> This patchset: >>> (1)Preparation for adding GTDT support in

Linux 4.10-rc4

Things are still looking fairly normal, and this is the usual weekly Sunday rc release. We're up to rc4, and people are clearly starting to find the regressions. Good, good. it's a slightly more random collection of fixes from last week: the bulk of it is still drivers (gpu, net, sound, usb stand

Linux 4.10-rc4

Things are still looking fairly normal, and this is the usual weekly Sunday rc release. We're up to rc4, and people are clearly starting to find the regressions. Good, good. it's a slightly more random collection of fixes from last week: the bulk of it is still drivers (gpu, net, sound, usb stand

Re: [Ocfs2-devel] [PATCH v3] ocfs2/journal: fix umount hang after flushing journal failure

On 17/1/13 20:37, Eric Ren wrote: On 01/13/2017 10:52 AM, Changwei Ge wrote: Hi Joseph, Do you think my last version of patch to fix umount hang after journal flushing failure is OK? If so, I 'd like to ask Andrew's help to merge this patch into his test tree. Thanks, Br. Changwei The

Re: [Ocfs2-devel] [PATCH v3] ocfs2/journal: fix umount hang after flushing journal failure

On 17/1/13 20:37, Eric Ren wrote: On 01/13/2017 10:52 AM, Changwei Ge wrote: Hi Joseph, Do you think my last version of patch to fix umount hang after journal flushing failure is OK? If so, I 'd like to ask Andrew's help to merge this patch into his test tree. Thanks, Br. Changwei The

Re: [RFC for GIT] pull-request: add praise to people doing QA

Wolfram Sang writes: > === new stuff starts here > > with much appreciated quality assurance from > > Andy Shevchenko (1): > (Rev.) i2c: piix4: Avoid race conditions with IMC > > Benjamin Tissoires (1): >

Re: [RFC for GIT] pull-request: add praise to people doing QA

Wolfram Sang writes: > === new stuff starts here > > with much appreciated quality assurance from > > Andy Shevchenko (1): > (Rev.) i2c: piix4: Avoid race conditions with IMC > > Benjamin Tissoires (1): > (Test) i2c: do

Re: [PATCH v2 3/3] Input: pwm-beeper: add optional amplifier regulator

On Sun, Jan 15, 2017 at 06:12:29PM -0600, David Lechner wrote: > On 01/14/2017 01:19 PM, Dmitry Torokhov wrote: > >On Wed, Jan 11, 2017 at 02:02:01PM -0600, David Lechner wrote: > >>This adds an optional regulator to the pwm-beeper device. This regulator > >>acts as an amplifier. The amplifier is

Re: [PATCH v2 3/3] Input: pwm-beeper: add optional amplifier regulator

On Sun, Jan 15, 2017 at 06:12:29PM -0600, David Lechner wrote: > On 01/14/2017 01:19 PM, Dmitry Torokhov wrote: > >On Wed, Jan 11, 2017 at 02:02:01PM -0600, David Lechner wrote: > >>This adds an optional regulator to the pwm-beeper device. This regulator > >>acts as an amplifier. The amplifier is

Re: [PATCH v2 3/3] Input: pwm-beeper: add optional amplifier regulator

On 01/14/2017 01:19 PM, Dmitry Torokhov wrote: On Wed, Jan 11, 2017 at 02:02:01PM -0600, David Lechner wrote: This adds an optional regulator to the pwm-beeper device. This regulator acts as an amplifier. The amplifier is only enabled while beeping in order to reduce power consumption. Tested

Re: [PATCH v2 3/3] Input: pwm-beeper: add optional amplifier regulator

On 01/14/2017 01:19 PM, Dmitry Torokhov wrote: On Wed, Jan 11, 2017 at 02:02:01PM -0600, David Lechner wrote: This adds an optional regulator to the pwm-beeper device. This regulator acts as an amplifier. The amplifier is only enabled while beeping in order to reduce power consumption. Tested

Re: [PATCHSET for-4.11] cgroup: avoid spurious identity ->*attach() invocations

On Wed, Jan 11, 2017 at 06:46:33PM +0800, Zefan Li wrote: > On 2016/12/30 6:11, Tejun Heo wrote: > > Hello, > > > > On the v2 hierarchy, when controllers are enabled and disabled, other > > ->*attach() callbacks of other controllers are called spuriously with > > the same source and destination.

Re: [PATCHSET for-4.11] cgroup: avoid spurious identity ->*attach() invocations

On Wed, Jan 11, 2017 at 06:46:33PM +0800, Zefan Li wrote: > On 2016/12/30 6:11, Tejun Heo wrote: > > Hello, > > > > On the v2 hierarchy, when controllers are enabled and disabled, other > > ->*attach() callbacks of other controllers are called spuriously with > > the same source and destination.

Re: [PATCH] writeback: use rb_entry()

On Fri, Jan 13, 2017 at 11:17:12PM +0800, Geliang Tang wrote: > To make the code clearer, use rb_entry() instead of container_of() to > deal with rbtree. > > Signed-off-by: Geliang Tang > --- > mm/backing-dev.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) >

Re: [PATCH] writeback: use rb_entry()

On Fri, Jan 13, 2017 at 11:17:12PM +0800, Geliang Tang wrote: > To make the code clearer, use rb_entry() instead of container_of() to > deal with rbtree. > > Signed-off-by: Geliang Tang > --- > mm/backing-dev.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git

[PATCH 3/6] ncr5380: Reduce #include files

The NCR5380 wrapper drivers don't export symbols or declarations and don't actually need separate header files. Most of these header files were removed already; only sun3_scsi.h and g_NCR5380.h remain. Move the remaining definitions to the corresponding .c files to improve readability and

[PATCH 3/6] ncr5380: Reduce #include files

The NCR5380 wrapper drivers don't export symbols or declarations and don't actually need separate header files. Most of these header files were removed already; only sun3_scsi.h and g_NCR5380.h remain. Move the remaining definitions to the corresponding .c files to improve readability and

Re: [PATCH] ahci: imx: fix building without hwmon or thermal

On Wed, Jan 11, 2017 at 02:36:16PM +0100, Arnd Bergmann wrote: > When CONFIG_HWMON is disabled, we now get a link failure: > > ERROR: "devm_hwmon_device_register_with_groups" [drivers/ata/ahci_imx.ko] > undefined! > drivers/ata/ahci_imx.o: In function `imx_ahci_probe': >

Re: [PATCH] ahci: imx: fix building without hwmon or thermal

On Wed, Jan 11, 2017 at 02:36:16PM +0100, Arnd Bergmann wrote: > When CONFIG_HWMON is disabled, we now get a link failure: > > ERROR: "devm_hwmon_device_register_with_groups" [drivers/ata/ahci_imx.ko] > undefined! > drivers/ata/ahci_imx.o: In function `imx_ahci_probe': >

[PATCH 1/6] ncr5380: Shorten host info string by removing unused option macros

The DIFFERENTIAL and PARITY option macros are unused: no supported hardware uses differential signalling and the core driver never implemented parity checking. These options just waste space in the host info string. While we are here, fix a typo in the NCR5380_info() kernel-doc comment.

[PATCH 1/6] ncr5380: Shorten host info string by removing unused option macros

The DIFFERENTIAL and PARITY option macros are unused: no supported hardware uses differential signalling and the core driver never implemented parity checking. These options just waste space in the host info string. While we are here, fix a typo in the NCR5380_info() kernel-doc comment.

[PATCH 5/6] ncr5380: Improve target selection robustness

Handle timeout or bus phase change errors that could occur when sending the IDENTIFY message. Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/NCR5380.c

[PATCH 5/6] ncr5380: Improve target selection robustness

Handle timeout or bus phase change errors that could occur when sending the IDENTIFY message. Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/NCR5380.c b/drivers/scsi/NCR5380.c index 518d101..acc3344

[PATCH 6/6] atari_scsi: Reset DMA during bus reset only under ST-DMA lock

The atari_scsi driver should not access Falcon DMA chip registers unless it has acquired exclusive access to that chip. If the driver doesn't have exclusive access then there's no need for a DMA reset as there are no scsi commands in progress. Signed-off-by: Finn Thain

[PATCH 6/6] atari_scsi: Reset DMA during bus reset only under ST-DMA lock

The atari_scsi driver should not access Falcon DMA chip registers unless it has acquired exclusive access to that chip. If the driver doesn't have exclusive access then there's no need for a DMA reset as there are no scsi commands in progress. Signed-off-by: Finn Thain ---

[PATCH 4/6] ncr5380: Resolve various static checker warnings

Avoid various warnings from "make C=1" by annotating a couple of unlock-then-lock sequences, replacing a zero with NULL and correcting some type casts. Also avoid a warning from "make W=1" by adding braces. Signed-off-by: Finn Thain --- These are the warning messages

[PATCH 2/6] ncr5380: Clean up dead code and redundant macro usage

Remove dead code inside #if 0 conditionals. Remove the #ifdef __KERNEL__ test, since NCR5380.h has no definitions that relate to userspace code. Remove two redundant macro definitions which were overlooked in commit e9db3198e08b ("sun3_scsi: Adopt NCR5380.c core driver"). Signed-off-by: Finn

[PATCH 4/6] ncr5380: Resolve various static checker warnings

Avoid various warnings from "make C=1" by annotating a couple of unlock-then-lock sequences, replacing a zero with NULL and correcting some type casts. Also avoid a warning from "make W=1" by adding braces. Signed-off-by: Finn Thain --- These are the warning messages referred to above:

[PATCH 2/6] ncr5380: Clean up dead code and redundant macro usage

Remove dead code inside #if 0 conditionals. Remove the #ifdef __KERNEL__ test, since NCR5380.h has no definitions that relate to userspace code. Remove two redundant macro definitions which were overlooked in commit e9db3198e08b ("sun3_scsi: Adopt NCR5380.c core driver"). Signed-off-by: Finn

[PATCH 0/6] ncr5380: Miscellaneous minor patches

This series removes some unused code and related comments, addresses the warnings generated by 'make W=1' and 'make C=1' and fixes a theoretical bug in the bus reset method in atari_scsi. There's also a patch to add a missing error check during target selection. The only target I tested was a

[PATCH 0/6] ncr5380: Miscellaneous minor patches

This series removes some unused code and related comments, addresses the warnings generated by 'make W=1' and 'make C=1' and fixes a theoretical bug in the bus reset method in atari_scsi. There's also a patch to add a missing error check during target selection. The only target I tested was a

<    1   2   3   4   5   6   7   >