| Age | Commit message (Collapse) | Author |
|---|
|
We do not have a computed table for HCRX_EL2, so statically define
the bits we know about. A warning will fire if the architecture
grows bits that are not handled yet.
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
These masks are now useless, and can be removed.
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
Flip the hyervisor FGT configuration over to the computed FGT
masks.
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/defconfig
Renesas ARM defconfig updates for v6.16 (take two)
- Enable modular support for the Renesas RZ/G2L GPT and MSIOF sound in
the ARM64 defconfig,
- Enable more support for RZN1D-DB/EB in shmobile_defconfig.
* tag 'renesas-arm-defconfig-for-v6.16-tag2' of https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel:
ARM: shmobile: defconfig: Enable more support for RZN1D-DB/EB
arm64: defconfig: Add Renesas MSIOF sound support
arm64: defconfig: Enable Renesas RZ/G2L GPT config
arm: multi_v7_defconfig: Drop individual Renesas SoC entries
arm: shmobile_defconfig: Drop individual Renesas SoC entries
arm64: defconfig: Remove individual Renesas SoC entries
soc: renesas: Kconfig: Enable SoCs by default when ARCH_RENESAS is set
Link: https://lore.kernel.org/r/cover.1746798750.git.geert+renesas@glider.be
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into soc/arm
ARM: convert board-file GPIO chips to using new value setters
struct gpio_chip now has callbacks for setting line values that return
an integer, allowing to indicate failures. We're in the process of
converting all GPIO drivers to using the new API. This series converts
all ARM board-file level controllers.
* tag 'arm-gpio-set-conversion-for-v6.16-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
ARM: s3c/gpio: use new line value setter callbacks
ARM: scoop/gpio: use new line value setter callbacks
ARM: sa1100/gpio: use new line value setter callbacks
ARM: orion/gpio: use new line value setter callbacks
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/dt
ARM: tegra: Device tree changes for v6.16-rc1
Use standard names for the APBDMA controller device tree nodes, add
support for the ASUS Transformer Pad LTE TF300TL and clean up the Apalis
evaluation board by removing the unused pcie-switch node.
* tag 'tegra-for-6.16-arm-dt' of https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
ARM: tegra: apalis-eval: Remove pcie-switch node
ARM: tegra: Add device-tree for ASUS Transformer Pad LTE TF300TL
ARM: tegra: Rename the apbdma nodename to match with common dma-controller binding
Link: https://lore.kernel.org/r/20250509212604.2849901-2-treding@nvidia.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/dt
arm64: tegra: Device tree changes for v6.16-rc1
Enable IOMMU support for the internal DMA controller of the QSPI
controller, add aliases for the I2C controllers on Tegra234 to match
hardware block names as well as the UART-D alias on Jetson TX1, and
enable PWM fans on Jetson TX1 and TX2.
Clean up serial port device tree nodes, add missing DMA properties,
enable the GPU on Jetson TX1 and Jetson TX2. Use an extended number of
address- and size-cells on Tegra186 to mirror what is done on other chip
generations.
Enable CEC on developer kit devices.
* tag 'tegra-for-6.16-arm64-dt' of https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
arm64: tegra: Wire up CEC to devkits
arm64: tegra: Add CEC controller on Tegra210
arm64: tegra: Add fallback CEC compatibles
arm64: tegra: Add uartd serial alias for Jetson TX1 module
arm64: tegra: Bump #address-cells and #size-cells on Tegra186
arm64: tegra: p2180: Explicitly enable GPU
arm64: tegra: p3310: Explicitly enable GPU
arm64: tegra: Add DMA properties for Tegra186 and Tegra194 UARTs
arm64: tegra: Drop remaining serial clock-names and reset-names
arm64: tegra: Enable PWM fan on the Jetson TX2 Devkit
arm64: tegra: Enable PWM fan on the Jetson TX1 Devkit
arm64: tegra: Add I2C aliases for Tegra234
arm64: tegra: Configure QSPI clocks and add DMA
Link: https://lore.kernel.org/r/20250509212604.2849901-3-treding@nvidia.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes
i.MX fixes for 6.15, 2nd round:
- One more i.MX8MP nominal drive mode DT fix from Ahmad Fatoum to use
800MHz NoC OPP
- A imx8mp-var-som DT change from Himanshu Bhavani to fix SD card
timeout caused by LDO5
* tag 'imx-fixes-6.15-2' of https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
arm64: dts: imx8mp-var-som: Fix LDO5 shutdown causing SD card timeout
arm64: dts: imx8mp: use 800MHz NoC OPP for nominal drive mode
Link: https://lore.kernel.org/r/aB6h/woeyG1bSo12@dragon
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Add poly1305_emit_arch with fallback instead of calling assembly
directly. This is because the state format differs between p10
and that of the generic implementation.
Reported-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
Reported-by: Eric Biggers <ebiggers@google.com>
Fixes: 14d31979145d ("crypto: powerpc/poly1305 - Add block-only interface")
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Make the architecture-optimized CRC code do its CPU feature checks in
subsys_initcalls instead of arch_initcalls. This makes it consistent
with arch/*/lib/crypto/ and ensures that it runs after initcalls that
possibly could be a prerequisite for kernel-mode FPU, such as x86's
xfd_update_static_branch() and loongarch's init_euen_mask().
Note: as far as I can tell, x86's xfd_update_static_branch() isn't
*actually* needed for kernel-mode FPU. loongarch's init_euen_mask() is
needed to enable save/restore of the vector registers, but loongarch
doesn't yet have any CRC or crypto code that uses vector registers
anyway. Regardless, let's be consistent with arch/*/lib/crypto/ and
robust against any potential future dependency on an arch_initcall.
Link: https://lore.kernel.org/r/20250510035959.87995-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux
Pull rust fixes from Miguel Ojeda:
- Make CFI_AUTO_DEFAULT depend on !RUST or Rust >= 1.88.0
- Clean Rust (and Clippy) lints for the upcoming Rust 1.87.0 and 1.88.0
releases
- Clean objtool warning for the upcoming Rust 1.87.0 release by adding
one more noreturn function
* tag 'rust-fixes-6.15-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux:
x86/Kconfig: make CFI_AUTO_DEFAULT depend on !RUST or Rust >= 1.88
rust: clean Rust 1.88.0's `clippy::uninlined_format_args` lint
rust: clean Rust 1.88.0's warning about `clippy::disallowed_macros` configuration
rust: clean Rust 1.88.0's `unnecessary_transmutes` lint
rust: allow Rust 1.87.0's `clippy::ptr_eq` lint
objtool/rust: add one more `noreturn` Rust function for Rust 1.87.0
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into soc/dt
Graphics support for the old rk3066-marsboard (hdmi + Mali400 gpu),
rk3036 improvements (mmc asliases, hdmi refclk), dropping of
redundant clock-latency props.
* tag 'v6.16-rockchip-dts32-1' of https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
ARM: dts: rockchip: enable Mali gpu on rk3066 marsboard
ARM: dts: rockchip: enable hdmi on rk3066 marsboard
Revert "ARM: dts: rockchip: drop grf reference from rk3036 hdmi"
ARM: dts: rockchip: Add ref clk for hdmi
ARM: dts: rockchip: Drop redundant CPU "clock-latency"
ARM: dts: rockchip: Add aliases for rk3036-kylin MMC devices
Link: https://lore.kernel.org/r/22686731.EfDdHjke4D@diego
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into soc/dt
- New boards: rk3588-evb2, rk3588-tiger-haikou-video-demo-overlay
- New peripherals: RNG+PCIe+SATA on rk3576; eDP on rk3588;
DMA+I2C+PWM on rk3528; DSI on rk3588
- SPI-flash binding got a supply-property, so a number of boards add
this supply.
- RK3588 wrongly declared the shared memory with SCMI in the peripheral
space - moved to the correct reserved-memory structure now.
- The rest is peripheral enablement accross many boards - like hdmi
output for a big number of boards, regulators, eeprom, etc.
* tag 'v6.16-rockchip-dts64-1' of https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip: (52 commits)
arm64: dts: rockchip: Add vcc-supply to SPI flash on rk3566-rock3c
arm64: dts: rockchip: Enable regulators for Radxa E20C
arm64: dts: rockchip: Add pwm nodes for RK3528
arm64: dts: rockchip: Add onboard EEPROM for Radxa E20C
arm64: dts: rockchip: Add I2C controllers for RK3528
arm64: dts: rockchip: add RK3576 RNG node
arm64: dts: rockchip: Switch to undeprecated qcom,calibration-variant on RK3399
arm64: dts: rockchip: Add vcc-supply to SPI flash on rk3566-quartz64-b
arm64: dts: rockchip: Add phy-supply to gmac0 on NanoPi R5S
arm64: dts: rockchip: fix usb-c port functionality on rk3588-nanopc-t6
arm64: dts: rockchip: Enable bluetooth of AP6611s on OrangePI5 Max/Ultra
arm64: dts: rockchip: add SATA nodes to RK3576
arm64: dts: rockchip: Add vcc-supply to SPI flash on rk3588-rock-5b
arm64: dts: rockchip: Add vcc-supply to SPI flash on rk3566-pinetab2
arm64: dts: rockchip: Add vcc-supply to SPI flash on rk3399-rockpro64
arm64: dts: rockchip: Add vcc-supply to SPI flash on rk3328-rock64
arm64: dts: rockchip: Add vcc supply to spi flash on rk3399-roc-pc
arm64: dts: rockchip: enable pcie on Sige5
arm64: dts: rockchip: Add HDMI support for roc-rk3576-pc
arm64: dts: rockchip: Enable HDMI0 audio output for Indiedroid Nova
...
Link: https://lore.kernel.org/r/2307187.iZASKD2KPV@diego
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Apple SoC Device Tree updates for 6.16:
- A-series SoCs: CPU cache information has been added to device trees
- M-series SoCs: SPMI controller and SPMI NVMEM nodes have been added
* tag 'asahi-soc-dt-6.16' of https://github.com/AsahiLinux/linux:
arm64: dts: apple: Add PMIC NVMEM
arm64: dts: apple: Add SPMI controller nodes
arm64: dts: apple: t8015: Add CPU caches
arm64: dts: apple: t8012: Add CPU caches
arm64: dts: apple: t8011: Add CPU caches
arm64: dts: apple: t8010: Add CPU caches
arm64: dts: apple: s8001: Add CPU caches
arm64: dts: apple: s800-0-3: Add CPU caches
arm64: dts: apple: t7001: Add CPU caches
arm64: dts: apple: t7000: Add CPU caches
arm64: dts: apple: s5l8960x: Add CPU caches
Link: https://lore.kernel.org/r/20250507160827.87725-1-sven@svenpeter.dev
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
https://github.com/Broadcom/stblinux into soc/dt
This pull request contains Broadcom ARM64-based SoCs Device Tree updates
for 6.16, please pull the following:
- Stanimir adds and enables the PCIe root complex Device Tree nodes present on the
Raspberry Pi 5
- Rob updates the BCM2712 L2 cache node names to use a more comforming
name
* tag 'arm-soc/for-6.16/devicetree-arm64' of https://github.com/Broadcom/stblinux:
arm64: dts: broadcom: bcm2712: Use "l2-cache" for L2 cache node names
arm64: dts: broadcom: bcm2712-rpi-5-b: Enable PCIe DT nodes
arm64: dts: broadcom: bcm2712: Add PCIe DT nodes
Link: https://lore.kernel.org/r/20250505165810.1948927-2-florian.fainelli@broadcom.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
https://github.com/Broadcom/stblinux into soc/dt
This pull request contains Broadcom ARM-based SoC Device Tree changes
for 6.16, please pull the following:
- Arthur adds a pinctrl node for BCM21664 and updates BCM23550 to use
it, he also drops the DTS file for the BCM59056 PMU chip and leaving
that board level DTS files
- Stefan documents and adds support for the Raspberry Pi 2 2nd revision.
* tag 'arm-soc/for-6.16/devicetree' of https://github.com/Broadcom/stblinux:
arm64: dts: bcm: Add reference to RPi 2 (2nd rev)
ARM: dts: bcm: Add support for Raspberry Pi 2 (2nd rev)
dt-bindings: arm: bcm2835: Add Raspberry Pi 2 (2nd rev)
ARM: dts: Drop DTS for BCM59056 PMU
ARM: dts: bcm2166x: Add bcm2166x-pinctrl DTSI
ARM: dts: bcm2166x-common: Add pinctrl node
Link: https://lore.kernel.org/r/20250505165810.1948927-1-florian.fainelli@broadcom.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/dt
Renesas DTS updates for v6.16 (take two)
- Add CANFD support for the RZ/G3E SoC and the RZ/G3E SMARC Carrier-II
EVK development board,
- Add support for Ethernet port A, 9-pin D-sub serial, and USB on the
RZN1D-DB and RZN1D-EB development and expansion boards,
- Add sound support for the Retronix Sparrow Hawk board,
- Add General PWM Timer (GPT) support for the RZ/G2L and RZ/V2L SoCs
and SMARC EVK boards,
- Miscellaneous fixes and improvements.
* tag 'renesas-dts-for-v6.16-tag2' of https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel:
ARM: dts: renesas: r9a06g032-rzn1d400-eb: Enable USB host port
ARM: dts: renesas: r9a06g032-rzn1d400-db: Add pinmux for the CPLD
arm64: dts: renesas: white-hawk-single: Improve Ethernet TSN description
ARM: dts: renesas: r9a06g032-rzn1d400-db: Enable USB device port
ARM: dts: renesas: r9a06g032-rzn1d400-eb: Describe 9-pin D-sub serial port
arm64: dts: renesas: beacon-renesom: Align wifi node name with bindings
arm64: dts: renesas: rzg2l-smarc: Enable GPT on carrier board
arm64: dts: renesas: r9a07g054: Add GPT support
arm64: dts: renesas: r9a07g044: Add GPT support
arm64: dts: renesas: sparrow-hawk: Add MSIOF Sound support
ARM: dts: renesas: r9a06g032-rzn1d400-eb: Add GMAC1 port
arm64: dts: renesas: r9a09g047e57-smarc: Enable CAN Transceiver
arm64: dts: renesas: r9a09g047e57-smarc: Enable CANFD
arm64: dts: renesas: r9a09g047: Add CANFD node
Link: https://lore.kernel.org/r/cover.1746798755.git.geert+renesas@glider.be
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/dt
Renesas DTS updates for v6.16
- Add SDHI, ICU, I2C, PMIC, and GPU support on the RZ/G3E SoC and the
RZ/G3E SoM and SMARC Carrier-II EVK development board,
- Add internal SDHI regulator support on the RZ/V2H(P) SoC,
- Add UFS tuning parameters in E-FUSE on the R-Car S4-8 ES1.2 SoC,
- Add support for Ethernet ports C and D, I2C, keys, and SDHI on the
RZ/N1D SoC and the RZN1D-DB and RZN1D-EB development and expansion
boards,
- Add initial support for the RZ/V2N (R9A09G056) and the RZ/V2N EVK
board,
- Add support for the Retronix Sparrow Hawk board, which is based on
R-Car V4H ES3.0,
- Add ISP core support on R-Car V3U, V4H, and V4M,
- Miscellaneous fixes and improvements.
* tag 'renesas-dts-for-v6.16-tag1' of https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: (29 commits)
arm64: dts: renesas: r8a779h0: Add ISP core function block
arm64: dts: renesas: r8a779g0: Add ISP core function block
arm64: dts: renesas: r8a779a0: Add ISP core function block
arm64: dts: renesas: r8a779g3: Add Retronix R-Car V4H Sparrow Hawk board support
arm64: dts: renesas: rzg3e-smarc-som: Enable Mali-G52
arm64: dts: renesas: r9a09g047: Add Mali-G52 GPU node
arm64: dts: renesas: rzg3e-smarc-som: Add RAA215300 pmic support
arm64: dts: renesas: rzg3e-smarc-som: Add I2C2 device pincontrol
ARM: dts: renesas: r9a06g032-rzn1d400-eb: describe SD card port
ARM: dts: renesas: r9a06g032: Describe SDHCI controllers
arm64: dts: renesas: Add initial device tree for RZ/V2N EVK
arm64: dts: renesas: Add initial SoC DTSI for RZ/V2N
dt-bindings: pinctrl: renesas: Document RZ/V2N SoC
dt-bindings: clock: renesas: Document RZ/V2N SoC CPG
dt-bindings: soc: renesas: Document SYS for RZ/V2N SoC
dt-bindings: soc: renesas: Document Renesas RZ/V2N SoC variants and EVK
ARM: dts: renesas: r9a06g032-rzn1d400-db: Describe keys
ARM: dts: renesas: r9a06g032-rzn1d400-eb: Describe I2C bus
ARM: dts: renesas: r9a06g032-rzn1d400-db: Describe I2C bus
ARM: dts: renesas: r9a06g032: Describe I2C controllers
...
Link: https://lore.kernel.org/r/cover.1745582596.git.geert+renesas@glider.be
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
FineIBT-paranoid was using the retpoline bytes for the paranoid check,
disabling retpolines, because all parts that have IBT also have eIBRS
and thus don't need no stinking retpolines.
Except... ITS needs the retpolines for indirect calls must not be in
the first half of a cacheline :-/
So what was the paranoid call sequence:
<fineibt_paranoid_start>:
0: 41 ba 78 56 34 12 mov $0x12345678, %r10d
6: 45 3b 53 f7 cmp -0x9(%r11), %r10d
a: 4d 8d 5b <f0> lea -0x10(%r11), %r11
e: 75 fd jne d <fineibt_paranoid_start+0xd>
10: 41 ff d3 call *%r11
13: 90 nop
Now becomes:
<fineibt_paranoid_start>:
0: 41 ba 78 56 34 12 mov $0x12345678, %r10d
6: 45 3b 53 f7 cmp -0x9(%r11), %r10d
a: 4d 8d 5b f0 lea -0x10(%r11), %r11
e: 2e e8 XX XX XX XX cs call __x86_indirect_paranoid_thunk_r11
Where the paranoid_thunk looks like:
1d: <ea> (bad)
__x86_indirect_paranoid_thunk_r11:
1e: 75 fd jne 1d
__x86_indirect_its_thunk_r11:
20: 41 ff eb jmp *%r11
23: cc int3
[ dhansen: remove initialization to false ]
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
|
|
ITS mitigation moves the unsafe indirect branches to a safe thunk. This
could degrade the prediction accuracy as the source address of indirect
branches becomes same for different execution paths.
To improve the predictions, and hence the performance, assign a separate
thunk for each indirect callsite. This is also a defense-in-depth measure
to avoid indirect branches aliasing with each other.
As an example, 5000 dynamic thunks would utilize around 16 bits of the
address space, thereby gaining entropy. For a BTB that uses
32 bits for indexing, dynamic thunks could provide better prediction
accuracy over fixed thunks.
Have ITS thunks be variable sized and use EXECMEM_MODULE_TEXT such that
they are both more flexible (got to extend them later) and live in 2M TLBs,
just like kernel code, avoiding undue TLB pressure.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux into soc/dt
SoCFPGA DTS updates for v6.15
- Updates to dt-bindings
- Document Agilex5 NAND daughter board
- Convert Stratix10 FPGA Manager to json-schema
- Convert Stratix10 Service Layer to json-schema
- Add document for Terasic's DE10-nano board
- Add support for Agilex5 NAND daughter board
- Add basic support for Terasic's DE10-nano board
* tag 'socfpga_dts_updates_for_v6.15' of https://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux:
arm64: dts: socfpga: agilex: Add dma channel id for spi
arm64: dts: socfpga: agilex5: add led and memory nodes
arm64: dts: intel: socfpga_agilex: add frequencies to internal oscillators
ARM: dts: socfpga: Add basic support for Terrasic's de10-nano
dt-bindings: altera: Add compatible for Terasic's DE10-nano
arm64: dts: socfpga: agilex5: add qspi flash node
dt-bindings: firmware: stratix10: Convert to json-schema
dt-bindings: fpga: stratix10: Convert to json-schema
arm64: dts: socfpga: agilex5: fix gpio0 address
arm64: dts: socfpga: agilex5: add NAND daughter board
dt-bindings: intel: document Agilex5 NAND daughter board
Link: https://lore.kernel.org/r/20250326121152.1739873-1-dinguyen@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
cfi_rewrite_callers() updates the fineIBT hash matching at the caller side,
but except for paranoid-mode it relies on apply_retpoline() and friends for
any ENDBR relocation. This could temporarily cause an indirect branch to
land on a poisoned ENDBR.
For instance, with para-virtualization enabled, a simple wrmsrl() could
have an indirect branch pointing to native_write_msr() who's ENDBR has been
relocated due to fineIBT:
<wrmsrl>:
push %rbp
mov %rsp,%rbp
mov %esi,%eax
mov %rsi,%rdx
shr $0x20,%rdx
mov %edi,%edi
mov %rax,%rsi
call *0x21e65d0(%rip) # <pv_ops+0xb8>
^^^^^^^^^^^^^^^^^^^^^^^
Such an indirect call during the alternative patching could #CP if the
caller is not *yet* adjusted for the new target ENDBR. To prevent a false
#CP, keep CET-IBT disabled until all callers are patched.
Patching during the module load does not need to be guarded by IBT-disable
because the module code is not executed until the patching is complete.
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
|
|
Early kernel memory is RWX, only at the end of early boot (before SMP)
do we mark things ROX. Have execmem_cache mirror this behaviour for
early users.
This avoids having to remember what code is execmem and what is not --
we can poke everything with impunity ;-) Also performance for not
having to do endless text_poke_mm switches.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
|
|
They should be named "usb@".
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Link: https://lore.kernel.org/r/20250330193833.21970-12-wsa+renesas@sang-engineering.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
They should be named "usb@".
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Link: https://lore.kernel.org/r/20250330193833.21970-11-wsa+renesas@sang-engineering.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
They should be named "usb@".
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Link: https://lore.kernel.org/r/20250330193833.21970-10-wsa+renesas@sang-engineering.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
They should be named "usb@".
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Link: https://lore.kernel.org/r/20250330193833.21970-9-wsa+renesas@sang-engineering.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
They should be named "usb@".
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Link: https://lore.kernel.org/r/20250330193833.21970-8-wsa+renesas@sang-engineering.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Fix a couple of node name warnings from the schema checks:
arch/arm64/boot/dts/amazon/alpine-v2-evp.dt.yaml: io-fabric: $nodename:0: 'io-fabric' does not match '^(bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$'
arch/arm64/boot/dts/amazon/alpine-v3-evp.dt.yaml: io-fabric: $nodename:0: 'io-fabric' does not match '^(bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$'
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20250409210255.1541298-1-robh@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
The software mitigation for BHI is to execute BHB clear sequence at syscall
entry, and possibly after a cBPF program. ITS mitigation thunks RETs in the
lower half of the cacheline. This causes the RETs in the BHB clear sequence
to be thunked as well, adding unnecessary branches to the BHB clear
sequence.
Since the sequence is in hot path, align the RET instructions in the
sequence to avoid thunking.
This is how disassembly clear_bhb_loop() looks like after this change:
0x44 <+4>: mov $0x5,%ecx
0x49 <+9>: call 0xffffffff81001d9b <clear_bhb_loop+91>
0x4e <+14>: jmp 0xffffffff81001de5 <clear_bhb_loop+165>
0x53 <+19>: int3
...
0x9b <+91>: call 0xffffffff81001dce <clear_bhb_loop+142>
0xa0 <+96>: ret
0xa1 <+97>: int3
...
0xce <+142>: mov $0x5,%eax
0xd3 <+147>: jmp 0xffffffff81001dd6 <clear_bhb_loop+150>
0xd5 <+149>: nop
0xd6 <+150>: sub $0x1,%eax
0xd9 <+153>: jne 0xffffffff81001dd3 <clear_bhb_loop+147>
0xdb <+155>: sub $0x1,%ecx
0xde <+158>: jne 0xffffffff81001d9b <clear_bhb_loop+91>
0xe0 <+160>: ret
0xe1 <+161>: int3
0xe2 <+162>: int3
0xe3 <+163>: int3
0xe4 <+164>: int3
0xe5 <+165>: lfence
0xe8 <+168>: pop %rbp
0xe9 <+169>: ret
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
|
|
When retpoline mitigation is enabled for spectre-v2, enabling
call-depth-tracking and RSB stuffing also mitigates ITS. Add cmdline option
indirect_target_selection=stuff to allow enabling RSB stuffing mitigation.
When retpoline mitigation is not enabled, =stuff option is ignored, and
default mitigation for ITS is deployed.
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Josh Poimboeuf <jpoimboe@kernel.org>
Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
|
|
Ice Lake generation CPUs are not affected by guest/host isolation part of
ITS. If a user is only concerned about KVM guests, they can now choose a
new cmdline option "vmexit" that will not deploy the ITS mitigation when
CPU is not affected by guest/host isolation. This saves the performance
overhead of ITS mitigation on Ice Lake gen CPUs.
When "vmexit" option selected, if the CPU is affected by ITS guest/host
isolation, the default ITS mitigation is deployed.
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Josh Poimboeuf <jpoimboe@kernel.org>
Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
|
|
Indirect Target Selection (ITS) is a bug in some pre-ADL Intel CPUs with
eIBRS. It affects prediction of indirect branch and RETs in the
lower half of cacheline. Due to ITS such branches may get wrongly predicted
to a target of (direct or indirect) branch that is located in the upper
half of the cacheline.
Scope of impact
===============
Guest/host isolation
--------------------
When eIBRS is used for guest/host isolation, the indirect branches in the
VMM may still be predicted with targets corresponding to branches in the
guest.
Intra-mode
----------
cBPF or other native gadgets can be used for intra-mode training and
disclosure using ITS.
User/kernel isolation
---------------------
When eIBRS is enabled user/kernel isolation is not impacted.
Indirect Branch Prediction Barrier (IBPB)
-----------------------------------------
After an IBPB, indirect branches may be predicted with targets
corresponding to direct branches which were executed prior to IBPB. This is
mitigated by a microcode update.
Add cmdline parameter indirect_target_selection=off|on|force to control the
mitigation to relocate the affected branches to an ITS-safe thunk i.e.
located in the upper half of cacheline. Also add the sysfs reporting.
When retpoline mitigation is deployed, ITS safe-thunks are not needed,
because retpoline sequence is already ITS-safe. Similarly, when call depth
tracking (CDT) mitigation is deployed (retbleed=stuff), ITS safe return
thunk is not used, as CDT prevents RSB-underflow.
To not overcomplicate things, ITS mitigation is not supported with
spectre-v2 lfence;jmp mitigation. Moreover, it is less practical to deploy
lfence;jmp mitigation on ITS affected parts anyways.
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Josh Poimboeuf <jpoimboe@kernel.org>
Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
|
|
RETs in the lower half of cacheline may be affected by ITS bug,
specifically when the RSB-underflows. Use ITS-safe return thunk for such
RETs.
RETs that are not patched:
- RET in retpoline sequence does not need to be patched, because the
sequence itself fills an RSB before RET.
- RET in Call Depth Tracking (CDT) thunks __x86_indirect_{call|jump}_thunk
and call_depth_return_thunk are not patched because CDT by design
prevents RSB-underflow.
- RETs in .init section are not reachable after init.
- RETs that are explicitly marked safe with ANNOTATE_UNRET_SAFE.
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Josh Poimboeuf <jpoimboe@kernel.org>
Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
|
|
Due to ITS, indirect branches in the lower half of a cacheline may be
vulnerable to branch target injection attack.
Introduce ITS-safe thunks to patch indirect branches in the lower half of
cacheline with the thunk. Also thunk any eBPF generated indirect branches
in emit_indirect_jump().
Below category of indirect branches are not mitigated:
- Indirect branches in the .init section are not mitigated because they are
discarded after boot.
- Indirect branches that are explicitly marked retpoline-safe.
Note that retpoline also mitigates the indirect branches against ITS. This
is because the retpoline sequence fills an RSB entry before RET, and it
does not suffer from RSB-underflow part of the ITS.
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Josh Poimboeuf <jpoimboe@kernel.org>
Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
|
|
ITS bug in some pre-Alderlake Intel CPUs may allow indirect branches in the
first half of a cache line get predicted to a target of a branch located in
the second half of the cache line.
Set X86_BUG_ITS on affected CPUs. Mitigation to follow in later commits.
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Josh Poimboeuf <jpoimboe@kernel.org>
Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
|
|
Add ROCK 5B+, which is an improved version of the ROCK 5B with the
following changes:
* Memory LPDDR4X -> LPDDR5
* HDMI input connector size
* eMMC socket -> onboard
* M.2 E-Key is replaced by onboard RTL8852BE WLAN/BT
* M.2 M-Key 1x4 lanes is replaced by 2x2 lanes
* Added M.2 B-Key for USB connected WWAN modules (untested)
* Add second camera port (not yet supported in upstream Linux)
* Add dedicated USB-C port for device power (no impact in DT;
the existing port has not been changed and the new port is
handled by CH224D standalone chip)
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://lore.kernel.org/r/20250508-rock5bp-for-upstream-v2-4-677033cc1ac2@kernel.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Radxa released some more boards, which are based on the original
Rock 5B. Move its board description into an include file to avoid
unnecessary duplication.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://lore.kernel.org/r/20250508-rock5bp-for-upstream-v2-1-677033cc1ac2@kernel.org
Link: https://lore.kernel.org/r/20250508-rock5bp-for-upstream-v2-2-677033cc1ac2@kernel.org
[The original submission was split into two elements, renaming the file
and then moving some nodes around. This was done to make review easier
due to the diff being smaller. This commit is a squash of both of them
to facilitate bisectability and was also intended by the original author]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
General feature for rk3399 industry evaluation board:
- Rockchip RK3399
- 4GB LPDDR4
- emmc5.1
- SDIO3.0 compatible TF card
- 1x HDMI2.0a TX
- 1x HDMI1.4b RX with TC358749XBG HDMI to MIPI CSI2 bridge chip
- 1x type-c DisplayPort
- 3x USB3.0 Host
- 1x USB2.0 Host
- 1x Ethernet / USB3.0 to Ethernet
Tested with HDMI/GPU/USB2.0/USB3.0/TF card/emmc.
Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
Link: https://lore.kernel.org/r/20250506034347.57-3-kernel@airkyi.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The RK3576 uses Rockchip SAI for audio output. Meanwhile, the Sige5
board, which uses the RK3576 and is supported by mainline, uses an
ES8388 codec over I2C with the ES8328 driver implementing support for
this codec.
Enable both in the defconfig.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Link: https://lore.kernel.org/r/20250506-rk3576-sai-v4-5-a8b5f5733ceb@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
With the hdmi_sound node added to the base RK3576 SoC tree, we can now
enable it on the Sige5 SBC.
Do this, and also enable the corresponding SAI6 audio controller node.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Link: https://lore.kernel.org/r/20250506-rk3576-sai-v4-4-a8b5f5733ceb@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The ArmSoM Sige5 board features an Everest ES8388 codec to provide
analog stereo audio output, as well as analog audio input. The codec
hangs off the i2c2 bus and responds to address 0x10. It is connected to
the SAI1 audio controller of the RK3576, with one SDO (output) lane and
one SDI (input) lane.
The codec has two sets of outputs. One set, LOUT1/ROUT1, is connected
through a set of 22uF non-polarised coupling capacitors to a 3-position
connector that appears to be a clone of the JST BM03B-SURS-TF header,
and is capable of mating with a JST 03SUR-32S (or JST 03SUR-36L if you
prefer lemon-lime) or compatible clone connector. The right headphone
output is the one closest to the Type-C DC input connector, the left
headphone output is the one in the middle, and the third position, the
one closest to the USB3 Type-A host connector, is puzzingly labelled as
"HP_GND" in the schematic but is in fact connected to the codecs RIN1
input through a 1uF non-plarised coupling capacitor.
LOUT2 and ROUT2 are routed to 1mm test pads T36 and T37 respectively.
These are located on the bottom of the board, and do not go through any
coupling capacitor. For use as line out, the ES8388 datasheet recommends
adding 1uF coupling capacitor if one wishes to use it as a line-level
output.
There is also a pair of inputs for a stereo microphone, going from two
1mm testpads T34 and T35, which are decoupled with a 100pF capacitor and
pulled to 3.3v and ground respectively. These inputs then go through 1uF
capacitors each and end up in the LINPUT2 and RINPUT2 pins of the
ES8388 codec.
The codec's power inputs are routed to receive 3.3V for both its analog
and digital inputs, though from different supplies.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Link: https://lore.kernel.org/r/20250506-rk3576-sai-v4-3-a8b5f5733ceb@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The RK3576 SoC now has upstream support for HDMI.
Add an HDMI audio node, which uses SAI6 as its audio controller
according to downstream.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Link: https://lore.kernel.org/r/20250506-rk3576-sai-v4-2-a8b5f5733ceb@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The RK3576 SoC has 10 SAI controllers in total. Five of them are in the
video output power domains, and are used for digital audio output along
with the video signal of those, e.g. HDMI audio.
The other five, SAI0 through SAI4, are exposed externally. SAI0 and SAI1
are capable of 8-channel audio, whereas SAI2, SAI3 and SAI4 are limited
to two channels. These five are in the audio power domain.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Link: https://lore.kernel.org/r/20250506-rk3576-sai-v4-1-a8b5f5733ceb@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
SD-card is available on Radxa E20C board.
Signed-off-by: Yao Zi <ziyao@disroot.org>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20250508234829.27111-4-ziyao@disroot.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
RK3528 features two SDIO controllers and one SD/MMC controller, describe
them in devicetree. Since their sample and drive clocks are located in
the VO and VPU GRFs, corresponding syscons are added to make these
clocks available.
Signed-off-by: Yao Zi <ziyao@disroot.org>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20250508234829.27111-3-ziyao@disroot.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull arm64 fix from Catalin Marinas:
"Move the arm64_use_ng_mappings variable from the .bss to the .data
section as it is accessed very early during boot with the MMU off and
before the .bss has been initialised.
This could lead to incorrect idmap page table"
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64: cpufeature: Move arm64_use_ng_mappings to the .data section to prevent wrong idmap generation
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux
Pull RISC-V fixes from Palmer Dabbelt:
- The compressed half-word misaligned access instructions (c.lhu, c.lh,
and c.sh) from the Zcb extension are now properly emulated
- A series of fixes to properly emulate permissions while handling
userspace misaligned accesses
- A pair of fixes for PR_GET_TAGGED_ADDR_CTRL to avoid accessing the
envcfg CSR on systems that don't support that CSR, and to report
those failures up to userspace
- The .rela.dyn section is no longer stripped from vmlinux, as it is
necessary to relocate the kernel under some conditions (including
kexec)
* tag 'riscv-for-linus-6.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
riscv: Disallow PR_GET_TAGGED_ADDR_CTRL without Supm
scripts: Do not strip .rela.dyn section
riscv: Fix kernel crash due to PR_SET_TAGGED_ADDR_CTRL
riscv: misaligned: use get_user() instead of __get_user()
riscv: misaligned: enable IRQs while handling misaligned accesses
riscv: misaligned: factorize trap handling
riscv: misaligned: Add handling for ZCB instructions
|
|
Currently, the verifier inserts a zext instruction right after every 8-,
16- or 32-bit load-acquire, which is already zero-extending. Skip such
redundant zext instructions.
While we are here, update that already-obsolete comment about "skip the
next instruction" in build_body(). Also change emit_atomic_rmw()'s
parameters to keep it consistent with emit_atomic_ld_st().
Note that checking 'insn[1]' relies on 'insn' not being the last
instruction, which should have been guaranteed by the verifier; we
already use 'insn[1]' elsewhere in the file for similar purposes.
Additionally, we don't check if 'insn[1]' is actually a zext for our
load-acquire's dst_reg, or some other registers - in other words, here
we are relying on the verifier to always insert a redundant zext right
after a 8/16/32-bit load-acquire, for its dst_reg.
Acked-by: Björn Töpel <bjorn@kernel.org>
Reviewed-by: Pu Lehui <pulehui@huawei.com>
Tested-by: Björn Töpel <bjorn@rivosinc.com> # QEMU/RVA23
Signed-off-by: Peilin Ye <yepeilin@google.com>
Link: https://lore.kernel.org/r/10e90e0eab042f924d35ad0d1c1f7ca29f673152.1746588351.git.yepeilin@google.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
|
Support BPF load-acquire (BPF_LOAD_ACQ) and store-release
(BPF_STORE_REL) instructions in the riscv64 JIT compiler. For example,
consider the following 64-bit load-acquire (assuming little-endian):
db 10 00 00 00 01 00 00 r1 = load_acquire((u64 *)(r1 + 0x0))
95 00 00 00 00 00 00 00 exit
opcode (0xdb): BPF_ATOMIC | BPF_DW | BPF_STX
imm (0x00000100): BPF_LOAD_ACQ
The JIT compiler will emit an LD instruction followed by a FENCE R,RW
instruction for the above, e.g.:
ld x7,0(x6)
fence r,rw
Similarly, consider the following 16-bit store-release:
cb 21 00 00 10 01 00 00 store_release((u16 *)(r1 + 0x0), w2)
95 00 00 00 00 00 00 00 exit
opcode (0xcb): BPF_ATOMIC | BPF_H | BPF_STX
imm (0x00000110): BPF_STORE_REL
A FENCE RW,W instruction followed by an SH instruction will be emitted,
e.g.:
fence rw,w
sh x2,0(x4)
8-bit and 16-bit load-acquires are zero-extending (cf., LBU, LHU). The
verifier always rejects misaligned load-acquires/store-releases (even if
BPF_F_ANY_ALIGNMENT is set), so the emitted load and store instructions
are guaranteed to be single-copy atomic.
Introduce primitives to emit the relevant (and the most common/used in
the kernel) fences, i.e. fences with R -> RW, RW -> W and RW -> RW.
Rename emit_atomic() to emit_atomic_rmw() to make it clear that it only
handles RMW atomics, and replace its is64 parameter to allow to perform
the required checks on the opsize (BPF_SIZE(code)).
Acked-by: Björn Töpel <bjorn@kernel.org>
Tested-by: Björn Töpel <bjorn@rivosinc.com> # QEMU/RVA23
Signed-off-by: Andrea Parri <parri.andrea@gmail.com>
Co-developed-by: Peilin Ye <yepeilin@google.com>
Signed-off-by: Peilin Ye <yepeilin@google.com>
Reviewed-by: Pu Lehui <pulehui@huawei.com>
Link: https://lore.kernel.org/r/3059c560e537ad43ed19055d2ebbd970c698095a.1746588351.git.yepeilin@google.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
