user/sven/linux.git/arch, branch v4.4.10

ACPI / processor: Request native thermal interrupt handling via _OSC

2016-05-11T09:21:26Z

commit a21211672c9a1d730a39aa65d4a5b3414700adfb upstream. There are several reports of freeze on enabling HWP (Hardware PStates) feature on Skylake-based systems by the Intel P-states driver. The root cause is identified as the HWP interrupts causing BIOS code to freeze. HWP interrupts use the thermal LVT which can be handled by Linux natively, but on the affected Skylake-based systems SMM will respond to it by default. This is a problem for several reasons: - On the affected systems the SMM thermal LVT handler is broken (it will crash when invoked) and a BIOS update is necessary to fix it. - With thermal interrupt handled in SMM we lose all of the reporting features of the arch/x86/kernel/cpu/mcheck/therm_throt driver. - Some thermal drivers like x86-package-temp depend on the thermal threshold interrupts signaled via the thermal LVT. - The HWP interrupts are useful for debugging and tuning performance (if the kernel can handle them). The native handling of thermal interrupts needs to be enabled because of that. This requires some way to tell SMM that the OS can handle thermal interrupts. That can be done by using _OSC/_PDC in processor scope very early during ACPI initialization. The meaning of _OSC/_PDC bit 12 in processor scope is whether or not the OS supports native handling of interrupts for Collaborative Processor Performance Control (CPPC) notifications. Since on HWP-capable systems CPPC is a firmware interface to HWP, setting this bit effectively tells the firmware that the OS will handle thermal interrupts natively going forward. For details on _OSC/_PDC refer to: http://www.intel.com/content/www/us/en/standards/processor-vendor-specific-acpi-specification.html To implement the _OSC/_PDC handshake as described, introduce a new function, acpi_early_processor_osc(), that walks the ACPI namespace looking for ACPI processor objects and invokes _OSC for them with bit 12 in the capabilities buffer set and terminates the namespace walk on the first success. Also modify intel_thermal_interrupt() to clear HWP status bits in the HWP_STATUS MSR to acknowledge HWP interrupts (which prevents them from firing continuously). Signed-off-by: Srinivas Pandruvada [ rjw: Subject & changelog, function rename ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

powerpc: Fix bad inline asm constraint in create_zero_mask()

2016-05-11T09:21:20Z

commit b4c112114aab9aff5ed4568ca5e662bb02cdfe74 upstream. In create_zero_mask() we have: addi %1,%2,-1 andc %1,%1,%2 popcntd %0,%1 using the "r" constraint for %2. r0 is a valid register in the "r" set, but addi X,r0,X turns it into an li: li r7,-1 andc r7,r7,r0 popcntd r4,r7 Fix this by using the "b" constraint, for which r0 is not a valid register. This was found with a kernel build using gcc trunk, narrowed down to when -frename-registers was enabled at -O2. It is just luck however that we aren't seeing this on older toolchains. Thanks to Segher for working with me to find this issue. Fixes: d0cebfa650a0 ("powerpc: word-at-a-time optimization for 64-bit Little Endian") Signed-off-by: Anton Blanchard Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman

x86/sysfb_efi: Fix valid BAR address range check

2016-05-11T09:21:20Z

commit c10fcb14c7afd6688c7b197a814358fecf244222 upstream. The code for checking whether a BAR address range is valid will break out of the loop when a start address of 0x0 is encountered. This behaviour is wrong since by breaking out of the loop we may miss the BAR that describes the EFI frame buffer in a later iteration. Because of this bug I can't use video=efifb: boot parameter to get efifb on my new ThinkPad E550 for my old linux system hard disk with 3.10 kernel. In 3.10, efifb is the only choice due to DRM/I915 not supporting the GPU. This patch also add a trivial optimization to break out after we find the frame buffer address range without testing later BARs. Signed-off-by: Wang YanQing [ Rewrote changelog. ] Signed-off-by: Matt Fleming Reviewed-by: Peter Jones Cc: Ard Biesheuvel Cc: David Herrmann Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Tomi Valkeinen Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/1462454061-21561-2-git-send-email-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

ARC: Add missing io barriers to io{read,write}{16,32}be()

2016-05-11T09:21:20Z

