Re: [PATCH v5 01/10] arm64: allwinner: a64: enable RSB on A64

在 2017-04-27 21:28，Maxime Ripard 写道： On Wed, Apr 26, 2017 at 11:20:14PM +0800, Icenowy Zheng wrote: Allwinner A64 have a RSB controller like the one on A23/A33 SoCs. Add it and its pinmux. Signed-off-by: Icenowy Zheng Acked-by: Chen-Yu Tsai --- Changes in v2:

Re: [PATCH v5 01/10] arm64: allwinner: a64: enable RSB on A64

在 2017-04-27 21:28，Maxime Ripard 写道： On Wed, Apr 26, 2017 at 11:20:14PM +0800, Icenowy Zheng wrote: Allwinner A64 have a RSB controller like the one on A23/A33 SoCs. Add it and its pinmux. Signed-off-by: Icenowy Zheng Acked-by: Chen-Yu Tsai --- Changes in v2: - Removed bonus properties in

Re: [PATCH] iio:ad5064: Add support for ltc2633 and similar devices

On 27-04-17 11:16, Lars-Peter Clausen wrote: On 04/27/2017 07:52 AM, Jonathan Cameron wrote: On 26/04/17 10:44, Mike Looijmans wrote: The Linear Technology LTC2631, LTC2633 and LTC2635 are very similar to the AD5064 device, in particular the LTC2627. This patch adds support for those

Re: [PATCH v2 3/3] arm64: Silence first allocation with CONFIG_ARM64_MODULE_PLTS=y

> On 27 Apr 2017, at 19:09, Florian Fainelli wrote: > >> On 04/27/2017 11:07 AM, Ard Biesheuvel wrote: >> >>> On 27 Apr 2017, at 18:39, Florian Fainelli wrote: >>> >>> When CONFIG_ARM64_MODULE_PLTS is enabled, the first allocation using the >>>

Re: [PATCH] iio:ad5064: Add support for ltc2633 and similar devices

On 27-04-17 11:16, Lars-Peter Clausen wrote: On 04/27/2017 07:52 AM, Jonathan Cameron wrote: On 26/04/17 10:44, Mike Looijmans wrote: The Linear Technology LTC2631, LTC2633 and LTC2635 are very similar to the AD5064 device, in particular the LTC2627. This patch adds support for those

Re: [PATCH v2 3/3] arm64: Silence first allocation with CONFIG_ARM64_MODULE_PLTS=y

> On 27 Apr 2017, at 19:09, Florian Fainelli wrote: > >> On 04/27/2017 11:07 AM, Ard Biesheuvel wrote: >> >>> On 27 Apr 2017, at 18:39, Florian Fainelli wrote: >>> >>> When CONFIG_ARM64_MODULE_PLTS is enabled, the first allocation using the >>> module space fails, because the module is too

Re: [PATCH 1/2] iommu/s390: Fix IOMMU groups

On Thu, 27 Apr 2017 17:28:24 +0200 Joerg Roedel wrote: > From: Joerg Roedel > > Currently the s390 iommu driver allocates an iommu-group for > every device that is added. But that is wrong, as there is > only one dma-table per pci-root-bus. Make all devices

Re: [PATCH 1/2] iommu/s390: Fix IOMMU groups

On Thu, 27 Apr 2017 17:28:24 +0200 Joerg Roedel wrote: > From: Joerg Roedel > > Currently the s390 iommu driver allocates an iommu-group for > every device that is added. But that is wrong, as there is > only one dma-table per pci-root-bus. Make all devices behind > one dma-table share one

Re: [PATCH v17 2/3] usb: USB Type-C connector class

On Thu, Apr 27, 2017 at 11:50:12AM +0530, Rajaram R wrote: > On Tue, Apr 25, 2017 at 7:40 PM, Guenter Roeck wrote: > > On 04/25/2017 01:26 AM, Rajaram R wrote: > >> > >> On Mon, Apr 24, 2017 at 11:20 PM, Badhri Jagan Sridharan > >> wrote: > >>> > >>> On

Re: [PATCH v17 2/3] usb: USB Type-C connector class

On Thu, Apr 27, 2017 at 11:50:12AM +0530, Rajaram R wrote: > On Tue, Apr 25, 2017 at 7:40 PM, Guenter Roeck wrote: > > On 04/25/2017 01:26 AM, Rajaram R wrote: > >> > >> On Mon, Apr 24, 2017 at 11:20 PM, Badhri Jagan Sridharan > >> wrote: > >>> > >>> On Sat, Apr 22, 2017 at 2:23 AM, Rajaram R >

Re: [RFC PATCH 0/2] iommu/s390: Fix iommu-groups and add sysfs support

On Thu, 27 Apr 2017 17:28:23 +0200 Joerg Roedel wrote: > Hey, > > here are two patches for the s390 PCI and IOMMU code. It is > based on the assumption that every pci_dev that points to > the same zpci_dev shares a single dma-table (and thus a > single address space). Well,

Re: [RFC PATCH 0/2] iommu/s390: Fix iommu-groups and add sysfs support

