08:58 <steev> just a whole lot has gone in to next

08:59 <steev> we're at ~81 patches above next now, so getting there - probably closer to 60 if you remove my hacks and the config files

09:02 <jhovold> steev: I'm counting 65 on top of today's next, but that's excluding the (4) pending audio patches (but including some non-sc8280 stuff as well)

09:02 <steev> :)

09:03 <steev> i was just about to ping you actually, and ask if you know why, the PCS_USB offset wasn't applied but the rest were?

09:03 <steev> in your 6.1-rc6 it's patch 64

09:04 <jhovold> what the commit summary?

09:04 <steev> ph: qcom-qmp-usb: fix sc8280xp PCS_USB offset

09:04 <steev> phy: qcom-qmp-usb: fix sc8280xp PCS_USB offset

09:05 <steev> oh, actually it is, just somehow i have it twice

09:05 <jhovold> hmm, I thought that one had been applied, let me check.

09:05 <jhovold> ah, ok, good

09:05 <steev> i'm guessing the thermal one is also applied and somehow i have it twice too

09:10 <steev> yeah, that was a double up, so now it's just a matter of doing the new patches

09:26 <steev> hm, i'm showing 57 after applying your 6.1 rc6 to next

09:28 <jhovold> steev: yeah, I'm overcounting a bit. No surpises in -next this morning? Booting as it should now?

09:28 <steev> i haven't checked yet :) just applied them all (minus the audio patches because i always have to manually fix them up on top of our stuff)

09:29 <jhovold> steev: well actually that should be 65 on top of next if you count configs and non-sc8280xp stuff.

09:29 <jhovold> perhaps I missed something that has already been applied to -next.

09:30 <jhovold> steev: I'll try to find some time to do a -next release next week. Always too many things going on...

09:30 <steev> no worries :)

09:30 <jhovold> steev: want to have audio myself :)

09:32 <steev> i'm showing 69 here with my stuff on top, which is just the uefi thingies from qzed that upstream already nacked, but i like having the ability to go into uefi firmware from grub, and the efivars access, the rest are just a few minor changes i've made like adding the battery present property, adding the 0x81 notification, and adding the sc8280xp mdss to the smmu

09:33 <steev> kicking off a build, but now it's almost 4am here so i should sleep

09:37 <jhovold> yeah, I figured you must be up late. Let me know how the next build works when you get around to booting it.

10:47 <ndec> steev: we've changed our mind about the efivars stuff.. we've discussed with the right folks inside qcom, and it looks like the current patches are pretty much what we want upstream. the smc-involke/tee stuff will be for future platforms. but for all current 'compute' platform (and most likely the next one too!) using qtee as it's done is the path forward.

10:49 <ndec> i've played with the current patches and efibootmgr and found it works quite well

13:35 <martijnbraam> heyo, anyone knows the state of the lenovo x13s on linux?

13:35 <martijnbraam> it's kinda on sale

15:44 <ardb> ndec: so does setting variables work as well?

15:45 <ardb> i tried on my c630 but i cannot change anything, only read the contents

15:59 <steev> ndec: oh that's good to hear

17:48 <steev> jhovold: yeah, next isn’t booting here for me, not with my config, not with yours, not with defconfig

17:57 <clover[m]> <martijnbraam> "heyo, anyone knows the state..." <- https://github.com/ironrobin/archiso-x13s/wiki/Feature-Support

17:59 <martijnbraam> oh that eeeh... doesn't look like a lot yet

18:00 <clover[m]> I can get most of my work done on it. I usually switch to windows for zoom calls

18:04 <ndec> ardb: yes, it works here, on x13s, at least. i could modify BootXXXX entries (add/remove), change BootOrder, BootNext, ..

18:04 <ardb> ndec: right

18:05 <ardb> and it /should/ work on c630 too, i suppose

18:05 <ardb> can anyone confirm that it does?

18:05 <ndec> well, it /could/ be slightly different too :)

18:05 <ardb> steev: ^^^

18:05 <ardb> exactly :-)

18:06 <ndec> but if you can read, it's a good sign, perhaps we need to check the commands/args on the setvar path..

18:08 <jhovold> steev: ok, thanks for the heads up

18:13 <steev> Ah I left the c630 at home, I’ll check it after the England/USA game and report back ardb

18:14 <ardb> steev: cheers

