summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-01-15arm64: dts: mediatek: mt7988a: Fix PCI-Express T-PHY node addressAngeloGioacchino Del Regno
The PCIe and USB TPHYs are under the soc bus, which provides MMIO, and all nodes under that must use the bus, otherwise those would clearly be out of place. Add ranges to both the tphy(s) and assign the address to the main node to silence a dtbs_check warning, and fix the children to use the MMIO range of t-phy. Fixes: ("f693e6ba55ae arm64: dts: mediatek: mt7988: Add t-phy for ssusb1") Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2026-01-15arm64: dts: meson-s4-s905y4-khadas-vim1s: add initial device treeNick Xie
The Khadas VIM1S uses the Amlogic S905Y4 SoC, based on the Amlogic S4 SoC family, on a board with the same form factor as the VIM/VIM2/VIM3/VIM4 models. Serial debug console, ethernet, SD card work with this initial device tree. It features: - 2GB LPDDR4 RAM - 16GB eMMC 5.1 storage - 32MB SPI flash - 100M Ethernet - AP6256 Wireless (802.11 a/b/g/n/ac, BT5.0) - HDMI 2.1 video - 2x USB 2.0 ports - 1x USB-C (power) with USB 2.0 OTG - 2x LED's (1x red, 1x white) - 3x buttons (power, function, reset) - IR receiver - 40pin GPIO Header - 1x micro SD card slot Signed-off-by: Nick Xie <nick@khadas.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260115030015.1334517-4-nick@khadas.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
2026-01-15arm64: dts: meson-s4-aq222: update compatible string with s805x2Nick Xie
Update the compatible string for the Amlogic AQ222 board to include the specific SoC compatible "amlogic,s805x2". This aligns the device tree with the updated bindings which now differentiate between S4 family members (S805X2 vs S905Y4). Signed-off-by: Nick Xie <nick@khadas.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260115030015.1334517-3-nick@khadas.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
2026-01-15dt-bindings: arm: amlogic: introduce specific compatibles for S4 familyNick Xie
The Amlogic S4 SoC family includes multiple variants, such as the S805X2 and S905Y4. Currently, the bindings only define the generic "amlogic,s4" compatible. This patch introduces specific compatibles "amlogic,s805x2" and "amlogic,s905y4" to properly differentiate these SoCs while keeping "amlogic,s4" as the family fallback. This allows for more precise hardware description and future-proofing if SoC-specific quirks arise. Signed-off-by: Nick Xie <nick@khadas.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260115030015.1334517-2-nick@khadas.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
2026-01-15ASoC: SDCA: Tidy up some memory allocationsCharles Keepax
It is slightly better to deference the type being allocate for a sizeof rather than manually using the type. Saves effort if types change in the future. This results in no functional changes, just tidies up the style of the code a little. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260115114607.271990-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-15pmdomain:rockchip: Fix init genpd as GENPD_STATE_ON before regulator readyFrank Zhang
RK3588_PD_NPU initialize as GENPD_STATE_ON before regulator ready. rknn_iommu initlized success and suspend RK3588_PD_NPU. When rocket driver register, it will resume rknn_iommu. If regulator is still not ready at this point, rknn_iommu resume fail, pm runtime status will be error: -EPROBE_DEFER. This patch set pmdomain to off if it need regulator during probe, consumer device can power on pmdomain after regulator ready. Signed-off-by: Frank Zhang <rmxpzlb@gmail.com> Tested-by: Chaoyi Chen <chaoyi.chen@rock-chips.com> Tested-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Fixes: db6df2e3fc16 ("pmdomain: rockchip: add regulator support") Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2026-01-15firewire: ohci: fix index of pages for dma address to 1394 OHCI IT contextTakashi Sakamoto
The index of pages for dma address was changed wrongly. This commit corrents it. Fixes: ef6bdffbb88d ("firewire: core: stop using page private to store DMA mapping address") Link: https://lore.kernel.org/r/20260114131729.16133-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2026-01-15platform/x86: hp-wmi: fix platform profile values for Omen 16-wf1xxxKrishna Chomal
HP Omen 16-wf1xxx (board ID 8C78) currently sends the incorrect Victus-specific thermal profile values via WMI, leading to a logical inconsistency when switching between platform profiles. The driver currently uses Victus S values: 0x00 => Balanced / Low-Power 0x01 => Performance However, Omen Gaming Hub logs / EC register inspection on Windows shows that this board is intended to use: 0x30 => Balanced / Low-Power 0x31 => Performance This patch corrects the thermal profile command values to match the values observed from Omen Gaming Hub logs. The performance benchmarks and peak power draw (from both CPU and GPU) show no observable change with this correction (suggesting that the firmware is currently tolerant of the incorrect values). However sending the correct values prevents potential regressions after future firmware updates. Refactor victus_s_thermal_profile_boards from a list of strings to a dmi_system_id table and move the lookup to module init. The new struct thermal_profile_params is used to store board-specific WMI parameters, allowing the driver to cache these values in a static pointer. This avoids repeated DMI string comparisons and allows marking of DMI table as __initconst. Testing on HP Omen 16-wf1xxx (board 8C78) confirmed WMI codes 0x30/0x31 are now sent, resolving the logical inconsistency and ensuring the value visible in EC registers match the Windows state for this profile. Fixes: fb146a38cb11 ("platform/x86: hp-wmi: Add Omen 16-wf1xxx fan support") Signed-off-by: Krishna Chomal <krishna.chomal108@gmail.com> Link: https://patch.msgid.link/20260113182604.115211-2-krishna.chomal108@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-01-15platform/x86: hp-wmi: implement fan keep-aliveKrishna Chomal
The firmware on some HP laptops automatically reverts the fan speed control to "Auto" mode after a 120 second timeout window. To ensure that the user-selected fan profile (Max/Manual) persists, implement a keep-alive mechanism that periodically refreshes the fan mode trigger before the timeout occurs. - Introduce a delayed workqueue to trigger the fan mode refresh every 90 seconds, ensuring the system maintains the correct fan mode setting. - Integrate the refresh mechanism into hp_wmi_apply_fan_settings() to start, update or cancel the keep-alive process based on the current fan mode. This ensures that the driver stays in sync with the hardware. Tested on: HP Omen 16-wf1xxx (board ID 8C78) Signed-off-by: Krishna Chomal <krishna.chomal108@gmail.com> Link: https://patch.msgid.link/20260113123738.222244-4-krishna.chomal108@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-01-15platform/x86: hp-wmi: add manual fan control for Victus S modelsKrishna Chomal
Add manual fan speed control and PWM reporting for HP Victus S-series laptops. While HPWMI_FAN_SPEED_SET_QUERY was previously added to reset max fan mode, it is actually capable of individual fan control. This patch implements hp_wmi_fan_speed_set() to allow manual control and hides PWM inputs for non-Victus devices as the query is Victus specific. The existing hp_wmi_fan_speed_max_get() query is unreliable on Victus S firmware, often incorrectly reporting "Auto" mode even when "Max" is active. To resolve this synchronization issue, move state tracking to a per-device private context and apply "Auto" mode during driver initialization to ensure a consistent starting point. Refactor hp_wmi_apply_fan_settings() to use an intermediate ret variable. This prepares the switch block for keep-alive logic being added in a later patch, avoiding the need for duplicated mode check. Tested on: HP Omen 16-wf1xxx (board ID 8C78) Signed-off-by: Krishna Chomal <krishna.chomal108@gmail.com> Link: https://patch.msgid.link/20260113123738.222244-3-krishna.chomal108@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-01-15platform/x86: hp-wmi: order include headersKrishna Chomal
The include headers in hp-wmi driver are currently not in any specific order. As the driver continues to grow, keep the header block organized by sorting them alphabetically. Signed-off-by: Krishna Chomal <krishna.chomal108@gmail.com> Link: https://patch.msgid.link/20260113123738.222244-2-krishna.chomal108@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-01-15Merge tag 'linux-can-fixes-for-6.19-20260115' of ↵Paolo Abeni
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== pull-request: can 2026-01-15 this is a pull request of 4 patches for net/main, it super-seeds the "can 2026-01-14" pull request. The dev refcount leak in patch #3 is fixed. The first 3 patches are by Oliver Hartkopp and revert the approach to instantly reject unsupported CAN frames introduced in net-next-for-v6.19 and replace it by placing the needed data into the CAN specific ml_priv. The last patch is by Tetsuo Handa and fixes a J1939 refcount leak for j1939_session in session deactivation upon receiving the second RTS. linux-can-fixes-for-6.19-20260115 * tag 'linux-can-fixes-for-6.19-20260115' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can: net: can: j1939: j1939_xtp_rx_rts_session_active(): deactivate session upon receiving the second rts can: raw: instantly reject disabled CAN frames can: propagate CAN device capabilities via ml_priv Revert "can: raw: instantly reject unsupported CAN frames" ==================== Link: https://patch.msgid.link/20260115090603.1124860-1-mkl@pengutronix.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-15KVM: arm64: selftests: Add a test for FEAT_IDSTMarc Zyngier
Add a very basic test checking that FEAT_IDST actually works for the {GMID,SMIDR,CSSIDR2}_EL1 registers. Link: https://patch.msgid.link/20260108173233.2911955-10-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-01-15KVM: arm64: pkvm: Report optional ID register traps with a 0x18 syndromeMarc Zyngier
With FEAT_IDST, unimplemented system registers in the feature ID space must be reported using EC=0x18 at the closest handling EL, rather than with an UNDEF. Most of these system registers are always implemented thanks to their dependency on FEAT_AA64, except for a set of (currently) three registers: GMID_EL1 (depending on MTE2), CCSIDR2_EL1 (depending on FEAT_CCIDX), and SMIDR_EL1 (depending on SME). For these three registers, report their trap as EC=0x18 if they end-up trapping into KVM and that FEAT_IDST is implemented in the guest. Otherwise, just make them UNDEF. Link: https://patch.msgid.link/20260108173233.2911955-9-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-01-15KVM: arm64: pkvm: Add a generic synchronous exception injection primitiveMarc Zyngier
Similarly to the "classic" KVM code, pKVM doesn't have an "anything goes" synchronous exception injection primitive. Carve one out of the UNDEF injection code. Link: https://patch.msgid.link/20260108173233.2911955-8-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-01-15KVM: arm64: Force trap of GMID_EL1 when the guest doesn't have MTEMarc Zyngier
If our host has MTE, but the guest doesn't, make sure we set HCR_EL2.TID5 to force GMID_EL1 being trapped. Such trap will be handled by the FEAT_IDST handling. Reviewed-by: Joey Gouly <joey.gouly@arm.com> Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com> Link: https://patch.msgid.link/20260108173233.2911955-7-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-01-15KVM: arm64: Handle CSSIDR2_EL1 and SMIDR_EL1 in a generic wayMarc Zyngier
Now that we can handle ID registers using the FEAT_IDST infrastrcuture, get rid of the handling of CSSIDR2_EL1 and SMIDR_EL1. Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com> Link: https://patch.msgid.link/20260108173233.2911955-6-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-01-15KVM: arm64: Handle FEAT_IDST for sysregs without specific handlersMarc Zyngier
Add a bit of infrastrtcture to triage_sysreg_trap() to handle the case of registers falling into the Feature ID space that do not have a local handler. For these, we can directly apply the FEAT_IDST semantics and inject an EC=0x18 exception. Otherwise, an UNDEF will do. Reviewed-by: Joey Gouly <joey.gouly@arm.com> Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com> Link: https://patch.msgid.link/20260108173233.2911955-5-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-01-15KVM: arm64: Add a generic synchronous exception injection primitiveMarc Zyngier
Maybe in a surprising way, we don't currently have a generic way to inject a synchronous exception at the EL the vcpu is currently running at. Extract such primitive from the UNDEF injection code. Reviewed-by: Ben Horgan <ben.horgan@arm.com> Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com> Link: https://patch.msgid.link/20260108173233.2911955-4-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-01-15KVM: arm64: Add trap routing for GMID_EL1Marc Zyngier
HCR_EL2.TID5 is currently ignored by the trap routing infrastructure. Wire it in the routing table so that GMID_EL1, the sole register trapped by this bit, is correctly handled in the NV case. Link: https://patch.msgid.link/20260108173233.2911955-3-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-01-15arm64: Repaint ID_AA64MMFR2_EL1.IDS descriptionMarc Zyngier
ID_AA64MMFR2_EL1.IDS, as described in the sysreg file, is pretty horrible as it diesctly give the ESR value. Repaint it using the usual NI/IMP identifiers to describe the absence/presence of FEAT_IDST. Also add the new EL3 routing feature, even if we really don't care about it. Reviewed-by: Joey Gouly <joey.gouly@arm.com> Link: https://patch.msgid.link/20260108173233.2911955-2-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-01-15Merge tag 'ipsec-2026-01-14' of ↵Paolo Abeni
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec Steffen Klassert says: ==================== pull request (net): ipsec 2026-01-14 1) Fix inner mode lookup in tunnel mode GSO segmentation. The protocol was taken from the wrong field. 2) Set ipv4 no_pmtu_disc flag only on output SAs. The insertation of input SAs can fail if no_pmtu_disc is set. Please pull or let me know if there are problems. ipsec-2026-01-14 * tag 'ipsec-2026-01-14' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec: xfrm: set ipv4 no_pmtu_disc flag only on output sa when direction is set xfrm: Fix inner mode lookup in tunnel mode GSO segmentation ==================== Link: https://patch.msgid.link/20260114121817.1106134-1-steffen.klassert@secunet.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-15arm64: dts: mediatek: mt8186-evb: Add vproc fixed regulatorAngeloGioacchino Del Regno
This board at the moment has no support for PMIC regulators, but the CCI requires a vproc regulator in order to both stop giving dtbs_check warnings and to actually probe. Since vproc is a system-critical regulator and the bootloader enables it at max voltage, model it (at least temporarily) as a regulator-fixed and assign it to CCI. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2026-01-15net: inline napi_skb_cache_get()Eric Dumazet
clang is inlining it already, gcc (14.2) does not. Small space cost (215 bytes on x86_64) but faster sk_buff allocations. $ scripts/bloat-o-meter -t net/core/skbuff.gcc.before.o net/core/skbuff.gcc.after.o add/remove: 0/1 grow/shrink: 4/1 up/down: 359/-144 (215) Function old new delta __alloc_skb 471 611 +140 napi_build_skb 245 363 +118 napi_alloc_skb 331 416 +85 skb_copy_ubufs 1869 1885 +16 skb_shift 1445 1413 -32 napi_skb_cache_get 112 - -112 Total: Before=59941, After=60156, chg +0.36% Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260112131515.4051589-1-edumazet@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-15ASoC: rt5640: Fix duplicate clock properties in DT bindingMark Brown
Not quite overlapping changes to the rt5640 binding resulted in duplicate definitions of the clocks and clock-names properties. Delete one of them, preferring the simpler one. Reported-by: Jon Hunter <jonathanh@nvidia.com> Closes: https://lore.kernel.org/r/0e68c5f4-f68d-4544-bc7a-40694829db75@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://patch.msgid.link/20260114-asoc-fix-rt5640-dt-clocks-v1-1-421d438673c2@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-15Merge branch 'net-mlx5-hws-single-flow-counter-support'Paolo Abeni
Tariq Toukan says: ==================== net/mlx5: HWS single flow counter support This small series refactors the flow counter bulk initialization code and extends it so that single flow counters are also usable by hardware steering (HWS) rules. Patches 1-2 refactor the bulk init path: first by factoring out common flow counter bulk initialization into mlx5_fc_bulk_init(), then by splitting the bitmap allocation into mlx5_fs_bulk_bitmap_alloc(), with no functional changes. Patch 3 initializes bulk data for counters allocated via mlx5_fc_single_alloc(), so they can be safely used by HWS rules. ==================== Link: https://patch.msgid.link/1768210825-1598472-1-git-send-email-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-15net/mlx5: Initialize bulk for single flow countersMoshe Shemesh
Ensure that flow counters allocated with mlx5_fc_single_alloc() have bulk correctly initialized so they can safely be used in HWS rules. Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1768210825-1598472-4-git-send-email-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-15net/mlx5: fs, split bulk initMark Bloch
Refactor mlx5_fs_bulk_init() by moving bitmap allocation logic into a new helper function mlx5_fs_bulk_bitmap_alloc(). This change does not alter any logic. Signed-off-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1768210825-1598472-3-git-send-email-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-15net/mlx5: fs, factor out flow counter bulk initMark Bloch
Add mlx5_fc_bulk_init() to handle bulk initialization of flow counters. This change does not alter any logic, but refactors the code to remove duplicate initialization logic by centralizing it in a single function. Signed-off-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1768210825-1598472-2-git-send-email-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-15soc: renesas: Add support for RZ/N1 GPIO Interrupt MultiplexerHerve Codina (Schneider Electric)
On the Renesas RZ/N1 SoC, GPIOs can generate interruptions. Those interruption lines are multiplexed by the GPIO Interrupt Multiplexer in order to map 32 * 3 GPIO interrupt lines to 8 GIC interrupt lines. The GPIO interrupt multiplexer IP does nothing but select 8 GPIO IRQ lines out of the 96 available to wire them to the GIC input lines. Signed-off-by: Herve Codina (Schneider Electric) <herve.codina@bootlin.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260114093938.1089936-8-herve.codina@bootlin.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-01-15irqchip/renesas-rza1: Use for_each_of_imap_item iteratorHerve Codina (Schneider Electric)
The renesas-rza1 driver parses the interrupt-map property. It does it using open code. Recently for_each_of_imap_item iterator has been introduce to help drivers in this parsing. Convert the renesas-rza1 driver to use the for_each_of_imap_item iterator instead of open code. Signed-off-by: Herve Codina (Schneider Electric) <herve.codina@bootlin.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260114093938.1089936-5-herve.codina@bootlin.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-01-15irqchip/ls-extirq: Use for_each_of_imap_item iteratorHerve Codina (Schneider Electric)
The ls-extirq driver parses the interrupt-map property. It does it using open code. Recently for_each_of_imap_item iterator has been introduce to help drivers in this parsing. Convert the ls-extirq driver to use the for_each_of_imap_item iterator instead of open code. Signed-off-by: Herve Codina (Schneider Electric) <herve.codina@bootlin.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260114093938.1089936-4-herve.codina@bootlin.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-01-15of: unittest: Add a test case for for_each_of_imap_item iteratorHerve Codina (Schneider Electric)
Recently for_each_of_imap_item iterator has been introduce to help drivers in parsing the interrupt-map property. Add a test case for this iterator. Signed-off-by: Herve Codina (Schneider Electric) <herve.codina@bootlin.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patch.msgid.link/20260114093938.1089936-3-herve.codina@bootlin.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-01-15of/irq: Introduce for_each_of_imap_itemHerve Codina (Schneider Electric)
for_each_of_imap_item is an iterator designed to help a driver to parse an interrupt-map property. Indeed some drivers need to know details about the interrupt mapping described in the device-tree in order to set internal registers accordingly. Signed-off-by: Herve Codina (Schneider Electric) <herve.codina@bootlin.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patch.msgid.link/20260114093938.1089936-2-herve.codina@bootlin.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-01-15RDMA/mana_ib: Take CQ type from the device typeKonstantin Taranov
Get CQ type from the used gdma device. The MANA_IB_CREATE_RNIC_CQ flag is ignored. It was used in older kernel versions where the mana_ib was shared between ethernet and rnic. Fixes: d4293f96ce0b ("RDMA/mana_ib: unify mana_ib functions to support any gdma device") Signed-off-by: Konstantin Taranov <kotaranov@microsoft.com> Link: https://patch.msgid.link/20260115093625.177306-1-kotaranov@linux.microsoft.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-01-15ARM: dts: r9a06g032: Add support for GPIO interruptsHerve Codina (Schneider Electric)
In the RZ/N1 SoC, the GPIO interrupts are multiplexed using the GPIO Interrupt Multiplexer. Add the multiplexer node and connect GPIO interrupt lines to the multiplexer. The interrupt-map available in the multiplexer node has to be updated in dts files depending on the GPIO usage. Indeed, the usage of an interrupt for a GPIO is board dependent. Up to 8 GPIOs can be used as an interrupt line (one per multiplexer output interrupt). Signed-off-by: Herve Codina (Schneider Electric) <herve.codina@bootlin.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://patch.msgid.link/20260114093938.1089936-9-herve.codina@bootlin.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-01-15ARM: dts: r9a06g032: Add GPIO controllersHerve Codina (Schneider Electric)
Add GPIO controllers (Synopsys DesignWare IPs) available in the r9a06g032 (RZ/N1D) SoC. Signed-off-by: Herve Codina (Schneider Electric) <herve.codina@bootlin.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patch.msgid.link/20260114093938.1089936-6-herve.codina@bootlin.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-01-15arm64: dts: renesas: rzg3e-smarc-som: Enable I3C supportTommaso Merciai
Enable I3C on RZ/G3E SMARC SoM. Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/9d1cf2cdb1c11f24378404142e4c8aff680c6961.1763638659.git.tommaso.merciai.xr@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-01-15KVM: arm64: Honor UX/PX attributes for EL2 S1 mappingsMarc Zyngier
Now that we potentially have two bits to deal with when setting execution permissions, make sure we correctly handle them when both when building the page tables and when reading back from them. Reported-by: Alexandru Elisei <alexandru.elisei@arm.com> Reviewed-by: Fuad Tabba <tabba@google.com> Reviewed-by: Joey Gouly <joey.gouly@arm.com> Tested-by: Fuad Tabba <tabba@google.com> Link: https://patch.msgid.link/20251210173024.561160-7-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-01-15KVM: arm64: Convert VTCR_EL2 to config-driven sanitisationMarc Zyngier
Describe all the VTCR_EL2 fields and their respective configurations, making sure that we correctly ignore the bits that are not defined for a given guest configuration. Reviewed-by: Alexandru Elisei <alexandru.elisei@arm.com> Reviewed-by: Fuad Tabba <tabba@google.com> Tested-by: Fuad Tabba <tabba@google.com> Link: https://patch.msgid.link/20251210173024.561160-6-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-01-15KVM: arm64: Account for RES1 bits in DECLARE_FEAT_MAP() and coMarc Zyngier
None of the registers we manage in the feature dependency infrastructure so far has any RES1 bit. This is about to change, as VTCR_EL2 has its bit 31 being RES1. In order to not fail the consistency checks by not describing a bit, add RES1 bits to the set of immutable bits. This requires some extra surgery for the FGT handling, as we now need to track RES1 bits there as well. There are no RES1 FGT bits *yet*. Watch this space. Reviewed-by: Fuad Tabba <tabba@google.com> Tested-by: Sascha Bischoff <sascha.bischoff@arm.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Tested-by: Fuad Tabba <tabba@google.com> Link: https://patch.msgid.link/20251210173024.561160-5-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-01-15arm64: Convert VTCR_EL2 to sysreg infratructureMarc Zyngier
Our definition of VTCR_EL2 is both partial (tons of fields are missing) and totally inconsistent (some constants are shifted, some are not). They are also expressed in terms of TCR, which is rather inconvenient. Replace the ad-hoc definitions with the the generated version. This results in a bunch of additional changes to make the code with the unshifted nature of generated enumerations. The register data was extracted from the BSD licenced AARCHMRS (AARCHMRS_OPENSOURCE_A_profile_FAT-2025-09_ASL0). Reviewed-by: Alexandru Elisei <alexandru.elisei@arm.com> Reviewed-by: Fuad Tabba <tabba@google.com> Tested-by: Fuad Tabba <tabba@google.com> Link: https://patch.msgid.link/20251210173024.561160-4-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-01-15arm64: Convert ID_AA64MMFR0_EL1.TGRAN{4,16,64}_2 to UnsignedEnumMarc Zyngier
ID_AA64MMFR0_EL1.TGRAN{4,16,64}_2 are currently represented as unordered enumerations. However, the architecture treats them as Unsigned, as hinted to by the MRS data: (FEAT_S2TGran4K <=> (((UInt(ID_AA64MMFR0_EL1.TGran4_2) == 0) && FEAT_TGran4K) || (UInt(ID_AA64MMFR0_EL1.TGran4_2) >= 2)))) and similar descriptions exist for 16 and 64k. This is also confirmed by D24.1.3.3 ("Alternative ID scheme used for ID_AA64MMFR0_EL1 stage 2 granule sizes") in the L.b revision of the ARM ARM. Turn these fields into UnsignedEnum so that we can use the above description more or less literally. Reviewed-by: Fuad Tabba <tabba@google.com> Tested-by: Fuad Tabba <tabba@google.com> Link: https://patch.msgid.link/20251210173024.561160-3-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-01-15dt-bindings: soc: renesas: Document RZ/N1 GPIO Interrupt MultiplexerHerve Codina (Schneider Electric)
On the Renesas RZ/N1 SoC, GPIOs can generate interruptions. Those interruption lines are multiplexed by the GPIO Interrupt Multiplexer in order to map 32 * 3 GPIO interrupt lines to 8 GIC interrupt lines. The GPIO interrupt multiplexer IP does nothing but select 8 GPIO IRQ lines out of the 96 available to wire them to the GIC input lines. Signed-off-by: Herve Codina (Schneider Electric) <herve.codina@bootlin.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260114093938.1089936-7-herve.codina@bootlin.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-01-15Merge branch 'introduce-and-use-netif_xmit_timeout_ms-helper'Paolo Abeni
Tariq Toukan says: ==================== Introduce and use netif_xmit_timeout_ms() helper This is V2, find V1 here: https://lore.kernel.org/all/1764054776-1308696-1-git-send-email-tariqt@nvidia.com/ This series by Shahar introduces a new helper function netif_xmit_timeout_ms() to check if a TX queue has timed out and report the timeout duration. It also encapsulates the check for whether the TX queue is stopped. Replace duplicated open-coded timeout check in hns3 driver with the new helper. For mlx5e, refine the TX timeout recovery flow to act only on SQs whose transmit timestamp indicates an actual timeout, as determined by the helper. This prevents unnecessary channel reopen events caused by attempting recovery on queues that are merely stopped but not truly timed out. ==================== Link: https://patch.msgid.link/1768209383-1546791-1-git-send-email-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-15net/mlx5e: Refine TX timeout handling to skip non-timed-out SQShahar Shitrit
mlx5e_tx_timeout_work() is invoked when the dev_watchdog reports a timed-out TX queue. Currently, the recovery flow is triggered for all stopped SQs, which is not always correct — some SQs may be temporarily stopped without actually timing out. Attempting to recover such SQs results in no EQE being polled (since no real timeout occurred), which the driver misinterprets as a recovery failure, unnecessarily causing channel reopening. Improve the logic to initiate recovery only for SQs that are both stopped and timed out. Utilize the helper introduced in the previous patch to determine whether the netdevice watchdog timeout period has elapsed since the SQ’s last transmit timestamp. Signed-off-by: Shahar Shitrit <shshitrit@nvidia.com> Reviewed-by: Yael Chemla <ychemla@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1768209383-1546791-4-git-send-email-tariqt@nvidia.com Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-15net: hns3: Use netif_xmit_timeout_ms() helperShahar Shitrit
Replace the open-coded TX queue timeout check in hns3_get_timeout_queue() with a call to netif_xmit_timeout_ms() helper. Signed-off-by: Shahar Shitrit <shshitrit@nvidia.com> Reviewed-by: Yael Chemla <ychemla@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Jijie Shao <shaojijie@huawei.com> Link: https://patch.msgid.link/1768209383-1546791-3-git-send-email-tariqt@nvidia.com Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-15net: Introduce netif_xmit_timeout_ms() helperShahar Shitrit
Introduce a new helper function netif_xmit_timeout_ms() to check if a TX queue is stopped and has timed out and report the timeout duration. This makes the timeout logic reusable, and will be used in several places in subsequent patches. Signed-off-by: Shahar Shitrit <shshitrit@nvidia.com> Reviewed-by: Yael Chemla <ychemla@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1768209383-1546791-2-git-send-email-tariqt@nvidia.com Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-15Merge branch kvmarm-fixes-6.19-1 into kvm-arm64/vtcrMarc Zyngier
KVM/arm64 fixes for 6.19 - Ensure early return semantics are preserved for pKVM fault handlers - Fix case where the kernel runs with the guest's PAN value when CONFIG_ARM64_PAN is not set - Make stage-1 walks to set the access flag respect the access permission of the underlying stage-2, when enabled - Propagate computed FGT values to the pKVM view of the vCPU at vcpu_load() - Correctly program PXN and UXN privilege bits for hVHE's stage-1 page tables - Check that the VM is actually using VGICv3 before accessing the GICv3 CPU interface - Delete some unused code # -----BEGIN PGP SIGNATURE----- # # iI0EABYKADUWIQSNXHjWXuzMZutrKNKivnWIJHzdFgUCaWiyJBccb2xpdmVyLnVw # dG9uQGxpbnV4LmRldgAKCRCivnWIJHzdFqVhAQDM4Lbrq0F80X+YzvO7oxWioOy4 # JiTATSii9Lit8KY6fgEAvLD4qaggLdF3+WY+V37YmTj3UDgI31ClBr+xSvSengA= # =XaL0 # -----END PGP SIGNATURE----- # gpg: Signature made Thu 15 Jan 2026 09:23:48 GMT # gpg: using EDDSA key 8D5C78D65EECCC66EB6B28D2A2BE7588247CDD16 # gpg: issuer "oliver.upton@linux.dev" # gpg: Can't check signature: No public key * tag 'kvmarm-fixes-6.19-1': KVM: arm64: Invert KVM_PGTABLE_WALK_HANDLE_FAULT to fix pKVM walkers KVM: arm64: Don't blindly set set PSTATE.PAN on guest exit KVM: arm64: nv: Respect stage-2 write permssion when setting stage-1 AF KVM: arm64: Remove unused vcpu_{clear,set}_wfx_traps() KVM: arm64: Remove unused parameter in synchronize_vcpu_pstate() KVM: arm64: Remove extra argument for __pvkm_host_{share,unshare}_hyp() KVM: arm64: Inject UNDEF for a register trap without accessor KVM: arm64: Copy FGT traps to unprotected pKVM VCPU on VCPU load KVM: arm64: Fix EL2 S1 XN handling for hVHE setups KVM: arm64: gic: Check for vGICv3 when clearing TWI Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-01-15LoongArch: Remove redundant code in head.SHuacai Chen
SETUP_MODES already setup the initial values of CSR.CRMD, CSR.PRMD and CSR.EUEN, so the redundant open code can be removed. Fixes: 7b2afeafaf9c2d5 ("LoongArch: Adjust boot & setup for 32BIT/64BIT") Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
generated by cgit v1.2.3 (git 2.25.1) at 2026-05-21 04:27:38 +0000