ChanServ changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | Non-development talk: #asahi | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
hertz has joined #asahi-dev
c10l has quit [Quit: Bye o/]
c10l has joined #asahi-dev
amarioguy has joined #asahi-dev
<amarioguy>
sorry if this is a dumb question but how do you use the gdbserver implementation in m1n1?
<amarioguy>
seems like it sets an address as "/tmp/.m1n1-unix" but not sure how you'd indicate to GDB that a local "file" is the remote? (from everything i've seen you need an ip/hostname or similar)
King_InuYasha has quit [Remote host closed the connection]
cyrozap has joined #asahi-dev
hertz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hertz has joined #asahi-dev
hertz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hertz has joined #asahi-dev
hertz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jluthra has quit [Remote host closed the connection]
lewurm has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
lewurm has joined #asahi-dev
fugi has quit [Quit: Ping timeout (120 seconds)]
fugi has joined #asahi-dev
<maz>
gah, merging the asahi branch into 6.2-rc1 is annoying...
<ncopa>
is there any work on 6.1.1 release?
<j`ey>
ncopa: markan doesnt usually rebase onto stable releases
<ChaosPrincess>
if you want stable, try applying the patches and see how it goes, they might just apply cleanly
<ncopa>
i wonder what the best way to do that would be? I mean, i can always take the 6.1-2 release and merge v6.1.1 into there, but then I dont get the latest asahi changes
<chadmed>
all the asahi patches should be on top of the last commit tagged in v6.1, so you might be able to take all commits past that and apply them to a 6.1.1 branch
<ncopa>
looks like the current head in asahi branch is same as tag asahi-6.1-2
<ncopa>
but merging v6.1.1 -> asahi branch works without conflicts
<mps>
isn't it asahi-wip branch
<mps>
ah no
<ncopa>
i think development happens in other branches
<mps>
yes
<mps>
some time ago tagged released was created from asahi-wip
<mps>
but looks like not now
<sven>
was a bit bored and didn’t feel like thunderbolt so I looked a bit into nvme/FileVault. looks like there are aes key and IV fields for aes-xts in the tcb struct
<sven>
I think you can set a flag somewhere and it’ll just take that key or set another flag and it’ll assume that key is “sep entangled”
<mps>
few days I'm using kernel with last commit in asahi-wip, works fine
<sven>
so essentially macOS asks sep to get the volume key, sep returns that key in an entangled form and just feeds that into ans
<sven>
and that entanglement seems to change between boots So you can’t grab keys and reuse them later
<mps>
anyone knows how to use charge_control_end_threshold and charge_control_start_threshold in /sys/class/power_supply/macsmc-battery
<mps>
I'm testing them blindly for now
<j`ey>
I think it's the % you want charging to start and end at
<j`ey>
so start is the lower value, and end is the upper value
<mps>
j`ey: this is also my guess
<mps>
and testing results shows we are right, but would be nice to have confirmation from author
<j`ey>
it's a generic linux thing
<j`ey>
(well those sysfs file are at least, so I assume markan followed that)
<jannau>
see "Battery charge control" in Documentation/admin-guide/laptops/thinkpad-acpi.rst for example
<mps>
looks like these files differently named for different drivers
<maz>
humph. 'git reset --hard' in the wrong terminal. I'll look at the merge another day...
<j`ey>
mps: maybe other drivers have custom ones
<mps>
j`ey: looks like some have stop_charge_thresh and start_charge_thresh
nela has quit [Ping timeout: 480 seconds]
<mps>
hm, have to look deeply in this
<marcan>
those are legacy nonstandard names
<mps>
but in my tests it works fine
<marcan>
Documentation/ABI/testing/sysfs-class-power is the proper documentation
<marcan>
maz: I'm going to do the rebase soonish, maybe this weekend
<mps>
marcan: ah yes
cylm_ has quit [Ping timeout: 480 seconds]
<marcan>
ncopa: I don't think stable releases make much sense here, given asahi itself is very much not stable
<ncopa>
ok
gladiac has joined #asahi-dev
<marcan>
stable releases will make sense at the point where upstream already has all the drivers you actually want (and backporting actual bugfixes should be trivial and already taken care of by the kernel stable process)
<marcan>
at that point there is nothing to do :)
<maz>
marcan: ah, that'd be awesome. I still have a couple of things to iron out on the NV front (vgic maintenance interrupt and a nvhe oddity), but I need to run on 6.2-rc before posting anything.
<marcan>
got it :)
iaguis has joined #asahi-dev
<maz>
no pressure! :D
<maz>
btw, do you have any idea why the vgic maintenance interrupt is reported as an IRQ and not a FIQ? this looks a bit odd.
<maz>
doesn't matter much anyway. I'll probably report it as a FIQ anyway, as it makes the per-cpu handling a bit simpler. not being able to mask it is the main issue right now.
TheLink has joined #asahi-dev
<amarioguy>
sven: apple did document that back in their 2016 talk