aboutsummaryrefslogtreecommitdiffstats
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2019-08-25ARM: aspeed: Add ASPEED AST2600 architectureJoel Stanley1-1/+13
The AST2600 is a Cortex A7 dual core CPU that uses the ARM GIC for interrupts and ARM timer as a clocksource. Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Joel Stanley <joel@jms.id.au>
2019-08-25ARM: aspeed: Select timer in each SoCJoel Stanley1-1/+2
In preparation for adding the ast2600 which does not use this timer. Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Joel Stanley <joel@jms.id.au>
2019-08-25ARM: configs: aspeed_g5: Enable AST2600Joel Stanley1-3/+14
CONFIG_STRICT_KERNEL_RWX is enabled by default with ARMv7. Turn on HIGHMEM as the EVB has 2GB of RAM, and not all is usable without hihgmem. The SoC contains Cortex A7 supporting VFP and has two CPUs. Acked-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Joel Stanley <joel@jms.id.au>
2019-08-25ARM: configs: multi_v7: Add ASPEED G6Joel Stanley1-0/+19
This adds the ASPEED AST2600 system and associated ASPEED devices so we get build coverage. The changes to the UART configuration to ensure the default console (UART5) works. Acked-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Joel Stanley <joel@jms.id.au>
2019-08-25ARM: dts: vf610-zii-scu4-aib: Configure IRQ line for GPIO expanderAndrey Smirnov1-0/+2
Configure IRQ line for SX1503 GPIO expander. We already have appropriate pinmux entry and all that is missing is "interrupt-parent" and "interrupts" properties. Add them. Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Chris Healy <cphealy@gmail.com> Cc: Cory Tusar <cory.tusar@zii.aero> Cc: Fabio Estevam <festevam@gmail.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Tested-by: Chris Healy <cphealy@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-08-24Merge tag 'dma-mapping-5.3-5' of git://git.infradead.org/users/hch/dma-mappingLinus Torvalds2-4/+4
Pull dma-mapping fixes from Christoph Hellwig: "Two fixes for regressions in this merge window: - select the Kconfig symbols for the noncoherent dma arch helpers on arm if swiotlb is selected, not just for LPAE to not break then Xen build, that uses swiotlb indirectly through swiotlb-xen - fix the page allocator fallback in dma_alloc_contiguous if the CMA allocation fails" * tag 'dma-mapping-5.3-5' of git://git.infradead.org/users/hch/dma-mapping: dma-direct: fix zone selection after an unaddressable CMA allocation arm: select the dma-noncoherent symbols for all swiotlb builds
2019-08-24parisc: fix compilation errrorsQian Cai1-2/+1
Commit 0cfaee2af3a0 ("include/asm-generic/5level-fixup.h: fix variable 'p4d' set but not used") converted a few functions from macros to static inline, which causes parisc to complain, In file included from include/asm-generic/4level-fixup.h:38:0, from arch/parisc/include/asm/pgtable.h:5, from arch/parisc/include/asm/io.h:6, from include/linux/io.h:13, from sound/core/memory.c:9: include/asm-generic/5level-fixup.h:14:18: error: unknown type name 'pgd_t'; did you mean 'pid_t'? #define p4d_t pgd_t ^ include/asm-generic/5level-fixup.h:24:28: note: in expansion of macro 'p4d_t' static inline int p4d_none(p4d_t p4d) ^~~~~ It is because "4level-fixup.h" is included before "asm/page.h" where "pgd_t" is defined. Link: http://lkml.kernel.org/r/20190815205305.1382-1-cai@lca.pw Fixes: 0cfaee2af3a0 ("include/asm-generic/5level-fixup.h: fix variable 'p4d' set but not used") Signed-off-by: Qian Cai <cai@lca.pw> Reported-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Guenter Roeck <linux@roeck-us.net> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-08-24s390/qeth: add TX NAPI support for IQD devicesJulian Wiedmann1-0/+1
Due to their large MTU and potentially low utilization of TX buffers, IQD devices in particular require fast TX recycling. This makes them a prime candidate for a TX NAPI path in qeth. qeth_tx_poll() uses the recently introduced qdio_inspect_queue() helper to poll the TX queue for completed buffers. To avoid hogging the CPU for too long, we yield to the stack after completing an entire queue's worth of buffers. While IQD is expected to transfer its buffers synchronously (and thus doesn't support TX interrupts), a timer covers for the odd case where a TX buffer doesn't complete synchronously. Currently this timer should only ever fire for (1) the mcast queue, (2) the occasional race, where the NAPI poll code observes an update to queue->used_buffers while the TX doorbell hasn't been issued yet. Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-24s390/qdio: let drivers opt-out from Output Queue scanningJulian Wiedmann1-1/+1
If a driver wants to use the new Output Queue poll code, then the qdio layer must disable its internal Queue scanning. Let the driver select this mode by passing a special scan_threshold of 0. As the scan_threshold is the same for all Output Queues, also move it into the main qdio_irq struct. This allows for fast opt-out checking, a driver is expected to operate either _all_ or none of its Output Queues in polling mode. Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Acked-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-24s390/qdio: enable drivers to poll for Output completionsJulian Wiedmann1-0/+3
While commit d36deae75011 ("qdio: extend API to allow polling") enhanced the qdio layer so that drivers can poll their Input Queues, we don't have the corresponding infrastructure for Output Queues yet. Factor out a helper that scans a single QDIO Queue, so that qeth can implement TX NAPI on top of it. While doing so, remove the duplicated tracking of the next-to-scan index (q->first_to_check vs q->first_to_kick) in this code path. qdio_handle_aobs() needs to move slightly upwards in the code hierarchy, so that it's still called from the polling path. Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Acked-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-24arm64: dts: imx8mq: Add mux controller to iomuxc_gprGuido Günther1-1/+8
The only mux controls the MIPI DSI input selection. Signed-off-by: Guido Günther <agx@sigxcpu.org> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-08-24ARM: dts: imx6ul-kontron-n6310: Add Kontron i.MX6UL N6310 SoM and boardsKrzysztof Kozlowski4-0/+658
Add support for i.MX6UL modules from Kontron Electronics GmbH (before acquisition: Exceet Electronics) and evalkit boards based on it: 1. N6310 SOM: i.MX6 UL System-on-Module, a 25x25 mm solderable module (LGA pads and pin castellations) with 256 MB RAM, 1 MB NOR-Flash, 256 MB NAND and other interfaces, 2. N6310 S: evalkit, w/wo eMMC, without display, 3. N6310 S 43: evalkit with 4.3" display, The work is based on Exceet/Kontron source code (GPLv2) with numerous changes: 1. Reorganize files, 2. Rename Exceet -> Kontron, 3. Rename models/compatibles to match newest Kontron product naming, 4. Fix coding style errors and adjust to device tree coding guidelines, 5. Fix DTC warnings, 6. Extend compatibles so eval boards inherit the SoM compatible, 7. Use defines instead of GPIO and interrupt flag values, 8. Use proper vendor compatible for Macronix SPI NOR, 9. Replace deprecated bindings with proper ones, 10. Sort nodes alphabetically, 11. Remove Admatec display nodes (not yet supported). Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de> Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-08-24arm64: dts: fsl: add support for Hummingboard PulseJon Nettleton3-0/+566
The SolidRun Hummingboard Pulse carrier board carries the SolidRun i.MX8MQ based SOM. Notably missing is PCIe support that depends on analog PLLOUT clock. Current imx clk driver does not support this clock. Signed-off-by: Jon Nettleton <jon@solid-run.com> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-08-24ARM: dts: vf610-zii-cfu1: Slow I2C0 down to 100 kHzAndrey Smirnov1-1/+1
Fiber-optic modules attached to the bus are only rated to work at 100 kHz, so decrease the bus frequency to accommodate that. Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Chris Healy <cphealy@gmail.com> Cc: Fabio Estevam <festevam@gmail.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-08-24arm64: dts: ls1088a: update gpio compatibleSong Hui1-4/+4
add ls1088a gpio specify compatible. Signed-off-by: Song Hui <hui.song_1@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-08-24arm64: dts: imx: Add i.mx8mq nitrogen8m basic dts supportGary Bisson2-0/+406
Add basic dts support for i.MX8MQ NITROGEN8M. Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com> [Dafna: porting vendor's code to mainline] Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-08-24arm64: dts: ls1088a-qds: Add the spi-flash nodes under the DSPI controllerChuanhua Han1-0/+33
This patch adds the spi-flash nodes under the DSPI controller for ls1088a-qds boards. Signed-off-by: Chuanhua Han <chuanhua.han@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-08-24arm64: dts: ls1088a: Add the DSPI controller nodeChuanhua Han1-0/+13
This patch adds the DSPI controller node for ls1088a boards. Signed-off-by: Chuanhua Han <chuanhua.han@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-08-24ARM: imx: stop adjusting ar8031 phy tx delayAndré Draszik1-6/+0
Recent changes to the Atheros at803x driver cause the approach taken here to stop working because commit 6d4cd041f0af ("net: phy: at803x: disable delay only for RGMII mode") and commit cd28d1d6e52e ("net: phy: at803x: Disable phy delay for RGMII mode") fix the AR8031 driver to configure the phy's (RX/TX) delays as per the 'phy-mode' in the device tree. In particular, the phy tx (and rx) delays are updated again as per the 'phy-mode' *after* the code in here runs. Things worked before above commits, because the AR8031 comes out of reset with RX delay enabled, and the at803x driver didn't touch the delay configuration at all when "rgmii" mode was selected. It appears the code in here tries to make device trees work that incorrectly specify "rgmii", but that can't work any more and it is imperative since above commits to have the phy-mode configured correctly in the device tree. I suspect there are a few imx7d based boards using the ar8031 phy and phy-mode = "rgmii", but given I don't know which ones exactly, I am not in a position to update the respective device trees. Hence this patch is simply removing the superfluous code from the imx7d initialisation. An alternative could be to add a warning instead, but that would penalize all boards that have been updated already. Signed-off-by: André Draszik <git@andred.net> CC: Russell King <linux@armlinux.org.uk> CC: Shawn Guo <shawnguo@kernel.org> CC: Sascha Hauer <s.hauer@pengutronix.de> CC: Pengutronix Kernel Team <kernel@pengutronix.de> CC: Fabio Estevam <festevam@gmail.com> CC: NXP Linux Team <linux-imx@nxp.com> CC: Kate Stewart <kstewart@linuxfoundation.org> CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org> CC: Thomas Gleixner <tglx@linutronix.de> CC: Leonard Crestez <leonard.crestez@nxp.com> CC: linux-arm-kernel@lists.infradead.org Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-08-24ARM: dts: pbab01: correct rtc vendorAlexandre Belloni1-1/+1
The rtc8564 is made by Epson but is similar to the NXP pcf8563. Use the correct vendor name. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-08-24MIPS: dts: mscc: describe the PTP ready interruptAntoine Tenart1-2/+2
This patch adds a description of the PTP ready interrupt, which can be triggered when a PTP timestamp is available on an hardware FIFO. Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: Paul Burton <paul.burton@mips.com> Cc: davem@davemloft.net Cc: richardcochran@gmail.com Cc: alexandre.belloni@bootlin.com Cc: UNGLinuxDriver@microchip.com Cc: ralf@linux-mips.org Cc: jhogan@kernel.org Cc: netdev@vger.kernel.org Cc: linux-mips@vger.kernel.org Cc: thomas.petazzoni@bootlin.com Cc: allan.nielsen@microchip.com
2019-08-24MIPS: dts: mscc: describe the PTP register rangeAntoine Tenart1-1/+2
This patch adds one register range within the mscc,vsc7514-switch node, to describe the PTP registers. Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: Paul Burton <paul.burton@mips.com> Cc: davem@davemloft.net Cc: richardcochran@gmail.com Cc: alexandre.belloni@bootlin.com Cc: UNGLinuxDriver@microchip.com Cc: ralf@linux-mips.org Cc: jhogan@kernel.org Cc: netdev@vger.kernel.org Cc: linux-mips@vger.kernel.org Cc: thomas.petazzoni@bootlin.com Cc: allan.nielsen@microchip.com
2019-08-24MIPS: lantiq: update the clock alias' for the mainline PCIe PHY driverMartin Blumenstingl1-8/+8
The mainline PCIe PHY driver has it's own devicetree node. Update the clock alias so the mainline driver finds the clocks. The first PCIe PHY is located at 0x1f106800 and exists on VRX200, ARX300 and GRX390. The second PCIe PHY is located at 0x1f700400 and exists on ARX300 and GRX390. The third PCIe PHY is located at 0x1f106a00 and exists onl on GRX390. Lantiq's board support package (called "UGW") names these registers "PDI". Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Paul Burton <paul.burton@mips.com> Cc: linux-mips@vger.kernel.org Cc: devicetree@vger.kernel.org Cc: john@phrozen.org Cc: kishon@ti.com Cc: ralf@linux-mips.org Cc: robh+dt@kernel.org Cc: linux-kernel@vger.kernel.org Cc: hauke@hauke-m.de Cc: mark.rutland@arm.com Cc: ms@dev.tdt.de
2019-08-24mips: avoid explicit UB in assignment of mips_io_port_baseNick Desaulniers2-13/+3
The code in question is modifying a variable declared const through pointer manipulation. Such code is explicitly undefined behavior, and is the lone issue preventing malta_defconfig from booting when built with Clang: If an attempt is made to modify an object defined with a const-qualified type through use of an lvalue with non-const-qualified type, the behavior is undefined. LLVM is removing such assignments. A simple fix is to not declare variables const that you plan on modifying. Limiting the scope would be a better method of preventing unwanted writes to such a variable. Further, the code in question mentions "compiler bugs" without any links to bug reports, so it is difficult to know if the issue is resolved in GCC. The patch was authored in 2006, which would have been GCC 4.0.3 or 4.1.1. The minimal supported version of GCC in the Linux kernel is currently 4.6. For what its worth, there was UB before the commit in question, it just added a barrier and got lucky IRT codegen. I don't think there's any actual compiler bugs related, just runtime bugs due to UB. Link: https://github.com/ClangBuiltLinux/linux/issues/610 Fixes: 966f4406d903 ("[MIPS] Work around bad code generation for <asm/io.h>.") Reported-by: Nathan Chancellor <natechancellor@gmail.com> Debugged-by: Nathan Chancellor <natechancellor@gmail.com> Suggested-by: Eli Friedman <efriedma@quicinc.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Paul Burton <paul.burton@mips.com> Cc: ralf@linux-mips.org Cc: jhogan@kernel.org Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: Hassan Naveed <hnaveed@wavecomp.com> Cc: Stephen Kitt <steve@sk2.org> Cc: Serge Semin <fancer.lancer@gmail.com> Cc: Mike Rapoport <rppt@linux.ibm.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Michal Hocko <mhocko@suse.com> Cc: linux-mips@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: clang-built-linux@googlegroups.com
2019-08-23Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfDavid S. Miller1-5/+7
Daniel Borkmann says: ==================== pull-request: bpf 2019-08-24 The following pull-request contains BPF updates for your *net* tree. The main changes are: 1) Fix verifier precision tracking with BPF-to-BPF calls, from Alexei. 2) Fix a use-after-free in prog symbol exposure, from Daniel. 3) Several s390x JIT fixes plus BE related fixes in BPF kselftests, from Ilya. 4) Fix memory leak by unpinning XDP umem pages in error path, from Ivan. 5) Fix a potential use-after-free on flow dissector detach, from Jakub. 6) Fix bpftool to close prog fd after showing metadata, from Quentin. 7) BPF kselftest config and TEST_PROGS_EXTENDED fixes, from Anders. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-23ARM: at91: move platform-specific asm-offset.h to arch/arm/mach-at91Masahiro Yamada3-3/+5
<generated/at91_pm_data-offsets.h> is only generated and included by arch/arm/mach-at91/, so it does not need to reside in the globally visible include/generated/. I renamed it to arch/arm/mach-at91/pm_data-offsets.h since the prefix 'at91_' is just redundant in mach-at91/. My main motivation of this change is to avoid the race condition for the parallel build (-j) when CONFIG_IKHEADERS is enabled. When it is enabled, all the headers under include/ are archived into kernel/kheaders_data.tar.xz and exposed in the sysfs. In the parallel build, we have no idea in which order files are built. - If at91_pm_data-offsets.h is built before kheaders_data.tar.xz, the header will be included in the archive. Probably nobody will use it, but it is harmless except that it will increase the archive size needlessly. - If kheaders_data.tar.xz is built before at91_pm_data-offsets.h, the header will not be included in the archive. However, in the next build, the archive will be re-generated to include the newly-found at91_pm_data-offsets.h. This is not nice from the build system point of view. - If at91_pm_data-offsets.h and kheaders_data.tar.xz are built at the same time, the corrupted header might be included in the archive, which does not look nice either. This commit fixes the race. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Link: https://lore.kernel.org/r/20190823024346.591-1-yamada.masahiro@socionext.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2019-08-23MIPS: Fix build with CONFIG_PROC_VMCORE=yPaul Burton1-1/+1
Commit a94e4f24ec83 ("MIPS: init: Drop boot_mem_map") introduced a reference to a non-existant "end" field in struct memblock_region. Replace it with a sum of the base & size fields to fix builds with CONFIG_PROC_VMCORE=y. Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Paul Burton <paul.burton@mips.com>
2019-08-23MIPS: mm: Fix highmem compilePaul Burton1-0/+2
Commit a5718fe8f70f ("MIPS: mm: Drop boot_mem_map") removed the definition of a page variable for some reason, but that variable is still used. Restore it to fix compilation with CONFIG_HIGHMEM enabled. Signed-off-by: Paul Burton <paul.burton@mips.com>
2019-08-23arm64: kexec_file: add rng-seed supportHsin-Yi Wang1-1/+17
Adding "rng-seed" to dtb. It's fine to add this property if original fdt doesn't contain it. Since original seed will be wiped after read, so use a default size 128 bytes here. Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Will Deacon <will@kernel.org>
2019-08-23arm64: map FDT as RW for early_init_dt_scan()Hsin-Yi Wang4-20/+11
Currently in arm64, FDT is mapped to RO before it's passed to early_init_dt_scan(). However, there might be some codes (eg. commit "fdt: add support for rng-seed") that need to modify FDT during init. Map FDT to RO after early fixups are done. Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Mike Rapoport <rppt@linux.ibm.com> Signed-off-by: Will Deacon <will@kernel.org>
2019-08-23x86/retpoline: Don't clobber RFLAGS during CALL_NOSPEC on i386Sean Christopherson1-1/+1
Use 'lea' instead of 'add' when adjusting %rsp in CALL_NOSPEC so as to avoid clobbering flags. KVM's emulator makes indirect calls into a jump table of sorts, where the destination of the CALL_NOSPEC is a small blob of code that performs fast emulation by executing the target instruction with fixed operands. adcb_al_dl: 0x000339f8 <+0>: adc %dl,%al 0x000339fa <+2>: ret A major motiviation for doing fast emulation is to leverage the CPU to handle consumption and manipulation of arithmetic flags, i.e. RFLAGS is both an input and output to the target of CALL_NOSPEC. Clobbering flags results in all sorts of incorrect emulation, e.g. Jcc instructions often take the wrong path. Sans the nops... asm("push %[flags]; popf; " CALL_NOSPEC " ; pushf; pop %[flags]\n" 0x0003595a <+58>: mov 0xc0(%ebx),%eax 0x00035960 <+64>: mov 0x60(%ebx),%edx 0x00035963 <+67>: mov 0x90(%ebx),%ecx 0x00035969 <+73>: push %edi 0x0003596a <+74>: popf 0x0003596b <+75>: call *%esi 0x000359a0 <+128>: pushf 0x000359a1 <+129>: pop %edi 0x000359a2 <+130>: mov %eax,0xc0(%ebx) 0x000359b1 <+145>: mov %edx,0x60(%ebx) ctxt->eflags = (ctxt->eflags & ~EFLAGS_MASK) | (flags & EFLAGS_MASK); 0x000359a8 <+136>: mov -0x10(%ebp),%eax 0x000359ab <+139>: and $0x8d5,%edi 0x000359b4 <+148>: and $0xfffff72a,%eax 0x000359b9 <+153>: or %eax,%edi 0x000359bd <+157>: mov %edi,0x4(%ebx) For the most part this has gone unnoticed as emulation of guest code that can trigger fast emulation is effectively limited to MMIO when running on modern hardware, and MMIO is rarely, if ever, accessed by instructions that affect or consume flags. Breakage is almost instantaneous when running with unrestricted guest disabled, in which case KVM must emulate all instructions when the guest has invalid state, e.g. when the guest is in Big Real Mode during early BIOS. Fixes: 776b043848fd2 ("x86/retpoline: Add initial retpoline support") Fixes: 1a29b5b7f347a ("KVM: x86: Make indirect calls in emulator speculation safe") Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20190822211122.27579-1-sean.j.christopherson@intel.com
2019-08-23clocksource/drivers/hyperv: Enable TSC page clocksource on 32bitVitaly Kuznetsov1-3/+3
There is no particular reason to not enable TSC page clocksource on 32-bit. mul_u64_u64_shr() is available and despite the increased computational complexity (compared to 64bit) TSC page is still a huge win compared to MSR-based clocksource. In-kernel reads: MSR based clocksource: 3361 cycles TSC page clocksource: 49 cycles Reads from userspace (utilizing vDSO in case of TSC page): MSR based clocksource: 5664 cycles TSC page clocksource: 131 cycles Enabling TSC page on 32bits allows to get rid of CONFIG_HYPERV_TSCPAGE as it is now not any different from CONFIG_HYPERV_TIMER. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Link: https://lkml.kernel.org/r/20190822083630.17059-1-vkuznets@redhat.com
2019-08-23clocksource/drivers/hyperv: Add Hyper-V specific sched clock functionTianyu Lan2-2/+8
Hyper-V guests use the default native_sched_clock() in pv_ops.time.sched_clock on x86. But native_sched_clock() directly uses the raw TSC value, which can be discontinuous in a Hyper-V VM. Add the generic hv_setup_sched_clock() to set the sched clock function appropriately. On x86, this sets pv_ops.time.sched_clock to read the Hyper-V reference TSC value that is scaled and adjusted to be continuous. Also move the Hyper-V reference TSC initialization much earlier in the boot process so no discontinuity is observed when pv_ops.time.sched_clock calculates its offset. [ tglx: Folded build fix ] Signed-off-by: Tianyu Lan <Tianyu.Lan@microsoft.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Link: https://lkml.kernel.org/r/20190814123216.32245-3-Tianyu.Lan@microsoft.com
2019-08-23clocksource/drivers/hyperv: Allocate Hyper-V TSC page staticallyTianyu Lan1-1/+1
Prepare to add Hyper-V sched clock callback and move Hyper-V Reference TSC initialization much earlier in the boot process. Earlier initialization is needed so that it happens while the timestamp value is still 0 and no discontinuity in the timestamp will occur when pv_ops.time.sched_clock calculates its offset. The earlier initialization requires that the Hyper-V TSC page be allocated statically instead of with vmalloc(), so fixup the references to the TSC page and the method of getting its physical address. Signed-off-by: Tianyu Lan <Tianyu.Lan@microsoft.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lkml.kernel.org/r/20190814123216.32245-2-Tianyu.Lan@microsoft.com
2019-08-23MIPS: init: Drop boot_mem_mapJiaxun Yang2-286/+85
boot_mem_map was introduced very early and cannot handle memory maps with nid. Nowadays, memblock can exactly replace boot_mem_map. Detect pfn info and setup resources with memblock maps. Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> [paul.burton@mips.com: Fix size calculation in check_kernel_sections_mem] Signed-off-by: Paul Burton <paul.burton@mips.com> Cc: linux-mips@vger.kernel.org Cc: yasha.che3@gmail.com Cc: aurelien@aurel32.net Cc: sfr@canb.auug.org.au Cc: fancer.lancer@gmail.com Cc: matt.redfearn@mips.com Cc: chenhc@lemote.com
2019-08-23MIPS: mm: Drop boot_mem_mapJiaxun Yang1-56/+36
Initialize maar by resource map and replace page_is_ram by memblock_is_memory. Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> [paul.burton@mips.com: - Fix bad MAAR address calculations. - Use ALIGN() & define maar_align to make it clearer what's going on with address manipulations. - Drop the new used field from struct maar_config. - Rework the RAM walk to avoid iterating over the cfg array needlessly to find the first unused entry, then count used entries at the end. Instead just keep the count as we go.] Signed-off-by: Paul Burton <paul.burton@mips.com> Cc: linux-mips@vger.kernel.org Cc: yasha.che3@gmail.com Cc: aurelien@aurel32.net Cc: sfr@canb.auug.org.au Cc: fancer.lancer@gmail.com Cc: matt.redfearn@mips.com Cc: chenhc@lemote.com
2019-08-23MIPS: xlp: Drop boot_mem_mapJiaxun Yang1-6/+6
Simply replace with memblock functions. Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Paul Burton <paul.burton@mips.com> Cc: linux-mips@vger.kernel.org Cc: yasha.che3@gmail.com Cc: aurelien@aurel32.net Cc: sfr@canb.auug.org.au Cc: fancer.lancer@gmail.com Cc: matt.redfearn@mips.com Cc: chenhc@lemote.com
2019-08-23MIPS: ip22: Drop addr_is_ramJiaxun Yang1-18/+2
It can be replaced by page_is_ram. Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Paul Burton <paul.burton@mips.com> Cc: linux-mips@vger.kernel.org Cc: yasha.che3@gmail.com Cc: aurelien@aurel32.net Cc: sfr@canb.auug.org.au Cc: fancer.lancer@gmail.com Cc: matt.redfearn@mips.com Cc: chenhc@lemote.com
2019-08-23MIPS: msp: Record prom memoryJiaxun Yang1-6/+16
boot_mem_map is nolonger exist so we need to maintain a list of prom memory by ourselves Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Paul Burton <paul.burton@mips.com> Cc: linux-mips@vger.kernel.org Cc: yasha.che3@gmail.com Cc: aurelien@aurel32.net Cc: sfr@canb.auug.org.au Cc: fancer.lancer@gmail.com Cc: matt.redfearn@mips.com Cc: chenhc@lemote.com
2019-08-23MIPS: malta: Drop prom_free_prom_memoryJiaxun Yang1-11/+0
Current prom_free_prom_memory is freeing maps marked as BOOT_MEM_ROM_DATA, however, nobody is exactly setting this type for malta. Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Paul Burton <paul.burton@mips.com> Cc: linux-mips@vger.kernel.org Cc: yasha.che3@gmail.com Cc: aurelien@aurel32.net Cc: sfr@canb.auug.org.au Cc: fancer.lancer@gmail.com Cc: matt.redfearn@mips.com Cc: chenhc@lemote.com
2019-08-23MIPS: fw: Record prom memoryJiaxun Yang1-6/+18
boot_mem_map is nolonger exist so we need to maintain a list of prom memory by ourselves. Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Paul Burton <paul.burton@mips.com> Cc: linux-mips@vger.kernel.org Cc: yasha.che3@gmail.com Cc: aurelien@aurel32.net Cc: sfr@canb.auug.org.au Cc: fancer.lancer@gmail.com Cc: matt.redfearn@mips.com Cc: chenhc@lemote.com
2019-08-23MIPS: OCTEON: Drop boot_mem_mapJiaxun Yang2-12/+8
Replace walk through boot_mem_map with for_each_memblock. And remove the check of total boot_mem_map. Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Paul Burton <paul.burton@mips.com> Cc: linux-mips@vger.kernel.org Cc: yasha.che3@gmail.com Cc: aurelien@aurel32.net Cc: sfr@canb.auug.org.au Cc: fancer.lancer@gmail.com Cc: matt.redfearn@mips.com Cc: chenhc@lemote.com
2019-08-23arm64: dts: allwinner: orange-pi-3: Enable WiFiOndrej Jirman1-0/+46
Orange Pi 3 has AP6256 WiFi/BT module. WiFi part of the module is called bcm43356 and can be used with the brcmfmac driver. The module is powered by the two always on regulators (not AXP805). WiFi uses a PG port with 1.8V voltage level signals. SoC needs to be configured so that it sets up an 1.8V input bias on this port. This is done by the pio driver by reading the vcc-pg-supply voltage. You'll need a fw_bcm43456c5_ag.bin firmware file and nvram.txt configuration that can be found in the Xulongs's repository for H6: https://github.com/orangepi-xunlong/OrangePiH6_external/tree/master/ap6256 Mainline brcmfmac driver expects the firmware and nvram at the following paths relative to the firmware directory: brcm/brcmfmac43456-sdio.bin brcm/brcmfmac43456-sdio.txt Signed-off-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2019-08-23ARM: 8898/1: mm: Don't treat faults reported from cache maintenance as writesWill Deacon2-2/+3
Translation faults arising from cache maintenance instructions are rather unhelpfully reported with an FSR value where the WnR field is set to 1, indicating that the faulting access was a write. Since cache maintenance instructions on 32-bit ARM do not require any particular permissions, this can cause our private 'cacheflush' system call to fail spuriously if a translation fault is generated due to page aging when targetting a read-only VMA. In this situation, we will return -EFAULT to userspace, although this is unfortunately suppressed by the popular '__builtin___clear_cache()' intrinsic provided by GCC, which returns void. Although it's tempting to write this off as a userspace issue, we can actually do a little bit better on CPUs that support LPAE, even if the short-descriptor format is in use. On these CPUs, cache maintenance faults additionally set the CM field in the FSR, which we can use to suppress the write permission checks in the page fault handler and succeed in performing cache maintenance to read-only areas even in the presence of a translation fault. Reported-by: Orion Hodson <oth@google.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2019-08-23ARM: 8896/1: VDSO: Don't leak kernel addressesGeert Uytterhoeven1-1/+0
Since commit ad67b74d2469d9b8 ("printk: hash addresses printed with %p"), an obfuscated kernel pointer is printed at every boot if debugging is enabled: vdso: 1 text pages at base (____ptrval____) Remove the print completely, as it's useless without the address. Based on commit 0f1bf7e39822476b ("arm64/vdso: don't leak kernel addresses"). Fixes: ad67b74d2469d9b8 ("printk: hash addresses printed with %p") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2019-08-23ARM: 8895/1: visit mach-* and plat-* directories when cleaningMasahiro Yamada1-0/+4
When you run "make clean" for arm, it never visits mach-* or plat-* directories because machine-y and plat-y are just empty. When cleaning, all machine, plat directories are accumulated to machine-, plat-, respectively. So, let's pass them to core- to clean up those directories. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2019-08-23ARM: 8894/1: boot: Replace open-coded nop with macroLinus Walleij1-1/+1
This open-coded nop as mov r0, r0 is a development history artifact. First commit b11fe38883d1 ("ARM: 6663/1: make Thumb2 kernel entry point more similar to the ARM one") moved the code around so that the nops would come before the conditional thumb instructions, as it turned out that some boot loaders were patching the initial nop instructions in the kernel. At this point it is clear that all mov r0,r0 are open-coded nops. Then commit 81a0bc39ea19 ("ARM: add UEFI stub support") moved things around and defined __nop for EFI support and missed this open-coded nop. commit 06a4b6d009a1 ("ARM: 8677/1: boot/compressed: fix decompressor header layout for v7-M") makes all invocations of __nop be wide, but that is fine, because this is what we want: the mov r0,r0 is inside ifndef CONFIG_THUMB2_KERNEL. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Nicolas Pitre <nico@fluxnic.net> Acked-by: Roy Franz <rfranz@marvell.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2019-08-23ARM: 8893/1: boot: Explain the 8 nopsLinus Walleij1-0/+12
This was unclear to me until Russell explained the obvious that 8 nops are added to offset an a.out image. Reading git history reveals that thumb kernels first removed the nops and then kept 7 of them (the last instruction being a switch to thumb mode) as it turns out that some boot loaders were using this as a "patch area". Also the magic numbers after the initial nops and the jump of course need to stay in the same offset for kernel file detection. Make the code easier to understand with a comment. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Nicolas Pitre <nico@fluxnic.net> Acked-by: Roy Franz <rfranz@marvell.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2019-08-23ARM: 8876/1: fix O= building with CONFIG_FPE_FASTFPEMasahiro Yamada1-7/+2
To use Fastfpe, a user is supposed to enable CONFIG_FPE_FASTFPE and put downstream source files into arch/arm/fastfpe/. It is not working for O= build because $(wildcard arch/arm/fastfpe) checks if it exists in $(objtree), not in $(srctree). Add the $(srctree)/ prefix to fix it. While I was here, I slightly refactored the code. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2019-08-23ARM: 8875/1: Kconfig: default to AEABI w/ ClangNick Desaulniers1-2/+3
Clang produces references to __aeabi_uidivmod and __aeabi_idivmod for arm-linux-gnueabi and arm-linux-gnueabihf targets incorrectly when AEABI is not selected (such as when OABI_COMPAT is selected). While this means that OABI userspaces wont be able to upgraded to kernels built with Clang, it means that boards that don't enable AEABI like s3c2410_defconfig will stop failing to link in KernelCI when built with Clang. Link: https://github.com/ClangBuiltLinux/linux/issues/482 Link: https://groups.google.com/forum/#!msg/clang-built-linux/yydsAAux5hk/GxjqJSW-AQAJ Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>