summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-05-21Merge tag 'samsung-drivers-6.16-2' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into soc/drivers Samsung SoC drivers for v6.16, part two Add CPU hotplug support on Google GS101 by toggling respective bits in secondary PMU intr block (Power Management Unit (PMU) Interrupt Generation) from the main PMU driver. * tag 'samsung-drivers-6.16-2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux: soc: samsung: exynos-pmu: enable CPU hotplug support for gs101 MAINTAINERS: Add google,gs101-pmu-intr-gen.yaml binding file dt-bindings: soc: samsung: exynos-pmu: gs101: add google,pmu-intr-gen phandle dt-bindings: soc: google: Add gs101-pmu-intr-gen binding documentation Link: https://lore.kernel.org/r/20250516082037.7248-2-krzysztof.kozlowski@linaro.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-05-21arm64: dts: nuvoton: Add pinctrlWilliam A. Kennington III
This is critical to support multifunction pins shared between devices as well as generic GPIOs. Signed-off-by: William A. Kennington III <william@wkennington.com> Link: https://patch.msgid.link/20250416015902.2091251-1-william@wkennington.com Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au> Link: https://lore.kernel.org/r/20250515-nuvoton-arm64-dt-v1-1-25769b8c1509@codeconstruct.com.au Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-05-21soc: aspeed: Add NULL check in aspeed_lpc_enable_snoop()Henry Martin
devm_kasprintf() returns NULL when memory allocation fails. Currently, aspeed_lpc_enable_snoop() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue. Fixes: 3772e5da4454 ("drivers/misc: Aspeed LPC snoop output using misc chardev") Signed-off-by: Henry Martin <bsdhenrymartin@gmail.com> Link: https://patch.msgid.link/20250401074647.21300-1-bsdhenrymartin@gmail.com [arj: Fix Fixes: tag to use subject from 3772e5da4454] Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-05-21soc: aspeed: lpc: Fix impossible judgment conditionSu Hui
smatch error： drivers/soc/aspeed/aspeed-lpc-snoop.c:169 aspeed_lpc_snoop_config_irq() warn: platform_get_irq() does not return zero platform_get_irq() return non-zero IRQ number or negative error code, change '!lpc_snoop->irq' to 'lpc_snoop->irq < 0' to fix this. Fixes: 9f4f9ae81d0a ("drivers/misc: add Aspeed LPC snoop driver") Signed-off-by: Su Hui <suhui@nfschina.com> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/20231027020703.1231875-1-suhui@nfschina.com Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-05-21ARM: aspeed: Don't select SRAMJoel Stanley
The ASPEED devices have SRAM, but don't require it for basic function (or any function; there's no known users of the driver). Fixes: 8c2ed9bcfbeb ("arm: Add Aspeed machine") Signed-off-by: Joel Stanley <joel@jms.id.au> Link: https://patch.msgid.link/20250115103942.421429-1-joel@jms.id.au Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-05-21wifi: ath12k: fix regdomain update failure when connection establishesBaochen Qiang
Commit 7ed3e88664e3 ("wifi: ath12k: update regulatory rules when connection established") introduced a call to ath12k_reg_handle_chan_list() upon connection to update the regulatory domain in cfg80211 based on the power type received from the AP. However, this update fails because ah->regd_updated was already set to true during the earlier regulatory update triggered when the interface was added. To resolve this, reset ah->regd_updated before calling ath12k_reg_handle_chan_list() to ensure the update proceeds correctly. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Fixes: 7ed3e88664e3 ("wifi: ath12k: update regulatory rules when connection established") Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Link: https://patch.msgid.link/20250521-ath12k-fix-ah-regd_updated-v1-3-9737de5bf98e@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-05-21wifi: ath12k: fix regdomain update failure when adding interfaceBaochen Qiang
Commit 4c546023d71a ("wifi: ath12k: update regulatory rules when interface added"), introduced a call to ath12k_reg_handle_chan_list() during interface addition to update the regulatory domain based on the interface type. While this works initially, subsequent updates (e.g., after an interface delete/re-add cycle) fail because ah->regd_updated is never reset. To address this, reset ah->regd_updated before calling ath12k_reg_handle_chan_list() to allow the update to proceed. However, this change exposes another issue: a timeout occurs when waiting for the 11D scan to complete, as seen in the log: ath12k_pci 0000:05:00.0: failed to receive 11d scan complete: timed out This happens because during interface down, ar->state_11d is set to ATH12K_11D_PREPARING, and during interface up, the host waits for ar->completed_11d_scan even though the scan hasn't started yet. Fix this by updating the wait condition to check for ATH12K_11D_RUNNING, which is the only state where a scan complete event is expected. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Fixes: 4c546023d71a ("wifi: ath12k: update regulatory rules when interface added") Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Link: https://patch.msgid.link/20250521-ath12k-fix-ah-regd_updated-v1-2-9737de5bf98e@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-05-21wifi: ath12k: fix regdomain update failure after 11D scan completesBaochen Qiang
In the current implementation of ath12k_regd_update(), the ah->regd_updated flag is used to ensure that the regulatory domain is updated only once per radio. During MAC registration, this function is called to push the default regulatory domain to cfg80211. At that point, the hardware state is not on and hence ah->regd_updated remains false. However, after commit 4c546023d71a ("wifi: ath12k: update regulatory rules when interface added"), ath12k_reg_handle_chan_list() is invoked when an interface is added, which in turn calls ath12k_regd_update(). By this time, hardware state is on and consecutively ah->regd_updated becomes true. Later, when the 11D scan completes and a new regulatory domain is received from the firmware, the host attempts to update cfg80211 again via ath12k_regd_update(). But since ah->regd_updated is already true, the update is skipped. >From the user's perspective, this results in a failure to connect to 6 GHz APs, as the default regulatory domain (the only one pushed to cfg80211) does not include 6 GHz support. To resolve this, reset the ah->regd_updated flag when handling the 11D regulatory domain update. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Fixes: 591de41d7008 ("wifi: ath12k: add 11d scan offload support") Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Link: https://patch.msgid.link/20250521-ath12k-fix-ah-regd_updated-v1-1-9737de5bf98e@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-05-21Merge tag 'cpufreq-arm-updates-6.16' of ↵Rafael J. Wysocki
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm Merge ARM CPUFreq updates for 6.16 from Viresh Kumar: "- Rust abstractions for CPUFreq framework (Viresh Kumar). - Rust abstractions for OPP framework (Viresh Kumar). - Basic Rust abstractions for Clk and Cpumask frameworks (Viresh Kumar). - Minor cleanup to the SCMI cpufreq driver (Mike Tipton)." * tag 'cpufreq-arm-updates-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: (24 commits) cpufreq: scmi: Skip SCMI devices that aren't used by the CPUs cpufreq: Add Rust-based cpufreq-dt driver rust: opp: Extend OPP abstractions with cpufreq support rust: cpufreq: Extend abstractions for driver registration rust: cpufreq: Extend abstractions for policy and driver ops rust: cpufreq: Add initial abstractions for cpufreq framework rust: opp: Add abstractions for the configuration options rust: opp: Add abstractions for the OPP table rust: opp: Add initial abstractions for OPP framework rust: cpu: Add from_cpu() rust: macros: enable use of hyphens in module names rust: clk: Add initial abstractions rust: clk: Add helpers for Rust code MAINTAINERS: Add entry for Rust cpumask API rust: cpumask: Add initial abstractions rust: cpumask: Add few more helpers rust: devres: require a bound device rust: pci: move iomap_region() to impl Device<Bound> rust: device: implement Bound device context rust: pci: preserve device context in AsRef ...
2025-05-21cpufreq: CPPC: Add support for autonomous selectionLifeng Zheng
Add sysfs interfaces for CPPC autonomous selection in the cppc_cpufreq driver. Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com> Reviewed-by: Sumit Gupta <sumitg@nvidia.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://patch.msgid.link/20250507031941.2812701-1-zhenglifeng1@huawei.com [ rjw: Subject edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-05-21ublk: handle ublk_set_auto_buf_reg() failure correctly in ublk_fetch()Ming Lei
If ublk_set_auto_buf_reg() fails, we need to unlock and return, otherwise `ub->mutex` is leaked. Fixes: 99c1e4eb6a3f ("ublk: register buffer to local io_uring with provided buf index via UBLK_F_AUTO_BUF_REG") Reported-by: Caleb Sander Mateos <csander@purestorage.com> Signed-off-by: Ming Lei <ming.lei@redhat.com> Link: https://lore.kernel.org/r/20250521025502.71041-2-ming.lei@redhat.com Reviewed-by: Caleb Sander Mateos <csander@purestorage.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-05-21cpufreq: Update sscanf() to kstrtouint()Bowen Yu
In store_scaling_setspeed(), sscanf is still used to read to sysfs. Newer kstrtox provide more features including overflow protection, better errorhandling and allows for other systems of numeration. It is therefore better to update sscanf() to kstrtouint(). Signed-off-by: Bowen Yu <yubowen8@huawei.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://patch.msgid.link/20250519070938.931396-1-yubowen8@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-05-21cpufreq: Replace magic numberBowen Yu
Setting the length of str_governor with a magic number could cause overflow when max length increases, it is better to use the defined macro in this case. Signed-off-by: Bowen Yu <yubowen8@huawei.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://patch.msgid.link/20250519070908.930879-1-yubowen8@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-05-21ALSA: hda/tegra: Switch to two-argument strscpy()Daniel Dadap
strscpy() is used in this driver with char[] struct member destinations, so it is possible to use the simplified two-argument variant which was added by commit e6584c3964f2 ("string: Allow 2-argument strscpy()"). Signed-off-by: Daniel Dadap <ddadap@nvidia.com> Link: https://patch.msgid.link/aC3lbOTYxWvYR9dl@ddadap-lakeline.nvidia.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2025-05-21ALSA: hda - Add new driver for HDA controllers listed via ACPIDaniel Dadap
Some systems expose HD-Audio controllers via objects in the ACPI tables which encapsulate the controller's interrupt and the base address for the HDA registers in an ACPI _CRS object, for example, as listed in this ACPI table dump excerpt: Device (HDA0) { Name (_HID, "NVDA2014") // _HID: Hardware ID ... Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings { Memory32Fixed (ReadWrite, 0x36078000, // Address Base 0x00008000, // Address Length ) Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, ) { 0x0000021E, } }) } Add support for HDA controllers discovered through ACPI, including support for some platforms which expose such HDA controllers on NVIDIA SoCs. This is done with a new driver which uses existing infrastructure for extracting resource information from _CRS objects and plumbs the parsed resource information through to the existing HDA infrastructure to enable HD-Audio functionality on such devices. Although this driver is in the sound/pci/hda/ directory, it targets devices which are not actually enumerated on the PCI bus. This is because it depends upon the Intel "Azalia" infrastructure which has traditionally been usedvfor PCI-based devices. Signed-off-by: Daniel Dadap <ddadap@nvidia.com> Link: https://patch.msgid.link/aC3ksXJUM9DlKiz6@ddadap-lakeline.nvidia.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2025-05-21tools: ynl: add a sample for TCJakub Kicinski
Add a very simple TC dump sample with decoding of fq_codel attrs: # ./tools/net/ynl/samples/tc dummy0: fq_codel limit: 10240p target: 5ms new_flow_cnt: 0 proving that selector passing (for stats) works. Reviewed-by: Donald Hunter <donald.hunter@gmail.com> Link: https://patch.msgid.link/20250520161916.413298-13-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-21netlink: specs: tc: add qdisc dump to TC specJakub Kicinski
Hook TC qdisc dump in the TC qdisc get, it only supported doit until now and dumping will be used by the sample code. Reviewed-by: Donald Hunter <donald.hunter@gmail.com> Link: https://patch.msgid.link/20250520161916.413298-12-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-21tools: ynl: enable codegen for TCJakub Kicinski
We are ready to support most of TC. Enable C code gen. Reviewed-by: Donald Hunter <donald.hunter@gmail.com> Link: https://patch.msgid.link/20250520161916.413298-11-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-21tools: ynl-gen: support weird sub-message formatsJakub Kicinski
TC uses all possible sub-message formats: - nested attrs - fixed headers + nested attrs - fixed headers - empty Nested attrs are already supported for rt-link. Add support for remaining 3. The empty and fixed headers ones are fairly trivial, we can fake a Binary or Flags type instead of a Nest. For fixed headers + nest we need to teach nest parsing and nest put to handle fixed headers. Reviewed-by: Donald Hunter <donald.hunter@gmail.com> Link: https://patch.msgid.link/20250520161916.413298-10-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-21tools: ynl-gen: support local attrs in _multi_parseJakub Kicinski
The _multi_parse() helper calls the _attr_get() method of each attr, but it only respects what code the helper wants to emit, not what local variables it needs. Local variables will soon be needed, support them. Reviewed-by: Donald Hunter <donald.hunter@gmail.com> Link: https://patch.msgid.link/20250520161916.413298-9-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-21tools: ynl-gen: move fixed header info from RenderInfo to StructJakub Kicinski
RenderInfo describes a request-response exchange. Struct describes a parsed attribute set. For ease of parsing sub-messages with fixed headers move fixed header info from RenderInfo to Struct. No functional changes. Reviewed-by: Donald Hunter <donald.hunter@gmail.com> Link: https://patch.msgid.link/20250520161916.413298-8-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-21tools: ynl-gen: support passing selector to a nestJakub Kicinski
In rtnetlink all submessages had the selector at the same level of nesting as the submessage. We could refer to the relevant attribute from the current struct. In TC, stats are one level of nesting deeper than "kind". Teach the code-gen about structs which need to be passed a selector by the caller for parsing. Because structs are "topologically sorted" one pass of propagating the selectors down is enough. For generating netlink message we depend on the presence bits so no selector passing needed there. Reviewed-by: Donald Hunter <donald.hunter@gmail.com> Link: https://patch.msgid.link/20250520161916.413298-7-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-21netlink: specs: tc: drop the family name prefix from attrsJakub Kicinski
All attribute sets and messages are prefixed with tc-. The C codegen also adds the family name to all structs. We end up with names like struct tc_tc_act_attrs. Remove the tc- prefixes to shorten the names. This should not impact Python as the attr set names are never exposed to user, they are only used to refer to things internally, in the encoder / decoder. Reviewed-by: Donald Hunter <donald.hunter@gmail.com> Link: https://patch.msgid.link/20250520161916.413298-6-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-21netlink: specs: tc: add C naming infoJakub Kicinski
Add naming info needed by C code gen. Reviewed-by: Donald Hunter <donald.hunter@gmail.com> Link: https://patch.msgid.link/20250520161916.413298-5-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-21netlink: specs: tc: use tc-gact instead of tc-gen as struct nameJakub Kicinski
There is a define in the uAPI header called tc_gen which expands to the "generic" TC action fields. This helps other actions include the base fields without having to deal with nested structs. A couple of actions (sample, gact) do not define extra fields, so the spec used a common tc-gen struct for both of them. Unfortunately this struct does not exist in C. Let's use gact's (generic act's) struct for basic actions. Reviewed-by: Donald Hunter <donald.hunter@gmail.com> Link: https://patch.msgid.link/20250520161916.413298-4-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-21netlink: specs: tc: remove duplicate nestsJakub Kicinski
tc-act-stats-attrs and tca-stats-attrs are almost identical. The only difference is that the latter has sub-message decoding for app, rather than declaring it as a binary attr. tc-act-police-attrs and tc-police-attrs are identical but for the TODO annotations. Reviewed-by: Donald Hunter <donald.hunter@gmail.com> Link: https://patch.msgid.link/20250520161916.413298-3-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-21tools: ynl-gen: add makefile deps for neighJakub Kicinski
Kory is reporting build issues after recent additions to YNL if the system headers are old. Link: https://lore.kernel.org/20250519164949.597d6e92@kmaincent-XPS-13-7390 Reported-by: Kory Maincent <kory.maincent@bootlin.com> Fixes: 0939a418b3b0 ("tools: ynl: submsg: reverse parse / error reporting") Tested-by: Kory Maincent <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20250520161916.413298-2-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-21PCI/MSI: Use bool for MSI enable state trackingHans Zhang
Convert pci_msi_enable and pci_msi_enabled() to use bool type for clarity. No functional changes, only code cleanup. Signed-off-by: Hans Zhang <hans.zhang@cixtech.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20250516165223.125083-2-18255117159@163.com
2025-05-21spi: spi-qpic-snand: remove superfluous parameters of qcom_spi_check_error()Gabor Juhos
The qcom_spi_check_error() function determines the errors of a previous page read operation solely by using the cached register values in the register read buffer. The data pointed by the 'data_buf' and the 'oob_buf' parameters are not used for that at all. Remove the superfluous parameters of the function along with the related local variables to simplify the code. Also, remove the variables from the caller functions which became unused due to the change. Note: Althought the similar parse_read_errors() function in the 'qcom_nand' driver has the same parameters, but that function passes down the pointers to check_for_erased_page() at the end of the function. It is not clear, that a similar call is missing here, or the superfluous parameters are simply leftovers of the development process. Nevertheless, if additional code is needed, the parameters can be added back later. Signed-off-by: Gabor Juhos <j4g8y7@gmail.com> Link: https://patch.msgid.link/20250520-qpic-snand-superfluous-params-v1-1-86dd4963e90f@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-21dt-bindings: spi: samsung: add exynosautov920-spi compatibleFaraz Ata
Add "samsung,exynosautov920-spi" dedicated compatible for SPI found in ExynosAutov920 SoC. Signed-off-by: Faraz Ata <faraz.ata@samsung.com> Link: https://patch.msgid.link/20250521084324.2759530-1-faraz.ata@samsung.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-21spi: spi-qpic-snand: reuse qcom_spi_check_raw_flash_errors()Gabor Juhos
The qcom_spi_check_raw_flash_errors() function can be used to verify the flash status after raw operations. Move the function slightly up in the code and change the qcom_spi_read_last_cw() function to call it instead of using an open coded implementation of the same check. Signed-off-by: Gabor Juhos <j4g8y7@gmail.com> Link: https://patch.msgid.link/20250514-qpic-snand-error-check-v1-1-c0ebd3aae72a@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-21scripts/gdb/symbols: determine KASLR offset on s390 during early bootIlya Leoshkevich
Using lx-symbols during s390 early boot fails with: Error occurred in Python: 'utf-8' codec can't decode byte 0xcb in position 0: invalid continuation byte The reason is that s390 decompressor's startup_kernel() does not create vmcoreinfo note, and sets vmcore_info to kernel's physical base. This confuses get_vmcore_s390(). Fix by handling this special case. Extract vm_layout.kaslr_offset from the kernel image in physical memory, which is placed there by the decompressor using the __bootdata_preserved mechanism, and generate a synthetic vmcoreinfo note from it. Link: https://lkml.kernel.org/r/20250515155811.114392-4-iii@linux.ibm.com Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Cc: Alexander Gordeev <agordeev@linux.ibm.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Jan Kiszka <jan.kiszka@siemens.com> Cc: Kieran Bingham <kbingham@kernel.org> Cc: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-21scripts/gdb/symbols: factor out pagination_off()Ilya Leoshkevich
Move the code that turns off pagination into a separate function. It will be useful later in order to prevent hangs when loading symbols for kernel image in physical memory during s390 early boot. Link: https://lkml.kernel.org/r/20250515155811.114392-3-iii@linux.ibm.com Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Cc: Alexander Gordeev <agordeev@linux.ibm.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Jan Kiszka <jan.kiszka@siemens.com> Cc: Kieran Bingham <kbingham@kernel.org> Cc: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-21scripts/gdb/symbols: factor out get_vmlinux()Ilya Leoshkevich
Patch series "scripts/gdb/symbols: determine KASLR offset on s390 during early boot". I noticed that debugging s390 early boot using the support I introduced in commit 28939c3e9925 ("scripts/gdb/symbols: determine KASLR offset on s390") does not work. The reason is that decompressor does not provide the vmcoreinfo note, so KASLR offset needs to be extracted in a different way, which this series implements. Patches 1-2 are trivial refactorings, and patch 3 is the implementation. This patch (of 3): Move the code that determines the current vmlinux file into a separate function. It will be useful later in order to analyze the kernel image in physical memory during s390 early boot. Link: https://lkml.kernel.org/r/20250515155811.114392-1-iii@linux.ibm.com Link: https://lkml.kernel.org/r/20250515155811.114392-2-iii@linux.ibm.com Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Cc: Alexander Gordeev <agordeev@linux.ibm.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Jan Kiszka <jan.kiszka@siemens.com> Cc: Kieran Bingham <kbingham@kernel.org> Cc: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-21kernel/panic.c: format kernel-doc commentsSravan Kumar Gundu
kernel-doc function comment don't follows documentation commenting style misinterpreting arguments description with function description. Please see latest docs generated before applying this patch https://docs.kernel.org/driver-api/basics.html#c.panic Link: https://lkml.kernel.org/r/20250516174031.2937-1-sravankumarlpu@gmail.com Signed-off-by: Sravan Kumar Gundu <sravankumarlpu@gmail.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jani Nikula <jani.nikula@intel.com> Cc: John Ogness <john.ogness@linutronix.de> Cc: Petr Mladek <pmladek@suse.com> Cc: Shuah Khan <shuah@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-21mailmap: update and consolidate Casey Connolly's name and emailCasey Connolly
I've used several email addresses and a previous name to contribute. Consolidate all of these to my primary email and update my name. Link: https://lkml.kernel.org/r/20250517223237.15647-2-casey.connolly@linaro.org Signed-off-by: Casey Connolly <casey.connolly@linaro.org> Cc: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-21nilfs2: remove wbc->for_reclaim handlingChristoph Hellwig
Since commit 013a07052a1a ("nilfs2: convert metadata aops from writepage to writepages"), nilfs_mdt_write_folio can't be called from reclaim context any more. Remove the code keyed of the wbc->for_reclaim flag, which is now only set for writing out swap or shmem pages inside the swap code, but never passed to file systems. Link: https://lkml.kernel.org/r/20250508054938.15894-7-hch@lst.de Link: https://lkml.kernel.org/r/20250516123417.6779-1-konishi.ryusuke@gmail.com Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-21fork: define a local GFP_VMAP_STACKLinus Walleij
The current allocation of VMAP stack memory is using (THREADINFO_GFP & ~__GFP_ACCOUNT) which is a complicated way of saying (GFP_KERNEL | __GFP_ZERO): <linux/thread_info.h>: define THREADINFO_GFP (GFP_KERNEL_ACCOUNT | __GFP_ZERO) <linux/gfp_types.h>: define GFP_KERNEL_ACCOUNT (GFP_KERNEL | __GFP_ACCOUNT) This is an unfortunate side-effect of independent changes blurring the picture: commit 19809c2da28aee5860ad9a2eff760730a0710df0 changed (THREADINFO_GFP | __GFP_HIGHMEM) to just THREADINFO_GFP since highmem became implicit. commit 9b6f7e163cd0f468d1b9696b785659d3c27c8667 then added stack caching and rewrote the allocation to (THREADINFO_GFP & ~__GFP_ACCOUNT) as cached stacks need to be accounted separately. However that code, when it eventually accounts the memory does this: ret = memcg_kmem_charge(vm->pages[i], GFP_KERNEL, 0) so the memory is charged as a GFP_KERNEL allocation. Define a unique GFP_VMAP_STACK to use GFP_KERNEL | __GFP_ZERO and move the comment there. Link: https://lkml.kernel.org/r/20250509-gfp-stack-v1-1-82f6f7efc210@linaro.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reported-by: Mateusz Guzik <mjguzik@gmail.com> Cc: Pasha Tatashin <pasha.tatashin@soleen.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-21fork: check charging success before zeroing stackPasha Tatashin
No need to do zero cached stack if memcg charge fails, so move the charging attempt before the memset operation. [linus.walleij@linaro.org: rebased] Link: https://lkml.kernel.org/r/20250509-fork-fixes-v3-3-e6c69dd356f2@linaro.org Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com> Link: https://lore.kernel.org/20240311164638.2015063-6-pasha.tatashin@soleen.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-21fork: clean-up naming of vm_stack/vm_struct variables in vmap stacks codePasha Tatashin
There are two data types: "struct vm_struct" and "struct vm_stack" that have the same local variable names: vm_stack, or vm, or s, which makes the code confusing to read. Change the code so the naming is consistent: struct vm_struct is always called vm_area struct vm_stack is always called vm_stack One change altering vfree(vm_stack) to vfree(vm_area->addr) may look like a semantic change but it is not: vm_area->addr points to the vm_stack. This was done to improve readability. [linus.walleij@linaro.org: rebased and added new users of the variable names, address review comments] Link: https://lore.kernel.org/20240311164638.2015063-4-pasha.tatashin@soleen.com Link: https://lkml.kernel.org/r/20250509-fork-fixes-v3-2-e6c69dd356f2@linaro.org Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-21fork: clean-up ifdef logic around stack allocationPasha Tatashin
Patch series "fork: Page operation cleanups in the fork code", v3. This patchset consists of outtakes from a 1 year+ old patchset from Pasha, which all stand on their own. See: https://lore.kernel.org/all/20240311164638.2015063-1-pasha.tatashin@soleen.com/ These are good cleanups for readability so I split these off, rebased on v6.15-rc1, addressed review comments and send them separately. All mentions of dynamic stack are removed from the patchset as we have no idea whether that will go anywhere. This patch (of 3): There is unneeded OR in the ifdef functions that are used to allocate and free kernel stacks based on direct map or vmap. Therefore, clean up by changing the order so OR is no longer needed. [linus.walleij@linaro.org: rebased] Link: https://lkml.kernel.org/r/20250509-fork-fixes-v3-1-e6c69dd356f2@linaro.org Link: https://lkml.kernel.org/r/20250509-fork-fixes-v3-0-e6c69dd356f2@linaro.org Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com> Link: https://lore.kernel.org/20240311164638.2015063-3-pasha.tatashin@soleen.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-21kernel/rcu/tree_stall: add /sys/kernel/rcu_stall_countMax Kellermann
Expose a simple counter to userspace for monitoring tools. Link: https://lkml.kernel.org/r/20250504180831.4190860-3-max.kellermann@ionos.com Signed-off-by: Max Kellermann <max.kellermann@ionos.com> Cc: Core Minyard <cminyard@mvista.com> Cc: Doug Anderson <dianders@chromium.org> Cc: Joel Granados <joel.granados@kernel.org> Cc: Kees Cook <kees@kernel.org> Cc: Song Liu <song@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-21kernel/watchdog: add /sys/kernel/{hard,soft}lockup_countMax Kellermann
Patch series "sysfs: add counters for lockups and stalls", v2. Commits 9db89b411170 ("exit: Expose "oops_count" to sysfs") and 8b05aa263361 ("panic: Expose "warn_count" to sysfs") added counters for oopses and warnings to sysfs, and these two patches do the same for hard/soft lockups and RCU stalls. All of these counters are useful for monitoring tools to detect whether the machine is healthy. If the kernel has experienced a lockup or a stall, it's probably due to a kernel bug, and I'd like to detect that quickly and easily. There is currently no way to detect that, other than parsing dmesg. Or observing indirect effects: such as certain tasks not responding, but then I need to observe all tasks, and it may take a while until these effects become visible/measurable. I'd rather be able to detect the primary cause more quickly, possibly before everything falls apart. This patch (of 2): There is /proc/sys/kernel/hung_task_detect_count, /sys/kernel/warn_count and /sys/kernel/oops_count but there is no userspace-accessible counter for hard/soft lockups. Having this is useful for monitoring tools. Link: https://lkml.kernel.org/r/20250504180831.4190860-1-max.kellermann@ionos.com Link: https://lkml.kernel.org/r/20250504180831.4190860-2-max.kellermann@ionos.com Signed-off-by: Max Kellermann <max.kellermann@ionos.com> Cc: Cc: Core Minyard <cminyard@mvista.com> Cc: Doug Anderson <dianders@chromium.org> Cc: Joel Granados <joel.granados@kernel.org> Cc: Song Liu <song@kernel.org> Cc: Kees Cook <kees@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-21x86/crash: make the page that stores the dm crypt keys inaccessibleCoiby Xu
This adds an addition layer of protection for the saved copy of dm crypt key. Trying to access the saved copy will cause page fault. Link: https://lkml.kernel.org/r/20250502011246.99238-9-coxu@redhat.com Signed-off-by: Coiby Xu <coxu@redhat.com> Suggested-by: Pingfan Liu <kernelfans@gmail.com> Acked-by: Baoquan He <bhe@redhat.com> Cc: "Daniel P. Berrange" <berrange@redhat.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Dave Young <dyoung@redhat.com> Cc: Jan Pazdziora <jpazdziora@redhat.com> Cc: Milan Broz <gmazyland@gmail.com> Cc: Ondrej Kozina <okozina@redhat.com> Cc: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-21x86/crash: pass dm crypt keys to kdump kernelCoiby Xu
1st kernel will build up the kernel command parameter dmcryptkeys as similar to elfcorehdr to pass the memory address of the stored info of dm crypt key to kdump kernel. Link: https://lkml.kernel.org/r/20250502011246.99238-8-coxu@redhat.com Signed-off-by: Coiby Xu <coxu@redhat.com> Acked-by: Baoquan He <bhe@redhat.com> Cc: "Daniel P. Berrange" <berrange@redhat.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Dave Young <dyoung@redhat.com> Cc: Jan Pazdziora <jpazdziora@redhat.com> Cc: Liu Pingfan <kernelfans@gmail.com> Cc: Milan Broz <gmazyland@gmail.com> Cc: Ondrej Kozina <okozina@redhat.com> Cc: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-21Revert "x86/mm: Remove unused __set_memory_prot()"Coiby Xu
This reverts commit 693bbf2a50447353c6a47961e6a7240a823ace02 as kdump LUKS support (CONFIG_CRASH_DM_CRYPT) depends on __set_memory_prot. [akpm@linux-foundation.org: x86 set_memory.h needs pgtable_types.h] Link: https://lkml.kernel.org/r/20250502011246.99238-7-coxu@redhat.com Signed-off-by: Coiby Xu <coxu@redhat.com> Cc: Baoquan He <bhe@redhat.com> Cc: "Daniel P. Berrange" <berrange@redhat.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Dave Young <dyoung@redhat.com> Cc: Jan Pazdziora <jpazdziora@redhat.com> Cc: Liu Pingfan <kernelfans@gmail.com> Cc: Milan Broz <gmazyland@gmail.com> Cc: Ondrej Kozina <okozina@redhat.com> Cc: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-21crash_dump: retrieve dm crypt keys in kdump kernelCoiby Xu
Crash kernel will retrieve the dm crypt keys based on the dmcryptkeys command line parameter. When user space writes the key description to /sys/kernel/config/crash_dm_crypt_key/restore, the crash kernel will save the encryption keys to the user keyring. Then user space e.g. cryptsetup's --volume-key-keyring API can use it to unlock the encrypted device. Link: https://lkml.kernel.org/r/20250502011246.99238-6-coxu@redhat.com Signed-off-by: Coiby Xu <coxu@redhat.com> Acked-by: Baoquan He <bhe@redhat.com> Cc: "Daniel P. Berrange" <berrange@redhat.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Dave Young <dyoung@redhat.com> Cc: Jan Pazdziora <jpazdziora@redhat.com> Cc: Liu Pingfan <kernelfans@gmail.com> Cc: Milan Broz <gmazyland@gmail.com> Cc: Ondrej Kozina <okozina@redhat.com> Cc: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-21crash_dump: reuse saved dm crypt keys for CPU/memory hot-pluggingCoiby Xu
When there are CPU and memory hot un/plugs, the dm crypt keys may need to be reloaded again depending on the solution for crash hotplug support. Currently, there are two solutions. One is to utilizes udev to instruct user space to reload the kdump kernel image and initrd, elfcorehdr and etc again. The other is to only update the elfcorehdr segment introduced in commit 247262756121 ("crash: add generic infrastructure for crash hotplug support"). For the 1st solution, the dm crypt keys need to be reloaded again. The user space can write true to /sys/kernel/config/crash_dm_crypt_key/reuse so the stored keys can be re-used. For the 2nd solution, the dm crypt keys don't need to be reloaded. Currently, only x86 supports the 2nd solution. If the 2nd solution gets extended to all arches, this patch can be dropped. Link: https://lkml.kernel.org/r/20250502011246.99238-5-coxu@redhat.com Signed-off-by: Coiby Xu <coxu@redhat.com> Acked-by: Baoquan He <bhe@redhat.com> Cc: "Daniel P. Berrange" <berrange@redhat.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Dave Young <dyoung@redhat.com> Cc: Jan Pazdziora <jpazdziora@redhat.com> Cc: Liu Pingfan <kernelfans@gmail.com> Cc: Milan Broz <gmazyland@gmail.com> Cc: Ondrej Kozina <okozina@redhat.com> Cc: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-21crash_dump: store dm crypt keys in kdump reserved memoryCoiby Xu
When the kdump kernel image and initrd are loaded, the dm crypts keys will be read from keyring and then stored in kdump reserved memory. Assume a key won't exceed 256 bytes thus MAX_KEY_SIZE=256 according to "cryptsetup benchmark". Link: https://lkml.kernel.org/r/20250502011246.99238-4-coxu@redhat.com Signed-off-by: Coiby Xu <coxu@redhat.com> Acked-by: Baoquan He <bhe@redhat.com> Cc: "Daniel P. Berrange" <berrange@redhat.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Dave Young <dyoung@redhat.com> Cc: Jan Pazdziora <jpazdziora@redhat.com> Cc: Liu Pingfan <kernelfans@gmail.com> Cc: Milan Broz <gmazyland@gmail.com> Cc: Ondrej Kozina <okozina@redhat.com> Cc: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-21crash_dump: make dm crypt keys persist for the kdump kernelCoiby Xu
A configfs /sys/kernel/config/crash_dm_crypt_keys is provided for user space to make the dm crypt keys persist for the kdump kernel. Take the case of dumping to a LUKS-encrypted target as an example, here is the life cycle of the kdump copies of LUKS volume keys, 1. After the 1st kernel loads the initramfs during boot, systemd uses an user-input passphrase to de-crypt the LUKS volume keys or simply TPM-sealed volume keys and then save the volume keys to specified keyring (using the --link-vk-to-keyring API) and the keys will expire within specified time. 2. A user space tool (kdump initramfs loader like kdump-utils) create key items inside /sys/kernel/config/crash_dm_crypt_keys to inform the 1st kernel which keys are needed. 3. When the kdump initramfs is loaded by the kexec_file_load syscall, the 1st kernel will iterate created key items, save the keys to kdump reserved memory. 4. When the 1st kernel crashes and the kdump initramfs is booted, the kdump initramfs asks the kdump kernel to create a user key using the key stored in kdump reserved memory by writing yes to /sys/kernel/crash_dm_crypt_keys/restore. Then the LUKS encrypted device is unlocked with libcryptsetup's --volume-key-keyring API. 5. The system gets rebooted to the 1st kernel after dumping vmcore to the LUKS encrypted device is finished Eventually the keys have to stay in the kdump reserved memory for the kdump kernel to unlock encrypted volumes. During this process, some measures like letting the keys expire within specified time are desirable to reduce security risk. This patch assumes, 1) there are 128 LUKS devices at maximum to be unlocked thus MAX_KEY_NUM=128. 2) a key description won't exceed 128 bytes thus KEY_DESC_MAX_LEN=128. And here is a demo on how to interact with /sys/kernel/config/crash_dm_crypt_keys, # Add key #1 mkdir /sys/kernel/config/crash_dm_crypt_keys/7d26b7b4-e342-4d2d-b660-7426b0996720 # Add key #1's description echo cryptsetup:7d26b7b4-e342-4d2d-b660-7426b0996720 > /sys/kernel/config/crash_dm_crypt_keys/description # how many keys do we have now? cat /sys/kernel/config/crash_dm_crypt_keys/count 1 # Add key# 2 in the same way # how many keys do we have now? cat /sys/kernel/config/crash_dm_crypt_keys/count 2 # the tree structure of /crash_dm_crypt_keys configfs tree /sys/kernel/config/crash_dm_crypt_keys/ /sys/kernel/config/crash_dm_crypt_keys/ ├── 7d26b7b4-e342-4d2d-b660-7426b0996720 │   └── description ├── count ├── fce2cd38-4d59-4317-8ce2-1fd24d52c46a │   └── description Link: https://lkml.kernel.org/r/20250502011246.99238-3-coxu@redhat.com Signed-off-by: Coiby Xu <coxu@redhat.com> Acked-by: Baoquan He <bhe@redhat.com> Cc: "Daniel P. Berrange" <berrange@redhat.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Dave Young <dyoung@redhat.com> Cc: Jan Pazdziora <jpazdziora@redhat.com> Cc: Liu Pingfan <kernelfans@gmail.com> Cc: Milan Broz <gmazyland@gmail.com> Cc: Ondrej Kozina <okozina@redhat.com> Cc: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
generated by cgit (git 2.34.1) at 2025-09-16 14:44:42 +0000