aboutsummaryrefslogtreecommitdiffstats
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2019-08-05arm64: dts: qcom: msm8998: Node ordering, address cleanupsJeffrey Hugo1-127/+127
DT nodes should be ordered by address, then node name, and finally label. The msm8998 dtsi does not follow this, so clean it up by reordering the nodes. While we are at it, extend the addresses to be fully 32-bits wide so that ordering is easy to determine when adding new nodes. Also, two or so nodes had the wrong address value in their node name (did not match the reg property), so fix those up as well. Hopefully going forward, things can be maintained so that a cleanup like this is not needed. Reviewed-by: Vinod Koul <vkoul@kernel.org> Reviewed-by: Marc Gonzalez <marc.w.gonzalez@free.fr> Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2019-08-05arm64: dts: qcom: sdm845-cheza: Spelling s/conenctors/connectors/Geert Uytterhoeven1-1/+1
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2019-08-05arm64: dts: qcom: qcs404: Add wifi rails in QCS404 dt node for proxy votesGovind Singh1-0/+3
Add wifi regulators in qcs404 dt node for proxy vote. Proxy votes are required for handling driver recovery scenarios to prevent un-clocked register access during driver recovery. Signed-off-by: Govind Singh <govinds@codeaurora.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2019-08-05arm64: dts: qcom: qcs404: remove unit name for thermal trip pointsVinod Koul1-15/+15
The thermal trip points have unit name but no reg property, so we can remove them arch/arm64/boot/dts/qcom/qcs404.dtsi:1080.31-1084.7: Warning (unit_address_vs_reg): /thermal-zones/aoss-thermal/trips/trip-point@0: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/qcs404.dtsi:1095.33-1099.7: Warning (unit_address_vs_reg): /thermal-zones/q6-hvx-thermal/trips/trip-point@0: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/qcs404.dtsi:1110.32-1114.7: Warning (unit_address_vs_reg): /thermal-zones/lpass-thermal/trips/trip-point@0: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/qcs404.dtsi:1125.31-1129.7: Warning (unit_address_vs_reg): /thermal-zones/wlan-thermal/trips/trip-point@0: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/qcs404.dtsi:1140.34-1144.7: Warning (unit_address_vs_reg): /thermal-zones/cluster-thermal/trips/trip-point@0: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/qcs404.dtsi:1145.34-1149.7: Warning (unit_address_vs_reg): /thermal-zones/cluster-thermal/trips/trip-point@1: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/qcs404.dtsi:1174.31-1178.7: Warning (unit_address_vs_reg): /thermal-zones/cpu0-thermal/trips/trip-point@0: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/qcs404.dtsi:1179.31-1183.7: Warning (unit_address_vs_reg): /thermal-zones/cpu0-thermal/trips/trip-point@1: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/qcs404.dtsi:1208.31-1212.7: Warning (unit_address_vs_reg): /thermal-zones/cpu1-thermal/trips/trip-point@0: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/qcs404.dtsi:1213.31-1217.7: Warning (unit_address_vs_reg): /thermal-zones/cpu1-thermal/trips/trip-point@1: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/qcs404.dtsi:1242.31-1246.7: Warning (unit_address_vs_reg): /thermal-zones/cpu2-thermal/trips/trip-point@0: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/qcs404.dtsi:1247.31-1251.7: Warning (unit_address_vs_reg): /thermal-zones/cpu2-thermal/trips/trip-point@1: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/qcs404.dtsi:1276.31-1280.7: Warning (unit_address_vs_reg): /thermal-zones/cpu3-thermal/trips/trip-point@0: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/qcs404.dtsi:1281.31-1285.7: Warning (unit_address_vs_reg): /thermal-zones/cpu3-thermal/trips/trip-point@1: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/qcs404.dtsi:1310.30-1314.7: Warning (unit_address_vs_reg): /thermal-zones/gpu-thermal/trips/trip-point@0: node has a unit name, but no reg property Signed-off-by: Vinod Koul <vkoul@kernel.org> Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2019-08-05arm64: dts: qcom: pms405: remove reduandant propertiesVinod Koul1-2/+0
pms405@1 nodes specified unnecessary #address-cells/#size-cells but the subnodes dont have "ranges" or "reg" so remove it arch/arm64/boot/dts/qcom/pms405.dtsi:141.21-150.4: Warning (avoid_unnecessary_addr_size): /soc@0/spmi@200f000/pms405@1: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property Signed-off-by: Vinod Koul <vkoul@kernel.org> Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2019-08-05arm64: dts: qcom: pms405: add unit name adc nodesVinod Koul1-7/+7
The adc nodes have reg property but were missing the unit name, so add that to fix these warnings: arch/arm64/boot/dts/qcom/pms405.dtsi:91.12-94.6: Warning (unit_address_vs_reg): /soc@0/spmi@200f000/pms405@0/adc@3100/ref_gnd: node has a reg or ranges property, but no unit name arch/arm64/boot/dts/qcom/pms405.dtsi:96.14-99.6: Warning (unit_address_vs_reg): /soc@0/spmi@200f000/pms405@0/adc@3100/vref_1p25: node has a reg or ranges property, but no unit name arch/arm64/boot/dts/qcom/pms405.dtsi:101.19-104.6: Warning (unit_address_vs_reg): /soc@0/spmi@200f000/pms405@0/adc@3100/vph_pwr: node has a reg or ranges property, but no unit name arch/arm64/boot/dts/qcom/pms405.dtsi:106.13-109.6: Warning (unit_address_vs_reg): /soc@0/spmi@200f000/pms405@0/adc@3100/die_temp: node has a reg or ranges property, but no unit name arch/arm64/boot/dts/qcom/pms405.dtsi:111.27-116.6: Warning (unit_address_vs_reg): /soc@0/spmi@200f000/pms405@0/adc@3100/thermistor1: node has a reg or ranges property, but no unit name arch/arm64/boot/dts/qcom/pms405.dtsi:118.27-123.6: Warning (unit_address_vs_reg): /soc@0/spmi@200f000/pms405@0/adc@3100/thermistor3: node has a reg or ranges property, but no unit name arch/arm64/boot/dts/qcom/pms405.dtsi:125.22-130.6: Warning (unit_address_vs_reg): /soc@0/spmi@200f000/pms405@0/adc@3100/xo_temp: node has a reg or ranges property, but no unit name Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2019-08-05arm64: dts: sdm845: Add device node for Last level cache controllerSai Prakash Ranjan1-0/+7
Last level cache (aka. system cache) controller provides control over the last level cache present on SDM845. This cache lies after the memory noc, right before the DDR. Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2019-08-05arm64: dts: qcom: msm8996: Rename smmu nodesBjorn Andersson1-4/+4
Node names shouldn't include a vendor prefix and should whenever possible use a generic identifier. Resolve this by renaming the smmu nodes "iommu". Reviewed-by: Vivek Gautam <vivek.gautam@codeaurora.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2019-08-05ARM: dts: meson8b: mxq: add the VDDEE regulatorMartin Blumenstingl1-3/+23
The VDDEE regulator is basically a copy of the VCCK regulator. VDDEE supplies for example the Mali GPU and is controlled by PWM_D instead of PWM_C. Add the VDDEE PWM regulator and make it the supply of the Mali GPU. Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2019-08-05ARM: dts: meson8b: odroidc1: add the VDDEE regulatorMartin Blumenstingl1-3/+24
The VDDEE regulator is basically a copy of the VCCK regulator. VDDEE supplies for example the Mali GPU and is controlled by PWM_D instead of PWM_C. Add the VDDEE PWM regulator and make it the supply of the Mali GPU. Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2019-08-05ARM: dts: meson8b: ec100: add the VDDEE regulatorMartin Blumenstingl1-3/+28
The VDDEE regulator is basically a copy of the VCCK regulator. VDDEE supplies for example the Mali GPU and is controlled by PWM_D instead of PWM_C. Add the VDDEE PWM regulator and make it the supply of the Mali GPU. Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2019-08-05ARM: dts: meson8b: add the PWM_D output pinMartin Blumenstingl1-0/+8
The PWM_D output is used for the VDDEE PWM regulator which supplies for example the Mali GPU on the EC-100 and Odroid-C1 boards. Add the output pin the VDDEE regulators can be added. Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2019-08-05ARM: dts: meson8b: add ethernet fifo sizesJerome Brunet1-0/+2
If unspecified in DT, the fifo sizes are not automatically detected by the dwmac1000 dma driver and the reported fifo sizes default to 0. Because of this, flow control will be turned off on the device. Add the fifo sizes provided by the datasheet in the SoC in DT so flow control may be enabled if necessary. Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2019-08-05arm64: dts: amlogic: odroid-n2: keep SD card regulator always onXavier Ruppen1-0/+1
When powering off the Odroid N2, the tflash_vdd regulator is automatically turned off by the kernel. This is a problem when issuing the "reboot" command while using an SD card. The boot ROM does not power this regulator back on, blocking the reboot process at the boot ROM stage, preventing the SD card from being detected. Adding the "regulator-always-on" property fixes the problem. Signed-off-by: Xavier Ruppen <xruppen@gmail.com> Suggested-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Fixes: c35f6dc5c377 ("arm64: dts: meson: Add minimal support for Odroid-N2") [khilman: minor subject change: s/meson/amlogic/] Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2019-08-05arm64: dts: meson-g12a-sei510: enable IR controllerNeil Armstrong1-0/+6
Enable the IR receiver controller on the SEI510 board. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2019-08-05arm64: dts: meson-g12a: add missing dwc2 phy-namesNeil Armstrong1-0/+1
The G12A USB2 OTG capable PHY uses a 8bit large UTMI bus, and the OTG controller gets the PHY but width by probing the associated phy. By default it will use 16bit wide settings if a phy is not specified, in our case we specified the phy, but not the phy-names. The dwc2 bindings specifies that if phys is present, phy-names shall be "usb2-phy". Adding phy-names = "usb2-phy" solves the OTG PHY bus configuration. Fixes: 9baf7d6be730 ("arm64: dts: meson: g12a: Add G12A USB nodes") Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2019-08-05arm64: dts: renesas: r8a774c0: cat874: Add definition for 12V regulatorFabrizio Castro1-0/+9
Power rail "D12.0V" comes straight from the power barrel connector, and it's used in both main board and sub board. Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2019-08-05arm64: dts: renesas: r8a774c0: Point LVDS0 to its companion LVDS1Fabrizio Castro1-0/+2
Add the new renesas,companion property to the LVDS0 node to point to the companion LVDS encoder LVDS1. Based on similar work from Laurent Pinchart for the r8a7799[05]. Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2019-08-05arm64: dts: renesas: r8a77995: Sort nodesYoshihiro Kaneko1-38/+38
Sort nodes. If node address is present * Sort by node address, grouping all nodes with the same compat string and sorting the group alphabetically. Else * Sort alphabetically This should not have any run-time effect. Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2019-08-05arm64: dts: renesas: r8a77995: draak: Sort nodesYoshihiro Kaneko1-5/+5
Sort nodes. If node address is present * Sort by node address, grouping all nodes with the same compat string and sorting the group alphabetically. Else * Sort alphabetically This should not have any run-time effect. Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2019-08-05arm64: dts: renesas: r8a77990: Sort nodesYoshihiro Kaneko1-22/+22
Sort nodes. If node address is present * Sort by node address, grouping all nodes with the same compat string and sorting the group alphabetically. Else * Sort alphabetically This should not have any run-time effect. Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2019-08-05arm64: dts: renesas: r8a77990: ebisu: Sort nodesYoshihiro Kaneko1-104/+104
Sort nodes. If node address is present * Sort by node address, grouping all nodes with the same compat string and sorting the group alphabetically. Else * Sort alphabetically This should not have any run-time effect. Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com> [geert: Sort sound child nodes] Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2019-08-05arm64: dts: renesas: r8a77980: v3hsk: Sort nodesYoshihiro Kaneko1-6/+6
Sort nodes. If node address is present * Sort by node address, grouping all nodes with the same compat string and sorting the group alphabetically. Else * Sort alphabetically This should not have any run-time effect. Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2019-08-05arm64: dts: renesas: r8a77980: condor: Sort nodesYoshihiro Kaneko1-21/+21
Sort nodes. If node address is present * Sort by node address, grouping all nodes with the same compat string and sorting the group alphabetically. Else * Sort alphabetically This should not have any run-time effect. Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2019-08-05arm64: dts: renesas: r8a77970: v3msk: Sort nodesYoshihiro Kaneko1-58/+58
Sort nodes. If node address is present * Sort by node address, grouping all nodes with the same compat string and sorting the group alphabetically. Else * Sort alphabetically This should not have any run-time effect. Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2019-08-05arm64: dts: renesas: r8a77970: eagle: Sort nodesYoshihiro Kaneko1-29/+29
Sort nodes. If node address is present * Sort by node address, grouping all nodes with the same compat string and sorting the group alphabetically. Else * Sort alphabetically This should not have any run-time effect. Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2019-08-05ARC: [plat-hsdk]: allow to switch between AXI DMAC port configurationsEugeniy Paltsev2-12/+78
We want to use DW AXI DMAC on HSDK board in our automated verification to test cache & dma kernel code changes. This is perfect candidate as we don't depend on any external peripherals like MMC card / USB storage / etc. To increase test coverage we want to test both options: * DW AXI DMAC is connected through IOC port & dma direct ops used * DW AXI DMAC is connected to DDR port & dma noncoherent ops used Introduce 'arc_hsdk_axi_dmac_coherent' global variable which can be modified by debugger (same way as we patch 'ioc_enable') to switch between these options without recompiling the kernel. Depend on this value we tweak memory bridge configuration and "dma-coherent" DTS property of DW AXI DMAC. Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> Acked-by: Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
2019-08-05arm64: Add support for relocating the kernel with RELR relocationsPeter Collingbourne4-6/+114
RELR is a relocation packing format for relative relocations. The format is described in a generic-abi proposal: https://groups.google.com/d/topic/generic-abi/bX460iggiKg/discussion The LLD linker can be instructed to pack relocations in the RELR format by passing the flag --pack-dyn-relocs=relr. This patch adds a new config option, CONFIG_RELR. Enabling this option instructs the linker to pack vmlinux's relative relocations in the RELR format, and causes the kernel to apply the relocations at startup along with the RELA relocations. RELA relocations still need to be applied because the linker will emit RELA relative relocations if they are unrepresentable in the RELR format (i.e. address not a multiple of 2). Enabling CONFIG_RELR reduces the size of a defconfig kernel image with CONFIG_RANDOMIZE_BASE by 3.5MB/16% uncompressed, or 550KB/5% compressed (lz4). Signed-off-by: Peter Collingbourne <pcc@google.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Will Deacon <will@kernel.org>
2019-08-05arm64: Move TIF_* documentation to individual definitionsGeert Uytterhoeven1-18/+7
Some TIF_* flags are documented in the comment block at the top, some next to their definitions, some in both places. Move all documentation to the individual definitions for consistency, and for easy lookup. Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Will Deacon <will@kernel.org>
2019-08-05arm64: mm: free the initrd reserved memblock in a aligned mannerJunhua Huang1-1/+5
We should free the initrd reserved memblock in an aligned manner, because the initrd reserves the memblock in an aligned manner in arm64_memblock_init(). Otherwise there are some fragments in memblock_reserved regions after free_initrd_mem(). e.g.: /sys/kernel/debug/memblock # cat reserved 0: 0x0000000080080000..0x00000000817fafff 1: 0x0000000083400000..0x0000000083ffffff 2: 0x0000000090000000..0x000000009000407f 3: 0x00000000b0000000..0x00000000b000003f 4: 0x00000000b26184ea..0x00000000b2618fff The fragments like the ranges from b0000000 to b000003f and from b26184ea to b2618fff should be freed. And we can do free_reserved_area() after memblock_free(), as free_reserved_area() calls __free_pages(), once we've done that it could be allocated somewhere else, but memblock and iomem still say this is reserved memory. Fixes: 05c58752f9dc ("arm64: To remove initrd reserved area entry from memblock") Signed-off-by: Junhua Huang <huang.junhua@zte.com.cn> Signed-off-by: Will Deacon <will@kernel.org>
2019-08-05arm64: io: Relax implicit barriers in default I/O accessorsWill Deacon1-2/+2
The arm64 implementation of the default I/O accessors requires barrier instructions to satisfy the memory ordering requirements documented in memory-barriers.txt [1], which are largely derived from the behaviour of I/O accesses on x86. Of particular interest are the requirements that a write to a device must be ordered against prior writes to memory, and a read from a device must be ordered against subsequent reads from memory. We satisfy these requirements using various flavours of DSB: the most expensive barrier we have, since it implies completion of prior accesses. This was deemed necessary when we first implemented the accessors, since accesses to different endpoints could propagate independently and therefore the only way to enforce order is to rely on completion guarantees [2]. Since then, the Armv8 memory model has been retrospectively strengthened to require "other-multi-copy atomicity", a property that requires memory accesses from an observer to become visible to all other observers simultaneously [3]. In other words, propagation of accesses is limited to transitioning from locally observed to globally observed. It recently became apparent that this change also has a subtle impact on our I/O accessors for shared peripherals, allowing us to use the cheaper DMB instruction instead. As a concrete example, consider the following: memcpy(dma_buffer, data, bufsz); writel(DMA_START, dev->ctrl_reg); A DMB ST instruction between the final write to the DMA buffer and the write to the control register will ensure that the writes to the DMA buffer are observed before the write to the control register by all observers. Put another way, if an observer can see the write to the control register, it can also see the writes to memory. This has always been the case and is not sufficient to provide the ordering required by Linux, since there is no guarantee that the master interface of the DMA-capable device has observed either of the accesses. However, in an other-multi-copy atomic world, we can infer two things: 1. A write arriving at an endpoint shared between multiple CPUs is visible to all CPUs 2. A write that is visible to all CPUs is also visible to all other observers in the shareability domain Pieced together, this allows us to use DMB OSHST for our default I/O write accessors and DMB OSHLD for our default I/O read accessors (the outer-shareability is for handling non-cacheable mappings) for shared devices. Memory-mapped, DMA-capable peripherals that are private to a CPU (i.e. inaccessible to other CPUs) still require the DSB, however these are few and far between and typically require special treatment anyway which is outside of the scope of the portable driver API (e.g. GIC, page-table walker, SPE profiler). Note that our mandatory barriers remain as DSBs, since there are cases where they are used to flush the store buffer of the CPU, e.g. when publishing page table updates to the SMMU. [1] https://git.kernel.org/linus/4614bbdee357 [2] https://www.youtube.com/watch?v=i6DayghhA8Q [3] https://www.cl.cam.ac.uk/~pes20/armv8-mca/ Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-08-05x86: kvm: remove useless calls to kvm_para_availablePaolo Bonzini1-8/+0
Most code in arch/x86/kernel/kvm.c is called through x86_hyper_kvm, and thus only runs if KVM has been detected. There is no need to check again for the CPUID base. Cc: Sergio Lopez <slp@redhat.com> Cc: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-08-05KVM: no need to check return value of debugfs_create functionsGreg KH1-28/+13
When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Also, when doing this, change kvm_arch_create_vcpu_debugfs() to return void instead of an integer, as we should not care at all about if this function actually does anything or not. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Radim Krčmář" <rkrcmar@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: <x86@kernel.org> Cc: <kvm@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-08-05KVM: remove kvm_arch_has_vcpu_debugfs()Paolo Bonzini5-35/+2
There is no need for this function as all arches have to implement kvm_arch_create_vcpu_debugfs() no matter what. A #define symbol let us actually simplify the code. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-08-05KVM: Fix leak vCPU's VMCS value into other pCPUWanpeng Li5-0/+34
After commit d73eb57b80b (KVM: Boost vCPUs that are delivering interrupts), a five years old bug is exposed. Running ebizzy benchmark in three 80 vCPUs VMs on one 80 pCPUs Skylake server, a lot of rcu_sched stall warning splatting in the VMs after stress testing: INFO: rcu_sched detected stalls on CPUs/tasks: { 4 41 57 62 77} (detected by 15, t=60004 jiffies, g=899, c=898, q=15073) Call Trace: flush_tlb_mm_range+0x68/0x140 tlb_flush_mmu.part.75+0x37/0xe0 tlb_finish_mmu+0x55/0x60 zap_page_range+0x142/0x190 SyS_madvise+0x3cd/0x9c0 system_call_fastpath+0x1c/0x21 swait_active() sustains to be true before finish_swait() is called in kvm_vcpu_block(), voluntarily preempted vCPUs are taken into account by kvm_vcpu_on_spin() loop greatly increases the probability condition kvm_arch_vcpu_runnable(vcpu) is checked and can be true, when APICv is enabled the yield-candidate vCPU's VMCS RVI field leaks(by vmx_sync_pir_to_irr()) into spinning-on-a-taken-lock vCPU's current VMCS. This patch fixes it by checking conservatively a subset of events. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Marc Zyngier <Marc.Zyngier@arm.com> Cc: stable@vger.kernel.org Fixes: 98f4a1467 (KVM: add kvm_arch_vcpu_runnable() test to kvm_vcpu_on_spin() loop) Signed-off-by: Wanpeng Li <wanpengli@tencent.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-08-05KVM: LAPIC: Don't need to wakeup vCPU twice afer timer fireWanpeng Li1-8/+0
kvm_set_pending_timer() will take care to wake up the sleeping vCPU which has pending timer, don't need to check this in apic_timer_expired() again. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Signed-off-by: Wanpeng Li <wanpengli@tencent.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-08-05arm64: dts: fast models: Remove clcd's max-memory-bandwidthKevin Brodsky2-10/+0
It is unclear why max-memory-bandwidth should be set for CLCD on the fast model. Removing that property allows allocating and using 32bpp buffers, which may be desirable on certain platforms such as Android. Reported-by: Ruben Ayrapetyan <ruben.ayrapetyan@arm.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-08-05arm64: Remove unused cpucap_multi_entry_cap_cpu_enable()Mark Brown1-15/+0
The function cpucap_multi_entry_cap_cpu_enable() is unused, remove it to avoid any confusion reading the code and potential for bit rot. Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2019-08-05arm64: sysreg: Remove unused and rotting SCTLR_ELx field definitionsWill Deacon1-29/+0
Our SCTLR_ELx field definitions are somewhat over-engineered in that they carefully define masks describing the RES0/RES1 bits and then use these to construct further masks representing bits to be set/cleared for the _EL1 and _EL2 registers. However, most of the resulting definitions aren't actually used by anybody and have subsequently started to bit-rot when new fields have been added by the architecture, resulting in fields being part of the RES0 mask despite being defined and used elsewhere. Rather than fix up these masks, simply remove the unused parts entirely so that we can drop the maintenance burden. We can always add things back if we need them in the future. Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2019-08-05arm64: esr: Add ESR exception class encoding for trapped ERETWill Deacon2-1/+3
The ESR.EC encoding of 0b011010 (0x1a) describes an exception generated by an ERET, ERETAA or ERETAB instruction as a result of a nested virtualisation trap to EL2. Add an encoding for this EC and a string description so that we identify it correctly if we take one unexpectedly. Acked-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2019-08-05arm64: Replace strncmp with str_has_prefixChuhong Yuan2-2/+2
In commit b6b2735514bc ("tracing: Use str_has_prefix() instead of using fixed sizes") the newly introduced str_has_prefix() was used to replace error-prone strncmp(str, const, len). Here fix codes with the same pattern. Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Signed-off-by: Will Deacon <will@kernel.org>
2019-08-05arm64: remove unneeded uapi/asm/stat.hMasahiro Yamada1-17/+0
stat.h is listed in include/uapi/asm-generic/Kbuild, so Kbuild will automatically generate it. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Will Deacon <will@kernel.org>
2019-08-05arm64/kexec: Use consistent convention of initializing 'kxec_buf.mem' with KEXEC_BUF_MEM_UNKNOWNBhupesh Sharma2-3/+3
With commit b6664ba42f14 ("s390, kexec_file: drop arch_kexec_mem_walk()"), we introduced the KEXEC_BUF_MEM_UNKNOWN macro. If kexec_buf.mem is set to this value, kexec_locate_mem_hole() will try to allocate free memory. While other arch(s) like s390 and x86_64 already use this macro to initialize kexec_buf.mem with, arm64 uses an equivalent value of 0. Replace it with KEXEC_BUF_MEM_UNKNOWN, to keep the convention of initializing 'kxec_buf.mem' consistent across various archs. Cc: takahiro.akashi@linaro.org Cc: james.morse@arm.com Reviewed-by: Matthias Brugger <mbrugger@suse.com> Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Will Deacon <will@kernel.org>
2019-08-05arm64: remove pointless __KERNEL__ guardsMark Rutland16-46/+3
For a number of years, UAPI headers have been split from kernel-internal headers. The latter are never exposed to userspace, and always built with __KERNEL__ defined. Most headers under arch/arm64 don't have __KERNEL__ guards, but there are a few stragglers lying around. To make things more consistent, and to set a good example going forward, let's remove these redundant __KERNEL__ guards. In a couple of cases, a trailing #endif lacked a comment describing its corresponding #if or #ifdef, so these are fixes up at the same time. Guards in auto-generated crypto code are left as-is, as these guards are generated by scripting imported from the upstream openssl project scripts. Guards in UAPI headers are left as-is, as these can be included by userspace or the kernel. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2019-08-05arm64: Remove unused assembly macroJulien Thierry1-11/+0
As of commit 4141c857fd09dbed480f021b3eece4f46c653161 ("arm64: convert raw syscall invocation to C"), moving syscall handling from assembly to C, the macro mask_nospec64 is no longer referenced. Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Julien Thierry <julien.thierry@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2019-08-05powerpc/pseries/hotplug-memory.c: Replace nested ifs by switch-caseLeonardo Bras1-8/+18
I noticed these nested ifs can be easily replaced by switch-cases, which can improve readability. Signed-off-by: Leonardo Bras <leonardo@linux.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20190801225251.17864-1-leonardo@linux.ibm.com
2019-08-05powerpc/xive: Update comment referencing magic loads from an ESBJordan Niethe1-1/+1
The comment above xive_esb_read() references magic loads from an ESB as described xive.h. This has been inaccurate since commit 12c1f339cd49 ("powerpc/xive: Move definition of ESB bits") which moved the description. Update the comment to reference the new location of the description in xive-regs.h Signed-off-by: Jordan Niethe <jniethe5@gmail.com> Acked-by: Stewart Smith <stewart@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20190802000835.26191-1-jniethe5@gmail.com
2019-08-05powerpc/32: activate ARCH_HAS_PMEM_API and ARCH_HAS_UACCESS_FLUSHCACHEChristophe Leroy2-4/+4
PPC32 also have flush_dcache_range() so it can also support ARCH_HAS_PMEM_API and ARCH_HAS_UACCESS_FLUSHCACHE without changes. Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/a682a2f9db308c5cfe77e45aa3352e41bc9f4e33.1564554634.git.christophe.leroy@c-s.fr
2019-08-05powerpc/powernv: Restrict OPAL symbol map to only be readable by rootAndrew Donnellan1-4/+7
Currently the OPAL symbol map is globally readable, which seems bad as it contains physical addresses. Restrict it to root. Fixes: c8742f85125d ("powerpc/powernv: Expose OPAL firmware symbol map") Cc: stable@vger.kernel.org # v3.19+ Suggested-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20190503075253.22798-1-ajd@linux.ibm.com
2019-08-05powerpc/configs: Disable SCOM_DEBUGFS in powernv_defconfigAndrew Donnellan1-1/+1
SCOM_DEBUGFS is really not needed for anything other than low-level hardware debugging. mpe: It also introduces a large and poorly documented/understood attack surface. Although the interface is only available to root, the kernel still aspires to restrict root to accessing hardware through well defined interfaces, which this is not. opal-prd uses its own interface (/dev/prd) for SCOM access, so it doesn't need SCOM_DEBUGFS. At some point in the future we'll introduce a debug config fragment where this can go instead. Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20190509051119.7694-5-ajd@linux.ibm.com