On Thu, 27 Apr 2017 17:28:23 +0200 Joerg Roedel wrote: > Hey, > > here are two patches for the s390 PCI and IOMMU code. It is > based on the assumption that every pci_dev that points to > the same zpci_dev shares a single dma-table (and thus a > single address space). Well, there is a separate

Re: [PATCH v2 3/3] arm64: Silence first allocation with CONFIG_ARM64_MODULE_PLTS=y

On 04/27/2017 11:07 AM, Ard Biesheuvel wrote: > >> On 27 Apr 2017, at 18:39, Florian Fainelli wrote: >> >> When CONFIG_ARM64_MODULE_PLTS is enabled, the first allocation using the >> module space fails, because the module is too big, and then the module >> allocation is

Re: [PATCH v2 3/3] arm64: Silence first allocation with CONFIG_ARM64_MODULE_PLTS=y

On 04/27/2017 11:07 AM, Ard Biesheuvel wrote: > >> On 27 Apr 2017, at 18:39, Florian Fainelli wrote: >> >> When CONFIG_ARM64_MODULE_PLTS is enabled, the first allocation using the >> module space fails, because the module is too big, and then the module >> allocation is attempted from vmalloc

Re: [PATCH RESEND v2] f2fs: release cp and dnode lock before IPU

Hi Chao, On 04/27, Chao Yu wrote: > From: Hou Pengyang > > We don't need to rewrite the page under cp_rwsem and dnode locks. > > Signed-off-by: Hou Pengyang > Signed-off-by: Chao Yu > Signed-off-by: Jaegeuk Kim

Re: [PATCH RESEND v2] f2fs: release cp and dnode lock before IPU

Hi Chao, On 04/27, Chao Yu wrote: > From: Hou Pengyang > > We don't need to rewrite the page under cp_rwsem and dnode locks. > > Signed-off-by: Hou Pengyang > Signed-off-by: Chao Yu > Signed-off-by: Jaegeuk Kim > --- > fs/f2fs/data.c| 39 --- >

Re: [PATCH v2 3/3] arm64: Silence first allocation with CONFIG_ARM64_MODULE_PLTS=y

> On 27 Apr 2017, at 18:39, Florian Fainelli wrote: > > When CONFIG_ARM64_MODULE_PLTS is enabled, the first allocation using the > module space fails, because the module is too big, and then the module > allocation is attempted from vmalloc space. Silence the first

Re: [PATCH v2 3/3] arm64: Silence first allocation with CONFIG_ARM64_MODULE_PLTS=y

> On 27 Apr 2017, at 18:39, Florian Fainelli wrote: > > When CONFIG_ARM64_MODULE_PLTS is enabled, the first allocation using the > module space fails, because the module is too big, and then the module > allocation is attempted from vmalloc space. Silence the first allocation > failure in that

Re: [PATCH v2 1/3] mm: Silence vmap() allocation failures based on caller gfp_flags

On 04/27/2017 10:56 AM, Michal Hocko wrote: > On Thu 27-04-17 10:38:58, Florian Fainelli wrote: >> If the caller has set __GFP_NOWARN don't print the following message: >> vmap allocation for size 15736832 failed: use vmalloc= to increase >> size. >> >> This can happen with the ARM/Linux or

Re: [PATCH v2 1/3] mm: Silence vmap() allocation failures based on caller gfp_flags

On 04/27/2017 10:56 AM, Michal Hocko wrote: > On Thu 27-04-17 10:38:58, Florian Fainelli wrote: >> If the caller has set __GFP_NOWARN don't print the following message: >> vmap allocation for size 15736832 failed: use vmalloc= to increase >> size. >> >> This can happen with the ARM/Linux or

Re: [PATCHv2 2/2] arm64: cpufeature: use static_branch_enable_cpuslocked()

On Thu, Apr 27, 2017 at 06:44:37PM +0100, Mark Rutland wrote: > Recently, the hotplug locking was conveted to use a percpu rwsem. Unlike > the existing {get,put}_online_cpus() logic, this can't nest. > Unfortunately, in arm64's secondary boot path we can end up nesting via > static_branch_enable()

Re: [PATCHv2 2/2] arm64: cpufeature: use static_branch_enable_cpuslocked()

On Thu, Apr 27, 2017 at 06:44:37PM +0100, Mark Rutland wrote: > Recently, the hotplug locking was conveted to use a percpu rwsem. Unlike > the existing {get,put}_online_cpus() logic, this can't nest. > Unfortunately, in arm64's secondary boot path we can end up nesting via > static_branch_enable()

[PATCH] igb: make a few local functions static

From: Colin Ian King clean up a few sparse warnings, these following functions can be made static: drivers/net/ethernet/intel/igb/igb_main.c: warning: symbol 'igb_add_mac_filter' was not declared. Should it be static? drivers/net/ethernet/intel/igb/igb_main.c:

[PATCH] igb: make a few local functions static

From: Colin Ian King clean up a few sparse warnings, these following functions can be made static: drivers/net/ethernet/intel/igb/igb_main.c: warning: symbol 'igb_add_mac_filter' was not declared. Should it be static? drivers/net/ethernet/intel/igb/igb_main.c: warning: symbol

Re: [PATCH v2 1/3] mm: Silence vmap() allocation failures based on caller gfp_flags

