The semantics of pfn_valid() is to check presence of the memory map for a
PFN and not whether a PFN is covered by the linear map. The memory map
may be present for NOMAP memory regions, but they won't be mapped in the
linear mapping. Accessing such regions via __va() when they are
memremap()'ed will cause a crash.
On v5.4.y the crash happens on qemu-arm with UEFI [1]:
<1>[ 0.084476] 8<--- cut here ---
<1>[ 0.084595] Unable to handle kernel paging request at virtual address dfb76000
<1>[ 0.084938] pgd = (ptrval)
<1>[ 0.085038] [dfb76000] *pgd=5f7fe801, *pte=00000000, *ppte=00000000
...
<4>[ 0.093923] [<c0ed6ce8>] (memcpy) from [<c16a06f8>] (dmi_setup+0x60/0x418)
<4>[ 0.094204] [<c16a06f8>] (dmi_setup) from [<c16a38d4>] (arm_dmi_init+0x8/0x10)
<4>[ 0.094408] [<c16a38d4>] (arm_dmi_init) from [<c0302e9c>] (do_one_initcall+0x50/0x228)
<4>[ 0.094619] [<c0302e9c>] (do_one_initcall) from [<c16011e4>] (kernel_init_freeable+0x15c/0x1f8)
<4>[ 0.094841] [<c16011e4>] (kernel_init_freeable) from [<c0f028cc>] (kernel_init+0x8/0x10c)
<4>[ 0.095057] [<c0f028cc>] (kernel_init) from [<c03010e8>] (ret_from_fork+0x14/0x2c)
On kernels v5.10.y and newer the same crash won't reproduce on ARM because
commit b10d6bca87 ("arch, drivers: replace for_each_membock() with
for_each_mem_range()") changed the way memory regions are registered in
the resource tree, but that merely covers up the problem.
On ARM64 memory resources registered in yet another way and there the
issue of wrong usage of pfn_valid() to ensure availability of the linear
map is also covered.
Implement arch_memremap_can_ram_remap() on ARM and ARM64 to prevent access
to NOMAP regions via the linear mapping in memremap().
Link: https://lore.kernel.org/all/Yl65zxGgFzF1Okac@sirena.org.uk
Link: https://lkml.kernel.org/r/20220426060107.7618-1-rppt@kernel.org
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
Reported-by: "kernelci.org bot" <bot@kernelci.org>
Tested-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Mark-PK Tsai <mark-pk.tsai@mediatek.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Will Deacon <will@kernel.org>
Cc: <stable@vger.kernel.org> [5.4+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
i.MX arm64 device tree update for 5.19:
- New board support: Engicam i.Core MX8M Plus SoM and EDIMM2.2 Starter
Kit, Toradex Verdin i.MX8M Plus devices, Data Modul i.MX8M Mini eDM SBC,
Verdin based MX8Menlo, 8MNANOD3L EVK, i.MX8M Plus Gateworks GW7400.
- Enable RTS-CTS on UART3 for imx8mm-beacon and imx8mn-beacon boards.
- Enable HS400-ES support for i.MX8MN and i.MX8MP uSDHC devices by
updating the compatible.
- A few updates on imx8mq-librem5 to increase boost regulation
current, add panel compatible for r4 ("Evergreen") revision and volume
buttons a wakeup source.
- Clean up vendor specific 'fsl,uart-has-rtscts' property by using
standard 'uart-has-rtscts'.
- Add GPC, GPU, MEDIAMIX, and HSIO power domains for i.MX8M Plus SoC.
- A series from Marcel Ziswiler to improve imx8mm-verdin support,
including cosmetic changes and functional improvements like SD1 sleep
pinctrl and fully validated IOMUX configuration.
- Add PWM polarity inversion support for i.MX8 SoCs.
- A couple of changes from Michael Walle to update PMIC output names and
min/max voltages for imx8mn-evk board.
- A series from Tim Harvey to improve imx8mm-venice boards, add missing
uart-has-rtscts property to UARTs, clock-names to pcie_phy, and
vdd_5p0 ADC channel.
- Add VPU codec devices for i.MX8QXP SoC.
- Other small and random changes.
* tag 'imx-dt64-5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: (65 commits)
arm64: dt: imx8mp: support pwm polarity inversion
arm64: dt: imx8mn: support pwm polarity inversion
arm64: dt: imx8mm: support pwm polarity inversion
arm64: dt: imx8mq: support pwm polarity inversion
arm64: dts: imx8mm-venice-gw7901: remove unnecessary cpu temp override
arm64: dts: imx8mm-venice-gw7902: add vdd_5p0 ADC channel
arm64: dts: imx8m*venice: add missing clock-names to pcie_phy
arm64: dts: imx8mm-venice-gw7902: fix pcie bindings
arm64: dts: freescale: reduce the interrup-map-mask
arm64: dts: imx8mn-beacon: Enable RTS-CTS on UART3
arm64: dts: imx8mm-beacon: Enable RTS-CTS on UART3
arm64: dts: imx8mm: Use 100 kHz I2C2 on Data Modul i.MX8M Mini eDM SBC
arm64: dts: imx8mm: Disable USB2 OC on Data Modul i.MX8M Mini eDM SBC
arm64: dts: imx8mm: Add CPLD on MX8Menlo board
arm64: dts: imx8mq-kontron-pitx-imx8m: Use the standard 'uart-has-rtscts'
arm64: dts: imx8mp-verdin: Use the standard 'uart-has-rtscts'
arm64: dts: imx8mp: Add MEDIA_BLK_CTRL
arm64: dts: imx8mp: Add MEDIAMIX power domains
arm64: dts: imx8mp: add HSIO power-domains
arm64: dts: imx8mp: Add Engicam i.Core MX8M Plus EDIMM2.2 Starter Kit
...
Link: https://lore.kernel.org/r/20220508033843.2773685-4-shawnguo@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Qualcomm ARM64 DT updates for v5.19
This adds MDIO bus description on the IPQ6018 platform.
On MSM8916 the BAM-DMUX WWAN network device is added and the Huawei
Ascend G7 gains sound card definition and clarified installation
instructions.
MSM8992 and MSM8994 continues to be worked on, gaining multimedia clock
controller, on-chip memory, watchdog and various cleanup changes. The
Xiaomi Mi 4C gains CPU regulators and fixes to the framebuffer
definition, while Huawei Nexus 6P gains eMMC support.
On MSM8996 the modem and sensor remtoeprocs are added and enabled in the
Dragonboard 820c and the Xiaomi devices.
On MSM8998 a few newly added clocks related to the sensor subsystem bus
are marked as protected by default and the OnePlus devices gains NFC.
The SC7180 platform and devices thereon are further polished and
limozeen moves to using edp-panel for EDID-based detection, over
statically defined panels.
On SC7280 GPI DMA, WiFi remoteproc and network device, LPASS audio
clocks, resets for SDCC controllers and a new CRD revision are added. A
supply glitch on the PCIe power and a current leak for Bluetooth during
suspend are corrected. The Herobrine board gains eDP support and the IDP
gains backlight. USB is marked wakeup capable.
On SDM845 the IPA, WLED based backlight and second WiFi channel are
enabled for Xiaomi Pocophone F1, the firmware name is modified to not
conflict with other boards. On RB3 the CAN bus controller is added and
the WiFi calibration variant is defined to allow adding the board's
calibration information into linux-firmware.
SM6350 gains I2C busses, UFS and WiFi support, and the numbering of
uart9 is corrected.
On SM7225 and the Fairphone 4 UFS, WiFi and haptics are enabled.
On SM8150 PCIe, Ethernet and uSD card support is added, and enabled for
the SA8155p ADP board. The PDC interrupt controller is also added and
described as wakup interrupt parent for TLMM.
Camera subsystem and control interface are defined for SM8250. On the
Sony Xperia 1 II the audio amplifiers are enabled.
On SM8350 GPI DMA engines are added and linked to the I2C and SPI
serial engines. Surface Duo 2 gains battery charger support.
On SM8450 the two PCIe controller/PHYs are enabled, GPI DMA and QUP
serial engine instances are added. Remoteproc instances are enabled on
SM8450 HDK.
Last, but not least, a number of DeviceTree validation errors across
various boards are corrected.
* tag 'qcom-arm64-for-5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: (150 commits)
arm64: dts: qcom: Only include sc7180.dtsi in sc7180-trogdor.dtsi
arm64: dts: qcom: sc7180-trogdor: Simplify spi0/spi6 labeling
arm64: dts: qcom: sc7180-trogdor: Simplify trackpad enabling
arm64: dts: qcom: sc7280: eDP for herobrine boards
arm64: dts: qcom: sa8155p-adp: Disable multiple Tx and Rx queues for ethernet IP
arm64: dts: qcom: sm8150: Fix iommu sid value for SDC2 controller
arm64: dts: qcom: sm8350-duo2: enable battery charger
arm64: dts: qcom: Enable pm8350c pwm for sc7280-idp2
arm64: dts: qcom: pm8350c: Add pwm support
arm64: dts: qcom: sc7280-qcard: Configure CTS pin to bias-bus-hold for bluetooth
arm64: dts: qcom: sc7280-idp: Configure CTS pin to bias-bus-hold for bluetooth
arm64: dts: qcom: sc7180: Remove ipa interconnect node
arm64: dts: qcom: sc7280-idp: Enable GPI DMAs
arm64: dts: qcom: sc7280: Add GENI I2C/SPI DMA channels
arm64: dts: qcom: sc7280: Add GPI DMAengines
arm64: dts: qcom: sm8450: Fix qmp phy node (use phy@ instead of lanes@)
arm64: dts: qcom: db845c: Add support for MCP2517FD
arm64: dts: qcom: qrb5165-rb5: Fix can-clock node name
arm64: dts: qcom: sc7280: Add SAR sensors to herobrine crd
arm64: dts: qcom: sm8250: camss: Add CCI definitions
...
Link: https://lore.kernel.org/r/20220509204451.325675-1-bjorn.andersson@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Qualcomm ARM64 DT fixes for v5.18
This disables the two Soundwire controllers as well as rx and tx macros
by default on the SM8250 platform to avoid crashes on devices where
these aren't available.
* tag 'qcom-arm64-fixes-for-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
arm64: dts: qcom: sm8250: don't enable rx/tx macro by default
Link: https://lore.kernel.org/r/20220509152310.306179-1-bjorn.andersson@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Qualcomm ARM64 defconfig updates for v5.19
This enables the GPI DMA driver, providing access to I2C and SPI
controllers that are setup for shared ownership. The PCIe Gen2 PHY
provides PCI support on the QCS405 platform, among others. The PMIC
watchdog, concell and ADC5 ThermalMonitor drivers provides housekeeping
services on a range of different platforms.
The Display and Video clock controllers for SM8250 are enabled, as is
the audio RX/TX macros and the WCD9335 audio codec driver.
Lastly the Ath11k driver, used on a variety of modern boards and the
FastRPC driver, which provides an interface for computational offloading
on the Hexagon cores, are enabled.
All drivers, except the SM8250 Display and Video clock controller
drivers are enabled as modules. The two clock controllers provides
power-domains and must be builtin to reduce the risk of probe deferral
happening (and being ignored) after late initcall.
* tag 'qcom-arm64-defconfig-for-5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
arm64: defconfig: Enable Qualcomm GPI DMA Driver
arm64: defconfig: Enable Qualcomm PCIe Gen2 PHY
arm64: defconfig: Enable SM8250 video clock controller
arm64: defconfig: Enable PM8916 watchdog driver
arm64: defconfig: enable ath11k driver
arm64: defconfig: Enable some Qualcomm drivers
arm64: defconfig: reenable SM_DISPCC_8250
arm64: defconfig: enable wcd9335 codec as module
arm64: defconfig: enable Qualcomm RX and TX macro for SM8250 audio
Link: https://lore.kernel.org/r/20220509170158.311962-1-bjorn.andersson@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
i.MX defconfig update for 5.19:
- Enable the WM8524 codec driver as module in arm64 defconfig for audio
support on imx8mn-evk board.
- Enable the ADC part of the STMPE MFD in imx_v6_v7_defconfig, as the
SoM Apalis/Colibri iMX6 use the ADC of a STMPE 811.
* tag 'imx-defconfig-5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
arm64: defconfig: Enable the WM8524 codec driver
ARM: imx_v6_v7_defconfig: Enable the ADC part of the STMPE MFD
Link: https://lore.kernel.org/r/20220508033843.2773685-5-shawnguo@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
TI K3 defconfig updates for v5.19
* Enable TIDSS and Display Port related configs
* Enable Cadence Torrent PHY for Display Port
* tag 'ti-k3-config-for-v5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/ti/linux:
arm64: defconfig: Enable configs for DisplayPort on J721e
Link: https://lore.kernel.org/r/88cd734e-47a7-4307-c119-8f6ec6c40452@ti.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Espressobin Ultra has a front panel USB3.0 Type-A port which works
just fine so enable it.
I dont see a reason why it was disabled in the first place anyway.
Fixes: 3404fe15a6 ("arm64: dts: marvell: add DT for ESPRESSObin-Ultra")
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Both the Topaz switch and 88E1512 PHY have their reset and interrupts
connected to the SoC.
So, define the Topaz and 88E1512 reset pins in the DTS.
Defining the interrupt pins wont work as both the 88E1512 and the
Topaz switch uses active LOW IRQ signals but the A37xx GPIO controller
only supports edge triggers.
88E1512 would require special setup anyway as its INT pin is shared with
the LED2 and you first need to configure it as INT.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
SPI config for the SPI-NOR is incorrect and completely breaking
reading/writing to the onboard SPI-NOR.
SPI-NOR is connected in the single(x1) IO mode and not in the quad
(x4) mode.
Also, there is no need to override the max frequency from the DTSI
as the mx25u3235f that is used supports 104Mhz.
Fixes: 3404fe15a6 ("arm64: dts: marvell: add DT for ESPRESSObin-Ultra")
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
uDPU has a pair of NCT375 temperature sensors, which are TMP75C compatible
as far as the driver is concerned.
The current LM75 compatible worked as all of the LM75 compatible sensors
are backwards compatible with the original part, but it meant that lower
resolution and incorrect sample rate was being used.
The "lm75" compatible has been deprecated anyway and is meant as fallback
in order to keep older DTS-es working.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Reviewed-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Partition currently called "uboot" does not only contain U-boot, but
rather it contains TF-A, U-boot and U-boot environment.
So, to avoid accidentally deleting the U-boot environment which is
located at 0x180000 split the partition.
"uboot" is not the correct name as you can't boot these boards with U-boot
only, TF-A must be present as well, so rename the "uboot" partition to
"firmware".
While we are here, describe the NOR node as "spi-flash@0" instead of
"m25p80@0" which is the old SPI-NOR driver name.
This won't break booting for existing devices as the SoC-s BootROM is not
partition aware at all, it will simply try booting from 0x0 of the
boot device that is set by bootstrap pins.
This will however prevent accidental or automated flashing of just U-boot
to the partition.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Reviewed-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Due to some historical confusion, arm64's current_top_of_stack() isn't
what the stackleak code expects. This could in theory result in a number
of problems, and practically results in an unnecessary performance hit.
We can avoid this by aligning the arm64 implementation with the x86
implementation.
The arm64 implementation of current_top_of_stack() was added
specifically for stackleak in commit:
0b3e336601 ("arm64: Add support for STACKLEAK gcc plugin")
This was intended to be equivalent to the x86 implementation, but the
implementation, semantics, and performance characteristics differ
wildly:
* On x86, current_top_of_stack() returns the top of the current task's
task stack, regardless of which stack is in active use.
The implementation accesses a percpu variable which the x86 entry code
maintains, and returns the location immediately above the pt_regs on
the task stack (above which x86 has some padding).
* On arm64 current_top_of_stack() returns the top of the stack in active
use (i.e. the one which is currently being used).
The implementation checks the SP against a number of
potentially-accessible stacks, and will BUG() if no stack is found.
The core stackleak_erase() code determines the upper bound of stack to
erase with:
| if (on_thread_stack())
| boundary = current_stack_pointer;
| else
| boundary = current_top_of_stack();
On arm64 stackleak_erase() is always called on a task stack, and
on_thread_stack() should always be true. On x86, stackleak_erase() is
mostly called on a trampoline stack, and is sometimes called on a task
stack.
Currently, this results in a lot of unnecessary code being generated for
arm64 for the impossible !on_thread_stack() case. Some of this is
inlined, bloating stackleak_erase(), while portions of this are left
out-of-line and permitted to be instrumented (which would be a
functional problem if that code were reachable).
As a first step towards improving this, this patch aligns arm64's
implementation of current_top_of_stack() with x86's, always returning
the top of the current task's stack. With GCC 11.1.0 this results in the
bulk of the unnecessary code being removed, including all of the
out-of-line instrumentable code.
While I don't believe there's a functional problem in practice I've
marked this as a fix since the semantic was clearly wrong, the fix
itself is simple, and other code might rely upon this in future.
Fixes: 0b3e336601 ("arm64: Add support for STACKLEAK gcc plugin")
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Alexander Popov <alex.popov@linux.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Will Deacon <will@kernel.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20220427173128.2603085-2-mark.rutland@arm.com
There are following issues in arm64 kdump:
1. We use crashkernel=X to reserve crashkernel in DMA zone, which
will fail when there is not enough low memory.
2. If reserving crashkernel above DMA zone, in this case, crash dump
kernel will fail to boot because there is no low memory available
for allocation.
To solve these issues, introduce crashkernel=X,[high,low].
The "crashkernel=X,high" is used to select a region above DMA zone, and
the "crashkernel=Y,low" is used to allocate specified size low memory.
Signed-off-by: Chen Zhou <chenzhou10@huawei.com>
Co-developed-by: Zhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Link: https://lore.kernel.org/r/20220506114402.365-4-thunder.leizhen@huawei.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Add fn and fn_arg members into struct kernel_clone_args and test for
them in copy_thread (instead of testing for PF_KTHREAD | PF_IO_WORKER).
This allows any task that wants to be a user space task that only runs
in kernel mode to use this functionality.
The code on x86 is an exception and still retains a PF_KTHREAD test
because x86 unlikely everything else handles kthreads slightly
differently than user space tasks that start with a function.
The functions that created tasks that start with a function
have been updated to set ".fn" and ".fn_arg" instead of
".stack" and ".stack_size". These functions are fork_idle(),
create_io_thread(), kernel_thread(), and user_mode_thread().
Link: https://lkml.kernel.org/r/20220506141512.516114-4-ebiederm@xmission.com
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
With io_uring we have started supporting tasks that are for most
purposes user space tasks that exclusively run code in kernel mode.
The kernel task that exec's init and tasks that exec user mode
helpers are also user mode tasks that just run kernel code
until they call kernel execve.
Pass kernel_clone_args into copy_thread so these oddball
tasks can be supported more cleanly and easily.
v2: Fix spelling of kenrel_clone_args on h8300
Link: https://lkml.kernel.org/r/20220506141512.516114-2-ebiederm@xmission.com
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
arm64: tegra: Default configuration updates for v5.19-rc1
This enables the driver for the new ASRC audio block that is found on
Tegra186 and later.
* tag 'tegra-for-5.19-arm64-defconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
arm64: defconfig: Build Tegra ASRC module
Link: https://lore.kernel.org/r/20220506143005.3916655-6-thierry.reding@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Renesas ARM defconfig updates for v5.19 (take two)
- Enable support for the Renesas RZ/G2UL and RZ/V2M SoCs in the arm64
defconfig,
* tag 'renesas-arm-defconfig-for-v5.19-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel:
arm64: defconfig: Enable Renesas RZ/V2M SoC
arm64: defconfig: Enable ARCH_R9A07G043
Link: https://lore.kernel.org/r/cover.1651828601.git.geert+renesas@glider.be
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
arm64: tegra: Device tree changes for v5.19-rc1
This adds some improvements on Tegra234 (QSPI, CCPLEX), improves the
SDMMC clock speed on Tegra194 and adds the ASRC audio block on various
chip generations. Memory controller channels are also added on Tegra186
and later and the missing DFLL reset is added for Tegra210.
* tag 'tegra-for-5.19-arm64-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
arm64: tegra: Add missing DFLL reset on Tegra210
arm64: tegra: Add memory controller channels
arm64: tegra: Enable ASRC on various platforms
arm64: tegra: Add ASRC device on Tegra186 and later
arm64: tegra: Update PWM fan node name
arm64: tegra: Add node for Tegra234 CCPLEX cluster
arm64: tegra: Add QSPI controllers on Tegra234
arm64: tegra: Update SDMMC1/3 clock source for Tegra194
Link: https://lore.kernel.org/r/20220506143005.3916655-5-thierry.reding@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Renesas ARM DT updates for v5.19 (take two)
- I2C, sound, USB, CANFD, timer, watchdog, (Q)SPI, cpufreq, and
thermal support for the RZ/G2UL SoC and the RZ/G2UL SMARC EVK
development board,
- Initial support for the R-Car V4H SoC and the Renesas White Hawk
development board stack,
- DMA, RTC, and USB support for the RZ/N1D SoC,
- Initial support for the RZ/V2M SoC an the RZ/V2M Evaluation Kit
Board,
- Miscellaneous fixes and improvements.
* tag 'renesas-arm-dt-for-v5.19-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: (40 commits)
arm64: dts: renesas: Add initial device tree for RZ/V2M EVK
arm64: dts: renesas: Add initial DTSI for RZ/V2M SoC
arm64: dts: renesas: r8a779a0: Update to R-Car Gen4 compatible values
ARM: dts: r9a06g032: Link the PCI USB devices to the USB PHY
ARM: dts: r9a06g032: Add USB PHY DT support
ARM: dts: r9a06g032: Add internal PCI bridge node
ARM: dts: r9a06g032: Describe the RTC
arm64: dts: renesas: Add interrupt-names to CANFD nodes
arm64: dts: renesas: r9a07g043: Add SPI Multi I/O Bus controller node
arm64: dts: renesas: r9a07g043: Create thermal zone to support IPA
arm64: dts: renesas: r9a07g043: Add TSU node
arm64: dts: renesas: r9a07g043: Add OPP table
arm64: dts: renesas: r9a07g043: Add RSPI{0,1,2} nodes
arm64: dts: renesas: r9a07g054: Fix external clk node names
arm64: dts: renesas: r9a07g044: Fix external clk node names
ARM: dts: r9a06g032: Fix the NAND controller node
ARM: dts: r9a06g032: Fill the UART DMA properties
ARM: dts: r9a06g032: Describe the DMA router
ARM: dts: r9a06g032: Add the two DMA nodes
arm64: dts: renesas: Remove empty rgb output endpoints
...
Link: https://lore.kernel.org/r/cover.1651828603.git.geert+renesas@glider.be
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Minor cleanup of ARM64 DTS for v5.19
Align SPI NOR node names and freq-table-hz to DT schema. Drop
unused/undocumented dma-channels/dma-requests.
* tag 'dt64-cleanup-5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux:
arm64: dts: broadcom: drop useless 'dma-channels/requests' properties
arm64: dts: stratix10/agilex: drop useless 'dma-channels/requests' properties
arm64: dts: marvell: align SPI NOR node name with dtschema
arm64: dts: microchip: align SPI NOR node name with dtschema
arm64: dts: hisilicon: align 'freq-table-hz' with dtschema in UFS
Link: https://lore.kernel.org/r/20220506081438.149192-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
In ACPI, describing power efficiency of CPUs can be done through the
following arm specific field:
ACPI 6.4, s5.2.12.14 'GIC CPU Interface (GICC) Structure',
'Processor Power Efficiency Class field':
Describes the relative power efficiency of the associated pro-
cessor. Lower efficiency class numbers are more efficient than
higher ones (e.g. efficiency class 0 should be treated as more
efficient than efficiency class 1). However, absolute values
of this number have no meaning: 2 isn’t necessarily half as
efficient as 1.
The efficiency_class field is stored in the GicC structure of the
ACPI MADT table and it's currently supported in Linux for arm64 only.
Thus, this new functionality is introduced for arm64 only.
To allow the cppc_cpufreq driver to know and preprocess the
efficiency_class values of all the CPUs, add a per_cpu efficiency_class
variable to store them.
At least 2 different efficiency classes must be present,
otherwise there is no use in creating an Energy Model.
The efficiency_class values are squeezed in [0:#efficiency_class-1]
while conserving the order. For instance, efficiency classes of:
[111, 212, 250]
will be mapped to:
[0 (was 111), 1 (was 212), 2 (was 250)].
Each policy being independently registered in the driver, populating
the per_cpu efficiency_class is done only once at the driver
initialization. This prevents from having each policy re-searching the
efficiency_class values of other CPUs. The EM will be registered in a
following patch.
The patch also exports acpi_cpu_get_madt_gicc() to fetch the GicC
structure of the ACPI MADT table for each CPU.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Since the vector length configuration mechanism is identical between SVE
and SME we share large elements of the code including the definition for
the maximum vector length. Unfortunately when we were defining the ABI
for SVE we included not only the actual maximum vector length of 2048
bits but also the value possible if all the bits reserved in the
architecture for expansion of the LEN field were used, 16384 bits.
This starts creating problems if we try to allocate anything for the ZA
matrix based on the maximum possible vector length, as we do for the
regset used with ptrace during the process of generating a core dump.
While the maximum potential size for ZA with the current architecture is
a reasonably managable 64K with the higher reserved limit ZA would be
64M which leads to entirely reasonable complaints from the memory
management code when we try to allocate a buffer of that size. Avoid
these issues by defining the actual maximum vector length for the
architecture and using it for the SME regsets.
Also use the full ZA_PT_SIZE() with the header rather than just the
actual register payload when specifying the size, fixing support for the
largest vector lengths now that we have this new, lower define. With the
SVE maximum this did not cause problems due to the extra headroom we
had.
While we're at it add a comment clarifying why even though ZA is a
single register we tell the regset code that it is a multi-register
regset.
Reported-by: Qian Cai <quic_qiancai@quicinc.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Link: https://lore.kernel.org/r/20220505221517.1642014-1-broonie@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Don't use begin-kernel-doc notation (/**) for comments that are not in
kernel-doc format.
This prevents these kernel-doc warnings:
arch/arm64/kvm/hyp/nvhe/switch.c:126: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
* Disable host events, enable guest events
arch/arm64/kvm/hyp/nvhe/switch.c:146: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
* Disable guest events, enable host events
arch/arm64/kvm/hyp/nvhe/switch.c:164: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
* Handler for protected VM restricted exceptions.
arch/arm64/kvm/hyp/nvhe/switch.c:176: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
* Handler for protected VM MSR, MRS or System instruction execution in AArch64.
arch/arm64/kvm/hyp/nvhe/switch.c:196: warning: Function parameter or member 'vcpu' not described in 'kvm_handle_pvm_fpsimd'
arch/arm64/kvm/hyp/nvhe/switch.c:196: warning: Function parameter or member 'exit_code' not described in 'kvm_handle_pvm_fpsimd'
arch/arm64/kvm/hyp/nvhe/switch.c:196: warning: expecting prototype for Handler for protected floating(). Prototype was for kvm_handle_pvm_fpsimd() instead
Fixes: 09cf57eba3 ("KVM: arm64: Split hyp/switch.c to VHE/nVHE")
Fixes: 1423afcb41 ("KVM: arm64: Trap access to pVM restricted features")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: kernel test robot <lkp@intel.com>
Cc: Fuad Tabba <tabba@google.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: David Brazdil <dbrazdil@google.com>
Cc: James Morse <james.morse@arm.com>
Cc: Alexandru Elisei <alexandru.elisei@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: kvmarm@lists.cs.columbia.edu
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220430050123.2844-1-rdunlap@infradead.org
There are a few cases in the nVHE code where we take the absolute
address of a symbol via a literal pool entry, and subsequently translate
it to another address space (PA, kimg VA, kernel linear VA, etc).
Originally, this literal was needed because we relied on a different
translation for absolute references, but this is no longer the case, so
we can simply use relative addressing instead. This removes a couple of
RELA entries pointing into the .text segment.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220428140350.3303481-1-ardb@kernel.org
