| Age | Commit message (Collapse) | Author |
|---|
|
SMCCC 1.1 and prior allows four registers to be sent back as a result
of an FF-A interface. SMCCC 1.2 increases the number of results that can
be sent back to 8 and 16 for 32-bit and 64-bit SMC/HVCs respectively.
FF-A 1.0 references SMCCC 1.2 (reference [4] on page xi) and FF-A 1.2
explicitly requires SMCCC 1.2 so it should be safe to use this version
unconditionally. Moreover, it is simpler to implement FF-A features
without having to worry about compatibility with SMCCC 1.1 and older.
SMCCC 1.2 requires that SMC32/HVC32 from aarch64 mode preserves x8-x30
but given that there is no reliable way to distinguish 32-bit/64-bit
calls, we assume SMC64 unconditionally. This has the benefit of being
consistent with the handling of calls that are passed through, i.e., not
proxied. (A cleaner solution will become available in FF-A 1.3.)
Update the FF-A initialization and host handler code to use SMCCC 1.2.
Signed-off-by: Per Larsen <perlarsen@google.com>
Acked-by: Will Deacon <will@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
Once the hypervisor negotiates the FF-A version with the host, it should
remain locked-in. However, it is possible to load FF-A as a module first
supporting version 1.1 and then 1.0.
Without this patch, the FF-A 1.0 driver will use 1.0 data structures to
make calls which the hypervisor will incorrectly interpret as 1.1 data
structures. With this patch, negotiation will fail.
This patch does not change existing functionality in the case where a
FF-A 1.2 driver is loaded after a 1.1 driver; the 1.2 driver will need
to use 1.1 in order to proceed.
Acked-by: Will Deacon <will@kernel.org>
Signed-off-by: Per Larsen <perlarsen@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
The config XEN_SAVE_RESTORE's only purpose is to select
HIBERNATE_CALLBACKS, when config XEN is set. The XEN config definition can
simply select HIBERNATE_CALLBACKS, though, and the definition of
XEN_SAVE_RESTORE can be dropped.
So, remove this indirection through XEN_SAVE_RESTORE and select
HIBERNATE_CALLBACKS directly. Also, drop the XEN_SAVE_RESTORE from the x86
xen config fragment.
No functional change intended with this clean-up.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@redhat.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20250829070402.159390-1-lukas.bulwahn@redhat.com>
|
|
The compiler flags for the compat vDSO are built manually as they are not
compatible with the ones from kbuild. CONFIG_WERROR is not respected.
Explicitly inherit -Werror from kbuild.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Signed-off-by: Will Deacon <will@kernel.org>
|
|
These warnings don't seem to trigger anymore. Probably due to the
introduction of the vdso/ header namespace. Nowadays these suppression
only hide real problems.
Re-enable the warnings.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Signed-off-by: Will Deacon <will@kernel.org>
|
|
Instead of testing the XENFEAT_auto_translated_physmap feature, just
use !xen_pv_domain() which is equivalent.
This has the advantage that a kernel not built with CONFIG_XEN_PV
will be smaller due to dead code elimination.
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20250826145608.10352-3-jgross@suse.com>
|
|
Rework xen_pv_domain() to no longer use the xen_domain_type variable,
but the artificial X86_FEATURE_XENPV cpu feature.
On non-x86 architectures xen_pv_domain() can be defined as "0".
This has the advantage that a kernel not built with CONFIG_XEN_PV
will be smaller due to dead code elimination.
Set the X86_FEATURE_XENPV feature very early, as xen_pv_domain() is
used rather early, too.
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20250826145608.10352-2-jgross@suse.com>
|
|
Add the sound card for monaco-evk board and verified playback
functionality using the max98357a I2S speaker amplifier and I2S
microphones. The max98357a speaker amplifier is connected via
High-Speed MI2S HS0 interface, while the microphones utilize the
Secondary MI2S interface and also enable required pin controller
gpios for audio.
Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250905192350.1223812-5-umang.chheda@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Add GPR(Generic Pack router) node along with
APM(Audio Process Manager) and PRM(Proxy resource
Manager) audio services.
Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250905192350.1223812-4-umang.chheda@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Monaco EVK is a single board computer, based on the Qualcomm
QCS8300 SoC, with the following features :
- Storage: 1 × 128 GB UFS, micro-SD card, EEPROMs for MACs,
and eMMC.
- Audio/Video, Camera & Display ports.
- Connectivity: RJ45 2.5GbE, WLAN/Bluetooth, CAN/CAN-FD.
- PCIe ports.
- USB & UART ports.
On top of Monaco EVK board additional mezzanine boards can be
stacked in future.
Add support for the following components :
- GPI (Generic Peripheral Interface) and QUPv3-0/1
controllers to facilitate DMA and peripheral communication.
- TCA9534 I/O expander via I2C to provide 8 additional GPIO
lines for extended I/O functionality.
- USB1 controller in device mode to support USB peripheral
operations. USB OTG mode will be enabled for USB1 controller
once the VBUS control based on ID pin is implemented in
hd3ss3220.c.
- Remoteproc subsystems for supported DSPs such as Audio DSP,
Compute DSP and Generic DSP, along with their corresponding
firmware.
- Configure nvmem-layout on the I2C EEPROM to store data for Ethernet
and other consumers.
- QCA8081 2.5G Ethernet PHY on port-0 and expose the
Ethernet MAC address via nvmem for network configuration.
It depends on CONFIG_QCA808X_PHY to use QCA8081 PHY.
- Support for the Iris video codec.
Written with inputs from :
Rakesh Kota <rakesh.kota@oss.qualcomm.com> - Regulators.
Nirmesh Kumar Singh <nirmesh.Singh@oss.qualcomm.com> - GPIO expander.
Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com> - GPI/QUP.
Mohd Ayaan Anwar <quic_mohdayaa@quicinc.com> - Ethernet.
Monish Chunara <quic_mchunara@quicinc.com> - EEPROM.
Vikash Garodia <quic_vgarodia@quicinc.com> - Iris Video codec.
Swati Agarwal <swati.agarwal@oss.qualcomm.com> - USB.
Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250905192350.1223812-3-umang.chheda@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Add the sound card node with tested playback over WSA8835 speakers,
digital on-board mics along with wcd9370 headset playabck and record.
Co-developed-by: Prasad Kumpatla <quic_pkumpatl@quicinc.com>
Signed-off-by: Prasad Kumpatla <quic_pkumpatl@quicinc.com>
Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250903151337.1037246-9-mohammad.rafi.shaik@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Add nodes for WSA8830 speakers and WCD9370 headset codec
on qcm6490-idp board and enable lpass macros along with
audio support pin controls.
Co-developed-by: Prasad Kumpatla <quic_pkumpatl@quicinc.com>
Signed-off-by: Prasad Kumpatla <quic_pkumpatl@quicinc.com>
Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250903151337.1037246-8-mohammad.rafi.shaik@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Add the sound card node with tested playback over WSA8835 speakers
and digital on-board mics.
Co-developed-by: Prasad Kumpatla <quic_pkumpatl@quicinc.com>
Signed-off-by: Prasad Kumpatla <quic_pkumpatl@quicinc.com>
Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250903151337.1037246-7-mohammad.rafi.shaik@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Add nodes for WSA8830 speakers amplifier on qcs6490-rb3gen2 board.
Enable lpass_wsa and lpass_va macros along with pinctrl settings
for audio.
Co-developed-by: Prasad Kumpatla <quic_pkumpatl@quicinc.com>
Signed-off-by: Prasad Kumpatla <quic_pkumpatl@quicinc.com>
Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250903151337.1037246-6-mohammad.rafi.shaik@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
audioreach
Enable LPASS macros (WSA, VA, RX, TX) and the lpass_tlmm clock required
for audioreach functionality. In audioreach solution mclk, npl, and fsgen
clocks are managed via the Q6PRM. On SC7280-based boards, the TX CORE
clock is used to drive both RX and WSA audio paths following as per
hardware design.
Co-developed-by: Prasad Kumpatla <quic_pkumpatl@quicinc.com>
Signed-off-by: Prasad Kumpatla <quic_pkumpatl@quicinc.com>
Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250903151337.1037246-5-mohammad.rafi.shaik@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Add WSA LPASS macro Codec along with SoundWire controller.
Co-developed-by: Prasad Kumpatla <quic_pkumpatl@quicinc.com>
Signed-off-by: Prasad Kumpatla <quic_pkumpatl@quicinc.com>
Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250903151337.1037246-4-mohammad.rafi.shaik@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Introduce qcs6490-audioreach.dtsi to support AudioReach architecture on
QCS6490 platforms. The existing ADSP Bypass DTSI files such as sc7280.dtsi,
which is tailored for ADSP Bypass architecture as they lack DSP-specific
nodes required for AudioReach. The new qcs6490-audioreach.dtsi file defines
nodes for AudioReach specific components such as APM (Audio Process
Manager), PRM (Proxy Resource Manager), and GPR (Generic Packet Router).
This change enable the audio from the legacy ADSP Bypass solution to
the AudioReach framework.
Co-developed-by: Prasad Kumpatla <quic_pkumpatl@quicinc.com>
Signed-off-by: Prasad Kumpatla <quic_pkumpatl@quicinc.com>
Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250903151337.1037246-3-mohammad.rafi.shaik@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
The minimum supported GCC version is 8.1, which supports flag output operands
and always defines __GCC_ASM_FLAG_OUTPUTS__ macro.
Remove code depending on __GCC_ASM_FLAG_OUTPUTS__ and use the "=@ccCOND" flag
output operand directly.
Use the equivalent "=@ccz" instead of "=@cce" flag output operand for
CMPXCHG8B and CMPXCHG16B instructions. These instructions set a single flag
bit - the Zero flag - and "=@ccz" is used to distinguish the CC user from
comparison instructions, where set ZERO flag indeed means that the values are
equal.
Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/20250905121723.GCaLrU04lP2A50PT-B@fat_crate.local
|
|
The CIX SKY1 SoC supports the integration of 8 I2C bus controllers and
2 I3C bus controllers.
Signed-off-by: Hongliang Yang <hongliang.yang@cixtech.com>
Signed-off-by: Jun Guo <jun.guo@cixtech.com>
Signed-off-by: Peter Chen <peter.chen@cixtech.com>
|
|
Support for parsing the topology on AMD/Hygon processors using CPUID leaf 0xb
was added in
3986a0a805e6 ("x86/CPU/AMD: Derive CPU topology from CPUID function 0xB when available").
In an effort to keep all the topology parsing bits in one place, this commit
also introduced a pseudo dependency on the TOPOEXT feature to parse the CPUID
leaf 0xb.
The TOPOEXT feature (CPUID 0x80000001 ECX[22]) advertises the support for
Cache Properties leaf 0x8000001d and the CPUID leaf 0x8000001e EAX for
"Extended APIC ID" however support for 0xb was introduced alongside the x2APIC
support not only on AMD [1], but also historically on x86 [2].
Similar to 0xb, the support for extended CPU topology leaf 0x80000026 too does
not depend on the TOPOEXT feature.
The support for these leaves is expected to be confirmed by ensuring
leaf <= {extended_}cpuid_level
and then parsing the level 0 of the respective leaf to confirm EBX[15:0]
(LogProcAtThisLevel) is non-zero as stated in the definition of
"CPUID_Fn0000000B_EAX_x00 [Extended Topology Enumeration]
(Core::X86::Cpuid::ExtTopEnumEax0)" in Processor Programming Reference (PPR)
for AMD Family 19h Model 01h Rev B1 Vol1 [3] Sec. 2.1.15.1 "CPUID Instruction
Functions".
This has not been a problem on baremetal platforms since support for TOPOEXT
(Fam 0x15 and later) predates the support for CPUID leaf 0xb (Fam 0x17[Zen2]
and later), however, for AMD guests on QEMU, the "x2apic" feature can be
enabled independent of the "topoext" feature where QEMU expects topology and
the initial APICID to be parsed using the CPUID leaf 0xb (especially when
number of cores > 255) which is populated independent of the "topoext" feature
flag.
Unconditionally call cpu_parse_topology_ext() on AMD and Hygon processors to
first parse the topology using the XTOPOLOGY leaves (0x80000026 / 0xb) before
using the TOPOEXT leaf (0x8000001e).
While at it, break down the single large comment in parse_topology_amd() to
better highlight the purpose of each CPUID leaf.
Fixes: 3986a0a805e6 ("x86/CPU/AMD: Derive CPU topology from CPUID function 0xB when available")
Suggested-by: Naveen N Rao (AMD) <naveen@kernel.org>
Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Cc: stable@vger.kernel.org # Only v6.9 and above; depends on x86 topology rewrite
Link: https://lore.kernel.org/lkml/1529686927-7665-1-git-send-email-suravee.suthikulpanit@amd.com/ [1]
Link: https://lore.kernel.org/lkml/20080818181435.523309000@linux-os.sc.intel.com/ [2]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537 [3]
|
|
Turns out that picking an idle CPU for floating interrupts has some
negative side effects. The guest will keep the IO workload on its CPU
and rather use an IPI from the interrupt CPU instead of moving workload.
For example a guest with 2 vCPUs and 1 fio process might run that fio on
vcpu1. If after diag500 both vCPUs are idle then vcpu0 is woken up. The
guest will then do an IPI from vcpu0 to vcpu1.
So lets change the heuristics and prefer the last CPU that went to
sleep. This one is likely still in halt polling and can be woken up
quickly.
This patch shows significant improvements in terms of bandwidth or
cpu consumption for fio and uperf workloads and seems to be a net
win.
Link: https://lore.kernel.org/linux-s390/20250904113927.119306-1-borntraeger@linux.ibm.com/
Reviewed-by: Christoph Schlameuß <schlameuss@de.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
|
|
This reverts commit 5a66087107b80ac4e58a94f37d9b8d12e22b4071.
m68k patches shouldn't go through the tty tree without the m68k
maintainer acking them first.
Cc: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The smdk5250 board has an ethernet port which is connected to bank 1
of the SROM controller. Describe it.
Signed-off-by: Henrik Grimler <henrik@grimler.se>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
|
|
According to public user manual for Exynos 5250 [1], the SROM
controller has 4 banks, at same addresses as for example Exynos
5410. Describe the bank memory map of the SoC.
[1] https://web.archive.org/web/20130921194458/http://www.samsung.com/global/business/semiconductor/file/product/Exynos_5_Dual_User_Manaul_Public_REV100-0.pdf
Signed-off-by: Henrik Grimler <henrik@grimler.se>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
|
|
Preferred style is to have comma separated tuples when multiple
addresses and sizes are defined in ranges. Therefore, change the
format to clarify the node.
Signed-off-by: Henrik Grimler <henrik@grimler.se>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
|
|
SBI_FWFT_MISALIGNED_DELEG needs hedeleg to be modified to delegate
misaligned load/store exceptions. Save and restore it during CPU
load/put.
Signed-off-by: Clément Léger <cleger@rivosinc.com>
Reviewed-by: Deepak Gupta <debug@rivosinc.com>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Reviewed-by: Atish Patra <atishp@rivosinc.com>
Link: https://lore.kernel.org/r/20250523101932.1594077-15-cleger@rivosinc.com
Signed-off-by: Anup Patel <anup@brainfault.org>
|
|
Add basic infrastructure to support the FWFT extension in KVM.
Signed-off-by: Clément Léger <cleger@rivosinc.com>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Reviewed-by: Atish Patra <atishp@rivosinc.com>
Link: https://lore.kernel.org/r/20250523101932.1594077-14-cleger@rivosinc.com
Signed-off-by: Anup Patel <anup@brainfault.org>
|
|
The logic of the headphone detect pin seems to be inverted, with this
change headphones actually output sound when plugged in.
Does not need workaround of using pin-switches to enable output.
Verified by checking /sys/kernel/debug/gpio.
Fixes: ae46756faff8 ("arm64: dts: rockchip: analog audio on Orange Pi 5")
Signed-off-by: Jimmy Hon <honyuenkwun@gmail.com>
Link: https://lore.kernel.org/r/20250904030150.986042-1-honyuenkwun@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
By default, the CPUs on RK3528 operates at 1.5GHz. Add CPU frequency and
voltage mapping to the device tree to enable dynamic scaling via cpufreq.
The OPP values come from downstream kernel[1], using a voltage close to
the actual frequency. Frequencies below 1.2GHz have been removed due to
the same voltage.
[1] https://github.com/rockchip-linux/kernel/blob/develop-5.10/arch/arm64/boot/dts/rockchip/rk3528.dtsi
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Link: https://lore.kernel.org/r/20250801080025.558935-2-amadeus@jmu.edu.cn
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Let enable HDMI input port.
Signed-off-by: Marcin Juszkiewicz <marcin@juszkiewicz.com.pl>
Link: https://lore.kernel.org/r/579370818ef3b70b57bc5b8846f3b330d091d9a4.1757068166.git.marcin@juszkiewicz.com.pl
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
FriendlyELEC NanoPC-T6 LTS schematics shows VCC_1V8_S3 being used to
power SPI NOR chip.
This fixes the following kernel message:
spi-nor spi5.0: supply vcc not found, using dummy regulator
Signed-off-by: Marcin Juszkiewicz <marcin@juszkiewicz.com.pl>
Link: https://lore.kernel.org/r/20250905-nanopc-t6-spi-nor-v2-1-098b476d9509@juszkiewicz.com.pl
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux
Pull RISC-V fixes from Paul Walmsley:
- LTO fix for clang when building with CONFIG_CMODEL_MEDLOW
- Fix for ACPI CPPC CSR read/write return values
- Several fixes for incorrect access widths in thread_info.cpu reads
- Fix an issue in __put_user_nocheck() that was causing the glibc
tst-socket-timestamp test to fail
- Initialize struct kexec_buf records in several kexec-related
functions, which were generating UBSAN warnings
- Two fixes for sparse warnings
* tag 'riscv-for-linus-6.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
riscv: Fix sparse warning about different address spaces
riscv: Fix sparse warning in __get_user_error()
riscv: kexec: Initialize kexec_buf struct
riscv: use lw when reading int cpu in asm_per_cpu
riscv, bpf: use lw when reading int cpu in bpf_get_smp_processor_id
riscv, bpf: use lw when reading int cpu in BPF_MOV64_PERCPU_REG
riscv: uaccess: fix __put_user_nocheck for unaligned accesses
riscv: use lw when reading int cpu in new_vmalloc_check
ACPI: RISC-V: Fix FFH_CPPC_CSR error handling
riscv: Only allow LTO with CMODEL_MEDANY
|
|
On SoCFPGA/Sodia board, mdio bus cannot be probed, so the PHY cannot be
found and the network device does not work.
```
stmmaceth ff702000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -19)
```
To probe the mdio bus, add "snps,dwmac-mdio" as compatible string of the
mdio bus. Also the PHY address connected to this board is 4. Therefore,
change to 4.
Cc: stable@vger.kernel.org # 6.3+
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
|
|
Add clock controller nodes for PERIC0 and PERIC1 blocks for USI nodes.
Signed-off-by: Denzeel Oliva <wachiturroxd150@gmail.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
|
|
Reorganize the Curve25519 library code:
- Build a single libcurve25519 module, instead of up to three modules:
libcurve25519, libcurve25519-generic, and an arch-specific module.
- Move the arch-specific Curve25519 code from arch/$(SRCARCH)/crypto/ to
lib/crypto/$(SRCARCH)/. Centralize the build rules into
lib/crypto/Makefile and lib/crypto/Kconfig.
- Include the arch-specific code directly in lib/crypto/curve25519.c via
a header, rather than using a separate .c file.
- Eliminate the entanglement with CRYPTO. CRYPTO_LIB_CURVE25519 no
longer selects CRYPTO, and the arch-specific Curve25519 code no longer
depends on CRYPTO.
This brings Curve25519 in line with the latest conventions for
lib/crypto/, used by other algorithms. The exception is that I kept the
generic code in separate translation units for now. (Some of the
function names collide between the x86 and generic Curve25519 code. And
the Curve25519 functions are very long anyway, so inlining doesn't
matter as much for Curve25519 as it does for some other algorithms.)
Link: https://lore.kernel.org/r/20250906213523.84915-11-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Curve25519 has both a library API and a crypto_kpp API. However, the
crypto_kpp API for Curve25519 had no users outside crypto/testmgr.c.
I.e., no non-test code ever passed "curve25519" to crypto_alloc_kpp().
Remove this unused code. We'll instead focus on the Curve25519 library
API (<crypto/curve25519.h>), which is a simpler and easier-to-use API
and is the API that is actually being used.
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> # m68k
Link: https://lore.kernel.org/r/20250906213523.84915-7-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Curve25519 is used only via the library API, not the crypto_kpp API. In
preparation for removing the unused crypto_kpp API for Curve25519,
remove the unused "curve25519-x86" kpp algorithm.
Note that the underlying x86_64 optimized Curve25519 code remains fully
supported and accessible via the library API.
It's also worth noting that even if the kpp support for Curve25519 comes
back later, there is no need for arch-specific kpp glue code like this,
as a single kpp algorithm that wraps the library API is sufficient.
Link: https://lore.kernel.org/r/20250906213523.84915-5-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Curve25519 is used only via the library API, not the crypto_kpp API. In
preparation for removing the unused crypto_kpp API for Curve25519,
remove the unused "curve25519-ppc64le" kpp algorithm.
Note that the underlying PowerPC optimized Curve25519 code remains fully
supported and accessible via the library API.
It's also worth noting that even if the kpp support for Curve25519 comes
back later, there is no need for arch-specific kpp glue code like this,
as a single kpp algorithm that wraps the library API is sufficient.
Link: https://lore.kernel.org/r/20250906213523.84915-4-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Curve25519 is used only via the library API, not the crypto_kpp API. In
preparation for removing the unused crypto_kpp API for Curve25519,
remove the unused "curve25519-neon" kpp algorithm.
Note that the underlying NEON optimized Curve25519 code remains fully
supported and accessible via the library API.
It's also worth noting that even if the kpp support for Curve25519 comes
back later, there is no need for arch-specific kpp glue code like this,
as a single kpp algorithm that wraps the library API is sufficient.
Link: https://lore.kernel.org/r/20250906213523.84915-3-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
The only user -- 8250_hp300 -- tests for CONFIG_HPDCA and CONFIG_HPAPCI.
It does not test for *_MODULE variants. That means that if someone sets
the configs to =m, the code is not compiled at all.
There is actually no point having these as tristate. Switch them to
bool.
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: linux-m68k@lists.linux-m68k.org
Link: https://lore.kernel.org/r/20250822104208.751191-1-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Move away from the legacy MSI domain setup, switch to use
msi_create_parent_irq_domain().
Signed-off-by: Nam Cao <namcao@linutronix.de>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/c7a6d8f27fd217021dea4daad777e81a525ae460.1754903590.git.namcao@linutronix.de
|
|
Move away from the legacy MSI domain setup, switch to use
msi_create_parent_irq_domain().
Signed-off-by: Nam Cao <namcao@linutronix.de>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/a4c2c363ac7b94fffc79d5b92086135be4c57e06.1754903590.git.namcao@linutronix.de
|
|
xive-specific data is stored in handler_data. This creates a mess, as xive
has to rely on child interrupt controller drivers to clean up this data, as
was done by 9a014f45688 ("powerpc/pseries/pci: Add a msi_free() handler to
clear XIVE data").
Instead, store xive-specific data in chip_data and untangle the child
drivers.
Signed-off-by: Nam Cao <namcao@linutronix.de>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/83968073022a4cc211dcbd0faccd20ec05e58c3e.1754903590.git.namcao@linutronix.de
|
|
Remove duplicate definition of ppc_msgsnd_sync() introduced in commit
b87ac0218355 ("powerpc: Introduce msgsnd/doorbell barrier primitives").
No functional change intended.
Signed-off-by: Gautam Menghani <gautam@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <riteshh@linux.ibm.com>
[maddy: Updated commit message to fixed checkpatch.pl warning]
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20250813122319.62278-1-gautam@linux.ibm.com
|
|
Remove legacy-of-mm-gpiochip.h header file. The above mentioned
file provides an OF API that's deprecated. There is no agnostic
alternatives to it and we have to open code the logic which was
hidden behind of_mm_gpiochip_add_data(). Note, most of the GPIO
drivers are using their own labeling schemas and resource retrieval
that only a few may gain of the code deduplication, so whenever
alternative is appear we can move drivers again to use that one.
As a side effect this change fixes a potential memory leak on
an error path, if of_mm_gpiochip_add_data() fails.
[Text copied from commit 34064c8267a6 ("powerpc/8xx: Drop
legacy-of-mm-gpiochip.h header")]
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/2f8f16eac72b9ec202b6e593939b44308891a661.1755519343.git.christophe.leroy@csgroup.eu
|
|
In order to drop legacy-of-mm-gpiochip dependency, first change the
44x GPIO driver to a proper platform driver.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/29d89aa43536714b193d9710301341f838fcb5b7.1755519343.git.christophe.leroy@csgroup.eu
|
|
Remove legacy-of-mm-gpiochip.h header file. The above mentioned
file provides an OF API that's deprecated. There is no agnostic
alternatives to it and we have to open code the logic which was
hidden behind of_mm_gpiochip_add_data(). Note, most of the GPIO
drivers are using their own labeling schemas and resource retrieval
that only a few may gain of the code deduplication, so whenever
alternative is appear we can move drivers again to use that one.
As a side effect this change fixes a potential memory leak on
an error path, if of_mm_gpiochip_add_data() fails.
[text copied from commit 34064c8267a6 ("powerpc/8xx:
Drop legacy-of-mm-gpiochip.h header")]
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/2662f24c539db393f11b27f0feae2dc14bb2f08f.1755518891.git.christophe.leroy@csgroup.eu
|
|
Include asm/syscalls.h to get the correct prototype for sys_ni_syscall()
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/e2215a515ae0e21393c50e2f38791a6567cf1dec.1755509195.git.christophe.leroy@csgroup.eu
|
|
SPRN_M_TWB contains the address of task PGD minus an offset which
compensates the offset required when accessing the kernel PGDIR.
However, since commit ac9f97ff8b32 ("powerpc/8xx: Inconditionally use
task PGDIR in DTLB misses") and commit 33c527522f39 ("powerpc/8xx:
Inconditionally use task PGDIR in ITLB misses") kernel PGDIR is not
used anymore in hot paths.
Remove this offset which was added by
commit fde5a9057fcf ("powerpc/8xx: Optimise access to swapper_pg_dir")
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
[maddy: Fixed checkpatch.pl warning for "pathes"]
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/9710d960b512996e64beebfd368cfeaadb28b3ba.1755509047.git.christophe.leroy@csgroup.eu
|
|
Commit 118c40b7b503 ("kbuild: require gcc-8 and binutils-2.30") raised
minimum GCC_VERSION and LD_VERSION.
Simplify powerpc build accordingly.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/b6b94cba7492c8581e8d5d25b15962e5ad7a37c2.1751366979.git.christophe.leroy@csgroup.eu
|