On Thu 27-04-17 10:38:58, Florian Fainelli wrote: > If the caller has set __GFP_NOWARN don't print the following message: > vmap allocation for size 15736832 failed: use vmalloc= to increase > size. > > This can happen with the ARM/Linux or ARM64/Linux module loader built > with

Re: [PATCH v2 1/3] mm: Silence vmap() allocation failures based on caller gfp_flags

On Thu 27-04-17 10:38:58, Florian Fainelli wrote: > If the caller has set __GFP_NOWARN don't print the following message: > vmap allocation for size 15736832 failed: use vmalloc= to increase > size. > > This can happen with the ARM/Linux or ARM64/Linux module loader built > with

[PATCHv2 2/2] arm64: cpufeature: use static_branch_enable_cpuslocked()

Recently, the hotplug locking was conveted to use a percpu rwsem. Unlike the existing {get,put}_online_cpus() logic, this can't nest. Unfortunately, in arm64's secondary boot path we can end up nesting via static_branch_enable() in cpus_set_cap() when we detect an erratum. This leads to a stream

[PATCHv2 1/2] jump_label: Provide static_key_[enable|/slow_inc]_cpuslocked()

From: Sebastian Andrzej Siewior Provide static_key_[enable|slow_inc]_cpuslocked() variant that don't take cpu_hotplug_lock(). Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Mark Rutland Cc: Peter Zijlstra

[PATCHv2 1/2] jump_label: Provide static_key_[enable|/slow_inc]_cpuslocked()

From: Sebastian Andrzej Siewior Provide static_key_[enable|slow_inc]_cpuslocked() variant that don't take cpu_hotplug_lock(). Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Mark Rutland Cc: Peter Zijlstra Cc: Sebastian Siewior Cc: Steven Rostedt Cc: jba...@akamai.com ---

[PATCHv2 2/2] arm64: cpufeature: use static_branch_enable_cpuslocked()

Recently, the hotplug locking was conveted to use a percpu rwsem. Unlike the existing {get,put}_online_cpus() logic, this can't nest. Unfortunately, in arm64's secondary boot path we can end up nesting via static_branch_enable() in cpus_set_cap() when we detect an erratum. This leads to a stream

[PATCHv2 0/2] arm64: fix hotplug rwsem boot fallout

Hi, These patches address a boot failure on arm64 observed when booting a kernel built with the hotplug rwsem changes currently queued in the tip smp/hotplug branch. I've given these a spin on Juno R1, which now boots happily. FWIW, I also did a test-merge with the arm64 for-next/core branch,

[PATCHv2 0/2] arm64: fix hotplug rwsem boot fallout

Hi, These patches address a boot failure on arm64 observed when booting a kernel built with the hotplug rwsem changes currently queued in the tip smp/hotplug branch. I've given these a spin on Juno R1, which now boots happily. FWIW, I also did a test-merge with the arm64 for-next/core branch,

Re: [PATCH 0/5] KEYS: sanitize key payloads

On Thu, Apr 27, 2017 at 04:09:42PM +0100, David Howells wrote: > Do you have a git branch I can pull from? > > David No I don't, sorry. - Eric

Re: [PATCH 0/5] KEYS: sanitize key payloads

On Thu, Apr 27, 2017 at 04:09:42PM +0100, David Howells wrote: > Do you have a git branch I can pull from? > > David No I don't, sorry. - Eric

Re: [PATCH 1/2] thermal: broadcom: Allow for NSP to use ns-thermal driver

On Thu, Apr 27, 2017 at 12:37 PM, Eduardo Valentin wrote: > Hey Jason, It's Jon :) > > On Tue, Apr 25, 2017 at 04:49:10PM -0400, Jon Mason wrote: >> Change the iProc Kconfig to select THERMAL and THERMAL_OF, which allows >> the ns-thermal driver to be selected via

Re: [PATCH 1/2] thermal: broadcom: Allow for NSP to use ns-thermal driver

On Thu, Apr 27, 2017 at 12:37 PM, Eduardo Valentin wrote: > Hey Jason, It's Jon :) > > On Tue, Apr 25, 2017 at 04:49:10PM -0400, Jon Mason wrote: >> Change the iProc Kconfig to select THERMAL and THERMAL_OF, which allows >> the ns-thermal driver to be selected via menuconfig. Also, change the

Re: [PATCH v8 1/3] backlight arcxcnn add arc to vendor prefix

On Thursday, April 27, 2017 8:37 AM, Geert Uytterhoeven wrote: > On Tue, Apr 25, 2017 at 6:36 PM, Jingoo Han wrote: > > On Monday, April 24, 2017 1:56 PM, Olimpiu Dejeu wrote: > >> > >> On Mon, April 24, 2017 11:10 AM, Rob Herring < r...@kernel.org> wrote: > >> > >> > On

Re: [PATCH v8 1/3] backlight arcxcnn add arc to vendor prefix

On Thursday, April 27, 2017 8:37 AM, Geert Uytterhoeven wrote: > On Tue, Apr 25, 2017 at 6:36 PM, Jingoo Han wrote: > > On Monday, April 24, 2017 1:56 PM, Olimpiu Dejeu wrote: > >> > >> On Mon, April 24, 2017 11:10 AM, Rob Herring < r...@kernel.org> wrote: > >> > >> > On Wed, Mar 15, 2017 at 2:45

