03:24 <steev> jhovold: aren't your audio patches from srini still v1 not v2?

06:34 <jhovold> steev: they are effectively v2 backported to 6.4

06:37 <jhovold> I'm still carrying the patch moving runtime pm enable though as a workaround for another audio bug that otherwise breaks audio every five boots or so

06:38 <jhovold> It changes the timimg enough to avoid it, srinik is trying to find a fix

08:27 <jhovold> robclark: are the fixes for the firefox video/webgl crases making their way into the stable mesa releases 23.1.x? Looks like they are still not in 23.1.3.

08:33 <moa5505> Hello everyone, I want to try linux on a Ideapad 5g (which is a 8cx gen2 device and should be quite similar to a Yoga 5G). Any documentation or advices ? I tried the standard arm Debian image, but it didn't boot

12:53 <robclark> jhovold: hmm, I guess we need to ask eric_engestrom if https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23324 could be picked to 23.1 branch

13:00 <eric_engestrom> busy right now, but I'll have a look in a bit

13:00 <eric_engestrom> (ping me again tomorrow if I forgot)

13:30 <robclark> thx

13:37 <calebccff> steev: fyi https://gitlab.com/postmarketOS/pmaports/-/commit/97e752caaf47749a75108aa9ea2db907d2344177

13:37 <calebccff> re: audio clicks/pops

15:10 <steev> calebccff: indeed that does seem to help as well

15:22 <eric_engestrom> robclark, jhovold: the commits in !23324 are all fixes and self-contained, so they make sense to backport; all the commits applied cleanly and compiled fine, so provided the CI doesn't find any regression, they'll be in 23.1.4 :)

15:34 <robclark> eric_engestrom: thx

16:12 <jhovold> eric_engestrom: thanks!

16:39 <qzed> jhovold: thanks for the review!

16:39 <qzed> jhovold: I'll try to answer later today, but I'm not sure if I can find the headspace...

16:40 <qzed> jhovold: if I can't do it today it might take some time... I'm moving/preparing a new flat and things are rather hectic right now

17:42 <robclark> hmm, seems like I'm also hitting https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/2012509 (on fedora).. non-working gdb is going to be a bit inconvenient

18:30 <exeat> AFAICT there's a commit to disable pauth for the kernel, but the cpu feature is still visible to userspace...

18:30 <exeat> Then arm64.nopauth completes the job and nobody needs to hurt themselves with gdb's target.xml :)

18:33 <hexdump0815> moa5505: (maybe you read this offline) - jenneron[m] did get his flex 5g working recently, maybe he has some bootable image around somewhere for it for you to start from for your ideapad 5g

18:34 <jenneron[m]> no images

18:34 <jenneron[m]> kernel is at https://gitlab.com/sc8180x-mainline/linux

20:16 <jhovold> qzed: ah, yeah, i saw you mentioning that in the logs here

20:17 <jhovold> i wanted to comment on 4/4 but didn't find the time today, i know have at least a couple of comments on that one too, nothing major

20:18 <jhovold> do you think you'll be able to work on it to get it into 6.6 despite the moving?

20:20 <jhovold> robclark, exeat: thanks for the heads up, I'll look into disabling pauth properly in my wip branches going forward

20:21 <jhovold> was hoping we'd have a fixed fw before everyone starts adding arm64.nopauth to their command lines and just leave it there forever

20:21 <konradybcio> jhovold most of 8280 devices are probably EOL by noc :P

20:22 <konradybcio> now*

20:23 <jhovold> konradybcio: you mean there'll be no fixed fw wrt pauth? rumour has it there may be...

20:23 <konradybcio> I'd hope there would be.. but companies have a track record of not updating firmware beyond whatever tag the device released with

20:27 <qzed> jhovold: I will try, I should have time on the evenings of next week. Not sure if i'll have proper internet yet, but I should be able to work off of my mobile one

20:29 <robclark> which fw is needed for the pauth stuff?

20:29 <konradybcio> tz

20:29 <robclark> ahh, tx

20:29 <konradybcio> it's always tz, innit :P

20:30 <jhovold> qzed: sounds good, just let me know if there's anything I can do to help. I assume you may have written that strscpy helper already, for example?

20:30 <robclark> oh, I suppose pauth is pointer authentication?

20:31 <konradybcio> y

20:31 <robclark> ok.. makes sense that that is a thing gdb would care about

20:48 <qzed> <jhovold> "qzed: sounds good, just let me..." <- I have, I haven't gotten around to fully test it yet though, I'll try to do that later today then I can push things somewhere

21:09 <qzed> jhovold: I pushed the current status to https://github.com/linux-surface/kernel/tree/spx/next-20230616-uefisecapp

21:11 <qzed> jhovold: it's essentially the same thing as on the ml, with on static fix (I think the one you mentioned in your review is still missing) and strscpy instead of strlcpy

21:12 <qzed> (and strscpy isn't fortified, I think fortifying the whole ucs2_string stuff is an opportunity for a follow-up series)

21:13 <qzed> jhovold: feel free to take it over and make some changes, I'll probably not get to it until some time next week

21:14 <qzed> unfortunately I still haven't had a detailed look at your comments, but since you mentioned adding an extra device for qseecom:

21:16 <qzed> v3 had something similar, but people wanted to keep the scm calls exclusively in qcom_scm and remove the need for a compatible, so I scrapped that

21:17 <qzed> we can probably still add an extra device, but I'm not sure if we can get around having some bootstrapping code in qcom_scm