Re: [PATCH] staging, android: remove lowmemory killer from the tree

On Fri 24-02-17 15:42:49, peter enderborg wrote: > On 02/24/2017 03:11 PM, Michal Hocko wrote: > > On Fri 24-02-17 14:16:34, peter enderborg wrote: > >> On 02/24/2017 01:28 PM, Michal Hocko wrote: > > [...] > >>> Yeah, I strongly believe that the chosen approach is completely wrong. > >>> Both in

Re: [PATCH] staging, android: remove lowmemory killer from the tree

On Fri 24-02-17 15:42:49, peter enderborg wrote: > On 02/24/2017 03:11 PM, Michal Hocko wrote: > > On Fri 24-02-17 14:16:34, peter enderborg wrote: > >> On 02/24/2017 01:28 PM, Michal Hocko wrote: > > [...] > >>> Yeah, I strongly believe that the chosen approach is completely wrong. > >>> Both in

Re: [PATCH v4 01/17] x86/mpx: Do not use SIB index if index points to R/ESP

On Thu, Feb 23, 2017 at 9:33 PM, Joe Perches wrote: > On Thu, 2017-02-23 at 14:17 -0800, Ricardo Neri wrote: >> On Thu, 2017-02-23 at 08:24 +0100, Peter Zijlstra wrote: >> > On Wed, Feb 22, 2017 at 10:36:50PM -0800, Ricardo Neri wrote: >> > > + /* >> > > +

Re: [PATCH v4 01/17] x86/mpx: Do not use SIB index if index points to R/ESP

On Thu, Feb 23, 2017 at 9:33 PM, Joe Perches wrote: > On Thu, 2017-02-23 at 14:17 -0800, Ricardo Neri wrote: >> On Thu, 2017-02-23 at 08:24 +0100, Peter Zijlstra wrote: >> > On Wed, Feb 22, 2017 at 10:36:50PM -0800, Ricardo Neri wrote: >> > > + /* >> > > + * A

Re: [PATCH 2/2] selftests, x86, pkeys: test with random, unallocated protection keys

On 02/24/2017 12:45 AM, Ingo Molnar wrote: > > * Shuah Khan wrote: > >> On 02/23/2017 03:26 PM, Dave Hansen wrote: >>> Shuah, I assume you'll take this patch in through the selftests tree. >> >> Yes I can do that. > > No, let's not do that please, we have a fix and a

Re: [PATCH 2/2] selftests, x86, pkeys: test with random, unallocated protection keys

On 02/24/2017 12:45 AM, Ingo Molnar wrote: > > * Shuah Khan wrote: > >> On 02/23/2017 03:26 PM, Dave Hansen wrote: >>> Shuah, I assume you'll take this patch in through the selftests tree. >> >> Yes I can do that. > > No, let's not do that please, we have a fix and a self-tests update, I'd

Re: [PATCH v4 18/24] scripts/checkstack.pl: Add openrisc support

On 2017-02-24 at 05:32:38 +0100, Stafford Horne wrote: > Openrisc stack pointer is managed by decrementing r1. Add regexes to > recognize this. > > Signed-off-by: Stafford Horne > --- > scripts/checkstack.pl | 3 +++ > 1 file changed, 3 insertions(+) > >

Re: [PATCH v4 18/24] scripts/checkstack.pl: Add openrisc support

On 2017-02-24 at 05:32:38 +0100, Stafford Horne wrote: > Openrisc stack pointer is managed by decrementing r1. Add regexes to > recognize this. > > Signed-off-by: Stafford Horne > --- > scripts/checkstack.pl | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/scripts/checkstack.pl

[PATCH v3 1/2] iio: Allow triggers to be used as parent of others triggers

Add "parent_trigger" sysfs attribute to iio trigger to be able to set a parent to the current trigger. Parent trigger edges or levels could be used to control current trigger status for example to start, stop or reset it. Introduce validate_trigger function in iio_trigger_ops which does the same

[PATCH v3 2/2] iio: stm32 trigger: Implement parent trigger feature

Add validate_trigger function in iio_trigger_ops and dev_attr_parent_trigger into trigger attribute group to be able to accept triggers as parents. Introduce an IIO device with one IIO_COUNT channel to get access to counter value. Counter directions can be set/get when writing/reading

[PATCH v3 1/2] iio: Allow triggers to be used as parent of others triggers

Add "parent_trigger" sysfs attribute to iio trigger to be able to set a parent to the current trigger. Parent trigger edges or levels could be used to control current trigger status for example to start, stop or reset it. Introduce validate_trigger function in iio_trigger_ops which does the same

[PATCH v3 2/2] iio: stm32 trigger: Implement parent trigger feature

Add validate_trigger function in iio_trigger_ops and dev_attr_parent_trigger into trigger attribute group to be able to accept triggers as parents. Introduce an IIO device with one IIO_COUNT channel to get access to counter value. Counter directions can be set/get when writing/reading

[PATCH v3 0/2] Add parent_trigger attribute to triggers

version 3: - try to provide better description of parent_trigger usages - add one channel to get counter raw value version 2: - Do not automatically set parent_trigger attribute on all triggers. Let driver decide to use it. - Improve documentation of parent_trigger - Improve slave modes

[PATCH v3 0/2] Add parent_trigger attribute to triggers

version 3: - try to provide better description of parent_trigger usages - add one channel to get counter raw value version 2: - Do not automatically set parent_trigger attribute on all triggers. Let driver decide to use it. - Improve documentation of parent_trigger - Improve slave modes

Re: [PATCH 4.4 00/25] 4.4.52-stable review

On Fri, Feb 24, 2017 at 01:55:31PM +, Ben Hutchings wrote: > On Fri, 2017-02-24 at 09:25 +0100, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.4.52 release. > > There are 25 patches in this series, all will be posted as a response > > to this one.  If

Re: [PATCH 4.4 00/25] 4.4.52-stable review

On Fri, Feb 24, 2017 at 01:55:31PM +, Ben Hutchings wrote: > On Fri, 2017-02-24 at 09:25 +0100, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.4.52 release. > > There are 25 patches in this series, all will be posted as a response > > to this one.  If

[PATCH] scsi: aacraid: remove redundant zero check on ret

From: Colin Ian King The check for ret being zero is redundant as a few statements earlier we break out of the while loop if ret is non-zero. Thus we can remove the zero check and also the dead-code non-zero case too. Detected by CoverityScan, CID#1411632 ("Logically

[PATCH] scsi: aacraid: remove redundant zero check on ret

From: Colin Ian King The check for ret being zero is redundant as a few statements earlier we break out of the while loop if ret is non-zero. Thus we can remove the zero check and also the dead-code non-zero case too. Detected by CoverityScan, CID#1411632 ("Logically Dead Code")

Re: [PATCH] staging, android: remove lowmemory killer from the tree

On 02/24/2017 03:11 PM, Michal Hocko wrote: > On Fri 24-02-17 14:16:34, peter enderborg wrote: >> On 02/24/2017 01:28 PM, Michal Hocko wrote: > [...] >>> Yeah, I strongly believe that the chosen approach is completely wrong. >>> Both in abusing the shrinker interface and abusing oom_score_adj as

Re: [PATCH] staging, android: remove lowmemory killer from the tree

On 02/24/2017 03:11 PM, Michal Hocko wrote: > On Fri 24-02-17 14:16:34, peter enderborg wrote: >> On 02/24/2017 01:28 PM, Michal Hocko wrote: > [...] >>> Yeah, I strongly believe that the chosen approach is completely wrong. >>> Both in abusing the shrinker interface and abusing oom_score_adj as

Re: + uapi-fix-linux-sysctlh-userspace-compilation-errors.patch added to -mm tree

On Thu, Feb 23, 2017 at 02:44:31PM -0800, a...@linux-foundation.org wrote: > /usr/include/linux/sysctl.h:38:2: error: unknown type name 'size_t' > size_t *oldlenp; > /usr/include/linux/sysctl.h:40:2: error: unknown type name 'size_t' > size_t newlen; > --- >

Re: + uapi-fix-linux-sysctlh-userspace-compilation-errors.patch added to -mm tree

On Thu, Feb 23, 2017 at 02:44:31PM -0800, a...@linux-foundation.org wrote: > /usr/include/linux/sysctl.h:38:2: error: unknown type name 'size_t' > size_t *oldlenp; > /usr/include/linux/sysctl.h:40:2: error: unknown type name 'size_t' > size_t newlen; > --- >

Re: [PATCH] scsi_lib: Fix priority order when generating LUN ID

On Tue, Jan 24, 2017 at 10:58 AM, Sylvain Munaut wrote: > Previously the order described in the comment wasn't the actual > order that was considered. And the result also depended on the orders > of the various ID in the pg83 data. > > Signed-off-by: Sylvain Munaut

Re: [PATCH] scsi_lib: Fix priority order when generating LUN ID

On Tue, Jan 24, 2017 at 10:58 AM, Sylvain Munaut wrote: > Previously the order described in the comment wasn't the actual > order that was considered. And the result also depended on the orders > of the various ID in the pg83 data. > > Signed-off-by: Sylvain Munaut > --- >

Re: [PATCH v3 4/4] iio: accel: adxl345: Add SPI support

On Fri, Feb 24, 2017 at 01:48:39PM +0200, Andy Shevchenko wrote: > On Fri, Feb 24, 2017 at 11:22 AM, Lars-Peter Clausen wrote: > > On 02/24/2017 10:12 AM, Eva Rachel Retuya wrote: > >> On Thu, Feb 23, 2017 at 06:58:12PM +0200, Andy Shevchenko wrote: > >>> On Thu, Feb 23, 2017 at

Re: [PATCH v3 4/4] iio: accel: adxl345: Add SPI support

On Fri, Feb 24, 2017 at 01:48:39PM +0200, Andy Shevchenko wrote: > On Fri, Feb 24, 2017 at 11:22 AM, Lars-Peter Clausen wrote: > > On 02/24/2017 10:12 AM, Eva Rachel Retuya wrote: > >> On Thu, Feb 23, 2017 at 06:58:12PM +0200, Andy Shevchenko wrote: > >>> On Thu, Feb 23, 2017 at 6:47 PM,

[PATCH] scsi: lpfc: fix missing spin_unlock on sql_list_lock

From: Colin Ian King In the case where sglq is null, the current code just returns without unlocking the spinlock sql_list_lock. Fix this by breaking out of the while loop and the exit path will then unlock and return NULL as was the original intention. Detected by

[PATCH] scsi: lpfc: fix missing spin_unlock on sql_list_lock

From: Colin Ian King In the case where sglq is null, the current code just returns without unlocking the spinlock sql_list_lock. Fix this by breaking out of the while loop and the exit path will then unlock and return NULL as was the original intention. Detected by CoverityScan, CID#1411635

Re: [PATCH 1/4] fs, afs: convert afs_cell.usage from atomic_t to refcount_t

Kees Cook wrote: > We can't allow the increment from 0 since it violates the intended > use-after-free protections. I would have thought that the protections would've been against the carry flag getting set. > If "0" means "still valid" then this > sounds like it needs a

Re: [PATCH 1/4] fs, afs: convert afs_cell.usage from atomic_t to refcount_t

Kees Cook wrote: > We can't allow the increment from 0 since it violates the intended > use-after-free protections. I would have thought that the protections would've been against the carry flag getting set. > If "0" means "still valid" then this > sounds like it needs a global +1, as Elena

[PATCH v2 2/2] crypto: vmx - Use skcipher for xts fallback

Signed-off-by: Paulo Flabiano Smorigo --- drivers/crypto/vmx/aes_xts.c | 30 +++--- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/drivers/crypto/vmx/aes_xts.c b/drivers/crypto/vmx/aes_xts.c index 24353ec3..a1e653a 100644 ---

[PATCH v2 2/2] crypto: vmx - Use skcipher for xts fallback

Signed-off-by: Paulo Flabiano Smorigo --- drivers/crypto/vmx/aes_xts.c | 30 +++--- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/drivers/crypto/vmx/aes_xts.c b/drivers/crypto/vmx/aes_xts.c index 24353ec3..a1e653a 100644 ---

[PATCH v2 1/2] crypto: vmx - Use skcipher for cbc fallback

Signed-off-by: Paulo Flabiano Smorigo --- drivers/crypto/vmx/aes_cbc.c | 44 ++-- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/drivers/crypto/vmx/aes_cbc.c b/drivers/crypto/vmx/aes_cbc.c index

[PATCH v2 1/2] crypto: vmx - Use skcipher for cbc fallback

Signed-off-by: Paulo Flabiano Smorigo --- drivers/crypto/vmx/aes_cbc.c | 44 ++-- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/drivers/crypto/vmx/aes_cbc.c b/drivers/crypto/vmx/aes_cbc.c index 94ad5c0..2bb5910 100644 ---

Re: [PATCH v1 1/2] of: add devm_ functions for populate and depopulate

On Fri, Feb 17, 2017 at 8:31 AM, Benjamin Gaignard wrote: > Lost of calls to of_platform_populate() are not unbalanced by a call s/Lost/Lots/ > to of_platform_depopulate(). This create issues while drivers are > bind/unbind. > > In way to solve those issues is to

Re: [PATCH v1 1/2] of: add devm_ functions for populate and depopulate

On Fri, Feb 17, 2017 at 8:31 AM, Benjamin Gaignard wrote: > Lost of calls to of_platform_populate() are not unbalanced by a call s/Lost/Lots/ > to of_platform_depopulate(). This create issues while drivers are > bind/unbind. > > In way to solve those issues is to add devm_of_platform_populate()

Re: [PATCH] staging, android: remove lowmemory killer from the tree

On Fri 24-02-17 14:16:34, peter enderborg wrote: > On 02/24/2017 01:28 PM, Michal Hocko wrote: [...] > > Yeah, I strongly believe that the chosen approach is completely wrong. > > Both in abusing the shrinker interface and abusing oom_score_adj as the > > only criterion for the oom victim

Re: [PATCH] staging, android: remove lowmemory killer from the tree

On Fri 24-02-17 14:16:34, peter enderborg wrote: > On 02/24/2017 01:28 PM, Michal Hocko wrote: [...] > > Yeah, I strongly believe that the chosen approach is completely wrong. > > Both in abusing the shrinker interface and abusing oom_score_adj as the > > only criterion for the oom victim

[PATCH] scsi: lpfc: don't dereference dma_buf->iocbq before null check

From: Colin Ian King dma_buf->iocbq is being dereferenced immediately before it is being null checked, so we have a potential null pointer dereference bug. Fix this by only dereferencing it only once we have passed a null check on the pointer. Detected by

[PATCH] scsi: lpfc: don't dereference dma_buf->iocbq before null check

From: Colin Ian King dma_buf->iocbq is being dereferenced immediately before it is being null checked, so we have a potential null pointer dereference bug. Fix this by only dereferencing it only once we have passed a null check on the pointer. Detected by CoverityScan, CID#1411652

Re: [PATCH] perf tools: Force uncore events to system wide monitoring

On Fri, Feb 24, 2017 at 10:32:22AM -0300, Arnaldo Carvalho de Melo wrote: > Em Fri, Feb 24, 2017 at 11:17:14AM +0100, Jiri Olsa escreveu: > > Adding system_wide flag to uncore pmu objects and passing > > this flag along to the their events. > > Boris, ack? Tested-by? actualy we discussed that on

Re: [PATCH] perf tools: Force uncore events to system wide monitoring

On Fri, Feb 24, 2017 at 10:32:22AM -0300, Arnaldo Carvalho de Melo wrote: > Em Fri, Feb 24, 2017 at 11:17:14AM +0100, Jiri Olsa escreveu: > > Adding system_wide flag to uncore pmu objects and passing > > this flag along to the their events. > > Boris, ack? Tested-by? actualy we discussed that on

Re: [PATCH v4 05/24] openrisc: head: refactor out tlb flush into it's own function

On Fri, Feb 24, 2017 at 01:48:10PM +0100, Jonas Bonn wrote: > On 02/24/2017 11:54 AM, Stefan Kristiansson wrote: > >eOn Fri, Feb 24, 2017 at 10:57:19AM +0100, Jonas Bonn wrote: > >>On 02/24/2017 05:32 AM, Stafford Horne wrote: > >>>From: Stefan Kristiansson >

Re: [PATCH v4 05/24] openrisc: head: refactor out tlb flush into it's own function

On Fri, Feb 24, 2017 at 01:48:10PM +0100, Jonas Bonn wrote: > On 02/24/2017 11:54 AM, Stefan Kristiansson wrote: > >eOn Fri, Feb 24, 2017 at 10:57:19AM +0100, Jonas Bonn wrote: > >>On 02/24/2017 05:32 AM, Stafford Horne wrote: > >>>From: Stefan Kristiansson > >>> > >>>This brings it inline with

[PATCH] scsi: lpfc: sanity check hrq is null before dereferencing it

From: Colin Ian King The sanity check for hrq should be moved to before the deference of hrq to ensure we don't perform a null pointer deference. Detected by CoverityScan, CID#1411650 ("Dereference before null check") Signed-off-by: Colin Ian King

[PATCH] scsi: lpfc: sanity check hrq is null before dereferencing it

From: Colin Ian King The sanity check for hrq should be moved to before the deference of hrq to ensure we don't perform a null pointer deference. Detected by CoverityScan, CID#1411650 ("Dereference before null check") Signed-off-by: Colin Ian King --- drivers/scsi/lpfc/lpfc_sli.c | 10

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

On Fri, Feb 17, 2017 at 9:56 AM, Tobias Jakobi wrote: > Alexandre Belloni wrote: >> On 17/02/2017 at 13:45:44 +0100, Tobias Jakobi wrote: The device tree is a representation of the hardware itself. The state of the driver support doesn't change the

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

On Fri, Feb 17, 2017 at 9:56 AM, Tobias Jakobi wrote: > Alexandre Belloni wrote: >> On 17/02/2017 at 13:45:44 +0100, Tobias Jakobi wrote: The device tree is a representation of the hardware itself. The state of the driver support doesn't change the hardware you're running on, just

Re: [PATCH 4.4 00/25] 4.4.52-stable review

On Fri, 2017-02-24 at 09:25 +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.52 release. > There are 25 patches in this series, all will be posted as a response > to this one.  If anyone has any issues with these being applied, please > let me know. [...]

Re: [PATCH 4.4 00/25] 4.4.52-stable review

On Fri, 2017-02-24 at 09:25 +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.52 release. > There are 25 patches in this series, all will be posted as a response > to this one.  If anyone has any issues with these being applied, please > let me know. [...]

Re: [PATCH] perf report: Allow sorting by symbol size.

Em Fri, Feb 24, 2017 at 01:32:56PM +, charles.bay...@linaro.org escreveu: > From: Charles Baylis > > Add new sort key 'symbol_size' to allow user to sort by > symbol size, or (more usefully) display the symbol size > using --fields=...,symbol_size. Hey, really

Re: [PATCH] perf report: Allow sorting by symbol size.

Em Fri, Feb 24, 2017 at 01:32:56PM +, charles.bay...@linaro.org escreveu: > From: Charles Baylis > > Add new sort key 'symbol_size' to allow user to sort by > symbol size, or (more usefully) display the symbol size > using --fields=...,symbol_size. Hey, really nice, will test and apply, and

[PATCH] scsi: lpfc: remove redundant assignment of sgel

From: Colin Ian King In the NVMET_FCOP_RSP case, sgel is assigned but never used and hence is redundant and can be removed. Detected by CoverityScan, CID#1411658 ("Unused value") Signed-off-by: Colin Ian King ---

[PATCH] scsi: lpfc: remove redundant assignment of sgel

From: Colin Ian King In the NVMET_FCOP_RSP case, sgel is assigned but never used and hence is redundant and can be removed. Detected by CoverityScan, CID#1411658 ("Unused value") Signed-off-by: Colin Ian King --- drivers/scsi/lpfc/lpfc_nvmet.c | 1 - 1 file changed, 1 deletion(-) diff --git

Re: [PATCH v2 1/2] mm/cgroup: avoid panic when init with low memory

On 24/02/17 00:36, Laurent Dufour wrote: > The system may panic when initialisation is done when almost all the > memory is assigned to the huge pages using the kernel command line > parameter hugepage=. Panic may occur like this: > > [0.082289] Unable to handle kernel paging request

Re: [PATCH v2 1/2] mm/cgroup: avoid panic when init with low memory

On 24/02/17 00:36, Laurent Dufour wrote: > The system may panic when initialisation is done when almost all the > memory is assigned to the huge pages using the kernel command line > parameter hugepage=. Panic may occur like this: > > [0.082289] Unable to handle kernel paging request

Perf degradation seen with thread_info stored in sp_el0

Hi, I am observing some degradation in context switch performance (reported by sched benchmark of perf), after including the change to keep thread_info in sp_el0: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6cdf9c7ca687e01840d0215437620a20263012fc However, if I

Perf degradation seen with thread_info stored in sp_el0

Hi, I am observing some degradation in context switch performance (reported by sched benchmark of perf), after including the change to keep thread_info in sp_el0: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6cdf9c7ca687e01840d0215437620a20263012fc However, if I

Re: [PATCH 4.4 17/25] USB: serial: digi_acceleport: fix OOB data sanity check

On Fri, 2017-02-24 at 09:25 +0100, Greg Kroah-Hartman wrote: > 4.4-stable review patch.  If anyone has any objections, please let me know. > > -- > > From: Johan Hovold > > commit 2d380889215fe20b8523345649dee0579821800c upstream. > > Make sure to check for

Re: [PATCH 4.4 17/25] USB: serial: digi_acceleport: fix OOB data sanity check

On Fri, 2017-02-24 at 09:25 +0100, Greg Kroah-Hartman wrote: > 4.4-stable review patch.  If anyone has any objections, please let me know. > > -- > > From: Johan Hovold > > commit 2d380889215fe20b8523345649dee0579821800c upstream. > > Make sure to check for short transfers to

Re: [PATCH 4/8] drm/sun4i: add support for sun8i DE2 mixers and display engines

On Wed, Feb 22, 2017 at 2:09 PM, Maxime Ripard wrote: > Hi, > > On Wed, Feb 22, 2017 at 11:23:06PM +0800, Icenowy Zheng wrote: >> Allwinner have a new "Display Engine 2.0" in there new SoCs, which comes >> in a new "Display Engine" (mixers instead of old backends

Re: [PATCH 4/8] drm/sun4i: add support for sun8i DE2 mixers and display engines

On Wed, Feb 22, 2017 at 2:09 PM, Maxime Ripard wrote: > Hi, > > On Wed, Feb 22, 2017 at 11:23:06PM +0800, Icenowy Zheng wrote: >> Allwinner have a new "Display Engine 2.0" in there new SoCs, which comes >> in a new "Display Engine" (mixers instead of old backends and >> frontends). >> >> Add

Re: [PATCH] perf tools: Force uncore events to system wide monitoring

Em Fri, Feb 24, 2017 at 11:17:14AM +0100, Jiri Olsa escreveu: > Adding system_wide flag to uncore pmu objects and passing > this flag along to the their events. Boris, ack? Tested-by? - Arnaldo > Making system wide (-a) the default option if no target > was specified and one of following

Re: [PATCH] perf tools: Force uncore events to system wide monitoring

Em Fri, Feb 24, 2017 at 11:17:14AM +0100, Jiri Olsa escreveu: > Adding system_wide flag to uncore pmu objects and passing > this flag along to the their events. Boris, ack? Tested-by? - Arnaldo > Making system wide (-a) the default option if no target > was specified and one of following

Re: [PATCH 0/9] tools subsystem refcounter conversions

Em Fri, Feb 24, 2017 at 07:27:32AM +, Reshetova, Elena escreveu: > > Em Thu, Feb 23, 2017 at 11:39:10AM +, Reshetova, Elena escreveu: > > > > Em Wed, Feb 22, 2017 at 08:23:29PM -0300, Arnaldo Carvalho de Melo > > > > escreveu: > > > > > Em Tue, Feb 21, 2017 at 12:39:35PM -0300, Arnaldo

Re: [PATCH 0/9] tools subsystem refcounter conversions

Em Fri, Feb 24, 2017 at 07:27:32AM +, Reshetova, Elena escreveu: > > Em Thu, Feb 23, 2017 at 11:39:10AM +, Reshetova, Elena escreveu: > > > > Em Wed, Feb 22, 2017 at 08:23:29PM -0300, Arnaldo Carvalho de Melo > > > > escreveu: > > > > > Em Tue, Feb 21, 2017 at 12:39:35PM -0300, Arnaldo

Re: [PATCH] [v2] selftests, x86, pkeys: test with random, unallocated protection keys

On Thu, Feb 23, 2017 at 04:23:39PM -0800, Dave Hansen wrote: > > > Changes from v1: > * Also generate random negative numbers for protection key > > -- > From: Dave Hansen > > The kernel pkeys code had a minor bug where it did some large shifts > to an integer

[PATCH] perf report: Allow sorting by symbol size.

From: Charles Baylis Add new sort key 'symbol_size' to allow user to sort by symbol size, or (more usefully) display the symbol size using --fields=...,symbol_size. Signed-off-by: Charles Baylis --- tools/perf/Documentation/perf-report.txt

Re: [PATCH] [v2] selftests, x86, pkeys: test with random, unallocated protection keys

On Thu, Feb 23, 2017 at 04:23:39PM -0800, Dave Hansen wrote: > > > Changes from v1: > * Also generate random negative numbers for protection key > > -- > From: Dave Hansen > > The kernel pkeys code had a minor bug where it did some large shifts > to an integer which is undefined behavior in

[PATCH] perf report: Allow sorting by symbol size.

From: Charles Baylis Add new sort key 'symbol_size' to allow user to sort by symbol size, or (more usefully) display the symbol size using --fields=...,symbol_size. Signed-off-by: Charles Baylis --- tools/perf/Documentation/perf-report.txt | 1 + tools/perf/util/hist.h | 1

Re: [PATCH] staging, android: remove lowmemory killer from the tree

On 02/24/2017 01:28 PM, Michal Hocko wrote: > On Fri 24-02-17 13:19:46, peter enderborg wrote: >> On 02/23/2017 09:36 PM, Martijn Coenen wrote: >>> On Thu, Feb 23, 2017 at 9:24 PM, John Stultz wrote: So, just for context, Android does have a userland LMK daemon (using

Re: [PATCH] staging, android: remove lowmemory killer from the tree

On 02/24/2017 01:28 PM, Michal Hocko wrote: > On Fri 24-02-17 13:19:46, peter enderborg wrote: >> On 02/23/2017 09:36 PM, Martijn Coenen wrote: >>> On Thu, Feb 23, 2017 at 9:24 PM, John Stultz wrote: So, just for context, Android does have a userland LMK daemon (using the mempressure

[PATCH 03/14] afs: Populate group ID from vnode status

From: Marc Dionne The group was hard coded to GLOBAL_ROOT_GID; use the group ID that was received from the server. Signed-off-by: Marc Dionne Signed-off-by: David Howells --- fs/afs/inode.c |2 +- 1 file changed, 1

[PATCH 03/14] afs: Populate group ID from vnode status

From: Marc Dionne The group was hard coded to GLOBAL_ROOT_GID; use the group ID that was received from the server. Signed-off-by: Marc Dionne Signed-off-by: David Howells --- fs/afs/inode.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/afs/inode.c

[PATCH 02/14] afs: Fix page overput in afs_fill_page()

afs_fill_page() loads the page it wants to fill into the afs_read request without incrementing its refcount - but then calls afs_put_read() to clean up afterwards, which then releases a ref on the page. Fix this by getting a ref on the page before calling afs_vnode_fetch_data(). This causes sync

[PATCH 02/14] afs: Fix page overput in afs_fill_page()

afs_fill_page() loads the page it wants to fill into the afs_read request without incrementing its refcount - but then calls afs_put_read() to clean up afterwards, which then releases a ref on the page. Fix this by getting a ref on the page before calling afs_vnode_fetch_data(). This causes sync

[PATCH 04/14] afs: Adjust mode bits processing

From: Marc Dionne Mode bits for an afs file should not be enforced in the usual way. For files, the absence of user bits can restrict file access with respect to what is granted by the server. These bits apply regardless of the owner or the current uid; the rest of

[PATCH 04/14] afs: Adjust mode bits processing

From: Marc Dionne Mode bits for an afs file should not be enforced in the usual way. For files, the absence of user bits can restrict file access with respect to what is granted by the server. These bits apply regardless of the owner or the current uid; the rest of the mode bits (group, other)

[PATCH 08/19] hwmon: (lm63) Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH 08/19] hwmon: (lm63) Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH 14/14] afs: Prevent callback expiry timer overflow

From: Tina Ruchandani get_seconds() returns real wall-clock seconds. On 32-bit systems this value will overflow in year 2038 and beyond. This patch changes afs_vnode record to use ktime_get_real_seconds() instead, for the fields cb_expires and cb_expires_at.

[PATCH 14/14] afs: Prevent callback expiry timer overflow

From: Tina Ruchandani get_seconds() returns real wall-clock seconds. On 32-bit systems this value will overflow in year 2038 and beyond. This patch changes afs_vnode record to use ktime_get_real_seconds() instead, for the fields cb_expires and cb_expires_at. Signed-off-by: Tina Ruchandani

[PATCH 11/19] hwmon: (lm90) Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH 15/19] hwmon: (ucd9200) Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH 11/19] hwmon: (lm90) Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH 15/19] hwmon: (ucd9200) Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH 06/19] hwmon: (ina209) Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v2 5/5] clk: tegra: add aclk

This clock clocks the ADSP cortex-A9. Signed-off-by: Peter De Schrijver --- drivers/clk/tegra/clk-tegra210.c | 10 ++ include/dt-bindings/clock/tegra210-car.h | 2 ++ 2 files changed, 12 insertions(+) diff --git a/drivers/clk/tegra/clk-tegra210.c

[PATCH 06/19] hwmon: (ina209) Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v2 5/5] clk: tegra: add aclk

This clock clocks the ADSP cortex-A9. Signed-off-by: Peter De Schrijver --- drivers/clk/tegra/clk-tegra210.c | 10 ++ include/dt-bindings/clock/tegra210-car.h | 2 ++ 2 files changed, 12 insertions(+) diff --git a/drivers/clk/tegra/clk-tegra210.c

[PATCH v2 1/5] clk: tegra: add cec clock

This clock is used to clock the HDMI CEC interface. Signed-off-by: Peter De Schrijver --- drivers/clk/tegra/clk-id.h | 1 + drivers/clk/tegra/clk-tegra-periph.c| 1 + drivers/clk/tegra/clk-tegra114.c| 1 +

[PATCH v2 1/5] clk: tegra: add cec clock

This clock is used to clock the HDMI CEC interface. Signed-off-by: Peter De Schrijver --- drivers/clk/tegra/clk-id.h | 1 + drivers/clk/tegra/clk-tegra-periph.c| 1 + drivers/clk/tegra/clk-tegra114.c| 1 + drivers/clk/tegra/clk-tegra124.c

[PATCH v2 2/5] clk: tegra: define Tegra210 DMIC sync clocks

Tegra210 has 3 DMIC inputs which can be clocked from the recovered clock of several other audio inputs (eg. i2s0, i2s1, ...). To model this, we add a 3 new clocks similar to the audio* clocks which handle the same function for the i2s and spdif clocks. Signed-off-by: Peter De Schrijver

[PATCH v2 4/5] clk: tegra: add super clk mux/div

Add a super clock type which implements both mux and divider. This is used for aclk. Signed-off-by: Peter De Schrijver --- drivers/clk/tegra/clk-super.c | 87 +-- drivers/clk/tegra/clk.h | 7 +++- 2 files changed, 89

[PATCH v2 2/5] clk: tegra: define Tegra210 DMIC sync clocks

Tegra210 has 3 DMIC inputs which can be clocked from the recovered clock of several other audio inputs (eg. i2s0, i2s1, ...). To model this, we add a 3 new clocks similar to the audio* clocks which handle the same function for the i2s and spdif clocks. Signed-off-by: Peter De Schrijver ---

[PATCH v2 4/5] clk: tegra: add super clk mux/div

Add a super clock type which implements both mux and divider. This is used for aclk. Signed-off-by: Peter De Schrijver --- drivers/clk/tegra/clk-super.c | 87 +-- drivers/clk/tegra/clk.h | 7 +++- 2 files changed, 89 insertions(+), 5 deletions(-)

[PATCH v2 3/5] clk: tegra: define Tegra210 DMIC clocks

Tegra210 has 3 inputs for Digital Microphones (DMICs). Provide the required clocks for them. Signed-off-by: Peter De Schrijver --- drivers/clk/tegra/clk-id.h | 5 - drivers/clk/tegra/clk-tegra-periph.c | 21 +

[PATCH v2 3/5] clk: tegra: define Tegra210 DMIC clocks

Tegra210 has 3 inputs for Digital Microphones (DMICs). Provide the required clocks for them. Signed-off-by: Peter De Schrijver --- drivers/clk/tegra/clk-id.h | 5 - drivers/clk/tegra/clk-tegra-periph.c | 21 + drivers/clk/tegra/clk-tegra210.c | 3 +++ 3

[PATCH 02/19] hwmon: (adc128d818) Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH 00/19] hwmon: Add OF device table to I2C drivers that are missing it

Hello, This series add OF device ID tables to hwmon I2C drivers whose devices are either used in Device Tree source files or are listed in binding docs as a compatible string. That's done because the plan is to change the I2C core to report proper OF modaliases instead of always reporting a

<    4   5   6   7   8   9   10   11   12   13   >