[PATCH] goldfish_pipe: make pipe_dev static

From: Colin Ian King Make this static as it's only referenced in this source and it does not need global scope. Cleans up a sparse warning: drivers/platform/goldfish/goldfish_pipe.c: warning: symbol 'pipe_dev' was not declared. Should it be static? Signed-off-by:

[PATCH] goldfish_pipe: make pipe_dev static

From: Colin Ian King Make this static as it's only referenced in this source and it does not need global scope. Cleans up a sparse warning: drivers/platform/goldfish/goldfish_pipe.c: warning: symbol 'pipe_dev' was not declared. Should it be static? Signed-off-by: Colin Ian King ---

[PATCH v2 1/3] mm: Silence vmap() allocation failures based on caller gfp_flags

If the caller has set __GFP_NOWARN don't print the following message: vmap allocation for size 15736832 failed: use vmalloc= to increase size. This can happen with the ARM/Linux or ARM64/Linux module loader built with CONFIG_ARM{,64}_MODULE_PLTS=y which does a first attempt at loading a large

[PATCH v2 1/3] mm: Silence vmap() allocation failures based on caller gfp_flags

If the caller has set __GFP_NOWARN don't print the following message: vmap allocation for size 15736832 failed: use vmalloc= to increase size. This can happen with the ARM/Linux or ARM64/Linux module loader built with CONFIG_ARM{,64}_MODULE_PLTS=y which does a first attempt at loading a large

[PATCH v2 2/3] ARM: Silence first allocation with CONFIG_ARM_MODULE_PLTS=y

When CONFIG_ARM_MODULE_PLTS is enabled, the first allocation using the module space fails, because the module is too big, and then the module allocation is attempted from vmalloc space. Silence the first allocation failure in that case by setting __GFP_NOWARN. Signed-off-by: Florian Fainelli

[PATCH v2 3/3] arm64: Silence first allocation with CONFIG_ARM64_MODULE_PLTS=y

When CONFIG_ARM64_MODULE_PLTS is enabled, the first allocation using the module space fails, because the module is too big, and then the module allocation is attempted from vmalloc space. Silence the first allocation failure in that case by setting __GFP_NOWARN. Signed-off-by: Florian Fainelli

[PATCH v2 2/3] ARM: Silence first allocation with CONFIG_ARM_MODULE_PLTS=y

When CONFIG_ARM_MODULE_PLTS is enabled, the first allocation using the module space fails, because the module is too big, and then the module allocation is attempted from vmalloc space. Silence the first allocation failure in that case by setting __GFP_NOWARN. Signed-off-by: Florian Fainelli ---

[PATCH v2 3/3] arm64: Silence first allocation with CONFIG_ARM64_MODULE_PLTS=y

When CONFIG_ARM64_MODULE_PLTS is enabled, the first allocation using the module space fails, because the module is too big, and then the module allocation is attempted from vmalloc space. Silence the first allocation failure in that case by setting __GFP_NOWARN. Signed-off-by: Florian Fainelli

Re: iov_iter_pipe warning.

On Thu, Apr 27, 2017 at 12:34:44PM -0400, Dave Jones wrote: > [977286.117268] RPC request reserved 116 but used 268 > [1918138.126285] RPC request reserved 200 but used 268 > [232.483077] RPC request reserved 200 but used 268 > [2327800.909007] RPC request reserved 200 but used 268 > >

Re: iov_iter_pipe warning.

On Thu, Apr 27, 2017 at 12:34:44PM -0400, Dave Jones wrote: > [977286.117268] RPC request reserved 116 but used 268 > [1918138.126285] RPC request reserved 200 but used 268 > [232.483077] RPC request reserved 200 but used 268 > [2327800.909007] RPC request reserved 200 but used 268 > >

[PATCH 0/3 v2] ARM/ARM64: silence large module first time allocation

With kernels built with CONFIG_ARM{,64}_MODULES_PLTS=y, the first allocation done from module space will fail, produce a general OOM allocation and also a vmap warning. The second allocation from vmalloc space may or may not be successful, but is actually the one we are interested about in these

[PATCH 0/3 v2] ARM/ARM64: silence large module first time allocation

With kernels built with CONFIG_ARM{,64}_MODULES_PLTS=y, the first allocation done from module space will fail, produce a general OOM allocation and also a vmap warning. The second allocation from vmalloc space may or may not be successful, but is actually the one we are interested about in these

Re: [PATCH v2] arm64: perf: Use only exclude_kernel attribute when kernel is running in HYP

On Wed, Apr 26, 2017 at 01:41:42PM +, Jayachandran C wrote: > On Wed, Apr 26, 2017 at 11:10:21AM +0100, Will Deacon wrote: > > On Wed, Apr 26, 2017 at 07:22:46AM +, Pinski, Andrew wrote: > > > On 4/25/2017 11:53 PM, Jayachandran C. wrote: > > > > On Tue, Apr 25, 2017 at 10:23 PM, Will

