If hbg_dma_map() fails, hbg_net_start_xmit() frees the skb, but buffer->skb
is left pointing to it. ring->ntu is not advanced, so the buffer is not
visible to the TX cleanup path.
A subsequent transmit normally overwrites the buffer. However, if the
interface is brought down first, hbg_ring_uninit() calls hbg_buffer_free().
It sees the stale pointer, attempts to unmap the failed mapping, and frees
the skb again.
Clear buffer->skb before freeing the skb in the error path, preventing
hbg_buffer_free() from treating it as an outstanding TX buffer.
Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Reviewed-by: Jijie Shao <shaojijie@huawei.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260710090527.58354-4-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
It is unnecessary to allocate continuous physical memory for cache
buffer, and when ebpf program is too large, it may cause memory
allocation failure.
Signed-off-by: Pu Lehui <pulehui@huawei.com>
Reviewed-by: Björn Töpel <bjorn@kernel.org>
Acked-by: Björn Töpel <bjorn@kernel.org>
Link: https://lore.kernel.org/bpf/20260708064436.2971933-4-pulehui@huaweicloud.com
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
When bpf_int_jit_compile() is called for subprograms, it returns early
during the first pass (!prog->is_func || extra_pass is false), keeping
ctx->offset alive for the subsequent extra pass.
If JIT compilation fails for a later subprogram, the BPF core aborts
and calls bpf_jit_free() to clean up the first subprogram. However,
bpf_jit_free() fails to free jit_data->ctx.offset, which causes a
memory leak of the JIT context offsets array.
Fix this by adding the missing kfree(jit_data->ctx.offset) in
bpf_jit_free().
Fixes: 48a8f78c50 ("bpf, riscv: use prog pack allocator in the BPF JIT")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Pu Lehui <pulehui@huawei.com>
Reviewed-by: Björn Töpel <bjorn@kernel.org>
Acked-by: Björn Töpel <bjorn@kernel.org>
Link: https://lore.kernel.org/bpf/20260708064436.2971933-3-pulehui@huaweicloud.com
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Marco Giunta <marco_giunta@outlook.it> says:
Several Lenovo Legion laptops (Pro 7i 16IAX10H, Y9000P IAX10,
Pro 7 16AFR10H, R9000P ADR10) use AWINIC AW88399 smart amplifiers
to drive their bass woofers, connected via I2C as side codecs
to a Realtek ALC287 HDA codec.
Without a driver for these amplifiers, only the tweeters produce
sound, resulting in quiet and tinny audio.
An ASoC driver for the AW88399 already exists in-tree
(sound/soc/codecs/aw88399.c), contributed by AWINIC, but it targets
ASoC topologies and cannot drive the chip when it sits behind an
HDA controller. This series adds a proper HDA side codec driver,
following the established pattern used by the CS35L41, CS35L56,
and TAS2781 drivers.
Patch 1 extracts the device-level functions from the existing ASoC
driver into a shared library module (SND_SOC_AW88399_LIB) with a
shared header at include/sound/aw88399.h, following the CS35L41
precedent (SND_SOC_CS35L41_LIB / include/sound/cs35l41.h). This
avoids a build-time dependency on the full ASoC codec module and
ensures clean separation between the ASoC and HDA drivers.
Patches 2 through 5 prepare the shared library for use on ACPI-based
HDA systems: patch 2 extends channel assignment to work without
Device Tree properties, patch 3 adds a per-instance flag to bypass
an unreliable hardware status bit on certain boards, patch 4 adds
a firmware reload flag so that the HDA driver can signal that DSP
firmware needs to be re-uploaded after system sleep, and patch 5
adds a channel setter so that the HDA driver can configure the
amplifier without depending on ASoC-internal device headers.
NOTE ON FIRMWARE: This driver requires the firmware file
aw88399_acf.bin, which uses the same format and request path as the
existing ASoC driver. This firmware is not yet available in the
linux-firmware repository. We intend to coordinate with the AWINIC
maintainers (CC'd) to arrange its inclusion. In the meantime, users
can extract the firmware from the Windows driver and place it in
/lib/firmware/.
This work builds on the initial driver development by Yakov Till
("Lyapsus") and the bounty effort organized by Nadim Kobeissi:
https://github.com/nadimkobeissi/16iax10h-linux-sound-saga
Link: https://patch.msgid.link/DS7PR19MB77247D9AD698CF0FF37DB58BFCC62@DS7PR19MB7724.namprd19.prod.outlook.com
If hinic3_tx_map_skb() fails in hinic3_send_one_skb(), the skb is freed,
but tx_info->skb was set before the mapping attempt and is not cleared. The
SQ producer index is rolled back, so later transmissions normally overwrite
the entry.
If the interface is brought down first, hinic3_free_txqs_res() calls
free_all_tx_skbs(). It scans the entire tx_info array and finds the stale
pointer. hinic3_tx_unmap_skb() then dereferences the freed skb in
skb_shinfo(), before it is freed again.
Set tx_info->skb and its WQEBB count only after DMA mapping succeeds,
preventing the stale pointer from reaching free_all_tx_skbs().
Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Reviewed-by: Fan Gong <gongfan1@huawei.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260710090527.58354-3-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
If dma_map_single() fails in bnad_start_xmit(), the skb is freed, but
head_unmap->skb was set before the mapping attempt and is not cleared. The
producer index is not advanced, so later transmissions normally overwrite
the entry.
However, if the interface is brought down first, bnad_txq_cleanup() scans
the entire unmap queue, finds the stale pointer, and calls
bnad_tx_buff_unmap() on it. That function dereferences the freed skb in
skb_headlen(). Its zero nvecs count is decremented to -1, causing its
while (nvecs) loop to repeatedly unmap entries around the TX ring and
potentially hang cleanup.
Set head_unmap->skb after the first DMA mapping succeeds. This prevents the
stale entry from reaching bnad_tx_buff_unmap().
Cc: stable+noautosel@kernel.org # untested fix to unlikely error path
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260710090527.58354-2-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Extract the is_struct_ops_tramp helper, and use it in riscv
as the current checks are somewhat hacky.
Signed-off-by: Pu Lehui <pulehui@huawei.com>
Reviewed-by: Björn Töpel <bjorn@kernel.org>
Acked-by: Björn Töpel <bjorn@kernel.org>
Link: https://lore.kernel.org/bpf/20260708064436.2971933-2-pulehui@huaweicloud.com
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Add aw88399_dev_set_channel() to the shared library so that the HDA side
codec driver can set the amplifier's channel assignment without
including the aw88395 device header directly.
The AW88399's struct aw_device is defined in aw88395_device.h, which
lives under sound/soc/codecs/aw88395/. Without this accessor, the
HDA driver would need a cross-subsystem relative include path to
access the channel field. Providing a setter in the library keeps the
interface clean and avoids coupling the HDA driver to ASoC-internal
headers.
Tested-by: Nadim Kobeissi <nadim@symbolic.software>
Tested-by: Xia Yun'an <imitoy@imitoy.top>
Tested-by: Munzir Taha <munzirtaha@gmail.com>
Signed-off-by: Marco Giunta <marco_giunta@outlook.it>
Link: https://patch.msgid.link/DS7PR19MB7724E8A1AD36D1E623FA2A0AFCC62@DS7PR19MB7724.namprd19.prod.outlook.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add a fw_needs_reload flag to struct aw88399 that, when set, causes
aw88399_start to perform a full DSP firmware upload instead of
assuming the firmware binary is already present in memory.
After system sleep, the AW88399 loses its memory contents. The
existing start sequence assumes the firmware binary persists from
initialization and only uploads register configuration and DSP
config (AW88399_DSP_FW_UPDATE_OFF). When memory is empty, this causes
the subsequent CRC check to fail, triggering the retry mechanism in
aw88399_start_pa which re-uploads the firmware on the second
attempt.
While the retry mechanism recovers correctly, it produces
misleading error-level log messages on every resume cycle. The
fw_needs_reload flag allows the HDA side codec driver to signal
that a full firmware reload is needed after resume, eliminating
the spurious CRC failures.
The flag defaults to false via kzalloc, preserving the original
behavior for existing ASoC users. No existing code path sets this
flag; it will be set by the HDA side codec driver's system suspend
handler.
Tested-by: Nadim Kobeissi <nadim@symbolic.software>
Tested-by: Xia Yun'an <imitoy@imitoy.top>
Tested-by: Munzir Taha <munzirtaha@gmail.com>
Signed-off-by: Marco Giunta <marco_giunta@outlook.it>
Link: https://patch.msgid.link/DS7PR19MB77240CB79188C0B7AE243829FCC62@DS7PR19MB7724.namprd19.prod.outlook.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add a bsts_unreliable flag to struct aw88399 that, when set, causes
the startup status check (aw_dev_check_sysst) to skip the BSTS
(boost startup finished) requirement.
On some hardware, the BSTS bit in the SYSST register (0x01, bit 9)
does not reliably assert even during normal audio playback. Register
inspection on affected Lenovo Legion hardware shows both amplifiers
reporting BSTS=0 on both channels despite clean audio output.
Per the AW88399 datasheet, BSTS indicates boost startup completion.
If BSTS never reliably sets to 1, the chip is never allowed to start
by aw_dev_check_sysst, regardless of whether the boot failure is genuine.
The new flag defaults to false via kzalloc, preserving the original check
behavior for all existing users. No existing code path sets this flag;
it will be set by the forthcoming HDA side codec property driver for
affected hardware.
Tested-by: Nadim Kobeissi <nadim@symbolic.software>
Tested-by: Xia Yun'an <imitoy@imitoy.top>
Tested-by: Munzir Taha <munzirtaha@gmail.com>
Signed-off-by: Marco Giunta <marco_giunta@outlook.it>
Link: https://patch.msgid.link/DS7PR19MB77242B8E5BB8BFB5E69816E9FCC62@DS7PR19MB7724.namprd19.prod.outlook.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Extend aw88399_parse_channel_dt to derive the audio channel from the
I2C address when the Device Tree property "awinic,audio-channel" is
absent.
The original code calls of_property_read_u32 without checking the
return value. On ACPI systems, the DT property is never present,
and channel_value is used uninitialized in the assignment to
aw_dev->channel.
Add a fallback that computes the channel as (i2c_addr - 0x34), where
0x34 is the AW88399's base I2C address per the datasheet (valid range
0x34-0x37). This channel assignment may be subsequently overridden by
the HDA side codec's property driver on systems that require it.
No change on Device Tree systems where the property is present.
Tested-by: Nadim Kobeissi <nadim@symbolic.software>
Tested-by: Xia Yun'an <imitoy@imitoy.top>
Tested-by: Munzir Taha <munzirtaha@gmail.com>
Co-developed-by: Yakov Till <yakov.till@gmail.com>
Signed-off-by: Yakov Till <yakov.till@gmail.com>
Signed-off-by: Marco Giunta <marco_giunta@outlook.it>
Link: https://patch.msgid.link/DS7PR19MB772468BB9F4D6925DC4E8E3EFCC62@DS7PR19MB7724.namprd19.prod.outlook.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Extract the device-level functions from aw88399.c into a new shared
library module (aw88399-lib.c) with a shared header at
include/sound/aw88399.h, following the pattern established by CS35L41
(cs35l41-lib.c / include/sound/cs35l41.h) for chips that need both
ASoC and HDA drivers.
The shared header at include/sound/aw88399.h contains the register
definitions, bit-field masks, hardware constants, device enums, the
struct aw88399 definition, and the library function declarations.
The ASoC-private header at sound/soc/codecs/aw88399.h is reduced to
ASoC-specific definitions (PCM formats/rates, ALSA kcontrol helpers,
calibration constants) and includes the shared header.
The library contains the chip initialization, firmware loading,
playback start/stop sequences, and all their internal dependencies
(PLL checks, DSP management, volume control, calibration, CRC
verification, etc.). The ASoC codec driver retains the ALSA controls,
DAPM widgets, codec probe/remove, calibration service, and I2C bus
driver registration.
A new Kconfig symbol SND_SOC_AW88399_LIB is introduced.
SND_SOC_AW88399 (the existing ASoC codec) selects it, ensuring no
change for current users. The HDA side codec driver (introduced
later in this series) selects the library without pulling in the
full ASoC codec module. This avoids a build-time dependency on the
full ASoC driver and follows the established pattern used by CS35L41
(SND_SOC_CS35L41_LIB) for chips with both ASoC and HDA drivers.
Some library functions (DSP control, volume setting, mute,
calibration updates, profile management, and status helpers) are
used internally by the library's start/stop sequences but are also
called directly by the ASoC driver's remaining code.
These are exported from the library so the ASoC module can access them.
This is a pure code movement with no functional changes. The moved
functions are identical to their originals in aw88399.c.
Tested-by: Nadim Kobeissi <nadim@symbolic.software>
Tested-by: Xia Yun'an <imitoy@imitoy.top>
Tested-by: Munzir Taha <munzirtaha@gmail.com>
Signed-off-by: Marco Giunta <marco_giunta@outlook.it>
Link: https://patch.msgid.link/DS7PR19MB772415C485FAF74297673FD7FCC62@DS7PR19MB7724.namprd19.prod.outlook.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Make sure to drop the reference taken to the buffer manager device when
attempting to look up its driver data before the driver has been bound.
Note that holding a reference to a device does not prevent its driver
data from going away.
Cc: stable+noautosel@kernel.org # untested fix to unlikely error path
Cc: Gregory CLEMENT <gregory.clement@bootlin.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com>
Link: https://patch.msgid.link/20260709082713.829446-1-johan@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
mptcp_get_options() clears only the status group of struct
mptcp_options_received; data_seq, subflow_seq and data_len are filled in
by mptcp_parse_option() exclusively inside the DSS mapping block, which
runs only when the DSS M (mapping present) bit is set.
A peer can send a DSS option with the DATA_FIN flag set but the mapping
bit clear. The parser then records mp_opt->data_fin while leaving
data_len and data_seq uninitialized. For a zero-length segment
mptcp_incoming_options() evaluates
if (mp_opt.data_fin && mp_opt.data_len == 1 &&
mptcp_update_rcv_data_fin(msk, mp_opt.data_seq, mp_opt.dsn64))
which reads the uninitialized data_len and data_seq; KMSAN reports an
uninit-value in mptcp_incoming_options(). The stale data_seq can also be
fed into the receive-side DATA_FIN sequence tracking.
Record the DATA_FIN flag only when the DSS option carries a mapping, so
data_fin is never set without data_seq and data_len also being present.
data_fin is part of the status group that mptcp_get_options() clears up
front, so on the no-map path it stays zero and the zero-length DATA_FIN
branch is simply skipped. A DATA_FIN is always transmitted together with
a mapping (mptcp_write_data_fin() sets use_map along with data_seq and
data_len), so legitimate DATA_FIN handling is unaffected.
Move the pr_debug() that logs the parsed DSS flags below the mapping
block, so it reports the final data_fin value instead of the stale one
it would otherwise print before the assignment.
Fixes: 43b54c6ee3 ("mptcp: Use full MPTCP-level disconnect state machine")
Suggested-by: Paolo Abeni <pabeni@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260709191925.2811195-1-michael.bommarito@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> says:
I will post Card capsuling patch.
To makes its review easy, tidyup meson drivers to reduce
un-related diff as preparation.
No functional change, but is preparation for cleanup driver.
Link: https://patch.msgid.link/87qzkxi0j5.wl-kuninori.morimoto.gx@renesas.com
storm_parse_of() can be processed without using *card.
No functional change, but is preparation for Card capsuling.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/87mrvli0hx.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
It is not used. Let's remove.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://patch.msgid.link/87o6g1i0i6.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
qcom_snd_parse_of() already have dev. Let's use it.
No functional change, but is preparation for Card capsuling.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/87pl0hi0il.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> says:
I will post Card capsuling patch.
To makes its review easy, tidyup its drivers to reduce
un-related diff as preparation.
No functional change, but is preparation for cleanup driver.
Link: https://patch.msgid.link/87bjc1i05a.wl-kuninori.morimoto.gx@renesas.com
acp-sdw-sof-mach.c will be updated when Card capsuling.
To makes its review easy, use &pdev->dev instead of card->dev in mc_probe().
There is no diff, because
static int mc_probe(...)
{
...
card->dev = &pdev->dev;
...
}
No functional change, but is preparation for cleanup driver.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Link: https://patch.msgid.link/878q75i04q.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
acp-sdw-legacy-mach.c will be updated when Card capsuling.
To makes its review easy, use &pdev->dev instead of card->dev in mc_probe().
There is no diff, because
static int mc_probe(...)
{
...
card->dev = &pdev->dev;
...
}
No functional change, but is preparation for cleanup driver.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Link: https://patch.msgid.link/87a4rli04u.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Register OVS_KEY_ATTR_ICMPV6 in the flow key parser so that
icmpv6(type=...) can be used in flow specifications. Without this
registration the parser silently drops the token and the kernel
rejects the flow with EINVAL because the expected ICMPv6 key
attribute is missing.
While here, add convert_int() to the ovs_key_ipv6 and ovs_key_icmp
fields_map entries so that specifying a field value produces the
correct wildcard mask. The IPv6 flow label uses convert_int(20) to
produce a 20-bit mask (0x000FFFFF), matching the kernel constraint in
flow_netlink.c that rejects masks with bits 20-31 set; byte-wide
fields use convert_int(8). The ipv4 counterpart already does this via
convert_int(); the ipv6 and icmp classes were simply missing the fifth
tuple element. Existing callers that pass empty parentheses are
unaffected because convert_int("") returns (0, 0).
Add test_icmpv6 exercising the ICMPv6 echo flow key. The test uses
static neighbour entries with nud permanent to prevent racy NDP, then
verifies in three steps: install icmpv6(type=128) and
icmpv6(type=129) flows and confirm ping works, remove the flows and
confirm ping fails, reinstall and confirm recovery.
Signed-off-by: Minxi Hou <houminxi@gmail.com>
Reviewed-by: Aaron Conole <aconole@redhat.com>
Link: https://patch.msgid.link/20260709120541.3556748-1-houminxi@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Convert Texas Instruments TPS51632 Voltage regulators from legacy text
to DT schema. No functional changes are introduced.
Signed-off-by: Bhargav Joshi <j.bhargav.u@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260717-ti-regulator-tp-v1-1-a49d41dc56d3@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Convert the TI OMAP4+ dmic bindings from txt to DT schema.
Following changes are introduced during converson:
- Drop ti,hwmods property as it is not needed since the sysc
conversion no existing DTS uses it.
- Add dma, dma-names, reg-names properties to match the DTS.
- Update example node to match existing DTS.
Signed-off-by: Bhargav Joshi <j.bhargav.u@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260713-ti-omap4-dmic-v1-1-3cc6e13decec@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
kvm_vgic_global_state.ich_vtr_el2 is the last bit of caching that
we can get rid of. Not as bad as a sysreg access, but still worse
than a constant.
Move over to the inlined stuff and remove the cached value.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://patch.msgid.link/20260721170754.3150521-7-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
Now that we have our magic inline helper for ICH_VTR_EL2, we can
get rid of the hack that was reporting a combination of that
register and of the indication of the CPU interface supporting
GICv2 compatibility. We now only report the latter.
As a small benefit, GICv5 is not involved in this stuff anymore,
since it never has GICv2 compatibility..
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://patch.msgid.link/20260721170754.3150521-6-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
Now that we have a new helper that inlines the value of ICH_VTR_EL2
into the code, use this to replace most of the sysreg accesses to
that register.
This avoids a lot of traps when running KVM under NV.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://patch.msgid.link/20260721170754.3150521-5-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
We already have two ways to deal with ICH_VTR_EL2:
- directly read the system register
- read a cached copy in the vgic global state
Add a third way, in the form of an inlined literal value that will
eventually replace all of the above. This literal value is computed
at boot time, and patched in the relevant code locations.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://patch.msgid.link/20260721170754.3150521-4-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
Using is_midr_in_range_list() in a noinstr function isn't a good idea.
And yet kvm_compute_ich_hcr_trap_bits() is doing that by calling
vgic_v3_broken_seis().
Move all the broken SEIS detection logic to the errata detection
framework, and use a new ARM64_WORKAROUND_GICv3_BROKEN_SEIS cap
to indicate that we're running on broken CPUs.
This reuses the MIDR list used for IMPDEF PMU detection, which
has a 100% overlap with the SEIS stuff...
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://patch.msgid.link/20260721170754.3150521-3-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
vgic-v3-sr.c still contains some hardcoded constants for some of
the ICH)VTR_EL2 fields. Bring them into the modern world by using
the named symbols from the sysreg file.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://patch.msgid.link/20260721170754.3150521-2-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
attach_probe/uprobe-lib and uprobe_autoattach selftests fail with "failed
to resolve full path for libc.so.6" on older non-usrmerged distros, where
libc.so.6 lives under a top-level /lib64 or /lib rather than /usr/lib64 or
/usr/lib. Add /lib64:/lib to the search paths, alongside the existing
/usr/lib64:/usr/lib and Debian multiarch entries.
Fixes: 1ce3a60e3c ("libbpf: auto-resolve programs/libraries when necessary for uprobes")
Signed-off-by: Ricardo B. Marlière <rbm@suse.com>
Acked-by: Ihor Solodrai <ihor.solodrai@linux.dev>
Link: https://lore.kernel.org/bpf/20260720-selftests-bpf_fixes-v2-3-b450eda93dfe@suse.com
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
progs/lsm_bdev.c keys its verity_devices hashmap with the raw kernel dev_t
read straight off bdev->bd_dev, i.e. MKDEV(major, minor) = (major << 20) |
minor. prog_tests/lsm_bdev.c instead builds its lookup key with dev_key =
(__u32)st.st_rdev from stat(2), but the stat(2) syscall fills st_rdev via
the kernel's new_encode_dev(), a different bit layout: (minor & 0xff) |
(major << 8) | ((minor & ~0xff) << 12).
For any device with a non-trivial major these two values differ, so the
lookup can never find what the BPF program stored, and test_lsm_bdev()
always fails with:
test_lsm_bdev:FAIL:map lookup unexpected error: -2 (errno 2)
Reconstruct the raw kernel dev_t from the decoded major/minor instead of
casting st_rdev directly, restoring the layout the BPF program actually
reads.
Fixes: 96f4c251a0 ("selftests/bpf: add block device management selftests")
Signed-off-by: Ricardo B. Marlière <rbm@suse.com>
Acked-by: Ihor Solodrai <ihor.solodrai@linux.dev>
Link: https://lore.kernel.org/bpf/20260720-selftests-bpf_fixes-v2-2-b450eda93dfe@suse.com
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
After "make install", test_progs fails because two files end up in the
wrong place:
- bpftool: TEST_GEN_PROGS_EXTENDED flattens it into $(INSTALL_PATH), losing
the tools/sbin/ prefix that detect_bpftool_path() expects. Remove it from
TEST_GEN_PROGS_EXTENDED and install it explicitly under tools/sbin/
instead.
- *.BTF: resolve_btfids writes resolve_btfids.test.o.BTF as a side-effect
of the build but INSTALL_RULE never copies it over. Install all *.BTF
files alongside the rest of the per-flavor output.
Fixes: f21fae5774 ("selftests/bpf: Add a few helpers for bpftool testing")
Fixes: 522397d05e ("resolve_btfids: Change in-place update with raw binary output")
Signed-off-by: Ricardo B. Marlière <rbm@suse.com>
Acked-by: Ihor Solodrai <ihor.solodrai@linux.dev>
Link: https://lore.kernel.org/bpf/20260720-selftests-bpf_fixes-v2-1-b450eda93dfe@suse.com
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Make sure the IPv4/6 and UDP headers are writable before fixing them up in
geneve_post_decap_hint. As skb_ensure_writable can reallocate the skb linear
area, reload the GRO hint header pointer and only set the IPv4/6 header ones
after the call.
Fixes: fd0dd79657 ("geneve: use GRO hint option in the RX path")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260529144713.780938-1-atenart%40kernel.org
Signed-off-by: Antoine Tenart <atenart@kernel.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260709125000.141092-1-atenart@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The function was reading reason_code from the frame before validating
that the frame is at least IEEE80211_DEAUTH_FRAME_LEN bytes long.
Move the reason_code read to after the length check so the field is
guaranteed to be present before it is accessed.
Signed-off-by: Shahar Tzarfati <shahar.tzarfati@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715212706.db26604650bd.I2caa73c396b8c9d357224b9334d5df3cafac498e@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Currently, we accept per-STA GTK for any interface type
if the IBSS_RSN flag is set, which doesn't make sense,
and also accept various key indices that aren't really
(meant to be) supported, such as IGTK/BIGTK on IBSS or
AP_VLAN etc.
For MESH and NAN_DATA interface types, per-STA GTKs are
required, so their support shouldn't depend on IBSS_RSN.
Conversely a driver setting IBSS_RSN doesn't really say
it also accepts per-STA GTK for other interface types.
Move more checks into cfg80211_valid_key_idx() and make
them more precise:
- allow IGTK and, if supported, BIGTK for NAN
- allow per-STA (RX) GTK only for
- NAN_DATA
- IBSS if IBSS_RSN is supported
- MESH
- allow B/I/GTK for station/P2P-client without mac_addr
for RX with the current AP (historic API quirk),
subject to support
- allow TX GTK for AP/P2P-GO/AP_VLAN
- allow TX IGTK/BIGTK for AP/P2P-GO subject to support
Other settings are rejected, clearing up corner cases
and disallowing unexpected settings.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715212403.725e6b63e890.I24684374112bb94d0633d61ef76ecb8a1517f7f1@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The previous change from John Walker fixed the loop iteration,
but the code is written in a bad way. Pass the pointers needed
for the iteration to the function instead.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715211048.04877081fd0a.I48f0135ba83dcc5f0b736b61f8f9e86ecc72583f@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The spec originally had the idea that the fact that it's
a beacon frame determines the (non-)presence of the values,
but added presence bits in D1.4. Use those presence bits in
addition to the enable bits.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715210407.3b1a79b0d002.Iaa762c55b4b6dc63d55f2d7b8b42acd47e640d50@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The spec says to include it if the STA is "capable of operating
as STA 6G", which is a bit unclear because this is defined at a
STA level and not at the MLD level or so, but WFA requires this
to be included. Either way, the element is completely advisory
and intended mostly for debugging (and perhaps a bit steering),
so just include it in association request all the time if 6 GHz
is supported.
To determine what exactly to include, check all the channels
that aren't disabled. That way, it ends up being a lowest
common denominator, which is most useful for steering etc.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715210322.02a4f3fced21.I94bbd08ac38001e11d5143a8b3f54dcea8ae8e15@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Pre-authentication frames (ETH_P_PREAUTH, 0x88C7) are sent before
the authentication handshake completes with the target AP, so no
encryption key exists for them yet. Unlike normal EAPOL frames
(ETH_P_8021X, 0x888E) which are registered as the control port
protocol, pre-auth frames are not recognized as control port frames,
causing the kernel to incorrectly assign the current AP's key and
attempt encryption, resulting in a WARN_ON in ieee80211_encrypt_tx_skb
when the cipher is not handled.
Fix this by setting IEEE80211_TX_INTFL_DONT_ENCRYPT for pre-auth
frames in ieee80211_tx_h_check_control_port_protocol(), so that
key selection skips them and they are sent unencrypted as intended.
Note that the only driver hitting this path is hwsim.
Reported-by: syzbot+b6ce23950fd636e6efb6@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=b6ce23950fd636e6efb6
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
Link: https://patch.msgid.link/20260713015946.44636-1-kartikey406@gmail.com
[add note about hwsim, fix subject]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Lachlan Hodges says:
====================
Introduce mm81x driver for mm81x based chipsets plus associated
SDIO ids.
====================
[list the full vendor directory in MAINTAINERS]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Commit d87773de9e ("clocksource/drivers/arm_arch_timer: Default to EL2
virtual timer when running VHE") causes boot to hang on Raspberry Pi 5.
The newly-selected EL2 virtual timer does not generate any interrupts,
even though the GIC_DIST_ENABLE_SET flag has been confirmed set via
readback.
It is highly unusual that this timer interrupt is non-operational because
this is a standard GIC interrupt corresponding to a standard Cortex-A76
CPU timer. However, Broadcom have confirmed for this SoC:
> the interrupt line was never connected in the first place as this was
> not identified as being a requirement
Remove the corresponding DeviceTree entry.
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Closes: https://lore.kernel.org/all/ea15cce1-b393-43f6-8d58-3d6f90f0c0cd@samsung.com/
Fixes: faa3381267 ("arm64: dts: broadcom: Add minimal support for Raspberry Pi 5")
Signed-off-by: Daniel Drake <dan@reactivated.net>
Link: https://lore.kernel.org/r/20260716-bcm2712-el2-v2-1-e708f7fb42fa@reactivated.net
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
Queue and stack pop/peek helpers accept an uninitialized output buffer
because the verifier expects the helper to initialize it. The empty-map
error path clears the buffer, but a failed lock acquisition returns
-EBUSY without writing it.
Clear the output before returning -EBUSY so BPF programs cannot observe
uninitialized stack contents after a failed helper call.
Fixes: a34a9f1a19 ("bpf: Avoid deadlock when using queue and stack maps from NMI")
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
Link: https://lore.kernel.org/bpf/20260719125419.1782196-1-memxor@gmail.com
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
The BCM43752 is not reliable with the default 512-byte SDIO function 2
block size: on an i.MX8MP board with an AMPAK AP6275S module at
SDR104 / 200 MHz, an iperf TX stress test kills WLAN within seconds:
mmc_submit_one: CMD53 sg block write failed -84
brcmf_sdio_dpc: failed backplane access over SDIO, halting operation
Commit d2587c57ff ("brcmfmac: add 43752 SDIO ids and initialization")
set up the 43752 like the 4373 for the F2 watermark but missed the F2
block size, which the 4373 limits to 256 bytes. The vendor driver
(bcmdhd) also programs a 256-byte F2 block size for this chip and runs
the same hardware without errors.
Group the 43752 with the 4373, matching the F2 watermark handling.
With this change a 10-minute bidirectional iperf3 soak completes with
zero SDIO errors at ~270 Mbit/s in each direction.
Backporting note: kernels before v6.18 name this id
SDIO_DEVICE_ID_BROADCOM_CYPRESS_43752, so on those trees the case
label added by this patch must be adjusted to that name. Cherry-picking
the rename commit 74e2ef72bd ("wifi: brcmfmac: fix 43752 SDIO FWVID
incorrectly labelled as Cypress (CYW)") first is not a clean
alternative: on trees before v6.17 its context collides with the 43751
additions, and trees before v6.2 lack the FWVID framework it touches.
Fixes: d2587c57ff ("brcmfmac: add 43752 SDIO ids and initialization")
Cc: stable@vger.kernel.org # see patch description, needs adjustments for <= 6.17
Signed-off-by: LiangCheng Wang <zaq14760@gmail.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Link: https://patch.msgid.link/20260715-b43752-f2-blksz-v2-1-f9be49856050@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
WMI_gaming_execute_u32_u64() returns success when firmware supplies
no output object, leaving the caller output untouched. Gaming getters
then inspect an uninitialized result value.
When the caller requests an output value, return -ENOMSG if firmware
supplies no object. Preserve a NULL output pointer as the supported way
for callers to ignore the result.
Fixes: 2d76708c22 ("platform/x86: acer-wmi: use WMI calls for platform profile handling")
Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
Link: https://patch.msgid.link/20260701164208.8998-1-alhouseenyousef@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
pmc_core_pmt_get_lpm_req() returns the last telemetry read status. When
firmware exposes no enabled low-power modes, the loop does not run
and the function returns an uninitialized stack value.
Initialize the status to success so an empty mode set is handled
deterministically.
Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
Reviewed-by: David E. Box <david.e.box@linux.intel.com>
Link: https://patch.msgid.link/20260630105101.54016-1-alhouseenyousef@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
