[PATCH 1/7] crypto : stylistic cleanup in sha1-mb

From: Megha Dey Currently there are several checkpatch warnings in the sha1_mb.c file: 'WARNING: line over 80 characters' in the sha1_mb.c file. Also, the syntax of some multi-line comments are not correct. This patch fixes these issues. Signed-off-by: Megha Dey ---

[PATCH 2/7] crypto : async implementation for sha1-mb

From: Megha Dey Herbert wants the sha1-mb algorithm to have an async implementation: https://lkml.org/lkml/2016/4/5/286. Currently, sha1-mb uses an async interface for the outer algorithm and a sync interface for the inner algorithm. This patch introduces a async interface for even the inner

Re: [PATCH 5/5] cpufreq: schedutil: do not update rate limit ts when freq is unchanged

On Fri, May 20, 2016 at 02:24:19AM +0200, Rafael J. Wysocki wrote: > On Fri, May 20, 2016 at 1:34 AM, Steve Muckle wrote: > > On Thu, May 19, 2016 at 11:15:52PM +0200, Rafael J. Wysocki wrote: > >> But anyway this change again seems to be an optimization that might be >

Re: [PATCH 5/5] cpufreq: schedutil: do not update rate limit ts when freq is unchanged

On Fri, May 20, 2016 at 02:24:19AM +0200, Rafael J. Wysocki wrote: > On Fri, May 20, 2016 at 1:34 AM, Steve Muckle wrote: > > On Thu, May 19, 2016 at 11:15:52PM +0200, Rafael J. Wysocki wrote: > >> But anyway this change again seems to be an optimization that might be > >> done later to me. > >>

Re: [PATCH 5/5] cpufreq: schedutil: do not update rate limit ts when freq is unchanged

On Fri, May 20, 2016 at 2:24 AM, Rafael J. Wysocki wrote: > On Fri, May 20, 2016 at 1:34 AM, Steve Muckle wrote: >> On Thu, May 19, 2016 at 11:15:52PM +0200, Rafael J. Wysocki wrote: >>> But anyway this change again seems to be an optimization that

Re: [PATCH 5/5] cpufreq: schedutil: do not update rate limit ts when freq is unchanged

On Fri, May 20, 2016 at 2:24 AM, Rafael J. Wysocki wrote: > On Fri, May 20, 2016 at 1:34 AM, Steve Muckle wrote: >> On Thu, May 19, 2016 at 11:15:52PM +0200, Rafael J. Wysocki wrote: >>> But anyway this change again seems to be an optimization that might be >>> done later to me. >>> >>> I guess

[PATCH v3] mailbox: pcc: Support HW-Reduced Communication Subspace type 2

ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. v3 * Remove 2 global structures *

[PATCH v3] mailbox: pcc: Support HW-Reduced Communication Subspace type 2

ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. v3 * Remove 2 global structures *

Erschwingliche Darlehen Angebot

Achtung Herr / Frau, Wir bieten derzeit gewerbliches Darlehen, Renovieren, Konsolidierung, Business und persönliche Darlehen zu einem erschwinglichen Zinssatz von 3% pro Jahr. Innerhalb von maximal 25 Jahre zu irgendeinem Teil der Welt. Sind Sie in Schulden? Wollen Sie Ihre Rechnungen zahlen

Erschwingliche Darlehen Angebot

Achtung Herr / Frau, Wir bieten derzeit gewerbliches Darlehen, Renovieren, Konsolidierung, Business und persönliche Darlehen zu einem erschwinglichen Zinssatz von 3% pro Jahr. Innerhalb von maximal 25 Jahre zu irgendeinem Teil der Welt. Sind Sie in Schulden? Wollen Sie Ihre Rechnungen zahlen

Re: [PATCH 5/5] cpufreq: schedutil: do not update rate limit ts when freq is unchanged

On Fri, May 20, 2016 at 1:34 AM, Steve Muckle wrote: > On Thu, May 19, 2016 at 11:15:52PM +0200, Rafael J. Wysocki wrote: >> But anyway this change again seems to be an optimization that might be >> done later to me. >> >> I guess there are many things that might be

Re: [PATCH 5/5] cpufreq: schedutil: do not update rate limit ts when freq is unchanged

On Fri, May 20, 2016 at 1:34 AM, Steve Muckle wrote: > On Thu, May 19, 2016 at 11:15:52PM +0200, Rafael J. Wysocki wrote: >> But anyway this change again seems to be an optimization that might be >> done later to me. >> >> I guess there are many things that might be optimized in schedutil, >> but

Re: next-20160517 - lockdep splat in pcie code

On Wed, 18 May 2016 11:54:59 +0300, Mika Westerberg said: > Can you check if the patch fixes the issue? Tested, no complaints at boot, and everything seems to be working. Feel free to add this to the patch and send it upstream: Tested-By: Valdis Kletnieks >