Re: [PATCH v2] arm64: perf: Use only exclude_kernel attribute when kernel is running in HYP

On Wed, Apr 26, 2017 at 01:41:42PM +, Jayachandran C wrote: > On Wed, Apr 26, 2017 at 11:10:21AM +0100, Will Deacon wrote: > > On Wed, Apr 26, 2017 at 07:22:46AM +, Pinski, Andrew wrote: > > > On 4/25/2017 11:53 PM, Jayachandran C. wrote: > > > > On Tue, Apr 25, 2017 at 10:23 PM, Will

Re: [PATCH 2/2] arm64: pmu: Wire-up L2 cache events for ARMv8 PMUv3

On Tue, Apr 25, 2017 at 10:13:51AM -0700, Florian Fainelli wrote: > On 04/25/2017 05:44 AM, Will Deacon wrote: > > Hi Florian, > > > > On Thu, Apr 20, 2017 at 12:05:46PM -0700, Florian Fainelli wrote: > >> The ARMv8 PMUv3 cache map did not include the L2 cache events, add > >> them. > >> > >>

Re: [PATCH 2/2] arm64: pmu: Wire-up L2 cache events for ARMv8 PMUv3

On Tue, Apr 25, 2017 at 10:13:51AM -0700, Florian Fainelli wrote: > On 04/25/2017 05:44 AM, Will Deacon wrote: > > Hi Florian, > > > > On Thu, Apr 20, 2017 at 12:05:46PM -0700, Florian Fainelli wrote: > >> The ARMv8 PMUv3 cache map did not include the L2 cache events, add > >> them. > >> > >>

Re: [trace-cmd Patch RFC] trace-cmd: top: A new interface to detect peak memory

On Thursday 27 April 2017 10:19 PM, Steven Rostedt wrote: On Thu, 27 Apr 2017 19:32:43 +0530 Pratyush Anand wrote: I will implement your review comments and will send next revision. However, I had couple of observation which I was unable to justify: # ./trace-cmd top -s

Re: [trace-cmd Patch RFC] trace-cmd: top: A new interface to detect peak memory

On Thursday 27 April 2017 10:19 PM, Steven Rostedt wrote: On Thu, 27 Apr 2017 19:32:43 +0530 Pratyush Anand wrote: I will implement your review comments and will send next revision. However, I had couple of observation which I was unable to justify: # ./trace-cmd top -s /tmp/test #

Re: [PATCH 1/2] drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.

Eric Anholt writes: > Many DRM drivers have common code to make a stub connector > implementation that wraps a drm_panel. By wrapping the panel in a DRM > bridge, all of the connector code (including calls during encoder > enable/disable) goes away. > > Signed-off-by: Eric

Re: [PATCH 1/2] drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.

