<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/arch, branch v3.4.20</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/arch?h=v3.4.20</id>
<link rel='self' href='https://git.amat.us/linux/atom/arch?h=v3.4.20'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2012-11-26T19:38:44Z</updated>
<entry>
<title>Revert "serial: omap: fix software flow control"</title>
<updated>2012-11-26T19:38:44Z</updated>
<author>
<name>Felipe Balbi</name>
<email>balbi@ti.com</email>
</author>
<published>2012-10-16T14:09:22Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=51b8318a818623899f9eb24ce697d43301bbe349'/>
<id>urn:sha1:51b8318a818623899f9eb24ce697d43301bbe349</id>
<content type='text'>
commit a4f743851f74fc3e0cc40c13082e65c24139f481 upstream.

This reverts commit 957ee7270d632245b43f6feb0e70d9a5e9ea6cf6
(serial: omap: fix software flow control).

As Russell has pointed out, that commit isn't fixing
Software Flow Control at all, and it actually makes
it even more broken.

It was agreed to revert this commit and use Russell's
latest UART patches instead.

Signed-off-by: Felipe Balbi &lt;balbi@ti.com&gt;
Cc: Russell King &lt;linux@arm.linux.org.uk&gt;
Acked-by: Tony Lindgren &lt;tony@atomide.com&gt;
Cc: Andreas Bießmann &lt;andreas.devel@googlemail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>s390/signal: set correct address space control</title>
<updated>2012-11-26T19:38:01Z</updated>
<author>
<name>Martin Schwidefsky</name>
<email>schwidefsky@de.ibm.com</email>
</author>
<published>2012-11-07T09:44:08Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=37a42f991f36aae9b064bc3f39b760006bd17131'/>
<id>urn:sha1:37a42f991f36aae9b064bc3f39b760006bd17131</id>
<content type='text'>
commit fa968ee215c0ca91e4a9c3a69ac2405aae6e5d2f upstream.

If user space is running in primary mode it can switch to secondary
or access register mode, this is used e.g. in the clock_gettime code
of the vdso. If a signal is delivered to the user space process while
it has been running in access register mode the signal handler is
executed in access register mode as well which will result in a crash
most of the time.

Set the address space control bits in the PSW to the default for the
execution of the signal handler and make sure that the previous
address space control is restored on signal return. Take care
that user space can not switch to the kernel address space by
modifying the registers in the signal frame.

Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>m68k: fix sigset_t accessor functions</title>
<updated>2012-11-26T19:37:46Z</updated>
<author>
<name>Andreas Schwab</name>
<email>schwab@linux-m68k.org</email>
</author>
<published>2012-11-17T21:27:04Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=999d6a5194c9707b081869f40306ac5e1727edf4'/>
<id>urn:sha1:999d6a5194c9707b081869f40306ac5e1727edf4</id>
<content type='text'>
commit 34fa78b59c52d1db3513db4c1a999db26b2e9ac2 upstream.

The sigaddset/sigdelset/sigismember functions that are implemented with
bitfield insn cannot allow the sigset argument to be placed in a data
register since the sigset is wider than 32 bits.  Remove the "d"
constraint from the asm statements.

The effect of the bug is that sending RT signals does not work, the signal
number is truncated modulo 32.

Signed-off-by: Andreas Schwab &lt;schwab@linux-m68k.org&gt;
Signed-off-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>s390/gup: add missing TASK_SIZE check to get_user_pages_fast()</title>
<updated>2012-11-26T19:37:44Z</updated>
<author>
<name>Heiko Carstens</name>
<email>heiko.carstens@de.ibm.com</email>
</author>
<published>2012-10-22T13:49:02Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=3e31ee155e0963e42bb02d33a2a9e44d5b91a45b'/>
<id>urn:sha1:3e31ee155e0963e42bb02d33a2a9e44d5b91a45b</id>
<content type='text'>
commit d55c4c613fc4d4ad2ba0fc6fa2b57176d420f7e4 upstream.

When walking page tables we need to make sure that everything
is within bounds of the ASCE limit of the task's address space.
Otherwise we might calculate e.g. a pud pointer which is not
within a pud and dereference it.
So check against TASK_SIZE (which is the ASCE limit) before
walking page tables.

Reviewed-by: Gerald Schaefer &lt;gerald.schaefer@de.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>xen/mmu: Use Xen specific TLB flush instead of the generic one.</title>
<updated>2012-11-17T21:15:54Z</updated>
<author>
<name>Konrad Rzeszutek Wilk</name>
<email>konrad.wilk@oracle.com</email>
</author>
<published>2012-10-31T16:38:31Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=da205c80275a7f7a90c2baab423783c55c406878'/>
<id>urn:sha1:da205c80275a7f7a90c2baab423783c55c406878</id>
<content type='text'>
commit 95a7d76897c1e7243d4137037c66d15cbf2cce76 upstream.

As Mukesh explained it, the MMUEXT_TLB_FLUSH_ALL allows the
hypervisor to do a TLB flush on all active vCPUs. If instead
we were using the generic one (which ends up being xen_flush_tlb)
we end up making the MMUEXT_TLB_FLUSH_LOCAL hypercall. But
before we make that hypercall the kernel will IPI all of the
vCPUs (even those that were asleep from the hypervisor
perspective). The end result is that we needlessly wake them
up and do a TLB flush when we can just let the hypervisor
do it correctly.

This patch gives around 50% speed improvement when migrating
idle guest's from one host to another.

Oracle-bug: 14630170

