summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2018-02-26ARM: omap2: set CONFIG_LIRC=y in defconfigArnd Bergmann1-1/+1
The CONFIG_LIRC symbol has changed from 'tristate' to 'bool, so we now get a warning for omap2plus_defconfig: arch/arm/configs/omap2plus_defconfig:322:warning: symbol value 'm' invalid for LIRC This changes the file to mark the symbol as built-in to get rid of the warning. Fixes: a60d64b15c20 ("media: lirc: lirc interface should not be a raw decoder") Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2018-02-22ARM: orion: fix orion_ge00_switch_board_info initializationArnd Bergmann1-12/+11
A section type mismatch warning shows up when building with LTO, since orion_ge00_mvmdio_bus_name was put in __initconst but not marked const itself: include/linux/of.h: In function 'spear_setup_of_timer': arch/arm/mach-spear/time.c:207:34: error: 'timer_of_match' causes a section type conflict with 'orion_ge00_mvmdio_bus_name' static const struct of_device_id timer_of_match[] __initconst = { ^ arch/arm/plat-orion/common.c:475:32: note: 'orion_ge00_mvmdio_bus_name' was declared here static __initconst const char *orion_ge00_mvmdio_bus_name = "orion-mii"; ^ As pointed out by Andrew Lunn, it should in fact be 'const' but not '__initconst' because the string is never copied but may be accessed after the init sections are freed. To fix that, I get rid of the extra symbol and rewrite the initialization in a simpler way that assigns both the bus_id and modalias statically. I spotted another theoretical bug in the same place, where d->netdev[i] may be an out of bounds access, this can be fixed by moving the device assignment into the loop. Cc: stable@vger.kernel.org Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2018-02-22Merge tag 'v4.16-rockchip-dts64fixes-1' of ↵Arnd Bergmann5-11/+10
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into fixes Pull "Rockchip dts64 fixes for 4.16" from Heiko Stübner: Fixes of dwmmc tuning clocks that may make probing HS cards fail, adding the grf-vio clock to the edp so that it can also be build as module, correct pcie ep-gpio on the sapphire board and finally a fix that makes the gmac work at gigabit speeds on the rk3328-rock64. * tag 'v4.16-rockchip-dts64fixes-1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip: arm64: dts: rockchip: Fix DWMMC clocks arm64: dts: rockchip: introduce pclk_vio_grf in rk3399-eDP device node arm64: dts: rockchip: correct ep-gpios for rk3399-sapphire arm64: dts: rockchip: fix rock64 gmac2io stability issues
2018-02-22Merge tag 'v4.16-rockchip-dts32fixes-1' of ↵Arnd Bergmann3-25/+5
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into fixes Pull "Rockchip dts32 fixes for 4.16" from Heiko Stübner: Fix wrong dwmmc tuning clocks that may make probing HS cards fail to probe and removal of special opps from the phycore boards that may run the cpu outside the soc-vendor specs. * tag 'v4.16-rockchip-dts32fixes-1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip: ARM: dts: rockchip: Fix DWMMC clocks ARM: dts: rockchip: Remove 1.8 GHz operation point from phycore som
2018-02-22Merge tag 'omap-for-v4.16/fixes-signed' of ↵Arnd Bergmann8-20/+38
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes Fixes for omaps for v4.16-rc cycle This is mostly SoC related fixes for clocks, interconnect, and PM with few board specifc dts related fixes: - Fix quirk handling for ti-sysc to check all quirk flags instead of just the first one - Fix LogicPD boards for i2c1 muxing to avoid intermittent PMIC errors - Fix debounce-interval use for omap5-uevm - Fix debugfs_create_*() usage for omap1 - Fix sar_base initialization for HS omaps - Fix omap3 prm wake interrupt for resume - Fix kmemleak for omap_get_timer_dt() - Enable optional clocks before main clock to prevent interconnect target module from being stuck in transition * tag 'omap-for-v4.16/fixes-signed' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: bus: ti-sysc: Fix checking of no-reset-on-init quirk ARM: dts: LogicPD SOM-LV: Fix I2C1 pinmux ARM: dts: LogicPD Torpedo: Fix I2C1 pinmux ARM: dts: OMAP5: uevm: Fix "debounce-interval" property misspelling ARM: OMAP1: clock: Fix debugfs_create_*() usage ARM: OMAP2+: Fix sar_base inititalization for HS omaps ARM: OMAP3: Fix prm wake interrupt for resume ARM: OMAP2+: timer: fix a kmemleak caused in omap_get_timer_dt ARM: OMAP2+: hwmod_core: enable optional clocks before main clock
2018-02-22Merge tag 'mvebu-fixes-4.16-1' of git://git.infradead.org/linux-mvebu into fixesArnd Bergmann1-2/+2
Pull "mvebu fixes for 4.16 (part 1)" from Gregory CLEMENT: - Updating my emails address (from free-electrons to bootlin) - Adding back the selection of the PL310 Errata fix for the Cortex A9 based Armada SoCs (Armada 375 and 38x) * tag 'mvebu-fixes-4.16-1' of git://git.infradead.org/linux-mvebu: ARM: mvebu: Fix broken PL310_ERRATA_753970 selects MAINTAINERS: update email address for Gregory CLEMENT
2018-02-22ARM: davinci: mark spi_board_info arrays as constArnd Bergmann3-3/+3
Building with LTO revealed that three spi_board_info arrays are marked __initconst, but not const: arch/arm/mach-davinci/board-dm365-evm.c: In function 'dm365_evm_init': arch/arm/mach-davinci/board-dm365-evm.c:729:30: error: 'dm365_evm_spi_info' causes a section type conflict with 'dm646x_edma_device' static struct spi_board_info dm365_evm_spi_info[] __initconst = { ^ arch/arm/mach-davinci/dm646x.c:603:42: note: 'dm646x_edma_device' was declared here static const struct platform_device_info dm646x_edma_device __initconst = { This marks them const as well, as was originally intended. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2018-02-22ARM: clps711x: mark clps711x_compat as constArnd Bergmann1-1/+1
The array of string pointers is put in __initconst, and the strings themselves are marke 'const' but the the pointers are not, which caused a warning when built with LTO: arch/arm/mach-clps711x/board-dt.c:72:20: error: 'clps711x_compat' causes a section type conflict with 'feroceon_ids' static const char *clps711x_compat[] __initconst = { This marks the array itself const as well, which was certainly the intention originally. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2018-02-22arm: zx: dts: Remove leading 0x and 0s from bindings notationMathieu Malaterre1-10/+10
Improve the DTS files by removing all the leading "0x" and zeros to fix the following dtc warnings: Warning (unit_address_format): Node /XXX unit name should not have leading "0x" and Warning (unit_address_format): Node /XXX unit name should not have leading 0s Converted using the following command: find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e "s/@\([0-9a-fA-FxX\.;:#]+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e "s/@0+\(.*\) {/@\1 {/g" {} +^C For simplicity, two sed expressions were used to solve each warnings separately. To make the regex expression more robust a few other issues were resolved, namely setting unit-address to lower case, and adding a whitespace before the the opening curly brace: https://elinux.org/Device_Tree_Linux#Linux_conventions This will solve as a side effect warning: Warning (simple_bus_reg): Node /XXX@<UPPER> simple-bus unit address format error, expected "<lower>" This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation") Reported-by: David Daney <ddaney@caviumnetworks.com> Suggested-by: Rob Herring <robh@kernel.org> Signed-off-by: Mathieu Malaterre <malat@debian.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2018-02-22arm64: dts: Remove leading 0x and 0s from bindings notationMathieu Malaterre4-8/+8
Improve the DTS files by removing all the leading "0x" and zeros to fix the following dtc warnings: Warning (unit_address_format): Node /XXX unit name should not have leading "0x" and Warning (unit_address_format): Node /XXX unit name should not have leading 0s Converted using the following command: find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -E -i -e "s/@0x([0-9a-fA-F\.]+)\s?\{/@\L\1 \{/g" -e "s/@0+([0-9a-fA-F\.]+)\s?\{/@\L\1 \{/g" {} + For simplicity, two sed expressions were used to solve each warnings separately. To make the regex expression more robust a few other issues were resolved, namely setting unit-address to lower case, and adding a whitespace before the the opening curly brace: https://elinux.org/Device_Tree_Linux#Linux_conventions This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation") Reported-by: David Daney <ddaney@caviumnetworks.com> Suggested-by: Rob Herring <robh@kernel.org> Signed-off-by: Mathieu Malaterre <malat@debian.org> Acked-by: Matthias Brugger <matthias.bgg@gmail.com> Acked-by: Andy Gross <andy.gross@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2018-02-22Merge tag 'amlogic-fixes' of ↵Arnd Bergmann3-7/+8
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic into fixes Amlogic fixes for v4.16-rc1 - DT: fix UART address ranges - DT: enable PHY interrupts * tag 'amlogic-fixes' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic: ARM64: dts: meson: uart: fix address space range ARM64: dts: meson-gxl: add internal ethernet PHY irq
2018-02-22arm64: dts: cavium: fix PCI bus dtc warningsRob Herring1-1/+2
dtc recently added PCI bus checks. Fix these warnings: arch/arm64/boot/dts/cavium/thunder2-99xx.dtb: Warning (pci_bridge): Node /pci missing bus-range for PCI bridge arch/arm64/boot/dts/cavium/thunder2-99xx.dtb: Warning (unit_address_vs_reg): Node /pci has a reg or ranges property, but no unit name Signed-off-by: Rob Herring <robh@kernel.org> Cc: Jayachandran C <jnair@caviumnetworks.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2018-02-18Merge branch 'x86-urgent-for-linus' of ↵Linus Torvalds2-3/+3
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 Kconfig fixes from Thomas Gleixner: "Three patchlets to correct HIGHMEM64G and CMPXCHG64 dependencies in Kconfig when CPU selections are explicitely set to M586 or M686" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/Kconfig: Explicitly enumerate i686-class CPUs in Kconfig x86/Kconfig: Exclude i586-class CPUs lacking PAE support from the HIGHMEM64G Kconfig group x86/Kconfig: Add missing i586-class CPUs to the X86_CMPXCHG64 Kconfig group
2018-02-17Merge tag 'powerpc-4.16-3' of ↵Linus Torvalds5-10/+29
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux Pull powerpc fixes from Michael Ellerman: "The main attraction is a fix for a bug in the new drmem code, which was causing an oops on boot on some versions of Qemu. There's also a fix for XIVE (Power9 interrupt controller) on KVM, as well as a few other minor fixes. Thanks to: Corentin Labbe, Cyril Bur, Cédric Le Goater, Daniel Black, Nathan Fontenot, Nicholas Piggin" * tag 'powerpc-4.16-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/pseries: Check for zero filled ibm,dynamic-memory property powerpc/pseries: Add empty update_numa_cpu_lookup_table() for NUMA=n powerpc/powernv: IMC fix out of bounds memory access at shutdown powerpc/xive: Use hw CPU ids when configuring the CPU queues powerpc: Expose TSCR via sysfs only on powernv
2018-02-17Merge tag 'arm64-fixes' of ↵Linus Torvalds17-406/+448
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Catalin Marinas: "The bulk of this is the pte accessors annotation to READ/WRITE_ONCE (we tried to avoid pushing this during the merge window to avoid conflicts) - Updated the page table accessors to use READ/WRITE_ONCE and prevent compiler transformation that could lead to an apparent loss of coherency - Enabled branch predictor hardening for the Falkor CPU - Fix interaction between kpti enabling and KASan causing the recursive page table walking to take a significant time - Fix some sparse warnings" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: cputype: Silence Sparse warnings arm64: mm: Use READ_ONCE/WRITE_ONCE when accessing page tables arm64: proc: Set PTE_NG for table entries to avoid traversing them twice arm64: Add missing Falkor part number for branch predictor hardening
2018-02-17x86/xen: Calculate __max_logical_packages on PV domainsPrarit Bhargava3-2/+11
The kernel panics on PV domains because native_smp_cpus_done() is only called for HVM domains. Calculate __max_logical_packages for PV domains. Fixes: b4c0a7326f5d ("x86/smpboot: Fix __max_logical_packages estimate") Signed-off-by: Prarit Bhargava <prarit@redhat.com> Tested-and-reported-by: Simon Gaiser <simon@invisiblethingslab.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: x86@kernel.org Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Juergen Gross <jgross@suse.com> Cc: Dou Liyang <douly.fnst@cn.fujitsu.com> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Kate Stewart <kstewart@linuxfoundation.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Andi Kleen <ak@linux.intel.com> Cc: Vitaly Kuznetsov <vkuznets@redhat.com> Cc: xen-devel@lists.xenproject.org Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2018-02-17arm64: cputype: Silence Sparse warningsRobin Murphy1-1/+1
Sparse makes a fair bit of noise about our MPIDR mask being implicitly long - let's explicitly describe it as such rather than just relying on the value forcing automatic promotion. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2018-02-16Merge tag 'dma-mapping-4.16-2' of git://git.infradead.org/users/hch/dma-mappingLinus Torvalds1-1/+0
Pull dma-mapping fixes from Christoph Hellwig: "A few dma-mapping fixes for the fallout from the changes in rc1" * tag 'dma-mapping-4.16-2' of git://git.infradead.org/users/hch/dma-mapping: powerpc/macio: set a proper dma_coherent_mask dma-mapping: fix a comment typo dma-direct: comment the dma_direct_free calling convention dma-direct: mark as is_phys ia64: fix build failure with CONFIG_SWIOTLB
2018-02-16arm64: mm: Use READ_ONCE/WRITE_ONCE when accessing page tablesWill Deacon13-399/+426
In many cases, page tables can be accessed concurrently by either another CPU (due to things like fast gup) or by the hardware page table walker itself, which may set access/dirty bits. In such cases, it is important to use READ_ONCE/WRITE_ONCE when accessing page table entries so that entries cannot be torn, merged or subject to apparent loss of coherence due to compiler transformations. Whilst there are some scenarios where this cannot happen (e.g. pinned kernel mappings for the linear region), the overhead of using READ_ONCE /WRITE_ONCE everywhere is minimal and makes the code an awful lot easier to reason about. This patch consistently uses these macros in the arch code, as well as explicitly namespacing pointers to page table entries from the entries themselves by using adopting a 'p' suffix for the former (as is sometimes used elsewhere in the kernel source). Tested-by: Yury Norov <ynorov@caviumnetworks.com> Tested-by: Richard Ruigrok <rruigrok@codeaurora.org> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2018-02-16Merge tag 'mips_fixes_4.16_2' of ↵Linus Torvalds3-5/+15
git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/mips Pull MIPS fixes from James Hogan: "A few fixes for outstanding MIPS issues: - an __init section mismatch warning when brcmstb_pm is enabled - a regression handling multiple mem=X@Y arguments (4.11) - a USB Kconfig select warning, and related sparc cleanup (4.16)" * tag 'mips_fixes_4.16_2' of git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/mips: sparc,leon: Select USB_UHCI_BIG_ENDIAN_{MMIO,DESC} usb: Move USB_UHCI_BIG_ENDIAN_* out of USB_SUPPORT MIPS: Fix incorrect mem=X@Y handling MIPS: BMIPS: Fix section mismatch warning
2018-02-16powerpc/pseries: Check for zero filled ibm,dynamic-memory propertyNathan Fontenot1-0/+8
Some versions of QEMU will produce an ibm,dynamic-reconfiguration-memory node with a ibm,dynamic-memory property that is zero-filled. This causes the drmem code to oops trying to parse this property. The fix for this is to validate that the property does contain LMB entries before trying to parse it and bail if the count is zero. Oops: Kernel access of bad area, sig: 11 [#1] DAR: 0000000000000010 NIP read_drconf_v1_cell+0x54/0x9c LR read_drconf_v1_cell+0x48/0x9c Call Trace: __param_initcall_debug+0x0/0x28 (unreliable) drmem_init+0x144/0x2f8 do_one_initcall+0x64/0x1d0 kernel_init_freeable+0x298/0x38c kernel_init+0x24/0x160 ret_from_kernel_thread+0x5c/0xb4 The ibm,dynamic-reconfiguration-memory device tree property generated that causes this: ibm,dynamic-reconfiguration-memory { ibm,lmb-size = <0x0 0x10000000>; ibm,memory-flags-mask = <0xff>; ibm,dynamic-memory = <0x0 0x0 0x0 0x0 0x0 0x0>; linux,phandle = <0x7e57eed8>; ibm,associativity-lookup-arrays = <0x1 0x4 0x0 0x0 0x0 0x0>; ibm,memory-preservation-time = <0x0>; }; Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com> Reviewed-by: Cyril Bur <cyrilbur@gmail.com> Tested-by: Daniel Black <daniel@linux.vnet.ibm.com> [mpe: Trim oops report] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-02-16ARM: dts: rockchip: Fix DWMMC clocksRobin Murphy2-5/+5
Trying to boot an RK3328 box with an HS200-capable eMMC, I see said eMMC fail to initialise as it can't run its tuning procedure, because the sample clock is missing. Upon closer inspection, whilst the clock is present in the DT, its name is subtly incorrect per the binding, so __of_clk_get_by_name() never finds it. By inspection, the drive clock suffers from a similar problem, so has never worked properly either. This error has propagated across the 32-bit DTs too, so fix those up. Fixes: 187d7967a5ee ("ARM: dts: rockchip: add the sdio/sdmmc node for rk3036") Fixes: faea098e1808 ("ARM: dts: rockchip: add core rk3036 dtsi") Fixes: 9848ebeb952d ("ARM: dts: rockchip: add core rk3228 dtsi") Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2018-02-16x86/Kconfig: Explicitly enumerate i686-class CPUs in KconfigMatthew Whitehead1-1/+1
The X86_P6_NOP config class leaves out many i686-class CPUs. Instead, explicitly enumerate all these CPUs. Using a configuration with M686 currently sets X86_MINIMUM_CPU_FAMILY=5 instead of the correct value of 6. Booting on an i586 it will fail to generate the "This kernel requires an i686 CPU, but only detected an i586 CPU" message and intentional halt as expected. It will instead just silently hang when it hits i686-specific instructions. Signed-off-by: Matthew Whitehead <tedheadster@gmail.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1518713696-11360-3-git-send-email-tedheadster@gmail.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-02-16x86/Kconfig: Exclude i586-class CPUs lacking PAE support from the HIGHMEM64G ↵Matthew Whitehead1-1/+1
Kconfig group i586-class machines also lack support for Physical Address Extension (PAE), so add them to the exclusion list. Signed-off-by: Matthew Whitehead <tedheadster@gmail.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1518713696-11360-2-git-send-email-tedheadster@gmail.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-02-16x86/Kconfig: Add missing i586-class CPUs to the X86_CMPXCHG64 Kconfig groupMatthew Whitehead1-1/+1
Several i586-class CPUs supporting this instruction are missing from the X86_CMPXCHG64 config group. Using a configuration with either M586TSC or M586MMX currently sets X86_MINIMUM_CPU_FAMILY=4 instead of the correct value of 5. Booting on an i486 it will fail to generate the "This kernel requires an i586 CPU, but only detected an i486 CPU" message and intentional halt as expected. It will instead just silently hang when it hits i586-specific instructions. The M586 CPU is not in this list because at least the Cyrix 5x86 lacks this instruction, and perhaps others. Signed-off-by: Matthew Whitehead <tedheadster@gmail.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1518713696-11360-1-git-send-email-tedheadster@gmail.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-02-16arm64: dts: rockchip: Fix DWMMC clocksRobin Murphy2-4/+4
Trying to boot an RK3328 box with an HS200-capable eMMC, I see said eMMC fail to initialise as it can't run its tuning procedure, because the sample clock is missing. Upon closer inspection, whilst the clock is present in the DT, its name is subtly incorrect per the binding, so __of_clk_get_by_name() never finds it. By inspection, the drive clock suffers from a similar problem, so has never worked properly either. Fix up all instances of the incorrect clock names across the 64-bit DTs. Fixes: d717f7352ec6 ("arm64: dts: rockchip: add sdmmc/sdio/emmc nodes for RK3328 SoCs") Fixes: b790c2cab5ca ("arm64: dts: add Rockchip rk3368 core dtsi and board dts for the r88 board") Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2018-02-16sparc,leon: Select USB_UHCI_BIG_ENDIAN_{MMIO,DESC}James Hogan1-0/+2
Now that USB_UHCI_BIG_ENDIAN_MMIO and USB_UHCI_BIG_ENDIAN_DESC are moved outside of the USB_SUPPORT conditional, simply select them from SPARC_LEON rather than by the symbol's defaults in drivers/usb/Kconfig, similar to how it is done for USB_EHCI_BIG_ENDIAN_MMIO and USB_EHCI_BIG_ENDIAN_DESC. Signed-off-by: James Hogan <jhogan@kernel.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Corentin Labbe <clabbe.montjoie@gmail.com> Cc: sparclinux@vger.kernel.org Cc: linux-usb@vger.kernel.org Acked-by: David S. Miller <davem@davemloft.net> Patchwork: https://patchwork.linux-mips.org/patch/18560/
2018-02-15ARM: dts: rockchip: Remove 1.8 GHz operation point from phycore somDaniel Schultz1-20/+0
Rockchip recommends to run the CPU cores only with operations points of 1.6 GHz or lower. Removed the cpu0 node with too high operation points and use the default values instead. Fixes: 903d31e34628 ("ARM: dts: rockchip: Add support for phyCORE-RK3288 SoM") Cc: stable@vger.kernel.org Signed-off-by: Daniel Schultz <d.schultz@phytec.de> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2018-02-15Merge branch 'x86-urgent-for-linus' of ↵Linus Torvalds10-73/+141
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Ingo Molnar: "Misc fixes all across the map: - /proc/kcore vsyscall related fixes - LTO fix - build warning fix - CPU hotplug fix - Kconfig NR_CPUS cleanups - cpu_has() cleanups/robustification - .gitignore fix - memory-failure unmapping fix - UV platform fix" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/mm, mm/hwpoison: Don't unconditionally unmap kernel 1:1 pages x86/error_inject: Make just_return_func() globally visible x86/platform/UV: Fix GAM Range Table entries less than 1GB x86/build: Add arch/x86/tools/insn_decoder_test to .gitignore x86/smpboot: Fix uncore_pci_remove() indexing bug when hot-removing a physical CPU x86/mm/kcore: Add vsyscall page to /proc/kcore conditionally vfs/proc/kcore, x86/mm/kcore: Fix SMAP fault when dumping vsyscall user page x86/Kconfig: Further simplify the NR_CPUS config x86/Kconfig: Simplify NR_CPUS config x86/MCE: Fix build warning introduced by "x86: do not use print_symbol()" x86/cpufeature: Update _static_cpu_has() to use all named variables x86/cpufeature: Reindent _static_cpu_has()
2018-02-15Merge branch 'x86-pti-for-linus' of ↵Linus Torvalds43-271/+241
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 PTI and Spectre related fixes and updates from Ingo Molnar: "Here's the latest set of Spectre and PTI related fixes and updates: Spectre: - Add entry code register clearing to reduce the Spectre attack surface - Update the Spectre microcode blacklist - Inline the KVM Spectre helpers to get close to v4.14 performance again. - Fix indirect_branch_prediction_barrier() - Fix/improve Spectre related kernel messages - Fix array_index_nospec_mask() asm constraint - KVM: fix two MSR handling bugs PTI: - Fix a paranoid entry PTI CR3 handling bug - Fix comments objtool: - Fix paranoid_entry() frame pointer warning - Annotate WARN()-related UD2 as reachable - Various fixes - Add Add Peter Zijlstra as objtool co-maintainer Misc: - Various x86 entry code self-test fixes - Improve/simplify entry code stack frame generation and handling after recent heavy-handed PTI and Spectre changes. (There's two more WIP improvements expected here.) - Type fix for cache entries There's also some low risk non-fix changes I've included in this branch to reduce backporting conflicts: - rename a confusing x86_cpu field name - de-obfuscate the naming of single-TLB flushing primitives" * 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (41 commits) x86/entry/64: Fix CR3 restore in paranoid_exit() x86/cpu: Change type of x86_cache_size variable to unsigned int x86/spectre: Fix an error message x86/cpu: Rename cpu_data.x86_mask to cpu_data.x86_stepping selftests/x86/mpx: Fix incorrect bounds with old _sigfault x86/mm: Rename flush_tlb_single() and flush_tlb_one() to __flush_tlb_one_[user|kernel]() x86/speculation: Add <asm/msr-index.h> dependency nospec: Move array_index_nospec() parameter checking into separate macro x86/speculation: Fix up array_index_nospec_mask() asm constraint x86/debug: Use UD2 for WARN() x86/debug, objtool: Annotate WARN()-related UD2 as reachable objtool: Fix segfault in ignore_unreachable_insn() selftests/x86: Disable tests requiring 32-bit support on pure 64-bit systems selftests/x86: Do not rely on "int $0x80" in single_step_syscall.c selftests/x86: Do not rely on "int $0x80" in test_mremap_vdso.c selftests/x86: Fix build bug caused by the 5lvl test which has been moved to the VM directory selftests/x86/pkeys: Remove unused functions selftests/x86: Clean up and document sscanf() usage selftests/x86: Fix vDSO selftest segfault for vsyscall=none x86/entry/64: Remove the unused 'icebp' macro ...
2018-02-15x86/entry/64: Fix CR3 restore in paranoid_exit()Ingo Molnar1-0/+1
Josh Poimboeuf noticed the following bug: "The paranoid exit code only restores the saved CR3 when it switches back to the user GS. However, even in the kernel GS case, it's possible that it needs to restore a user CR3, if for example, the paranoid exception occurred in the syscall exit path between SWITCH_TO_USER_CR3_STACK and SWAPGS." Josh also confirmed via targeted testing that it's possible to hit this bug. Fix the bug by also restoring CR3 in the paranoid_exit_no_swapgs branch. The reason we haven't seen this bug reported by users yet is probably because "paranoid" entry points are limited to the following cases: idtentry double_fault do_double_fault has_error_code=1 paranoid=2 idtentry debug do_debug has_error_code=0 paranoid=1 shift_ist=DEBUG_STACK idtentry int3 do_int3 has_error_code=0 paranoid=1 shift_ist=DEBUG_STACK idtentry machine_check do_mce has_error_code=0 paranoid=1 Amongst those entry points only machine_check is one that will interrupt an IRQS-off critical section asynchronously - and machine check events are rare. The other main asynchronous entries are NMI entries, which can be very high-freq with perf profiling, but they are special: they don't use the 'idtentry' macro but are open coded and restore user CR3 unconditionally so don't have this bug. Reported-and-tested-by: Josh Poimboeuf <jpoimboe@redhat.com> Reviewed-by: Andy Lutomirski <luto@kernel.org> Acked-by: Thomas Gleixner <tglx@linutronix.de> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20180214073910.boevmg65upbk3vqb@gmail.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-02-15x86/cpu: Change type of x86_cache_size variable to unsigned intGustavo A. R. Silva4-5/+5
Currently, x86_cache_size is of type int, which makes no sense as we will never have a valid cache size equal or less than 0. So instead of initializing this variable to -1, it can perfectly be initialized to 0 and use it as an unsigned variable instead. Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Addresses-Coverity-ID: 1464429 Link: http://lkml.kernel.org/r/20180213192208.GA26414@embeddedor.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-02-15x86/spectre: Fix an error messageDan Carpenter1-1/+1
If i == ARRAY_SIZE(mitigation_options) then we accidentally print garbage from one space beyond the end of the mitigation_options[] array. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@suse.de> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: KarimAllah Ahmed <karahmed@amazon.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: kernel-janitors@vger.kernel.org Fixes: 9005c6834c0f ("x86/spectre: Simplify spectre_v2 command line parsing") Link: http://lkml.kernel.org/r/20180214071416.GA26677@mwanda Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-02-15x86/cpu: Rename cpu_data.x86_mask to cpu_data.x86_steppingJia Zhang21-52/+52
x86_mask is a confusing name which is hard to associate with the processor's stepping. Additionally, correct an indent issue in lib/cpu.c. Signed-off-by: Jia Zhang <qianyue.zj@alibaba-inc.com> [ Updated it to more recent kernels. ] Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: bp@alien8.de Cc: tony.luck@intel.com Link: http://lkml.kernel.org/r/1514771530-70829-1-git-send-email-qianyue.zj@alibaba-inc.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-02-15x86/mm: Rename flush_tlb_single() and flush_tlb_one() to ↵Andy Lutomirski12-25/+38
__flush_tlb_one_[user|kernel]() flush_tlb_single() and flush_tlb_one() sound almost identical, but they really mean "flush one user translation" and "flush one kernel translation". Rename them to flush_tlb_one_user() and flush_tlb_one_kernel() to make the semantics more obvious. [ I was looking at some PTI-related code, and the flush-one-address code is unnecessarily hard to understand because the names of the helpers are uninformative. This came up during PTI review, but no one got around to doing it. ] Signed-off-by: Andy Lutomirski <luto@kernel.org> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Eduardo Valentin <eduval@amazon.com> Cc: Hugh Dickins <hughd@google.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Juergen Gross <jgross@suse.com> Cc: Kees Cook <keescook@google.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Linux-MM <linux-mm@kvack.org> Cc: Rik van Riel <riel@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will.deacon@arm.com> Link: http://lkml.kernel.org/r/3303b02e3c3d049dc5235d5651e0ae6d29a34354.1517414378.git.luto@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-02-15x86/speculation: Add <asm/msr-index.h> dependencyPeter Zijlstra1-0/+1
Joe Konno reported a compile failure resulting from using an MSR without inclusion of <asm/msr-index.h>, and while the current code builds fine (by accident) this needs fixing for future patches. Reported-by: Joe Konno <joe.konno@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: arjan@linux.intel.com Cc: bp@alien8.de Cc: dan.j.williams@intel.com Cc: dave.hansen@linux.intel.com Cc: dwmw2@infradead.org Cc: dwmw@amazon.co.uk Cc: gregkh@linuxfoundation.org Cc: hpa@zytor.com Cc: jpoimboe@redhat.com Cc: linux-tip-commits@vger.kernel.org Cc: luto@kernel.org Fixes: 20ffa1caecca ("x86/speculation: Add basic IBPB (Indirect Branch Prediction Barrier) support") Link: http://lkml.kernel.org/r/20180213132819.GJ25201@hirez.programming.kicks-ass.net Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-02-15x86/speculation: Fix up array_index_nospec_mask() asm constraintDan Williams1-1/+1
Allow the compiler to handle @size as an immediate value or memory directly rather than allocating a register. Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/151797010204.1289.1510000292250184993.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-02-15x86/debug: Use UD2 for WARN()Peter Zijlstra2-10/+7
Since the Intel SDM added an ModR/M byte to UD0 and binutils followed that specification, we now cannot disassemble our kernel anymore. This now means Intel and AMD disagree on the encoding of UD0. And instead of playing games with additional bytes that are valid ModR/M and single byte instructions (0xd6 for instance), simply use UD2 for both WARN() and BUG(). Requested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20180208194406.GD25181@hirez.programming.kicks-ass.net Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-02-15x86/debug, objtool: Annotate WARN()-related UD2 as reachableJosh Poimboeuf1-1/+5
By default, objtool assumes that a UD2 is a dead end. This is mainly because GCC 7+ sometimes inserts a UD2 when it detects a divide-by-zero condition. Now that WARN() is moving back to UD2, annotate the code after it as reachable so objtool can follow the code flow. Reported-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: kbuild test robot <fengguang.wu@intel.com> Link: http://lkml.kernel.org/r/0e483379275a42626ba8898117f918e1bf661e40.1518130694.git.jpoimboe@redhat.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-02-15powerpc/pseries: Add empty update_numa_cpu_lookup_table() for NUMA=nCorentin Labbe1-0/+3
When CONFIG_NUMA is not set, the build fails with: arch/powerpc/platforms/pseries/hotplug-cpu.c:335:4: error: déclaration implicite de la fonction « update_numa_cpu_lookup_table » So we have to add update_numa_cpu_lookup_table() as an empty function when CONFIG_NUMA is not set. Fixes: 1d9a090783be ("powerpc/numa: Invalidate numa_cpu_lookup_table on cpu remove") Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-02-15powerpc/powernv: IMC fix out of bounds memory access at shutdownNicholas Piggin1-2/+4
The OPAL IMC driver's shutdown handler disables nest PMU counters by walking nodes and taking the first CPU out of their cpumask, which is used to index into the paca (get_hard_smp_processor_id()). This does not always do the right thing, and in particular for CPU-less nodes it returns NR_CPUS and that overruns the paca and dereferences random memory. Fix it by being more careful about checking returned CPU, and only using online CPUs. It's not clear this shutdown code makes sense after commit 885dcd709b ("powerpc/perf: Add nest IMC PMU support"), but this should not make things worse Currently the bug causes us to call OPAL with a junk CPU number. A separate patch in development to change the way pacas are allocated escalates this bug into a crash: Unable to handle kernel paging request for data at address 0x2a21af1eeb000076 Faulting instruction address: 0xc0000000000a5468 Oops: Kernel access of bad area, sig: 11 [#1] ... NIP opal_imc_counters_shutdown+0x148/0x1d0 LR opal_imc_counters_shutdown+0x134/0x1d0 Call Trace: opal_imc_counters_shutdown+0x134/0x1d0 (unreliable) platform_drv_shutdown+0x44/0x60 device_shutdown+0x1f8/0x350 kernel_restart_prepare+0x54/0x70 kernel_restart+0x28/0xc0 SyS_reboot+0x1d0/0x2c0 system_call+0x58/0x6c Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-02-15powerpc/xive: Use hw CPU ids when configuring the CPU queuesCédric Le Goater1-6/+10
The CPU event notification queues on sPAPR should be configured using a hardware CPU identifier. The problem did not show up on the Power Hypervisor because pHyp supports 8 threads per core which keeps CPU number contiguous. This is not the case on all sPAPR virtual machines, some use SMT=1. Also improve error logging by adding the CPU number. Fixes: eac1e731b59e ("powerpc/xive: guest exploitation of the XIVE interrupt controller") Cc: stable@vger.kernel.org # v4.14+ Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-02-15powerpc: Expose TSCR via sysfs only on powernvCyril Bur1-2/+4
The TSCR can only be accessed in hypervisor mode. Fixes: 88b5e12eeb11 ("powerpc: Expose TSCR via sysfs") Signed-off-by: Cyril Bur <cyrilbur@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-02-14arm64: proc: Set PTE_NG for table entries to avoid traversing them twiceWill Deacon1-5/+9
When KASAN is enabled, the swapper page table contains many identical mappings of the zero page, which can lead to a stall during boot whilst the G -> nG code continually walks the same page table entries looking for global mappings. This patch sets the nG bit (bit 11, which is IGNORED) in table entries after processing the subtree so we can easily skip them if we see them a second time. Tested-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2018-02-14Merge tag 'powerpc-4.16-2' of ↵Linus Torvalds26-77/+229
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux Pull powerpc fixes from Michael Ellerman: "A larger batch of fixes than we'd like. Roughly 1/3 fixes for new code, 1/3 fixes for stable and 1/3 minor things. There's four commits fixing bugs when using 16GB huge pages on hash, caused by some of the preparatory changes for pkeys. Two fixes for bugs in the enhanced IRQ soft masking for local_t, one of which broke KVM in some circumstances. Four fixes for Power9. The most bizarre being a bug where futexes stopped working because a NULL pointer dereference didn't trap during early boot (it aliased the kernel mapping). A fix for memory hotplug when using the Radix MMU, and a fix for live migration of guests using the Radix MMU. Two fixes for hotplug on pseries machines. One where we weren't correctly updating NUMA info when CPUs are added and removed. And the other fixes crashes/hangs seen when doing memory hot remove during boot, which is apparently a thing people do. Finally a handful of build fixes for obscure configs and other minor fixes. Thanks to: Alexey Kardashevskiy, Aneesh Kumar K.V, Balbir Singh, Colin Ian King, Daniel Henrique Barboza, Florian Weimer, Guenter Roeck, Harish, Laurent Vivier, Madhavan Srinivasan, Mauricio Faria de Oliveira, Nathan Fontenot, Nicholas Piggin, Sam Bobroff" * tag 'powerpc-4.16-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: selftests/powerpc: Fix to use ucontext_t instead of struct ucontext powerpc/kdump: Fix powernv build break when KEXEC_CORE=n powerpc/pseries: Fix build break for SPLPAR=n and CPU hotplug powerpc/mm/hash64: Zero PGD pages on allocation powerpc/mm/hash64: Store the slot information at the right offset for hugetlb powerpc/mm/hash64: Allocate larger PMD table if hugetlb config is enabled powerpc/mm: Fix crashes with 16G huge pages powerpc/mm: Flush radix process translations when setting MMU type powerpc/vas: Don't set uses_vas for kernel windows powerpc/pseries: Enable RAS hotplug events later powerpc/mm/radix: Split linear mapping on hot-unplug powerpc/64s/radix: Boot-time NULL pointer protection using a guard-PID ocxl: fix signed comparison with less than zero powerpc/64s: Fix may_hard_irq_enable() for PMI soft masking powerpc/64s: Fix MASKABLE_RELON_EXCEPTION_HV_OOL macro powerpc/numa: Invalidate numa_cpu_lookup_table on cpu remove
2018-02-14ARM: dts: LogicPD SOM-LV: Fix I2C1 pinmuxAdam Ford1-1/+8
The pinmuxing was missing for I2C1 which was causing intermittent issues with the PMIC which is connected to I2C1. The bootloader did not quite configure the I2C1 either, so when running at 2.6MHz, it was generating errors at times. This correctly sets the I2C1 pinmuxing so it can operate at 2.6MHz Fixes: ab8dd3aed011 ("ARM: DTS: Add minimal Support for Logic PD DM3730 SOM-LV") Signed-off-by: Adam Ford <aford173@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-02-14ARM: dts: LogicPD Torpedo: Fix I2C1 pinmuxAdam Ford1-0/+8
The pinmuxing was missing for I2C1 which was causing intermittent issues with the PMIC which is connected to I2C1. The bootloader did not quite configure the I2C1 either, so when running at 2.6MHz, it was generating errors at time. This correctly sets the I2C1 pinmuxing so it can operate at 2.6MHz Fixes: 687c27676151 ("ARM: dts: Add minimal support for LogicPD Torpedo DM3730 devkit") Signed-off-by: Adam Ford <aford173@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-02-14ARM: dts: OMAP5: uevm: Fix "debounce-interval" property misspellingGeert Uytterhoeven1-1/+1
"debounce_interval" was never supported. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Benoît Cousson <bcousson@baylibre.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-02-14ARM: OMAP1: clock: Fix debugfs_create_*() usageGeert Uytterhoeven1-3/+3
When exposing data access through debugfs, the correct debugfs_create_*() functions must be used, depending on data type. Remove all casts from data pointers passed to debugfs_create_*() functions, as such casts prevent the compiler from flagging bugs. Correct all wrong usage: - clk.rate is unsigned long, not u32, - clk.flags is u8, not u32, which exposed the successive clk.rate_offset and clk.src_offset fields. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-02-14ARM: OMAP2+: Fix sar_base inititalization for HS omapsTony Lindgren1-2/+2
HS omaps use irq_save_secure_context() instead of irq_save_context() so sar_base will never get initialized and irq_sar_clear() gets called with a wrong address for HS omaps from irq_restore_context(). Starting with commit f4b9f40ae95b ("ARM: OMAP4+: Initialize SAR RAM base early for proper CPU1 reset for kexec") we have it available, and this ideally would been fixed with that commit already. Fixes: f4b9f40ae95b ("ARM: OMAP4+: Initialize SAR RAM base early for proper CPU1 reset for kexec") Cc: Andrew F. Davis <afd@ti.com> Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Santosh Shilimkar <ssantosh@kernel.org> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
generated by cgit v1.2.3 (git 2.39.0) at 2024-12-25 04:58:20 +0300