On 07/12/2012 04:57 PM, Forest Bond wrote:
Hi Larry,
On Thu, Jul 12, 2012 at 05:07:03PM -0400, Forest Bond wrote:
On Thu, Jul 12, 2012 at 02:17:51PM -0400, Forest Bond wrote:
On Thu, Jul 12, 2012 at 11:23:20AM -0500, Larry Finger wrote:
On 07/12/2012 10:25 AM, Forest Bond wrote:
On Wed, Jul 11, 2012 at 08:58:16PM -0500, Larry Finger wrote:
On 07/11/2012 08:32 PM, Forest Bond wrote:
On Wed, Jul 11, 2012 at 07:58:04PM -0500, Larry Finger wrote:
On 07/11/2012 07:21 PM, Forest Bond wrote:
The rtl8192de driver is working fine for me at 5GHz, but I am having trouble
getting scan results for 2.4GHz 802.11g networks. I have been doing a lot of
debugging but am not making much progress. I suspect the 802.11 b/g/n phy is
not being initialized correctly, but I'm pretty far outside my domain on this
one.
Is anyone successfully using this driver with a 2.4GHz 802.11g network?
I have several different models - some work better than others. What
is the PCI ID for yours?
This is the one I have:
02:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. Device [10ec:8193]
02:00.1 Network controller [0280]: Realtek Semiconductor Co., Ltd. Device [10ec:8193] (rev 01)
It turns out that both kinds have the same ID. I think one of them
is a prototype, while the other is probably a production unit.
Obviously, bitrot has set in while I wasn't testing. With the kernel
driver, neither unit can even scan in the 2.4 GHz band. Using the
latest version of the vendor driver, the production version connects
with APs running WEP, WPA, or WPA2. The prototype can only handle
WEP.
Obviously, I have some work to do. In the meantime, I will send you
a tarball containing the vendor driver - privately so as not to spam
the list.
Thank you, I appreciate that.
Of course, my preference would be to fix up the kernel driver. I don't mind
doing some manual bisection with compat-wireless releases unless you think that
would be a total waste of time. Do you have any sense for what the last working
kernel version would have been?
As you suggest, we may need to use the vendor driver in the meantime. Thanks
again for sending it over (although I suspect it is the same version I
downloaded from Realtek's web site).
It started with the Realtek version, but has some important bug
fixes that I wanted you to have.
Thanks, that's really helpful.
Of course, we want to fix the kernel version, but if you want to
bisect compat-wireless, that would be a big help. In the meantime, I
will try bisecting wireless-testing when I get a chance.
I have begun disecting compat-wireless releases. 3.1.1-1 works, 3.2.5-1
doesn't. I'm going to try to identify the commit that broke things by applying
patches to 3.1.1-1.
So unless I screwed something up while bisecting, I think this is where things
broke:
commit d83579e2a50ac68389e6b4c58b845c702cf37516
Author: Chaoming Li <chaoming_li@xxxxxxxxxxxxxx>
Date: Tue Oct 11 21:28:51 2011 -0500
rtlwifi: rtl8192de: Updates from latest Reaktek driver - Part III
This patch incorporate the differences between the 06/20/2011 and
08/16/2011 Realtek releases of the rtl8192de driver.
The changes include:
1. Update for new chip versions
Signed-off-by: Chaoming Li <chaoming_li@xxxxxxxxxxxxxx>
Signed-off-by: Larry Finger <Larry.Finger@xxxxxxxxxxxx>
Signed-off-by: John W. Linville <linville@xxxxxxxxxxxxx>
I managed to get into an interesting situation at one point during testing where
neither MAC would return scan results, even after reverting to a known-good
driver version. This was resolved by removing and re-applying power (i.e. a
reboot did not fix it). Something must've put the hardware in a bad state. I
haven't seen this problem again.
Anyway, I'll probably play with that patch a bit to see if I can figure out what
broke, but let me know if you have any ideas.
So this seems to fix things:
diff --git a/drivers/net/wireless/rtlwifi/rtl8192de/phy.c b/drivers/net/wireless/rtlwifi/rtl8192de/phy.c
index 18380a7..be21c81 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192de/phy.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192de/phy.c
@@ -3345,21 +3345,25 @@ void rtl92d_phy_config_macphymode_info(struct ieee80211_hw *hw)
switch (rtlhal->macphymode) {
case DUALMAC_SINGLEPHY:
rtlphy->rf_type = RF_2T2R;
- rtlhal->version |= CHIP_92D_SINGLEPHY;
+ /*rtlhal->version |= CHIP_92D_SINGLEPHY;*/
+ rtlhal->version |= RF_TYPE_2T2R;
rtlhal->bandset = BAND_ON_BOTH;
rtlhal->current_bandtype = BAND_ON_2_4G;
break;
case SINGLEMAC_SINGLEPHY:
rtlphy->rf_type = RF_2T2R;
- rtlhal->version |= CHIP_92D_SINGLEPHY;
+ /*rtlhal->version |= CHIP_92D_SINGLEPHY;*/
+ rtlhal->version |= RF_TYPE_2T2R;
rtlhal->bandset = BAND_ON_BOTH;
rtlhal->current_bandtype = BAND_ON_2_4G;
break;
case DUALMAC_DUALPHY:
rtlphy->rf_type = RF_1T1R;
- rtlhal->version &= (~CHIP_92D_SINGLEPHY);
+ /*rtlhal->version &= (~CHIP_92D_SINGLEPHY);*/
+ rtlhal->version &= RF_TYPE_1T1R;
+
/* Now we let MAC0 run on 5G band. */
if (rtlhal->interfaceindex == 0) {
rtlhal->bandset = BAND_ON_5G;
And this is unrelated, but also seems important:
diff --git a/drivers/net/wireless/rtlwifi/rtl8192de/hw.c b/drivers/net/wireless/rtlwifi/rtl8192de/hw.c
index b338d52..59e85f5 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192de/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192de/hw.c
@@ -1058,11 +1058,14 @@ static enum version_8192d _rtl92de_read_chip_version(struct ieee80211_hw *hw)
u32 value32;
value32 = rtl_read_dword(rtlpriv, REG_SYS_CFG);
+ version |= CHIP_92D;
+
if (!(value32 & 0x000f0000)) {
version = VERSION_TEST_CHIP_92D_SINGLEPHY;
RT_TRACE(rtlpriv, COMP_INIT, DBG_LOUD, "TEST CHIP!!!\n");
} else {
- version = VERSION_NORMAL_CHIP_92D_SINGLEPHY;
+ /*version = VERSION_NORMAL_CHIP_92D_SINGLEPHY;*/
+ version |= NORMAL_CHIP;
RT_TRACE(rtlpriv, COMP_INIT, DBG_LOUD, "Normal CHIP!!!\n");
}
return version;
Let me know what you think. I can prepare some proper patches sometime
tomorrow.
All of those match the code in the 0816.2011 driver. I have no idea what went
wrong earlier, but I think those patches are OK.
Larry
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
