01:11 <Sayatomoki[m]> does anyone know the status of alarm repo? it seems cant upgrade.

01:16 <Sayatomoki[m]> * does anyone know the status of archlinux arm repo? it seems cant upgrade.

02:35 <icecream95> This seems relevant to the CPU idle discussion (though 7W savings seems too large to be something that Linux doesn't already do?): https://freshbsd.org/netbsd/src/commit/W2Vm2TruayMzIyDF ("Enable support for low power idle CPU states on ACPI platforms")

07:25 <SpieringsAE> Sayatomoki: alarm servers take a nap sometimes, it will be back in a week or so.

07:26 <SpieringsAE> From my understanding if some particular package updates, it needs to do a bunch of work also updating other packages which apparently takes quite long. I believe it is python in this case?

07:31 <abby> probably, everything that uses libpython or is a python module needs to be rebuilt every 3.x version

07:43 <SpieringsAE> I wonder long it would take to build the complete alarm repos on one of these snapdragon x elites

08:05 <Nios34[m]> Hello! I'm trying to look into the EC of Samsung Galaxy Book Go. It seems it uses a driver called EmuEC.sys (Samsung EmuEC) to control the USB port and charging.

08:09 <Nios34[m]> But when I look it the ACPI resources, I got really confused. It calims 0x33@i2c7 0x14@i2c7 0x09@i2c4 0x0b@i2c4 0x10@i2c1 0x33@i2c2 0x14@i2c2 0x2c@i2c6. Also ghidra shows there are strings including PS8743B, SM5504, s2mm005. So what to do with this? I'd like to retrieve battery status switching charging state from it but I don't have any clue yet

08:10 <Nios34[m]> (Those I2C devices was probed to be existing with i2cdetect, except 0x2c@i2c6)

08:29 <Nios34[m]> https://github.com/leezu/aarch64-laptops-build/blob/1019f47e48a54f3f1ca075c3dc67e81471e3806b/misc/samsung-galaxy-book-go/acpi/dsdt.dsl

09:47 <alx___> On my x13s, latest kernel versions somehow never boot and crash with a UBSAN error if enabled, someone else experienced this?

11:12 <anthony25> icecream95: that's interesting, the LPI thing

11:15 <anthony25> the only thing I see about this is audio related

11:20 <kettenis> the LPI states are represented in the device tree (in the domain-idle-states)

11:22 <anthony25> ha ok

11:29 <kettenis> actually the LPI thing on my vivobook matches what's encoded in the 'idle-states' node

11:33 <kettenis> there are placeholders in some of the _LPI methods for what could be the equivalent of the 'domain-idle-states' that seem to depend on PEP magic

19:08 <macc24> William Goodspeed: what dts file are you using with that laptop?

19:21 <macc24> can you dump the dsdt table? the one on github seems to be a bit weird

20:49 <steev> alx___: i do not have ubsan enabled, so i haven't seen that here