[PATCH v5 3/5] crypto: Change LZ4 modules to work with new LZ4 module version

This patch updates the crypto modules using LZ4 compression to work with the new LZ4 module version. Signed-off-by: Sven Schmidt <4ssch...@informatik.uni-hamburg.de> --- crypto/lz4.c | 21 - crypto/lz4hc.c | 21 - 2 files changed, 16 insertions(+), 26

[PATCH v5 4/5] fs/pstore: fs/squashfs: Change usage of LZ4 to work with new LZ4 version

This patch updates fs/pstore and fs/squashfs to use the updated functions from the new LZ4 module. Signed-off-by: Sven Schmidt <4ssch...@informatik.uni-hamburg.de> --- fs/pstore/platform.c | 14 +++--- fs/squashfs/lz4_wrapper.c | 12 ++-- 2 files changed, 13 insertions(+),

[PATCH v5 1/5] lib: Update LZ4 compressor module

This patch updates LZ4 kernel module to LZ4 v1.7.3 by Yann Collet. The kernel module is inspired by the previous work by Chanho Min. The updated LZ4 module will not break existing code since the patchset contains appropriate changes. API changes: New method LZ4_compress_fast which differs from

[PATCH v5 3/5] crypto: Change LZ4 modules to work with new LZ4 module version

This patch updates the crypto modules using LZ4 compression to work with the new LZ4 module version. Signed-off-by: Sven Schmidt <4ssch...@informatik.uni-hamburg.de> --- crypto/lz4.c | 21 - crypto/lz4hc.c | 21 - 2 files changed, 16 insertions(+), 26

[PATCH v5 4/5] fs/pstore: fs/squashfs: Change usage of LZ4 to work with new LZ4 version

This patch updates fs/pstore and fs/squashfs to use the updated functions from the new LZ4 module. Signed-off-by: Sven Schmidt <4ssch...@informatik.uni-hamburg.de> --- fs/pstore/platform.c | 14 +++--- fs/squashfs/lz4_wrapper.c | 12 ++-- 2 files changed, 13 insertions(+),

[PATCH v5 1/5] lib: Update LZ4 compressor module

This patch updates LZ4 kernel module to LZ4 v1.7.3 by Yann Collet. The kernel module is inspired by the previous work by Chanho Min. The updated LZ4 module will not break existing code since the patchset contains appropriate changes. API changes: New method LZ4_compress_fast which differs from

Re: [PATCH v6] mm: Add memory allocation watchdog kernel thread.

On Wed 25-01-17 14:22:45, Johannes Weiner wrote: > On Wed, Jan 25, 2017 at 07:45:49PM +0100, Michal Hocko wrote: > > On Wed 25-01-17 13:11:50, Johannes Weiner wrote: > > [...] > > > >From 6420cae52cac8167bd5fb19f45feed2d540bc11d Mon Sep 17 00:00:00 2001 > > > From: Johannes Weiner

[PATCH v5 5/5] lib/lz4: Remove back-compat wrappers

This patch removes the functions introduced as wrappers for providing backwards compatibility to the prior LZ4 version. They're not needed anymore since there's no callers left. Signed-off-by: Sven Schmidt <4ssch...@informatik.uni-hamburg.de> --- include/linux/lz4.h | 73

Re: [PATCH v6] mm: Add memory allocation watchdog kernel thread.

On Wed 25-01-17 14:22:45, Johannes Weiner wrote: > On Wed, Jan 25, 2017 at 07:45:49PM +0100, Michal Hocko wrote: > > On Wed 25-01-17 13:11:50, Johannes Weiner wrote: > > [...] > > > >From 6420cae52cac8167bd5fb19f45feed2d540bc11d Mon Sep 17 00:00:00 2001 > > > From: Johannes Weiner > > > Date:

[PATCH v5 5/5] lib/lz4: Remove back-compat wrappers

This patch removes the functions introduced as wrappers for providing backwards compatibility to the prior LZ4 version. They're not needed anymore since there's no callers left. Signed-off-by: Sven Schmidt <4ssch...@informatik.uni-hamburg.de> --- include/linux/lz4.h | 73

[PATCH v5 2/5] lib/decompress_unlz4: Change module to work with new LZ4 module version

This patch updates the unlz4 wrapper to work with the updated LZ4 kernel module version. Signed-off-by: Sven Schmidt <4ssch...@informatik.uni-hamburg.de> --- lib/decompress_unlz4.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/lib/decompress_unlz4.c

[PATCH v5 2/5] lib/decompress_unlz4: Change module to work with new LZ4 module version

This patch updates the unlz4 wrapper to work with the updated LZ4 kernel module version. Signed-off-by: Sven Schmidt <4ssch...@informatik.uni-hamburg.de> --- lib/decompress_unlz4.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/lib/decompress_unlz4.c

[PATCH v5 0/5] Update LZ4 compressor module

