kgarrington has quit [Remote host closed the connection]
<marcan>
sven: please split off the MAINTAINERS changes for v4 :)
<marcan>
actually, this time you can get away without the nvme one
<marcan>
it's dwc3 and spi that conflict
user982492_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
user982492 has joined #asahi-dev
<marcan>
sven: also is there a reason why all the RTKit symbols are _GPL when the driver itself is MIT?
<sven>
hm, maybe _that_ was the reason why I originally had them inside the SART driver as EXPORT_SYMBOL
<jannau>
sven: I intend to send https://github.com/jannau/linux/tree/dart-t6000 tonight. I kept you as commit author and added myself as "Co-Developed-by:" for the two commits I changed. Is that ok?
<sven>
sure
<marcan>
sven: ported smc to the new rtkit stuff; you're missing the apple_rtkit_poll() thing (which calls the peek nonsense), I assume that's deliberate? I'll probably send the mailbox cleanup and tack on the apple changes as one series later today
<marcan>
(at which point it will be called poll instead of peek)
<sven>
yes, that’s why I kept it out for now
<sven>
a function called poll that calls peek which actually polls was a bit too weird for me ;)
<marcan>
:p
<marcan>
[ 15.568940] macsmc-reboot macsmc-reboot: Issuing power off (off1)
<marcan>
[ 15.578488] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
<marcan>
oh boy
<marcan>
kernel panic but it shuts down anyway
<marcan>
:-)
<marcan>
ah, I think it's just supposed to never return?
<marcan>
yeah, same as restart, nevermind then
<sven>
:D
<marcan>
pushed new asahi & bits based on v5.18-rc5, with nvme-v3 and fixed up smc and mailbox stuff
<marcan>
smoke tested the smc stuff only
<sven>
nice!
<sven>
arnd: regarding nvme, do I send a v4 with the minor changes from v3, wait a few more days, and then send the pull request or do I send the pull request directly and only mention the changes in the tag description?
<j`ey>
marcan: yay for new branch
<arnd>
sven: if the changes are very small, just reply that you've folded in the obvious fix, and then send the pull request when you feel it's ready
<marcan>
arnd: if smc makes it in we can just send you another pull with it on top, right?
<arnd>
sure
<marcan>
cool
<marcan>
wonder how that review will go. it's a pile of (individually quite trivial) drivers in various subsystems, on top of a core mfd device... not sure if I should send the whole thing as one series (to provide context) or what
<marcan>
either way the mailbox stuff has to go in first so I'll send that today
<marcan>
and also the PCIe GPIO stuff... and I have some other random patches I should just get rid of too
<sven>
also spi :-P
<marcan>
yeah
<marcan>
and I wonder about the PMU MFD+nvmem stuff... kernel-wise it's independent from SMC but SMC is its only user, and this is assuming people like that approach, so maybe it should go in the SMC series too
<marcan>
I guess I can always just send a big fat series for context, see what first impressions I get, then if it doesn't need a complete rethink split it off for further reviews
<marcan>
also I really should fix up that SPMI driver too
<marcan>
guess I'll go do that once I send the stuff that's ready today
jluthra has quit [Remote host closed the connection]
jluthra has joined #asahi-dev
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Telvana has quit []
Telvana has joined #asahi-dev
___nick___ has joined #asahi-dev
<marcan>
sven: re _GPL, just realized mailbox stuff is _GPL
<marcan>
so that might mean we should keep all the rtkit stuff _GPL
<marcan>
(ugh)
<marcan>
I guess it makes sense from a licensing point of view to have a chain of GPL -> MIT -> MIT -> MIT drivers that have their exports poisoned to _GPL by the first one... but I'm not happy about it.
<sven>
heh, so either i realized that back then as well and made the exports non-GPL in SART but those in rtkit GPL or I just got it right by accident :D
<marcan>
oh well, at least the drivers themselves are MIT so it won't stop the BSDs et al from using them as long as they roll their own mailbox
<sven>
i don't really care about the exports fwiw, i only want BSD etc. to be able to re-use code from the drivers itself if possible
<marcan>
yeah, whatever
<sven>
we're gonna write ~all things inside linux that use rtkit and sart anyway *shrug*
<marcan>
yeah
<marcan>
sending the mailbox mess
<sven>
:D
<marcan>
argh
<marcan>
dammit
<marcan>
why do I always screw up git send emails
<marcan>
I said --to-cover and I had a to: line, why didn't that go through?
<marcan>
... because I had a spurious newline
<sven>
:/
<marcan>
also of *course* the broadcom guy bounced
<marcan>
I think I'm going to stop ccing any broadcom people
<marcan>
they must have some serious churn over there
<marcan>
I'll send cpufreq too, because why not. Needs a binding though, let me do that.
MajorBiscuit has joined #asahi-dev
<marcan>
actually, let me figure out if I can find the "current pstate" field real quick
bisko has joined #asahi-dev
<marcan>
found it, offset 0x50 has [actual][requested] in the low 4+4 bits
bisko has quit [Ping timeout: 480 seconds]
<marcan>
found the PLL coefficients too, and a last change timestamp. I'll throw them in the driver for doc purposes.
<marcan>
j`ey: bet you weren't expecting that one
<marcan>
also sigh, typoed the CC: to lkml
<marcan>
I think git send-email will curse me to the end
<marcan>
this one brought to you by me trying to use a shiny USB-C ethernet adapter I got a while ago and getting a pretty fireworks show
<marcan>
actually sigh, I messed that up
<marcan>
really not my day today eh
<j`ey>
marcan: what is this non-asahi related stuff??? :P
<marcan>
what do you mean non-asahi related stuff? I fixed anker USB-Ethernet adapters to work on M1 Macs!
<j`ey>
:-)
<marcan>
(and also fixed them to work on every other machine, but that's just a nice side effect)
<dottedmag>
marcan: Does this device expose two Ethernet interfaces, one CDC-Ethernet and another custom?!
<marcan>
it exposes multiple configurations, two of which are standard CDC-Ethernet
<marcan>
CDC uses two interfaces per config
<dottedmag>
ic
<marcan>
then this vendor specific driver indiscriminately binds to both CDC interfaces, and tries to drive them as two vendor specific devices
<marcan>
(since CDC is the default config)
<j`ey>
typo in the commit message, missing 'v', "and comes back as a endor specific only device".. unless you mean a device that only works on Endor https://starwars.fandom.com/wiki/Endor :D
<marcan>
j`ey: fixed in v2 already
<j`ey>
:-)
<marcan>
(which also fixed the cc and an actual code problem which I just forgot to amend)
<sven>
i'm always a bit afraid every single time i use send-email that something will go wrong. hasn't happened in a while but i bet the moment i get confident that i know how to use it i'll mess up again :D
<j`ey>
sven: that sounds like using git in general
<sven>
at least with git itself no-one usually notices when I mess up!
<j`ey>
sven: that's because you dont stream :P
<sven>
and now you know _why_ I don't stream :D
<kettenis>
the EXPORT_SYMBOL_GPL() thing in non-GPL licensed files is always a bit weird, but from a copyright perspective I'm confident I can just ignore it as long as we don't have any GPL-only code in our kernel (which we don't)
nyx_o has joined #asahi-dev
yuyichao has quit [Ping timeout: 480 seconds]
hir0pro has joined #asahi-dev
yuyichao has joined #asahi-dev
hir0pro has quit [Ping timeout: 480 seconds]
hir0pro has joined #asahi-dev
hir0pro has quit []
<marcan>
so much for the "easy" pwner gpio series. now we get to make deep changes to how the PCI subsystem probes devices.
<marcan>
*pwren
<sven>
fwiw, i have some rather hacky pcie hotplug code
<sven>
i can push that somewhere, you can clean it up and then just let whatever else down the line enable that pwren gpio
<sven>
but tl;dr: just wait for the port_up interrupt and re-scan it
<sven>
and for port_down remove the devices and enable the LTSS again
<kettenis>
marcan, looks like you didn't cc me on that series
<kettenis>
but changing this now is a pain
<sven>
maybe we really need some linux-asahi mailing list. i'm sure i've forgotten people every now and then as well :/
<kettenis>
and the way pcie works it really doesn't matter whether it is on the device itself or on the port node
<kettenis>
and if this were an actual pcie slot and the gpio would control the slot power, the port would actually be the right place fir the pwern-gpio
<marcan>
kettenis: that's true, but it's also true that future devices could have multiple gpios for power sequencing or similar nonsense :(
<marcan>
any objections to requesting a list there?
<sven>
sounds good to me
<kettenis>
I would subscribe to such a list
<marcan>
kettenis: if rob does want the gpio under the device, I can just have it in both places in our devicetrees for the time being, to make it less painful for you?
<kettenis>
yes, keeping both for 6 month or a year would allow users to easily upgrade across such a change
<kettenis>
putting the property on the device node makes it a bit ambiguous whether it is the responsibility of the pci bus driver or the actual device driver to turn on the GPIO
<kettenis>
but letting the device driver control the GPIO doesn't really scale
<kettenis>
it also makes it hard to have the schema do the appropriate checks
<sven>
so, uh, i guess i can just use git send-email to send out pull requests as well? or is there any reason why that wouldn't work?
<marcan>
I usually edit them to put something at the top, but I dunno
<sven>
yeah, i put subject, to/cc and a small message at the top
<sven>
and at least --dry-run looks like it does the correct thing
<sven>
let's see, i guess i can send it just to myself to test
<sven>
yup, seems to work
MajorBiscuit has quit [Quit: WeeChat 3.4]
<marcan>
ok, merged and pushed everything again
<marcan>
I think bits/130-cpufreq is submittable, if anyone wants to take a look
<marcan>
I'm going to sleep :)
<sven>
tags/asahi-soc-rtkit-sart-nvme-for-5.19 should be ready as well (and just point to asahi-soc/rtkit-sart-nvme)
<sven>
i've kept the _gpl now because it doesn't matter fwiw
<marcan>
yeah
user982492 has joined #asahi-dev
<sven>
cpufreq looks good to me. And surprisingly simple!
<ep0x>
update? i saw today commits on linux main branch
<j`ey>
it was a rebase onto 5.18-rc4
<j`ey>
and marcan sent out a bunch of patches to the mailing list for review
<ep0x>
it means we will get something fixed in this patch? :D
<j`ey>
*5.18-rc5
<j`ey>
no new fixes, just upstreaming of current features
<ep0x>
ok mate, thanks for this info.
<ep0x>
Just to ask, where i can track about new fixes or new features, in Linux or in M1n1. repo?
<ep0x>
like speakers on M1 pro 14'
<ep0x>
btw i am using Asahi as everyday linux on M1, and for me biggest problem is display brightness, everything else i can wait without problem, but damn to much light in my eyes everyday :)
<j`ey>
ep0x: you can try rebooting into macOS and dim it, and then reboot into linux.. apparently that worked for some
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mps>
yes, this works
<j`ey>
not ideal of course :P
<ep0x>
well i knew here is a lot of smart people!
<ep0x>
I didn't want to annoy ppl here with questions, but after using Asahi as everyday especially with high brightness, i had to come and ask :)
<ep0x>
and sure THANKS for your help and work guys! I wish i can help somehow for this project
<j`ey>
j annau is working on DCP, which will eventually be used to control brightness, but it's WIP
<ep0x>
for now no1 did manage speakers to work?
<Dcow[m]1>
it's not safe yet. povik is the who working on audio.
<j`ey>
speakers work on some models, but it's disabled for now
<ep0x>
i go to dim display in mac and reboot ill come with results ;) Thanks once again <3
ep0x has quit [Remote host closed the connection]
ep0x has joined #asahi-dev
<ep0x>
ha! perfect, working as you said guys! Awesome
<ep0x>
i am currently on Asahi mac m1 pro 14''
ep0x has quit [Remote host closed the connection]
qdot has joined #asahi-dev
user982492 has joined #asahi-dev
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]