summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-01-27Revert "tty: tty_port: add workqueue to flip TTY buffer"Greg Kroah-Hartman
This reverts commit d000422a46aad32217cf1be747eb61d641baae2f. It is reported by many to cause boot failures, so must be reverted. Cc: Xin Zhao <jackzxcui1989@163.com> Cc: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/d1942304-ee30-478d-90fb-279519f3ae81@samsung.com Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Reported-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-27Merge tag 'iwlwifi-next-2026-01-21' of ↵Johannes Berg
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next Miri Korenblit says: ==================== iwlwifi features. Notably: - Partial NAN support - without DATA - Initial UHR support - UNII-9 support - EHT code cleanup in iwlmvm ==================== Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-27Merge tag 'ath-next-20260120' of ↵Johannes Berg
git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath Jeff Johnson says: ================== ath.git patches for v6.20 (#2) Highlights for some specific drivers include: ath11k: Add support for Channel Frequency Response measurement. ath12k: Add support for the QCC2072 chipset. And of course there is the usual set of cleanups and bug fixes across the entire family of "ath" drivers. ================== Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-27ASoC: sophgo: add CV1800B internal DAC codec driverAnton D. Stavinskii
Codec DAI endpoint for TXDAC. The codec does only a few things - set up decimation - enable codec and I2S output - ensures the driver doesn't have dac overwrite enabled. (unmute the output) Signed-off-by: Anton D. Stavinskii <stavinsky@gmail.com> Link: https://patch.msgid.link/20260120-cv1800b-i2s-driver-v4-5-6ef787dc6426@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-27ASoC: sophgo: add CV1800B internal ADC codec driverAnton D. Stavinskii
Codec DAI endpoint for RXADC + basic controls. THe codec have basic volume control. Which is imlemented by lookup table for simplicity. The codec expects set_sysclk callback to adjust internal mclk divider. Signed-off-by: Anton D. Stavinskii <stavinsky@gmail.com> Link: https://patch.msgid.link/20260120-cv1800b-i2s-driver-v4-4-6ef787dc6426@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-27wifi: iwlegacy: add missing mutex protection in il4965_store_tx_power()Ziyi Guo
il4965_store_tx_power() calls il_set_tx_power() without holding il->mutex. However, il_set_tx_power() has lockdep_assert_held(&il->mutex) indicating that callers must hold this lock. All other callers of il_set_tx_power() properly acquire the mutex: - il_bg_scan_completed() acquires mutex at common.c:1683 - il_mac_config() acquires mutex at common.c:5006 - il3945_commit_rxon() and il4965_commit_rxon() are called via work queues that hold the mutex (like il4965_bg_alive_start) Add mutex_lock()/mutex_unlock() around the il_set_tx_power() call in the sysfs store function to fix the missing lock protection. Signed-off-by: Ziyi Guo <n7l8m4@u.northwestern.edu> Acked-by: Stanislaw Gruszka <stf_xl@wp.pl> Link: https://patch.msgid.link/20260125194039.1196488-1-n7l8m4@u.northwestern.edu Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-27ASoC: dt-bindings: sophgo,cv1800b: add ADC/DAC codecAnton D. Stavinskii
Document the internal ADC and DAC audio codecs integrated in the Sophgo CV1800B SoC. Signed-off-by: Anton D. Stavinskii <stavinsky@gmail.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260120-cv1800b-i2s-driver-v4-3-6ef787dc6426@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-27ASoC: sophgo: add CV1800B I2S/TDM controller driverAnton D. Stavinskii
The actual CPU DAI controller. The driver can be used with simple-audio-card. It respects fixed clock configuration from simple-audio-card. The card driver can request direction out, this will be interpreted as mclk out, the clock which can be used in other CPU or codecs. For example I2S3 generates clock for ADC. I2S was tested in S24_32 and S16 dual channel formats. Signed-off-by: Anton D. Stavinskii <stavinsky@gmail.com> Link: https://patch.msgid.link/20260120-cv1800b-i2s-driver-v4-2-6ef787dc6426@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-27ASoC: dt-bindings: sophgo,cv1800b: add I2S/TDM controllerAnton D. Stavinskii
There are 4 TDM controllers on the SoC. Each controller can receive or transmit data over DMA. The dma it self has 8 channels. Each channel can be connected only to a specific i2s node. But each of dma channel can have multiple purposes so in order to save dma channels the configurations allows to use tx and rx, only rx, only tx or none channels. I2S controller without channels can be useful in configuration where I2S is used as clock source only and doesn't produce any data. Signed-off-by: Anton D. Stavinskii <stavinsky@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260120-cv1800b-i2s-driver-v4-1-6ef787dc6426@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-27wifi: iwlegacy: add missing mutex protection in il3945_store_measurement()Ziyi Guo
il3945_store_measurement() calls il3945_get_measurement() which internally calls il_send_cmd_sync() without holding il->mutex. However, il_send_cmd_sync() has lockdep_assert_held(&il->mutex) indicating that callers must hold this lock. Other sysfs store functions in the same file properly acquire the mutex: - il3945_store_flags() acquires mutex at 3945-mac.c:3110 - il3945_store_filter_flags() acquires mutex at 3945-mac.c:3144 Add mutex_lock()/mutex_unlock() around the il3945_get_measurement() call in the sysfs store function to fix the missing lock protection. Signed-off-by: Ziyi Guo <n7l8m4@u.northwestern.edu> Acked-by: Stanislaw Gruszka <stf_xl@wp.pl> Link: https://patch.msgid.link/20260125193005.1090429-1-n7l8m4@u.northwestern.edu Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-27spi: dw-mmio: support suspend/resumeJisheng Zhang
Add system wide suspend and resume support, the implementation is straightforward, just call spi_controller_suspend() then assert the reset and disable clks for suspend, enable clks and deassert reset then call spi_controller_resume() for resume. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Link: https://patch.msgid.link/20260122155046.12848-1-jszhang@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-27spi: cadence-xspi: support suspend/resumeJisheng Zhang
Add system wide suspend and resume support, the suspend hook implementation is straightforward, just call spi_controller_suspend() While the resume hook implementation is a bit complex, we need to redo something which is done during probe, such as enable the interrupts, setup clk and config the phy for mrvl hw overlay. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Link: https://patch.msgid.link/20260122155119.12865-1-jszhang@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-27spi: aspeed: Add support for non-spi-mem devicesChin-Ting Kuo
The ASPEED FMC/SPI controller may be shared by spi-mem devices and other SPI peripherals that do not use the spi-mem framework. The driver currently assumes spi-mem semantics for all devices, while the controller also supports direct user mode access commonly used by non-spi-mem devices. This mismatch can result in incorrect behavior when different types of devices share the same controller. Therefore, a user mode based path for non-spi-mem devices is added by implementing the transfer_one() callback and wiring up prepare_message() and unprepare_message() so controller state is initialized and restored for user mode transfers. This allows non-spi-mem devices to operate correctly alongside spi-mem devices on a shared controller. This patch has been tested on: - AST2700 EVB + Infineon and ST SPI TPM device. - AST2x00 EVB + spidev_test utility and the output waveforms are verified with logic analyzer. - AST2x00 EVB + SPI NOR flash read/write regression. Signed-off-by: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com> Link: https://patch.msgid.link/20260120123005.1392071-3-chin-ting_kuo@aspeedtech.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-27spi: spi-mem: Protect dirmap_create() with spi_mem_access_start/endChin-Ting Kuo
spi_mem_dirmap_create() may reconfigure controller-wide settings, which can interfere with concurrent transfers to other devices sharing the same SPI controller but using different chip selects. Wrap the ->dirmap_create() callback with spi_mem_access_start() and spi_mem_access_end() to serialize access and prevent cross-CS interference during dirmap creation. This patch has been verified on a setup where a SPI TPM is connected to CS0 of a SPI controller, while a SPI NOR flash is connected to CS1 of the same controller. Without this patch, spi_mem_dirmap_create() for the SPI NOR flash interferes with ongoing SPI TPM data transfers, resulting in failure to create the TPM device. This was tested on an ASPEED AST2700 EVB. Signed-off-by: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Link: https://patch.msgid.link/20260120123005.1392071-2-chin-ting_kuo@aspeedtech.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-27regcache: Demote defaults readback from HW to debug printMarek Vasut
Since commit 632e04739c8f ("clk: rs9: Fix suspend/resume"), the clk-renesas-pcie-9series driver produces the following print in kernel log on boot: " clk-renesas-pcie-9series 8-0068: No cache defaults, reading back from HW " This is caused by the presence of .num_reg_defaults_raw in its struct regmap_config, without a matching .reg_defaults_raw table of built-in register default values. This configuration is valid, and causes the regcache code to read the default register settings from the hardware, which is a valid behavior for this particular chip. In fact, this configuration is more common than configuration with .reg_defaults_raw built-in register defaults. Do not warn about the read of default values being read from hardware, as that is too strong and seems unnecessary, turn the warning into a debug print. Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Link: https://patch.msgid.link/20260121234309.178391-1-marek.vasut+renesas@mailbox.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-27regmap: add KUnit coverage for reg_default_cb callbackSheetal
Add a flat-cache KUnit test that verifies reg_defaults are honored while missing entries are populated via the reg_default_cb callback without hardware reads. This exercises the new callback path added for REGCACHE_FLAT defaults. Test: ./tools/testing/kunit/kunit.py run regmap Result: ======== reg_default_callback_populates_flat_cache ======== [PASSED] flat-default @0x0 [PASSED] flat-default fast I/O @0x0 [PASSED] flat-default @0x2001 ==== [PASSED] reg_default_callback_populates_flat_cache ==== Signed-off-by: Sheetal <sheetal@nvidia.com> Link: https://patch.msgid.link/20260123095346.1258556-5-sheetal@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-27regmap: Add reg_default_cb callback for flat cache defaultsSheetal
Commit e062bdfdd6ad ("regmap: warn users about uninitialized flat cache") warns when REGCACHE_FLAT is used without full defaults. This causes false positives on hardware where many registers reset to zero but are not listed in reg_defaults, forcing drivers to maintain large tables just to silence the warning. Add a reg_default_cb() hook so drivers can supply defaults for registers not present in reg_defaults when populating REGCACHE_FLAT. This keeps the warning quiet for known zero-reset registers without bloating tables. Provide a generic regmap_default_zero_cb() helper for drivers that need zero defaults. The hook is only used for REGCACHE_FLAT; the core does not check readable/writeable access, so drivers must provide readable_reg/ writeable_reg callbacks and handle holes in the register map. Signed-off-by: Sheetal <sheetal@nvidia.com> Link: https://patch.msgid.link/20260123095346.1258556-3-sheetal@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-27ASoC: sunxi: sun50i-dmic: Add missing check for devm_regmap_init_mmioChen Ni
Add check for the return value of devm_regmap_init_mmio() and return the error if it fails in order to catch the error. Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Link: https://patch.msgid.link/20260127033250.2044608-1-nichen@iscas.ac.cn Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-27ASoC: sun4i-spdif: Add missing check for devm_regmap_init_mmioChen Ni
Add check for the return value of devm_regmap_init_mmio() and return the error if it fails in order to catch the error. Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Link: https://patch.msgid.link/20260127034025.2044669-1-nichen@iscas.ac.cn Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-27ASoC: ac97: Convert to GPIO descriptorsPeng Fan
of_gpio.h is deprecated, update the driver to use GPIO descriptors. - Use devm_gpiod_get to get GPIO descriptor, and set consumer name. Since the driver still pass the reset_gpio to pxa27x_configure_ac97reset, so use desc_to_gpio() to get it gpio id. Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://patch.msgid.link/20260122-sound-cleanup-v1-4-0a91901609b8@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-27ASoC: pxa2xx-ac97: Remove platform_dataPeng Fan
Since commit d6df7df7ae5a0 ("ARM: pxa: remove unused board files"), there has been no in-tree user to create the device with platform data. So remove them. Signed-off-by: Peng Fan <peng.fan@nxp.com> Acked-by: Andy Shevchenko <andriy.shevchenko@intel.com> Link: https://patch.msgid.link/20260122-sound-cleanup-v1-3-0a91901609b8@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-27ASoC: codec: Remove pxa2xx-ac97.cPeng Fan
With commit ce79f3a1ad5f ("ARM: pxa: prune unused device support") and commit 2548e6c76ebf ("ARM: pxa: pxa2xx-ac97-lib: use IRQ resource"), there is no 'pxa2xx-ac97' platform device created by machine level code, so this driver could be removed. Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Acked-by: Andy Shevchenko <andriy.shevchenko@intel.com> Link: https://patch.msgid.link/20260122-sound-cleanup-v1-2-0a91901609b8@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-27ASoC: codec: Remove ak4641Peng Fan
Since commit d6df7df7ae5a0 ("ARM: pxa: remove unused board files"), there has been no in-tree user of the AK4641 codec driver. The last user (HP iPAQ hx4700) was a non-DT PXA board file that instantiated the device via I2C board data; that code was removed as part of the PXA board-file purge. The AK4641 driver was introduced ~2011 and still probes only via the I2C device-ID table ('.id_table'), without an 'of_match_table', so there are no upstream Devicetree users to retain. With no in-tree users left, remove the driver. Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Acked-by: Andy Shevchenko <andriy.shevchenko@intel.com> Link: https://patch.msgid.link/20260122-sound-cleanup-v1-1-0a91901609b8@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-27ASoC: Intel: sof_es8336: fix headphone GPIO logic inversionTagir Garaev
The headphone GPIO should be set to the inverse of speaker_en. When speakers are enabled, headphones should be disabled and vice versa. Currently both GPIOs are set to the same value (speaker_en), causing audio to play through both speakers and headphones simultaneously when headphones are plugged in. Tested on Huawei Matebook (BOD-WXX9) with ES8336 codec. Fixes: 6e1ff1459e00 ("ASoC: Intel: sof_es8336: support a separate gpio to control headphone") Signed-off-by: Tagir Garaev <tgaraev653@gmail.com> Link: https://patch.msgid.link/20260121152435.101698-1-tgaraev653@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-27wifi: mac80211: use u64_stats_t with u64_stats_sync properlyDavid Yang
On 64bit arches, struct u64_stats_sync is empty and provides no help against load/store tearing. Convert to u64_stats_t to ensure atomic operations. Signed-off-by: David Yang <mmyangfl@gmail.com> Link: https://patch.msgid.link/20260123203845.2915525-1-mmyangfl@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-27wifi: p54: Fix memory leak in p54_beacon_update()Zilin Guan
In p54_beacon_update(), beacon is allocated via ieee80211_beacon_get(). If p54_beacon_format_ie_tim() fails, the function returns immediately without freeing the allocated beacon skb, which would lead to a memory leak. Since no other references to this memory exist, it must be freed locally before returning the error. Fix this by freeing the buffer using dev_kfree_skb_any() in the error path. Note that this error path is unreachable in practice because mac80211 guarantees a minimum TIM length of 4 bytes for non-S1G devices. This change primarily serves to silence static analysis warnings and keep the error handling logic complete. Compile tested only. Issue found using a prototype static analysis tool and code review. Signed-off-by: Zilin Guan <zilin@seu.edu.cn> Acked-by: Christian Lamparter <chunkeey@gmail.com> Link: https://patch.msgid.link/20260122085945.444955-1-zilin@seu.edu.cn Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-27wifi: cfg80211: treat deprecated INDOOR_SP_AP_OLD control value as LPI modePagadala Yesu Anjaneyulu
Although value 4 (INDOOR_SP_AP_OLD) is deprecated in IEEE standards, existing APs may still use this control value. Since this value is based on the old specification, we cannot trust such APs implement proper power controls. Therefore, move IEEE80211_6GHZ_CTRL_REG_INDOOR_SP_AP_OLD case from SP_AP to LPI_AP power type handling to prevent potential power limit violations. Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260111163601.6b5a36d3601e.I1704ee575fd25edb0d56f48a0a3169b44ef72ad0@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-27wifi: rtw88: sdio: Migrate to use sdio specific shutdown functionUwe Kleine-König
This saves a cast in the driver. The motivation is stop using the callback .shutdown in rsi_driver.drv to make it possible to drop that. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/5a328658c20613068bbbfabd3d0e721b69b3d474.1768232321.git.u.kleine-koenig@baylibre.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-27wifi: rsi: sdio: Migrate to use sdio specific shutdown functionUwe Kleine-König
This saves a cast in the driver. The motivation is stop using the callback .shutdown in rsi_driver.drv to make it possible to drop that. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://patch.msgid.link/2909323889b8ad4732ef6a8e05b5c40487a6c4bb.1768232321.git.u.kleine-koenig@baylibre.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-27sdio: Provide a bustype shutdown functionUwe Kleine-König
To prepare sdio drivers to migrate away from struct device_driver::shutdown (and then eventually remove that callback) create a serdev driver shutdown callback and migration code to keep the existing behaviour. Note this introduces a warning for each driver that isn't converted yet to that callback at register time. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://patch.msgid.link/397f45c2818f6632151f92b70e547262f373c3b6.1768232321.git.u.kleine-koenig@baylibre.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-27wifi: nl80211/cfg80211: support operating as RSTA in PMSR FTM requestAvraham Stern
Add an option to operate as the RSTA in an FTM measurement request. When requested, the device will dwell on the requested channel until the peer starts the FTM negotiation. This option is only valid for trigger-based/non trigger-based measurement with LMR feedback which will allow the RSTA to receive the results of the measurement. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260111190221.1f95fc0afab4.Iae2d32783b8e7c4a29089fec0f4c6bce94d303cc@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-27wifi: nl80211/cfg80211: add negotiated burst period to FTM resultAvraham Stern
The FTM result includes some of the periodic measurement negotiated parameters (like the burst duration and number of bursts), but it doesn't include the burst period. Add it to the FTM result notification. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260111190221.e0778f86edef.I3c98c1933eb639963bc3ffdef81a8788b59f2188@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-27wifi: nl80211/cfg80211: clarify periodic FTM parameters for non-EDCA based ↵Avraham Stern
ranging Periodic FTM request attributes are defined based on the periodic parameters used in EDCA-based ranging negotiation. However, non-EDCA based ranging (trigger-based/non-trigger-based) does not include periodic parameters in the negotiation protocol, even though upper layers may still request periodic measurements. Clarify the semantics of periodic ranging attributes when used with non-EDCA based ranging. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260111190221.b89cb3f68e1a.I7a9d8c6d1c66c77f1b43120a841101c96c3f19ad@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-27wifi: nl80211/cfg80211: add new FTM capabilitiesAvraham Stern
Add new capabilities to the PMSR FTM capabilities list. The new capabilities include 6 GHz support, supported number of spatial streams and supported number of LTF repetitions. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Tested-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260111190221.bf43785c18f6.Ic98cf9790ddee84bf88e5720b93c46c23af3c96c@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-27Merge branch 'extend-bit-width-in-the-flow-director-of-hns3-driver'Paolo Abeni
Jijie Shao says: ==================== extend bit width in the flow director of HNS3 driver The bit widths of HCLGE_FD_AD_QID and HCLGE_FD_AD_COUNTER_NUM are increased to support higher specifications. Note: The hardware already supports the specifications. ==================== Link: https://patch.msgid.link/20260123094756.3718516-1-shaojijie@huawei.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-27net: hns3: extend HCLGE_FD_AD_COUNTER_NUM to 8 bitsJijie Shao
Currently, HCLGE_FD_AD_COUNTER_NUM has only 7 bits and supports a maximum of 127 counter_id. However, there are actually scenarios where the counter_id exceeds 127. This patch adds an additional bit to HCLGE_FD_AD_QID to ensure that counter_id greater than 127 are supported. Signed-off-by: Jijie Shao <shaojijie@huawei.com> Link: https://patch.msgid.link/20260123094756.3718516-3-shaojijie@huawei.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-27net: hns3: extend HCLGE_FD_AD_QID to 11 bitsJijie Shao
Currently, HCLGE_FD_AD_QID has only 10 bits and supports a maximum of 1023 queues. However, there are actually scenarios where the queue_id exceeds 1023. This patch adds an additional bit to HCLGE_FD_AD_QID to ensure that queue_id greater than 1023 are supported. Signed-off-by: Jijie Shao <shaojijie@huawei.com> Link: https://patch.msgid.link/20260123094756.3718516-2-shaojijie@huawei.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-27RDMA/mlx5: Fix memory leak in GET_DATA_DIRECT_SYSFS_PATH handlerZilin Guan
The UVERBS_HANDLER(MLX5_IB_METHOD_GET_DATA_DIRECT_SYSFS_PATH) function allocates memory for the device path using kobject_get_path(). If the length of the device path exceeds the output buffer length, the function returns -ENOSPC but does not free the allocated memory, resulting in a memory leak. Add a kfree() call to the error path to ensure the allocated memory is properly freed. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: ec7ad6530909 ("RDMA/mlx5: Introduce GET_DATA_DIRECT_SYSFS_PATH ioctl") Signed-off-by: Zilin Guan <zilin@seu.edu.cn> Link: https://patch.msgid.link/20260126074801.627898-1-zilin@seu.edu.cn Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-01-27Merge tag 'rust-xarray-for-v6.20-v7.0' of ↵Miguel Ojeda
https://github.com/Rust-for-Linux/linux into rust-next Pull XArray update from Andreas Hindborg: - Add '__rust_helper' to XArray abstraction C helpers. * tag 'rust-xarray-for-v6.20-v7.0' of https://github.com/Rust-for-Linux/linux: rust: xarray: add __rust_helper to helpers
2026-01-27drm/bridge: imx8qxp-pxl2dpi: Fix NULL pointer dereference in ↵Liu Ying
imx8qxp_pxl2dpi_bridge_destroy() Pointer bridge->driver_private in imx8qxp_pxl2dpi_bridge_destroy() is NULL when imx8qxp_pxl2dpi_bridge_probe() returns error, because the pointer is initialized only when imx8qxp_pxl2dpi_bridge_probe() returns 0. The NULL pointer would be set to pointer p2d and then NULL pointer p2d would be dereferenced. Fix this by returning early from imx8qxp_pxl2dpi_bridge_destroy() if !p2d is true. Fixes: 900699ba830f ("drm/bridge: imx8qxp-pxl2dpi: get/put the companion bridge") Signed-off-by: Liu Ying <victor.liu@nxp.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260123-imx8qxp-drm-bridge-fixes-v1-2-8bb85ada5866@nxp.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-01-27drm/bridge: imx8qxp-ldb: Fix NULL pointer dereference in ↵Liu Ying
imx8qxp_ldb_bridge_destroy() Pointer bridge->driver_private in imx8qxp_ldb_bridge_destroy() is NULL when a LDB channel is unavailable or imx8qxp_ldb_probe() returns error, because ldb_add_bridge_helper() is the last function called from imx8qxp_ldb_probe() and it doesn't initialize bridge->driver_private if a LDB channel is unavailable. The NULL pointer would be set to pointer ldb_ch and then NULL pointer ldb_ch would be dereferenced. Fix this by returning early from imx8qxp_ldb_bridge_destroy() if !ldb_ch is true. Fixes: 32529d384cea ("drm/bridge: imx8qxp-ldb: convert to of_drm_find_and_get_bridge()") Signed-off-by: Liu Ying <victor.liu@nxp.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260123-imx8qxp-drm-bridge-fixes-v1-1-8bb85ada5866@nxp.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-01-27s390/perf: Disable register readout on sampling eventsThomas Richter
Running commands # ./perf record -IR0,R1 -a sleep 1 extracts and displays register value of general purpose register r1 and r0. However the value displayed of any register is random and does not reflect the register value recorded at the time of the sample interrupt. The sampling device driver on s390 creates a very large buffer for the hardware to store the samples. Only when that large buffer gets full an interrupt is generated and many hundreds of sample entries are processed and copied to the kernel ring buffer and eventually get copied to the perf tool. It is during the copy to the kernel ring buffer that each sample is processed (on s390) and at that time the register values are extracted. This is not the original goal, the register values should be read when the samples are created not when the samples are copied to the kernel ring buffer. Prevent this event from being installed in the first place and return -EOPNOTSUPP. This is already the case for PERF_SAMPLE_REGS_USER. Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Reviewed-by: Jan Polensky <japo@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2026-01-27s390/Kconfig: Define non-zero ILLEGAL_POINTER_VALUEGerd Bayer
Define CONFIG_ILLEGAL_POINTER_VALUE to the eye-catching non-zero value of 0xdead000000000000, consistent with other architectures. Assert at compile-time that the poison pointers that include/linux/poison.h defines based on this illegal pointer are beyond the largest useful virtual addresses. Also, assert at compile-time that the range of poison pointers per include/linux/poison.h (currently a range of less than 0x10000 addresses) does not overlap with the range used for address handles for s390's non-MIO PCI instructions. This enables s390 to track the DMA mappings by the network stack's page_pool that was introduced with [0]. Other functional changes are not intended. Other archictectures have introduced this for various other reasons with commit 5c178472af24 ("riscv: define ILLEGAL_POINTER_VALUE for 64bit") commit f6853eb561fb ("powerpc/64: Define ILLEGAL_POINTER_VALUE for 64-bit") commit bf0c4e047324 ("arm64: kconfig: Move LIST_POISON to a safe value") commit a29815a333c6 ("core, x86: make LIST_POISON less deadly") [0] https://lore.kernel.org/all/20250409-page-pool-track-dma-v9-0-6a9ef2e0cba8@redhat.com/ Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Gerd Bayer <gbayer@linux.ibm.com> Acked-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2026-01-27Merge branch 'warn-exception'Heiko Carstens
Heiko Carstens says: ==================== v2: - Use generic WARN() implementation in case of gcc-8, which avoids the need to raise the minimum gcc version to gcc-9 for (only) s390 - Add couple of additional ifdef guards to avoid compile errors and warnings v1 ([1]): Use the generic infrastructure introduced by Peter Zijlstra [2] to implement an exception based WARN() and WARN_ONCE() similar to x86. Due to some compiler oddities on s390 this requires to raise the minimum gcc version to 9. Maybe there are ways to avoid this, but I failed to find a working solution. Details are in the patch descriptions. Just posting this now to also get some compile bot testing, since I'm afraid there might be some compiler version / config option around where even this new approach breaks. Peter, since you were wondering: your generic infrastructure pieces work very nice. Looking at the x86 and s390 implementation: it might be possible to make things even more generic since both __WARN_printf(), and WARN_ONCE() are identical; it looks like only __WARN_print_arg() needs to be provided. [1] https://lore.kernel.org/all/20251209121701.1856271-1-hca@linux.ibm.com/ [2] https://lore.kernel.org/all/20251110114633.202485143@infradead.org/ ==================== Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2026-01-27s390/bug: Prevent tail-call optimizationHeiko Carstens
For the exception based __WARN_trap() implementation it is technically not necessary to prevent tail-call optimization, however it may be confusing to see warning messages like: WARNING: arch/s390/kernel/setup.c:1017 at foobar+0x2c/0x50, CPU#0: swapper/0/0 together with a disassembly of a different function caused by tail-call optimization for the __WARN_trap() call. Prevent that by adding an empty asm statement. This generates slightly worse code, but should hopefully avoid confusion. With this the output looks like: WARNING: arch/s390/kernel/setup.c:1017 at foobar+0x2c/0x50, CPU#0: swapper/0/0 ... Krnl PSW : 0704c00180000000 000003ffe0119788 (foobar+0x38/0x50) ... Krnl Code: 000003ffe0119776: e3e0f0980024 stg %r14,152(%r15) 000003ffe011977c: c02000b8992a larl %r2,000003ffe182c9d0 *000003ffe0119782: c0e5007270b7 brasl %r14,000003ffe0f678f0 >000003ffe0119788: ebeff0a00004 lmg %r14,%r15,160(%r15) 000003ffe011978e: 07fe bcr 15,%r14 000003ffe0119790: 47000700 bc 0,1792 000003ffe0119794: 0707 bcr 0,%r7 000003ffe0119796: 0707 bcr 0,%r7 Call Trace: [<000003ffe0119788>] foobar+0x38/0x50 [<000003ffe185bc2e>] arch_cpu_finalize_init+0x26/0x60 [<000003ffe185654c>] start_kernel+0x53c/0x5d8 [<000003ffe010002e>] startup_continue+0x2e/0x40 A better solution would be to replace or patch the branch instruction to __WARN_trap() with the monitor call instruction, similar to what is done for x86 [1]. However s390 does not support static_cond_calls(). Therefore use the simple approach for the time being. [1] commit 860238af7a33 ("x86_64/bug: Inline the UD1") Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2026-01-27s390/bug: Skip __WARN_trap() in call tracesHeiko Carstens
In order to avoid rather pointless warning disassemblies of __WARN_trap() set the PSW address to the return address of the function which called __WARN_trap(). This is the address to which __WARN_trap() would return in any case. The result is a disassembly of the function which called __WARN_trap(), which is much more helpful. Before: WARNING: arch/s390/kernel/setup.c:1017 at foobar+0x2c/0x20, CPU#0: swapper/0/0 ... Krnl PSW : 0704c00180000000 000003ffe0f675f4 (__WARN_trap+0x4/0x10) ... Krnl Code: 000003ffe0f675ec: 0707 bcr 0,%r7 000003ffe0f675ee: 0707 bcr 0,%r7 *000003ffe0f675f0: af000001 mc 1,0 >000003ffe0f675f4: 07fe bcr 15,%r14 000003ffe0f675f6: 47000700 bc 0,1792 000003ffe0f675fa: 0707 bcr 0,%r7 000003ffe0f675fc: 0707 bcr 0,%r7 000003ffe0f675fe: 0707 bcr 0,%r7 Call Trace: [<000003ffe0f675f4>] __WARN_trap+0x4/0x10 [<000003ffe185bc2e>] arch_cpu_finalize_init+0x26/0x60 [<000003ffe185654c>] start_kernel+0x53c/0x5d8 [<000003ffe010002e>] startup_continue+0x2e/0x40 Afterwards: WARNING: arch/s390/kernel/setup.c:1017 at foobar+0x12/0x30, CPU#0: swapper/0/0 ... Krnl PSW : 0704c00180000000 000003ffe185bc2e (arch_cpu_finalize_init+0x26/0x60) ... Krnl Code: 000003ffe185bc1c: e3f0ff98ff71 lay %r15,-104(%r15) 000003ffe185bc22: e3e0f0980024 stg %r14,152(%r15) *000003ffe185bc28: c0e5ff45ed94 brasl %r14,000003ffe0119750 >000003ffe185bc2e: c0e5ffa052b9 brasl %r14,000003ffe0c661a0 000003ffe185bc34: c020fffe86d6 larl %r2,000003ffe182c9e0 000003ffe185bc3a: e548f0a80006 mvghi 168(%r15),6 000003ffe185bc40: e548f0a00005 mvghi 160(%r15),5 000003ffe185bc46: a7690004 lghi %r6,4 Call Trace: [<000003ffe185bc2e>] arch_cpu_finalize_init+0x26/0x60 [<000003ffe185654c>] start_kernel+0x53c/0x5d8 [<000003ffe010002e>] startup_continue+0x2e/0x40 Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2026-01-27s390/bug: Implement WARN_ONCE()Heiko Carstens
This is the s390 variant of commit 11bb4944f014 ("x86/bug: Implement WARN_ONCE()"). Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2026-01-27s390/bug: Implement __WARN_printf()Heiko Carstens
This is the s390 variant of commit 5b472b6e5bd9 ("x86_64/bug: Implement __WARN_printf()"). See the x86 commit for the general idea; there are only implementation details which are different. With the new exception based __WARN_printf() implementation the generated code for a simple WARN() is simplified. For example: void foo(int a) { WARN(a, "bar"); } Before this change the generated code looks like this: 0000000000000210 <foo>: 210: c0 04 00 00 00 00 jgnop 210 <foo> 216: ec 26 00 06 00 7c cgijne %r2,0,222 <foo+0x12> 21c: c0 f4 00 00 00 00 jg 21c <foo+0xc> 21e: R_390_PC32DBL __s390_indirect_jump_r14+0x2 222: eb ef f0 88 00 24 stmg %r14,%r15,136(%r15) 228: b9 04 00 ef lgr %r14,%r15 22c: e3 f0 ff e8 ff 71 lay %r15,-24(%r15) 232: e3 e0 f0 98 00 24 stg %r14,152(%r15) 238: c0 20 00 00 00 00 larl %r2,238 <foo+0x28> 23a: R_390_PC32DBL .LC48+0x2 23e: c0 e5 00 00 00 00 brasl %r14,23e <foo+0x2e> 240: R_390_PLT32DBL __warn_printk+0x2 244: af 00 00 00 mc 0,0 248: eb ef f0 a0 00 04 lmg %r14,%r15,160(%r15) 24e: c0 f4 00 00 00 00 jg 24e <foo+0x3e> 250: R_390_PC32DBL __s390_indirect_jump_r14+0x2 With this change the generated code looks like this: 0000000000000210 <foo>: 210: c0 04 00 00 00 00 jgnop 210 <foo> 216: ec 26 00 06 00 7c cgijne %r2,0,222 <foo+0x12> 21c: c0 f4 00 00 00 00 jg 21c <foo+0xc> 21e: R_390_PC32DBL __s390_indirect_jump_r14+0x2 222: c0 20 00 00 00 00 larl %r2,222 <foobar+0x12> 224: R_390_PC32DBL __bug_table+0x2 228: c0 f4 00 00 00 00 jg 228 <foobar+0x18> 22a: R_390_PLT32DBL __WARN_trap+0x2 Downside is that the call trace now starts at __WARN_trap(): ------------[ cut here ]------------ bar WARNING: arch/s390/kernel/setup.c:1017 at 0x0, CPU#0: swapper/0/0 ... Krnl PSW : 0704c00180000000 000003ffe0f6a3b4 (__WARN_trap+0x4/0x10) ... Krnl Code: 000003ffe0f6a3ac: 0707 bcr 0,%r7 000003ffe0f6a3ae: 0707 bcr 0,%r7 *000003ffe0f6a3b0: af000001 mc 1,0 >000003ffe0f6a3b4: 07fe bcr 15,%r14 000003ffe0f6a3b6: 47000700 bc 0,1792 000003ffe0f6a3ba: 0707 bcr 0,%r7 000003ffe0f6a3bc: 0707 bcr 0,%r7 000003ffe0f6a3be: 0707 bcr 0,%r7 Call Trace: [<000003ffe0f6a3b4>] __WARN_trap+0x4/0x10 ([<000003ffe185a54c>] start_kernel+0x53c/0x5d8) [<000003ffe010002e>] startup_continue+0x2e/0x40 Which isn't too helpful. This can be addressed by just skipping __WARN_trap(), which will be addressed in a later patch. Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2026-01-27s390/traps: Copy monitor code to pt_regsHeiko Carstens
In case of a monitor call program check the CPU stores the monitor code to lowcore. Let the program check handler copy it to the pt_regs structure so it can be used by the monitor call exception handler. Instead of increasing the pt_regs size add a union which contains both orig_gpr2 and monitor_code, since orig_gpr2 is not used in case of a program check. Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2026-01-27s390/bug: Introduce and use monitor code macroHeiko Carstens
The first operand address of the monitor call (mc) instruction is the monitor code. Currently the monitor code is ignored, but this will change. Therefore add and use MONCODE_BUG instead of a hardcoded zero. Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
generated by cgit v1.2.3 (git 2.51.0) at 2026-10-30 06:04:05 +0000