This patchset is for updating the LZ4 compression module to a version based on LZ4 v1.7.3 allowing to use the fast compression algorithm aka LZ4 fast which provides an "acceleration" parameter as a tradeoff between high compression ratio and high compression speed. We want to use LZ4 fast in

[PATCH v5 0/5] Update LZ4 compressor module

This patchset is for updating the LZ4 compression module to a version based on LZ4 v1.7.3 allowing to use the fast compression algorithm aka LZ4 fast which provides an "acceleration" parameter as a tradeoff between high compression ratio and high compression speed. We want to use LZ4 fast in

Re: [PATCH v5 01/13] lockdep: Refactor lookup_chain_cache()

I added a comment that you recommanded after modifying a bit, like the following. Please let me know if the my sentence is rather awkward. Thank you. ->8- commit bb8ad95a4944eec6ab72e950ef063960791b0d8c Author: Byungchul Park Date: Tue Jan 24 16:44:16 2017

Re: [PATCH v5 01/13] lockdep: Refactor lookup_chain_cache()

I added a comment that you recommanded after modifying a bit, like the following. Please let me know if the my sentence is rather awkward. Thank you. ->8- commit bb8ad95a4944eec6ab72e950ef063960791b0d8c Author: Byungchul Park Date: Tue Jan 24 16:44:16 2017 +0900 lockdep: Refactor

Re: [PATCH] Drivers: hv: vmbus: finally fix hv_need_to_signal_on_read()

On Thu, Jan 26, 2017 at 07:44:46AM +, Dexuan Cui wrote: > > From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org] > > > Dexuan Cui wrote: > > > As I checked against the kernels listed on the homapage, > > > the below versions are impacted: > > > v3.16.39 >

Re: [PATCH] Drivers: hv: vmbus: finally fix hv_need_to_signal_on_read()

On Thu, Jan 26, 2017 at 07:44:46AM +, Dexuan Cui wrote: > > From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org] > > > Dexuan Cui wrote: > > > As I checked against the kernels listed on the homapage, > > > the below versions are impacted: > > > v3.16.39 > > > v3.18.47 > > >

Linux 4.4.45

I'm announcing the release of the 4.4.45 kernel. All users of the 4.4 kernel series must upgrade. The updated 4.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.4.y and can be browsed at the normal kernel.org git web browser:

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

Hi Ingo, On 01/26/2017 03:19 PM, Ingo Molnar wrote: > * Lu Baolu wrote: > >> Fair enough. >> >> USB connection is stable enough, unless the user unplugs the >> USB cable during debugging. > What does the hardware do in this case? The XHCI registers are in the host >

Linux 4.4.45

I'm announcing the release of the 4.4.45 kernel. All users of the 4.4 kernel series must upgrade. The updated 4.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.4.y and can be browsed at the normal kernel.org git web browser:

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

Hi Ingo, On 01/26/2017 03:19 PM, Ingo Molnar wrote: > * Lu Baolu wrote: > >> Fair enough. >> >> USB connection is stable enough, unless the user unplugs the >> USB cable during debugging. > What does the hardware do in this case? The XHCI registers are in the host > hardware, so they won't

4.10-rc5+ WARNING: CPU: 3 PID: 1 at ./include/drm/drm_crtc.h:857 drm_kms_helper_poll_enable.part.4+0xa8/0xc0

Hi all, I see this brand new warning when booting here. Top commit is v4.10-rc5-107-g883af14e67e8 from Linus' master. [2.209255] [drm] Initialized [2.210636] [drm] Memory usable by graphics device = 2048M [2.210732] [drm] Replacing VGA console driver [2.211517] Console:

4.10-rc5+ WARNING: CPU: 3 PID: 1 at ./include/drm/drm_crtc.h:857 drm_kms_helper_poll_enable.part.4+0xa8/0xc0

Hi all, I see this brand new warning when booting here. Top commit is v4.10-rc5-107-g883af14e67e8 from Linus' master. [2.209255] [drm] Initialized [2.210636] [drm] Memory usable by graphics device = 2048M [2.210732] [drm] Replacing VGA console driver [2.211517] Console:

Re: Linux 4.9.6

diff --git a/Documentation/devicetree/bindings/clock/imx31-clock.txt b/Documentation/devicetree/bindings/clock/imx31-clock.txt index 19df842c694f..8163d565f697 100644 --- a/Documentation/devicetree/bindings/clock/imx31-clock.txt +++ b/Documentation/devicetree/bindings/clock/imx31-clock.txt @@

Re: Linux 4.9.6

diff --git a/Documentation/devicetree/bindings/clock/imx31-clock.txt b/Documentation/devicetree/bindings/clock/imx31-clock.txt index 19df842c694f..8163d565f697 100644 --- a/Documentation/devicetree/bindings/clock/imx31-clock.txt +++ b/Documentation/devicetree/bindings/clock/imx31-clock.txt @@

Re: Linux 4.4.45

