Re: [PATCH] input: goodix: Poll the 'buffer status' bit before reading data

Hey, Sorry I took this long to look into this. On Thu, 2017-03-30 at 15:33 +0200, Paul Cercueil wrote: > The Goodix panel triggers an interrupt on touch events. However, its > registers will contain the valid values a short time after the > interrupt, and not when it's raised. At that moment,

Re: [PATCH] input: goodix: Poll the 'buffer status' bit before reading data

Hey, Sorry I took this long to look into this. On Thu, 2017-03-30 at 15:33 +0200, Paul Cercueil wrote: > The Goodix panel triggers an interrupt on touch events. However, its > registers will contain the valid values a short time after the > interrupt, and not when it's raised. At that moment,

Re: __user with scalar data types

On Mon, Jun 19, 2017 at 09:46:37PM +0100, Al Viro wrote: > On Mon, Jun 19, 2017 at 10:32:18PM +0200, Luc Van Oostenryck wrote: > > On Mon, Jun 19, 2017 at 10:15:09AM -0600, Jordan Crouse wrote: > > > struct uapistruct { > > > ... > > > __u64 __user myptr; > > > --- > > > }; > > > > > > And

Re: __user with scalar data types

On Mon, Jun 19, 2017 at 09:46:37PM +0100, Al Viro wrote: > On Mon, Jun 19, 2017 at 10:32:18PM +0200, Luc Van Oostenryck wrote: > > On Mon, Jun 19, 2017 at 10:15:09AM -0600, Jordan Crouse wrote: > > > struct uapistruct { > > > ... > > > __u64 __user myptr; > > > --- > > > }; > > > > > > And

Re: [PATCH v3 1/2] PCI: iproc: Retry request when CRS returned from EP

On Tue, Jun 13, 2017 at 09:58:22AM +0530, Oza Oza wrote: > On Tue, Jun 13, 2017 at 5:00 AM, Bjorn Helgaas wrote: > > Please wrap your changelogs to use 75 columns. "git log" indents the > > changelog by four spaces, so if your text is 75 wide, it will still > > fit without

Re: [PATCH v3 1/2] PCI: iproc: Retry request when CRS returned from EP

On Tue, Jun 13, 2017 at 09:58:22AM +0530, Oza Oza wrote: > On Tue, Jun 13, 2017 at 5:00 AM, Bjorn Helgaas wrote: > > Please wrap your changelogs to use 75 columns. "git log" indents the > > changelog by four spaces, so if your text is 75 wide, it will still > > fit without wrapping. > > > > On

Re: [PATCH 0/7] CONFIG_FORTIFY_SOURCE

On Mon, 19 Jun 2017 15:12:22 -0700 Kees Cook wrote: > >> This was in my for-next/kspp tree, but since it depends on fixes in other > >> trees, the preference is for these to all get carried in -mm instead of > >> in KSPP. > > > > All the patches you sent are already in

Re: [PATCH 0/7] CONFIG_FORTIFY_SOURCE

