<jannau>
I think fixup strategy for users with broken installs should be:
<jannau>
1. provide fixed u-boot and kernel packages
<jannau>
2. prepare a m1n1 + u-boot bundle with smc and simple-framebuffer backlight disabled
<jannau>
3. tell users to replace ESP:m1n1/boot.bin with the bundle from from 2.
<marcan>
I agree
<jannau>
4. update the system
<sven>
ouch, that‘s a pretty subtle bug
<jannau>
macos 12.3 acks the crashlog buffer request so there might be future incompabilities
<j`ey>
doesnt that mean a 12.3 macos would crash too?
<jannau>
assuming apple would enforce a consistent usage on all endpoint. this problem was with the ioreport endpoint
derzahl has quit [Remote host closed the connection]
wCPO62 has quit []
wCPO62 has joined #asahi-dev
wCPO62 has quit []
wCPO62 has joined #asahi-dev
kov has joined #asahi-dev
wCPO62 has quit []
wCPO62 has joined #asahi-dev
bakk[m] has joined #asahi-dev
opticron has quit [Ping timeout: 480 seconds]
<kettenis>
no smc means no wifi
<kettenis>
so I think an updated kernel is needed first
<kettenis>
then you don't need to disable smc in the device tree
<kettenis>
ah, you're talking about fixing a broken install
<jannau>
the kernel is on ext3 so updating the kernel is inconvenient without working Linux
<kettenis>
is it possible to prevent the smc driver from loading?
<jannau>
yes, fixed kernel and u-boot packages should be provided at the same time with unmodified DTBs
<jannau>
yes, but a little bit less convenient. its init function can be blocked on the kernel command line
<jannau>
i.e. the users would have to edit the grub entry
opticron has joined #asahi-dev
<kettenis>
that is fairly straightforward, but I'll leave it up to you folks to decide what the most fool-proof way is ;)
<kettenis>
jannau: are you planning to do the cleanup and submit the u-boot diff upstream?
<jannau>
kettenis: yes, although I'm a little bit unsure what you mean with cleanup. just the code style indentation, variables defined at the beginning?
<kettenis>
yeah, I have the feeling the _t typedefs will cause some issue for example
<kettenis>
and I don't know what the policy is about embedding code with a different license into a file is
<jannau>
ah, I did a quich search and I found similar typedef in other files
<kettenis>
then it is probably fine
<kettenis>
do we know what endpoint 10 is about?
<jannau>
do you see a problem with the direct instantation of sart via of* instead of using the device model?
<kettenis>
I don't, but others might
<kettenis>
one issue is that rtkit.c probably should call the sart functions directly
<kettenis>
so maybe apple_rtkit_init() should accept function pointers to map/unmap and an opaque pointer for those callbacks
<jannau>
you mean init/free? I guess that's kind of ok as long as rtkit is only used for nvme
<kettenis>
true, but rtkit.o is included even if you disable nvme
<jannau>
ah, I understand
<kettenis>
(that would be somewhat silly but the Kconfig stuff is supposed to express the dependencies properly)
<kettenis>
endpoint 10 isn't handled by the linux kernel rtkit code is it?
<jannau>
no, linux ignores it. m1n1/proxy has "0xa: ASCDummyEndpoint, # tracekit"
<kettenis>
should add a #define for it
<kettenis>
anyway, if you have a version that you're happy with I can add some comments on github
<sven>
I’m happy to relicense the SART code if it makes life easier fwiw
___nick___ has joined #asahi-dev
___nick___ has quit []
___nick___ has joined #asahi-dev
<marcan>
same, not sure if anyone other than us touched rtkit?
<marcan>
if git blame says it's just folks from around here I'm sure relicensing won't be an issue
<jannau>
it's sart and only touched by sven but I've already moved it to its own file
<marcan>
ah, if it's just sart then sven, yeah
<marcan>
jannau: also while you're at it can you bump all the timeouts across the board to at least 100ms, if not 1s?
<marcan>
having them at 10ms serves no useful purpose and is just a dumb way for it to break in the future
<sven>
I actually checked before I wrote that comment :D
<marcan>
:)
Guest1499 is now known as Skirmisher[m]
<kettenis>
1s may be a bit excessive since there may be several timeouts and it may take rather long for things to fail
<kettenis>
but 100ms should be fine
___nick___ has quit []
<marcan>
kettenis: I think any one of those failing would bail anyway? but sure, if some codepaths could have that 100ms is fine
___nick___ has joined #asahi-dev
___nick___ has quit []
the_lanetly_052___ has joined #asahi-dev
___nick___ has joined #asahi-dev
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
<kettenis>
actually you're right; each timeout is fatal, so waiting 1s should be ok
<amarioguy>
sven: quick question, we need to pass platform_get_irq a pointer to a pdev struct, but the pasemi i2c files only show an platform driver struct, do we just pass that or an element of that into the platform_get_irq func?
<sven>
uh, you should have a pointer to that struct in the apple
<sven>
probe function
<amarioguy>
ah gotcha
the_lanetly_052___ has quit [Ping timeout: 480 seconds]
confusomu has quit [Remote host closed the connection]