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@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx/
>
> (...)
>   
> > 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