Linux 6.19-rc1 mediatek mt7921e broke badly

Linux 6.19-rc1 mediatek mt7921e broke badly

[Shuah Khan]

mt7921e doesn't load on my primary laptopn on Linux 6.19-rc1 and problem
still there on 6.19-rc2.

  From what I can tell from dmesg it attempts to do load firmware
in mt792x_load_firmware() during and then generates warns and
fails to load the module. dmesg excerpt below.

commit 066f417be5fd8c7fe581c5550206364735dad7a3
Author: Quan Zhou <quan.zhou@mediatek.com>
Date:   Tue Nov 18 19:54:54 2025 +0800

      wifi: mt76: mt792x: fix wifi init fail by setting MCU_RUNNING after CLC load

The above commit changes when the MCU_RUNNING bit is set in mt7925_run_firmware(),
changing it to set this bit only after mt7921_load_clc() completes.

I didn't get a chance to bisect yet and a quick revert of the patch didn't solve
the problem. This is a serious problem for me since my wifi is dead on my
primary laptop. Hope a fix is coming soon.

I am available for debug/testing help early next week.

thanks,
-- Shuah

dmesg
=====================================================================================

kern  :crit  : kernel BUG at lib/string_helpers.c:1043!
kern  :warn  : Oops: invalid opcode: 0000 [#1] SMP NOPTI
kern  :warn  : CPU: 14 UID: 0 PID: 61 Comm: kworker/14:0 Tainted: G        W
         6.19.0-rc1 #1 PREEMPT(voluntary)
kern  :warn  : Tainted: [W]=WARN
kern  :warn  : Hardware name: Framework Laptop 13 (AMD Ryzen 7040Series)/FRANMDCP07, BIOS 03.16 07/25/2025
kern  :warn  : Workqueue: events mt7921_init_work [mt7921_common]
kern  :warn  : RIP: 0010:__fortify_panic+0xd/0xf
kern  :warn  : Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 40 0f b6 ff e8 c3 55 71 00 <0f> 0b 48 8b 54 24 10 48 8b 74 24 08 4c 89 e9 48 c7 c7 00 a2 d5 a0
kern  :warn  : RSP: 0018:ffffa7a5c03a3d10 EFLAGS: 00010246
kern  :warn  : RAX: ffffffffa0d7aaf2 RBX: 0000000000000000 RCX: ffffffffa0d7aaf2
kern  :warn  : RDX: 0000000000000011 RSI: ffffffffa0d5a170 RDI: ffffffffa128db10
kern  :warn  : RBP: ffff91650ae52060 R08: 0000000000000010 R09: ffffa7a5c31b2000
kern  :warn  : R10: ffffa7a5c03a3bf0 R11: 00000000ffffffff R12: 0000000000000000
kern  :warn  : R13: ffffa7a5c31b2000 R14: 0000000000001000 R15: 0000000000000000
kern  :warn  : FS:  0000000000000000(0000) GS:ffff91743e664000(0000) knlGS:0000000000000000
kern  :warn  : CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kern  :warn  : CR2: 00007f10786c241c CR3: 00000003eca24000 CR4: 0000000000f50ef0
kern  :warn  : PKRU: 55555554
kern  :warn  : Call Trace:
kern  :warn  :  <TASK>
kern  :warn  :  mt76_connac2_load_patch.cold+0x2b/0xa41 [mt76_connac_lib]
kern  :warn  :  ? srso_alias_return_thunk+0x5/0xfbef5
kern  :warn  :  mt792x_load_firmware+0x36/0x150 [mt792x_lib]
kern  :warn  :  mt7921_run_firmware+0x2c/0x4a0 [mt7921_common]
kern  :warn  :  ? srso_alias_return_thunk+0x5/0xfbef5
kern  :warn  :  ? mt7921_rr+0x12/0x30 [mt7921e]
kern  :warn  :  ? srso_alias_return_thunk+0x5/0xfbef5
kern  :warn  :  ? ____mt76_poll_msec+0x75/0xb0 [mt76]
kern  :warn  :  mt7921e_mcu_init+0x4c/0x7a [mt7921e]
kern  :warn  :  mt7921_init_work+0x51/0x190 [mt7921_common]
kern  :warn  :  process_one_work+0x18b/0x340
kern  :warn  :  worker_thread+0x256/0x3a0
kern  :warn  :  ? __pfx_worker_thread+0x10/0x10
kern  :warn  :  kthread+0xfc/0x240
kern  :warn  :  ? __pfx_kthread+0x10/0x10
kern  :warn  :  ? __pfx_kthread+0x10/0x10
kern  :warn  :  ret_from_fork+0x254/0x290
kern  :warn  :  ? __pfx_kthread+0x10/0x10
kern  :warn  :  ret_from_fork_asm+0x1a/0x30
kern  :warn  :  </TASK>
kern  :warn  : Modules linked in: snd_hda_codec_alc269(+) snd_sof_amd_rembrandt mt7921e snd_hda_scodec_component snd_sof_amd_acp snd_hda_codec_realtek_lib mt7921_common snd_sof_pci snd_sof_xtensa_dsp snd_hda_codec_generic btusb amd_atl mt792x_lib uvcvideo snd_hda_codec_atihdmi intel_rapl_msr mt76_connac_lib snd_sof btrtl intel_rapl_common snd_hda_codec_hdmi btintel videobuf2_vmalloc mt76 videobuf2_memops btbcm uvc snd_sof_utils videobuf2_v4l2 kvm_amd btmtk hid_sensor_als snd_hda_intel mac80211 hid_sensor_trigger snd_soc_core videodev bluetooth snd_hda_codec industrialio_triggered_buffer hid_sensor_iio_common snd_compress videobuf2_common kvm snd_hwdep libarc4 kfifo_buf snd_pci_ps industrialio snd_soc_acpi_amd_match mc snd_hda_core snd_rpl_pci_acp6x irqbypass cfg80211 snd_intel_dspcfg snd_pci_acp6x amd_pmf rapl snd_pci_acp5x snd_pcm amdtee leds_cros_ec snd_rn_pci_acp3x hid_sensor_hub wmi_bmof snd_timer led_class_multicolor snd_acp_config snd_soc_acpi cros_ec_hwmon snd spd5118 ccp snd_pci_acp3x pcspkr platform_profile
kern  :warn  :  soundcore rfkill k10temp ac button amd_sfh tee amd_pmc joydev evdev msr parport_pc ppdev lp parport configfs efi_pstore nfnetlink efivarfs autofs4 ext4 mbcache jbd2 dm_crypt dm_mod usbhid amdgpu amdxcp i2c_algo_bit drm_client_lib drm_ttm_helper ttm ucsi_acpi typec_ucsi drm_exec drm_panel_backlight_quirks roles gpu_sched hid_multitouch typec drm_suballoc_helper drm_buddy hid_generic xhci_pci drm_display_helper cros_ec_debugfs cros_ec_sysfs cros_charge_control cros_ec_chardev cros_kbd_led_backlight i2c_hid_acpi xhci_hcd i2c_hid hid drm_kms_helper sp5100_tco watchdog cros_ec_dev thunderbolt drm usbcore nvme ghash_clmulni_intel cec aesni_intel nvme_core rc_core serio_raw i2c_piix4 i2c_smbus crc16 video usb_common battery wmi cros_ec_lpcs cros_ec cros_ec_proto

Re: Linux 6.19-rc1 mediatek mt7921e broke badly

[Thomas Weißschuh]

Hi Shuah,

On 2025-12-27 02:07:24-0700, Shuah Khan wrote:
> mt7921e doesn't load on my primary laptopn on Linux 6.19-rc1 and problem
> still there on 6.19-rc2.

This should be a duplicate of
https://lore.kernel.org/all/CABXGCsMeAZyNJ-Axt_CUCXgyieWPV3rrcLpWsveMPT8R0YPGnQ@mail.gmail.com/

(...)


Thomas

Re: Linux 6.19-rc1 mediatek mt7921e broke badly

[Linus Torvalds]

On Sat, 27 Dec 2025 at 04:25, Thomas Weißschuh <linux@weissschuh.net> wrote:
>
> Hi Shuah,
>
> On 2025-12-27 02:07:24-0700, Shuah Khan wrote:
> > mt7921e doesn't load on my primary laptopn on Linux 6.19-rc1 and problem
> > still there on 6.19-rc2.
>
> This should be a duplicate of
> https://lore.kernel.org/all/CABXGCsMeAZyNJ-Axt_CUCXgyieWPV3rrcLpWsveMPT8R0YPGnQ@mail.gmail.com/

Hmm. I wonder if we could instead do this:

  --- a/lib/string.c
  +++ b/lib/string.c
  @@ -113,7 +113,7 @@ EXPORT_SYMBOL(strncpy);
   ssize_t sized_strscpy(char *dest, const char *src, size_t count)
   {
          const struct word_at_a_time constants = WORD_AT_A_TIME_CONSTANTS;
  -       size_t max = count;
  +       size_t max = count - 1;
          long res = 0;

          if (count == 0 || WARN_ON_ONCE(count > INT_MAX))

(intentionally whitespace-damaged patch, because I want people to
think about it).

It basically says that if the size of the 'strscpy()' buffer is N,
then we do the "word-at-a-time" only up to 'N-1' bytes, because we
don't even need to read the last byte of the source, because we will
always NUL-terminate the destination...

That would basically make it ok to use a destination that is one byte
larger than the source (in order to fit NUL termination that doesn't
exist in the source).

The downside, of course, is that it means that we possibly miss out of
doing the last word of the copy a word-at-a-time. But possibly not a
big downside, and it would make strscpy() able to deal with this case
natively.

The *real* issue is that we don't have a "source is this big,
destination is that big" version of string copy.

Normally that is a non-issue - just pick the smaller size of the two.
Except for this particular case, where the destination is exactly one
byte larger, and wants to be NUL-terminated while the source might not
be.

I haven't really thought this through fully, which is why that patch
is very much whitespace-damaged. Somebody else should verify my
thinking.

                   Linus

Re: Linux 6.19-rc1 mediatek mt7921e broke badly

[Matthew Schwartz]

On 12/29/25 4:41 PM, Linus Torvalds wrote:
> On Sat, 27 Dec 2025 at 04:25, Thomas Weißschuh <linux@weissschuh.net> wrote:
>>
>> Hi Shuah,
>>
>> On 2025-12-27 02:07:24-0700, Shuah Khan wrote:
>>> mt7921e doesn't load on my primary laptopn on Linux 6.19-rc1 and problem
>>> still there on 6.19-rc2.
>>
>> This should be a duplicate of
>> https://lore.kernel.org/all/CABXGCsMeAZyNJ-Axt_CUCXgyieWPV3rrcLpWsveMPT8R0YPGnQ@mail.gmail.com/
> 
> Hmm. I wonder if we could instead do this:
> 
>   --- a/lib/string.c
>   +++ b/lib/string.c
>   @@ -113,7 +113,7 @@ EXPORT_SYMBOL(strncpy);
>    ssize_t sized_strscpy(char *dest, const char *src, size_t count)
>    {
>           const struct word_at_a_time constants = WORD_AT_A_TIME_CONSTANTS;
>   -       size_t max = count;
>   +       size_t max = count - 1;
>           long res = 0;
> 
>           if (count == 0 || WARN_ON_ONCE(count > INT_MAX))
> 
> (intentionally whitespace-damaged patch, because I want people to
> think about it).

I gave this a try on its own but I was still experiencing a kernel crash:

[    3.339408] strnlen: detected buffer overflow: 17 byte read of buffer size 16
[    3.339804] WARNING: lib/string_helpers.c:1035 at __fortify_report+0x41/0x50, CPU#14: kworker/14:0/105
[    3.352248]  __fortify_panic+0xd/0xf
[    3.352259]  mt76_connac2_load_patch.cold+0x2b/0x95a [mt76_connac_lib 8f0d0f7b30f881af23462dac0a8cc5ff88d08cd0]

However, applying a similar diff in the fortify wrapper does prevent the crash:

--- a/include/linux/fortify-string.h
+++ b/include/linux/fortify-string.h
@@ -306,13 +306,13 @@ __FORTIFY_INLINE ssize_t sized_strscpy(char * const POS p, const char * const PO
      * This call protects from read overflow, because len will default to q
      * length if it smaller than size.
      */
-    len = strnlen(q, size);
+    len = strnlen(q, size - 1);
     /*
      * If len equals size, we will copy only size bytes which leads to
      * -E2BIG being returned.
      * Otherwise we will copy len + 1 because of the final '\O'.
      */
-    len = len == size ? size : len + 1;
+    len = len == size - 1 ? size : len + 1;
 
     /*
      * Generate a runtime write overflow error if len is greater than

Not sure what the implications of such a change would be relative to the proposed
fix here: https://lore.kernel.org/all/20251205161202.48409-1-mikhail.v.gavrilov@gmail.com/

Matt

> 
> It basically says that if the size of the 'strscpy()' buffer is N,
> then we do the "word-at-a-time" only up to 'N-1' bytes, because we
> don't even need to read the last byte of the source, because we will
> always NUL-terminate the destination...
> 
> That would basically make it ok to use a destination that is one byte
> larger than the source (in order to fit NUL termination that doesn't
> exist in the source).
> 
> The downside, of course, is that it means that we possibly miss out of
> doing the last word of the copy a word-at-a-time. But possibly not a
> big downside, and it would make strscpy() able to deal with this case
> natively.
> 
> The *real* issue is that we don't have a "source is this big,
> destination is that big" version of string copy.
> 
> Normally that is a non-issue - just pick the smaller size of the two.
> Except for this particular case, where the destination is exactly one
> byte larger, and wants to be NUL-terminated while the source might not
> be.
> 
> I haven't really thought this through fully, which is why that patch
> is very much whitespace-damaged. Somebody else should verify my
> thinking.
> 
>                    Linus
> 

Re: Linux 6.19-rc1 mediatek mt7921e broke badly

[Shuah Khan]

On 12/29/25 21:21, Matthew Schwartz wrote:
> On 12/29/25 4:41 PM, Linus Torvalds wrote:
>> On Sat, 27 Dec 2025 at 04:25, Thomas Weißschuh <linux@weissschuh.net> wrote:
>>>
>>> Hi Shuah,
>>>
>>> On 2025-12-27 02:07:24-0700, Shuah Khan wrote:
>>>> mt7921e doesn't load on my primary laptopn on Linux 6.19-rc1 and problem
>>>> still there on 6.19-rc2.
>>>
>>> This should be a duplicate of
>>> https://lore.kernel.org/all/CABXGCsMeAZyNJ-Axt_CUCXgyieWPV3rrcLpWsveMPT8R0YPGnQ@mail.gmail.com/
>>
>> Hmm. I wonder if we could instead do this:
>>
>>    --- a/lib/string.c
>>    +++ b/lib/string.c
>>    @@ -113,7 +113,7 @@ EXPORT_SYMBOL(strncpy);
>>     ssize_t sized_strscpy(char *dest, const char *src, size_t count)
>>     {
>>            const struct word_at_a_time constants = WORD_AT_A_TIME_CONSTANTS;
>>    -       size_t max = count;
>>    +       size_t max = count - 1;
>>            long res = 0;
>>
>>            if (count == 0 || WARN_ON_ONCE(count > INT_MAX))
>>
>> (intentionally whitespace-damaged patch, because I want people to
>> think about it).
> 
> I gave this a try on its own but I was still experiencing a kernel crash:
> 
> [    3.339408] strnlen: detected buffer overflow: 17 byte read of buffer size 16
> [    3.339804] WARNING: lib/string_helpers.c:1035 at __fortify_report+0x41/0x50, CPU#14: kworker/14:0/105
> [    3.352248]  __fortify_panic+0xd/0xf
> [    3.352259]  mt76_connac2_load_patch.cold+0x2b/0x95a [mt76_connac_lib 8f0d0f7b30f881af23462dac0a8cc5ff88d08cd0]
> 
> However, applying a similar diff in the fortify wrapper does prevent the crash:
> 
> --- a/include/linux/fortify-string.h
> +++ b/include/linux/fortify-string.h
> @@ -306,13 +306,13 @@ __FORTIFY_INLINE ssize_t sized_strscpy(char * const POS p, const char * const PO
>        * This call protects from read overflow, because len will default to q
>        * length if it smaller than size.
>        */
> -    len = strnlen(q, size);
> +    len = strnlen(q, size - 1);
>       /*
>        * If len equals size, we will copy only size bytes which leads to
>        * -E2BIG being returned.
>        * Otherwise we will copy len + 1 because of the final '\O'.
>        */
> -    len = len == size ? size : len + 1;
> +    len = len == size - 1 ? size : len + 1;
>   
>       /*
>        * Generate a runtime write overflow error if len is greater than
> 
> Not sure what the implications of such a change would be relative to the proposed
> fix here: https://lore.kernel.org/all/20251205161202.48409-1-mikhail.v.gavrilov@gmail.com/

+ adding Johannes to this thread also.

Reverting the following fixed my problem.
  
f804a5895eba ("wifi: mt76: Strip whitespace from build ddate")

The above fixes an extra newline in the dmesg by making the
code more complex it needs to introducing local buffers and
strscpy() - the proposed fix replaces this with memcpy().

Is there a simple way to do this than introducing memcpy()
or strscpy() to remove an extra newline that might or might
not exist? Why not check if newline exists or not using
strstr()?

I would recommend reverting f804a5895eba instead of trying
fix it. Then find a better way to eliminate extra newline that
shows up in dmesg when firmware build date happens to have
a newline.

thanks,
-- Shuah

Re: Linux 6.19-rc1 mediatek mt7921e broke badly

[Linus Torvalds]

On Tue, 30 Dec 2025 at 15:57, Shuah Khan <skhan@linuxfoundation.org> wrote:
>
> I would recommend reverting f804a5895eba instead of trying
> fix it. Then find a better way to eliminate extra newline that
> shows up in dmesg when firmware build date happens to have
> a newline.

Yeah. Let's revert it.

And the way to fix the extra newline is trivial: just remove it from
the "dev_info()" format string.

Our kernel printing logic will add a newline for the next line anyway
if it is missing (unless somebody explicitly uses PR_CONT).

Can whoever saw the problem confirm that just a revert and a "remove
\n from that dev_info()" fixes the output for them?

              Linus

Re: Linux 6.19-rc1 mediatek mt7921e broke badly

[Eric Biggers]

On Tue, Dec 30, 2025 at 05:27:13PM -0800, Linus Torvalds wrote:
> On Tue, 30 Dec 2025 at 15:57, Shuah Khan <skhan@linuxfoundation.org> wrote:
> >
> > I would recommend reverting f804a5895eba instead of trying
> > fix it. Then find a better way to eliminate extra newline that
> > shows up in dmesg when firmware build date happens to have
> > a newline.
> 
> Yeah. Let's revert it.
> 
> And the way to fix the extra newline is trivial: just remove it from
> the "dev_info()" format string.
> 
> Our kernel printing logic will add a newline for the next line anyway
> if it is missing (unless somebody explicitly uses PR_CONT).
> 
> Can whoever saw the problem confirm that just a revert and a "remove
> \n from that dev_info()" fixes the output for them?

That works for me.  The revert by itself makes the FORTIFY_SOURCE crash
go away and reintroduces a blank line in the log.  Removing the \n from
the string passed to dev_info as well makes the blank line go away.

- Eric

Re: Linux 6.19-rc1 mediatek mt7921e broke badly

[Shuah Khan]

On 12/30/25 18:57, Eric Biggers wrote:
> On Tue, Dec 30, 2025 at 05:27:13PM -0800, Linus Torvalds wrote:
>> On Tue, 30 Dec 2025 at 15:57, Shuah Khan <skhan@linuxfoundation.org> wrote:
>>>
>>> I would recommend reverting f804a5895eba instead of trying
>>> fix it. Then find a better way to eliminate extra newline that
>>> shows up in dmesg when firmware build date happens to have
>>> a newline.
>>
>> Yeah. Let's revert it.
>>
>> And the way to fix the extra newline is trivial: just remove it from
>> the "dev_info()" format string.
>>
>> Our kernel printing logic will add a newline for the next line anyway
>> if it is missing (unless somebody explicitly uses PR_CONT).
>>
>> Can whoever saw the problem confirm that just a revert and a "remove
>> \n from that dev_info()" fixes the output for them?
> 
> That works for me.  The revert by itself makes the FORTIFY_SOURCE crash
> go away and reintroduces a blank line in the log.  Removing the \n from
> the string passed to dev_info as well makes the blank line go away.
> 

I just sent the revert. I will try removing \n from dev_info()
later on tomorrow.

My quick trial still showed extra line which didn't make sense
to me. More trials have to wait for tomorrow.

thanks,
-- Shuah

Re: Linux 6.19-rc1 mediatek mt7921e broke badly

[Shuah Khan]

On 12/30/25 21:00, Shuah Khan wrote:
> On 12/30/25 18:57, Eric Biggers wrote:
>> On Tue, Dec 30, 2025 at 05:27:13PM -0800, Linus Torvalds wrote:
>>> On Tue, 30 Dec 2025 at 15:57, Shuah Khan <skhan@linuxfoundation.org> wrote:
>>>>
>>>> I would recommend reverting f804a5895eba instead of trying
>>>> fix it. Then find a better way to eliminate extra newline that
>>>> shows up in dmesg when firmware build date happens to have
>>>> a newline.
>>>
>>> Yeah. Let's revert it.
>>>
>>> And the way to fix the extra newline is trivial: just remove it from
>>> the "dev_info()" format string.
>>>
>>> Our kernel printing logic will add a newline for the next line anyway
>>> if it is missing (unless somebody explicitly uses PR_CONT).
>>>
>>> Can whoever saw the problem confirm that just a revert and a "remove
>>> \n from that dev_info()" fixes the output for them?
>>
>> That works for me.  The revert by itself makes the FORTIFY_SOURCE crash
>> go away and reintroduces a blank line in the log.  Removing the \n from
>> the string passed to dev_info as well makes the blank line go away.
>>
> 
> I just sent the revert. I will try removing \n from dev_info()
> later on tomorrow.
> 
> My quick trial still showed extra line which didn't make sense
> to me. More trials have to wait for tomorrow.
> 

Hmm - there are 3 places that print build_date in  mt76_connac2_load_ram()

3022         dev_info(dev->dev, "WM Firmware Version: %.10s, Build Time: %.15s\n     ",
3023                  hdr->fw_ver, hdr->build_date);


3051         dev_info(dev->dev, "WA Firmware Version: %.10s, Build Time: %.15s\n     ",
3052                  hdr->fw_ver, hdr->build_date);

3127         dev_info(dev->dev, "HW/SW Version: 0x%x, Build Time: %.16s\n",
3128                  be32_to_cpu(hdr->hw_sw_ver), hdr->build_date);

The last one prints %.16s and other two do %.15s - is the fix simply
changing last one on line 3127 to print %.15s - this avoids printing
the extra \n?

thanks,
-- Shuah

Re: Linux 6.19-rc1 mediatek mt7921e broke badly

[Thomas Weißschuh]

On 2025-12-30 16:57:20-0700, Shuah Khan wrote:
> On 12/29/25 21:21, Matthew Schwartz wrote:
> > On 12/29/25 4:41 PM, Linus Torvalds wrote:
> > > On Sat, 27 Dec 2025 at 04:25, Thomas Weißschuh <linux@weissschuh.net> wrote:
> > > > 
> > > > Hi Shuah,
> > > > 
> > > > On 2025-12-27 02:07:24-0700, Shuah Khan wrote:
> > > > > mt7921e doesn't load on my primary laptopn on Linux 6.19-rc1 and problem
> > > > > still there on 6.19-rc2.
> > > > 
> > > > This should be a duplicate of
> > > > https://lore.kernel.org/all/CABXGCsMeAZyNJ-Axt_CUCXgyieWPV3rrcLpWsveMPT8R0YPGnQ@mail.gmail.com/

(...)
 
> Reverting the following fixed my problem.
> f804a5895eba ("wifi: mt76: Strip whitespace from build ddate")
> 
> The above fixes an extra newline in the dmesg by making the
> code more complex it needs to introducing local buffers and
> strscpy() - the proposed fix replaces this with memcpy().
> 
> Is there a simple way to do this than introducing memcpy()
> or strscpy() to remove an extra newline that might or might
> not exist? Why not check if newline exists or not using
> strstr()?

We do have memtostr() which would be a perfect fit to use here.
That is still a memcpy() under the hood, but the code is clear and safe.
It does however require the source to be annotated as __nonstring.
Which also seems to be the right choice here anyways. However for
consistency, all other similar fields should also be annotated in the
same way. So it is a bit of a larger change than a pure bugfix.


Thomas

Re: Linux 6.19-rc1 mediatek mt7921e broke badly

[Shuah Khan]

On 12/31/25 03:36, Thomas Weißschuh wrote:
> On 2025-12-30 16:57:20-0700, Shuah Khan wrote:
>> On 12/29/25 21:21, Matthew Schwartz wrote:
>>> On 12/29/25 4:41 PM, Linus Torvalds wrote:
>>>> On Sat, 27 Dec 2025 at 04:25, Thomas Weißschuh <linux@weissschuh.net> wrote:
>>>>>
>>>>> Hi Shuah,
>>>>>
>>>>> On 2025-12-27 02:07:24-0700, Shuah Khan wrote:
>>>>>> mt7921e doesn't load on my primary laptopn on Linux 6.19-rc1 and problem
>>>>>> still there on 6.19-rc2.
>>>>>
>>>>> This should be a duplicate of
>>>>> https://lore.kernel.org/all/CABXGCsMeAZyNJ-Axt_CUCXgyieWPV3rrcLpWsveMPT8R0YPGnQ@mail.gmail.com/
> 
> (...)
>   
>> Reverting the following fixed my problem.
>> f804a5895eba ("wifi: mt76: Strip whitespace from build ddate")
>>
>> The above fixes an extra newline in the dmesg by making the
>> code more complex it needs to introducing local buffers and
>> strscpy() - the proposed fix replaces this with memcpy().
>>
>> Is there a simple way to do this than introducing memcpy()
>> or strscpy() to remove an extra newline that might or might
>> not exist? Why not check if newline exists or not using
>> strstr()?
> 
> We do have memtostr() which would be a perfect fit to use here.
> That is still a memcpy() under the hood, but the code is clear and safe.
> It does however require the source to be annotated as __nonstring.
> Which also seems to be the right choice here anyways. However for
> consistency, all other similar fields should also be annotated in the
> same way. So it is a bit of a larger change than a pure bugfix.
> 

I am playing with just removing \n from dev_info() - there are
three dev_info()s in the same routine that print the same
information. I will also take a look to see if they are indeed
needed.

thanks,
-- Shuah

Re: Linux 6.19-rc1 mediatek mt7921e broke badly

[Shuah Khan]

On 12/30/25 21:07, Shuah Khan wrote:
> On 12/30/25 21:00, Shuah Khan wrote:
>> On 12/30/25 18:57, Eric Biggers wrote:
>>> On Tue, Dec 30, 2025 at 05:27:13PM -0800, Linus Torvalds wrote:
>>>> On Tue, 30 Dec 2025 at 15:57, Shuah Khan <skhan@linuxfoundation.org> wrote:
>>>>>
>>>>> I would recommend reverting f804a5895eba instead of trying
>>>>> fix it. Then find a better way to eliminate extra newline that
>>>>> shows up in dmesg when firmware build date happens to have
>>>>> a newline.
>>>>
>>>> Yeah. Let's revert it.
>>>>
>>>> And the way to fix the extra newline is trivial: just remove it from
>>>> the "dev_info()" format string.
>>>>
>>>> Our kernel printing logic will add a newline for the next line anyway
>>>> if it is missing (unless somebody explicitly uses PR_CONT).
>>>>
>>>> Can whoever saw the problem confirm that just a revert and a "remove
>>>> \n from that dev_info()" fixes the output for them?
>>>
>>> That works for me.  The revert by itself makes the FORTIFY_SOURCE crash
>>> go away and reintroduces a blank line in the log.  Removing the \n from
>>> the string passed to dev_info as well makes the blank line go away.
>>>
>>
>> I just sent the revert. I will try removing \n from dev_info()
>> later on tomorrow.
>>
>> My quick trial still showed extra line which didn't make sense
>> to me. More trials have to wait for tomorrow.
>>
> 
> Hmm - there are 3 places that print build_date in  mt76_connac2_load_ram()
> 
> 3022         dev_info(dev->dev, "WM Firmware Version: %.10s, Build Time: %.15s\n     ",
> 3023                  hdr->fw_ver, hdr->build_date);
> 
> 
> 3051         dev_info(dev->dev, "WA Firmware Version: %.10s, Build Time: %.15s\n     ",
> 3052                  hdr->fw_ver, hdr->build_date);
> 
> 3127         dev_info(dev->dev, "HW/SW Version: 0x%x, Build Time: %.16s\n",
> 3128                  be32_to_cpu(hdr->hw_sw_ver), hdr->build_date);
> 
> The last one prints %.16s and other two do %.15s - is the fix simply
> changing last one on line 3127 to print %.15s - this avoids printing
> the extra \n?
> 

The following change fixed the blank line problem on my system.

Mario, if you want to send this patch after testing on your system,
let me know. Otherwise I will send it.

==============================================

diff --git a/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c b/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c
index fba7025ffd3f..0457712286d5 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c
@@ -3019,7 +3019,7 @@ int mt76_connac2_load_ram(struct mt76_dev *dev, const char *fw_wm,
         }
  
         hdr = (const void *)(fw->data + fw->size - sizeof(*hdr));
-       dev_info(dev->dev, "WM Firmware Version: %.10s, Build Time: %.15s\n",
+       dev_info(dev->dev, "WM Firmware Version: %.10s, Build Time: %.15s",
                  hdr->fw_ver, hdr->build_date);
  
         ret = mt76_connac_mcu_send_ram_firmware(dev, hdr, fw->data, false);
@@ -3048,7 +3048,7 @@ int mt76_connac2_load_ram(struct mt76_dev *dev, const char *fw_wm,
         }
  
         hdr = (const void *)(fw->data + fw->size - sizeof(*hdr));
-       dev_info(dev->dev, "WA Firmware Version: %.10s, Build Time: %.15s\n",
+       dev_info(dev->dev, "WA Firmware Version: %.10s, Build Time: %.15s",
                  hdr->fw_ver, hdr->build_date);
  
         ret = mt76_connac_mcu_send_ram_firmware(dev, hdr, fw->data, true);
@@ -3124,7 +3124,7 @@ int mt76_connac2_load_patch(struct mt76_dev *dev, const char *fw_name)
         }
  
         hdr = (const void *)fw->data;
-       dev_info(dev->dev, "HW/SW Version: 0x%x, Build Time: %.16s\n",
+       dev_info(dev->dev, "HW/SW Version: 0x%x, Build Time: %.16s",
                  be32_to_cpu(hdr->hw_sw_ver), hdr->build_date);
  
         for (i = 0; i < be32_to_cpu(hdr->desc.n_region); i++) {

========================================

thanks,
-- Shuah