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

FAILED: patch "[PATCH] wifi: cfg80211: add an hrtimer based delayed work item" 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 7ceba45a6658ce637da334cd0ebf27f4ede6c0fe # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025110956-qualified-stock-5d33@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 7ceba45a6658ce637da334cd0ebf27f4ede6c0fe Mon Sep 17 00:00:00 2001 From: Benjamin Berg <benjamin.berg(a)intel.com> Date: Tue, 28 Oct 2025 12:58:37 +0200 Subject: [PATCH] wifi: cfg80211: add an hrtimer based delayed work item The normal timer mechanism assume that timeout further in the future need a lower accuracy. As an example, the granularity for a timer scheduled 4096 ms in the future on a 1000 Hz system is already 512 ms. This granularity is perfectly sufficient for e.g. timeouts, but there are other types of events that will happen at a future point in time and require a higher accuracy. Add a new wiphy_hrtimer_work type that uses an hrtimer internally. The API is almost identical to the existing wiphy_delayed_work and it can be used as a drop-in replacement after minor adjustments. The work will be scheduled relative to the current time with a slack of 1 millisecond. CC: stable(a)vger.kernel.org # 6.4+ 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.7f13a2adc5eb.I01b5af0363869864b0580… Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index 781624f5913a..820e299f06b5 100644 --- a/include/net/cfg80211.h +++ b/include/net/cfg80211.h @@ -6435,6 +6435,11 @@ static inline void wiphy_delayed_work_init(struct wiphy_delayed_work *dwork, * after wiphy_lock() was called. Therefore, wiphy_cancel_work() can * use just cancel_work() instead of cancel_work_sync(), it requires * being in a section protected by wiphy_lock(). + * + * Note that these are scheduled with a timer where the accuracy + * becomes less the longer in the future the scheduled timer is. Use + * wiphy_hrtimer_work_queue() if the timer must be not be late by more + * than approximately 10 percent. */ void wiphy_delayed_work_queue(struct wiphy *wiphy, struct wiphy_delayed_work *dwork, @@ -6506,6 +6511,79 @@ void wiphy_delayed_work_flush(struct wiphy *wiphy, bool wiphy_delayed_work_pending(struct wiphy *wiphy, struct wiphy_delayed_work *dwork); +struct wiphy_hrtimer_work { + struct wiphy_work work; + struct wiphy *wiphy; + struct hrtimer timer; +}; + +enum hrtimer_restart wiphy_hrtimer_work_timer(struct hrtimer *t); + +static inline void wiphy_hrtimer_work_init(struct wiphy_hrtimer_work *hrwork, + wiphy_work_func_t func) +{ + hrtimer_setup(&hrwork->timer, wiphy_hrtimer_work_timer, + CLOCK_BOOTTIME, HRTIMER_MODE_REL); + wiphy_work_init(&hrwork->work, func); +} + +/** + * wiphy_hrtimer_work_queue - queue hrtimer work for the wiphy + * @wiphy: the wiphy to queue for + * @hrwork: the high resolution timer worker + * @delay: the delay given as a ktime_t + * + * Please refer to wiphy_delayed_work_queue(). The difference is that + * the hrtimer work uses a high resolution timer for scheduling. This + * may be needed if timeouts might be scheduled further in the future + * and the accuracy of the normal timer is not sufficient. + * + * Expect a delay of a few milliseconds as the timer is scheduled + * with some slack and some more time may pass between queueing the + * work and its start. + */ +void wiphy_hrtimer_work_queue(struct wiphy *wiphy, + struct wiphy_hrtimer_work *hrwork, + ktime_t delay); + +/** + * wiphy_hrtimer_work_cancel - cancel previously queued hrtimer work + * @wiphy: the wiphy, for debug purposes + * @hrtimer: the hrtimer work to cancel + * + * Cancel the work *without* waiting for it, this assumes being + * called under the wiphy mutex acquired by wiphy_lock(). + */ +void wiphy_hrtimer_work_cancel(struct wiphy *wiphy, + struct wiphy_hrtimer_work *hrtimer); + +/** + * wiphy_hrtimer_work_flush - flush previously queued hrtimer work + * @wiphy: the wiphy, for debug purposes + * @hrwork: the hrtimer work to flush + * + * Flush the work (i.e. run it if pending). This must be called + * under the wiphy mutex acquired by wiphy_lock(). + */ +void wiphy_hrtimer_work_flush(struct wiphy *wiphy, + struct wiphy_hrtimer_work *hrwork); + +/** + * wiphy_hrtimer_work_pending - Find out whether a wiphy hrtimer + * work item is currently pending. + * + * @wiphy: the wiphy, for debug purposes + * @hrwork: the hrtimer work in question + * + * Return: true if timer is pending, false otherwise + * + * Please refer to the wiphy_delayed_work_pending() documentation as + * this is the equivalent function for hrtimer based delayed work + * items. + */ +bool wiphy_hrtimer_work_pending(struct wiphy *wiphy, + struct wiphy_hrtimer_work *hrwork); + /** * enum ieee80211_ap_reg_power - regulatory power for an Access Point * diff --git a/net/wireless/core.c b/net/wireless/core.c index 797f9f2004a6..54a34d8d356e 100644 --- a/net/wireless/core.c +++ b/net/wireless/core.c @@ -1787,6 +1787,62 @@ bool wiphy_delayed_work_pending(struct wiphy *wiphy, } EXPORT_SYMBOL_GPL(wiphy_delayed_work_pending); +enum hrtimer_restart wiphy_hrtimer_work_timer(struct hrtimer *t) +{ + struct wiphy_hrtimer_work *hrwork = + container_of(t, struct wiphy_hrtimer_work, timer); + + wiphy_work_queue(hrwork->wiphy, &hrwork->work); + + return HRTIMER_NORESTART; +} +EXPORT_SYMBOL_GPL(wiphy_hrtimer_work_timer); + +void wiphy_hrtimer_work_queue(struct wiphy *wiphy, + struct wiphy_hrtimer_work *hrwork, + ktime_t delay) +{ + trace_wiphy_hrtimer_work_queue(wiphy, &hrwork->work, delay); + + if (!delay) { + hrtimer_cancel(&hrwork->timer); + wiphy_work_queue(wiphy, &hrwork->work); + return; + } + + hrwork->wiphy = wiphy; + hrtimer_start_range_ns(&hrwork->timer, delay, + 1000 * NSEC_PER_USEC, HRTIMER_MODE_REL); +} +EXPORT_SYMBOL_GPL(wiphy_hrtimer_work_queue); + +void wiphy_hrtimer_work_cancel(struct wiphy *wiphy, + struct wiphy_hrtimer_work *hrwork) +{ + lockdep_assert_held(&wiphy->mtx); + + hrtimer_cancel(&hrwork->timer); + wiphy_work_cancel(wiphy, &hrwork->work); +} +EXPORT_SYMBOL_GPL(wiphy_hrtimer_work_cancel); + +void wiphy_hrtimer_work_flush(struct wiphy *wiphy, + struct wiphy_hrtimer_work *hrwork) +{ + lockdep_assert_held(&wiphy->mtx); + + hrtimer_cancel(&hrwork->timer); + wiphy_work_flush(wiphy, &hrwork->work); +} +EXPORT_SYMBOL_GPL(wiphy_hrtimer_work_flush); + +bool wiphy_hrtimer_work_pending(struct wiphy *wiphy, + struct wiphy_hrtimer_work *hrwork) +{ + return hrtimer_is_queued(&hrwork->timer); +} +EXPORT_SYMBOL_GPL(wiphy_hrtimer_work_pending); + static int __init cfg80211_init(void) { int err; diff --git a/net/wireless/trace.h b/net/wireless/trace.h index 8a4c34112eb5..2b71f1d867a0 100644 --- a/net/wireless/trace.h +++ b/net/wireless/trace.h @@ -304,6 +304,27 @@ TRACE_EVENT(wiphy_delayed_work_queue, __entry->delay) ); +TRACE_EVENT(wiphy_hrtimer_work_queue, + TP_PROTO(struct wiphy *wiphy, struct wiphy_work *work, + ktime_t delay), + TP_ARGS(wiphy, work, delay), + TP_STRUCT__entry( + WIPHY_ENTRY + __field(void *, instance) + __field(void *, func) + __field(ktime_t, delay) + ), + TP_fast_assign( + WIPHY_ASSIGN; + __entry->instance = work; + __entry->func = work->func; + __entry->delay = delay; + ), + TP_printk(WIPHY_PR_FMT " instance=%p func=%pS delay=%llu", + WIPHY_PR_ARG, __entry->instance, __entry->func, + __entry->delay) +); + TRACE_EVENT(wiphy_work_worker_start, TP_PROTO(struct wiphy *wiphy), TP_ARGS(wiphy),

1 week, 6 days

2
1
0 0

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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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 .

2 weeks

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(-)

2 weeks

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

2 weeks

3
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror