- Linux-stable-mirror - lists.linaro.org

Re: Patch "clocksource/drivers/timer-rtl-otto: Work around dying timers" has been added to the 6.17-stab

by Pascal Ernster

Hi Sasha, [2025-11-04 14:17] Sasha Levin: > This is a note to let you know that I've just added the patch titled > > clocksource/drivers/timer-rtl-otto: Work around dying timers > > to the 6.17-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > clocksource-drivers-timer-rtl-otto-work-around-dying.patch > and it can be found in the queue-6.17 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > > > > commit fbc0494f847969d81c1f087117dca462c816bedb > Author: Markus Stockhausen <markus.stockhausen(a)gmx.de> > Date: Mon Aug 4 04:03:25 2025 -0400 > > clocksource/drivers/timer-rtl-otto: Work around dying timers > > [ Upstream commit e7a25106335041aeca4fdf50a84804c90142c886 ] > > The OpenWrt distribution has switched from kernel longterm 6.6 to > 6.12. Reports show that devices with the Realtek Otto switch platform > die during operation and are rebooted by the watchdog. Sorting out > other possible reasons the Otto timer is to blame. The platform > currently consists of 4 targets with different hardware revisions. > It is not 100% clear which devices and revisions are affected. > > Analysis shows: > > A more aggressive sched/deadline handling leads to more timer starts > with small intervals. This increases the bug chances. See > https://marc.info/?l=linux-kernel&m=175276556023276&w=2 > > Focusing on the real issue a hardware limitation on some devices was > found. There is a minimal chance that a timer ends without firing an > interrupt if it is reprogrammed within the 5us before its expiration > time. Work around this issue by introducing a bounce() function. It > restarts the timer directly before the normal restart functions as > follows: > > - Stop timer > - Restart timer with a slow frequency. > - Target time will be >5us > - The subsequent normal restart is outside the critical window > > Downstream has already tested and confirmed a patch. See > https://github.com/openwrt/openwrt/pull/19468 > https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/5787… > > Signed-off-by: Markus Stockhausen <markus.stockhausen(a)gmx.de> > Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org> > Tested-by: Stephen Howell <howels(a)allthatwemight.be> > Tested-by: Bjørn Mork <bjorn(a)mork.no> > Link: https://lore.kernel.org/r/20250804080328.2609287-2-markus.stockhausen@gmx.de > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/drivers/clocksource/timer-rtl-otto.c b/drivers/clocksource/timer-rtl-otto.c > index 8a3068b36e752..8be45a11fb8b6 100644 > --- a/drivers/clocksource/timer-rtl-otto.c > +++ b/drivers/clocksource/timer-rtl-otto.c > @@ -38,6 +38,7 @@ > #define RTTM_BIT_COUNT 28 > #define RTTM_MIN_DELTA 8 > #define RTTM_MAX_DELTA CLOCKSOURCE_MASK(28) > +#define RTTM_MAX_DIVISOR GENMASK(15, 0) > > /* > * Timers are derived from the LXB clock frequency. Usually this is a fixed > @@ -112,6 +113,22 @@ static irqreturn_t rttm_timer_interrupt(int irq, void *dev_id) > return IRQ_HANDLED; > } > > +static void rttm_bounce_timer(void __iomem *base, u32 mode) > +{ > + /* > + * When a running timer has less than ~5us left, a stop/start sequence > + * might fail. While the details are unknown the most evident effect is > + * that the subsequent interrupt will not be fired. > + * > + * As a workaround issue an intermediate restart with a very slow > + * frequency of ~3kHz keeping the target counter (>=8). So the follow > + * up restart will always be issued outside the critical window. > + */ > + > + rttm_disable_timer(base); > + rttm_enable_timer(base, mode, RTTM_MAX_DIVISOR); > +} > + > static void rttm_stop_timer(void __iomem *base) > { > rttm_disable_timer(base); > @@ -129,6 +146,7 @@ static int rttm_next_event(unsigned long delta, struct clock_event_device *clkev > struct timer_of *to = to_timer_of(clkevt); > > RTTM_DEBUG(to->of_base.base); > + rttm_bounce_timer(to->of_base.base, RTTM_CTRL_COUNTER); > rttm_stop_timer(to->of_base.base); > rttm_set_period(to->of_base.base, delta); > rttm_start_timer(to, RTTM_CTRL_COUNTER); > @@ -141,6 +159,7 @@ static int rttm_state_oneshot(struct clock_event_device *clkevt) > struct timer_of *to = to_timer_of(clkevt); > > RTTM_DEBUG(to->of_base.base); > + rttm_bounce_timer(to->of_base.base, RTTM_CTRL_COUNTER); > rttm_stop_timer(to->of_base.base); > rttm_set_period(to->of_base.base, RTTM_TICKS_PER_SEC / HZ); > rttm_start_timer(to, RTTM_CTRL_COUNTER); > @@ -153,6 +172,7 @@ static int rttm_state_periodic(struct clock_event_device *clkevt) > struct timer_of *to = to_timer_of(clkevt); > > RTTM_DEBUG(to->of_base.base); > + rttm_bounce_timer(to->of_base.base, RTTM_CTRL_TIMER); > rttm_stop_timer(to->of_base.base); > rttm_set_period(to->of_base.base, RTTM_TICKS_PER_SEC / HZ); > rttm_start_timer(to, RTTM_CTRL_TIMER); this patch is part of a series of 4 patches, but it seems you have only cherry-picked patches 1 and 3 from that series, although all 4 were merged into Linus' tree: https://lore.kernel.org/all/20250804080328.2609287-1-markus.stockhausen@gmx… https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/driv… I could only find the "linux-stable-commits" mails for queue-6.17, but you selected the same 2 patches for queue-6.12 as well. Is that selection of only 2 of the 4 patches intentional? Regards Pascaö

