12:36 <arnd> maz: do you have an opinion on the pxa zeus/viper bits of https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/commit/?h=pxa-multiplatform-5.18&id=6d55ed1d32e3f4bf094d85d3707f65df196e59f1 ?

12:37 <arnd> it should make ISA I/O ports work as intended, but I could not figure out if they ever worked in the past, of if anyone ever cared about pc/104 on these machines

13:19 <maz> arnd: ISA I/O worked at some point (I remember playing with some watchdog device). I still have the boards somewhere in the attic, but I don't think anyone remotely cares these days.

13:20 <maz> arnd: conversely, if anyone cares, I'm happy to ship them the boards!

13:21 <maz> (I fired up the netwinder today, and that was enough archaeology for the rest of the week).

13:22 <arnd> maz: do you remember how you used to access them? my guess would be that you would have to pass the I/O port number as a virtual address, so for a device on port 0x300 one would give io=0xf1000300 as a module argument before my patch, or io=0x300 after my patch

13:23 <arnd> I'm fairly sure this change won't cause actual problems for users even if they exist, just trying to make sure I don't miss something obvious

13:24 <maz> arnd: I think the driver had the address hardcoded in it. but don't take my word for it, it was almost 20 years ago./

13:24 <arnd> ok

13:25 <maz> honestly, just merge it. it looks reasonably correct, and I can't imagine anyone screaming about this HW.

13:25 <arnd> right

13:28 <arnd> the entire pxa conversion felt rather pointless, I got no replies from the maintainers for it this time and I think we end up completely removing the boardfiles in next few years. I just really wanted to have the multiplatform stuff done

13:28 <arnd> in the current linux-next, only the three strongarm platforms remain outside of CONFIG_ARCH_MULTIPLATFORM, and it's unlikely that they would ever get merged in there

13:33 <maz> arnd: I think PXA has run its course. nobody really cares about this these days, or so it seems.

13:34 <maz> what's you plan for SA? get rid of it altogether? or leave it outside of multiplatform?

13:35 <arnd> So rmk still has his RiscPC, which keeps us from removing it already, but that one has an expiration date on it because it no longer builds with gcc-9 or later after they dropped -march=armv3

13:35 <arnd> I think we can probably wait until then, and remove all strongarm at the same time

13:37 <arnd> or possibly we can phase out all board files at some point in the future, which would also remove all strongarm in the process

13:39 <arnd> I recently noticed that there are only five ARMv7 board files remaining (three mmp and two dove), so it's tempting to just declare ARMv7 as DT-only and remove those

13:39 <arnd> need to discuss with rmk though, he was the reason for leaving the two dove boards a few years ago when the rest of dove was converted to DT

13:39 <maz> that'd seem reasonable after over 10 years of intense DT-ification. they can always come back as new DTs any time.

13:44 <arnd> For ARMv6, we still have mach-cns3xxx (only one reference board, out of tree openwrt support dropped in 2020), and s3c64xx (now marked deprecated and scheduled for removal "after 2024")

13:46 <maz> I'd be *very* happy to see the back of the Cavium stuff. it is the last machine to have some ugly ties to the GIC internals.

13:49 <arnd> maz: that should be no problem. I think the last time it came up with Krzysztof was when we debated dropping arm11mpcore because of bugs, and he said that he could live with it gone from mainline. I have to find the actual email reference to be sure.

13:50 <arnd> we ended up keeping arm11mpcore, so there was no need to remove cns3xxx either

13:54 <arnd> maz: https://lore.kernel.org/lkml/m3fsxg7tv4.fsf@t19.piap.pl/ "I don't have a problem with the CNS3xxx being dropped. In fact, we don't use anything (ARM) older than v7 here"

13:54 <arnd> feel free to send a removal patch if that helps you

13:56 <maz> arnd: re 11mp, we still have at least a RealView board in the tree. or do you plan to drop that as well?

13:57 <arnd> maz: if both cns3xxx and oxnas get dropped for some reason, I would suggest we also remove mpcore support in integrator and realview along with the CPU core support

13:58 <arnd> having the realview target makes sense as a qemu-supported test environment as long as there are users of the CPU core on real hardware, but it doesn't seem overly valuable as a platform in itself

13:59 <arnd> I never got a reply from narmstrong about oxnas ox820 SMP users

14:00 <maz> arnd: well, it was fun at a time where SMP was pretty rare, but it is such a pain to run with its broken cache coherency and dodgy L2.

14:02 <maz> (btw, I have a stash of about 40 unsoldered chips, should anyone want one for their collection)

14:03 <maz> 11MP, r0p0, as shipped on the RV-11MP.

14:05 <narmstrong> arnd: what do you want to know ?

14:05 <narmstrong> arnd: afaik there’s still users on ox820 with openwrt

14:08 <arnd> narmstrong: https://lore.kernel.org/lkml/20210616162716.GH22278@shell.armlinux.org.uk/ talks about the problems with mpcore, and I think this means it's fundamentally unreliable, and oxnas would be the last real hardware with that core after we drop cns3xxx

14:11 <arnd> narmstrong: I checked latest openwrt, and can confirm that they still have a 5.10 kernel like most platforms, but not 5.15 yet. So it's probably still getting tested

14:11 <arnd> otoh, it looks like the drivers never made it into mainline and are still carried as patches in openwrt

14:15 <arnd> sata, ehci, phy, reset, and pcie are added there.

14:17 <arnd> oh, and I think it doesn't actually work: the 5.10 patches were added with commit message "PCIe still reports link-down for some reason, RAID fails to assemble despite SATA looking good (maybe a generic problem with RAID?)", and then the (presumably working) 5.4 patches got removed with comment "Linux 5.10 has been there as testing kernel for a while now. Do the switch and drop config and patches for Linux 5.4."

14:17 <arnd> but none of the original bugs ever got fixed

14:19 <narmstrong> Yep nobody took the time to push the remaining drivers

14:22 <arnd> the drivers look fine for the most part and I think they could just get merged, though I don't like the way they change the DT binding header without explanation. I should try to ping the openwrt maintainers for the platform on #openwrt-devel about it. I think the platform should either fully get merged or get dropped, no point keeping the broken code

14:59 <mrutland> arnd: thanks for building/uploading the GCC 12 cross toolchains! (I assume that's still down to you)

15:00 <arnd> mrutland: it's still uploaded, hadn't expected anyone to notice already ;-)

15:00 <arnd> s/uploaded/uploading/

15:01 <mrutland> arnd: I'd seen our local GCC devs celebrating the release, so I took a look at the page and was pleasantly surprised!

15:01 <arnd> mrutland: let me know if you run into problems

15:01 <arnd> I also uploaded 11.3 recently, it was still on 11.1

15:01 <mrutland> Ah, I hadn't seen that; I'll grab all of those and drop them into my toolchains folder for testing

15:02 <mrutland> I need to figure out scripting the download step

15:37 <arnd> mrutland: we had at some point discussed putting some machine readable index files in the directories that one can use for easier scripting, I think I even suggested a format, but nobody was able to test it so I did not want to upload it without knowing that it works

15:38 <arnd> if you come up with a format that works for you, I can upload those files

15:44 <broonie> arnd: The s3c64xx stuff would be painful, the Wolfson board doesn't map well onto DT since it probes plugin modules.

15:48 <mrutland> arnd: tbh, given the folder structure is pretty uniform, I just need to have something talk HTTP and enumerate bin/${BUILDARCH}/${TOOLCHAIN_VERSION}/*.tar.xz

15:49 <mrutland> arnd: ... I'm sure that's less than 10 lines of python if I foudn the right libraries :)

15:50 <mrutland> Looks like I'm almost done for the day, so I'll leave that for tomorrow or monday

15:50 <broonie> Or a similar amount of shell script.

20:10 <ukleinek> someone in #debian-arm reports on RockPro64: OF: graph: no port node found in /i2c@ff3d0000/typec-portc@22

20:10 <ukleinek> mmind00: does that ring a bell?

20:10 <ukleinek> dt and kernel are 5.17

21:11 <mmind00> ukleinek: not of the top of my hat no ... though the type-c support on non-chromeos-rk3399 is of course unfinished ... a number of boards define the typec controll (fusb302 in most cases) as that makes some part of the port work for charging or something, but there is still no real hook into the rockchip-typec-phy nor the dwc3 controllers

21:11 <mmind00> ukleinek: is that more of a notice or a probe error?