Re: next-20160517 - lockdep splat in pcie code

On Wed, 18 May 2016 11:54:59 +0300, Mika Westerberg said: > Can you check if the patch fixes the issue? Tested, no complaints at boot, and everything seems to be working. Feel free to add this to the patch and send it upstream: Tested-By: Valdis Kletnieks >

Re: [PATCH v3 3/5] mmc: core: implement enhanced strobe support

Hi, On Tue, May 10, 2016 at 2:09 AM, Shawn Lin wrote: > Controllers use data strobe line to latch data from devices > under hs400 mode, but not for cmd line. So since emmc 5.1, JEDEC > introduces enhanced strobe mode for latching cmd response from > emmc devices to host

Re: [PATCH v3 3/5] mmc: core: implement enhanced strobe support

Hi, On Tue, May 10, 2016 at 2:09 AM, Shawn Lin wrote: > Controllers use data strobe line to latch data from devices > under hs400 mode, but not for cmd line. So since emmc 5.1, JEDEC > introduces enhanced strobe mode for latching cmd response from > emmc devices to host controllers. This new

Re: [Intel-gfx] [PATCH 3/3] Introduce & use new lightweight SGL iterators

On 19/05/2016 18:27, Chris Wilson wrote: On Tue, May 17, 2016 at 01:05:48PM +0100, Dave Gordon wrote: On 17/05/16 11:34, Tvrtko Ursulin wrote: On 16/05/16 16:19, Dave Gordon wrote: The existing for_each_sg_page() iterator is somewhat heavyweight, and is limiting i915 driver performance in a

Re: [Intel-gfx] [PATCH 3/3] Introduce & use new lightweight SGL iterators

On 19/05/2016 18:27, Chris Wilson wrote: On Tue, May 17, 2016 at 01:05:48PM +0100, Dave Gordon wrote: On 17/05/16 11:34, Tvrtko Ursulin wrote: On 16/05/16 16:19, Dave Gordon wrote: The existing for_each_sg_page() iterator is somewhat heavyweight, and is limiting i915 driver performance in a

[PATCH 2/8] perf/x86: Support sysfs files depending on SMT status

From: Andi Kleen Add a way to show different sysfs events attributes depending on HyperThreading is on or off. This is difficult to determine early at boot, so we just do it dynamically when the sysfs attribute is read. v2: Compute HT status only once in CPU online/offline

[PATCH 2/8] perf/x86: Support sysfs files depending on SMT status

From: Andi Kleen Add a way to show different sysfs events attributes depending on HyperThreading is on or off. This is difficult to determine early at boot, so we just do it dynamically when the sysfs attribute is read. v2: Compute HT status only once in CPU online/offline hooks. v3: Use

[PATCH 5/8] perf/x86/intel: Use new topology_max_smt_threads() in HT leak workaround

From: Andi Kleen Now that we have topology_max_smt_threads() use it to detect the HT workarounds for older CPUs. v2: Use topology_max_smt_threads() Signed-off-by: Andi Kleen --- arch/x86/events/intel/core.c | 6 ++ 1 file changed, 2

[PATCH 1/8] x86/topology: Add topology_max_smt_threads()

From: Andi Kleen For SMT specific workarounds it is useful to know if SMT is active on any online CPU in the system. This currently requires a loop over all online CPUs. Add a global variable that is updated with the maximum number of smt threads on any CPU on

[PATCH 5/8] perf/x86/intel: Use new topology_max_smt_threads() in HT leak workaround

From: Andi Kleen Now that we have topology_max_smt_threads() use it to detect the HT workarounds for older CPUs. v2: Use topology_max_smt_threads() Signed-off-by: Andi Kleen --- arch/x86/events/intel/core.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git

[PATCH 1/8] x86/topology: Add topology_max_smt_threads()

From: Andi Kleen For SMT specific workarounds it is useful to know if SMT is active on any online CPU in the system. This currently requires a loop over all online CPUs. Add a global variable that is updated with the maximum number of smt threads on any CPU on online/offline, and use it for

Add top down metrics to perf stat

Note to reviewers: includes both tools and kernel patches. The kernel patches are at the beginning. [v2: Address review feedback. Metrics are now always printed, but colored when crossing threshold. --topdown implies --metric-only. Various smaller fixes, see individual patches] [v3: Add

[PATCH 7/8] perf stat: Basic support for TopDown in perf stat

From: Andi Kleen Add basic plumbing for TopDown in perf stat Add a new --topdown options to enable events. When --topdown is specified set up events for all topdown events supported by the kernel. Add topdown-* as a special case to the event parser, as is needed for all

Add top down metrics to perf stat

Note to reviewers: includes both tools and kernel patches. The kernel patches are at the beginning. [v2: Address review feedback. Metrics are now always printed, but colored when crossing threshold. --topdown implies --metric-only. Various smaller fixes, see individual patches] [v3: Add

[PATCH 7/8] perf stat: Basic support for TopDown in perf stat

From: Andi Kleen Add basic plumbing for TopDown in perf stat Add a new --topdown options to enable events. When --topdown is specified set up events for all topdown events supported by the kernel. Add topdown-* as a special case to the event parser, as is needed for all events containing -.

[PATCH 6/8] perf stat: Avoid fractional digits for integer scales

From: Andi Kleen When the scaling factor is a full integer don't display fractional digits. This avoids unnecessary .00 output for topdown metrics with scale factors. v2: Remove redundant check. Signed-off-by: Andi Kleen ---

[PATCH 6/8] perf stat: Avoid fractional digits for integer scales

From: Andi Kleen When the scaling factor is a full integer don't display fractional digits. This avoids unnecessary .00 output for topdown metrics with scale factors. v2: Remove redundant check. Signed-off-by: Andi Kleen --- tools/perf/builtin-stat.c | 7 --- 1 file changed, 4

[PATCH 3/8] perf/x86/intel: Add Top Down events to Intel Core

From: Andi Kleen Add declarations for the events needed for TopDown to the Intel big core CPUs starting with Sandy Bridge. We need to report different values if HyperThreading is on or off. The only thing this patch does is to export some events in sysfs. TopDown level 1

Re: [PATCH v3 5/5] mmc: sdhci-of-arasan: implement enhanced strobe callback

Hi, On Tue, May 10, 2016 at 2:10 AM, Shawn Lin wrote: > Currently sdhci-arasan 5.1 can support enhanced strobe function, > and we now limit it just for "arasan,sdhci-5.1". Add > mmc-hs400-enhanced-strobe in DT to enable the function if we'r sure nit:s/we'r/we're/ [

[PATCH 3/8] perf/x86/intel: Add Top Down events to Intel Core

From: Andi Kleen Add declarations for the events needed for TopDown to the Intel big core CPUs starting with Sandy Bridge. We need to report different values if HyperThreading is on or off. The only thing this patch does is to export some events in sysfs. TopDown level 1 uses a set of

Re: [PATCH v3 5/5] mmc: sdhci-of-arasan: implement enhanced strobe callback

Hi, On Tue, May 10, 2016 at 2:10 AM, Shawn Lin wrote: > Currently sdhci-arasan 5.1 can support enhanced strobe function, > and we now limit it just for "arasan,sdhci-5.1". Add > mmc-hs400-enhanced-strobe in DT to enable the function if we'r sure nit:s/we'r/we're/ [ ... ] > @@ -79,6 +81,21 @@

[PATCH 8/8] perf stat: Add computation of TopDown formulas

From: Andi Kleen Implement the TopDown formulas in perf stat. The topdown basic metrics reported by the kernel are collected, and the formulas are computed and output as normal metrics. See the kernel commit exporting the events for details on the used metrics. v2: Always

[PATCH 4/8] perf/x86/intel: Add Top Down events to Intel Atom

From: Andi Kleen Add topdown event declarations to Silvermont / Airmont. These cores do not support the full Top Down metrics, but an useful subset (FrontendBound, Retiring, Backend Bound/Bad Speculation). The perf stat tool automatically handles the missing events and

[PATCH 8/8] perf stat: Add computation of TopDown formulas

From: Andi Kleen Implement the TopDown formulas in perf stat. The topdown basic metrics reported by the kernel are collected, and the formulas are computed and output as normal metrics. See the kernel commit exporting the events for details on the used metrics. v2: Always print all metrics,

[PATCH 4/8] perf/x86/intel: Add Top Down events to Intel Atom

From: Andi Kleen Add topdown event declarations to Silvermont / Airmont. These cores do not support the full Top Down metrics, but an useful subset (FrontendBound, Retiring, Backend Bound/Bad Speculation). The perf stat tool automatically handles the missing events and combines the available

Re: [PATCH 10/10] perf, tools, stat: Add extra output of counter values with -vv

> hi, > we already have similar output for aggregated counters, > could you please consider something like below to clearly > separate them? I think Arnaldo has already merged the patch, so he should merge the fix too. The fix is fine for me. -Andi > > [root@ibm-x3650m4-01 perf]# ./perf stat

Re: [PATCH 10/10] perf, tools, stat: Add extra output of counter values with -vv

> hi, > we already have similar output for aggregated counters, > could you please consider something like below to clearly > separate them? I think Arnaldo has already merged the patch, so he should merge the fix too. The fix is fine for me. -Andi > > [root@ibm-x3650m4-01 perf]# ./perf stat

[PATCH] - silence UBSAN complaint in ehci-hcd.

UBSAN throws a complaint: [2.418579] UBSAN: Undefined behaviour in drivers/usb/host/ehci-hub.c:877:47 [2.418582] index -1 is out of range for type 'u32 [1]' though it's only on the hostpc[] part, not on the port_status[] on the previous line which has the same exact index calculation.

[PATCH v2 3/3] ARM: dts: rockchip: fixes the spi compatible for rk3036

That's seem the incorrect string to match the spi driver. Fixes commit f629fcfab2cd ("ARM: dts: rockchip: support the spi for rk3036") Signed-off-by: Caesar Wang Cc: Heiko Stuebner Cc: linux-rockc...@lists.infradead.org --- Changes in v2: None

[PATCH] - silence UBSAN complaint in ehci-hcd.

UBSAN throws a complaint: [2.418579] UBSAN: Undefined behaviour in drivers/usb/host/ehci-hub.c:877:47 [2.418582] index -1 is out of range for type 'u32 [1]' though it's only on the hostpc[] part, not on the port_status[] on the previous line which has the same exact index calculation.

[PATCH v2 3/3] ARM: dts: rockchip: fixes the spi compatible for rk3036

That's seem the incorrect string to match the spi driver. Fixes commit f629fcfab2cd ("ARM: dts: rockchip: support the spi for rk3036") Signed-off-by: Caesar Wang Cc: Heiko Stuebner Cc: linux-rockc...@lists.infradead.org --- Changes in v2: None arch/arm/boot/dts/rk3036.dtsi | 2 +- 1 file

[PATCH v2 2/3] spi/rockchip: add the rk3036/rk3228/rk3368 to match for driver

In gerenal, the "rockchip,rockchip-spi" string will match the dts that's great in spi driver. After all the most of rockchip SoCs ar same spi controller. Then, we should keep the old style to match the dts various. Signed-off-by: Caesar Wang Cc: Mark Brown

[PATCH v2 2/3] spi/rockchip: add the rk3036/rk3228/rk3368 to match for driver

In gerenal, the "rockchip,rockchip-spi" string will match the dts that's great in spi driver. After all the most of rockchip SoCs ar same spi controller. Then, we should keep the old style to match the dts various. Signed-off-by: Caesar Wang Cc: Mark Brown Cc: Heiko Stuebner Cc:

[PATCH v2 1/3] spi/rockchip: add rk3036/rk3228/rk3368 SoCs for spi document

We had supported the rk3036/rk3066/rk3188/rk3228/rk3288/rk3368/rk3399 family SoCs in linux kernel. Let's add the other SoCs, in order to a better understanding from the rockchip spi document. Signed-off-by: Caesar Wang Cc: Rob Herring Cc: Mark Brown

[PATCH v2 1/3] spi/rockchip: add rk3036/rk3228/rk3368 SoCs for spi document

We had supported the rk3036/rk3066/rk3188/rk3228/rk3288/rk3368/rk3399 family SoCs in linux kernel. Let's add the other SoCs, in order to a better understanding from the rockchip spi document. Signed-off-by: Caesar Wang Cc: Rob Herring Cc: Mark Brown Cc: Heiko Stuebner Cc:

Re: Add top down metrics to perf stat

On Mon, May 16, 2016 at 02:58:38PM +0200, Jiri Olsa wrote: > On Fri, May 13, 2016 at 06:44:49PM -0700, Andi Kleen wrote: > > SNIP > > > > > The formulas to compute the metrics are generic, they > > only change based on the availability on the abstracted > > input values. > > > > The

Re: sharing page cache pages between multiple mappings

On Thu, May 19, 2016 at 12:17:14PM +0200, Miklos Szeredi wrote: > On Thu, May 19, 2016 at 11:05 AM, Michal Hocko wrote: > > On Thu 19-05-16 10:20:13, Miklos Szeredi wrote: > >> Has anyone thought about sharing pages between multiple files? > >> > >> The obvious application is

Re: Add top down metrics to perf stat

On Mon, May 16, 2016 at 02:58:38PM +0200, Jiri Olsa wrote: > On Fri, May 13, 2016 at 06:44:49PM -0700, Andi Kleen wrote: > > SNIP > > > > > The formulas to compute the metrics are generic, they > > only change based on the availability on the abstracted > > input values. > > > > The

Re: sharing page cache pages between multiple mappings

On Thu, May 19, 2016 at 12:17:14PM +0200, Miklos Szeredi wrote: > On Thu, May 19, 2016 at 11:05 AM, Michal Hocko wrote: > > On Thu 19-05-16 10:20:13, Miklos Szeredi wrote: > >> Has anyone thought about sharing pages between multiple files? > >> > >> The obvious application is for COW filesytems

Re: [rcu_sched stall] regression/miss-config ?

Hi Paul, On 5/17/2016 12:15 PM, Paul E. McKenney wrote: On Tue, May 17, 2016 at 06:46:22AM -0700, santosh.shilim...@oracle.com wrote: On 5/16/16 5:58 PM, Paul E. McKenney wrote: On Mon, May 16, 2016 at 12:49:41PM -0700, Santosh Shilimkar wrote: On 5/16/2016 10:34 AM, Paul E. McKenney wrote:

Re: [rcu_sched stall] regression/miss-config ?

Hi Paul, On 5/17/2016 12:15 PM, Paul E. McKenney wrote: On Tue, May 17, 2016 at 06:46:22AM -0700, santosh.shilim...@oracle.com wrote: On 5/16/16 5:58 PM, Paul E. McKenney wrote: On Mon, May 16, 2016 at 12:49:41PM -0700, Santosh Shilimkar wrote: On 5/16/2016 10:34 AM, Paul E. McKenney wrote:

linux-next: manual merge of the vfs tree with the cifs tree

Hi Al, Today's linux-next merge of the vfs tree got a conflict in: fs/cifs/cifsfs.c between commit: 56c1d814aadf ("CIFS: Remove some obsolete comments") from the cifs tree and commit: 51085a1f913a ("cifs: use C99 syntax for inode_operations initializer") from the vfs tree. This was

linux-next: manual merge of the vfs tree with the cifs tree

Hi Al, Today's linux-next merge of the vfs tree got a conflict in: fs/cifs/cifsfs.c between commit: 56c1d814aadf ("CIFS: Remove some obsolete comments") from the cifs tree and commit: 51085a1f913a ("cifs: use C99 syntax for inode_operations initializer") from the vfs tree. This was

Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking

On Thu, May 19, 2016 at 4:15 PM, Josh Poimboeuf wrote: > On Mon, May 02, 2016 at 08:52:41AM -0700, Andy Lutomirski wrote: >> On Mon, May 2, 2016 at 6:52 AM, Josh Poimboeuf wrote: >> > On Fri, Apr 29, 2016 at 05:08:50PM -0700, Andy Lutomirski wrote: >> >>

Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking

On Thu, May 19, 2016 at 4:15 PM, Josh Poimboeuf wrote: > On Mon, May 02, 2016 at 08:52:41AM -0700, Andy Lutomirski wrote: >> On Mon, May 2, 2016 at 6:52 AM, Josh Poimboeuf wrote: >> > On Fri, Apr 29, 2016 at 05:08:50PM -0700, Andy Lutomirski wrote: >> >> On Apr 29, 2016 3:41 PM, "Josh Poimboeuf"

Re: [PATCH v4 0/6] Add alignment check for DAX mount

On 5/10/16 11:23 AM, Toshi Kani wrote: > When a partition is not aligned by 4KB, mount -o dax succeeds, Sorry for being late, but - Shouldn't this and all subsequent patch commits refer to PAGE_SIZE, rather than "4kB?" -Eric

Re: [PATCH v4 0/6] Add alignment check for DAX mount

On 5/10/16 11:23 AM, Toshi Kani wrote: > When a partition is not aligned by 4KB, mount -o dax succeeds, Sorry for being late, but - Shouldn't this and all subsequent patch commits refer to PAGE_SIZE, rather than "4kB?" -Eric

Re: [PATCH 5/5] cpufreq: schedutil: do not update rate limit ts when freq is unchanged

On Thu, May 19, 2016 at 11:15:52PM +0200, Rafael J. Wysocki wrote: > But anyway this change again seems to be an optimization that might be > done later to me. > > I guess there are many things that might be optimized in schedutil, > but I'd prefer to address one item at a time, maybe going after

Re: [PATCH 5/5] cpufreq: schedutil: do not update rate limit ts when freq is unchanged

On Thu, May 19, 2016 at 11:15:52PM +0200, Rafael J. Wysocki wrote: > But anyway this change again seems to be an optimization that might be > done later to me. > > I guess there are many things that might be optimized in schedutil, > but I'd prefer to address one item at a time, maybe going after

Re: [PATCH] mm: move page_ext_init after all struct pages are initialized

On 5/19/2016 4:21 PM, Andrew Morton wrote: On Thu, 19 May 2016 15:35:15 -0700 "Shi, Yang" wrote: On 5/19/2016 3:30 PM, Andrew Morton wrote: On Thu, 19 May 2016 14:29:05 -0700 Yang Shi wrote: When DEFERRED_STRUCT_PAGE_INIT is enabled, just a subset

Re: [PATCH] mm: move page_ext_init after all struct pages are initialized

On 5/19/2016 4:21 PM, Andrew Morton wrote: On Thu, 19 May 2016 15:35:15 -0700 "Shi, Yang" wrote: On 5/19/2016 3:30 PM, Andrew Morton wrote: On Thu, 19 May 2016 14:29:05 -0700 Yang Shi wrote: When DEFERRED_STRUCT_PAGE_INIT is enabled, just a subset of memmap at boot are initialized, then

Re: [PATCH] mm: move page_ext_init after all struct pages are initialized

On Thu, 19 May 2016 15:35:15 -0700 "Shi, Yang" wrote: > On 5/19/2016 3:30 PM, Andrew Morton wrote: > > On Thu, 19 May 2016 14:29:05 -0700 Yang Shi wrote: > > > >> When DEFERRED_STRUCT_PAGE_INIT is enabled, just a subset of memmap at boot > >> are

Re: [PATCH] mm: move page_ext_init after all struct pages are initialized

On Thu, 19 May 2016 15:35:15 -0700 "Shi, Yang" wrote: > On 5/19/2016 3:30 PM, Andrew Morton wrote: > > On Thu, 19 May 2016 14:29:05 -0700 Yang Shi wrote: > > > >> When DEFERRED_STRUCT_PAGE_INIT is enabled, just a subset of memmap at boot > >> are initialized, then the rest are initialized in

[PATCH] ARM: OMAP2: Enable Errata 430973 for OMAP3

Enable Erratum 430973 similar to commit 5c86c5339c56 ("ARM: omap2plus_defconfig: Enable ARM erratum 430973 for omap3") - Since multiple defconfigs can exist from various points of view (multi_v7, omap2plus etc.. it is always better to enable the erratum from the Kconfig selection point of view so

[PATCH] ARM: OMAP2: Enable Errata 430973 for OMAP3

Enable Erratum 430973 similar to commit 5c86c5339c56 ("ARM: omap2plus_defconfig: Enable ARM erratum 430973 for omap3") - Since multiple defconfigs can exist from various points of view (multi_v7, omap2plus etc.. it is always better to enable the erratum from the Kconfig selection point of view so

Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking

On Mon, May 02, 2016 at 08:52:41AM -0700, Andy Lutomirski wrote: > On Mon, May 2, 2016 at 6:52 AM, Josh Poimboeuf wrote: > > On Fri, Apr 29, 2016 at 05:08:50PM -0700, Andy Lutomirski wrote: > >> On Apr 29, 2016 3:41 PM, "Josh Poimboeuf" wrote: > >> > >

Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking

On Mon, May 02, 2016 at 08:52:41AM -0700, Andy Lutomirski wrote: > On Mon, May 2, 2016 at 6:52 AM, Josh Poimboeuf wrote: > > On Fri, Apr 29, 2016 at 05:08:50PM -0700, Andy Lutomirski wrote: > >> On Apr 29, 2016 3:41 PM, "Josh Poimboeuf" wrote: > >> > > >> > On Fri, Apr 29, 2016 at 02:37:41PM

Re: [PATCH 2/5] cpufreq: schedutil: support scheduler cpufreq callbacks on remote CPUs

On Fri, May 20, 2016 at 12:59 AM, Steve Muckle wrote: > On Thu, May 19, 2016 at 10:55:23PM +0200, Rafael J. Wysocki wrote: >> >> > +static inline bool sugov_queue_remote_callback(struct sugov_policy >> >> > *sg_policy, >> >> > +int

Re: linux-next: build failure after merge of the security tree

Hi Steve, On Thu, 19 May 2016 14:01:20 +1000 Stephen Rothwell wrote: > > After merging the security tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > fs/cifs/cifs_spnego.c: In function 'init_cifs_spnego': > fs/cifs/cifs_spnego.c:206:12: error:

Re: [PATCH 2/5] cpufreq: schedutil: support scheduler cpufreq callbacks on remote CPUs

On Fri, May 20, 2016 at 12:59 AM, Steve Muckle wrote: > On Thu, May 19, 2016 at 10:55:23PM +0200, Rafael J. Wysocki wrote: >> >> > +static inline bool sugov_queue_remote_callback(struct sugov_policy >> >> > *sg_policy, >> >> > +int cpu) >> >> > +{ >> >> >

Re: linux-next: build failure after merge of the security tree

Hi Steve, On Thu, 19 May 2016 14:01:20 +1000 Stephen Rothwell wrote: > > After merging the security tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > fs/cifs/cifs_spnego.c: In function 'init_cifs_spnego': > fs/cifs/cifs_spnego.c:206:12: error: too few arguments to

Re: [PATCH 3/5] sched: cpufreq: call cpufreq hook from remote CPUs

On Thu, May 19, 2016 at 11:06:14PM +0200, Rafael J. Wysocki wrote: > > In the case of a remote update the hook has to run (or not) after it is > > known whether preemption will occur so we don't do needless work or > > IPIs. If the policy CPUs aren't known in the scheduler then the early > > hook

Re: [PATCH 3/5] sched: cpufreq: call cpufreq hook from remote CPUs

On Thu, May 19, 2016 at 11:06:14PM +0200, Rafael J. Wysocki wrote: > > In the case of a remote update the hook has to run (or not) after it is > > known whether preemption will occur so we don't do needless work or > > IPIs. If the policy CPUs aren't known in the scheduler then the early > > hook

Re: [PATCH 2/5] cpufreq: schedutil: support scheduler cpufreq callbacks on remote CPUs

On Thu, May 19, 2016 at 10:55:23PM +0200, Rafael J. Wysocki wrote: > >> > +static inline bool sugov_queue_remote_callback(struct sugov_policy > >> > *sg_policy, > >> > +int cpu) > >> > +{ > >> > + struct cpufreq_policy *policy = sg_policy->policy; >

Re: [PATCH 2/5] cpufreq: schedutil: support scheduler cpufreq callbacks on remote CPUs

On Thu, May 19, 2016 at 10:55:23PM +0200, Rafael J. Wysocki wrote: > >> > +static inline bool sugov_queue_remote_callback(struct sugov_policy > >> > *sg_policy, > >> > +int cpu) > >> > +{ > >> > + struct cpufreq_policy *policy = sg_policy->policy; >

Re: linux-next 20160512 - ACPI issue with screen brightness

roblem is present then. If it is, please revert all of > the top-most commits up to and including the above one and see if the > problem goes away. Put this one in the "things that go bump in the night" pile - the problem doesn't manifest on next-20160519, even though the commit I bisected to is in the tree for today, and I don't see any obvious smoking guns to have fixed it in the past week's worth of 'git log' pgp3OdhuVCW76.pgp Description: PGP signature

Re: linux-next 20160512 - ACPI issue with screen brightness

; > > > > but I've stared at the code and don't see what would do this > > Please try to check out the acpi-video branch from linux-pm.git and > see if the problem is present then. If it is, please revert all of > the top-most commits up to and including the above one and s

Re: [PATCH] fbcon: warn on invalid cursor blink intervals

On 05/19/2016 03:31 PM, Scot Doyle wrote: Two systems are locking on boot [1] because ops->cur_blink_jiffies is set to zero from vc->vc_cur_blink_ms. Ignore such invalid intervals and log a warning. [1] https://bugs.launchpad.net/bugs/1574814 Suggested-by: David Daney

Re: [PATCH] fbcon: warn on invalid cursor blink intervals

On 05/19/2016 03:31 PM, Scot Doyle wrote: Two systems are locking on boot [1] because ops->cur_blink_jiffies is set to zero from vc->vc_cur_blink_ms. Ignore such invalid intervals and log a warning. [1] https://bugs.launchpad.net/bugs/1574814 Suggested-by: David Daney Signed-off-by: Scot

[v2 PATCH] mm: move page_ext_init after all struct pages are initialized

When DEFERRED_STRUCT_PAGE_INIT is enabled, just a subset of memmap at boot are initialized, then the rest are initialized in parallel by starting one-off "pgdatinitX" kernel thread for each node X. If page_ext_init is called before it, some pages will not have valid extension, this may lead the

[v2 PATCH] mm: move page_ext_init after all struct pages are initialized

When DEFERRED_STRUCT_PAGE_INIT is enabled, just a subset of memmap at boot are initialized, then the rest are initialized in parallel by starting one-off "pgdatinitX" kernel thread for each node X. If page_ext_init is called before it, some pages will not have valid extension, this may lead the

Re: [PATCH] tty: vt: Fix soft lockup in fbcon cursor blink timer.

On Tue, 17 May 2016, David Daney wrote: > From: David Daney > > We are getting somewhat random soft lockups with this signature: > > [ 86.992215] [] el1_irq+0xa0/0x10c > [ 86.997082] [] cursor_timer_handler+0x30/0x54 > [ 87.002991] [] call_timer_fn+0x54/0x1a8 > [

Re: [PATCH] tty: vt: Fix soft lockup in fbcon cursor blink timer.

On Tue, 17 May 2016, David Daney wrote: > From: David Daney > > We are getting somewhat random soft lockups with this signature: > > [ 86.992215] [] el1_irq+0xa0/0x10c > [ 86.997082] [] cursor_timer_handler+0x30/0x54 > [ 87.002991] [] call_timer_fn+0x54/0x1a8 > [ 87.008378] []

Re: [PATCH] mm: move page_ext_init after all struct pages are initialized

On 5/19/2016 3:30 PM, Andrew Morton wrote: On Thu, 19 May 2016 14:29:05 -0700 Yang Shi wrote: When DEFERRED_STRUCT_PAGE_INIT is enabled, just a subset of memmap at boot are initialized, then the rest are initialized in parallel by starting one-off "pgdatinitX" kernel

Re: [PATCH] mm: move page_ext_init after all struct pages are initialized

On 5/19/2016 3:30 PM, Andrew Morton wrote: On Thu, 19 May 2016 14:29:05 -0700 Yang Shi wrote: When DEFERRED_STRUCT_PAGE_INIT is enabled, just a subset of memmap at boot are initialized, then the rest are initialized in parallel by starting one-off "pgdatinitX" kernel thread for each node X.

Re: [PATCH v3] vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive

On Thu, 12 May 2016 18:20:51 +0800 Yongji Xie wrote: > Current vfio-pci implementation disallows to mmap > sub-page(size < PAGE_SIZE) MMIO BARs because these BARs' mmio > page may be shared with other BARs. This will cause some > performance issues when we passthrough

Re: [PATCH v3] vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive

On Thu, 12 May 2016 18:20:51 +0800 Yongji Xie wrote: > Current vfio-pci implementation disallows to mmap > sub-page(size < PAGE_SIZE) MMIO BARs because these BARs' mmio > page may be shared with other BARs. This will cause some > performance issues when we passthrough a PCI device with > this

Re: get_maintainer.pl and MAINTAINERS file

On Thu, 2016-05-19 at 21:53 +0200, Jiri Slaby wrote: > Cc: joe > > On 05/19/2016, 02:57 PM, Kalle Valo wrote: > > > > (Changed the subject from "Re: [PATCH v6 0/3] auxdisplay: Introduce ht16k33 > > driver") > > > > Robin van der Gracht writes: > > > > > > > > > > > > >

Re: get_maintainer.pl and MAINTAINERS file

On Thu, 2016-05-19 at 21:53 +0200, Jiri Slaby wrote: > Cc: joe > > On 05/19/2016, 02:57 PM, Kalle Valo wrote: > > > > (Changed the subject from "Re: [PATCH v6 0/3] auxdisplay: Introduce ht16k33 > > driver") > > > > Robin van der Gracht writes: > > > > > > > > > > > > > And 4th, what is

[PATCH] locking/mutex: Set and clear owner using WRITE_ONCE()

The mutex owner can get read and written to without the wait_lock. Use WRITE_ONCE when setting and clearing the owner field in order to avoid optimizations such as store tearing. This avoids situations where the owner field gets written to with multiple stores and another thread could concurrently

[PATCH] locking/mutex: Set and clear owner using WRITE_ONCE()

The mutex owner can get read and written to without the wait_lock. Use WRITE_ONCE when setting and clearing the owner field in order to avoid optimizations such as store tearing. This avoids situations where the owner field gets written to with multiple stores and another thread could concurrently

[PATCH] fbcon: warn on invalid cursor blink intervals

Two systems are locking on boot [1] because ops->cur_blink_jiffies is set to zero from vc->vc_cur_blink_ms. Ignore such invalid intervals and log a warning. [1] https://bugs.launchpad.net/bugs/1574814 Suggested-by: David Daney Signed-off-by: Scot Doyle

[PATCH] fbcon: warn on invalid cursor blink intervals

Two systems are locking on boot [1] because ops->cur_blink_jiffies is set to zero from vc->vc_cur_blink_ms. Ignore such invalid intervals and log a warning. [1] https://bugs.launchpad.net/bugs/1574814 Suggested-by: David Daney Signed-off-by: Scot Doyle Cc: [v4.2] ---

Re: [PATCH v4 2/5] locking/rwsem: Protect all writes to owner by WRITE_ONCE

On Wed, 2016-05-18 at 12:58 -0700, Jason Low wrote: > On Wed, 2016-05-18 at 14:29 -0400, Waiman Long wrote: > > On 05/18/2016 01:21 PM, Jason Low wrote: > > > On Wed, 2016-05-18 at 07:04 -0700, Davidlohr Bueso wrote: > > >> On Tue, 17 May 2016, Waiman Long wrote: > > >> > > >>> Without using

Re: [PATCH v4 2/5] locking/rwsem: Protect all writes to owner by WRITE_ONCE

On Wed, 2016-05-18 at 12:58 -0700, Jason Low wrote: > On Wed, 2016-05-18 at 14:29 -0400, Waiman Long wrote: > > On 05/18/2016 01:21 PM, Jason Low wrote: > > > On Wed, 2016-05-18 at 07:04 -0700, Davidlohr Bueso wrote: > > >> On Tue, 17 May 2016, Waiman Long wrote: > > >> > > >>> Without using

Re: [PATCH] mm: move page_ext_init after all struct pages are initialized

On Thu, 19 May 2016 14:29:05 -0700 Yang Shi wrote: > When DEFERRED_STRUCT_PAGE_INIT is enabled, just a subset of memmap at boot > are initialized, then the rest are initialized in parallel by starting one-off > "pgdatinitX" kernel thread for each node X. > > If

Re: [PATCH] mm: move page_ext_init after all struct pages are initialized

On Thu, 19 May 2016 14:29:05 -0700 Yang Shi wrote: > When DEFERRED_STRUCT_PAGE_INIT is enabled, just a subset of memmap at boot > are initialized, then the rest are initialized in parallel by starting one-off > "pgdatinitX" kernel thread for each node X. > > If page_ext_init is called before

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