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.
Yeah, but I think this an avenue we should peruse. If by any chance they copied anything from rk3399-linux, the whole thing should be released under GPLv2.
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.
The context was not "Who isn't using RISC-V?" It was whether anyone is using SPARC. The reality: they're not mutually exclusive. They offer both, contrary to the implied subtext of your comment that there has been a transition from SPARC to RISC-V.
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.
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.