linux-toradex.git/arch, branch v3.3.5 Linux kernel for Apalis and Colibri modules powerpc/85xx: don't call of_platform_bus_probe() twice 2012-05-07T15:53:35+00:00 Timur Tabi timur@freescale.com 2011-11-30T16:19:17+00:00 da42136018f3a2e187ab1976f7f0a5768c3bda24 commit 8a95bc8dfe06982fc2b8a0a2adda7baa2346a17b upstream. Commit 46d026ac ("powerpc/85xx: consolidate of_platform_bus_probe calls") replaced platform-specific of_device_id tables with a single function that probes the most of the busses in 85xx device trees. If a specific platform needed additional busses probed, then it could call of_platform_bus_probe() again. Typically, the additional platform-specific busses are children of existing busses that have already been probed. of_platform_bus_probe() does not handle those child busses automatically. Unfortunately, this doesn't actually work. The second (platform-specific) call to of_platform_bus_probe() never finds any of the busses it's asked to find. To remedy this, the platform-specific of_device_id tables are eliminated, and their entries are merged into mpc85xx_common_ids[], so that all busses are probed at once. Signed-off-by: Timur Tabi <timur@freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 8a95bc8dfe06982fc2b8a0a2adda7baa2346a17b upstream.

Commit 46d026ac ("powerpc/85xx: consolidate of_platform_bus_probe calls")
replaced platform-specific of_device_id tables with a single function
that probes the most of the busses in 85xx device trees.  If a specific
platform needed additional busses probed, then it could call
of_platform_bus_probe() again.  Typically, the additional platform-specific
busses are children of existing busses that have already been probed.
of_platform_bus_probe() does not handle those child busses automatically.

Unfortunately, this doesn't actually work.  The second (platform-specific)
call to of_platform_bus_probe() never finds any of the busses it's asked
to find.

To remedy this, the platform-specific of_device_id tables are eliminated,
and their entries are merged into mpc85xx_common_ids[], so that all busses
are probed at once.

Signed-off-by: Timur Tabi <timur@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
x86, efi: Add dedicated EFI stub entry point 2012-05-07T15:53:35+00:00 Matt Fleming matt.fleming@intel.com 2012-04-15T15:06:04+00:00 50d61918ff77bd2e0355c124e73595cdea3fa177 commit b1994304fc399f5d3a5368c81111d713490c4799 upstream. The method used to work out whether we were booted by EFI firmware or via a boot loader is broken. Because efi_main() is always executed when booting from a boot loader we will dereference invalid pointers either on the stack (CONFIG_X86_32) or contained in %rdx (CONFIG_X86_64) when searching for an EFI System Table signature. Instead of dereferencing these invalid system table pointers, add a new entry point that is only used when booting from EFI firmware, when we know the pointer arguments will be valid. With this change legacy boot loaders will no longer execute efi_main(), but will instead skip EFI stub initialisation completely. [ hpa: Marking this for urgent/stable since it is a regression when the option is enabled; without the option the patch has no effect ] Signed-off-by: Matt Fleming <matt.hfleming@intel.com> Link: http://lkml.kernel.org/r/1334584744.26997.14.camel@mfleming-mobl1.ger.corp.intel.com Reported-by: Jordan Justen <jordan.l.justen@intel.com> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit b1994304fc399f5d3a5368c81111d713490c4799 upstream.

The method used to work out whether we were booted by EFI firmware or
via a boot loader is broken. Because efi_main() is always executed
when booting from a boot loader we will dereference invalid pointers
either on the stack (CONFIG_X86_32) or contained in %rdx
(CONFIG_X86_64) when searching for an EFI System Table signature.

Instead of dereferencing these invalid system table pointers, add a
new entry point that is only used when booting from EFI firmware, when
we know the pointer arguments will be valid. With this change legacy
boot loaders will no longer execute efi_main(), but will instead skip
EFI stub initialisation completely.

