| Age | Commit message (Collapse) | Author |
|---|
|
arch/arm/crypto/ghash-ce-core.S implements pmull_ghash_update_p8(),
which is used only by a crypto_shash implementation of GHASH. It also
implements other functions, including pmull_ghash_update_p64() and
others, which are used only by a crypto_aead implementation of AES-GCM.
While some code is shared between pmull_ghash_update_p8() and
pmull_ghash_update_p64(), it's not very much. Since
pmull_ghash_update_p8() will also need to be migrated into lib/crypto/
to achieve parity in the standalone GHASH support, let's move it into a
separate file ghash-neon-core.S.
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20260319061723.1140720-7-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
arch/arm/crypto/ghash-ce-glue.c originally provided only a "ghash"
crypto_shash algorithm using PMULL if available, else NEON.
Significantly later, it was updated to also provide a full AES-GCM
implementation using PMULL.
This made the PMULL support in the "ghash" crypto_shash largely
obsolete. Indeed, the arm64 equivalent of this file unconditionally
uses only ASIMD in its "ghash" crypto_shash.
Given that inconsistency and the fact that the NEON-only code is more
easily separable into the GHASH library than the PMULL based code is,
let's align with arm64 and just support NEON-only for the pure GHASH.
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20260319061723.1140720-6-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
The Gameforce Ace's joystick axes were set incorrectly initially,
getting the X/Y and RX/RY axes backwards. Additionally, correct the
RY axis so that it is inverted.
All axes tested with evtest and outputting correct values.
Fixes: 4e946c447a04 ("arm64: dts: rockchip: Add GameForce Ace")
Reported-by: sydarn <sydarn@proton.me>
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Link: https://patch.msgid.link/20260310134919.550023-1-macroalpha82@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Correct the regulator providing power to the PWM controlled fan.
Without this fix the fan only runs when the audio path is playing
audio (because the speaker amplifier and PWM fan share the same
regulator).
Fixes: 4e946c447a04 ("arm64: dts: rockchip: Add GameForce Ace")
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Link: https://patch.msgid.link/20260310134648.550006-1-macroalpha82@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
This reverts commit bdc4d388c6452498ab62ef2564589f40e0c8c262.
While Beelink A1 mostly follows the high-end RK3328 reference design,
it does not in fact have the S/PDIF connector, only HDMI and a 3.5mm
jack for the analog audio/TV codecs - the tiny form factor literally
doesn't have room to fit more!
Cc: Christian Hewitt <christianshewitt@gmail.com>
Cc: Alex Bee <knaerzche@gmail.com>
Fixes: bdc4d388c645 ("arm64: dts: rockchip: add SPDIF audio to Beelink A1")
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Link: https://patch.msgid.link/0af77a02c2b0806d4ca72066392a5453fcc89a8f.1767111968.git.robin.murphy@arm.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The AP6212 WiFi/BT module on the LCKFB TaiShan Pi (RK3566) is prone to
communication timeouts and reset failures (error -110) when operating at
3 Mbps.
This patch stabilizes the Bluetooth interface by:
1. Updating the compatible string to 'brcm,bcm43430a1-bt' to better reflect
the actual chip revision used in the AP6212 module.
2. Lowering the maximum UART baud rate from 3,000,000 to 1,500,000 bps.
Tests show that 1.5 Mbps is the reliable upper limit for this board's
UART configuration, eliminating the initialization timeouts.
Fixes: 251e5ade9ba4 ("arm64: dts: rockchip: add dts for LCKFB Taishan Pi RK3566")
Signed-off-by: Ming Wang <wangming5719@gmail.com>
Link: https://patch.msgid.link/20260206090453.1041919-1-wming126@126.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
According to nxp,pca953x.yaml, the pattern for the led names should be:
"^led-[0-9a-z]+$".
Change it accordingly to fix the following dt-schema warning"
leddimmer@62 (nxp,pca9533): 'led1', 'led2', 'led3', 'led4' do not match any
of the regexes: '^led-[0-9a-z]+$', '^pinctrl-[0-9]+$'
Signed-off-by: Fabio Estevam <festevam@nabladev.com>
Link: https://patch.msgid.link/20260311135604.21634-1-festevam@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
According to rockchip-dwmac.yaml, the mdio node should be 'mdio0' and
'wakeup-source' is not a valid property.
Change it accordingly.
This fixes the following dt-schema warning:
Unevaluated properties are not allowed ('mdio0', 'wakeup-source'\
were unexpected)
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://patch.msgid.link/20260303193855.828892-3-festevam@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Node names should be generic, so use 'rtc'.
Remove 'clock-frequency' as is not a valid property.
This fixes the following dt-schema warnings:
'hym8563@51' does not match '^rtc(@.*|-([0-9]|[1-9][0-9]+))?$'
Unevaluated properties are not allowed ('clock-frequency' was unexpected)
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://patch.msgid.link/20260303193855.828892-2-festevam@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
According to the phyCORE - RK3288 Hardware Manual, GPIO5_B4 corresponds to
the touchscreen interrupt line:
https://www.phytec.eu/fileadmin/legacy/downloads/Manuals/L-826e_1.pdf
Describe it to improve the devicetree representation.
This fixes the following dt-schema warning:
'interrupts' is a required property
'interrupts-extended' is a required property
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://patch.msgid.link/20260303193855.828892-1-festevam@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
According to hid-over-i2c.yaml, the correct name for the 3.3V supply
is 'vdd-supply'.
Fix it accordingly.
This fixes the following dt-schema warning:
'vcc-supply' does not match any of the regexes: '^pinctrl-[0-9]+$'
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Reviewed-by: Charalampos Mitrodimas <charmitro@posteo.net>
Link: https://patch.msgid.link/20260304164448.1024410-1-festevam@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Node names should be generic, so use 'bluetooth' as the node name.
This fixes the following dt-schema warning:
'btmrvl@2' does not match '^bluetooth(@.*)?$'
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://patch.msgid.link/20260226144842.2727107-2-festevam@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The 'regulator-suspend-mem-disabled' property is not documented nor used
anywhere.
Remove this invalid property.
This fixes the following dt-schema warning:
('regulator-suspend-mem-disabled' was unexpected)
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://patch.msgid.link/20260226144842.2727107-1-festevam@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
'rotation-matrix' is not a valid property.
Use the documented 'mount-matrix' property instead.
This fixes the following dt-schema warning:
accelerometer@29 (st,lis3de): 'rotation-matrix' does not match any of the
regexes: '^pinctrl-[0-9]+$'
accelerometer@29 (st,lis3de): rotation-matrix:
b'1\x000\x000\x000\x00-1\x000\x000\x000\x001\x00' is not of type 'object',
'integer', 'array', 'boolean', 'null'
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://patch.msgid.link/20260226145916.2729492-1-festevam@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
According to st,m41t80.yaml, the correct compatible for the RV4162 RTC
is "microcrystal,rv4162".
Fix it accordingly.
This fixes the following dt-schema warning:
rtc@68: failed to match any schema with compatible: ['rv4162']
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://patch.msgid.link/20260301124156.473862-1-festevam@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
According to rockchip,emac.yaml, 'phy-reset-duration' and 'phy-reset-gpios'
are not valid properties.
Use the valid 'reset-gpios' and 'reset-assert-us' properties under
the etherne-phy node.
This fixes the following dt-schema warning:
Unevaluated properties are not allowed ('phy-reset-duration',
'phy-reset-gpios' were unexpected)
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://patch.msgid.link/20260228013257.256973-1-festevam@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
According to rockchip-thermal.yaml, RK3288 does not require rockchip,grf,
so remove this invalid property.
This fixes the following dt-schema warning:
tsadc@ff280000 (rockchip,rk3288-tsadc): False schema does not allow [[53]]
The rockchip_thermal driver also confirms that grf is not needed as
the rk3288_tsadc_data contains:
.grf_required = false,
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://patch.msgid.link/20260228013257.256973-2-festevam@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The 'leading' helper returns BITS_PER_LONG if x == 0, while 'trailing'
one returns COUNT_TRAILING_ZEROS_0, which turns to be -1.
None of the current users explicitly check the returned value for
COUNT_TRAILING_ZEROS_0, except the loongarch, which tests implicitly
for the '>= 0'.
So, align count_trailing_zeros() with the count_leading_zeros(), and
simplify the loongarch handling.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Yury Norov <ynorov@nvidia.com>
|
|
Switch topo_unit_count() to use bitmap_weight_from().
Signed-off-by: Yury Norov <ynorov@nvidia.com>
|
|
Lontium LT8713sx DP bridge hub can be found on a Qualcomm
Monaco EVK board for converting 1 DP to 3 DP outputs.
Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260319-lt8713sx-bridge-linux-for-next-v4-2-da886ec78fe3@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Enable the driver for Qualcomm Eliza SoC display clock controller, used
for example on Qualcomm Eliza MTP board.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260319-clk-qcom-dispcc-eliza-v3-3-d1f2b19a6e6b@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Enable GCC, Pinctrl for Qualcomm's IPQ5210 SoC which is required to boot
ipq5210-rdp504 board to a console shell.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260318-ipq5210_boot_to_shell-v2-6-a87e27c37070@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Build the LPASS LPI pinctrl driver as module, as required by devices
using the Qualcomm Milos SoC.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Link: https://lore.kernel.org/r/20260306-milos-pinctrl-lpi-v1-3-086946dbb855@fairphone.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Enable the Kaanapali display, video, camera and gpu clock controller
for their respective functionalities on the Qualcomm Kaanapali QRD and
MTP boards.
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260224-knp-dts-misc-v6-10-79d20dab8a60@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Merge the two separate switch cases for AMD and Hygon as they share the
common cpu_parse_topology_amd().
Also drop the IS_ENABLED(CONFIG_CPU_SUP_AMD/HYGON) guards, because
1) they are dead code: when a vendor's CONFIG_CPU_SUP_* is disabled, its
vendor detection code (in amd.c / hygon.c) is not compiled, so
x86_vendor will never be set to X86_VENDOR_AMD / X86_VENDOR_HYGON,
instead it will default to X86_VENDOR_UNKNOWN and those switch cases
are unreachable.
2) topology_amd.o is always built (obj-y), so cpu_parse_topology_amd() is
always available regardless of CPU_SUP_* configuration.
Signed-off-by: Wei Wang <wei.w.wang@hotmail.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Tested-by: Yongwei Xu <xuyongwei@open-hieco.net>
Link: https://patch.msgid.link/SI2PR01MB4393D6B7E17AB05612AEE925DC4BA@SI2PR01MB4393.apcprd01.prod.exchangelabs.com
|
|
nodes
The 'marvell,usb-misc-reg' property is present both in the EHCI and
in the XHCI USB host device nodes, however it is not documented. Thus
'make dtbs_check' produces warnings like these:
/arch/arm64/boot/dts/marvell/armada-3720-db.dtb: usb@58000 (marvell,armada3700-xhci): Unevaluated properties are not allowed ('marvell,usb-misc-reg' was unexpected)
from schema $id: http://devicetree.org/schemas/usb/generic-xhci.yaml
/arch/arm64/boot/dts/marvell/armada-3720-db.dtb: usb@5e000 (marvell,armada-3700-ehci): Unevaluated properties are not allowed ('marvell,usb-misc-reg' was unexpected)
from schema $id: http://devicetree.org/schemas/usb/generic-ehci.yaml
Apart from the fact that the properties are not documented, those are
not even used by any USB host drivers. Due to this, drop the properties
in order to get rid of the warnings.
Note:
With the same name, there is a property used for the Armada 3700 USB
UTMI PHYs of which dt-bindings documentation has been added in commit
e60958699afa ("dt-bindings: phy: mvebu-utmi: add UTMI PHY bindings").
Additionally, the property is handled by the 'phy-mvebu-a3700-utmi'
driver since commit cc8b7a0ae866 ("phy: add A3700 UTMI PHY driver").
When the nodes of the UTMI PHYs has been added to the SoC dtsi by
commit 05d168a56fae ("arm64: dts: marvell: armada-37xx: declare USB2
UTMI PHYs"), the properties has been added to the USB host controller
nodes also. According to the commit message this was unintentional,
however in regard to the USB hosts, neither the respective documentation,
nor driver support has been added into the tree since that.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
|
|
To avoid future confusion on the purpose and design of the CRn pinning code.
Also note that if the attacker controls page-tables, the CRn bits lose much of
the attraction anyway.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20260320092521.GG3739106@noisy.programming.kicks-ass.net
|
|
FRED-enabled SEV-(ES,SNP) guests fail to boot due to the following issues
in the early boot sequence:
* FRED does not have a #VC exception handler in the dispatch logic
* Early FRED #VC exceptions attempt to use uninitialized per-CPU GHCBs
instead of boot_ghcb
Add X86_TRAP_VC case to fred_hwexc() with a new exc_vmm_communication()
function that provides the unified entry point FRED requires, dispatching
to existing user/kernel handlers based on privilege level. The function is
already declared via DECLARE_IDTENTRY_VC().
Fix early GHCB access by falling back to boot_ghcb in
__sev_{get,put}_ghcb() when per-CPU GHCBs are not yet initialized.
Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code")
Signed-off-by: Nikunj A Dadhania <nikunj@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Cc: <stable@kernel.org> # 6.12+
Link: https://patch.msgid.link/20260318075654.1792916-4-nikunj@amd.com
|
|
Commit in Fixes added the FRED CR4 bit to the CR4 pinned bits mask so
that whenever something else modifies CR4, that bit remains set. Which
in itself is a perfectly fine idea.
However, there's an issue when during boot FRED is initialized: first on
the BSP and later on the APs. Thus, there's a window in time when
exceptions cannot be handled.
This becomes particularly nasty when running as SEV-{ES,SNP} or TDX
guests which, when they manage to trigger exceptions during that short
window described above, triple fault due to FRED MSRs not being set up
yet.
See Link tag below for a much more detailed explanation of the
situation.
So, as a result, the commit in that Link URL tried to address this
shortcoming by temporarily disabling CR4 pinning when an AP is not
online yet.
However, that is a problem in itself because in this case, an attack on
the kernel needs to only modify the online bit - a single bit in RW
memory - and then disable CR4 pinning and then disable SM*P, leading to
more and worse things to happen to the system.
So, instead, remove the FRED bit from the CR4 pinning mask, thus
obviating the need to temporarily disable CR4 pinning.
If someone manages to disable FRED when poking at CR4, then
idt_invalidate() would make sure the system would crash'n'burn on the
first exception triggered, which is a much better outcome security-wise.
Fixes: ff45746fbf00 ("x86/cpu: Add X86_CR4_FRED macro")
Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Cc: <stable@kernel.org> # 6.12+
Link: https://lore.kernel.org/r/177385987098.1647592.3381141860481415647.tip-bot2@tip-bot2
|
|
Move FSGSBASE enablement from identify_cpu() to cpu_init_exception_handling()
to ensure it is enabled before any exceptions can occur on both boot and
secondary CPUs.
== Background ==
Exception entry code (paranoid_entry()) uses ALTERNATIVE patching based on
X86_FEATURE_FSGSBASE to decide whether to use RDGSBASE/WRGSBASE instructions
or the slower RDMSR/SWAPGS sequence for saving/restoring GSBASE.
On boot CPU, ALTERNATIVE patching happens after enabling FSGSBASE in CR4.
When the feature is available, the code is permanently patched to use
RDGSBASE/WRGSBASE, which require CR4.FSGSBASE=1 to execute without triggering
== Boot Sequence ==
Boot CPU (with CR pinning enabled):
trap_init()
cpu_init() <- Uses unpatched code (RDMSR/SWAPGS)
x2apic_setup()
...
arch_cpu_finalize_init()
identify_boot_cpu()
identify_cpu()
cr4_set_bits(X86_CR4_FSGSBASE) # Enables the feature
# This becomes part of cr4_pinned_bits
...
alternative_instructions() <- Patches code to use RDGSBASE/WRGSBASE
Secondary CPUs (with CR pinning enabled):
start_secondary()
cr4_init() <- Code already patched, CR4.FSGSBASE=1
set implicitly via cr4_pinned_bits
cpu_init() <- exceptions work because FSGSBASE is
already enabled
Secondary CPU (with CR pinning disabled):
start_secondary()
cr4_init() <- Code already patched, CR4.FSGSBASE=0
cpu_init()
x2apic_setup()
rdmsrq(MSR_IA32_APICBASE) <- Triggers #VC in SNP guests
exc_vmm_communication()
paranoid_entry() <- Uses RDGSBASE with CR4.FSGSBASE=0
(patched code)
...
ap_starting()
identify_secondary_cpu()
identify_cpu()
cr4_set_bits(X86_CR4_FSGSBASE) <- Enables the feature, which is
too late
== CR Pinning ==
Currently, for secondary CPUs, CR4.FSGSBASE is set implicitly through
CR-pinning: the boot CPU sets it during identify_cpu(), it becomes part of
cr4_pinned_bits, and cr4_init() applies those pinned bits to secondary CPUs.
This works but creates an undocumented dependency between cr4_init() and the
pinning mechanism.
== Problem ==
Secondary CPUs boot after alternatives have been applied globally. They
execute already-patched paranoid_entry() code that uses RDGSBASE/WRGSBASE
instructions, which require CR4.FSGSBASE=1. Upcoming changes to CR pinning
behavior will break the implicit dependency, causing secondary CPUs to
generate #UD.
This issue manifests itself on AMD SEV-SNP guests, where the rdmsrq() in
x2apic_setup() triggers a #VC exception early during cpu_init(). The #VC
handler (exc_vmm_communication()) executes the patched paranoid_entry() path.
Without CR4.FSGSBASE enabled, RDGSBASE instructions trigger #UD.
== Fix ==
Enable FSGSBASE explicitly in cpu_init_exception_handling() before loading
exception handlers. This makes the dependency explicit and ensures both
boot and secondary CPUs have FSGSBASE enabled before paranoid_entry()
executes.
Fixes: c82965f9e530 ("x86/entry/64: Handle FSGSBASE enabled paranoid entry/exit")
Reported-by: Borislav Petkov <bp@alien8.de>
Suggested-by: Sohil Mehta <sohil.mehta@intel.com>
Signed-off-by: Nikunj A Dadhania <nikunj@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Sohil Mehta <sohil.mehta@intel.com>
Cc: <stable@kernel.org>
Link: https://patch.msgid.link/20260318075654.1792916-2-nikunj@amd.com
|
|
The "small" argument to do_sys_ftruncate indicates if > 32-bit size
should be reject, but all the arch-specific compat ftruncate64
implementations get this wrong. Merge do_sys_ftruncate and
ksys_ftruncate, replace the integer as boolean small flag with a
descriptive one about LFS semantics, and use it correctly in the
architecture-specific ftruncate64 implementations.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Fixes: 3dd681d944f6 ("arm64: 32-bit (compat) applications support")
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://patch.msgid.link/20260323070205.2939118-2-hch@lst.de
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
|
|
The msr_hcr_el2 macro is slightly awkward, as it provides an ISB
when CONFIG_AMPERE_ERRATUM_AC04_CPU_23 is present, and none
otherwise. Note that this this option is 'default y', meaning that
it is likely to be selected.
Most instances of msr_hcr_el2 are also immediately followed by an ISB,
meaning that in most cases, you end-up with two back-to-back ISBs.
This isn't a big deal, but once you have seen that, you can't unsee it.
Rework the msr_hcr_el2 macro to always provide the ISB, and drop
the superfluous ISBs everywhere else.
Reviewed-by: Fuad Tabba <tabba@google.com>
Tested-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260321212419.2803972-6-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
Instead of using a boolean to decide whether a CPU is booting or
resuming, just pass an actual function pointer around.
This makes the code a bit more straightforward to understand.
Reviewed-by: Fuad Tabba <tabba@google.com>
Tested-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260321212419.2803972-5-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
__kvm_hyp_init_cpu really is an internal label for kvm_hyp_cpu_entry
and kvm_hyp_cpu_resume.
Make it clear that this is what it is, and drop a pointless branch
in kvm_hyp_cpu_resume.
Reviewed-by: Fuad Tabba <tabba@google.com>
Tested-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260321212419.2803972-4-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
In order to perform an indirect branch to kvm_host_psci_cpu_entry()
on a BTI-aware system, we first branch to a 'BTI j' landing pad,
and from there branch again to the target.
While this works, this is really not required:
- BLR works with 'BTI c' and 'PACIASP' as the landing pad
- Even if LR gets clobbered by BLR, we are going to restore the
host's registers, so it is pointless to try and avoid touching
LR
Given the above, drop the veneer and directly call into C code.
If we were to come back from it, we'd directly enter the error
handler.
Reviewed-by: Fuad Tabba <tabba@google.com>
Tested-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260321212419.2803972-3-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
We currently handle CPUs having booted at EL1 in the middle of
the kvm_hyp_cpu_entry function. Not only this adversely affects
readability, but this is also at a bizarre spot should more
error handling be added (which we're about to do).
Move the WFE/WFI loop to the end of the function and fix a comment.
Reviewed-by: Fuad Tabba <tabba@google.com>
Tested-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260321212419.2803972-2-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
The pioB controller on the SAM9X7 SoC actually supports 27 GPIO lines.
The previous value of 26 was incorrect, leading to the last pin being
unavailable for use by the GPIO subsystem.
Update the #gpio-lines property to reflect
the correct hardware specification.
Fixes: 41af45af8bc3 ("ARM: dts: at91: sam9x7: add device tree for SoC")
Signed-off-by: Mihai Sain <mihai.sain@microchip.com>
Link: https://lore.kernel.org/r/20260209090735.2016-1-mihai.sain@microchip.com
Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
|
|
Add missing device tree node for main_i2c4, and the corresponding ranges
in cbass_main. Interrupt for this i2c controller is routed through the
Main GPIOMUX Router.
Base address, Interrupt IDs are taken from J722S TRM [0].
Device, Clock IDs are taken from TISCI docs [1].
Additionally, the I2C4 is the only interrupt source to the GPIOMUX INTR
router that generates level interrupts, while all other sources generate
edge interrupts. Due to this, the router needs to handle interrupt-type
on a per-line basis. Modify the router node and its consumers to
specify the interrupt type corresponding to each interrupt line.
[0]: https://www.ti.com/lit/zip/sprujb3
[1]:
https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/index.html#j722s
Signed-off-by: Jared McArthur <j-mcarthur@ti.com>
Signed-off-by: Aniket Limaye <a-limaye@ti.com>
Tested-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
Link: https://patch.msgid.link/20260304-j722s-main-i2c4-dt-v1-1-03f79f0cdf97@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
Exposing shadow page tables in debugfs improves the debugability and
testability of NV. With this patch a new directory "nested" is created
for each VM created if the host is NV capable. Within the directory each
valid s2 mmu will have its shadow page table exposed as a readable file
with the file name formatted as 0x<vttbr>-0x<vtcr>-s2-{en,dis}abled. The
creation and removal of the files happen at the points when an s2 mmu
becomes valid, or the context it represents change. In the future the
"nested" directory can also hold other NV related information.
This is gated behind CONFIG_PTDUMP_STAGE2_DEBUGFS.
Suggested-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Sebastian Ene <sebastianene@google.com>
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Link: https://patch.msgid.link/20260317182638.1592507-3-weilin.chang@arm.com
[maz: minor refactor, full 16 chars addresses]
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
The Corstone-1000-a320 is a Corstone-1000 derivative with Cortex-A320 cores,
GIC-600, and Ethos-U85 NPU.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Message-Id: <20260320-dt-corstone1000-a320-v1-5-a549dfcfe8da@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
|
|
The FVPs have a common set of peripherals specific to the FVP. Move
these to a separate .dtsi so they can be shared across FVP platforms.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Message-Id: <20260320-dt-corstone1000-a320-v1-4-a549dfcfe8da@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
|
|
In preparation to add a new Corstone-1000 variation with different CPUs,
move the CPU nodes into the specific platforms and out of the common
corstone1000.dtsi.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Message-Id: <20260320-dt-corstone1000-a320-v1-3-a549dfcfe8da@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
|
|
Enable RSPI0 on the RZ/G3E SMARC EVK, where it is accessible on the
PMOD0 connector.
Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/b634c10e632fed07b5652c11de060deca27ead90.1771344527.git.tommaso.merciai.xr@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Add nodes for the RSPI IPs found in the Renesas RZ/G3E SoC.
Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/c8df5202caf4e36ee5beafe78ad0940643edcbb6.1771344527.git.tommaso.merciai.xr@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Cross-merge BPF and other fixes after downstream PR.
Minor conflicts in:
tools/testing/selftests/bpf/progs/exceptions_fail.c
tools/testing/selftests/bpf/progs/verifier_bounds.c
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Ingo Molnar:
- Improve Qemu MCE-injection behavior by only using AMD SMCA MSRs if
the feature bit is set
- Fix the relative path of gettimeofday.c inclusion in vclock_gettime.c
- Fix a boot crash on UV clusters when a socket is marked as
'deconfigured' which are mapped to the SOCK_EMPTY node ID by
the UV firmware, while Linux APIs expect NUMA_NO_NODE.
The difference being (0xffff [unsigned short ~0]) vs [int -1]
* tag 'x86-urgent-2026-03-22' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/platform/uv: Handle deconfigured sockets
x86/entry/vdso: Fix path of included gettimeofday.c
x86/mce/amd: Check SMCA feature bit before accessing SMCA MSRs
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull perf fixes from Ingo Molnar:
- Fix a PMU driver crash on AMD EPYC systems, caused by
a race condition in x86_pmu_enable()
- Fix a possible counter-initialization bug in x86_pmu_enable()
- Fix a counter inheritance bug in inherit_event() and
__perf_event_read()
- Fix an Intel PMU driver branch constraints handling bug
found by UBSAN
- Fix the Intel PMU driver's new Off-Module Response (OMR)
support code for Diamond Rapids / Nova lake, to fix a snoop
information parsing bug
* tag 'perf-urgent-2026-03-22' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf/x86/intel: Fix OMR snoop information parsing issues
perf/x86/intel: Add missing branch counters constraint apply
perf: Make sure to use pmu_ctx->pmu for groups
x86/perf: Make sure to program the counter value for stopped events on migration
perf/x86: Move event pointer setup earlier in x86_pmu_enable()
|
|
On the J721S2 platform, pinctrl contexts must be saved and restored during
suspend-to-ram, just like on the J7200. So use ti,j7200-padconf compatible.
Signed-off-by: Thomas Richard (TI) <thomas.richard@bootlin.com>
Link: https://patch.msgid.link/20260313-j721s2-s2r-pinctrl-v1-1-a6f80c641037@bootlin.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
Add an overlay to use the PEB-AV-15 AV-Adapter. It's a small expansion board
using a Lontium LT8912B DSI->HDMI bridge and a TLV320AIC3007 audio codec.
Signed-off-by: Dominik Haller <d.haller@phytec.de>
Link: https://patch.msgid.link/20260320212349.420951-6-d.haller@phytec.de
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
Add the second DSI instance and its corresponding phy to the main domain
include file.
Signed-off-by: Dominik Haller <d.haller@phytec.de>
Reviewed-by: Beleswar Padhi <b-padhi@ti.com>
Link: https://patch.msgid.link/20260320212349.420951-5-d.haller@phytec.de
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
