| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Device nodes are enabled by default and this DTSI file does not include
anything else, thus it is impossible that nodes were disabled before and
need to be re-enabled. Adding redundant status=okay is just confusing
and suggests some other code flow. Verified with dtx_diff.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Device nodes are enabled by default and this DTSI file does not include
anything else, thus it is impossible that nodes were disabled before and
need to be re-enabled. Adding redundant status=okay is just confusing
and suggests some other code flow. Verified with dtx_diff.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Device nodes are enabled by default and this DTSI file does not include
anything else, thus it is impossible that nodes were disabled before and
need to be re-enabled. Adding redundant status=okay is just confusing
and suggests some other code flow. Verified with dtx_diff.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Device nodes are enabled by default and this DTSI file does not include
anything else, thus it is impossible that nodes were disabled before and
need to be re-enabled. Adding redundant status=okay is just confusing
and suggests some other code flow. Verified with dtx_diff.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The Command Queue Virtualization (CMDQV) hardware is part of the
SMMUv3 implementation on NVIDIA Tegra SoCs. It assists in
virtualizing the command queue for the SMMU.
Update SMMU compatible strings to use nvidia,tegra264-smmu to enable
CMDQV support. Add device tree nodes for the CMDQV hardware and enable
them on the tegra264-p3834 platform where SMMUs are enabled. Each SMMU
instance is paired with its corresponding CMDQV instance via the
nvidia,cmdqv property.
Acked-by: Nicolin Chen <nicolinc@nvidia.com>
Signed-off-by: Ashish Mhetre <amhetre@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The DBB clock is used by the EMC to enable the data path from various IP
blocks to external memory.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
partition node
"ranges" is only valid for MMIO addresses as it is used for translating
addresses to CPU address. Even if a partial translation was supported,
the DT is incorrect here as the nvmem-layout node would also need
"ranges". So drop "ranges" and the associated cell size properties.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20260108231558.1422454-2-robh@kernel.org
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
|
|
The "arm,cci-400-pmu" compatible is not documented as a valid fallback
nor is it used, so drop it.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20260106-dt-dtbs-broadcom-fixes-v1-13-ba45874e4553@kernel.org
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
|
|
The "clock-names" property is not documented for the "brcm,spi-bcm-qspi"
binding nor in use by the kernel driver, so drop it.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20260106-dt-dtbs-broadcom-fixes-v1-12-ba45874e4553@kernel.org
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
|
|
"brcm,pcie-ob-oarr-size" properties
The "brcm,pcie-ob-oarr-size" property is unused and undocumented, so drop
them.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20260106-dt-dtbs-broadcom-fixes-v1-11-ba45874e4553@kernel.org
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
|
|
The nd2-clocks.dtsi is oddly included in the middle of a bus node and is
only included in one place, so collapse it into ns2.dtsi. Move the fixed
and fixed-factor clock nodes to the root as they are not part of the
bus. Rename the node names to use preferred names.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20260106-dt-dtbs-broadcom-fixes-v1-10-ba45874e4553@kernel.org
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
|
|
The at25,* properties have been deprecated since 2012. This board wasn't
upstream until 2014, so it should be safe to switch over to the "new"
properties.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20260106-dt-dtbs-broadcom-fixes-v1-9-ba45874e4553@kernel.org
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
|
|
Update various node names to use the documented preferred names. Node
names/path aren't considered ABI, so changing them should be safe.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20260106-dt-dtbs-broadcom-fixes-v1-8-ba45874e4553@kernel.org
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
|
|
The 'raid' nodes are not MMIO devices and are not part of a bus, so move
them to the root level. Drop the unit-addresses as they don't have any
address.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20260106-dt-dtbs-broadcom-fixes-v1-7-ba45874e4553@kernel.org
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
|
|
Fix 'simple-bus' node names to follow the defined pattern. Nodes with 'reg'
or 'ranges' addresses should also have a unit-address.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20260106-dt-dtbs-broadcom-fixes-v1-6-ba45874e4553@kernel.org
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
|
|
The stringray-clocks.dtsi is oddly included in the middle of a bus
node and is only included in one place, so collapse it into
stingray.dtsi. Move the fixed and fixed-factor clock nodes to the root
as they are not part of the bus. Rename the node names to use preferred
names.
Drop the unnecessary 1:1 fixed-factor clock providers.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20260106-dt-dtbs-broadcom-fixes-v1-5-ba45874e4553@kernel.org
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
|
|
The "silabs,si3226x" and "brcm,bdc-v0.16" nodes have no documentation
and no driver in the kernel, so remove them. They can be added back with
proper documentation if there is a need for them.
Note that if both USB ports have similar memory maps in relationship to
their USB PHY nodes, it looks like the device controller should have
been at 0x12000, not 0x21000?
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20260106-dt-dtbs-broadcom-fixes-v1-4-ba45874e4553@kernel.org
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
|
|
This fixes several typos in the filtering of compiler flags for vdso,
discovered by Chris Mason using an AI script:
1. "-fno-PIE" was written as "fno-PIE".
2. "CC_PLUGINS_FLAGS" was written as "CC_PLUGIN_FLAGS"
To the best of my knowledge, none of these actually had any real
impact on the build at this time but they are genuine bugs which could
break things at any point in the future.
Chris's script also found that "CONFIG_X86_USER_SHADOW_STACK" was
missing "CONFIG_", but it needs a different fix.
[ dhansen: remove CONFIG_X86_USER_SHADOW_STACK munging,
add mention in changelog. ]
Closes: https://lore.kernel.org/20260116035807.2307742-1-clm@meta.com
Fixes: 693c819fedcd ("x86/entry/vdso: Refactor the vdso build")
Reported-by: Chris Mason <clm@meta.com>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Link: https://patch.msgid.link/20260116204057.386268-3-hpa@zytor.com
|
|
When CONFIG_BROADCAST_TLB_FLUSH is not enabled, mm_free_global_asid() remains
a globally visible symbol and generates a useless function call to it in
destroy_context(). Therefore, hide the mm_free_global_asid() definition under
CONFIG_BROADCAST_TLB_FLUSH and provide a static inline empty version when it
is not enabled to remove the function call.
Signed-off-by: Hou Wenlong <houwenlong.hwl@antgroup.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Rik van Riel <riel@surriel.com>
Link: https://patch.msgid.link/b262a8ec8076fb26bb692aaf113848b1e6f40e40.1768448079.git.houwenlong.hwl@antgroup.com
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl
Pull Compute Express Link (CXL) fixes from Dave Jiang:
- Recognize all ZONE_DEVICE users as physaddr consumers
- Fix format string for extended_linear_cache_size_show()
- Fix target list setup for multiple decoders sharing the same
downstream port
- Restore HBIW check before derefernce platform data
- Fix potential infinite loop in __cxl_dpa_reserve()
- Check for invalid addresses returned from translation functions on
error
* tag 'cxl-fixes-6.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl:
cxl: Check for invalid addresses returned from translation functions on errors
cxl/hdm: Fix potential infinite loop in __cxl_dpa_reserve()
cxl/acpi: Restore HBIW check before dereferencing platform_data
cxl/port: Fix target list setup for multiple decoders sharing the same dport
cxl/region: fix format string for resource_size_t
x86/kaslr: Recognize all ZONE_DEVICE users as physaddr consumers
|
|
The location of the vdso binary files in the object tree has changed;
update "make vdso_install" to match.
Closes: https://lore.kernel.org/16ea64d1-2a9b-46f9-9fcc-42958f599eb6@leemhuis.info
Fixes: 693c819fedcd ("x86/entry/vdso: Refactor the vdso build")
Reported-by: Thorsten Leemhuis <linux@leemhuis.info>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Link: https://patch.msgid.link/20260116204057.386268-2-hpa@zytor.com
|
|
... same as native mount(2) is doing for devname argument. While we
are at it, fix misspelling ufs_args as cdfs_args in osf_ufs_mount() -
layouts are identical, so it doesn't change anything, but the current
variant is confusing for no reason.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
Add a multicore configuration for the Terasic de0 nano FPGA development
board. This SoC runs 2 OpenRISC CPUs at 50Mhz with 32MB ram, UART for
console and GPIOs for LEDs.
This FPGA SoC is based on the simple-smp reference board and brings in
devices from the de0 nano common DTSI file.
A default config is added that brings together the device tree and
driver setup.
Link: https://github.com/stffrdhrn/de0_nano-multicore
Signed-off-by: Stafford Horne <shorne@gmail.com>
|
|
Split out the common memory, CPU and PIC definitions of the simple SMP
system to a DTSI file which we will later use for our De0 Nano multicore
board device tree. We also take this opportunity to swich underscores
to dashes as that seems to be the more common convention for DTS files.
Signed-off-by: Stafford Horne <shorne@gmail.com>
|
|
Commit c05671846451 ("openrisc: sleep instead of spin on secondary
wait") fixed OpenRISC SMP Linux for QEMU. However, stability was never
achieved on FPGA development boards. This is because the above patch
has a step to unmask IPIs on non-boot cpu's but on hardware without
power management, IPIs remain masked.
This meant that IPI's were never actually working on the simple SMP
systems we run on development boards. The systems booted but stability
was very suspect.
Add the ability to unmask IPI's on the non-boot cores. This is done by
making the OMPIC IRQs proper percpu IRQs. We can then use the
enabled_percpu_irq() to unmask IRQ on the non-boot cpus.
Update the or1k PIC driver to use a flow handler that can switch between
percpu and the configured level or edge flow handlers at runtime.
This mechanism is inspired by that done in the J-Core AIC driver.
Signed-off-by: Stafford Horne <shorne@gmail.com>
Acked-by: Thomas Gleixner <tglx@kernel.org>
|
|
The de0 nano from Terasic is an FPGA board that we use in the OpenRISC
community to test OpenRISC configurations. Add a base configuration for
the board that runs an OpenRISC CPU at 50Mhz with 32MB ram, UART for
console and some GPIOs for LEDs and switches.
There is an older version of this floating around that defines all of
the hardware on the board including SPI's, flash devices, sram, ADCs
etc. Eventually it would be good to get the full version upstream
but for now I think a minimal board is good to start with.
Link: https://openrisc.io/tutorials/de0_nano/
Link: https://github.com/olofk/de0_nano
Signed-off-by: Stafford Horne <shorne@gmail.com>
|
|
Insert Soft Reserved memory into a dedicated soft_reserve_resource tree
instead of the iomem_resource tree at boot. Delay publishing these ranges
into the iomem hierarchy until ownership is resolved and the HMEM path
is ready to consume them.
Publishing Soft Reserved ranges into iomem too early conflicts with CXL
hotplug and prevents region assembly when those ranges overlap CXL
windows.
Follow up patches will reinsert Soft Reserved ranges into iomem after CXL
window publication is complete and HMEM is ready to claim the memory. This
provides a cleaner handoff between EFI-defined memory ranges and CXL
resource management without trimming or deleting resources later.
In the meantime "Soft Reserved" resources will no longer appear in
/proc/iomem, only their results. I.e. with "memmap=4G%4G+0xefffffff"
Before:
100000000-1ffffffff : Soft Reserved
100000000-1ffffffff : dax1.0
100000000-1ffffffff : System RAM (kmem)
After:
100000000-1ffffffff : dax1.0
100000000-1ffffffff : System RAM (kmem)
The expectation is that this does not lead to a user visible regression
because the dax1.0 device is created in both instances.
Co-developed-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
[Smita: incorporate feedback from x86 maintainer review]
Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
Link: https://patch.msgid.link/20251120031925.87762-2-Smita.KoralahalliChannabasappa@amd.com
[djbw: cleanups and clarifications]
Link: https://lore.kernel.org/69443f707b025_1cee10022@dwillia2-mobl4.notmuch
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
|
|
Add a wrapper macro, ENC_TO_VMCS12_IDX(), to get a vmcs12 index given a
field encoding in anticipation of adding a macro to get from a vmcs12 index
back to the field encoding. And because open coding ROL16(n, 6) everywhere
is gross.
No functional change intended.
Suggested-by: Xiaoyao Li <xiaoyao.li@intel.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Link: https://patch.msgid.link/20260115173427.716021-3-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Move the call to nested_vmx_setup_ctls_msrs() from vmx_hardware_setup() to
nested_vmx_hardware_setup() so that the nested code can deal with ordering
dependencies without having to straddle vmx_hardware_setup() and
nested_vmx_hardware_setup(). Specifically, an upcoming change will
sanitize the vmcs12 fields based on hardware support, and that code needs
to run _before_ the MSRs are configured, because the lovely vmcs_enum MSR
depends on the max support vmcs12 field.
No functional change intended.
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Link: https://patch.msgid.link/20260115173427.716021-2-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
This script
#!/usr/bin/bash
echo 0 > /proc/sys/kernel/randomize_va_space
echo 'void main(void) {}' > TEST.c
# -fcf-protection to ensure that the 1st endbr32 insn can't be emulated
gcc -m32 -fcf-protection=branch TEST.c -o test
bpftrace -e 'uprobe:./test:main {}' -c ./test
"hangs", the probed ./test task enters an endless loop.
The problem is that with randomize_va_space == 0
get_unmapped_area(TASK_SIZE - PAGE_SIZE) called by xol_add_vma() can not
just return the "addr == TASK_SIZE - PAGE_SIZE" hint, this addr is used
by the stack vma.
arch_get_unmapped_area_topdown() doesn't take TIF_ADDR32 into account and
in_32bit_syscall() is false, this leads to info.high_limit > TASK_SIZE.
vm_unmapped_area() happily returns the high address > TASK_SIZE and then
get_unmapped_area() returns -ENOMEM after the "if (addr > TASK_SIZE - len)"
check.
handle_swbp() doesn't report this failure (probably it should) and silently
restarts the probed insn. Endless loop.
I think that the right fix should change the x86 get_unmapped_area() paths
to rely on TIF_ADDR32 rather than in_32bit_syscall(). Note also that if
CONFIG_X86_X32_ABI=y, in_x32_syscall() falsely returns true in this case
because ->orig_ax = -1.
But we need a simple fix for -stable, so this patch just sets TS_COMPAT if
the probed task is 32-bit to make in_ia32_syscall() true.
Fixes: 1b028f784e8c ("x86/mm: Introduce mmap_compat_base() for 32-bit mmap()")
Reported-by: Paulo Andrade <pandrade@redhat.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/all/aV5uldEvV7pb4RA8@redhat.com/
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/aWO7Fdxn39piQnxu@redhat.com
|
|
Enable static TPDM device for lemans.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20251028-add_static_tpdm_support-v4-3-84e21b98e727@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Add reserved memory region for audio PD dynamic loading and remote
heap requirement. Also add LPASS and ADSP_HEAP VMIDs.
Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20251117070819.492-1-jianping.li@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
The Thinkpad T14s embeds a transparent 4lanes DP->HDMI transceiver
connected to the third QMP Combo PHY 4 lanes.
Add all the data routing, disable mode switching and specify the
QMP Combo PHY should be in DP-Only mode to route the 4 lanes to
the underlying DP phy.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20251119-topic-x1e80100-hdmi-v7-3-2bee0e66cc1b@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Unlike the phone SoCs this was copied from, x1e has a 40-bit physical bus.
The upper address space is used to support more than 32GB of memory.
This fixes issues when DMA buffers are allocated outside the 36-bit range.
Fixes: af16b00578a7 ("arm64: dts: qcom: Add base X1E80100 dtsi and the QCP dts")
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20251127212943.24480-1-jonathan@marek.ca
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
The video-demo adapter also works on the Lion SoM when running
on a Haikou baseboard, so add an overlay for it.
Tested-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Link: https://patch.msgid.link/20260114230707.4175162-6-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The pwm1 is exposed as BLT_CTRL signal on the MISC I/O pin header of the
haikou baseboard and the Qseven standard specifies this signal is only
for PWM (either for a panel backlight or generic PWM).
So enable it in the Haikou baseboard for Lion.
Suggested-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://patch.msgid.link/20260114230707.4175162-5-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Enable the VOP and HDMI controller on the Lion-Haikou board.
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://patch.msgid.link/20260114230707.4175162-4-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Add the HDMI controller node to the main SoC devicetree and hook
it into the VOP.
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Link: https://patch.msgid.link/20260114230707.4175162-3-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
i2c@0 on i2cmux2 does already have a phandle i2c_lvds_blc defined.
Use this one instead of replicating the hierarchy again, as this might
result in strange errors if the lion dtsi is changed at some point
in the future.
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Link: https://patch.msgid.link/20260114230707.4175162-2-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
When runtime suspend is enabled, the associated power domain is powered
off, which resets the registers, including the power control bit. As a result,
the card loses power during runtime suspend. The card should still be able
to process I/O with the help of mmc_blk_mq_rw_recovery(), which is suboptimal.
To address this issue, we must use vmmc-supply with a GPIO based method to
maintain power to the card and store valid tuning phases. Also, add cd-gpios
method to make hot-plug work correctly during idle periods.
Fixes: 7fee88882704 ("arm64: dts: rockchip: Add devicetree for the FriendlyElec NanoPi R76S")
Cc: stable@vger.kernel.org
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Tested-by: Marco Schirrmeister <mschirrmeister@gmail.com>
Link: https://patch.msgid.link/1768524932-163929-6-git-send-email-shawn.lin@rock-chips.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
When runtime suspend is enabled, the associated power domain is powered
off, which resets the registers, including the power control bit. As a result,
the card loses power during runtime suspend. The card should still be able
to process I/O with the help of mmc_blk_mq_rw_recovery(), which is suboptimal.
To address this issue, we must use vmmc-supply with a GPIO based method to
maintain power to the card. Also, add cd-gpios method to make hot-plug work
correctly during idle periods.
Fixes: f135a1a07352 ("arm64: dts: rockchip: Add rk3576 evb1 board")
Cc: stable@vger.kernel.org
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Link: https://patch.msgid.link/1768524932-163929-5-git-send-email-shawn.lin@rock-chips.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The property "enable-active-high" was missing, as the default is
active-low. Add it.
Fixes: 1c3c4df06f9d ("arm64: dts: ti: Add support for Kontron SMARC-sAM67")
Signed-off-by: Michael Walle <mwalle@kernel.org>
Link: https://patch.msgid.link/20260115131431.1521102-3-mwalle@kernel.org
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Fix the size of the CMA node by making it a 64bit size. This was
probably a copy&paste mistake. Also drop the unneeded alignment.
Fixes: 1c3c4df06f9d ("arm64: dts: ti: Add support for Kontron SMARC-sAM67")
Signed-off-by: Michael Walle <mwalle@kernel.org>
Link: https://patch.msgid.link/20260115131431.1521102-2-mwalle@kernel.org
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
The TI K3 AM62P and J722S SoCs have a HSM (High Security Module) M4F
core in the MAIN Voltage Domain which could be used to run secure
services like Authentication. Add Device Tree Node definitions for the
HSM core in the respective SoC common main dtsi file.
The HSM node is reserved to be loaded and booted by the early-stage
bootloader. The firmware-name property is defined at the SoC level
since the HSM is not a general-purpose remote core and boards are
unlikely to use separate firmware. If needed in exceptional cases,
board-specific device trees can override this property.
The corresponding reg ranges of HSM node has also been added to its
parent node's (cbass_main bus) ranges property.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Link: https://patch.msgid.link/20260114173551.2545088-3-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
The TI K3 J721S2, J784S4 and J742S2 SoCs have a HSM (High Security
Module) M4F core in the Wakeup Voltage Domain which could be used to run
secure services like Authentication. Add Device Tree Node definitions
for the HSM core in the respective SoC wakeup dtsi files.
The HSM node is reserved to be loaded and booted by the early-stage
bootloader. The firmware-name property is defined at the SoC level
since the HSM is not a general-purpose remote core and boards are
unlikely to use separate firmware. If needed in exceptional cases,
board-specific device trees can override this property.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Link: https://patch.msgid.link/20260114173551.2545088-2-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Reorder the ADC nodes in the dts/i files so they follow the same
alphabetical ordering used elsewhere in these files.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260115122210.3971063-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
According to section 13.2 of the DEN0077 FF-A specification, when
firmware does not support the requested version, it should reply with
FFA_RET_NOT_SUPPORTED(-1). Table 13.6 specifies the type of the error
code as int32.
Currently, the error checking logic compares the unsigned long return
value it got from the SMC layer, against a "-1" literal. This fails due
to a type mismatch: the literal is extended to 64 bits, whereas the
register contains only 32 bits of ones(0x00000000ffffffff).
Consequently, hyp_ffa_init misinterprets the "-1" return value as an
invalid FF-A version. This prevents pKVM initialization on devices where
FF-A is not supported in firmware.
Fix this by explicitly casting res.a0 to s32.
Signed-off-by: Kornel Dulęba <korneld@google.com>
Acked-by: Will Deacon <will@kernel.org>
Link: https://patch.msgid.link/20251114-pkvm_init_noffa-v1-1-87a82e87c345@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
This legacy platform driver was used with some Qong board.
Support for this board was removed with
commit c93197b0041d ("ARM: imx: Remove i.MX31 board files")
in 2020. So remove this now orphaned driver.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/cef7c728-28ee-439f-b747-eb1c9394fe51@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
CONFIG_CACHEMAINT_FOR_DMA
The Kconfig menu entry was converted to a menuconfig to allow it to be
hidden for !CONFIG_RISCV. The drivers under this new option were selected
by some other Kconfig symbols and so an extra select CACHEMAINT_FOR_DMA is
needed.
Fixes: 4d1608d0ab33 ("cache: Make top level Kconfig menu a boolean dependent on RISCV")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202512100509.g6llkMMr-lkp@intel.com/
Signed-off-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Link: https://patch.msgid.link/20251210160047.201379-2-Jonathan.Cameron@huawei.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
Switch from the old AES library functions (which use struct
crypto_aes_ctx) to the new ones (which use struct aes_enckey). This
eliminates the unnecessary computation and caching of the decryption
round keys. The new AES en/decryption functions are also much faster
and use AES instructions when supported by the CPU.
Since this changes the format of the AES-GCM key structures that are
used by the AES-GCM assembly code, the offsets in the assembly code had
to be updated to match. Note that the new key structures are smaller,
since the decryption round keys are no longer unnecessarily included.
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20260112192035.10427-26-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
