| Age | Commit message (Collapse) | Author |
|---|
|
Add cooling-cells property to the CPU nodes to support cpufreq
cooling devices.
Signed-off-by: Dipa Mantre <dipa.mantre@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260415-cpufreq_kaanapali-v1-1-1fa94105d5c2@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Add gpio device nodes in pm8010*.dtsi files for any consumers to be
able to use the GPIOs.
Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260507-pm8010_gpio-v1-3-3bce9da8d2ba@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Move generic IPA-related properties to the base DTSI file.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Alex Elder <elder@riscstar.com>
Link: https://lore.kernel.org/r/20260517-ipa-loader-v1-7-3c3764c1b4a3@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Move generic IPA-related properties to the base DTSI file. The herobrine
has special software configuration, so delete the memory-region property
which wasn't set for it beforehand. Also delete the property for several
IoT devices, which don't enable IPA memory at this point (and don't
seem to have IPA supported by the modem firmware).
Co-developed-by: Stanislav Zaikin <zstaseg@gmail.com>
Signed-off-by: Stanislav Zaikin <zstaseg@gmail.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Alex Elder <elder@riscstar.com>
Link: https://lore.kernel.org/r/20260517-ipa-loader-v1-6-3c3764c1b4a3@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Move generic IPA-related properties to the base DTSI file.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Alex Elder <elder@riscstar.com>
Link: https://lore.kernel.org/r/20260517-ipa-loader-v1-5-3c3764c1b4a3@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Move generic IPA-related properties to the base DTSI file.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Alex Elder <elder@riscstar.com>
Link: https://lore.kernel.org/r/20260517-ipa-loader-v1-3-3c3764c1b4a3@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Move generic IPA-related properties to the base DTSI file.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Alex Elder <elder@riscstar.com>
Link: https://lore.kernel.org/r/20260517-ipa-loader-v1-2-3c3764c1b4a3@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Move generic IPA-related properties to the base DTSI file.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Alex Elder <elder@riscstar.com>
Link: https://lore.kernel.org/r/20260517-ipa-loader-v1-1-3c3764c1b4a3@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
The sa8775p-ride board development mostly happened back to year 2023,
and it hadn't got any major update since then, except Wasim's refactor[1]
last year which had no functional change for the board.
Propose to stop maintaining the board for reasons below.
- The Lemans development had moved to QCS9100/9075 EVK and Ride board
for a long time.
- Qualcomm stopped maintaining Meta Build (NHLOS firmware) for this target
years ago. There is not too much point to continuing maintaining the DT,
as DT usually depends on NHLOS firmware.
Link: https://lore.kernel.org/all/20250803110113.401927-1-wasim.nazir@oss.qualcomm.com/ [1]
Cc: Wasim Nazir <wasim.nazir@oss.qualcomm.com>
Cc: Shazad Hussain <shazad.hussain@oss.qualcomm.com>
Cc: Andrew Halaney <ahalaney@redhat.com>
Cc: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260520141457.988130-1-shengchao.guo@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Add the kaanpali nodes for the True Random Number Generator (TRNG).
Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260423-knp_rng-v1-1-9df6c0391a8f@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
The Inline Crypto Engine (ICE) exists as a standalone DT node, but the
UFS node lacks the required qcom,ice phandle reference.
Add the qcom,ice property to explicitly associate the UFS controller
with its ICE instance.
Fixes: d288abc3a70e ("arm64: dts: qcom: sm8750: Add UFS nodes for SM8750 SoC")
Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
Tested-by: Wenjia Zhang <wenjia.zhang@oss.qualcomm.com> # on sm8750-mtp
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260429-sm8750_ice_dt_fix-v1-1-2540dc337082@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Add device nodes for display: MDSS, DPU, DSI and DSI PHY.
DisplayPort is not added for now.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Link: https://lore.kernel.org/r/20260501-milos-mdss-v3-9-58bfc58c0e13@fairphone.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
by EFI
Remove reservations from reserved-memory which are already covered by
the EFI memmap. AFAICT there is no need to have these in the DT and chances
are that they might change with a BIOS update, so lets drop them.
hyp_elf_package_mem + ncc_mem are together covered by
efi: 0x000080800000-0x000080dfffff [Reserved |
xbl_dtlog_mem is covered by:
efi: 0x000081a00000-0x000081a3ffff [Reserved |
pdp_ns_shared_mem is covered by:
efi: 0x000081e00000-0x000081efffff [Reserved |
gpu_prr_mem + tpm_control_mem are together covered by:
efi: 0x000081f00000-0x000081f1ffff [Reserved |
usb_ucsi_shared_mem is covered by:
efi: 0x000081f20000-0x000081f2ffff [Reserved |
pld_pep_mem + pld_gmu_mem + pld_pdp_mem are together covered by:
efi: 0x000081f30000-0x000081f37fff [Reserved |
tz_stat_mem is covered by:
efi: 0x000082700000-0x0000827fffff [Reserved |
xbl_tmp_buffer_mem is covered by:
efi: 0x000082800000-0x0000829bffff [Reserved |
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260525114749.5939-3-johannes.goede@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
The EFI memtable (shown when booting with efi=debug) shows that the
xbl_tmp_buffer_mem region size is 0x1c0000 bytes large not 0xc00000 bytes:
efi: 0x000082800000-0x0000829bffff [Reserved |
efi: 0x0000829c0000-0x000083efffff [Conventional|
This fix aligns the size with the EFI reported size and makes /proc/iomem
correctly show mem blocks matching the EFI memmap:
82800000-829bffff : reserved
829c0000-83efffff : System RAM
Instead of:
82800000-833fffff : reserved
83400000-83efffff : System RAM
before this change
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260525114749.5939-2-johannes.goede@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Enable EC_QCOM_HAMOA as a module to support the embedded controller
found on Qualcomm CRD reference devices such as Hamoa and Glymur.
Reviewed-by: Pankaj Patil <pankaj.patil@oss.qualcomm.com>
Signed-off-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Tested-by: Anthony Ruhier <aruhier@mailbox.org>
Link: https://lore.kernel.org/r/20260511-add-driver-for-ec-v9-6-e5437c39b7f8@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Add embedded controller node for Hamoa IOT EVK boards which adds fan
control, temperature sensors, access to EC internal state changes and
suspend entry/exit notifications to the EC.
Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
Tested-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
Co-developed-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
Signed-off-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
Tested-by: Anthony Ruhier <aruhier@mailbox.org>
Link: https://lore.kernel.org/r/20260511-add-driver-for-ec-v9-5-e5437c39b7f8@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Add embedded controller node for Hamoa/Purwa CRDs which adds fan control,
temperature sensors, access to EC internal state changes and suspend
entry/exit notifications to the EC.
Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Co-developed-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
Signed-off-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
Tested-by: Anthony Ruhier <aruhier@mailbox.org>
Link: https://lore.kernel.org/r/20260511-add-driver-for-ec-v9-4-e5437c39b7f8@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Add embedded controller node for Glymur CRDs which adds fan control,
temperature sensors, access to EC state changes through SCI events
and suspend entry/exit notifications to the EC.
Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Co-developed-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
Signed-off-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
Tested-by: Anthony Ruhier <aruhier@mailbox.org>
Link: https://lore.kernel.org/r/20260511-add-driver-for-ec-v9-3-e5437c39b7f8@oss.qualcomm.com
[bjorn: Added i2c alias for &i2c9]
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Add the interconnect paths to enable drivers to vote on them, ensuring
the necessary NoC bandwidth is available.
This hasn't been done before, as prior to commit 05566ebcc0cd
("clk: qcom: gcc-x1e80100: Keep GCC USB QTB clock always ON"), this
would cause an inexplicable crash upon resume from system suspend.
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260410-topic-hamoa_usb_icc-v1-1-461e64304067@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Add the touchscreen device node for the HTC One (M8).
The downstream vendor kernel used an I2C frequency of 384 kHz
for this bus. Use the same value as the vendor.
Signed-off-by: Alexandre Messier <alex@me.ssier.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260406-m8-dts-additions-v2-4-c4c4bd50af48@me.ssier.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Add the required pin configuration to enable Bluetooth.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Alexandre Messier <alex@me.ssier.org>
Link: https://lore.kernel.org/r/20260406-m8-dts-additions-v2-3-c4c4bd50af48@me.ssier.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Add the NFC chip used in the HTC One M8 to its device tree.
The downstream vendor kernel used an I2C frequency of 384 kHz
for this bus. Use the same value as the vendor.
Signed-off-by: Alexandre Messier <alex@me.ssier.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260406-m8-dts-additions-v2-2-c4c4bd50af48@me.ssier.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Add support for the notification LEDs on the HTC One M8.
Two LEDs are available, one orange and one green. Together,
they both form a single notification source, so use a
multicolor LED node to describe this arrangement.
Cc: Lee Jones <lee@kernel.org>
Cc: Pavel Machek <pavel@kernel.org>
Cc: linux-leds@vger.kernel.org
Signed-off-by: Alexandre Messier <alex@me.ssier.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260406-m8-dts-additions-v2-1-c4c4bd50af48@me.ssier.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fix from Ingo Molnar:
- Prevent OOB access in the resctrl code while offlining
CPUs when Intel SNC (Sub-NUMA Clustering) is enabled
(Reinette Chatre)
* tag 'x86-urgent-2026-07-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86,fs/resctrl: Prevent out-of-bounds access while offlining CPU when SNC enabled
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull perf events fixes from Ingo Molnar:
- Fix a perf_event_attr::remove_on_exec bug for group events
(Taeyang Lee)
- Fix uprobes CALL emulation interaction with shadow stacks, and
add a testcase for this (David Windsor)
- Fix uprobes unregister bug (Jiri Olsa)
* tag 'perf-urgent-2026-07-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
uprobes/x86: Use proper mm_struct in __in_uprobe_trampoline
selftests/x86: Add shadow stack uprobe CALL test
x86/uprobes: Keep shadow stack in sync for emulated CALLs
perf/core: Detach event groups during remove_on_exec
|
|
Correct the MMIO ranges and IRQs for T8122 I2C controllers.
They were mistakenly incorrect in the original commit. This
fix is required for i2c dependent hardware to function
correctly, i.e. audio codecs.
Tested on J613 (MacBook Air M3).
Fixes: c65ab4905e58 ("arm64: dts: apple: Initial t8122 (M3) device trees")
Signed-off-by: Michael Reeves <michael.reeves077@gmail.com>
Link: https://patch.msgid.link/20260629-t8122-i2c-fix-v1-1-cec044001550@gmail.com
Signed-off-by: Sven Peter <sven@kernel.org>
|
|
Since this file just implements a hwrng driver, move it into
drivers/char/hw_random/. Rename the kconfig option accordingly as well.
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux
Pull MIPS fixes from Thomas Bogendoerfer.
* tag 'mips-fixes_7.2_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux:
MIPS: configs: Enable the current Ingenic USB PHY symbol
MIPS: loongson64: add IRQ work based on self-IPI
MIPS: mm: Add check for highmem before removing memory block
mips: Add build salt to the vDSO
MIPS: DEC: Ensure RTC platform device deregistration upon failure
|
|
The amd_uncore driver currently does not validate event groups and
allows creation of groups with more events than the number of available
hardware counters. Because of this, pmu->event_init() succeeds but
counter assignment fails later in pmu->add() which returns -EBUSY once
all counters are exhausted.
Address this by introducing group validation in the pmu->event_init()
path. Since the uncore PMUs have no per-event constraints and all
counters of a PMU are interchangeable, validation is reduced to just
counting the group members that target a PMU and ensuring that they fit
within the available set of counters.
Fixes: c43ca5091a37 ("perf/x86/amd: Add support for AMD NB and L2I "uncore" counters")
Signed-off-by: Sandipan Das <sandipan.das@amd.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://patch.msgid.link/750877d66e208603c3047f13eed6399625d43969.1782884387.git.sandipan.das@amd.com
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux
Pull RISC-V fixes from Paul Walmsley:
- Fix a crash when a kretprobe reads from the stack
- Fix an issue with the build-time mcount sorter that broke ftrace
- Fix the rv32 IRQ stack frame padding to match the ABI
- Only defer IOMMU configuration during initialization. This avoids an
issue where IOMMU configuration could be indefinitely deferred
- Add the missing build salt to the vDSO
- Now that RISC-V systems with higher numbers of cores are starting to
become available, raise NR_CPUS for RISC-V to 256
- Clean up some warnings from sparse caused by the RISC-V-optimized
RAID6 code
- Clean up our __cpu_up() code with a few minor fixes
* tag 'riscv-for-linus-7.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
riscv: probes: save original sp in rethook trampoline
riscv: Fix 32-bit call_on_irq_stack() frame pointer ABI
scripts/sorttable: Handle RISC-V patchable ftrace entries
riscv: smp: use secs_to_jiffies in __cpu_up
ACPI: RIMT: Only defer the IOMMU configuration in init stage
riscv: Add build salt to the vDSO
raid6: fix raid6_recov_rvv symbol undeclared warning
raid6: fix riscv symbol undeclared warnigns
riscv: Raise default NR_CPUS for 64BIT to 256
|
|
Fix all kernel-doc warnings in imr.c:
imr.c:300: warning: Function parameter or struct member 'rmask' not described in 'imr_add_range'
imr.c:300: warning: Function parameter or struct member 'wmask' not described in 'imr_add_range'
imr.c:300: warning: Excess function parameter 'read_mask' description in 'imr_add_range'
imr.c:300: warning: Excess function parameter 'write_mask' description in 'imr_add_range'
Fixes: 28a375df16c2 ("x86/intel/quark: Add Isolated Memory Regions for Quark X1000")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20250620065639.3348609-1-rdunlap@infradead.org
|
|
Along with RiscPC and SA1100, these are the last remaining Intel StrongARM
machines. The Corel NetWinder used to be particular popular in the late
1990s, but was discontinued during the bankruptcy of rebel.com in 2001.
The other machine is the DEC (later Intel) EBSA285 evaluation board that
was made in small numbers in 1997 for software developers.
The footbridge/netwinder platform was the main target for the first Debian
2.0 "Hamm" release on the Arm architecture back in 1998, but was dropped
in Debian 6.0 "Squeeze" in 2011, which only supported ARMv4T and higher
with the EABI based ports as ARMv4 hardware had fallen already out of
use by that time.
Link: http://netwinder.org/
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Russell King <linux@armlinux.org.uk>
Acked-by: Ralph Siemsen <ralphs@netwinder.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
This platform is the oldest still supported machine, dating back
to the original 1994 ARM610 version. The only currently supported
configuration uses an ARMv4 StrongARM but still requires building
for ARMv3 because of the board design not supporting 16-bit
data access.
ARMv3 support has been removed in gcc-9, and the gcc-8 release
is already old but still supported for building the kernel.
The only set of machines that lacks support for 16-bit load/store
instructions (Alpha EV5 and older) was recently removed from
the kernel.
Since there is little hope of this being maintainable much
longer, plan to remove it in early 2027 while it is still expected
to mostly work.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Most of the old StrongARM1100 machines were removed two years ago as part
of a wider cleanup, the remaining four were left either because someone
showed interest in converting them to devicetree, or because they were
still supported by qemu and therefore useful to keep the platform alive.
None of the devicetree conversion actually happened, and qemu has
marked the platform as deprecated, so do the same in the kernel now.
If anyone is still running one of these four machines and planning
to keep updating their kernels, please speak up now so we can adapt
the plans as needed.
If nobody is found using StrongARM1100 any more, it can be removing
during 2027, leaving 7.3-LTS as the last longterm support kernel
for it.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Kristoffer Ericson <kristoffer.ericson@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Conversion of the old orion5x board files to devicetree has
stalled over the past few years, so it seems better to remove
the remaining ones in order to allow cleaning up the device
drivers.
Debian and OpenWRT no longer support orion5x, and buildroot
could keep using linux-7.3-LTS for a few more years.
Jeremy Peper still plans to convert the Terastation 2 Pro
to devicetree in the future, but that can be done even
after it is removed.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
In the 2021 board file removal, the gumstix and sharpsl
support was left around in order to make it easier to convert
more of the PXA platform to device tree, given that both
platforms had some level of support in qemu.
As far as I can tell, nobody has worked on additional DT
conversion in that time, and qemu has in turn deprecated
the entire PXA platform.
Schedule the remaining board files for removal now, as they
are unlikely to be of any help in the future. If anyone
wants to revive support for these machines, they can
obviously still contribute device tree based code and
work on updating the corresponding drivers.
Any drivers that are only usable on legacy PXA board files
can also get removed along with the boards, or saved by
adding devicetree support.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
The Marvell Armada 510 (Dove) platform is supported both as devicetree
and atags/boardfile variants, with varying degrees of hardware support.
Russell was the last known user of the board file version, and there
are very few users overall. Unless Russell still needs this variant,
let's remove after the next LTS kernel, leaving the CONFIG_MACH_DOVE
variant with devicetree.
Reviewed-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
With no remaining users and support getting removed from future compilers,
there seems little point in keeping iwmmxt around much longer.
On the other hand, the iwmmxt support in the kernel rarely gets in the
way, so there is little cost, so set a removal date of early 2027 for
the moment. If anyone is still using this, it can be extended as long
there is binutils support.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
The help text is seriously outdated and predates the introduction of
VFP floating point units that were available as early as some ARM926
based systems.
Change the help text to reflect that this is now a legacy feature
and that it will go away along with OABI support in the future.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Ralph Siemsen <ralphs@netwinder.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Mark Brown is still using this machine for regular work, so it should
not be removed as originally scheduled.
Give the platform another year, with the option to extend it further
based on the state of ATAGS support next year.
I expect that we end up removing all of s3c64xx when either Mark has
moved his test setup to other hardware, or when all other ATAGS based
machines are getting removed.
Cc: Mark Brown <broonie@kernel.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
This configuration option is for the older boot method that preceeded
ATAGS. This was scheduled for removal back in 2001, but the removal
never happened, presumably because nobody cared enough to actually do it,
not because there are any users left.
Add "(DEPRECATED)' to the Kconfig line and update the timeline so we can
remove it next year along with the other options that are not scheduled
for that timeframe.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Following the deprecation of big-endian ARMv8 mode in arch/arm64 in commit
1cf89b6bf660 ("arm64: Kconfig: Make CPU_BIG_ENDIAN depend on BROKEN"),
this does the same for ARMv7 (and v6), leaving the code around but
disabled by default: There are no known products that make use of this
mode any more, and it only hangs around for testing that it still works.
At the moment, there are no known bugs with big-endian ARMv7 mode, but
it does break occasionally and require someone to fix it. By marking
the code as 'depends on BROKEN' now, it will no longer be covered by CI
testing. If any users remain, they can keep patching out the dependency
but are more likely to run into regressions.
The big-endian ARMv5 support (CONFIG_CPU_ENDIAN_BE32) in contrast is
still used on Intel IXP4xx platform, and is the only currently supported
mode there, so this one can still be enabled.
There is no timeline for actually removing the code at this point,
we will likely debate this if we ever remove IXP4xx support on arm,
or big-endian support on ARM64.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Only a very small number of machines remain that rely on
traditional board files with the ATAGS boot data instead
of devicetree, and we have not accepted new ones for
a decade.
Most of the remaining ones are on their way out of the
kernel, but the Kconfig option that controls ATAGS
is still enabled by default.
To reflect the actual status of ATAGS support and alert
the remaining users of upstream and out-of-tree platforms
with this, change it to being default-disabled and
add a dependency on CONFIG_EXPERT.
The board specific defconfig files that rely on ATAGS
are changed to turn on both EXPERT and ATAGS if they
were not doing that already, and the ones that explicitly
turned it off before no longer need to.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi> # OMAP
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
This CPU revision remains a special case as it is now incompatible
with CONFIG_SMP. Only the Nokia N8x0 is used in practice, and even
that one is fairly rare these days, so let's plan to remove all of
them after the 2026 LTS kernel release.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Vladimir Zapolskiy <vz@mleia.com> # Freescale i.MX31
Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi> # OMAP
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Support for SMP on ARM1136r0 has been broken for a while, and nobody
is working on fixing it. I had a plan to change ARMv6 support to no
longer coexist in a common kernel with ARMv7 CPUs but instead ARMv5 and
below. This would have addressed the problem, but after a recent mailing
list discussion, we concluded that an easier approach is to just forbid
ARM1136r0 CPU support on SMP-enabled kernels.
This mainly affects users of the Nokia N800/N810 tablets using an
OMAP2420 SoC, which is the only commercial product with an ARM1136r0
that is still supported by the kernel.
The other machines that are still in the same hardware catogory are:
- TI OMAP2420 H4 reference board
- TI OMAP2430 SDP software development platform
- Freescale/NXP i.MX31 Lite Development Kit
- Buglabs i.MX31 Bug 1.x prototype
- Arm Integrator/AP with CM1136JF-S core module
To my knowledge, none of these have any actual users aside from
reference boards being used to more easily test the platforms.
There are also a few ARM1136r1 machines, which implement the
ARMv6K SMP support (barriers, atomics and TLS):
- Eukrea CPUIMX35 reference platform
- Freescale/NXP i.MX35 Product Development Kit
- ARM Integrator/CP/IM-LT3 with ARM1136J Core Tile
- ARM Realview/EB with ARM1136J Core Tile
Again, these are mainly reference implementations rather than
actual products, but since they support ARMv6K, they should
continue to work correctly in SMP-enabled kernels. For the
ARM Core Tile, I have not found a datasheet but instead use
the revision based on what the respective virtual models
report.
All the other ARMv6 platforms use an ARM1176 with ARMv6K,
VMSAv7 and Trustzone support.
To avoid the broken configuration, annotate the ARM1136 based
machines with specific CPU_ARM1136R0 or CPU_ARM1136R2 symbols
in Kconfig and make the r0 variants depend on !SMP.
Link: https://lore.kernel.org/linux-arm-kernel/2831c5a6-cfbf-4fe0-b51c-0396e5b0aeb7@app.fastmail.com/T/
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi> # OMAP
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
As discussed on the mailing lists, there is no way to build OABI userspace
binaries any more since gcc-4.8, and now support is also getting dropped in
binutils, which will make it impossible to build pure OABI kernels at some
point in the future.
I found no evidence of anyone still sing OABI userspace on embedded systems
that keep getting kernel updates, but there are a few desktop-class machines
that date back to the 1990s using Intel StrongARM processors that were
supported by old versions of Debian, Red Hat or the official Corel
Netwinder distribution.
Add a much stricter Kconfig dependency for both native OABI and OABI_COMPAT
enabled kernels, only allowing either of them to be selected when building
a kernel that targets a StrongARM based machine.
Link: https://lore.kernel.org/lkml/2831c5a6-cfbf-4fe0-b51c-0396e5b0aeb7@app.fastmail.com/
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
On ARMv4 and ARMv5, the default is still to build for OABI, with
CONFIG_AEABI disabled, even though distros and toolchains no longer
support OABI as a target.
Change the default to EABI for all architecture levels and change
the defconfig entries as follows:
- All machines that used to explicitly enable EABI can drop that line now
- Machines that are likely to actually use old distros and had NWFPE
enabled in combination with OABI (rpc, footrbridge, netwinder,
assabet, neponset) explicitly turn it on now.
- Machines that already had both EABI and NWFPE disabled in defconfig
(spear3xx, spear6xx) were likely not usable with either OABI or
EABI and now use EABI instead implicitly, making it more likely that
they could work.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi> # OMAP
Acked-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
Pull xen fixes from Juergen Gross:
- rename function parameters and a comment related to
xen_exchange_memory() (Jan Beulich)
- replace __ASSEMBLY__ with __ASSEMBLER__ (Thomas Huth)
- add some sanity checking to the Xen pvcalls frontend driver (Michael
Bommarito)
- fix error handling in the Xen gntdev driver (Wentao Liang)
- fix several minor bugs in Xen related drivers (Yousef Alhouseen)
* tag 'for-linus-7.2a-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
x86/Xen: correct commentary and parameter naming of xen_exchange_memory()
xenbus: reject unterminated directory replies
xen/gntalloc: validate grant count before allocation
xen/gntalloc: make grant counters unsigned
xen/front-pgdir-shbuf: free grant reference head on errors
xen/gntdev: fix error handling in ioctl
xen: Replace __ASSEMBLY__ with __ASSEMBLER__ in header files
xen/pvcalls: bound backend response req_id before indexing rsp[]
|
|
Andrii reported an issue with optimized uprobes [1] that can clobber
redzone area with call instruction storing return address on stack
where user code may keep temporary data without adjusting rsp.
Fixing this by moving the optimized uprobes on top of 10-bytes nop
instruction, so we can squeeze another instruction to escape the
redzone area before doing the call, like:
lea -0x80(%rsp), %rsp
call tramp
Note the lea instruction is used to adjust the rsp register without
changing the flags.
We use nop10 and following transformation to optimized instructions
above and back as suggested by Peterz [2].
Optimize path (int3_update_optimize):
1) Initial state after set_swbp() installed the uprobe:
cc 2e 0f 1f 84 00 00 00 00 00
From offset 0 this is INT3 followed by the tail of the original
10-byte NOP.
After a previous unoptimization bytes 5..9 may still contain the
old call instruction, which remains valid for threads already there.
2) Rewrite the LEA tail and call displacement:
cc [8d 64 24 80 e8 d0 d1 d2 d3]
From offset 0 this traps on the uprobe INT3. Bytes 1..9 are not
executable entry points while byte 0 is trapped.
3) Publish the first LEA byte:
[48] 8d 64 24 80 e8 d0 d1 d2 d3
From offset 0 this is:
lea -0x80(%rsp), %rsp
call <uprobe-trampoline>
Unoptimize path (int3_update_unoptimize):
1) Initial optimized state:
48 8d 64 24 80 e8 d0 d1 d2 d3
Same as 3) above.
2) Trap new entries before restoring the NOP bytes:
[cc] 8d 64 24 80 e8 d0 d1 d2 d3
From offset 0 this traps. A thread that had already executed the
LEA can still reach the intact CALL at offset 5.
3) Restore bytes 1..4 of the original NOP while keeping byte 0 trapped
and byte 5 as CALL.
cc [2e 0f 1f 84] e8 d0 d1 d2 d3
From offset 0 this still traps. Offset 5 is still the CALL for any
thread that was already past the first LEA byte.
4) Publish the first byte of the original NOP:
[66] 2e 0f 1f 84 e8 d0 d1 d2 d3
From offset 0 this is the restored 10-byte NOP; the CALL opcode and
displacement are now only NOP operands. Offset 5 still decodes as
CALL for a thread that was already there.
Tthere is only a single target uprobe-trampoline for the given nop10
instruction address, so the CALL instruction will not be changed across
unoptimization/optimization cycles.
Therefore, any task that is preempted at the CALL instruction is guaranteed
to observe that CALL and not anything else.
Note as explained in [2] we need to use following nop10:
PF1 PF2 ESC NOPL MOD SIB DISP32
NOP10: 0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00 -- cs nopw 0x00000000(%rax,%rax,1)
which means we need to allow 0x2e prefix which maps to INAT_PFX_CS
attribute in is_prefix_bad function.
Also changing the uprobe syscall error when called out of uprobe
trampoline to -EPROTO, so we are able to detect the fixed kernel.
The optimized uprobe performance stays the same:
uprobe-nop : 3.129 ± 0.013M/s
uprobe-push : 3.045 ± 0.006M/s
uprobe-ret : 1.095 ± 0.004M/s
--> uprobe-nop10 : 7.170 ± 0.020M/s
uretprobe-nop : 2.143 ± 0.021M/s
uretprobe-push : 2.090 ± 0.000M/s
uretprobe-ret : 0.942 ± 0.000M/s
--> uretprobe-nop10: 3.381 ± 0.003M/s
usdt-nop : 3.245 ± 0.004M/s
--> usdt-nop10 : 7.256 ± 0.023M/s
[1] https://lore.kernel.org/bpf/20260509003146.976844-1-andrii@kernel.org/
[2] https://lore.kernel.org/bpf/20260518104306.GU3102624@noisy.programming.kicks-ass.net/#t
Closes: https://lore.kernel.org/bpf/20260509003146.976844-1-andrii@kernel.org/
Fixes: ba2bfc97b462 ("uprobes/x86: Add support to optimize uprobes")
Reported-by: Andrii Nakryiko <andrii@kernel.org>
Assisted-by: Codex:GPT-5.5
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Link: https://patch.msgid.link/20260703114917.238144-6-jolsa@kernel.org
|
|
When we do fork or clone without CLONE_VM the new process won't
have uprobe trampoline vma objects and at the same time it will
have optimized code calling that trampoline and crash.
Fixing this by allowing vma uprobe trampoline objects to be copied
on fork to the new process.
Fixes: ba2bfc97b462 ("uprobes/x86: Add support to optimize uprobes")
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Link: https://patch.msgid.link/20260703114917.238144-5-jolsa@kernel.org
|
