No, it only means that Rockchips (or one of their customers) ships a kernel with a a driver for a Marvell wireless devices (presumably now made by NXP), for which Marvell claims to own the copyright and gives permission under GPL.
Assuming that the license text is correct, Marvell or NXP would have been in their full rights to provide the same source code to some users under the GPLv2 for use in a Linux driver, and to other users under a different license.
Another possibility is that Marvell themselves licensed the supplicant code from someone else and replaced the copyright information when publishing it together with their driver.
M1 is Armv8.5-A, which is almost the same as Armv9.0-A, except that it lacks SVE2 vector instructions. Apple's CPUs tend to move to the latest architecture revision that is available at the time the instruction set gets nailed down, so the next generation (M2 and A15) would be Armv8.6-A if it lacks SVE2, or Armv9.1-A if it includes it.
Most likely the M2/A15 will include SVE2 but won't be available for another six months, while the M1+ in the coming Macbook Pro would still be Armv8.5-A.
Some of the Apple M1 changes went into the tty/serial driver tree that GregKH maintains. The actual platform code requires those changes, so we based the branch on top of that, and the top-level merge commit contains all of these.
MIPSr6, aarch64 and riscv are siblings born from MIPSr5 plus the best of other RISC architectures.
ppc64le and 32-bit Arm are part of the wider family, but have some notable differences that make them slightly less RISC-like. Both include e.g. more complex condition code handling and instructions that operate on more than three registers.
Mips R6 (Warrior m62xx/i6400/i6500/p6600) was already somewhat incompatible with R5 and earlier, the seventh generation nanomips i7200 was incompatible with that again.
The next "loongarch" generation was already announced to move away from mips as the underlying ISA but instead allow running mips, arm64, risc-v, and x86 code in hardware assisted emulation.
I double-checked the numbers reported by the driver against doing actual writes to the file system and the numbers reported by the OS, and they match exactly when there is no other activity: writing a 1GB file increases the number by 1GB and a few kilobytes of metadata.
Once the memory is full, it starts swapping a lot and then things go bad.
For the record, here are the numbers from this box: 900GB written in 20 power-on hours, on a 256GB driver.
Critical Warning: 0x00
Temperature: 26 Celsius
Available Spare: 100%
Available Spare Threshold: 99%
Percentage Used: 0%
Data Units Read: 15,019,377 [7.68 TB]
Data Units Written: 1,759,297 [900 GB]
Host Read Commands: 101,021,092
Host Write Commands: 14,010,727
Controller Busy Time: 0
Power Cycles: 75
Power On Hours: 20
It was apparently built for a very specific use case (doing CI for some application) so I guess it has to be ARM Linux. You can run Linux in a VM guest on Mac mini, but some limitations remain:
- The project was obviously started before the Mac mini was available
- Linux guests are still rather experimental and might not behave the same way as a real machine.
- 32-bit Arm applications do not run on the M1, it is a 64-bit-only CPU
- Nested virtualization is said to not work yet under MacOS, so you cannot run KVM guests inside of the Linux guest
- If you need to spin up lots OS instances simultaneously to test various setups and each of them need 8GB, you can have at most 2 instances on a Mac.
For most use cases, none of those apply, so you would be better off with a Mac, a Graviton instance or an off-the-shelf PC.
User space doesn't generally deal well with time going backwards, but the main problem is that setting an absolute timeout in a program is broken when the target time is less than the current time. An example of this is 32-bit systemd, which just hangs at boot when the RTC points to a time after 2038, as it tries to figure out of timers work.
https://www.adelielinux.org/ is an example of a Linux distro built on musl-1.2, so you can use that beyond 2038 on 32-bit hardware.
I think you get into practical problems at some point. WikiChip lists a 28nm Cortex-A7 core at 0.48mm², with every node shrink (20nm, 14nm, 10nm, 7nm, ...) you can halve that, but adding 64-bit support to a core might only add about 10%.
You can't make chips arbitrarily small, because you end up wasting more of your wafer for the area between the dies and for the wire bond pads. If the chip size stays the same but the CPU gets smaller, most of the chip is for off-core components and the CPU has less impact on the total cost and power consumption.
You could use more complex CPU cores, or simply more cores, for better performance, but then you also need a faster memory interface (wider buses, LD-DDR4+ instead of DDR3, ...) to make actually use of the performance. These lead to higher memory capacity as well, but then you can't actually use the available memory as you run into 32-bit addressing limits.
I wouldn't rule out shrinks of existing 32-bit SoC families to 22nm or below to lower cost once those processes get cheap enough and there is still demand for compatibility, but there is a good chance that 28nm SoCs is where 32-bit ends. (note that I'm not talking about the dozen or so additional ARC/Xtensa/RV32/Cortex-M/... microcontroller cores on high-end SoCs, as those are not the ones running Linux).
That sweet spot for cost has already moved from 40nm to 28nm for most of the market. The new SAM9X60 I mentioned is still on 40nm, but it's a tiny chip and all new Cortex-A7 SoCs and things like the Ingenic X2000 are on 28nm because of overall cost for that design point.
The sweet spot for power efficiency has apparently moved from 28nm to 22nm, which uses less energy than either 28nm HKMG or 14nm FinFET and is also closing in on 28nm on cost.
There no mainstream 32-bit cores on 22nm or below (yet), so there is a good chance that the coming generation of low-cost 64-bit SoCs on 22nm will beat all 32-bit chips on performance, power consumption and cost.
I tried not to talk too much about 64-bit architectures, but that's a good point. Indeed not just Alpha but also MIPS R4000, UltraSPARC, PA-8000 were already around in the 1990s when the 32-bit kernel support got merged, while ppc64, s390x and TileGX hardware came a little later than the corresponding 32-bit ports.
For time_t, I remember it first getting discussed seriously among kernel developers around 2010 as it became clearer that we had misjudged how long 32-bit systems would be around for, how much work it would be to fix it, and how long before 2038 things would fall apart from bugs.
Before then, the general thinking was we could either delay dealing with it until the 2030s or 32-bit Linux would just not be there any more.
I would consider the LFS transition a user space failure, as glibc never made that the default and Debian still builds some packages with 32-bit off_t to avoid breaking the interface between libraries. As late as 2018, glibc was still merging architecture ports (csky) that default to a 32-bit off_t, despite the kernel having 64-bit off_t since 1994 (linux-1.1.46) before any non-i386 ports were added, and all new architectures in the kernel only supporting 64-bit off_t since 2011.
Assuming that the license text is correct, Marvell or NXP would have been in their full rights to provide the same source code to some users under the GPLv2 for use in a Linux driver, and to other users under a different license.
Another possibility is that Marvell themselves licensed the supplicant code from someone else and replaced the copyright information when publishing it together with their driver.