[ hpa: Marking this for urgent/stable since it is a regression when
  the option is enabled; without the option the patch has no effect ]

Signed-off-by: Matt Fleming <matt.hfleming@intel.com>
Link: http://lkml.kernel.org/r/1334584744.26997.14.camel@mfleming-mobl1.ger.corp.intel.com
Reported-by: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
x86, boot: Correct CFLAGS for hostprogs 2012-05-07T15:53:35+00:00 H. Peter Anvin hpa@zytor.com 2012-03-22T18:08:18+00:00 7229d3aea8bd7b60eaad158c2b9e749fff41940b commit 446e1c86d51d0823e003a43a2b85c430efce2733 upstream. This is a partial revert of commit: d40f833 "Restrict CFLAGS for hostprogs" The endian-manipulation macros in tools/include need <linux/types.h>, but the hostprogs in arch/x86/boot need several headers from the kernel build tree, which means we have to add the kernel headers to the include path. This picks up <linux/types.h> from the kernel tree, which gives a warning. Since this use of <linux/types.h> is intentional, add -D__EXPORTED_HEADERS__ to the command line to silence the warning. A better way to fix this would be to always install the exported kernel headers into $(objtree)/usr/include as a standard part of the kernel build, but that is a lot more involved. Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Acked-by: Matt Fleming <matt.fleming@intel.com> Link: http://lkml.kernel.org/r/1330436245-24875-5-git-send-email-matt@console-pimps.org Signed-off-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 446e1c86d51d0823e003a43a2b85c430efce2733 upstream.

This is a partial revert of commit:
    d40f833 "Restrict CFLAGS for hostprogs"

The endian-manipulation macros in tools/include need <linux/types.h>,
but the hostprogs in arch/x86/boot need several headers from the
kernel build tree, which means we have to add the kernel headers to
the include path.  This picks up <linux/types.h> from the kernel tree,
which gives a warning.

Since this use of <linux/types.h> is intentional, add
-D__EXPORTED_HEADERS__ to the command line to silence the warning.

A better way to fix this would be to always install the exported
kernel headers into $(objtree)/usr/include as a standard part of the
kernel build, but that is a lot more involved.

Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1330436245-24875-5-git-send-email-matt@console-pimps.org
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
x86, efi: Fix endian issues and unaligned accesses 2012-05-07T15:53:35+00:00 Matt Fleming matt.fleming@intel.com 2012-02-28T13:37:24+00:00 82c4c5d001608a9a3194bdf74fba824e1c2ec686 commit 92f42c50f227ad228f815a8f4eec872524dae3a5 upstream. We may need to convert the endianness of the data we read from/write to 'buf', so let's use {get,put}_unaligned_le32() to do that. Failure to do so can result in accessing invalid memory, leading to a segfault. Stephen Rothwell noticed this bug while cross-building an x86_64 allmodconfig kernel on PowerPC. We need to read from and write to 'buf' a byte at a time otherwise it's possible we'll perform an unaligned access, which can lead to bus errors when cross-building an x86 kernel on risc architectures. Cc: H. Peter Anvin <hpa@zytor.com> Cc: Nick Bowler <nbowler@elliptictech.com> Tested-by: Stephen Rothwell <sfr@canb.auug.org.au> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Matt Fleming <matt.fleming@intel.com> Link: http://lkml.kernel.org/r/1330436245-24875-6-git-send-email-matt@console-pimps.org Signed-off-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 92f42c50f227ad228f815a8f4eec872524dae3a5 upstream.

We may need to convert the endianness of the data we read from/write
to 'buf', so let's use {get,put}_unaligned_le32() to do that. Failure
to do so can result in accessing invalid memory, leading to a
segfault.  Stephen Rothwell noticed this bug while cross-building an
x86_64 allmodconfig kernel on PowerPC.

