Re: [PATCH v3 00/19] rtlwifi: halmac: Add new module halmac

[Barry Day]

On Fri, Apr 27, 2018 at 05:44:16AM +, Pkshih wrote:
>
> The registers reside in driver causes error frequently, because MAC register
> is maintained by Realtek's MAC team so they create this module to avoid 
> mistakes.
> Another benefit is to make it possible to become a thin driver, because many
> common functions are provided, so duplicate code will be reduced.

How is it possible to create a thin driver by adding lots more code and layers
of indirection ??? and writing it in a way that it won't compile without the
code for every type of bus interface even though most modules only use one ?

It's a horrible pile of garbage slapped together by an inexperienced
programmer. Its a major deterrent for anyone looking at working on one of
the latest realtek drivers.

Re: RTL8723bu: poor signal and connection troubles

[Barry Day]

On Wed, Jan 10, 2018 at 12:15:51PM +, Carlo Caione wrote:
> Hi,
> this is a follow up email to [0] since the problem was never fully
> investigated / solved and I keep seeing the same problem also on my
> hardware.
> 
> Also in my case the hardware is a rtl8723bt transceiver
> (0x0bda:0xb720), this time shipped on the internal USB bus in a cheap
> laptop branded Zyrex Sky 232.
> 
> As already reported by Mylene the problem is that using this
> transceiver and the latest Linus master you can barely see any WiFi
> network around and also when a WiFi network is actually seen, the
> connection is impossible since the signal strength is too low to have
> a reliable connection. Of course during my tests BT is off and no BT
> driver is probed at all.
> 
> Using the downstream driver at [1] everything works correctly.
> 
> I tried to debug a bit the issue, in particular comparing functions
> and registers related to the antenna setup (.power_on, .enable_rf,
> .phy_init_antenna_selection, .phy_iq_calibrate hooks) but everything
> seems pretty much the same on the two drivers (even though slightly
> differences do exist).
> 
> Any idea / suggestion on how to debug this problem? I guess it's worth
> to start looking at this since several platforms are being affected
> now.
> 
> Cheers,
> 
> [0] https://www.spinics.net/lists/netdev/msg468028.html
> [1] https://github.com/lwfinger/rtl8723bu
> 
> -- 
> Carlo Caione  |  +44.7384.69.16.04  |  Endless

I've found the same. The signal strength using the original driver
from Realtek is significantly higher than when using rtl8xxxu.
I also was not able to find anything wrong in the rtl8xxxu source code
that would be causing the difference, which leads to the thought it is
missing something that exists in the original driver.


Barry Day

Re: rtlwifi oops

[Barry Day]

On Sun, Oct 29, 2017 at 01:08:24AM +0300, nirinA raseliarison wrote:
> [  145.966016] usb 2-1.4: new high-speed USB device number 4 using ehci-pci
> [  146.045808] usb 2-1.4: New USB device found, idVendor=0bda,
> idProduct=8178
> [  146.045811] usb 2-1.4: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [  146.045812] usb 2-1.4: Product: 802.11n WLAN Adapter
> [  146.045813] usb 2-1.4: Manufacturer: Realtek
> [  146.045814] usb 2-1.4: SerialNumber: 00e04c01
> [  146.202043] rtl8192cu: Chip version 0x11
> [  146.278549] rtl8192cu: Board Type 0
> [  146.278790] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
> [  146.278823] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
> [  146.278938] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
> [  146.279113] usbcore: registered new interface driver rtl8192cu
> [  146.281706] usbcore: registered new interface driver rtl8xxxu
> --
> nirinA

It appears that both rtl8192cu and rtl8xxxu are being loaded for the
one device.

Try blacklisting one of them.

Barry

Re: iw not finding physical interface

[Barry Day]

Try changing the driver setting in /etc/hostapd.conf to wext

Re: [PATCH v2 1/2] rtlwifi: use debugfs to debug.

[Barry Day]

