user/sven/linux.git/arch, branch v3.6.5

x86, mm: Use memblock memory loop instead of e820_RAM

2012-10-31T17:10:32Z

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 Link: http://lkml.kernel.org/r/CAE9FiQVZirvaBMFYRfXMmWEcHbKSicQEHz4VAwUv0xFCk51ZNw@mail.gmail.com Acked-by: Jacob Shin Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman

x86: efi: Turn off efi_enabled after setup on mixed fw/kernel

2012-10-31T17:10:31Z

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 Reported-by: Maxim Kammerer Signed-off-by: Olof Johansson Acked-by: Maarten Lankhorst Cc: Matthew Garrett Signed-off-by: Matt Fleming Signed-off-by: Greg Kroah-Hartman

efi: Defer freeing boot services memory until after ACPI init

2012-10-31T17:10:31Z

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 Link: http://lkml.kernel.org/r/baaa6d44bdc4eb0c58e5d1b4ccd2c729f854ac55.1348876882.git.josh@joshtriplett.org Signed-off-by: H. Peter Anvin Cc: Matt Fleming Signed-off-by: Greg Kroah-Hartman

x86, mm: Undo incorrect revert in arch/x86/mm/init.c

2012-10-31T17:10:31Z

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 Link: http://lkml.kernel.org/r/CAE9FiQW_vuaYQbmagVnxT2DGsYc=9tNeAbdBq53sYkitPOwxSQ@mail.gmail.com Acked-by: Jacob Shin Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman

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

2012-10-31T17:10:23Z

commit 844ab6f993b1d32eb40512503d35ff6ad0c57030 upstream. Current logic finds enough space for direct mapping page tables from 0 to end. Instead, we only need to find enough space to cover mr[0].start to mr[nr_range].end -- the range that is actually being mapped by init_memory_mapping() This is needed after 1bbbbe779aabe1f0768c2bf8f8c0a5583679b54a, to address the panic reported here: https://lkml.org/lkml/2012/10/20/160 https://lkml.org/lkml/2012/10/21/157 Signed-off-by: Jacob Shin Link: http://lkml.kernel.org/r/20121024195311.GB11779@jshin-Toonie Tested-by: Tom Rini Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman

ARM: at91: fix external interrupt specification in board code

2012-10-31T17:10:19Z

commit 69e7ea04c9365626c0963ff09bbaa3a1b49e293a upstream. Since the switch to sparse irq, we have to add the NR_IRQS_LEGACY offset to static irq numbers. It has been forgotten on these SPI irq definitions in board code. Signed-off-by: Nicolas Ferre Acked-by: Jean-Christophe PLAGNIOL-VILLARD Acked-by: Ludovic Desroches Signed-off-by: Greg Kroah-Hartman

ARM: at91: fix external interrupts in non-DT case

2012-10-31T17:10:19Z

commit 738a0fd752dc60e20beeda6f2f0f62e58dc0e344 upstream. Management of external interrupts has changed but the non-DT code has not integrated these changes. Add a mask to pass external irq specification from SoC specific code to the at91_aic_init() function. Signed-off-by: Nicolas Ferre Acked-by: Jean-Christophe PLAGNIOL-VILLARD Acked-by: Ludovic Desroches Signed-off-by: Greg Kroah-Hartman

ARM: at91: at91sam9g10: fix SOC type detection

2012-10-31T17:10:19Z

commit 3d9a0183dd3423353e9e363bcc261c1220d05f9f upstream. Newer at91sam9g10 SoC revision can't be detected, so the kernel can't boot with this kind of kernel panic: "AT91: Impossible to detect the SOC type" CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177 CPU: VIVT data cache, VIVT instruction cache Machine: Atmel AT91SAM9G10-EK Ignoring tag cmdline (using the default kernel command line) bootconsole [earlycon0] enabled Memory policy: ECC disabled, Data cache writeback Kernel panic - not syncing: AT91: Impossible to detect the SOC type [] (unwind_backtrace+0x0/0xe0) from [] (panic+0x78/0x1cc) [] (panic+0x78/0x1cc) from [] (at91_map_io+0x90/0xc8) [] (at91_map_io+0x90/0xc8) from [] (paging_init+0x564/0x6d0) [] (paging_init+0x564/0x6d0) from [] (setup_arch+0x464/0x704) [] (setup_arch+0x464/0x704) from [] (start_kernel+0x6c/0x2d4) [] (start_kernel+0x6c/0x2d4) from [<20008040>] (0x20008040) The reason for this is that the Debug Unit Chip ID Register has changed between Engineering Sample and definitive revision of the SoC. Changing the check of cidr to socid will address the problem. We do not integrate this check to the list just above because we also have to make sure that the extended id is disregarded. Signed-off-by: Ivan Shugov [nicolas.ferre@atmel.com: change commit message] Signed-off-by: Nicolas Ferre Acked-by: Jean-Christophe PLAGNIOL-VILLARD Signed-off-by: Greg Kroah-Hartman

ARM: at91/i2c: change id to let i2c-gpio work

2012-10-31T17:10:19Z

commit 7840487cd6298f9f931103b558290d8d98d41c49 upstream. The i2c core driver will turn the platform device ID to busnum When using platfrom device ID as -1, it means dynamically assigned the busnum. When writing code, we need to make sure the busnum, and call i2c_register_board_info(int busnum, ...) to register device if using -1, we do not know the value of busnum In order to solve this issue, set the platform device ID as a fix number Here using 0 to match the busnum used in i2c_regsiter_board_info() Signed-off-by: Bo Shen Acked-by: Jean Delvare Signed-off-by: Nicolas Ferre Acked-by: Jean-Christophe PLAGNIOL-VILLARD Acked-by: Ludovic Desroches Signed-off-by: Greg Kroah-Hartman

ARM: SAMSUNG: Add naming of s3c64xx-spi devices

2012-10-31T17:10:18Z

commit 308b3afb97dc342e9c4f958d8b4c459ae0e22bd7 upstream. Commit a5238e360b71 (spi: s3c64xx: move controller information into driver data) introduced separate device names for the different subtypes of the spi controller but forgot to set these in the relevant machines. To fix this introduce a s3c64xx_spi_setname function and populate all Samsung arches with the correct names. The function resides in a new header, as the s3c64xx-spi.h contains driver platform data and should therefore at some later point move out of the Samsung include dir. Tested on a s3c2416-based machine. Signed-off-by: Heiko Stuebner Reviewed-by: Sylwester Nawrocki [s.nawrocki@samsung.com: tested on mach-exynos] Tested-by: Sylwester Nawrocki Signed-off-by: Kukjin Kim Signed-off-by: Greg Kroah-Hartman