diff --git a/Documentation/devicetree/bindings/clock/imx31-clock.txt b/Documentation/devicetree/bindings/clock/imx31-clock.txt index 19df842c694f..8163d565f697 100644 --- a/Documentation/devicetree/bindings/clock/imx31-clock.txt +++ b/Documentation/devicetree/bindings/clock/imx31-clock.txt @@

Linux 4.9.6

I'm announcing the release of the 4.9.6 kernel. All users of the 4.9 kernel series must upgrade. The updated 4.9.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y and can be browsed at the normal kernel.org git web browser:

Linux 4.9.6

I'm announcing the release of the 4.9.6 kernel. All users of the 4.9 kernel series must upgrade. The updated 4.9.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y and can be browsed at the normal kernel.org git web browser:

Re: Linux 4.4.45

diff --git a/Documentation/devicetree/bindings/clock/imx31-clock.txt b/Documentation/devicetree/bindings/clock/imx31-clock.txt index 19df842c694f..8163d565f697 100644 --- a/Documentation/devicetree/bindings/clock/imx31-clock.txt +++ b/Documentation/devicetree/bindings/clock/imx31-clock.txt @@

Re: [PATCH 8/8] Revert "ext4: fix wrong gfp type under transaction"

On Thu 19-01-17 10:44:05, Michal Hocko wrote: > On Thu 19-01-17 10:22:36, Jan Kara wrote: > > On Thu 19-01-17 09:39:56, Michal Hocko wrote: > > > On Tue 17-01-17 18:29:25, Jan Kara wrote: > > > > On Tue 17-01-17 17:16:19, Michal Hocko wrote: > > > > > > > But before going to play with that I am

Re: [PATCH 8/8] Revert "ext4: fix wrong gfp type under transaction"

On Thu 19-01-17 10:44:05, Michal Hocko wrote: > On Thu 19-01-17 10:22:36, Jan Kara wrote: > > On Thu 19-01-17 09:39:56, Michal Hocko wrote: > > > On Tue 17-01-17 18:29:25, Jan Kara wrote: > > > > On Tue 17-01-17 17:16:19, Michal Hocko wrote: > > > > > > > But before going to play with that I am

RE: [PATCH] Drivers: hv: vmbus: finally fix hv_need_to_signal_on_read()

> From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org] > > Dexuan Cui wrote: > > As I checked against the kernels listed on the homapage, > > the below versions are impacted: > > v3.16.39 > > v3.18.47 > > v4.1.38 > > v4.8.17 > > v4.9.5 > > v4.10-rc5 > > > >

RE: [PATCH] Drivers: hv: vmbus: finally fix hv_need_to_signal_on_read()

> From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org] > > Dexuan Cui wrote: > > As I checked against the kernels listed on the homapage, > > the below versions are impacted: > > v3.16.39 > > v3.18.47 > > v4.1.38 > > v4.8.17 > > v4.9.5 > > v4.10-rc5 > > > > It's interesting

Re: [PATCH 0/6 v3] kvmalloc

On Wed 25-01-17 21:16:42, Daniel Borkmann wrote: > On 01/25/2017 07:14 PM, Alexei Starovoitov wrote: > > On Wed, Jan 25, 2017 at 5:21 AM, Michal Hocko wrote: > > > On Wed 25-01-17 14:10:06, Michal Hocko wrote: > > > > On Tue 24-01-17 11:17:21, Alexei Starovoitov wrote: > [...]

Re: [PATCH 0/6 v3] kvmalloc

On Wed 25-01-17 21:16:42, Daniel Borkmann wrote: > On 01/25/2017 07:14 PM, Alexei Starovoitov wrote: > > On Wed, Jan 25, 2017 at 5:21 AM, Michal Hocko wrote: > > > On Wed 25-01-17 14:10:06, Michal Hocko wrote: > > > > On Tue 24-01-17 11:17:21, Alexei Starovoitov wrote: > [...] > > > > > > Are

Re: [PATCH v5 05/13] lockdep: Pass a callback arg to check_prev_add() to handle stack_trace

I fixed a hole that peterz pointed out. And then, I think the following is reasonable. Don't you think so? ->8- commit ac185d1820ee7223773ec3e23f614c1fe5c079fc Author: Byungchul Park Date: Tue Jan 24 14:46:14 2017 +0900 lockdep: Pass a callback arg to

Re: [PATCH v5 05/13] lockdep: Pass a callback arg to check_prev_add() to handle stack_trace

I fixed a hole that peterz pointed out. And then, I think the following is reasonable. Don't you think so? ->8- commit ac185d1820ee7223773ec3e23f614c1fe5c079fc Author: Byungchul Park Date: Tue Jan 24 14:46:14 2017 +0900 lockdep: Pass a callback arg to check_prev_add() to handle

Re: [PATCH] mm: migrate: add isolate_movable_page() stub implementation

JFYI, Yisheng Xie has already posted a new version of the patchset [1] and I assume Andrew will drop the current one. [1] http://lkml.kernel.org/r/1485356738-4831-1-git-send-email-ys...@foxmail.com On Wed 25-01-17 23:27:38, Arnd Bergmann wrote: > Without CONFIG_MIGRATION, we get a build failure

