09:01 <arnd> ardb: I agree dropping platforms in bulk makes sense, as that opens up opportunities for cleanup. When we drop rpc, that gives us the chance of killing off all StrongARM (sa1100, footbridge) and the OABI support at the same time, but it depends on rmk's plans (he's still using OABI on at least one machine, but I'm not if it's only on rpc). The remaining ARMv4 support (fa526 moxart and gemini) will probably outlive StrongARM by at

09:01 <arnd> least a couple of years though.

09:04 <arnd> I also expect ARMv5 (ARM926) to outlive ARMv6-nonK by many years, as we are still adding ARM9 based SoCs, and SAM9X60 was only put into production in 2020

09:07 <arnd> We could probably drop V4T (clps711x, at91rm9000, imx1) at any point now, but I see no benefit in that, as they don't get in the way as long as we keep v4-nonT and v5 around

09:07 <ardb> arnd: yeah it really depends on how much cleanup can result

09:08 <ardb> arnd: rpc is an obvious candidate due to lack of toolchain support

09:08 <ardb> but beyond that, if we don't have to keep obsolete infrastructure around them, no need in dropping more platforms

09:08 <ardb> arnd: wasn't there something related to timekeeping as well?

09:10 <arnd> ardb: yes, LEGACY_TIMER_TICK, but that's also still used on ia64 (orphaned), parisc and m68k

09:11 <arnd> it would mean that rpc can't be part of ARCH_MULTIPLATFORM, but there are a lot of other reasons for that as well

09:12 <arnd> Having everything in multiplatform (and subsequently removing CONFIG_ARCH_MULTIPLATFORM) would be a massive cleanup IMHO.

09:14 <arnd> There isn't much left for s3c24xx and ep93xx on that side, I have (older) patches to get omap1, pxa and ixp4xx to a similar state.

09:16 <arnd> which leaves rpc, footbridge, sa1100 and iop32x. Once those are the only ones left, I think removing them will become rather attractive

09:30 <CounterPillow> I wonder if we should strive for standardising some "alias" names in CM4 modules in mainline device trees so baseboard device trees can be used interchangeably, if that's not been done already.

09:31 <CounterPillow> e.g. if there's i2c on the connector, we don't care about which i2c it is on the precise compute module being used, just that it's an i2c on the connector, so it'd be something like i2c_cm4

13:23 <kos_tom_> arnd: we're still maintaining the rm9200 support

13:23 <kos_tom_> at least, I no abelloni is testing once in a while on rm9200

13:25 <arnd> kos_tom_: yes, I know, this was kind of my point: there are probably no users remaining, but it is (like imx1 and clps711x) almost no effort to keep it working, so there is no reason to kill it

13:29 <kos_tom_> CounterPillow: the BeagleBone people have the same issue

13:30 <kos_tom_> see https://elinux.org/Beagleboard:BeagleBone_cape_interface_spec

13:30 <kos_tom_> essentially, they have a standardized pin header with a number of I2C/SPI/UART/etc. busses, but depending on which board is used, which I2C/SPI/UART/etc. bus that gets exposed is different

13:32 <CounterPillow> Interesting

14:36 <geertu> arnd: Having everything in multiplatform means rmk can no longer object against adding XIP support to v7 SoCs?

14:46 <arnd> geertu: that is my hope, yes