Received-SPF: pass (google.com: domain of linux-wireless+bounces-1922-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Message-ID: <d4fa544d-46fc-4795-8da1-5dd6199bdea9@gmail.com>
Date: Mon, 15 Jan 2024 14:50:50 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] wifi: rtlwifi: rtl8192de: Fix byte order of chip version
To: Ping-Ke Shih <pkshih@realtek.com>,
 "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
References: <81b6c452-e940-423a-acf7-4a7b7c5e7847@gmail.com>
 <c369eeb8b3014f068d1c60b42b44e206@realtek.com>
Content-Language: en-US
From: Bitterblue Smith <rtl8821cerfe2@gmail.com>
In-Reply-To: <c369eeb8b3014f068d1c60b42b44e206@realtek.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15/01/2024 07:42, Ping-Ke Shih wrote:
> 
> 
>> -----Original Message-----
>> From: Bitterblue Smith <rtl8821cerfe2@gmail.com>
>> Sent: Saturday, January 13, 2024 6:50 AM
>> To: linux-wireless@vger.kernel.org
>> Cc: Ping-Ke Shih <pkshih@realtek.com>; Larry Finger <Larry.Finger@lwfinger.net>
>> Subject: [PATCH] wifi: rtlwifi: rtl8192de: Fix byte order of chip version
>>
>> 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.
> 
> I run vendor driver with 8192DU, and got correct 0xcc33. 
> 
> efuse[EEPROME_CHIP_VERSION_H] = efuse[0x3fe] = cutvalue[1] = 0xcc
> efuse[EEPROME_CHIP_VERSION_L] = efuse[0x3ff] = cutvalue[0] = 0x33
> 
> So, 
> 
> chhipvalue = (cutvalue[1] << 8) | cutvalue[0] = (0xcc << 8) | 0x33 = 0xcc33;
> 
>> 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.
> 
> Can you check the efuse value you read out?
> 
> 

I checked again like this:

diff --git a/hal/rtl8192d_hal_init.c b/hal/rtl8192d_hal_init.c
index 156541b..175c856 100644
--- a/hal/rtl8192d_hal_init.c
+++ b/hal/rtl8192d_hal_init.c
@@ -1565,6 +1565,8 @@ hal_EfuseUpdateNormalChipVersion_92D(
 	ReadEFuseByte(Adapter,EEPROME_CHIP_VERSION_L,&CutValue[0], _FALSE);
 
 	ChipValue= (CutValue[1]<<8)|CutValue[0];
+
+	pr_err("%s: EEPROME_CHIP_VERSION_H: %#x EEPROME_CHIP_VERSION_L: %#x CutValue[1]: %#x CutValue[0]: %#x ChipValue: %#x\n", __func__, EEPROME_CHIP_VERSION_H, EEPROME_CHIP_VERSION_L, CutValue[1], CutValue[0], ChipValue);
 	switch(ChipValue){
 		case 0xAA55:
 			//ChipVer |= CHIP_92D_C_CUT;

This is the output:

Jan 15 14:35:21 ideapad2 kernel: hal_EfuseUpdateNormalChipVersion_92D: EEPROME_CHIP_VERSION_H: 0x3fe EEPROME_CHIP_VERSION_L: 0x3ff CutValue[1]: 0x33 CutValue[0]: 0xcc ChipValue: 0x33cc

I'm using branch v4.0.10:
https://github.com/lwfinger/rtl8192du/tree/v4.0.10
because the master branch doesn't work. I don't think it
matters because this code is the same in both branches.

Maybe my device really is a different version.