RISC-V Testing Lapse Resulted In Wrong MIPS RISC-V Vendor ID Landing In Linux 6.18
([RISC-V] 37 Minutes Ago
MIPS RISC-V ID)
- Reference: 0001593997
- News link: https://www.phoronix.com/news/MIPS-RISC-V-Vendor-ID-Linux-618
- Source link:
An interesting anecdote from this week's batch of RISC-V fixes for the Linux 6.18 kernel exposed that the MIPS RISC-V/JEDEC vendor ID was wrong for code merged at the start of the kernel cycle. The testing hadn't caught it either as the QEMU emulation also ended up inadvertently using the wrong vendor ID too.
With Friday's [1]RISC-V pull request is this interesting bit:
"To my eyes, the only notable patch in this PR is a patch to deal with MIPS getting their RISC-V/JEDEC vendor ID wrong. Apparently this didn't affect their testing, because they've told us that their QEMU platform was also using the wrong vendor ID. (They are fixing upstream QEMU.) The patch that added the incorrect vendor ID only went in for the v6.18 merge window. So the good news is that we can fix this before the final v6.18 release is tagged. Speaking with MIPS off-list, they've assured us that they will start testing on FPGA bitstreams now, so I hope this will be a closed issue going forward."
The RISC-V fixes were merged today for correcting the MIPS RISC-V vendor ID. This MIPS vendor ID was needed as part of the Linux 6.18 code for [2]introducing MIPS vendor extensions with initially bringing up the xmipsexectl extension.
The wrong MIPS vendor ID added to the Linux kernel and for QEMU testing was 0x722 while the actual correct vendor ID is 0x127. Going through the prior mailing list discussions among the developers, it isn't clear how the 0x722 ID even came up in the first place besides misreading it or confusing it with 0x27 and 0x2 mentions also in the programmer's guide around the bit descriptions.
Good news indeed that it was caught just in time prior to Linux 6.18 stable tentatively expected for release next weekend on 30 November. The developers have committed to better testing so hopefully a similar situation doesn't repeat itself in the future.
[1] https://lore.kernel.org/lkml/d51764f8-04af-8930-78bf-bb253b55b561@kernel.org/
[2] https://www.phoronix.com/news/Linux-6.18-RISC-V
With Friday's [1]RISC-V pull request is this interesting bit:
"To my eyes, the only notable patch in this PR is a patch to deal with MIPS getting their RISC-V/JEDEC vendor ID wrong. Apparently this didn't affect their testing, because they've told us that their QEMU platform was also using the wrong vendor ID. (They are fixing upstream QEMU.) The patch that added the incorrect vendor ID only went in for the v6.18 merge window. So the good news is that we can fix this before the final v6.18 release is tagged. Speaking with MIPS off-list, they've assured us that they will start testing on FPGA bitstreams now, so I hope this will be a closed issue going forward."
The RISC-V fixes were merged today for correcting the MIPS RISC-V vendor ID. This MIPS vendor ID was needed as part of the Linux 6.18 code for [2]introducing MIPS vendor extensions with initially bringing up the xmipsexectl extension.
The wrong MIPS vendor ID added to the Linux kernel and for QEMU testing was 0x722 while the actual correct vendor ID is 0x127. Going through the prior mailing list discussions among the developers, it isn't clear how the 0x722 ID even came up in the first place besides misreading it or confusing it with 0x27 and 0x2 mentions also in the programmer's guide around the bit descriptions.
Good news indeed that it was caught just in time prior to Linux 6.18 stable tentatively expected for release next weekend on 30 November. The developers have committed to better testing so hopefully a similar situation doesn't repeat itself in the future.
[1] https://lore.kernel.org/lkml/d51764f8-04af-8930-78bf-bb253b55b561@kernel.org/
[2] https://www.phoronix.com/news/Linux-6.18-RISC-V