| Age | Commit message (Collapse) | Author |
|---|
|
"soc" node has "ranges" property thus add matching unit address to fix
dtc W=1 warnings:
rtd139x.dtsi:50.6-120.4: Warning (unit_address_vs_reg): /soc: node has a reg or ranges property, but no unit name
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20240401140912.97157-2-krzk@kernel.org
|
|
"soc" node has "ranges" property thus add matching unit address to fix
dtc W=1 warnings:
rtd129x.dtsi:51.6-122.4: Warning (unit_address_vs_reg): /soc: node has a reg or ranges property, but no unit name
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20240401140912.97157-1-krzk@kernel.org
|
|
Audio codec port does not have "reg", thus it should not have unit
address, as reported by dtc W=1 warning:
uniphier-ld20-global.dts:127.10-132.5: Warning (unit_address_vs_reg): /soc@0/i2c@58780000/tas5707@1b/port@0: node has a unit name, but no reg or ranges property
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20240401140952.97923-4-krzk@kernel.org
|
|
Devicetree specification expects node names to be generic, representing
the class of devices.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20240401140952.97923-3-krzk@kernel.org
|
|
Audio codec port does not have "reg", thus it should not have unit
address, as reported by dtc W=1 warning:
uniphier-ld11-global.dts:127.10-132.5: Warning (unit_address_vs_reg): /soc@0/i2c@58780000/tas5707a@1d/port@0: node has a unit name, but no reg or ranges property
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20240401140952.97923-2-krzk@kernel.org
|
|
Devicetree specification expects node names to be generic, representing
the class of devices.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20240401140952.97923-1-krzk@kernel.org
|
|
Nodes with "reg" property are supposed to have unit address, as reported
by dtc W=1 warning:
sharkl3.dtsi:42.23-48.6: Warning (unit_address_vs_reg): /soc/syscon@402b0000/pmu-gate: node has a reg or ranges property, but no unit name
sharkl3.dtsi:59.29-63.6: Warning (unit_address_vs_reg): /soc/syscon@402e0000/aonapb-gate: node has a reg or ranges property, but no unit name
sharkl3.dtsi:74.13-80.6: Warning (unit_address_vs_reg): /soc/syscon@40353000/pll: node has a reg or ranges property, but no unit name
sharkl3.dtsi:91.15-95.6: Warning (unit_address_vs_reg): /soc/syscon@40359000/mpll: node has a reg or ranges property, but no unit name
sharkl3.dtsi:106.15-112.6: Warning (unit_address_vs_reg): /soc/syscon@4035c000/rpll: node has a reg or ranges property, but no unit name
sharkl3.dtsi:123.15-127.6: Warning (unit_address_vs_reg): /soc/syscon@40363000/dpll: node has a reg or ranges property, but no unit name
sharkl3.dtsi:138.21-142.6: Warning (unit_address_vs_reg): /soc/syscon@60800000/mm-gate: node has a reg or ranges property, but no unit name
sharkl3.dtsi:153.27-159.6: Warning (unit_address_vs_reg): /soc/syscon@71300000/apapb-gate: node has a reg or ranges property, but no unit name
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20240401141128.98317-5-krzk@kernel.org
|
|
Nodes with "reg" property are supposed to have unit address, as reported
by dtc W=1 warning:
whale2.dtsi:67.10-116.5: Warning (simple_bus_reg): /soc/ap-apb: simple-bus unit address format error, expected "70000000"
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20240401141128.98317-4-krzk@kernel.org
|
|
All devices on MMIO bus should be within the "soc" node.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20240401141128.98317-3-krzk@kernel.org
|
|
GPIO keys are properties of a board, not SoC, because SoC physically
does not have any keys or buttons.
This also fixes dtc W=1 build warning:
sc9860.dtsi:688.13-714.5: Warning (simple_bus_reg): /soc/gpio-keys: missing or empty reg/ranges property
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20240401141128.98317-2-krzk@kernel.org
|
|
Nodes with "reg" property are supposed to have unit address, as reported
by dtc W=1 warning:
sc9860.dtsi:210.26-216.5: Warning (simple_bus_reg): /soc/aon-prediv: simple-bus unit address format error, expected "402d0000"
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20240401141128.98317-1-krzk@kernel.org
|
|
In order to fix perf's callchain parse error for LoongArch, we implement
perf_arch_fetch_caller_regs() which fills several necessary registers
used for callchain unwinding, including sp, fp, and era. This is similar
to the following commits.
commit b3eac0265bf6:
("arm: perf: Fix callchain parse error with kernel tracepoint events")
commit 5b09a094f2fb:
("arm64: perf: Fix callchain parse error with kernel tracepoint events")
commit 9a7e8ec0d4cc:
("riscv: perf: Fix callchain parse error with kernel tracepoint events")
Test with commands:
perf record -e sched:sched_switch -g --call-graph dwarf
perf report
Without this patch:
Children Self Command Shared Object Symbol
........ ........ ............. ................. ....................
43.41% 43.41% swapper [unknown] [k] 0000000000000000
10.94% 10.94% loong-container [unknown] [k] 0000000000000000
|
|--5.98%--0x12006ba38
|
|--2.56%--0x12006bb84
|
--2.40%--0x12006b6b8
With this patch, callchain can be parsed correctly:
Children Self Command Shared Object Symbol
........ ........ ............. ................. ....................
47.57% 47.57% swapper [kernel.vmlinux] [k] __schedule
|
---__schedule
26.76% 26.76% loong-container [kernel.vmlinux] [k] __schedule
|
|--13.78%--0x12006ba38
| |
| |--9.19%--__schedule
| |
| --4.59%--handle_syscall
| do_syscall
| sys_futex
| do_futex
| futex_wait
| futex_wait_queue_me
| hrtimer_start_range_ns
| __schedule
|
|--8.38%--0x12006bb84
| handle_syscall
| do_syscall
| sys_epoll_pwait
| do_epoll_wait
| schedule_hrtimeout_range_clock
| hrtimer_start_range_ns
| __schedule
|
--4.59%--0x12006b6b8
handle_syscall
do_syscall
sys_nanosleep
hrtimer_nanosleep
do_nanosleep
hrtimer_start_range_ns
__schedule
Cc: stable@vger.kernel.org
Fixes: b37042b2bb7cd751f0 ("LoongArch: Add perf events support")
Reported-by: Youling Tang <tangyouling@kylinos.cn>
Suggested-by: Youling Tang <tangyouling@kylinos.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
As with most architectures, allow handling of read faults in VMAs that
have VM_WRITE but without VM_READ (WRITE implies READ).
Otherwise, reading before writing a write-only memory will error while
reading after writing everything is fine.
BTW, move the VM_EXEC judgement before VM_READ/VM_WRITE to make logic a
little clearer.
Cc: stable@vger.kernel.org
Fixes: 09cfefb7fa70c3af01 ("LoongArch: Add memory management")
Signed-off-by: Jiantao Shan <shanjiantao@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
With LLVM=1 and W=1 we get:
./include/asm-generic/tlb.h:629:10: error: parameter 'ptep' set
but not used [-Werror,-Wunused-but-set-parameter]
We fixed a similar issue via Arnd in the introducing commit, missed the
LoongArch variant. Turns out, there is no need for LoongArch to have a
custom variant, so let's just drop it and rely on the asm-generic one.
Fixes: 4d5bf0b6183f ("mm/mmu_gather: add tlb_remove_tlb_entries()")
Closes: https://lkml.kernel.org/r/CANiq72mQh3O9S4umbvrKBgMMorty48UMwS01U22FR0mRyd3cyQ@mail.gmail.com
Reported-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
Tested-by: Miguel Ojeda <ojeda@kernel.org>
Tested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
In commit 85fcde402db191b5 ("kexec: split crashkernel reservation code
out from crash_core.c"), crashkernel reservation code is split out from
crash_core.c, and add CRASH_RESERVE to control it. And also rename each
ARCH's <asm/crash_core.h> to <asm/crash_reserve.h> accordingly.
But the relevant part in LoongArch is missed. Do it now.
Fixes: 85fcde402db1 ("kexec: split crashkernel reservation code out from crash_core.c")
Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
Enable the VBUS regulator used on Qualcomm platforms (RB1, RB2, RB5) to
supply VBUS voltage to the USB-C connector.
Reported-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20240325-arm64-config-usb-vbus-v1-1-d14601f81d08@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
We still support GCC 8.x, and it appears that this toolchain
usually comes with an assembler that does not understand "pauth"
as a valid architectural extension.
This results in the NV ERETAx code breaking the build, as it relies
on this extention to make use of the PACGA instruction (required
by assemblers such as LLVM's).
Work around it by hand-assembling the instruction, which removes the
requirement for any assembler directive.
Fixes: 6ccc971ee2c6 ("KVM: arm64: nv: Add emulation for ERETAx instructions")
Reported-by: Linaro Kernel Functional Testing <lkft@linaro.org>
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
Apart from the host-only usb3 controller (host2) the rk3588 also provides
two dual-role controllers. On the Tiger-Haikou combination these are
connected to the lower usb3-host port in host-only mode and the micro-usb3
port for dual-role operation.
Add the necessary controllers, phys to the Tiger-Haikou board and enable
the usb-id extcon.
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Link: https://lore.kernel.org/r/20240422163951.2604273-4-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The Q7 standard specifies a usb-id pin on the connector to distiuish
between host and device mode. Model this via the usb-id extcon binding.
While the pin is part of the Q7 standard, so part of the module, the
extcon stays disabled in the som dtsi and will only be enabled in a
baseboard using it.
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Link: https://lore.kernel.org/r/20240422163951.2604273-3-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The comment for the host2_xhci points to the wrong port on the board.
The upper usb3 port is the correct one, so fix the comment to prevent
confusion.
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Link: https://lore.kernel.org/r/20240422163951.2604273-2-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The clock-generator of course only produces a 100MHz clock rate,
not 1GHz.
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Link: https://lore.kernel.org/r/20240423114635.2637310-1-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
gpio_pwrctrl2 gets duplicated by both rk806_dvs1_null and rk806_dvs2_null
gpio_pwrctrl1 is unset. This typo appears in multiple files. Let's fix them.
Note: I haven't had the chance to test them all because I don't own all
of these boards (obviously). Please test if it's needed.
Signed-off-by: Jing Luo <jing@jing.rocks>
Link: https://lore.kernel.org/r/20240420130355.639406-1-jing@jing.rocks
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Correct the model names of a few Pine64 boards and devices, according
to their official names used on the Pine64 wiki. This ensures consistency
between the officially used names and the names in the source code.
Cc: Marek Kraus <gamiee@pine64.org>
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/06ce014a1dedff11a785fe523056b3b8ffdf21ee.1713832790.git.dsimic@manjaro.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Specification:
Rockchip Rk3588 SoC
4x ARM Cortex-A76, 4x ARM Cortex-A55
8/16/32GB Memory LPDDR4/LPDDR4x
Mali G610MP4 GPU
2× MIPI-CSI Connector
1× MIPI-DSI Connector
1x M.2 Key M (PCIe 3.0 4-lanes)
2x RTL8125 2.5G Ethernet
Onboard AP6275P for WIFI6/BT5
32GB/64GB/128GB eMMC
MicroSD card slot
1x USB2.0, 1x USB3.0 Type-A, 1x US3.0 Type-C
1x HDMI Output, 1x type-C DP Output
Functions work normally:
USB2.0 Host
USB3.0 Type-A Host
M.2 Key M (PCIe 3.0 4-lanes)
2x RTL8125 2.5G Ethernet
eMMC
MicroSD card
More information can be obtained from the following website
https://docs.armsom.org/armsom-sige7
Signed-off-by: Jianfeng Liu <liujianfeng1994@gmail.com>
Reviewed-by: Weizhao Ouyang <weizhao.ouyang@arm.com>
Link: https://lore.kernel.org/r/20240420034300.176920-4-liujianfeng1994@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The Jaguar SBC provides an M.2 slot connected to the pcie3 controller.
In contrast to a number of other boards the pcie-refclk is gpio-controlled,
so the necessary clock and is added to the list of pcie3 clocks.
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Link: https://lore.kernel.org/r/20240423074956.2622318-1-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The association of uart2 to the q7-uart pins is part of the module
itself and not the baseboard used. Therefore move the pinctrl over
to the tiger dtsi.
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Link: https://lore.kernel.org/r/20240422143356.2596414-1-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Add support for the USB-C port on the Indiedroid Nova board. This
port supports USB-C DP Alt mode (not implemented yet in drivers),
but works as a USB XHCI/EHCI/OHCI port.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Link: https://lore.kernel.org/r/20240418173627.1368494-1-macroalpha82@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
According to https://radxa.com/products/rock3/3a,
the name of this board should be "Radxa ROCK 3A".
Suggested-by: FUKAUMI Naoki <naoki@radxa.com>
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/20240419103019.992586-3-amadeus@jmu.edu.cn
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Correct the descriptions of a few Radxa boards, according to the up-to-date
documentation from Radxa and the detailed explanation from Naoki. [1] To sum
it up, the short naming, as specified by Radxa, is preferred.
[1] https://lore.kernel.org/linux-rockchip/B26C732A4DCEA9B3+282b8775-601b-4d4a-a513-4924b7940076@radxa.com/
Suggested-by: FUKAUMI Naoki <naoki@radxa.com>
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/6931289a252dc2d6c7bfd2388835c5e98ba0d8c9.1713457260.git.dsimic@manjaro.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The current definition yields a negative 32bits signed value which
result in a mask with is obviously incorrect. Replace it by using a
1ULL bit shift value to obtain a single set bit mask.
Fixes: 5dadda5e6a59 ("riscv: hwprobe: export Zvfh[min] ISA extensions")
Signed-off-by: Clément Léger <cleger@rivosinc.com>
Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Link: https://lore.kernel.org/r/20240409143839.558784-1-cleger@rivosinc.com
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
|
|
The only difference between Samsung Galaxy S5 China (kltechn) and klte
is the gpio pins of i2c_led_gpio. With pins corrected, the LEDs and WiFi
are able to work properly.
Signed-off-by: Rong Zhang <i@rong.moe>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Tested-by: Icenowy Zheng <uwu@icenowy.me>
Link: https://lore.kernel.org/r/20240213110137.122737-5-i@rong.moe
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
klte* variants have little difference in the WiFi part. Without
"brcm,board-type", variant-specific NVRAM file will be probed (e.g.,
klte probes samsung,klte). Pin it to "samsung,klte" to allow klte* to
load the same NVRAM file as klte.
Signed-off-by: Rong Zhang <i@rong.moe>
Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Tested-by: Icenowy Zheng <uwu@icenowy.me>
Link: https://lore.kernel.org/r/20240213110137.122737-3-i@rong.moe
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Samsung Galaxy S5 has many variants. Variants that support LTE use klte*
as their codename. Currently, the only supported one is the one without
any suffix, namely, klte. It is known that other klte* variants have
only minor differences compared to klte and can mostly work with the
klte DTB.
Split the common part into a common DTSI so that it can be imported in
the DTS of klte and other klte* variants.
Signed-off-by: Rong Zhang <i@rong.moe>
Tested-by: Alexey Minnekhanov <alexeymin@postmarketos.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Tested-by: Icenowy Zheng <uwu@icenowy.me>
Link: https://lore.kernel.org/r/20240213110137.122737-2-i@rong.moe
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
We need the usb/thunderbolt fixes in here as well.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
We want the kernfs fixes in here as well.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The original dts of CV1800B has a weird memory length as it
contains reserved memory for coprocessor. Make this area a
separate node so it can get the real memory length.
Link: https://lore.kernel.org/r/IA1PR20MB49531F274753B04A5547DB59BB052@IA1PR20MB4953.namprd20.prod.outlook.com
Signed-off-by: Inochi Amaoto <inochiama@outlook.com>
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
|
|
Add the device node and related header file
for Amlogic T7 reset controller.
Signed-off-by: Zelong Dong <zelong.dong@amlogic.com>
Signed-off-by: Kelvin Zhang <kelvin.zhang@amlogic.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20240422-t7-reset-v2-3-cb82271d3296@amlogic.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
|
|
Link all IOMMU consumers to the corresponding IPMMU instances.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/d22ff0526263937ddfa214cdc3ec116a359cbb27.1713526951.git.geert+renesas@glider.be
|
|
Add device nodes for the main and cache I/O Memory Management Unit
(IPMMU) instances on the R-Car V4M (R8A779H0) SoC.
Add IPMMU main and cache nodes for R-Car R8A779H0 SoC.
Signed-off-by: Thanh Le <thanh.le.xv@renesas.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/b4701548e199ee2a72434bf73990557a63e13bd9.1713526951.git.geert+renesas@glider.be
|
|
Add the device node for the Interrupt Controller for External Devices
(INTC-EX) on the Renesas R-Car V4M (R8A779H0) SoC, which serves external
IRQ pins IRQ[0-5].
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/66aba473186df9a137e7f95393209b23a5916fd1.1713281889.git.geert+renesas@glider.be
|
|
Add device nodes for the Clock-Synchronized Serial Interfaces with FIFO
(MSIOF) on the Renesas R-Car V4M (R8A779H0) SoC.
Signed-off-by: Thanh Quan <thanh.quan.xn@renesas.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/62d2a1424cabda06c53541d93f6a1a5110267a71.1713280753.git.geert+renesas@glider.be
|
|
Extend the arch crash hotplug handler, as introduced by the patch title
("powerpc: add crash CPU hotplug support"), to also support memory
add/remove events.
Elfcorehdr describes the memory of the crash kernel to capture the
kernel; hence, it needs to be updated if memory resources change due to
memory add/remove events. Therefore, arch_crash_handle_hotplug_event()
is updated to recreate the elfcorehdr and replace it with the previous
one on memory add/remove events.
The memblock list is used to prepare the elfcorehdr. In the case of
memory hot remove, the memblock list is updated after the arch crash
hotplug handler is triggered, as depicted in Figure 1. Thus, the
hot-removed memory is explicitly removed from the crash memory ranges
to ensure that the memory ranges added to elfcorehdr do not include the
hot-removed memory.
Memory remove
|
v
Offline pages
|
v
Initiate memory notify call <----> crash hotplug handler
chain for MEM_OFFLINE event
|
v
Update memblock list
Figure 1
There are two system calls, `kexec_file_load` and `kexec_load`, used to
load the kdump image. A few changes have been made to ensure that the
kernel can safely update the elfcorehdr component of the kdump image for
both system calls.
For the kexec_file_load syscall, kdump image is prepared in the kernel.
To support an increasing number of memory regions, the elfcorehdr is
built with extra buffer space to ensure that it can accommodate
additional memory ranges in future.
For the kexec_load syscall, the elfcorehdr is updated only if the
KEXEC_CRASH_HOTPLUG_SUPPORT kexec flag is passed to the kernel by the
kexec tool. Passing this flag to the kernel indicates that the
elfcorehdr is built to accommodate additional memory ranges and the
elfcorehdr segment is not considered for SHA calculation, making it safe
to update.
The changes related to this feature are kept under the CRASH_HOTPLUG
config, and it is enabled by default.
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20240326055413.186534-7-sourabhjain@linux.ibm.com
|
|
Due to CPU/Memory hotplug or online/offline events, the elfcorehdr
(which describes the CPUs and memory of the crashed kernel) and FDT
(Flattened Device Tree) of kdump image becomes outdated. Consequently,
attempting dump collection with an outdated elfcorehdr or FDT can lead
to failed or inaccurate dump collection.
Going forward, CPU hotplug or online/offline events are referred as
CPU/Memory add/remove events.
The current solution to address the above issue involves monitoring the
CPU/Memory add/remove events in userspace using udev rules and whenever
there are changes in CPU and memory resources, the entire kdump image
is loaded again. The kdump image includes kernel, initrd, elfcorehdr,
FDT, purgatory. Given that only elfcorehdr and FDT get outdated due to
CPU/Memory add/remove events, reloading the entire kdump image is
inefficient. More importantly, kdump remains inactive for a substantial
amount of time until the kdump reload completes.
To address the aforementioned issue, commit 247262756121 ("crash: add
generic infrastructure for crash hotplug support") added a generic
infrastructure that allows architectures to selectively update the kdump
image component during CPU or memory add/remove events within the kernel
itself.
In the event of a CPU or memory add/remove events, the generic crash
hotplug event handler, `crash_handle_hotplug_event()`, is triggered. It
then acquires the necessary locks to update the kdump image and invokes
the architecture-specific crash hotplug handler,
`arch_crash_handle_hotplug_event()`, to update the required kdump image
components.
This patch adds crash hotplug handler for PowerPC and enable support to
update the kdump image on CPU add/remove events. Support for memory
add/remove events is added in a subsequent patch with the title
"powerpc: add crash memory hotplug support"
As mentioned earlier, only the elfcorehdr and FDT kdump image components
need to be updated in the event of CPU or memory add/remove events.
However, on PowerPC architecture crash hotplug handler only updates the
FDT to enable crash hotplug support for CPU add/remove events. Here's
why.
The elfcorehdr on PowerPC is built with possible CPUs, and thus, it does
not need an update on CPU add/remove events. On the other hand, the FDT
needs to be updated on CPU add events to include the newly added CPU. If
the FDT is not updated and the kernel crashes on a newly added CPU, the
kdump kernel will fail to boot due to the unavailability of the crashing
CPU in the FDT. During the early boot, it is expected that the boot CPU
must be a part of the FDT; otherwise, the kernel will raise a BUG and
fail to boot. For more information, refer to commit 36ae37e3436b0
("powerpc: Make boot_cpuid common between 32 and 64-bit"). Since it is
okay to have an offline CPU in the kdump FDT, no action is taken in case
of CPU removal.
There are two system calls, `kexec_file_load` and `kexec_load`, used to
load the kdump image. Few changes have been made to ensure kernel can
safely update the FDT of kdump image loaded using both system calls.
For kexec_file_load syscall the kdump image is prepared in kernel. So to
support an increasing number of CPUs, the FDT is constructed with extra
buffer space to ensure it can accommodate a possible number of CPU
nodes. Additionally, a call to fdt_pack (which trims the unused space
once the FDT is prepared) is avoided if this feature is enabled.
For the kexec_load syscall, the FDT is updated only if the
KEXEC_CRASH_HOTPLUG_SUPPORT kexec flag is passed to the kernel by
userspace (kexec tools). When userspace passes this flag to the kernel,
it indicates that the FDT is built to accommodate possible CPUs, and the
FDT segment is excluded from SHA calculation, making it safe to update.
The changes related to this feature are kept under the CRASH_HOTPLUG
config, and it is enabled by default.
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20240326055413.186534-6-sourabhjain@linux.ibm.com
|
|
Move the update_cpus_node() from kexec/{file_load_64.c => core_64.c}
to allow other kexec components to use it.
Later in the series, this function is used for in-kernel updates
to the kdump image during CPU/memory hotplug or online/offline events for
both kexec_load and kexec_file_load syscalls.
No functional changes are intended.
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20240326055413.186534-5-sourabhjain@linux.ibm.com
|
|
Move the following functions form kexec/{file_load_64.c => ranges.c} and
make them public so that components other than KEXEC_FILE can also use
these functions.
1. get_exclude_memory_ranges
2. get_reserved_memory_ranges
3. get_crash_memory_ranges
4. get_usable_memory_ranges
Later in the series get_crash_memory_ranges function is utilized for
in-kernel updates to kdump image during CPU/Memory hotplug or
online/offline events for both kexec_load and kexec_file_load syscalls.
Since the above functions are moved to ranges.c, some of the helper
functions in ranges.c are no longer required to be public. Mark them as
static and removed them from kexec_ranges.h header file.
Finally, remove the CONFIG_KEXEC_FILE build dependency for range.c
because it is required for other config, such as CONFIG_CRASH_DUMP.
No functional changes are intended.
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20240326055413.186534-4-sourabhjain@linux.ibm.com
|
|
Commit a72bbec70da2 ("crash: hotplug support for kexec_load()")
introduced a new kexec flag, `KEXEC_UPDATE_ELFCOREHDR`. Kexec tool uses
this flag to indicate to the kernel that it is safe to modify the
elfcorehdr of the kdump image loaded using the kexec_load system call.
However, it is possible that architectures may need to update kexec
segments other then elfcorehdr. For example, FDT (Flatten Device Tree)
on PowerPC. Introducing a new kexec flag for every new kexec segment
may not be a good solution. Hence, a generic kexec flag bit,
`KEXEC_CRASH_HOTPLUG_SUPPORT`, is introduced to share the CPU/Memory
hotplug support intent between the kexec tool and the kernel for the
kexec_load system call.
Now we have two kexec flags that enables crash hotplug support for
kexec_load system call. First is KEXEC_UPDATE_ELFCOREHDR (only used in
x86), and second is KEXEC_CRASH_HOTPLUG_SUPPORT (for all architectures).
To simplify the process of finding and reporting the crash hotplug
support the following changes are introduced.
1. Define arch specific function to process the kexec flags and
determine crash hotplug support
2. Rename the @update_elfcorehdr member of struct kimage to
@hotplug_support and populate it for both kexec_load and
kexec_file_load syscalls, because architecture can update more than
one kexec segment
3. Let generic function crash_check_hotplug_support report hotplug
support for loaded kdump image based on value of @hotplug_support
To bring the x86 crash hotplug support in line with the above points,
the following changes have been made:
- Introduce the arch_crash_hotplug_support function to process kexec
flags and determine crash hotplug support
- Remove the arch_crash_hotplug_[cpu|memory]_support functions
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20240326055413.186534-3-sourabhjain@linux.ibm.com
|
|
In the event of memory hotplug or online/offline events, the crash
memory hotplug notifier `crash_memhp_notifier()` receives a
`memory_notify` object but doesn't forward that object to the
generic and architecture-specific crash hotplug handler.
The `memory_notify` object contains the starting PFN (Page Frame Number)
and the number of pages in the hot-removed memory. This information is
necessary for architectures like PowerPC to update/recreate the kdump
image, specifically `elfcorehdr`.
So update the function signature of `crash_handle_hotplug_event()` and
`arch_crash_handle_hotplug_event()` to accept the `memory_notify` object
as an argument from crash memory hotplug notifier.
Since no such object is available in the case of CPU hotplug event, the
crash CPU hotplug notifier `crash_cpuhp_online()` passes NULL to the
crash hotplug handler.
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20240326055413.186534-2-sourabhjain@linux.ibm.com
|
|
At the time of LPAR boot up, partition firmware provides Open Firmware
property ibm,dma-window for the PE. This property is provided on the PCI
bus the PE is attached to.
There are execptions where the partition firmware might not provide this
property for the PE at the time of LPAR boot up. One of the scenario is
where the firmware has frozen the PE due to some error condition. This
PE is frozen for 24 hours or unless the whole system is reinitialized.
Within this time frame, if the LPAR is booted, the frozen PE will be
presented to the LPAR but ibm,dma-window property could be missing.
Today, under these circumstances, the LPAR oopses with NULL pointer
dereference, when configuring the PCI bus the PE is attached to.
BUG: Kernel NULL pointer dereference on read at 0x000000c8
Faulting instruction address: 0xc0000000001024c0
Oops: Kernel access of bad area, sig: 7 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
Modules linked in:
Supported: Yes
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.4.0-150600.9-default #1
Hardware name: IBM,9043-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_023) hv:phyp pSeries
NIP: c0000000001024c0 LR: c0000000001024b0 CTR: c000000000102450
REGS: c0000000037db5c0 TRAP: 0300 Not tainted (6.4.0-150600.9-default)
MSR: 8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE> CR: 28000822 XER: 00000000
CFAR: c00000000010254c DAR: 00000000000000c8 DSISR: 00080000 IRQMASK: 0
...
NIP [c0000000001024c0] pci_dma_bus_setup_pSeriesLP+0x70/0x2a0
LR [c0000000001024b0] pci_dma_bus_setup_pSeriesLP+0x60/0x2a0
Call Trace:
pci_dma_bus_setup_pSeriesLP+0x60/0x2a0 (unreliable)
pcibios_setup_bus_self+0x1c0/0x370
__of_scan_bus+0x2f8/0x330
pcibios_scan_phb+0x280/0x3d0
pcibios_init+0x88/0x12c
do_one_initcall+0x60/0x320
kernel_init_freeable+0x344/0x3e4
kernel_init+0x34/0x1d0
ret_from_kernel_user_thread+0x14/0x1c
Fixes: b1fc44eaa9ba ("pseries/iommu/ddw: Fix kdump to work in absence of ibm,dma-window")
Signed-off-by: Gaurav Batra <gbatra@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20240422205141.10662-1-gbatra@linux.ibm.com
|
|
Add exti1 as interrupt parent for the two pin controllers. Add the
additional required property st,syscfg.
Signed-off-by: Antonio Borneo <antonio.borneo@foss.st.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20240415134926.1254428-12-antonio.borneo@foss.st.com
|
|
Update the device-tree stm32mp251.dtsi by adding the nodes for exti1 and
exti2 interrupt controllers.
Signed-off-by: Antonio Borneo <antonio.borneo@foss.st.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20240415134926.1254428-11-antonio.borneo@foss.st.com
|