Re: [PATCH] mm: migrate: add isolate_movable_page() stub implementation

JFYI, Yisheng Xie has already posted a new version of the patchset [1] and I assume Andrew will drop the current one. [1] http://lkml.kernel.org/r/1485356738-4831-1-git-send-email-ys...@foxmail.com On Wed 25-01-17 23:27:38, Arnd Bergmann wrote: > Without CONFIG_MIGRATION, we get a build failure

Re: [PATCHv2 10/12] mm: convert page_mapped_in_vma() to page_vma_mapped_walk()

On January 26, 2017 2:26 AM Kirill A. Shutemov wrote: > > For consistency, it worth converting all page_check_address() to > page_vma_mapped_walk(), so we could drop the former. > > Signed-off-by: Kirill A. Shutemov > --- Acked-by: Hillf Danton

Re: [PATCHv2 10/12] mm: convert page_mapped_in_vma() to page_vma_mapped_walk()

On January 26, 2017 2:26 AM Kirill A. Shutemov wrote: > > For consistency, it worth converting all page_check_address() to > page_vma_mapped_walk(), so we could drop the former. > > Signed-off-by: Kirill A. Shutemov > --- Acked-by: Hillf Danton > mm/page_vma_mapped.c | 30

[PATCH] Kbuild: fix file name in comment about extra gcc checks

Extra gcc checks like W=1 were moved to scripts/Makefile.exrawarn, so the file name in comment needs to be fixed. Signed-off-by: Seung-Woo Kim --- Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index

[PATCH] Kbuild: fix file name in comment about extra gcc checks

Extra gcc checks like W=1 were moved to scripts/Makefile.exrawarn, so the file name in comment needs to be fixed. Signed-off-by: Seung-Woo Kim --- Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index 0988400..dbaada3 100644 --- a/Makefile

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

* Lu Baolu wrote: > > Hi, > > On 01/25/2017 10:38 PM, Peter Zijlstra wrote: > > On Wed, Jan 25, 2017 at 08:27:38PM +0800, Lu Baolu wrote: > >> In my driver, udelay() is mostly used to handle time out. > >> > >> Xdbc hides most USB things in its firmware. Early printk

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

* Lu Baolu wrote: > > Hi, > > On 01/25/2017 10:38 PM, Peter Zijlstra wrote: > > On Wed, Jan 25, 2017 at 08:27:38PM +0800, Lu Baolu wrote: > >> In my driver, udelay() is mostly used to handle time out. > >> > >> Xdbc hides most USB things in its firmware. Early printk driver only needs > >> to

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

* Lu Baolu wrote: > Fair enough. > > USB connection is stable enough, unless the user unplugs the > USB cable during debugging. What does the hardware do in this case? The XHCI registers are in the host hardware, so they won't disappear, right? Is there some cable

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

* Lu Baolu wrote: > Fair enough. > > USB connection is stable enough, unless the user unplugs the > USB cable during debugging. What does the hardware do in this case? The XHCI registers are in the host hardware, so they won't disappear, right? Is there some cable connection status bit we

Re: [PATCH 4/7] arm64: dts: exynos: Add clocks to Exynos5433 LPASS module

Hi Krzysztof, On 2017-01-25 20:50, Krzysztof Kozlowski wrote: On Wed, Jan 25, 2017 at 12:50:28PM +0100, Marek Szyprowski wrote: Exynos5433 LPASS module requires some clocks for proper operation with power domain. Signed-off-by: Marek Szyprowski ---

Re: [PATCH 4/7] arm64: dts: exynos: Add clocks to Exynos5433 LPASS module

Hi Krzysztof, On 2017-01-25 20:50, Krzysztof Kozlowski wrote: On Wed, Jan 25, 2017 at 12:50:28PM +0100, Marek Szyprowski wrote: Exynos5433 LPASS module requires some clocks for proper operation with power domain. Signed-off-by: Marek Szyprowski ---

Re: [PATCH] Drivers: hv: vmbus: finally fix hv_need_to_signal_on_read()

On Thu, Jan 26, 2017 at 06:10:19AM +, Dexuan Cui wrote: > > From: Stephen Hemminger [mailto:step...@networkplumber.org] > > Sent: Wednesday, January 25, 2017 00:08 > > To: Dexuan Cui > > Cc: gre...@linuxfoundation.org; driverdev-de...@linuxdriverproject.org; KY > >

Re: [PATCH] Drivers: hv: vmbus: finally fix hv_need_to_signal_on_read()

On Thu, Jan 26, 2017 at 06:10:19AM +, Dexuan Cui wrote: > > From: Stephen Hemminger [mailto:step...@networkplumber.org] > > Sent: Wednesday, January 25, 2017 00:08 > > To: Dexuan Cui > > Cc: gre...@linuxfoundation.org; driverdev-de...@linuxdriverproject.org; KY > > Srinivasan ; Haiyang Zhang

