Changed:
- Replace the 'Zeroable' impls for 'Option<NonZero*>' with impls of
'ZeroableOption' for 'NonZero*'.
- Improve feature gate handling for unstable features.
- Declutter the documentation of implementations of 'Zeroable' for
tuples.
- Replace uses of 'addr_of[_mut]!' with '&raw [mut]'.
-----BEGIN PGP SIGNATURE-----
iIgEABYKADAWIQQjEG/HT3UeYLJybLTomd21rZaLygUCacvG9BIcbG9zc2luQGtl
cm5lbC5vcmcACgkQ6Jndta2Wi8r6/gEAxIk8Z6T4xxpDiAs7eW78EZQm315ezULa
UNCiBsnsnFUBANMEeYzknentM/kblOZuQ7Eg8UcYTOGWXBGC10QUNRgL
=LoFy
-----END PGP SIGNATURE-----
Merge tag 'pin-init-v7.1' of https://github.com/Rust-for-Linux/linux into rust-next
Pull pin-init updates from Benno Lossin:
- Replace the 'Zeroable' impls for 'Option<NonZero*>' with impls of
'ZeroableOption' for 'NonZero*'.
- Improve feature gate handling for unstable features.
- Declutter the documentation of implementations of 'Zeroable' for
tuples.
- Replace uses of 'addr_of[_mut]!' with '&raw [mut]'.
* tag 'pin-init-v7.1' of https://github.com/Rust-for-Linux/linux:
rust: pin-init: replace `addr_of_mut!` with `&raw mut`
rust: pin-init: implement ZeroableOption for NonZero* integer types
rust: pin-init: doc: de-clutter documentation with fake-variadics
rust: pin-init: properly document let binding workaround
rust: pin-init: build: simplify use of nightly features
- Expand the example section in the `HrTimer` documentation.
- Mark the `ClockSource` trait as unsafe to ensure valid values for `ktime_get()`.
- Add `Delta::from_nanos()`.
-----BEGIN PGP SIGNATURE-----
iQJKBAABCgA0FiEEEsH5R1a/fCoV1sAS4bgaPnkoY3cFAmnKP7YWHGEuaGluZGJv
cmdAa2VybmVsLm9yZwAKCRDhuBo+eShjdz6WD/wJwqnMIh8Rlm0HOaOkow9zcOhV
JCKFThJRxcFZBgFF9sugHPDDay36NzylIiT+9R088JhLbgBjFhV8Bquvu1NECLHX
xYcRo8aUm5hd/xpEysGSX4s1M5S128701xFT3DXQYkCI0qaBDXtf6Eqmm1jecEEQ
xRvcFg/sip7hq0f8C2+WIIKoU9fgBHAx3epDbUjg9UWu4l2XLEE6GXjlFR1ypVZN
/28j9kikWVytlst3udqzVxNW9Vjak3mWflv+J/aBEWjBF0IFTZI3MY//RExHOTMZ
oWS8zJb1AiLeEGz3UIHeZASrpbkJO2icxkXxYxDZfMs3SH+JTBc16Sk+GFIG1iqj
v7pX4xeUiN4nemvVAuF/UEGCxEGqKz5gJ7Letk96mAZLroFMtHMOBfAH0/uE/+Zl
73ZNeeeNZgrlQnNGfJigXQqyySwaAHuKhMHy5nKAYq2QyYJoMLji02ZzCfSDfmKY
dXKeGXB97dSF8zYnblix8t9A5BDfbPgPiKoKBBmMujPk4lYq4F5mVXgisIuoOs6y
KXKyNNZDo6wCnHQjfVLm6/Dp1NRE7kQoLwH8fgxjO6vQLrYmBPyBDqnVxrHmDfYP
mVt+X+7MLve8fADA6ZxWhEgmRnfLdRdfU0CTRFfKVYItbWoj05Zfdj3Z5tN8hzSw
IlbbtWtuyThXyPvpjg==
=WT7M
-----END PGP SIGNATURE-----
Merge tag 'rust-timekeeping-for-v7.1' of https://github.com/Rust-for-Linux/linux into rust-next
Pull timekeeping updates from Andreas Hindborg:
- Expand the example section in the 'HrTimer' documentation.
- Mark the 'ClockSource' trait as unsafe to ensure valid values for
'ktime_get()'.
- Add 'Delta::from_nanos()'.
This is a back merge since the pull request has a newer base -- we will
avoid that in the future.
And, given it is a back merge, it happens to resolve the "subtle" conflict
around '--remap-path-{prefix,scope}' that I discussed in linux-next [1],
plus a few other common conflicts. The result matches what we did for
next-20260407.
The actual diffstat (i.e. using a temporary merge of upstream first) is:
rust/kernel/time.rs | 32 ++++-
rust/kernel/time/hrtimer.rs | 336 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 362 insertions(+), 6 deletions(-)
Link: https://lore.kernel.org/linux-next/CANiq72kdxB=W3_CV1U44oOK3SssztPo2wLDZt6LP94TEO+Kj4g@mail.gmail.com/ [1]
* tag 'rust-timekeeping-for-v7.1' of https://github.com/Rust-for-Linux/linux:
hrtimer: add usage examples to documentation
rust: time: make ClockSource unsafe trait
rust/time: Add Delta::from_nanos()
Delta 410 uses snd_akm4xxx_reset() both around DFS changes and from
its PM callbacks, but the AK4529 case in this helper is still left
unimplemented and never drives the codec reset path.
The AK4529 datasheet documents register 09h.RSTN as an internal
timing reset. Clearing RSTN powers down the ADC and DAC blocks, but
does not reinitialize the register map. That matches the existing
ak4xxx helper model, which already keeps the desired codec state in
the software register cache.
Implement AK4529 reset handling by clearing 09h.RSTN on state == 1,
then replaying the cached register image and setting RSTN back to 1
on state == 0.
This restores cached Delta 410 mixer state after resume and gives
the AK4529 DFS-change path a real codec reset sequence.
Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Link: https://patch.msgid.link/20260407-ak4529-reset-handling-v1-1-b971c18b1a32@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Remove the "michael_mic" crypto_shash algorithm, since it's no longer
used. Its only users were wireless drivers, which have now been
converted to use the michael_mic() function instead.
It makes sense that no other users ever appeared: Michael MIC is an
insecure algorithm that is specific to WPA TKIP, which itself was an
interim security solution to replace the broken WEP standard.
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Link: https://patch.msgid.link/20260408030651.80336-7-ebiggers@kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
interwave still leaves both its ISA and PnP PM callbacks disabled even
though the shared GUS suspend and resume path now exists.
This board needs InterWave-specific glue around the shared GUS PM path.
The attached WSS codec has its own register image that must be saved and
restored across suspend, the InterWave-specific GF1 compatibility,
decode, MPU401, and emulation settings must be rewritten after the
shared GF1 resume path reinitializes the chip, and the probe-detected
InterWave memory layout must be restored without rerunning the
destructive DRAM/ROM detection path.
Track the optional STB TEA6330T bus at probe time, restore its cached
mixer state after resume, add resume-safe helpers for the InterWave
register and memory-configuration state, and wire both the ISA and PnP
front-ends up to the shared GUS PM helpers.
The resume path intentionally restores only the cached hardware setup.
It does not attempt to preserve sample RAM contents across suspend.
Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260407-alsa-interwave-pm-v2-3-8dd96c6129e9@gmail.com
The InterWave STB variant uses a TEA6330T mixer on its private
I2C bus. The mixer state is cached in software, but there is no
helper to push that register image back to hardware after system
resume.
Add a small restore helper that reapplies the cached TEA6330T
register image to the device so board drivers can restore the
external mixer state as part of their PM resume path.
Take snd_i2c_lock() around the full device lookup and restore
sequence so the bus device list traversal is also protected.
Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260407-alsa-interwave-pm-v2-2-8dd96c6129e9@gmail.com
Move the remaining standalone snd_tea6330t_detect() EXPORT_SYMBOL()
declaration next to its function definition so tea6330t.c follows the
usual layout.
No functional change intended.
Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260407-alsa-interwave-pm-v2-1-8dd96c6129e9@gmail.com
The original iuutool author is Juan Carlos Borrás - fix the spelling.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Signed-off-by: Johan Hovold <johan@kernel.org>
Building ARCH=um on glibc >= 2.43 fails:
arch/um/drivers/cow_user.c: error: implicit declaration of
function 'strrchr' [-Wimplicit-function-declaration]
glibc 2.43's C23 const-preserving strrchr() macro does not survive
UML's global -Dstrrchr=kernel_strrchr remap from arch/um/Makefile.
Call kernel_strrchr() directly in cow_user.c so the source no longer
depends on the -D rewrite.
Fixes: 2c51a4bc02 ("um: fix strrchr() problems")
Suggested-by: Johannes Berg <johannes@sipsolutions.net>
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-6
Assisted-by: Codex:gpt-5-4
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
Link: https://patch.msgid.link/20260408070102.2325572-1-michael.bommarito@gmail.com
[remove unnecessary 'extern']
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Currently the probe does not check whether getting the regmap succeeded.
This can cause crash when regmap is used, if it wasn't successfully
obtained. Failing to get the regmap is unlikely, especially since this
driver is expected to be kicked by the MFD driver only after registering
the regmap - but it is still better to handle this gracefully.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Fixes: e7eef0bd4075 ("regulator: bd71828-regulator.c: Fix LDON-HEAD mode")
Link: https://patch.msgid.link/5bfffee380863bcf24f3062e48094c8eb7b1342f.1775565381.git.mazziesaccount@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Just use the michael_mic() function from cfg80211 instead of a local
implementation of it using the crypto_shash API.
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Link: https://patch.msgid.link/20260408030651.80336-6-ebiggers@kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Just use the michael_mic() function from cfg80211 instead of a local
implementation of it using the crypto_shash API.
Note: when the kernel is booted with fips=1,
crypto_alloc_shash("michael_mic", 0, 0) always returned
ERR_PTR(-ENOENT), because Michael MIC is not a "FIPS allowed" algorithm.
For now, just preserve that behavior exactly, to ensure that TKIP is not
allowed to be used in FIPS mode. This logic actually seems to disable
the entire driver in FIPS mode and not just TKIP, but that was the
existing behavior. Supporting this driver in FIPS mode, if anyone
actually needs it there, should be a separate commit.
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Link: https://patch.msgid.link/20260408030651.80336-5-ebiggers@kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Just use the michael_mic() function from cfg80211 instead of a local
implementation of it using the crypto_shash API.
Note: when the kernel is booted with fips=1,
crypto_alloc_shash("michael_mic", 0, 0) always returned
ERR_PTR(-ENOENT), because Michael MIC is not a "FIPS allowed" algorithm.
For now, just preserve that behavior exactly, to ensure that TKIP is not
allowed to be used in FIPS mode. This logic actually seems to disable
the entire driver in FIPS mode and not just TKIP, but that was the
existing behavior. Supporting this driver in FIPS mode, if anyone
actually needs it there, should be a separate commit.
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Link: https://patch.msgid.link/20260408030651.80336-4-ebiggers@kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Export michael_mic() so that the ath11k and ath12k drivers can call it.
In addition, move it from mac80211 to cfg80211 so that the ipw2x00
drivers, which depend on cfg80211 but not mac80211, can also call it.
Currently these drivers have their own local implementations of
michael_mic() based on crypto_shash, which is redundant and inefficient.
By consolidating all the Michael MIC code into cfg80211, we'll be able
to remove the duplicate Michael MIC code in the crypto/ directory.
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Link: https://patch.msgid.link/20260408030651.80336-3-ebiggers@kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Rename the driver-local michael_mic() function to libipw_michael_mic()
to prevent a name conflict with the common michael_mic() function.
Note that this code will be superseded later when libipw starts using
the common michael_mic(). This commit just prevents a bisection hazard.
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Link: https://patch.msgid.link/20260408030651.80336-2-ebiggers@kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add ath12k support for IPQ5424.
And of course there is the usual set of cleanups and bug fixes touching
the ath10k and ath12k drivers.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQ/mtSHzPUi16IfDEksFbugiYzLewUCadWz6wAKCRAsFbugiYzL
e/RyAQC2pNMwwrhU5N+31HzHO4VztoY9fTVWazbTOgEOmGsWewD/YTifCs5DT3gO
u1g6KqKypP9u9tUQ4JDlFUXXB1ccHwU=
=SLDs
-----END PGP SIGNATURE-----
Merge tag 'ath-next-20260407' of git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath
Jeff Johnson says:
==================
ath.git patches for v7.1 (PR #3)
Add ath12k support for IPQ5424.
And of course there is the usual set of cleanups and bug fixes touching
the ath10k and ath12k drivers.
==================
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Use the common USB helpers for looking up bulk and interrupt endpoints
(and determining max packet size) instead of open coding.
Note that the driver has an implicit max packet size check which is
kept.
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://patch.msgid.link/20260407151111.3187826-4-johan@kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Use the common USB helpers for looking up bulk and interrupt endpoints
(and determining max packet size) instead of open coding.
Note that the driver has an implicit max packet size check which is
kept.
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://patch.msgid.link/20260407151111.3187826-3-johan@kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Use the common USB helper for looking up bulk and interrupt endpoints
instead of open coding.
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://patch.msgid.link/20260407151111.3187826-2-johan@kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add a new helper function to retrieve the next action entry in flow
rule, check if the maximum number of actions is reached, bail out in
such case.
Replace existing opencoded iteration on the action array by this
helper function.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Florian Westphal <fw@strlen.de>
The trace lines are indented using PRINT("%*.s", xx, " ").
Userspace will treat this as "%*.0s" and will output no characters
when 'xx' is zero, the kernel treats it as "%*s" and will output
a single ' ' - which is probably what is intended.
Change all the formats to "%*s" removing the default precision.
This gives a single space indent when level is zero.
Signed-off-by: David Laight <david.laight.linux@gmail.com>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Currently:
add rule netdev x y ip saddr 1.1.1.1
does not work with neither double-tagged vlan nor pppoe packets. This is
because the network and transport header offset are not pointing to the
IP and transport protocol headers in the stack.
This patch expands NFT_META_PROTOCOL and NFT_META_L4PROTO to parse
double-tagged vlan and pppoe packets so matching network and transport
header fields becomes possible with the existing userspace generated
bytecode. Note that this parser only supports double-tagged vlan which
is composed of vlan offload + vlan header in the skb payload area for
simplicity.
NFT_META_PROTOCOL is used by bridge and netdev family as an implicit
dependency in the bytecode to match on network header fields.
Similarly, there is also NFT_META_L4PROTO, which is also used as an
implicit dependency when matching on the transport protocol header
fields.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Florian Westphal <fw@strlen.de>
nft_pipapo_avx2_lookup_slow will never be used in reality, because the
common sizes are handled by avx2 optimized versions.
However, nft_pipapo_avx2_lookup_slow loops over the data just like the
avx2 functions. However, _slow doesn't need to do that.
As-is, first loop sets all the right result bits and the next iterations
boil down to 'x = x & x'. Remove the loop.
Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Since commit e807b13cb3 ("nft_set_pipapo: Generalise group size for buckets")
there is no longer a need to increment the data pointer in two steps.
Switch to a single invocation of NFT_PIPAPO_GROUPS_PADDED_SIZE() helper,
like the avx2 implementation.
[ Stefano: Improve commit message ]
Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Should have no effect in practice; all of these use the
nft_parse_register_load/store apis which is mandatory anyway due
to the need to further validate the register load/store, e.g.
that the size argument doesn't result in out-of-bounds load/store.
OTOH this is a simple method to reject obviously wrong input
at earlier stage.
Signed-off-by: Florian Westphal <fw@strlen.de>
These spots either already check the attribute range manually
before use or the consuming functions tolerate unexpected values.
Nevertheless, add more range checks via netlink policy so we gain
more users and avoid possible re-use in other places that might
not have the required manual checks. This also improves error
reporting: netlink core can generate extack errors.
Signed-off-by: Florian Westphal <fw@strlen.de>
The debug code (not enabled in any build) reads up to 6 octets of
the inpt buffer, but does so without bound checks. Zap this.
Signed-off-by: Florian Westphal <fw@strlen.de>
net is already set, derived from nf_conn.
I don't see how the device could be living in a different netns
than the conntrack entry.
Remove the extra variable and re-use existing one.
Signed-off-by: Florian Westphal <fw@strlen.de>
After commit 07919126ec ("netfilter: annotate NAT helper hook pointers
with __rcu"), sparse can warn about type/address-space mismatches when
RCU-dereferencing NAT helper hook function pointers.
The hooks are __rcu-annotated and accessed via rcu_dereference(), but the
combination of complex function pointer declarators and the WRITE_ONCE()
machinery used by RCU_INIT_POINTER()/rcu_assign_pointer() can confuse
sparse and trigger false positives.
Introduce typedefs for the NAT helper function types, so __rcu applies to
a simple "fn_t __rcu *" pointer form. Also replace local typeof(hook)
variables with "fn_t *" to avoid propagating __rcu address space into
temporaries.
No functional change intended.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202603022359.3dGE9fwI-lkp@intel.com/
Signed-off-by: Sun Jian <sun.jian.kdev@gmail.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
A lockdep circular locking dependency warning can be triggered
reproducibly when using a force-feedback gamepad with uinput (for
example, playing ELDEN RING under Wine with a Flydigi Vader 5
controller):
ff->mutex -> udev->mutex -> input_mutex -> dev->mutex -> ff->mutex
The cycle is caused by four lock acquisition paths:
1. ff upload: input_ff_upload() holds ff->mutex and calls
uinput_dev_upload_effect() -> uinput_request_submit() ->
uinput_request_send(), which acquires udev->mutex.
2. device create: uinput_ioctl_handler() holds udev->mutex and calls
uinput_create_device() -> input_register_device(), which acquires
input_mutex.
3. device register: input_register_device() holds input_mutex and
calls kbd_connect() -> input_register_handle(), which acquires
dev->mutex.
4. evdev release: evdev_release() calls input_flush_device() under
dev->mutex, which calls input_ff_flush() acquiring ff->mutex.
Fix this by introducing a new state_lock spinlock to protect
udev->state and udev->dev access in uinput_request_send() instead of
acquiring udev->mutex. The function only needs to atomically check
device state and queue an input event into the ring buffer via
uinput_dev_event() -- both operations are safe under a spinlock
(ktime_get_ts64() and wake_up_interruptible() do not sleep). This
breaks the ff->mutex -> udev->mutex link since a spinlock is a leaf in
the lock ordering and cannot form cycles with mutexes.
To keep state transitions visible to uinput_request_send(), protect
writes to udev->state in uinput_create_device() and
uinput_destroy_device() with the same state_lock spinlock.
Additionally, move init_completion(&request->done) from
uinput_request_send() to uinput_request_submit() before
uinput_request_reserve_slot(). Once the slot is allocated,
uinput_flush_requests() may call complete() on it at any time from
the destroy path, so the completion must be initialised before the
request becomes visible.
Lock ordering after the fix:
ff->mutex -> state_lock (spinlock, leaf)
udev->mutex -> state_lock (spinlock, leaf)
udev->mutex -> input_mutex -> dev->mutex -> ff->mutex (no back-edge)
Fixes: ff46255123 ("Input: uinput - switch to the new FF interface")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/all/CABXGCsMoxag+kEwHhb7KqhuyxfmGGd0P=tHZyb1uKE0pLr8Hkg@mail.gmail.com/
Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Link: https://patch.msgid.link/20260407075031.38351-1-mikhail.v.gavrilov@gmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
PPC_RAW_LI32 is not a valid macro in the PowerPC BPF JIT. Use PPC_LI32,
which correctly handles immediate loads for large values.
Fixes the build error introduced when adding fsession support on ppc32.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202604040212.jIxEd2DW-lkp@intel.com/
Fixes: 92258b5bf1 ("powerpc32/bpf: Add fsession support")
Signed-off-by: Abhishek Dubey <adubey@linux.ibm.com>
Reviewed-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260408055301.232745-1-adubey@linux.ibm.com
VESA backlight enable is possible when
BACKLIGHT_AUX_ENABLE_CAPABLE is true via AUX command or when
BACKLIGHT_PIN_ENABLE_CAPABLE is true via eDP connector pin.
Similarly, backlight brightness adjustment can be
done via AUX-based control or PWM pin-based control.
It means there can be three configurations:
1) Full AUX-based: Enable and adjustment both via AUX. We currently
support this (apart from the AUX luminance-based backlight control).
2) Hybrid: Enable via the BL_ENABLE pin, adjustment via either AUX or
PWM.
3) Fully PWM pin-based: Enable via the BL_ENABLE pin, adjustment via
PWM.
Since that only 1 is supported as of now we need to make
sure we do not try to manipulate backlight when
BACKLIGHT_AUX_ENABLE_CAPABLE is not set.
Also fix return value when condition is not fulfilled.
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/15907
Fixes: 0fb03890d1 ("drm/i915/backlight: Check if VESA backlight is possible")
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260407030710.1440046-1-suraj.kandpal@intel.com
Andrea Mayer says:
====================
seg6: fix dst_cache sharing in seg6 lwtunnel
The seg6 lwtunnel encap uses a single per-route dst_cache shared
between seg6_input_core() and seg6_output_core(). These two paths
can perform the post-encap SID lookup in different routing contexts
(e.g., ip rules matching on the ingress interface, or VRF table
separation). Whichever path runs first populates the cache, and the
other reuses it blindly, bypassing its own lookup.
Patch 1 fixes this by splitting the cache into cache_input and
cache_output. Patch 2 adds a selftest that validates the isolation.
====================
Link: https://patch.msgid.link/20260404004405.4057-1-andrea.mayer@uniroma2.it
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add a selftest that verifies the dst_cache in seg6 lwtunnel is not
shared between the input (forwarding) and output (locally generated)
paths.
The test creates three namespaces (ns_src, ns_router, ns_dst)
connected in a line. An SRv6 encap route on ns_router encapsulates
traffic destined to cafe::1 with SID fc00::100. The SID is
reachable only for forwarded traffic (from ns_src) via an ip rule
matching the ingress interface (iif veth-r0 lookup 100), and
blackholed in the main table.
The test verifies that:
1. A packet generated locally on ns_router does not reach
ns_dst with an empty cache, since the SID is blackholed;
2. A forwarded packet from ns_src populates the input cache
from table 100 and reaches ns_dst;
3. A packet generated locally on ns_router still does not
reach ns_dst after the input cache is populated,
confirming the output path does not reuse the input
cache entry.
Both the forwarded and local packets are pinned to the same CPU
with taskset, since dst_cache is per-cpu.
Cc: Shuah Khan <shuah@kernel.org>
Signed-off-by: Andrea Mayer <andrea.mayer@uniroma2.it>
Reviewed-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Reviewed-by: Justin Iurman <justin.iurman@gmail.com>
Link: https://patch.msgid.link/20260404004405.4057-3-andrea.mayer@uniroma2.it
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The seg6 lwtunnel uses a single dst_cache per encap route, shared
between seg6_input_core() and seg6_output_core(). These two paths
can perform the post-encap SID lookup in different routing contexts
(e.g., ip rules matching on the ingress interface, or VRF table
separation). Whichever path runs first populates the cache, and the
other reuses it blindly, bypassing its own lookup.
Fix this by splitting the cache into cache_input and cache_output,
so each path maintains its own cached dst independently.
Fixes: 6c8702c60b ("ipv6: sr: add support for SRH encapsulation and injection with lwtunnels")
Cc: stable@vger.kernel.org
Signed-off-by: Andrea Mayer <andrea.mayer@uniroma2.it>
Reviewed-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Reviewed-by: Justin Iurman <justin.iurman@gmail.com>
Link: https://patch.msgid.link/20260404004405.4057-2-andrea.mayer@uniroma2.it
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The querier-interval test adds h1 (currently a slave of the VRF created
by simple_if_init) to a temporary bridge br1 acting as an outside IGMP
querier. The kernel VRF driver (drivers/net/vrf.c) calls cycle_netdev()
on every slave add and remove, toggling the interface admin-down then up.
Phylink takes the PHY down during the admin-down half of that cycle.
Since h1 and swp1 are cable-connected, swp1 also loses its link may need
several seconds to re-negotiate.
Use setup_wait_dev $h1 0 which waits for h1 to return to UP state, so the
test can rely on the link being back up at this point.
Fixes: 4d8610ee8b ("selftests: net: bridge: add vlan mcast_querier_interval tests")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Link: https://patch.msgid.link/c830f130860fd2efae08bfb9e5b25fd028e58ce5.1775424423.git.daniel@makrotopia.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Eric Dumazet says:
====================
net: pull gso packet headers in core stack
Most ndo_start_xmit() methods expects headers of gso packets
to be already in skb->head.
net/core/tso.c users are particularly at risk, because tso_build_hdr()
does a memcpy(hdr, skb->data, hdr_len);
qdisc_pkt_len_segs_init() already does a dissection of gso packets.
Use pskb_may_pull() instead of skb_header_pointer() to make
sure drivers do not have to reimplement this.
First patch is a small cleanup to ease second patch review.
====================
Link: https://patch.msgid.link/20260403221540.3297753-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Most ndo_start_xmit() methods expects headers of gso packets
to be already in skb->head.
net/core/tso.c users are particularly at risk, because tso_build_hdr()
does a memcpy(hdr, skb->data, hdr_len);
qdisc_pkt_len_segs_init() already does a dissection of gso packets.
Use pskb_may_pull() instead of skb_header_pointer() to make
sure drivers do not have to reimplement this.
Some malicious packets could be fed, detect them so that we can
drop them sooner with a new SKB_DROP_REASON_SKB_BAD_GSO drop_reason.
Fixes: e876f208af ("net: Add a software TSO helper API")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Joe Damato <joe@dama.to>
Link: https://patch.msgid.link/20260403221540.3297753-3-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reduce indentation level by returning early if the transport header
was not set.
Add an unlikely() clause as this is not the common case.
No functional change.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Joe Damato <joe@dama.to>
Link: https://patch.msgid.link/20260403221540.3297753-2-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Sashiko points out that we use qops in __net_mp_open_rxq()
but never validate they are null. This was introduced when
check was moved from netdev_rx_queue_restart().
Look at ops directly instead of the locking config.
qops imply netdev_need_ops_lock(). We used netdev_need_ops_lock()
initially to signify that the real_num_rx_queues check below
is safe without rtnl_lock, but I'm not sure if this is actually
clear to most people, anyway.
Fixes: da7772a2b4 ("net: move mp->rx_page_size validation to __net_mp_open_rxq()")
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Mina Almasry <almasrymina@google.com>
Link: https://patch.msgid.link/20260404001938.2425670-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
socat v1.8.1.0 now defaults to shut-null, it sends an extra
0-length UDP packet when sender disconnects. This breaks
our tests which expect the exact packet sequence.
Add shut-none which was the old default where necessary.
Acked-by: Stanislav Fomichev <sdf@fomichev.me>
Reviewed-by: Joe Damato <joe@dama.to>
Reviewed-by: Breno Leitao <leitao@debian.org>
Link: https://patch.msgid.link/20260404230103.2719103-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This patch fixes an issue where reading the MAC address from the eFUSE
fails due to a race condition.
The root cause was identified by comparing the driver's behavior with a
custom U-Boot port. In U-Boot, the MAC address was read successfully
every time because the driver was loaded later in the boot process, giving
the hardware ample time to initialize. In Linux, reading the eFUSE
immediately returns all zeros, resulting in a fallback to a random MAC address.
Hardware cold-boot testing revealed that the eFUSE controller requires a
short settling time to load its internal data. Adding a 2000-5000us
delay after the reset ensures the hardware is fully ready, allowing the
native MAC address to be read consistently.
Fixes: 02ff155ea2 ("net: stmmac: Add glue driver for Motorcomm YT6801 ethernet controller")
Reported-by: Georg Gottleuber <ggo@tuxedocomputers.com>
Closes: https://lore.kernel.org/24cfefff-1233-4745-8c47-812b502d5d19@tuxedocomputers.com
Signed-off-by: Johan Alvarado <contact@c127.dev>
Reviewed-by: Yao Zi <me@ziyao.cc>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/fc5992a4-9532-49c3-8ec1-c2f8c5b84ca1@smtp-relay.sendinblue.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Amery Hung says:
====================
Allow referenced dynptr to be overwritten when siblings exists
The patchset conditionally allow a referenced dynptr to be overwritten
when its siblings (original dynptr or dynptr clone) exist. Do it before
the verifier relation tracking refactor to mimimize verifier changes at
a time.
====================
Link: https://patch.msgid.link/20260406150548.1354271-1-ameryhung@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Test overwriting referenced dynptr and clones to make sure it is only
allow when there is at least one other dynptr with the same ref_obj_id.
Also make sure slice is still invalidated after the dynptr's stack slot
is destroyed.
Signed-off-by: Amery Hung <ameryhung@gmail.com>
Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/r/20260406150548.1354271-3-ameryhung@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
The verifier currently does not allow overwriting a referenced dynptr's
stack slot to prevent resource leak. This is because referenced dynptr
holds additional resources that requires calling specific helpers to
release. This limitation can be relaxed when there are multiple copies
of the same dynptr. Whether it is the orignial dynptr or one of its
clones, as long as there exists at least one other dynptr with the same
ref_obj_id (to be used to release the reference), its stack slot should
be allowed to be overwritten.
Suggested-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Amery Hung <ameryhung@gmail.com>
Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/r/20260406150548.1354271-2-ameryhung@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
