11:34 <martinr> so I finally got around to finishing up VDM support for tipd - is anyone with a second M1 device interested in helping me test serial mode? my M1 iPad Pro does respond to VDMs, but doesn't appear to output anything over serial at boot-time unfortunately

11:34 <martinr> https://github.com/martinyrm/apple-cd321x-driver/tree/main

11:36 <chaos_princess> sure, how do i test it?

11:41 <martinr> so I think we need to apply that patch to the tipd module on one device, connect the two M1 devices together with a USB3 cable (w/ SBU wires), then 'echo 1' to /sys/class/typec/port0/device/cd321x_vdm/serial - and then hopefully they should be able to talk to each other on /dev/ttySAC0 or /dev/ttySAC2

11:49 <martinr> */dev/ttySAC0 for the back port i think

12:02 <chaos_princess> https://pastebin.com/7wczp2rF

12:07 <chadmed> https://github.com/martinyrm/apple-cd321x-driver/blob/main/tipd/core.patch#L67

12:07 <chadmed> ??

12:08 <chaos_princess> patching out the check does not help btw

12:09 <chaos_princess> i also get a bunch of this dmesg spam https://pastebin.com/PdvmgHBi

12:09 <martinr> chaos_princes: ok there is something quite different about the m1 pro then

12:09 <martinr> i expected the patching out the strlen check to work

12:10 <martinr> as for the spam, that is the sysfs object not being removed on device/module reload

12:10 <martinr> which is a bug I had encountered but is fixed on my end

12:11 <chadmed> different vdm key for t600x perhaps?

12:12 <martinr> has macvdmtool been tested on t600x?

12:15 <chadmed> unclear from the commit history but perhaps not

12:30 <martinr> chaos_princess: thanks for the help anyways - i'll see if I can find anything more on the keys

12:31 <chaos_princess> sure

12:42 <jannau> I think there are people using macvdmtool on all devices

13:27 <martinr> chaos_princess: ok I don't think it's key related - I managed to reproduce the -1 error codes on my M1 MBA, and bumping up the VDM command timeout seems to help, would you mind trying again?

13:27 <martinr> https://github.com/martinyrm/apple-cd321x-driver/blob/main/tipd/core.patch

13:28 <chaos_princess> sure, give me a few mins

13:28 <martinr> no rush

13:30 <martinr> i couldn't recreate the sysfs issue but we'll leave that for later

13:54 <chaos_princess> yep, still not working

13:54 <chaos_princess> actually, wait

13:57 <chaos_princess> ok, nvm, i am stupid, it works

13:59 <chaos_princess> dfu port is port1 on j314

13:59 <martinr> are you getting anything on the serial console?

13:59 <chaos_princess> i could talk between machines over serial with picocom

13:59 <martinr> nice

13:59 <martinr> thanks

14:00 <chaos_princess> sysfs spam is still a thing though

14:01 <martinr> yeah I'm not sure what's going on there, can I get a full dmesg?

14:01 <martinr> it should only try to create the sysfs object when the module is loaded

14:04 <chaos_princess> https://pastebin.com/ymNM30Xu - that should be all the relevant bits

14:05 <martinr> ...unless i dont understand when tps6598x_probe is called

14:05 <chaos_princess> i think i maybe see the issue

14:05 <chaos_princess> are you building as module or built-in?

14:05 <martinr> module

14:06 <martinr> loading in with insmod

14:06 <chaos_princess> built-in here, and it seems like your thing probes before the supplier devices do. so something returns EPROBE_DEFER after you created the sysfs entries, and you never clean up those on error

14:10 <martinr> ah you mean it is loading in too soon as a built-in?

14:11 <chaos_princess> yes, but it is more that you are not cleaning up everything that you should if something errors out

14:34 <martinr> ok i think i see the fix

15:55 <martinr> chaos_princess: sysfs entries should now be removed on all errors during probe, I don't see any dmesg messages when building as a built-in, feel free to verify if you'd like

15:59 <chaos_princess> you got the order wrong, now all other errors will cause a non-existent sysfs groups to be removed

16:00 <martinr> so entry creation should be near start of probe, right?

16:01 <chaos_princess> no, just drop entry cleanup at all. the fact that you moved the creation to the end is enough

16:02 <martinr> ok, thanks

16:02 <chaos_princess> and you may or may not want to add a goto entry_disconnect after dev_err(tps->dev, "Couldn't register sysfs group for CD321x VDMs\n");

16:02 <chaos_princess> depending on if it is ok to operate in this "degraded" state

16:03 <martinr> that makes sense

16:03 <chaos_princess> *err_disconnect

16:03 <martinr> first kernel driver attempt so I appreciate the hints

16:07 <martinr> i think it makes sense to keep the rest of tipd working if there's an issue with the VDM feature, especially because a device reset won't help with the sysfs creation error

16:08 <martinr> none of the added code will be used without a write to sysfs

16:09 <chaos_princess> up to you

16:26 <martinr> ok I think that looks pretty good, I went back and fixed the strlen check too

16:43 <amarioguy2> quick question - if we want to redirect the timer IRQ to the guest (as an vIRQ, not enabling the FIQ in EL1 or injecting a virtual FIQ) where would it be best to inject a virtual IRQ in the HV exception handler?

16:44 <amarioguy2> my first guess would be the start exception lower proxy call?

16:48 <amarioguy2> (in case it helps - i'm envisioning the flow here as: timer FIQ fires, traps to EL2, masks the FIQ for a bit to handle it, then HV kicks it to the guest as a virtual IRQ where it proceeds from there)