Re: [PATCH 1/2] soc: samsung: pmu: Remove unused and duplicated defines

Hi Krzysztof, On 2017-01-25 20:34, Krzysztof Kozlowski wrote: The exynos-regs-pmu.h was never a complete list of PMU registers. It contained a lot of holes for registers which are not used. However, a lot of unused defines came with porting the code from vendor kernel. Few of defines were

Re: [PATCH 1/2] soc: samsung: pmu: Remove unused and duplicated defines

Hi Krzysztof, On 2017-01-25 20:34, Krzysztof Kozlowski wrote: The exynos-regs-pmu.h was never a complete list of PMU registers. It contained a lot of holes for registers which are not used. However, a lot of unused defines came with porting the code from vendor kernel. Few of defines were

Re: [PATCHv2 05/12] mm, rmap: check all VMAs that PTE-mapped THP can be part of

On January 26, 2017 2:26 AM Kirill A. Shutemov wrote: > @@ -333,12 +333,15 @@ __vma_address(struct page *page, struct vm_area_struct > *vma) > static inline unsigned long > vma_address(struct page *page, struct vm_area_struct *vma) > { > - unsigned long address = __vma_address(page,

Re: [PATCHv2 05/12] mm, rmap: check all VMAs that PTE-mapped THP can be part of

On January 26, 2017 2:26 AM Kirill A. Shutemov wrote: > @@ -333,12 +333,15 @@ __vma_address(struct page *page, struct vm_area_struct > *vma) > static inline unsigned long > vma_address(struct page *page, struct vm_area_struct *vma) > { > - unsigned long address = __vma_address(page,

Re: [PATCH] x86/mce: Keep quiet in case of broadcasted mce after system panic

On Thu, Jan 26, 2017 at 02:30:02PM +0800, Xunlei Pang wrote: > The hardware machine check is hard to reproduce, but the mce code of > RHEL7 is quite the same as that of tip/master, anyway we are able to > inject software mce to reproduce it. Please give me your exact steps so that I can try to

Re: [PATCH] x86/mce: Keep quiet in case of broadcasted mce after system panic

On Thu, Jan 26, 2017 at 02:30:02PM +0800, Xunlei Pang wrote: > The hardware machine check is hard to reproduce, but the mce code of > RHEL7 is quite the same as that of tip/master, anyway we are able to > inject software mce to reproduce it. Please give me your exact steps so that I can try to

Re: [PATCH] x86/mce: Keep quiet in case of broadcasted mce after system panic

On 01/24/2017 at 08:22 PM, Borislav Petkov wrote: > On Tue, Jan 24, 2017 at 09:27:45AM +0800, Xunlei Pang wrote: >> It occurred on real hardware when testing crash dump. >> >> 1) SysRq-c was injected for the test in 1st kernel >> [ 49.897279] SysRq : Trigger a crash 2) The 2nd kernel started for

Re: [PATCH] x86/mce: Keep quiet in case of broadcasted mce after system panic

On 01/24/2017 at 08:22 PM, Borislav Petkov wrote: > On Tue, Jan 24, 2017 at 09:27:45AM +0800, Xunlei Pang wrote: >> It occurred on real hardware when testing crash dump. >> >> 1) SysRq-c was injected for the test in 1st kernel >> [ 49.897279] SysRq : Trigger a crash 2) The 2nd kernel started for

Re: [PATCH v3 10/14] mmc: jz4740: Let the pinctrl driver configure the pins

Hi Paul, [auto build test ERROR on linus/master] [also build test ERROR on v4.10-rc5 next-20170125] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Paul-Cercueil/Ingenic-JZ4740-JZ4780-pinctrl

Re: [PATCH v3 10/14] mmc: jz4740: Let the pinctrl driver configure the pins

Hi Paul, [auto build test ERROR on linus/master] [also build test ERROR on v4.10-rc5 next-20170125] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Paul-Cercueil/Ingenic-JZ4740-JZ4780-pinctrl

RE: [PATCH] Drivers: hv: vmbus: finally fix hv_need_to_signal_on_read()

> From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: Wednesday, January 25, 2017 00:08 > To: Dexuan Cui > Cc: gre...@linuxfoundation.org; driverdev-de...@linuxdriverproject.org; KY > Srinivasan ; Haiyang Zhang ; >

RE: [PATCH] Drivers: hv: vmbus: finally fix hv_need_to_signal_on_read()

> From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: Wednesday, January 25, 2017 00:08 > To: Dexuan Cui > Cc: gre...@linuxfoundation.org; driverdev-de...@linuxdriverproject.org; KY > Srinivasan ; Haiyang Zhang ; > Stephen Hemminger ; o...@aepfle.de; Rolf > Neugebauer ;

Re: [v3 PATCH 04/10] x86/insn-kernel: Add a function to obtain register offset in ModRM

Hi Masami, On Thu, 2017-01-26 at 11:11 +0900, Masami Hiramatsu wrote: > On Wed, 25 Jan 2017 12:23:47 -0800 > Ricardo Neri wrote: > > > The function insn_get_reg_offset requires a type to indicate whether > > the returned offset is that given by by the

