pin is an unsigned int pin id, where 0 (GPIO_0 / gmac0_rxdv on K3) is a
valid pin, so rejecting it here drops the PAD config write for the first
pin of every group. On K3 Pico-ITX the GMAC RGMII group lists pin 0 as
its first entry, so its drive-strength / bias configuration was silently
ignored.
The intended guard is against spacemit_get_pin() returning NULL when the
pin id isn't in the SoC's pin table. Check spin instead, which both
restores PAD setup for pin 0 and prevents a NULL deref on spin->pin.
Fixes: a83c29e1d145 ("pinctrl: spacemit: add support for SpacemiT K1 SoC") Signed-off-by: Han Gao <gaohan@iscas.ac.cn> Reviewed-by: Troy Mitchell <troy.mitchell@linux.spacemit.com> Reviewed-by: Yixun Lan <dlan@kernel.org> Signed-off-by: Linus Walleij <linusw@kernel.org>
Thomas Hellström [Wed, 20 May 2026 10:16:16 +0000 (12:16 +0200)]
drm/exec, drm/xe, drm/amdgpu: Add an accessor for struct drm_exec::ticket
Drivers were accessing this drm_exec member directly.
While that may seem harmless, it will require action if
the drm_exec utility is made a subclass of a dma-resv transaction
utility as outlined in the cover-letter.
Provide an accessor, drm_exec_ticket() to avoid that.
Thomas Hellström [Wed, 20 May 2026 10:16:15 +0000 (12:16 +0200)]
drm/exec, drm/xe: Avoid abusing the drm_exec retry pointer
The xe driver was using the drm_exec retry pointer directly to
restart the locking loop after out-of-memory errors. This is
relying on undocumented behaviour.
Instead add a drm_exec_retry() macro that can be used in this
situation, and that also warns if the struct drm_exec is
not newly (re-)initialized.
Use that macro in xe.
v2:
- Only allow if the drm_exec context is newly initialized.
(Christian)
Thomas Hellström [Wed, 20 May 2026 10:16:13 +0000 (12:16 +0200)]
drm/exec: Remove the index parameter from drm_exec_for_each_locked_obj[_reverse]
Nobody makes any use of it. Possible internal future users can
instead use the _index variable. External users shouldn't use
it since the array it's pointing into is internal drm_exec state.
v2:
- Use a unique id for the loop variable (Christian)
Arnd Bergmann [Wed, 20 May 2026 07:51:14 +0000 (09:51 +0200)]
pinctrl: avoid duplicate function definitions
The pinctrl_generic_to_map() and pinctrl_generic_pins_function_dt_node_to_map()
functions are built whenever CONFIG_GENERIC_PINCTRL is enabled, including
configurations without CONFIG_OF.
When CONFIG_OF is disabled, the dummy definitions are also present in the header,
which causes the build to fail:
drivers/pinctrl/pinctrl-generic.c:20:5: error: conflicting types for 'pinctrl_generic_to_map'; have 'int(struct pinctrl_dev *, struct device_node *, struct device_node *, struct pinctrl_map **, unsigned int *, unsigned int *, const char **, unsigned int, const char **, unsigned int *, unsigned int)'
20 | int pinctrl_generic_to_map(struct pinctrl_dev *pctldev, struct device_node *parent,
| ^~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/pinctrl/pinctrl-generic.c:16:
drivers/pinctrl/pinconf.h:193:1: note: previous definition of 'pinctrl_generic_to_map' with type 'int(struct pinctrl_dev *, struct device_node *, struct device_node *, struct pinctrl_map **, unsigned int *, unsigned int *, const char **, unsigned int, const char **, unsigned int *, void *)'
193 | pinctrl_generic_to_map(struct pinctrl_dev *pctldev, struct device_node *parent,
| ^~~~~~~~~~~~~~~~~~~~~~
drivers/pinctrl/pinctrl-generic.c:130:5: error: redefinition of 'pinctrl_generic_pins_function_dt_node_to_map'
130 | int pinctrl_generic_pins_function_dt_node_to_map(struct pinctrl_dev *pctldev,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/pinctrl/pinconf.h:184:1: note: previous definition of 'pinctrl_generic_pins_function_dt_node_to_map' with type 'int(struct pinctrl_dev *, struct device_node *, struct pinctrl_map **, unsigned int *)'
184 | pinctrl_generic_pins_function_dt_node_to_map(struct pinctrl_dev *pctldev,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Removing either set of definitions is sufficient to avoid the problem.
Thomas Gerner [Thu, 14 May 2026 18:32:01 +0000 (20:32 +0200)]
riscv: dts: thead: Enable wifi on the BeagleV-Ahead
The BeagleV-Ahead board uses an AP6203BM WiFi chip from AMPAK Technology
Inc. connected to SDIO1. The chip is compatible to the broadcom wireless
driver.
The AP6203BM is a dual-band 2.4GHz/5GHz Wi-Fi 4 (802.11a/b/g/n) and
Bluetooth 5.4 module. Bluetooth is not enabled by this patch.
Signed-off-by: Thomas Gerner <thomas.gerner@muenchen-mail.de> Signed-off-by: Drew Fustini <fustini@kernel.org>
MoeLeak [Fri, 8 May 2026 11:44:14 +0000 (19:44 +0800)]
riscv: dts: thead: Enable WiFi on Lichee Pi 4A
The Lichee Pi 4A has an RTL8723DS WiFi module connected to the TH1520
SDIO1 controller. The module reset line is driven through a PCA9557 GPIO
expander on the I2C1 bus.
Enable I2C1 for the GPIO expander and configure SDIO1 as a non-removable
4-bit SDIO bus using an mmc-pwrseq-simple reset sequence so the WiFi
device can be powered and enumerated.
Billy Tsai [Thu, 21 May 2026 09:17:46 +0000 (17:17 +0800)]
pinctrl: aspeed: Add AST2700 SoC1 support
Implement pin multiplexing (and pin configuration where applicable)
for the AST2700 SoC1 SCU pinctrl block using static SoC data tables.
Unlike legacy ASPEED pin controllers, the SoC1 pin function control
fields are highly regular, which makes it practical to describe the
packed-field register layout directly in driver data rather than reuse
the existing Aspeed pinctrl macro infrastructure.
The driver uses the generic pinctrl, pinmux and pinconf frameworks.
The controller registers are accessed via regmap from the parent
syscon, allowing shared ownership of the SCU register block.
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
Karol Wachowski [Fri, 22 May 2026 09:32:09 +0000 (11:32 +0200)]
accel/ivpu: Document why full JSM message size is always used
Firmware expects IPC messages to always carry the full fixed
sizeof(struct vpu_jsm_msg) size. Sending the full struct also
ensures unused fields are zeroed, which maintains compatibility
when existing commands are extended with new fields in the future.
Replace the misleading TODO comment with an explanation of the
actual intent.
ACPI: button: Add missing device class clearing on probe failures
Commit e18947038bf4 ("ACPI: driver: Do not set acpi_device_class()
unnecessarily") modified acpi_button_remove() to clear the device class
field in struct acpi_device on driver removal, but it should also have
updated the rollback path in acpi_button_probe(), which it didn't do,
so do it now.
Fixes: e18947038bf4 ("ACPI: driver: Do not set acpi_device_class() unnecessarily") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Link: https://patch.msgid.link/6167713.MhkbZ0Pkbq@rafael.j.wysocki
ACPI: button: Enable wakeup GPEs for ACPI buttons at probe time
Prior to commit 57c31e6d620f ("ACPI: scan: Use acpi_setup_gpe_for_wake()
for buttons"), ACPI button wakeup GPEs having handler methods remained
enabled after acpi_wakeup_gpe_init(), but currently they are not enabled
because acpi_setup_gpe_for_wake() disables them.
That causes function keys to stop working on some systems [1] and there
may be other related issues elsewhere.
To address that, make the ACPI button driver enable wakeup GPEs for ACPI
buttons so long as they have handler methods. While this does not
restore the old behavior exactly (the ACPI button driver needs to be
bound to the button devices for the GPEs to be enabled), it should be
sufficient to restore the missing functionality.
For this purpose, introduce acpi_enable_gpe_cond() that enables
a GPE if its dispatch type matches the supplied one and modify
acpi_button_probe() to use that function for enabling the GPEs in
question.
Fixes: 57c31e6d620f ("ACPI: scan: Use acpi_setup_gpe_for_wake() for buttons") Reported-by: Nick <nick@kousu.ca> Closes: https://lore.kernel.org/linux-acpi/E2OXET.4X5GTP37VTNC3@kousu.ca/ [1] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Nick <nick@kousu.ca> Cc: 7.0+ <stable@vger.kernel.org> # 7.0+ Link: https://patch.msgid.link/9629117.CDJkKcVGEf@rafael.j.wysocki
ACPI: button: Fix ACPI GPE handler leak during removal
Commit a7e23ec17fee ("ACPI: button: Install notifier for system events
as well") changed the ACPI notify handler type for ACPI buttons to
ACPI_ALL_NOTIFY, but it forgot to update acpi_button_remove() to reflect
that change. This leads to leaking the notify handler past driver
removal, which may cause a kernel crash to occur if ACPI notify on
the given device is triggered after removing the driver, and causes a
subsequent probe of the given device with the same driver to fail.
Address this by updating the acpi_remove_notify_handler() call in
acpi_button_remove() as appropriate.
Fixes: a7e23ec17fee ("ACPI: button: Install notifier for system events as well") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Cc: 6.15+ <stable@vger.kernel.org> # 6.15+ Link: https://patch.msgid.link/7954431.EvYhyI6sBW@rafael.j.wysocki
Oleksij Rempel [Fri, 15 May 2026 16:05:31 +0000 (18:05 +0200)]
pinctrl: core: Make pin group callbacks optional for pin-only drivers
Currently, the pinctrl core strictly requires all drivers to implement
.get_groups_count and .get_group_name callbacks in their pinctrl_ops.
However, for simple pinctrl drivers that act purely as GPIO controllers
and pin-specific configuration proxies, without any concept of muxing or
pin groups, this strict requirement forces the implementation of dummy
callbacks just to satisfy pinctrl_check_ops().
Relax this requirement for pin-only drivers by making the group callbacks
optional when no muxing or group pin configuration support is provided.
Update the core and debugfs helpers to check for the existence of these
callbacks before invoking them.
Drivers that provide muxing or group pin configuration operations still
must implement group enumeration and naming callbacks, and are rejected
at registration time if they do not.
Judith Mendez [Wed, 13 May 2026 23:11:54 +0000 (18:11 -0500)]
pinctrl: mcp23s08: Read spi-present-mask as u8 not u32
The binding (microchip,mcp23s08) specifies microchip,spi-present-mask
as uint8, but driver would read u32, causing type mismatch. Use
device_property_read_u8 to match binding spec, hardware (8 chips max),
& prevent probe failure.
Judith Mendez [Wed, 13 May 2026 23:11:53 +0000 (18:11 -0500)]
pinctrl: mcp23s08: Initialize mcp->dev and mcp->addr before regmap init
Regmap initialization triggers regcache_maple_populate() which attempts
SPI read to populate cache. SPI read requires mcp->dev and mcp->addr to
be set, without them, NULL pointer dereference occurs during probe.
Move initialization before mcp23s08_spi_regmap_init() call.
Cc: stable@vger.kernel.org Fixes: f9f4fda15e72 ("pinctrl: mcp23s08: init reg_defaults from HW at probe and switch cache type") Signed-off-by: Judith Mendez <jm@ti.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
Len Bao [Sun, 24 May 2026 16:52:48 +0000 (16:52 +0000)]
ALSA: drivers: Mark some variables as __ro_after_init
Some variables in the 'ALSA/drivers' are initialized only during the
init phase in the '__init' functions and never changed. So, mark them
as __ro_after_init to reduce the attack surface.
Len Bao [Sun, 24 May 2026 16:29:13 +0000 (16:29 +0000)]
ALSA: core: Mark some variables as __ro_after_init
Some variables in the 'ALSA/core' are initialized only during the init
phase in the '__init' functions and never changed. So, mark them as
__ro_after_init to reduce the attack surface.
Len Bao [Sun, 24 May 2026 15:40:49 +0000 (15:40 +0000)]
ALSA: isa: Mark '*_registered' variables as __ro_after_init
The '*_registered' variables are initialized only during the init
phase in the '__init' functions and never changed. So, mark them as
__ro_after_init to reduce the attack surface.
ALSA: hda/realtek: Limit mic boost on Positivo DN140
The internal mic boost on the Positivo DN140 is too high.
Fix this by applying the ALC269_FIXUP_LIMIT_INT_MIC_BOOST fixup to the machine
to limit the gain.
ALSA: scarlett2: Fix 2i2 Gen 4 direct monitor gain on firmware 2417
Firmware 2417 for the Scarlett 4th Gen 2i2 moved the direct monitor
gain parameter by 4 bytes, from offset 0x2a0 to 0x2a4, breaking the
"Direct Monitor X Mix Y" controls.
Special-case the offset in the get/set config helpers when the
running firmware is 2417 or later.
Fixes: 4e809a299677 ("ALSA: scarlett2: Add support for Solo, 2i2, and 4i4 Gen 4") Cc: <stable@vger.kernel.org> Signed-off-by: Geoffrey D. Bennett <g@b4.vu> Link: https://patch.msgid.link/ahIWTueUlWA5xiV+@m.b4.vu Signed-off-by: Takashi Iwai <tiwai@suse.de>
Cássio Gabriel [Sat, 23 May 2026 01:09:40 +0000 (22:09 -0300)]
ALSA: pcm: oss: Fix setup list UAF on proc write error
snd_pcm_oss_proc_write() links a newly allocated setup entry into the
OSS setup list before duplicating the task name. If the task-name
allocation fails, the error path frees the already linked entry and
leaves setup_list pointing at freed memory.
A later OSS device open can then walk the stale list entry in
snd_pcm_oss_look_for_setup() and dereference freed memory.
Allocate the task name and initialize the setup entry before publishing
the entry on setup_list. Also fetch the initial proc read iterator only
after taking setup_mutex, so all setup_list traversal follows the same
list lifetime rules.
Cássio Gabriel [Fri, 22 May 2026 12:49:30 +0000 (09:49 -0300)]
ALSA: hda: cs35l56: Fix system name string leaks
cs35l56_hda_read_acpi() gets an allocated ACPI _SUB string from
acpi_get_subsystem_id(). On success, that string is used to create the
firmware system name.
Several error paths after the _SUB lookup can return without releasing
the allocated string. This includes speaker ID lookup errors other than
-ENOENT, and errors after a firmware system name has been allocated.
Use scoped cleanup for the temporary _SUB string and make
cs35l56->system_name device-managed. This releases the temporary _SUB
string on every error path and lets devres release the firmware system
name on probe failure and device removal.
Fixes: 6f03b446cbae ("ALSA: hda: cs35l56: Add support for speaker id") Fixes: 40b1c2f9b299 ("ALSA: hda/cs35l56: Workaround bad dev-index on Lenovo Yoga Book 9i GenX") Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260522-alsa-cs35l56-system-name-leak-v4-1-a6154dd09cd9@gmail.com
Kris Kater [Fri, 22 May 2026 06:09:02 +0000 (08:09 +0200)]
ALSA: hda/realtek: Add HDA_CODEC_QUIRK for Lenovo Yoga Slim 7 14AGP11
The BIOS on the Lenovo Yoga Slim 7 14AGP11 (AMD Ryzen AI / Kraken
Point chassis; board LNVNB161216, product 83QS) programs the PCI
subsystem ID of the HDA function as 17aa:0000. As a result no entry
in alc269_fixup_tbl[] matches via SND_PCI_QUIRK, the fixup falls back
to the generic auto-routing path, and the bass speaker pin is left
mis-routed. Laptop speakers sound noticeably thin.
The codec's own internal subsystem ID register reports 0x17aa394c
correctly, so an HDA_CODEC_QUIRK entry (which matches on the codec
SSID rather than on the PCI SSID) binds the chassis to the existing
ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN fixup. This mirrors the same
workaround already in place for the closely-related Yoga 7 2-in-1
14AKP10 and 16AKP10 entries earlier in the table.
With this change the kernel log goes from
ALC287: picked fixup for PCI SSID 17aa:0000
to
ALC287: picked fixup alc287-yoga9-bass-spk-pin
and speaker routing matches what the firmware intended. Verified by
the reporter against the equivalent modprobe override
(model=,alc287-yoga9-bass-spk-pin).
Zhang Heng [Fri, 22 May 2026 06:07:42 +0000 (14:07 +0800)]
ALSA: hda/realtek: Fix incorrect comment for ALC299_FIXUP_PREDATOR_SPK
The comment for the pin configuration 0x21 in the fixup
ALC299_FIXUP_PREDATOR_SPK states "use as headset mic, without its own
jack detect", but the fixup name and the actual usage indicate that the
pin is meant to be used as internal speaker. Correct the comment to
avoid confusion.
The register DSP event queue is updated under parser->lock, but
snd_motu_register_dsp_message_parser_count_event() reads pull_pos and
push_pos without the lock.
snd_motu_register_dsp_message_parser_copy_event() also reads both queue
positions before taking the lock.
Protect these accesses with parser->lock as well. This keeps the hwdep
poll/read path consistent with the producer side and with the cached
meter/parameter accessors.
Fixes: 634ec0b2906e ("ALSA: firewire-motu: notify event for parameter change in register DSP model") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260521-alsa-firewire-motu-event-locking-v1-1-708e1c2b5e56@gmail.com
Commit 792d2b9a1259 ("drm: drop mtrr from i915"), added this comment,
drop it since it since MTRR no longer exists since 2013 and is removed
by commit 281856477cda ("drm: rip out drm_core_has_MTRR checks").
Luka Gejak [Mon, 18 May 2026 14:23:11 +0000 (16:23 +0200)]
wifi: rtw88: usb: fix memory leaks on USB write failures
When rtw_usb_write_port() fails to submit a USB Request Block (URB)
(e.g., due to device disconnect or ENOMEM), the completion callback is
never executed.
Currently, the driver ignores the return value of rtw_usb_write_port()
in rtw_usb_write_data() and rtw_usb_tx_agg_skb(). Because these
functions rely on the completion callback to free the socket buffers
(skbs) and the transaction control block (txcb), a submission failure
results in:
1. A memory leak of the allocated skb in rtw_usb_write_data().
2. A memory leak of the txcb structure and all aggregated skbs in
rtw_usb_tx_agg_skb().
Fix this by checking the return value of rtw_usb_write_port(). If it
fails, explicitly free the skb in rtw_usb_write_data(), and properly
purge the tx_ack_queue and free the txcb in rtw_usb_tx_agg_skb().
The issue was discovered in practice during device disconnect/reconnect
scenarios and memory pressure conditions. Tested by verifying normal TX
operation continues after the fix without regressions.
Fixes: a82dfd33d123 ("wifi: rtw88: Add common USB chip support") Cc: stable@vger.kernel.org Acked-by: Ping-Ke Shih <pkshih@realtek.com> Tested-by: Luka Gejak <luka.gejak@linux.dev> Signed-off-by: Luka Gejak <luka.gejak@linux.dev> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260518142311.10328-2-luka.gejak@linux.dev
Luka Gejak [Mon, 18 May 2026 14:23:10 +0000 (16:23 +0200)]
wifi: rtw88: increase TX report timeout to fix race condition
The driver expects the firmware to report TX status within 500ms.
However, a timeout can be triggered when the hardware performs
background scans while under TX load. During these scans, the firmware
stays off-channel for periods exceeding 500ms, delaying the delivery of
TX reports back to the driver.
When this occurs, the purge timer fires prematurely and drops the
tracking skbs from the queue. This results in the host stack
interpreting the missing status as packet loss, leading to TCP window
collapse. In testing with iperf3, this causes throughput to drop from
~90 Mbps to near-zero for approximately 2 seconds until the connection
recovers.
Increase RTW_TX_PROBE_TIMEOUT to 2500ms for RTL8723DU. This duration is
sufficient to accommodate off-channel dwell time during full background
scans, ensuring the purge timer only trips during genuine firmware
lockups and preventing unnecessary TCP retransmission cycles.
Fixes: a82dfd33d123 ("wifi: rtw88: Add common USB chip support") Cc: stable@vger.kernel.org Acked-by: Ping-Ke Shih <pkshih@realtek.com> Tested-by: Luka Gejak <luka.gejak@linux.dev> Signed-off-by: Luka Gejak <luka.gejak@linux.dev> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260518142311.10328-1-luka.gejak@linux.dev
Ping-Ke Shih [Fri, 15 May 2026 01:44:33 +0000 (09:44 +0800)]
wifi: rtw89: 8922d: add quota for RTL8922DE variant
The existing quota set is for RTL8922DE-VS, so rename the existing tables.
Add new quota set for RTL8922DE, containing more memory to yield better
performance, so rearrange quota accordingly.
Ping-Ke Shih [Fri, 15 May 2026 01:44:32 +0000 (09:44 +0800)]
wifi: rtw89: mac: consolidate quota into a struct for variant chips
RTL8922D has many variants, using different quota tables. Consolidate the
quota data into a struct, and then select corresponding table for the
chip variant.
Po-Hao Huang [Fri, 15 May 2026 01:44:29 +0000 (09:44 +0800)]
wifi: rtw89: correct drop logic for malformed AMPDU frames
The previous commit aims to fix issue caused by malformed AMPDU frames.
But the drop logic fails to deal with the first AMPDU packet paired with
certain range of sequence number, and leads to unexpected packet drop.
It is more likely to encounter this failure when there are busy traffic
during rekey process and could lead to disconnection from the AP.
Fix this by adding a initial state judgement and only reset status
during pairwise rekey.
Chin-Yen Lee [Fri, 15 May 2026 01:44:28 +0000 (09:44 +0800)]
wifi: rtw89: wow: send ARP reply packets instead of Null packets to keep alive
In WoWLAN mode, the firmware periodically sends Null packets to the AP
to keep the connection alive and prevent the AP from disconnecting the
client due to inactivity. However, it was observed that certain APs,
such as TP-Link Archer BE800, do not recognize Null packets as
valid activity and still drop the connection. Replacing Null packets
with ARP reply packets effectively resolves this compatibility issue
and maintains the connection.
Specifically, while the firmware typically handles standard ARP
offloads by dynamically modifying target IP/MAC fields, these
keep-alive ARP reply packets are pre-filled by the driver with the
DUT's own MAC and IP addresses for both sender and target fields.
In this case, the firmware transmits the packets as-is without
further modification. This approach ensures compatibility with APs
that require valid Layer 3 traffic for activity monitoring while
simplifying the firmware's processing logic during WoWLAN mode.
Dian-Syuan Yang [Fri, 15 May 2026 01:44:24 +0000 (09:44 +0800)]
wifi: rtw89: pci: enable LTR based on pcie control register
Originally, driver always transmits LTR (Latency Tolerance Reporting) to
pcie host, but it may cause pcie link down on some platforms because
LTR is not supported. As a result, driver will check the control
register of LTR setting to decide whether to enable LTR feature.
This applies to Wi-Fi 6 chips only. For Wi-Fi 7 chips, although the
driver still issues LTR, the hardware has its own internal logic
to determine whether to actually transmit it to pcie host.
Zong-Zhe Yang [Fri, 15 May 2026 01:44:23 +0000 (09:44 +0800)]
wifi: rtw89: fw: dump status of H2C command and C2H event for SER
When SER (system error recovery) happens, there may be some handshake
between FW and SW, e.g. SER Level 1. These handshake are based on H2C
commands and C2H events. Dump the status of them to enhance SER debug.
Zong-Zhe Yang [Fri, 15 May 2026 01:44:22 +0000 (09:44 +0800)]
wifi: rtw89: debug: Wi-Fi 7 update simulation of SER L0/L1 by halt H2C command
Wi-Fi 7 FW fixes support of triggering SER L0/L1 simulation via halt H2C
command on v0.35.108.0. After that, the halt H2C command trigger for
Wi-Fi 6 and Wi-Fi 7 can be the same. Update FW feature table and share the
halt H2C command trigger function between Wi-Fi 6 and Wi-Fi 7.
Nicolás Antinori [Sun, 24 May 2026 15:40:16 +0000 (12:40 -0300)]
opp: rust: mark OPP methods as inline
When building the kernel using llvm-19.1.7-rust-1.85.0-x86_64, the
following symbols are generated:
$ nm vmlinux | grep ' _R'.*OPP | rustfilt ffffffff81801560 T <kernel::opp::OPP>::freq ffffffff81801540 T <kernel::opp::OPP as kernel::sync::aref::AlwaysRefCounted>::dec_ref ffffffff81801520 T <kernel::opp::OPP as kernel::sync::aref::AlwaysRefCounted>::inc_ref
However, these Rust symbols are trivial wrappers around the
`dev_pm_opp_get`, `dev_pm_opp_put` and `dev_pm_opp_get_freq_indexed`
functions. It doesn't make sense to go through a trivial wrapper for
these functions.
After applying this patch, the above command will produce no output.
The register address was already validated for read operations in
regmap_sunxi_rsb_reg_read before being truncated to a u8. Write operations
have the same set of possible addresses, and the address is being truncated
from u32 to u8 here as well, so the same check is needed.
Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Andrey Skvortsov <andrej.skvortzov@gmail.com> Fixes: d787dcdb9c8f ("bus: sunxi-rsb: Add driver for Allwinner Reduced Serial Bus") Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20260301144939.1832806-1-andrej.skvortzov@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
Mark Brown [Sun, 24 May 2026 22:35:39 +0000 (23:35 +0100)]
regulator: add support for SGM3804 Dual Output driver
Neil Armstrong <neil.armstrong@linaro.org> says:
Add support for the SG Micro SGM3804 Single Inductor Dual Output
Buck/Boost Converter used to power LCD panels a provide positive
and negative power rails with configurable voltage and active
discharge function for each output.
The SGM3804 is powered by the enable GPIO pins inputs and only
supports I2C write messages.
In order to add flexibility and simplify the driver, the
regmap cache is enabled and populated with default values
since we can't write registers when the 2 GPIOs are down.
This regulator is used to provide vsn and vsn power to the
Ayaneo Pocket S2 dual-DSI LCD panel.
KancyJoe [Fri, 22 May 2026 13:09:13 +0000 (15:09 +0200)]
regulator: add SGM3804 Dual Output driver
Add support for the SG Micro SGM3804 Single Inductor Dual Output
Buck/Boost Converter used to power LCD panels a provide positive
and negative power rails with configurable voltage and active
discharge function for each output.
The SGM3804 is powered by the enable GPIO pins inputs and only
supports I2C write messages.
In order to add flexibility and simplify the driver, the
regmap cache is enabled and populated with default values
since we can't write registers when the 2 GPIOs are down.
Neil Armstrong [Fri, 22 May 2026 13:09:12 +0000 (15:09 +0200)]
regulator: dt-bindings: document the SGM3804 Dual Output regulator
Document the SG Micro SGM3804 Single Inductor Dual Output Buck/Boost
Converter used to power LCD panels a provide positive and negative
power rails with configurable voltage and active discharge function
for each output.
Thomas Weißschuh [Thu, 21 May 2026 17:31:04 +0000 (19:31 +0200)]
tools/nolibc: add ftruncate()
On architectures with 32-bit longs, call the compat syscall
__NR_ftruncate64. As off_t is 64-bit it must be split into 2 registers.
Unlike llseek() which passes the high and low parts in explicitly named
arguments, the order here is endian independent.
Some architectures (arm, mips, ppc) require this pair of registers to
be aligned to an even register, so add custom _sys_ftruncate64()
wrappers for those.
A test case for ftruncate is added which validates negative length or
invalid fd return the appropriate error, and checks the length is
correct on success.
Co-developed-by: Jordan Richards <jordanrichards@google.com> Signed-off-by: Jordan Richards <jordanrichards@google.com> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Willy Tarreau <w@1wt.eu> Reviewed-by: Daniel Palmer <daniel@thingy.jp> Link: https://patch.msgid.link/20260521-nolibc-ftruncate-v1-3-5384a83b2402@weissschuh.net
Daniel Palmer [Fri, 22 May 2026 09:07:26 +0000 (18:07 +0900)]
tools/nolibc: stackprotector: Avoid stalling program startup if crng is not init yet
We are using the getrandom syscall to get a random seed for the
stack protector canary but we are calling it with no flags which means
it'll block until there is some real randomness to return.
This means that if the crng is not ready yet program startup will
block and if you are unlucky that could be for a long time and
look like the program has crashed.
Even if the call to getrandom does not yield any random data,
we will still initialize the canary.
Fixes: 7188d4637e95 ("tools/nolibc: add support for stack protector") Signed-off-by: Daniel Palmer <daniel@thingy.jp> Acked-by: Willy Tarreau <w@1wt.eu> Link: https://patch.msgid.link/20260522090726.726985-1-daniel@thingy.jp Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
The avx2 lookup routines get the next map index to process passes as a
function argument, but this isn't obvious because it's hidden in the
lookup macro.
Additionally, a recent LLM review pointed out following "bug":
-------------------------------------------------------------
> b = nft_pipapo_avx2_refill(i_ul, &map[i_ul], fill, f->mt, last);
> if (last)
> - return b;
> + ret = b;
>
> if (unlikely(ret == -1))
> ret = b / XSAVE_YMM_SIZE;
Does this change introduce a logic error when last=true and no match is
found? [..]
Should this be changed to an else-if structure instead?
-------------------------------------------------------------
LLM sees a control-flow change, but there is none:
All call sites invoke nft_pipapo_avx2_refill() only when at least one
bit in the map is set, i.e. nft_pipapo_avx2_refill() never returns -1.
Add a runtime debug check that fires if we'd return -1 as additional
documentation and also make the suggested change, code might be easier
to understand this way.
In commit 17a20e09f086 ("netfilter: nft_set: remove one argument from
lookup and update functions") I incorrectly moved the "ret" scope into
the loop.
This has no effect on the correctness, but it can (depending on map sizes)
cause a redundant repeat of an earlier processing step.
Restore the intended 'pass map index' instead of always-0. Note that I
did not see any change in performance numbers, but Stefano correctly
points out that the existing perf test likely lack a sparse intermediate
bitmap (between fields) with a lot of leading zeroes.
parse_dcc() treats data_end as an inclusive end pointer, but its only
caller passes data_limit = ib_ptr + datalen, which points one past the
last valid byte.
The newline search loop iterates while tmp <= data_end, so when no
newline is present, *tmp is read at tmp == data_end, one byte beyond
the region filled by skb_header_pointer().
irc_buffer is kmalloc'd as MAX_SEARCH_SIZE + 1 bytes and datalen is
capped at MAX_SEARCH_SIZE, so the stray read does not fault. The byte
is uninitialized or stale; if it contains an ASCII digit, simple_strtoul
will consume it and produce a wrong DCC IP or port in the conntrack
expectation. The extra allocation byte is also a fragile guard: if the
cap or allocation size changes, this becomes a real out-of-bounds read.
Change the loop and its post-loop check to use strict less-than,
consistent with the caller's exclusive-end convention. Update the
function comment accordingly.
David Carlier [Sat, 11 Apr 2026 18:57:21 +0000 (19:57 +0100)]
netfilter: nfnl_cthelper: apply per-class values when updating policies
When a userspace conntrack helper with multiple expectation classes is
updated via nfnetlink, every class ends up with the first class's
max_expected and timeout values.
nfnl_cthelper_update_policy_all() validates each new policy into the
corresponding slot of the temporary new_policy array, but the second
loop that commits the values into the live helper dereferences
new_policy as a pointer instead of indexing it, so every iteration
reads new_policy[0] regardless of i. An update that changes per-class
values is silently collapsed onto class 0's values with no error
returned to userspace.
Index the temporary array by i in the commit loop so each class gets
its own validated values.
netfilter: nft_set_rbtree: remove dead conditional
net/netfilter/nft_set_rbtree.c:399 __nft_rbtree_insert()
warn: 'removed_end' is not an error pointer
Since commit : 087388278e0f ("netfilter: nf_tables: nft_set_rbtree: fix
spurious insertion failure") __nft_rbtree_insert() can no longer fail
and this condition is always false. Remove it.
Reported-by: Dan Carpenter <error27@gmail.com> Closes: https://lore.kernel.org/netfilter-devel/adjSaolTji0mPgqx@stanley.mountain/ Signed-off-by: Florian Westphal <fw@strlen.de>
Pratham Gupta [Tue, 5 May 2026 05:11:57 +0000 (22:11 -0700)]
netfilter: ctnetlink: use nf_ct_exp_net() in expectation dump
Commit 02a3231b6d82 ("netfilter: nf_conntrack_expect: store netns and zone in expectation")
introduced exp->net so RCU-only expectation paths no longer need to
dereference exp->master for netns lookups.
Commit 3db5647984de ("netfilter: nf_conntrack_expect: skip expectations in other netns via proc")
updated the proc path accordingly, but ctnetlink_exp_dump_table() still
compares against nf_ct_net(exp->master).
Use nf_ct_exp_net(exp) here as well so the netlink dump path matches
the rest of the March 2026 expectation netns/RCU cleanup.
Fixes: 02a3231b6d82 ("netfilter: nf_conntrack_expect: store netns and zone in expectation") Cc: stable@vger.kernel.org Signed-off-by: Pratham Gupta <pratham36gupta@gmail.com> Signed-off-by: Florian Westphal <fw@strlen.de>
netfilter: nf_conncount: use per-rule hash initval
As-is, different netns will use same slots if the key is the same.
OVS uses this infrastructure to limit conntrack counts per zones.
Those can easily overlap. Make them hash to different slots internally.
Netfilter has its own netlink multiplexer, initially only a few
subsystem were using it, most notably conntrack, queue and log,
later in time nf_tables. These days it is the control plane of
preference.
Just remove modular support for this, allow it built-in only.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de> Signed-off-by: Florian Westphal <fw@strlen.de>
Rosen Penev [Mon, 11 May 2026 04:18:12 +0000 (21:18 -0700)]
RDMA/rtrs: Use flexible array for client path stats
Store the client path statistics in the RTRS client path allocation
instead of allocating them separately.
This ties the stats lifetime directly to the path and removes a separate
allocation failure path. Keep freeing the per-CPU stats data separately,
but do not free the embedded stats object from error paths or the stats
kobject release handler.
A bunch of Samsung SoCs are missing the EL2 virtual timer interrupt
despite using ARMv8.1+ CPUs. Add the missing interrupt, except for
those broken designs where the interrupt is documented as not being
wired.
Linus Torvalds [Sun, 24 May 2026 19:50:36 +0000 (12:50 -0700)]
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull kvm fixes from Paolo Bonzini:
"arm64:
- Fix ITS EventID sanitisation when restoring an interrupt
translation table.
- Fix PPI memory leak when failing to initialise a vcpu.
- Correctly return an error when the validation of a hypervisor trace
descriptor fails, and limit this validation to protected mode only.
RISC-V:
- Fix invalid HVA warning in steal-time recording
- Return SBI_ERR_FAILURE to guest upon OOM in pmu_event_info() and
pmu_snapshot_set_shmem()
- Fix NULL pointer dereference in SBI v0.1 SEND_IPI handler
- Fix sign extension of value for MMIO loads
s390:
- Fix bugs in vSIE (nested virtualization) and UCONTROL, caused by
the page table rewrite.
x86:
- Apply erratum #1235 workaround (disable AVIC IPI virtualization) on
Hygon Family 18h, just like on AMD Family 17h.
- When KVM_CAP_X86_APIC_BUS_CYCLES_NS is queried on a specific VM,
return the VM's configured APIC bus frequency instead of the
default. This is less confusing (read: not wrong) and makes it
easier to fill in CPUID information that communicates the APIC bus
frequency to the guest.
Selftests:
- Do not include glibc-internal <bits/endian.h>; it worked by chance
and broke building KVM selftests with musl"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: SVM: Disable AVIC IPI virtualization on Hygon Family 18h (erratum #1235)
KVM: selftests: Verify that KVM returns the configured APIC cycle length
KVM: x86: Return the VM's configured APIC bus frequency when queried
KVM: selftests: elf: Include <endian.h> instead of <bits/endian.h>
KVM: s390: Properly reset zero bit in PGSTE
KVM: s390: vsie: Fix redundant rmap entries
KVM: s390: vsie: Fix unshadowing logic
KVM: s390: Fix leaking kvm_s390_mmu_cache in case of errors
KVM: s390: vsie: Fix memory leak when unshadowing
KVM: arm64: Fix nVHE/pKVM hyp tracing error on invalid desc
KVM: arm64: vgic: Free private_irqs when init fails after allocation
KVM: arm64: vgic-its: Reject restored DTE with out-of-range num_eventid_bits
RISC-V: KVM: Fix sign extension for MMIO loads
RISC-V: KVM: Fix NULL pointer dereference in SBI v0.1 SEND_IPI handler
riscv: kvm: return SBI_ERR_FAILURE for pmu_event_info() when OOM
riscv: kvm: return SBI_ERR_FAILURE for pmu_snapshot_set_shmem() when OOM
RISC-V: KVM: Fix invalid HVA warning in steal-time recording
This occurs because platform_device_alloc() uses pdev->id for the device
ID, which may be PLATFORM_DEVID_NONE (-1) for multiple instances, causing
all instances to attempt registration with the same name.
Fix this by using PLATFORM_DEVID_AUTO instead, which automatically assigns
unique IDs to each device instance, allowing multiple xSPI controllers to
coexist without naming conflicts.
Lad Prabhakar [Fri, 15 May 2026 11:52:01 +0000 (12:52 +0100)]
dt-bindings: memory: renesas,rzg3e-xspi: Add RZ/T2H and RZ/N2H support
Document xSPI controller found on the Renesas RZ/T2H and RZ/N2H SoCs.
The xSPI IP on these SoCs is identical to that found on the RZ/G3E SoC.
The RZ/G3E HW manual (Rev.1.15) references bridge channel 1 and its
bits, however the hardware actually supports only a single bridge
channel (channel 0), matching the RZ/T2H design. The references to
channel 1 and its configuration bits will be corrected in a future
revision of the HW manual.
Update clock/reset constraints to handle the SoC differences.
__io_uring_add_tctx_node() installs the node into ctx->tctx_list (via
io_tctx_install_node(), which does the list_add() under tctx_lock) and
only assigns current->io_uring = tctx afterwards. A task doing its first
io_uring operation on a shared ring therefore has a window in which its
node is already visible on ctx->tctx_list while node->task->io_uring is
still NULL. A concurrent IORING_REGISTER_IOWQ_MAX_WORKERS on the same
ring reads that NULL and dereferences tctx->io_wq:
KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
RIP: io_register_iowq_max_workers io_uring/register.c:423
Publish current->io_uring = tctx before installing the node, so any node
visible on ctx->tctx_list always has a valid task->io_uring.
Linus Torvalds [Sun, 24 May 2026 18:00:45 +0000 (11:00 -0700)]
Merge tag 'x86-urgent-2026-05-24' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Ingo Molnar:
- On SEV guests, handle set_memory_{encrypted,decrypted}() failures
more conservatively by assuming that all affected pages are
unencrypted (Carlos López)
- Disable broadcast TLB flush when PCID is disabled (Tom Lendacky)
- Fix VMX vs. hrtimer_rearm_deferred() regression (Peter Zijlstra)
- Move IRQ/NMI dispatch code from KVM into x86 core, to prepare for a
KVM x2apic fix (Peter Zijlstra)
* tag 'x86-urgent-2026-05-24' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
virt: sev-guest: Explicitly leak pages in unknown state
x86/mm: Disable broadcast TLB flush when PCID is disabled
x86/kvm/vmx: Fix VMX vs hrtimer_rearm_deferred()
x86/kvm/vmx: Move IRQ/NMI dispatch from KVM into x86 core
x86/vdso: Fix incorrect size in munmap() on map_vdso() failure
Linus Torvalds [Sun, 24 May 2026 17:55:21 +0000 (10:55 -0700)]
Merge tag 'irq-urgent-2026-05-24' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull irqchip driver fixes from Ingo Molnar:
- Fix the hardware probing error path of the renesas-rzt2h
irqchip driver
- Fix the exynos-combiner irqchip driver on -rt kernels
by turning the IRQ controller spinlock into a raw spinlock
* tag 'irq-urgent-2026-05-24' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
irqchip/renesas-rzt2h: Use pm_runtime_put_sync() in probe error path
irqchip/exynos-combiner: Switch to raw_spinlock
Linus Torvalds [Sun, 24 May 2026 17:48:55 +0000 (10:48 -0700)]
Merge tag 'core-urgent-2026-05-24' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull debugobjects fix from Ingo Molnar::
- Fix debugobjects regression on -rt kernels: don't fill the pool
(which uses a coarse lock) if ->pi_blocked_on, because that messes up
the priority inheritance of callers
* tag 'core-urgent-2026-05-24' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
debugobjects: Do not fill_pool() if pi_blocked_on
Linus Torvalds [Sun, 24 May 2026 17:37:55 +0000 (10:37 -0700)]
Merge tag 'hwmon-for-v7.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
Pull hwmon fixes from Guenter Roeck:
- adm1266: Various fixes from Abdurrahman Hussain
The fixed issues were reported by Sashiko as part of a code review of
a functional change in the driver.
- lenovo-ec-sensors: Convert to devm_request_region() to fix
release_region cleanup, and fix EC "MCHP" signature validation logic,
from Kean Ren
* tag 'hwmon-for-v7.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
hwmon: (pmbus/adm1266) serialize sequencer_state debugfs read with pmbus_lock
hwmon: (pmbus/adm1266) serialize NVMEM blackbox read with pmbus_lock
hwmon: (pmbus/adm1266) serialize GPIO PMBus accesses with pmbus_lock
hwmon: (pmbus/adm1266) register the nvmem device after pmbus_do_probe()
hwmon: (pmbus/adm1266) register the gpio_chip after pmbus_do_probe()
hwmon: (pmbus/adm1266) reject short block-read responses in the GPIO accessors
hwmon: (pmbus/adm1266) don't clobber GPIO bits before PDIO read in get_multiple
hwmon: (pmbus/adm1266) cap PDIO scan in get_multiple at ADM1266_PDIO_NR
hwmon: (pmbus/adm1266) bounce blackbox records through a protocol-sized buffer
hwmon: (pmbus/adm1266) include adapter number in GPIO line label
hwmon: (pmbus/adm1266) include PEC byte in pmbus_block_xfer read buffer
hwmon: (pmbus/adm1266) reject implausible blackbox record_count
hwmon: (pmbus/adm1266) widen blackbox-info buffer to I2C_SMBUS_BLOCK_MAX
hwmon: (pmbus/adm1266) seed timestamp from the real-time clock
hwmon: (lenovo-ec-sensors): Fix EC "MCHP" signature validation logic
hwmon: (lenovo-ec-sensors): Convert to devm_request_region()
drm/msm: Restore second parameter name in purge() and evict()
After commit 3392291fc509 ("drm/msm: Fix shrinker deadlock"), all
supported versions of clang warn (or error with CONFIG_WERROR=y):
drivers/gpu/drm/msm/msm_gem_shrinker.c:105:58: error: omitting the parameter name in a function definition is a C23 extension [-Werror,-Wc23-extensions]
105 | purge(struct drm_gem_object *obj, struct ww_acquire_ctx *)
| ^
drivers/gpu/drm/msm/msm_gem_shrinker.c:117:58: error: omitting the parameter name in a function definition is a C23 extension [-Werror,-Wc23-extensions]
117 | evict(struct drm_gem_object *obj, struct ww_acquire_ctx *)
| ^
2 errors generated.
With older but supported versions of GCC, this is an unconditional hard error:
drivers/gpu/drm/msm/msm_gem_shrinker.c: In function 'purge':
drivers/gpu/drm/msm/msm_gem_shrinker.c:105:35: error: parameter name omitted
purge(struct drm_gem_object *obj, struct ww_acquire_ctx *)
^~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/msm/msm_gem_shrinker.c: In function 'evict':
drivers/gpu/drm/msm/msm_gem_shrinker.c:117:35: error: parameter name omitted
evict(struct drm_gem_object *obj, struct ww_acquire_ctx *)
^~~~~~~~~~~~~~~~~~~~~~~
Restore the parameter name to clear up the warnings, renaming it
"unused" to make it clear it is only needed to satisfy the prototype of
drm_gem_lru_scan().
Linus Torvalds [Sun, 24 May 2026 16:53:17 +0000 (09:53 -0700)]
Merge tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf
Pull bpf fixes from Alexei Starovoitov:
- Fix bpf_throw() and global subprog combination (Kumar Kartikeya
Dwivedi)
- Fix out of bounds access in BPF interpreter (Yazhou Tang)
- Fix potential out of bounds access in inner per-cpu array map
(Guannan Wang)
- Reject NULL data/sig in bpf_verify_pkcs7_signature (KP Singh)
* tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf:
libbpf: fix off-by-one in emit_signature_match jump offset
bpf: Reject NULL data/sig in bpf_verify_pkcs7_signature
selftests/bpf: Cover global subprog exception leaks
bpf: Check global subprog exception paths
bpf: make bpf_session_is_return() reference optional
bpf: Use array_map_meta_equal for percpu array inner map replacement
selftests/bpf: Add test for large offset bpf-to-bpf call
bpf: Fix s16 truncation for large bpf-to-bpf call offsets
bpf: Fix out-of-bounds read in bpf_patch_call_args()
The driver supports a new comp_mask: REQ_MASK_FIXED_QUE_ATTR.
The application sets this comp_mask bit in the CREATE_QP ureq
to indicate direct control of the QP. The driver goes through
the required processing for app allocated QPs (previous patches).
Only variable WQE mode is supported for these QPs.
This patch removes an unused comp_mask:
BNXT_RE_QP_REQ_MASK_VAR_WQE_SQ_SLOTS
RDMA/bnxt_re: Support doorbells for app allocated QPs
App allocated QPs can use a separate doorbell for each QP.
This doorbell region can be passed through a new driver specific
DBR_HANDLE attribute, during QP creation. When this attribute
is set, associate the QP with the given doorbell region.
While the QP holds a reference to the dbr, the dbr itself
cannot be destroyed and is rejected with EBUSY error.
RDMA/bnxt_re: Enhance dpi lifecycle logic in doorbell uapis
If the DPI is freed when the dbr object is freed, but if the
process has not unmapped the page yet, then the DPI slot could
get reallocated to another process while the original process
still has it mapped. To prevent this, save the DPI info in the
mmap entry during dbr allocation and free the DPI slot from
bnxt_re_mmap_free(), which enures that there are no references
to it.
This change is needed to support doorbell allocation to QPs
in the next patch.
RDMA/bnxt_re: Enhance dbr usecnt logic in doorbell uapis
The current logic in the doorbell cleanup function is not
sufficient for a change in a subsequent patch, that fails
doorbell remove operation in some conditions. The cleanup
should facilitate freeing of the dbr object when the caller
may not retry the teardown operation (implicit teardown:
process-exit/driver-removal).
Extend this counter to use kref mechanism so that the dbr
object gets freed (via kref callback) when there are no more
references to it, rather than directly freeing it in the
cleanup uapi.
RDMA/bnxt_re: Update msn table size for app allocated QPs
For app allocated QPs, the driver shouldn't use slots/round-up logic
to compute the msn table size. The application handles this logic
and computes 'sq_npsn' and passes it to the driver using a new uapi
parameter.
The umem changes for CQ added a helper - bnxt_re_setup_sginfo().
Use the same helper for QP creation since we support only 4K
pages for QP ring memory too.
Add a new helper function bnxt_re_get_psn_bytes() to improve
readability as this code will be updated in subsequent patches.
projects / thirdparty / kernel / linux.git / log
