Re: Linux 6.19-rc1 mediatek mt7921e broke badly

[Shuah Khan <skhan@linuxfoundation.org>]

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