Re: [v3 PATCH 04/10] x86/insn-kernel: Add a function to obtain register offset in ModRM

Hi Masami, On Thu, 2017-01-26 at 11:11 +0900, Masami Hiramatsu wrote: > On Wed, 25 Jan 2017 12:23:47 -0800 > Ricardo Neri wrote: > > > The function insn_get_reg_offset requires a type to indicate whether > > the returned offset is that given by by the ModRM or the SIB byte. > > Callers of this

Re: [PATCH v2] clk: samsung: mark s3c...._clk_sleep_init() as __init

On Wed, Jan 25, 2017 at 10:42:25PM +0100, mar...@kaiser.cx wrote: > From: Martin Kaiser > > These functions are referencing s3c_clk_regs[], which are marked as > __initdata. When compiling with CONFIG_DEBUG_SECTION_MISMATCH=y, this > produces warnings like > > WARNING:

Re: [PATCH v2] clk: samsung: mark s3c...._clk_sleep_init() as __init

On Wed, Jan 25, 2017 at 10:42:25PM +0100, mar...@kaiser.cx wrote: > From: Martin Kaiser > > These functions are referencing s3c_clk_regs[], which are marked as > __initdata. When compiling with CONFIG_DEBUG_SECTION_MISMATCH=y, this > produces warnings like > > WARNING:

Re: [PATCH v20 08/17] clocksource/drivers/arm_arch_timer: Rework counter frequency detection.

Hi Mark, Christopher, On 26 January 2017 at 01:36, Mark Rutland wrote: > On Wed, Jan 25, 2017 at 10:38:01AM -0500, Christopher Covington wrote: >> On 01/25/2017 01:46 AM, Fu Wei wrote: >> > On 25 January 2017 at 01:24, Mark Rutland wrote: >> >> On

Re: [PATCH v20 08/17] clocksource/drivers/arm_arch_timer: Rework counter frequency detection.

Hi Mark, Christopher, On 26 January 2017 at 01:36, Mark Rutland wrote: > On Wed, Jan 25, 2017 at 10:38:01AM -0500, Christopher Covington wrote: >> On 01/25/2017 01:46 AM, Fu Wei wrote: >> > On 25 January 2017 at 01:24, Mark Rutland wrote: >> >> On Wed, Jan 18, 2017 at 09:25:32PM +0800,

Re: [v3 PATCH 07/10] x86: Add emulation code for UMIP instructions

On Wed, 2017-01-25 at 12:38 -0800, H. Peter Anvin wrote: > On 01/25/17 12:23, Ricardo Neri wrote: > > + case UMIP_SMSW: > > + dummy_value = CR0_STATE; > > Unless the user space process is running in 64-bit mode this value > should be & 0x. But wouldn't that prevent the bits

Re: [v3 PATCH 07/10] x86: Add emulation code for UMIP instructions

On Wed, 2017-01-25 at 12:38 -0800, H. Peter Anvin wrote: > On 01/25/17 12:23, Ricardo Neri wrote: > > + case UMIP_SMSW: > > + dummy_value = CR0_STATE; > > Unless the user space process is running in 64-bit mode this value > should be & 0x. But wouldn't that prevent the bits

Re: [PATCH] NFC: remove TI nfcwilink driver

Hi Rob, > It appears that TI WiLink devices including NFC (WL185x/WL189x) never > shipped. The only information I found were announcements in Feb > 2012 about the parts. There's been no activity on this driver besided > common changes since initially added in Jan 2012. There's also no in > users

Re: [PATCH] NFC: remove TI nfcwilink driver

Hi Rob, > It appears that TI WiLink devices including NFC (WL185x/WL189x) never > shipped. The only information I found were announcements in Feb > 2012 about the parts. There's been no activity on this driver besided > common changes since initially added in Jan 2012. There's also no in > users

Re: [PATCH v2] openrisc: migrate exception table users off module.h and onto extable.h

On Wed, Jan 25, 2017 at 04:40:46PM -0500, Paul Gortmaker wrote: > These files were only including module.h for exception table related > functions. We've now separated that content out into its own file > "extable.h" so now move over to that and avoid all the extra header > content in module.h

Re: [PATCH v2] openrisc: migrate exception table users off module.h and onto extable.h

On Wed, Jan 25, 2017 at 04:40:46PM -0500, Paul Gortmaker wrote: > These files were only including module.h for exception table related > functions. We've now separated that content out into its own file > "extable.h" so now move over to that and avoid all the extra header > content in module.h

Re: [RFC PATCH 0/5] userfaultfd: non-cooperative: better tracking for mapping changes

On January 24, 2017 9:52 PM Mike Rapoport wrote: > Hi, > > These patches try to address issues I've encountered during integration of > userfaultfd with CRIU. > Previously added userfaultfd events for fork(), madvise() and mremap() > unfortunately do not cover all possible changes to a process