1 week, 5 days

2
2
0 0

[PATCH v2] iio: trigger: Fix error handling in viio_trigger_alloc

by Ma Ke

viio_trigger_alloc() initializes the device with device_initialize() but uses kfree() directly in error paths, which bypasses the device's release callback iio_trig_release(). This could lead to memory leaks and inconsistent device state. Additionally, the current error handling has the following issues: 1. Potential double-free of IRQ descriptors when kvasprintf fails. 2. The release function may attempt to free negative subirq_base. 3. Missing mutex_destroy in release function. Fix these issues by: 1. Replacing kfree(trig) with put_device(&trig->dev) in error paths. 2. Setting subirq_base to 0 after freeing IRQ descriptors in error path to prevent double-free in release callback. 3. Modifying release function to properly handle negative subirq_base. 4. Adding missing mutex_destroy(). Found by code review. Cc: stable(a)vger.kernel.org Fixes: 2c99f1a09da3 ("iio: trigger: clean up viio_trigger_alloc()") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- Changes in v2: - modified the patch, thanks for developer's suggestions. --- drivers/iio/industrialio-trigger.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/iio/industrialio-trigger.c b/drivers/iio/industrialio-trigger.c index 54416a384232..9f6d30a244d9 100644 --- a/drivers/iio/industrialio-trigger.c +++ b/drivers/iio/industrialio-trigger.c @@ -524,6 +524,7 @@ static void iio_trig_release(struct device *device) CONFIG_IIO_CONSUMERS_PER_TRIGGER); } kfree(trig->name); + mutex_destroy(&trig->pool_lock); kfree(trig); } @@ -596,8 +597,9 @@ struct iio_trigger *viio_trigger_alloc(struct device *parent, free_descs: irq_free_descs(trig->subirq_base, CONFIG_IIO_CONSUMERS_PER_TRIGGER); + trig->subirq_base = 0; free_trig: - kfree(trig); + put_device(&trig->dev); return NULL; } -- 2.17.1

1 week, 5 days

4
3
0 0

FAILED: patch "[PATCH] x86/CPU/AMD: Add missing terminator for zen5_rdseed_microcode" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y git checkout FETCH_HEAD git cherry-pick -x f1fdffe0afea02ba783acfe815b6a60e7180df40 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025110944-strenuous-hydrant-ea0b@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From f1fdffe0afea02ba783acfe815b6a60e7180df40 Mon Sep 17 00:00:00 2001 From: Mario Limonciello <mario.limonciello(a)amd.com> Date: Tue, 4 Nov 2025 10:10:06 -0600 Subject: [PATCH] x86/CPU/AMD: Add missing terminator for zen5_rdseed_microcode Running x86_match_min_microcode_rev() on a Zen5 CPU trips up KASAN for an out of bounds access. Fixes: 607b9fb2ce248 ("x86/CPU/AMD: Add RDSEED fix for Zen5") Signed-off-by: Mario Limonciello <mario.limonciello(a)amd.com> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20251104161007.269885-1-mario.limonciello@amd.com diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index 8e36964a7721..2ba9f2d42d8c 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -1038,6 +1038,7 @@ static void init_amd_zen4(struct cpuinfo_x86 *c) static const struct x86_cpu_id zen5_rdseed_microcode[] = { ZEN_MODEL_STEP_UCODE(0x1a, 0x02, 0x1, 0x0b00215a), ZEN_MODEL_STEP_UCODE(0x1a, 0x11, 0x0, 0x0b101054), + {}, }; static void init_amd_zen5(struct cpuinfo_x86 *c)