18:25 <steev> Thinking on it, I do think that maybe it was read only on the 845

18:26 <steev> Do have 30 minutes before the game starts, I could run home and grab it

18:26 <ardb> no worries

18:26 <ardb> it can wait, seriously

20:41 <steev> ardb: https://paste.debian.net/1261875/ looks like i can write em

20:42 <ardb> interesting

20:42 <ardb> thanks for double checking

20:43 <ardb> btw you should really be using Driver0000 for DtbLoader not Boot0000

20:43 <steev> i'm using https://github.com/steev/linux/tree/linux-6.0.y with the distro_defconfig in there

20:43 <ardb> i'll play with that tomorrow, thanks

20:43 <steev> ardb: good to know but... i have no idea what that means tbh; i just followed the readme

20:43 <ardb> right

20:44 <ardb> https://www.irccloud.com/pastebin/yd3ABx5O/

20:45 <ardb> surprised it even runs, as it comes second in your boot order

20:45 <steev> oh, the 0001 was just added

20:45 <steev> so it took prescedence i guess

20:45 <ardb> yes

20:46 <ardb> where is your bootloader?

20:46 <steev> in \EFI\debian

20:46 <ardb> yeah but why isn't it listed?

20:46 <steev> afaik, dtbloader -> grub

20:46 <ardb> ugh

20:46 <ardb> really?

20:47 <steev> yeah, but likely because we don't know what we're doing and it was a hack to get things working?

20:47 <ardb> anyway, if it works for everybody then who am i to complain

20:47 <ardb> i collaborated with rob at the time but i didn't follow where it went afterwards

20:51 <steev> just because it works doesn't mean it's right :) would be nice to do things "correctly" and have them working too

20:57 <steev> and i was able to delete that entry and rebooting still works so... it can create, read and delete

20:57 <ardb> good to know

20:57 <steev> deleting 0001 i mean

20:57 <ardb> tbh i never really needed this to begin with

20:57 <steev> i definitely don't have your skillset

20:57 <ardb> you just set it once and never update it

20:58 <ardb> using efivars for pstore etc on this machine is only going to lead to tears

20:58 <steev> yeah but that first time setting it is currently a pita

20:58 <steev> it would be nice to let the installer do it

20:59 <steev> fwiw

20:59 <steev> root@limitless:~# efibootmgr -r -v

20:59 <steev> No DriverOrder is set

20:59 <ardb> yeah you can set entries with -r just like you set the Boot#### ones

20:59 <ardb> but i used 'bcfg driver add' in the EFI shell

20:59 <ardb> (~2 years ago and never changed it)

21:01 <steev> hm

21:02 <steev> trying to add it by passing -r it just says no driverorder set every time

21:02 <steev> efibootmgr -r c -d /dev/sda -p 1 -L DtbLoader -l \EFI\DtbLoader.efi

21:02 <steev> oh

21:02 <steev> silly me, c != -c

21:03 <ardb> you'll need \\ not \ there i think

21:06 <steev> And it’s not inside \EFI anyway

21:06 <steev> So fix that too

21:07 <steev> Hm, it doesn’t appear to save it

21:07 <steev> Rebooting and it shows back up as no driver order set

21:07 <ardb> yeah that was my point before

21:08 <ardb> i can read but i cannot set

21:08 <steev> Oh, got ya,

21:08 <ardb> guess i wasn't quite clear, sorry about that

21:08 <steev> I guess we can’t write on 845, pretty sure we can on 8180x and 8280xp

21:09 <ardb> ok good to know

21:09 <ardb> now i just need to find someone who will buy me a x13s :-)

21:09 <steev> Christmas is coming, maybe Santa will hook us both up

21:09 <ardb> indeed

21:10 <steev> I have one… but I’d like one that I can actually afford to break

21:29 <ndec> ardb: https://github.com/aarch64-laptops/edk2/commit/25c3e55cd9a66d1766c18384f45f56daa1bd8706, this is why it moved to Bootxxxx, iirc.

21:30 <ardb> right

21:30 <ardb> doesn't really explain why though

21:31 <ndec> right..

21:31 <ndec> robclark might remember ;)

21:31 <ardb> more loaders, just what we need :-)

22:18 <steev> calebccff: actually, if I remember correctly (and my brain definitely isn’t what it used to so HUGE grain of salt) - the i2c timeout thing was taken care of by 3 patches from bamse to the i2c geni driver