[1] introduced free request pending code to avoid scheduling
by mutex under spinlock and it was a mess which made code
lenghty and increased overhead.
Now, we don't need zram->lock any more to free slot so
this patch reverts it and then, tb_lock should protect it.
[1] a0c516c, zram: don't grab mu
Finally, we separated zram->lock dependency from 32bit stat/
table handling so there is no reason to use rw_semaphore
between read and write path so this patch removes the lock
from read path totally and changes rw_semaphore with mutex.
So, we could do
old:
read-read: OK
read-write: NO
write-writ
From: "Michael S. Tsirkin"
Date: Sun, 12 Jan 2014 13:37:56 +0200
> Since virtio is an OASIS standard draft now, virtio implementation
> discussions are taking place on the virtio-dev OASIS mailing list.
> Update MAINTAINERS.
>
> Signed-off-by: Michael S. Tsirkin
Applied, thanks.
--
To unsubscr
On Tue, 2014-01-14 at 16:33 -0800, Jason Low wrote:
> When running workloads that have high contention in mutexes on an 8 socket
> machine, spinners would often spin for a long time with no lock owner.
>
> One of the potential reasons for this is because a thread can be preempted
> after clearing
On Tue, 14 Jan 2014, Andrew Morton wrote:
> From: Andrew Morton
> Subject: mm/memory_hotplug.c: register_memory_resource() fixes
>
> - register_memory_resource() should not go BUG on ENOMEM. That's
> appropriate at system boot time, but not at memory-hotplug time. Fix.
>
> - register_memory
On Tue, 10 Dec 2013 16:42:18 +0100
Petr Mladek wrote:
> The commit fd4363fff3d9 (x86: Introduce int3 (breakpoint)-based instruction
> patching) uses the same technique that has been used in ftrace since 08d636b
> ("ftrace/x86: Have arch x86_64 use breakpoints instead of stop machine")
>
> It wou
On Tue, 14 Jan 2014 16:33:10 -0800 Jason Low wrote:
> When running workloads that have high contention in mutexes on an 8 socket
> machine, spinners would often spin for a long time with no lock owner.
>
> One of the potential reasons for this is because a thread can be preempted
> after clearin
On 01/14/14 at 12:16pm, One Thousand Gnomes wrote:
> On Tue, 14 Jan 2014 16:23:23 +0800
> Dave Young wrote:
>
> > In kdump kernel watchdog could interrupt vmcore capturing because we
> > have no way to disable/stop it while crashing happens.
>
> Lots of watchdogs cannot be stopped.
>
> > Add a
On Tue, 14 Jan 2014, Nathan Zimmer wrote:
> We don't need to do register_memory_resource() since it has its own lock and
> doesn't make any callbacks.
>
We need to do it, just not under lock_memory_hotplug() :).
> Also register_memory_resource return NULL on failure so we don't have anything
>
This bounced LKML, re-sending. My phone sent it as HTML
On Tue, Jan 14, 2014 at 7:50 PM, William Roberts
wrote:
> The race was non existent. I had the VMA locked. I switched to this to keep
> the code that gets the cmdline value almost unchanged to try and reduce
> bugs. I can still author a patc
On 01/14/2014 04:45 PM, tip-bot for Borislav Petkov wrote:
> + rdmsrl(MSR_AMD64_LS_CFG, val);
> + if (!(val & BIT(15)))
> + wrmsrl(MSR_AMD64_LS_CFG, val | BIT(15));
Incidentally, I'm wondering if we shouldn't have a
set_in_msr()/clear_in_msr() set of fun
On Tue, 14 Jan 2014, Andrew Morton wrote:
> I've been waiting 10+ years for us to decide to delete that warning due
> to the false positives. Hasn't happened yet, and the warning does
> find bugs/issues/misconfigurations/etc.
>
I've found memory leaks from the meminfo that is emitted as part of
On Tue, 10 Dec 2013 16:42:17 +0100
Petr Mladek wrote:
> probe_kernel_read is used when modifying function calls in
> ftrace_replace_code,
> see arch/x86/kernel/ftrace.c. On x86, the code is replaced using int3 guard.
> All functions are patched in parallel to reduce an expensive synchronization
Libo Chen writes:
> yes
> On 2014/1/6 16:42, Gao feng wrote:
>> On 01/06/2014 03:54 PM, Libo Chen wrote:
>>> On 2014/1/3 13:20, Cong Wang wrote:
On Thu, Jan 2, 2014 at 7:11 PM, Libo Chen
wrote:
> Hi guys,
>
> Now, lxc created with veth can not be under control by
> cls
On Monday, January 13, 2014 7:17 PM, Lothar Waßmann wrote:
>
> This patch allows the edt-ft5x06 multitouch panel driver to be
> configured via DT.
>
> Signed-off-by: Lothar Waßmann
(+cc Simon Budig)
This 'edt-ft5x06' driver was made by Simon Budig.
Please, add him to CC list.
Also, I added so
Commit-ID: 3b56496865f9f7d9bcb2f93b44c63f274f08e3b6
Gitweb: http://git.kernel.org/tip/3b56496865f9f7d9bcb2f93b44c63f274f08e3b6
Author: Borislav Petkov
AuthorDate: Wed, 15 Jan 2014 00:07:11 +0100
Committer: H. Peter Anvin
CommitDate: Tue, 14 Jan 2014 16:39:07 -0800
x86, cpu, amd: Add wo
On Tue, 10 Dec 2013 16:42:16 +0100
Petr Mladek wrote:
> When trying to use text_poke_bp_iter in ftrace, the result was slower than
> the original implementation.
>
> It turned out that one difference was in text_poke vs. ftrace_write.
> text_poke did many extra operations to make sure that code
On Tue, 14 Jan 2014, Prarit Bhargava wrote:
> diff --git a/Documentation/kernel-parameters.txt
> b/Documentation/kernel-parameters.txt
> index b9e9bd8..ea93f75 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -343,6 +343,9 @@ bytes respectively.
On 01/14/2014 03:07 PM, Borislav Petkov wrote:
> From: Borislav Petkov
>
> This adds the workaround for erratum 793 as a precaution in case not
> every BIOS implements it. This addresses CVE-2013-6885.
>
> Signed-off-by: Borislav Petkov
> Tested-by: Aravind Gopalakrishnan
> ---
> arch/x86/inc
Hello Rafael,
> -Original Message-
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Wednesday, January 15, 2014 6:55 AM
> To: Liu, Chuansheng
> Cc: gre...@linuxfoundation.org; Brown, Len; pa...@ucw.cz;
> linux...@vger.kernel.org; linux-kernel@vger.kernel.org; Li, Zhuangzhi
> S
On Tue, 14 Jan 2014, Dave Hansen wrote:
> > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=c65c1877bd6826ce0d9713d76e30a7bed8e49f38
>
> I think the assert is just bogus at least in the early case.
> early_kmem_cache_node_alloc() says:
> * No kmalloc_node yet so do it
On Tue, 14 Jan 2014 16:25:10 -0800 (PST) David Rientjes
wrote:
> On Tue, 14 Jan 2014, Andrew Morton wrote:
>
> > This is all a bit nasty, isn't it? THP goes and alters min_free_kbytes
> > to improve its own reliability, but min_free_kbytes is also
> > user-modifiable. And over many years we h
On Tue, 10 Dec 2013 16:42:15 +0100
Petr Mladek wrote:
> diff --git a/arch/x86/include/asm/alternative.h
> b/arch/x86/include/asm/alternative.h
> index 586747f5f41d..82ffe7e1529c 100644
> --- a/arch/x86/include/asm/alternative.h
> +++ b/arch/x86/include/asm/alternative.h
> @@ -232,4 +232,40 @@ ex
This patch is needed for patch 3, but should also be beneficial in general.
The mutex->spin_mlock was introduced in order to ensure that only 1 thread
loops on lock->owner field at a time to reduce cache line contention. When
lock->owner is NULL and the lock->count is still not 1, the spinner(s) w
When running workloads that have high contention in mutexes on an 8 socket
machine, spinners would often spin for a long time with no lock owner.
One of the potential reasons for this is because a thread can be preempted
after clearing lock->owner but before releasing the lock, or preempted after
The mutex_can_spin_on_owner() function should also return false if the
task needs to be rescheduled.
Signed-off-by: Jason Low
---
kernel/locking/mutex.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index 4dd6e4c..85c6b
While optimistic spinning is beneficial to performance, I have found that
threads can potentially spin for a long time while there is no lock owner
during high contention cases. In these scenarios, too much spinning can reduce
performance. This RFC patchset attempts to address some of the issues wi
On Tue, 14 Jan 2014, Andrew Morton wrote:
> This is all a bit nasty, isn't it? THP goes and alters min_free_kbytes
> to improve its own reliability, but min_free_kbytes is also
> user-modifiable. And over many years we have trained a *lot* of users
> to alter min_free_kbytes. Often to prevent n
On Wed, Jan 15, 2014 at 6:44 AM, Paul E. McKenney
wrote:
>
> Which means that Alpha should be able to similarly emulate 1-byte and
> 2-byte atomics, correct?
Not reasonably, no.
The ldl/stc implementation on early alpha was so broken as to be
unusable. It's not actually done in the cache, it WEN
This patch for ni_mio_common.c changes out a while loop for a timeout,
which is preferred.
Signed-off-by: Chase Southwood
---
OK, here's another go at it. Hopefully everything looks more correct
this time. Greg, I've followed the pattern you gave me, and I really
appreciate all of the tips! A
On Wed, Jan 08, 2014 at 10:06:31AM +0800, Li Wang wrote:
> Hi,
>
> On 01/03/2014 07:55 AM, Andrew Morton wrote:
> >On Mon, 30 Dec 2013 21:45:17 +0800 Li Wang wrote:
> >
> >>Analogous to shrink_dcache_parent except that it collects inodes.
> >>It is not very appropriate to be put in dcache.c, but
On Thu, Jan 09, 2014 at 10:57:15AM +0800, Fengguang Wu wrote:
> Hi Dave,
>
> As you suggested, I added tests for ext4 and btrfs, the results are
> the same.
>
> Then I tried running perf record for 10 seconds starting from 200s.
> (The test runs for 410s). I see several warning messages and hope
Hi Ingo,
On Fri, Dec 20, 2013 at 09:49:53AM +0100, Ingo Molnar wrote:
>
> * David Cohen wrote:
>
> > Prevent sfi_handle_*_dev() to register device in case
> > intel_mid_sfi_get_pdata() failed to execute.
> >
> > Since 'NULL' is a valid return value, this patch makes
> > sfi_handle_*_dev() func
On Tue, Jan 14, 2014 at 07:41:39PM +0100, Josh Cartwright wrote:
> Signed-off-by: Josh Cartwright
> ---
> .../bindings/spmi/qcom,spmi-pmic-arb.txt | 46
> ++
> 1 file changed, 46 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/spmi/qcom,spmi
On Tue, 14 Jan 2014 23:41:56 + atom...@redhat.com wrote:
> The khungtaskd thread limits how many hung task warnings it displays
> at a time, when a timeout occurs. This patch allows that limit to be
> set to "unlimited", by setting hung_task_warnings to -1, which will
> cause khungtaskd to dis
On Tue, Jan 14, 2014 at 03:52:01PM -0800, H. Peter Anvin wrote:
> On 01/14/2014 02:44 PM, David Cohen wrote:
> > On Mon, Dec 16, 2013 at 12:07:35PM -0800, David Cohen wrote:
> >> Hi,
> >>
> >> I've a bunch of Intel MID patches under review but it seems they are
> >> becoming
> >> old and start to
> + pr_debug("Command IRQ complete %d %d %x\n", cmd->opcode, cmd->error,
> + cmd->flags);
dev_dbg... (and a few other places)
> +/* Set MMC clock / power.
> + * Note: This controller uses a simple divider scheme therefore it cannot run
> + * SD/MMC cards at full speed (24/20MHz). HC
On Fri, Jan 10, 2014 at 10:24:07AM -0500, Jeff Moyer wrote:
> Matthew Wilcox writes:
>
> > This patch set implements pageio as I described in my talk at
> > Linux.Conf.AU. It's for review more than application, I think
> > benchmarking is going to be required to see if it's a win. We've done
>
On Tue, 2014-01-14 at 20:14 +0100, Jan-Simon Möller wrote:
> Hi David,
>
> what version of clang did you use btw ?
This is LLVM HEAD + extra patches at git://,
http://git.infradead.org/users/dwmw2/llvm.git and the following patch to
clang HEAD:
diff --git a/include/clang/Driver/Options.td b/incl
On Wed, 15 Jan 2014 04:07:20 +0800 Han Pingtian
wrote:
> min_free_kbytes may be raised during THP's initialization. Sometimes,
> this will change the value being set by user. Showing message will
> clarify this confusion.
>
> Only show this message when changing the value set by user according
On 01/14/2014 02:44 PM, David Cohen wrote:
> On Mon, Dec 16, 2013 at 12:07:35PM -0800, David Cohen wrote:
>> Hi,
>>
>> I've a bunch of Intel MID patches under review but it seems they are becoming
>> old and start to need changes.
>> I gathered an up-to-date version of all of them in this single pa
Document the Broadcom Brahma B15 GIC implementation as compatible
with the ARM GIC standard.
Signed-off-by: Marc Carino
Acked-by: Florian Fainelli
---
Documentation/devicetree/bindings/arm/gic.txt |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/
Add a sample DTS which will allow bootup of a board populated
with the BCM7445 chip.
Signed-off-by: Marc Carino
Acked-by: Florian Fainelli
---
arch/arm/boot/dts/brcmstb-7445.dts | 104
1 files changed, 104 insertions(+), 0 deletions(-)
create mode 100644 a
Add the Broadcom Brahma B15 CPU to the DT CPU binding list.
Signed-off-by: Marc Carino
Acked-by: Florian Fainelli
---
Documentation/devicetree/bindings/arm/cpus.txt |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
b/Documen
On Tue, Jan 14, 2014 at 07:48:28PM +0100, Oleg Nesterov wrote:
> On 01/13, Paul E. McKenney wrote:
> >
> > The __run_timers() function currently steps through the list one jiffy at
> > a time in order to update the timer wheel. However, if the timer wheel
> > is empty, no adjustment is needed othe
Document the bindings that the Broadcom STB platform needs
for proper bootup.
Signed-off-by: Marc Carino
Acked-by: Florian Fainelli
---
.../devicetree/bindings/arm/brcm-brcmstb.txt | 43
1 files changed, 43 insertions(+), 0 deletions(-)
create mode 100644 Documenta
Add the UART definitions needed to support earlyprintk on brcmstb machines.
Signed-off-by: Marc Carino
Acked-by: Florian Fainelli
---
arch/arm/Kconfig.debug | 16 +++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
i
Perform any CPU-specific initialization required on the
Broadcom Brahma-15 core.
Signed-off-by: Marc Carino
Acked-by: Florian Fainelli
---
arch/arm/mm/proc-v7.S | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
inde
The BCM7xxx series of Broadcom SoCs are used primarily in set-top boxes.
This patch adds machine support for the ARM-based Broadcom SoCs.
Signed-off-by: Marc Carino
Acked-by: Florian Fainelli
---
arch/arm/configs/multi_v7_defconfig |1 +
arch/arm/mach-bcm/Kconfig | 14 ++
arch/
This patchset contains the board support package for the
Broadcom BCM7445 ARM-based SoC [1]. These changes contain a
minimal set of code needed for a BCM7445-based board to boot
the Linux kernel.
These changes heavily leverage the OF/devicetree framework.
v3:
- rebased to v3.13-rc8
- switched to
On Mon, Dec 16, 2013 at 3:16 PM, Alex Williamson
wrote:
> PCI resets will attempt to take the device_lock for any device to be
> reset. This is a problem if that lock is already held, for instance
> in the device remove path. It's not sufficient to simply kill the
> user process or skip the rese
Nicolas Ferre writes:
> Arnd, Olof, Kevin,
>
> A little "cleanup" pull-request for 3.14 that goes on top of the previous
> AT91 cleanup material.
> The thing to note from this pull-request is the beginning of board file
> removal
> thank to the conversion to DT. We are still waiting for more fee
. The initrd is on the list of
> areas that get avoided, so the fundamental design isn't broken, but
> clearly something is busted.
>
> How long has tip:x86/kaslr been sitting in linux-next? If this is some
> interaction between kaslr and something else, perhaps merge order just
&g
On Tue, Jan 14, 2014 at 10:01:04AM -0800, Richard Henderson wrote:
> On 01/14/2014 09:08 AM, Matt Turner wrote:
> > On Tue, Jan 14, 2014 at 3:03 AM, Peter Zijlstra
> > wrote:
> >> On Tue, Jan 14, 2014 at 10:28:23AM +0800, Daniel J Blueman wrote:
> Peter,
>
> I found out that the bu
On Tuesday 14 January 2014 04:13 PM, Nishanth Menon wrote:
> On Tue, Jan 14, 2014 at 3:03 PM, Santosh Shilimkar
> wrote:
>>
>>> ok.. some sort of Linaro thing about which I have no background about
>>> - but dont really care in this context.
>>>
>> Nothing related Linaro. Its just that platforms a
From: Aaron Tomlin
The khungtaskd thread limits how many hung task warnings it displays
at a time, when a timeout occurs. This patch allows that limit to be
set to "unlimited", by setting hung_task_warnings to -1, which will
cause khungtaskd to display information about all hung tasks.
While ULO
From: Aaron Tomlin
The khungtaskd thread limits how many hung task
warnings it displays at a time, when a timeout
occurs. This patch allows that limit to be set
to "unlimited", by setting hung_task_warnings
to -1, which will cause khungtaskd to display
information about all hung tasks.
While ULO
From: Aaron Tomlin
Add neg_one to the list of standard constraints.
Signed-off-by: Aaron Tomlin
---
kernel/sysctl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 34a6047..dd531a6 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -122,6 +122,7 @
On Tue, Jan 14, 2014 at 07:41:38PM +0100, Josh Cartwright wrote:
> The Qualcomm PMIC Arbiter, in addition to being a basic SPMI controller,
> also implements interrupt handling for slave devices. Note, this is
> outside the scope of SPMI, as SPMI leaves interrupt handling completely
> unspecified.
On Mon, Dec 16, 2013 at 3:14 PM, Alex Williamson
wrote:
> When doing a function/slot/bus reset PCI grabs the device_lock for
> each device to block things like suspend and driver probes, which is
> all well and good, but call paths exist where this lock may already be
> held. This creates an oppo
On Tue, 14 Jan 2014 14:33:11 -0500 Vivek Goyal wrote:
> Right now we seem to be exporting the max data size contained inside
> vmcoreinfo note. But this does not include the size of meta data around
> vmcore info data. Like name of the note and starting and ending elf_note.
>
> I think user spac
Add entry for AppliedMicro X-Gene PCIe host driver.
Signed-off-by: Tanmay Inamdar
---
MAINTAINERS |7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6c20792..9e3ed53 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6531,6 +6531,13 @@ L: linux-...@vg
This patch adds the device tree nodes for APM X-Gene PCIe controller and
PCIe clock interface. Since X-Gene SOC supports maximum 5 ports, 5 dts
nodes are added.
Signed-off-by: Tanmay Inamdar
---
arch/arm64/boot/dts/apm-mustang.dts |4 +
arch/arm64/boot/dts/apm-storm.dtsi | 144
This patch adds the bindings for X-Gene PCIe driver. The driver resides
under 'drivers/pci/host/pci-xgene.c' file.
Signed-off-by: Tanmay Inamdar
---
.../devicetree/bindings/pci/xgene-pcie.txt | 45
1 file changed, 45 insertions(+)
create mode 100644 Documentation/
This patch adds the AppliedMicro X-Gene SOC PCIe controller driver.
X-Gene PCIe controller supports maxmum upto 8 lanes and GEN3 speed.
X-Gene has maximum 5 PCIe ports supported.
Signed-off-by: Tanmay Inamdar
---
drivers/pci/host/Kconfig | 10 +
drivers/pci/host/Makefile|1 +
drive
This patch adds support for AppliedMicro X-Gene PCIe host controller. The
driver is tested on X-Gene platform with different gen1/2/3 PCIe endpoint
cards.
X-Gene PCIe controller driver has depedency on the pcie arch support for
arm64. The arm64 pcie arch support is not yet part of mainline Linux k
n, but
clearly something is busted.
How long has tip:x86/kaslr been sitting in linux-next? If this is some
interaction between kaslr and something else, perhaps merge order just
happens to be pointing at kaslr?
Regardless, all my tests so far against next-20140114 and an initramfs
haven't se
soc_widget_read API returns the register data and it is possible
that a register can contain 0x at any point of time.
In such cases snd_soc_widget_write is not called after the read
operation inside snd_soc_update_bits_locked API. Thus, change
the prototype of soc_widget_read to return only
soc_widget_read API returns the register data and it is possible
that a register can contain 0x. Thus, change the prototype
of soc_widget_read to return only the error code and pass the reg
data through pointer argument.
Signed-off-by: Arun Shamanna Lakshmi
---
sound/soc/soc-dapm.c | 2
On Tuesday 14 January 2014 04:26 PM, Kevin Hilman wrote:
> On Fri, Nov 15, 2013 at 8:12 AM, Santosh Shilimkar
> wrote:
>> On Friday 15 November 2013 11:11 AM, Tony Lindgren wrote:
>>> * Taras Kondratiuk [131115 08:03]:
On 11/15/2013 05:36 PM, Tony Lindgren wrote:
> * Tony Lindgren [1311
On Tue, Jan 14, 2014 at 02:45:37PM -0800, Eric Dumazet wrote:
> Even on a Jaguar, the proposed alternative
I don't know what Jaguar you guys are talking about but the Jaguar
I know - Fam16h - has an int hardware divider:
http://developer.amd.com/wordpress/media/2012/10/SOG_16h_52128_PUB_Rev1_1.pd
On 01/14/2014 02:33 PM, Kees Cook wrote:
>
> Can you tell me how the initrd for quantal-core-x86_64.cgz was built
> in the qemu instances you're using? It seems like all the failures
> point to a problem with how kASLR is interacting with the initrd.
>
If kASLR somehow causes the kernel to colli
FYI, for future patches, start the subject with a capital letter. ie:
x86: Allow to handle errors in text_poke function family
On Tue, 10 Dec 2013 16:42:13 +0100
Petr Mladek wrote:
> The text_poke functions called BUG() in case of error. This was too strict.
> There are situations when the sys
On Tue, 14 Jan 2014 12:24:34 -0600 Nathan Zimmer wrote:
> We don't need to do register_memory_resource() since it has its own lock and
> doesn't make any callbacks.
>
> Also register_memory_resource return NULL on failure so we don't have anything
> to cleanup at this point.
>
>
> The reason f
> -Original Message-
> From: Olaf Hering [mailto:o...@aepfle.de]
> Sent: Tuesday, January 14, 2014 2:13 PM
> To: KY Srinivasan
> Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; a...@canonical.com; jasow...@redhat.com
> Subject: Re: [PATCH V2 1
On Tue, Jan 14, 2014 at 11:42:22PM +0900, Satoru Takeuchi wrote:
> At Mon, 13 Jan 2014 16:27:21 -0800,
> Greg Kroah-Hartman wrote:
> >
> > This is the start of the stable review cycle for the 3.12.8 release.
> > There are 77 patches in this series, all will be posted as a response
> > to this one.
On Tue, Jan 14, 2014 at 12:30:35PM -0700, Shuah Khan wrote:
> On 01/13/2014 05:26 PM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 3.10.27 release.
> >There are 62 patches in this series, all will be posted as a response
> >to this one. If anyone has any issues
On Mon, Jan 13, 2014 at 07:02:23PM -0800, Guenter Roeck wrote:
> On 01/13/2014 04:26 PM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 3.10.27 release.
> >There are 62 patches in this series, all will be posted as a response
> >to this one. If anyone has any iss
On Tue, Jan 14, 2014 at 03:31:01PM -0600, Chase Southwood wrote:
> This patch to ni_mio_common.c changes a simple while loop to a timeout,
> which is preferred.
>
> Signed-off-by: Chase Southwood
> ---
>
> I removed the extra counter variable this time. Greg, you mentioned that I
> could just
From: Rafael J. Wysocki
Rework the ACPI PM domain's PM callbacks to avoid resuming devices
during system suspend in order to modify their wakeup settings if
that isn't necessary.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/device_pm.c | 31 +++
1 file change
From: Rafael J. Wysocki
Add a new helper routine, pm_runtime_enabled_and_suspended(), to
allow subsystems (or PM domains) to check the runtime PM status of
devices during system suspend (possibly to avoid resuming those
devices upfront at that time).
Signed-off-by: Rafael J. Wysocki
---
driver
Hi,
The following experimental series of 3 patches implements a mechanism allowing
subsystems to avoid resuming runtime-suspended devices during system suspend.
As far as the PM core goes, it introduces a new flag, power.no_suspend, that
will be set by the core for devices which can stay suspende
From: Rafael J. Wysocki
Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to
resume all runtime-suspended devices during system suspend, mostly
because those devices may need to be reprogrammed due to different
wakeup settings for system sleep and runtime PM. However, at least
in
From: Borislav Petkov
This adds the workaround for erratum 793 as a precaution in case not
every BIOS implements it. This addresses CVE-2013-6885.
Signed-off-by: Borislav Petkov
Tested-by: Aravind Gopalakrishnan
---
arch/x86/include/uapi/asm/msr-index.h | 1 +
arch/x86/kernel/cpu/amd.c
Signed-off-by: Josh Cartwright
---
.../bindings/spmi/qcom,spmi-pmic-arb.txt | 46 ++
1 file changed, 46 insertions(+)
create mode 100644
Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
diff --git a/Documentation/devicetree/bindings/spmi/qcom,spmi-pmi
From: Kenneth Heitke
Qualcomm's PMIC Arbiter SPMI controller functions as a bus master and
is used to communication with one or more PMIC (slave) devices on the
SPMI bus. The PMIC Arbiter is actually a hardware wrapper around the
SPMI controller that provides concurrent and autonomous PMIC acces
The Qualcomm PMIC Arbiter, in addition to being a basic SPMI controller,
also implements interrupt handling for slave devices. Note, this is
outside the scope of SPMI, as SPMI leaves interrupt handling completely
unspecified.
Extend the driver to provide a irq_chip implementation and chained irq
The System Power Management Interface (SPMI) is a high-speed,
low-latency, bi-directional, two-wire serial bus suitable for real-time
control of voltage and frequency scaled multi-core application
processors and its power management of auxiliary components. SPMI
obsoletes a number of legacy, custom
Signed-off-by: Josh Cartwright
---
Documentation/devicetree/bindings/spmi/spmi.txt | 41 +
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spmi/spmi.txt
diff --git a/Documentation/devicetree/bindings/spmi/spmi.txt
b/Documentation/de
SPMI states that a slave may contain two register spaces, the Base
register space is a 5-bit byte-addressable space accessed via the
Register Read/Write and Register Zero Write command sequences, and the
Extended register space: a 16-bit byte-addressable space accessed via
the Extended Read/Write a
From: Kenneth Heitke
System Power Management Interface (SPMI) is a specification
developed by the MIPI (Mobile Industry Process Interface) Alliance
optimized for the real time control of Power Management ICs (PMIC).
SPMI is a two-wire serial interface that supports up to 4 master
devices and up
Hello,
On Tue, Jan 14, 2014 at 9:49 PM, Randy Dunlap wrote:
>
> On 01/13/2014 09:51 PM, Stephen Rothwell wrote:
> > Hi all,
> >
> > This tree fails (more than usual) the powerpc allyesconfig build.
> >
> > Changes since 20140113:
> >
>
>
> on i386:
>
> net/built-in.o: In function `header_create'
On Mon, Dec 02, 2013 at 04:20:00PM -0800, David Cohen wrote:
> This patch removes the unnecessary enum for platform type to handle the
> array of pdatas. We can set pdata directly to pci_device_id struct
> instead.
Ping. comments here? :)
Br, David Cohen
>
> Signed-off-by: David Cohen
> ---
>
On Tue, 2014-01-14 at 15:53 -0500, Austin S Hemmelgarn wrote:
> On 2014-01-14 14:50, Eric Dumazet wrote:
> > On Tue, 2014-01-14 at 14:22 -0500, Austin S Hemmelgarn wrote:
> >
> >> I disagree with the statement that current CPU's have reasonably fast
> >> dividers. A lot of embedded processors and
Hello.
On 12/14/2013 02:24 AM, Sergei Shtylyov wrote:
File names in the heading comments fell out of favor long ago, and this one
weren't even changed when the driver was moved from arch/arm/common/, so remove
it at last...
Signed-off-by: Sergei Shtylyov
---
The patch is against the 'ir
On 14 January 2014 23:13, Nishanth Menon wrote:
> On Tue, Jan 14, 2014 at 3:03 PM, Santosh Shilimkar
> wrote:
>>
>>> ok.. some sort of Linaro thing about which I have no background about
>>> - but dont really care in this context.
>>>
>> Nothing related Linaro. Its just that platforms are support
On 14/01/06, William Roberts wrote:
> During an audit event, cache and print the value of the process's
> cmdline value (proc//cmdline). This is useful in situations
> where processes are started via fork'd virtual machines where the
> comm field is incorrect. Often times, setting the comm field st
On Tuesday, January 14, 2014 03:18:08 PM Chuansheng Liu wrote:
>
> Currently, the dpm_resume_noirq() is done synchronously, and for PCI devices
> pci_pm_resume_noirq():
>
> pci_pm_resume_noirq()
> pci_pm_default_resume_early()
> pci_power_up()
>pci_raw_set_power_state()
> Which set the dev
On Tue, Jan 14, 2014 at 10:07:05AM -0800, Eric Dumazet wrote:
> On Mon, 2014-01-13 at 22:42 +0100, Hannes Frederic Sowa wrote:
> > This patch is a RFC and part of a series Daniel Borkmann and me want to
> > do when introducing prandom_u32_range{,_ro} and prandom_u32_max{,_ro}
> > helpers later this
On Mon, Dec 16, 2013 at 12:07:35PM -0800, David Cohen wrote:
> Hi,
>
> I've a bunch of Intel MID patches under review but it seems they are becoming
> old and start to need changes.
> I gathered an up-to-date version of all of them in this single patch set.
>
> This series implements support of C
201 - 300 of 909 matches
Mail list logo