Re: [PATCH] Allow to use DMA_CTRL_REUSE flag for all channel types

On Fri, Apr 28, 2017 at 04:37:46PM +0300, Eugeniy Paltsev wrote: > In the current implementation dma_get_slave_caps is used to check > state of descriptor_reuse option. But dma_get_slave_caps includes > check if the channel supports slave transactions. > So DMA_CTRL_REUSE flag can be set (even for

Re: [PATCH] Allow to use DMA_CTRL_REUSE flag for all channel types

On Fri, Apr 28, 2017 at 04:37:46PM +0300, Eugeniy Paltsev wrote: > In the current implementation dma_get_slave_caps is used to check > state of descriptor_reuse option. But dma_get_slave_caps includes > check if the channel supports slave transactions. > So DMA_CTRL_REUSE flag can be set (even for

[PATCH man-pages 4/5] userfaultfd.2: add note about asynchronios events delivery

Signed-off-by: Mike Rapoport --- man2/userfaultfd.2 | 12 1 file changed, 12 insertions(+) diff --git a/man2/userfaultfd.2 b/man2/userfaultfd.2 index 8b89162..f177bba 100644 --- a/man2/userfaultfd.2 +++ b/man2/userfaultfd.2 @@ -112,6 +112,18 @@ created for

[PATCH man-pages 1/5] ioctl_userfaultfd.2: update description of shared memory areas

Signed-off-by: Mike Rapoport --- man2/ioctl_userfaultfd.2 | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/man2/ioctl_userfaultfd.2 b/man2/ioctl_userfaultfd.2 index 889feb9..6edd396 100644 --- a/man2/ioctl_userfaultfd.2 +++

[PATCH man-pages 3/5] ioctl_userfaultfd.2: add BUGS section

The features handshake is not quite convenient. Elaborate about it in the BUGS section. Signed-off-by: Mike Rapoport --- man2/ioctl_userfaultfd.2 | 9 + 1 file changed, 9 insertions(+) diff --git a/man2/ioctl_userfaultfd.2 b/man2/ioctl_userfaultfd.2 index

[PATCH man-pages 5/5] userfaultfd.2: update VERSIONS section with 4.11 chanegs

Signed-off-by: Mike Rapoport --- man2/userfaultfd.2 | 3 +++ 1 file changed, 3 insertions(+) diff --git a/man2/userfaultfd.2 b/man2/userfaultfd.2 index f177bba..07a69f1 100644 --- a/man2/userfaultfd.2 +++ b/man2/userfaultfd.2 @@ -404,6 +404,9 @@ Insufficient kernel

[PATCH man-pages 2/5] ioctl_userfaultfd.2: UFFDIO_COPY: add ENOENT and ENOSPC description

Signed-off-by: Mike Rapoport --- man2/ioctl_userfaultfd.2 | 13 + 1 file changed, 13 insertions(+) diff --git a/man2/ioctl_userfaultfd.2 b/man2/ioctl_userfaultfd.2 index 6edd396..e12b9de 100644 --- a/man2/ioctl_userfaultfd.2 +++ b/man2/ioctl_userfaultfd.2 @@

[PATCH man-pages 0/5] {ioctl_}userfaultfd.2: yet another update

Hi Michael, These updates pretty much complete the coverage of 4.11 additions, IMHO. Mike Rapoport (5): ioctl_userfaultfd.2: update description of shared memory areas ioctl_userfaultfd.2: UFFDIO_COPY: add ENOENT and ENOSPC description ioctl_userfaultfd.2: add BUGS section userfaultfd.2:

[PATCH man-pages 1/5] ioctl_userfaultfd.2: update description of shared memory areas

Signed-off-by: Mike Rapoport --- man2/ioctl_userfaultfd.2 | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/man2/ioctl_userfaultfd.2 b/man2/ioctl_userfaultfd.2 index 889feb9..6edd396 100644 --- a/man2/ioctl_userfaultfd.2 +++ b/man2/ioctl_userfaultfd.2 @@ -181,8

[PATCH man-pages 3/5] ioctl_userfaultfd.2: add BUGS section

The features handshake is not quite convenient. Elaborate about it in the BUGS section. Signed-off-by: Mike Rapoport --- man2/ioctl_userfaultfd.2 | 9 + 1 file changed, 9 insertions(+) diff --git a/man2/ioctl_userfaultfd.2 b/man2/ioctl_userfaultfd.2 index e12b9de..50316de 100644 ---

[PATCH man-pages 5/5] userfaultfd.2: update VERSIONS section with 4.11 chanegs

Signed-off-by: Mike Rapoport --- man2/userfaultfd.2 | 3 +++ 1 file changed, 3 insertions(+) diff --git a/man2/userfaultfd.2 b/man2/userfaultfd.2 index f177bba..07a69f1 100644 --- a/man2/userfaultfd.2 +++ b/man2/userfaultfd.2 @@ -404,6 +404,9 @@ Insufficient kernel memory was available. The

[PATCH man-pages 2/5] ioctl_userfaultfd.2: UFFDIO_COPY: add ENOENT and ENOSPC description

Signed-off-by: Mike Rapoport --- man2/ioctl_userfaultfd.2 | 13 + 1 file changed, 13 insertions(+) diff --git a/man2/ioctl_userfaultfd.2 b/man2/ioctl_userfaultfd.2 index 6edd396..e12b9de 100644 --- a/man2/ioctl_userfaultfd.2 +++ b/man2/ioctl_userfaultfd.2 @@ -481,6 +481,19 @@ was

[PATCH man-pages 0/5] {ioctl_}userfaultfd.2: yet another update

Hi Michael, These updates pretty much complete the coverage of 4.11 additions, IMHO. Mike Rapoport (5): ioctl_userfaultfd.2: update description of shared memory areas ioctl_userfaultfd.2: UFFDIO_COPY: add ENOENT and ENOSPC description ioctl_userfaultfd.2: add BUGS section userfaultfd.2:

[PATCH man-pages 4/5] userfaultfd.2: add note about asynchronios events delivery

Signed-off-by: Mike Rapoport --- man2/userfaultfd.2 | 12 1 file changed, 12 insertions(+) diff --git a/man2/userfaultfd.2 b/man2/userfaultfd.2 index 8b89162..f177bba 100644 --- a/man2/userfaultfd.2 +++ b/man2/userfaultfd.2 @@ -112,6 +112,18 @@ created for the child process, which

Re: [PATCH 0/3] TI-SoC-thermal: Fine-tuning for two functions

On Thursday 27 April 2017 09:50 PM, Eduardo Valentin wrote: > On Wed, Apr 26, 2017 at 05:33:10PM +0200, SF Markus Elfring wrote: >> From: Markus Elfring >> Date: Wed, 26 Apr 2017 17:24:56 +0200 >> >> Three update suggestions were taken into account >> from static

Re: [PATCH 0/3] TI-SoC-thermal: Fine-tuning for two functions

On Thursday 27 April 2017 09:50 PM, Eduardo Valentin wrote: > On Wed, Apr 26, 2017 at 05:33:10PM +0200, SF Markus Elfring wrote: >> From: Markus Elfring >> Date: Wed, 26 Apr 2017 17:24:56 +0200 >> >> Three update suggestions were taken into account >> from static source code analysis. >> >>

Re: new ...at() flag: AT_NO_JUMPS

On Sun, Apr 30, 2017 at 09:52:37PM -0700, Andy Lutomirski wrote: > On Sun, Apr 30, 2017 at 9:10 AM, Al Viro wrote: > > On Sat, Apr 29, 2017 at 09:38:22PM -0700, Matthew Wilcox wrote: > > > >> It sounds more like AT_NO_ESCAPE ... or AT_BELOW, or something. > > > > I

Re: new ...at() flag: AT_NO_JUMPS

On Sun, Apr 30, 2017 at 09:52:37PM -0700, Andy Lutomirski wrote: > On Sun, Apr 30, 2017 at 9:10 AM, Al Viro wrote: > > On Sat, Apr 29, 2017 at 09:38:22PM -0700, Matthew Wilcox wrote: > > > >> It sounds more like AT_NO_ESCAPE ... or AT_BELOW, or something. > > > > I considered AT_ROACH_MOTEL at

Re: [PATCH 02/11] blk: make the bioset rescue_workqueue optional.

On Mon, Apr 24 2017, Christoph Hellwig wrote: > On Mon, Apr 24, 2017 at 11:51:01AM +1000, NeilBrown wrote: >> >> I was following the existing practice exemplified by >> bioset_create_nobvec(). > > Which is pretty ugly to start with.. That is a matter of personal taste. As such, it is up to the

Re: [PATCH 02/11] blk: make the bioset rescue_workqueue optional.

On Mon, Apr 24 2017, Christoph Hellwig wrote: > On Mon, Apr 24, 2017 at 11:51:01AM +1000, NeilBrown wrote: >> >> I was following the existing practice exemplified by >> bioset_create_nobvec(). > > Which is pretty ugly to start with.. That is a matter of personal taste. As such, it is up to the

Re: [PATCH v7] Input: psxpad-spi - Add PlayStation 1/2 joypads via SPI interface Driver

Mr.Torokhov I fixed source, and sent PATCH v7 to you. I'm sorry to occars warnings. * In function 'psxpad_spi_probe', removed uninitialized value 'err' in dev_err(). * 'psxpad_spi_resume' restored. Regards. -- Tomohiro

Re: [PATCH v7] Input: psxpad-spi - Add PlayStation 1/2 joypads via SPI interface Driver

Mr.Torokhov I fixed source, and sent PATCH v7 to you. I'm sorry to occars warnings. * In function 'psxpad_spi_probe', removed uninitialized value 'err' in dev_err(). * 'psxpad_spi_resume' restored. Regards. -- Tomohiro

linux-next: build warning after merge of the cgroup tree

Hi Tejun, After merging the cgroup tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: kernel/cgroup/cgroup.c:439:13: warning: 'cgroup_get' defined but not used [-Wunused-function] static void cgroup_get(struct cgroup *cgrp) ^ Introduced by commit

linux-next: build warning after merge of the cgroup tree

Hi Tejun, After merging the cgroup tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: kernel/cgroup/cgroup.c:439:13: warning: 'cgroup_get' defined but not used [-Wunused-function] static void cgroup_get(struct cgroup *cgrp) ^ Introduced by commit

Re: [PATCH 0/2] arm64: Workaround for Thunder KVM hang issues.

On 04/24/2017 02:42 PM, David Daney wrote: > We have discovered in rare circumstances, guest execution may result > in host not receiving one or more interrupts. This does not otherwise > affect guest or host execution and/or isolation. Thanks David. I have tested these and can confirm that a

Re: [PATCH 0/2] arm64: Workaround for Thunder KVM hang issues.

On 04/24/2017 02:42 PM, David Daney wrote: > We have discovered in rare circumstances, guest execution may result > in host not receiving one or more interrupts. This does not otherwise > affect guest or host execution and/or isolation. Thanks David. I have tested these and can confirm that a

Re: new ...at() flag: AT_NO_JUMPS

On Sun, Apr 30, 2017 at 9:10 AM, Al Viro wrote: > On Sat, Apr 29, 2017 at 09:38:22PM -0700, Matthew Wilcox wrote: > >> It sounds more like AT_NO_ESCAPE ... or AT_BELOW, or something. > > I considered AT_ROACH_MOTEL at one point... Another interesting > question is

Re: new ...at() flag: AT_NO_JUMPS

On Sun, Apr 30, 2017 at 9:10 AM, Al Viro wrote: > On Sat, Apr 29, 2017 at 09:38:22PM -0700, Matthew Wilcox wrote: > >> It sounds more like AT_NO_ESCAPE ... or AT_BELOW, or something. > > I considered AT_ROACH_MOTEL at one point... Another interesting > question is whether EXDEV would've been

linux-next: build failure after merge of the staging tree

Hi Greg, After merging the staging tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c: In function 'rtw_cfg80211_indicate_connect': drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:552:6: error: passing argument 2 of

linux-next: build failure after merge of the staging tree

Hi Greg, After merging the staging tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c: In function 'rtw_cfg80211_indicate_connect': drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:552:6: error: passing argument 2 of

[GIT PULL] EDAC queue for 4.12

Hi Linus, here's the EDAC pile for 4.12. Please pull, thanks. -- The following changes since commit 819f60fb7db169d851186d04e571e9bca27321e8: EDAC, pnd2_edac: Fix reported DIMM number (2017-03-26 09:36:28 +0200) are available in the git repository at:

[GIT PULL] EDAC queue for 4.12

Hi Linus, here's the EDAC pile for 4.12. Please pull, thanks. -- The following changes since commit 819f60fb7db169d851186d04e571e9bca27321e8: EDAC, pnd2_edac: Fix reported DIMM number (2017-03-26 09:36:28 +0200) are available in the git repository at:

linux-next: manual merge of the staging tree with the usb tree

Hi Greg, Today's linux-next merge of the staging tree got a conflict in: drivers/staging/Makefile between commit: f0690a25a140 ("staging: typec: USB Type-C Port Manager (tcpm)") from the usb tree and commit: 051420a997a5 ("staging: bcm2835-audio: Move driver under vc04_services")

linux-next: manual merge of the staging tree with the usb tree

Hi Greg, Today's linux-next merge of the staging tree got a conflict in: drivers/staging/Makefile between commit: f0690a25a140 ("staging: typec: USB Type-C Port Manager (tcpm)") from the usb tree and commit: 051420a997a5 ("staging: bcm2835-audio: Move driver under vc04_services")

Re: [PATCH v2] mm, zone_device: replace {get, put}_zone_device_page() with a single reference

On 30/04/17 05:14 PM, Jerome Glisse wrote: > HMM ZONE_DEVICE pages are use like other pages (anonymous or file back page) > in _any_ vma. So i need to know when a page is freed ie either as result of > unmap, exit or migration or anything that would free the memory. For zone > device a page is

Re: [PATCH v2] mm, zone_device: replace {get, put}_zone_device_page() with a single reference

On 30/04/17 05:14 PM, Jerome Glisse wrote: > HMM ZONE_DEVICE pages are use like other pages (anonymous or file back page) > in _any_ vma. So i need to know when a page is freed ie either as result of > unmap, exit or migration or anything that would free the memory. For zone > device a page is

[git pull] uaccess-related bits of vfs.git

uaccess unification pile. It's _not_ the end of uaccess work, but the next batch of that will go into the next cycle. This one mostly takes copy_from_user() and friends out of arch/* and gets the zero-padding behaviour in sync for all architectures. Dealing with the

[git pull] uaccess-related bits of vfs.git

uaccess unification pile. It's _not_ the end of uaccess work, but the next batch of that will go into the next cycle. This one mostly takes copy_from_user() and friends out of arch/* and gets the zero-padding behaviour in sync for all architectures. Dealing with the

linux-next: manual merge of the rcu tree with the ftrace tree

Hi Paul, Today's linux-next merge of the rcu tree got a conflict in: kernel/rcu/tree.c between commit: a278d4718988 ("rcu: Fix dyntick-idle tracing") from the ftrace tree and commit: e83d58dc7de2 ("rcu: Add lockdep_assert_held() teeth to tree.c") from the rcu tree. I fixed it up (see

linux-next: manual merge of the rcu tree with the ftrace tree

Hi Paul, Today's linux-next merge of the rcu tree got a conflict in: kernel/rcu/tree.c between commit: a278d4718988 ("rcu: Fix dyntick-idle tracing") from the ftrace tree and commit: e83d58dc7de2 ("rcu: Add lockdep_assert_held() teeth to tree.c") from the rcu tree. I fixed it up (see

Linux 4.11

So after that extra week with an rc8, things were pretty calm, and I'm much happier releasing a final 4.11 now. We still had various smaller fixes the last week, but nothing that made me go "hmm..". Shortlog appended for people who want to peruse the details, but it's a mix all over, with about

Linux 4.11

So after that extra week with an rc8, things were pretty calm, and I'm much happier releasing a final 4.11 now. We still had various smaller fixes the last week, but nothing that made me go "hmm..". Shortlog appended for people who want to peruse the details, but it's a mix all over, with about

Re: [PATCH v2] powerpc/mm: Only read faulting instruction when necessary in do_page_fault()

On Fri, 28 Apr 2017 08:13:01 +0200 (CEST) Christophe Leroy wrote: > Commit a7a9dcd882a67 ("powerpc: Avoid taking a data miss on every > userspace instruction miss") has shown that limiting the read of > faulting instruction to likely cases improves performance. > > This

Re: [PATCH v2] powerpc/mm: Only read faulting instruction when necessary in do_page_fault()

On Fri, 28 Apr 2017 08:13:01 +0200 (CEST) Christophe Leroy wrote: > Commit a7a9dcd882a67 ("powerpc: Avoid taking a data miss on every > userspace instruction miss") has shown that limiting the read of > faulting instruction to likely cases improves performance. > > This patch goes further into

Re: [PATCH] net: phy: Allow BCM5481x PHYs to setup internal TX/RX clock delay

From: Abhishek Shah Date: Sun, 30 Apr 2017 11:04:21 +0530 > This patch allows users to enable/disable internal TX and/or RX > clock delay for BCM5481x series PHYs so as to satisfy RGMII timing > specifications. > > On a particular platform, whether TX and/or RX clock

Re: [PATCH] net: phy: Allow BCM5481x PHYs to setup internal TX/RX clock delay

From: Abhishek Shah Date: Sun, 30 Apr 2017 11:04:21 +0530 > This patch allows users to enable/disable internal TX and/or RX > clock delay for BCM5481x series PHYs so as to satisfy RGMII timing > specifications. > > On a particular platform, whether TX and/or RX clock delay is required > depends

Re: [PATCH] net: sunhme: fix spelling mistakes: "ParityErro" -> "ParityError"

From: Colin King Date: Sat, 29 Apr 2017 22:38:57 +0100 > From: Colin Ian King > > trivial fix to spelling mistakes in printk message. > > Signed-off-by: Colin Ian King Applied.

Re: [PATCH] net: sunhme: fix spelling mistakes: "ParityErro" -> "ParityError"

From: Colin King Date: Sat, 29 Apr 2017 22:38:57 +0100 > From: Colin Ian King > > trivial fix to spelling mistakes in printk message. > > Signed-off-by: Colin Ian King Applied.

Re: [PATCH v2] iov_iter: don't revert iov buffer if csum error

From: Al Viro Date: Sat, 29 Apr 2017 21:48:23 +0100 > On Sat, Apr 29, 2017 at 05:37:38PM +0800, Ding Tianhong wrote: > >> Looks good, if so, we don't need the csum_error any more, > > Acked-by: Al Viro > > Dave, I could put that through my

Re: [PATCH v2] iov_iter: don't revert iov buffer if csum error

From: Al Viro Date: Sat, 29 Apr 2017 21:48:23 +0100 > On Sat, Apr 29, 2017 at 05:37:38PM +0800, Ding Tianhong wrote: > >> Looks good, if so, we don't need the csum_error any more, > > Acked-by: Al Viro > > Dave, I could put that through my tree, but I think it would be better off > in

linux-next: manual merge of the spi tree with the pm tree

Hi Mark, Today's linux-next merge of the spi tree got a conflict in: drivers/acpi/acpi_apd.c between commit: 6e14cf361a0c ("ACPI / APD: Add clock frequency for Hisilicon Hip07/08 I2C controller") from the pm tree and commit: 251831bd4f49 ("spi: xlp: update for ARCH_VULCAN2") from the

linux-next: manual merge of the spi tree with the pm tree

Hi Mark, Today's linux-next merge of the spi tree got a conflict in: drivers/acpi/acpi_apd.c between commit: 6e14cf361a0c ("ACPI / APD: Add clock frequency for Hisilicon Hip07/08 I2C controller") from the pm tree and commit: 251831bd4f49 ("spi: xlp: update for ARCH_VULCAN2") from the

Re: [PATCH v3 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.

From: Eric Anholt Date: Fri, 28 Apr 2017 15:22:03 -0700 > Cygnus is a small family of SoCs, of which we currently have > devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the > same as 58xx, just requiring a tiny bit of setup that was previously > missing. > >

Re: [PATCH v3 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.

From: Eric Anholt Date: Fri, 28 Apr 2017 15:22:03 -0700 > Cygnus is a small family of SoCs, of which we currently have > devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the > same as 58xx, just requiring a tiny bit of setup that was previously > missing. > > v2: Reorder the

Re: [PATCH v2] mm, zone_device: replace {get, put}_zone_device_page() with a single reference

On Sat, Apr 29, 2017 at 7:18 AM, Ingo Molnar wrote: > > * Dan Williams wrote: > >> Kirill points out that the calls to {get,put}_dev_pagemap() can be >> removed from the mm fast path if we take a single get_dev_pagemap() >> reference to signify that

Re: [PATCH v2] mm, zone_device: replace {get, put}_zone_device_page() with a single reference

On Sat, Apr 29, 2017 at 7:18 AM, Ingo Molnar wrote: > > * Dan Williams wrote: > >> Kirill points out that the calls to {get,put}_dev_pagemap() can be >> removed from the mm fast path if we take a single get_dev_pagemap() >> reference to signify that the page is alive and use the final put of the

Re: [PATCH 2/3] mm/slub: wrap cpu_slab->partial in CONFIG_SLUB_CPU_PARTIAL

On Sun, Apr 30, 2017 at 07:31:51PM +0800, Wei Yang wrote: > @@ -2302,7 +2302,11 @@ static bool has_cpu_slab(int cpu, void *info) > struct kmem_cache *s = info; > struct kmem_cache_cpu *c = per_cpu_ptr(s->cpu_slab, cpu); > > - return c->page || c->partial; > + return c->page >

Re: [PATCH 2/3] mm/slub: wrap cpu_slab->partial in CONFIG_SLUB_CPU_PARTIAL

On Sun, Apr 30, 2017 at 07:31:51PM +0800, Wei Yang wrote: > @@ -2302,7 +2302,11 @@ static bool has_cpu_slab(int cpu, void *info) > struct kmem_cache *s = info; > struct kmem_cache_cpu *c = per_cpu_ptr(s->cpu_slab, cpu); > > - return c->page || c->partial; > + return c->page >

Re: [PATCH v2] mm, zone_device: replace {get, put}_zone_device_page() with a single reference

On Sun, Apr 30, 2017 at 6:54 PM, Jerome Glisse wrote: > On Sun, Apr 30, 2017 at 06:42:02PM -0700, Dan Williams wrote: >> On Sun, Apr 30, 2017 at 4:14 PM, Jerome Glisse wrote: >> > On Sat, Apr 29, 2017 at 01:17:26PM +0300, Kirill A. Shutemov wrote: >> >> On

Re: [PATCH v2] mm, zone_device: replace {get, put}_zone_device_page() with a single reference

On Sun, Apr 30, 2017 at 6:54 PM, Jerome Glisse wrote: > On Sun, Apr 30, 2017 at 06:42:02PM -0700, Dan Williams wrote: >> On Sun, Apr 30, 2017 at 4:14 PM, Jerome Glisse wrote: >> > On Sat, Apr 29, 2017 at 01:17:26PM +0300, Kirill A. Shutemov wrote: >> >> On Fri, Apr 28, 2017 at 03:33:07PM -0400,

Re: [PATCH] drivers:net:ethernet:emulex:benet: Use time_before_eq for time comparison

From: Karim Eshapa Date: Fri, 28 Apr 2017 03:48:59 +0200 > Use time_before_eq for time comparison more safe and dealing > with timer wrapping to be future-proof. > > Signed-off-by: Karim Eshapa Subject line has way too many subsystem prefixes,

Re: [PATCH] drivers:net:ethernet:emulex:benet: Use time_before_eq for time comparison

From: Karim Eshapa Date: Fri, 28 Apr 2017 03:48:59 +0200 > Use time_before_eq for time comparison more safe and dealing > with timer wrapping to be future-proof. > > Signed-off-by: Karim Eshapa Subject line has way too many subsystem prefixes, simply "benet: " is sufficient. And in

Re: [PATCH net-next] net: Initialise init_net.count to 1

From: David Howells Date: Thu, 27 Apr 2017 22:40:23 +0100 > Initialise init_net.count to 1 for its pointer from init_nsproxy lest > someone tries to do a get_net() and a put_net() in a process in which > current->ns_proxy->net_ns points to the initial network namespace. > >

Re: [PATCH net-next] net: Initialise init_net.count to 1

From: David Howells Date: Thu, 27 Apr 2017 22:40:23 +0100 > Initialise init_net.count to 1 for its pointer from init_nsproxy lest > someone tries to do a get_net() and a put_net() in a process in which > current->ns_proxy->net_ns points to the initial network namespace. > > Signed-off-by: David

Re: [PATCH] net: macb: fix phy interrupt parsing

From: Alexandre Belloni Date: Wed, 26 Apr 2017 12:06:28 +0200 > Since 83a77e9ec415, the phydev irq is explicitly set to PHY_POLL when > there is no pdata. It doesn't work on DT enabled platforms because the > phydev irq is already set by libphy before. > >

Re: [PATCH] net: macb: fix phy interrupt parsing

From: Alexandre Belloni Date: Wed, 26 Apr 2017 12:06:28 +0200 > Since 83a77e9ec415, the phydev irq is explicitly set to PHY_POLL when > there is no pdata. It doesn't work on DT enabled platforms because the > phydev irq is already set by libphy before. > > Fixes: 83a77e9ec415 ("net: macb: Added

Re: RFC: i2c designware gpio recovery

On 28/04/2017 23:43, Tim Sander wrote: Hi G'day Tim, Given a couple of days I can test this on some flack i2c hardware I have with a Cyclone-V SOC. I'm interested in the functionality as well. For i2c that are connected to the dedicated HPS pins it should be possible to reconfigure the pin

Re: RFC: i2c designware gpio recovery

On 28/04/2017 23:43, Tim Sander wrote: Hi G'day Tim, Given a couple of days I can test this on some flack i2c hardware I have with a Cyclone-V SOC. I'm interested in the functionality as well. For i2c that are connected to the dedicated HPS pins it should be possible to reconfigure the pin

Re: Q. drm/i915 shrinker, synchronize_rcu_expedited() from handlers

Thanx for the reply. Andrea Arcangeli: > Yes I already reported this, my original fix was way more efficient > (and also safer considering the above) than what landed upstream. My > feedback was ignored though. > > https://lists.freedesktop.org/archives/intel-gfx/2017-April/125414.html I see.

Re: Q. drm/i915 shrinker, synchronize_rcu_expedited() from handlers

Thanx for the reply. Andrea Arcangeli: > Yes I already reported this, my original fix was way more efficient > (and also safer considering the above) than what landed upstream. My > feedback was ignored though. > > https://lists.freedesktop.org/archives/intel-gfx/2017-April/125414.html I see.

Re: RFC: i2c designware gpio recovery

G'day Tim, On 29/04/2017 00:14, Tim Sander wrote: Hi After sending this mail i just found out how i could reset the i2c-1 controller manually with devmem 0xffd05014 32 0x2000 devmem 0xffd05014 32 0 So i took a look into the device tree file socfpga.dtsi and found that the reset lines where

Re: RFC: i2c designware gpio recovery

G'day Tim, On 29/04/2017 00:14, Tim Sander wrote: Hi After sending this mail i just found out how i could reset the i2c-1 controller manually with devmem 0xffd05014 32 0x2000 devmem 0xffd05014 32 0 So i took a look into the device tree file socfpga.dtsi and found that the reset lines where

Re: [PATCH v2] mm, zone_device: replace {get, put}_zone_device_page() with a single reference

On Sun, Apr 30, 2017 at 06:42:02PM -0700, Dan Williams wrote: > On Sun, Apr 30, 2017 at 4:14 PM, Jerome Glisse wrote: > > On Sat, Apr 29, 2017 at 01:17:26PM +0300, Kirill A. Shutemov wrote: > >> On Fri, Apr 28, 2017 at 03:33:07PM -0400, Jerome Glisse wrote: > >> > On Fri, Apr

Re: [PATCH v2] mm, zone_device: replace {get, put}_zone_device_page() with a single reference

On Sun, Apr 30, 2017 at 06:42:02PM -0700, Dan Williams wrote: > On Sun, Apr 30, 2017 at 4:14 PM, Jerome Glisse wrote: > > On Sat, Apr 29, 2017 at 01:17:26PM +0300, Kirill A. Shutemov wrote: > >> On Fri, Apr 28, 2017 at 03:33:07PM -0400, Jerome Glisse wrote: > >> > On Fri, Apr 28, 2017 at

Re: [PATCH v2] mm, zone_device: replace {get, put}_zone_device_page() with a single reference

On Sun, Apr 30, 2017 at 4:14 PM, Jerome Glisse wrote: > On Sat, Apr 29, 2017 at 01:17:26PM +0300, Kirill A. Shutemov wrote: >> On Fri, Apr 28, 2017 at 03:33:07PM -0400, Jerome Glisse wrote: >> > On Fri, Apr 28, 2017 at 12:22:24PM -0700, Dan Williams wrote: >> > > Are you sure

Re: [PATCH v2] mm, zone_device: replace {get, put}_zone_device_page() with a single reference

On Sun, Apr 30, 2017 at 4:14 PM, Jerome Glisse wrote: > On Sat, Apr 29, 2017 at 01:17:26PM +0300, Kirill A. Shutemov wrote: >> On Fri, Apr 28, 2017 at 03:33:07PM -0400, Jerome Glisse wrote: >> > On Fri, Apr 28, 2017 at 12:22:24PM -0700, Dan Williams wrote: >> > > Are you sure about needing to

Re: [PATCH] net: phy: Allow BCM5481x PHYs to setup internal TX/RX clock delay

On 04/29/2017 10:34 PM, Abhishek Shah wrote: > This patch allows users to enable/disable internal TX and/or RX > clock delay for BCM5481x series PHYs so as to satisfy RGMII timing > specifications. > > On a particular platform, whether TX and/or RX clock delay is required > depends on how PHY

Re: [PATCH] net: phy: Allow BCM5481x PHYs to setup internal TX/RX clock delay

On 04/29/2017 10:34 PM, Abhishek Shah wrote: > This patch allows users to enable/disable internal TX and/or RX > clock delay for BCM5481x series PHYs so as to satisfy RGMII timing > specifications. > > On a particular platform, whether TX and/or RX clock delay is required > depends on how PHY

Re: [PATCH v2 4/4] iio: accel: adxl345: Add support for triggered buffer

On 29/04/17 08:49, Eva Rachel Retuya wrote: > Previously, the only way to capture data is to read the exposed sysfs > files in_accel_[x/y/z]_raw and applying the scale from in_accel_scale. > Provide a way for continuous data capture that allows multiple data > channels to be read at once by

Re: [PATCH v2 4/4] iio: accel: adxl345: Add support for triggered buffer

On 29/04/17 08:49, Eva Rachel Retuya wrote: > Previously, the only way to capture data is to read the exposed sysfs > files in_accel_[x/y/z]_raw and applying the scale from in_accel_scale. > Provide a way for continuous data capture that allows multiple data > channels to be read at once by

Re: [PATCH v2 3/4] iio: accel: adxl345: Setup DATA_READY trigger

On 29/04/17 08:49, Eva Rachel Retuya wrote: > The ADXL345 provides a DATA_READY interrupt function to signal > availability of new data. This interrupt function is latched and can be > cleared by reading the data registers. The polarity is set to active > high by default. > > Support this

Re: [PATCH v2 3/4] iio: accel: adxl345: Setup DATA_READY trigger

On 29/04/17 08:49, Eva Rachel Retuya wrote: > The ADXL345 provides a DATA_READY interrupt function to signal > availability of new data. This interrupt function is latched and can be > cleared by reading the data registers. The polarity is set to active > high by default. > > Support this

Re: [PATCH v2 2/4] iio: accel: adxl345_core: Introduce set_mode and data_ready functions

On 29/04/17 08:48, Eva Rachel Retuya wrote: > Move code that enables measurement/standby mode into its own function > and call that function when appropriate. Previously, we set the sensor > to measurement in probe and back to standby during remove. Change it > here to only enter measurement mode

Re: [PATCH v2 2/4] iio: accel: adxl345_core: Introduce set_mode and data_ready functions

On 29/04/17 08:48, Eva Rachel Retuya wrote: > Move code that enables measurement/standby mode into its own function > and call that function when appropriate. Previously, we set the sensor > to measurement in probe and back to standby during remove. Change it > here to only enter measurement mode

[PATCH 5/6] Drivers: hv: vmbus: Fix rescind handling

From: K. Y. Srinivasan Fix the rescind handling. This patch addresses the following rescind scenario that is currently not handled correctly: If a rescind were to be received while the offer is still being peocessed, we will be blocked indefinitely since the rescind message

[PATCH 5/6] Drivers: hv: vmbus: Fix rescind handling

From: K. Y. Srinivasan Fix the rescind handling. This patch addresses the following rescind scenario that is currently not handled correctly: If a rescind were to be received while the offer is still being peocessed, we will be blocked indefinitely since the rescind message is handled on the

[PATCH 4/6] Drivers: hv: util: Make hv_poll_channel() a little more efficient

From: K. Y. Srinivasan The current code unconditionally sends an IPI. If we are running on the correct CPU and are in interrupt level, we don't need an IPI. Make this adjustment. Signed-off-by: K. Y. Srinivasan --- drivers/hv/hyperv_vmbus.h |4

[PATCH 4/6] Drivers: hv: util: Make hv_poll_channel() a little more efficient

From: K. Y. Srinivasan The current code unconditionally sends an IPI. If we are running on the correct CPU and are in interrupt level, we don't need an IPI. Make this adjustment. Signed-off-by: K. Y. Srinivasan --- drivers/hv/hyperv_vmbus.h |4 1 files changed, 4 insertions(+), 0

[PATCH 3/6] Drivers: hv: vmbus: Fix error code returned by vmbus_post_msg()

From: K. Y. Srinivasan ENOBUFS is a more approrpiate error code to be returned when the hypervisor cannot post the message because of insufficient buffers. Make the adjustment. Signed-off-by: K. Y. Srinivasan --- drivers/hv/connection.c |2 +- 1

[PATCH 3/6] Drivers: hv: vmbus: Fix error code returned by vmbus_post_msg()

From: K. Y. Srinivasan ENOBUFS is a more approrpiate error code to be returned when the hypervisor cannot post the message because of insufficient buffers. Make the adjustment. Signed-off-by: K. Y. Srinivasan --- drivers/hv/connection.c |2 +- 1 files changed, 1 insertions(+), 1

Re: [PATCH v1] LSM: Enable multiple calls to security_add_hooks() for the same LSM

On Sat, 29 Apr 2017, Mickaël Salaün wrote: > Check if the registering LSM already registered hooks just before. This > enable to split hook declarations into multiple files without > registering multiple time the same LSM name, starting from commit > d69dece5f5b6 ("LSM: Add

Re: [PATCH v1] LSM: Enable multiple calls to security_add_hooks() for the same LSM

On Sat, 29 Apr 2017, Mickaël Salaün wrote: > Check if the registering LSM already registered hooks just before. This > enable to split hook declarations into multiple files without > registering multiple time the same LSM name, starting from commit > d69dece5f5b6 ("LSM: Add

[PATCH 6/6] HV: properly delay KVP packets when negotiation is in progress

From: Long Li The host may send multiple negotiation packets (due to timeout) before the KVP user-mode daemon is connected. KVP user-mode daemon is connected. We need to defer processing those packets until the daemon is negotiated and connected. It's okay for guest to

[PATCH 6/6] HV: properly delay KVP packets when negotiation is in progress

From: Long Li The host may send multiple negotiation packets (due to timeout) before the KVP user-mode daemon is connected. KVP user-mode daemon is connected. We need to defer processing those packets until the daemon is negotiated and connected. It's okay for guest to respond to all negotiation

[PATCH 2/6] tools: hv: properly handle long paths

From: Vitaly Kuznetsov Paths can be up to PATH_MAX long and PATH_MAX is usually greater than 256. While on it, simplify path reconstruction to a simple snprintf(), define and reuse KVP_NET_DIR. Suggested-by: Tomas Hozza Signed-off-by: Vitaly Kuznetsov

[PATCH 2/6] tools: hv: properly handle long paths

From: Vitaly Kuznetsov Paths can be up to PATH_MAX long and PATH_MAX is usually greater than 256. While on it, simplify path reconstruction to a simple snprintf(), define and reuse KVP_NET_DIR. Suggested-by: Tomas Hozza Signed-off-by: Vitaly Kuznetsov Signed-off-by: K. Y. Srinivasan ---

[PATCH 1/6] Tools: hv: vss: Thaw the filesystem and continue if freeze call has timed out

From: Alex Ng If a FREEZE operation takes too long, the driver may time out and move on to another operation. The daemon is unaware of this and attempts to notify the driver that the FREEZE succeeded. This results in an error from the driver and the daemon leaves

[PATCH 1/6] Tools: hv: vss: Thaw the filesystem and continue if freeze call has timed out

From: Alex Ng If a FREEZE operation takes too long, the driver may time out and move on to another operation. The daemon is unaware of this and attempts to notify the driver that the FREEZE succeeded. This results in an error from the driver and the daemon leaves the filesystem in frozen state.

[PATCH 0/6] Drivers: hv: Miscellaneous fixes

From: K. Y. Srinivasan Miscellaneous fixes to vmbus and util drivers. Alex Ng (1): Tools: hv: vss: Thaw the filesystem and continue if freeze call has timed out K. Y. Srinivasan (3): Drivers: hv: vmbus: Fix error code returned by vmbus_post_msg() Drivers: hv:

[PATCH 0/6] Drivers: hv: Miscellaneous fixes

From: K. Y. Srinivasan Miscellaneous fixes to vmbus and util drivers. Alex Ng (1): Tools: hv: vss: Thaw the filesystem and continue if freeze call has timed out K. Y. Srinivasan (3): Drivers: hv: vmbus: Fix error code returned by vmbus_post_msg() Drivers: hv: util: Make

  1   2   3   4   >