commit e5bc0478ab6cf565619224536d75ecb2aedca43b upstream. While reviewing a different change to asm-generic/io.h Arnd spotted that ARC ioread32 and ioread32be both of which come from asm-generic versions are not symmetrical in terms of calling the io barriers. generic ioread32 -> ARC readl() [ has barriers] generic ioread32be -> __be32_to_cpu(__raw_readl()) [ lacks barriers] While generic ioread32be is being remediated to call readl(), that involves a swab32(), causing double swaps on ioread32be() on Big Endian systems. So provide our versions of big endian IO accessors to ensure io barrier calls while also keeping them optimal Suggested-by: Arnd Bergmann Acked-by: Arnd Bergmann Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman

x86/tsc: Read all ratio bits from MSR_PLATFORM_INFO

2016-05-11T09:21:19Z

commit 886123fb3a8656699dff40afa0573df359abeb18 upstream. Currently we read the tsc radio: ratio = (MSR_PLATFORM_INFO >> 8) & 0x1f; Thus we get bit 8-12 of MSR_PLATFORM_INFO, however according to the SDM (35.5), the ratio bits are bit 8-15. Ignoring the upper bits can result in an incorrect tsc ratio, which causes the TSC calibration and the Local APIC timer frequency to be incorrect. Fix this problem by masking 0xff instead. [ tglx: Massaged changelog ] Fixes: 7da7c1561366 "x86, tsc: Add static (MSR) TSC calibration on Intel Atom SoCs" Signed-off-by: Chen Yu Cc: "Rafael J. Wysocki" Cc: Bin Gao Cc: Len Brown Link: http://lkml.kernel.org/r/1462505619-5516-1-git-send-email-yu.c.chen@intel.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman

ARM: SoCFPGA: Fix secondary CPU startup in thumb2 kernel

2016-05-11T09:21:14Z

commit 5616f36713ea77f57ae908bf2fef641364403c9f upstream. The secondary CPU starts up in ARM mode. When the kernel is compiled in thumb2 mode we have to explicitly compile the secondary startup trampoline in ARM mode, otherwise the CPU will go to Nirvana. Signed-off-by: Sascha Hauer Reported-by: Steffen Trumtrar Suggested-by: Ard Biesheuvel Signed-off-by: Dinh Nguyen Signed-off-by: Kevin Hilman Signed-off-by: Greg Kroah-Hartman

ARM: EXYNOS: Properly skip unitialized parent clock in power domain on

2016-05-11T09:21:14Z

commit a0a966b83873f33778710a4fc59240244b0734a5 upstream. We want to skip reparenting a clock on turning on power domain, if we do not have the parent yet. The parent is obtained when turning the domain off. However due to a typo, the loop is continued on IS_ERR() of clock being reparented, not on the IS_ERR() of the parent. Theoretically this could lead to OOPS on first turn on of a power domain, if there was no turn off before. Practically that should never happen because all power domains are turned on by default (reset value, bootloader does not turn off them usually) so the first action will be always turn off. Fixes: 29e5eea06bc1 ("ARM: EXYNOS: Get current parent clock for power domain on/off") Reported-by: Vladimir Zapolskiy Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman

CNS3xxx: Fix PCI cns3xxx_write_config()

2016-05-11T09:21:11Z

commit 88e9da9a2a70b6f1a171fbf30a681d6bc4031c4d upstream. The "where" offset was added twice, fix it. Signed-off-by: Krzysztof Hałasa Fixes: 498a92d42596 ("ARM: cns3xxx: pci: avoid potential stack overflow") Signed-off-by: Olof Johansson Signed-off-by: Greg Kroah-Hartman

Revert: "powerpc/tm: Check for already reclaimed tasks"

2016-05-11T09:21:09Z

This reverts commit e924c60db1b4891e45d15a33474ac5fab62cf029 which was commit 7f821fc9c77a9b01fe7b1d6e72717b33d8d64142 upstream. It shouldn't have been applied as the original was already in 4.4. Reported-by: Jiri Slaby Cc: Michael Neuling Cc: Michael Ellerman Signed-off-by: Greg Kroah-Hartman

ARM: dts: pxa: fix dma engine node to pxa3xx-nand

2016-05-04T21:48:53Z

commit 07c6b2d01d351f0512ed7145625265e435ab3240 upstream. Since the switch from mmp_pdma to pxa_dma driver for pxa architectures, the pxa_dma requires 2 arguments, namely the requestor line and the requested priority. Fix the only left device node which was still passing only one argument, making the pxa3xx-nand driver misbehave in a device-tree configuration, ie. failing all data transfers. Fixes: c943646d1f49 ("ARM: dts: pxa: add dma engine node to pxa3xx-nand") Signed-off-by: Robert Jarzmik Signed-off-by: Greg Kroah-Hartman