1 week, 5 days

2
1
0 0

[PATCH v2] bpf: hashtab: fix 32-bit overflow in memory usage calculation

by Alexei Safin

The intermediate product value_size * num_possible_cpus() is evaluated in 32-bit arithmetic and only then promoted to 64 bits. On systems with large value_size and many possible CPUs this can overflow and lead to an underestimated memory usage. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 304849a27b34 ("bpf: hashtab memory usage") Cc: stable(a)vger.kernel.org Suggested-by: Yafang Shao <laoar.shao(a)gmail.com> Signed-off-by: Alexei Safin <a.safin(a)rosa.ru> --- v2: Promote value_size to u64 at declaration to avoid 32-bit overflow in all arithmetic using this variable (suggested by Yafang Shao) kernel/bpf/hashtab.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c index 570e2f723144..1f0add26ba3f 100644 --- a/kernel/bpf/hashtab.c +++ b/kernel/bpf/hashtab.c @@ -2252,7 +2252,7 @@ static long bpf_for_each_hash_elem(struct bpf_map *map, bpf_callback_t callback_ static u64 htab_map_mem_usage(const struct bpf_map *map) { struct bpf_htab *htab = container_of(map, struct bpf_htab, map); - u32 value_size = round_up(htab->map.value_size, 8); + u64 value_size = round_up(htab->map.value_size, 8); bool prealloc = htab_is_prealloc(htab); bool percpu = htab_is_percpu(htab); bool lru = htab_is_lru(htab); -- 2.50.1 (Apple Git-155)

1 week, 5 days

4
6
0 0

[PATCH] powerpc: Use relocated font data pointer for btext_drawchar()

by Finn Thain

From: Christophe Leroy <christophe.leroy(a)csgroup.eu> Since Linux v6.7, booting using BootX on an Old World PowerMac produces an early crash. Stan Johnson writes, "the symptoms are that the screen goes blank and the backlight stays on, and the system freezes (Linux doesn't boot)." Further testing revealed that the failure can be avoided by disabling CONFIG_BOOTX_TEXT. Bisection revealed that the regression was caused by a patch which replaced the static btext font data with const data in a different compilation unit. To fix this, access the font data at its relocated address. Cc: Cedar Maxwell <cedarmaxwell(a)mac.com> Cc: Stan Johnson <userm57(a)yahoo.com> Cc: "Dr. David Alan Gilbert" <linux(a)treblig.org> Cc: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> Cc: stable(a)vger.kernel.org Link: https://lists.debian.org/debian-powerpc/2025/10/msg00111.html Link: https://lore.kernel.org/linuxppc-dev/d81ddca8-c5ee-d583-d579-02b19ed95301@y… Reported-by: Cedar Maxwell <cedarmaxwell(a)mac.com> Closes: https://lists.debian.org/debian-powerpc/2025/09/msg00031.html Bisected-by: Stan Johnson <userm57(a)yahoo.com> Tested-by: Stan Johnson <userm57(a)yahoo.com> Fixes: 0ebc7feae79a ("powerpc: Use shared font data") Signed-off-by: Finn Thain <fthain(a)linux-m68k.org> --- Christophe, as you're the author of this patch, this submission will probably need your sign-off. --- arch/powerpc/kernel/btext.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/btext.c b/arch/powerpc/kernel/btext.c index 7f63f1cdc6c3..ca00c4824e31 100644 --- a/arch/powerpc/kernel/btext.c +++ b/arch/powerpc/kernel/btext.c @@ -20,6 +20,7 @@ #include <asm/io.h> #include <asm/processor.h> #include <asm/udbg.h> +#include <asm/setup.h> #define NO_SCROLL @@ -463,7 +464,7 @@ static noinline void draw_byte(unsigned char c, long locX, long locY) { unsigned char *base = calc_base(locX << 3, locY << 4); unsigned int font_index = c * 16; - const unsigned char *font = font_sun_8x16.data + font_index; + const unsigned char *font = PTRRELOC(font_sun_8x16.data) + font_index; int rb = dispDeviceRowBytes; rmci_maybe_on(); -- 2.49.1

1 week, 5 days

2
1
0 0

[PATCH] rtc: Fix error handling in devm_rtc_allocate_device

by Ma Ke

In rtc_allocate_device(), device_initialize() sets the reference count to 1. In rtc_allocate_device(), when devm_add_action_or_reset() or dev_set_name() fails after successful device initialization via device_initialize(), rtc_allocate_device() returns an error without properly calling put_device() and releasing the reference count. Add proper error handling that calls put_device() in all error paths after device_initialize(), ensuring proper resource cleanup. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 3068a254d551 ("rtc: introduce new registration method") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/rtc/class.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c index b1a2be1f9e3b..db5f33a22b14 100644 --- a/drivers/rtc/class.c +++ b/drivers/rtc/class.c @@ -379,13 +379,17 @@ struct rtc_device *devm_rtc_allocate_device(struct device *dev) rtc->dev.parent = dev; err = devm_add_action_or_reset(dev, devm_rtc_release_device, rtc); if (err) - return ERR_PTR(err); + goto err_put_device; err = dev_set_name(&rtc->dev, "rtc%d", id); if (err) - return ERR_PTR(err); + goto err_put_device; return rtc; + +err_put_device: + put_device(&rtc->dev); + return ERR_PTR(err); } EXPORT_SYMBOL_GPL(devm_rtc_allocate_device); -- 2.17.1

1 week, 5 days

2
1
0 0

PETROLEUM PRODUCT OFFER

by Mr, Lee Timur

We at STANDARD TRADING LLP are Oil Trading Company that deals directly with a reliable Refinery. We wish to inform your good self and your esteemed buying company that we currently have petroleum products for an immediate lift such as JP54, A1, D2, D6, EN590, PETCOKE Aviation Kerosene, Jet fuel, LNG and LPG, D6 Virgin Fuel oil, Automotive Gas Oil , Mazut M100,REBCO, BITUMEN, UREA. contact us for more information .

1 week, 5 days

1
0
0 0

[GIT PULL] KVM/arm64 fixes for 6.18, take #2

by Marc Zyngier

Paolo, Much later than expected, but here's the second set of fixes KVM/arm64 for 6.18. The core changes are mostly fixes for a bunch of recent regressions, plus a couple that address the way pKVM deals with untrusted data. The rest address a couple of selftests, and Oliver's new email address. Please pull, M. The following changes since commit ca88ecdce5f51874a7c151809bd2c936ee0d3805: arm64: Revamp HCR_EL2.E2H RES1 detection (2025-10-14 08:18:40 +0100) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-fixes-6.18-2 for you to fetch changes up to 4af235bf645516481a82227d82d1352b9788903a: MAINTAINERS: Switch myself to using kernel.org address (2025-11-08 11:21:20 +0000) ---------------------------------------------------------------- KVM/arm654 fixes for 6.18, take #2 * Core fixes - Fix trapping regression when no in-kernel irqchip is present (20251021094358.1963807-1-sascha.bischoff(a)arm.com) - Check host-provided, untrusted ranges and offsets in pKVM (20251016164541.3771235-1-vdonnefort(a)google.com) (20251017075710.2605118-1-sebastianene(a)google.com) - Fix regression restoring the ID_PFR1_EL1 register (20251030122707.2033690-1-maz(a)kernel.org - Fix vgic ITS locking issues when LPIs are not directly injected (20251107184847.1784820-1-oupton(a)kernel.org) * Test fixes - Correct target CPU programming in vgic_lpi_stress selftest (20251020145946.48288-1-mdittgen(a)amazon.de) - Fix exposure of SCTLR2_EL2 and ZCR_EL2 in get-reg-list selftest (20251023-b4-kvm-arm64-get-reg-list-sctlr-el2-v1-1-088f88ff992a(a)kernel.org) (20251024-kvm-arm64-get-reg-list-zcr-el2-v1-1-0cd0ff75e22f(a)kernel.org) * Misc - Update Oliver's email address (20251107012830.1708225-1-oupton(a)kernel.org) ---------------------------------------------------------------- Marc Zyngier (3): KVM: arm64: Make all 32bit ID registers fully writable KVM: arm64: Set ID_{AA64PFR0,PFR1}_EL1.GIC when GICv3 is configured KVM: arm64: Limit clearing of ID_{AA64PFR0,PFR1}_EL1.GIC to userspace irqchip Mark Brown (2): KVM: arm64: selftests: Add SCTLR2_EL2 to get-reg-list KVM: arm64: selftests: Filter ZCR_EL2 in get-reg-list Maximilian Dittgen (1): KVM: selftests: fix MAPC RDbase target formatting in vgic_lpi_stress Oliver Upton (3): KVM: arm64: vgic-v3: Reinstate IRQ lock ordering for LPI xarray KVM: arm64: vgic-v3: Release reserved slot outside of lpi_xa's lock MAINTAINERS: Switch myself to using kernel.org address Sascha Bischoff (1): KVM: arm64: vgic-v3: Trap all if no in-kernel irqchip Sebastian Ene (1): KVM: arm64: Check the untrusted offset in FF-A memory share Vincent Donnefort (1): KVM: arm64: Check range args for pKVM mem transitions .mailmap | 3 +- MAINTAINERS | 2 +- arch/arm64/kvm/hyp/nvhe/ffa.c | 9 ++- arch/arm64/kvm/hyp/nvhe/mem_protect.c | 28 +++++++++ arch/arm64/kvm/sys_regs.c | 71 ++++++++++++---------- arch/arm64/kvm/vgic/vgic-debug.c | 16 +++-- arch/arm64/kvm/vgic/vgic-init.c | 16 ++++- arch/arm64/kvm/vgic/vgic-its.c | 18 +++--- arch/arm64/kvm/vgic/vgic-v3.c | 3 +- arch/arm64/kvm/vgic/vgic.c | 23 ++++--- tools/testing/selftests/kvm/arm64/get-reg-list.c | 3 + tools/testing/selftests/kvm/lib/arm64/gic_v3_its.c | 9 ++- 12 files changed, 137 insertions(+), 64 deletions(-)

1 week, 5 days

2
1
0 0

[PATCH v2 0/1] Bluetooth: btusb: add new custom firmwares

by Shuai Zhang

add new custom firmwares Please refer to the link for information about the qcs2066 folder. a3f9f6dd047a ("Bluetooth: btusb: QCA: Support downloading custom-made firmwares") Changes for v2 - Add a more detailed description of the patch. - remove CC stable - V1 link https://lore.kernel.org/all/20251107021345.2759890-1-quic_shuaz@quicinc.com/ Shuai Zhang (1): Bluetooth: btusb: add new custom firmwares drivers/bluetooth/btusb.c | 1 + 1 file changed, 1 insertion(+) -- 2.34.1

1 week, 5 days

3
4
0 0

FAILED: patch "[PATCH] wifi: mac80211: use wiphy_hrtimer_work for ttlm_work" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y git checkout FETCH_HEAD git cherry-pick -x dfa865d490b1bd252045463588a91a4d3c82f3c8 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025110934-construct-gestate-8ed7@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From dfa865d490b1bd252045463588a91a4d3c82f3c8 Mon Sep 17 00:00:00 2001 From: Benjamin Berg <benjamin.berg(a)intel.com> Date: Tue, 28 Oct 2025 12:58:38 +0200 Subject: [PATCH] wifi: mac80211: use wiphy_hrtimer_work for ttlm_work The work item may be scheduled relatively far in the future. As the event happens at a specific point in time, the normal timer accuracy is not sufficient in that case. Switch to use wiphy_hrtimer_work so that the accuracy is sufficient. CC: stable(a)vger.kernel.org Fixes: 702e80470a33 ("wifi: mac80211: support handling of advertised TID-to-link mapping") Signed-off-by: Benjamin Berg <benjamin.berg(a)intel.com> Reviewed-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit(a)intel.com> Link: https://patch.msgid.link/20251028125710.83c2c611545e.I35498a6d883ea24b0dc49… Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h index 73fd86ec1bce..eb22279c6e01 100644 --- a/net/mac80211/ieee80211_i.h +++ b/net/mac80211/ieee80211_i.h @@ -616,7 +616,7 @@ struct ieee80211_if_managed { u16 removed_links; /* TID-to-link mapping support */ - struct wiphy_delayed_work ttlm_work; + struct wiphy_hrtimer_work ttlm_work; struct ieee80211_adv_ttlm_info ttlm_info; struct wiphy_work teardown_ttlm_work; diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c index 3b5827ea438e..623a46b3214e 100644 --- a/net/mac80211/mlme.c +++ b/net/mac80211/mlme.c @@ -45,7 +45,7 @@ #define IEEE80211_ASSOC_TIMEOUT_SHORT (HZ / 10) #define IEEE80211_ASSOC_MAX_TRIES 3 -#define IEEE80211_ADV_TTLM_SAFETY_BUFFER_MS msecs_to_jiffies(100) +#define IEEE80211_ADV_TTLM_SAFETY_BUFFER_MS (100 * USEC_PER_MSEC) #define IEEE80211_ADV_TTLM_ST_UNDERFLOW 0xff00 #define IEEE80211_NEG_TTLM_REQ_TIMEOUT (HZ / 5) @@ -4242,7 +4242,7 @@ static void ieee80211_set_disassoc(struct ieee80211_sub_if_data *sdata, memset(&sdata->u.mgd.ttlm_info, 0, sizeof(sdata->u.mgd.ttlm_info)); - wiphy_delayed_work_cancel(sdata->local->hw.wiphy, &ifmgd->ttlm_work); + wiphy_hrtimer_work_cancel(sdata->local->hw.wiphy, &ifmgd->ttlm_work); memset(&sdata->vif.neg_ttlm, 0, sizeof(sdata->vif.neg_ttlm)); wiphy_delayed_work_cancel(sdata->local->hw.wiphy, @@ -7095,7 +7095,7 @@ static void ieee80211_process_adv_ttlm(struct ieee80211_sub_if_data *sdata, /* if a planned TID-to-link mapping was cancelled - * abort it */ - wiphy_delayed_work_cancel(sdata->local->hw.wiphy, + wiphy_hrtimer_work_cancel(sdata->local->hw.wiphy, &sdata->u.mgd.ttlm_work); } else if (sdata->u.mgd.ttlm_info.active) { /* if no TID-to-link element, set to default mapping in @@ -7130,7 +7130,7 @@ static void ieee80211_process_adv_ttlm(struct ieee80211_sub_if_data *sdata, if (ttlm_info.switch_time) { u16 beacon_ts_tu, st_tu, delay; - u32 delay_jiffies; + u64 delay_usec; u64 mask; /* The t2l map switch time is indicated with a partial @@ -7152,23 +7152,23 @@ static void ieee80211_process_adv_ttlm(struct ieee80211_sub_if_data *sdata, if (delay > IEEE80211_ADV_TTLM_ST_UNDERFLOW) return; - delay_jiffies = TU_TO_JIFFIES(delay); + delay_usec = ieee80211_tu_to_usec(delay); /* Link switching can take time, so schedule it * 100ms before to be ready on time */ - if (delay_jiffies > IEEE80211_ADV_TTLM_SAFETY_BUFFER_MS) - delay_jiffies -= + if (delay_usec > IEEE80211_ADV_TTLM_SAFETY_BUFFER_MS) + delay_usec -= IEEE80211_ADV_TTLM_SAFETY_BUFFER_MS; else - delay_jiffies = 0; + delay_usec = 0; sdata->u.mgd.ttlm_info = ttlm_info; - wiphy_delayed_work_cancel(sdata->local->hw.wiphy, + wiphy_hrtimer_work_cancel(sdata->local->hw.wiphy, &sdata->u.mgd.ttlm_work); - wiphy_delayed_work_queue(sdata->local->hw.wiphy, + wiphy_hrtimer_work_queue(sdata->local->hw.wiphy, &sdata->u.mgd.ttlm_work, - delay_jiffies); + us_to_ktime(delay_usec)); return; } } @@ -8802,7 +8802,7 @@ void ieee80211_sta_setup_sdata(struct ieee80211_sub_if_data *sdata) timer_setup(&ifmgd->conn_mon_timer, ieee80211_sta_conn_mon_timer, 0); wiphy_delayed_work_init(&ifmgd->tx_tspec_wk, ieee80211_sta_handle_tspec_ac_params_wk); - wiphy_delayed_work_init(&ifmgd->ttlm_work, + wiphy_hrtimer_work_init(&ifmgd->ttlm_work, ieee80211_tid_to_link_map_work); wiphy_delayed_work_init(&ifmgd->neg_ttlm_timeout_work, ieee80211_neg_ttlm_timeout_work);

1 week, 5 days

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror