From: Sasha Levin Date: Sat, 15 Mar 2025 13:34:17 +0000 (-0400) Subject: Fixes for 5.15 X-Git-Tag: v6.6.84~44 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=95b5007800cc71ba5b9033acc631931f74d461d3;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 5.15 Signed-off-by: Sasha Levin --- diff --git a/queue-5.15/acpi-resource-irq-override-for-eluktronics-mech-17.patch b/queue-5.15/acpi-resource-irq-override-for-eluktronics-mech-17.patch new file mode 100644 index 0000000000..32c1bee00b --- /dev/null +++ b/queue-5.15/acpi-resource-irq-override-for-eluktronics-mech-17.patch @@ -0,0 +1,43 @@ +From c7c610f1efe64f09e5c264bb7b5894ca29f52f27 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 27 Jan 2025 02:39:02 -0700 +Subject: ACPI: resource: IRQ override for Eluktronics MECH-17 + +From: Gannon Kolding + +[ Upstream commit 607ab6f85f4194b644ea95ac5fe660ef575db3b4 ] + +The Eluktronics MECH-17 (GM7RG7N) needs IRQ overriding for the +keyboard to work. + +Adding a DMI_MATCH entry for this laptop model makes the internal +keyboard function normally. + +Signed-off-by: Gannon Kolding +Link: https://patch.msgid.link/20250127093902.328361-1-gannon.kolding@gmail.com +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Sasha Levin +--- + drivers/acpi/resource.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c +index 56bbdd2f9a40d..0735ad7f01e22 100644 +--- a/drivers/acpi/resource.c ++++ b/drivers/acpi/resource.c +@@ -556,6 +556,12 @@ static const struct dmi_system_id maingear_laptop[] = { + DMI_MATCH(DMI_BOARD_NAME, "RP-15"), + }, + }, ++ { ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "Eluktronics Inc."), ++ DMI_MATCH(DMI_BOARD_NAME, "MECH-17"), ++ }, ++ }, + { + /* TongFang GM6XGxX/TUXEDO Stellaris 16 Gen5 AMD */ + .matches = { +-- +2.39.5 + diff --git a/queue-5.15/alpha-elf-fix-misc-setarch-test-of-util-linux-by-rem.patch b/queue-5.15/alpha-elf-fix-misc-setarch-test-of-util-linux-by-rem.patch new file mode 100644 index 0000000000..e0723a0a3e --- /dev/null +++ b/queue-5.15/alpha-elf-fix-misc-setarch-test-of-util-linux-by-rem.patch @@ -0,0 +1,152 @@ +From 54014234391bc12703f6b89356c3e4a831b4921e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 12 Jan 2025 23:39:01 -0600 +Subject: alpha/elf: Fix misc/setarch test of util-linux by removing 32bit + support + +From: Eric W. Biederman + +[ Upstream commit b029628be267cba3c7684ec684749fe3e4372398 ] + +Richard Henderson writes[1]: + +> There was a Spec benchmark (I forget which) which was memory bound and ran +> twice as fast with 32-bit pointers. +> +> I copied the idea from DEC to the ELF abi, but never did all the other work +> to allow the toolchain to take advantage. +> +> Amusingly, a later Spec changed the benchmark data sets to not fit into a +> 32-bit address space, specifically because of this. +> +> I expect one could delete the ELF bit and personality and no one would +> notice. Not even the 10 remaining Alpha users. + +In [2] it was pointed out that parts of setarch weren't working +properly on alpha because it has it's own SET_PERSONALITY +implementation. In the discussion that followed Richard Henderson +pointed out that the 32bit pointer support for alpha was never +completed. + +Fix this by removing alpha's 32bit pointer support. + +As a bit of paranoia refuse to execute any alpha binaries that have +the EF_ALPHA_32BIT flag set. Just in case someone somewhere has +binaries that try to use alpha's 32bit pointer support. + +Link: https://lkml.kernel.org/r/CAFXwXrkgu=4Qn-v1PjnOR4SG0oUb9LSa0g6QXpBq4ttm52pJOQ@mail.gmail.com [1] +Link: https://lkml.kernel.org/r/20250103140148.370368-1-glaubitz@physik.fu-berlin.de [2] +Signed-off-by: Eric W. Biederman +Reviewed-by: Richard Henderson +Reviewed-by: Arnd Bergmann +Reviewed-by: John Paul Adrian Glaubitz +Tested-by: John Paul Adrian Glaubitz +Link: https://lore.kernel.org/r/87y0zfs26i.fsf_-_@email.froward.int.ebiederm.org +Signed-off-by: Kees Cook +Signed-off-by: Sasha Levin +--- + arch/alpha/include/asm/elf.h | 6 +----- + arch/alpha/include/asm/pgtable.h | 2 +- + arch/alpha/include/asm/processor.h | 8 ++------ + arch/alpha/kernel/osf_sys.c | 11 ++--------- + 4 files changed, 6 insertions(+), 21 deletions(-) + +diff --git a/arch/alpha/include/asm/elf.h b/arch/alpha/include/asm/elf.h +index 8049997fa372a..2039a8c8d5473 100644 +--- a/arch/alpha/include/asm/elf.h ++++ b/arch/alpha/include/asm/elf.h +@@ -74,7 +74,7 @@ typedef elf_fpreg_t elf_fpregset_t[ELF_NFPREG]; + /* + * This is used to ensure we don't load something for the wrong architecture. + */ +-#define elf_check_arch(x) ((x)->e_machine == EM_ALPHA) ++#define elf_check_arch(x) (((x)->e_machine == EM_ALPHA) && !((x)->e_flags & EF_ALPHA_32BIT)) + + /* + * These are used to set parameters in the core dumps. +@@ -145,10 +145,6 @@ extern int dump_elf_task_fp(elf_fpreg_t *dest, struct task_struct *task); + : amask (AMASK_CIX) ? "ev6" : "ev67"); \ + }) + +-#define SET_PERSONALITY(EX) \ +- set_personality(((EX).e_flags & EF_ALPHA_32BIT) \ +- ? PER_LINUX_32BIT : PER_LINUX) +- + extern int alpha_l1i_cacheshape; + extern int alpha_l1d_cacheshape; + extern int alpha_l2_cacheshape; +diff --git a/arch/alpha/include/asm/pgtable.h b/arch/alpha/include/asm/pgtable.h +index 02f0429f1068a..8e3cf3c9f913d 100644 +--- a/arch/alpha/include/asm/pgtable.h ++++ b/arch/alpha/include/asm/pgtable.h +@@ -340,7 +340,7 @@ extern inline pte_t mk_swap_pte(unsigned long type, unsigned long offset) + + extern void paging_init(void); + +-/* We have our own get_unmapped_area to cope with ADDR_LIMIT_32BIT. */ ++/* We have our own get_unmapped_area */ + #define HAVE_ARCH_UNMAPPED_AREA + + #endif /* _ALPHA_PGTABLE_H */ +diff --git a/arch/alpha/include/asm/processor.h b/arch/alpha/include/asm/processor.h +index 6100431da07a3..d27db62c3247d 100644 +--- a/arch/alpha/include/asm/processor.h ++++ b/arch/alpha/include/asm/processor.h +@@ -8,23 +8,19 @@ + #ifndef __ASM_ALPHA_PROCESSOR_H + #define __ASM_ALPHA_PROCESSOR_H + +-#include /* for ADDR_LIMIT_32BIT */ +- + /* + * We have a 42-bit user address space: 4TB user VM... + */ + #define TASK_SIZE (0x40000000000UL) + +-#define STACK_TOP \ +- (current->personality & ADDR_LIMIT_32BIT ? 0x80000000 : 0x00120000000UL) ++#define STACK_TOP (0x00120000000UL) + + #define STACK_TOP_MAX 0x00120000000UL + + /* This decides where the kernel will search for a free chunk of vm + * space during mmap's. + */ +-#define TASK_UNMAPPED_BASE \ +- ((current->personality & ADDR_LIMIT_32BIT) ? 0x40000000 : TASK_SIZE / 2) ++#define TASK_UNMAPPED_BASE (TASK_SIZE / 2) + + typedef struct { + unsigned long seg; +diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c +index 8bbeebb73cf03..2dfb69a2ae43a 100644 +--- a/arch/alpha/kernel/osf_sys.c ++++ b/arch/alpha/kernel/osf_sys.c +@@ -1212,8 +1212,7 @@ SYSCALL_DEFINE1(old_adjtimex, struct timex32 __user *, txc_p) + return ret; + } + +-/* Get an address range which is currently unmapped. Similar to the +- generic version except that we know how to honor ADDR_LIMIT_32BIT. */ ++/* Get an address range which is currently unmapped. */ + + static unsigned long + arch_get_unmapped_area_1(unsigned long addr, unsigned long len, +@@ -1235,13 +1234,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr, + unsigned long len, unsigned long pgoff, + unsigned long flags) + { +- unsigned long limit; +- +- /* "32 bit" actually means 31 bit, since pointers sign extend. */ +- if (current->personality & ADDR_LIMIT_32BIT) +- limit = 0x80000000; +- else +- limit = TASK_SIZE; ++ unsigned long limit = TASK_SIZE; + + if (len > limit) + return -ENOMEM; +-- +2.39.5 + diff --git a/queue-5.15/asoc-arizona-madera-use-fsleep-in-up-down-dapm-event.patch b/queue-5.15/asoc-arizona-madera-use-fsleep-in-up-down-dapm-event.patch new file mode 100644 index 0000000000..e02bc3b711 --- /dev/null +++ b/queue-5.15/asoc-arizona-madera-use-fsleep-in-up-down-dapm-event.patch @@ -0,0 +1,174 @@ +From 9b2e056221a2e6eccbe93293e1f72e9ccf7210c9 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 5 Feb 2025 16:08:46 +0000 +Subject: ASoC: arizona/madera: use fsleep() in up/down DAPM event delays. + +From: Vitaly Rodionov + +[ Upstream commit 679074942c2502a95842a80471d8fb718165ac77 ] + +Using `fsleep` instead of `msleep` resolves some customer complaints +regarding the precision of up/down DAPM event timing. `fsleep()` +automatically selects the appropriate sleep function, making the delay +time more predictable. + +Signed-off-by: Vitaly Rodionov +Link: https://patch.msgid.link/20250205160849.500306-1-vitalyr@opensource.cirrus.com +Reviewed-by: Charles Keepax +Signed-off-by: Mark Brown +Signed-off-by: Sasha Levin +--- + sound/soc/codecs/arizona.c | 14 +++++++------- + sound/soc/codecs/madera.c | 10 +++++----- + sound/soc/codecs/wm5110.c | 8 ++++---- + 3 files changed, 16 insertions(+), 16 deletions(-) + +diff --git a/sound/soc/codecs/arizona.c b/sound/soc/codecs/arizona.c +index e32871b3f68ac..be207350b7124 100644 +--- a/sound/soc/codecs/arizona.c ++++ b/sound/soc/codecs/arizona.c +@@ -967,7 +967,7 @@ int arizona_out_ev(struct snd_soc_dapm_widget *w, + case ARIZONA_OUT3L_ENA_SHIFT: + case ARIZONA_OUT3R_ENA_SHIFT: + priv->out_up_pending++; +- priv->out_up_delay += 17; ++ priv->out_up_delay += 17000; + break; + case ARIZONA_OUT4L_ENA_SHIFT: + case ARIZONA_OUT4R_ENA_SHIFT: +@@ -977,7 +977,7 @@ int arizona_out_ev(struct snd_soc_dapm_widget *w, + case WM8997: + break; + default: +- priv->out_up_delay += 10; ++ priv->out_up_delay += 10000; + break; + } + break; +@@ -999,7 +999,7 @@ int arizona_out_ev(struct snd_soc_dapm_widget *w, + if (!priv->out_up_pending && priv->out_up_delay) { + dev_dbg(component->dev, "Power up delay: %d\n", + priv->out_up_delay); +- msleep(priv->out_up_delay); ++ fsleep(priv->out_up_delay); + priv->out_up_delay = 0; + } + break; +@@ -1017,7 +1017,7 @@ int arizona_out_ev(struct snd_soc_dapm_widget *w, + case ARIZONA_OUT3L_ENA_SHIFT: + case ARIZONA_OUT3R_ENA_SHIFT: + priv->out_down_pending++; +- priv->out_down_delay++; ++ priv->out_down_delay += 1000; + break; + case ARIZONA_OUT4L_ENA_SHIFT: + case ARIZONA_OUT4R_ENA_SHIFT: +@@ -1028,10 +1028,10 @@ int arizona_out_ev(struct snd_soc_dapm_widget *w, + break; + case WM8998: + case WM1814: +- priv->out_down_delay += 5; ++ priv->out_down_delay += 5000; + break; + default: +- priv->out_down_delay++; ++ priv->out_down_delay += 1000; + break; + } + break; +@@ -1053,7 +1053,7 @@ int arizona_out_ev(struct snd_soc_dapm_widget *w, + if (!priv->out_down_pending && priv->out_down_delay) { + dev_dbg(component->dev, "Power down delay: %d\n", + priv->out_down_delay); +- msleep(priv->out_down_delay); ++ fsleep(priv->out_down_delay); + priv->out_down_delay = 0; + } + break; +diff --git a/sound/soc/codecs/madera.c b/sound/soc/codecs/madera.c +index fd4fa1d5d2d12..5775898fc6f9e 100644 +--- a/sound/soc/codecs/madera.c ++++ b/sound/soc/codecs/madera.c +@@ -2322,10 +2322,10 @@ int madera_out_ev(struct snd_soc_dapm_widget *w, + case CS42L92: + case CS47L92: + case CS47L93: +- out_up_delay = 6; ++ out_up_delay = 6000; + break; + default: +- out_up_delay = 17; ++ out_up_delay = 17000; + break; + } + +@@ -2356,7 +2356,7 @@ int madera_out_ev(struct snd_soc_dapm_widget *w, + case MADERA_OUT3R_ENA_SHIFT: + priv->out_up_pending--; + if (!priv->out_up_pending) { +- msleep(priv->out_up_delay); ++ fsleep(priv->out_up_delay); + priv->out_up_delay = 0; + } + break; +@@ -2375,7 +2375,7 @@ int madera_out_ev(struct snd_soc_dapm_widget *w, + case MADERA_OUT3L_ENA_SHIFT: + case MADERA_OUT3R_ENA_SHIFT: + priv->out_down_pending++; +- priv->out_down_delay++; ++ priv->out_down_delay += 1000; + break; + default: + break; +@@ -2392,7 +2392,7 @@ int madera_out_ev(struct snd_soc_dapm_widget *w, + case MADERA_OUT3R_ENA_SHIFT: + priv->out_down_pending--; + if (!priv->out_down_pending) { +- msleep(priv->out_down_delay); ++ fsleep(priv->out_down_delay); + priv->out_down_delay = 0; + } + break; +diff --git a/sound/soc/codecs/wm5110.c b/sound/soc/codecs/wm5110.c +index 7c6e01720d651..bc3dfb53ba953 100644 +--- a/sound/soc/codecs/wm5110.c ++++ b/sound/soc/codecs/wm5110.c +@@ -302,7 +302,7 @@ static int wm5110_hp_pre_enable(struct snd_soc_dapm_widget *w) + } else { + wseq = wm5110_no_dre_left_enable; + nregs = ARRAY_SIZE(wm5110_no_dre_left_enable); +- priv->out_up_delay += 10; ++ priv->out_up_delay += 10000; + } + break; + case ARIZONA_OUT1R_ENA_SHIFT: +@@ -312,7 +312,7 @@ static int wm5110_hp_pre_enable(struct snd_soc_dapm_widget *w) + } else { + wseq = wm5110_no_dre_right_enable; + nregs = ARRAY_SIZE(wm5110_no_dre_right_enable); +- priv->out_up_delay += 10; ++ priv->out_up_delay += 10000; + } + break; + default: +@@ -338,7 +338,7 @@ static int wm5110_hp_pre_disable(struct snd_soc_dapm_widget *w) + snd_soc_component_update_bits(component, + ARIZONA_SPARE_TRIGGERS, + ARIZONA_WS_TRG1, 0); +- priv->out_down_delay += 27; ++ priv->out_down_delay += 27000; + } + break; + case ARIZONA_OUT1R_ENA_SHIFT: +@@ -350,7 +350,7 @@ static int wm5110_hp_pre_disable(struct snd_soc_dapm_widget *w) + snd_soc_component_update_bits(component, + ARIZONA_SPARE_TRIGGERS, + ARIZONA_WS_TRG2, 0); +- priv->out_down_delay += 27; ++ priv->out_down_delay += 27000; + } + break; + default: +-- +2.39.5 + diff --git a/queue-5.15/asoc-rsnd-don-t-indicate-warning-on-rsnd_kctrl_accep.patch b/queue-5.15/asoc-rsnd-don-t-indicate-warning-on-rsnd_kctrl_accep.patch new file mode 100644 index 0000000000..d757a11afb --- /dev/null +++ b/queue-5.15/asoc-rsnd-don-t-indicate-warning-on-rsnd_kctrl_accep.patch @@ -0,0 +1,125 @@ +From 86fc7b4ba3931e34bf5f4a5e8dcdcab156fd66ee Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 5 Feb 2025 00:20:42 +0000 +Subject: ASoC: rsnd: don't indicate warning on rsnd_kctrl_accept_runtime() + +From: Kuninori Morimoto + +[ Upstream commit c3fc002b206c6c83d1e3702b979733002ba6fb2c ] + +rsnd_kctrl_accept_runtime() (1) is used for runtime convert rate +(= Synchronous SRC Mode). Now, rsnd driver has 2 kctrls for it + +(A): "SRC Out Rate Switch" +(B): "SRC Out Rate" // it calls (1) + +(A): can be called anytime +(B): can be called only runtime, and will indicate warning if it was used + at non-runtime. + +To use runtime convert rate (= Synchronous SRC Mode), user might uses +command in below order. + +(X): > amixer set "SRC Out Rate" on + > aplay xxx.wav & +(Y): > amixer set "SRC Out Rate" 48010 // convert rate to 48010Hz + +(Y): calls B +(X): calls both A and B. + +In this case, when user calls (X), it calls both (A) and (B), but it is not +yet start running. So, (B) will indicate warning. + +This warning was added by commit b5c088689847 ("ASoC: rsnd: add warning +message to rsnd_kctrl_accept_runtime()"), but the message sounds like the +operation was not correct. Let's update warning message. + +The message is very SRC specific, implement it in src.c + +Signed-off-by: Kuninori Morimoto +Reviewed-by: Yoshihiro Shimoda +Link: https://patch.msgid.link/8734gt2qed.wl-kuninori.morimoto.gx@renesas.com +Signed-off-by: Mark Brown +Signed-off-by: Sasha Levin +--- + sound/soc/sh/rcar/core.c | 14 -------------- + sound/soc/sh/rcar/rsnd.h | 1 - + sound/soc/sh/rcar/src.c | 18 +++++++++++++++++- + 3 files changed, 17 insertions(+), 16 deletions(-) + +diff --git a/sound/soc/sh/rcar/core.c b/sound/soc/sh/rcar/core.c +index af8ef2a27d341..65022ba5c5875 100644 +--- a/sound/soc/sh/rcar/core.c ++++ b/sound/soc/sh/rcar/core.c +@@ -1694,20 +1694,6 @@ int rsnd_kctrl_accept_anytime(struct rsnd_dai_stream *io) + return 1; + } + +-int rsnd_kctrl_accept_runtime(struct rsnd_dai_stream *io) +-{ +- struct snd_pcm_runtime *runtime = rsnd_io_to_runtime(io); +- struct rsnd_priv *priv = rsnd_io_to_priv(io); +- struct device *dev = rsnd_priv_to_dev(priv); +- +- if (!runtime) { +- dev_warn(dev, "Can't update kctrl when idle\n"); +- return 0; +- } +- +- return 1; +-} +- + struct rsnd_kctrl_cfg *rsnd_kctrl_init_m(struct rsnd_kctrl_cfg_m *cfg) + { + cfg->cfg.val = cfg->val; +diff --git a/sound/soc/sh/rcar/rsnd.h b/sound/soc/sh/rcar/rsnd.h +index f8ef6836ef84e..690f4932357c1 100644 +--- a/sound/soc/sh/rcar/rsnd.h ++++ b/sound/soc/sh/rcar/rsnd.h +@@ -742,7 +742,6 @@ struct rsnd_kctrl_cfg_s { + #define rsnd_kctrl_vals(x) ((x).val) /* = (x).cfg.val[0] */ + + int rsnd_kctrl_accept_anytime(struct rsnd_dai_stream *io); +-int rsnd_kctrl_accept_runtime(struct rsnd_dai_stream *io); + struct rsnd_kctrl_cfg *rsnd_kctrl_init_m(struct rsnd_kctrl_cfg_m *cfg); + struct rsnd_kctrl_cfg *rsnd_kctrl_init_s(struct rsnd_kctrl_cfg_s *cfg); + int rsnd_kctrl_new(struct rsnd_mod *mod, +diff --git a/sound/soc/sh/rcar/src.c b/sound/soc/sh/rcar/src.c +index f832165e46bc0..9893839666d7b 100644 +--- a/sound/soc/sh/rcar/src.c ++++ b/sound/soc/sh/rcar/src.c +@@ -530,6 +530,22 @@ static irqreturn_t rsnd_src_interrupt(int irq, void *data) + return IRQ_HANDLED; + } + ++static int rsnd_src_kctrl_accept_runtime(struct rsnd_dai_stream *io) ++{ ++ struct snd_pcm_runtime *runtime = rsnd_io_to_runtime(io); ++ ++ if (!runtime) { ++ struct rsnd_priv *priv = rsnd_io_to_priv(io); ++ struct device *dev = rsnd_priv_to_dev(priv); ++ ++ dev_warn(dev, "\"SRC Out Rate\" can use during running\n"); ++ ++ return 0; ++ } ++ ++ return 1; ++} ++ + static int rsnd_src_probe_(struct rsnd_mod *mod, + struct rsnd_dai_stream *io, + struct rsnd_priv *priv) +@@ -593,7 +609,7 @@ static int rsnd_src_pcm_new(struct rsnd_mod *mod, + rsnd_io_is_play(io) ? + "SRC Out Rate" : + "SRC In Rate", +- rsnd_kctrl_accept_runtime, ++ rsnd_src_kctrl_accept_runtime, + rsnd_src_set_convert_rate, + &src->sync, 192000); + +-- +2.39.5 + diff --git a/queue-5.15/asoc-sof-intel-hda-add-softdep-pre-to-snd-hda-codec-.patch b/queue-5.15/asoc-sof-intel-hda-add-softdep-pre-to-snd-hda-codec-.patch new file mode 100644 index 0000000000..b630d6fc32 --- /dev/null +++ b/queue-5.15/asoc-sof-intel-hda-add-softdep-pre-to-snd-hda-codec-.patch @@ -0,0 +1,44 @@ +From c0378112c931660c55b88d5705a5b68c8e6cce07 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 6 Feb 2025 11:47:23 +0200 +Subject: ASoC: SOF: Intel: hda: add softdep pre to snd-hda-codec-hdmi module +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Terry Cheong + +[ Upstream commit 33b7dc7843dbdc9b90c91d11ba30b107f9138ffd ] + +In enviornment without KMOD requesting module may fail to load +snd-hda-codec-hdmi, resulting in HDMI audio not usable. +Add softdep to loading HDMI codec module first to ensure we can load it +correctly. + +Signed-off-by: Terry Cheong +Reviewed-by: Bard Liao +Reviewed-by: Johny Lin +Reviewed-by: Péter Ujfalusi +Signed-off-by: Peter Ujfalusi +Link: https://patch.msgid.link/20250206094723.18013-1-peter.ujfalusi@linux.intel.com +Signed-off-by: Mark Brown +Signed-off-by: Sasha Levin +--- + sound/soc/sof/intel/hda-codec.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/sound/soc/sof/intel/hda-codec.c b/sound/soc/sof/intel/hda-codec.c +index 6744318de612e..0449e7a2669ff 100644 +--- a/sound/soc/sof/intel/hda-codec.c ++++ b/sound/soc/sof/intel/hda-codec.c +@@ -258,6 +258,7 @@ int hda_codec_i915_exit(struct snd_sof_dev *sdev) + } + EXPORT_SYMBOL_NS(hda_codec_i915_exit, SND_SOC_SOF_HDA_AUDIO_CODEC_I915); + ++MODULE_SOFTDEP("pre: snd-hda-codec-hdmi"); + #endif + + MODULE_LICENSE("Dual BSD/GPL"); +-- +2.39.5 + diff --git a/queue-5.15/asoc-tas2764-fix-power-control-mask.patch b/queue-5.15/asoc-tas2764-fix-power-control-mask.patch new file mode 100644 index 0000000000..7f54c32c4c --- /dev/null +++ b/queue-5.15/asoc-tas2764-fix-power-control-mask.patch @@ -0,0 +1,35 @@ +From 4c70cdd52741503d0c899ab380b87bda70936f42 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 18 Feb 2025 18:35:35 +1000 +Subject: ASoC: tas2764: Fix power control mask + +From: Hector Martin + +[ Upstream commit a3f172359e22b2c11b750d23560481a55bf86af1 ] + +Reviewed-by: Neal Gompa +Signed-off-by: Hector Martin +Signed-off-by: James Calligeros +Link: https://patch.msgid.link/20250218-apple-codec-changes-v2-1-932760fd7e07@gmail.com +Signed-off-by: Mark Brown +Signed-off-by: Sasha Levin +--- + sound/soc/codecs/tas2764.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/sound/soc/codecs/tas2764.h b/sound/soc/codecs/tas2764.h +index f015f22a083b5..b18a637bd9fa3 100644 +--- a/sound/soc/codecs/tas2764.h ++++ b/sound/soc/codecs/tas2764.h +@@ -25,7 +25,7 @@ + + /* Power Control */ + #define TAS2764_PWR_CTRL TAS2764_REG(0X0, 0x02) +-#define TAS2764_PWR_CTRL_MASK GENMASK(1, 0) ++#define TAS2764_PWR_CTRL_MASK GENMASK(2, 0) + #define TAS2764_PWR_CTRL_ACTIVE 0x0 + #define TAS2764_PWR_CTRL_MUTE BIT(0) + #define TAS2764_PWR_CTRL_SHUTDOWN BIT(1) +-- +2.39.5 + diff --git a/queue-5.15/asoc-tas2764-set-the-sdout-polarity-correctly.patch b/queue-5.15/asoc-tas2764-set-the-sdout-polarity-correctly.patch new file mode 100644 index 0000000000..3d66041199 --- /dev/null +++ b/queue-5.15/asoc-tas2764-set-the-sdout-polarity-correctly.patch @@ -0,0 +1,84 @@ +From d75ce8e7ef37b9f2233e970ec4562d8e3853c8ba Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 18 Feb 2025 18:36:02 +1000 +Subject: ASoC: tas2764: Set the SDOUT polarity correctly + +From: Hector Martin + +[ Upstream commit f5468beeab1b1adfc63c2717b1f29ef3f49a5fab ] + +TX launch polarity needs to be the opposite of RX capture polarity, to +generate the right bit slot alignment. + +Reviewed-by: Neal Gompa +Signed-off-by: Hector Martin +Signed-off-by: James Calligeros +Link: https://patch.msgid.link/20250218-apple-codec-changes-v2-28-932760fd7e07@gmail.com +Signed-off-by: Mark Brown +Signed-off-by: Sasha Levin +--- + sound/soc/codecs/tas2764.c | 10 +++++++++- + sound/soc/codecs/tas2764.h | 6 ++++++ + 2 files changed, 15 insertions(+), 1 deletion(-) + +diff --git a/sound/soc/codecs/tas2764.c b/sound/soc/codecs/tas2764.c +index 1951bae95b315..273bf4027a6e5 100644 +--- a/sound/soc/codecs/tas2764.c ++++ b/sound/soc/codecs/tas2764.c +@@ -315,7 +315,7 @@ static int tas2764_set_fmt(struct snd_soc_dai *dai, unsigned int fmt) + { + struct snd_soc_component *component = dai->component; + struct tas2764_priv *tas2764 = snd_soc_component_get_drvdata(component); +- u8 tdm_rx_start_slot = 0, asi_cfg_0 = 0, asi_cfg_1 = 0; ++ u8 tdm_rx_start_slot = 0, asi_cfg_0 = 0, asi_cfg_1 = 0, asi_cfg_4 = 0; + int ret; + + switch (fmt & SND_SOC_DAIFMT_INV_MASK) { +@@ -324,12 +324,14 @@ static int tas2764_set_fmt(struct snd_soc_dai *dai, unsigned int fmt) + fallthrough; + case SND_SOC_DAIFMT_NB_NF: + asi_cfg_1 = TAS2764_TDM_CFG1_RX_RISING; ++ asi_cfg_4 = TAS2764_TDM_CFG4_TX_FALLING; + break; + case SND_SOC_DAIFMT_IB_IF: + asi_cfg_0 ^= TAS2764_TDM_CFG0_FRAME_START; + fallthrough; + case SND_SOC_DAIFMT_IB_NF: + asi_cfg_1 = TAS2764_TDM_CFG1_RX_FALLING; ++ asi_cfg_4 = TAS2764_TDM_CFG4_TX_RISING; + break; + } + +@@ -339,6 +341,12 @@ static int tas2764_set_fmt(struct snd_soc_dai *dai, unsigned int fmt) + if (ret < 0) + return ret; + ++ ret = snd_soc_component_update_bits(component, TAS2764_TDM_CFG4, ++ TAS2764_TDM_CFG4_TX_MASK, ++ asi_cfg_4); ++ if (ret < 0) ++ return ret; ++ + switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) { + case SND_SOC_DAIFMT_I2S: + asi_cfg_0 ^= TAS2764_TDM_CFG0_FRAME_START; +diff --git a/sound/soc/codecs/tas2764.h b/sound/soc/codecs/tas2764.h +index b18a637bd9fa3..337bc611bee96 100644 +--- a/sound/soc/codecs/tas2764.h ++++ b/sound/soc/codecs/tas2764.h +@@ -75,6 +75,12 @@ + #define TAS2764_TDM_CFG3_RXS_SHIFT 0x4 + #define TAS2764_TDM_CFG3_MASK GENMASK(3, 0) + ++/* TDM Configuration Reg4 */ ++#define TAS2764_TDM_CFG4 TAS2764_REG(0X0, 0x0d) ++#define TAS2764_TDM_CFG4_TX_MASK BIT(0) ++#define TAS2764_TDM_CFG4_TX_RISING 0x0 ++#define TAS2764_TDM_CFG4_TX_FALLING BIT(0) ++ + /* TDM Configuration Reg5 */ + #define TAS2764_TDM_CFG5 TAS2764_REG(0X0, 0x0e) + #define TAS2764_TDM_CFG5_VSNS_MASK BIT(6) +-- +2.39.5 + diff --git a/queue-5.15/asoc-tas2770-fix-volume-scale.patch b/queue-5.15/asoc-tas2770-fix-volume-scale.patch new file mode 100644 index 0000000000..0f4bd80ce8 --- /dev/null +++ b/queue-5.15/asoc-tas2770-fix-volume-scale.patch @@ -0,0 +1,36 @@ +From f662b9cc40173c87596ef40c04360e87b49eb775 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 8 Feb 2025 00:54:35 +0000 +Subject: ASoC: tas2770: Fix volume scale + +From: Hector Martin + +[ Upstream commit 579cd64b9df8a60284ec3422be919c362de40e41 ] + +The scale starts at -100dB, not -128dB. + +Signed-off-by: Hector Martin +Signed-off-by: Mark Brown +Link: https://patch.msgid.link/20250208-asoc-tas2770-v1-1-cf50ff1d59a3@kernel.org +Signed-off-by: Mark Brown +Signed-off-by: Sasha Levin +--- + sound/soc/codecs/tas2770.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/sound/soc/codecs/tas2770.c b/sound/soc/codecs/tas2770.c +index ec0df3b1ef615..4e71dc1cf588f 100644 +--- a/sound/soc/codecs/tas2770.c ++++ b/sound/soc/codecs/tas2770.c +@@ -508,7 +508,7 @@ static int tas2770_codec_probe(struct snd_soc_component *component) + } + + static DECLARE_TLV_DB_SCALE(tas2770_digital_tlv, 1100, 50, 0); +-static DECLARE_TLV_DB_SCALE(tas2770_playback_volume, -12750, 50, 0); ++static DECLARE_TLV_DB_SCALE(tas2770_playback_volume, -10050, 50, 0); + + static const struct snd_kcontrol_new tas2770_snd_controls[] = { + SOC_SINGLE_TLV("Speaker Playback Volume", TAS2770_PLAY_CFG_REG2, +-- +2.39.5 + diff --git a/queue-5.15/block-fix-kmem_cache-of-name-bio-108-already-exists.patch b/queue-5.15/block-fix-kmem_cache-of-name-bio-108-already-exists.patch new file mode 100644 index 0000000000..523151aadc --- /dev/null +++ b/queue-5.15/block-fix-kmem_cache-of-name-bio-108-already-exists.patch @@ -0,0 +1,41 @@ +From 2e24d6db00fa43db9c7e7b904e0e3811e1a7e877 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 28 Feb 2025 21:26:56 +0800 +Subject: block: fix 'kmem_cache of name 'bio-108' already exists' + +From: Ming Lei + +[ Upstream commit b654f7a51ffb386131de42aa98ed831f8c126546 ] + +Device mapper bioset often has big bio_slab size, which can be more than +1000, then 8byte can't hold the slab name any more, cause the kmem_cache +allocation warning of 'kmem_cache of name 'bio-108' already exists'. + +Fix the warning by extending bio_slab->name to 12 bytes, but fix output +of /proc/slabinfo + +Reported-by: Guangwu Zhang +Signed-off-by: Ming Lei +Link: https://lore.kernel.org/r/20250228132656.2838008-1-ming.lei@redhat.com +Signed-off-by: Jens Axboe +Signed-off-by: Sasha Levin +--- + block/bio.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/block/bio.c b/block/bio.c +index 92399883bc5e1..029dba492ac2d 100644 +--- a/block/bio.c ++++ b/block/bio.c +@@ -73,7 +73,7 @@ struct bio_slab { + struct kmem_cache *slab; + unsigned int slab_ref; + unsigned int slab_size; +- char name[8]; ++ char name[12]; + }; + static DEFINE_MUTEX(bio_slab_lock); + static DEFINE_XARRAY(bio_slabs); +-- +2.39.5 + diff --git a/queue-5.15/drm-nouveau-do-not-override-forced-connector-status.patch b/queue-5.15/drm-nouveau-do-not-override-forced-connector-status.patch new file mode 100644 index 0000000000..d3bbfbbebe --- /dev/null +++ b/queue-5.15/drm-nouveau-do-not-override-forced-connector-status.patch @@ -0,0 +1,35 @@ +From 938ef597fb6ff4a82fdb6df0d57c69034a3ab867 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 14 Jan 2025 10:57:25 +0100 +Subject: drm/nouveau: Do not override forced connector status + +From: Thomas Zimmermann + +[ Upstream commit 01f1d77a2630e774ce33233c4e6723bca3ae9daa ] + +Keep user-forced connector status even if it cannot be programmed. Same +behavior as for the rest of the drivers. + +Signed-off-by: Thomas Zimmermann +Signed-off-by: Lyude Paul +Link: https://patchwork.freedesktop.org/patch/msgid/20250114100214.195386-1-tzimmermann@suse.de +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/nouveau/nouveau_connector.c | 1 - + 1 file changed, 1 deletion(-) + +diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c +index ac9eb92059bc3..30f871be52cb3 100644 +--- a/drivers/gpu/drm/nouveau/nouveau_connector.c ++++ b/drivers/gpu/drm/nouveau/nouveau_connector.c +@@ -754,7 +754,6 @@ nouveau_connector_force(struct drm_connector *connector) + if (!nv_encoder) { + NV_ERROR(drm, "can't find encoder to force %s on!\n", + connector->name); +- connector->status = connector_status_disconnected; + return; + } + +-- +2.39.5 + diff --git a/queue-5.15/fuse-don-t-truncate-cached-mutated-symlink.patch b/queue-5.15/fuse-don-t-truncate-cached-mutated-symlink.patch new file mode 100644 index 0000000000..2793f6079b --- /dev/null +++ b/queue-5.15/fuse-don-t-truncate-cached-mutated-symlink.patch @@ -0,0 +1,119 @@ +From 01ba3545f4fe2bdd63d99ff02ba3f072b01da81c Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 20 Feb 2025 11:02:58 +0100 +Subject: fuse: don't truncate cached, mutated symlink + +From: Miklos Szeredi + +[ Upstream commit b4c173dfbb6c78568578ff18f9e8822d7bd0e31b ] + +Fuse allows the value of a symlink to change and this property is exploited +by some filesystems (e.g. CVMFS). + +It has been observed, that sometimes after changing the symlink contents, +the value is truncated to the old size. + +This is caused by fuse_getattr() racing with fuse_reverse_inval_inode(). +fuse_reverse_inval_inode() updates the fuse_inode's attr_version, which +results in fuse_change_attributes() exiting before updating the cached +attributes + +This is okay, as the cached attributes remain invalid and the next call to +fuse_change_attributes() will likely update the inode with the correct +values. + +The reason this causes problems is that cached symlinks will be +returned through page_get_link(), which truncates the symlink to +inode->i_size. This is correct for filesystems that don't mutate +symlinks, but in this case it causes bad behavior. + +The solution is to just remove this truncation. This can cause a +regression in a filesystem that relies on supplying a symlink larger than +the file size, but this is unlikely. If that happens we'd need to make +this behavior conditional. + +Reported-by: Laura Promberger +Tested-by: Sam Lewis +Signed-off-by: Miklos Szeredi +Link: https://lore.kernel.org/r/20250220100258.793363-1-mszeredi@redhat.com +Reviewed-by: Bernd Schubert +Signed-off-by: Christian Brauner +Signed-off-by: Sasha Levin +--- + fs/fuse/dir.c | 2 +- + fs/namei.c | 24 +++++++++++++++++++----- + include/linux/fs.h | 2 ++ + 3 files changed, 22 insertions(+), 6 deletions(-) + +diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c +index 44d1c8cc58a42..03dadc44e9b1c 100644 +--- a/fs/fuse/dir.c ++++ b/fs/fuse/dir.c +@@ -1333,7 +1333,7 @@ static const char *fuse_get_link(struct dentry *dentry, struct inode *inode, + goto out_err; + + if (fc->cache_symlinks) +- return page_get_link(dentry, inode, callback); ++ return page_get_link_raw(dentry, inode, callback); + + err = -ECHILD; + if (!dentry) +diff --git a/fs/namei.c b/fs/namei.c +index 05d45b9b59cb4..c188d525300d1 100644 +--- a/fs/namei.c ++++ b/fs/namei.c +@@ -5114,10 +5114,9 @@ const char *vfs_get_link(struct dentry *dentry, struct delayed_call *done) + EXPORT_SYMBOL(vfs_get_link); + + /* get the link contents into pagecache */ +-const char *page_get_link(struct dentry *dentry, struct inode *inode, +- struct delayed_call *callback) ++static char *__page_get_link(struct dentry *dentry, struct inode *inode, ++ struct delayed_call *callback) + { +- char *kaddr; + struct page *page; + struct address_space *mapping = inode->i_mapping; + +@@ -5136,8 +5135,23 @@ const char *page_get_link(struct dentry *dentry, struct inode *inode, + } + set_delayed_call(callback, page_put_link, page); + BUG_ON(mapping_gfp_mask(mapping) & __GFP_HIGHMEM); +- kaddr = page_address(page); +- nd_terminate_link(kaddr, inode->i_size, PAGE_SIZE - 1); ++ return page_address(page); ++} ++ ++const char *page_get_link_raw(struct dentry *dentry, struct inode *inode, ++ struct delayed_call *callback) ++{ ++ return __page_get_link(dentry, inode, callback); ++} ++EXPORT_SYMBOL_GPL(page_get_link_raw); ++ ++const char *page_get_link(struct dentry *dentry, struct inode *inode, ++ struct delayed_call *callback) ++{ ++ char *kaddr = __page_get_link(dentry, inode, callback); ++ ++ if (!IS_ERR(kaddr)) ++ nd_terminate_link(kaddr, inode->i_size, PAGE_SIZE - 1); + return kaddr; + } + +diff --git a/include/linux/fs.h b/include/linux/fs.h +index d011dc742e3ef..a111724982795 100644 +--- a/include/linux/fs.h ++++ b/include/linux/fs.h +@@ -3387,6 +3387,8 @@ extern const struct file_operations generic_ro_fops; + + extern int readlink_copy(char __user *, int, const char *); + extern int page_readlink(struct dentry *, char __user *, int); ++extern const char *page_get_link_raw(struct dentry *, struct inode *, ++ struct delayed_call *); + extern const char *page_get_link(struct dentry *, struct inode *, + struct delayed_call *); + extern void page_put_link(void *); +-- +2.39.5 + diff --git a/queue-5.15/hid-ignore-non-functional-sensor-in-hp-5mp-camera.patch b/queue-5.15/hid-ignore-non-functional-sensor-in-hp-5mp-camera.patch new file mode 100644 index 0000000000..c2271a37e6 --- /dev/null +++ b/queue-5.15/hid-ignore-non-functional-sensor-in-hp-5mp-camera.patch @@ -0,0 +1,56 @@ +From f75afcb93699a0bc1c9de2e402c229c8aa5edea4 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 15 Jan 2025 15:00:20 +0800 +Subject: HID: ignore non-functional sensor in HP 5MP Camera + +From: Chia-Lin Kao (AceLan) + +[ Upstream commit 363236d709e75610b628c2a4337ccbe42e454b6d ] + +The HP 5MP Camera (USB ID 0408:5473) reports a HID sensor interface that +is not actually implemented. Attempting to access this non-functional +sensor via iio_info causes system hangs as runtime PM tries to wake up +an unresponsive sensor. + + [453] hid-sensor-hub 0003:0408:5473.0003: Report latency attributes: ffffffff:ffffffff + [453] hid-sensor-hub 0003:0408:5473.0003: common attributes: 5:1, 2:1, 3:1 ffffffff:ffffffff + +Add this device to the HID ignore list since the sensor interface is +non-functional by design and should not be exposed to userspace. + +Signed-off-by: Chia-Lin Kao (AceLan) +Acked-by: Srinivas Pandruvada +Signed-off-by: Jiri Kosina +Signed-off-by: Sasha Levin +--- + drivers/hid/hid-ids.h | 1 + + drivers/hid/hid-quirks.c | 1 + + 2 files changed, 2 insertions(+) + +diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h +index 81db294dda408..44825a916eeb2 100644 +--- a/drivers/hid/hid-ids.h ++++ b/drivers/hid/hid-ids.h +@@ -1037,6 +1037,7 @@ + #define USB_DEVICE_ID_QUANTA_OPTICAL_TOUCH_3001 0x3001 + #define USB_DEVICE_ID_QUANTA_OPTICAL_TOUCH_3003 0x3003 + #define USB_DEVICE_ID_QUANTA_OPTICAL_TOUCH_3008 0x3008 ++#define USB_DEVICE_ID_QUANTA_HP_5MP_CAMERA_5473 0x5473 + + #define I2C_VENDOR_ID_RAYDIUM 0x2386 + #define I2C_PRODUCT_ID_RAYDIUM_4B33 0x4b33 +diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c +index 80e4247a768bd..b5ad4c87daacf 100644 +--- a/drivers/hid/hid-quirks.c ++++ b/drivers/hid/hid-quirks.c +@@ -871,6 +871,7 @@ static const struct hid_device_id hid_ignore_list[] = { + { HID_USB_DEVICE(USB_VENDOR_ID_SYNAPTICS, USB_DEVICE_ID_SYNAPTICS_DPAD) }, + #endif + { HID_USB_DEVICE(USB_VENDOR_ID_YEALINK, USB_DEVICE_ID_YEALINK_P1K_P4K_B2K) }, ++ { HID_USB_DEVICE(USB_VENDOR_ID_QUANTA, USB_DEVICE_ID_QUANTA_HP_5MP_CAMERA_5473) }, + { } + }; + +-- +2.39.5 + diff --git a/queue-5.15/hid-intel-ish-hid-fix-the-length-of-mng_sync_fw_cloc.patch b/queue-5.15/hid-intel-ish-hid-fix-the-length-of-mng_sync_fw_cloc.patch new file mode 100644 index 0000000000..40b393c65a --- /dev/null +++ b/queue-5.15/hid-intel-ish-hid-fix-the-length-of-mng_sync_fw_cloc.patch @@ -0,0 +1,56 @@ +From ea3875b7ae043a7168da70783c6a973ba3a87a51 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 22 Jan 2025 09:29:00 +0800 +Subject: HID: intel-ish-hid: fix the length of MNG_SYNC_FW_CLOCK in doorbell + +From: Zhang Lixu + +[ Upstream commit 4b54ae69197b9f416baa0fceadff7e89075f8454 ] + +The timestamps in the Firmware log and HID sensor samples are incorrect. +They show 1970-01-01 because the current IPC driver only uses the first +8 bytes of bootup time when synchronizing time with the firmware. The +firmware converts the bootup time to UTC time, which results in the +display of 1970-01-01. + +In write_ipc_from_queue(), when sending the MNG_SYNC_FW_CLOCK message, +the clock is updated according to the definition of ipc_time_update_msg. +However, in _ish_sync_fw_clock(), the message length is specified as the +size of uint64_t when building the doorbell. As a result, the firmware +only receives the first 8 bytes of struct ipc_time_update_msg. +This patch corrects the length in the doorbell to ensure the entire +ipc_time_update_msg is sent, fixing the timestamp issue. + +Signed-off-by: Zhang Lixu +Acked-by: Srinivas Pandruvada +Signed-off-by: Jiri Kosina +Signed-off-by: Sasha Levin +--- + drivers/hid/intel-ish-hid/ipc/ipc.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +diff --git a/drivers/hid/intel-ish-hid/ipc/ipc.c b/drivers/hid/intel-ish-hid/ipc/ipc.c +index ba45605fc6b52..a48f7cd514b0f 100644 +--- a/drivers/hid/intel-ish-hid/ipc/ipc.c ++++ b/drivers/hid/intel-ish-hid/ipc/ipc.c +@@ -577,14 +577,14 @@ static void fw_reset_work_fn(struct work_struct *unused) + static void _ish_sync_fw_clock(struct ishtp_device *dev) + { + static unsigned long prev_sync; +- uint64_t usec; ++ struct ipc_time_update_msg time = {}; + + if (prev_sync && jiffies - prev_sync < 20 * HZ) + return; + + prev_sync = jiffies; +- usec = ktime_to_us(ktime_get_boottime()); +- ipc_send_mng_msg(dev, MNG_SYNC_FW_CLOCK, &usec, sizeof(uint64_t)); ++ /* The fields of time would be updated while sending message */ ++ ipc_send_mng_msg(dev, MNG_SYNC_FW_CLOCK, &time, sizeof(time)); + } + + /** +-- +2.39.5 + diff --git a/queue-5.15/hrtimers-mark-is_migration_base-with-__always_inline.patch b/queue-5.15/hrtimers-mark-is_migration_base-with-__always_inline.patch new file mode 100644 index 0000000000..c50830dd7f --- /dev/null +++ b/queue-5.15/hrtimers-mark-is_migration_base-with-__always_inline.patch @@ -0,0 +1,79 @@ +From 89827a6f7cee33570cd02be74900bae2feccef59 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 16 Jan 2025 18:07:45 +0200 +Subject: hrtimers: Mark is_migration_base() with __always_inline + +From: Andy Shevchenko + +[ Upstream commit 27af31e44949fa85550176520ef7086a0d00fd7b ] + +When is_migration_base() is unused, it prevents kernel builds +with clang, `make W=1` and CONFIG_WERROR=y: + +kernel/time/hrtimer.c:156:20: error: unused function 'is_migration_base' [-Werror,-Wunused-function] + 156 | static inline bool is_migration_base(struct hrtimer_clock_base *base) + | ^~~~~~~~~~~~~~~~~ + +Fix this by marking it with __always_inline. + +[ tglx: Use __always_inline instead of __maybe_unused and move it into the + usage sites conditional ] + +Signed-off-by: Andy Shevchenko +Signed-off-by: Thomas Gleixner +Link: https://lore.kernel.org/all/20250116160745.243358-1-andriy.shevchenko@linux.intel.com +Signed-off-by: Sasha Levin +--- + kernel/time/hrtimer.c | 22 ++++++++++++---------- + 1 file changed, 12 insertions(+), 10 deletions(-) + +diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c +index 9e91f69012a73..2e4b63f3c6dda 100644 +--- a/kernel/time/hrtimer.c ++++ b/kernel/time/hrtimer.c +@@ -144,11 +144,6 @@ static struct hrtimer_cpu_base migration_cpu_base = { + + #define migration_base migration_cpu_base.clock_base[0] + +-static inline bool is_migration_base(struct hrtimer_clock_base *base) +-{ +- return base == &migration_base; +-} +- + /* + * We are using hashed locking: holding per_cpu(hrtimer_bases)[n].lock + * means that all timers which are tied to this base via timer->base are +@@ -273,11 +268,6 @@ switch_hrtimer_base(struct hrtimer *timer, struct hrtimer_clock_base *base, + + #else /* CONFIG_SMP */ + +-static inline bool is_migration_base(struct hrtimer_clock_base *base) +-{ +- return false; +-} +- + static inline struct hrtimer_clock_base * + lock_hrtimer_base(const struct hrtimer *timer, unsigned long *flags) + { +@@ -1377,6 +1367,18 @@ static void hrtimer_sync_wait_running(struct hrtimer_cpu_base *cpu_base, + } + } + ++#ifdef CONFIG_SMP ++static __always_inline bool is_migration_base(struct hrtimer_clock_base *base) ++{ ++ return base == &migration_base; ++} ++#else ++static __always_inline bool is_migration_base(struct hrtimer_clock_base *base) ++{ ++ return false; ++} ++#endif ++ + /* + * This function is called on PREEMPT_RT kernels when the fast path + * deletion of a timer failed because the timer callback function was +-- +2.39.5 + diff --git a/queue-5.15/iscsi_ibft-fix-ubsan-shift-out-of-bounds-warning-in-.patch b/queue-5.15/iscsi_ibft-fix-ubsan-shift-out-of-bounds-warning-in-.patch new file mode 100644 index 0000000000..e066f33d37 --- /dev/null +++ b/queue-5.15/iscsi_ibft-fix-ubsan-shift-out-of-bounds-warning-in-.patch @@ -0,0 +1,42 @@ +From 9360503fa9ccbe586bca0a6629cfca01f22006ad Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 14 Jan 2025 12:12:34 +0800 +Subject: iscsi_ibft: Fix UBSAN shift-out-of-bounds warning in + ibft_attr_show_nic() + +From: Chengen Du + +[ Upstream commit 07e0d99a2f701123ad3104c0f1a1e66bce74d6e5 ] + +When performing an iSCSI boot using IPv6, iscsistart still reads the +/sys/firmware/ibft/ethernetX/subnet-mask entry. Since the IPv6 prefix +length is 64, this causes the shift exponent to become negative, +triggering a UBSAN warning. As the concept of a subnet mask does not +apply to IPv6, the value is set to ~0 to suppress the warning message. + +Signed-off-by: Chengen Du +Signed-off-by: Konrad Rzeszutek Wilk +Signed-off-by: Sasha Levin +--- + drivers/firmware/iscsi_ibft.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +diff --git a/drivers/firmware/iscsi_ibft.c b/drivers/firmware/iscsi_ibft.c +index 6e9788324fea5..371f24569b3b2 100644 +--- a/drivers/firmware/iscsi_ibft.c ++++ b/drivers/firmware/iscsi_ibft.c +@@ -310,7 +310,10 @@ static ssize_t ibft_attr_show_nic(void *data, int type, char *buf) + str += sprintf_ipaddr(str, nic->ip_addr); + break; + case ISCSI_BOOT_ETH_SUBNET_MASK: +- val = cpu_to_be32(~((1 << (32-nic->subnet_mask_prefix))-1)); ++ if (nic->subnet_mask_prefix > 32) ++ val = cpu_to_be32(~0); ++ else ++ val = cpu_to_be32(~((1 << (32-nic->subnet_mask_prefix))-1)); + str += sprintf(str, "%pI4", &val); + break; + case ISCSI_BOOT_ETH_PREFIX_LEN: +-- +2.39.5 + diff --git a/queue-5.15/mptcp-safety-check-before-fallback.patch b/queue-5.15/mptcp-safety-check-before-fallback.patch new file mode 100644 index 0000000000..e581071a09 --- /dev/null +++ b/queue-5.15/mptcp-safety-check-before-fallback.patch @@ -0,0 +1,41 @@ +From 8afb22e4563f936efdf4a6666a2221ec1f79a883 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 24 Feb 2025 19:11:52 +0100 +Subject: mptcp: safety check before fallback + +From: Matthieu Baerts (NGI0) + +[ Upstream commit db75a16813aabae3b78c06b1b99f5e314c1f55d3 ] + +Recently, some fallback have been initiated, while the connection was +not supposed to fallback. + +Add a safety check with a warning to detect when an wrong attempt to +fallback is being done. This should help detecting any future issues +quicker. + +Acked-by: Paolo Abeni +Signed-off-by: Matthieu Baerts (NGI0) +Link: https://patch.msgid.link/20250224-net-mptcp-misc-fixes-v1-3-f550f636b435@kernel.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + net/mptcp/protocol.h | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h +index 83e93a7e9b40e..cfb6aa72515e8 100644 +--- a/net/mptcp/protocol.h ++++ b/net/mptcp/protocol.h +@@ -872,6 +872,8 @@ static inline void __mptcp_do_fallback(struct mptcp_sock *msk) + pr_debug("TCP fallback already done (msk=%p)\n", msk); + return; + } ++ if (WARN_ON_ONCE(!READ_ONCE(msk->allow_infinite_fallback))) ++ return; + set_bit(MPTCP_FALLBACK_DONE, &msk->flags); + } + +-- +2.39.5 + diff --git a/queue-5.15/net-wwan-mhi_wwan_mbim-silence-sequence-number-glitc.patch b/queue-5.15/net-wwan-mhi_wwan_mbim-silence-sequence-number-glitc.patch new file mode 100644 index 0000000000..d0a586a288 --- /dev/null +++ b/queue-5.15/net-wwan-mhi_wwan_mbim-silence-sequence-number-glitc.patch @@ -0,0 +1,61 @@ +From d486f51f9103ee2d8c119249c1d88f29fd82c36f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 12 Feb 2025 12:15:35 +0100 +Subject: net: wwan: mhi_wwan_mbim: Silence sequence number glitch errors + +From: Stephan Gerhold + +[ Upstream commit 0d1fac6d26aff5df21bb4ec980d9b7a11c410b96 ] + +When using the Qualcomm X55 modem on the ThinkPad X13s, the kernel log is +constantly being filled with errors related to a "sequence number glitch", +e.g.: + + [ 1903.284538] sequence number glitch prev=16 curr=0 + [ 1913.812205] sequence number glitch prev=50 curr=0 + [ 1923.698219] sequence number glitch prev=142 curr=0 + [ 2029.248276] sequence number glitch prev=1555 curr=0 + [ 2046.333059] sequence number glitch prev=70 curr=0 + [ 2076.520067] sequence number glitch prev=272 curr=0 + [ 2158.704202] sequence number glitch prev=2655 curr=0 + [ 2218.530776] sequence number glitch prev=2349 curr=0 + [ 2225.579092] sequence number glitch prev=6 curr=0 + +Internet connectivity is working fine, so this error seems harmless. It +looks like modem does not preserve the sequence number when entering low +power state; the amount of errors depends on how actively the modem is +being used. + +A similar issue has also been seen on USB-based MBIM modems [1]. However, +in cdc_ncm.c the "sequence number glitch" message is a debug message +instead of an error. Apply the same to the mhi_wwan_mbim.c driver to +silence these errors when using the modem. + +[1]: https://lists.freedesktop.org/archives/libmbim-devel/2016-November/000781.html + +Signed-off-by: Stephan Gerhold +Reviewed-by: Loic Poulain +Acked-by: Manivannan Sadhasivam +Link: https://patch.msgid.link/20250212-mhi-wwan-mbim-sequence-glitch-v1-1-503735977cbd@linaro.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/net/wwan/mhi_wwan_mbim.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/net/wwan/mhi_wwan_mbim.c b/drivers/net/wwan/mhi_wwan_mbim.c +index ef70bb7c88ad6..43c20deab3189 100644 +--- a/drivers/net/wwan/mhi_wwan_mbim.c ++++ b/drivers/net/wwan/mhi_wwan_mbim.c +@@ -209,7 +209,7 @@ static int mbim_rx_verify_nth16(struct mhi_mbim_context *mbim, struct sk_buff *s + if (mbim->rx_seq + 1 != le16_to_cpu(nth16->wSequence) && + (mbim->rx_seq || le16_to_cpu(nth16->wSequence)) && + !(mbim->rx_seq == 0xffff && !le16_to_cpu(nth16->wSequence))) { +- net_err_ratelimited("sequence number glitch prev=%d curr=%d\n", ++ net_dbg_ratelimited("sequence number glitch prev=%d curr=%d\n", + mbim->rx_seq, le16_to_cpu(nth16->wSequence)); + } + mbim->rx_seq = le16_to_cpu(nth16->wSequence); +-- +2.39.5 + diff --git a/queue-5.15/nvme-fc-go-straight-to-connecting-state-when-initial.patch b/queue-5.15/nvme-fc-go-straight-to-connecting-state-when-initial.patch new file mode 100644 index 0000000000..758f71f3a3 --- /dev/null +++ b/queue-5.15/nvme-fc-go-straight-to-connecting-state-when-initial.patch @@ -0,0 +1,43 @@ +From 8a9cb9895443f2fc29cc7eb0d0a395c26bae2a32 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 9 Jan 2025 14:30:47 +0100 +Subject: nvme-fc: go straight to connecting state when initializing + +From: Daniel Wagner + +[ Upstream commit d3d380eded7ee5fc2fc53b3b0e72365ded025c4a ] + +The initial controller initialization mimiks the reconnect loop +behavior by switching from NEW to RESETTING and then to CONNECTING. + +The transition from NEW to CONNECTING is a valid transition, so there is +no point entering the RESETTING state. TCP and RDMA also transition +directly to CONNECTING state. + +Reviewed-by: Sagi Grimberg +Reviewed-by: Hannes Reinecke +Reviewed-by: Christoph Hellwig +Signed-off-by: Daniel Wagner +Signed-off-by: Keith Busch +Signed-off-by: Sasha Levin +--- + drivers/nvme/host/fc.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +diff --git a/drivers/nvme/host/fc.c b/drivers/nvme/host/fc.c +index 8dfd317509aa6..ebe8c2f147a33 100644 +--- a/drivers/nvme/host/fc.c ++++ b/drivers/nvme/host/fc.c +@@ -3547,8 +3547,7 @@ nvme_fc_init_ctrl(struct device *dev, struct nvmf_ctrl_options *opts, + list_add_tail(&ctrl->ctrl_list, &rport->ctrl_list); + spin_unlock_irqrestore(&rport->lock, flags); + +- if (!nvme_change_ctrl_state(&ctrl->ctrl, NVME_CTRL_RESETTING) || +- !nvme_change_ctrl_state(&ctrl->ctrl, NVME_CTRL_CONNECTING)) { ++ if (!nvme_change_ctrl_state(&ctrl->ctrl, NVME_CTRL_CONNECTING)) { + dev_err(ctrl->ctrl.device, + "NVME-FC{%d}: failed to init ctrl state\n", ctrl->cnum); + goto fail_ctrl; +-- +2.39.5 + diff --git a/queue-5.15/nvme-only-allow-entering-live-from-connecting-state.patch b/queue-5.15/nvme-only-allow-entering-live-from-connecting-state.patch new file mode 100644 index 0000000000..da8dfad5eb --- /dev/null +++ b/queue-5.15/nvme-only-allow-entering-live-from-connecting-state.patch @@ -0,0 +1,38 @@ +From 526e3f67ef3fda793e3d28eea83ea282e7690618 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 14 Feb 2025 09:02:03 +0100 +Subject: nvme: only allow entering LIVE from CONNECTING state + +From: Daniel Wagner + +[ Upstream commit d2fe192348f93fe3a0cb1e33e4aba58e646397f4 ] + +The fabric transports and also the PCI transport are not entering the +LIVE state from NEW or RESETTING. This makes the state machine more +restrictive and allows to catch not supported state transitions, e.g. +directly switching from RESETTING to LIVE. + +Reviewed-by: Sagi Grimberg +Signed-off-by: Daniel Wagner +Signed-off-by: Keith Busch +Signed-off-by: Sasha Levin +--- + drivers/nvme/host/core.c | 2 -- + 1 file changed, 2 deletions(-) + +diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c +index 7f744aa4d120c..6748532c776b8 100644 +--- a/drivers/nvme/host/core.c ++++ b/drivers/nvme/host/core.c +@@ -444,8 +444,6 @@ bool nvme_change_ctrl_state(struct nvme_ctrl *ctrl, + switch (new_state) { + case NVME_CTRL_LIVE: + switch (old_state) { +- case NVME_CTRL_NEW: +- case NVME_CTRL_RESETTING: + case NVME_CTRL_CONNECTING: + changed = true; + fallthrough; +-- +2.39.5 + diff --git a/queue-5.15/nvmet-rdma-recheck-queue-state-is-live-in-state-lock.patch b/queue-5.15/nvmet-rdma-recheck-queue-state-is-live-in-state-lock.patch new file mode 100644 index 0000000000..284d4846e4 --- /dev/null +++ b/queue-5.15/nvmet-rdma-recheck-queue-state-is-live-in-state-lock.patch @@ -0,0 +1,79 @@ +From ae98fa6142f025aa14c89bac90e0b85a2c10c443 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 16 Feb 2025 20:49:56 +0800 +Subject: nvmet-rdma: recheck queue state is LIVE in state lock in recv done + +From: Ruozhu Li + +[ Upstream commit 3988ac1c67e6e84d2feb987d7b36d5791174b3da ] + +The queue state checking in nvmet_rdma_recv_done is not in queue state +lock.Queue state can transfer to LIVE in cm establish handler between +state checking and state lock here, cause a silent drop of nvme connect +cmd. +Recheck queue state whether in LIVE state in state lock to prevent this +issue. + +Signed-off-by: Ruozhu Li +Reviewed-by: Sagi Grimberg +Signed-off-by: Keith Busch +Signed-off-by: Sasha Levin +--- + drivers/nvme/target/rdma.c | 33 +++++++++++++++++++++++---------- + 1 file changed, 23 insertions(+), 10 deletions(-) + +diff --git a/drivers/nvme/target/rdma.c b/drivers/nvme/target/rdma.c +index 9561ba3d43138..3b4b2d134cf81 100644 +--- a/drivers/nvme/target/rdma.c ++++ b/drivers/nvme/target/rdma.c +@@ -996,6 +996,27 @@ static void nvmet_rdma_handle_command(struct nvmet_rdma_queue *queue, + nvmet_req_complete(&cmd->req, status); + } + ++static bool nvmet_rdma_recv_not_live(struct nvmet_rdma_queue *queue, ++ struct nvmet_rdma_rsp *rsp) ++{ ++ unsigned long flags; ++ bool ret = true; ++ ++ spin_lock_irqsave(&queue->state_lock, flags); ++ /* ++ * recheck queue state is not live to prevent a race condition ++ * with RDMA_CM_EVENT_ESTABLISHED handler. ++ */ ++ if (queue->state == NVMET_RDMA_Q_LIVE) ++ ret = false; ++ else if (queue->state == NVMET_RDMA_Q_CONNECTING) ++ list_add_tail(&rsp->wait_list, &queue->rsp_wait_list); ++ else ++ nvmet_rdma_put_rsp(rsp); ++ spin_unlock_irqrestore(&queue->state_lock, flags); ++ return ret; ++} ++ + static void nvmet_rdma_recv_done(struct ib_cq *cq, struct ib_wc *wc) + { + struct nvmet_rdma_cmd *cmd = +@@ -1037,17 +1058,9 @@ static void nvmet_rdma_recv_done(struct ib_cq *cq, struct ib_wc *wc) + rsp->req.port = queue->port; + rsp->n_rdma = 0; + +- if (unlikely(queue->state != NVMET_RDMA_Q_LIVE)) { +- unsigned long flags; +- +- spin_lock_irqsave(&queue->state_lock, flags); +- if (queue->state == NVMET_RDMA_Q_CONNECTING) +- list_add_tail(&rsp->wait_list, &queue->rsp_wait_list); +- else +- nvmet_rdma_put_rsp(rsp); +- spin_unlock_irqrestore(&queue->state_lock, flags); ++ if (unlikely(queue->state != NVMET_RDMA_Q_LIVE) && ++ nvmet_rdma_recv_not_live(queue, rsp)) + return; +- } + + nvmet_rdma_handle_command(queue, rsp); + } +-- +2.39.5 + diff --git a/queue-5.15/perf-x86-intel-use-better-start-period-for-frequency.patch b/queue-5.15/perf-x86-intel-use-better-start-period-for-frequency.patch new file mode 100644 index 0000000000..d32f65bf03 --- /dev/null +++ b/queue-5.15/perf-x86-intel-use-better-start-period-for-frequency.patch @@ -0,0 +1,150 @@ +From d4b58c9fc31f4815b2e04ff60dfeb27dab7af085 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 17 Jan 2025 07:19:13 -0800 +Subject: perf/x86/intel: Use better start period for frequency mode + +From: Kan Liang + +[ Upstream commit a26b24b2e21f6222635a95426b9ef9eec63d69b1 ] + +Freqency mode is the current default mode of Linux perf. A period of 1 is +used as a starting period. The period is auto-adjusted on each tick or an +overflow, to meet the frequency target. + +The start period of 1 is too low and may trigger some issues: + +- Many HWs do not support period 1 well. + https://lore.kernel.org/lkml/875xs2oh69.ffs@tglx/ + +- For an event that occurs frequently, period 1 is too far away from the + real period. Lots of samples are generated at the beginning. + The distribution of samples may not be even. + +- A low starting period for frequently occurring events also challenges + virtualization, which has a longer path to handle a PMI. + +The limit_period value only checks the minimum acceptable value for HW. +It cannot be used to set the start period, because some events may +need a very low period. The limit_period cannot be set too high. It +doesn't help with the events that occur frequently. + +It's hard to find a universal starting period for all events. The idea +implemented by this patch is to only give an estimate for the popular +HW and HW cache events. For the rest of the events, start from the lowest +possible recommended value. + +Signed-off-by: Kan Liang +Signed-off-by: Ingo Molnar +Cc: Peter Zijlstra +Link: https://lore.kernel.org/r/20250117151913.3043942-3-kan.liang@linux.intel.com +Signed-off-by: Sasha Levin +--- + arch/x86/events/intel/core.c | 85 ++++++++++++++++++++++++++++++++++++ + 1 file changed, 85 insertions(+) + +diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c +index 767c60af13be3..9a44e53591f96 100644 +--- a/arch/x86/events/intel/core.c ++++ b/arch/x86/events/intel/core.c +@@ -3717,6 +3717,85 @@ static inline bool intel_pmu_has_cap(struct perf_event *event, int idx) + return test_bit(idx, (unsigned long *)&intel_cap->capabilities); + } + ++static u64 intel_pmu_freq_start_period(struct perf_event *event) ++{ ++ int type = event->attr.type; ++ u64 config, factor; ++ s64 start; ++ ++ /* ++ * The 127 is the lowest possible recommended SAV (sample after value) ++ * for a 4000 freq (default freq), according to the event list JSON file. ++ * Also, assume the workload is idle 50% time. ++ */ ++ factor = 64 * 4000; ++ if (type != PERF_TYPE_HARDWARE && type != PERF_TYPE_HW_CACHE) ++ goto end; ++ ++ /* ++ * The estimation of the start period in the freq mode is ++ * based on the below assumption. ++ * ++ * For a cycles or an instructions event, 1GHZ of the ++ * underlying platform, 1 IPC. The workload is idle 50% time. ++ * The start period = 1,000,000,000 * 1 / freq / 2. ++ * = 500,000,000 / freq ++ * ++ * Usually, the branch-related events occur less than the ++ * instructions event. According to the Intel event list JSON ++ * file, the SAV (sample after value) of a branch-related event ++ * is usually 1/4 of an instruction event. ++ * The start period of branch-related events = 125,000,000 / freq. ++ * ++ * The cache-related events occurs even less. The SAV is usually ++ * 1/20 of an instruction event. ++ * The start period of cache-related events = 25,000,000 / freq. ++ */ ++ config = event->attr.config & PERF_HW_EVENT_MASK; ++ if (type == PERF_TYPE_HARDWARE) { ++ switch (config) { ++ case PERF_COUNT_HW_CPU_CYCLES: ++ case PERF_COUNT_HW_INSTRUCTIONS: ++ case PERF_COUNT_HW_BUS_CYCLES: ++ case PERF_COUNT_HW_STALLED_CYCLES_FRONTEND: ++ case PERF_COUNT_HW_STALLED_CYCLES_BACKEND: ++ case PERF_COUNT_HW_REF_CPU_CYCLES: ++ factor = 500000000; ++ break; ++ case PERF_COUNT_HW_BRANCH_INSTRUCTIONS: ++ case PERF_COUNT_HW_BRANCH_MISSES: ++ factor = 125000000; ++ break; ++ case PERF_COUNT_HW_CACHE_REFERENCES: ++ case PERF_COUNT_HW_CACHE_MISSES: ++ factor = 25000000; ++ break; ++ default: ++ goto end; ++ } ++ } ++ ++ if (type == PERF_TYPE_HW_CACHE) ++ factor = 25000000; ++end: ++ /* ++ * Usually, a prime or a number with less factors (close to prime) ++ * is chosen as an SAV, which makes it less likely that the sampling ++ * period synchronizes with some periodic event in the workload. ++ * Minus 1 to make it at least avoiding values near power of twos ++ * for the default freq. ++ */ ++ start = DIV_ROUND_UP_ULL(factor, event->attr.sample_freq) - 1; ++ ++ if (start > x86_pmu.max_period) ++ start = x86_pmu.max_period; ++ ++ if (x86_pmu.limit_period) ++ x86_pmu.limit_period(event, &start); ++ ++ return start; ++} ++ + static int intel_pmu_hw_config(struct perf_event *event) + { + int ret = x86_pmu_hw_config(event); +@@ -3728,6 +3807,12 @@ static int intel_pmu_hw_config(struct perf_event *event) + if (ret) + return ret; + ++ if (event->attr.freq && event->attr.sample_freq) { ++ event->hw.sample_period = intel_pmu_freq_start_period(event); ++ event->hw.last_period = event->hw.sample_period; ++ local64_set(&event->hw.period_left, event->hw.sample_period); ++ } ++ + if (event->attr.precise_ip) { + if ((event->attr.config & INTEL_ARCH_EVENT_MASK) == INTEL_FIXED_VLBR_EVENT) + return -EINVAL; +-- +2.39.5 + diff --git a/queue-5.15/powercap-call-put_device-on-an-error-path-in-powerca.patch b/queue-5.15/powercap-call-put_device-on-an-error-path-in-powerca.patch new file mode 100644 index 0000000000..625e03d11e --- /dev/null +++ b/queue-5.15/powercap-call-put_device-on-an-error-path-in-powerca.patch @@ -0,0 +1,46 @@ +From bf17de7d14c4fe5eeeab45c56313315921793d38 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 10 Jan 2025 10:05:54 +0900 +Subject: powercap: call put_device() on an error path in + powercap_register_control_type() + +From: Joe Hattori + +[ Upstream commit 93c66fbc280747ea700bd6199633d661e3c819b3 ] + +powercap_register_control_type() calls device_register(), but does not +release the refcount of the device when it fails. + +Call put_device() before returning an error to balance the refcount. + +Since the kfree(control_type) will be done by powercap_release(), remove +the lines in powercap_register_control_type() before returning the error. + +This bug was found by an experimental verifier that I am developing. + +Signed-off-by: Joe Hattori +Link: https://patch.msgid.link/20250110010554.1583411-1-joe@pf.is.s.u-tokyo.ac.jp +[ rjw: Changelog edits ] +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Sasha Levin +--- + drivers/powercap/powercap_sys.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +diff --git a/drivers/powercap/powercap_sys.c b/drivers/powercap/powercap_sys.c +index ff736b006198f..fd475e463d1fa 100644 +--- a/drivers/powercap/powercap_sys.c ++++ b/drivers/powercap/powercap_sys.c +@@ -626,8 +626,7 @@ struct powercap_control_type *powercap_register_control_type( + dev_set_name(&control_type->dev, "%s", name); + result = device_register(&control_type->dev); + if (result) { +- if (control_type->allocated) +- kfree(control_type); ++ put_device(&control_type->dev); + return ERR_PTR(result); + } + idr_init(&control_type->idr); +-- +2.39.5 + diff --git a/queue-5.15/s390-cio-fix-chpid-configure-attribute-caching.patch b/queue-5.15/s390-cio-fix-chpid-configure-attribute-caching.patch new file mode 100644 index 0000000000..96144d60fc --- /dev/null +++ b/queue-5.15/s390-cio-fix-chpid-configure-attribute-caching.patch @@ -0,0 +1,60 @@ +From a2b7fdfcbe90823090b9f829a83397a051f8f739 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 31 Jan 2025 12:02:55 +0100 +Subject: s390/cio: Fix CHPID "configure" attribute caching + +From: Peter Oberparleiter + +[ Upstream commit 32ae4a2992529e2c7934e422035fad1d9b0f1fb5 ] + +In some environments, the SCLP firmware interface used to query a +CHPID's configured state is not supported. On these environments, +rapidly reading the corresponding sysfs attribute produces inconsistent +results: + + $ cat /sys/devices/css0/chp0.00/configure + cat: /sys/devices/css0/chp0.00/configure: Operation not supported + $ cat /sys/devices/css0/chp0.00/configure + 3 + +This occurs for example when Linux is run as a KVM guest. The +inconsistency is a result of CIO using cached results for generating +the value of the "configure" attribute while failing to handle the +situation where no data was returned by SCLP. + +Fix this by not updating the cache-expiration timestamp when SCLP +returns no data. With the fix applied, the system response is +consistent: + + $ cat /sys/devices/css0/chp0.00/configure + cat: /sys/devices/css0/chp0.00/configure: Operation not supported + $ cat /sys/devices/css0/chp0.00/configure + cat: /sys/devices/css0/chp0.00/configure: Operation not supported + +Reviewed-by: Vineeth Vijayan +Reviewed-by: Eric Farman +Tested-by: Eric Farman +Signed-off-by: Peter Oberparleiter +Signed-off-by: Vasily Gorbik +Signed-off-by: Sasha Levin +--- + drivers/s390/cio/chp.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/drivers/s390/cio/chp.c b/drivers/s390/cio/chp.c +index 1097e76982a5d..6b0f1b8bf2790 100644 +--- a/drivers/s390/cio/chp.c ++++ b/drivers/s390/cio/chp.c +@@ -661,7 +661,8 @@ static int info_update(void) + if (time_after(jiffies, chp_info_expires)) { + /* Data is too old, update. */ + rc = sclp_chp_read_info(&chp_info); +- chp_info_expires = jiffies + CHP_INFO_UPDATE_INTERVAL ; ++ if (!rc) ++ chp_info_expires = jiffies + CHP_INFO_UPDATE_INTERVAL; + } + mutex_unlock(&info_lock); + +-- +2.39.5 + diff --git a/queue-5.15/sched-clarify-wake_up_q-s-write-to-task-wake_q.next.patch b/queue-5.15/sched-clarify-wake_up_q-s-write-to-task-wake_q.next.patch new file mode 100644 index 0000000000..37af798082 --- /dev/null +++ b/queue-5.15/sched-clarify-wake_up_q-s-write-to-task-wake_q.next.patch @@ -0,0 +1,41 @@ +From 85ccd2d8250b2f2aea667388e456c37447cd1277 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 29 Jan 2025 20:53:03 +0100 +Subject: sched: Clarify wake_up_q()'s write to task->wake_q.next + +From: Jann Horn + +[ Upstream commit bcc6244e13b4d4903511a1ea84368abf925031c0 ] + +Clarify that wake_up_q() does an atomic write to task->wake_q.next, after +which a concurrent __wake_q_add() can immediately overwrite +task->wake_q.next again. + +Signed-off-by: Jann Horn +Signed-off-by: Peter Zijlstra (Intel) +Link: https://lkml.kernel.org/r/20250129-sched-wakeup-prettier-v1-1-2f51f5f663fa@google.com +Signed-off-by: Sasha Levin +--- + kernel/sched/core.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +diff --git a/kernel/sched/core.c b/kernel/sched/core.c +index 70a7cf563f01e..380938831b130 100644 +--- a/kernel/sched/core.c ++++ b/kernel/sched/core.c +@@ -941,9 +941,10 @@ void wake_up_q(struct wake_q_head *head) + struct task_struct *task; + + task = container_of(node, struct task_struct, wake_q); +- /* Task can safely be re-inserted now: */ + node = node->next; +- task->wake_q.next = NULL; ++ /* pairs with cmpxchg_relaxed() in __wake_q_add() */ ++ WRITE_ONCE(task->wake_q.next, NULL); ++ /* Task can safely be re-inserted now. */ + + /* + * wake_up_process() executes a full barrier, which pairs with +-- +2.39.5 + diff --git a/queue-5.15/scsi-core-use-gfp_noio-to-avoid-circular-locking-dep.patch b/queue-5.15/scsi-core-use-gfp_noio-to-avoid-circular-locking-dep.patch new file mode 100644 index 0000000000..2f6c576d34 --- /dev/null +++ b/queue-5.15/scsi-core-use-gfp_noio-to-avoid-circular-locking-dep.patch @@ -0,0 +1,59 @@ +From 1ea6ab8cd7eaed9b6ddd351236fa08fab1f3b4c0 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 28 Jan 2025 16:35:39 -0500 +Subject: scsi: core: Use GFP_NOIO to avoid circular locking dependency +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Rik van Riel + +[ Upstream commit 5363ee9d110e139584c2d92a0b640bc210588506 ] + +Filesystems can write to disk from page reclaim with __GFP_FS +set. Marc found a case where scsi_realloc_sdev_budget_map() ends up in +page reclaim with GFP_KERNEL, where it could try to take filesystem +locks again, leading to a deadlock. + +WARNING: possible circular locking dependency detected +6.13.0 #1 Not tainted +------------------------------------------------------ +kswapd0/70 is trying to acquire lock: +ffff8881025d5d78 (&q->q_usage_counter(io)){++++}-{0:0}, at: blk_mq_submit_bio+0x461/0x6e0 + +but task is already holding lock: +ffffffff81ef5f40 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat+0x9f/0x760 + +The full lockdep splat can be found in Marc's report: + +https://lkml.org/lkml/2025/1/24/1101 + +Avoid the potential deadlock by doing the allocation with GFP_NOIO, which +prevents both filesystem and block layer recursion. + +Reported-by: Marc Aurèle La France +Signed-off-by: Rik van Riel +Link: https://lore.kernel.org/r/20250129104525.0ae8421e@fangorn +Reviewed-by: Christoph Hellwig +Signed-off-by: Martin K. Petersen +Signed-off-by: Sasha Levin +--- + drivers/scsi/scsi_scan.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c +index 9c155d5768144..f00b4624e46b5 100644 +--- a/drivers/scsi/scsi_scan.c ++++ b/drivers/scsi/scsi_scan.c +@@ -229,7 +229,7 @@ static int scsi_realloc_sdev_budget_map(struct scsi_device *sdev, + } + ret = sbitmap_init_node(&sdev->budget_map, + scsi_device_max_queue_depth(sdev), +- new_shift, GFP_KERNEL, ++ new_shift, GFP_NOIO, + sdev->request_queue->node, false, true); + if (!ret) + sbitmap_resize(&sdev->budget_map, depth); +-- +2.39.5 + diff --git a/queue-5.15/scsi-qla1280-fix-kernel-oops-when-debug-level-2.patch b/queue-5.15/scsi-qla1280-fix-kernel-oops-when-debug-level-2.patch new file mode 100644 index 0000000000..d61210ce63 --- /dev/null +++ b/queue-5.15/scsi-qla1280-fix-kernel-oops-when-debug-level-2.patch @@ -0,0 +1,38 @@ +From e9ab6aba0630ff3e9cdce07eea3154a0e4b9495b Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 25 Jan 2025 10:49:22 +0100 +Subject: scsi: qla1280: Fix kernel oops when debug level > 2 + +From: Magnus Lindholm + +[ Upstream commit 5233e3235dec3065ccc632729675575dbe3c6b8a ] + +A null dereference or oops exception will eventually occur when qla1280.c +driver is compiled with DEBUG_QLA1280 enabled and ql_debug_level > 2. I +think its clear from the code that the intention here is sg_dma_len(s) not +length of sg_next(s) when printing the debug info. + +Signed-off-by: Magnus Lindholm +Link: https://lore.kernel.org/r/20250125095033.26188-1-linmag7@gmail.com +Signed-off-by: Martin K. Petersen +Signed-off-by: Sasha Levin +--- + drivers/scsi/qla1280.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/scsi/qla1280.c b/drivers/scsi/qla1280.c +index d0b4e063bfe1e..eb8e9c54837e0 100644 +--- a/drivers/scsi/qla1280.c ++++ b/drivers/scsi/qla1280.c +@@ -2875,7 +2875,7 @@ qla1280_64bit_start_scsi(struct scsi_qla_host *ha, struct srb * sp) + dprintk(3, "S/G Segment phys_addr=%x %x, len=0x%x\n", + cpu_to_le32(upper_32_bits(dma_handle)), + cpu_to_le32(lower_32_bits(dma_handle)), +- cpu_to_le32(sg_dma_len(sg_next(s)))); ++ cpu_to_le32(sg_dma_len(s))); + remseg--; + } + dprintk(5, "qla1280_64bit_start_scsi: Scatter/gather " +-- +2.39.5 + diff --git a/queue-5.15/sctp-fix-undefined-behavior-in-left-shift-operation.patch b/queue-5.15/sctp-fix-undefined-behavior-in-left-shift-operation.patch new file mode 100644 index 0000000000..aea10855c9 --- /dev/null +++ b/queue-5.15/sctp-fix-undefined-behavior-in-left-shift-operation.patch @@ -0,0 +1,43 @@ +From bd943bc76936469ebc8e70fc5f350cc354cdbf72 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 18 Feb 2025 16:12:16 +0800 +Subject: sctp: Fix undefined behavior in left shift operation + +From: Yu-Chun Lin + +[ Upstream commit 606572eb22c1786a3957d24307f5760bb058ca19 ] + +According to the C11 standard (ISO/IEC 9899:2011, 6.5.7): +"If E1 has a signed type and E1 x 2^E2 is not representable in the result +type, the behavior is undefined." + +Shifting 1 << 31 causes signed integer overflow, which leads to undefined +behavior. + +Fix this by explicitly using '1U << 31' to ensure the shift operates on +an unsigned type, avoiding undefined behavior. + +Signed-off-by: Yu-Chun Lin +Link: https://patch.msgid.link/20250218081217.3468369-1-eleanor15x@gmail.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + net/sctp/stream.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/net/sctp/stream.c b/net/sctp/stream.c +index ee6514af830f7..0527728aee986 100644 +--- a/net/sctp/stream.c ++++ b/net/sctp/stream.c +@@ -735,7 +735,7 @@ struct sctp_chunk *sctp_process_strreset_tsnreq( + * value SHOULD be the smallest TSN not acknowledged by the + * receiver of the request plus 2^31. + */ +- init_tsn = sctp_tsnmap_get_ctsn(&asoc->peer.tsn_map) + (1 << 31); ++ init_tsn = sctp_tsnmap_get_ctsn(&asoc->peer.tsn_map) + (1U << 31); + sctp_tsnmap_init(&asoc->peer.tsn_map, SCTP_TSN_MAP_INITIAL, + init_tsn, GFP_ATOMIC); + +-- +2.39.5 + diff --git a/queue-5.15/series b/queue-5.15/series index 4a744a5783..b1cbff4e67 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -21,3 +21,33 @@ openvswitch-use-kmalloc_size_roundup-to-match-ksize-.patch net-openvswitch-remove-misbehaving-actions-length-ch.patch net-mlx5-bridge-fix-the-crash-caused-by-lag-state-ch.patch net-mlx5e-prevent-bridge-link-show-failure-for-non-e.patch +nvme-fc-go-straight-to-connecting-state-when-initial.patch +hrtimers-mark-is_migration_base-with-__always_inline.patch +powercap-call-put_device-on-an-error-path-in-powerca.patch +iscsi_ibft-fix-ubsan-shift-out-of-bounds-warning-in-.patch +scsi-core-use-gfp_noio-to-avoid-circular-locking-dep.patch +scsi-qla1280-fix-kernel-oops-when-debug-level-2.patch +acpi-resource-irq-override-for-eluktronics-mech-17.patch +alpha-elf-fix-misc-setarch-test-of-util-linux-by-rem.patch +vboxsf-fix-building-with-gcc-15.patch +hid-intel-ish-hid-fix-the-length-of-mng_sync_fw_cloc.patch +hid-ignore-non-functional-sensor-in-hp-5mp-camera.patch +sched-clarify-wake_up_q-s-write-to-task-wake_q.next.patch +s390-cio-fix-chpid-configure-attribute-caching.patch +thermal-cpufreq_cooling-remove-structure-member-docu.patch +asoc-rsnd-don-t-indicate-warning-on-rsnd_kctrl_accep.patch +asoc-arizona-madera-use-fsleep-in-up-down-dapm-event.patch +asoc-sof-intel-hda-add-softdep-pre-to-snd-hda-codec-.patch +net-wwan-mhi_wwan_mbim-silence-sequence-number-glitc.patch +nvmet-rdma-recheck-queue-state-is-live-in-state-lock.patch +sctp-fix-undefined-behavior-in-left-shift-operation.patch +nvme-only-allow-entering-live-from-connecting-state.patch +asoc-tas2770-fix-volume-scale.patch +asoc-tas2764-fix-power-control-mask.patch +asoc-tas2764-set-the-sdout-polarity-correctly.patch +fuse-don-t-truncate-cached-mutated-symlink.patch +perf-x86-intel-use-better-start-period-for-frequency.patch +x86-irq-define-trace-events-conditionally.patch +mptcp-safety-check-before-fallback.patch +drm-nouveau-do-not-override-forced-connector-status.patch +block-fix-kmem_cache-of-name-bio-108-already-exists.patch diff --git a/queue-5.15/thermal-cpufreq_cooling-remove-structure-member-docu.patch b/queue-5.15/thermal-cpufreq_cooling-remove-structure-member-docu.patch new file mode 100644 index 0000000000..f89e13c1d0 --- /dev/null +++ b/queue-5.15/thermal-cpufreq_cooling-remove-structure-member-docu.patch @@ -0,0 +1,41 @@ +From 7dec8f75d6c7492e904b0de71b4dbf64eda2f793 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 11 Feb 2025 09:47:11 +0100 +Subject: thermal/cpufreq_cooling: Remove structure member documentation + +From: Daniel Lezcano + +[ Upstream commit a6768c4f92e152265590371975d44c071a5279c7 ] + +The structure member documentation refers to a member which does not +exist any more. Remove it. + +Link: https://lore.kernel.org/all/202501220046.h3PMBCti-lkp@intel.com/ +Reported-by: kernel test robot +Closes: https://lore.kernel.org/oe-kbuild-all/202501220046.h3PMBCti-lkp@intel.com/ +Signed-off-by: Daniel Lezcano +Acked-by: Viresh Kumar +Link: https://patch.msgid.link/20250211084712.2746705-1-daniel.lezcano@linaro.org +[ rjw: Minor changelog edits ] +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Sasha Levin +--- + drivers/thermal/cpufreq_cooling.c | 2 -- + 1 file changed, 2 deletions(-) + +diff --git a/drivers/thermal/cpufreq_cooling.c b/drivers/thermal/cpufreq_cooling.c +index 12a60415af955..8171c806f5f6f 100644 +--- a/drivers/thermal/cpufreq_cooling.c ++++ b/drivers/thermal/cpufreq_cooling.c +@@ -56,8 +56,6 @@ struct time_in_idle { + * @max_level: maximum cooling level. One less than total number of valid + * cpufreq frequencies. + * @em: Reference on the Energy Model of the device +- * @cdev: thermal_cooling_device pointer to keep track of the +- * registered cooling device. + * @policy: cpufreq policy. + * @idle_time: idle time stats + * @qos_req: PM QoS contraint to apply +-- +2.39.5 + diff --git a/queue-5.15/vboxsf-fix-building-with-gcc-15.patch b/queue-5.15/vboxsf-fix-building-with-gcc-15.patch new file mode 100644 index 0000000000..00f4aa684b --- /dev/null +++ b/queue-5.15/vboxsf-fix-building-with-gcc-15.patch @@ -0,0 +1,51 @@ +From e51c370be310c88409f2edc2409bf939e96307d8 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 21 Jan 2025 21:56:48 +0530 +Subject: vboxsf: fix building with GCC 15 +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Brahmajit Das + +[ Upstream commit 4e7487245abcbc5a1a1aea54e4d3b33c53804bda ] + +Building with GCC 15 results in build error +fs/vboxsf/super.c:24:54: error: initializer-string for array of ‘unsigned char’ is too long [-Werror=unterminated-string-initialization] + 24 | static const unsigned char VBSF_MOUNT_SIGNATURE[4] = "\000\377\376\375"; + | ^~~~~~~~~~~~~~~~~~ +cc1: all warnings being treated as errors + +Due to GCC having enabled -Werror=unterminated-string-initialization[0] +by default. Separately initializing each array element of +VBSF_MOUNT_SIGNATURE to ensure NUL termination, thus satisfying GCC 15 +and fixing the build error. + +[0]: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wno-unterminated-string-initialization + +Signed-off-by: Brahmajit Das +Link: https://lore.kernel.org/r/20250121162648.1408743-1-brahmajit.xyz@gmail.com +Reviewed-by: Hans de Goede +Signed-off-by: Christian Brauner +Signed-off-by: Sasha Levin +--- + fs/vboxsf/super.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/fs/vboxsf/super.c b/fs/vboxsf/super.c +index 44725007ccc2c..20cfb2a9e8707 100644 +--- a/fs/vboxsf/super.c ++++ b/fs/vboxsf/super.c +@@ -21,7 +21,8 @@ + + #define VBOXSF_SUPER_MAGIC 0x786f4256 /* 'VBox' little endian */ + +-static const unsigned char VBSF_MOUNT_SIGNATURE[4] = "\000\377\376\375"; ++static const unsigned char VBSF_MOUNT_SIGNATURE[4] = { '\000', '\377', '\376', ++ '\375' }; + + static int follow_symlinks; + module_param(follow_symlinks, int, 0444); +-- +2.39.5 + diff --git a/queue-5.15/x86-irq-define-trace-events-conditionally.patch b/queue-5.15/x86-irq-define-trace-events-conditionally.patch new file mode 100644 index 0000000000..a76a77c691 --- /dev/null +++ b/queue-5.15/x86-irq-define-trace-events-conditionally.patch @@ -0,0 +1,48 @@ +From 245debcc9e034ebd84a3c8175a4232c676fa0928 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 25 Feb 2025 22:32:33 +0100 +Subject: x86/irq: Define trace events conditionally + +From: Arnd Bergmann + +[ Upstream commit 9de7695925d5d2d2085681ba935857246eb2817d ] + +When both of X86_LOCAL_APIC and X86_THERMAL_VECTOR are disabled, +the irq tracing produces a W=1 build warning for the tracing +definitions: + + In file included from include/trace/trace_events.h:27, + from include/trace/define_trace.h:113, + from arch/x86/include/asm/trace/irq_vectors.h:383, + from arch/x86/kernel/irq.c:29: + include/trace/stages/init.h:2:23: error: 'str__irq_vectors__trace_system_name' defined but not used [-Werror=unused-const-variable=] + +Make the tracepoints conditional on the same symbosl that guard +their usage. + +Signed-off-by: Arnd Bergmann +Signed-off-by: Ingo Molnar +Link: https://lore.kernel.org/r/20250225213236.3141752-1-arnd@kernel.org +Signed-off-by: Sasha Levin +--- + arch/x86/kernel/irq.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c +index 766ffe3ba3137..439fdb3f5fdf1 100644 +--- a/arch/x86/kernel/irq.c ++++ b/arch/x86/kernel/irq.c +@@ -23,8 +23,10 @@ + #include + #include + ++#if defined(CONFIG_X86_LOCAL_APIC) || defined(CONFIG_X86_THERMAL_VECTOR) + #define CREATE_TRACE_POINTS + #include ++#endif + + DEFINE_PER_CPU_SHARED_ALIGNED(irq_cpustat_t, irq_stat); + EXPORT_PER_CPU_SYMBOL(irq_stat); +-- +2.39.5 +