Eric Anholt writes: > Many DRM drivers have common code to make a stub connector > implementation that wraps a drm_panel. By wrapping the panel in a DRM > bridge, all of the connector code (including calls during encoder > enable/disable) goes away. > > Signed-off-by: Eric Anholt > +/** > + *

Re: [PATCH man-pages 2/2] ioctl_userfaultfd.2: start adding details about userfaultfd features

On 04/27/2017 04:14 PM, Mike Rapoport wrote: > Signed-off-by: Mike Rapoport Thanks, Mike. Applied, and lightly edited. All changes now pushed to Git. Cheers, Michael > --- > man2/ioctl_userfaultfd.2 | 53 > ++-- > 1 file

Re: [PATCH man-pages 2/2] ioctl_userfaultfd.2: start adding details about userfaultfd features

On 04/27/2017 04:14 PM, Mike Rapoport wrote: > Signed-off-by: Mike Rapoport Thanks, Mike. Applied, and lightly edited. All changes now pushed to Git. Cheers, Michael > --- > man2/ioctl_userfaultfd.2 | 53 > ++-- > 1 file changed, 51

Re: [PATCH man-pages 1/2] userfaultfd.2: start documenting non-cooperative events

Hi Mike, I've applied this, but have some questions/points I think further clarification. On 04/27/2017 04:14 PM, Mike Rapoport wrote: > Signed-off-by: Mike Rapoport > --- > man2/userfaultfd.2 | 135 > ++--- > 1 file

Re: [PATCH man-pages 1/2] userfaultfd.2: start documenting non-cooperative events

Hi Mike, I've applied this, but have some questions/points I think further clarification. On 04/27/2017 04:14 PM, Mike Rapoport wrote: > Signed-off-by: Mike Rapoport > --- > man2/userfaultfd.2 | 135 > ++--- > 1 file changed, 128 insertions(+),

Re: [PATCH] perf evsel: Fix to perf-stat malloc corruption on arm64 platforms

On Thu, Apr 27, 2017 at 9:22 PM, Mark Rutland wrote: > On Thu, Apr 27, 2017 at 09:16:41PM +0530, Ganapatrao Kulkarni wrote: >> > Could you please give my diff a go? >> >> i tried your diff, and testing looks ok. > > Can I take that as a Tested-by when I post this as a proper

Re: [PATCH] perf evsel: Fix to perf-stat malloc corruption on arm64 platforms

On Thu, Apr 27, 2017 at 9:22 PM, Mark Rutland wrote: > On Thu, Apr 27, 2017 at 09:16:41PM +0530, Ganapatrao Kulkarni wrote: >> > Could you please give my diff a go? >> >> i tried your diff, and testing looks ok. > > Can I take that as a Tested-by when I post this as a proper patch? sure. > >>

Re: [PATCH v3] NFC: trf7970a: Correct register settings for 27MHz clock

On Thu, Apr 27, 2017 at 10:41:59AM -0400, Geoff Lansberry wrote: > In prior commits the selected clock frequency does not propagate > correctly to what is written the the TRF7970A_MODULATOR_SYS_CLK_CTRL ^^^ s/the the/to the/ > register. > > Signed-off-by: Geoff

Re: [PATCH v3] NFC: trf7970a: Correct register settings for 27MHz clock

On Thu, Apr 27, 2017 at 10:41:59AM -0400, Geoff Lansberry wrote: > In prior commits the selected clock frequency does not propagate > correctly to what is written the the TRF7970A_MODULATOR_SYS_CLK_CTRL ^^^ s/the the/to the/ > register. > > Signed-off-by: Geoff

Re: [PATCH] arm64: cpufeature: use static_branch_enable_cpuslocked()

On Thu, Apr 27, 2017 at 06:03:35PM +0100, Suzuki K Poulose wrote: > On 27/04/17 17:35, Suzuki K Poulose wrote: > >@@ -1092,7 +1093,9 @@ void check_local_cpu_capabilities(void) > > > > static void __init setup_feature_capabilities(void) > > { > >-update_cpu_capabilities(arm64_features,

Re: [PATCH] arm64: cpufeature: use static_branch_enable_cpuslocked()

On Thu, Apr 27, 2017 at 06:03:35PM +0100, Suzuki K Poulose wrote: > On 27/04/17 17:35, Suzuki K Poulose wrote: > >@@ -1092,7 +1093,9 @@ void check_local_cpu_capabilities(void) > > > > static void __init setup_feature_capabilities(void) > > { > >-update_cpu_capabilities(arm64_features,

Re: [PATCH] usb: musb: musb_host: Introduce postponed URB giveback

On Thu, Apr 27, 2017 at 07:26:31PM +0300, Matwey V. Kornilov wrote: > 2017-04-27 18:35 GMT+03:00 Bin Liu : > > Hi Matwey, > > > > On Thu, Apr 27, 2017 at 01:20:33PM +0300, Matwey V. Kornilov wrote: > >> This commit changes the order of actions undertaken in > >>

Re: [PATCH] usb: musb: musb_host: Introduce postponed URB giveback

On Thu, Apr 27, 2017 at 07:26:31PM +0300, Matwey V. Kornilov wrote: > 2017-04-27 18:35 GMT+03:00 Bin Liu : > > Hi Matwey, > > > > On Thu, Apr 27, 2017 at 01:20:33PM +0300, Matwey V. Kornilov wrote: > >> This commit changes the order of actions undertaken in > >> musb_advance_schedule() in order to

Re: [PATCH 2/3] selinux: add checksum to policydb

2017-04-27 17:18 GMT+02:00 Stephen Smalley : > Ok, that should work as long as you just want to validate that all the > clients loaded the same policy file, and aren't concerned about non- > persistent policy boolean changes. As far as I understand, non-persistent policy

Re: [PATCH 2/3] selinux: add checksum to policydb

2017-04-27 17:18 GMT+02:00 Stephen Smalley : > Ok, that should work as long as you just want to validate that all the > clients loaded the same policy file, and aren't concerned about non- > persistent policy boolean changes. As far as I understand, non-persistent policy boolean changes can

[PATCH] EDAC,amd64: Fix reporting of Chip Select sizes on Fam17h

From: Yazen Ghannam The wrong value is being passed to our function to compute CS sizes which results in the wrong size being computed. Redo the printing function so that the correct values are computed and printed. Also, redo how we calculate the number of pages in a CS

[PATCH] EDAC,amd64: Fix reporting of Chip Select sizes on Fam17h

From: Yazen Ghannam The wrong value is being passed to our function to compute CS sizes which results in the wrong size being computed. Redo the printing function so that the correct values are computed and printed. Also, redo how we calculate the number of pages in a CS row. Tested on AMD

Re: [PATCH] Introduce v3 namespaced file capabilities

"Serge E. Hallyn" writes: > Quoting Eric W. Biederman (ebied...@xmission.com): >> ebied...@xmission.com (Eric W. Biederman) writes: >> >> > "Serge E. Hallyn" writes: >> > >> >> Quoting Eric W. Biederman (ebied...@xmission.com): >> >>> >> >>> "Serge E.

Re: [PATCH] Introduce v3 namespaced file capabilities

"Serge E. Hallyn" writes: > Quoting Eric W. Biederman (ebied...@xmission.com): >> ebied...@xmission.com (Eric W. Biederman) writes: >> >> > "Serge E. Hallyn" writes: >> > >> >> Quoting Eric W. Biederman (ebied...@xmission.com): >> >>> >> >>> "Serge E. Hallyn" writes: >> >>> >> >>> > diff

Re: [PATCH] Prevent timer value 0 for MWAITX

On 4/25/2017 4:44 PM, Janakarajan Natarajan wrote: This patch prevents the value 0 from being used for the MWAITX timer. Newer hardware has uncovered a bug in the software implementation of using MWAITX for the delay function. A value of 0 for the timer is meant to indicate that a timeout will

Re: [PATCH] Prevent timer value 0 for MWAITX

On 4/25/2017 4:44 PM, Janakarajan Natarajan wrote: This patch prevents the value 0 from being used for the MWAITX timer. Newer hardware has uncovered a bug in the software implementation of using MWAITX for the delay function. A value of 0 for the timer is meant to indicate that a timeout will

Re: [PATCH] arm64: cpufeature: use static_branch_enable_cpuslocked()

On 27/04/17 17:35, Suzuki K Poulose wrote: rom f3b0809224e4915197d3ae4a38ebe7f210e74abf Mon Sep 17 00:00:00 2001 From: Mark Rutland Date: Thu, 27 Apr 2017 16:48:06 +0100 Subject: [PATCH] arm64: cpufeature: use static_branch_enable_cpuslocked() Build break alert. There

Re: [PATCH] arm64: cpufeature: use static_branch_enable_cpuslocked()

On 27/04/17 17:35, Suzuki K Poulose wrote: rom f3b0809224e4915197d3ae4a38ebe7f210e74abf Mon Sep 17 00:00:00 2001 From: Mark Rutland Date: Thu, 27 Apr 2017 16:48:06 +0100 Subject: [PATCH] arm64: cpufeature: use static_branch_enable_cpuslocked() Build break alert. There are some issues with

Re: [PATCH 2/3] iommu/arm-smmu-v3: Add workaround for Cavium ThunderX2 erratum #74

On Thu, Apr 27, 2017 at 05:42:37PM +0100, Mark Rutland wrote: > On Thu, Apr 27, 2017 at 05:16:23PM +0530, Geetha sowjanya wrote: > > + /* > > +* Override the size, for Cavium CN99xx implementations > > +* which doesn't support the page 1 SMMU register space. > > +*/ > > + cpu_model

Re: [PATCH 2/3] iommu/arm-smmu-v3: Add workaround for Cavium ThunderX2 erratum #74

On Thu, Apr 27, 2017 at 05:42:37PM +0100, Mark Rutland wrote: > On Thu, Apr 27, 2017 at 05:16:23PM +0530, Geetha sowjanya wrote: > > + /* > > +* Override the size, for Cavium CN99xx implementations > > +* which doesn't support the page 1 SMMU register space. > > +*/ > > + cpu_model

Re: [PATCH v3] libnvdimm, region: sysfs trigger for nvdimm_flush()

On Thu, Apr 27, 2017 at 6:45 AM, Jeff Moyer wrote: > Dan Williams writes: > >> On Wed, Apr 26, 2017 at 1:38 PM, Jeff Moyer wrote: >>> Dan Williams writes: >>> The nvdimm_flush() mechanism helps to

Re: [PATCH v3] libnvdimm, region: sysfs trigger for nvdimm_flush()

On Thu, Apr 27, 2017 at 6:45 AM, Jeff Moyer wrote: > Dan Williams writes: > >> On Wed, Apr 26, 2017 at 1:38 PM, Jeff Moyer wrote: >>> Dan Williams writes: >>> The nvdimm_flush() mechanism helps to reduce the impact of an ADR (asynchronous-dimm-refresh) failure. The ADR mechanism

Re: [PATCH] Introduce v3 namespaced file capabilities

Quoting Eric W. Biederman (ebied...@xmission.com): > ebied...@xmission.com (Eric W. Biederman) writes: > > > "Serge E. Hallyn" writes: > > > >> Quoting Eric W. Biederman (ebied...@xmission.com): > >>> > >>> "Serge E. Hallyn" writes: > >>> > >>> > diff --git

Re: [PATCH] Introduce v3 namespaced file capabilities

Quoting Eric W. Biederman (ebied...@xmission.com): > ebied...@xmission.com (Eric W. Biederman) writes: > > > "Serge E. Hallyn" writes: > > > >> Quoting Eric W. Biederman (ebied...@xmission.com): > >>> > >>> "Serge E. Hallyn" writes: > >>> > >>> > diff --git a/fs/xattr.c b/fs/xattr.c > >>> >

Re: [PATCH 1/7] hwmon: twl4030-madc: drop driver

On Thu, Apr 27, 2017 at 05:30:06PM +0200, Sebastian Reichel wrote: > This driver is no longer needed: > > * It has no mainline users > * It has no DT support and OMAP is DT only > * iio-hwmon can be used for madc, which also works with DT > > Signed-off-by: Sebastian Reichel

Re: [PATCH 1/7] hwmon: twl4030-madc: drop driver

On Thu, Apr 27, 2017 at 05:30:06PM +0200, Sebastian Reichel wrote: > This driver is no longer needed: > > * It has no mainline users > * It has no DT support and OMAP is DT only > * iio-hwmon can be used for madc, which also works with DT > > Signed-off-by: Sebastian Reichel Acked-by:

Re: [PATCH 5/7] IB/hfi1: use pcie_flr instead of duplicating it

On Thu, Apr 27, 2017 at 08:47:58AM +0200, Christoph Hellwig wrote: > On Tue, Apr 25, 2017 at 02:39:55PM -0500, Bjorn Helgaas wrote: > > This still leaves these: > > > > [PATCH 4/7] ixgbe: use pcie_flr instead of duplicating it > > [PATCH 6/7] crypto: qat: use pcie_flr instead of duplicating

Re: [PATCH 5/7] IB/hfi1: use pcie_flr instead of duplicating it

On Thu, Apr 27, 2017 at 08:47:58AM +0200, Christoph Hellwig wrote: > On Tue, Apr 25, 2017 at 02:39:55PM -0500, Bjorn Helgaas wrote: > > This still leaves these: > > > > [PATCH 4/7] ixgbe: use pcie_flr instead of duplicating it > > [PATCH 6/7] crypto: qat: use pcie_flr instead of duplicating

Re: [trace-cmd Patch RFC] trace-cmd: top: A new interface to detect peak memory

On Thu, 27 Apr 2017 19:32:43 +0530 Pratyush Anand wrote: > I will implement your review comments and will send next revision. > However, I had couple of observation which I was unable to justify: > > # ./trace-cmd top -s /tmp/test > # ./trace-cmd top -p /tmp/test | grep

Re: [trace-cmd Patch RFC] trace-cmd: top: A new interface to detect peak memory

On Thu, 27 Apr 2017 19:32:43 +0530 Pratyush Anand wrote: > I will implement your review comments and will send next revision. > However, I had couple of observation which I was unable to justify: > > # ./trace-cmd top -s /tmp/test > # ./trace-cmd top -p /tmp/test | grep trace-cmd >15292

Re: [PATCH -mm -v3] mm, swap: Sort swap entries before free

On Thu, 2017-04-27 at 09:21 +0800, Huang, Ying wrote: > Tim Chen writes: > > > > > > > > > > > > From 7bd903c42749c448ef6acbbdee8dcbc1c5b498b9 Mon Sep 17 00:00:00 2001 > > > From: Huang Ying > > > Date: Thu, 23 Feb 2017 13:05:20 +0800 > > >

Re: [PATCH -mm -v3] mm, swap: Sort swap entries before free

On Thu, 2017-04-27 at 09:21 +0800, Huang, Ying wrote: > Tim Chen writes: > > > > > > > > > > > > From 7bd903c42749c448ef6acbbdee8dcbc1c5b498b9 Mon Sep 17 00:00:00 2001 > > > From: Huang Ying > > > Date: Thu, 23 Feb 2017 13:05:20 +0800 > > > Subject: [PATCH -v5] mm, swap: Sort swap entries

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

On Thu, Apr 27, 2017 at 9:45 AM, Logan Gunthorpe wrote: > > > On 27/04/17 10:38 AM, Dan Williams wrote: >> ...is inside a for_each_device_pfn() loop. >> > > Ah, oops. Then that makes perfect sense. Thanks. > > You may have my review tag if you'd like: > > Reviewed-by: Logan

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

On Thu, Apr 27, 2017 at 9:45 AM, Logan Gunthorpe wrote: > > > On 27/04/17 10:38 AM, Dan Williams wrote: >> ...is inside a for_each_device_pfn() loop. >> > > Ah, oops. Then that makes perfect sense. Thanks. > > You may have my review tag if you'd like: > > Reviewed-by: Logan Gunthorpe Thanks!

Re: xen_exit_mmap() questions

On Thu, Apr 27, 2017 at 6:21 AM, Boris Ostrovsky wrote: > > >> Also, this code in drop_other_mm_ref() looks dubious to me: >> >> /* If this cpu still has a stale cr3 reference, then make sure >>it has been flushed. */ >> if

Re: xen_exit_mmap() questions

On Thu, Apr 27, 2017 at 6:21 AM, Boris Ostrovsky wrote: > > >> Also, this code in drop_other_mm_ref() looks dubious to me: >> >> /* If this cpu still has a stale cr3 reference, then make sure >>it has been flushed. */ >> if (this_cpu_read(xen_current_cr3)

Re: [PATCH 2/2] pid_ns: Introduce ioctl to set vector of ns_last_pid's on ns hierarhy

Kirill Tkhai writes: > On 27.04.2017 19:12, Oleg Nesterov wrote: >> On 04/26, Kirill Tkhai wrote: >>> >>> On 26.04.2017 18:53, Oleg Nesterov wrote: > +static long set_last_pid_vec(struct pid_namespace *pid_ns, > + struct pidns_ioc_req *req)

Re: [PATCH 2/2] pid_ns: Introduce ioctl to set vector of ns_last_pid's on ns hierarhy

Kirill Tkhai writes: > On 27.04.2017 19:12, Oleg Nesterov wrote: >> On 04/26, Kirill Tkhai wrote: >>> >>> On 26.04.2017 18:53, Oleg Nesterov wrote: > +static long set_last_pid_vec(struct pid_namespace *pid_ns, > + struct pidns_ioc_req *req) > +{ > + char

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