| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Remove the "try-power-role = sink" property from all USB-C connectors.
The try mechanism is unnecessary and wastes time during connection.
Since power-role = "dual" is already configured, standard USB PD
negotiation is sufficient and more efficient.
Signed-off-by: Cosmo Chou <chou.cosmo@gmail.com>
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
|
|
The Meta Anacapa BMC is the DC-SCM (Data Center Secure Control
Module) controller for the Meta OCP Open Rack Wide (ORW) compute tray.
This platform is a key component of the AMD Helios AI rack reference
design system, designed for next-generation AI workloads.
The BMC utilizes the Aspeed AST2600 SoC to manage the compute tray, which
contains up to 4 AMD Instinct MI450 Series GPUs (connected via a Broadcom
OCP NIC) and host CPUs. Its primary role is to provide essential system
control, power sequencing, and telemetry reporting for the compute complex
via the OpenBMC software stack.
For more detail on the AMD Helios reference design:
https://www.amd.com/en/blogs/2025/amd-helios-ai-rack-built-on-metas-2025-ocp-design.html
Signed-off-by: Peter Shen <sjg168@gmail.com>
Link: https://patch.msgid.link/20251219091632.1598603-3-sjg168@gmail.com
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
|
|
Extend KVM's restriction on CPUID and feature MSR changes to disallow
updates while L2 is active in addition to rejecting updates after the vCPU
has run at least once. Like post-run vCPU model updates, attempting to
react to model changes while L2 is active is practically infeasible, e.g.
KVM would need to do _something_ in response to impossible situations where
userspace has a removed a feature that was consumed as parted of nested
VM-Enter.
In practice, disallowing vCPU model changes while L2 is active is largely
uninteresting, as the only way for L2 to be active without the vCPU having
run at least once is if userspace stuffed state via KVM_SET_NESTED_STATE.
And because KVM_SET_NESTED_STATE can't put the vCPU into L2 without
userspace first defining the vCPU model, e.g. to enable SVM/VMX, modifying
the vCPU model while L2 is active would require deliberately setting the
vCPU model, then loading nested state, and then changing the model. I.e.
no sane VMM should run afoul of the new restriction, and any VMM that does
encounter problems has likely been running a broken setup for a long time.
Cc: Yosry Ahmed <yosry.ahmed@linux.dev>
Cc: Kevin Cheng <chengkev@google.com>
Reviewed-by: Yosry Ahmed <yosry.ahmed@linux.dev>
Link: https://patch.msgid.link/20251230205641.4092235-1-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
If sbi_ecall.c's functions are traceable,
echo "__sbi_ecall:snapshot" > /sys/kernel/tracing/set_ftrace_filter
may get the kernel into a deadlock.
(Functions in sbi_ecall.c are excluded from tracing if
CONFIG_RISCV_ALTERNATIVE_EARLY is set.)
__sbi_ecall triggers a snapshot of the ringbuffer. The snapshot code
raises an IPI interrupt, which results in another call to __sbi_ecall
and another snapshot...
All it takes to get into this endless loop is one initial __sbi_ecall.
On RISC-V systems without SSTC extension, the clock events in
timer-riscv.c issue periodic sbi ecalls, making the problem easy to
trigger.
Always exclude the sbi_ecall.c functions from tracing to fix the
potential deadlock.
sbi ecalls can easiliy be logged via trace events, excluding ecall
functions from function tracing is not a big limitation.
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Link: https://patch.msgid.link/20251223135043.1336524-1-martin@kaiser.cx
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
SPARC T5-2 dts describes some PCI BARs as 64-bit resources without the
pref(etchable) bit (0x83... vs 0xc3... in assigned-addresses) for address
ranges above the 4G threshold. Such resources cannot be placed into a
non-prefetchable PCI bridge window that is capable only of 32-bit
addressing. As such, it looks like the platform is improperly described by
the dts.
The kernel detects this problem (see the IORESOURCE_PREFETCH check in
pci_find_parent_resource()) and fails to assign these BAR resources to the
resource tree due to lack of a compatible bridge window.
Prior to 754babaaf333 ("sparc/PCI: Remove pcibios_enable_device() as they
do nothing extra") SPARC arch code did not test whether device resources
were successfully in the resource tree when enabling a device, effectively
hiding the problem. After removing the arch-specific enable code,
pci_enable_resources() refuses to enable the device when it finds not all
mem resources are assigned, and therefore mpt3sas can't be enabled:
pci 0001:04:00.0: reg 0x14: [mem 0x801110000000-0x80111000ffff 64bit]
pci 0001:04:00.0: reg 0x1c: [mem 0x801110040000-0x80111007ffff 64bit]
pci 0001:04:00.0: BAR 1 [mem 0x801110000000-0x80111000ffff 64bit]: can't claim; no compatible bridge window
pci 0001:04:00.0: BAR 3 [mem 0x801110040000-0x80111007ffff 64bit]: can't claim; no compatible bridge window
mpt3sas 0001:04:00.0: BAR 1 [mem size 0x00010000 64bit]: not assigned; can't enable device
For clarity, this filtered log only shows failures for one mpt3sas device
but other devices fail similarly. In the reported case, the end result with
all the failures is an unbootable system.
Things appeared to "work" before 754babaaf333 ("sparc/PCI: Remove
pcibios_enable_device() as they do nothing extra") because the resource
tree is agnostic to whether PCI BAR resources are properly in the tree or
not. So as long as there was a parent resource (e.g. a root bus resource)
that contains the address range, the resource tree code just places
resource request underneath it without any consideration to the
intermediate BAR resource. While it worked, it's incorrect setup still.
Add an OF fixup to set the IORESOURCE_PREFETCH flag for a 64-bit PCI
resource that has the end address above 4G requiring placement into the
prefetchable window. Also log the issue.
Fixes: 754babaaf333 ("sparc/PCI: Remove pcibios_enable_device() as they do nothing extra")
Reported-by: Nathaniel Roach <nroach44@gmail.com>
Closes: https://github.com/sparclinux/issues/issues/22
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Nathaniel Roach <nroach44@gmail.com>
Link: https://patch.msgid.link/20251124170411.3709-1-ilpo.jarvinen@linux.intel.com
|
|
The arch/riscv/include/asm/bitops.h does not functionally require
including /linux/irqflags.h. Additionally, adding
arch/riscv/include/asm/percpu.h causes a circular inclusion:
kernel/bounds.c
->include/linux/log2.h
->include/linux/bitops.h
->arch/riscv/include/asm/bitops.h
->include/linux/irqflags.h
->include/linux/find.h
->return val ? __ffs(val) : size;
->arch/riscv/include/asm/bitops.h
The compilation log is as follows:
CC kernel/bounds.s
In file included from ./include/linux/bitmap.h:11,
from ./include/linux/cpumask.h:12,
from ./arch/riscv/include/asm/processor.h:55,
from ./arch/riscv/include/asm/thread_info.h:42,
from ./include/linux/thread_info.h:60,
from ./include/asm-generic/preempt.h:5,
from ./arch/riscv/include/generated/asm/preempt.h:1,
from ./include/linux/preempt.h:79,
from ./arch/riscv/include/asm/percpu.h:8,
from ./include/linux/irqflags.h:19,
from ./arch/riscv/include/asm/bitops.h:14,
from ./include/linux/bitops.h:68,
from ./include/linux/log2.h:12,
from kernel/bounds.c:13:
./include/linux/find.h: In function 'find_next_bit':
./include/linux/find.h:66:30: error: implicit declaration of function '__ffs' [-Wimplicit-function-declaration]
66 | return val ? __ffs(val) : size;
| ^~~~~
Signed-off-by: Yunhui Cui <cuiyunhui@bytedance.com>
Acked-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
Link: https://patch.msgid.link/20251216014721.42262-2-cuiyunhui@bytedance.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
The print in sbi_cpu_stop() assumes smp_processor_id() returns an
unsigned int, when it is actually an int. Fix the format string to
avoid mismatch type warnings in rht pr_crit().
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Link: https://patch.msgid.link/20260102145839.657864-1-ben.dooks@codethink.co.uk
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
- Drop 'CONFIG_I2C_COMPAT is not set' (removed in commit 7e722083fcc3
("i2c: Remove I2C_COMPAT config symbol and related code"))
- Drop 'CONFIG_SCHED_DEBUG is not set' (removed in commit b52173065e0a
("sched/debug: Remove CONFIG_SCHED_DEBUG"))
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@redhat.com>
Link: https://patch.msgid.link/20260107092425.24737-1-lukas.bulwahn@redhat.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/dt
Renesas DTS updates for v6.20
- Add USB3.2 host and more RSCI serial support for the RZ/G3E SoC and
the RZ/G3E SMARC EVK board,
- Add display and USB3.0 host support for the RZ/V2H and RZ/V2N SoCs
and their EVK boards,
- Add SPI NOR Flash support for the Yuridenki-Shokai Kakip board,
- Add PCIe support for the RZ/G3S SoC and the RZ/G3S SMARC EVK board,
- Add SPI, interrupt controller, and DMAC support for the RZ/T2H,
RZ/N2H, and RZ/V2N SoCs,
- Add NMI wakeup button support for the RZ/V2N EVK board,
- Add thermal support for the RZ/V2N SoC,
- Add system watchdog timer support for R-Car V3H, which is reserved
for secure firmware,
- Add window watchdog timer support for R-Car V3M, V3H, and Gen4 SoCs,
- Miscellaneous fixes and improvements.
* tag 'renesas-dts-for-v6.20-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: (41 commits)
arm64: dts: renesas: r8a779h0: Add WWDT nodes
arm64: dts: renesas: r8a779g0: Add WWDT nodes
arm64: dts: renesas: r8a779f0: Add WWDT nodes
arm64: dts: renesas: r8a779a0: Add WWDT nodes
arm64: dts: renesas: r8a77980: Add WWDT nodes
arm64: dts: renesas: r8a77970: Add WWDT nodes
arm64: dts: renesas: condor/v3hsk: Mark SWDT as reserved
arm64: dts: renesas: r8a77980: Add SWDT node
arm64: dts: renesas: r9a09g056: Add TSU nodes
arm64: dts: renesas: r9a09g087: Add DMAC support
arm64: dts: renesas: r9a09g077: Add DMAC support
arm64: dts: renesas: r9a09g087: Add ICU support
arm64: dts: renesas: r9a09g077: Add ICU support
arm64: dts: renesas: r9a09g047e57-smarc: Enable rsci{2,4,9} nodes
arm64: dts: renesas: renesas-smarc2: Move aliases to board DTS
arm64: dts: renesas: r9a09g047: Add RSCI nodes
ARM: dts: renesas: r9a06g032: Add Ethernet switch interrupts
arm64: dts: renesas: r9a09g056n48-rzv2n-evk: Add NMI wakeup button support
arm64: dts: renesas: r9a09g056: Add RSPI nodes
arm64: dts: renesas: r9a09g056: Add DMAC nodes
...
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux into soc/dt
First batch of ASPEED Arm devicetree changes for 6.20
New platforms:
- NVIDIA MSX4 BMC
The NVIDIA MSX4 HPM (host platform module) is a reference board for
managing up to 8 PCIe connected NVIDIA GPUs via ConnectX-8 (CX8)
SuperNICs. The BMC manages all GPUs and CX8s for both telemetry and
firmware update via MCTP over USB. The host CPUs are dual socket Intel
Granite Rapids processors.
For more detail on this architecture:
https://developer.nvidia.com/blog/nvidia-connectx-8-supernics-advance-ai-platform-architecture-with-pcie-gen6-connectivity/
Updated platforms:
- ast2600-evb (ASPEED): Various tidy-ups to address binding warnings
- bletchley (Meta): Watchdog fix, tidy-ups to address binding warnings
- clemente (Meta): HDD LED fix, GPIO line names, EEPROMs
- harma (Meta): fanboard presence GPIO
- santabarbara (Meta): IPMB, GPIO line names, additional IO expander
* tag 'aspeed-6.20-devicetree-0' of https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux:
ARM: dts: aspeed: bletchley: Fix ADC vref property names
ARM: dts: aspeed: bletchley: Remove unused i2c13 property
ARM: dts: aspeed: bletchley: Remove unused pca9539 properties
ARM: dts: aspeed: bletchley: Fix SPI GPIO property names
ARM: dts: aspeed: bletchley: Use generic node names
ARM: dts: aspeed: g6: Drop clocks property from arm,armv7-timer
ARM: dts: aspeed: ast2600-evb: Tidy up A0 work-around for UART5
ARM: dts: aspeed: g6: Drop unspecified aspeed,ast2600-udma node
ARM: dts: aspeed: Drop syscon compatible from EDAC in g6 dtsi
ARM: dts: aspeed: Use specified wp-inverted property for AST2600 EVB
ARM: dts: aspeed: Remove sdhci-drive-type property from AST2600 EVB
ARM: dts: aspeed: Add NVIDIA MSX4 HPM
dt-bindings: arm: aspeed: Add NVIDIA MSX4 board
ARM: dts: aspeed: clemente: move hdd_led to its own gpio-leds group
ARM: dts: aspeed: clemente: add gpio line name to io expander
ARM: dts: aspeed: santabarbara: Enable ipmb device for OCP debug card
ARM: dts: aspeed: santabarbara: Add swb IO expander and gpio line names
ARM: dts: aspeed: clemente: Add EEPROMs for boot and data drive FRUs
ARM: dts: aspeed: harma: add fanboard presence sgpio
ARM: dts: aspeed: bletchley: remove WDTRST1 assertion from wdt1
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
https://github.com/Broadcom/stblinux into soc/dt
This pull request contains Broadcom ARM64-based SoCs Device Tre updates
for 6.19, please pull the following:
- Peter enables the random number generator on BCM2712
- Stanimir adds the watchdog Device Tree node for BCM2712
* tag 'arm-soc/for-6.19/devicetree-arm64' of https://github.com/Broadcom/stblinux:
arm64: dts: broadcom: bcm2712: Add watchdog DT node
arm64: dts: broadcom: bcm2712: Enable RNG
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
"snps,tx_de_emphasis*" properties
"snps,tx_de_emphasis" is supposed to be a u8, not a u32. Since it is big
endian, 0 will be read rather than 1. The DWC3 Linux driver simply ORs
the value if "snps,tx_de_emphasis_quirk" is set, so the 2 properties
have no effect. (The driver doesn't clear the field either which is
another problem).
"snps,gctl-reset-quirk" is not documented nor used in the driver, so
drop it as well.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20260105174002.2997615-1-robh@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
A "regulator-gpio" must have a GPIO control, hence the name. There's no
GPIO on a couple of Marvell platforms at least as far as the DT is
defined, so change the regulator type from GPIO to fixed.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
|
|
"nxp,pca9536"
The PCA9536 is always a GPIO provider, so add the missing properties.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes
i.MX fixes for 6.19:
- A mba8mx fix from Alexander Stein to correct Ethernet PHY IRQ trigger
type
- An i.MX95 fix from Carlos Song to correct I3C2 pclk
- A couple of imx8qm-mek changes from Haibo Chen to fix light sensor
interrupt type and usdhc2 regulator configuration
- An imx6q-ba16 change from Ian Ray to fix RTC interrupt level
- An imx8mp-dhcom-som change from Marek Vasut to fix sporadic Ethernet
link bouncing caused by interruptions on the PHY reference clock
- A couple of imx8mp-tx8p changes from Maud Spierings to fix compatible
and eqos nvmem-cells
- An ARM i.MX fix from Rob Herring to correct mc13xxx LED node names
- An imx8qm-ss-dma change from Sherry Sun to correct DMA channels for
LPUART
- A couple of imx95-toradex-smarc changes from Vitor Soares to fix
ethphy1 interrupt and SMARC_SDIO_WP label position
* tag 'imx-fixes-6.19' of https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
arm64: dts: mba8mx: Fix Ethernet PHY IRQ support
arm64: dts: imx8qm-ss-dma: correct the dma channels of lpuart
arm64: dts: imx8mp: Fix LAN8740Ai PHY reference clock on DH electronics i.MX8M Plus DHCOM
arm64: dts: freescale: tx8p-ml81: fix eqos nvmem-cells
arm64: dts: freescale: moduline-display: fix compatible
dt-bindings: arm: fsl: moduline-display: fix compatible
ARM: dts: imx6q-ba16: fix RTC interrupt level
arm64: dts: freescale: imx95-toradex-smarc: fix SMARC_SDIO_WP label position
arm64: dts: freescale: imx95-toradex-smarc: use edge trigger for ethphy1 interrupt
arm64: dts: add off-on-delay-us for usdhc2 regulator
arm64: dts: imx8qm-mek: correct the light sensor interrupt type to low level
ARM: dts: nxp: imx: Fix mc13xxx LED node names
arm64: dts: imx95: correct I3C2 pclk to IMX95_CLK_BUSWAKEUP
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
There's several cases of "pinctrl-names" used without any "pinctrl-0"
properties. Drop them.
Fix the typo "pintrl-names" as well.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
|
|
The "usb-nop-xceiv" binding requires "#phy-cells" property with a value
of 0 though it is not really used. Add it where missing from Marvell
platforms.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
|
|
https://github.com/Broadcom/stblinux into arm/fixes
This pull request contains Broadcom ARM64-SoC Device Tree fixes for
6.19, please pull the following:
- Andrea fixes the RP1 DeviceTree hierarchy and drop overlay support,
this resolves a number of DTC warnings and other issues
* tag 'arm-soc/for-6.19/devicetree-arm64-fixes' of https://github.com/Broadcom/stblinux:
arm64: dts: broadcom: rp1: drop RP1 overlay
arm64: dts: broadcom: bcm2712: fix RP1 endpoint PCI topology
misc: rp1: drop overlay support
dt-bindings: misc: pci1de4,1: add required reg property for endpoint
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
In the same spirit as e.g. Commit 6314184be391 ("arm64: dts: qcom:
sc8180x: Drop ipa-virt interconnect") drop the resources that should
be taken care of through the clk-rpmh driver.
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250627-topic-qcs615_icc_ipa-v1-1-dc47596cde69@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Instead of patching a single location potentially multiple times in case of
nested ALTERNATIVE()s, do the patching only after having evaluated all
alt_instr instances for that location.
This has multiple advantages:
- In case of replacing an indirect with a direct call using the
ALT_FLAG_DIRECT_CALL flag, there is no longer the need to have that
instance before any other instances at the same location (the
original instruction is needed for finding the target of the direct
call).
This issue has been hit when trying to do paravirt patching similar
to the following:
ALTERNATIVE_2(PARAVIRT_CALL, // indirect call
instr, feature, // native instruction
ALT_CALL_INSTR, X86_FEATURE_XENPV) // Xen function
In case "feature" was true, "instr" replaced the indirect call. Under
Xen PV the patching to have a direct call failed, as the original
indirect call was no longer there to find the call target.
- In case of nested ALTERNATIVE()s there is no intermediate replacement
visible. This avoids any problems in case e.g. an interrupt is
happening between the single instances and the patched location is
used during handling the interrupt.
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20260105080452.5064-3-jgross@suse.com
|
|
Tidy up apply_alternatives() by moving the main patching action of a single
alternative instance into 3 helper functions:
- analyze_patch_site() for selection whether patching should occur or not and
to handle nested alternatives.
- prep_patch_site() for applying any needed relocations and issuing debug
prints for the site.
- patch_site() doing the real patching action, including optimization of any
padding NOPs.
In prep_patch_site() use __apply_relocation() instead of
text_poke_apply_relocation(), as the NOP optimization is now done in
patch_site() for all cases.
Suggested-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20260105080452.5064-2-jgross@suse.com
|
|
The DTS code coding style expects lowercase hex for values and unit
addresses.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://patch.msgid.link/20251223152510.155463-4-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
|
|
DTS coding style prefers hyphens instead of underscores in the node
names. Change should be safe, because node names are not considered an
ABI.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://patch.msgid.link/20251223152510.155463-3-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
|
|
Commit 85b21fdec906e ("thermal/drivers/generic-adc: Register thermal
zones as hwmon sensors") made "generic-adc-thermal" also register hwmon
attributes. That means we now have the temperature sensor shown twice:
- once from iio-hwmon
- and another time from generic-adc-thermal
We need the latter for SoC temperature control, so simply drop the
former so userspace doesn't see duplicate sensors. Also
generic-adc-thermal provides a better name to userspace
("soc_thermal-virtual-0") than iio_hwmon.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://patch.msgid.link/20251108211503.1578711-1-martin.blumenstingl@googlemail.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
|
|
The value of FPEX32_EL2 has no effect on execution in AArch64 state, and
consequently there's no need for an ISB after writing to it in the hyp
code (which executes in AArch64 state). When performing an exception
return to AArch32 state, the exception return will provide the necessary
context synchronization event.
Remove the redundant ISB.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Fuad Tabba <tabba@google.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Oliver Upton <oliver.upton@linux.dev>
Cc: Will Deacon <will@kernel.org>
Tested-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260106173707.3292074-4-mark.rutland@arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
There's a gap in the KVM_HOST_DATA_FLAG_* indices since the removal of
KVM_HOST_DATA_FLAG_HOST_SVE_ENABLED and
KVM_HOST_DATA_FLAG_HOST_SME_ENABLED in commits:
* 459f059be702 ("KVM: arm64: Remove VHE host restore of CPACR_EL1.ZEN")
* 407a99c4654e ("KVM: arm64: Remove VHE host restore of CPACR_EL1.SMEN")
Shuffle the indices to remove the gap, as Oliver requested at the time of
the removals:
https://lore.kernel.org/linux-arm-kernel/Z6qC4qn47ONfDCSH@linux.dev/
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Fuad Tabba <tabba@google.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Oliver Upton <oliver.upton@linux.dev>
Cc: Will Deacon <will@kernel.org>
Tested-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://patch.msgid.link/20260106173707.3292074-3-mark.rutland@arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
The comment in fpsimd_lazy_switch_to_host() erroneously says guest traps
for FPSIMD/SVE/SME are disabled by fpsimd_lazy_switch_to_guest(). In
reality, the traps are disabled by __activate_cptr_traps(), and
fpsimd_lazy_switch_to_guest() only manipulates the SVE vector length.
This was mistake; I accidentally copy+pasted the wrong function name in
commit:
59419f10045b ("KVM: arm64: Eagerly switch ZCR_EL{1,2}")
Fix the comment.
Fixes: 59419f10045b ("KVM: arm64: Eagerly switch ZCR_EL{1,2}")
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Fuad Tabba <tabba@google.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Oliver Upton <oliver.upton@linux.dev>
Cc: Will Deacon <will@kernel.org>
Tested-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260106173707.3292074-2-mark.rutland@arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
In order to enable the HDMI output support on Mediatek Genio 510-EVK,
700-EVK, and 1200-EVK boards, enable the driver for it in the default
configuration.
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
It's a requirement that DT overlays be applied at build time in order to
validate them as overlays are not validated on their own.
Add missing target for mt8395-radxa hd panel overlay.
Fixes: 4c8ff61199a7 ("arm64: dts: mediatek: mt8395-radxa-nio-12l: Add Radxa 8 HD panel")
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Acked-by: AngeloGioacchino Del Regno <angelogiaocchino.delregno@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
Build devicetree binaries for testing overlays and providing users
full dtb without using overlays for Bananapi R4 (pro) variants.
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
Build devicetree binaries for testing overlays and providing users
full dtb without using overlays.
Suggested-by: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Acked-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Fixes: a58c36806741 ("arm64: dts: mediatek: mt7988a-bpi-r4pro: Add mmc overlays")
Fixes: dec929e61a42 ("arm64: dts: mediatek: mt7988a-bpi-r4-pro: Add PCIe overlays")
Fixes: 714a80ced07a ("arm64: dts: mediatek: mt7988a-bpi-r4: Add dt overlays for sd + emmc")
Fixes: 312189ebb802 ("arm64: dts: mt7986: add overlay for SATA power socket on BPI-R3")
Fixes: 8e01fb15b815 ("arm64: dts: mt7986: add Bananapi R3")
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
DTS coding style prefers hyphens instead of underscores in the node
names. Change should be safe, because node names are not considered an
ABI.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
Leverage ARCH_HAS_DMA_MAP_DIRECT config option for coherent allocations as
well. This will bypass DMA ops for memory allocations that have been
pre-mapped.
Always set device bus_dma_limit when memory is pre-mapped. In some
architectures, like PowerPC, pmemory can be converted to regular memory via
daxctl command. This will gate the coherent allocations to pre-mapped RAM
only, by dma_coherent_ok().
Signed-off-by: Gaurav Batra <gbatra@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20251107161105.85999-1-gbatra@linux.ibm.com
|
|
Inline the calls to bpf_get_smp_processor_id() and bpf_get_current_task/_btf()
in the powerpc bpf jit.
powerpc saves the Logical processor number (paca_index) and pointer
to current task (__current) in paca.
Here is how the powerpc JITed assembly changes after this commit:
Before:
cpu = bpf_get_smp_processor_id();
addis 12, 2, -517
addi 12, 12, -29456
mtctr 12
bctrl
mr 8, 3
After:
cpu = bpf_get_smp_processor_id();
lhz 8, 8(13)
To evaluate the performance improvements introduced by this change,
the benchmark described in [1] was employed.
+---------------+-------------------+-------------------+--------------+
| Name | Before | After | % change |
|---------------+-------------------+-------------------+--------------|
| glob-arr-inc | 40.701 ± 0.008M/s | 55.207 ± 0.021M/s | + 35.64% |
| arr-inc | 39.401 ± 0.007M/s | 56.275 ± 0.023M/s | + 42.42% |
| hash-inc | 24.944 ± 0.004M/s | 26.212 ± 0.003M/s | + 5.08% |
+---------------+-------------------+-------------------+--------------+
[1] https://github.com/anakryiko/linux/commit/8dec900975ef
Reviewed-by: Puranjay Mohan <puranjay@kernel.org>
Signed-off-by: Saket Kumar Bhaskar <skb99@linux.ibm.com>
Acked-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/89abfdd6f6721fbe7897865e74f2f691e5f7824a.1765343385.git.skb99@linux.ibm.com
|
|
With the introduction of commit 7bdbf7446305 ("bpf: add special
internal-only MOV instruction to resolve per-CPU addrs"),
a new BPF instruction BPF_MOV64_PERCPU_REG has been added to
resolve absolute addresses of per-CPU data from their per-CPU
offsets. This update requires enabling support for this
instruction in the powerpc JIT compiler.
As of commit 7a0268fa1a36 ("[PATCH] powerpc/64: per cpu data
optimisations"), the per-CPU data offset for the CPU is stored in
the paca.
To support this BPF instruction in the powerpc JIT, the following
powerpc instructions are emitted:
if (IS_ENABLED(CONFIG_SMP))
ld tmp1_reg, 48(13) //Load per-CPU data offset from paca(r13) in tmp1_reg.
add dst_reg, src_reg, tmp1_reg //Add the per cpu offset to the dst.
else if (src_reg != dst_reg)
mr dst_reg, src_reg //Move src_reg to dst_reg, if src_reg != dst_reg
To evaluate the performance improvements introduced by this change,
the benchmark described in [1] was employed.
Before Change:
glob-arr-inc : 41.580 ± 0.034M/s
arr-inc : 39.592 ± 0.055M/s
hash-inc : 25.873 ± 0.012M/s
After Change:
glob-arr-inc : 42.024 ± 0.049M/s
arr-inc : 55.447 ± 0.031M/s
hash-inc : 26.565 ± 0.014M/s
[1] https://github.com/anakryiko/linux/commit/8dec900975ef
Reviewed-by: Puranjay Mohan <puranjay@kernel.org>
Signed-off-by: Saket Kumar Bhaskar <skb99@linux.ibm.com>
Acked-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/667fdaa19c1564141f6cd82e75b2be86a42c0f96.1765343385.git.skb99@linux.ibm.com
|
|
Masked user access avoids the address/size verification by access_ok().
Allthough its main purpose is to skip the speculation in the
verification of user address and size hence avoid the need of spec
mitigation, it also has the advantage of reducing the amount of
instructions required so it even benefits to platforms that don't
need speculation mitigation, especially when the size of the copy is
not know at build time.
So implement masked user access on powerpc. The only requirement is
to have memory gap that faults between the top user space and the
real start of kernel area.
On 64 bits platforms the address space is divided that way:
0xffffffffffffffff +------------------+
| |
| kernel space |
| |
0xc000000000000000 +------------------+ <== PAGE_OFFSET
|//////////////////|
|//////////////////|
0x8000000000000000 |//////////////////|
|//////////////////|
|//////////////////|
0x0010000000000000 +------------------+ <== TASK_SIZE_MAX
| |
| user space |
| |
0x0000000000000000 +------------------+
Kernel is always above 0x8000000000000000 and user always
below, with a gap in-between. It leads to a 3 instructions sequence:
150: 7c 69 fe 76 sradi r9,r3,63
154: 79 29 00 40 clrldi r9,r9,1
158: 7c 63 48 78 andc r3,r3,r9
This sequence leaves r3 unmodified when it is below 0x8000000000000000
and clamps it to 0x8000000000000000 if it is above.
On 32 bits it is more tricky. In theory user space can go up to
0xbfffffff while kernel will usually start at 0xc0000000. So a gap
needs to be added in-between. Allthough in theory a single 4k page
would suffice, it is easier and more efficient to enforce a 128k gap
below kernel, as it simplifies the masking.
e500 has the isel instruction which allows selecting one value or
the other without branch and that instruction is not speculative, so
use it. Allthough GCC usually generates code using that instruction,
it is safer to use inline assembly to be sure. The result is:
14: 3d 20 bf fe lis r9,-16386
18: 7c 03 48 40 cmplw r3,r9
1c: 7c 69 18 5e iselgt r3,r9,r3
On other ones, when kernel space is over 0x80000000 and user space
is below, the logic in mask_user_address_simple() leads to a
3 instruction sequence:
64: 7c 69 fe 70 srawi r9,r3,31
68: 55 29 00 7e clrlwi r9,r9,1
6c: 7c 63 48 78 andc r3,r3,r9
This is the default on powerpc 8xx.
When the limit between user space and kernel space is not 0x80000000,
mask_user_address_32() is used and a 6 instructions sequence is
generated:
24: 54 69 7c 7e srwi r9,r3,17
28: 21 29 57 ff subfic r9,r9,22527
2c: 7d 29 fe 70 srawi r9,r9,31
30: 75 2a b0 00 andis. r10,r9,45056
34: 7c 63 48 78 andc r3,r3,r9
38: 7c 63 53 78 or r3,r3,r10
The constraint is that TASK_SIZE be aligned to 128K in order to get
the most optimal number of instructions.
When CONFIG_PPC_BARRIER_NOSPEC is not defined, fallback on the
test-based masking as it is quicker than the 6 instructions sequence
but not quicker than the 3 instructions sequences above.
As an exemple, allthough barrier_nospec() voids on the 8xx, this
change has the following impact on strncpy_from_user(): the length of
the function is reduced from 488 to 340 bytes:
Start of the function with the patch:
00000000 <strncpy_from_user>:
0: 7c ab 2b 79 mr. r11,r5
4: 40 81 01 40 ble 144 <strncpy_from_user+0x144>
8: 7c 89 fe 70 srawi r9,r4,31
c: 55 29 00 7e clrlwi r9,r9,1
10: 7c 84 48 78 andc r4,r4,r9
14: 3d 20 dc 00 lis r9,-9216
18: 7d 3a c3 a6 mtspr 794,r9
1c: 2f 8b 00 03 cmpwi cr7,r11,3
20: 40 9d 00 b4 ble cr7,d4 <strncpy_from_user+0xd4>
...
Start of the function without the patch:
00000000 <strncpy_from_user>:
0: 7c a0 2b 79 mr. r0,r5
4: 40 81 01 10 ble 114 <strncpy_from_user+0x114>
8: 2f 84 00 00 cmpwi cr7,r4,0
c: 41 9c 01 30 blt cr7,13c <strncpy_from_user+0x13c>
10: 3d 20 80 00 lis r9,-32768
14: 7d 24 48 50 subf r9,r4,r9
18: 7f 80 48 40 cmplw cr7,r0,r9
1c: 7c 05 03 78 mr r5,r0
20: 41 9d 01 00 bgt cr7,120 <strncpy_from_user+0x120>
24: 3d 20 80 00 lis r9,-32768
28: 7d 25 48 50 subf r9,r5,r9
2c: 7f 84 48 40 cmplw cr7,r4,r9
30: 38 e0 ff f2 li r7,-14
34: 41 9d 00 e4 bgt cr7,118 <strncpy_from_user+0x118>
38: 94 21 ff e0 stwu r1,-32(r1)
3c: 3d 20 dc 00 lis r9,-9216
40: 7d 3a c3 a6 mtspr 794,r9
44: 2b 85 00 03 cmplwi cr7,r5,3
48: 40 9d 01 6c ble cr7,1b4 <strncpy_from_user+0x1b4>
...
118: 7c e3 3b 78 mr r3,r7
11c: 4e 80 00 20 blr
120: 7d 25 4b 78 mr r5,r9
124: 3d 20 80 00 lis r9,-32768
128: 7d 25 48 50 subf r9,r5,r9
12c: 7f 84 48 40 cmplw cr7,r4,r9
130: 38 e0 ff f2 li r7,-14
134: 41 bd ff e4 bgt cr7,118 <strncpy_from_user+0x118>
138: 4b ff ff 00 b 38 <strncpy_from_user+0x38>
13c: 38 e0 ff f2 li r7,-14
140: 4b ff ff d8 b 118 <strncpy_from_user+0x118>
...
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/8f418183d9125cc0bf23922bc2ef2a1130d8b63a.1766574657.git.chleroy@kernel.org
|
|
At the time being, TASK_SIZE can be customized by the user via Kconfig
but it is not possible to check all constraints in Kconfig. Impossible
setups are detected at compile time with BUILD_BUG() but that leads
to build failure when setting crazy values. It is not a problem on its
own because the user will usually either use the default value or set
a well thought value. However build robots generate crazy random
configs that lead to build failures, and build robots see it as a
regression every time a patch adds such a constraint.
So instead of failing the build when the custom TASK_SIZE is too
big, just adjust it to the maximum possible value matching the setup.
Several architectures already calculate TASK_SIZE based on other
parameters and options.
In order to do so, move MODULES_VADDR calculation into task_size_32.h
and ensure that:
- On book3s/32, userspace and module area have their own segments (256M)
- On 8xx, userspace has its own full PGDIR entries (4M)
Then TASK_SIZE is guaranteed to be correct so remove related
BUILD_BUG()s.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/6a2575420770d075cd090b5a316730a2ffafdee4.1766574657.git.chleroy@kernel.org
|
|
For book3s/32 it is assumed that TASK_SIZE is a multiple of 256 Mbytes,
but Kconfig allows any value for TASK_SIZE.
In all relevant calculations, align TASK_SIZE to the upper 256 Mbytes
boundary.
Also use ASM_CONST() in the definition of TASK_SIZE to ensure it is
seen as an unsigned constant.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/8928d906079e156c59794c41e826a684eaaaebb4.1766574657.git.chleroy@kernel.org
|
|
user_read_access_begin() and user_write_access_begin() and
user_access_begin() are now very similar. Create a common
__user_access_begin() that takes direction as parameter.
In order to avoid a warning with the conditional call of
barrier_nospec() which is sometimes an empty macro, change it to a
do {} while (0).
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/2b4f9d4e521e0b56bf5cb239916b4a178c4d2007.1766574657.git.chleroy@kernel.org
|
|
{allow/prevent}_{read/write/read_write}_{from/to/}_user()
The six following functions have become simple single-line fonctions
that do not have much added value anymore:
- allow_read_from_user()
- allow_write_to_user()
- allow_read_write_user()
- prevent_read_from_user()
- prevent_write_to_user()
- prevent_read_write_user()
Directly call allow_user_access() and prevent_user_access(), it doesn't
reduce the readability and it removes unnecessary middle functions.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/70971f0ba81eab742a120e5bfdeff6b42d08fd98.1766574657.git.chleroy@kernel.org
|
|
Since commit 16132529cee5 ("powerpc/32s: Rework Kernel Userspace
Access Protection") the size parameter is unused on all platforms.
And the 'from' parameter has never been used.
Remove them.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/4552b00707923b71150ee47b925d6eaae1b03261.1766574657.git.chleroy@kernel.org
|
|
Commit 74e19ef0ff80 ("uaccess: Add speculation barrier to
copy_from_user()") added a redundant barrier_nospec() in
copy_from_user(), because powerpc is already calling
barrier_nospec() in allow_read_from_user() and
allow_read_write_user(). But on other architectures that
call to barrier_nospec() was missing. So change powerpc
instead of reverting the above commit and having to fix
other architectures one by one. This is now possible
because barrier_nospec() has also been added in
copy_from_user_iter().
Move barrier_nospec() out of allow_read_from_user() and
allow_read_write_user(). This will also allow reuse of those
functions when implementing masked user access which doesn't
require barrier_nospec().
Don't add it back in raw_copy_from_user() as it is already called
by copy_from_user() and copy_from_user_iter().
Fixes: 74e19ef0ff80 ("uaccess: Add speculation barrier to copy_from_user()")
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/f29612105c5fcbc8ceb7303808ddc1a781f0f6b5.1766574657.git.chleroy@kernel.org
|
|
This UAPI header contains declarations of internal kernel symbols.
Such declarations are invalid. Normally headers_check.pl would report
an error, but apparently its dependency on CC_CAN_LINK prevent its
execution on hexagon so far.
As the header does not expose any additional UAPI, just make it a
regular internal kernel header. asm-generic/signal.h will be used
for the UAPI automatically, the same as before.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Link: https://patch.msgid.link/20251223-uapi-nostdinc-v1-2-d91545d794f7@linutronix.de
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
|
|
The usage of BPF_TRAMP_F_ORIG_STACK in __arch_prepare_bpf_trampoline() is
wrong, and it should be BPF_TRAMP_F_CALL_ORIG, which caused crash as
Andreas reported:
Insufficient stack space to handle exception!
Task stack: [0xff20000000010000..0xff20000000014000]
Overflow stack: [0xff600000ffdad070..0xff600000ffdae070]
CPU: 1 UID: 0 PID: 1 Comm: systemd Not tainted 6.18.0-rc5+ #15 PREEMPT(voluntary)
Hardware name: riscv-virtio qemu/qemu, BIOS 2025.10 10/01/2025
epc : copy_from_kernel_nofault+0xa/0x198
ra : bpf_probe_read_kernel+0x20/0x60
epc : ffffffff802b732a ra : ffffffff801e6070 sp : ff2000000000ffe0
gp : ffffffff82262ed0 tp : 0000000000000000 t0 : ffffffff80022320
t1 : ffffffff801e6056 t2 : 0000000000000000 s0 : ff20000000010040
s1 : 0000000000000008 a0 : ff20000000010050 a1 : ff60000083b3d320
a2 : 0000000000000008 a3 : 0000000000000097 a4 : 0000000000000000
a5 : 0000000000000000 a6 : 0000000000000021 a7 : 0000000000000003
s2 : ff20000000010050 s3 : ff6000008459fc18 s4 : ff60000083b3d340
s5 : ff20000000010060 s6 : 0000000000000000 s7 : ff20000000013aa8
s8 : 0000000000000000 s9 : 0000000000008000 s10: 000000000058dcb0
s11: 000000000058dca7 t3 : 000000006925116d t4 : ff6000008090f026
t5 : 00007fff9b0cbaa8 t6 : 0000000000000016
status: 0000000200000120 badaddr: 0000000000000000 cause: 8000000000000005
Kernel panic - not syncing: Kernel stack overflow
CPU: 1 UID: 0 PID: 1 Comm: systemd Not tainted 6.18.0-rc5+ #15 PREEMPT(voluntary)
Hardware name: riscv-virtio qemu/qemu, BIOS 2025.10 10/01/2025
Call Trace:
[<ffffffff8001a1f8>] dump_backtrace+0x28/0x38
[<ffffffff80002502>] show_stack+0x3a/0x50
[<ffffffff800122be>] dump_stack_lvl+0x56/0x80
[<ffffffff80012300>] dump_stack+0x18/0x22
[<ffffffff80002abe>] vpanic+0xf6/0x328
[<ffffffff80002d2e>] panic+0x3e/0x40
[<ffffffff80019ef0>] handle_bad_stack+0x98/0xa0
[<ffffffff801e6070>] bpf_probe_read_kernel+0x20/0x60
Just fix it.
Fixes: 47c9214dcbea ("bpf: fix the usage of BPF_TRAMP_F_SKIP_FRAME")
Link: https://lore.kernel.org/bpf/20251219142948.204312-1-dongml2@chinatelecom.cn
Closes: https://lore.kernel.org/bpf/874ipnkfvt.fsf@igel.home/
Reported-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Menglong Dong <dongml2@chinatelecom.cn>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
|
According to RK3576 TRM part1 Table 1-1 Address Mapping, the size of
the GPU registers is 128 KB.
The current mapping incorrectly includes the addresses of multiple
following IP like the eInk interface at 0x27900000. This has not
been detected by the DT tooling as none of the extra mapped IP is
described in the upstream RK3576 DT so far.
Fixes: 57b1ce903966 ("arm64: dts: rockchip: Add rk3576 SoC base DT")
Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://patch.msgid.link/20260106071513.209-1-kernel@airkyi.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
NanoPi M5 derives its analog sound signal from SAI2 in M0 pin mode, so the
MCLK pin should be configured accordingly for the sound codec to get its
I2S signal from the SoC. Request the required pin config.
The clock itself should also be CLK_SAI2_MCLKOUT_TO_IO for the sound to
work (otherwise there is only silence out of the audio out jack).
Fixes: 96cbdfdd3ac2 ("arm64: dts: rockchip: Add FriendlyElec NanoPi M5 support")
Cc: stable@vger.kernel.org
Signed-off-by: Alexey Charkov <alchark@gmail.com>
Link: https://patch.msgid.link/20251229-rk3576-sound-v1-2-2f59ef0d19b1@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Fix the mismatch between the simple-audio-card routing table vs. widget
names, which caused the following error at boot preventing the sound
card from getting added:
[ 6.625634] asoc-simple-card sound: ASoC: DAPM unknown pin Headphones
[ 6.627247] asoc-simple-card sound: ASoC: Failed to add route HPOL -> Headphones(*)
[ 6.627988] asoc-simple-card sound: ASoC: Failed to add route HPOR -> Headphones(*)
Fixes: 96cbdfdd3ac2 ("arm64: dts: rockchip: Add FriendlyElec NanoPi M5 support")
Cc: stable@vger.kernel.org
Signed-off-by: Alexey Charkov <alchark@gmail.com>
Link: https://patch.msgid.link/20251229-rk3576-sound-v1-1-2f59ef0d19b1@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Rockchip RK3576 EVB1 board uses the typical configuration with an ES8388
analog codec driven from built-in SAI I2S.
Add device tree nodes for it.
Signed-off-by: Alexey Charkov <alchark@gmail.com>
Link: https://patch.msgid.link/20251229-rk3576-sound-v1-7-2f59ef0d19b1@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
All RK3576 boards get their HDMI sound from SAI6, which is internally
connected to the HDMI codec. Enable this for Rockchip RK3576 EVB1
Signed-off-by: Alexey Charkov <alchark@gmail.com>
Link: https://patch.msgid.link/20251229-rk3576-sound-v1-6-2f59ef0d19b1@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
All RK3576 boards get their HDMI sound from SAI6, which is internally
connected to the HDMI codec. Enable this for Luckfox Core3576
Signed-off-by: Alexey Charkov <alchark@gmail.com>
Link: https://patch.msgid.link/20251229-rk3576-sound-v1-5-2f59ef0d19b1@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