We need to read from and write to 'buf' a byte at a time otherwise
it's possible we'll perform an unaligned access, which can lead to bus
errors when cross-building an x86 kernel on risc architectures.

Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Nick Bowler <nbowler@elliptictech.com>
Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1330436245-24875-6-git-send-email-matt@console-pimps.org
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
x86, boot: Restrict CFLAGS for hostprogs 2012-05-07T15:53:35+00:00 Matt Fleming matt.fleming@intel.com 2012-02-28T13:37:23+00:00 aa703cc83786fabab0058713a424d5201e29dde2 commit d40f833630a1299fd377408dc8d8fac370d621b0 upstream. Currently tools/build has access to all the kernel headers in $(srctree). This is unnecessary and could potentially allow tools/build to erroneously include kernel headers when it should only be including userspace-exported headers. Unfortunately, mkcpustr still needs access to some of the asm kernel headers, so explicitly special case that hostprog. Cc: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com> Link: http://lkml.kernel.org/r/1330436245-24875-5-git-send-email-matt@console-pimps.org Signed-off-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit d40f833630a1299fd377408dc8d8fac370d621b0 upstream.

Currently tools/build has access to all the kernel headers in
$(srctree). This is unnecessary and could potentially allow
tools/build to erroneously include kernel headers when it should only
be including userspace-exported headers.

Unfortunately, mkcpustr still needs access to some of the asm kernel
headers, so explicitly special case that hostprog.

Cc: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1330436245-24875-5-git-send-email-matt@console-pimps.org
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
x86, mkpiggy: Don't open code put_unaligned_le32() 2012-05-07T15:53:34+00:00 Matt Fleming matt.fleming@intel.com 2012-02-28T13:37:22+00:00 24eba790c0dae612b499a77e736fb11cc8e81a9c commit 12871c568305a0b20f116315479a18cd46882e9b upstream. Use the new headers in tools/include instead of rolling our own put_unaligned_le32() implementation. Cc: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com> Link: http://lkml.kernel.org/r/1330436245-24875-4-git-send-email-matt@console-pimps.org Signed-off-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 12871c568305a0b20f116315479a18cd46882e9b upstream.

Use the new headers in tools/include instead of rolling our own
put_unaligned_le32() implementation.

Cc: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1330436245-24875-4-git-send-email-matt@console-pimps.org
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
x86, efi: Fix pointer math issue in handle_ramdisks() 2012-05-07T15:53:34+00:00 Dan Carpenter dan.carpenter@oracle.com 2012-03-05T18:06:14+00:00 1b4071cc8b463c7e98652d28e8a7535b7602c481 commit c7b738351ba92f48b943ac59aff6b5b0f17f37c9 upstream. "filename" is a efi_char16_t string so this check for reaching the end of the array doesn't work. We need to cast the pointer to (u8 *) before doing the math. This patch changes the "filename" to "filename_16" to avoid confusion in the future. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: http://lkml.kernel.org/r/20120305180614.GA26880@elgon.mountain Acked-by: Matt Fleming <matt.fleming@intel.com> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit c7b738351ba92f48b943ac59aff6b5b0f17f37c9 upstream.

"filename" is a efi_char16_t string so this check for reaching the end
of the array doesn't work.  We need to cast the pointer to (u8 *) before
doing the math.

This patch changes the "filename" to "filename_16" to avoid confusion in
the future.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: http://lkml.kernel.org/r/20120305180614.GA26880@elgon.mountain
Acked-by: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
MIPS: ath79: fix AR933X WMAC reset code 2012-05-07T15:53:25+00:00 Gabor Juhos juhosg@openwrt.org 2012-03-14T09:28:35+00:00 be443a52b085a10b696e7abc26524e709839e8d1 commit de14ca6ae2c592d66db88f1e5596b26f7f011384 upstream. The current code puts the built-in WMAC device of the AR933X SoCs into reset instead of starting it. This causes a hard lock on AR933X based boards when the wireless driver tries to access the device. Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/3484/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit de14ca6ae2c592d66db88f1e5596b26f7f011384 upstream.

