summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2025-01-06arm64: dts: renesas: r8a779g0: Add FCPVX instancesJacopo Mondi
Add device nodes for the FCPVX instances on R-Car V4H (R8A779G0) SoC. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Link: https://lore.kernel.org/20241220-rcar-v4h-vspx-v4-2-7dc1812585ad@ideasonboard.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-01-06arm64: dts: renesas: r9a09g047e57-smarc: Add SCIF pincontrolBiju Das
Add device node for SCIF pincontrol. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/20241216195325.164212-8-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-01-06bpf, arm64: Emit A64_{ADD,SUB}_I when possible in emit_{lse,ll_sc}_atomic()Peilin Ye
Currently in emit_{lse,ll_sc}_atomic(), if there is an offset, we add it to the base address by doing e.g.: if (off) { emit_a64_mov_i(1, tmp, off, ctx); emit(A64_ADD(1, tmp, tmp, dst), ctx); [...] As pointed out by Xu, we can use emit_a64_add_i() (added in the previous patch) instead, which tries to combine the above into a single A64_ADD_I or A64_SUB_I when possible. Suggested-by: Xu Kuohai <xukuohai@huaweicloud.com> Signed-off-by: Peilin Ye <yepeilin@google.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Xu Kuohai <xukuohai@huawei.com> Link: https://lore.kernel.org/bpf/9ad3034a62361d91a99af24efa03f48c4c9e13ea.1735868489.git.yepeilin@google.com
2025-01-06bpf, arm64: Factor out emit_a64_add_i()Peilin Ye
As suggested by Xu, factor out emit_a64_add_i() for later use. No functional change. Suggested-by: Xu Kuohai <xukuohai@huaweicloud.com> Signed-off-by: Peilin Ye <yepeilin@google.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Xu Kuohai <xukuohai@huawei.com> Link: https://lore.kernel.org/bpf/fedbaca80e6d8bd5bcba1ac5320dfbbdab14472e.1735868489.git.yepeilin@google.com
2025-01-06bpf, arm64: Simplify if logic in emit_lse_atomic()Peilin Ye
Delete that unnecessary outer if clause. No functional change. Signed-off-by: Peilin Ye <yepeilin@google.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Xu Kuohai <xukuohai@huawei.com> Link: https://lore.kernel.org/bpf/e8520e5503a489e2dea8526077976ae5a0ab1849.1735868489.git.yepeilin@google.com
2025-01-06ARM: dts: st: enable the MALI gpu on the stih410-b2260Alain Volmat
Enable the GPU on the stih410-b2260 board. Signed-off-by: Alain Volmat <avolmat@me.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
2025-01-06ARM: dts: st: add node for the MALI gpu on stih410.dtsiAlain Volmat
Add the entry for the GPU (Mali400) on the stih410.dtsi Signed-off-by: Alain Volmat <avolmat@me.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
2025-01-04arm64: dts: allwinner: a64: explicitly assign clock parent for TCON0Vasily Khoruzhick
TCON0 seems to need a different clock parent depending on output type. For RGB it has to be PLL-VIDEO0-2X, while for DSI it has to be PLL-MIPI, so select it explicitly. Video output doesn't work if incorrect clock is assigned. On my Pinebook I manually configured PLL-VIDEO0-2X and PLL-MIPI to the same rate, and while video output works fine with PLL-VIDEO0-2X, it doesn't work at all (as in no picture) with PLL-MIPI. Fixes: ca1170b69968 ("clk: sunxi-ng: a64: force select PLL_MIPI in TCON0 mux") Reviewed-by: Dragan Simic <dsimic@manjaro.org> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Tested-by: Frank Oltmanns <frank@oltmanns.dev> # on PinePhone Tested-by: Stuart Gathman <stuart@gathman.org> # on OG Pinebook Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Link: https://patch.msgid.link/20250104074035.1611136-4-anarsoul@gmail.com Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2025-01-04EDAC: Add an EDAC driver for the Loongson memory controllerZhao Qunqin
Add ECC support for Loongson SoC DDR controller. This driver reports single bit errors (CE) only. Only ACPI firmware is supported. [ bp: Document what last_ce_count is for. ] Signed-off-by: Zhao Qunqin <zhaoqunqin@loongson.cn> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Huacai Chen <chenhuacai@loongson.cn> Link: https://lore.kernel.org/r/20241219124846.1876-1-zhaoqunqin@loongson.cn Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
2025-01-04crypto: keywrap - remove unused keywrap algorithmEric Biggers
The keywrap (kw) algorithm has no in-tree user. It has never had an in-tree user, and the patch that added it provided no justification for its inclusion. Even use of it via AF_ALG is impossible, as it uses a weird calling convention where part of the ciphertext is returned via the IV buffer, which is not returned to userspace in AF_ALG. It's also unclear whether any new code in the kernel that does key wrapping would actually use this algorithm. It is controversial in the cryptographic community due to having no clearly stated security goal, no security proof, poor performance, and only a 64-bit auth tag. Later work (https://eprint.iacr.org/2006/221) suggested that the goal is deterministic authenticated encryption. But there are now more modern algorithms for this, and this is not the same as key wrapping, for which a regular AEAD such as AES-GCM usually can be (and is) used instead. Therefore, remove this unused code. There were several special cases for this algorithm in the self-tests, due to its weird calling convention. Remove those too. Cc: Stephan Mueller <smueller@chronox.de> Signed-off-by: Eric Biggers <ebiggers@google.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> # m68k Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-01-04crypto: vmac - remove unused VMAC algorithmEric Biggers
Remove the vmac64 template, as it has no known users. It also continues to have longstanding bugs such as alignment violations (see https://lore.kernel.org/r/20241226134847.6690-1-evepolonium@gmail.com/). This code was added in 2009 by commit f1939f7c5645 ("crypto: vmac - New hash algorithm for intel_txt support"). Based on the mention of intel_txt support in the commit title, it seems it was added as a prerequisite for the contemporaneous patch "intel_txt: add s3 userspace memory integrity verification" (https://lore.kernel.org/r/4ABF2B50.6070106@intel.com/). In the design proposed by that patch, when an Intel Trusted Execution Technology (TXT) enabled system resumed from suspend, the "tboot" trusted executable launched the Linux kernel without verifying userspace memory, and then the Linux kernel used VMAC to verify userspace memory. However, that patch was never merged, as reviewers had objected to the design. It was later reworked into commit 4bd96a7a8185 ("x86, tboot: Add support for S3 memory integrity protection") which made tboot verify the memory instead. Thus the VMAC support in Linux was never used. No in-tree user has appeared since then, other than potentially the usual components that allow specifying arbitrary hash algorithms by name, namely AF_ALG and dm-integrity. However there are no indications that VMAC is being used with these components. Debian Code Search and web searches for "vmac64" (the actual algorithm name) do not return any results other than the kernel itself, suggesting that it does not appear in any other code or documentation. Explicitly grepping the source code of the usual suspects (libell, iwd, cryptsetup) finds no matches either. Before 2018, the vmac code was also completely broken due to using a hardcoded nonce and the wrong endianness for the MAC. It was then fixed by commit ed331adab35b ("crypto: vmac - add nonced version with big endian digest") and commit 0917b873127c ("crypto: vmac - remove insecure version with hardcoded nonce"). These were intentionally breaking changes that changed all the computed MAC values as well as the algorithm name ("vmac" to "vmac64"). No complaints were ever received about these breaking changes, strongly suggesting the absence of users. The reason I had put some effort into fixing this code in 2018 is because it was used by an out-of-tree driver. But if it is still needed in that particular out-of-tree driver, the code can be carried in that driver instead. There is no need to carry it upstream. Cc: Atharva Tiwari <evepolonium@gmail.com> Cc: Shane Wang <shane.wang@intel.com> Signed-off-by: Eric Biggers <ebiggers@google.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> # m68k Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-01-03Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR (net-6.13-rc6). No conflicts. Adjacent changes: include/linux/if_vlan.h f91a5b808938 ("af_packet: fix vlan_get_protocol_dgram() vs MSG_PEEK") 3f330db30638 ("net: reformat kdoc return statements") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-03Merge tag 'nios2_update_for_v6.14' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux Pull nios2 fixlet from Dinh Nguyen: - Use str_yes_no() helper function * tag 'nios2_update_for_v6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux: nios2: Use str_yes_no() helper in show_cpuinfo()
2025-01-03arm64: dts: renesas: r9a09g047: Add pincontrol nodeBiju Das
Add pincontrol node to RZ/G3E ("R9A09G047") SoC DTSI. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/20241216195325.164212-7-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-01-03arm64: dts: renesas: r9a09g057h44-rzv2h-evk: Replace RZG2L macrosBiju Das
Replace RZG2L_* macros with RZV2H_* macros, so that we can define port names in alpha-numeric. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/20241216195325.164212-6-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-01-03Merge tag 'pinctrl-v6.13-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control fixes from Linus Walleij: - A small Kconfig fixup for the i.MX. In principle this could come in from the SoC tree but the bug was introduced from the pin control tree so let's fix it from here. - Fix a sleep in atomic context in the MCP23xxx GPIO expander by disabling the regmap locking and using explicit mutex locks. * tag 'pinctrl-v6.13-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: pinctrl: mcp23s08: Fix sleeping in atomic context due to regmap locking ARM: imx: Re-introduce the PINCTRL selection
2025-01-03x86/mce/amd: Remove shared threshold bank plumbingYazen Ghannam
Legacy AMD systems include an integrated Northbridge that is represented by MCA bank 4. This is the only non-core MCA bank in legacy systems. The Northbridge is physically shared by all the CPUs within an AMD "Node". However, in practice the "shared" MCA bank can only by managed by a single CPU within that AMD Node. This is known as the "Node Base Core" (NBC). For example, only the NBC will be able to read the MCA bank 4 registers; they will be Read-as-Zero for other CPUs. Also, the MCA Thresholding interrupt will only signal the NBC; the other CPUs will not receive it. This is enforced by hardware, and it should not be managed by software. The current AMD Thresholding code attempts to deal with the "shared" MCA bank by micromanaging the bank's sysfs kobjects. However, this does not follow the intended kobject use cases. It is also fragile, and it has caused bugs in the past. Modern AMD systems do not need this shared MCA bank support, and it should not be needed on legacy systems either. Remove the shared threshold bank code. Also, move the threshold struct definitions to mce/amd.c, since they are no longer needed in amd_nb.c. Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20241206161210.163701-2-yazen.ghannam@amd.com
2025-01-03x86/ioapic: Remove a stray tab in the IO-APIC type stringAlan Song
The type "physic al" should be "physical". [ bp: Massage commit message. ] Fixes: 54cd3795b471 ("x86/ioapic: Cleanup guarded debug printk()s") Signed-off-by: Alan Song <syfmark114@163.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20241230065706.16789-1-syfmark114@163.com
2025-01-03arm64: dts: rockchip: set hdd led labels on QNAP-TS433Heiko Stuebner
The automatically generated names for the LEDs from color and function do not match nicely for the 4 hdds, so set them manually per the label property to also match the LEDs generated from the MCU. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20241107114712.538976-10-heiko@sntech.de
2025-01-03arm64: dts: rockchip: hook up the MCU on the QNAP TS433Heiko Stuebner
The MCU is an important part of the device functionality. It provides functionality like fan-control, more leds, etc and even more important without it, the NAS-device cannot even fully turned off. Hook up the serial device to its uart and hook into the thermal management to control the fan according to the cpu temperature. While the MCU also provides a temperature sensor for the case, this one is just polled and does not provide functionality for handling trip points in hardware, so a lot of polling would be involved. As the cpu is only cooled passively in these devices, it's temperature rising will indicate the temperature level of the system just earlier. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20241107114712.538976-9-heiko@sntech.de
2025-01-03arm64: dts: rockchip: Fix sdmmc access on rk3308-rock-s0 v1.1 boardsJonas Karlman
BootROM leave GPIO4_D6 configured as SDMMC_PWREN function and DW MCI driver set PRWEN high on MMC_POWER_UP and low on MMC_POWER_OFF. Similarly U-Boot also set PRWEN high before accessing mmc. However, HW revision prior to v1.2 must pull GPIO4_D6 low to access sdmmc. For HW revision v1.2 the state of GPIO4_D6 has no impact. Model an always-on active low fixed regulator using GPIO4_D6 to fix use of sdmmc on older HW revisions of the board. Fixes: adeb5d2a4ba4 ("arm64: dts: rockchip: Add Radxa ROCK S0") Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Link: https://lore.kernel.org/r/20241119230838.4137130-1-jonas@kwiboo.se Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-01-03driver core: Constify API device_find_child() and adapt for various usagesZijun Hu
Constify the following API: struct device *device_find_child(struct device *dev, void *data, int (*match)(struct device *dev, void *data)); To : struct device *device_find_child(struct device *dev, const void *data, device_match_t match); typedef int (*device_match_t)(struct device *dev, const void *data); with the following reasons: - Protect caller's match data @*data which is for comparison and lookup and the API does not actually need to modify @*data. - Make the API's parameters (@match)() and @data have the same type as all of other device finding APIs (bus|class|driver)_find_device(). - All kinds of existing device match functions can be directly taken as the API's argument, they were exported by driver core. Constify the API and adapt for various existing usages. BTW, various subsystem changes are squashed into this commit to meet 'git bisect' requirement, and this commit has the minimal and simplest changes to complement squashing shortcoming, and that may bring extra code improvement. Reviewed-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Acked-by: Uwe Kleine-König <ukleinek@kernel.org> # for drivers/pwm Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20241224-const_dfc_done-v5-4-6623037414d4@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-01-03s390/qdio: Rename feature flag aif_osa to aif_qdioBenjamin Block
This feature is not only utilized by OSA, but by QDIO in general. Clear up possible confusions. Signed-off-by: Benjamin Block <bblock@linux.ibm.com> Reviewed-by: Steffen Maier <maier@linux.ibm.com> Acked-by: Alexandra Winter <wintera@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2025-01-02KVM: arm64: Work around x1e's CNTVOFF_EL2 bogosityMarc Zyngier
It appears that on Qualcomm's x1e CPU, CNTVOFF_EL2 doesn't really work, specially with HCR_EL2.E2H=1. A non-zero offset results in a screaming virtual timer interrupt, to the tune of a few 100k interrupts per second on a 4 vcpu VM. This is also evidenced by this CPU's inability to correctly run any of the timer selftests. The only case this doesn't break is when this register is set to 0, which breaks VM migration. When HCR_EL2.E2H=0, the timer seems to behave normally, and does not result in an interrupt storm. As a workaround, use the fact that this CPU implements FEAT_ECV, and trap all accesses to the virtual timer and counter, keeping CNTVOFF_EL2 set to zero, and emulate accesses to CVAL/TVAL/CTL and the counter itself, fixing up the timer to account for the missing offset. And if you think this is disgusting, you'd probably be right. Acked-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20241217142321.763801-12-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-01-02KVM: arm64: nv: Sanitise CNTHCTL_EL2Marc Zyngier
Inject some sanity in CNTHCTL_EL2, ensuring that we don't handle more than we advertise to the guest. Acked-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20241217142321.763801-11-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-01-02KVM: arm64: nv: Propagate CNTHCTL_EL2.EL1NV{P,V}CT bitsMarc Zyngier
Allow a guest hypervisor to trap accesses to CNT{P,V}CT_EL02 by propagating these trap bits to the host trap configuration. Acked-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20241217142321.763801-10-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-01-02KVM: arm64: nv: Add trap routing for CNTHCTL_EL2.EL1{NVPCT,NVVCT,TVT,TVCT}Marc Zyngier
For completeness, fun, and cerebral meltdown, add the virtualisation related traps to the counter and timers. Acked-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20241217142321.763801-9-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-01-02KVM: arm64: Handle counter access early in non-HYP contextMarc Zyngier
We already deal with CNTPCT_EL0 accesses in non-HYP context. Let's add CNTVCT_EL0 as a good measure. This is also an opportunity to simplify things and make it plain that this code is only for non-HYP context handling. Acked-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20241217142321.763801-8-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-01-02KVM: arm64: nv: Accelerate EL0 counter accesses from hypervisor contextMarc Zyngier
Similarly to handling the physical timer accesses early when FEAT_ECV causes a trap, we try to handle the physical counter without returning to the general sysreg handling. More surprisingly, we introduce something similar for the virtual counter. Although this isn't necessary yet, it will prove useful on systems that have a broken CNTVOFF_EL2 implementation. Yes, they exist. Acked-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20241217142321.763801-7-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-01-02KVM: arm64: nv: Accelerate EL0 timer read accesses when FEAT_ECV in useMarc Zyngier
Although FEAT_ECV allows us to correctly emulate the timers, it also reduces performances pretty badly. Mitigate this by emulating the CTL/CVAL register reads in the inner run loop, without returning to the general kernel. Acked-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20241217142321.763801-6-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-01-02KVM: arm64: nv: Use FEAT_ECV to trap access to EL0 timersMarc Zyngier
Although FEAT_NV2 makes most things fast, it also makes it impossible to correctly emulate the timers, as the sysreg accesses are redirected to memory. FEAT_ECV addresses this by giving a hypervisor the ability to trap the EL02 sysregs as well as the virtual timer. Add the required trap setting to make use of the feature, allowing us to elide the ugly resync in the middle of the run loop. Acked-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20241217142321.763801-5-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-01-02KVM: arm64: nv: Publish emulated timer interrupt state in the in-memory stateMarc Zyngier
With FEAT_NV2, the EL0 timer state is entirely stored in memory, meaning that the hypervisor can only provide a very poor emulation. The only thing we can really do is to publish the interrupt state in the guest view of CNT{P,V}_CTL_EL0, and defer everything else to the next exit. Only FEAT_ECV will allow us to fix it, at the cost of extra trapping. Suggested-by: Chase Conklin <chase.conklin@arm.com> Suggested-by: Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com> Acked-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20241217142321.763801-4-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-01-02KVM: arm64: nv: Sync nested timer state with FEAT_NV2Marc Zyngier
Emulating the timers with FEAT_NV2 is a bit odd, as the timers can be reconfigured behind our back without the hypervisor even noticing. In the VHE case, that's an actual regression in the architecture... Co-developed-by: Christoffer Dall <christoffer.dall@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@arm.com> Acked-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20241217142321.763801-3-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-01-02KVM: arm64: nv: Add handling of EL2-specific timer registersMarc Zyngier
Add the required handling for EL2 and EL02 registers, as well as EL1 registers used in the E2H context. This includes handling the virtual timer accesses when CNTHCTL_EL2.EL1TVT or CNTHCTL_EL2.EL1TVCT are set. Acked-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20241217142321.763801-2-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-01-02arm64: dts: ti: k3-j7200: Add node to disable loopback connectionAnurag Dutta
CTRLMMR_MCU_SPI1_CTRL register controls if MCU_SPI1 is directly connected to SPI3 in the MAIN Domain (default) or if MCU_SPI1 and SPI3 are independently pinned out. By default, the field SPI1_LINKDIS (Bit 0) is set to 0h. In order to disable the direct connection, the SPI1_LINKDIS (Bit 0) needs to be set to 1h. Model this functionality as a "reg-mux" device and based on the idle-state property, enable/disable the connection bewtween MCU_SPI1 and MAIN_SPI3. The register field description has been referred from J7200 TRM [1] (Table 5-517. CTRLMMR_MCU_SPI1_CTRL Register Field Descriptions). [1] https://www.ti.com/lit/pdf/spruiu1 Signed-off-by: Anurag Dutta <a-dutta@ti.com> Link: https://lore.kernel.org/r/20241127075644.210759-1-a-dutta@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-01-02arm64: dts: ti: k3-j784s4: Use ti,j7200-padconf compatibleThomas Richard
Like on j7200, pinctrl contexts shall be saved and restored during suspend-to-ram. So use ti,j7200-padconf compatible. Signed-off-by: Thomas Richard <thomas.richard@bootlin.com> Link: https://lore.kernel.org/r/20241230-j784s4-s2r-pinctrl-v2-1-35039fafe2ca@bootlin.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-01-02arm64: dts: ti: k3-am62p-j722s-common-main: Enable USB0 for DFU bootSiddharth Vadapalli
Add the "bootph-all" property to the "usb0" device-tree node. This is required for the USB0 instance of USB to be functional at all stages of USB DFU boot. Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Reviewed-by: Roger Quadros <rogerq@kernel.org> Link: https://lore.kernel.org/r/20241220054550.153360-1-s-vadapalli@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-01-02arm64: dts: ti: k3-am62a: Remove duplicate GICR regBryan Brattlof
The GIC Redistributor control range is mapped twice. Remove the extra entry from the reg range. Fixes: 5fc6b1b62639 ("arm64: dts: ti: Introduce AM62A7 family of SoCs") Reported-by: Bin Liu <b-liu@ti.com> Signed-off-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20241210-am62-gic-fixup-v1-2-758b4d5b4a0a@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-01-02arm64: dts: ti: k3-am62: Remove duplicate GICR regBryan Brattlof
The GIC Redistributor control register range is mapped twice. Remove the extra entry from the reg range. Fixes: f1d17330a5be ("arm64: dts: ti: Introduce base support for AM62x SoC") Reported-by: Bin Liu <b-liu@ti.com> Signed-off-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20241210-am62-gic-fixup-v1-1-758b4d5b4a0a@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-01-02x86/static-call: Remove early_boot_irqs_disabled check to fix Xen PVH dom0Andrew Cooper
__static_call_update_early() has a check for early_boot_irqs_disabled, but is used before early_boot_irqs_disabled is set up in start_kernel(). Xen PV has always special cased early_boot_irqs_disabled, but Xen PVH does not and falls over the BUG when booting as dom0. It is very suspect that early_boot_irqs_disabled starts as 0, becomes 1 for a time, then becomes 0 again, but as this needs backporting to fix a breakage in a security fix, dropping the BUG_ON() is the far safer option. Fixes: 0ef8047b737d ("x86/static-call: provide a way to do very early static-call updates") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219620 Reported-by: Alex Zenla <alex@edera.dev> Suggested-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Juergen Gross <jgross@suse.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Alex Zenla <alex@edera.dev> Link: https://lore.kernel.org/r/20241221211046.6475-1-andrew.cooper3@citrix.com
2025-01-02arm64: dts: ti: k3-am67a-beagley-ai: Add remote processor nodesAndrew Davis
Add nodes for the R5F and C7x cores on the SoC. This includes the mailbox and memory carveouts used by these remote cores. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20241203174114.94751-2-afd@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-01-02arm64: dts: ti: k3-am62p: Enable Mailbox nodes at the board levelAndrew Davis
Mailbox nodes defined in the top-level J722s/AM62p SoC dtsi files are incomplete and may not be functional unless they are extended with a chosen interrupt and connection to a remote processor. Disable the Mailbox nodes in the dtsi files and only enable the ones that are actually used on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20241203174114.94751-1-afd@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-01-02arm64: dts: ti: k3-am625-sk: Remove M4 mailbox node redefinitionAndrew Davis
This node is already defined in the included k3-am62x-sk-common.dtsi. Remove this redefinition. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20241203164031.20211-1-afd@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-01-02arm64: dts: ti: k3-j722s-evm: Enable support for mcu_i2c0Bhavya Kapoor
Enable support for mcu_i2c0 and add pinmux required to bring out the mcu_i2c0 signals on 40-pin RPi expansion header on the J722S EVM. Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com> Signed-off-by: Shreyash Sinha <s-sinha@ti.com> Reviewed-by: Prasanth Babu Mantena <p-mantena@ti.com> Link: https://lore.kernel.org/r/20241105091224.23453-1-b-kapoor@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-01-02arm64: dts: ti: k3-am62x-sk-common: Add bootph-all property in ↵Chintan Vankar
cpsw_mac_syscon node Ethernet boot requires CPSW node to be present starting from R5 SPL stage. Add bootph-all property in CPSW MAC's eFuse node cpsw_mac_syscon to enable this node during SPL stage along with later boot stages so that CPSW port will get static MAC address. Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com> Signed-off-by: Chintan Vankar <c-vankar@ti.com> Link: https://lore.kernel.org/r/20241114165331.1279065-1-c-vankar@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-01-02x86/sev: Disable UBSAN on SEV code that may execute very earlyArd Biesheuvel
Clang 14 and older may emit UBSAN instrumentation into code that is inlined into functions marked with __no_sanitize_undefined¹. This may result in faults when the code is executed very early, which may be the case for functions annotated as __head. Now that this requirement is strictly enforced, the build will fail in this case with the following message Absolute reference to symbol '.data' not permitted in .head.text Work around this by disabling UBSAN instrumentation on all SEV core code. ¹ https://lore.kernel.org/r/20250101024348.GA1828419@ax162 [ bp: Add a footnote with Nathan's detailed explanation and a Fixes tag ] Fixes: 3b6f99a94b04 ("x86/boot: Disable UBSAN in early boot code") Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20250101115119.114584-2-ardb@kernel.org
2025-01-02ARM: dts: microchip: sam9x7: Add address/size to spi-controller nodesMihai Sain
Since these properties are common for all spi subnodes, add them to SoC dtsi instead of board dts. Signed-off-by: Mihai Sain <mihai.sain@microchip.com> Link: https://lore.kernel.org/r/20241218080333.2225-3-mihai.sain@microchip.com Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
2025-01-02ARM: dts: microchip: sam9x60: Add address/size to spi-controller nodesMihai Sain
Since these properties are common for all spi subnodes, add them to SoC dtsi instead of board dts. Signed-off-by: Mihai Sain <mihai.sain@microchip.com> Link: https://lore.kernel.org/r/20241218080333.2225-2-mihai.sain@microchip.com Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
2025-01-02ARM: dts: microchip: sama5d27_wlsom1_ek: Add no-1-8-v property to sdmmc0 nodeCristian Birsan
Add no-1-8-v property to sdmmc0 node to keep VDDSDMMC power rail at 3.3V. This property will stop the LDO regulator from switching to 1.8V when the MMC core detects an UHS SD Card. VDDSDMMC power rail is used by all the SDMMC interface pins in GPIO mode (PA0 - PA13). On this board, PA10 is used as GPIO to enable the power switch controlling USB Vbus for the USB Host. The change is needed to fix the PA10 voltage level to 3.3V instead of 1.8V. Fixes: 5d4c3cfb63fe ("ARM: dts: at91: sama5d27_wlsom1: add SAMA5D27 wlsom1 and wlsom1-ek") Suggested-by: Mihai Sain <mihai.sain@microchip.com> Signed-off-by: Cristian Birsan <cristian.birsan@microchip.com> Tested-by: Andrei Simion <andrei.simion@microchip.com> Link: https://lore.kernel.org/r/20241119160107.598411-3-cristian.birsan@microchip.com Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
2025-01-02ARM: dts: microchip: sama5d29_curiosity: Add no-1-8-v property to sdmmc0 nodeCristian Birsan
Add no-1-8-v property to sdmmc0 node to keep VDDSDMMC power rail at 3.3V. This property will stop the LDO regulator from switching to 1.8V when the MMC core detects an UHS SD Card. VDDSDMMC power rail is used by all the SDMMC interface pins in GPIO mode (PA0 - PA13). On this board, PA6 is used as GPIO to enable the power switch controlling USB Vbus for the USB Host. The change is needed to fix the PA6 voltage level to 3.3V instead of 1.8V. Fixes: d85c4229e925 ("ARM: dts: at91: sama5d29_curiosity: Add device tree for sama5d29_curiosity board") Suggested-by: Mihai Sain <mihai.sain@microchip.com> Signed-off-by: Cristian Birsan <cristian.birsan@microchip.com> Tested-by: Andrei Simion <andrei.simion@microchip.com> Link: https://lore.kernel.org/r/20241119160107.598411-2-cristian.birsan@microchip.com Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
generated by cgit (git 2.34.1) at 2025-09-19 07:49:23 +0000