Re: [RFC PATCH 0/5] userfaultfd: non-cooperative: better tracking for mapping changes

On January 24, 2017 9:52 PM Mike Rapoport wrote: > Hi, > > These patches try to address issues I've encountered during integration of > userfaultfd with CRIU. > Previously added userfaultfd events for fork(), madvise() and mremap() > unfortunately do not cover all possible changes to a process

Re: [v3 PATCH 00/10] x86: Enable User-Mode Instruction Prevention

Hi Peter, On Wed, 2017-01-25 at 12:34 -0800, H. Peter Anvin wrote: > On 01/25/17 12:23, Ricardo Neri wrote: > > * SMSW returns the value with which the CR0 register is programmed in > >head_32/64.S at boot time. This is, the following bits are enabed: > >CR0.0 for Protection Enable, CR.1

Re: [v3 PATCH 00/10] x86: Enable User-Mode Instruction Prevention

Hi Peter, On Wed, 2017-01-25 at 12:34 -0800, H. Peter Anvin wrote: > On 01/25/17 12:23, Ricardo Neri wrote: > > * SMSW returns the value with which the CR0 register is programmed in > >head_32/64.S at boot time. This is, the following bits are enabed: > >CR0.0 for Protection Enable, CR.1

Re: [v3 PATCH 05/10] x86/insn-kernel: Add support to resolve 16-bit addressing encodings

On Wed, 2017-01-25 at 13:58 -0800, Andy Lutomirski wrote: > On Wed, Jan 25, 2017 at 12:23 PM, Ricardo Neri > wrote: > > Tasks running in virtual-8086 mode will use 16-bit addressing form > > encodings as described in the Intel 64 and IA-32 Architecture

Re: [v3 PATCH 05/10] x86/insn-kernel: Add support to resolve 16-bit addressing encodings

On Wed, 2017-01-25 at 13:58 -0800, Andy Lutomirski wrote: > On Wed, Jan 25, 2017 at 12:23 PM, Ricardo Neri > wrote: > > Tasks running in virtual-8086 mode will use 16-bit addressing form > > encodings as described in the Intel 64 and IA-32 Architecture Software > > Developer's Manual Volume 2A

Re: [PATCH v20 08/17] clocksource/drivers/arm_arch_timer: Rework counter frequency detection.

Hi Mark, On 26 January 2017 at 01:25, Mark Rutland wrote: > On Wed, Jan 25, 2017 at 02:46:12PM +0800, Fu Wei wrote: >> Hi Mark, > > Hi, > >> On 25 January 2017 at 01:24, Mark Rutland wrote: >> > On Wed, Jan 18, 2017 at 09:25:32PM +0800,

Re: [PATCH v20 08/17] clocksource/drivers/arm_arch_timer: Rework counter frequency detection.

Hi Mark, On 26 January 2017 at 01:25, Mark Rutland wrote: > On Wed, Jan 25, 2017 at 02:46:12PM +0800, Fu Wei wrote: >> Hi Mark, > > Hi, > >> On 25 January 2017 at 01:24, Mark Rutland wrote: >> > On Wed, Jan 18, 2017 at 09:25:32PM +0800, fu@linaro.org wrote: >> >> From: Fu Wei >> >> >> >>

Re: linux-next: Tree for Jan 19

On Wed, Jan 25, 2017 at 11:37:11AM -0500, Paul Gortmaker wrote: > [Re: linux-next: Tree for Jan 19] On 23/01/2017 (Mon 23:11) Stafford Horne > wrote: > > [...] > > > > > Are all of these builds using the tests from lkp-tests [0]? > > Not using any specific tests, other than compiling

Re: linux-next: Tree for Jan 19

On Wed, Jan 25, 2017 at 11:37:11AM -0500, Paul Gortmaker wrote: > [Re: linux-next: Tree for Jan 19] On 23/01/2017 (Mon 23:11) Stafford Horne > wrote: > > [...] > > > > > Are all of these builds using the tests from lkp-tests [0]? > > Not using any specific tests, other than compiling

Re: [PATCH 0/5] mm: vmscan: fix kswapd writeback regression

On January 24, 2017 2:17 AM Johannes Weiner wrote: > > We noticed a regression on multiple hadoop workloads when moving from > 3.10 to 4.0 and 4.6, which involves kswapd getting tangled up in page > writeout, causing direct reclaim herds that also don't make progress. > > I tracked it down to

Re: [PATCH 0/5] mm: vmscan: fix kswapd writeback regression

On January 24, 2017 2:17 AM Johannes Weiner wrote: > > We noticed a regression on multiple hadoop workloads when moving from > 3.10 to 4.0 and 4.6, which involves kswapd getting tangled up in page > writeout, causing direct reclaim herds that also don't make progress. > > I tracked it down to

Re: [PATCH v2] netfilter: nf_ct_helper: warn when not applying default helper assignment

