The chip version stored in the efuse is currently assumed to be in big endian order: #define EEPROME_CHIP_VERSION_L 0x3FF #define EEPROME_CHIP_VERSION_H 0x3FE But other 2-byte things in the efuse are stored in little endian order. For example, the EEPROM ID, the vendor ID, the product ID. The out-of-kernel driver for the USB version of the chip uses the same macros and version detection code as this driver. They recognise 0xaa55, 0x9966, and 0xcc33 as correct versions. With the original macros, my device's version is the unrecognised value of 0x33cc. This seems like a mistake. Swap the addresses to fix the chip version detection. Compile tested only. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@xxxxxxxxx> --- drivers/net/wireless/realtek/rtlwifi/rtl8192de/reg.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/reg.h b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/reg.h index 2783d7e7b227..bf15c636b092 100644 --- a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/reg.h +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/reg.h @@ -657,8 +657,8 @@ #define EEPROM_RF_OPT7 0xCC #define EEPROM_DEF_PART_NO 0x3FD /* Byte */ -#define EEPROME_CHIP_VERSION_L 0x3FF -#define EEPROME_CHIP_VERSION_H 0x3FE +#define EEPROME_CHIP_VERSION_L 0x3FE +#define EEPROME_CHIP_VERSION_H 0x3FF /* * Current IOREG MAP -- 2.43.0
