02:22 <nickchan> some additional context: 1. ADP3,2 can be get up and running using only publicly release copyright material 2. these hardware comes from chinese scrapyard selling supposedly destroyed boards as scrap

02:22 <nickchan> clearly some of them are not properly destroyed though

02:28 <nickchan> personally id say it is fair game this is just equivalent of picking trash from the bin

03:06 <chadmed_> nickchan: IANAL but id be very careful about using "fell off the back of a truck" chinese scrapyard parts

03:06 <chadmed_> they very rarely "fall" off the back of the truck

03:27 <nickchan> chadmed_: in particular they did not fell off a truck

03:27 <nickchan> these are scrap metal

03:28 <nickchan> well they are *supposed* to be

03:29 <nickchan> im quite sure that they are sent to china to get destoryed, and then after they are destoryed they got sold as scrap, but the catch it some isn't destoryed properly

03:29 <nickchan> falling of a truck would be very illegal

03:31 <chadmed_> tbf its probably also very illegal to take money to destroy something, then not destroy it, then sell it to reverse engineers

03:31 <chadmed_> if some document destroyal mob were taking my money to shred my paperwork and i found out they were just selling it all to data brokers or something id be quite miffed

03:35 <nickchan> chadmed_: in case you are wondering they are in fact damaged

03:36 <nickchan> the thing to do here would have been drill right through the soc but some of them just got a small piece of the board where there doesn't seem to be much ripped off

03:38 <nickchan> and the damage is all different so with some luck if is possible to cannibalize parts for fully working units

03:39 <nickchan> s/if is/it is/

03:46 <nickchan> anyways onto less shady stuff

03:47 <nickchan> maybe I should resend the watchdog patch? it's been two weeks but then again the past two weeks is the merge window

03:47 <nickchan> increase reset delay 50ms -> 150ms

03:48 <nickchan> patches should start to get applied again now merge window is closed

07:15 <chaos_princess> Is adp3.2 the arm dtk?

07:37 <nickchan> chaos_princess: correct

10:27 <nickchan> https://lore.kernel.org/linux-watchdog/6775f288-9278-412e-957b-b341b1a75ae8@app.fastmail.com/

10:28 <nickchan> sven: I am not super familiar with the watchdog but from my understanding of it, to immediately reset the machine all that needs to happen is setting bit 2 in control reg, then set 0 in bite time reg

10:29 <nickchan> so are the current time reg write and current time reg read even needed?

10:30 <nickchan> it really doesn't matter what the current time is it is basically always going to be larger than 0

10:30 <nickchan> and if it happens to be 0 right now it will become non-zero like immediately after anyways

10:37 <nickchan> okay, it doesn't exactly work like that

10:46 <nickchan> time to check some more in m1n1

10:52 <nickchan> wdt1 is a7-a11; wdt2 is from a12z

11:03 <nickchan> wdt0 casues SoC and only SoC to reset

11:03 <nickchan> things like display stays on and are put in a weird state

11:04 <nickchan> I mean wd0 in linux not related to the wdt version above

11:04 <nickchan> and wd1 does a normal system reset

11:04 <nickchan> wd2 doesn't seem to exist here

11:04 <nickchan> on wdt-version 1

11:15 <nickchan> Okay, this sequence correctly reset system on 5s

11:19 <nickchan> and iphone x as well

11:19 <nickchan> 1. set APPLE_WDT_WD1_CUR_TIME to 1

11:19 <nickchan> wait no

11:26 <nickchan> 1. set APPLE_WDT_WD1_BITE_TIME to 0, 2. set APPLE_WDT_WD1_CTRL to 4 (bit 2), 3. set APPLE_WDT_WD1_CUR_TIME to 0

11:26 <nickchan> this sequence works

11:28 <nickchan> reading current time is not neede

11:29 <nickchan> needed

11:40 <nickchan> https://paste.debian.net/hidden/055a3a42/

11:57 <nickchan> ugh so wd2 *does* exist at least on iphone x just not iphone 5s

12:03 <nickchan> okay after a lot of testing wd2 exists a11 and above

12:03 <nickchan> a7-a10 has wd0 and wd1

12:09 <nickchan> okay whatever I think the best course of action is to remove the readl_relaxed() from the wdt driver

12:19 <nickchan> I can check on t6000 a bit later

15:52 <Zollerboy1> Hey everyone! During my journey to learn how to write kernel modules in Rust, I noticed that the Asahi fork has quite a bit more Rust APIs than what's in the main kernel rn. Is all that extra Rust API supposed to be merged into the main kernel eventually and just held back due to the current Rust for Linux issues? Suppose I wanted to contribute to the Rust wrappers, would it be better to contribute to the Asahi fork or the

15:54 <Zollerboy1> Also, is there anyone who I could contact if I have specific questions about the Rust APIs?

16:04 <nickchan> oh nice linux has the driver for the battery gauge on a10... just not on an uart bus

16:12 <sven> the suggestion was to replace the _relaxed variant with the normal one

16:12 <sven> not to remove it entirely

17:17 <opticron> Zollerboy1, your message cut off after "contribute to the Asahi fork or the" though we did get the next message about specific questions

17:36 <Zollerboy1> opticron: huh? that's strange. the rest of the message was "main kernel? Thanks!" :)

22:17 <chadmed_> Zollerboy1: aiui the drm rust bindings in our fork are mostly blocked by bikeshedding

22:25 <jannau> I don't think so. the problem is several layers before drm. I don't expect problems with drm specifically

22:28 <jannau> Zollerboy1: I think the best approach would be looking at upstream / rust4linux / zulip / rust-next. Before starting something new check if it already exists and if it does see into upstreaming that

22:33 <Zollerboy1> jannau: Yeah, I was just writing an abstraction for character device drivers in Rust (which afaics doesn't exist anywhere – but please prove me wrong^^) and was wondering if and how this could *eventually* get upstreamed. I have never submitted a patch to the linux kernel before, so I'm not quite sure on the process and also thought that in the current situation starting with a Rust patch specifically could be not such a

22:35 <jannau> there is currently a misc device patch on the mailing list https://lore.kernel.org/rust-for-linux/2024092708-rust-wrath-306d@gregkh/T/#t

22:37 <jannau> and in https://rust-for-linux.zulipchat.com two people were asking for rust chardev implementions recently

22:46 <Zollerboy1> jannau: thanks for the link. I'm still learning to navigate the jungle that is linux kernel patches :)

22:57 <fl0_id> Zollerboy1 OTOH, maybe the current situation is exactly the right thing to start with a rust patch ;)

22:59 <chadmed_> alternatively if you want to contribute to asahi specifically ill take hwmon bindings ;)

22:59 <chadmed_> there are a couple of things in macsmc-hwmon that could probably be made a bit less rubbish by riir

23:09 <Zollerboy1> chadmed_: I would love to contribute to asahi specifically, but I don't think that I can really be that useful, because I don't actually own an M1 mac ;)

23:11 <Zollerboy1> I just chose the asahi kernel as the baseline for my rust explorations, because it's still quite close to the t2-linux kernel that I need for my Intel mac and because it has a few more Rust bindings than the rust4linux kernel.