On Wed, 2017-01-25 at 21:43 +0100, Jiri Kosina wrote: > Rewrite the code a little bit as suggested by Linus, so that we avoid > spaghettiing the code even more -- namely the whole decision making > process regarding helper selection (either automatic or not) is being > separated, so that the whole

Re: [PATCH v2] netfilter: nf_ct_helper: warn when not applying default helper assignment

On Wed, 2017-01-25 at 21:43 +0100, Jiri Kosina wrote: > Rewrite the code a little bit as suggested by Linus, so that we avoid > spaghettiing the code even more -- namely the whole decision making > process regarding helper selection (either automatic or not) is being > separated, so that the whole

Re: linux-next: Tree for Jan 19

On Wed, Jan 25, 2017 at 08:54:53PM -0800, Guenter Roeck wrote: > On 01/25/2017 08:37 AM, Paul Gortmaker wrote: > > [Re: linux-next: Tree for Jan 19] On 23/01/2017 (Mon 23:11) Stafford Horne > > wrote: > > > > [...] > > > > > > > > Are all of these builds using the tests from lkp-tests [0]? > >

Re: linux-next: Tree for Jan 19

On Wed, Jan 25, 2017 at 08:54:53PM -0800, Guenter Roeck wrote: > On 01/25/2017 08:37 AM, Paul Gortmaker wrote: > > [Re: linux-next: Tree for Jan 19] On 23/01/2017 (Mon 23:11) Stafford Horne > > wrote: > > > > [...] > > > > > > > > Are all of these builds using the tests from lkp-tests [0]? > >

Re: [PATCH] mm: vmscan: do not pass reclaimed slab to vmpressure

Hi Minchan On Thu, Jan 26, 2017 at 4:57 AM, Minchan Kim wrote: > Hello Vinayak, > > On Wed, Jan 25, 2017 at 05:08:38PM +0530, Vinayak Menon wrote: >> It is noticed that during a global reclaim the memory >> reclaimed via shrinking the slabs can sometimes result >> in

Re: [PATCH] mm: vmscan: do not pass reclaimed slab to vmpressure

Hi Minchan On Thu, Jan 26, 2017 at 4:57 AM, Minchan Kim wrote: > Hello Vinayak, > > On Wed, Jan 25, 2017 at 05:08:38PM +0530, Vinayak Menon wrote: >> It is noticed that during a global reclaim the memory >> reclaimed via shrinking the slabs can sometimes result >> in reclaimed pages being

Re: linux-next: Tree for Jan 19

On 01/25/2017 08:37 AM, Paul Gortmaker wrote: [Re: linux-next: Tree for Jan 19] On 23/01/2017 (Mon 23:11) Stafford Horne wrote: [...] Are all of these builds using the tests from lkp-tests [0]? Not using any specific tests, other than compiling allmodconfig and defconfig. If so and no

Re: linux-next: Tree for Jan 19

On 01/25/2017 08:37 AM, Paul Gortmaker wrote: [Re: linux-next: Tree for Jan 19] On 23/01/2017 (Mon 23:11) Stafford Horne wrote: [...] Are all of these builds using the tests from lkp-tests [0]? Not using any specific tests, other than compiling allmodconfig and defconfig. If so and no

Re: [PATCH v20 2/4] mailbox: mediatek: Add Mediatek CMDQ driver

On Wed, Jan 4, 2017 at 8:36 AM, HS Liao wrote: > diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c > b/drivers/mailbox/mtk-cmdq-mailbox.c > new file mode 100644 > index 000..747bcd3 > --- /dev/null > +++ b/drivers/mailbox/mtk-cmdq-mailbox.c ... > +static void

Re: [PATCH v20 2/4] mailbox: mediatek: Add Mediatek CMDQ driver

On Wed, Jan 4, 2017 at 8:36 AM, HS Liao wrote: > diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c > b/drivers/mailbox/mtk-cmdq-mailbox.c > new file mode 100644 > index 000..747bcd3 > --- /dev/null > +++ b/drivers/mailbox/mtk-cmdq-mailbox.c ... > +static void cmdq_task_exec(struct cmdq_pkt

Re: [git pull] drm fixes for 4.10-rc6 (just missed rc5 tagging :-)

On Wed, Jan 25, 2017 at 01:54:32PM +0100, Daniel Vetter wrote: > On Wed, Jan 25, 2017 at 06:10:57PM +0900, Michel Dänzer wrote: > > On 25/01/17 05:33 PM, Markus Trippelsdorf wrote: > > > On 2017.01.23 at 09:38 +1000, Dave Airlie wrote: > > >>

Re: [git pull] drm fixes for 4.10-rc6 (just missed rc5 tagging :-)

On Wed, Jan 25, 2017 at 01:54:32PM +0100, Daniel Vetter wrote: > On Wed, Jan 25, 2017 at 06:10:57PM +0900, Michel Dänzer wrote: > > On 25/01/17 05:33 PM, Markus Trippelsdorf wrote: > > > On 2017.01.23 at 09:38 +1000, Dave Airlie wrote: > > >>

  1   2   3   4   5   6   7   8   9   10   >