On Mon, 19 Jun 2017 15:12:22 -0700 Kees Cook wrote: > >> This was in my for-next/kspp tree, but since it depends on fixes in other > >> trees, the preference is for these to all get carried in -mm instead of > >> in KSPP. > > > > All the patches you sent are already in -next (from the kspp

Re: WMI and Kernel:User interface

On Tue, May 09, 2017 at 04:16:39PM -0700, Darren Hart wrote: > To address this, I have proposed [3] that exporting WMI be opt-in, only done > at > the request of and in collaboration with a vendor, with the kernel platform > driver given the opportunity to filter requests. This filtering would

Re: WMI and Kernel:User interface

On Tue, May 09, 2017 at 04:16:39PM -0700, Darren Hart wrote: > To address this, I have proposed [3] that exporting WMI be opt-in, only done > at > the request of and in collaboration with a vendor, with the kernel platform > driver given the opportunity to filter requests. This filtering would

Re: [RFC] regulator: Shared regulators (configured by bootloader)

On Fri, Jun 16, 2017 at 03:29:17PM +0530, Viresh Kumar wrote: > Yes, but there can be weird dependencies between different components that > want > to interact. For example a supply shared between LCD and I2C controller (Not > sure if such configurations are there in any of the hardware we

Re: [RFC] regulator: Shared regulators (configured by bootloader)

On Fri, Jun 16, 2017 at 03:29:17PM +0530, Viresh Kumar wrote: > Yes, but there can be weird dependencies between different components that > want > to interact. For example a supply shared between LCD and I2C controller (Not > sure if such configurations are there in any of the hardware we

Re: [PATCH] compiler, clang: Add always_inline attribute to inline

On 2017-06-19 14:42, David Rientjes wrote: On Mon, 19 Jun 2017, Sodagudi Prasad wrote: > > Commit abb2ea7dfd82 ("compiler, clang: suppress warning for unused > > static inline functions") re-defining the 'inline' macro but > > __attribute__((always_inline)) is missing. Some compilers may > >

Re: [PATCH] compiler, clang: Add always_inline attribute to inline

On 2017-06-19 14:42, David Rientjes wrote: On Mon, 19 Jun 2017, Sodagudi Prasad wrote: > > Commit abb2ea7dfd82 ("compiler, clang: suppress warning for unused > > static inline functions") re-defining the 'inline' macro but > > __attribute__((always_inline)) is missing. Some compilers may > >

Re: [RESEND PATCH v3] pci-sysfs: Make PCI bridge attribute visible in sysfs

On Thu, Jun 01, 2017 at 05:43:06PM +0800, Wong Vee Khee wrote: > From: vwong > > In this commit, we are exposing PCIe bridges attributes > such as secondary bus number, subordinate bus number, > max link speed and link width, current link speed and > link width to sysfs

Re: [RESEND PATCH v3] pci-sysfs: Make PCI bridge attribute visible in sysfs

On Thu, Jun 01, 2017 at 05:43:06PM +0800, Wong Vee Khee wrote: > From: vwong > > In this commit, we are exposing PCIe bridges attributes > such as secondary bus number, subordinate bus number, > max link speed and link width, current link speed and > link width to sysfs located in

[PATCH V6 2/2] powerpc/numa: Update CPU topology when VPHN enabled

powerpc/numa: Correct the currently broken capability to set the topology for shared CPUs in LPARs. At boot time for shared CPU lpars, the topology for each shared CPU is set to node zero, however, this is now updated correctly using the Virtual Processor Home Node (VPHN) capabilities

[PATCH V6 2/2] powerpc/numa: Update CPU topology when VPHN enabled

powerpc/numa: Correct the currently broken capability to set the topology for shared CPUs in LPARs. At boot time for shared CPU lpars, the topology for each shared CPU is set to node zero, however, this is now updated correctly using the Virtual Processor Home Node (VPHN) capabilities

Re: [PATCH 0/7] CONFIG_FORTIFY_SOURCE

On Mon, Jun 19, 2017 at 2:50 PM, Andrew Morton wrote: > On Mon, 19 Jun 2017 13:26:20 -0700 Kees Cook wrote: > >> Here are the outstanding fixes for CONFIG_FORTIFY_SOURCE, along with Daniel's >> v5 patch and a tweak from me to add

Re: [PATCH 0/7] CONFIG_FORTIFY_SOURCE

On Mon, Jun 19, 2017 at 2:50 PM, Andrew Morton wrote: > On Mon, 19 Jun 2017 13:26:20 -0700 Kees Cook wrote: > >> Here are the outstanding fixes for CONFIG_FORTIFY_SOURCE, along with Daniel's >> v5 patch and a tweak from me to add CONFIG_ARCH_HAS_FORTIFY_SOURCE to avoid >> failing the build on

[PATCH V6 1/2] powerpc/numa: Update CPU topology when VPHN enabled

powerpc/numa: Correct the currently broken capability to set the topology for shared CPUs in LPARs. At boot time for shared CPU lpars, the topology for each shared CPU is set to node zero, however, this is now updated correctly using the Virtual Processor Home Node (VPHN) capabilities

[PATCH V6 1/2] powerpc/numa: Update CPU topology when VPHN enabled

powerpc/numa: Correct the currently broken capability to set the topology for shared CPUs in LPARs. At boot time for shared CPU lpars, the topology for each shared CPU is set to node zero, however, this is now updated correctly using the Virtual Processor Home Node (VPHN) capabilities

Re: WMI and Kernel:User interface

On Tue, Jun 13, 2017 at 9:38 PM, Greg Kroah-Hartman wrote: > On Tue, Jun 13, 2017 at 10:07:19AM -0700, Darren Hart wrote: >> On Tue, Jun 13, 2017 at 06:52:47PM +0200, Greg Kroah-Hartman wrote: >> > > As a concrete example, Dell has specifically made the request that we

[PATCH V6 1/2] powerpc/hotplug: Ensure enough nodes avail for operations

powerpc/hotplug: On systems like PowerPC which allow 'hot-add' of CPU or memory resources, it may occur that the new resources are to be inserted into nodes that were not used for these resources at bootup. In the kernel, any node that is used must be defined and initialized at boot. In order to

Re: WMI and Kernel:User interface

On Tue, Jun 13, 2017 at 9:38 PM, Greg Kroah-Hartman wrote: > On Tue, Jun 13, 2017 at 10:07:19AM -0700, Darren Hart wrote: >> On Tue, Jun 13, 2017 at 06:52:47PM +0200, Greg Kroah-Hartman wrote: >> > > As a concrete example, Dell has specifically made the request that we >> > > work on a solution

[PATCH V6 1/2] powerpc/hotplug: Ensure enough nodes avail for operations

powerpc/hotplug: On systems like PowerPC which allow 'hot-add' of CPU or memory resources, it may occur that the new resources are to be inserted into nodes that were not used for these resources at bootup. In the kernel, any node that is used must be defined and initialized at boot. In order to

Re: [PATCH v3 2/4] [media] platform: Add Synopsys Designware HDMI RX Controller Driver

On 06/19/2017 11:33 AM, Jose Abreu wrote: > On 18-06-2017 19:04, Sylwester Nawrocki wrote: >> On 06/16/2017 06:38 PM, Jose Abreu wrote: >>> This is an initial submission for the Synopsys Designware HDMI RX >>> Controller Driver. This driver interacts with a phy driver so that >>> a communication

Re: [PATCH v3 2/4] [media] platform: Add Synopsys Designware HDMI RX Controller Driver

On 06/19/2017 11:33 AM, Jose Abreu wrote: > On 18-06-2017 19:04, Sylwester Nawrocki wrote: >> On 06/16/2017 06:38 PM, Jose Abreu wrote: >>> This is an initial submission for the Synopsys Designware HDMI RX >>> Controller Driver. This driver interacts with a phy driver so that >>> a communication

[PATCH 2/7] staging: max98927: Added controls for Envelope tracking

Signed-off-by: Ryan Lee --- sound/soc/codecs/max98927.c | 20 sound/soc/codecs/max98927.h | 4 2 files changed, 20 insertions(+), 4 deletions(-) diff --git a/sound/soc/codecs/max98927.c b/sound/soc/codecs/max98927.c index

[PATCH 2/7] staging: max98927: Added controls for Envelope tracking

Signed-off-by: Ryan Lee --- sound/soc/codecs/max98927.c | 20 sound/soc/codecs/max98927.h | 4 2 files changed, 20 insertions(+), 4 deletions(-) diff --git a/sound/soc/codecs/max98927.c b/sound/soc/codecs/max98927.c index 99d6e41..cdee3a3 100644 ---

[PATCH 4/7] staging: max98927: Added missing \n to end of dev_err messages

Signed-off-by: Ryan Lee --- sound/soc/codecs/max98927.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/soc/codecs/max98927.c b/sound/soc/codecs/max98927.c index 585b8d0..5e33956 100644 --- a/sound/soc/codecs/max98927.c +++

[PATCH 4/7] staging: max98927: Added missing \n to end of dev_err messages

Signed-off-by: Ryan Lee --- sound/soc/codecs/max98927.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/soc/codecs/max98927.c b/sound/soc/codecs/max98927.c index 585b8d0..5e33956 100644 --- a/sound/soc/codecs/max98927.c +++ b/sound/soc/codecs/max98927.c @@ -160,7

[PATCH V6 0/2] powerpc/dlpar: Correct display of hot-add/hot-remove CPUs and memory

On Power systems with shared configurations of CPUs and memory, there are some issues with association of additional CPUs and memory to nodes when hot-adding resources. These patches address some of those problems. powerpc/hotplug: On systems like PowerPC which allow 'hot-add' of CPU or memory

[PATCH V6 0/2] powerpc/dlpar: Correct display of hot-add/hot-remove CPUs and memory

On Power systems with shared configurations of CPUs and memory, there are some issues with association of additional CPUs and memory to nodes when hot-adding resources. These patches address some of those problems. powerpc/hotplug: On systems like PowerPC which allow 'hot-add' of CPU or memory

Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

On Mon, 2017-06-19 at 01:43 +, Zheng, Lv wrote: > > > > > If you implement it in such a way that GNOME settings daemon > > behaves weirdly, you'll get my revert > > request in the mail. Do. Not. Ever. Lie. > > First, I don't know what should be reverted... > I have 2 solutions here for

Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

On Mon, 2017-06-19 at 01:43 +, Zheng, Lv wrote: > > > > > If you implement it in such a way that GNOME settings daemon > > behaves weirdly, you'll get my revert > > request in the mail. Do. Not. Ever. Lie. > > First, I don't know what should be reverted... > I have 2 solutions here for

Re: [PATCH] usb: host: ehci: workaround PME bug on AMD EHCI controller

On Monday, June 19, 2017 02:32:57 PM Alan Stern wrote: > On Mon, 19 Jun 2017, Bjorn Helgaas wrote: > > > > > Have you tested it with system suspend? That is, if you suspend the > > > > whole computer, does plugging or unplugging a USB device cause the > > > > system to wake up? > > > > > > No,

[PATCH 6/7] staging: max98927: Modified chip default register values

Signed-off-by: Ryan Lee --- sound/soc/codecs/max98927.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/sound/soc/codecs/max98927.c b/sound/soc/codecs/max98927.c index 5e33956..36be29c 100644 --- a/sound/soc/codecs/max98927.c +++

Re: [PATCH] usb: host: ehci: workaround PME bug on AMD EHCI controller

On Monday, June 19, 2017 02:32:57 PM Alan Stern wrote: > On Mon, 19 Jun 2017, Bjorn Helgaas wrote: > > > > > Have you tested it with system suspend? That is, if you suspend the > > > > whole computer, does plugging or unplugging a USB device cause the > > > > system to wake up? > > > > > > No,

[PATCH 6/7] staging: max98927: Modified chip default register values

Signed-off-by: Ryan Lee --- sound/soc/codecs/max98927.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/sound/soc/codecs/max98927.c b/sound/soc/codecs/max98927.c index 5e33956..36be29c 100644 --- a/sound/soc/codecs/max98927.c +++ b/sound/soc/codecs/max98927.c @@

[PATCH 3/7] staging: max98927: Updated volatile register list

Signed-off-by: Ryan Lee --- sound/soc/codecs/max98927.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/sound/soc/codecs/max98927.c b/sound/soc/codecs/max98927.c index cdee3a3..585b8d0 100644 --- a/sound/soc/codecs/max98927.c +++

[PATCH 3/7] staging: max98927: Updated volatile register list

Signed-off-by: Ryan Lee --- sound/soc/codecs/max98927.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/sound/soc/codecs/max98927.c b/sound/soc/codecs/max98927.c index cdee3a3..585b8d0 100644 --- a/sound/soc/codecs/max98927.c +++ b/sound/soc/codecs/max98927.c @@ -586,6 +586,13 @@

[PATCH 7/7] staging: max98927: Added PM suspend and resume function

Signed-off-by: Ryan Lee --- sound/soc/codecs/max98927.c | 27 ++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/sound/soc/codecs/max98927.c b/sound/soc/codecs/max98927.c index 36be29c..b744578 100644 ---

[PATCH 7/7] staging: max98927: Added PM suspend and resume function

Signed-off-by: Ryan Lee --- sound/soc/codecs/max98927.c | 27 ++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/sound/soc/codecs/max98927.c b/sound/soc/codecs/max98927.c index 36be29c..b744578 100644 --- a/sound/soc/codecs/max98927.c +++

[PATCH 1/7] staging: max98927: Added TDM support

Signed-off-by: Ryan Lee --- sound/soc/codecs/max98927.c | 141 sound/soc/codecs/max98927.h | 6 +- 2 files changed, 120 insertions(+), 27 deletions(-) diff --git a/sound/soc/codecs/max98927.c

[PATCH 5/7] staging: max98927: Removed an obsolete variable

Signed-off-by: Ryan Lee --- sound/soc/codecs/max98927.h | 1 - 1 file changed, 1 deletion(-) diff --git a/sound/soc/codecs/max98927.h b/sound/soc/codecs/max98927.h index 3069a09..3551e7d 100644 --- a/sound/soc/codecs/max98927.h +++ b/sound/soc/codecs/max98927.h @@

[PATCH 1/7] staging: max98927: Added TDM support

Signed-off-by: Ryan Lee --- sound/soc/codecs/max98927.c | 141 sound/soc/codecs/max98927.h | 6 +- 2 files changed, 120 insertions(+), 27 deletions(-) diff --git a/sound/soc/codecs/max98927.c b/sound/soc/codecs/max98927.c index b5ee294..99d6e41

[PATCH 5/7] staging: max98927: Removed an obsolete variable

Signed-off-by: Ryan Lee --- sound/soc/codecs/max98927.h | 1 - 1 file changed, 1 deletion(-) diff --git a/sound/soc/codecs/max98927.h b/sound/soc/codecs/max98927.h index 3069a09..3551e7d 100644 --- a/sound/soc/codecs/max98927.h +++ b/sound/soc/codecs/max98927.h @@ -263,7 +263,6 @@ struct

Re: [PATCH v2 10/10] x86/mm: Try to preserve old TLB entries using PCID

On Sat, Jun 17, 2017 at 11:26 PM, Nadav Amit wrote: > >> On Jun 13, 2017, at 9:56 PM, Andy Lutomirski wrote: >> >> PCID is a "process context ID" -- it's what other architectures call >> an address space ID. Every non-global TLB entry is tagged with a >>

Re: [PATCH v2 10/10] x86/mm: Try to preserve old TLB entries using PCID

On Sat, Jun 17, 2017 at 11:26 PM, Nadav Amit wrote: > >> On Jun 13, 2017, at 9:56 PM, Andy Lutomirski wrote: >> >> PCID is a "process context ID" -- it's what other architectures call >> an address space ID. Every non-global TLB entry is tagged with a >> PCID, only TLB entries that match the

Re: [PATCH v5 0/8] Support for contiguous pte hugepages

On Mon, 19 Jun 2017 18:01:37 +0100 Punit Agrawal wrote: > This is v5 of the patchset to update the hugetlb code to support > contiguous hugepages. Previous version of the patchset can be found at > [0]. Dumb question: is there a handy description anywhere which describes

Re: [PATCH v5 0/8] Support for contiguous pte hugepages

On Mon, 19 Jun 2017 18:01:37 +0100 Punit Agrawal wrote: > This is v5 of the patchset to update the hugetlb code to support > contiguous hugepages. Previous version of the patchset can be found at > [0]. Dumb question: is there a handy description anywhere which describes how arm64 implements

Re: [PATCH V2] staging: unisys: visorhba - style fix

On Mon, Jun 19, 2017 at 03:28:19PM +, Kershner, David A wrote: > > > -Original Message- > > From: Derek Robson [mailto:robso...@gmail.com] > > Sent: Friday, June 16, 2017 11:13 PM > > To: Kershner, David A ; > > gre...@linuxfoundation.org; Sell, Timothy C

[PATCH v2 1/3] platform: x86: intel-vbtn: Wake up the system from suspend-to-idle

From: Rafael J. Wysocki Allow the intel-vbtn driver to wake up the system from suspend-to-idle by configuring its platform device as a wakeup one by default and switching it over to a system wakeup events triggering mode during system suspend transitions.

Re: [PATCH V2] staging: unisys: visorhba - style fix

On Mon, Jun 19, 2017 at 03:28:19PM +, Kershner, David A wrote: > > > -Original Message- > > From: Derek Robson [mailto:robso...@gmail.com] > > Sent: Friday, June 16, 2017 11:13 PM > > To: Kershner, David A ; > > gre...@linuxfoundation.org; Sell, Timothy C ; > > Binder, David Anthony ;

[PATCH v2 1/3] platform: x86: intel-vbtn: Wake up the system from suspend-to-idle

From: Rafael J. Wysocki Allow the intel-vbtn driver to wake up the system from suspend-to-idle by configuring its platform device as a wakeup one by default and switching it over to a system wakeup events triggering mode during system suspend transitions. Signed-off-by: Rafael J. Wysocki

[PATCH v2 0/3] ACPI / sleep: Support power button wakeup from S2I on recent Dell laptops

Hi All, On Thursday, June 01, 2017 01:23:43 AM Rafael J. Wysocki wrote: > > This is a follow-up for a patch series posted some time ago: > > http://marc.info/?l=linux-kernel=149324246701378=2 > > The first two patches from that series are in 4.12-rc already and the rest > have been rearranged.

[PATCH v2 0/3] ACPI / sleep: Support power button wakeup from S2I on recent Dell laptops

Hi All, On Thursday, June 01, 2017 01:23:43 AM Rafael J. Wysocki wrote: > > This is a follow-up for a patch series posted some time ago: > > http://marc.info/?l=linux-kernel=149324246701378=2 > > The first two patches from that series are in 4.12-rc already and the rest > have been rearranged.

Re: [PATCH v2 05/10] x86/mm: Rework lazy TLB mode and TLB freshness tracking

On Tue, Jun 13, 2017 at 11:09 PM, Juergen Gross wrote: > On 14/06/17 06:56, Andy Lutomirski wrote: >> x86's lazy TLB mode used to be fairly weak -- it would switch to >> init_mm the first time it tried to flush a lazy TLB. This meant an >> unnecessary CR3 write and, if the flush

Re: [PATCH v2 05/10] x86/mm: Rework lazy TLB mode and TLB freshness tracking

On Tue, Jun 13, 2017 at 11:09 PM, Juergen Gross wrote: > On 14/06/17 06:56, Andy Lutomirski wrote: >> x86's lazy TLB mode used to be fairly weak -- it would switch to >> init_mm the first time it tried to flush a lazy TLB. This meant an >> unnecessary CR3 write and, if the flush was remote, an

[PATCH v2 3/3] ACPI / sleep: EC-based wakeup from suspend-to-idle on recent Dell systems

From: Rafael J. Wysocki Some recent Dell laptops, including the XPS13 model numbers 9360 and 9365, cannot be woken up from suspend-to-idle by pressing the power button which is unexpected and makes that feature less usable on those systems. Moreover, on the 9365 ACPI

[PATCH v2 2/3] platform: x86: intel-hid: Wake up the system from suspend-to-idle

From: Rafael J. Wysocki Allow the intel-hid driver to wake up the system from suspend-to-idle by configuring its platform device as a wakeup one by default and switching it over to a system wakeup events triggering mode during system suspend transitions.

[PATCH v2 3/3] ACPI / sleep: EC-based wakeup from suspend-to-idle on recent Dell systems

From: Rafael J. Wysocki Some recent Dell laptops, including the XPS13 model numbers 9360 and 9365, cannot be woken up from suspend-to-idle by pressing the power button which is unexpected and makes that feature less usable on those systems. Moreover, on the 9365 ACPI S3 (suspend-to-RAM) is not

[PATCH v2 2/3] platform: x86: intel-hid: Wake up the system from suspend-to-idle

From: Rafael J. Wysocki Allow the intel-hid driver to wake up the system from suspend-to-idle by configuring its platform device as a wakeup one by default and switching it over to a system wakeup events triggering mode during system suspend transitions. Signed-off-by: Rafael J. Wysocki

Re: [PATCH v2 05/10] x86/mm: Rework lazy TLB mode and TLB freshness tracking

On Sun, Jun 18, 2017 at 1:06 AM, Nadav Amit wrote: > >> On Jun 13, 2017, at 9:56 PM, Andy Lutomirski wrote: >> >> x86's lazy TLB mode used to be fairly weak -- it would switch to >> init_mm the first time it tried to flush a lazy TLB. This meant an >>

Re: [PATCH v2 05/10] x86/mm: Rework lazy TLB mode and TLB freshness tracking

On Sun, Jun 18, 2017 at 1:06 AM, Nadav Amit wrote: > >> On Jun 13, 2017, at 9:56 PM, Andy Lutomirski wrote: >> >> x86's lazy TLB mode used to be fairly weak -- it would switch to >> init_mm the first time it tried to flush a lazy TLB. This meant an >> unnecessary CR3 write and, if the flush was

Re: [PATCHv2 1/3] x86/mm: Provide pmdp_establish() helper

On Mon, Jun 19, 2017 at 10:11:35AM -0700, Nadav Amit wrote: > Kirill A. Shutemov wrote: > > > We need an atomic way to setup pmd page table entry, avoiding races with > > CPU setting dirty/accessed bits. This is required to implement > > pmdp_invalidate() that

Re: [PATCHv2 1/3] x86/mm: Provide pmdp_establish() helper

On Mon, Jun 19, 2017 at 10:11:35AM -0700, Nadav Amit wrote: > Kirill A. Shutemov wrote: > > > We need an atomic way to setup pmd page table entry, avoiding races with > > CPU setting dirty/accessed bits. This is required to implement > > pmdp_invalidate() that doesn't loose these bits. > > > >

Re: [PATCH NET] net/hns:bugfix of ethtool -t phy self_test

On Mon, Jun 19, 2017 at 02:00:43PM -0700, Florian Fainelli wrote: > On 06/16/2017 02:24 AM, Lin Yun Sheng wrote: > > This patch fixes the phy loopback self_test failed issue. when > > Marvell Phy Module is loaded, it will powerdown fiber when doing > > phy loopback self test, which cause phy

Re: [PATCH NET] net/hns:bugfix of ethtool -t phy self_test

On Mon, Jun 19, 2017 at 02:00:43PM -0700, Florian Fainelli wrote: > On 06/16/2017 02:24 AM, Lin Yun Sheng wrote: > > This patch fixes the phy loopback self_test failed issue. when > > Marvell Phy Module is loaded, it will powerdown fiber when doing > > phy loopback self test, which cause phy

Re: [PATCH] PCI/MSI: Improve MSI alias detection

[+cc David, Alex] On Wed, May 31, 2017 at 06:52:28PM +0100, Robin Murphy wrote: > Currently, we consider all DMA aliases when calculating MSI requester > IDs. This turns out to be the wrong thing to do in the face of pure DMA > quirks like those of Marvell SATA cards, where we can end up

Re: From: Nitin Gupta <nitin.m.gu...@oracle.com>

Please ignore this patch series. I will resend again with correct email headers. Nitin On 6/19/17 2:48 PM, Nitin Gupta wrote: Adds support for 16GB hugepage size. To use this page size use kernel parameters as: default_hugepagesz=16G hugepagesz=16G hugepages=10 Testing: Tested with the

Re: [PATCHv2 1/3] x86/mm: Provide pmdp_establish() helper

On Mon, Jun 19, 2017 at 06:09:12PM +0100, Catalin Marinas wrote: > On Mon, Jun 19, 2017 at 07:00:05PM +0300, Kirill A. Shutemov wrote: > > On Mon, Jun 19, 2017 at 04:22:29PM +0100, Catalin Marinas wrote: > > > On Thu, Jun 15, 2017 at 05:52:22PM +0300, Kirill A. Shutemov wrote: > > > > We need an

Re: [PATCH] PCI/MSI: Improve MSI alias detection

[+cc David, Alex] On Wed, May 31, 2017 at 06:52:28PM +0100, Robin Murphy wrote: > Currently, we consider all DMA aliases when calculating MSI requester > IDs. This turns out to be the wrong thing to do in the face of pure DMA > quirks like those of Marvell SATA cards, where we can end up

Re: From: Nitin Gupta

Please ignore this patch series. I will resend again with correct email headers. Nitin On 6/19/17 2:48 PM, Nitin Gupta wrote: Adds support for 16GB hugepage size. To use this page size use kernel parameters as: default_hugepagesz=16G hugepagesz=16G hugepages=10 Testing: Tested with the

Re: [PATCHv2 1/3] x86/mm: Provide pmdp_establish() helper

On Mon, Jun 19, 2017 at 06:09:12PM +0100, Catalin Marinas wrote: > On Mon, Jun 19, 2017 at 07:00:05PM +0300, Kirill A. Shutemov wrote: > > On Mon, Jun 19, 2017 at 04:22:29PM +0100, Catalin Marinas wrote: > > > On Thu, Jun 15, 2017 at 05:52:22PM +0300, Kirill A. Shutemov wrote: > > > > We need an

Re: [PATCH 0/7] CONFIG_FORTIFY_SOURCE

On Mon, 19 Jun 2017 13:26:20 -0700 Kees Cook wrote: > Here are the outstanding fixes for CONFIG_FORTIFY_SOURCE, along with Daniel's > v5 patch and a tweak from me to add CONFIG_ARCH_HAS_FORTIFY_SOURCE to avoid > failing the build on architectures that have not hunted down

Re: [PATCH 0/7] CONFIG_FORTIFY_SOURCE

On Mon, 19 Jun 2017 13:26:20 -0700 Kees Cook wrote: > Here are the outstanding fixes for CONFIG_FORTIFY_SOURCE, along with Daniel's > v5 patch and a tweak from me to add CONFIG_ARCH_HAS_FORTIFY_SOURCE to avoid > failing the build on architectures that have not hunted down all the needed > fixes

[PATCH v2 3/4] sparc64: Fix gup_huge_pmd

The function assumes that each PMD points to head of a huge page. This is not correct as a PMD can point to start of any 8M region with a, say 256M, hugepage. The fix ensures that it points to the correct head of any PMD huge page. Signed-off-by: Nitin Gupta ---

[PATCH v2 3/4] sparc64: Fix gup_huge_pmd

The function assumes that each PMD points to head of a huge page. This is not correct as a PMD can point to start of any 8M region with a, say 256M, hugepage. The fix ensures that it points to the correct head of any PMD huge page. Signed-off-by: Nitin Gupta --- arch/sparc/mm/gup.c | 2 ++ 1

From: Nitin Gupta <nitin.m.gu...@oracle.com>

Adds support for 16GB hugepage size. To use this page size use kernel parameters as: default_hugepagesz=16G hugepagesz=16G hugepages=10 Testing: Tested with the stream benchmark which allocates 48G of arrays backed by 16G hugepages and does RW operation on them in parallel. Orabug: 25362942

From: Nitin Gupta

Adds support for 16GB hugepage size. To use this page size use kernel parameters as: default_hugepagesz=16G hugepagesz=16G hugepages=10 Testing: Tested with the stream benchmark which allocates 48G of arrays backed by 16G hugepages and does RW operation on them in parallel. Orabug: 25362942

[PATCH v2 4/4] sparc64: Cleanup hugepage table walk functions

Flatten out nested code structure in huge_pte_offset() and huge_pte_alloc(). Signed-off-by: Nitin Gupta --- arch/sparc/mm/hugetlbpage.c | 54 + 1 file changed, 20 insertions(+), 34 deletions(-) diff --git

[PATCH v2 4/4] sparc64: Cleanup hugepage table walk functions

Flatten out nested code structure in huge_pte_offset() and huge_pte_alloc(). Signed-off-by: Nitin Gupta --- arch/sparc/mm/hugetlbpage.c | 54 + 1 file changed, 20 insertions(+), 34 deletions(-) diff --git a/arch/sparc/mm/hugetlbpage.c

[PATCH v2 2/4] sparc64: Support huge PUD case in get_user_pages

get_user_pages() is used to do direct IO. It already handles the case where the address range is backed by PMD huge pages. This patch now adds the case where the range could be backed by PUD huge pages. Signed-off-by: Nitin Gupta --- arch/sparc/include/asm/pgtable_64.h

[PATCH v2 2/4] sparc64: Support huge PUD case in get_user_pages

get_user_pages() is used to do direct IO. It already handles the case where the address range is backed by PMD huge pages. This patch now adds the case where the range could be backed by PUD huge pages. Signed-off-by: Nitin Gupta --- arch/sparc/include/asm/pgtable_64.h | 15 ++--

Re: [PATCH v2 3/4] KVM: async_pf: Force a nested vmexit if the injected #PF is async_pf

2017-06-19 22:51 GMT+08:00 Radim Krčmář : > 2017-06-17 13:52+0800, Wanpeng Li: >> 2017-06-16 23:38 GMT+08:00 Radim Krčmář : >> > 2017-06-16 22:24+0800, Wanpeng Li: >> >> 2017-06-16 21:37 GMT+08:00 Radim Krčmář : >> >> > 2017-06-14

Re: [PATCH v2 3/4] KVM: async_pf: Force a nested vmexit if the injected #PF is async_pf

2017-06-19 22:51 GMT+08:00 Radim Krčmář : > 2017-06-17 13:52+0800, Wanpeng Li: >> 2017-06-16 23:38 GMT+08:00 Radim Krčmář : >> > 2017-06-16 22:24+0800, Wanpeng Li: >> >> 2017-06-16 21:37 GMT+08:00 Radim Krčmář : >> >> > 2017-06-14 19:26-0700, Wanpeng Li: >> >> >> From: Wanpeng Li >> >> >> >> >>

[PATCH 1/6] ACPI / PM: Drop run_wake from struct acpi_device_wakeup_flags

From: Rafael J. Wysocki The run_wake flag in struct acpi_device_wakeup_flags stores the information on whether or not the device can generate wakeup signals at run time, but in ACPI that really is equivalent to being able to generate wakeup signals at all. In fact,

[PATCH 1/6] ACPI / PM: Drop run_wake from struct acpi_device_wakeup_flags

From: Rafael J. Wysocki The run_wake flag in struct acpi_device_wakeup_flags stores the information on whether or not the device can generate wakeup signals at run time, but in ACPI that really is equivalent to being able to generate wakeup signals at all. In fact, run_wake will always be set

[PATCH 0/6] PM: Unify the handling of device wakeup settings

Hi All, The handling of device wakeup settings, especially in the ACPI core and the PCI bus type, depends on whether it is about system wakeup from sleep states or remote wakeup in the working state (runtime). However, that distinction is mostly based on the ACPI concept of "wakeup" and

[PATCH 0/6] PM: Unify the handling of device wakeup settings

Hi All, The handling of device wakeup settings, especially in the ACPI core and the PCI bus type, depends on whether it is about system wakeup from sleep states or remote wakeup in the working state (runtime). However, that distinction is mostly based on the ACPI concept of "wakeup" and

[PATCH 5/6] PCI / ACPI / PM: Avoid disabling wakeup for bridges too early

From: Rafael J. Wysocki If acpi_pci_propagate_wakeup() is used, it may trigger wakeup configuration twice for the same bridge indirectly, when configuring wakeup for two different PCI devices under that bridge. Actually, however, the ACPI wakeup code can only be

[PATCH 6/6] PM / core: Drop run_wake flag from struct dev_pm_info

From: Rafael J. Wysocki The run_wake flag in struct dev_pm_info is used to indicate whether or not the device is capable of generating remote wakeup signals at run time (or in the system working state), but the distinction between runtime remote wakeup and system

[PATCH 5/6] PCI / ACPI / PM: Avoid disabling wakeup for bridges too early

From: Rafael J. Wysocki If acpi_pci_propagate_wakeup() is used, it may trigger wakeup configuration twice for the same bridge indirectly, when configuring wakeup for two different PCI devices under that bridge. Actually, however, the ACPI wakeup code can only be enabled to trigger wakeup

[PATCH 6/6] PM / core: Drop run_wake flag from struct dev_pm_info

From: Rafael J. Wysocki The run_wake flag in struct dev_pm_info is used to indicate whether or not the device is capable of generating remote wakeup signals at run time (or in the system working state), but the distinction between runtime remote wakeup and system wakeup signaling has always been

[PATCH 3/6] PCI / PM: Drop pme_interrupt flag from struct pci_dev

From: Rafael J. Wysocki The pme_interrupt flag in struct pci_dev is set when PMEs generated by the device are going to be signaled via root port PME interrupts. Ironically enough, that information is only used by the code setting up device wakeup through ACPI which

[PATCH 4/6] PCI / PM: Simplify device wakeup settings code

From: Rafael J. Wysocki After previous changes it is not necessary to distinguish between device wakeup for run time and device wakeup from system sleep states any more, so rework the PCI device wakeup settings code accordingly. Signed-off-by: Rafael J. Wysocki

[PATCH 2/6] ACPI / PM: Consolidate device wakeup settings code

From: Rafael J. Wysocki Currently, there are two separate ways of handling device wakeup settings in the ACPI core, depending on whether this is runtime wakeup or system wakeup (from sleep states). However, after the previous commit eliminating the run_wake ACPI

[PATCH 3/6] PCI / PM: Drop pme_interrupt flag from struct pci_dev

From: Rafael J. Wysocki The pme_interrupt flag in struct pci_dev is set when PMEs generated by the device are going to be signaled via root port PME interrupts. Ironically enough, that information is only used by the code setting up device wakeup through ACPI which returns as soon as it sees

<    2   3   4   5   6   7   8   9   10   11   >