summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-05-21staging: octeon: replace pr_warn with dev_warn in fill and rx pathsAyush Mukkanwar
Add struct platform_device parameter to cvm_oct_fill_hw_memory, cvm_oct_mem_fill_fpa, cvm_oct_rx_refill_pool and cvm_oct_rx_initialize to support device-aware logging. Replace pr_warn with dev_warn using &pdev->dev. To avoid passing these parameters through global state, introduce struct octeon_ethernet_platform to hold per-device state including the rx_refill_work and the oct_rx_group array. This ensures all receive group state and workers are correctly associated with the platform device. Define struct oct_rx_group and struct octeon_ethernet_platform in octeon-ethernet.h so they are shared across compilation units. Signed-off-by: Ayush Mukkanwar <ayushmukkanwar@gmail.com> Link: https://patch.msgid.link/20260511150931.93382-4-ayushmukkanwar@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-21staging: octeon: ethernet: replace pr_err and pr_info with dev_err and ↵Ayush Mukkanwar
netdev_err Replace pr_err() and pr_info() calls in cvm_oct_probe() with dev_err(), netdev_err(), and netdev_info() to include device information in log messages. Use dev_err() where no net_device is available (allocation failures), and netdev_err()/netdev_info() where a net_device exists. Signed-off-by: Ayush Mukkanwar <ayushmukkanwar@gmail.com> Link: https://patch.msgid.link/20260511150931.93382-3-ayushmukkanwar@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-21staging: octeon: ethernet-mem: replace pr_warn with dev_warn in free functionsAyush Mukkanwar
Add struct platform_device parameter to cvm_oct_free_hw_skbuff, cvm_oct_free_hw_memory and cvm_oct_mem_empty_fpa. Replace pr_warn calls with dev_warn, using &pdev->dev for device-aware logging. Signed-off-by: Ayush Mukkanwar <ayushmukkanwar@gmail.com> Link: https://patch.msgid.link/20260511150931.93382-2-ayushmukkanwar@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-21Merge patch series "vfs: add O_EMPTYPATH to openat(2)/openat2(2)"Christian Brauner
Jori Koolstra <jkoolstra@xs4all.nl> says: To get an operable version of an O_PATH file descriptor, it is possible to use openat(fd, ".", O_DIRECTORY) for directories, but other files currently require going through open("/proc/<pid>/fd/<nr>"), which depends on a functioning procfs. This patch adds the O_EMPTYPATH flag to openat(2)/openat2(2). If passed, LOOKUP_EMPTY is set at path resolution time. * patches from https://patch.msgid.link/20260424114611.1678641-1-jkoolstra@xs4all.nl: selftest: add tests for O_EMPTYPATH vfs: add O_EMPTYPATH to openat(2)/openat2(2) Link: https://patch.msgid.link/20260424114611.1678641-1-jkoolstra@xs4all.nl Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-05-21openat2: introduce EFTYPE error codeDorjoy Chowdhury
Introduce a new error code EFTYPE for wrong file type operations. EFTYPE is already used in BSD systems like FreeBSD and macOS. This will be used by the upcoming OPENAT2_REGULAR flag support to return a specific error when a path doesn't refer to a regular file. Signed-off-by: Dorjoy Chowdhury <dorjoychy111@gmail.com> Link: https://patch.msgid.link/20260328172314.45807-2-dorjoychy111@gmail.com Reviewed-by: Jeff Layton <jlayton@kernel.org> Reviewed-by: Aleksa Sarai <aleksa@amutable.com> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-05-21selftest: add tests for O_EMPTYPATHJori Koolstra
Add tests for the new O_EMPTYPATH flag of openat(2)/openat2(2). Also, the current openat2 tests include a helper header file that defines the necessary structs and constants to use openat2(2), such as struct open_how. This may result in conflicting definitions when the system header openat2.h is present as well. So add openat2.h generated by 'make headers' to the uapi header files in ./tools/include and remove the helper file definitions of the current openat2 selftests. Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl> Link: https://patch.msgid.link/20260424114611.1678641-3-jkoolstra@xs4all.nl Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-05-21Merge patch series "selftests: openat2: migrate to kselftest harness"Christian Brauner
Aleksa Sarai <aleksa@amutable.com> says: These tests were written in the early days of selftests' TAP support, the more modern kselftest harness is much easier to follow and maintain. The actual contents of the tests are unchanged by this change. * patches from https://patch.msgid.link/20260401-openat2-selftests-kunit-v2-0-ad153a07da0c@amutable.com: selftests: openat2: migrate to kselftest harness selftests: openat2: switch from custom ARRAY_LEN to ARRAY_SIZE selftests: openat2: move helpers to header selftests: move openat2 tests to selftests/filesystems/ Link: https://patch.msgid.link/20260401-openat2-selftests-kunit-v2-0-ad153a07da0c@amutable.com Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-05-21vfs: add O_EMPTYPATH to openat(2)/openat2(2)Jori Koolstra
To get an operable version of an O_PATH file descriptor, it is possible to use openat(fd, ".", O_DIRECTORY) for directories, but other files currently require going through open("/proc/<pid>/fd/<nr>"), which depends on a functioning procfs. This patch adds the O_EMPTYPATH flag to openat(2)/openat2(2). If passed, LOOKUP_EMPTY is set at path resolution time. Note: This implies that you cannot rely anymore on disabling procfs from being mounted (e.g. inside a container without procfs mounted and with CAP_SYS_ADMIN dropped) to prevent O_PATH fds from being re-opened read-write. Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl> Link: https://patch.msgid.link/20260424114611.1678641-2-jkoolstra@xs4all.nl Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-05-21selftests: openat2: migrate to kselftest harnessAleksa Sarai
These tests were written in the early days of selftests' TAP support, the more modern kselftest harness is much easier to follow and maintain. The actual contents of the tests are unchanged by this change. Most of the diff involves switching from the E_* syscall wrappers we previously used to ASSERT_EQ(fn(...), 0) in tests and helper functions. The first pass of the migration was done using Claude, followed by a manual rework and review. Assisted-by: Claude:claude-4.6-opus Signed-off-by: Aleksa Sarai <aleksa@amutable.com> Link: https://patch.msgid.link/20260401-openat2-selftests-kunit-v2-4-ad153a07da0c@amutable.com Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-05-21selftests: openat2: switch from custom ARRAY_LEN to ARRAY_SIZEAleksa Sarai
For whatever reason, the original version of the tests used a custom version of ARRAY_SIZE, but ARRAY_SIZE works just as well. Signed-off-by: Aleksa Sarai <aleksa@amutable.com> Link: https://patch.msgid.link/20260401-openat2-selftests-kunit-v2-3-ad153a07da0c@amutable.com Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-05-21selftests: openat2: move helpers to headerAleksa Sarai
This is a bit ugly, but in the next patch we will move to using kselftest_harness.h -- which doesn't play well with being included in multiple compilation units due to duplicate function definitions. Not including kselftest_harness.h would let us avoid this patch, but the helpers will need include kselftest_harness.h in order to switch to TH_LOG. Signed-off-by: Aleksa Sarai <aleksa@amutable.com> Link: https://patch.msgid.link/20260401-openat2-selftests-kunit-v2-2-ad153a07da0c@amutable.com Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-05-21selftests: move openat2 tests to selftests/filesystems/Aleksa Sarai
These tests really should've always belonged there, doubly so now that they include a lot of other generic filesystem-related tests. Suggested-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Aleksa Sarai <aleksa@amutable.com> Link: https://patch.msgid.link/20260401-openat2-selftests-kunit-v2-1-ad153a07da0c@amutable.com Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-05-21gpio: dwapb: Add ACPI ID LECA0001 for LECARC SoCsThomas Lin
Add ACPI ID "LECA0001" for LECARC SoCs that use the DesignWare GPIO controller with V1 register offsets. Signed-off-by: Thomas Lin <thomas_lin@lecomputing.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260521-lecarc-acpi-ids-v1-1-ae0ae90b2817@lecomputing.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-05-21regmap-i2c: fix sparse warning in regmap_smbus_word_write_reg16Nishanth Sampath Kumar
i2c_smbus_write_word_data() expects a plain u16, but cpu_to_le16() returns __le16 (a sparse-restricted endian type), causing: drivers/base/regmap/regmap-i2c.c:340: sparse: incorrect type in argument 3 (different base types) expected unsigned short [usertype] value got restricted __le16 [usertype] SMBus already defines byte ordering internally, so cpu_to_le16() is wrong here. Replace it with a plain (u16) cast. Fixes: bad4bd28abf4 ("regmap-i2c: add SMBus byte/word reg16 bus for adapters lacking I2C_FUNC_I2C") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202605161621.mY5zFh4D-lkp@intel.com/ Signed-off-by: Nishanth Sampath Kumar <nissampa@cisco.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2026-05-21gpio: tegra186: Enable GTE for Tegra264Suneel Garapati
Set has_gte flag to enable GTE for Tegra264 AON pins. Signed-off-by: Suneel Garapati <suneelg@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260521012031.2003914-1-suneelg@nvidia.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-05-21comedi: Consistently define pci_device_ids using named initializersUwe Kleine-König (The Capable Hub)
The .driver_data member of the various struct pci_device_id arrays were initialized by list expressions. This isn't easily readable if you're not into PCI. Using named initializers is more explicit and thus easier to parse. Also skip explicit assignments of 0 (which the compiler takes care of). The secret plan is to make struct pci_device_id::driver_data an anonymous union (similar to https://lore.kernel.org/all/cover.1776579304.git.u.kleine-koenig@baylibre.com/) and that requires named initializers. But it's also a nice cleanup on its own. This change doesn't introduce changes to the compiled pci_device_id arrays. Tested on x86 and arm64. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Link: https://patch.msgid.link/20260430165214.449166-2-u.kleine-koenig@baylibre.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-21comedi: comedi_test: fix check for valid scan_begin_src in waveform_ai_cmdtest()Ian Abbott
Commit 783ddaebd397 ("staging: comedi: comedi_test: support scan_begin_src == TRIG_FOLLOW") neglected to add a test that `scan_begin_src` has only one bit set. The allowed values are `TRIG_FOLLOW` and `TRIG_TIMER`, but the code incorrectly also allows `TRIG_FOLLOW | TRIG_TIMER`. Add a call to `comedi_check_trigger_is_unique()` to check that only one trigger source bit is set. Fixes: 783ddaebd397 ("staging: comedi: comedi_test: support scan_begin_src == TRIG_FOLLOW") Cc: stable <stable@kernel.org> Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Link: https://patch.msgid.link/20260422162138.36003-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-21comedi: comedi_test: Fix limiting of convert_arg in waveform_ai_cmdtest()Ian Abbott
The function checks and possibly modifies the description of an asynchronous command to be run on the analog input subdevice of a comedi device attached to the "comedi_test" driver, returning 0 if no modifications were required, or a positive value that indicates which step of the checking process it failed on. Step 4 fixes up various argument values for various trigger sources. There are two bugs in the fixing up of the `convert_arg` value to keep the `scan_begin_arg` value within the range of `unsigned int` when `scan_begin_src` and `convert_src` both have the value `TRIG_TIMER`, which indicates that the corresponding `_arg` values hold a time period in nanoseconds. The code also uses `scan_end_arg` which hold the number of "conversions" within each "scan". The goal is to end up with the scan period being less than or equal to the convert period multiplied by the number of conversions per scan. It intends to do that by clamping the `convert_arg` value to a maximum value of `UINT_MAX / scan_end_arg` rounded down to a multiple of 1000 (`NSEC_PER_USEC`). (The rounding from nanoseconds to microseconds is because the driver is modelling a device that uses a 1 MHz clock for timing. This is partly because that is a more typical timing base for real hardware devices driven by comedi, and partly because the driver used to use `struct timeval` internally.) The first bug is that the code checks if `scan_begin_arg == TRIG_TIMER` when it should be checking if `scan_begin_src == TRIG_TIMER`. The bugged check will always fail because if `scan_begin_src == TRIG_TIMER`, then `scan_begin_arg` will be at least 1000 (`NSEC_PER_USEC`), otherwise `scan_begin_src == TRIG_FOLLOW` and `scan_begin_arg` will be 0. (N.B `TRIG_TIMER` is defined as `0x10`.) The second bug is that is rounding the maximum value down to a multiple of 1000000000 (`NSEC_PER_SEC`) instead of 1000 (`NSEC_PER_USEC`), however this bug is not reached due to the first bug. This patch fixes both bugs. Fixes: 783ddaebd397 ("staging: comedi: comedi_test: support scan_begin_src == TRIG_FOLLOW") Fixes: 5afdcad2f818 ("staging: comedi: comedi_test: limit maximum convert_arg") Cc: stable <stable@kernel.org> Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Link: https://patch.msgid.link/20260422144637.27692-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-21gpio: pca953x: propagate regulator_enable() error from resumeStepan Ionichev
pca953x_resume() returns 0 when regulator_enable() fails, dropping the real error code and masking the failure as a successful resume. The caller then proceeds as if the chip is powered, while the regulator is in fact disabled. Return ret so PM core sees the actual failure. Signed-off-by: Stepan Ionichev <sozdayvek@gmail.com> Link: https://patch.msgid.link/20260520110504.13969-1-sozdayvek@gmail.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-05-21USB: serial: option: add missing RSVD(5) flag for Rolling RW135R-GLWanquan Zhong
The RW135R-GL entry added in commit 01e8d0f74222 ("USB: serial: option: add support for Rolling Wireless RW135R-GL") was missing the .driver_info = RSVD(5) flag used by other Rolling Wireless MBIM laptop modules (e.g. RW135-GL and RW350-GL). Without this flag, the option driver incorrectly binds to the reserved ADB interface (If#5) in multi-interface USB modes, causing AT/MBIM communication failures after mode switching. This matches the handling of other Rolling Wireless MBIM devices. - VID:PID 33f8:1003, RW135R-GL for laptop debug M.2 cards (with MBIM interface for Linux/Chrome OS) 0x1003: mbim, diag, AT, pipe Here are the outputs of usb-devices: T: Bus=03 Lev=01 Prnt=01 Port=04 Cnt=02 Dev#= 8 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=33f8 ProdID=1003 Rev= 5.15 S: Manufacturer=Rolling Wireless S.a.r.l. S: Product=Rolling RW135R-GL Module S: SerialNumber=12345678 C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00 I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim E: Ad=82(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms - VID:PID 33f8:1003, RW135R-GL for laptop debug M.2 cards (with MBIM interface for Linux/Chrome OS) 0x1003: mbim, diag, AT, ADB, pipe Here are the outputs of usb-devices: T: Bus=03 Lev=01 Prnt=01 Port=04 Cnt=02 Dev#= 7 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=33f8 ProdID=1003 Rev= 5.15 S: Manufacturer=Rolling Wireless S.a.r.l. S: Product=Rolling RW135R-GL Module S: SerialNumber=12345678 C:* #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00 I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim E: Ad=82(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms - VID:PID 33f8:1003, RW135R-GL for laptop debug M.2 cards (with MBIM interface for Linux/Chrome OS) 0x1003: mbim, pipe Here are the outputs of usb-devices: T: Bus=03 Lev=01 Prnt=01 Port=04 Cnt=02 Dev#= 9 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=33f8 ProdID=1003 Rev= 5.15 S: Manufacturer=Rolling Wireless S.a.r.l. S: Product=Rolling RW135R-GL Module S: SerialNumber=12345678 C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=500mA A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00 I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim E: Ad=82(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Fixes: 01e8d0f74222 ("USB: serial: option: add support for Rolling Wireless RW135R-GL") Signed-off-by: Wanquan Zhong <wanquan.zhong@fibocom.com> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org>
2026-05-21USB: serial: option: add MeiG SRM813QJan Volckaert
Add support for the Qualcomm Technology Snapdragon X35-based MeiG SRM813Q module. The module can be put in different modes via AT commands to enable/disable GPS functionality: MODEM - PPP mode(2dee:4d63): AT+SER=1,1 If#= 0: RMNET If#= 1: DIAG/ADB If#= 2: MODEM If#= 3: AT P: Vendor=2dee ProdID=4d63 Rev=05.15 S: Manufacturer=MEIG S: Product=LTE-A Module S: SerialNumber=1bd51f0e C: #Ifs= 4 Cfg#= 1 Atr=80 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms NMEA mode(2dee:4d64): AT+SER=51,1 If#= 0: RMNET If#= 1: DIAG/ADB If#= 2: NMEA If#= 3: AT P: Vendor=2dee ProdID=4d64 Rev=05.15 S: Manufacturer=MEIG S: Product=LTE-A Module S: SerialNumber=1bd51f0e C: #Ifs= 4 Cfg#= 1 Atr=80 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms Signed-off-by: Jan Volckaert <janvolck@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org>
2026-05-21dcache: use kmalloc_flex() in __d_allocThorsten Blum
Use kmalloc_flex() when allocating a new 'struct external_name' in __d_alloc() to replace offsetof() and the open-coded size arithmetic, and to keep the size type-safe. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Link: https://patch.msgid.link/20260417094238.551114-3-thorsten.blum@linux.dev Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Jori Koolstra <jkoolstra@xs4all.nl> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-05-21vfs: remove always taken if-branch in find_next_fd()Jori Koolstra
find_next_fd() finds the next free fd slot in the passed fdtable's bitmap. It does so in two steps: first it checks whether the bitmap has a free entry in the word containing start. If not, it looks at second level bitmap that registers which words in the first level bitmap are full and then looks at the first level bitmap at the first non-full word. In the current code the second level lookup is done by: bitbit = find_next_zero_bit(fdt->full_fds_bits, maxbit, bitbit) * BITS_PER_LONG; where bitbit = start / BITS_PER_LONG. However, in the fast path (first step) we already checked the word at bitbit, so we can skip that word bit and start at bitbit+1. This also means that we can get rid of the branch if (bitbit > start) start = bitbit; since if we set bitbit = find_next_zero_bit(fdt->full_fds_bits, maxbit, bitbit+1) * BITS_PER_LONG; the reassigned bitbit can never be less than ((start/BITS_PER_LONG)+1) * BITS_PER_LONG > start So the branch is always taken. Obviously the reuse of the variable name bitbit (and the name itself) is quite confusing, so change that as well. Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl> Link: https://patch.msgid.link/20260420101801.806785-1-jkoolstra@xs4all.nl Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-05-21iov_iter: use kmemdup_array for dup_iter to harden against overflowWang Haoran
While auditing the Linux 7.0-rc2 kernel, I identified a potential security vulnerability in the iov_iter framework's memory allocation logic. The dup_iter() function, which is exported via EXPORT_SYMBOL, currently uses kmemdup() with a raw multiplication to allocate the duplicate iovec array: new->iov = kmemdup(from->iov, nr_segs * sizeof(struct iovec), gfp); The hazard here is that dup_iter() relies on a primitive multiplication without any integrated overflow check. Since nr_segs is often derived from user-space input, this line is vulnerable to integer overflow (on 32-bit systems or via type narrowing), potentially leading to a small allocation followed by a large out-of-bounds memory copy. Furthermore, it allows for unbounded memory allocations, as the function lacks intrinsic knowledge of safe limits. On the 7.0-rc2 branch, several high-impact callchains still rely on this exported function: drivers/usb/gadget/function/f_fs.c: The ffs_epfile_read_iter() path demonstrates why relying on dup_iter() is dangerous: it performs allocation based on user input before verifying driver state. This confirms that dup_iter() must be hardened internally as it cannot assume pre-validated input. drivers/usb/gadget/legacy/inode.c: The ep_read_iter() path illustrates how dup_iter()’s lack of boundary awareness compounds resource risks. When combined with other allocations, it creates a multiplier effect for kernel memory pressure. This patch replaces kmemdup() with kmemdup_array(), which utilizes check_mul_overflow() to ensure the allocation size is calculated safely, hardening dup_iter() against malicious or malformed inputs from its callers Signed-off-by: Wang Haoran <haoranwangsec@gmail.com> Link: https://patch.msgid.link/20260413060655.1139141-1-haoranwangsec@gmail.com Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-05-21Merge patch series "initramfs: test and improve cpio hex header validation"Christian Brauner
David Disseldorp <ddiss@suse.de> says: The series that introduced simple_strntoul() had passed into kernel without proper review and hence reinvented a wheel that's not needed. Here is the refactoring to show that. It can go via PRINTK or VFS tree. I have tested this on x86, but I believe the same result will be on big-endian CPUs (I deduced that from how strtox() works). I also run KUnit tests. * patches from https://patch.msgid.link/20260331070519.5974-1-ddiss@suse.de: kstrtox: Drop extern keyword in the simple_strtox() declarations vsprintf: Revert "add simple_strntoul" initramfs: Refactor to use hex2bin() instead of custom approach initramfs: Sort headers alphabetically initramfs_test: test header fields with 0x hex prefix initramfs_test: add fill_cpio() inject_ox parameter Link: https://patch.msgid.link/20260331070519.5974-1-ddiss@suse.de Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-05-21kstrtox: Drop extern keyword in the simple_strtox() declarationsAndy Shevchenko
There is legacy 'extern' keyword for the exported simple_strtox() function which are the artefact that can be removed. So drop it. While at it, tweak the declaration to provide parameter names. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260331070519.5974-7-ddiss@suse.de Reviewed-by: David Disseldorp <ddiss@suse.de> Reviewed-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-05-21vsprintf: Revert "add simple_strntoul"Andy Shevchenko
No users anymore and none should be in the first place. This reverts commit fcc155008a20fa31b01569e105250490750f0687. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260331070519.5974-6-ddiss@suse.de Acked-by: Petr Mladek <pmladek@suse.com> Reviewed-by: David Disseldorp <ddiss@suse.de> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-05-21initramfs: Refactor to use hex2bin() instead of custom approachAndy Shevchenko
There is a simple_strntoul() function used solely as a shortcut for hex2bin() with proper endianess conversions. Replace that and drop the unneeded function in the next changes. This implementation will abort if we fail to parse the cpio header, instead of using potentially bogus header values. Co-developed-by: David Disseldorp <ddiss@suse.de> Signed-off-by: David Disseldorp <ddiss@suse.de> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260331070519.5974-5-ddiss@suse.de Reviewed-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-05-21initramfs: Sort headers alphabeticallyAndy Shevchenko
Sorting headers alphabetically helps locating duplicates, and makes it easier to figure out where to insert new headers. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260331070519.5974-4-ddiss@suse.de Reviewed-by: David Disseldorp <ddiss@suse.de> Reviewed-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-05-21initramfs_test: test header fields with 0x hex prefixDavid Disseldorp
cpio header fields are 8-byte hex strings, but one "interesting" side-effect of our historic simple_str[n]toul() use means that a "0x" (or "0X") prefixed header field will be successfully processed when coupled alongside a 6-byte hex remainder string. "0x" prefix support is contrary to the initramfs specification at Documentation/driver-api/early-userspace/buffer-format.rst which states: The structure of the cpio_header is as follows (all fields contain hexadecimal ASCII numbers fully padded with '0' on the left to the full width of the field, for example, the integer 4780 is represented by the ASCII string "000012ac"): Test for this corner case by injecting "0x" prefixes into the uid, gid and namesize cpio header fields. Confirm that init_stat() returns matching uid and gid values. This test can be modified in future to expect unpack_to_rootfs() failure when header validation is changed to properly follow the specification. Add some missing struct kstat initializations to account for possible init_stat() failures. Signed-off-by: David Disseldorp <ddiss@suse.de> Link: https://patch.msgid.link/20260331070519.5974-3-ddiss@suse.de Reviewed-by: Petr Mladek <pmladek@suse.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-05-21initramfs_test: add fill_cpio() inject_ox parameterDavid Disseldorp
fill_cpio() uses sprintf() to write out the in-memory cpio archive from an array of struct initramfs_test_cpio. This change allows callers to modify the cpio sprintf() format string so that future tests can intentionally corrupt the header with "0x" and "0X" prefixed fields. Signed-off-by: David Disseldorp <ddiss@suse.de> Link: https://patch.msgid.link/20260331070519.5974-2-ddiss@suse.de Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-05-20sched_ext: Add cmask mask opsTejun Heo
Sub-sched cap code and other upcoming consumers need bulk cmask ops, both mutating (and/or/copy/andnot) and predicate (subset/intersects/empty). cmask_walk_op2() walks the intersection of two ranges word by word; cmask_walk_op1() walks one range. Both are __always_inline and dispatched on a compile-time-constant op enum, so each public entry collapses to a specialized loop with the inner switch reduced to one arm. Two-cmask ops only touch bits in the intersection of the two ranges; bits outside are left unchanged. scx_cmask_or_racy() and scx_cmask_copy_racy() mirror the locking forms but read @src word-by-word through data_race(); callers handle ordering with concurrent writers themselves. v2: Add scx_cmask_empty(). Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Andrea Righi <arighi@nvidia.com>
2026-05-20sched_ext: Track bits[] storage size in struct scx_cmaskTejun Heo
scx_cmask carries @base and @nr_cids but not the bits[] allocation size, so helpers reshaping the active range have no way to check it fits and later kfuncs taking caller-provided storage can't validate it. Add @alloc_words (u64 word count) annotated with __counted_by, and split the bit-range API into three helpers: - SCX_CMASK_DEFINE() / __SCX_CMASK_DEFINE() define an on-stack cmask, the latter taking an explicit capacity for oversized storage. SCX_CMASK_DEFINE_SHARD() is a thin wrapper that always reserves SCX_CID_SHARD_MAX_CPUS bits of storage. - scx_cmask_init() / __scx_cmask_init() initialize a cmask, with the same tight-vs-explicit split. - scx_cmask_reframe() reshapes the active range without resizing storage. The BPF mirror (cmask_init / __cmask_init / cmask_reframe) gets the same shape. Add scx_cmask_clear() and scx_cmask_fill() to zero and set the active-range bits respectively. scx_cpumask_to_cmask() uses scx_cmask_clear(); scx_cmask_init() would otherwise re-write @alloc_words on every call. A later patch uses @alloc_words in scx_cmask_ref_shard() to refuse output storage that can't hold the requested shard. v2: Init per-CPU scx_set_cmask_scratch (was zero-init, emitted empty cmasks). Add nr_cids/alloc_cids check in BPF __cmask_init(). (sashiko AI) Widen SCX_CMASK_NR_WORDS()/CMASK_NR_WORDS() to compute in u64 so that @nr_cids near U32_MAX no longer wraps to a small value and bypasses the bounds check in cmask_reframe(). (Andrea) Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Andrea Righi <arighi@nvidia.com>
2026-05-20sched_ext: Rename scx_cmask.nr_bits to nr_cidsTejun Heo
struct scx_cmask is a base-windowed bitmap over cid space. Each bit represents one cid, so the count of active bits is the count of cids. The sibling struct scx_cid_shard already uses nr_cids. Rename as a prep so the following patches that grow the cmask API can use the consistent name. v2: Also rename src->nr_bits / dst->nr_bits in cmask_copy_from_kernel(). (sashiko AI) Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Andrea Righi <arighi@nvidia.com>
2026-05-21media: renesas: vsp1: Drop deprecated vsp1_du_setup_lif() functionLaurent Pinchart
The vsp1_du_setup_lif() is deprecated and its last users are gone. Drop it. Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://patch.msgid.link/20260511235637.3468558-12-laurent.pinchart+renesas@ideasonboard.com Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-05-21media: renesas: vsp1: Simplify iteration over format arraysLaurent Pinchart
Introduce a vsp1_for_each_format() macro to iterate over format arrays, to improve readability. No functional change intended. Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://patch.msgid.link/20260511235637.3468558-10-laurent.pinchart+renesas@ideasonboard.com Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-05-21media: renesas: vsp1: Use spinlock scoped guardsLaurent Pinchart
Replace remaining manual spinlock locking and unlocking with scoped guards. This simplifies error paths and reduces the amount of code. Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://patch.msgid.link/20260511235637.3468558-9-laurent.pinchart+renesas@ideasonboard.com Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-05-21media: renesas: vsp1: Use spinlock guardsLaurent Pinchart
Replace manual spinlock locking and unlocking with guards. This simplifies error paths and reduces the amount of code. Limit the changes to locations where the guard covers until the end of the function to ease review. Scoped guards will be introduced separately. Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://patch.msgid.link/20260511235637.3468558-8-laurent.pinchart+renesas@ideasonboard.com Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-05-21media: renesas: vsp1: Use mutex scoped guardsLaurent Pinchart
Replace remaining manual mutex locking and unlocking with scoped guards. This simplifies error paths and reduces the amount of code. Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://patch.msgid.link/20260511235637.3468558-7-laurent.pinchart+renesas@ideasonboard.com Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-05-21media: renesas: vsp1: Use mutex guardsLaurent Pinchart
Replace manual mutex locking and unlocking with guards. This simplifies error paths and reduces the amount of code. Limit the changes to locations where the guard covers until the end of the function to ease review. Scoped guards will be introduced separately. Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://patch.msgid.link/20260511235637.3468558-6-laurent.pinchart+renesas@ideasonboard.com Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-05-21drm: renesas: rz-du: Switch to new VSP APILaurent Pinchart
The vsp1_du_setup_lif() function is deprecated. Use the new vsp1_du_enable() and vsp1_du_disable() functions instead. Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Acked-by: Biju Das <biju.das.jz@bp.renesas.com> Acked-by: Dave Airlie <airlied@redhat.com> Link: https://patch.msgid.link/20260511235637.3468558-5-laurent.pinchart+renesas@ideasonboard.com Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-05-21drm: renesas: rcar-du: Switch to new VSP APILaurent Pinchart
The vsp1_du_setup_lif() function is deprecated. Use the new vsp1_du_enable() and vsp1_du_disable() functions instead. Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Acked-by: Dave Airlie <airlied@redhat.com> Link: https://patch.msgid.link/20260511235637.3468558-4-laurent.pinchart+renesas@ideasonboard.com Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-05-21media: renesas: vsp1: Split vsp1_du_setup_lif()Laurent Pinchart
The vsp1_du_setup_lif() function is used to configure and enable a pipeline, as well as disable it, depending on the cfg argument being a valid pointer or NULL. This creates a confusing API. Improve it by splitting the function in two, a vsp1_du_enable() function to configure a pipeline, and a vsp1_du_disable() function to disaple it. Keep vsp1_du_setup_lif() as an inline wrapper for existing callers in the DRM subsystem, to simplify merging. The callers will be updated separately and the old API will then be removed. Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://patch.msgid.link/20260511235637.3468558-3-laurent.pinchart+renesas@ideasonboard.com Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-05-21media: renesas: vsp1: Avoid forward function declarationLaurent Pinchart
Reorder functions to avoid the forward declaration of the vsp1_du_pipeline_configure(). No functional change intended. Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://patch.msgid.link/20260511235637.3468558-2-laurent.pinchart+renesas@ideasonboard.com Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-05-21KVM: arm64: vgic-v2: Don't init the vgic on in-kernel interrupt injectionMarc Zyngier
We now have the lazy init on three paths: - on first run of a vcpu - on first injection of an interrupt from userspace and irqfd - on first injection of an interrupt from kernel space as part of the device emulation (timers, PMU, vgic MI) Given that we recompute the state of each in-kernel interrupt every time we are about to enter the guest, we can drop the lazy init from the kernel injection path. This solves a bunch of issues related to vgic_lazy_init() being called in non-preemptible context, such as vcpu reset. Reviewed-by: Oliver Upton <oupton@kernel.org> Link: https://patch.msgid.link/20260520100200.543845-7-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-05-21KVM: arm64: vgic-v2: Force vgic init on injection outside the run loopMarc Zyngier
Make sure that any attempt to inject an interrupt from userspace or an irqfd results in the GICv2 lazy init to take place. This is not currently necessary as the init is also performed on *any* interrupt injection. But as we're about to remove that, let's introduce it here. Reviewed-by: Oliver Upton <oupton@kernel.org> Link: https://patch.msgid.link/20260520100200.543845-6-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-05-21KVM: arm64: pmu: Kill the PMU interrupt level cacheMarc Zyngier
Just like the timer, the PMU has an interrupt cache that serves little purpose. Drop it. Reviewed-by: Oliver Upton <oupton@kernel.org> Link: https://patch.msgid.link/20260520100200.543845-5-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-05-21KVM: arm64: timer: Kill the per-timer irq level cacheMarc Zyngier
The timer code makes use of a per-timer irq level cache, which looks like a very minor optimisation to avoid taking a lock upon updating the GIC view of the interrupt when it is unchanged from the previous state. This is coming in the way of more important correctness issues, so get rid of the cache, which simplifies a couple of minor things. Reviewed-by: Oliver Upton <oupton@kernel.org> Link: https://patch.msgid.link/20260520100200.543845-4-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-05-21KVM: arm64: Simplify userspace notification of interrupt stateMarc Zyngier
The userspace notification of interrupts is has a few problems: - it is utterly pointless - it is annoyingly split between detecting the need for notification and the population of the interrupts in the run structure We can't do anything about the former (yet), but the latter can be addressed. If we detect that we must notify userspace, we know that we are going to exit, as we populate the exit status. Which means we can also populate the interrupt state at this stage and be done with it. This simplifies the structure of the code. Reviewed-by: Oliver Upton <oupton@kernel.org> Link: https://patch.msgid.link/20260520100200.543845-3-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-05-21KVM: arm64: timer: Repaint kvm_timer_{should,irq_can}_fire() to ↵Marc Zyngier
kvm_timer_{pending,enabled}() kvm_timer_should_fire() seems to date back to a time where the author of the timer code didn't seem to have made the word "pending" part of their vocabulary. Having since slightly improved on that front, let's rename this predicate to kvm_timer_pending(), which clearly indicates whether the timer interrupt is pending or not. Similarly, kvm_timer_irq_can_fire() is renamed to kvm_timer_enabled(). Reviewed-by: Joey Gouly <joey.gouly@arm.com> Reviewed-by: Oliver Upton <oupton@kernel.org> Link: https://patch.msgid.link/20260520100200.543845-2-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>