| Age | Commit message (Collapse) | Author |
|---|
|
Update all i2c nodes with the following properties:
- replace interrupts with interrupts-extended and rely on exti
- add dma properties
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Link: https://lore.kernel.org/r/20260224-stm32-i2c-dt-updates-v1-1-347cf6fca7d1@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
The following DTOs are supported on STM32MP15xx DHCOM PDK2:
- DH 460-200 SRAM board in header X11
- DH 497-200 adapter card with EDT ETM0700G0EDH6 Parallel RGB panel
- DH 505-200 adapter card with Chefree CH101OLHLWH-002 LVDS panel
- DH 531-100 SPI/I2C board in header X21
- DH 531-200 SPI/I2C board in header X22
- DH 560-200 7" LCD board in header X12
- DH 638-100 mezzanine card with RPi 7" DSI panel attached on top
- DH 672-100 expansion card, which contains CAN/FD transceiver and
enables PDK2 to use one more CAN/FD interface
The following DTOs are supported on STM32MP15xx DHCOM DRC02:
- Enable configuration where the DHSOM inserted into the DRC02 has
RSI 9116 WiFi populated on the SoM and where the microSD slot on
the bottom of DRC02 must not be used.
This permits a non-default configuration of the SoM and DRC02 board
used for custom device setup with on-SoM WiFi.
The following DTOs are supported on STM32MP15xx DHCOM PicoITX:
- DH 548-200 adapter card with Multi-Inno MI0700D4T-6 7" DPI panel
- DH 553-100 adapter card with Team Source Display TST043015CMHX 4.3" DPI panel
- DH 626-100 adapter card with Chefree CH101OLHLWH-002 LVDS panel
The following DTOs are supported on STM32MP15xx DHCOR Avenger96:
- FDCAN1 on low-speed expansion X6
- FDCAN2 on low-speed expansion X6
- AT24C04 I2C EEPROM on low-speed expansion X6 I2C1
- AT24C04 I2C EEPROM on low-speed expansion X6 I2C2
- AT25AA010A SPI EEPROM on low-speed expansion X6 SPI2
- 96boards OV5640 mezzanine card with sensor connected to port J3.
- DH 644-100 mezzanine card with Orisetech OTM8009A DSI panel
- DH 644-100 mezzanine card with RPi 7" DSI panel
The following DTOs are supported on STM32MP13xx DHCOR DHSBC:
- joy-IT RB-TFT3.2-V2 240x320 SPI LCD and XPT2046 resistive touch controller
Signed-off-by: Marek Vasut <marex@nabladev.com>
Link: https://lore.kernel.org/r/20260121085347.10368-3-marex@nabladev.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
Enable CoreSight peripherals on the stm32mp135f-dk board.
Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
Link: https://lore.kernel.org/r/20260226-debug_bus-v6-11-5d794697798d@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
Enable CoreSight peripherals on the stm32mp157c-ev1 board.
Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
Link: https://lore.kernel.org/r/20260226-debug_bus-v6-10-5d794697798d@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
Enable CoreSight peripherals on the stm32mp15xx-dkx boards. All boards
including this file are embedding a dual core SoC so this change is
applicable.
Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
Link: https://lore.kernel.org/r/20260226-debug_bus-v6-9-5d794697798d@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
On stm32mp1x boards, enable the debug bus so we always try to probe
the debug peripherals, if their status and the debug configuration
allow it.
Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
Link: https://lore.kernel.org/r/20260226-debug_bus-v6-8-5d794697798d@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
Some peripherals cannot be probed if a debug configuration is not set
in the BSEC.
Introduce a debug bus that will check the debug subsystem accessibility
before probing these peripheral drivers.
Add Coresight peripheral nodes under this bus and add the appropriate
access-controllers property to the HDP node.
Signed-off-by: Antonio Borneo <antonio.borneo@foss.st.com>
Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
Link: https://lore.kernel.org/r/20260226-debug_bus-v6-7-5d794697798d@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
The BeagleV Ahead board includes a micro HDMI connector (Type-D)
wired to the TH1520 SoC's HDMI transmitter.
Enable the display pipeline by adding the HDMI connector node,
connecting it to the HDMI controller, and activating the DPU
and HDMI nodes.
Signed-off-by: Robert Mazur <robert.mazur@imgtec.com>
Signed-off-by: Drew Fustini <fustini@kernel.org>
|
|
All CONFIG_ARCH_TEGRA_132_SOC-like symbols are now default for
ARCH_TEGRA, so drop redundant lines from defconfig. Tested with
comparing include/generated/autoconf.h.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
All CONFIG_ARCH_TEGRA_2x_SOC-like symbols are now default for
ARCH_TEGRA, so drop redundant lines from defconfigs. Tested with
comparing include/generated/autoconf.h.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Previously different architectures were using random sources of
differing strength and cost to decide the random kstack offset. A number
of architectures (loongarch, powerpc, s390, x86) were using their
timestamp counter, at whatever the frequency happened to be. Other
arches (arm64, riscv) were using entropy from the crng via
get_random_u16().
There have been concerns that in some cases the timestamp counters may
be too weak, because they can be easily guessed or influenced by user
space. And get_random_u16() has been shown to be too costly for the
level of protection kstack offset randomization provides.
So let's use a common, architecture-agnostic source of entropy; a
per-cpu prng, seeded at boot-time from the crng. This has a few
benefits:
- We can remove choose_random_kstack_offset(); That was only there to
try to make the timestamp counter value a bit harder to influence
from user space [*].
- The architecture code is simplified. All it has to do now is call
add_random_kstack_offset() in the syscall path.
- The strength of the randomness can be reasoned about independently
of the architecture.
- Arches previously using get_random_u16() now have much faster
syscall paths, see below results.
[*] Additionally, this gets rid of some redundant work on s390 and x86.
Before this patch, those architectures called
choose_random_kstack_offset() under arch_exit_to_user_mode_prepare(),
which is also called for exception returns to userspace which were *not*
syscalls (e.g. regular interrupts). Getting rid of
choose_random_kstack_offset() avoids a small amount of redundant work
for the non-syscall cases.
In some configurations, add_random_kstack_offset() will now call
instrumentable code, so for a couple of arches, I have moved the call a
bit later to the first point where instrumentation is allowed. This
doesn't impact the efficacy of the mechanism.
There have been some claims that a prng may be less strong than the
timestamp counter if not regularly reseeded. But the prng has a period
of about 2^113. So as long as the prng state remains secret, it should
not be possible to guess. If the prng state can be accessed, we have
bigger problems.
Additionally, we are only consuming 6 bits to randomize the stack, so
there are only 64 possible random offsets. I assert that it would be
trivial for an attacker to brute force by repeating their attack and
waiting for the random stack offset to be the desired one. The prng
approach seems entirely proportional to this level of protection.
Performance data are provided below. The baseline is v6.18 with rndstack
on for each respective arch. (I)/(R) indicate statistically significant
improvement/regression. arm64 platform is AWS Graviton3 (m7g.metal).
x86_64 platform is AWS Sapphire Rapids (m7i.24xlarge):
+-----------------+--------------+---------------+---------------+
| Benchmark | Result Class | per-cpu-prng | per-cpu-prng |
| | | arm64 (metal) | x86_64 (VM) |
+=================+==============+===============+===============+
| syscall/getpid | mean (ns) | (I) -9.50% | (I) -17.65% |
| | p99 (ns) | (I) -59.24% | (I) -24.41% |
| | p99.9 (ns) | (I) -59.52% | (I) -28.52% |
+-----------------+--------------+---------------+---------------+
| syscall/getppid | mean (ns) | (I) -9.52% | (I) -19.24% |
| | p99 (ns) | (I) -59.25% | (I) -25.03% |
| | p99.9 (ns) | (I) -59.50% | (I) -28.17% |
+-----------------+--------------+---------------+---------------+
| syscall/invalid | mean (ns) | (I) -10.31% | (I) -18.56% |
| | p99 (ns) | (I) -60.79% | (I) -20.06% |
| | p99.9 (ns) | (I) -61.04% | (I) -25.04% |
+-----------------+--------------+---------------+---------------+
I tested an earlier version of this change on x86 bare metal and it
showed a smaller but still significant improvement. The bare metal
system wasn't available this time around so testing was done in a VM
instance. I'm guessing the cost of rdtsc is higher for VMs.
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
Link: https://patch.msgid.link/20260303150840.3789438-3-ryan.roberts@arm.com
Signed-off-by: Kees Cook <kees@kernel.org>
|
|
These clocks are used by PCIe lanes, but we're missing from the
definition.
Suggested-by: Charalampos Mitrodimas <charmitro@posteo.net>
Signed-off-by: David Heidelberg <david@ixit.cz>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Link: https://patch.msgid.link/20260304-rk3568-bri-r2-pro-fix-pcie-v4-1-37abd7ba29d0@ixit.cz
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The mphy reset signal is used to reset the physical adapter. Resetting
other components while leaving the mphy unreset may occasionally prevent
the UFS controller from successfully linking up with the device.
This addresses an intermittent hardware bug where the UFS link fails to
establish under specific timing conditions with certain chips. While
difficult to reproduce initially, this issue was consistently observed in
downstream testing and requires explicit mphy reset control for full
stability.
Fixes: c75e5e010fef ("scsi: arm64: dts: rockchip: Add UFS support for RK3576 SoC")
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Link: https://patch.msgid.link/1773277913-29580-1-git-send-email-shawn.lin@rock-chips.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Enable the One Time Programmable Controller (OTPC) in RK3528 and add
an initial nvmem fixed layout.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260312213019.13965-4-heiko@sntech.de
|
|
Enable the One Time Programmable Controller (OTPC) in RK356x and add
an initial nvmem fixed layout.
Tested-by: Diederik de Haas <diederik@cknow-tech.com> # NanoPi R5S, PineNote
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260312213019.13965-3-heiko@sntech.de
|
|
Enable the One Time Programmable Controller (OTPC) in RK3562 and add
an initial nvmem fixed layout.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260312213019.13965-2-heiko@sntech.de
|
|
Add supports-clkreq and the corresponding pinmux configurations for PCIe
ASPM L1 substates on the Rock 5B, 5B+ and 5T.
The supports-clkreq flag informs the PCIe controller that the hardware
routing for the CLKREQ# sideband signal is present. This enables support
for PCIe ASPM (Active State Power Management) L1 substates, allowing for
better power efficiency.
Cc: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Link: https://patch.msgid.link/20260316073621.39027-1-linux.amoon@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Provide aliases for the SD and eMMC interfaces, so that the operating
system can assign stable interface names.
On Linux this is only relevant when booting without partition UUID
based root device identification, e.g. when booting without an
initramfs. In that case booting with e.g. root=/dev/mmcblk0p2 is
unreliable without this patch as the device numbers changed based
on device probe order.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://patch.msgid.link/20260317-sige5-mmc-aliases-v1-1-ee93a1571802@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Add support for all six SPDIF transmitters found in the RK3576.
The nodes have been taken over from the BSP kernel and checked
against the TRM (power domain descriptions from chapter 6.3.2,
addresses from "Table 1-1 Address Mapping", interrupt from
"Table 1-3 RK3576 Interrupt Connection List" (TRM numbers are
off by 32 due to SGI/PPI not being numbered separately). The
TRM lacks a proper clock tree, but fortunately are quite obvious
for the SPDIF IP.
Note, that the RK3576 also has 3 SPDIF receivers, which need their
own binding and are not handled in this patch.
A typical use case for the SPDIF transmitters is audio support for
the Displayport (DP) controller. DP requires inserting PCUV control
bits, which requires software support when using I2S. The SPDIF IP
can add it automatically and thus is preferred.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://patch.msgid.link/20260316-rk3576-spdif-v1-2-acb75088b560@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The Khadas Edge 2L is a single board computer based on the Rockchip
RK3576 SoC.
Add basic device tree support for this board. Currently, only eMMC
and UART are enabled, allowing the board to boot into a basic Linux
system via the serial console.
Signed-off-by: Gray Huang <gray.huang@wesion.com>
Link: https://patch.msgid.link/20260317090731.600787-3-gray.huang@wesion.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The purpose of the constant it is not entirely clear from its name.
As this constant is going to be exposed in a UAPI header, give it a more
specific name for clarity. As all its users call it 'marker', use that
wording in the constant itself.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
|
|
This enum originates in generic cryptographic code and has a very
generic name. Nowadays it is only used for module signatures.
As this enum is going to be exposed in a UAPI header, give it a more
specific name for clarity and consistency.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
|
|
commit fcc43a7e294f ("s390/configs: Set HZ=1000") changed the interrupt
frequency of the system. On machines with heavy load and many perf event
overflows, this might lead to an exception. Dmesg displays these entries:
[112.242542] cpum_sf: Loading sampling controls failed: op 1 err -22
One line per CPU online.
The root cause is the CPU Measurement sampling facility overflow
adjustment. Whenever an overflow (too much samples per tick) occurs, the
sampling rate is adjusted and increased. This was done without observing
the maximum sampling rate limit. When the current sampling interval is
higher than the maximum sampling rate limit, the lsctl instruction raises
an exception. The error messages is the result of such an exception.
Observe the upper limit when the new sampling rate is recalculated.
Cc: stable@vger.kernel.org
Fixes: 39d4a501a9ef ("s390/cpum_sf: Adjust sampling interval to avoid hitting sample limits")
Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
Reviewed-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Reviewed-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
In increment mode, the tsu clock for the macb is provided separately to
the pck, usually the same clock as the reference to the rtc provided by
an off-chip oscillator. pclk is 150 MHz typically, and the reference is
either 100 MHz or 125 MHz, so having the tsu clock is required for
correct rate selection.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
|
|
Substitute user hidden CONFIG_ARCH_MICROCHIP_POLARFIRE by user visible
CONFIG_ARCH_MICROCHIP.
Signed-off-by: Pierre-Henry Moussay <pierre-henry.moussay@microchip.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
|
|
The Curiosity-GX10000 (PIC64GX SoC Curiosity Kit) is a compact SoC
prototyping board featuring a Microchip PIC64GX SoC PIC64GC-1000.
Features include:
- 1 GB DDR4 SDRAM
- Gigabit Ethernet
- microSD-card slot
note: due to issue on some board, the SDHCI is limited to HS (High
speed mode, with a clock of 50MHz and 3.3V signals).
Signed-off-by: Pierre-Henry Moussay <pierre-henry.moussay@microchip.com>
Co-developed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
|
|
Add pinctrl nodes to PolarFire to demonstrate their use, matching the
default configuration set by the HSS firmware for the Icicle kit's
reference design, as a demonstration of use.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
|
|
The model name should be "Rockchip RK3562 EVB2 V10 Board".
Fixes: ceb6ef1ea900 ("arm64: dts: rockchip: Add RK3562 evb2 devicetree")
Signed-off-by: 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
Link: https://patch.msgid.link/tencent_78E7E3F6991FB4403D5ADC9E6A6BC3BF8307@qq.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The Onion Omega4 Evaluation Board is based on the RV1103B SoC and has:
- 256 MB of RAM
- 256 MB of SPI-NAND
- Ethernet
- USB OTG
- Wifi
- SD card
- Camera connector
The details can be found at:
https://documentation.onioniot.com/omega4/getting-started/
Add the initial support for this board so that it can fully boot into
Linux with the root file system stored in the SPI NAND.
Signed-off-by: Fabio Estevam <festevam@nabladev.com>
Link: https://patch.msgid.link/20260313131058.708361-4-festevam@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Add the initial RV1103B devicetree.
Based on the 5.10 Rockchip vendor kernel.
Signed-off-by: Fabio Estevam <festevam@nabladev.com>
Link: https://patch.msgid.link/20260313131058.708361-2-festevam@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD
KVM/arm64 fixes for 7.0, take #4
- Clear the pending exception state from a vcpu coming out of
reset, as it could otherwise affect the first instruction
executed in the guest.
- Fix the address translation emulation icode to set the Hardware
Access bit on the correct PTE instead of some other location.
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into HEAD
KVM: s390: Fixes for 7.0
- fix deadlock in new memory management
- handle kernel faults on donated memory properly
- fix bounds checking for irq routing + selftest
- fix invalid machine checks + logging
|
|
According to gpio-keys.yaml, linux,code is a required property.
Pass it to fix the following dt-schema warning:
lid-switch (gpio-keys): key-power: 'linux,code' is a required property
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://patch.msgid.link/20260323125721.692139-1-festevam@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Wenyuan Li <2063309626@qq.com> says:
The driver currently ignores the return values of several I2C operations
during register writes, which could lead to silent failures and
inconsistent device state.
Link: https://patch.msgid.link/tencent_579D057AC557914CF739A2D9EAD045CE7306@qq.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Build the kernel with make W=1 generates the following warning:
arch/x86/events/intel/p4.c: In function ‘p4_pmu_init’:
arch/x86/events/intel/p4.c:1370:27: error: variable ‘high’ set but not used [-Werror=unused-but-set-variable]
1370 | unsigned int low, high;
| ^~~~
This happens because, although both variables are declared and
initialized by rdmsr, only `low` is used in the subsequent if statement.
This patch uses the rdmsrq() macro instead of the rdmsr() macro.
The rdmsrq() macro avoids the use of high and low variables
because it reads the msr value in a single u64 variable.
Also, replace (1 << 7) with the proper macro.
Running `make W=1` again resolves the error.
I was unable to test the patch because
i do not have the hardware.
Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Aldo Conte <aldocontelk@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/20260320112302.281549-1-aldocontelk@gmail.com
|
|
Add the Performance Monitoring Unit (PMU) node with the appropriate
compatible string and interrupt line so that perf and other
PMU-based tooling can function correctly on this SoC.
[root@SAMA7D65 ~]$ dmesg | grep -i pmu
[ 1.487869] hw-perfevents: enabled with armv7_cortex_a7 PMU driver, 5 (8000000f) counters available
[root@SAMA7D65 ~]$ perf list hw
List of pre-defined events (to be used in -e or -M):
branch-instructions OR branches [Hardware event]
branch-misses [Hardware event]
bus-cycles [Hardware event]
cache-misses [Hardware event]
cache-references [Hardware event]
cpu-cycles OR cycles [Hardware event]
instructions [Hardware event]
Signed-off-by: Mihai Sain <mihai.sain@microchip.com>
Link: https://lore.kernel.org/r/20260324070927.1496-2-mihai.sain@microchip.com
[claudiu.beznea: keep nodes alphanumerically sorted]
Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
|
|
Other places that are doing this version comparison are already using
pmuv3_implemented(), so might as well use it here too for consistency.
Signed-off-by: James Clark <james.clark@linaro.org>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Colton Lewis <coltonlewis@google.com>
Signed-off-by: Will Deacon <will@kernel.org>
|
|
On the host, this change doesn't make a difference because the fields
are defined as FTR_EXACT. However, KVM allows userspace to set these
fields for a guest and overrides the type to be FTR_LOWER_SAFE. And
while KVM used to do an unsigned comparison to validate that the new
value is lower than what the hardware provides, since the linked commit
it uses the generic sanitization framework which does a signed
comparison.
Fix it by defining these fields as unsigned. In theory, without this
fix, userspace could set a higher PMU version than the hardware supports
by providing any value with the top bit set.
Fixes: c118cead07a7 ("KVM: arm64: Use generic sanitisation for ID_(AA64)DFR0_EL1")
Signed-off-by: James Clark <james.clark@linaro.org>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Colton Lewis <coltonlewis@google.com>
Signed-off-by: Will Deacon <will@kernel.org>
|
|
ID_AA64DFR0_EL1.PMUVer is an unsigned field, so this skips
initialization of host_data_ptr(nr_event_counters) for PMUv3 for Armv8.8
onwards as they appear as negative values.
Fix it by reading it as unsigned. Now ID_AA64DFR0_EL1_PMUVer_IMP_DEF
needs to be special cased, so use pmuv3_implemented() which already does
it.
Fixes: 2417218f2f23 ("KVM: arm64: Get rid of __kvm_get_mdcr_el2() and related warts")
Signed-off-by: James Clark <james.clark@linaro.org>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Colton Lewis <coltonlewis@google.com>
Signed-off-by: Will Deacon <will@kernel.org>
|
|
Add Cadence GPIO controller nodes for Sky1 FCH(S0) and S5 domains in
sky1.dtsi, and enable those controllers on sky1-orion-o6.
Signed-off-by: Zichar Zhang <zichar.zhang@cixtech.com>
Link: https://lore.kernel.org/r/20260312080826.3470205-2-zichar.zhang@cixtech.com
Signed-off-by: Peter Chen <peter.chen@cixtech.com>
|
|
Add a second SCMI channel using SMC transport to communicate with TF-A
for power domain management on the Sky1 SoC.
Signed-off-by: Gary Yang <gary.yang@cixtech.com>
Link: https://lore.kernel.org/r/20260313114914.1564115-3-gary.yang@cixtech.com
Signed-off-by: Peter Chen <peter.chen@cixtech.com>
|
|
There are two reset conctrollers on Cix Sky1 Soc. One is located in S0
domain, and the other is located in S5 domain.
Signed-off-by: Gary Yang <gary.yang@cixtech.com>
Link: https://lore.kernel.org/r/20260302064407.1914014-4-gary.yang@cixtech.com
Signed-off-by: Peter Chen <peter.chen@cixtech.com>
|
|
The combo PHY on the Banana Pi F3 is used for the USB 3.0 port. The high
speed differential lanes are always configured as such, and do not
require a pinctrl entry.
The existing pinctrl entry only configures PCIe secondary pins, which
are unused for USB and instead routed to the MIPI CSI1 connector.
Remove this incorrect pinctrl entry.
Fixes: 0be016a4b5d1b9 ("riscv: dts: spacemit: PCIe and PHY-related updates")
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Reviewed-by: Yixun Lan <dlan@kernel.org>
Link: https://lore.kernel.org/r/20260322202502.2205755-1-aurelien@aurel32.net
Signed-off-by: Yixun Lan <dlan@kernel.org>
|
|
Reorder the PHY nodes of USB and PCIe to the correct positions based on
the register address. This improves the readability and maintainability
of the DT. No functional change is introduced by this reordering.
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Reviewed-by: Yixun Lan <dlan@kernel.org>
Link: https://lore.kernel.org/r/20260318100000.3934516-1-amadeus@jmu.edu.cn
Signed-off-by: Yixun Lan <dlan@kernel.org>
|
|
Fix IOMMU DT propeties for GPU, display and video peripherals via
dropping SMMU stream IDs which relates to secure context bank.
This problem only surfaced when the Gunyah based firmware stack is
ported on Agatti replacing the legacy QHEE based firmware stack. Assigning
Linux kernel (HLOS) VMID to secure context bank stream IDs is treated
as a fault by Gunyah hypervisor which were previously ignored by QHEE
hypervisor.
The DT changes should be backwards compatible with legacy QHEE based
firmware stack too.
Suggested-by: Prakash Gupta <guptap@qti.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260122121042.579270-4-sumit.garg@kernel.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
r-spi has DRQs for both the main and MCU DMA controllers on the A523 SoC
family, however it seems it that it is mainly routed to the MCU DMA
controller, with no obvious way to change it.
Change the DMA channels of r-spi to the MCU so that it works properly.
Fixes: 1bec3bd1f839 ("arm64: dts: allwinner: sun55i: Add SPI controllers")
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://patch.msgid.link/20260323171927.1256507-1-wens@kernel.org
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
|
|
Enable the generic power control driver module since it's required
to power up the PCIe USB3 controller found on the Ayaneo Pocket S2
gaming console.
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20260319-topic-sm8650-ayaneo-pocket-s2-base-v6-1-797bf96df771@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Instead of exposing the x86-optimized SM3 code via an x86-specific
crypto_shash algorithm, instead just implement the sm3_blocks() library
function. This is much simpler, it makes the SM3 library functions be
x86-optimized, and it fixes the longstanding issue where the
x86-optimized SM3 code was disabled by default. SM3 still remains
available through crypto_shash, but individual architectures no longer
need to handle it.
Tweak the prototype of sm3_transform_avx() to match what the library
expects, including changing the block count to size_t. Note that the
assembly code actually already treated this argument as size_t.
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20260321040935.410034-10-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Instead of exposing the riscv-optimized SM3 code via a riscv-specific
crypto_shash algorithm, instead just implement the sm3_blocks() library
function. This is much simpler, it makes the SM3 library functions be
riscv-optimized, and it fixes the longstanding issue where the
riscv-optimized SM3 code was disabled by default. SM3 still remains
available through crypto_shash, but individual architectures no longer
need to handle it.
Tweak the prototype of sm3_transform_zvksh_zvkb() to match what the
library expects, including changing the block count to size_t.
Note that the assembly code already treated it as size_t.
Note: to see the diff from arch/riscv/crypto/sm3-riscv64-glue.c to
lib/crypto/riscv/sm3.h, view this commit with 'git show -M10'.
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20260321040935.410034-9-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Instead of exposing the arm64-optimized SM3 code via arm64-specific
crypto_shash algorithms, instead just implement the sm3_blocks() library
function. This is much simpler, it makes the SM3 library functions be
arm64-optimized, and it fixes the longstanding issue where the
arm64-optimized SM3 code was disabled by default. SM3 still remains
available through crypto_shash, but individual architectures no longer
need to handle it.
Tweak the SM3 assembly function prototypes to match what the library
expects, including changing the block count from 'int' to 'size_t'.
sm3_ce_transform() had to be updated to access 'x2' instead of 'w2',
while sm3_neon_transform() already used 'x2'.
Remove the CFI stubs which are no longer needed because the SM3 assembly
functions are no longer ever indirectly called.
Remove the dependency on KERNEL_MODE_NEON. It was unnecessary, because
KERNEL_MODE_NEON is always enabled on arm64.
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20260321040935.410034-8-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