The current code puts the built-in WMAC device of the
AR933X SoCs into reset instead of starting it. This
causes a hard lock on AR933X based boards when the
wireless driver tries to access the device.

Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/3484/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARM: 7406/1: hotplug: copy the affinity mask when forcefully migrating IRQs 2012-05-07T15:53:24+00:00 Will Deacon will.deacon@arm.com 2012-04-27T11:56:24+00:00 d2375bc5f69b8a76b3b706c92d90b5d772dc4c97 commit 5e7371ded05adfcfcee44a8bc070bfc37979b8f2 upstream. When a CPU is hotplugged off, we migrate any IRQs currently affine to it away and onto another online CPU by calling the irq_set_affinity function of the relevant interrupt controller chip. This function returns either IRQ_SET_MASK_OK or IRQ_SET_MASK_OK_NOCOPY, to indicate whether irq_data.affinity was updated. If we are forcefully migrating an interrupt (because the affinity mask no longer identifies any online CPUs) then we should update the IRQ affinity mask to reflect the new CPU set. Failure to do so can potentially leave /proc/irq/n/smp_affinity identifying only offline CPUs, which may confuse userspace IRQ balancing daemons. This patch updates migrate_one_irq to copy the affinity mask when the interrupt chip returns IRQ_SET_MASK_OK after forcefully changing the affinity of an interrupt. Reported-by: Leif Lindholm <leif.lindholm@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 5e7371ded05adfcfcee44a8bc070bfc37979b8f2 upstream.

When a CPU is hotplugged off, we migrate any IRQs currently affine to it
away and onto another online CPU by calling the irq_set_affinity
function of the relevant interrupt controller chip. This function
returns either IRQ_SET_MASK_OK or IRQ_SET_MASK_OK_NOCOPY, to indicate
whether irq_data.affinity was updated.

If we are forcefully migrating an interrupt (because the affinity mask
no longer identifies any online CPUs) then we should update the IRQ
affinity mask to reflect the new CPU set. Failure to do so can
potentially leave /proc/irq/n/smp_affinity identifying only offline
CPUs, which may confuse userspace IRQ balancing daemons.

This patch updates migrate_one_irq to copy the affinity mask when
the interrupt chip returns IRQ_SET_MASK_OK after forcefully changing the
affinity of an interrupt.

Reported-by: Leif Lindholm <leif.lindholm@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARM: 7403/1: tls: remove covert channel via TPIDRURW 2012-05-07T15:53:24+00:00 Will Deacon will.deacon@arm.com 2012-04-27T11:45:07+00:00 6938679dad4f018f1ddd1936de202028b8d9baac commit 6a1c53124aa161eb624ce7b1e40ade728186d34c upstream. TPIDRURW is a user read/write register forming part of the group of thread registers in more recent versions of the ARM architecture (~v6+). Currently, the kernel does not touch this register, which allows tasks to communicate covertly by reading and writing to the register without context-switching affecting its contents. This patch clears TPIDRURW when TPIDRURO is updated via the set_tls macro, which is called directly from __switch_to. Since the current behaviour makes the register useless to userspace as far as thread pointers are concerned, simply clearing the register (rather than saving and restoring it) will not cause any problems to userspace. Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 6a1c53124aa161eb624ce7b1e40ade728186d34c upstream.

TPIDRURW is a user read/write register forming part of the group of
thread registers in more recent versions of the ARM architecture (~v6+).

Currently, the kernel does not touch this register, which allows tasks
to communicate covertly by reading and writing to the register without
context-switching affecting its contents.

This patch clears TPIDRURW when TPIDRURO is updated via the set_tls
macro, which is called directly from __switch_to. Since the current
behaviour makes the register useless to userspace as far as thread
pointers are concerned, simply clearing the register (rather than saving
and restoring it) will not cause any problems to userspace.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>