On Thu, Aug 10, 2017 at 11:47:43AM -0500, Larry Finger wrote:
> +struct rtl_debgufs_priv {

spelling mistake ?

[PATCH] rtl8xxxu: Fix fail to reconnect to AP

[Barry Day]

Removed the report_connect functions as the h2c commands used are
not required for a soft-mac driver and they prevent reconnecting to an
AP for a couple of the chipsets.

Signed-off-by: Barry Day <brise...@gmail.com>
---
 rtl8xxxu.h   |  6 --
 rtl8xxxu_8192c.c |  1 -
 rtl8xxxu_8192e.c |  1 -
 rtl8xxxu_8723a.c |  1 -
 rtl8xxxu_8723b.c |  1 -
 rtl8xxxu_core.c  | 36 
 6 files changed, 46 deletions(-)

diff --git a/rtl8xxxu.h b/rtl8xxxu.h
index df551b2..3b1f62d 100644
--- a/rtl8xxxu.h
+++ b/rtl8xxxu.h
@@ -1335,8 +1335,6 @@ struct rtl8xxxu_fileops {
  bool ht40);
void (*update_rate_mask) (struct rtl8xxxu_priv *priv,
  u32 ramask, int sgi);
-   void (*report_connect) (struct rtl8xxxu_priv *priv,
-   u8 macid, bool connect);
void (*fill_txdesc) (struct ieee80211_hw *hw, struct ieee80211_hdr *hdr,
 struct ieee80211_tx_info *tx_info,
 struct rtl8xxxu_txdesc32 *tx_desc, bool sgi,
@@ -1422,10 +1420,6 @@ void rtl8xxxu_update_rate_mask(struct rtl8xxxu_priv 
*priv,
   u32 ramask, int sgi);
 void rtl8xxxu_gen2_update_rate_mask(struct rtl8xxxu_priv *priv,
u32 ramask, int sgi);
-void rtl8xxxu_gen1_report_connect(struct rtl8xxxu_priv *priv,
- u8 macid, bool connect);
-void rtl8xxxu_gen2_report_connect(struct rtl8xxxu_priv *priv,
- u8 macid, bool connect);
 void rtl8xxxu_gen1_init_aggregation(struct rtl8xxxu_priv *priv);
 void rtl8xxxu_gen1_enable_rf(struct rtl8xxxu_priv *priv);
 void rtl8xxxu_gen1_disable_rf(struct rtl8xxxu_priv *priv);
diff --git a/rtl8xxxu_8192c.c b/rtl8xxxu_8192c.c
index f9e2050..d5c37e0 100644
--- a/rtl8xxxu_8192c.c
+++ b/rtl8xxxu_8192c.c
@@ -566,7 +566,6 @@ struct rtl8xxxu_fileops rtl8192cu_fops = {
.usb_quirks = rtl8xxxu_gen1_usb_quirks,
.set_tx_power = rtl8xxxu_gen1_set_tx_power,
.update_rate_mask = rtl8xxxu_update_rate_mask,
-   .report_connect = rtl8xxxu_gen1_report_connect,
.fill_txdesc = rtl8xxxu_fill_txdesc_v1,
.writeN_block_size = 128,
.rx_agg_buf_size = 16000,
diff --git a/rtl8xxxu_8192e.c b/rtl8xxxu_8192e.c
index a1178c5..401aac4 100644
--- a/rtl8xxxu_8192e.c
+++ b/rtl8xxxu_8192e.c
@@ -1648,7 +1648,6 @@ struct rtl8xxxu_fileops rtl8192eu_fops = {
.usb_quirks = rtl8xxxu_gen2_usb_quirks,
.set_tx_power = rtl8192e_set_tx_power,
.update_rate_mask = rtl8xxxu_gen2_update_rate_mask,
-   .report_connect = rtl8xxxu_gen2_report_connect,
.fill_txdesc = rtl8xxxu_fill_txdesc_v2,
.writeN_block_size = 128,
.tx_desc_size = sizeof(struct rtl8xxxu_txdesc40),
diff --git a/rtl8xxxu_8723a.c b/rtl8xxxu_8723a.c
index aef3730..9c13db5 100644
--- a/rtl8xxxu_8723a.c
+++ b/rtl8xxxu_8723a.c
@@ -383,7 +383,6 @@ struct rtl8xxxu_fileops rtl8723au_fops = {
.usb_quirks = rtl8xxxu_gen1_usb_quirks,
.set_tx_power = rtl8xxxu_gen1_set_tx_power,
.update_rate_mask = rtl8xxxu_update_rate_mask,
-   .report_connect = rtl8xxxu_gen1_report_connect,
.fill_txdesc = rtl8xxxu_fill_txdesc_v1,
.writeN_block_size = 1024,
.rx_agg_buf_size = 16000,
diff --git a/rtl8xxxu_8723b.c b/rtl8xxxu_8723b.c
index 02b8ddd..30dc66e 100644
--- a/rtl8xxxu_8723b.c
+++ b/rtl8xxxu_8723b.c
@@ -1665,7 +1665,6 @@ struct rtl8xxxu_fileops rtl8723bu_fops = {
.usb_quirks = rtl8xxxu_gen2_usb_quirks,
.set_tx_power = rtl8723b_set_tx_power,
.update_rate_mask = rtl8xxxu_gen2_update_rate_mask,
-   .report_connect = rtl8xxxu_gen2_report_connect,
.fill_txdesc = rtl8xxxu_fill_txdesc_v2,
.writeN_block_size = 1024,
.tx_desc_size = sizeof(struct rtl8xxxu_txdesc40),
diff --git a/rtl8xxxu_core.c b/rtl8xxxu_core.c
index a9137ab..03e88d2 100644
--- a/rtl8xxxu_core.c
+++ b/rtl8xxxu_core.c
@@ -4352,39 +4352,6 @@ void rtl8xxxu_gen2_update_rate_mask(struct rtl8xxxu_priv 
*priv,
rtl8xxxu_gen2_h2c_cmd(priv, , sizeof(h2c.b_macid_cfg));
 }
 
-void rtl8xxxu_gen1_report_connect(struct rtl8xxxu_priv *priv,
- u8 macid, bool connect)
-{
-   struct h2c_cmd h2c;
-
-   memset(, 0, sizeof(struct h2c_cmd));
-
-   h2c.joinbss.cmd = H2C_JOIN_BSS_REPORT;
-
-   if (connect)
-   h2c.joinbss.data = H2C_JOIN_BSS_CONNECT;
-   else
-   h2c.joinbss.data = H2C_JOIN_BSS_DISCONNECT;
-
-   rtl8xxxu_gen1_h2c_cmd(priv, , sizeof(h2c.joinbss));
-}
-
-void rtl8xxxu_gen2_report_connect(struct rtl8xxxu_priv *priv,
- u8 macid, bool connect)
-{
-   struct h2c_cmd h2c;
-
-   memset(, 0, sizeof(struct h2c_cmd));
-
-   h2c.media_status_rpt.cmd = H2C_8723B_MEDIA_STATUS_RPT;
-   if (connect)
-   h2c.media_status_rpt.parm |= BIT(0);
- 

Re: linux-next: build warning after merge of the wireless-drivers-next tree

[Barry Day]

On Mon, Nov 28, 2016 at 09:25:30AM +0200, Kalle Valo wrote:
> Stephen Rothwell  writes:
> 
> > Hi all,
> >
> > After merging the wireless-drivers-next tree, today's linux-next build
> > (x86_64 allmodconfig) produced this warning:
> >
> > In file included from include/linux/usb/ch9.h:35:0,
> >  from include/linux/usb.h:5,
> >  from 
> > drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c:32:
> > drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c: In function 
> > 'rtl8xxxu_fill_txdesc_v2':
> > include/linux/device.h:1214:36: warning: 'rate' may be used uninitialized 
> > in this function [-Wmaybe-uninitialized]
> >  #define dev_info(dev, fmt, arg...) _dev_info(dev, fmt, ##arg)
> > ^
> > drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c:4841:6: note: 'rate' 
> > was declared here
> >   u32 rate;
> >   ^
> >
> > Introduced by commit
> >
> >   b4c3d9cfb607 ("rtl8xxxu: Pass tx_info to fill_txdesc in order to have 
> > access to retry count")
> >
> > This is a correct diagnosis.
> 
> Thanks for the report. Jes, can you send a patch to fix this? (Unless
> someone else beats to it.)
> 
> -- 
> Kalle Valo

I posted a patch on the 26th that fixes this

Barry

[PATCH] rtl8xxxu: tx rate reported before set

[Barry Day]

Move the dev_info call that attempts to show the rate used before it is set.

Signed-off-by: Barry Day <brise...@gmail.com>
---
 rtl8xxxu_core.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/rtl8xxxu_core.c b/rtl8xxxu_core.c
index 04141e5..a9137ab 100644
--- a/rtl8xxxu_core.c
+++ b/rtl8xxxu_core.c
@@ -4844,16 +4844,16 @@ rtl8xxxu_fill_txdesc_v2(struct ieee80211_hw *hw, struct 
ieee80211_hdr *hdr,
 
tx_desc40 = (struct rtl8xxxu_txdesc40 *)tx_desc32;
 
-   if (rtl8xxxu_debug & RTL8XXXU_DEBUG_TX)
-   dev_info(dev, "%s: TX rate: %d, pkt size %d\n",
-__func__, rate, cpu_to_le16(tx_desc40->pkt_size));
-
if (rate_flags & IEEE80211_TX_RC_MCS &&
!ieee80211_is_mgmt(hdr->frame_control))
rate = tx_info->control.rates[0].idx + DESC_RATE_MCS0;
else
rate = tx_rate->hw_value;
 
+   if (rtl8xxxu_debug & RTL8XXXU_DEBUG_TX)
+   dev_info(dev, "%s: TX rate: %d, pkt size %d\n",
+__func__, rate, cpu_to_le16(tx_desc40->pkt_size));
+
seq_number = IEEE80211_SEQ_TO_SN(le16_to_cpu(hdr->seq_ctrl));
 
tx_desc40->txdw4 = cpu_to_le32(rate);
-- 
2.9.2

Re: [PATCH] rtl8xxxu: Fix failure to reconnect to AP

[Barry Day]

On Mon, Nov 21, 2016 at 11:57:22AM -0500, Jes Sorensen wrote:
> Jes Sorensen <jes.soren...@redhat.com> writes:
> > Barry Day <brise...@gmail.com> writes:
> >> The rtl8192e and rtl8723 fail to reconnect to an AP after being
> >> disconnected. Ths patch fixes that without affecting the rtl8192cu.
> >> I don't have a rtl8723 to test but it has been tested on a rtl8192eu.
> >> After going through the orginal realtek code for the rtl8723, I am
> >> confident the patch is applicable to both.
> >>
> >> Signed-off-by: Barry Day <brise...@gmail.com>
> >> ---
> >>  rtl8xxxu_core.c | 18 ++
> >>  1 file changed, 14 insertions(+), 4 deletions(-)
> >
> > Hi Barry,
> >
> > Thank you for the patch. There are a couple of items which I am not
> > 100% sure about the order of.
> >
> >> diff --git a/rtl8xxxu_core.c b/rtl8xxxu_core.c
> >> index 04141e5..6ac10d2 100644
> >> --- a/rtl8xxxu_core.c
> >> +++ b/rtl8xxxu_core.c
> >> @@ -4372,17 +4372,25 @@ void rtl8xxxu_gen1_report_connect(struct 
> >> rtl8xxxu_priv *priv,
> >>  void rtl8xxxu_gen2_report_connect(struct rtl8xxxu_priv *priv,
> >>  u8 macid, bool connect)
> >>  {
> >> +  u8 val8;
> >>struct h2c_cmd h2c;
> >>  
> >>memset(, 0, sizeof(struct h2c_cmd));
> >>  
> >>h2c.media_status_rpt.cmd = H2C_8723B_MEDIA_STATUS_RPT;
> >> -  if (connect)
> >> +  if (connect) {
> >>h2c.media_status_rpt.parm |= BIT(0);
> >> -  else
> >> -  h2c.media_status_rpt.parm &= ~BIT(0);
> >> +  rtl8xxxu_gen2_h2c_cmd(priv, ,
> >> +  sizeof(h2c.media_status_rpt));
> >> +  } else {
> >> +  val8 = rtl8xxxu_read8(priv, REG_BEACON_CTRL);
> >> +  val8 &= ~BEACON_FUNCTION_ENABLE;
> >> +
> >> +  rtl8xxxu_write8(priv, REG_BEACON_CTRL, val8);
> >> +  rtl8xxxu_write16(priv, REG_RXFLTMAP2, 0x00);
> >> +  rtl8xxxu_write8(priv, REG_DUAL_TSF_RST, (BIT(0) | BIT(1)));
> >> +  }
> >>  
> >> -  rtl8xxxu_gen2_h2c_cmd(priv, , sizeof(h2c.media_status_rpt));
> >>  }
> 
> Barry,
> 
> So looking at this again, I am pretty sure you will break monitor mode
> with this. By setting REG_RXFLTMAP2 to 0x you stop reception of all
> data frames.
> 
> The other thing here is that you change removes the part notifying the
> firmware that we disconnected since you now only send the
> media_start_rpt command on connect, but not on disconnect.
> 
> I am curious if the problem goes away if you simply add the BEACON_CTRL
> and REG_DUAL_TSF_RST parts?
> 
> >
> > This only affects 8192eu and not 8192cu - we left RXFLTMAP2 out of here
> > on purpose for monitor mode, but you now disable it for 8192eu/8723bu.
> >
> >>  void rtl8xxxu_gen1_init_aggregation(struct rtl8xxxu_priv *priv)
> >> @@ -4515,6 +4523,8 @@ rtl8xxxu_bss_info_changed(struct ieee80211_hw *hw, 
> >> struct ieee80211_vif *vif,
> >>sgi = 1;
> >>rcu_read_unlock();
> >>  
> >> +  rtl8xxxu_write16(priv, REG_RXFLTMAP2, 0x);
> >> +
> >>priv->fops->update_rate_mask(priv, ramask, sgi);
> >>  
> >>rtl8xxxu_write8(priv, REG_BCN_MAX_ERR, 0xff);
> 
> I believe this change only matters because you disable RXFLTMAP2
> above. If we really have to write to RXFLTMAP2 to make this work, I
> suspect we need to keep some sort of state information.
> 
> I would also be curious if RXFLTMAP2 gets reset somehow by the firmware,
> and we do not account for that.
> 
> Cheers,
> Jes
> 

I'll redo the patch without touching REG_RXFLTMAP2. I don't think it's needed
to fix the fail to reconnect issue.

I haven't had a proper look at the 8723 chips yet but the vendor drivers for
the others don't do a h2c cmd for disconnect but I'll test leaving it in to see
if it makes any difference. A 8723bu arrived in the mail today so now I can
test it too and I discovered yesterday I have a 8723au but it's in a cheap
Android tablet.

Barry

Re: [PATCH 0/7] rtl8xxxu: Pending patches

[Barry Day]

On Mon, Nov 21, 2016 at 11:59:47AM -0500, Jes Sorensen wrote:
> Barry Day <brise...@gmail.com> writes:
> > On Sat, Nov 19, 2016 at 06:53:42PM -0500, Jes Sorensen wrote:
> >> Barry Day <brise...@gmail.com> writes:
> >> > On Fri, Nov 18, 2016 at 09:00:10PM -0500, Jes Sorensen wrote:
> >> >> Barry Day <brise...@gmail.com> writes:
> >> >> > On Fri, Nov 18, 2016 at 04:44:21PM -0500, jes.soren...@redhat.com 
> >> >> > wrote:
> >> >> >> From: Jes Sorensen <jes.soren...@redhat.com>
> >> >> >> 
> >> >> >> Kalle,
> >> >> >> 
> >> >> >> Please find attached a number of patches for the rtl8xxxu
> >> >> >> driver.
> >> >> >> 
> >> >> >> The issues reported with wpa_supplicant on 8723bu still needs further
> >> >> >> investigation.
> >> >> >> 
> >> >> >
> >> >> > The patch I posted that you want tested more will also fix the
> >> >> > wpa_supplicant issue.  Currently I'm looking at why the tx rate is not
> >> >> > what it should be. I feel fixing that first will be beneficial for
> >> >> > fixing any other issues.
> >> >> 
> >> >> Interesting, I was thinking that might be the case. I do want to dig
> >> >> into this further to understand it better. If we use your solution I
> >> >> will want to make sure we cover both gen1 and gen2 parts.
> >> >> 
> >> >> > The recent merge has made my local branch of rtl8xxxu-devel 14
> >> >> > commits ahead.
> >> >> > Do I need to do a reset and submit a new patch for the DWA-131 dongle?
> >> >> 
> >> >> In general you need to use 'git pull --rebase' on my tree. I rebase it
> >> >> to stay in sync with Kalle's tree.
> >> >> 
> >> >> The DWA-131 is the 8192eu? Sorry a bit behind and my mind is losing
> >> >> bits. If it's the patch you posted earlier I can dig it out and play
> >> >> with it - I am still catching up though, so please be patient.
> >> >
> >> > yes it's an 8192eu.
> >> 
> >> Gotcha - how do you do your testing to reproduce the problem btw? Most
> >> of my testing is using the 8723au as a primary device and the next
> >> device as a follow-on, so I may not see as long a run with the device
> >> active as you see.
> >> 
> >
> > Testing is simple. Connect to an AP in the usual
> > manner..disconnect..reconnect.  The 8192eu will fail to reconnect and
> > John Heenan reported the 8723bu also fails to reconnect. Even though
> > he was directly stopping and restarting wpa_supplicant, it's the same
> > thing to the driver - connect..disconnect..reconnect.
> 
> Thanks for the details - I'll have a look shortly.
> 
> > With using a usb_device pointer, each message starts with the usb bus
> > address.  Plug it into a different port and that address could
> > change. By using a pointer to the device associated with the wiphy
> > each message will begin with the driver name. Just makes it easier for
> > the average user to report what's in the log because he can just grep
> > for "rtl8xxxu".
> 
> I see - that would be problematic for me as I quite often have 3-4 of
> these things plugged in at the same time. Not knowing which port spits
> out the message would make it a lot harder to track. In fact my primary
> devel box for this (Lenovo Yoga 13) has an rtl8723au soldered on the
> motherboard, so the moment I plug in any other dongle I'll have two.
> 
> The alternative would be to add a prefer to the individual messages.
> 
> Cheers,
> Jes

I should have mentioned it also places the usb address after the driver name.

Re: [PATCH 0/7] rtl8xxxu: Pending patches

[Barry Day]

On Sat, Nov 19, 2016 at 06:53:42PM -0500, Jes Sorensen wrote:
> Barry Day <brise...@gmail.com> writes:
> > On Fri, Nov 18, 2016 at 09:00:10PM -0500, Jes Sorensen wrote:
> >> Barry Day <brise...@gmail.com> writes:
> >> > On Fri, Nov 18, 2016 at 04:44:21PM -0500, jes.soren...@redhat.com wrote:
> >> >> From: Jes Sorensen <jes.soren...@redhat.com>
> >> >> 
> >> >> Kalle,
> >> >> 
> >> >> Please find attached a number of patches for the rtl8xxxu
> >> >> driver.
> >> >> 
> >> >> The issues reported with wpa_supplicant on 8723bu still needs further
> >> >> investigation.
> >> >> 
> >> >
> >> > The patch I posted that you want tested more will also fix the
> >> > wpa_supplicant issue.  Currently I'm looking at why the tx rate is not
> >> > what it should be. I feel fixing that first will be beneficial for
> >> > fixing any other issues.
> >> 
> >> Interesting, I was thinking that might be the case. I do want to dig
> >> into this further to understand it better. If we use your solution I
> >> will want to make sure we cover both gen1 and gen2 parts.
> >> 
> >> > The recent merge has made my local branch of rtl8xxxu-devel 14
> >> > commits ahead.
> >> > Do I need to do a reset and submit a new patch for the DWA-131 dongle?
> >> 
> >> In general you need to use 'git pull --rebase' on my tree. I rebase it
> >> to stay in sync with Kalle's tree.
> >> 
> >> The DWA-131 is the 8192eu? Sorry a bit behind and my mind is losing
> >> bits. If it's the patch you posted earlier I can dig it out and play
> >> with it - I am still catching up though, so please be patient.
> >
> > yes it's an 8192eu.
> 
> Gotcha - how do you do your testing to reproduce the problem btw? Most
> of my testing is using the 8723au as a primary device and the next
> device as a follow-on, so I may not see as long a run with the device
> active as you see.
> 

Testing is simple. Connect to an AP in the usual manner..disconnect..reconnect.
The 8192eu will fail to reconnect and John Heenan reported the 8723bu also
fails to reconnect. Even though he was directly stopping and restarting
wpa_supplicant, it's the same thing to the driver -
connect..disconnect..reconnect.


> > Would you accept a patch that adds a struct device pointer to rtl8xxxu_priv
> > and used as the device pointer in the logging functions? Then all the 
> > messages
> > will start with the driver name making them easier to find.
> 
> How do you mean? Right now I have a struct usb_device pointer and
> dereference that for ->dev to use with dev_info() messages etc. Do you
> want to see more than that?
> 
> Cheers,
> Jes


With using a usb_device pointer, each message starts with the usb bus address.
Plug it into a different port and that address could change. By using a pointer
to the device associated with the wiphy each message will begin with the driver
name. Just makes it easier for the average user to report what's in the log
because he can just grep for "rtl8xxxu".

Barry

Re: [PATCH 0/7] rtl8xxxu: Pending patches

[Barry Day]

On Fri, Nov 18, 2016 at 09:00:10PM -0500, Jes Sorensen wrote:
> Barry Day <brise...@gmail.com> writes:
> > On Fri, Nov 18, 2016 at 04:44:21PM -0500, jes.soren...@redhat.com wrote:
> >> From: Jes Sorensen <jes.soren...@redhat.com>
> >> 
> >> Kalle,
> >> 
> >> Please find attached a number of patches for the rtl8xxxu
> >> driver.
> >> 
> >> The issues reported with wpa_supplicant on 8723bu still needs further
> >> investigation.
> >> 
> >
> > The patch I posted that you want tested more will also fix the
> > wpa_supplicant issue.  Currently I'm looking at why the tx rate is not
> > what it should be. I feel fixing that first will be beneficial for
> > fixing any other issues.
> 
> Interesting, I was thinking that might be the case. I do want to dig
> into this further to understand it better. If we use your solution I
> will want to make sure we cover both gen1 and gen2 parts.
> 
> > The recent merge has made my local branch of rtl8xxxu-devel 14 commits 
> > ahead.
> > Do I need to do a reset and submit a new patch for the DWA-131 dongle?
> 
> In general you need to use 'git pull --rebase' on my tree. I rebase it
> to stay in sync with Kalle's tree.
> 
> The DWA-131 is the 8192eu? Sorry a bit behind and my mind is losing
> bits. If it's the patch you posted earlier I can dig it out and play
> with it - I am still catching up though, so please be patient.
> 
> Cheers,
> Jes
> 
> 

yes it's an 8192eu.

Would you accept a patch that adds a struct device pointer to rtl8xxxu_priv
and used as the device pointer in the logging functions? Then all the messages
will start with the driver name making them easier to find.

Barry

Re: [PATCH 0/7] rtl8xxxu: Pending patches

[Barry Day]

On Fri, Nov 18, 2016 at 04:44:21PM -0500, jes.soren...@redhat.com wrote:
> From: Jes Sorensen 
> 
> Kalle,
> 
> Please find attached a number of patches for the rtl8xxxu
> driver.
> 
> The issues reported with wpa_supplicant on 8723bu still needs further
> investigation.
> 

The patch I posted that you want tested more will also fix the wpa_supplicant
issue.
Currently I'm looking at why the tx rate is not what it should be. I feel
fixing that first will be beneficial for fixing any other issues.

The recent merge has made my local branch of rtl8xxxu-devel 14 commits ahead.
Do I need to do a reset and submit a new patch for the DWA-131 dongle?

Barry

Re: [PATCH] rtl8xxxu: Fix failure to reconnect to AP

[Barry Day]

On Mon, Nov 14, 2016 at 08:24:45AM -0500, Jes Sorensen wrote:
> Barry Day <brise...@gmail.com> writes:
> > The rtl8192e and rtl8723 fail to reconnect to an AP after being
> > disconnected. Ths patch fixes that without affecting the rtl8192cu.
> > I don't have a rtl8723 to test but it has been tested on a rtl8192eu.
> > After going through the orginal realtek code for the rtl8723, I am
> > confident the patch is applicable to both.
> >
> > Signed-off-by: Barry Day <brise...@gmail.com>
> > ---
> >  rtl8xxxu_core.c | 18 ++
> >  1 file changed, 14 insertions(+), 4 deletions(-)
> 
> Hi Barry,
> 
> Thank you for the patch. There are a couple of items which I am not
> 100% sure about the order of.
> 
> > diff --git a/rtl8xxxu_core.c b/rtl8xxxu_core.c
> > index 04141e5..6ac10d2 100644
> > --- a/rtl8xxxu_core.c
> > +++ b/rtl8xxxu_core.c
> > @@ -4372,17 +4372,25 @@ void rtl8xxxu_gen1_report_connect(struct 
> > rtl8xxxu_priv *priv,
> >  void rtl8xxxu_gen2_report_connect(struct rtl8xxxu_priv *priv,
> >   u8 macid, bool connect)
> >  {
> > +   u8 val8;
> > struct h2c_cmd h2c;
> >  
> > memset(, 0, sizeof(struct h2c_cmd));
> >  
> > h2c.media_status_rpt.cmd = H2C_8723B_MEDIA_STATUS_RPT;
> > -   if (connect)
> > +   if (connect) {
> > h2c.media_status_rpt.parm |= BIT(0);
> > -   else
> > -   h2c.media_status_rpt.parm &= ~BIT(0);
> > +   rtl8xxxu_gen2_h2c_cmd(priv, ,
> > +   sizeof(h2c.media_status_rpt));
> > +   } else {
> > +   val8 = rtl8xxxu_read8(priv, REG_BEACON_CTRL);
> > +   val8 &= ~BEACON_FUNCTION_ENABLE;
> > +
> > +   rtl8xxxu_write8(priv, REG_BEACON_CTRL, val8);
> > +   rtl8xxxu_write16(priv, REG_RXFLTMAP2, 0x00);
> > +   rtl8xxxu_write8(priv, REG_DUAL_TSF_RST, (BIT(0) | BIT(1)));
> > +   }
> >  
> > -   rtl8xxxu_gen2_h2c_cmd(priv, , sizeof(h2c.media_status_rpt));
> >  }
> 
> This only affects 8192eu and not 8192cu - we left RXFLTMAP2 out of here
> on purpose for monitor mode, but you now disable it for 8192eu/8723bu.
> 

Even in monitor mode the interface has to brought up to use it which invokes
rtl8xxxu_start which sets it back to accepting frames.


> >  void rtl8xxxu_gen1_init_aggregation(struct rtl8xxxu_priv *priv)
> > @@ -4515,6 +4523,8 @@ rtl8xxxu_bss_info_changed(struct ieee80211_hw *hw, 
> > struct ieee80211_vif *vif,
> > sgi = 1;
> > rcu_read_unlock();
> >  
> > +   rtl8xxxu_write16(priv, REG_RXFLTMAP2, 0x);
> > +
> > priv->fops->update_rate_mask(priv, ramask, sgi);
> >  
> > rtl8xxxu_write8(priv, REG_BCN_MAX_ERR, 0xff);
> 
> Here you enable RXFLTMAP2 for all devices - this doesn't balance with
> the above.
> 

The original realtek code I have for the 8192cu does the disconnect the
same way as in this patch. I tested the 8192cu using the patched
gen2_report connect and it works. That would make things consistent across
all chipsets.

[PATCH] rtl8xxxu: Fix failure to reconnect to AP

[Barry Day]

The rtl8192e and rtl8723 fail to reconnect to an AP after being
disconnected. Ths patch fixes that without affecting the rtl8192cu.
I don't have a rtl8723 to test but it has been tested on a rtl8192eu.
After going through the orginal realtek code for the rtl8723, I am
confident the patch is applicable to both.

Signed-off-by: Barry Day <brise...@gmail.com>
---
 rtl8xxxu_core.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/rtl8xxxu_core.c b/rtl8xxxu_core.c
index 04141e5..6ac10d2 100644
--- a/rtl8xxxu_core.c
+++ b/rtl8xxxu_core.c
@@ -4372,17 +4372,25 @@ void rtl8xxxu_gen1_report_connect(struct rtl8xxxu_priv 
*priv,
 void rtl8xxxu_gen2_report_connect(struct rtl8xxxu_priv *priv,
  u8 macid, bool connect)
 {
+   u8 val8;
struct h2c_cmd h2c;
 
memset(, 0, sizeof(struct h2c_cmd));
 
h2c.media_status_rpt.cmd = H2C_8723B_MEDIA_STATUS_RPT;
-   if (connect)
+   if (connect) {
h2c.media_status_rpt.parm |= BIT(0);
-   else
-   h2c.media_status_rpt.parm &= ~BIT(0);
+   rtl8xxxu_gen2_h2c_cmd(priv, ,
+   sizeof(h2c.media_status_rpt));
+   } else {
+   val8 = rtl8xxxu_read8(priv, REG_BEACON_CTRL);
+   val8 &= ~BEACON_FUNCTION_ENABLE;
+
+   rtl8xxxu_write8(priv, REG_BEACON_CTRL, val8);
+   rtl8xxxu_write16(priv, REG_RXFLTMAP2, 0x00);
+   rtl8xxxu_write8(priv, REG_DUAL_TSF_RST, (BIT(0) | BIT(1)));
+   }
 
-   rtl8xxxu_gen2_h2c_cmd(priv, , sizeof(h2c.media_status_rpt));
 }
 
 void rtl8xxxu_gen1_init_aggregation(struct rtl8xxxu_priv *priv)
@@ -4515,6 +4523,8 @@ rtl8xxxu_bss_info_changed(struct ieee80211_hw *hw, struct 
ieee80211_vif *vif,
sgi = 1;
rcu_read_unlock();
 
+   rtl8xxxu_write16(priv, REG_RXFLTMAP2, 0x);
+
priv->fops->update_rate_mask(priv, ramask, sgi);
 
rtl8xxxu_write8(priv, REG_BCN_MAX_ERR, 0xff);
-- 
2.9.2

Re: [PATCH 2/2] rtl8xxxu: Fix for bogus data used to determine macpower

[Barry Day]

On Tue, Nov 08, 2016 at 09:29:07AM -0500, Jes Sorensen wrote:
> Dave Jones  writes:
> > On Fri, Nov 04, 2016 at 09:56:00AM -0400, Jes Sorensen wrote:
> >>
> >> Joe Perches  writes:
> >> > On Sun, 2016-10-30 at 19:02 -0400, Jes Sorensen wrote:
> >> >> Code is 80 characters wide, and comments are /* */ never the ugly C++
> >> >> crap.
> >> >
> >> > You might look at the recent Linus Torvalds authored commit
> >> > 5e467652ffef (?printk: re-organize log_output() to be more legible")
> >> > which does both of those: c99 // comments and > 80 columns.
> >> >
> >> > Absolutes are for zealots.
> >>
> >> What Linus does in his code, is totally up to him. What I pull into the
> >> driver that *I* maintain, is up to me. It is perfectly normal to expect
> >> submitters to respect the coding style of the piece of code they are
> >> trying to edit.
> >
> > Bullshit.  It's perfectly normal to respect Linux coding style described in
> > Documentation/CodingStyle.  Now let's back to the topic, could you
> > apply John's patch or you just wanna improve your driver is 100% bug free?
> 
> First of all, I call for proper CodingStyle to be applied to my driver,
> and I expect someone posting a patch to respect the codingstyle of the
> driver in question. It is simple respect for the code. If you consider
> that BS - that is on you!
> 
> Second I am NOT applying that patch as I have stated repeatedly because
> I am not convinced it is safe to do so and it changes the code flow for
> one type of chip and not the rest. In addition it uses a broken approach
> to doing chip specific changes.
> 
> In short, the patch is broken!
> 
> Jes


Jes is correct not to accept the patch. It is just a hack that in one
particular situation gets around a problem with the driver. It doesn't do
anything towards fixing the issue.

Barry

Re: Avery's notes from LPC2016 wireless track (Santa Fe)

[Barry Day]

Thanks for that. Can I take this as meaning there won't be any videos?
I would like to have seen Jes Sorensen's talk on rtl8xxxu

Barry

Re: [PATCH] rtl8xxxu: Fix for agressive power saving by rtl8723bu wireless IC

[Barry Day]

On Mon, Oct 31, 2016 at 06:41:30PM -0400, Jes Sorensen wrote:
> Barry Day <brise...@gmail.com> writes:
> > On Mon, Oct 31, 2016 at 05:25:12PM -0400, Jes Sorensen wrote:
> >> As mentioned previously, if this is to be changed here, it has to be
> >> matched in the _stop section too. It also has to be investigated exactly
> >> why this matters for 8723bu. It is possible this matters for other
> >> devices, but we need to find out exactly what causes this not moving a
> >> major block of init code around like this.
> >
> > I've tested this on the 8192e and 8192c. The same problems occurs with the
> > 8192e but not the 8192c. Stopping and restarting wpa_supplicant had
> > no affect on the 8192c ability to connect to an AP.
> 
> Which version of the driver? I did push in some changes for 8192eu
> recently that fixed the issue with 8192eu driver reloading, and I would
> be interested in knowing if this didn't fix the problem for you?
> 
> Second, could we please keep this on the linux-wireless list where it
> belongs. Everybody else doesn't necessarily want to receive a copy via
> netdev and linux-kernel
> 
> Jes

The tests were done with the latest version of rtl8xxxu-devel. I haven't
noticed any occurence of the previous issue with the 8192eu.

Re: [PATCH] rtl8xxxu: Fix for agressive power saving by rtl8723bu wireless IC

[Barry Day]

On Mon, Oct 31, 2016 at 05:25:12PM -0400, Jes Sorensen wrote:
> As mentioned previously, if this is to be changed here, it has to be
> matched in the _stop section too. It also has to be investigated exactly
> why this matters for 8723bu. It is possible this matters for other
> devices, but we need to find out exactly what causes this not moving a
> major block of init code around like this.
>

I've tested this on the 8192e and 8192c. The same problems occurs with the
8192e but not the 8192c. Stopping and restarting wpa_supplicant had
no affect on the 8192c ability to connect to an AP.

[PATCH] rtl8xxxu: Add D-Link DWA-131 rev E1

[Barry Day]

This is a rtl8192eu dongle and has been tested

Signed-off-by: Barry Day <brise...@gmail.com>
---
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 04141e5..d426836 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -6009,7 +6009,7 @@ static int rtl8xxxu_probe(struct usb_interface *interface,
untested = 0;
break;
case 0x2001:
-   if (id->idProduct == 0x3308)
+   if (id->idProduct == 0x3308 || id->idProduct == 0x3319)
untested = 0;
break;
case 0x2357:
@@ -6188,6 +6188,8 @@ static struct usb_device_id dev_table[] = {
.driver_info = (unsigned long)_fops},
 {USB_DEVICE_AND_INTERFACE_INFO(USB_VENDOR_ID_REALTEK, 0x818b, 0xff, 0xff, 
0xff),
.driver_info = (unsigned long)_fops},
+{USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x3319, 0xff, 0xff, 0xff),
+   .driver_info = (unsigned long)_fops},
 /* Tested by Myckel Habets */
 {USB_DEVICE_AND_INTERFACE_INFO(0x2357, 0x0109, 0xff, 0xff, 0xff),
.driver_info = (unsigned long)_fops},
-- 
2.9.2