Tested-by:  Jingjie Jiang &lt;jingjie.jiang@oracle.com&gt;
Suggested-by:  Mukesh Rathor &lt;mukesh.rathor@oracle.com&gt;
Signed-off-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Revert: ARM: SAMSUNG: Add naming of s3c64xx-spi devices</title>
<updated>2012-11-05T08:50:42Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2012-10-17T07:47:11Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=0b1743f0b0e1f8db0be800c301c0cf83add46fe9'/>
<id>urn:sha1:0b1743f0b0e1f8db0be800c301c0cf83add46fe9</id>
<content type='text'>
This reverts commit baa526f45d3f096a1cd9f14b668203a03bbab6f9, which is 
commit 308b3afb97dc342e9c4f958d8b4c459ae0e22bd7 upstream.

To quote Colin Cross:
	This patch breaks Exynos5 spi on 3.4.17.  The patch with the bug
	that this patch was supposed to address went in to 3.6 and not
	3.4, so this patch causes a driver name mismatch when applied to
	3.4.


Cc: Colin Cross &lt;ccross@google.com&gt;
Cc: Heiko Stuebner &lt;heiko@sntech.de&gt;
Cc: Sylwester Nawrocki &lt;s.nawrocki@samsung.com&gt;
Cc: Kukjin Kim &lt;kgene.kim@samsung.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>x86, mm: Use memblock memory loop instead of e820_RAM</title>
<updated>2012-10-31T17:03:19Z</updated>
<author>
<name>Yinghai Lu</name>
<email>yinghai@kernel.org</email>
</author>
<published>2012-10-22T23:35:18Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=0187c24809c9590412c0112dab88f28621a961ed'/>
<id>urn:sha1:0187c24809c9590412c0112dab88f28621a961ed</id>
<content type='text'>
commit 1f2ff682ac951ed82cc043cf140d2851084512df upstream.

We need to handle E820_RAM and E820_RESERVED_KERNEL at the same time.

Also memblock has page aligned range for ram, so we could avoid mapping
partial pages.

Signed-off-by: Yinghai Lu &lt;yinghai@kernel.org&gt;
Link: http://lkml.kernel.org/r/CAE9FiQVZirvaBMFYRfXMmWEcHbKSicQEHz4VAwUv0xFCk51ZNw@mail.gmail.com
Acked-by: Jacob Shin &lt;jacob.shin@amd.com&gt;
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>x86: efi: Turn off efi_enabled after setup on mixed fw/kernel</title>
<updated>2012-10-31T17:03:19Z</updated>
<author>
<name>Olof Johansson</name>
<email>olof@lixom.net</email>
</author>
<published>2012-10-24T17:00:44Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=775dc1a3fd51abc6e459aa92e049fd3687b66c2f'/>
<id>urn:sha1:775dc1a3fd51abc6e459aa92e049fd3687b66c2f</id>
<content type='text'>
commit 5189c2a7c7769ee9d037d76c1a7b8550ccf3481c upstream.

When 32-bit EFI is used with 64-bit kernel (or vice versa), turn off
efi_enabled once setup is done. Beyond setup, it is normally used to
determine if runtime services are available and we will have none.

This will resolve issues stemming from efivars modprobe panicking on a
32/64-bit setup, as well as some reboot issues on similar setups.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45991

Reported-by: Marko Kohtala &lt;marko.kohtala@gmail.com&gt;
Reported-by: Maxim Kammerer &lt;mk@dee.su&gt;
Signed-off-by: Olof Johansson &lt;olof@lixom.net&gt;
Acked-by: Maarten Lankhorst &lt;maarten.lankhorst@canonical.com&gt;
Cc: Matthew Garrett &lt;mjg@redhat.com&gt;
Signed-off-by: Matt Fleming &lt;matt.fleming@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>efi: Defer freeing boot services memory until after ACPI init</title>
<updated>2012-10-31T17:03:18Z</updated>
<author>
<name>Josh Triplett</name>
<email>josh@joshtriplett.org</email>
</author>
<published>2012-09-29T00:55:44Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=a57a57aea0ad2ced60a8aa59d49fe542f23efb72'/>
<id>urn:sha1:a57a57aea0ad2ced60a8aa59d49fe542f23efb72</id>
<content type='text'>
commit 785107923a83d8456bbd8564e288a24d84109a46 upstream.

Some new ACPI 5.0 tables reference resources stored in boot services
memory, so keep that memory around until we have ACPI and can extract
data from it.

Signed-off-by: Josh Triplett &lt;josh@joshtriplett.org&gt;
Link: http://lkml.kernel.org/r/baaa6d44bdc4eb0c58e5d1b4ccd2c729f854ac55.1348876882.git.josh@joshtriplett.org
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Cc: Matt Fleming &lt;matt@console-pimps.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>x86, mm: Undo incorrect revert in arch/x86/mm/init.c</title>
<updated>2012-10-31T17:03:18Z</updated>
<author>
<name>Yinghai Lu</name>
<email>yinghai@kernel.org</email>
</author>
<published>2012-10-25T22:45:26Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=7a32a0b9985742493575ffa1c6fedf043d966708'/>
<id>urn:sha1:7a32a0b9985742493575ffa1c6fedf043d966708</id>
<content type='text'>
commit f82f64dd9f485e13f29f369772d4a0e868e5633a upstream.

Commit

    844ab6f9 x86, mm: Find_early_table_space based on ranges that are actually being mapped

added back some lines back wrongly that has been removed in commit

    7b16bbf97 Revert "x86/mm: Fix the size calculation of mapping tables"

remove them again.

Signed-off-by: Yinghai Lu &lt;yinghai@kernel.org&gt;
Link: http://lkml.kernel.org/r/CAE9FiQW_vuaYQbmagVnxT2DGsYc=9tNeAbdBq53sYkitPOwxSQ@mail.gmail.com
Acked-by: Jacob Shin &lt;jacob.shin@amd.com&gt;
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
