| Age | Commit message (Collapse) | Author |
|---|
|
DTS coding style expects labels to be lowercase. No functional impact.
Verified with comparing decompiled DTB (dtx_diff and fdtdump+diff).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20241022-dts-qcom-label-v3-15-0505bc7d2c56@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
DTS coding style expects labels to be lowercase. No functional impact.
Verified with comparing decompiled DTB (dtx_diff and fdtdump+diff).
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20241022-dts-qcom-label-v3-14-0505bc7d2c56@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
DTS coding style expects labels to be lowercase. No functional impact.
Verified with comparing decompiled DTB (dtx_diff and fdtdump+diff).
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20241022-dts-qcom-label-v3-13-0505bc7d2c56@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
DTS coding style expects labels to be lowercase. No functional impact.
Verified with comparing decompiled DTB (dtx_diff and fdtdump+diff).
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20241022-dts-qcom-label-v3-12-0505bc7d2c56@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
DTS coding style expects labels to be lowercase. No functional impact.
Verified with comparing decompiled DTB (dtx_diff and fdtdump+diff).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20241022-dts-qcom-label-v3-11-0505bc7d2c56@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
DTS coding style expects labels to be lowercase. No functional impact.
Verified with comparing decompiled DTB (dtx_diff and fdtdump+diff).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20241022-dts-qcom-label-v3-10-0505bc7d2c56@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
DTS coding style expects labels to be lowercase. No functional impact.
Verified with comparing decompiled DTB (dtx_diff and fdtdump+diff).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20241022-dts-qcom-label-v3-9-0505bc7d2c56@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
DTS coding style expects labels to be lowercase. No functional impact.
Verified with comparing decompiled DTB (dtx_diff and fdtdump+diff).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20241022-dts-qcom-label-v3-8-0505bc7d2c56@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
DTS coding style expects labels to be lowercase. No functional impact.
Verified with comparing decompiled DTB (dtx_diff and fdtdump+diff).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20241022-dts-qcom-label-v3-7-0505bc7d2c56@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
DTS coding style expects labels to be lowercase. No functional impact.
Verified with comparing decompiled DTB (dtx_diff and fdtdump+diff).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20241022-dts-qcom-label-v3-6-0505bc7d2c56@linaro.org
[bjorn: Update sm7325 references to match the updated case]
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
DTS coding style expects labels to be lowercase. No functional impact.
Verified with comparing decompiled DTB (dtx_diff and fdtdump+diff).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20241022-dts-qcom-label-v3-18-0505bc7d2c56@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
DTS coding style expects labels to be lowercase. No functional impact.
Verified with comparing decompiled DTB (dtx_diff and fdtdump+diff).
Tested-by: Steev Klimaszewski <steev@kali.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20241022-dts-qcom-label-v3-5-0505bc7d2c56@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
DTS coding style expects labels to be lowercase. No functional impact.
Verified with comparing decompiled DTB (dtx_diff and fdtdump+diff).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20241022-dts-qcom-label-v3-4-0505bc7d2c56@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
DTS coding style expects labels to be lowercase, but the labels are not
used, so just drop them.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20241022-dts-qcom-label-v3-3-0505bc7d2c56@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
DTS coding style expects labels to be lowercase. No functional impact.
Verified with comparing decompiled DTB (dtx_diff and fdtdump+diff).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20241022-dts-qcom-label-v3-2-0505bc7d2c56@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
DTS coding style expects labels to be lowercase. No functional impact.
Verified with comparing decompiled DTB (dtx_diff and fdtdump+diff).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20241022-dts-qcom-label-v3-1-0505bc7d2c56@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Qcom PCIe RC controllers are capable of generating 'global' SPI interrupt
to the host CPUs. This interrupt can be used by the device driver to
identify events such as PCIe link specific events, safety events, etc...
Hence, add it to the PCIe RC node along with the existing MSI interrupts.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20240828-pci-qcom-hotplug-v4-12-263a385fbbcb@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
'linux,pci-domain' property provides the PCI domain number for the PCI
endpoint controllers in a SoC. If this property is not present, then an
unstable (across boots) unique number will be assigned.
Use this property to specify the domain number based on the actual hardware
instance of the PCI endpoint controllers in SA8775P SoC.
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20240828-pci-qcom-hotplug-v4-9-263a385fbbcb@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
'linux,pci-domain' property provides the PCI domain number for the PCI
endpoint controllers in a SoC. If this property is not present, then an
unstable (across boots) unique number will be assigned.
Use this property to specify the domain number based on the actual hardware
instance of the PCI endpoint controllers in SDX65 SoC.
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20240828-pci-qcom-hotplug-v4-8-263a385fbbcb@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
'linux,pci-domain' property provides the PCI domain number for the PCI
endpoint controllers in a SoC. If this property is not present, then an
unstable (across boots) unique number will be assigned.
Use this property to specify the domain number based on the actual hardware
instance of the PCI endpoint controllers in SDX55 SoC.
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20240828-pci-qcom-hotplug-v4-7-263a385fbbcb@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Enable download mode for sa8775p which can help collect
ramdump for this SoC.
Reviewed-by: Elliot Berman <quic_eberman@quicinc.com>
Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>
Link: https://lore.kernel.org/r/20240830133908.2246139-2-quic_mojha@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Add a node for the PMU module of the WCN6855 present on the sa8775p-ride
board. Assign its LDO power outputs to the existing WiFi/Bluetooth module.
Signed-off-by: Miaoqing Pan <quic_miaoqing@quicinc.com>
Acked-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20241011041939.2916179-1-quic_miaoqing@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Add the QCE and Crypto BAM DMA nodes.
Signed-off-by: Yuvaraj Ranganathan <quic_yrangana@quicinc.com>
Link: https://lore.kernel.org/r/20241017144500.3968797-3-quic_yrangana@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
This makes the name consistent with both other x1e80100 devices and the
dictionary. A UCM fix was merged already and is required in order for
sound to work after this commit.
Signed-off-by: Maya Matuszczyk <maccraft123mc@gmail.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20241019190214.3337-2-maccraft123mc@gmail.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Add device tree for the Nothing Phone 1 (nothing,spacewar) smartphone
which is based on the SM7325 SoC.
Supported features are, as of now:
* USB & UFS
* Debug UART
* Display via SimpleFB
* Power & volume buttons
* PMIC GLink
* Remoteprocs (ADSP, CDSP, MPSS, WPSS)
* WiFi & Bluetooth
* IPA
* VPU Iris (Venus)
* NFC
* Flash/torch LED
* RTC
* Device-specific thermals
* Various plumbing like regulators, i2c, spi, cci, etc
Signed-off-by: Eugene Lepshy <fekz115@gmail.com>
Co-developed-by: Danila Tikhonov <danila@jiaxyga.com>
Signed-off-by: Danila Tikhonov <danila@jiaxyga.com>
Link: https://lore.kernel.org/r/20241020205615.211256-7-danila@jiaxyga.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
The Snapdragon 778G (SM7325) / 778G+ (SM7325-AE) / 782G (SM7325-AF)
is software-wise very similar to the Snapdragon 7c+ Gen 3 (SC7280).
It uses the Kryo670.
Signed-off-by: Eugene Lepshy <fekz115@gmail.com>
Signed-off-by: Danila Tikhonov <danila@jiaxyga.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20241020205615.211256-4-danila@jiaxyga.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
I2C and SPI geni driver also supports the GSI node based
on client requirements. Currently, in the DTSI, the GSI mode
configuration is not added.
Therefore, add GPI DT nodes for QUPV_0/1/2/3 for I2C and SPI
for the SA8775.
Signed-off-by: Viken Dadhaniya <quic_vdadhani@quicinc.com>
Link: https://lore.kernel.org/r/20241021102815.12079-1-quic_vdadhani@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
This function should've been split a long time ago because it is used in
two paths:
1) On the late loading path, when the microcode is loaded through the
request_firmware interface
2) In the save_microcode_in_initrd() path which collects all the
microcode patches which are relevant for the current system before
the initrd with the microcode container has been jettisoned.
In that path, it is not really necessary to iterate over the nodes on
a system and match a patch however it didn't cause any trouble so it
was left for a later cleanup
However, that later cleanup was expedited by the fact that Jens was
enabling "Use L3 as a NUMA node" in the BIOS setting in his machine and
so this causes the NUMA CPU masks used in cpumask_of_node() to be
generated *after* 2) above happened on the first node. Which means, all
those masks were funky, wrong, uninitialized and whatnot, leading to
explosions when dereffing c->microcode in load_microcode_amd().
So split that function and do only the necessary work needed at each
stage.
Fixes: 94838d230a6c ("x86/microcode/AMD: Use the family,model,stepping encoded in the patch ID")
Reported-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Tested-by: Jens Axboe <axboe@kernel.dk>
Link: https://lore.kernel.org/r/91194406-3fdf-4e38-9838-d334af538f74@kernel.dk
|
|
Commit in Fixes changed how a microcode patch is loaded on Zen and newer but
the patch matching needs to happen with different rigidity, depending on what
is being done:
1) When the patch is added to the patches cache, the stepping must be ignored
because the driver still supports different steppings per system
2) When the patch is matched for loading, then the stepping must be taken into
account because each CPU needs the patch matching its exact stepping
Take care of that by making the matching smarter.
Fixes: 94838d230a6c ("x86/microcode/AMD: Use the family,model,stepping encoded in the patch ID")
Reported-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Tested-by: Jens Axboe <axboe@kernel.dk>
Link: https://lore.kernel.org/r/91194406-3fdf-4e38-9838-d334af538f74@kernel.dk
|
|
Analog audio using es8388 codec via the headset jack and onboard mic
Signed-off-by: Jimmy Hon <honyuenkwun@gmail.com>
Link: https://lore.kernel.org/r/20241008031429.2410-1-honyuenkwun@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Following the hierarchical representation of the SoC data that's been already
established in the commit 296602b8e5f7 ("arm64: dts: rockchip: Move RK3399
OPPs to dtsi files for SoC variants"), add new SoC dtsi file for the Rockchip
RK3399S SoC, which is yet another variant of the Rockchip RK3399 SoC.
The only perceivable differences between the RK3399S and the RK3399 are in
the supported CPU DVFS OPPs, which result from the RK3399S being binned for
lower maximum CPU frequencies than the regular RK3399 variant.
The RK3399S variant is used in the Pine64 PinePhone Pro only, [1] whose board
dts file included the necessary adjustments to the CPU DVFS OPPs. This commit
effectively moves those adjustments into the separate RK3399S SoC dtsi file,
following the above-mentioned "encapsulation" approach.
No functional changes are introduced, which was validated by decompiling and
comparing the affected dtb file before and after these changes.
[1] https://wiki.pine64.org/index.php/PinePhone_Pro
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/c32622e4a6897378d9df81c8c3eda1bdb9211e0b.1728632052.git.dsimic@manjaro.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Including a board dts file is not the right way to represent the hierarchical
nature of the board dts files and to create a dts file for another variant of
an ancestor board. However, a few boards and their variants (ab)used this
approach, so let's clean that up by converting the common ancestors into dtsi
files, and by adding separate board-variant dts files.
No functional changes are introduced, which was validated by decompiling and
comparing all affected board dtb files before and after these changes. In
more detail, the affected dtb files have some of their blocks shuffled around
a bit and some of their phandles have different values, as a result of the
changes to the order in which the building blocks from the parent dtsi files
are included, but they effectively remain the same as the originals.
The only perceivable introduced change is the turning of "roc-rk3328-cc" into
"ROC-RK3328-CC", which is the model name of one of the affected boards, which
was performed to match the styling of the official board name.
As a side note, due to the nature of introduced changes, this commit is best
viewed using "-B80%/80% -M20% -C5%" as the set of options for git-log(1).
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/f3d789c14fe34a53327cac03cd3837e530e21f5c.1728937091.git.dsimic@manjaro.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The Rock 5 ITX uses two PCIe controllers to drive both a M.2 slot and its
SATA controller with 2 lanes each. The supply for the refclk oscillator is
the same that supplies the M.2 slot, but the SATA controller port is
supplied by a different rail.
This leads to the effect that if the PCIe30x4 controller for the M.2
probes first, everything works normally. But if the PCIe30x2 controller
that is connected to the SATA controller probes first, it will hang on
the first DBI read as nothing will have enabled the refclock before.
Fix this by describing the clock generator with its supplies so that
both controllers can reference it as needed.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240906082511.2963890-6-heiko@sntech.de
|
|
The NanoPi R3S(as "R3S") is an open source platform with dual-Gbps
Ethernet ports designed and developed by FriendlyElec for IoT
applications.
Specification:
- Rockchip RK3566
- 2GB LPDDR4X RAM
- optional 32GB eMMC module
- SD card slot
- 2x 1000 Base-T
- 3x LEDs (POWER, LAN, WAN)
- 2x Buttons (Reset, MaskROM)
- 1x USB 3.0 Port
- Type-C 5V 2A Power
Signed-off-by: Tianling Shen <cnsztl@gmail.com>
Link: https://lore.kernel.org/r/20241020173946.225960-2-cnsztl@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Add the necessary DT changes to enable HDMI0 on Orange Pi 5
Signed-off-by: Jimmy Hon <honyuenkwun@gmail.com>
Link: https://lore.kernel.org/r/20241019021034.1710-1-honyuenkwun@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
add gpu node to make it usable on Radxa ROCK 5A.
Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
Link: https://lore.kernel.org/r/20241019025008.852-1-naoki@radxa.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Add the necessary DT changes to enable HDMI0 on Orange Pi 5 Plus.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20241019-rk3588-hdmi0-dt-v2-4-466cd80e8ff9@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Add the necessary DT changes to enable HDMI0 on Rockchip RK3588 EVB1.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20241019-rk3588-hdmi0-dt-v2-3-466cd80e8ff9@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Add the necessary DT changes to enable HDMI0 on Radxa ROCK 5B.
Tested-by: FUKAUMI Naoki <naoki@radxa.com>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20241019-rk3588-hdmi0-dt-v2-2-466cd80e8ff9@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Add support for the HDMI0 output port found on RK3588 SoC.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20241019-rk3588-hdmi0-dt-v2-1-466cd80e8ff9@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Add board-level device tree for Radxa e20c board[1]. This basic
implementation supports boot into a kernel with only UART console.
Other features will be added later.
[1]: https://docs.radxa.com/en/e/e20c
Signed-off-by: Yao Zi <ziyao@disroot.org>
Link: https://lore.kernel.org/r/20240829092705.6241-5-ziyao@disroot.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
This initial device tree describes CPU, interrupts and UART on the chip
and is able to boot into basic kernel with only UART. Cache information
is omitted for now as there is no precise documentation. Support for
other features will be added later.
Signed-off-by: Yao Zi <ziyao@disroot.org>
Link: https://lore.kernel.org/r/20240829092705.6241-4-ziyao@disroot.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Add board file for the rk3576 based ArmSoM Sige5 board. While the hardware
offers plenty of peripherals and connectivity this basic implementation
just handles things required to successfully boot Linux from SD card and
connect via UART or Ethernet.
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
Link: https://lore.kernel.org/r/20240903152308.13565-10-detlev.casanova@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
This device tree contains all devices necessary for booting from network
or SD Card.
It supports CPU, CRU, PM domains, dma, interrupts, timers, UART, I2C
and SDHCI (everything necessary to boot Linux on this system on chip)
as well as Ethernet, SPI, GPU and RTC.
Signed-off-by: Liang Chen <cl@rock-chips.com>
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
Signed-off-by: Yifeng Zhao <yifeng.zhao@rock-chips.com>
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
Tested-by: Liang Chen <cl@rock-chips.com>
Link: https://lore.kernel.org/r/20240903152308.13565-9-detlev.casanova@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Property 'rockchip,system-power-controller' was deprecated in commit
961748bb1555 ("dt-bindings: mfd: rk8xx: Deprecate rockchip,system-power-controller")
in the "rockchip,rk{805,808,809,817,818}.yaml" mtd bindings and its
replacement is (just) 'system-power-controller'.
Update the rk356x DT files which still used the deprecated variant.
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/20241008105450.20648-6-didi.debian@cknow.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Property 'rockchip,system-power-controller' was deprecated in commit
961748bb1555 ("dt-bindings: mfd: rk8xx: Deprecate rockchip,system-power-controller")
in the "rockchip,rk{805,808,809,817,818}.yaml" mtd bindings and its
replacement is (just) 'system-power-controller'.
Update the rk3399 DT files which still used the deprecated variant.
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/20241008105450.20648-5-didi.debian@cknow.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Property 'rockchip,system-power-controller' was deprecated in commit
961748bb1555 ("dt-bindings: mfd: rk8xx: Deprecate rockchip,system-power-controller")
in the "rockchip,rk{805,808,809,817,818}.yaml" mtd bindings and its
replacement is (just) 'system-power-controller'.
Update the rk3368 DT files which still used the deprecated variant.
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/20241008105450.20648-4-didi.debian@cknow.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Property 'rockchip,system-power-controller' was deprecated in commit
961748bb1555 ("dt-bindings: mfd: rk8xx: Deprecate rockchip,system-power-controller")
in the "rockchip,rk{805,808,809,817,818}.yaml" mtd bindings and its
replacement is (just) 'system-power-controller'.
Update the rk3328 DT files which still used the deprecated variant.
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/20241008105450.20648-3-didi.debian@cknow.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Property 'rockchip,system-power-controller' was deprecated in commit
961748bb1555 ("dt-bindings: mfd: rk8xx: Deprecate rockchip,system-power-controller")
in the "rockchip,rk{805,808,809,817,818}.yaml" mtd bindings and its
replacement is (just) 'system-power-controller'.
Update the px30 DT files which still used the deprecated variant.
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/20241008105450.20648-2-didi.debian@cknow.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
When performing an exec*(), there's a transient period before the return
to userspace where any stacktrace will result in a warning triggered by
kunwind_next_frame_record_meta() encountering a struct frame_record_meta
with an unknown type. This can be seen fairly reliably by enabling KASAN
or KFENCE, e.g.
| WARNING: CPU: 3 PID: 143 at arch/arm64/kernel/stacktrace.c:223 arch_stack_walk+0x264/0x3b0
| Modules linked in:
| CPU: 3 UID: 0 PID: 143 Comm: login Not tainted 6.12.0-rc2-00010-g0f0b9a3f6a50 #1
| Hardware name: linux,dummy-virt (DT)
| pstate: 814000c5 (Nzcv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
| pc : arch_stack_walk+0x264/0x3b0
| lr : arch_stack_walk+0x1ec/0x3b0
| sp : ffff80008060b970
| x29: ffff80008060ba10 x28: fff00000051133c0 x27: 0000000000000000
| x26: 0000000000000000 x25: 0000000000000000 x24: fff000007fe84000
| x23: ffff9d1b3c940af0 x22: 0000000000000000 x21: fff00000051133c0
| x20: ffff80008060ba50 x19: ffff9d1b3c9408e0 x18: 0000000000000014
| x17: 000000006d50da47 x16: 000000008e3f265e x15: fff0000004e8bf40
| x14: 0000ffffc5e50e48 x13: 000000000000000f x12: 0000ffffc5e50fed
| x11: 000000000000001f x10: 000018007f8bffff x9 : 0000000000000000
| x8 : ffff80008060b9c0 x7 : ffff80008060bfd8 x6 : ffff80008060ba80
| x5 : ffff80008060ba00 x4 : ffff80008060c000 x3 : ffff80008060bff0
| x2 : 0000000000000018 x1 : ffff80008060bfd8 x0 : 0000000000000000
| Call trace:
| arch_stack_walk+0x264/0x3b0 (P)
| arch_stack_walk+0x1ec/0x3b0 (L)
| stack_trace_save+0x50/0x80
| metadata_update_state+0x98/0xa0
| kfence_guarded_free+0xec/0x2c4
| __kfence_free+0x50/0x100
| kmem_cache_free+0x1a4/0x37c
| putname+0x9c/0xc0
| do_execveat_common.isra.0+0xf0/0x1e4
| __arm64_sys_execve+0x40/0x60
| invoke_syscall+0x48/0x104
| el0_svc_common.constprop.0+0x40/0xe0
| do_el0_svc+0x1c/0x28
| el0_svc+0x34/0xe0
| el0t_64_sync_handler+0x120/0x12c
| el0t_64_sync+0x198/0x19c
This happens because start_thread_common() zeroes the entirety of
current_pt_regs(), including pt_regs::stackframe::type, changing this
from FRAME_META_TYPE_FINAL to 0 and making the final record invalid.
The stacktrace code will reject this until the next return to userspace,
where a subsequent exception entry will reinitialize the type to
FRAME_META_TYPE_FINAL.
This zeroing wasn't a problem prior to commit:
c2c6b27b5aa14fa2 ("arm64: stacktrace: unwind exception boundaries")
... as before that commit the stacktrace code only expected the final
pt_regs::stackframe to contain zeroes, which was unchanged by
start_thread_common().
A stacktrace could occur at any time, either due to instrumentation or
an exception, and so start_thread_common() must ensure that
pt_regs::stackframe is always valid.
Fix this by changing the way start_thread_common() zeroes and
reinitializes the pt_regs fields:
* The '{regs,pc,pstate}' fields are initialized in one go via a struct
assignment to the user_regs, with start_thread() and
compat_start_thread() modified to pass 'pstate' into
start_thread_common().
* The 'sp' and 'compat_sp' fields are zeroed by the struct assignment in
start_thread_common(), and subsequently overwritten in start_thread()
and compat_start_thread respectively, matching existing behaviour.
* The 'syscallno' field is implicitly preserved while the 'orig_x0'
field is explicitly zeroed, maintaining existing ABI.
* The 'pmr' field is explicitly initialized, as necessary for an exec*()
from a kernel thread, matching existing behaviour.
* The 'stackframe' field is implicitly preserved, with a new comment and
some assertions to ensure we don't accidentally break this in future.
* All other fields are implicitly preserved, and should have no
functional impact:
- 'sdei_ttbr1' is only used for SDEI exception entry/exit, and we
never exec*() inside an SDEI handler.
- 'lockdep_hardirqs' and 'exit_rcu' are only used for EL1 exception
entry/exit, and we never exec*() inside an EL1 exception handler.
While updating compat_start_thread() to pass 'pstate' into
start_thread_common(), I've also updated the logic to remove the
ifdeffery, replacing:
| #ifdef __AARCH64EB__
| regs->pstate |= PSR_AA32_E_BIT;
| #endif
... with:
| if (IS_ENABLED(CONFIG_CPU_BIG_ENDIAN))
| pstate |= PSR_AA32_E_BIT;
... which should be functionally equivalent, and matches our preferred
code style.
Fixes: c2c6b27b5aa1 ("arm64: stacktrace: unwind exception boundaries")
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Miroslav Benes <mbenes@suse.cz>
Cc: Puranjay Mohan <puranjay12@gmail.com>
Cc: Will Deacon <will@kernel.org>
Fixes: c2c6b27b5aa1 ("arm64: stacktrace: unwind exception boundaries")
Tested-by: Puranjay Mohan <puranjay12@gmail.com>
Reviewed-by: Puranjay Mohan <puranjay12@gmail.com>
Link: https://lore.kernel.org/r/20241021164456.2275285-1-mark.rutland@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
