aboutsummaryrefslogtreecommitdiffstats
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2022-05-03ARM: dts: BCM5301X: Add DT for WZR-1166DHP,DHP2SHIMAMOTO Takayoshi4-0/+246
Buffalo WZR-1166DHP/WZR-1166DHP2 wireless router with - BCM4708A0 - 128MiB NAND flash - 2T2R 11ac/a/b/g/n Wi-Fi - 4x 10/100/1000M ethernet switch - 1x USB 3.0 port WZR-1166DHP and WZR-1166DHP2 have different memory capacity. WZR-1166DHP - 512 MiB DDR2 SDRAM WZR-1166DHP2 - 256 MiB DDR2 SDRAM These hardware components are very similar to the WZR-1750DHP except for the number of antennas. Signed-off-by: SHIMAMOTO Takayoshi <takayoshi.shimamoto.360@gmail.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
2022-05-03KVM: arm64: Add vendor hypervisor firmware registerRaghavendra Rao Ananta3-5/+30
Introduce the firmware register to hold the vendor specific hypervisor service calls (owner value 6) as a bitmap. The bitmap represents the features that'll be enabled for the guest, as configured by the user-space. Currently, this includes support for KVM-vendor features along with reading the UID, represented by bit-0, and Precision Time Protocol (PTP), represented by bit-1. Signed-off-by: Raghavendra Rao Ananta <rananta@google.com> Reviewed-by: Gavin Shan <gshan@redhat.com> [maz: tidy-up bitmap values] Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220502233853.1233742-5-rananta@google.com
2022-05-03KVM: arm64: Add standard hypervisor firmware registerRaghavendra Rao Ananta3-3/+29
Introduce the firmware register to hold the standard hypervisor service calls (owner value 5) as a bitmap. The bitmap represents the features that'll be enabled for the guest, as configured by the user-space. Currently, this includes support only for Paravirtualized time, represented by bit-0. Signed-off-by: Raghavendra Rao Ananta <rananta@google.com> Reviewed-by: Gavin Shan <gshan@redhat.com> [maz: tidy-up bitmap values] Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220502233853.1233742-4-rananta@google.com
2022-05-03KVM: arm64: Setup a framework for hypercall bitmap firmware registersRaghavendra Rao Ananta5-2/+136
KVM regularly introduces new hypercall services to the guests without any consent from the userspace. This means, the guests can observe hypercall services in and out as they migrate across various host kernel versions. This could be a major problem if the guest discovered a hypercall, started using it, and after getting migrated to an older kernel realizes that it's no longer available. Depending on how the guest handles the change, there's a potential chance that the guest would just panic. As a result, there's a need for the userspace to elect the services that it wishes the guest to discover. It can elect these services based on the kernels spread across its (migration) fleet. To remedy this, extend the existing firmware pseudo-registers, such as KVM_REG_ARM_PSCI_VERSION, but by creating a new COPROC register space for all the hypercall services available. These firmware registers are categorized based on the service call owners, but unlike the existing firmware pseudo-registers, they hold the features supported in the form of a bitmap. During the VM initialization, the registers are set to upper-limit of the features supported by the corresponding registers. It's expected that the VMMs discover the features provided by each register via GET_ONE_REG, and write back the desired values using SET_ONE_REG. KVM allows this modification only until the VM has started. Some of the standard features are not mapped to any bits of the registers. But since they can recreate the original problem of making it available without userspace's consent, they need to be explicitly added to the case-list in kvm_hvc_call_default_allowed(). Any function-id that's not enabled via the bitmap, or not listed in kvm_hvc_call_default_allowed, will be returned as SMCCC_RET_NOT_SUPPORTED to the guest. Older userspace code can simply ignore the feature and the hypercall services will be exposed unconditionally to the guests, thus ensuring backward compatibility. In this patch, the framework adds the register only for ARM's standard secure services (owner value 4). Currently, this includes support only for ARM True Random Number Generator (TRNG) service, with bit-0 of the register representing mandatory features of v1.0. Other services are momentarily added in the upcoming patches. Signed-off-by: Raghavendra Rao Ananta <rananta@google.com> Reviewed-by: Gavin Shan <gshan@redhat.com> [maz: reduced the scope of some helpers, tidy-up bitmap max values, dropped error-only fast path] Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220502233853.1233742-3-rananta@google.com
2022-05-03ARM: dts: qcom: msm8974-FP2: Add supplies for remoteprocsLuca Weiss1-0/+11
Those were removed from msm8974.dtsi as part of a recent cleanup commit, so add them back for FP2. Signed-off-by: Luca Weiss <luca@z3ntu.xyz> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220421214243.352469-3-luca@z3ntu.xyz
2022-05-03ARM: dts: qcom: msm8974-FP2: Configure chargerLuca Weiss1-0/+10
Set the relevant properties on the smbb charger to allow the device to charge properly. Signed-off-by: Luca Weiss <luca@z3ntu.xyz> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220421214243.352469-2-luca@z3ntu.xyz
2022-05-03ARM: dts: qcom: msm8974-FP2: Add support for touchscreenLuca Weiss1-0/+15
Configure the touchscreen found on the new display module of the FP2. To add some detail, FP2 has two different screen/touchscreen variants ("display module"), the old module has Synaptics touchscreen, the new one this Ilitek touchscreen. We're only supporting the new display module for now. Signed-off-by: Luca Weiss <luca@z3ntu.xyz> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220421214243.352469-1-luca@z3ntu.xyz
2022-05-03arm64: dts: qcom: sc7280-qcard: Configure CTS pin to bias-bus-hold for bluetoothVijaya Krishna Nivarthi1-5/+14
WLAN rail was leaking power during RBSC/sleep even after turning BT off. Change active and sleep pinctrl configurations to handle same. Signed-off-by: Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/1650556567-4995-3-git-send-email-quic_vnivarth@quicinc.com
2022-05-03arm64: dts: qcom: sc7280-idp: Configure CTS pin to bias-bus-hold for bluetoothVijaya Krishna Nivarthi1-6/+12
WLAN rail was leaking power during RBSC/sleep even after turning BT off. Change active and sleep pinctrl configurations to handle same. Signed-off-by: Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/1650556567-4995-2-git-send-email-quic_vnivarth@quicinc.com
2022-05-03ARM: dts: qcom: sdx55: Remove ipa interconnect nodeStephen Boyd1-7/+0
This device node is unused now that we've removed the driver that consumed it in the kernel. Drop the unused node to save some space. Cc: Alex Elder <elder@linaro.org> Cc: Taniya Das <quic_tdas@quicinc.com> Cc: Mike Tipton <quic_mdtipton@quicinc.com> Cc: Georgi Djakov <djakov@kernel.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Alex Elder <elder@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220415005828.1980055-2-swboyd@chromium.org
2022-05-03arm64: dts: qcom: sc7180: Remove ipa interconnect nodeStephen Boyd1-7/+0
This device node is unused now that we've removed the driver that consumed it in the kernel. Drop the unused node to save some space. Cc: Alex Elder <elder@linaro.org> Cc: Taniya Das <quic_tdas@quicinc.com> Cc: Mike Tipton <quic_mdtipton@quicinc.com> Cc: Georgi Djakov <djakov@kernel.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Acked-by: Georgi Djakov <djakov@kernel.org> Reviewed-by: Alex Elder <elder@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220415005828.1980055-1-swboyd@chromium.org
2022-05-03arm64: dts: allwinner: teres-i: Add GPIO port regulatorsHarald Geyer1-0/+8
Allwinner A64 SoC has separate supplies for PC, PD, PE, PG and PL. Signed-off-by: Harald Geyer <harald@ccbib.org> Reviewed-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://lore.kernel.org/r/20220430191009.73946-1-harald@ccbib.org
2022-05-03ubd: don't set the discard_alignment queue limitChristoph Hellwig1-1/+0
The discard_alignment queue limit is named a bit misleading means the offset into the block device at which the discard granularity starts. Setting it to the discard granularity as done by ubd is mostly harmless but also useless. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Link: https://lore.kernel.org/r/20220418045314.360785-2-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-05-03ARM: dts: exynos: add atmel,24c128 fallback to Samsung EEPROMKrzysztof Kozlowski1-2/+2
The Samsung s524ad0xd1 EEPROM should use atmel,24c128 fallback, according to the AT24 EEPROM bindings. Reported-by: Rob Herring <robh@kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20220426183443.243113-1-krzysztof.kozlowski@linaro.org
2022-05-03ARM: versatile: Add missing of_node_put in dcscb_initPeng Wu1-0/+1
The device_node pointer is returned by of_find_compatible_node with refcount incremented. We should use of_node_put() to avoid the refcount leak. Signed-off-by: Peng Wu <wupeng58@huawei.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20220428230356.69418-1-linus.walleij@linaro.org' Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-05-03Merge tag 'omap-for-v5.19/soc-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/socArnd Bergmann5-30/+26
Soc clean-up for omaps Soc clean-up for omaps to add missing of_node_put() calls and drop unused omap_device_register(). * tag 'omap-for-v5.19/soc-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: ARM: OMAP2+: drop hwmod-clock helper comment ARM: OMAP2+: drop omap_device_register() helper ARM: OMAP2+: add missing of_node_put before break and return Link: https://lore.kernel.org/r/pull-1651061256-836848@atomide.com-3 Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-05-03Merge 5.18-rc5 into usb-nextGreg Kroah-Hartman228-1258/+1500
We need the USB fixes in here, and this resolves a merge issue in drivers/usb/dwc3/drd.c Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-03Merge tag 'aspeed-v5.18-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/joel/bmc into arm/fixesArnd Bergmann3-6/+18
ASPEED device tree fixes for v5.18 - Quad SPI device tree corrections - Reinstate GFX node that was removed - romed8hm3 machine fixes * tag 'aspeed-v5.18-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/joel/bmc: ARM: dts: aspeed: Add video engine to g6 ARM: dts: aspeed: romed8hm3: Fix GPIOB0 name ARM: dts: aspeed: romed8hm3: Add lm25066 sense resistor values ARM: dts: aspeed-g6: fix SPI1/SPI2 quad pin group ARM: dts: aspeed-g6: add FWQSPI group in pinctrl dtsi dt-bindings: pinctrl: aspeed-g6: add FWQSPI function/group pinctrl: pinctrl-aspeed-g6: add FWQSPI function-group dt-bindings: pinctrl: aspeed-g6: remove FWQSPID group pinctrl: pinctrl-aspeed-g6: remove FWQSPID group in pinctrl ARM: dts: aspeed-g6: remove FWQSPID group in pinctrl dtsi Link: https://lore.kernel.org/r/CACPK8XdhLfafOfqvR0r7p6V6AhtNXD4uZGaz7Y+Y4P-rc9p0tQ@mail.gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-05-03KVM: arm64: Factor out firmware register handling from psci.cRaghavendra Rao Ananta3-184/+185
Common hypercall firmware register handing is currently employed by psci.c. Since the upcoming patches add more of these registers, it's better to move the generic handling to hypercall.c for a cleaner presentation. While we are at it, collect all the firmware registers under fw_reg_ids[] to help implement kvm_arm_get_fw_num_regs() and kvm_arm_copy_fw_reg_indices() in a generic way. Also, define KVM_REG_FEATURE_LEVEL_MASK using a GENMASK instead. No functional change intended. Signed-off-by: Raghavendra Rao Ananta <rananta@google.com> Reviewed-by: Oliver Upton <oupton@google.com> Reviewed-by: Gavin Shan <gshan@redhat.com> [maz: fixed KVM_REG_FEATURE_LEVEL_MASK] Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220502233853.1233742-2-rananta@google.com
2022-05-03ARM: dts: stm32: add UserPA13 button on stm32mp135f-dkFabien Dessenne1-0/+11
The PA13 user button is connected to the PA13 pin of the stm32mp135f-dk board. It requires an internal pull-up configuration. Signed-off-by: Fabien Dessenne <fabien.dessenne@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2022-05-03ARM: dts: stm32: add blue led (Linux heartbeat) on stm32mp135f-dkFabien Dessenne1-0/+14
The blue led (Linux heartbeat) is connected to the PA14 pin of the stm32mp135f-dk board. Signed-off-by: Fabien Dessenne <fabien.dessenne@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2022-05-03ARM: dts: stm32: add EXTI interrupt-parent to pinctrl node on stm32mp131Fabien Dessenne1-0/+2
Add interrupt-parent property in pinctrl node to use GPIO as IRQ. Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com> Signed-off-by: Fabien Dessenne <fabien.dessenne@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2022-05-03efi: x86: Set the NX-compatibility flag in the PE headerPeter Jones1-0/+4
Following Baskov Evgeniy's "Handle UEFI NX-restricted page tables" patches, it's safe to set this compatibility flag to let loaders know they don't need to make special accommodations for kernel to load if pre-boot NX is enabled. Signed-off-by: Peter Jones <pjones@redhat.com> Link: https://lore.kernel.org/all/20220329184743.798513-1-pjones@redhat.com/ Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-05-03efi: libstub: declare DXE services tableBaskov Evgeniy1-0/+5
UEFI DXE services are not yet used in kernel code but are required to manipulate page table memory protection flags. Add required declarations to use DXE services functions. Signed-off-by: Baskov Evgeniy <baskov@ispras.ru> Link: https://lore.kernel.org/r/20220303142120.1975-2-baskov@ispras.ru [ardb: ignore absent DXE table but warn if the signature check fails] Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-05-03Merge tag 'amlogic-arm-dt-for-v5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux into arm/dtArnd Bergmann1-1/+1
Amlogic ARM DT changes for v5.19: - align SPI NOR node name with dtschema * tag 'amlogic-arm-dt-for-v5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux: ARM: dts: meson: align SPI NOR node name with dtschema Link: https://lore.kernel.org/r/fbd7cbe7-1fe9-7009-37d6-c01b15c93032@baylibre.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-05-03Merge tag 'amlogic-arm64-dt-for-v5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux into arm/dtArnd Bergmann10-29/+76
Amlogic ARM64 DT changes for v5.19: - DTS makefile alpsa sort - align SPI NOR node name with dtschema - add support for S4 power domain, gpio_intc, pinctrl - updates and fixes for JetHub D1/H1 boards * tag 'amlogic-arm64-dt-for-v5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux: arm64: dts: meson: alpa sort the board Makefile arm64: dts: meson: align SPI NOR node name with dtschema arm64: dts: add support for S4 power domain controller arm64: dts: meson-s4: add gpio_intc node arm64: dts: meson-s4: add pinctrl node arm64: meson: update WiFi SDIO in dts for JetHub D1 arm64: meson: update SDIO voltage in dts for JetHub D1 arm64: meson: dts: update serial alias in dts for JetHub D1 arm64: meson: add dts bluetooth node for JetHub H1 Link: https://lore.kernel.org/r/1e5179ab-2d92-0d64-c57b-e002ec2f0806@baylibre.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-05-03Merge tag 'ux500-dts-v5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik into arm/dtArnd Bergmann9-18/+951
Ux500 DTS updates for the v5.19 kernel cycle: - New devicetree for Codina TMO (SGH-T599). - Add the Amastaos proximity sensor to the Codina. - Add line impedance per machine to the Fuel Gauge nodes. - Add GPS to Janice, Skomer and Codina. - Add NFC to the Codina for GT-I8160P. - Some janitorial like clock names. * tag 'ux500-dts-v5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik: ARM: dts: ux500: Add GPS to the Codina ARM: dts: ux500: Add NFC to the Codina ARM: dts: ux500: Add GPS to Skomer device tree ARM: dts: ux500: Add GPS to Janice device tree ARM: dts: ux500: Add line impedance to fuel gauge ARM: dts: ux500: Register Amstaos proximity sensor ARM: dts: ux500: Add Codina TMO device tree dt-bindings: arm: ux500: Document Codina-TMO ARM: dts: ste-dbx: Update spi clock-names property Link: https://lore.kernel.org/r/CACRpkdYngWscqak5phKm58O2GF0RmVETgwW4NCKTBiASdaEcyg@mail.gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-05-03Merge tag 'omap-for-v5.19/dt-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/dtArnd Bergmann14-555/+1582
Devicetree changes for omaps Devicetree changes for omaps: - A series of changes to fix devicetree binding check warnings for omaps the the use of clock-output-names and clksel bindings - Update Ethernet node names for omaps - Pinctrl updates for logicpd-som-lv - A series of updates for am335x-guardian - Regulator range update for am335x-baltos Note that this branch is based on a upstream IOMMU fix as it's needed for booting on some SoCs. * tag 'omap-for-v5.19/dt-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: (29 commits) ARM: dts: am335x-baltos: update MPU regulator range ARM: dts: am335x: Guardian: Update comments ARM: dts: am335x: Guardian: Add gpio line manes ARM: dts: am335x: Guardian: Update interface pinmux ARM: dts: am335x: Guardian: Disable DMA property of USB1 ARM: dts: am335x: Guardian: Enable UART port two ARM: dts: am335x: Guardian: Update backlight parameter ARM: dts: am335x: Guardian: Add lcd port ARM: dts: am335x: Guardian: Update regulator node name ARM: dts: am335x: Guardian: Update beeper label ARM: dts: am335x: Guardian: Update life led ARM: dts: am335x: Guardian: Remove mmc status led ARM: dts: am335x: Guardian: Disable poweroff support from RTC ARM: dts: am335x: Guardian: Add keypad ARM: dts: am335x: Guardian: Rename power button label ARM: dts: am335x: Guardian: Update NAND partition table ARM: dts: logicpd-som-lv: Move pinmuxing to peripheral nodes ARM: dts: omap3/4/5: fix ethernet node name for different OMAP boards ARM: dts: Drop custom clkctrl compatible and update omap5 l4per ARM: dts: Add clock-output-names for omap5 ... Link: https://lore.kernel.org/r/pull-1650961799-428630@atomide.com-2 Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-05-03Merge tag 'renesas-arm-dt-for-v5.19-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into arm/dtArnd Bergmann46-141/+2273
Renesas ARM DT updates for v5.19 - ADC, SDHI, CAN-FD, I2C, QSPI, timer, watchdog, sound, USB, SPI, GPU, cpufreq, and thermal support for the RZ/V2L SoC, and the RZ/V2L SMARC EVK development board, - USB, I2C, Audio, NOR Flash, timer, SPI support for RZ/G2LC SMARC EVK development board, - Can-FD support for the R-Car M30W+ and V3U SoCs, and the Falcon development board, - I2C and GPIO support for the R-Car S4-8 SoC, - I2C EEPROM support for the Falcon development board, - SPI Multi I/O Bus Controller (RPC-IF) support for the R-Car H3, M3-W(+), M3-N, E3, and D3 SoCs, - RPC HyperFlash support for the Draak, Ebisu, Salvator-X(S), and ULCB development boards, - Initial support (UART, DMAC, pin control, SDHI, eMMC, Ethernet) for the RZ/G2UL SoC, and the RZ/G2UL SMARC EVK development board, - Miscellaneous fixes and improvements. * tag 'renesas-arm-dt-for-v5.19-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: (55 commits) ARM: dts: r9a06g032: Drop "arm,cortex-a7-timer" from timer node arm64: dts: renesas: r8a779f0: Add GPIO nodes arm64: dts: renesas: rzg2ul-smarc-som: Enable Ethernet on SMARC platform arm64: dts: renesas: rzg2ul-smarc-som: Enable eMMC on SMARC platform arm64: dts: renesas: rzg2ul-smarc: Enable microSD on SMARC platform arm64: dts: renesas: r9a07g043: Add GbEthernet nodes arm64: dts: renesas: r9a07g043: Add SDHI nodes arm64: dts: renesas: rzg2ul-smarc: Add scif0 and audio clk pins arm64: dts: renesas: r9a07g043: Fillup the pinctrl stub node arm64: dts: renesas: Add initial device tree for RZ/G2UL Type-1 SMARC EVK arm64: dts: renesas: Add initial DTSI for RZ/G2UL SoC arm64: dts: renesas: rzg2l-smarc: Move gpios property of vccq_sdhi1 from common dtsi arm64: dts: renesas: rzg2lc-smarc: Enable RSPI1 on carrier board arm64: dts: renesas: ulcb: Add RPC HyperFlash device node arm64: dts: renesas: salvator-common: Add RPC HyperFlash device node arm64: dts: renesas: ebisu: Add RPC HyperFlash device node arm64: dts: renesas: draak: Add RPC HyperFlash device node arm64: dts: renesas: rcar-gen3: Add RPC device nodes arm64: dts: renesas: rcar-gen4: Add interrupt properties to watchdog nodes arm64: dts: renesas: rzg2: Add interrupt properties to watchdog nodes ... Link: https://lore.kernel.org/r/cover.1650638505.git.geert+renesas@glider.be Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-05-03KVM: s390: vsie/gmap: reduce gmap_rmap overheadChristian Borntraeger1-0/+7
there are cases that trigger a 2nd shadow event for the same vmaddr/raddr combination. (prefix changes, reboots, some known races) This will increase memory usages and it will result in long latencies when cleaning up, e.g. on shutdown. To avoid cases with a list that has hundreds of identical raddrs we check existing entries at insert time. As this measurably reduces the list length this will be faster than traversing the list at shutdown time. In the long run several places will be optimized to create less entries and a shrinker might be necessary. Fixes: 4be130a08420 ("s390/mm: add shadow gmap support") Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com> Acked-by: David Hildenbrand <david@redhat.com> Link: https://lore.kernel.org/r/20220429151526.1560-1-borntraeger@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2022-05-03Merge tag 'omap-for-v5.19/defconfig-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/defconfigArnd Bergmann1-0/+3
Defconfig changes for omaps Changes to add tlv320aic3x and is176x drivers as loadable modules to omap2plus_defconfig. * tag 'omap-for-v5.19/defconfig-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: ARM: omap2plus_defconfig: Enable ISP176x USB driver ARM: omap2plus_defconfig: enable TLV320AIC3X Link: https://lore.kernel.org/r/pull-1651061256-836848@atomide.com-2 Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-05-03Merge tag 'renesas-arm-defconfig-for-v5.19-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into arm/defconfigArnd Bergmann2-2/+4
Renesas ARM defconfig updates for v5.19 - Enable support for the Renesas RZ/V2L SoC and the Maxim MAX96712 Quad GMSL2 Deserializer in the arm64 defconfig, - Refresh shmobile_defconfig for v5.18-rc1. * tag 'renesas-arm-defconfig-for-v5.19-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: ARM: shmobile: defconfig: Refresh for v5.18-rc1 arm64: defconfig: Enable Maxim MAX96712 Quad GMSL2 Deserializer support arm64: defconfig: Enable ARCH_R9A07G054 Link: https://lore.kernel.org/r/cover.1650638503.git.geert+renesas@glider.be Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-05-03arm64: defconfig: Enable modules for arm displayscarsten.haitzler@foss.arm.com1-0/+3
Key devices that support displays on SoCs like the Komeda DRM driver, the older HDLCD were not enabled by default and should be so displays can work out of the box on defconfig. Also Candence I2C support should be enabled so the PHY and thus displays can work too. Signed-off-by: Carsten Haitzler <carsten.haitzler@arm.com> Link: https://lore.kernel.org/r/20220427114200.111904-1-carsten.haitzler@foss.arm.com' Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-05-03arm: nomadik: drop selecting obsolete CLKSRC_NOMADIK_MTU_SCHED_CLOCKLukas Bulwahn1-1/+0
Commit 85b6fcadcf66 ("clocksource/drivers/ux500: Drop Ux500 custom SCHED_CLOCK") removes a sched_clock workaround and its corresponding config CLKSRC_NOMADIK_MTU_SCHED_CLOCK. Since then, selecting CLKSRC_NOMADIK_MTU_SCHED_CLOCK in ./arch/arm/mach-nomadik/Kconfig has no effect and ./scripts/checkkconfigsymbols.py warns: CLKSRC_NOMADIK_MTU_SCHED_CLOCK Referencing files: arch/arm/mach-nomadik/Kconfig Simply drop selecting the obsolete CLKSRC_NOMADIK_MTU_SCHED_CLOCK. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20220410145623.2620380-1-linus.walleij@linaro.org' Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-05-03ARM: config: Refresh IXP4xx config after multiplatformLinus Walleij1-53/+34
After converting to multiplatform the old IXP4xx defconfig doesn't even activate the ethernet driver anymore, we need to refresh this thoroughly. - Drop options that ARCH_MULTI_V5 selects for us. - Some options moved around because of multiplatform and because generic Kconfig movements. - Drop all MACH_* that do not exist anymore. - Compress the kernel and initramfs with XZ as the memory is often limited for these machines. - Make sure IXP4XX_QMGR and IXP4XX_NPE is selected. - Make sure the MTD_PHYSMAP_IXP4XX is selected and not the old MTD_IXP4XX (will be deleted). - Activate CRYPTO_DEV_IXP4XX - Add some very basic default drivers such as AT24 EEPROMs used in many routers. - Add some kernel configs needed to bring up OpenWrt which is the only userspace for these devices: CGROUPS, DEVTMPFS, INOTIFY_USER, SIGNALFD, TIMERFD, EPOLL, OVERLAY_FS and SQUASHFS. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Cc: Arnd Bergmann <arnd@kernel.org> Cc: Krzysztof Halasa <khalasa@piap.pl> Cc: Imre Kaloz <kaloz@openwrt.org> Link: https://lore.kernel.org/r/20220407204502.2470560-1-linus.walleij@linaro.org' Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-05-03Merge branch 'kvm-amd-pmu-fixes' into HEADPaolo Bonzini2-3/+30
2022-05-03Merge branch 'kvm-amd-pmu-fixes' into HEADPaolo Bonzini2-3/+30
2022-05-03kvm: x86/cpuid: Only provide CPUID leaf 0xA if host has architectural PMUSandipan Das1-0/+5
On some x86 processors, CPUID leaf 0xA provides information on Architectural Performance Monitoring features. It advertises a PMU version which Qemu uses to determine the availability of additional MSRs to manage the PMCs. Upon receiving a KVM_GET_SUPPORTED_CPUID ioctl request for the same, the kernel constructs return values based on the x86_pmu_capability irrespective of the vendor. This leaf and the additional MSRs are not supported on AMD and Hygon processors. If AMD PerfMonV2 is detected, the PMU version is set to 2 and guest startup breaks because of an attempt to access a non-existent MSR. Return zeros to avoid this. Fixes: a6c06ed1a60a ("KVM: Expose the architectural performance monitoring CPUID leaf") Reported-by: Vasant Hegde <vasant.hegde@amd.com> Signed-off-by: Sandipan Das <sandipan.das@amd.com> Message-Id: <3fef83d9c2b2f7516e8ff50d60851f29a4bcb716.1651058600.git.sandipan.das@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-03KVM: x86/svm: Account for family 17h event renumberings in amd_pmc_perf_hw_idKyle Huey1-3/+25
Zen renumbered some of the performance counters that correspond to the well known events in perf_hw_id. This code in KVM was never updated for that, so guest that attempt to use counters on Zen that correspond to the pre-Zen perf_hw_id values will silently receive the wrong values. This has been observed in the wild with rr[0] when running in Zen 3 guests. rr uses the retired conditional branch counter 00d1 which is incorrectly recognized by KVM as PERF_COUNT_HW_STALLED_CYCLES_BACKEND. [0] https://rr-project.org/ Signed-off-by: Kyle Huey <me@kylehuey.com> Message-Id: <20220503050136.86298-1-khuey@kylehuey.com> Cc: stable@vger.kernel.org [Check guest family, not host. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-03Merge branch 'kvm-tdp-mmu-atomicity-fix' into HEADPaolo Bonzini5-61/+121
We are dropping A/D bits (and W bits) in the TDP MMU. Even if mmu_lock is held for write, as volatile SPTEs can be written by other tasks/vCPUs outside of mmu_lock. Attempting to prove that bug exposed another notable goof, which has been lurking for a decade, give or take: KVM treats _all_ MMU-writable SPTEs as volatile, even though KVM never clears WRITABLE outside of MMU lock. As a result, the legacy MMU (and the TDP MMU if not fixed) uses XCHG to update writable SPTEs. The fix does not seem to have an easily-measurable affect on performance; page faults are so slow that wasting even a few hundred cycles is dwarfed by the base cost.
2022-05-03Merge branch 'kvm-tdp-mmu-atomicity-fix' into HEADPaolo Bonzini5-61/+121
We are dropping A/D bits (and W bits) in the TDP MMU. Even if mmu_lock is held for write, as volatile SPTEs can be written by other tasks/vCPUs outside of mmu_lock. Attempting to prove that bug exposed another notable goof, which has been lurking for a decade, give or take: KVM treats _all_ MMU-writable SPTEs as volatile, even though KVM never clears WRITABLE outside of MMU lock. As a result, the legacy MMU (and the TDP MMU if not fixed) uses XCHG to update writable SPTEs. The fix does not seem to have an easily-measurable affect on performance; page faults are so slow that wasting even a few hundred cycles is dwarfed by the base cost.
2022-05-03KVM: x86/mmu: Use atomic XCHG to write TDP MMU SPTEs with volatile bitsSean Christopherson2-31/+85
Use an atomic XCHG to write TDP MMU SPTEs that have volatile bits, even if mmu_lock is held for write, as volatile SPTEs can be written by other tasks/vCPUs outside of mmu_lock. If a vCPU uses the to-be-modified SPTE to write a page, the CPU can cache the translation as WRITABLE in the TLB despite it being seen by KVM as !WRITABLE, and/or KVM can clobber the Accessed/Dirty bits and not properly tag the backing page. Exempt non-leaf SPTEs from atomic updates as KVM itself doesn't modify non-leaf SPTEs without holding mmu_lock, they do not have Dirty bits, and KVM doesn't consume the Accessed bit of non-leaf SPTEs. Dropping the Dirty and/or Writable bits is most problematic for dirty logging, as doing so can result in a missed TLB flush and eventually a missed dirty page. In the unlikely event that the only dirty page(s) is a clobbered SPTE, clear_dirty_gfn_range() will see the SPTE as not dirty (based on the Dirty or Writable bit depending on the method) and so not update the SPTE and ultimately not flush. If the SPTE is cached in the TLB as writable before it is clobbered, the guest can continue writing the associated page without ever taking a write-protect fault. For most (all?) file back memory, dropping the Dirty bit is a non-issue. The primary MMU write-protects its PTEs on writeback, i.e. KVM's dirty bit is effectively ignored because the primary MMU will mark that page dirty when the write-protection is lifted, e.g. when KVM faults the page back in for write. The Accessed bit is a complete non-issue. Aside from being unused for non-leaf SPTEs, KVM doesn't do a TLB flush when aging SPTEs, i.e. the Accessed bit may be dropped anyways. Lastly, the Writable bit is also problematic as an extension of the Dirty bit, as KVM (correctly) treats the Dirty bit as volatile iff the SPTE is !DIRTY && WRITABLE. If KVM fixes an MMU-writable, but !WRITABLE, SPTE out of mmu_lock, then it can allow the CPU to set the Dirty bit despite the SPTE being !WRITABLE when it is checked by KVM. But that all depends on the Dirty bit being problematic in the first place. Fixes: 2f2fad0897cb ("kvm: x86/mmu: Add functions to handle changed TDP SPTEs") Cc: stable@vger.kernel.org Cc: Ben Gardon <bgardon@google.com> Cc: David Matlack <dmatlack@google.com> Cc: Venkatesh Srinivas <venkateshs@google.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220423034752.1161007-4-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-03KVM: x86/mmu: Move shadow-present check out of spte_has_volatile_bits()Sean Christopherson3-27/+32
Move the is_shadow_present_pte() check out of spte_has_volatile_bits() and into its callers. Well, caller, since only one of its two callers doesn't already do the shadow-present check. Opportunistically move the helper to spte.c/h so that it can be used by the TDP MMU, which is also the primary motivation for the shadow-present change. Unlike the legacy MMU, the TDP MMU uses a single path for clear leaf and non-leaf SPTEs, and to avoid unnecessary atomic updates, the TDP MMU will need to check is_last_spte() prior to calling spte_has_volatile_bits(), and calling is_last_spte() without first calling is_shadow_present_spte() is at best odd, and at worst a violation of KVM's loosely defines SPTE rules. Note, mmu_spte_clear_track_bits() could likely skip the write entirely for SPTEs that are not shadow-present. Leave that cleanup for a future patch to avoid introducing a functional change, and because the shadow-present check can likely be moved further up the stack, e.g. drop_large_spte() appears to be the only path that doesn't already explicitly check for a shadow-present SPTE. No functional change intended. Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220423034752.1161007-3-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-03KVM: x86/mmu: Don't treat fully writable SPTEs as volatile (modulo A/D)Sean Christopherson2-9/+10
Don't treat SPTEs that are truly writable, i.e. writable in hardware, as being volatile (unless they're volatile for other reasons, e.g. A/D bits). KVM _sets_ the WRITABLE bit out of mmu_lock, but never _clears_ the bit out of mmu_lock, so if the WRITABLE bit is set, it cannot magically get cleared just because the SPTE is MMU-writable. Rename the wrapper of MMU-writable to be more literal, the previous name of spte_can_locklessly_be_made_writable() is wrong and misleading. Fixes: c7ba5b48cc8d ("KVM: MMU: fast path of handling guest page fault") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220423034752.1161007-2-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-03x86/entry: Convert SWAPGS to swapgs and remove the definition of SWAPGSLai Jiangshan3-12/+4
XENPV doesn't use swapgs_restore_regs_and_return_to_usermode(), error_entry() and the code between entry_SYSENTER_compat() and entry_SYSENTER_compat_after_hwframe. Change the PV-compatible SWAPGS to the ASM instruction swapgs in these places. Also remove the definition of SWAPGS since no more users. Signed-off-by: Lai Jiangshan <jiangshan.ljs@antgroup.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20220503032107.680190-7-jiangshanlai@gmail.com
2022-05-03x86/entry: Don't call error_entry() for XENPVLai Jiangshan1-2/+11
XENPV guests enter already on the task stack and they can't fault for native_iret() nor native_load_gs_index() since they use their own pvop for IRET and load_gs_index(). A CR3 switch is not needed either. So there is no reason to call error_entry() in XENPV. [ bp: Massage commit message. ] Signed-off-by: Lai Jiangshan <jiangshan.ljs@antgroup.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20220503032107.680190-6-jiangshanlai@gmail.com
2022-05-03KVM: arm64: Hide AArch32 PMU registers when not availableAlexandru Elisei2-30/+32
commit 11663111cd49 ("KVM: arm64: Hide PMU registers from userspace when not available") hid the AArch64 PMU registers from userspace and guest when the PMU VCPU feature was not set. Do the same when the PMU registers are accessed by an AArch32 guest. While we're at it, rename the previously unused AA32_ZEROHIGH to AA32_DIRECT to match the behavior of get_access_mask(). Now that KVM emulates ID_DFR0 and hides the PMU from the guest when the feature is not set, it is safe to inject to inject an undefined exception when the PMU is not present, as that corresponds to the architected behaviour. Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com> [Oliver - Add AA32_DIRECT to match the zero value of the enum] Signed-off-by: Oliver Upton <oupton@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220503060205.2823727-7-oupton@google.com
2022-05-03x86/entry: Move CLD to the start of the idtentry macroLai Jiangshan1-3/+5
Move it after CLAC. Suggested-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Lai Jiangshan <jiangshan.ljs@antgroup.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lore.kernel.org/r/20220503032107.680190-5-jiangshanlai@gmail.com
2022-05-03KVM: arm64: Start trapping ID registers for 32 bit guestsOliver Upton2-8/+2
To date KVM has not trapped ID register accesses from AArch32, meaning that guests get an unconstrained view of what hardware supports. This can be a serious problem because we try to base the guest's feature registers on values that are safe system-wide. Furthermore, KVM does not implement the latest ISA in the PMU and Debug architecture, so we constrain these fields to supported values. Since KVM now correctly handles CP15 and CP10 register traps, we no longer need to clear HCR_EL2.TID3 for 32 bit guests and will instead emulate reads with their safe values. Signed-off-by: Oliver Upton <oupton@google.com> Reviewed-by: Reiji Watanabe <reijiw@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220503060205.2823727-6-oupton@google.com
2022-05-03KVM: arm64: Plumb cp10 ID traps through the AArch64 sysreg handlerOliver Upton3-0/+73
In order to enable HCR_EL2.TID3 for AArch32 guests KVM needs to handle traps where ESR_EL2.EC=0x8, which corresponds to an attempted VMRS access from an ID group register. Specifically, the MVFR{0-2} registers are accessed this way from AArch32. Conveniently, these registers are architecturally mapped to MVFR{0-2}_EL1 in AArch64. Furthermore, KVM already handles reads to these aliases in AArch64. Plumb VMRS read traps through to the general AArch64 system register handler. Signed-off-by: Oliver Upton <oupton@google.com> Reviewed-by: Reiji Watanabe <reijiw@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220503060205.2823727-5-oupton@google.com