[PATCH 5/5] mt76x2: initialize fall-back rate registers

2018-12-07 Thread Stanislaw Gruszka
Initialize MT_LG_FBK_CFG{0,1} and MT_VHT_HT_FBK_CFG{0,1} registers.

Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/mediatek/mt76/mt76x0/initvals.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/initvals.h 
b/drivers/net/wireless/mediatek/mt76/mt76x0/initvals.h
index a1657922758e..01e672bad2f1 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/initvals.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/initvals.h
@@ -88,6 +88,10 @@
{ MT_TX_PROT_CFG6,  0xe3f42004 },
{ MT_TX_PROT_CFG7,  0xe3f42084 },
{ MT_TX_PROT_CFG8,  0xe3f42104 },
+   { MT_VHT_HT_FBK_CFG0,   0x65432100 },
+   { MT_VHT_HT_FBK_CFG1,   0xedcba980 },
+   { MT_LG_FBK_CFG0,   0xedcba988 },
+   { MT_LG_FBK_CFG1,   0x00872100 },
 };
 
 static const struct mt76_reg_pair mt76x0_bbp_init_tab[] = {
-- 
1.9.3



[PATCH 4/5] mt76x2: initialize fall-back rate registers

2018-12-07 Thread Stanislaw Gruszka
Initialize MT_LG_FBK_CFG{0,1} and MT_VHT_HT_FBK_CFG0 registers.
MT_VHT_HT_FBK_CFG1 was already configured.

Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/mediatek/mt76/mt76x2/init.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/init.c 
b/drivers/net/wireless/mediatek/mt76/mt76x2/init.c
index 54a9b5fac787..16fd514b5207 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2/init.c
@@ -140,7 +140,10 @@ void mt76_write_mac_initvals(struct mt76x02_dev *dev)
{ MT_WPDMA_DELAY_INT_CFG,   0x94ff },
{ MT_TX_SW_CFG3,0x0004 },
{ MT_HT_FBK_TO_LEGACY,  0x1818 },
+   { MT_VHT_HT_FBK_CFG0,   0x65432100 },
{ MT_VHT_HT_FBK_CFG1,   0xedcba980 },
+   { MT_LG_FBK_CFG0,   0xedcba988 },
+   { MT_LG_FBK_CFG1,   0x87872100 },
{ MT_PROT_AUTO_TX_CFG,  0x00830083 },
{ MT_HT_CTRL_CFG,   0x01ff },
};
-- 
1.9.3



[PATCH 3/5] mt76x02: set protection according to ht operation element

2018-12-07 Thread Stanislaw Gruszka
Configure protection based on information that are provided to
us either by remote AP or by hostapd via HT operation IE.

Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/mediatek/mt76/mt76x02_mac.c  | 83 +++
 drivers/net/wireless/mediatek/mt76/mt76x02_mac.h  |  2 +
 drivers/net/wireless/mediatek/mt76/mt76x02_regs.h |  1 +
 drivers/net/wireless/mediatek/mt76/mt76x02_util.c |  4 ++
 4 files changed, 90 insertions(+)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c 
b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
index 9693d6140b3d..3fc7a722ea53 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
@@ -731,6 +731,89 @@ void mt76x02_mac_set_rts_thresh(struct mt76x02_dev *dev, 
u32 val)
 MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
 }
 
+void mt76x02_mac_set_tx_protection(struct mt76x02_dev *dev, bool legacy_prot,
+  int ht_mode)
+{
+   int mode = ht_mode & IEEE80211_HT_OP_MODE_PROTECTION;
+   bool non_gf = !!(ht_mode & IEEE80211_HT_OP_MODE_NON_GF_STA_PRSNT);
+   u32 prot[6];
+   u32 vht_prot[3];
+   int i;
+   u16 rts_thr;
+
+   for (i = 0; i < ARRAY_SIZE(prot); i++) {
+   prot[i] = mt76_rr(dev, MT_CCK_PROT_CFG + i * 4);
+   prot[i] &= ~MT_PROT_CFG_CTRL;
+   if (i >= 2)
+   prot[i] &= ~MT_PROT_CFG_RATE;
+   }
+
+   for (i = 0; i < ARRAY_SIZE(vht_prot); i++) {
+   vht_prot[i] = mt76_rr(dev, MT_TX_PROT_CFG6 + i * 4);
+   vht_prot[i] &= ~(MT_PROT_CFG_CTRL | MT_PROT_CFG_RATE);
+   }
+
+   rts_thr = mt76_get_field(dev, MT_TX_RTS_CFG, MT_TX_RTS_CFG_THRESH);
+
+   if (rts_thr != 0x)
+   prot[0] |= MT_PROT_CTRL_RTS_CTS;
+
+   if (legacy_prot) {
+   prot[1] |= MT_PROT_CTRL_CTS2SELF;
+
+   prot[2] |= MT_PROT_RATE_CCK_11;
+   prot[3] |= MT_PROT_RATE_CCK_11;
+   prot[4] |= MT_PROT_RATE_CCK_11;
+   prot[5] |= MT_PROT_RATE_CCK_11;
+
+   vht_prot[0] |= MT_PROT_RATE_CCK_11;
+   vht_prot[1] |= MT_PROT_RATE_CCK_11;
+   vht_prot[2] |= MT_PROT_RATE_CCK_11;
+   } else {
+   if (rts_thr != 0x)
+   prot[1] |= MT_PROT_CTRL_RTS_CTS;
+
+   prot[2] |= MT_PROT_RATE_OFDM_24;
+   prot[3] |= MT_PROT_RATE_DUP_OFDM_24;
+   prot[4] |= MT_PROT_RATE_OFDM_24;
+   prot[5] |= MT_PROT_RATE_DUP_OFDM_24;
+
+   vht_prot[0] |= MT_PROT_RATE_OFDM_24;
+   vht_prot[1] |= MT_PROT_RATE_DUP_OFDM_24;
+   vht_prot[2] |= MT_PROT_RATE_SGI_OFDM_24;
+   }
+
+   switch (mode) {
+   case IEEE80211_HT_OP_MODE_PROTECTION_NONMEMBER:
+   case IEEE80211_HT_OP_MODE_PROTECTION_NONHT_MIXED:
+   prot[2] |= MT_PROT_CTRL_RTS_CTS;
+   prot[3] |= MT_PROT_CTRL_RTS_CTS;
+   prot[4] |= MT_PROT_CTRL_RTS_CTS;
+   prot[5] |= MT_PROT_CTRL_RTS_CTS;
+   vht_prot[0] |= MT_PROT_CTRL_RTS_CTS;
+   vht_prot[1] |= MT_PROT_CTRL_RTS_CTS;
+   vht_prot[2] |= MT_PROT_CTRL_RTS_CTS;
+   break;
+   case IEEE80211_HT_OP_MODE_PROTECTION_20MHZ:
+   prot[3] |= MT_PROT_CTRL_RTS_CTS;
+   prot[5] |= MT_PROT_CTRL_RTS_CTS;
+   vht_prot[1] |= MT_PROT_CTRL_RTS_CTS;
+   vht_prot[2] |= MT_PROT_CTRL_RTS_CTS;
+   break;
+   }
+
+   if (non_gf) {
+   prot[4] |= MT_PROT_CTRL_RTS_CTS;
+   prot[5] |= MT_PROT_CTRL_RTS_CTS;
+   }
+
+   for (i = 0; i < ARRAY_SIZE(prot); i++)
+   mt76_wr(dev, MT_CCK_PROT_CFG + i * 4, prot[i]);
+
+   for (i = 0; i < ARRAY_SIZE(vht_prot); i++)
+   mt76_wr(dev, MT_TX_PROT_CFG6 + i * 4, vht_prot[i]);
+}
+
 void mt76x02_update_channel(struct mt76_dev *mdev)
 {
struct mt76x02_dev *dev = container_of(mdev, struct mt76x02_dev, mt76);
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.h 
b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.h
index d1a8ed171537..91c76a050f7e 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.h
@@ -194,6 +194,8 @@ void mt76x02_send_tx_status(struct mt76x02_dev *dev,
struct mt76x02_tx_status *stat, u8 *update);
 int mt76x02_mac_process_rx(struct mt76x02_dev *dev, struct sk_buff *skb,
   void *rxi);
+void mt76x02_mac_set_tx_protection(struct mt76x02_dev *dev, bool legacy_prot,
+  int ht_mode);
 void mt76x02_mac_set_rts_thresh(struct mt76x02_dev *dev, u32 val);
 void mt76x02_mac_setaddr(struct mt76x02_dev *dev, u8 *addr);
 void mt76x02_mac_write_txwi(struct mt76x02_dev *dev, struct mt76x02_txwi *txwi,
diff --git a

[PATCH 1/5] mt76x02: do not set protection on set_rts_threshold callback

2018-12-07 Thread Stanislaw Gruszka
Use set_rts_threshold calback to enable/disable threshold only for
legacy traffic.

Protection for HT and VHT traffic is defined by HT operation element
and it's provided by remote AP or by hostapd.

Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/mediatek/mt76/mt76x02_mac.c  | 16 +---
 drivers/net/wireless/mediatek/mt76/mt76x02_mac.h  |  2 +-
 drivers/net/wireless/mediatek/mt76/mt76x02_util.c |  2 +-
 3 files changed, 3 insertions(+), 17 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c 
b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
index c08bf371e527..9693d6140b3d 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
@@ -715,7 +715,7 @@ void mt76x02_tx_complete_skb(struct mt76_dev *mdev, struct 
mt76_queue *q,
 }
 EXPORT_SYMBOL_GPL(mt76x02_tx_complete_skb);
 
-void mt76x02_mac_set_tx_protection(struct mt76x02_dev *dev, u32 val)
+void mt76x02_mac_set_rts_thresh(struct mt76x02_dev *dev, u32 val)
 {
u32 data = 0;
 
@@ -729,20 +729,6 @@ void mt76x02_mac_set_tx_protection(struct mt76x02_dev 
*dev, u32 val)
 MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
mt76_rmw(dev, MT_OFDM_PROT_CFG,
 MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
-   mt76_rmw(dev, MT_MM20_PROT_CFG,
-MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
-   mt76_rmw(dev, MT_MM40_PROT_CFG,
-MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
-   mt76_rmw(dev, MT_GF20_PROT_CFG,
-MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
-   mt76_rmw(dev, MT_GF40_PROT_CFG,
-MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
-   mt76_rmw(dev, MT_TX_PROT_CFG6,
-MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
-   mt76_rmw(dev, MT_TX_PROT_CFG7,
-MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
-   mt76_rmw(dev, MT_TX_PROT_CFG8,
-MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
 }
 
 void mt76x02_update_channel(struct mt76_dev *mdev)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.h 
b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.h
index 4e597004c445..d1a8ed171537 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.h
@@ -194,7 +194,7 @@ void mt76x02_send_tx_status(struct mt76x02_dev *dev,
struct mt76x02_tx_status *stat, u8 *update);
 int mt76x02_mac_process_rx(struct mt76x02_dev *dev, struct sk_buff *skb,
   void *rxi);
-void mt76x02_mac_set_tx_protection(struct mt76x02_dev *dev, u32 val);
+void mt76x02_mac_set_rts_thresh(struct mt76x02_dev *dev, u32 val);
 void mt76x02_mac_setaddr(struct mt76x02_dev *dev, u8 *addr);
 void mt76x02_mac_write_txwi(struct mt76x02_dev *dev, struct mt76x02_txwi *txwi,
struct sk_buff *skb, struct mt76_wcid *wcid,
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c 
b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
index 3a70e5bf7d42..e7ee2cc76edf 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
@@ -463,7 +463,7 @@ int mt76x02_set_rts_threshold(struct ieee80211_hw *hw, u32 
val)
return -EINVAL;
 
mutex_lock(>mutex);
-   mt76x02_mac_set_tx_protection(dev, val);
+   mt76x02_mac_set_rts_thresh(dev, val);
mutex_unlock(>mutex);
 
return 0;
-- 
1.9.3



[PATCH 2/5] mt76x02: fixup MT_PROT_RATE_* defines

2018-12-07 Thread Stanislaw Gruszka
On new mt76 chips, phy mode is configured by last 3 bits
of rate value. Hence OFDM bit is marked by 0x2000
instead of 0x4000.

Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/mediatek/mt76/mt76x02_regs.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_regs.h 
b/drivers/net/wireless/mediatek/mt76/mt76x02_regs.h
index f7de77d09d28..d1ac847adce5 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_regs.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_regs.h
@@ -440,9 +440,9 @@
 #define MT_PROT_TXOP_ALLOW_GF40BIT(25)
 #define MT_PROT_RTS_THR_EN BIT(26)
 #define MT_PROT_RATE_CCK_110x0003
-#define MT_PROT_RATE_OFDM_60x4000
-#define MT_PROT_RATE_OFDM_24   0x4004
-#define MT_PROT_RATE_DUP_OFDM_24   0x4084
+#define MT_PROT_RATE_OFDM_60x2000
+#define MT_PROT_RATE_OFDM_24   0x2004
+#define MT_PROT_RATE_DUP_OFDM_24   0x2084
 #define MT_PROT_TXOP_ALLOW_ALL GENMASK(25, 20)
 #define MT_PROT_TXOP_ALLOW_BW20(MT_PROT_TXOP_ALLOW_ALL &   
\
 ~MT_PROT_TXOP_ALLOW_MM40 & \
-- 
1.9.3



Re: [RFC/RFT 1/4] mt76x02: configure basic rates and fallback on STA mode

2018-12-07 Thread Stanislaw Gruszka
On Thu, Nov 08, 2018 at 05:02:14PM +0100, Felix Fietkau wrote:
> >> > +   if (changed & BSS_CHANGED_BASIC_RATES &&
> >> > +   vif->type == NL80211_IFTYPE_STATION) {
> >> > +   mt76_wr(dev, MT_LEGACY_BASIC_RATE, info->basic_rates);

It's a bit hard to interpret how vendor driver set LEGACY_BIT_RATE
in MlmeUpdateTxRates(). It seems to always enable bits for
OFDM6/OFDM12/OFDM24 (bitmask 0x150) or maybe just do this for 5GHz,
I'm not sure. Need more investigation on this.
 
> >> > +   mt76_wr(dev, MT_VHT_HT_FBK_CFG0, 0x65432100);
> >> > +   mt76_wr(dev, MT_VHT_HT_FBK_CFG1, 0xedcba980);
> >> > +   mt76_wr(dev, MT_LG_FBK_CFG0, 0xedcba988);
> >> > +   if (is_mt76x2(dev))
> >> > +   mt76_wr(dev, MT_LG_FBK_CFG1, 0x87872100);
> >> > +   else
> >> > +   mt76_wr(dev, MT_LG_FBK_CFG1, 0x00872100);
> >> > +   }
> >> > +
> >> 
> >> since these values are constant, why not put them init_vals?
> > 
> > I wanted them to be used only in STA mode like vendor driver does.
> > However if we will have AP+STA , we still will configure them,
> > so better to configure them anyway and put in init_vals .
> Yes, I think we should put them in initvals. Also, I think we should
> keep the values the shared between mt76x0 and mt76x2.
> 
> For MT_LG_FBK_CFG1 there is no need to make a distinction between 76x2
> and 76x0, because 76x0 will simply ignore the upper values (they apply
> to 2SS transmission only).
> Also, I don't think MT_VHT_HT_FBK_CFG1 even gets used on mt76x0, because
> it is for 2SS rates only. However, the value in there seems more useful
> than the one we currently use on mt76x2, because it allows fallback from
> 2SS MCS0 to 1SS MCS0.
> The contents of MT_LG_FBK_CFG0 also match the default initialization
> values documented in the 7612E datasheet.
> 
> I don't think there is any meaningful difference between the 76x2 and
> the 76x0 MAC except for the missing 2SS support.

Since there are different initvals tables for mt76x2 and mt76x0, I use
different values of MT_LG_FBK_CFG1. Will post a patches soon, please
comment there, if something is not correct.

Thanks
Stanislaw


Re: [PATCH 2/2] mt76: dma: add rx buffer recycle support

2018-12-06 Thread Stanislaw Gruszka
On Wed, Dec 05, 2018 at 04:17:31PM +0100, Lorenzo Bianconi wrote:
> > On Wed, Dec 05, 2018 at 11:37:33AM +0100, Lorenzo Bianconi wrote:
> > > >
> > > > Add support for recycling rx buffers if they are not forwarded
> > > > to network stack instead of reallocate them from scratch
> > > >
> > > > Signed-off-by: Lorenzo Bianconi 
> > > > ---
> > > 
> > > Felix,
> > > 
> > > could you please drop this patch since it does not help to reduce pressure
> > > on page_frag_cache.
> > 
> > What is the problem ? Maybe using kmalloc() instead of page_frag_alloc()
> > could help (kmalloc has standard kmem_cache for 2048 bytes object) ?
> 
> Hi Stanislaw,
> 
> I think the only difference in using a recycle buffer with page_frag_cache is
> we are a little bit less greedy in consuming the compound page since in case 
> of
> error we will reuse the previously allocated fragment. However we will need to
> reallocate a new compound page if we have a leftover fragment that 'locks'
> the previous compound (we have the same issue if we do not use the recycle
> buffer). Does this 'little' improvement worth a more complex code?
> Do you agree or is there something I am missing here?

I was not asking about the patch. I agree it should be droped. 

I was asking what is the problem with "pressure on page_frag_cache" and if
using kmalloc() instead of page_frag_alloc() whould be potential solution.

Regards
Stanislaw



Re: [PATCH 2/2] mt76: dma: add rx buffer recycle support

2018-12-05 Thread Stanislaw Gruszka
On Wed, Dec 05, 2018 at 11:37:33AM +0100, Lorenzo Bianconi wrote:
> >
> > Add support for recycling rx buffers if they are not forwarded
> > to network stack instead of reallocate them from scratch
> >
> > Signed-off-by: Lorenzo Bianconi 
> > ---
> 
> Felix,
> 
> could you please drop this patch since it does not help to reduce pressure
> on page_frag_cache.

What is the problem ? Maybe using kmalloc() instead of page_frag_alloc()
could help (kmalloc has standard kmem_cache for 2048 bytes object) ?

Thanks
Stanislaw


Re: [RFC/RFT 3/4] mt76x02: do not set protection on set_rts_threshold callback

2018-12-04 Thread Stanislaw Gruszka
On Tue, Dec 04, 2018 at 11:45:09AM +0100, Stanislaw Gruszka wrote:

> Only OFDM_PROT_CFG is configured there based on legacy proto
> value. I'm not sure how handle CCK_PROT_CFG.
> 
> > > - mt76_rmw(dev, MT_MM20_PROT_CFG,
> > > -  MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
> > > - mt76_rmw(dev, MT_MM40_PROT_CFG,
> > > -  MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
> > > - mt76_rmw(dev, MT_GF20_PROT_CFG,
> > > -  MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
> > > - mt76_rmw(dev, MT_GF40_PROT_CFG,
> > > -  MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
> > > - mt76_rmw(dev, MT_TX_PROT_CFG6,
> > > -  MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
> > > - mt76_rmw(dev, MT_TX_PROT_CFG7,
> > > -  MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
> > > - mt76_rmw(dev, MT_TX_PROT_CFG8,
> > > -  MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
> > 
> > Removing these lines we are no longer able to configure protection for VHT
> > rates. Do we have an equivalent for them in vht_capab?
> 
> Actually it's not based on HT capabilities but by on ht operation and
> it's modified dynamically by hostapd based on what stations are
> associated. For STA mode it's provided by remote AP via HT operation IE.
> 
> VHT Operation IE do not define protection. Seems interoperability with
> legacy STA's is not allowed for VHT, so leaving default values from
> initvals where PROT bits are 0 (none protection) is right thing to do.

But vendor driver change the VHT protection bits based on HT
operation element, with the comment:

"TODO: shiang-6590, fix me for this protection mechanism"

So I'm not sure any longer what correct behaviour should be for 
TX_PROT_CFG{6,7,8}.

Regards
Stanislaw


Re: [RFC/RFT 3/4] mt76x02: do not set protection on set_rts_threshold callback

2018-12-04 Thread Stanislaw Gruszka
On Fri, Nov 09, 2018 at 10:23:56AM +0100, Lorenzo Bianconi wrote:
> > Use set_rts_threshold calback to enable/disable threshold only for
> > legacy traffic. RTS/CTS threshold for HT TXOP make make no sense
> > to me since used protection (RTS/CTS , CTS-to-self or none)
> > should be determined by HT capabilities and applied to any HT
> > frames.
> > 
> > Signed-off-by: Stanislaw Gruszka 
> > ---
> >  drivers/net/wireless/mediatek/mt76/mt76x02_mac.c  | 16 +---
> >  drivers/net/wireless/mediatek/mt76/mt76x02_mac.h  |  2 +-
> >  drivers/net/wireless/mediatek/mt76/mt76x02_util.c |  2 +-
> >  3 files changed, 3 insertions(+), 17 deletions(-)
> > 
> > diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c 
> > b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
> > index 59b336e34cb5..567a7ab47fab 100644
> > --- a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
> > +++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
> > @@ -737,7 +737,7 @@ void mt76x02_tx_complete_skb(struct mt76_dev *mdev, 
> > struct mt76_queue *q,
> >  }
> >  EXPORT_SYMBOL_GPL(mt76x02_tx_complete_skb);
> >  
> > -void mt76x02_mac_set_tx_protection(struct mt76x02_dev *dev, u32 val)
> > +void mt76x02_mac_set_rts_thresh(struct mt76x02_dev *dev, u32 val)
> >  {
> > u32 data = 0;
> >  
> > @@ -751,20 +751,6 @@ void mt76x02_mac_set_tx_protection(struct mt76x02_dev 
> > *dev, u32 val)
> >  MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
> > mt76_rmw(dev, MT_OFDM_PROT_CFG,
> >  MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
> 
> Do we need to configure MT_OFDM_PROT_CFG and MT_CCK_PROT_CFG here? (since they
> are already configured in 4/4 (mt76x02: set protection according to ht
> capabilities))

Only OFDM_PROT_CFG is configured there based on legacy proto
value. I'm not sure how handle CCK_PROT_CFG.

> > -   mt76_rmw(dev, MT_MM20_PROT_CFG,
> > -MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
> > -   mt76_rmw(dev, MT_MM40_PROT_CFG,
> > -MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
> > -   mt76_rmw(dev, MT_GF20_PROT_CFG,
> > -MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
> > -   mt76_rmw(dev, MT_GF40_PROT_CFG,
> > -MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
> > -   mt76_rmw(dev, MT_TX_PROT_CFG6,
> > -MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
> > -   mt76_rmw(dev, MT_TX_PROT_CFG7,
> > -MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
> > -   mt76_rmw(dev, MT_TX_PROT_CFG8,
> > -MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
> 
> Removing these lines we are no longer able to configure protection for VHT
> rates. Do we have an equivalent for them in vht_capab?

Actually it's not based on HT capabilities but by on ht operation and
it's modified dynamically by hostapd based on what stations are
associated. For STA mode it's provided by remote AP via HT operation IE.

VHT Operation IE do not define protection. Seems interoperability with
legacy STA's is not allowed for VHT, so leaving default values from
initvals where PROT bits are 0 (none protection) is right thing to do.

Regards
Stanislaw


Re: rt2800 tx frame dropping issue.

2018-12-04 Thread Stanislaw Gruszka
Hi Daniel

On Mon, Dec 03, 2018 at 03:44:46PM -0600, Daniel Santos wrote:
> I almost managed to get that patch in a build to send to somebody who
> can reproduce the error in abundance, but they have 15 different people
> hammer the router to do it and we ended up sending them a few other
> experimental builds instead.
> 
> I'm still learning this driver, but I don't see where it creates a
> struct net_device -- was that something that came out after the driver
> was originally written? (And maybe gets implicitly created somewhere
> else?)  

It is done in ieee80211_if_add(), one netdev per vif.

> iiuc, the best way to do this is by setting tx_queue_len while
> the interface is down (via "ip link") and then allocating the queue when
> it's brought up.

We have diffrent queues at various levels in the network stack.
The queues size I plan to increase are referenced as HW queues

> Unless you know of a problem with this approach, I'm planning on making
> a patch just for that.  It will then be easier to tune for an end user's
> particular application. 

I don't think it's correct approch. Maybe module parameter will be
better just for testing. But since this is for routers/APs just
making build with diffrent tx queues size seems to be better
approach.

> For instance, if there is a small number of
> uses who just use a very large amount of bandwidth then buffer bloat
> could become a problem if it's too high.  But for a larger number of
> users I don't think the buffer bloat probably will matter as much as
> lost performance from dropping frames and needing to re-request many
> lost packets at the TCP layer.  This would also result in more uplink
> bandwidth being consumed.

Well, I guess that correct, but I still wish to see if increase queues
size do not cause big negative effect.

Thanks
Stanislaw


Re: [PATCH v2 00/13] rtw88: mac80211 driver for Realtek 802.11ac wireless network chips

2018-11-30 Thread Stanislaw Gruszka
On Fri, Nov 16, 2018 at 07:31:06PM +0800, yhchu...@realtek.com wrote:
> From: Yan-Hsuan Chuang 
> 
> This is a new mac80211 driver for Realtek 802.11ac wireless network chips.
> rtw88 supports 8822BE and 8822CE chips, and will be able to support
> multi-vif combinations in run-time.
> 
> For now, only PCI bus is supported, but rtw88 was originally designed
> to optionally support three buses includes USB & SDIO. USB & SDIO modules
> will soon be supported by rtw88, with configurable core module to fit
> with different bus modules in the same time.
> 
> For example, if we choose 8822BE and 8822CU, only PCI & USB modules will
> be selected, built, loaded into kernel. This is one of the major
> difference from rtlwifi, which can only support specific combinations.
> 
> Another difference from rtlwifi is that rtw88 is designed to support
> the latest Realtek 802.11ac wireless network chips like 8822B and
> 8822C series. Compared to the earlier chips supported by rtlwifi like
> the 802.11n 8192EE chipset or 802.11ac 8821AE/8812AE chips, newer ICs
> have different MAC & PHY settings, such as new multi-port feature for the
> MAC layer design and Jaguar2/Jaguar3 PHY layer IPs.
> 
> Multi-Port feature is also supported under rtw88's software architecture.
> rtlwifi can only support one vif in the same time, most because of the
> hardware limitations for early chips, hence the original design of it
> also restricts the usage of multi-vif support, so latest chipset seems not
> take advantages from its new MAC engine.
> 
> However, rtw88 can run multiple vifs concurrently by holding them on
> hardware ports provided by MAC engine, hence can easily start different
> roles on a single device.
> 
> Based on the reasons mentioned before, we implemented rtw88. It had many
> authors, they are listed here alphabetically:
> 
> Ping-Ke Shih 
> Tzu-En Huang 
> Yan-Hsuan Chuang 

For the series:
Reviewed-by: Stanislaw Gruszka 


Re: [PATCH] mt76: handle protocol error to proper deinit rx_tasklet

2018-11-26 Thread Stanislaw Gruszka
On Sat, Nov 24, 2018 at 10:25:52AM +0100, Lorenzo Bianconi wrote:
> > During removal of usb dongle, noticed many unhandled rx urb
> > below. This this patch, make it possible and early completion
> > of the rx tasklet.
> >
> > mt76x2u 1-3.4.3.1.2:1.0: rx urb failed: -71
> > mt76x2u 1-3.4.3.1.2:1.0: rx urb failed: -71
> > mt76x2u 1-3.4.3.1.2:1.0: rx urb failed: -71
> > mt76x2u 1-3.4.3.1.2:1.0: rx urb failed: -71

If problem here is just printing errors, I think we are ok. If problem
is some hung or infinity loop, it should be fixed.

> Hi Eduardo,
> 
> I think EPROTO is a more general error (it is not strictly related to
> device removal)
> and it could happen even during normal operation. In this case I guess we 
> should
> reinsert the urb to usb-core.

Some (out of tree) usb host drivers returns EPROTO all the time
in some error conditions. On rt2x00 resubmitting urb resulted in
infinity loop:
https://marc.info/?t=15337512872=1=2

Fix I proposed for that was counting EPROTO errors and 
mark device as removed if 10 of them happened in row:
https://marc.info/?l=linux-wireless=153441755529960=2

Thanks
Stanislaw 


Re: rt2800 tx frame dropping issue.

2018-11-26 Thread Stanislaw Gruszka
On Fri, Nov 23, 2018 at 08:45:54PM +0100, Johannes Berg wrote:
> On Tue, 2018-11-20 at 15:20 -0600, Daniel Santos wrote:
> 
> > I believe I have the answer as to why we're getting frames after we stop
> > the queue.  I had a little chat about this in #kernelnewbies and some
> > other devs believe it is intentional.
> > 
> > There is a race in ieee80211_tx_frags (net/mac80211/tx.c) between
> > releasing local->queue_stop_reason_lock and calling the driver's tx
> > until we lock queue->tx_lock in rt2x00queue_write_tx_frame -- in between
> > these two points the thread can be preempted.  So while we stop the
> > queue in one thread, there can be 20 other threads in between that have
> > already checked that the queue was running and have a frame buffer
> > sitting on their stacks.
> 
> Not 20, only 1 per netdev queue. I suspect that means just 1 per
> hardware queue, but I don't know how rt2x00 maps netdev queues to
> hardware queues. If you have lots of netdevs, that might actually be 20,
> but I suspect that's not what's going on here.
> 
> >   I think it could be fixed with the below
> > patch, but I'm being told that it doesn't need it and that the driver
> > should just *quietly* drop the frame:
> 
> [snip patch]
> 
> > Could anybody illuminate for me why this isn't done?  I know that there
> > has to be a point where we realize there are too many items in the queue
> > and we can't keep up, but this would seem to be a terrible way to do
> > that.  Is it one of those things where it isn't worth the performance
> > degradation?  Any insights would be most appreciated!! :)
> 
> There's just not much point, and doing the locking here will mean it's
> across _all_ queues, whereas if you have multiple hardware queues you
> wouldn't really need it.
> 
> Note that with internal TXQs with fq/codel support etc. we actually have
> the fq->lock and it's global, and it turns out that's still a better
> deal than actually doing parallel TX. So this may not matter so much.
> 
> In any case, while this might solve the problem for the specific case
> you're thinking about, as soon as you have something else starting or
> stopping queues from outside the TX path it still wouldn't actually
> help.
> 
> By the way, one thing that can likely exacerbate the problem is
> fragmentation, once you have that you're more likely to trigger lots of
> frames in close succession.
> 
> What I would suggest doing in the driver is actually stop the queues
> once a *threshold* is reached, rather than being full. Say if you have
> 128 entries in the HW queue, you can stop once you reach 120 (you
> probably don't really need the other 8 places). If you get a 121st
> frame, then you can still put it on the queue (until you filled 128),
> but you can also stop the queue again (stopping queues is idempotent).

That what rt2x00 does, but we have 64 entries on tx queues and
because of that threshold is small. In:

https://bugzilla.kernel.org/show_bug.cgi?id=82751

I proposed increase of queue size to 256 and hence make threshold
bigger. However I was concerned about bufferbloat and requested
testing from users how this affect latency. Never get testing 
results :-(

Thanks
Stanislaw


Re: [PATCH 2/5] mt76x02: initalize mutli bss mode by default

2018-11-09 Thread Stanislaw Gruszka
On Fri, Nov 09, 2018 at 02:31:31PM +0100, Lorenzo Bianconi wrote:
> > 
> > Anyway I think, to support MAC address change, we should not filter
> > based on MAC address, but maybe only on BSSID ? 
> > 
> > Thanks
> > Stanislaw
> 
> You can create the interface with a given mac address
> 
> # iw phy phy0 interface add wlp0s4u1 type managed addr 00:11:22:33:44:55

I realized I have ancient version of iw :-)

Ok, so to do not break that we can add it to common function like this:

+   if (vif->type == NL80211_IFTYPE_STATION) {
+   if (idx == 0)
+   mt76x02_mac_init_mbss(dev, vif->addr);
idx += 8;
+   }

Thanks
Stanislaw
 


Re: [PATCH 1/5] mt76x02: correct set bssid for STA

2018-11-09 Thread Stanislaw Gruszka
On Fri, Nov 09, 2018 at 01:50:51PM +0100, Lorenzo Bianconi wrote:
> > On 2018-11-09 12:09, Lorenzo Bianconi wrote:
> > >> Use MT_MAC_APC_BSSID0_H_EN bit to indicatate we are
> > >> setting BSSID for STA.
> > >> 
> > >> Signed-off-by: Stanislaw Gruszka 
> > >> ---
> > >>  drivers/net/wireless/mediatek/mt76/mt76x02_mac.c | 12 +---
> > >>  1 file changed, 9 insertions(+), 3 deletions(-)
> > >> 
> > >> diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c 
> > >> b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
> > >> index 59b336e34cb5..cfeae5586897 100644
> > >> --- a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
> > >> +++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
> > >> @@ -826,10 +826,16 @@ void mt76x02_mac_work(struct work_struct *work)
> > >>  
> > >>  void mt76x02_mac_set_bssid(struct mt76x02_dev *dev, u8 idx, const u8 
> > >> *addr)
> > >>  {
> > >> +u32 bssid_h = FIELD_PREP(MT_MAC_APC_BSSID_H_ADDR,
> > >> + get_unaligned_le16(addr + 4));
> > >> +u32 bssid_l = get_unaligned_le32(addr);
> > >> +
> > >> +if (idx > 7)
> > >> +bssid_h |= MT_MAC_APC_BSSID0_H_EN;
> > > 
> > > This bit is to enable APClient mode and it is valid just for register 
> > > 0x1094
> > > (MT_MAC_APC_BSSID_{L,h}(0)). Moreover IIRC APClient has been disabled 
> > > because
> > > it causes a performance degradation.
> > The performance degradation was with MAC_ADDR_EXT, not AP-Client.
> > This patch should be fine.
> 
> Ah, now I remember sorry, you are right :)
> Anyway IIRC MT_MAC_APC_BSSID0_H_EN is just for AP_CLIENT_BSSID0 (at least for
> 76x2), for others we need to use BIT(31) but just if APClient is disabled, 
> right?
> Moreover BSSID filter is currently disabled (BIT(3) in RX_FILTER_CFG).
> 
> # echo 0x1400 > /sys/kernel/debug/ieee80211/phy0/mt76/regidx
> # cat /sys/kernel/debug/ieee80211/phy0/mt76/regval
> 0x00017f97
> 
> Have you tried to enabled it?

I didn't try this yet, but I think it should be enabled to support
mulit BSS and MAC address change. 

However I still don't know how to set multiple bssid for STA,
Use BIT(31) or BIT(16) as indicator or maybe 
just write BSSID to MT_MAC_APC_BSSID_{H,L} and hardware will
recognize this is not AP BSSID ?

Thanks
Stanislaw


Re: [PATCH 4/5] mt76x02: minor beaconing init changes

2018-11-09 Thread Stanislaw Gruszka
On Fri, Nov 09, 2018 at 12:33:32PM +0100, Lorenzo Bianconi wrote:
> > Disable BEACON timer during init and remove interrupt registers
> > initalization form generic conde since they are PCIe specific.
> > 
> 
> Since the timer is actually disabled (MT_INT_TIMER_EN set to 0) and
> we just set the timer timeout here, does it worth to copy/paste
> the same code?

As I pointed somwhere else I have some random, not easy to reproduce
performance drops on MT7610U sta mode, starting when AP mode support
was added. I'm can not be sure if this is by this setting this
timer, but I would rather accept slight code duplication, than 
do something that (even with very low probability) can cause
troubles and for sure is not necessary.

Thanks
Stanislaw


Re: [PATCH 2/5] mt76x02: initalize mutli bss mode by default

2018-11-09 Thread Stanislaw Gruszka
On Fri, Nov 09, 2018 at 12:26:51PM +0100, Lorenzo Bianconi wrote:
> > @@ -52,9 +52,6 @@ static int mt76x2u_add_interface(struct ieee80211_hw *hw,
> > struct mt76x02_dev *dev = hw->priv;
> > unsigned int idx = 8;
> >  
> > -   if (!ether_addr_equal(dev->mt76.macaddr, vif->addr))
> > -   mt76x02_mac_setaddr(dev, vif->addr);
> > -
> 
> I think this is a regression since you will able to change device mac address
> in this way. Do you agree?

I don't think it works currently, because we have already created
vif interface when set mac address via ieee80211_change_mac().

The only thing, I suppose could work is set MAC, del vif and
add vif. But this does not seems to work either , below is
example from unpached kernel:

[root@dhcp-27-155 ~]# iw dev
phy#1
Interface wlan1
ifindex 10
wdev 0x10001
addr 2c:4d:54:cb:d8:04
type managed
[root@dhcp-27-155 ~]# ip link set addres  b0:6e:bf:a5:31:90  wlan1
[root@dhcp-27-155 ~]# iw dev wlan1 del
[root@dhcp-27-155 ~]# iw phy phy0 interface  add wlan0 type station
command failed: No such file or directory (-2)
[root@dhcp-27-155 ~]# iw phy phy1 interface  add wlan0 type station
[root@dhcp-27-155 ~]# iw dev 
phy#1
Interface wlan0
ifindex 11
wdev 0x10002
addr 2c:4d:54:cb:d8:04
type managed
[root@dhcp-27-155 ~]# ethtool -i wlan0
driver: mt76x2u
version: 4.20.0-rc1+
firmware-version: 0.0.00-b1
bus-info: 1-1.2:1.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

Anyway I think, to support MAC address change, we should not filter
based on MAC address, but maybe only on BSSID ? 

Thanks
Stanislaw


Re: [PATCH 1/5] mt76x02: correct set bssid for STA

2018-11-09 Thread Stanislaw Gruszka
On Fri, Nov 09, 2018 at 12:09:50PM +0100, Lorenzo Bianconi wrote:
> > Use MT_MAC_APC_BSSID0_H_EN bit to indicatate we are
> > setting BSSID for STA.
> > 
> > Signed-off-by: Stanislaw Gruszka 
> > ---
> >  drivers/net/wireless/mediatek/mt76/mt76x02_mac.c | 12 +---
> >  1 file changed, 9 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c 
> > b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
> > index 59b336e34cb5..cfeae5586897 100644
> > --- a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
> > +++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
> > @@ -826,10 +826,16 @@ void mt76x02_mac_work(struct work_struct *work)
> >  
> >  void mt76x02_mac_set_bssid(struct mt76x02_dev *dev, u8 idx, const u8 *addr)
> >  {
> > +   u32 bssid_h = FIELD_PREP(MT_MAC_APC_BSSID_H_ADDR,
> > +get_unaligned_le16(addr + 4));
> > +   u32 bssid_l = get_unaligned_le32(addr);
> > +
> > +   if (idx > 7)
> > +   bssid_h |= MT_MAC_APC_BSSID0_H_EN;
> 
> This bit is to enable APClient mode and it is valid just for register 0x1094
> (MT_MAC_APC_BSSID_{L,h}(0)). Moreover IIRC APClient has been disabled because
> it causes a performance degradation.

IIRC MT_MAC_APC_BSSID0_H_EN bit enable BSSID8-15 for STA usage, how we then
can program to device those BSSIDs ?

And if this bit is disabled, shouldn't we use MAC_BSSID_DW for setting BSSID
in STA mode ?

Thanks
Stanislaw


[PATCH v2] mt76: remove wait argument from mt76x02_mcu_calibrate

2018-11-09 Thread Stanislaw Gruszka
We always wait for CMD_CALIBRATION_OP mcu message, but wait argument is used
for do additional MT_MCU_COM_REG0 register operations, which are needed
for mt76x2e devices and we can use appropriate check instead of wait argument.

Signed-off-by: Stanislaw Gruszka 
---
v2: use MT_MCU_COM_REG0 register only for mt76x2e

 drivers/net/wireless/mediatek/mt76/mt76x0/phy.c| 14 ++
 drivers/net/wireless/mediatek/mt76/mt76x02_mcu.c   |  8 
 drivers/net/wireless/mediatek/mt76/mt76x02_mcu.h   |  3 +--
 drivers/net/wireless/mediatek/mt76/mt76x2/mt76x2.h |  2 +-
 .../net/wireless/mediatek/mt76/mt76x2/pci_phy.c| 22 +++---
 drivers/net/wireless/mediatek/mt76/mt76x2/phy.c|  4 ++--
 .../net/wireless/mediatek/mt76/mt76x2/usb_phy.c| 22 +++---
 7 files changed, 36 insertions(+), 39 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c 
b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
index 275458891ce4..1eb1a802ed20 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
@@ -868,9 +868,8 @@ void mt76x0_phy_calibrate(struct mt76x02_dev *dev, bool 
power_on)
return;
 
if (power_on) {
-   mt76x02_mcu_calibrate(dev, MCU_CAL_R, 0, false);
-   mt76x02_mcu_calibrate(dev, MCU_CAL_VCO, chan->hw_value,
- false);
+   mt76x02_mcu_calibrate(dev, MCU_CAL_R, 0);
+   mt76x02_mcu_calibrate(dev, MCU_CAL_VCO, chan->hw_value);
usleep_range(10, 20);
 
if (mt76x0_tssi_enabled(dev)) {
@@ -901,14 +900,14 @@ void mt76x0_phy_calibrate(struct mt76x02_dev *dev, bool 
power_on)
val = 0x600;
}
 
-   mt76x02_mcu_calibrate(dev, MCU_CAL_FULL, val, false);
+   mt76x02_mcu_calibrate(dev, MCU_CAL_FULL, val);
msleep(350);
-   mt76x02_mcu_calibrate(dev, MCU_CAL_LC, is_5ghz, false);
+   mt76x02_mcu_calibrate(dev, MCU_CAL_LC, is_5ghz);
usleep_range(15000, 2);
 
mt76_wr(dev, MT_BBP(IBI, 9), reg_val);
mt76_wr(dev, MT_TX_ALC_CFG_0, tx_alc);
-   mt76x02_mcu_calibrate(dev, MCU_CAL_RXDCOC, 1, false);
+   mt76x02_mcu_calibrate(dev, MCU_CAL_RXDCOC, 1);
 }
 EXPORT_SYMBOL_GPL(mt76x0_phy_calibrate);
 
@@ -1044,8 +1043,7 @@ static void mt76x0_phy_temp_sensor(struct mt76x02_dev 
*dev)
 
if (abs(val - dev->cal.temp_vco) > 20) {
mt76x02_mcu_calibrate(dev, MCU_CAL_VCO,
- dev->mt76.chandef.chan->hw_value,
- false);
+ dev->mt76.chandef.chan->hw_value);
dev->cal.temp_vco = val;
}
if (abs(val - dev->cal.temp) > 30) {
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.c 
b/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.c
index 6015ba9ffdac..b7f4edb729e3 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.c
@@ -165,8 +165,7 @@ int mt76x02_mcu_set_radio_state(struct mt76x02_dev *dev, 
bool on)
 }
 EXPORT_SYMBOL_GPL(mt76x02_mcu_set_radio_state);
 
-int mt76x02_mcu_calibrate(struct mt76x02_dev *dev, int type,
- u32 param, bool wait)
+int mt76x02_mcu_calibrate(struct mt76x02_dev *dev, int type, u32 param)
 {
struct {
__le32 id;
@@ -175,9 +174,10 @@ int mt76x02_mcu_calibrate(struct mt76x02_dev *dev, int 
type,
.id = cpu_to_le32(type),
.value = cpu_to_le32(param),
};
+   bool is_mt76x2e = mt76_is_mmio(dev) && is_mt76x2(dev);
int ret;
 
-   if (wait)
+   if (is_mt76x2e)
mt76_rmw(dev, MT_MCU_COM_REG0, BIT(31), 0);
 
ret = mt76_mcu_send_msg(dev, CMD_CALIBRATION_OP, , sizeof(msg),
@@ -185,7 +185,7 @@ int mt76x02_mcu_calibrate(struct mt76x02_dev *dev, int type,
if (ret)
return ret;
 
-   if (wait &&
+   if (is_mt76x2e &&
WARN_ON(!mt76_poll_msec(dev, MT_MCU_COM_REG0,
BIT(31), BIT(31), 100)))
return -ETIMEDOUT;
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.h 
b/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.h
index 97025c31a986..7e4004120102 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.h
@@ -97,8 +97,7 @@ struct mt76x02_patch_header {
 };
 
 int mt76x02_mcu_cleanup(struct mt76x02_dev *dev);
-int mt76x02_mcu_calibrate(struct mt76x02_dev *dev, int type,
- u32 param, bool wait);
+int mt76x02_mcu_calibrate(struct mt76x02_dev *dev, int type, u32 param);
 int mt76x02_mcu_msg_send(struct mt76_dev *mdev, int cmd, const void *data,
 int len, bool wait_resp);
 int mt76x02_mcu_function_select(struct mt76x0

[PATCH 5/5] mt76x02: remove no longer actual comment

2018-11-09 Thread Stanislaw Gruszka
Remove comment about one configurable BSSID registers since
we utilize AP-Client feature now.

Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/mediatek/mt76/mt76x02_util.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c 
b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
index 2bb79c6eb54b..9fd9b5f9d3f5 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
@@ -250,17 +250,10 @@ int mt76x02_sta_remove(struct ieee80211_hw *hw, struct 
ieee80211_vif *vif,
idx = 1 + (((dev->mt76.macaddr[0] ^ vif->addr[0]) >> 2) & 7);
 
/*
-* Client mode typically only has one configurable BSSID register,
-* which is used for bssidx=0. This is linked to the MAC address.
-* Since mac80211 allows changing interface types, and we cannot
-* force the use of the primary MAC address for a station mode
-* interface, we need some other way of configuring a per-interface
-* remote BSSID.
 * The hardware provides an AP-Client feature, where bssidx 0-7 are
 * used for AP mode and bssidx 8-15 for client mode.
 * We shift the station interface bss index by 8 to force the
-* hardware to recognize the BSSID.
-* The resulting bssidx mismatch for unicast frames is ignored by hw.
+* hardware to recognize the BSSID as STA.
 */
if (vif->type == NL80211_IFTYPE_STATION)
idx += 8;
-- 
1.9.3



[PATCH 3/5] mt76x2u: use common mt76x02_add_interface

2018-11-09 Thread Stanislaw Gruszka
There is no need anymore to use custom add interface function
for mt76x02u.

Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/mediatek/mt76/mt76x02.h |  2 --
 drivers/net/wireless/mediatek/mt76/mt76x02_util.c|  6 +++---
 drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c | 12 +---
 3 files changed, 4 insertions(+), 16 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02.h 
b/drivers/net/wireless/mediatek/mt76/mt76x02.h
index a8c5fdd903b9..f8e998ef8716 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02.h
@@ -115,8 +115,6 @@ int mt76x02_sta_add(struct ieee80211_hw *hw, struct 
ieee80211_vif *vif,
 int mt76x02_sta_remove(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
  struct ieee80211_sta *sta);
 
-void mt76x02_vif_init(struct mt76x02_dev *dev, struct ieee80211_vif *vif,
- unsigned int idx);
 int mt76x02_add_interface(struct ieee80211_hw *hw,
 struct ieee80211_vif *vif);
 void mt76x02_remove_interface(struct ieee80211_hw *hw,
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c 
b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
index 2aa3f4b15fd9..dbf9d89dd328 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
@@ -228,8 +228,9 @@ int mt76x02_sta_remove(struct ieee80211_hw *hw, struct 
ieee80211_vif *vif,
 }
 EXPORT_SYMBOL_GPL(mt76x02_sta_remove);
 
-void mt76x02_vif_init(struct mt76x02_dev *dev, struct ieee80211_vif *vif,
- unsigned int idx)
+static void
+mt76x02_vif_init(struct mt76x02_dev *dev, struct ieee80211_vif *vif,
+unsigned int idx)
 {
struct mt76x02_vif *mvif = (struct mt76x02_vif *)vif->drv_priv;
 
@@ -238,7 +239,6 @@ void mt76x02_vif_init(struct mt76x02_dev *dev, struct 
ieee80211_vif *vif,
mvif->group_wcid.hw_key_idx = -1;
mt76x02_txq_init(dev, vif->txq);
 }
-EXPORT_SYMBOL_GPL(mt76x02_vif_init);
 
 int
 mt76x02_add_interface(struct ieee80211_hw *hw, struct ieee80211_vif *vif)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c 
b/drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c
index 977e74091a27..6b51dd749491 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c
@@ -46,16 +46,6 @@ static void mt76x2u_stop(struct ieee80211_hw *hw)
mutex_unlock(>mt76.mutex);
 }
 
-static int mt76x2u_add_interface(struct ieee80211_hw *hw,
-struct ieee80211_vif *vif)
-{
-   struct mt76x02_dev *dev = hw->priv;
-   unsigned int idx = 8;
-
-   mt76x02_vif_init(dev, vif, idx);
-   return 0;
-}
-
 static int
 mt76x2u_set_channel(struct mt76x02_dev *dev,
struct cfg80211_chan_def *chandef)
@@ -122,7 +112,7 @@ static int mt76x2u_add_interface(struct ieee80211_hw *hw,
.tx = mt76x02_tx,
.start = mt76x2u_start,
.stop = mt76x2u_stop,
-   .add_interface = mt76x2u_add_interface,
+   .add_interface = mt76x02_add_interface,
.remove_interface = mt76x02_remove_interface,
.sta_add = mt76x02_sta_add,
.sta_remove = mt76x02_sta_remove,
-- 
1.9.3



[PATCH 1/5] mt76x02: correct set bssid for STA

2018-11-09 Thread Stanislaw Gruszka
Use MT_MAC_APC_BSSID0_H_EN bit to indicatate we are
setting BSSID for STA.

Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/mediatek/mt76/mt76x02_mac.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c 
b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
index 59b336e34cb5..cfeae5586897 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
@@ -826,10 +826,16 @@ void mt76x02_mac_work(struct work_struct *work)
 
 void mt76x02_mac_set_bssid(struct mt76x02_dev *dev, u8 idx, const u8 *addr)
 {
+   u32 bssid_h = FIELD_PREP(MT_MAC_APC_BSSID_H_ADDR,
+get_unaligned_le16(addr + 4));
+   u32 bssid_l = get_unaligned_le32(addr);
+
+   if (idx > 7)
+   bssid_h |= MT_MAC_APC_BSSID0_H_EN;
+
idx &= 7;
-   mt76_wr(dev, MT_MAC_APC_BSSID_L(idx), get_unaligned_le32(addr));
-   mt76_rmw_field(dev, MT_MAC_APC_BSSID_H(idx), MT_MAC_APC_BSSID_H_ADDR,
-  get_unaligned_le16(addr + 4));
+   mt76_wr(dev, MT_MAC_APC_BSSID_L(idx), bssid_l);
+   mt76_wr(dev, MT_MAC_APC_BSSID_H(idx), bssid_h);
 }
 
 static int
-- 
1.9.3



[PATCH 2/5] mt76x02: initalize mutli bss mode by default

2018-11-09 Thread Stanislaw Gruszka
Configure multi bss mode by default on all devices. That mean we
use MAC address for MT_MAC_BSSID_DW and use MT_MAC_APC_BSSID
for configuree bssid for each vif.

This is separe from beaconing as we can have for example 2 STA vifs,
so do not mix bssid init and beacon init.

Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c   |  2 +-
 drivers/net/wireless/mediatek/mt76/mt76x02_mac.c | 17 +++--
 drivers/net/wireless/mediatek/mt76/mt76x02_mac.h |  2 +-
 drivers/net/wireless/mediatek/mt76/mt76x02_util.c| 13 ++---
 drivers/net/wireless/mediatek/mt76/mt76x2/pci_init.c |  4 +---
 drivers/net/wireless/mediatek/mt76/mt76x2/usb_init.c |  2 +-
 drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c |  3 ---
 7 files changed, 21 insertions(+), 22 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c 
b/drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c
index 497e762978cc..5036b61b66f9 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c
@@ -347,7 +347,7 @@ int mt76x0_eeprom_init(struct mt76x02_dev *dev)
dev_info(dev->mt76.dev, "EEPROM ver:%02hhx fae:%02hhx\n",
 version, fae);
 
-   mt76x02_mac_setaddr(dev, dev->mt76.eeprom.data + MT_EE_MAC_ADDR);
+   mt76x02_mac_init_mbss(dev, dev->mt76.eeprom.data + MT_EE_MAC_ADDR);
mt76x0_set_chip_cap(dev);
mt76x0_set_freq_offset(dev);
mt76x0_set_temp_offset(dev);
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c 
b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
index cfeae5586897..b19f9f5b8b89 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
@@ -566,8 +566,11 @@ void mt76x02_send_tx_status(struct mt76x02_dev *dev,
return 0;
 }
 
-void mt76x02_mac_setaddr(struct mt76x02_dev *dev, u8 *addr)
+void mt76x02_mac_init_mbss(struct mt76x02_dev *dev, const u8 *addr)
 {
+   static const u8 null_addr[ETH_ALEN] = {};
+   int i;
+
ether_addr_copy(dev->mt76.macaddr, addr);
 
if (!is_valid_ether_addr(dev->mt76.macaddr)) {
@@ -581,8 +584,18 @@ void mt76x02_mac_setaddr(struct mt76x02_dev *dev, u8 *addr)
mt76_wr(dev, MT_MAC_ADDR_DW1,
get_unaligned_le16(dev->mt76.macaddr + 4) |
FIELD_PREP(MT_MAC_ADDR_DW1_U2ME_MASK, 0xff));
+
+   mt76_wr(dev, MT_MAC_BSSID_DW0,
+   get_unaligned_le32(dev->mt76.macaddr));
+   mt76_wr(dev, MT_MAC_BSSID_DW1,
+   get_unaligned_le16(dev->mt76.macaddr + 4) |
+   FIELD_PREP(MT_MAC_BSSID_DW1_MBSS_MODE, 3) | /* 8 APs + 8 STAs */
+   MT_MAC_BSSID_DW1_MBSS_LOCAL_BIT);
+
+   for (i = 0; i < 16; i++)
+   mt76x02_mac_set_bssid(dev, i, null_addr);
 }
-EXPORT_SYMBOL_GPL(mt76x02_mac_setaddr);
+EXPORT_SYMBOL_GPL(mt76x02_mac_init_mbss);
 
 static int
 mt76x02_mac_get_rssi(struct mt76x02_dev *dev, s8 rssi, int chain)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.h 
b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.h
index b076c4305585..c09181f2da2e 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.h
@@ -198,7 +198,7 @@ void mt76x02_send_tx_status(struct mt76x02_dev *dev,
 int mt76x02_mac_process_rx(struct mt76x02_dev *dev, struct sk_buff *skb,
   void *rxi);
 void mt76x02_mac_set_tx_protection(struct mt76x02_dev *dev, u32 val);
-void mt76x02_mac_setaddr(struct mt76x02_dev *dev, u8 *addr);
+void mt76x02_mac_init_mbss(struct mt76x02_dev *dev, const u8 *addr);
 void mt76x02_mac_write_txwi(struct mt76x02_dev *dev, struct mt76x02_txwi *txwi,
struct sk_buff *skb, struct mt76_wcid *wcid,
struct ieee80211_sta *sta, int len);
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c 
b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
index 87ce6a51fb05..2aa3f4b15fd9 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
@@ -631,16 +631,8 @@ static void mt76x02_set_beacon_offsets(struct mt76x02_dev 
*dev)
 
 void mt76x02_init_beacon_config(struct mt76x02_dev *dev)
 {
-   static const u8 null_addr[ETH_ALEN] = {};
int i;
 
-   mt76_wr(dev, MT_MAC_BSSID_DW0,
-   get_unaligned_le32(dev->mt76.macaddr));
-   mt76_wr(dev, MT_MAC_BSSID_DW1,
-   get_unaligned_le16(dev->mt76.macaddr + 4) |
-   FIELD_PREP(MT_MAC_BSSID_DW1_MBSS_MODE, 3) | /* 8 beacons */
-   MT_MAC_BSSID_DW1_MBSS_LOCAL_BIT);
-
/* Fire a pre-TBTT interrupt 8 ms before TBTT */
mt76_rmw_field(dev, MT_INT_TIMER_CFG, MT_INT_TIMER_CFG_PRE_TBTT,
   8 << 4);
@@ -650,10 +642,9 @@ void mt76x02_init_beacon_config(struct mt76x02_dev *dev)

[PATCH 0/5] mt76x02: bssid setup corrections for STA

2018-11-09 Thread Stanislaw Gruszka
Minor MBSS and beaconing fixups. On top of:
"mt76x2u: init: remove mt76x2u_init_beacon_offsets routine"

Stanislaw Gruszka (5):
  mt76x02: correct set bssid for STA
  mt76x02: initalize mutli bss mode by default
  mt76x2u: use common mt76x02_add_interface
  mt76x02: minor beaconing init changes
  mt76x02: remove no longer actuall comment

 drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c |  2 +-
 drivers/net/wireless/mediatek/mt76/mt76x0/pci.c|  7 
 drivers/net/wireless/mediatek/mt76/mt76x02.h   |  2 --
 drivers/net/wireless/mediatek/mt76/mt76x02_mac.c   | 29 +---
 drivers/net/wireless/mediatek/mt76/mt76x02_mac.h   |  2 +-
 drivers/net/wireless/mediatek/mt76/mt76x02_util.c  | 39 ++
 .../net/wireless/mediatek/mt76/mt76x2/pci_init.c   | 12 +--
 .../net/wireless/mediatek/mt76/mt76x2/usb_init.c   |  2 +-
 .../net/wireless/mediatek/mt76/mt76x2/usb_main.c   | 15 +
 9 files changed, 54 insertions(+), 56 deletions(-)

-- 
1.9.3



[PATCH 4/5] mt76x02: minor beaconing init changes

2018-11-09 Thread Stanislaw Gruszka
Disable BEACON timer during init and remove interrupt registers
initalization form generic conde since they are PCIe specific.

Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/mediatek/mt76/mt76x0/pci.c  |  7 +++
 drivers/net/wireless/mediatek/mt76/mt76x02_util.c| 11 ---
 drivers/net/wireless/mediatek/mt76/mt76x2/pci_init.c |  8 
 3 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c 
b/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
index 757816d2b1ab..d1d3c5706c4d 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
@@ -129,6 +129,13 @@ static int mt76x0e_register_device(struct mt76x02_dev *dev)
if (err < 0)
return err;
 
+   /* Beaconing: fire a pre-TBTT interrupt 8 ms before TBTT */
+   mt76_rmw_field(dev, MT_INT_TIMER_CFG, MT_INT_TIMER_CFG_PRE_TBTT,
+  8 << 4);
+   mt76_rmw_field(dev, MT_INT_TIMER_CFG, MT_INT_TIMER_CFG_GP_TIMER,
+  MT_DFS_GP_INTERVAL);
+   mt76_wr(dev, MT_INT_TIMER_EN, 0);
+
if (mt76_chip(>mt76) == 0x7610) {
u16 val;
 
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c 
b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
index dbf9d89dd328..2bb79c6eb54b 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
@@ -633,13 +633,10 @@ void mt76x02_init_beacon_config(struct mt76x02_dev *dev)
 {
int i;
 
-   /* Fire a pre-TBTT interrupt 8 ms before TBTT */
-   mt76_rmw_field(dev, MT_INT_TIMER_CFG, MT_INT_TIMER_CFG_PRE_TBTT,
-  8 << 4);
-   mt76_rmw_field(dev, MT_INT_TIMER_CFG, MT_INT_TIMER_CFG_GP_TIMER,
-  MT_DFS_GP_INTERVAL);
-   mt76_wr(dev, MT_INT_TIMER_EN, 0);
-
+   mt76_clear(dev, MT_BEACON_TIME_CFG, (MT_BEACON_TIME_CFG_TIMER_EN |
+MT_BEACON_TIME_CFG_SYNC_MODE |
+MT_BEACON_TIME_CFG_TBTT_EN |
+MT_BEACON_TIME_CFG_BEACON_TX));
mt76_wr(dev, MT_BCN_BYPASS_MASK, 0x);
 
for (i = 0; i < 8; i++)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_init.c 
b/drivers/net/wireless/mediatek/mt76/mt76x2/pci_init.c
index d2ef68c48ea5..89941aea8a88 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2/pci_init.c
@@ -121,6 +121,14 @@ static int mt76x2_mac_reset(struct mt76x02_dev *dev, bool 
hard)
 
mt76x02_mac_init_mbss(dev, macaddr);
mt76x02_init_beacon_config(dev);
+
+   /* Fire a pre-TBTT interrupt 8 ms before TBTT */
+   mt76_rmw_field(dev, MT_INT_TIMER_CFG, MT_INT_TIMER_CFG_PRE_TBTT,
+  8 << 4);
+   mt76_rmw_field(dev, MT_INT_TIMER_CFG, MT_INT_TIMER_CFG_GP_TIMER,
+  MT_DFS_GP_INTERVAL);
+   mt76_wr(dev, MT_INT_TIMER_EN, 0);
+
if (!hard)
return 0;
 
-- 
1.9.3



Re: [RFC/RFT 2/4] mt76x02: reserve wcid 0 for global traffic

2018-11-08 Thread Stanislaw Gruszka
On Thu, Nov 08, 2018 at 04:01:54PM +0100, Lorenzo Bianconi wrote:
> > Restore behaviour on mt76x0 before commit  1bb04bb4b838 ("mt76: move
> > mt76x02_init_device in mt76x02-lib module"). This will allow to use
> > wcid 1 for AP when we work in station mode. It's not clear if this
> > is needed, but this is how vendor driver assign wcid's in STA mode.
> > This should be harmless for mt76x2.
> >
> > Signed-off-by: Stanislaw Gruszka 
> > ---
> >  drivers/net/wireless/mediatek/mt76/mt76x02_util.c | 6 +-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c 
> > b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
> > index 2be4b527477f..e624397b3d8b 100644
> > --- a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
> > +++ b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
> > @@ -113,7 +113,11 @@ void mt76x02_init_device(struct mt76x02_dev *dev)
> > ieee80211_hw_set(hw, SUPPORTS_HT_CCK_RATES);
> > ieee80211_hw_set(hw, SUPPORTS_REORDERING_BUFFER);
> >
> > -   dev->mt76.global_wcid.idx = 255;
> > +   /* Reserve WCID 0 for mcast - thanks to this APs WCID will go to
> > +* entry no. 1 like it does in the vendor driver.
> > +*/
> > +   dev->mt76.wcid_mask[0] |= 1;
> > +   dev->mt76.global_wcid.idx = 0;
> > dev->mt76.global_wcid.hw_key_idx = -1;
> > dev->slottime = 9;
> >
> 
> Does it make any difference in AP mode?

First sta will get wcid = 1 instead of 0.

> What about using 0 instead of
> 255 for global_wcid.idx?

Patch do exactly that , it assigns:

dev->mt76.global_wcid.idx = 0;

Thanks
Stanislaw


Re: [RFC/RFT 1/4] mt76x02: configure basic rates and fallback on STA mode

2018-11-08 Thread Stanislaw Gruszka
On Thu, Nov 08, 2018 at 03:58:29PM +0100, Lorenzo Bianconi wrote:
> > For STA mode configure legacy basic rates according to info
> > mac80211 provides to us, as well as follback registers, which
> > are setup in vendor driver under CONFIG_STA_SUPPORT .
> > For LB_FBK_CFG1 register use values from vendor driver, which
> > are different for mt76x0 and mt76x2 .
> >
> > Signed-off-by: Stanislaw Gruszka 
> > ---
> >  drivers/net/wireless/mediatek/mt76/mt76x02_util.c | 12 
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c 
> > b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
> > index 87ce6a51fb05..2be4b527477f 100644
> > --- a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
> > +++ b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
> > @@ -678,6 +678,18 @@ void mt76x02_bss_info_changed(struct ieee80211_hw *hw,
> > tasklet_enable(>pre_tbtt_tasklet);
> > }
> >
> > +   if (changed & BSS_CHANGED_BASIC_RATES &&
> > +   vif->type == NL80211_IFTYPE_STATION) {
> > +   mt76_wr(dev, MT_LEGACY_BASIC_RATE, info->basic_rates);
> > +   mt76_wr(dev, MT_VHT_HT_FBK_CFG0, 0x65432100);
> > +   mt76_wr(dev, MT_VHT_HT_FBK_CFG1, 0xedcba980);
> > +   mt76_wr(dev, MT_LG_FBK_CFG0, 0xedcba988);
> > +   if (is_mt76x2(dev))
> > +   mt76_wr(dev, MT_LG_FBK_CFG1, 0x87872100);
> > +   else
> > +   mt76_wr(dev, MT_LG_FBK_CFG1, 0x00872100);
> > +   }
> > +
> 
> since these values are constant, why not put them init_vals?

I wanted them to be used only in STA mode like vendor driver does.
However if we will have AP+STA , we still will configure them,
so better to configure them anyway and put in init_vals .

Thanks
Stanislaw



[RFC/RFT 2/4] mt76x02: reserve wcid 0 for global traffic

2018-11-08 Thread Stanislaw Gruszka
Restore behaviour on mt76x0 before commit  1bb04bb4b838 ("mt76: move
mt76x02_init_device in mt76x02-lib module"). This will allow to use
wcid 1 for AP when we work in station mode. It's not clear if this
is needed, but this is how vendor driver assign wcid's in STA mode.
This should be harmless for mt76x2.

Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/mediatek/mt76/mt76x02_util.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c 
b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
index 2be4b527477f..e624397b3d8b 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
@@ -113,7 +113,11 @@ void mt76x02_init_device(struct mt76x02_dev *dev)
ieee80211_hw_set(hw, SUPPORTS_HT_CCK_RATES);
ieee80211_hw_set(hw, SUPPORTS_REORDERING_BUFFER);
 
-   dev->mt76.global_wcid.idx = 255;
+   /* Reserve WCID 0 for mcast - thanks to this APs WCID will go to
+* entry no. 1 like it does in the vendor driver.
+*/
+   dev->mt76.wcid_mask[0] |= 1;
+   dev->mt76.global_wcid.idx = 0;
dev->mt76.global_wcid.hw_key_idx = -1;
dev->slottime = 9;
 
-- 
1.9.3



[RFC/RFT 4/4] mt76x02: set protection according to ht capabilities

2018-11-08 Thread Stanislaw Gruszka
Use information about protection that mac80211 provide to us.
Used protection should be part of ht capabilites that either
remote AP provde to us in STA mode or is set in hostapd.conf
in ht_capab option.

Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/mediatek/mt76/mt76x02_mac.c  | 58 +++
 drivers/net/wireless/mediatek/mt76/mt76x02_mac.h  |  2 +
 drivers/net/wireless/mediatek/mt76/mt76x02_util.c |  4 ++
 3 files changed, 64 insertions(+)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c 
b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
index 567a7ab47fab..6096efc4119b 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
@@ -753,6 +753,64 @@ void mt76x02_mac_set_rts_thresh(struct mt76x02_dev *dev, 
u32 val)
 MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
 }
 
+void mt76x02_mac_set_tx_protection(struct mt76x02_dev *dev, bool legacy_prot,
+  int ht_mode)
+{
+   int mode = ht_mode & IEEE80211_HT_OP_MODE_PROTECTION;
+   bool non_gf = !!(ht_mode & IEEE80211_HT_OP_MODE_NON_GF_STA_PRSNT);
+   u32 prot[6];
+   bool ht_rts[4] = {};
+   int i;
+
+   for (i = 0; i < 6; i++) {
+   prot[i] = mt76_rr(dev, MT_CCK_PROT_CFG + i * 4);
+   if (i >= 2)
+   prot[i] &= ~(MT_PROT_CFG_CTRL | MT_PROT_CFG_RATE);
+   }
+
+   if (legacy_prot) {
+   prot[1] &= ~MT_PROT_CFG_CTRL;
+   prot[1] |= MT_PROT_CTRL_CTS2SELF;
+
+   prot[2] |= MT_PROT_RATE_CCK_11;
+   prot[3] |= MT_PROT_RATE_CCK_11;
+   prot[4] |= MT_PROT_RATE_CCK_11;
+   prot[5] |= MT_PROT_RATE_CCK_11;
+   } else {
+   prot[2] |= MT_PROT_RATE_OFDM_24;
+   prot[3] |= MT_PROT_RATE_DUP_OFDM_24;
+   prot[4] |= MT_PROT_RATE_OFDM_24;
+   prot[5] |= MT_PROT_RATE_DUP_OFDM_24;
+   }
+
+   switch (mode) {
+   case IEEE80211_HT_OP_MODE_PROTECTION_NONE:
+   break;
+
+   case IEEE80211_HT_OP_MODE_PROTECTION_NONMEMBER:
+   ht_rts[0] = ht_rts[1] = ht_rts[2] = ht_rts[3] = true;
+   break;
+
+   case IEEE80211_HT_OP_MODE_PROTECTION_20MHZ:
+   ht_rts[1] = ht_rts[3] = true;
+   break;
+
+   case IEEE80211_HT_OP_MODE_PROTECTION_NONHT_MIXED:
+   ht_rts[0] = ht_rts[1] = ht_rts[2] = ht_rts[3] = true;
+   break;
+   }
+
+   if (non_gf)
+   ht_rts[2] = ht_rts[3] = true;
+
+   for (i = 0; i < 4; i++)
+   if (ht_rts[i])
+   prot[i + 2] |= MT_PROT_CTRL_RTS_CTS;
+
+   for (i = 0; i < 6; i++)
+   mt76_wr(dev, MT_CCK_PROT_CFG + i * 4, prot[i]);
+}
+
 void mt76x02_update_channel(struct mt76_dev *mdev)
 {
struct mt76x02_dev *dev = container_of(mdev, struct mt76x02_dev, mt76);
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.h 
b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.h
index 34da8c600db8..9035397ae081 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.h
@@ -197,6 +197,8 @@ void mt76x02_send_tx_status(struct mt76x02_dev *dev,
struct mt76x02_tx_status *stat, u8 *update);
 int mt76x02_mac_process_rx(struct mt76x02_dev *dev, struct sk_buff *skb,
   void *rxi);
+void mt76x02_mac_set_tx_protection(struct mt76x02_dev *dev, bool legacy_prot,
+  int ht_mode);
 void mt76x02_mac_set_rts_thresh(struct mt76x02_dev *dev, u32 val);
 void mt76x02_mac_setaddr(struct mt76x02_dev *dev, u8 *addr);
 void mt76x02_mac_write_txwi(struct mt76x02_dev *dev, struct mt76x02_txwi *txwi,
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c 
b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
index fda67b0923a6..51db4d3dcc13 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
@@ -682,6 +682,10 @@ void mt76x02_bss_info_changed(struct ieee80211_hw *hw,
tasklet_enable(>pre_tbtt_tasklet);
}
 
+   if (changed & BSS_CHANGED_HT || changed & BSS_CHANGED_ERP_CTS_PROT)
+   mt76x02_mac_set_tx_protection(dev, info->use_cts_prot,
+ info->ht_operation_mode);
+
if (changed & BSS_CHANGED_BASIC_RATES &&
vif->type == NL80211_IFTYPE_STATION) {
mt76_wr(dev, MT_LEGACY_BASIC_RATE, info->basic_rates);
-- 
1.9.3



[RFC/RFT 3/4] mt76x02: do not set protection on set_rts_threshold callback

2018-11-08 Thread Stanislaw Gruszka
Use set_rts_threshold calback to enable/disable threshold only for
legacy traffic. RTS/CTS threshold for HT TXOP make make no sense
to me since used protection (RTS/CTS , CTS-to-self or none)
should be determined by HT capabilities and applied to any HT
frames.

Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/mediatek/mt76/mt76x02_mac.c  | 16 +---
 drivers/net/wireless/mediatek/mt76/mt76x02_mac.h  |  2 +-
 drivers/net/wireless/mediatek/mt76/mt76x02_util.c |  2 +-
 3 files changed, 3 insertions(+), 17 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c 
b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
index 59b336e34cb5..567a7ab47fab 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
@@ -737,7 +737,7 @@ void mt76x02_tx_complete_skb(struct mt76_dev *mdev, struct 
mt76_queue *q,
 }
 EXPORT_SYMBOL_GPL(mt76x02_tx_complete_skb);
 
-void mt76x02_mac_set_tx_protection(struct mt76x02_dev *dev, u32 val)
+void mt76x02_mac_set_rts_thresh(struct mt76x02_dev *dev, u32 val)
 {
u32 data = 0;
 
@@ -751,20 +751,6 @@ void mt76x02_mac_set_tx_protection(struct mt76x02_dev 
*dev, u32 val)
 MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
mt76_rmw(dev, MT_OFDM_PROT_CFG,
 MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
-   mt76_rmw(dev, MT_MM20_PROT_CFG,
-MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
-   mt76_rmw(dev, MT_MM40_PROT_CFG,
-MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
-   mt76_rmw(dev, MT_GF20_PROT_CFG,
-MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
-   mt76_rmw(dev, MT_GF40_PROT_CFG,
-MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
-   mt76_rmw(dev, MT_TX_PROT_CFG6,
-MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
-   mt76_rmw(dev, MT_TX_PROT_CFG7,
-MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
-   mt76_rmw(dev, MT_TX_PROT_CFG8,
-MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
 }
 
 void mt76x02_update_channel(struct mt76_dev *mdev)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.h 
b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.h
index b076c4305585..34da8c600db8 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.h
@@ -197,7 +197,7 @@ void mt76x02_send_tx_status(struct mt76x02_dev *dev,
struct mt76x02_tx_status *stat, u8 *update);
 int mt76x02_mac_process_rx(struct mt76x02_dev *dev, struct sk_buff *skb,
   void *rxi);
-void mt76x02_mac_set_tx_protection(struct mt76x02_dev *dev, u32 val);
+void mt76x02_mac_set_rts_thresh(struct mt76x02_dev *dev, u32 val);
 void mt76x02_mac_setaddr(struct mt76x02_dev *dev, u8 *addr);
 void mt76x02_mac_write_txwi(struct mt76x02_dev *dev, struct mt76x02_txwi *txwi,
struct sk_buff *skb, struct mt76_wcid *wcid,
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c 
b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
index e624397b3d8b..fda67b0923a6 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
@@ -484,7 +484,7 @@ int mt76x02_set_rts_threshold(struct ieee80211_hw *hw, u32 
val)
return -EINVAL;
 
mutex_lock(>mutex);
-   mt76x02_mac_set_tx_protection(dev, val);
+   mt76x02_mac_set_rts_thresh(dev, val);
mutex_unlock(>mutex);
 
return 0;
-- 
1.9.3



[RFC/RFT 1/4] mt76x02: configure basic rates and fallback on STA mode

2018-11-08 Thread Stanislaw Gruszka
For STA mode configure legacy basic rates according to info
mac80211 provides to us, as well as follback registers, which
are setup in vendor driver under CONFIG_STA_SUPPORT .
For LB_FBK_CFG1 register use values from vendor driver, which
are different for mt76x0 and mt76x2 .

Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/mediatek/mt76/mt76x02_util.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c 
b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
index 87ce6a51fb05..2be4b527477f 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
@@ -678,6 +678,18 @@ void mt76x02_bss_info_changed(struct ieee80211_hw *hw,
tasklet_enable(>pre_tbtt_tasklet);
}
 
+   if (changed & BSS_CHANGED_BASIC_RATES &&
+   vif->type == NL80211_IFTYPE_STATION) {
+   mt76_wr(dev, MT_LEGACY_BASIC_RATE, info->basic_rates);
+   mt76_wr(dev, MT_VHT_HT_FBK_CFG0, 0x65432100);
+   mt76_wr(dev, MT_VHT_HT_FBK_CFG1, 0xedcba980);
+   mt76_wr(dev, MT_LG_FBK_CFG0, 0xedcba988);
+   if (is_mt76x2(dev))
+   mt76_wr(dev, MT_LG_FBK_CFG1, 0x87872100);
+   else
+   mt76_wr(dev, MT_LG_FBK_CFG1, 0x00872100);
+   }
+
if (changed & BSS_CHANGED_BEACON_INT) {
mt76_rmw_field(dev, MT_BEACON_TIME_CFG,
   MT_BEACON_TIME_CFG_INTVAL,
-- 
1.9.3



[RFC/RFT 0/4] restore some old mt76x0u behaviour

2018-11-08 Thread Stanislaw Gruszka
I can still observe random performance drops on my setup.
Those drops are very rare after applying those:

mt76x02: assure we update gain after scan
mt76x02: run calibration after scanning
mt76x0: do not overwrite other MT_BBP(AGC, 8) fields

but sill happened in Felix tree up to:

79864387b0a0 mt76x0: pci: add DFS support

I did not notice them on linux-4.20 with 3 above fixes
and following patches:

1737618972d6 mt76x0: phy: unify calibration between mt76x0u and mt76x0e
c9540a53b257 mt76x2u: introduce mac workqueue support
9ed42cfca329 mt76x0: use mt76x02_mac_work as stats handler
f6f36ffc6da8 mt76x0: use shared debugfs implementation
1ef5b4893baa mt76: move mt76x02_debugfs in mt76x02-lib module
210ec41d92a0 mt76: move mt76x02_mac_work routine in mt76x02-lib module
9e72f73dc692 mt76x0: pci: add get_survey support
70ef7506c741 mt76x0: phy: improve code readability in initvals_phy.h
30ec3a3558c8 mt76x0: phy: simplify rf configuration routines
37385b8f96bc mt76x0: phy: use proper name convention
7936959c4544 mt76x2u: align channel gain logic to mt76x2 one
0129c6cf5577 mt76x2: align mt76x2 and mt76x2u firmware

Since is hard to reproduce the problem, I was not able to
identify offended commit. However looking at the history there are
planty of commits like:

mt76: move XXX in mt76x02-lib module

which does not only move the code, but change the behavior of
the mt76x0u driver in various ways.

Following patches restore some of old mt76x0u behaviour and
should do correct thing and do not cause any harm on different
setup (AP mode , mt76x2u, mt76x0e), but I did not test them 
in those setups.

Stanislaw Gruszka (4):
  mt76x02: configure basic rates and fallback on STA mode
  mt76x02: reserve wcid 0 for global
  mt76x02: do not set protection on set_rts_threshold callback
  mt76x02: set protection according to ht capabilities

 drivers/net/wireless/mediatek/mt76/mt76x02_mac.c  | 74 ++-
 drivers/net/wireless/mediatek/mt76/mt76x02_mac.h  |  4 +-
 drivers/net/wireless/mediatek/mt76/mt76x02_util.c | 24 +++-
 3 files changed, 84 insertions(+), 18 deletions(-)

-- 
1.9.3



Re: [PATCH] mt76: introduce mt76x02_config_mac_addr_list routine

2018-11-07 Thread Stanislaw Gruszka
On Tue, Nov 06, 2018 at 11:49:12PM +0100, Lorenzo Bianconi wrote:
> Add mt76x02_config_mac_addr_list routine in order to set
> the mac address list supported by the driver. Initialize
> wiphy->addresses/n_addresses for mt76x0e driver
> 
> Signed-off-by: Lorenzo Bianconi 
> ---
>  .../net/wireless/mediatek/mt76/mt76x0/init.c  |  2 ++
>  drivers/net/wireless/mediatek/mt76/mt76x02.h  |  1 +
>  .../net/wireless/mediatek/mt76/mt76x02_util.c | 22 +++
>  .../wireless/mediatek/mt76/mt76x2/pci_init.c  | 17 ++
>  4 files changed, 27 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/init.c 
> b/drivers/net/wireless/mediatek/mt76/mt76x0/init.c
> index e74d476eca24..87b575fe1c74 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt76x0/init.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt76x0/init.c
> @@ -289,6 +289,8 @@ int mt76x0_register_device(struct mt76x02_dev *dev)
>   int ret;
>  
>   mt76x02_init_device(dev);
> + mt76x02_config_mac_addr_list(dev);
> +

Does this work for USB devices ?

Thanks
Stanislaw


Re: [PATCH 2/3] mt76x0: phy: introduce tssi calibration support

2018-11-02 Thread Stanislaw Gruszka
(cc Mediatek.com engineers)

On Mon, Oct 29, 2018 at 10:31:24PM +0100, Lorenzo Bianconi wrote:
> Run mt76x0 tssi calibration process if enabled in eeprom data.
> Perform calibration procedure every 4s

I just checked the Mediatek vendor drivers for both MT7610E (at
github https://github.com/i80s/mtk-sources ) and GPL relesed MT7610U driver
are compiled without MT76x0_TSSI_CAL_COMPENSATION define.
So seems TSSI compensation is not used or tested in vendor driver.

Perhaps Cheng-Hao Luo and Ryder Lee at Mediatek could clarify if this
code is needed and is correct.

Thanks
Stanislaw


> Signed-off-by: Lorenzo Bianconi 
> ---
>  .../net/wireless/mediatek/mt76/mt76x0/phy.c   | 355 +-
>  drivers/net/wireless/mediatek/mt76/mt76x02.h  |   3 +
>  .../wireless/mediatek/mt76/mt76x02_eeprom.h   |   2 +
>  3 files changed, 357 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c 
> b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
> index 830ea6047f10..f0d46e7bb76a 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
> @@ -503,6 +503,345 @@ mt76x0_phy_bbp_set_bw(struct mt76x02_dev *dev, enum 
> nl80211_chan_width width)
>   mt76x02_mcu_function_select(dev, BW_SETTING, bw, false);
>  }
>  
> +static void mt76x0_phy_tssi_dc_calibrate(struct mt76x02_dev *dev)
> +{
> + struct ieee80211_channel *chan = dev->mt76.chandef.chan;
> + u32 val;
> +
> + if (chan->band == NL80211_BAND_5GHZ)
> + mt76x0_rf_clear(dev, MT_RF(0, 67), 0xf);
> +
> + /* bypass ADDA control */
> + mt76_wr(dev, MT_RF_SETTING_0, 0x60002237);
> + mt76_wr(dev, MT_RF_BYPASS_0, 0x);
> +
> + /* bbp sw reset */
> + mt76_set(dev, MT_BBP(CORE, 4), BIT(0));
> + usleep_range(500, 1000);
> + mt76_clear(dev, MT_BBP(CORE, 4), BIT(0));
> +
> + val = (chan->band == NL80211_BAND_5GHZ) ? 0x80055 : 0x80050;
> + mt76_wr(dev, MT_BBP(CORE, 34), val);
> +
> + /* enable TX with DAC0 input */
> + mt76_wr(dev, MT_BBP(TXBE, 6), BIT(31));
> +
> + mt76_poll_msec(dev, MT_BBP(CORE, 34), BIT(4), 0, 200);
> + dev->cal.tssi_dc = mt76_rr(dev, MT_BBP(CORE, 35)) & 0xff;
> +
> + /* stop bypass ADDA */
> + mt76_wr(dev, MT_RF_BYPASS_0, 0);
> + /* stop TX */
> + mt76_wr(dev, MT_BBP(TXBE, 6), 0);
> + /* bbp sw reset */
> + mt76_set(dev, MT_BBP(CORE, 4), BIT(0));
> + usleep_range(500, 1000);
> + mt76_clear(dev, MT_BBP(CORE, 4), BIT(0));
> +
> + if (chan->band == NL80211_BAND_5GHZ)
> + mt76x0_rf_rmw(dev, MT_RF(0, 67), 0xf, 0x4);
> +}
> +
> +static int
> +mt76x0_phy_tssi_adc_calibrate(struct mt76x02_dev *dev, s16 *ltssi,
> +   u8 *info)
> +{
> + struct ieee80211_channel *chan = dev->mt76.chandef.chan;
> + u32 val;
> +
> + val = (chan->band == NL80211_BAND_5GHZ) ? 0x80055 : 0x80050;
> + mt76_wr(dev, MT_BBP(CORE, 34), val);
> +
> + if (!mt76_poll_msec(dev, MT_BBP(CORE, 34), BIT(4), 0, 200)) {
> + mt76_clear(dev, MT_BBP(CORE, 34), BIT(4));
> + return -ETIMEDOUT;
> + }
> +
> + *ltssi = mt76_rr(dev, MT_BBP(CORE, 35)) & 0xff;
> + if (chan->band == NL80211_BAND_5GHZ)
> + *ltssi += 128;
> +
> + /* set packet info#1 mode */
> + mt76_wr(dev, MT_BBP(CORE, 34), 0x80041);
> + info[0] = mt76_rr(dev, MT_BBP(CORE, 35)) & 0xff;
> +
> + /* set packet info#2 mode */
> + mt76_wr(dev, MT_BBP(CORE, 34), 0x80042);
> + info[1] = mt76_rr(dev, MT_BBP(CORE, 35)) & 0xff;
> +
> + /* set packet info#3 mode */
> + mt76_wr(dev, MT_BBP(CORE, 34), 0x80043);
> + info[2] = mt76_rr(dev, MT_BBP(CORE, 35)) & 0xff;
> +
> + return 0;
> +}
> +
> +static u8 mt76x0_phy_get_rf_pa_mode(struct mt76x02_dev *dev,
> + int index, u8 tx_rate)
> +{
> + u32 val, reg;
> +
> + reg = (index == 1) ? MT_RF_PA_MODE_CFG1 : MT_RF_PA_MODE_CFG0;
> + val = mt76_rr(dev, reg);
> + return (val & (3 << (tx_rate * 2))) >> (tx_rate * 2);
> +}
> +
> +static int
> +mt76x0_phy_get_target_power(struct mt76x02_dev *dev, u8 tx_mode,
> + u8 *info, s8 *target_power,
> + s8 *target_pa_power)
> +{
> + u8 tx_rate, cur_power;
> +
> + cur_power = mt76_rr(dev, MT_TX_ALC_CFG_0) & MT_TX_ALC_CFG_0_CH_INIT_0;
> + switch (tx_mode) {
> + case 0:
> + /* cck rates */
> + tx_rate = (info[0] & 0x60) >> 5;
> + if (tx_rate > 3)
> + return -EINVAL;
> +
> + *target_power = cur_power + dev->mt76.rate_power.cck[tx_rate];
> + *target_pa_power = mt76x0_phy_get_rf_pa_mode(dev, 0, tx_rate);
> + break;
> + case 1: {
> + u8 index;
> +
> + /* ofdm rates */
> + tx_rate = (info[0] & 0xf0) >> 4;
> + switch (tx_rate) {
> + case 0xb:
> + index 

Re: [PATCH 2/4] mt76: remove wait argument from mt76x02_mcu_calibrate

2018-11-02 Thread Stanislaw Gruszka
On Thu, Nov 01, 2018 at 06:29:01PM +0100, Felix Fietkau wrote:
> On 2018-10-26 14:00, Stanislaw Gruszka wrote:
> > We always wait for CMD_CALIBRATION_OP mcu message, but wait argument is used
> > for do additioanl MT_MCU_COM_REG0 register operations, which are needed
> > for MMIO devices and we can use mt76_is_mmio() check instead of wait 
> > argument.
> > 
> > Signed-off-by: Stanislaw Gruszka 
> With this commit, I hit the WARN_ON on polling the MT_MCU_COM_REG0
> register on mt76x0e. It seems to me that this register polling should be
> moved out of mt76x02 and into a mt76x2 wrapper function.

I think it would be better to just do mt76x2e check like this:

bool is_mt76x2e = mt76_is_mmio(dev) && is_mt76x2(dev);

if (is_mt76x2e)
mt76_rmw(dev, MT_MCU_COM_REG0, BIT(31), 0);

Then we will not have sparate calibration functions for mt76x2e and
mt76x2u, so code could be easier shared between those.

Thanks
Stanislaw





[PATCH v3 2/2] mt76x02: assure we update gain after scan

2018-11-01 Thread Stanislaw Gruszka
Assure that after we initialize dev->cal.low_gain to -1 this
will cause update gain calibration. Otherwise this might or
might not happen depending on value of second bit of low_gain
and values read from registers in mt76x02_phy_adjust_vga_gain().

Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/mediatek/mt76/mt76x0/phy.c   | 3 ++-
 drivers/net/wireless/mediatek/mt76/mt76x02_util.c | 5 -
 drivers/net/wireless/mediatek/mt76/mt76x2/phy.c   | 3 ++-
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c 
b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
index b2cbe4f19023..7eee91bedacc 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
@@ -736,7 +736,8 @@ mt76x0_phy_update_channel_gain(struct mt76x02_dev *dev)
low_gain = (dev->cal.avg_rssi_all > mt76x02_get_rssi_gain_thresh(dev)) +
   (dev->cal.avg_rssi_all > 
mt76x02_get_low_rssi_gain_thresh(dev));
 
-   gain_change = (dev->cal.low_gain & 2) ^ (low_gain & 2);
+   gain_change = dev->cal.low_gain < 0 ||
+ (dev->cal.low_gain & 2) ^ (low_gain & 2);
dev->cal.low_gain = low_gain;
 
if (!gain_change) {
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c 
b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
index 8a250224fcd7..87ce6a51fb05 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
@@ -555,8 +555,11 @@ void mt76x02_sw_scan_complete(struct ieee80211_hw *hw,
if (mt76_is_mmio(dev))
tasklet_enable(>pre_tbtt_tasklet);
 
-   if (dev->cal.gain_init_done)
+   if (dev->cal.gain_init_done) {
+   /* Restore AGC gain and resume calibration after scanning. */
+   dev->cal.low_gain = -1;
ieee80211_queue_delayed_work(hw, >cal_work, 0);
+   }
 }
 EXPORT_SYMBOL_GPL(mt76x02_sw_scan_complete);
 
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/phy.c 
b/drivers/net/wireless/mediatek/mt76/mt76x2/phy.c
index bbeff9c19997..1b85fb415548 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/phy.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2/phy.c
@@ -289,7 +289,8 @@ void mt76x2_phy_update_channel_gain(struct mt76x02_dev *dev)
low_gain = (dev->cal.avg_rssi_all > mt76x02_get_rssi_gain_thresh(dev)) +
   (dev->cal.avg_rssi_all > 
mt76x02_get_low_rssi_gain_thresh(dev));
 
-   gain_change = (dev->cal.low_gain & 2) ^ (low_gain & 2);
+   gain_change = dev->cal.low_gain < 0 ||
+ (dev->cal.low_gain & 2) ^ (low_gain & 2);
dev->cal.low_gain = low_gain;
 
if (!gain_change) {
-- 
2.7.5



[PATCH v3 1/2] mt76x02: run calibration after scanning

2018-11-01 Thread Stanislaw Gruszka
If we are associated and scanning is performed, sw_scan_complete callback
is done after we get back to operating channel, so we do not perform
queue cal work. Fix this queue cal work from sw_scan_complete().

On mt76x0 we have to restore gain in MT_BBP(AGC, 8) register after
scanning, as it was multiple times modified by channel switch code.
So queue cal work without any delay to set AGC gain value.

Similar like in mt76x2 init AGC gain only when set operating channel
and just check before queuing cal work in sw_scan_complete() if 
initialization was already done.

Fixes: bbd10586f0df ("mt76x0: phy: do not run calibration during channel 
switch")
Signed-off-by: Stanislaw Gruszka 
---
v1 -> v2:
only queue cal work with 0 delay
v2 -> v3:
- do not check for assoc, check init gain was done
- do not init agc gain for any channel in mt76x0

 drivers/net/wireless/mediatek/mt76/mt76x0/phy.c   | 2 +-
 drivers/net/wireless/mediatek/mt76/mt76x02.h  | 1 +
 drivers/net/wireless/mediatek/mt76/mt76x02_phy.c  | 1 +
 drivers/net/wireless/mediatek/mt76/mt76x02_util.c | 3 +++
 4 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c 
b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
index ba3cbceb5dd2..b2cbe4f19023 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
@@ -657,13 +657,13 @@ int mt76x0_phy_set_channel(struct mt76x02_dev *dev,
 
mt76x0_read_rx_gain(dev);
mt76x0_phy_set_chan_bbp_params(dev, rf_bw_band);
-   mt76x02_init_agc_gain(dev);
 
/* enable vco */
mt76x0_rf_set(dev, MT_RF(0, 4), BIT(7));
if (scan)
return 0;
 
+   mt76x02_init_agc_gain(dev);
mt76x0_phy_calibrate(dev, false);
mt76x0_phy_set_txpower(dev);
 
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02.h 
b/drivers/net/wireless/mediatek/mt76/mt76x02.h
index 19489a72fc2b..3a3324eb4a69 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02.h
@@ -57,6 +57,7 @@ struct mt76x02_calibration {
bool tssi_comp_pending;
bool dpd_cal_done;
bool channel_cal_done;
+   bool gain_init_done;
 };
 
 struct mt76x02_dev {
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_phy.c 
b/drivers/net/wireless/mediatek/mt76/mt76x02_phy.c
index 0f1d7b5c9f68..977a8e7e26df 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_phy.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_phy.c
@@ -254,5 +254,6 @@ void mt76x02_init_agc_gain(struct mt76x02_dev *dev)
memcpy(dev->cal.agc_gain_cur, dev->cal.agc_gain_init,
   sizeof(dev->cal.agc_gain_cur));
dev->cal.low_gain = -1;
+   dev->cal.gain_init_done = true;
 }
 EXPORT_SYMBOL_GPL(mt76x02_init_agc_gain);
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c 
b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
index adfc46419b6b..8a250224fcd7 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
@@ -554,6 +554,9 @@ void mt76x02_sw_scan_complete(struct ieee80211_hw *hw,
clear_bit(MT76_SCANNING, >mt76.state);
if (mt76_is_mmio(dev))
tasklet_enable(>pre_tbtt_tasklet);
+
+   if (dev->cal.gain_init_done)
+   ieee80211_queue_delayed_work(hw, >cal_work, 0);
 }
 EXPORT_SYMBOL_GPL(mt76x02_sw_scan_complete);
 
-- 
2.7.5



Re: [PATCH v2] mt76x0: run calibration after scanning

2018-10-31 Thread Stanislaw Gruszka
On Wed, Oct 31, 2018 at 02:11:26PM +0100, Stanislaw Gruszka wrote:
> If we are associated and scanning is performed, sw_scan_complete callback
> is done after we get back to operating channel, so we do not perform
> queue cal work. Fix this queue cal work from sw_scan_complete().
> 
> We have to restore gain in MT_BBP(AGC, 8) register after scanning, as
> it was multiple times modified by channel switch code. So queue cal work
> without  any delay and reset dev->cal.low_gain to assure calibration
> code will AGC gain value.
> 
> Note patch was not tested on mt76x2, but should work and be needed
> fix as well.
> 
> Fixes: bbd10586f0df ("mt76x0: phy: do not run calibration during channel 
> switch")
> Signed-off-by: Stanislaw Gruszka 
> ---
> v1 -> v2:
> only queue cal work with 0 delay an reset dev->cal.low_gain 
> 
>  drivers/net/wireless/mediatek/mt76/mt76x02_util.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c 
> b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
> index 9f083008dbd4..747fd2c9ec45 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
> @@ -553,6 +553,12 @@ void mt76x02_sw_scan_complete(struct ieee80211_hw *hw,
>   clear_bit(MT76_SCANNING, >mt76.state);
>   if (mt76_is_mmio(dev))
>   tasklet_enable(>pre_tbtt_tasklet);
> +
> + if (vif->bss_conf.assoc) {
> + /* Restore AGC gain and resume calibration after scanning. */
> + dev->cal.low_gain = -1;
> + ieee80211_queue_delayed_work(hw, >cal_work, 0);
> + }
>  }
>  EXPORT_SYMBOL_GPL(mt76x02_sw_scan_complete);

I think this can not be sufficient fix. Something like seems
to be needed as wall to force AGC gain write to register:

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c 
b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
index 1af2a1227924..fc4085ef3e16 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
@@ -833,7 +833,7 @@ mt76x0_phy_update_channel_gain(struct mt76x02_dev *dev)
low_gain = (dev->cal.avg_rssi_all > mt76x02_get_rssi_gain_thresh(dev)) +
   (dev->cal.avg_rssi_all > 
mt76x02_get_low_rssi_gain_thresh(dev));
 
-   gain_change = (dev->cal.low_gain & 2) ^ (low_gain & 2);
+   gain_change = log_gain != dev->cal.low_gain;
dev->cal.low_gain = low_gain;

but I do not fully understand this xor logic, so I'm not sure.

Thanks
Stanislaw


[PATCH v2] mt76x0: run calibration after scanning

2018-10-31 Thread Stanislaw Gruszka
If we are associated and scanning is performed, sw_scan_complete callback
is done after we get back to operating channel, so we do not perform
queue cal work. Fix this queue cal work from sw_scan_complete().

We have to restore gain in MT_BBP(AGC, 8) register after scanning, as
it was multiple times modified by channel switch code. So queue cal work
without  any delay and reset dev->cal.low_gain to assure calibration
code will AGC gain value.

Note patch was not tested on mt76x2, but should work and be needed
fix as well.

Fixes: bbd10586f0df ("mt76x0: phy: do not run calibration during channel 
switch")
Signed-off-by: Stanislaw Gruszka 
---
v1 -> v2:
only queue cal work with 0 delay an reset dev->cal.low_gain 

 drivers/net/wireless/mediatek/mt76/mt76x02_util.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c 
b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
index 9f083008dbd4..747fd2c9ec45 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
@@ -553,6 +553,12 @@ void mt76x02_sw_scan_complete(struct ieee80211_hw *hw,
clear_bit(MT76_SCANNING, >mt76.state);
if (mt76_is_mmio(dev))
tasklet_enable(>pre_tbtt_tasklet);
+
+   if (vif->bss_conf.assoc) {
+   /* Restore AGC gain and resume calibration after scanning. */
+   dev->cal.low_gain = -1;
+   ieee80211_queue_delayed_work(hw, >cal_work, 0);
+   }
 }
 EXPORT_SYMBOL_GPL(mt76x02_sw_scan_complete);
 
-- 
2.7.5



[PATCH] mt76x0: do not overwrite other MT_BBP(AGC, 8) fields

2018-10-31 Thread Stanislaw Gruszka
MT_BBP(AGC, 8) register has values depend on band in
mt76x0_bbp_switch_tab, so we should not overwrite other fields
than MT_BBP_AGC_GAIN when setting gain.

This can fix performance issues when connecting to 2.4GHz AP.

Fixes: 4636a2544c3b ("mt76x0: phy: align channel gain logic to mt76x2 one")
Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/mediatek/mt76/mt76x0/phy.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c 
b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
index ba98814ae47d..88dd0aa7e877 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
@@ -690,10 +690,8 @@ static void mt76x0_phy_temp_sensor(struct mt76x02_dev *dev)
 static void mt76x0_phy_set_gain_val(struct mt76x02_dev *dev)
 {
u8 gain = dev->cal.agc_gain_cur[0] - dev->cal.agc_gain_adjust;
-   u32 val = 0x122c << 16 | 0xf2;
 
-   mt76_wr(dev, MT_BBP(AGC, 8),
-   val | FIELD_PREP(MT_BBP_AGC_GAIN, gain));
+   mt76_rmw_field(dev, MT_BBP(AGC, 8), MT_BBP_AGC_GAIN, gain);
 
if ((dev->mt76.chandef.chan->flags & IEEE80211_CHAN_RADAR) &&
!is_mt7630(dev))
-- 
2.7.5



Re: [PATCH] mt76x0: use band parameter for LC calibration

2018-10-30 Thread Stanislaw Gruszka
On Thu, Oct 25, 2018 at 06:18:33PM +0200, Stanislaw Gruszka wrote:
> We use always 1 as band parameter for MCU_CAL_LC, this break 2GHz,
> we should use 0 for this band instead.
> 
> Patch fixes problems happened sometimes when try to associate with 2GHz
> AP and manifest by errors like below:
> 
> [14680.920823] wlan0: authenticate with 18:31:bf:c0:51:b0
> [14681.109506] wlan0: send auth to 18:31:bf:c0:51:b0 (try 1/3)
> [14681.310454] wlan0: send auth to 18:31:bf:c0:51:b0 (try 2/3)
> [14681.518469] wlan0: send auth to 18:31:bf:c0:51:b0 (try 3/3)
> [14681.726499] wlan0: authentication with 18:31:bf:c0:51:b0 timed out
> 
> Fixes: 9aec146d0f6b ("mt76x0: pci: introduce mt76x0_phy_calirate routine")
> Signed-off-by: Stanislaw Gruszka 
> ---
> This is for 4.20.

Actually it is not needed for 4.20, bacause the new calibrate code is
not use for USB in 4.20. It start to be used since:

commit e868a944c55b1f42303ab2941dc1aaada9a3570c
Author: Lorenzo Bianconi 
Date:   Mon Oct 15 14:18:05 2018 +0200

mt76x0: phy: unify calibration between mt76x0u and mt76x0e

Regards
Stanislaw


Re: [PATCH] mt76x0: run calibration after scanning

2018-10-30 Thread Stanislaw Gruszka
On Mon, Oct 29, 2018 at 11:16:53AM +0100, Stanislaw Gruszka wrote:
> If we are associated and scanning is performed , sw_scan_complete callback
> is done after we get back to operating channel, so we do not perform
> phy calibration and queue cal work. Fix this by run calibration from
> sw_scan_complete().
> 
> Fixes: bbd10586f0df ("mt76x0: phy: do not run calibration during channel 
> switch")
> Signed-off-by: Stanislaw Gruszka 
> ---
> This is for 4.20
> 
>  drivers/net/wireless/mediatek/mt76/mt76x0/main.c   | 19 +++
>  drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0.h |  2 ++
>  drivers/net/wireless/mediatek/mt76/mt76x0/pci.c|  2 +-
>  drivers/net/wireless/mediatek/mt76/mt76x0/usb.c|  2 +-
>  4 files changed, 23 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/main.c 
> b/drivers/net/wireless/mediatek/mt76/mt76x0/main.c
> index a803a9b6a4c5..896a9d46bb76 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt76x0/main.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt76x0/main.c
> @@ -78,3 +78,22 @@ int mt76x0_config(struct ieee80211_hw *hw, u32 changed)
>   return ret;
>  }
>  EXPORT_SYMBOL_GPL(mt76x0_config);
> +
> +void mt76x0_sw_scan_complete(struct ieee80211_hw *hw,
> +  struct ieee80211_vif *vif)
> +{
> + struct mt76x02_dev *dev = hw->priv;
> +
> + mutex_lock(>mt76.mutex);
> + if (vif->bss_conf.assoc) {
> + mt76x0_phy_calibrate(dev, false);
> + mt76x0_phy_set_txpower(dev);

Actually I don't think this part is needed, it is done after channel
switch just before we associate, and that seems to be sufficient.

> +
> + ieee80211_queue_delayed_work(dev->mt76.hw, >cal_work,
> +  MT_CALIBRATE_INTERVAL);

We just have to schedule this work, and mt76x2 suffer from similar
issue, so this can be done in mt76x02_sw_scan_complete(). Will
post v2.

Thanks
Stanislaw


Re: [PATCH] mt76x0: run calibration after scanning

2018-10-30 Thread Stanislaw Gruszka
On Mon, Oct 29, 2018 at 04:25:31PM +0200, Kalle Valo wrote:
> Stanislaw Gruszka  writes:
> 
> > If we are associated and scanning is performed , sw_scan_complete callback
> > is done after we get back to operating channel, so we do not perform
> > phy calibration and queue cal work. Fix this by run calibration from
> > sw_scan_complete().
> >
> > Fixes: bbd10586f0df ("mt76x0: phy: do not run calibration during channel 
> > switch")
> > Signed-off-by: Stanislaw Gruszka 
> > ---
> > This is for 4.20
> 
> So what are the symptoms from user's point of view? Is this a
> regression?

We do not perform gain calibration any longer if somebody will
request scan after association. This is formally a regression,
but calibration code changed a lot, so perhaps this can be dropped
for 4.20 and eventually go through -stable if I can confirm
it fixes performance problems.

Thanks
Stanislaw


[PATCH] mt76x0: run calibration after scanning

2018-10-29 Thread Stanislaw Gruszka
If we are associated and scanning is performed , sw_scan_complete callback
is done after we get back to operating channel, so we do not perform
phy calibration and queue cal work. Fix this by run calibration from
sw_scan_complete().

Fixes: bbd10586f0df ("mt76x0: phy: do not run calibration during channel 
switch")
Signed-off-by: Stanislaw Gruszka 
---
This is for 4.20

 drivers/net/wireless/mediatek/mt76/mt76x0/main.c   | 19 +++
 drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0.h |  2 ++
 drivers/net/wireless/mediatek/mt76/mt76x0/pci.c|  2 +-
 drivers/net/wireless/mediatek/mt76/mt76x0/usb.c|  2 +-
 4 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/main.c 
b/drivers/net/wireless/mediatek/mt76/mt76x0/main.c
index a803a9b6a4c5..896a9d46bb76 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/main.c
@@ -78,3 +78,22 @@ int mt76x0_config(struct ieee80211_hw *hw, u32 changed)
return ret;
 }
 EXPORT_SYMBOL_GPL(mt76x0_config);
+
+void mt76x0_sw_scan_complete(struct ieee80211_hw *hw,
+struct ieee80211_vif *vif)
+{
+   struct mt76x02_dev *dev = hw->priv;
+
+   mutex_lock(>mt76.mutex);
+   if (vif->bss_conf.assoc) {
+   mt76x0_phy_calibrate(dev, false);
+   mt76x0_phy_set_txpower(dev);
+
+   ieee80211_queue_delayed_work(dev->mt76.hw, >cal_work,
+MT_CALIBRATE_INTERVAL);
+   }
+   mutex_unlock(>mt76.mutex);
+
+   mt76x02_sw_scan_complete(hw, vif);
+}
+EXPORT_SYMBOL_GPL(mt76x0_sw_scan_complete);
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0.h 
b/drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0.h
index 46629f61673b..d850a6702598 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0.h
@@ -62,6 +62,8 @@ int mt76x0_mac_start(struct mt76x02_dev *dev);
 void mt76x0_mac_stop(struct mt76x02_dev *dev);
 
 int mt76x0_config(struct ieee80211_hw *hw, u32 changed);
+void mt76x0_sw_scan_complete(struct ieee80211_hw *hw,
+struct ieee80211_vif *vif);
 
 /* PHY */
 void mt76x0_phy_init(struct mt76x02_dev *dev);
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c 
b/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
index 757816d2b1ab..854d882f775b 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
@@ -95,7 +95,7 @@ static const struct ieee80211_ops mt76x0e_ops = {
.set_key = mt76x02_set_key,
.conf_tx = mt76x02_conf_tx,
.sw_scan_start = mt76x02_sw_scan,
-   .sw_scan_complete = mt76x02_sw_scan_complete,
+   .sw_scan_complete = mt76x0_sw_scan_complete,
.ampdu_action = mt76x02_ampdu_action,
.sta_rate_tbl_update = mt76x02_sta_rate_tbl_update,
.wake_tx_queue = mt76_wake_tx_queue,
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c 
b/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
index 35b98661632a..9a83d9f62012 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
@@ -151,7 +151,7 @@ static const struct ieee80211_ops mt76x0u_ops = {
.set_key = mt76x02_set_key,
.conf_tx = mt76x02_conf_tx,
.sw_scan_start = mt76x02_sw_scan,
-   .sw_scan_complete = mt76x02_sw_scan_complete,
+   .sw_scan_complete = mt76x0_sw_scan_complete,
.ampdu_action = mt76x02_ampdu_action,
.sta_rate_tbl_update = mt76x02_sta_rate_tbl_update,
.set_rts_threshold = mt76x02_set_rts_threshold,
-- 
2.7.5



Re: [PATCH 4/4] mt76: add support for reporting tx status with skb

2018-10-27 Thread Stanislaw Gruszka
On Thu, Oct 25, 2018 at 06:55:41PM +0200, Felix Fietkau wrote:
> + struct mt76_tx_cb *cb = mt76_tx_skb_cb(skb);
> + u8 done = MT_TX_CB_DMA_DONE | MT_TX_CB_TXS_DONE;
can be "const u8 done = ..."

> +mt76_tx_status_skb_add(struct mt76_dev *dev, struct mt76_wcid *wcid,
> +struct sk_buff *skb)
> +{
> + struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
> + struct mt76_tx_cb *cb = mt76_tx_skb_cb(skb);
> + int pid;
> +
> + if (!wcid || !wcid->sta)
> + return 0;

Due to !wcid->sta check I can not associate with AP on MT7610U,
because we use pid = 0 for assoc frames which are marked
IEEE80211_TX_CTL_REQ_TX_STATUS .
After removing it and leave just !wcid check, things work ok.

Thanks
Stanislaw


[PATCH 4/4] mt76: remove wait argument from mt76x02_mcu_set_radio_state

2018-10-26 Thread Stanislaw Gruszka
Remove wait argument from mt76x02_mcu_set_radio_state and newer wait
for response when sending CMD_POWER_SAVING_OP mcu command.
Note this change behaviour for PCIe devices, but the change is in
align with vendor driver.

Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/mediatek/mt76/mt76x02_mcu.c | 6 ++
 drivers/net/wireless/mediatek/mt76/mt76x02_mcu.h | 3 +--
 drivers/net/wireless/mediatek/mt76/mt76x2/pci_init.c | 2 +-
 drivers/net/wireless/mediatek/mt76/mt76x2/pci_phy.c  | 2 +-
 drivers/net/wireless/mediatek/mt76/mt76x2/usb_init.c | 2 +-
 drivers/net/wireless/mediatek/mt76/mt76x2/usb_mcu.c  | 2 +-
 6 files changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.c 
b/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.c
index 964befc525f3..e91d4deaa8c0 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.c
@@ -151,8 +151,7 @@ int mt76x02_mcu_function_select(struct mt76x02_dev *dev, 
enum mcu_function func,
 }
 EXPORT_SYMBOL_GPL(mt76x02_mcu_function_select);
 
-int mt76x02_mcu_set_radio_state(struct mt76x02_dev *dev, bool on,
-   bool wait_resp)
+int mt76x02_mcu_set_radio_state(struct mt76x02_dev *dev, bool on)
 {
struct {
__le32 mode;
@@ -162,8 +161,7 @@ int mt76x02_mcu_set_radio_state(struct mt76x02_dev *dev, 
bool on,
.level = cpu_to_le32(0),
};
 
-   return mt76_mcu_send_msg(dev, CMD_POWER_SAVING_OP, , sizeof(msg),
-wait_resp);
+   return mt76_mcu_send_msg(dev, CMD_POWER_SAVING_OP, , sizeof(msg), 
false);
 }
 EXPORT_SYMBOL_GPL(mt76x02_mcu_set_radio_state);
 
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.h 
b/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.h
index 5cbf0e7c118c..7e4004120102 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.h
@@ -102,8 +102,7 @@ int mt76x02_mcu_msg_send(struct mt76_dev *mdev, int cmd, 
const void *data,
 int len, bool wait_resp);
 int mt76x02_mcu_function_select(struct mt76x02_dev *dev, enum mcu_function 
func,
u32 val);
-int mt76x02_mcu_set_radio_state(struct mt76x02_dev *dev, bool on,
-   bool wait_resp);
+int mt76x02_mcu_set_radio_state(struct mt76x02_dev *dev, bool on);
 void mt76x02_set_ethtool_fwver(struct mt76x02_dev *dev,
   const struct mt76x02_fw_header *h);
 
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_init.c 
b/drivers/net/wireless/mediatek/mt76/mt76x2/pci_init.c
index f6e8af6432c1..9163481e778c 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2/pci_init.c
@@ -297,7 +297,7 @@ void mt76x2_stop_hardware(struct mt76x02_dev *dev)
 {
cancel_delayed_work_sync(>cal_work);
cancel_delayed_work_sync(>mac_work);
-   mt76x02_mcu_set_radio_state(dev, false, true);
+   mt76x02_mcu_set_radio_state(dev, false);
mt76x2_mac_stop(dev, false);
 }
 
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_phy.c 
b/drivers/net/wireless/mediatek/mt76/mt76x2/pci_phy.c
index 59ef7931df50..da7cd40f56ff 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_phy.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2/pci_phy.c
@@ -305,7 +305,7 @@ int mt76x2_phy_start(struct mt76x02_dev *dev)
 {
int ret;
 
-   ret = mt76x02_mcu_set_radio_state(dev, true, true);
+   ret = mt76x02_mcu_set_radio_state(dev, true);
if (ret)
return ret;
 
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/usb_init.c 
b/drivers/net/wireless/mediatek/mt76/mt76x2/usb_init.c
index a7d591610f16..2e690ef5f2fc 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/usb_init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2/usb_init.c
@@ -300,7 +300,7 @@ void mt76x2u_stop_hw(struct mt76x02_dev *dev)
 
 void mt76x2u_cleanup(struct mt76x02_dev *dev)
 {
-   mt76x02_mcu_set_radio_state(dev, false, false);
+   mt76x02_mcu_set_radio_state(dev, false);
mt76x2u_stop_hw(dev);
mt76u_queues_deinit(>mt76);
mt76u_mcu_deinit(>mt76);
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/usb_mcu.c 
b/drivers/net/wireless/mediatek/mt76/mt76x2/usb_mcu.c
index ca9037af804c..45a95ee3a415 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/usb_mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2/usb_mcu.c
@@ -262,5 +262,5 @@ int mt76x2u_mcu_init(struct mt76x02_dev *dev)
if (err < 0)
return err;
 
-   return mt76x02_mcu_set_radio_state(dev, true, false);
+   return mt76x02_mcu_set_radio_state(dev, true);
 }
-- 
2.7.5



[PATCH 3/4] mt76: remove wait argument from mt76x02_mcu_function_select

2018-10-26 Thread Stanislaw Gruszka
Remove wait argument from mt76x02_mcu_function_select and wait for
response when function is not Q_SELECT, what is the same behaviour
like in vendor driver.

Note this change behaviour for PCIe devices for Q_SELECT function
form wait to no-wait, and for mt76x0u BW_SETTING from no-wait to wait.
But the change is in align with vendor driver.

Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/mediatek/mt76/mt76x0/init.c|  2 +-
 drivers/net/wireless/mediatek/mt76/mt76x0/phy.c |  2 +-
 drivers/net/wireless/mediatek/mt76/mt76x02_mcu.c| 12 +++-
 drivers/net/wireless/mediatek/mt76/mt76x02_mcu.h|  5 ++---
 drivers/net/wireless/mediatek/mt76/mt76x2/pci_mcu.c |  2 +-
 drivers/net/wireless/mediatek/mt76/mt76x2/usb_mcu.c |  2 +-
 6 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/init.c 
b/drivers/net/wireless/mediatek/mt76/mt76x0/init.c
index 64eb6f451541..0889196e79d4 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/init.c
@@ -270,7 +270,7 @@ int mt76x0_init_hardware(struct mt76x02_dev *dev)
return -ETIMEDOUT;
 
mt76x0_reset_csr_bbp(dev);
-   ret = mt76x02_mcu_function_select(dev, Q_SELECT, 1, false);
+   ret = mt76x02_mcu_function_select(dev, Q_SELECT, 1);
if (ret)
return ret;
 
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c 
b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
index 42351179c3cc..e1da7d6eee6b 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
@@ -500,7 +500,7 @@ mt76x0_phy_bbp_set_bw(struct mt76x02_dev *dev, enum 
nl80211_chan_width width)
return ;
}
 
-   mt76x02_mcu_function_select(dev, BW_SETTING, bw, false);
+   mt76x02_mcu_function_select(dev, BW_SETTING, bw);
 }
 
 void mt76x0_phy_set_txpower(struct mt76x02_dev *dev)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.c 
b/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.c
index 254bf3d22d94..964befc525f3 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.c
@@ -132,9 +132,8 @@ int mt76x02_mcu_msg_send(struct mt76_dev *mdev, int cmd, 
const void *data,
 }
 EXPORT_SYMBOL_GPL(mt76x02_mcu_msg_send);
 
-int mt76x02_mcu_function_select(struct mt76x02_dev *dev,
-   enum mcu_function func,
-   u32 val, bool wait_resp)
+int mt76x02_mcu_function_select(struct mt76x02_dev *dev, enum mcu_function 
func,
+   u32 val)
 {
struct {
__le32 id;
@@ -143,9 +142,12 @@ int mt76x02_mcu_function_select(struct mt76x02_dev *dev,
.id = cpu_to_le32(func),
.value = cpu_to_le32(val),
};
+   bool wait = false;
 
-   return mt76_mcu_send_msg(dev, CMD_FUN_SET_OP, , sizeof(msg),
-wait_resp);
+   if (func != Q_SELECT)
+   wait = true;
+
+   return mt76_mcu_send_msg(dev, CMD_FUN_SET_OP, , sizeof(msg), wait);
 }
 EXPORT_SYMBOL_GPL(mt76x02_mcu_function_select);
 
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.h 
b/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.h
index 605cdb44961a..5cbf0e7c118c 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.h
@@ -100,9 +100,8 @@ int mt76x02_mcu_cleanup(struct mt76x02_dev *dev);
 int mt76x02_mcu_calibrate(struct mt76x02_dev *dev, int type, u32 param);
 int mt76x02_mcu_msg_send(struct mt76_dev *mdev, int cmd, const void *data,
 int len, bool wait_resp);
-int mt76x02_mcu_function_select(struct mt76x02_dev *dev,
-   enum mcu_function func,
-   u32 val, bool wait_resp);
+int mt76x02_mcu_function_select(struct mt76x02_dev *dev, enum mcu_function 
func,
+   u32 val);
 int mt76x02_mcu_set_radio_state(struct mt76x02_dev *dev, bool on,
bool wait_resp);
 void mt76x02_set_ethtool_fwver(struct mt76x02_dev *dev,
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_mcu.c 
b/drivers/net/wireless/mediatek/mt76/mt76x2/pci_mcu.c
index b5067ee0b001..03e24ae7f66c 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2/pci_mcu.c
@@ -182,6 +182,6 @@ int mt76x2_mcu_init(struct mt76x02_dev *dev)
if (ret)
return ret;
 
-   mt76x02_mcu_function_select(dev, Q_SELECT, 1, true);
+   mt76x02_mcu_function_select(dev, Q_SELECT, 1);
return 0;
 }
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/usb_mcu.c 
b/drivers/net/wireless/mediatek/mt76/mt76x2/usb_mcu.c
index d6e3e663dd8a..ca9037af804c 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/usb_mcu.c
+++ b/drivers/net/wireless

[PATCH 0/4] mt76: mcu api clenups

2018-10-26 Thread Stanislaw Gruszka
Simplify mcu api and wait for response for mcu commands the same
as vendor driver.

This is on top of:
[PATCH] mt76x0: use band parameter for LC calibration

Stanislaw Gruszka (4):
  mt76: remove mcu_msg_alloc
  mt76: remove wait argument from mt76x02_mcu_calibrate
  mt76: remove wait argument from mt76x02_mcu_function_select
  mt76: remove wait argument from mt76x02_mcu_set_radio_state

 drivers/net/wireless/mediatek/mt76/mt76.h  |  6 +--
 drivers/net/wireless/mediatek/mt76/mt76x0/init.c   |  2 +-
 .../net/wireless/mediatek/mt76/mt76x0/pci_mcu.c|  1 -
 drivers/net/wireless/mediatek/mt76/mt76x0/phy.c| 16 
 drivers/net/wireless/mediatek/mt76/mt76x02_mcu.c   | 43 ++
 drivers/net/wireless/mediatek/mt76/mt76x02_mcu.h   | 16 +++-
 .../net/wireless/mediatek/mt76/mt76x02_usb_mcu.c   | 18 +
 drivers/net/wireless/mediatek/mt76/mt76x2/mcu.c| 22 ---
 drivers/net/wireless/mediatek/mt76/mt76x2/mt76x2.h |  2 +-
 .../net/wireless/mediatek/mt76/mt76x2/pci_init.c   |  2 +-
 .../net/wireless/mediatek/mt76/mt76x2/pci_mcu.c|  3 +-
 .../net/wireless/mediatek/mt76/mt76x2/pci_phy.c| 24 ++--
 drivers/net/wireless/mediatek/mt76/mt76x2/phy.c|  4 +-
 .../net/wireless/mediatek/mt76/mt76x2/usb_init.c   |  2 +-
 .../net/wireless/mediatek/mt76/mt76x2/usb_mcu.c|  4 +-
 .../net/wireless/mediatek/mt76/mt76x2/usb_phy.c| 20 +-
 16 files changed, 85 insertions(+), 100 deletions(-)

-- 
2.7.5



[PATCH 1/4] mt76: remove mcu_msg_alloc

2018-10-26 Thread Stanislaw Gruszka
We almost always use patter like this:

   skb = mt76_mcu_msg_alloc(dev, , sizeof(msg));
   return mt76_mcu_send_msg(dev, skb, CMD_FUN_SET_OP, wait_resp);

This is not needed, we can allocate skb in mcu_send_msg routine.

Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/mediatek/mt76/mt76.h  |  6 ++---
 .../net/wireless/mediatek/mt76/mt76x0/pci_mcu.c|  1 -
 drivers/net/wireless/mediatek/mt76/mt76x02_mcu.c   | 26 ++
 drivers/net/wireless/mediatek/mt76/mt76x02_mcu.h   |  5 ++---
 .../net/wireless/mediatek/mt76/mt76x02_usb_mcu.c   | 18 +--
 drivers/net/wireless/mediatek/mt76/mt76x2/mcu.c| 22 +++---
 .../net/wireless/mediatek/mt76/mt76x2/pci_mcu.c|  1 -
 7 files changed, 35 insertions(+), 44 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h 
b/drivers/net/wireless/mediatek/mt76/mt76.h
index 94ab00b549af..e1d89163ee6b 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -135,9 +135,8 @@ struct mt76_queue {
 };
 
 struct mt76_mcu_ops {
-   struct sk_buff *(*mcu_msg_alloc)(const void *data, int len);
-   int (*mcu_send_msg)(struct mt76_dev *dev, struct sk_buff *skb,
-   int cmd, bool wait_resp);
+   int (*mcu_send_msg)(struct mt76_dev *dev, int cmd, const void *data,
+   int len, bool wait_resp);
int (*mcu_wr_rp)(struct mt76_dev *dev, u32 base,
 const struct mt76_reg_pair *rp, int len);
int (*mcu_rd_rp)(struct mt76_dev *dev, u32 base,
@@ -503,7 +502,6 @@ struct mt76_rx_status {
 #define mt76_wr_rp(dev, ...)   (dev)->mt76.bus->wr_rp(&((dev)->mt76), 
__VA_ARGS__)
 #define mt76_rd_rp(dev, ...)   (dev)->mt76.bus->rd_rp(&((dev)->mt76), 
__VA_ARGS__)
 
-#define mt76_mcu_msg_alloc(dev, ...)   
(dev)->mt76.mcu_ops->mcu_msg_alloc(__VA_ARGS__)
 #define mt76_mcu_send_msg(dev, ...)
(dev)->mt76.mcu_ops->mcu_send_msg(&((dev)->mt76), __VA_ARGS__)
 
 #define mt76_set(dev, offset, val) mt76_rmw(dev, offset, 0, val)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/pci_mcu.c 
b/drivers/net/wireless/mediatek/mt76/mt76x0/pci_mcu.c
index aca0ea318dce..490c1869f2c4 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/pci_mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/pci_mcu.c
@@ -127,7 +127,6 @@ static int mt76x0e_load_firmware(struct mt76x02_dev *dev)
 int mt76x0e_mcu_init(struct mt76x02_dev *dev)
 {
static const struct mt76_mcu_ops mt76x0e_mcu_ops = {
-   .mcu_msg_alloc = mt76x02_mcu_msg_alloc,
.mcu_send_msg = mt76x02_mcu_msg_send,
};
int err;
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.c 
b/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.c
index 1b853bb723fb..550e73f81438 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.c
@@ -21,7 +21,7 @@
 
 #include "mt76x02_mcu.h"
 
-struct sk_buff *mt76x02_mcu_msg_alloc(const void *data, int len)
+static struct sk_buff *mt76x02_mcu_msg_alloc(const void *data, int len)
 {
struct sk_buff *skb;
 
@@ -32,7 +32,6 @@ struct sk_buff *mt76x02_mcu_msg_alloc(const void *data, int 
len)
 
return skb;
 }
-EXPORT_SYMBOL_GPL(mt76x02_mcu_msg_alloc);
 
 static struct sk_buff *
 mt76x02_mcu_get_response(struct mt76x02_dev *dev, unsigned long expires)
@@ -80,16 +79,18 @@ mt76x02_tx_queue_mcu(struct mt76x02_dev *dev, enum 
mt76_txq_id qid,
return 0;
 }
 
-int mt76x02_mcu_msg_send(struct mt76_dev *mdev, struct sk_buff *skb,
-int cmd, bool wait_resp)
+int mt76x02_mcu_msg_send(struct mt76_dev *mdev, int cmd, const void *data,
+int len, bool wait_resp)
 {
struct mt76x02_dev *dev = container_of(mdev, struct mt76x02_dev, mt76);
unsigned long expires = jiffies + HZ;
+   struct sk_buff *skb;
int ret;
u8 seq;
 
+   skb = mt76x02_mcu_msg_alloc(data, len);
if (!skb)
-   return -EINVAL;
+   return -ENOMEM;
 
mutex_lock(>mmio.mcu.mutex);
 
@@ -135,7 +136,6 @@ int mt76x02_mcu_function_select(struct mt76x02_dev *dev,
enum mcu_function func,
u32 val, bool wait_resp)
 {
-   struct sk_buff *skb;
struct {
__le32 id;
__le32 value;
@@ -144,15 +144,14 @@ int mt76x02_mcu_function_select(struct mt76x02_dev *dev,
.value = cpu_to_le32(val),
};
 
-   skb = mt76_mcu_msg_alloc(dev, , sizeof(msg));
-   return mt76_mcu_send_msg(dev, skb, CMD_FUN_SET_OP, wait_resp);
+   return mt76_mcu_send_msg(dev, CMD_FUN_SET_OP, , sizeof(msg),
+wait_resp);
 }
 EXPORT_SYMBOL_GPL(mt76x02_mcu_function_select);
 
 int mt76x02_mcu_set_radio_state(struct mt76x02_dev *dev, bool on,
   

[PATCH 2/4] mt76: remove wait argument from mt76x02_mcu_calibrate

2018-10-26 Thread Stanislaw Gruszka
We always wait for CMD_CALIBRATION_OP mcu message, but wait argument is used
for do additioanl MT_MCU_COM_REG0 register operations, which are needed
for MMIO devices and we can use mt76_is_mmio() check instead of wait argument.

Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/mediatek/mt76/mt76x0/phy.c| 14 ++
 drivers/net/wireless/mediatek/mt76/mt76x02_mcu.c   |  7 +++
 drivers/net/wireless/mediatek/mt76/mt76x02_mcu.h   |  3 +--
 drivers/net/wireless/mediatek/mt76/mt76x2/mt76x2.h |  2 +-
 .../net/wireless/mediatek/mt76/mt76x2/pci_phy.c| 22 +++---
 drivers/net/wireless/mediatek/mt76/mt76x2/phy.c|  4 ++--
 .../net/wireless/mediatek/mt76/mt76x2/usb_phy.c| 20 ++--
 7 files changed, 34 insertions(+), 38 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c 
b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
index ca24b5716b58..42351179c3cc 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
@@ -529,9 +529,8 @@ void mt76x0_phy_calibrate(struct mt76x02_dev *dev, bool 
power_on)
return;
 
if (power_on) {
-   mt76x02_mcu_calibrate(dev, MCU_CAL_R, 0, false);
-   mt76x02_mcu_calibrate(dev, MCU_CAL_VCO, chan->hw_value,
- false);
+   mt76x02_mcu_calibrate(dev, MCU_CAL_R, 0);
+   mt76x02_mcu_calibrate(dev, MCU_CAL_VCO, chan->hw_value);
usleep_range(10, 20);
/* XXX: tssi */
}
@@ -554,14 +553,14 @@ void mt76x0_phy_calibrate(struct mt76x02_dev *dev, bool 
power_on)
val = 0x600;
}
 
-   mt76x02_mcu_calibrate(dev, MCU_CAL_FULL, val, false);
+   mt76x02_mcu_calibrate(dev, MCU_CAL_FULL, val);
msleep(350);
-   mt76x02_mcu_calibrate(dev, MCU_CAL_LC, is_5ghz, false);
+   mt76x02_mcu_calibrate(dev, MCU_CAL_LC, is_5ghz);
usleep_range(15000, 2);
 
mt76_wr(dev, MT_BBP(IBI, 9), reg_val);
mt76_wr(dev, MT_TX_ALC_CFG_0, tx_alc);
-   mt76x02_mcu_calibrate(dev, MCU_CAL_RXDCOC, 1, false);
+   mt76x02_mcu_calibrate(dev, MCU_CAL_RXDCOC, 1);
 }
 EXPORT_SYMBOL_GPL(mt76x0_phy_calibrate);
 
@@ -698,8 +697,7 @@ static void mt76x0_phy_temp_sensor(struct mt76x02_dev *dev)
 
if (abs(val - dev->cal.temp_vco) > 20) {
mt76x02_mcu_calibrate(dev, MCU_CAL_VCO,
- dev->mt76.chandef.chan->hw_value,
- false);
+ dev->mt76.chandef.chan->hw_value);
dev->cal.temp_vco = val;
}
if (abs(val - dev->cal.temp) > 30) {
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.c 
b/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.c
index 550e73f81438..254bf3d22d94 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.c
@@ -165,8 +165,7 @@ int mt76x02_mcu_set_radio_state(struct mt76x02_dev *dev, 
bool on,
 }
 EXPORT_SYMBOL_GPL(mt76x02_mcu_set_radio_state);
 
-int mt76x02_mcu_calibrate(struct mt76x02_dev *dev, int type,
- u32 param, bool wait)
+int mt76x02_mcu_calibrate(struct mt76x02_dev *dev, int type, u32 param)
 {
struct {
__le32 id;
@@ -177,7 +176,7 @@ int mt76x02_mcu_calibrate(struct mt76x02_dev *dev, int type,
};
int ret;
 
-   if (wait)
+   if (mt76_is_mmio(dev))
mt76_rmw(dev, MT_MCU_COM_REG0, BIT(31), 0);
 
ret = mt76_mcu_send_msg(dev, CMD_CALIBRATION_OP, , sizeof(msg),
@@ -185,7 +184,7 @@ int mt76x02_mcu_calibrate(struct mt76x02_dev *dev, int type,
if (ret)
return ret;
 
-   if (wait &&
+   if (mt76_is_mmio(dev) &&
WARN_ON(!mt76_poll_msec(dev, MT_MCU_COM_REG0,
BIT(31), BIT(31), 100)))
return -ETIMEDOUT;
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.h 
b/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.h
index a3aee579d42c..605cdb44961a 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mcu.h
@@ -97,8 +97,7 @@ struct mt76x02_patch_header {
 };
 
 int mt76x02_mcu_cleanup(struct mt76x02_dev *dev);
-int mt76x02_mcu_calibrate(struct mt76x02_dev *dev, int type,
- u32 param, bool wait);
+int mt76x02_mcu_calibrate(struct mt76x02_dev *dev, int type, u32 param);
 int mt76x02_mcu_msg_send(struct mt76_dev *mdev, int cmd, const void *data,
 int len, bool wait_resp);
 int mt76x02_mcu_function_select(struct mt76x02_dev *dev,
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/mt76x2.h 
b/drivers/net/wireless/mediatek/mt76/mt76x2/mt76x2.h
index e5846a85d6ab..b259e4b50f1e 100644
--- a/drivers/net/wireless/mediate

[PATCH] mt76x0: use band parameter for LC calibration

2018-10-25 Thread Stanislaw Gruszka
We use always 1 as band parameter for MCU_CAL_LC, this break 2GHz,
we should use 0 for this band instead.

Patch fixes problems happened sometimes when try to associate with 2GHz
AP and manifest by errors like below:

[14680.920823] wlan0: authenticate with 18:31:bf:c0:51:b0
[14681.109506] wlan0: send auth to 18:31:bf:c0:51:b0 (try 1/3)
[14681.310454] wlan0: send auth to 18:31:bf:c0:51:b0 (try 2/3)
[14681.518469] wlan0: send auth to 18:31:bf:c0:51:b0 (try 3/3)
[14681.726499] wlan0: authentication with 18:31:bf:c0:51:b0 timed out

Fixes: 9aec146d0f6b ("mt76x0: pci: introduce mt76x0_phy_calirate routine")
Signed-off-by: Stanislaw Gruszka 
---
This is for 4.20.

 drivers/net/wireless/mediatek/mt76/mt76x0/phy.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c 
b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
index c734987a344c..ca24b5716b58 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
@@ -522,6 +522,7 @@ void mt76x0_phy_set_txpower(struct mt76x02_dev *dev)
 void mt76x0_phy_calibrate(struct mt76x02_dev *dev, bool power_on)
 {
struct ieee80211_channel *chan = dev->mt76.chandef.chan;
+   int is_5ghz = (chan->band == NL80211_BAND_5GHZ) ? 1 : 0;
u32 val, tx_alc, reg_val;
 
if (is_mt7630(dev))
@@ -542,7 +543,7 @@ void mt76x0_phy_calibrate(struct mt76x02_dev *dev, bool 
power_on)
reg_val = mt76_rr(dev, MT_BBP(IBI, 9));
mt76_wr(dev, MT_BBP(IBI, 9), 0xff7e);
 
-   if (chan->band == NL80211_BAND_5GHZ) {
+   if (is_5ghz) {
if (chan->hw_value < 100)
val = 0x701;
else if (chan->hw_value < 140)
@@ -555,7 +556,7 @@ void mt76x0_phy_calibrate(struct mt76x02_dev *dev, bool 
power_on)
 
mt76x02_mcu_calibrate(dev, MCU_CAL_FULL, val, false);
msleep(350);
-   mt76x02_mcu_calibrate(dev, MCU_CAL_LC, 1, false);
+   mt76x02_mcu_calibrate(dev, MCU_CAL_LC, is_5ghz, false);
usleep_range(15000, 2);
 
mt76_wr(dev, MT_BBP(IBI, 9), reg_val);
-- 
2.7.5



Re: [PATCH] iwlwifi: pcie: align licensing to dual GPL/BSD

2018-10-24 Thread Stanislaw Gruszka
On Wed, Oct 24, 2018 at 09:04:36AM +0200, Johannes Berg wrote:
> From: Johannes Berg 
> 
> These files have a long history of code changes, but analysing
> the remaining code leads to having only a few changes that are
> not already owned by Intel, notably from
>  - Andy Lutomirski 
>  - Joonwoo Park 
>  - Kirtika Ruchandani 
>  - Rajat Jain 
>  - Stanislaw Gruszka 
> remaining in the code today.
> 
> Note that
>  - I myself was working for Intel and for any possibly code
>that might be before my employment there give permission
>  - Wizery employees were working for Intel
> 
> More specifically, we identified the following commits that
> (partially may) remain today:
> 
> 25c03d8e8c13 Joonwoo Park   ("iwlwifi: do not 
> schedule tasklet when rcv unused irq")
> f36d04abe684 Stanislaw Gruszka("iwlwifi: use 
> dma_alloc_coherent")
> 387f3381f732 Stanislaw Gruszka("iwlwifi: fix dma 
> mappings and skbs leak")
> 2624e96ce16b Stanislaw Gruszka("iwlwifi: fix 
> possible data overwrite in hcmd callback")
> bfe4b80e9f73 Stanislaw Gruszka("iwlwifi: always 
> check if got h/w access before write")
> d536c32b45d2 Andy Lutomirski  ("iwlwifi: pcie: log 
> when waking the NIC for hcmd submission fails")
> a6d24fad00d9 Rajat Jain("iwlwifi: pcie: dump 
> registers when HW becomes inaccessible")
> fb12777ab59b Kirtika Ruchandani  ("iwlwifi: Add more 
> call-sites for pcie reg dumper")
> 3a73a30049f2 Stanislaw Gruszka("iwlwifi: cleanup/fix 
> memory barriers")
> aa5affbacb24 Stanislaw Gruszka("iwlwifi: dump stack 
> when fail to gain access to the device")
> 
> Align the licenses with their permission to clean up and to
> make it all identical.
> 
> CC: Joonwoo Park 
> CC: Stanislaw Gruszka 
> CC: Andy Lutomirski 
> CC: Rajat Jain 
> CC: Kirtika Ruchandani 
> Acked-by: Johannes Berg 
> Signed-off-by: Johannes Berg 

Acked-by: Stanislaw Gruszka 


Re: [PATCH v4 4/8] rt2800: fix registers init for MT7620

2018-10-20 Thread Stanislaw Gruszka
On Fri, Oct 19, 2018 at 04:21:09PM +0200, Tom Psyborg wrote:
> On 19/10/2018, Stanislaw Gruszka  wrote:
> >
> > I tried to do this, but somehow after update BUILD1 image into device
> > my configuration was wiped out :-( and I have to reconfigure the
> > device now. Anyway I'm going to test and provide dmesg , but this
> > will take some time.
> >
> > Regards
> > Stanislaw
> >
> 
> that's because these builds were done on 4.4 that i had in my system
> and there are config differences between these builds and current
> snapshot. to save you time i need only bootlogs not wifi performance
> tests.

So, there is no diffrence in dmesg and device is recognized as RT6352.
I atteched both dmesg's for the record.

Regards
Stanislaw

[0.00] Linux version 4.9.73 (ubuntu@ubuntu) (gcc version 5.5.0 (OpenWrt 
GCC 5.5.0 r5682-b153dbf) ) #0 Fri Jan 5 10:59:59 2018
[0.00] Board has DDR1
[0.00] Analog PMU set to hw control
[0.00] Digital PMU set to hw control
[0.00] SoC Type: MediaTek MT7620N ver:2 eco:6
[0.00] bootconsole [early0] enabled
[0.00] CPU0 revision is: 00019650 (MIPS 24KEc)
[0.00] MIPS: machine is Nexx WT3020 (8M)
[0.00] Determined physical RAM map:
[0.00]  memory: 0400 @  (usable)
[0.00] Initrd not found or empty - disabling initrd
[0.00] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
[0.00] Primary data cache 32kB, 4-way, PIPT, no aliases, linesize 32 
bytes
[0.00] Zone ranges:
[0.00]   Normal   [mem 0x-0x03ff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x-0x03ff]
[0.00] Initmem setup node 0 [mem 0x-0x03ff]
[0.00] On node 0 totalpages: 16384
[0.00] free_area_init_node: node 0, pgdat 803af724, node_mem_map 
8120
[0.00]   Normal zone: 128 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 16384 pages, LIFO batch:3
[0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[0.00] pcpu-alloc: [0] 0 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 16256
[0.00] Kernel command line: console=ttyS0,57600 
rootfstype=squashfs,jffs2
[0.00] PID hash table entries: 256 (order: -2, 1024 bytes)
[0.00] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[0.00] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Writing ErrCtl register=0003f290
[0.00] Readback ErrCtl register=0003f290
[0.00] Memory: 60708K/65536K available (2912K kernel code, 144K rwdata, 
720K rodata, 184K init, 210K bss, 4828K reserved, 0K cma-reserved)
[0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[0.00] NR_IRQS:256
[0.00] CPU Clock: 580MHz
[0.00] clocksource: systick: mask: 0x max_cycles: 0x, 
max_idle_ns: 583261500 ns
[0.00] systick: enable autosleep mode
[0.00] systick: running - mult: 214748, shift: 32
[0.00] clocksource: MIPS: mask: 0x max_cycles: 0x, 
max_idle_ns: 6590553264 ns
[0.11] sched_clock: 32 bits at 290MHz, resolution 3ns, wraps every 
7405115902ns
[0.015451] Calibrating delay loop... 385.84 BogoMIPS (lpj=1929216)
[0.080614] pid_max: default: 32768 minimum: 301
[0.089921] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.102950] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.122146] clocksource: jiffies: mask: 0x max_cycles: 0x, 
max_idle_ns: 1911260446275 ns
[0.141623] futex hash table entries: 256 (order: -1, 3072 bytes)
[0.153770] pinctrl core: initialized pinctrl subsystem
[0.164734] NET: Registered protocol family 16
[0.193594] rt2880_gpio 1600.gpio: registering 24 gpios
[0.204618] rt2880_gpio 1600.gpio: registering 24 irq handlers
[0.217201] rt2880_gpio 1660.gpio: registering 32 gpios
[0.228189] rt2880_gpio 1660.gpio: registering 32 irq handlers
[0.240725] rt2880_gpio 1688.gpio: registering 1 gpios
[0.251533] rt2880_gpio 1688.gpio: registering 1 irq handlers
[0.267228] clocksource: Switched to clocksource systick
[0.278917] NET: Registered protocol family 2
[0.288380] TCP established hash table entries: 1024 (order: 0, 4096 bytes)
[0.302151] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
[0.314747] TCP: Hash tables configured (established 1024 bind 1024)
[0.327466] UDP hash table entries: 256 (order: 0, 4096 bytes)
[0.339003] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[0.351666] NET: Registered protocol family 1
[0.360231] PCI: CLS 0 bytes, defaul

MT7630E firmware and Mediatek support

2018-10-19 Thread Stanislaw Gruszka
Hello MediaTek

I plan to submit this firmware to linux-firwmare git tree:
https://github.com/neurobin/MT7630E/tree/release/firmware/Wi-FI
to add support for MT7630E with mt76/mt76x0 driver, is this ok ?

I would also ask if Mediatek can provide some support for us
to have their WiFi products working better with mainline linux?

Some example things that Mediatek could do that come in mind
and I would like to request are:

- Testing and reviewing our patches.
- Assign support engineer for us who could answer questions about
  low level configuration and help solving problems.
- Financing to Felix for doing maintainace and development work of
  mt76 driver.
- Provide newer/better version of Mediatek driver/SDK for reference.
- Provide hardware not yet released on the market for adding
  support for new chips.
- Provide documentation.

If any of that could be done by Mediatek would be great.

You can answer me off-list, if you prefer that.

Thanks
Stanislaw


Re: [PATCH v4 4/8] rt2800: fix registers init for MT7620

2018-10-19 Thread Stanislaw Gruszka
On Wed, Oct 17, 2018 at 03:25:58PM +0200, Tom Psyborg wrote:
> On 16/10/2018, Stanislaw Gruszka  wrote:
> > On Tue, Oct 16, 2018 at 01:32:18PM +0200, Tom Psyborg wrote:
> >> I am sending you two builds privately so please check if there are any
> >> differences between the two builds and report back. Thanks.
> >
> > I extracted rt2800lib.ko module from provided images, did disassembly via:
> >
> > ./staging_dir/toolchain-mipsel_24kc_gcc-7.3.0_musl/bin/mipsel-openwrt-linux-objdump
> > \
> >  -d -r --prefix-addresses ~/rt2800lib-BUILDn.ko  > ~/BUILDn.dump.txt
> >
> > command and compered disassembled code. Here is difference:
> >
> > $ diff -up  BUILD1.dump.txt BUILD2.dump.txt
> > --- BUILD1.dump.txt 2018-10-16 16:40:34.834220838 +0200
> > +++ BUILD2.dump.txt 2018-10-16 16:40:40.187219211 +0200
> > @@ -1,5 +1,5 @@
> >
> > -/home/stasiu/rt2800lib-BUILD1.ko: file format elf32-tradlittlemips
> > +/home/stasiu/rt2800lib-BUILD2.ko: file format elf32-tradlittlemips
> >
> >
> >  Disassembly of section .text:
> > @@ -9374,7 +9374,7 @@ Disassembly of section .text:
> >  7f80  jalr  v0
> >  7f84  move  a0,s0
> >  7f88  lhu   v1,732(s0)
> > -7f8c  liv0,21392
> > +7f8c  liv0,25426
> >  7f90  bne   v1,v0,810c
> > 
> >  7f94  lia2,1025
> >  7f98  lwv0,4(s0)
> >
> > There is no difference in init_registers (which is inlined in
> > rt2800_enable_radio). The only difference is in some number
> > rt2800_clear_beacon() function.
> >
> > Regards
> > Stanislaw
> >
> 
> i meant you try it on your nexx device. and post dmesg if you can boot them

I tried to do this, but somehow after update BUILD1 image into device
my configuration was wiped out :-( and I have to reconfigure the
device now. Anyway I'm going to test and provide dmesg , but this
will take some time.

Regards
Stanislaw


Re: [PATCH 1/2] mt76: mt76x0: reduce duplication in setting rf bandwidth parameters

2018-10-19 Thread Stanislaw Gruszka
On Thu, Oct 18, 2018 at 04:16:44PM +0200, Felix Fietkau wrote:
> Remove initval table with duplicated registers and driver specific flags
> in favor of a function that sets the registers directly

There are few problems with this patch: MT_RF(7, 77) is missing and
band is not taken directly from chandef but overwriteen in
'rf_band = mt76x0_frequency_plan[i].band' . But even after fixing that
I can not make MT7610U associate with AP on 5GHz. So please drop this
patch.

Thanks
Stanislaw



[PATCH v2] mt76x0: antenna select corrections

2018-10-18 Thread Stanislaw Gruszka
Update mt76x0_phy_ant_select() to conform vendor driver, most notably
add dual antenna mode support, read configuration from EEPROM and
move ant select out of channel config to init phase. Plus small MT7630E
quirk for MT_CMB_CTRL register which vendor driver dedicated to this
chip do.

This make MT7630E workable with mt76x0e driver and do not cause any
problems on MT7610U for me.

Signed-off-by: Stanislaw Gruszka 
Acked-by: Lorenzo Bianconi 
---
v1 -> v2:
- fix clear of BIT(14) instead of BIT(15) in MT_CMB_CTRL
- do not clear BIT(1) in MT_COEXCFG3

 drivers/net/wireless/mediatek/mt76/mt76x0/phy.c| 52 --
 .../net/wireless/mediatek/mt76/mt76x02_eeprom.h| 10 ++---
 2 files changed, 44 insertions(+), 18 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c 
b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
index 37e1ead1dc85..143cbe6d7899 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
@@ -431,21 +431,47 @@ int mt76x0_phy_wait_bbp_ready(struct mt76x02_dev *dev)
 
 static void mt76x0_phy_ant_select(struct mt76x02_dev *dev)
 {
-   struct ieee80211_channel *chan = dev->mt76.chandef.chan;
-
-   /* single antenna mode */
-   if (chan->band == NL80211_BAND_2GHZ) {
-   mt76_rmw(dev, MT_COEXCFG3,
-BIT(5) | BIT(4) | BIT(3) | BIT(2), BIT(1));
-   mt76_rmw(dev, MT_WLAN_FUN_CTRL, BIT(5), BIT(6));
+   u16 ee_ant = mt76x02_eeprom_get(dev, MT_EE_ANTENNA);
+   u16 nic_conf2 = mt76x02_eeprom_get(dev, MT_EE_NIC_CONF_2);
+   u32 wlan, coex3, cmb;
+   bool ant_div;
+
+   wlan = mt76_rr(dev, MT_WLAN_FUN_CTRL);
+   cmb = mt76_rr(dev, MT_CMB_CTRL);
+   coex3 = mt76_rr(dev, MT_COEXCFG3);
+
+   cmb   &= ~(BIT(14) | BIT(12));
+   wlan  &= ~(BIT(6) | BIT(5));
+   coex3 &= ~GENMASK(5, 2);
+
+   if (ee_ant & MT_EE_ANTENNA_DUAL) {
+   /* dual antenna mode */
+   ant_div = !(nic_conf2 & MT_EE_NIC_CONF_2_ANT_OPT) &&
+ (nic_conf2 & MT_EE_NIC_CONF_2_ANT_DIV);
+   if (ant_div)
+   cmb |= BIT(12);
+   else
+   coex3 |= BIT(4);
+   coex3 |= BIT(3);
+   if (dev->mt76.cap.has_2ghz)
+   wlan |= BIT(6);
} else {
-   mt76_rmw(dev, MT_COEXCFG3, BIT(5) | BIT(2),
-BIT(4) | BIT(3));
-   mt76_clear(dev, MT_WLAN_FUN_CTRL,
-  BIT(6) | BIT(5));
+   /* sigle antenna mode */
+   if (dev->mt76.cap.has_5ghz) {
+   coex3 |= BIT(3) | BIT(4);
+   } else {
+   wlan |= BIT(6);
+   coex3 |= BIT(1);
+   }
}
-   mt76_clear(dev, MT_CMB_CTRL, BIT(14) | BIT(12));
+
+   if (is_mt7630(dev))
+   cmb |= BIT(14) | BIT(11);
+
+   mt76_wr(dev, MT_WLAN_FUN_CTRL, wlan);
+   mt76_wr(dev, MT_CMB_CTRL, cmb);
mt76_clear(dev, MT_COEXCFG0, BIT(2));
+   mt76_wr(dev, MT_COEXCFG3, coex3);
 }
 
 static void
@@ -612,7 +638,6 @@ int mt76x0_phy_set_channel(struct mt76x02_dev *dev,
mt76x02_phy_set_bw(dev, chandef->width, ch_group_index);
mt76x02_phy_set_band(dev, chandef->chan->band,
 ch_group_index & 1);
-   mt76x0_phy_ant_select(dev);
 
mt76_rmw(dev, MT_EXT_CCA_CFG,
 (MT_EXT_CCA_CFG_CCA0 |
@@ -795,6 +820,7 @@ void mt76x0_phy_init(struct mt76x02_dev *dev)
 {
INIT_DELAYED_WORK(>cal_work, mt76x0_phy_calibration_work);
 
+   mt76x0_phy_ant_select(dev);
mt76x0_phy_rf_init(dev);
mt76x02_phy_set_rxpath(dev);
mt76x02_phy_set_txdac(dev);
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_eeprom.h 
b/drivers/net/wireless/mediatek/mt76/mt76x02_eeprom.h
index b3ec74835d10..1de041590050 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_eeprom.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_eeprom.h
@@ -25,6 +25,7 @@ enum mt76x02_eeprom_field {
MT_EE_VERSION = 0x002,
MT_EE_MAC_ADDR =0x004,
MT_EE_PCI_ID =  0x00A,
+   MT_EE_ANTENNA = 0x022,
MT_EE_NIC_CONF_0 =  0x034,
MT_EE_NIC_CONF_1 =  0x036,
MT_EE_COUNTRY_REGION_5GHZ = 0x038,
@@ -104,6 +105,8 @@ enum mt76x02_eeprom_field {
__MT_EE_MAX
 };
 
+#define MT_EE_ANTENNA_DUAL BIT(15)
+
 #define MT_EE_NIC_CONF_0_RX_PATH   GENMASK(3, 0)
 #define MT_EE_NIC_CONF_0_TX_PATH   GENMASK(7, 4)
 #define MT_EE_NIC_CONF_0_PA_TYPE   GENMASK(9, 8)
@@ -118,12 +121,9 @@ enum mt76x02_eeprom_field {
 #define MT_EE_NIC_CONF_1_LNA_EXT_5G   

Re: [PATCH] mt76x0: antenna select corrections

2018-10-18 Thread Stanislaw Gruszka
On Thu, Oct 18, 2018 at 11:40:56AM +0200, Stanislaw Gruszka wrote:
> On GPL realeased driver for MT7610U ( mt7610u_wifi_sta_v3002_dpo_2013091 )
> it's like this:
> 
> CoexCfg3 &= ~(BIT5 | BIT4 | BIT3 | BIT2 | BIT1);


> Does your SDK do something diffrent ?
Ok I can see:

CoexCfg3 &= ~(BIT5 | BIT4 | BIT3 | BIT2);

in
https://github.com/i80s/mtk-sources 
which is newer version of the driver, so preasumely BIT1
should not be cleared. Will fix that in the patch.

Thanks
Stanislaw


Re: [PATCH] mt76x0: antenna select corrections

2018-10-18 Thread Stanislaw Gruszka
On Thu, Oct 18, 2018 at 11:28:19AM +0200, Lorenzo Bianconi wrote:
> > On Thu, Oct 18, 2018 at 11:13:36AM +0200, Lorenzo Bianconi wrote:
> > > >  static void mt76x0_phy_ant_select(struct mt76x02_dev *dev)
> > > >  {
> > > > -   struct ieee80211_channel *chan = dev->mt76.chandef.chan;
> > > > -
> > > > -   /* single antenna mode */
> > > > -   if (chan->band == NL80211_BAND_2GHZ) {
> > > > -   mt76_rmw(dev, MT_COEXCFG3,
> > > > -BIT(5) | BIT(4) | BIT(3) | BIT(2), BIT(1));
> > > > -   mt76_rmw(dev, MT_WLAN_FUN_CTRL, BIT(5), BIT(6));
> > > > +   u16 ee_ant = mt76x02_eeprom_get(dev, MT_EE_ANTENNA);
> > > > +   u16 nic_conf2 = mt76x02_eeprom_get(dev, MT_EE_NIC_CONF_2);
> > > > +   u32 wlan, coex3, cmb;
> > > > +   bool ant_div;
> > > > +
> > > > +   wlan = mt76_rr(dev, MT_WLAN_FUN_CTRL);
> > > > +   cmb = mt76_rr(dev, MT_CMB_CTRL);
> > > > +   coex3 = mt76_rr(dev, MT_COEXCFG3);
> > > > +
> > > > +   cmb   &= ~(BIT(15) | BIT(12));
> > > 
> > > I guess should be BIT(14) here (at least for single antenna mode)
> > 
> > Yes , I will fix it.
> > 
> > > > +   coex3 &= ~GENMASK(5, 1);
> > > 
> > > according to vendor sdk BIT(1) should not cleared if device supports 5GHz 
> > > band
> > > (signle antenna mode)
> > 
> > It is set below for that case:
> 
> it is set just if the device does not support 5GHz band but it is cleared in
> the other case (and sdk driver does not clear it in that case, do not know if
> it does a real difference)

On GPL realeased driver for MT7610U ( mt7610u_wifi_sta_v3002_dpo_2013091 )
it's like this:

CoexCfg3 &= ~(BIT5 | BIT4 | BIT3 | BIT2 | BIT1);



{
if (WMODE_CAP_5G(pAd->CommonCfg.PhyMode))
{
CoexCfg3 |= (BIT3 | BIT4); /* 0x4C[3]=1, 0x4C[4]=1 */
}
else
{
WlanFunCtrl |= BIT6; /* 0x80[6]=1 */
CoexCfg3 |= BIT1; /* 0x4C[1]=1 */
}
DBGPRINT(RT_DEBUG_ERROR, ("%s - Single antenna mode\n", 
__FUNCTION__));
}

Which I belive is reflected in my patch in this parts:

coex3 &= ~GENMASK(5, 1);



if (dev->mt76.cap.has_5ghz) {
coex3 |= BIT(3) | BIT(4);
} else {
wlan |= BIT(6);
coex3 |= BIT(1);
}

Does your SDK do something diffrent ?

Thanks
Stanislaw


Re: [PATCH] mt76x0: antenna select corrections

2018-10-18 Thread Stanislaw Gruszka
On Thu, Oct 18, 2018 at 11:13:36AM +0200, Lorenzo Bianconi wrote:
> >  static void mt76x0_phy_ant_select(struct mt76x02_dev *dev)
> >  {
> > -   struct ieee80211_channel *chan = dev->mt76.chandef.chan;
> > -
> > -   /* single antenna mode */
> > -   if (chan->band == NL80211_BAND_2GHZ) {
> > -   mt76_rmw(dev, MT_COEXCFG3,
> > -BIT(5) | BIT(4) | BIT(3) | BIT(2), BIT(1));
> > -   mt76_rmw(dev, MT_WLAN_FUN_CTRL, BIT(5), BIT(6));
> > +   u16 ee_ant = mt76x02_eeprom_get(dev, MT_EE_ANTENNA);
> > +   u16 nic_conf2 = mt76x02_eeprom_get(dev, MT_EE_NIC_CONF_2);
> > +   u32 wlan, coex3, cmb;
> > +   bool ant_div;
> > +
> > +   wlan = mt76_rr(dev, MT_WLAN_FUN_CTRL);
> > +   cmb = mt76_rr(dev, MT_CMB_CTRL);
> > +   coex3 = mt76_rr(dev, MT_COEXCFG3);
> > +
> > +   cmb   &= ~(BIT(15) | BIT(12));
> 
> I guess should be BIT(14) here (at least for single antenna mode)

Yes , I will fix it.

> > +   coex3 &= ~GENMASK(5, 1);
> 
> according to vendor sdk BIT(1) should not cleared if device supports 5GHz band
> (signle antenna mode)

It is set below for that case:

> > +   if (dev->mt76.cap.has_5ghz) {
> > +   coex3 |= BIT(3) | BIT(4);
> > +   } else {
> > +   wlan |= BIT(6);
> > +   coex3 |= BIT(1);
> > +   }


Thanks
Stanislaw


Re: [PATCH] mt76: usb: fix static tracepoints

2018-10-18 Thread Stanislaw Gruszka
On Thu, Oct 18, 2018 at 10:13:51AM +0200, Lorenzo Bianconi wrote:
> On Oct 18, Stanislaw Gruszka wrote:
> > On Thu, Oct 18, 2018 at 12:35:32AM +0200, Lorenzo Bianconi wrote:
> > > Add submit_urb and rx_urb static tracepoints in mt76-usb module.
> > > Move trace_mac_txstat_fetch in mt76x02_mac_load_tx_status routine
> > > in order to be available to usb drivers. Moreover remove
> > > no longer used mt76x0/trace.{c,h}
> > > 
> > > Signed-off-by: Lorenzo Bianconi 
> > > ---
> > > @@ -54,7 +53,7 @@ mt76x0_rf_csr_wr(struct mt76x02_dev *dev, u32 offset, 
> > > u8 value)
> > >   FIELD_PREP(MT_RF_CSR_CFG_REG_ID, reg) |
> > >   MT_RF_CSR_CFG_WR |
> > >   MT_RF_CSR_CFG_KICK);
> > > - trace_mt76x0_rf_write(>mt76, bank, offset, value);
> > 
> > I think tracing RF registers writes/read can still be useful.
> 
> Hi Stanislaw,
> 
> I removed tracing for RF registers since these operations are already tracked 
> in
> mt76_wr/mt76_rr so I thought they were redundant. Do you think deducing rf
> read/write operations from mt76_{rr,wr} tracing is too convoluted? If so I
> can reintroduce them in v2.

No, if we can trace RF access thats ok. ACK for patch.

Thanks
Stanislaw


Re: wireless workshop (was: Re: Announcing Netdev 0x13 conference)

2018-10-18 Thread Stanislaw Gruszka
On Tue, Oct 09, 2018 at 12:28:23PM +0200, Johannes Berg wrote:
> Kalle and I have (more or less) decided to propose a wireless workshop
> for Netdev 0x13.
> 
> In order to gauge interest and plan room size, can you reply (privately
> if you like) if this would work for you and you'd (want to) attend?

I plan to attend.

Thanks
Stanislaw


[PATCH] mt76x0: antenna select corrections

2018-10-18 Thread Stanislaw Gruszka
Update mt76x0_phy_ant_select() to conform vendor driver, most notably
add dual antenna mode support, read configuration from EEPROM and
move ant select out of channel config to init phase. Plus small MT7630E
quirk for MT_CMB_CTRL register which vendor driver dedicated to this
chip do.

This make MT7630E workable with mt76x0e driver and do not cause any
problems on MT7610U for me.

Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/mediatek/mt76/mt76x0/phy.c| 52 --
 .../net/wireless/mediatek/mt76/mt76x02_eeprom.h| 10 ++---
 2 files changed, 44 insertions(+), 18 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c 
b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
index 37e1ead1dc85..143cbe6d7899 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
@@ -431,21 +431,47 @@ int mt76x0_phy_wait_bbp_ready(struct mt76x02_dev *dev)
 
 static void mt76x0_phy_ant_select(struct mt76x02_dev *dev)
 {
-   struct ieee80211_channel *chan = dev->mt76.chandef.chan;
-
-   /* single antenna mode */
-   if (chan->band == NL80211_BAND_2GHZ) {
-   mt76_rmw(dev, MT_COEXCFG3,
-BIT(5) | BIT(4) | BIT(3) | BIT(2), BIT(1));
-   mt76_rmw(dev, MT_WLAN_FUN_CTRL, BIT(5), BIT(6));
+   u16 ee_ant = mt76x02_eeprom_get(dev, MT_EE_ANTENNA);
+   u16 nic_conf2 = mt76x02_eeprom_get(dev, MT_EE_NIC_CONF_2);
+   u32 wlan, coex3, cmb;
+   bool ant_div;
+
+   wlan = mt76_rr(dev, MT_WLAN_FUN_CTRL);
+   cmb = mt76_rr(dev, MT_CMB_CTRL);
+   coex3 = mt76_rr(dev, MT_COEXCFG3);
+
+   cmb   &= ~(BIT(15) | BIT(12));
+   wlan  &= ~(BIT(6) | BIT(5));
+   coex3 &= ~GENMASK(5, 1);
+
+   if (ee_ant & MT_EE_ANTENNA_DUAL) {
+   /* dual antenna mode */
+   ant_div = !(nic_conf2 & MT_EE_NIC_CONF_2_ANT_OPT) &&
+ (nic_conf2 & MT_EE_NIC_CONF_2_ANT_DIV);
+   if (ant_div)
+   cmb |= BIT(12);
+   else
+   coex3 |= BIT(4);
+   coex3 |= BIT(3);
+   if (dev->mt76.cap.has_2ghz)
+   wlan |= BIT(6);
} else {
-   mt76_rmw(dev, MT_COEXCFG3, BIT(5) | BIT(2),
-BIT(4) | BIT(3));
-   mt76_clear(dev, MT_WLAN_FUN_CTRL,
-  BIT(6) | BIT(5));
+   /* sigle antenna mode */
+   if (dev->mt76.cap.has_5ghz) {
+   coex3 |= BIT(3) | BIT(4);
+   } else {
+   wlan |= BIT(6);
+   coex3 |= BIT(1);
+   }
}
-   mt76_clear(dev, MT_CMB_CTRL, BIT(14) | BIT(12));
+
+   if (is_mt7630(dev))
+   cmb |= BIT(14) | BIT(11);
+
+   mt76_wr(dev, MT_WLAN_FUN_CTRL, wlan);
+   mt76_wr(dev, MT_CMB_CTRL, cmb);
mt76_clear(dev, MT_COEXCFG0, BIT(2));
+   mt76_wr(dev, MT_COEXCFG3, coex3);
 }
 
 static void
@@ -612,7 +638,6 @@ int mt76x0_phy_set_channel(struct mt76x02_dev *dev,
mt76x02_phy_set_bw(dev, chandef->width, ch_group_index);
mt76x02_phy_set_band(dev, chandef->chan->band,
 ch_group_index & 1);
-   mt76x0_phy_ant_select(dev);
 
mt76_rmw(dev, MT_EXT_CCA_CFG,
 (MT_EXT_CCA_CFG_CCA0 |
@@ -795,6 +820,7 @@ void mt76x0_phy_init(struct mt76x02_dev *dev)
 {
INIT_DELAYED_WORK(>cal_work, mt76x0_phy_calibration_work);
 
+   mt76x0_phy_ant_select(dev);
mt76x0_phy_rf_init(dev);
mt76x02_phy_set_rxpath(dev);
mt76x02_phy_set_txdac(dev);
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_eeprom.h 
b/drivers/net/wireless/mediatek/mt76/mt76x02_eeprom.h
index b3ec74835d10..1de041590050 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_eeprom.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_eeprom.h
@@ -25,6 +25,7 @@ enum mt76x02_eeprom_field {
MT_EE_VERSION = 0x002,
MT_EE_MAC_ADDR =0x004,
MT_EE_PCI_ID =  0x00A,
+   MT_EE_ANTENNA = 0x022,
MT_EE_NIC_CONF_0 =  0x034,
MT_EE_NIC_CONF_1 =  0x036,
MT_EE_COUNTRY_REGION_5GHZ = 0x038,
@@ -104,6 +105,8 @@ enum mt76x02_eeprom_field {
__MT_EE_MAX
 };
 
+#define MT_EE_ANTENNA_DUAL BIT(15)
+
 #define MT_EE_NIC_CONF_0_RX_PATH   GENMASK(3, 0)
 #define MT_EE_NIC_CONF_0_TX_PATH   GENMASK(7, 4)
 #define MT_EE_NIC_CONF_0_PA_TYPE   GENMASK(9, 8)
@@ -118,12 +121,9 @@ enum mt76x02_eeprom_field {
 #define MT_EE_NIC_CONF_1_LNA_EXT_5GBIT(3)
 #define MT_EE_NIC_CONF_1_TX_ALC_EN BIT(13)
 
-#define MT_EE_NIC_CONF_2_RX_STREAM GENMASK(3, 0)

Re: [PATCH] mt76: usb: fix static tracepoints

2018-10-18 Thread Stanislaw Gruszka
On Thu, Oct 18, 2018 at 12:35:32AM +0200, Lorenzo Bianconi wrote:
> Add submit_urb and rx_urb static tracepoints in mt76-usb module.
> Move trace_mac_txstat_fetch in mt76x02_mac_load_tx_status routine
> in order to be available to usb drivers. Moreover remove
> no longer used mt76x0/trace.{c,h}
> 
> Signed-off-by: Lorenzo Bianconi 
> ---
> @@ -54,7 +53,7 @@ mt76x0_rf_csr_wr(struct mt76x02_dev *dev, u32 offset, u8 
> value)
>   FIELD_PREP(MT_RF_CSR_CFG_REG_ID, reg) |
>   MT_RF_CSR_CFG_WR |
>   MT_RF_CSR_CFG_KICK);
> - trace_mt76x0_rf_write(>mt76, bank, offset, value);

I think tracing RF registers writes/read can still be useful.

Thanks
Stanislaw


Re: [RFC 4/9] mt76x0: pci: add pre_tbtt_tasklet support

2018-10-17 Thread Stanislaw Gruszka
On Tue, Oct 16, 2018 at 11:23:26PM +0200, Lorenzo Bianconi wrote:
> Enable/disable pre_tbtt_tasklet in mt76x0 driver in order
> to add AP support

Is there some USB limitation that disallow tho do this for USB
as well? Or perhaps this is easer for now do this for PCI devices
and add AP support for USB later? But perhaps, since you adding
support for AP you could do this for both buses.

Thanks
Stanislaw 


Re: [PATCH v4 4/8] rt2800: fix registers init for MT7620

2018-10-16 Thread Stanislaw Gruszka
Hello

On Tue, Oct 16, 2018 at 01:32:18PM +0200, Tom Psyborg wrote:
> I am sending you two builds privately so please check if there are any
> differences between the two builds and report back. Thanks.

I extracted rt2800lib.ko module from provided images, did disassembly via:

./staging_dir/toolchain-mipsel_24kc_gcc-7.3.0_musl/bin/mipsel-openwrt-linux-objdump
 \
 -d -r --prefix-addresses ~/rt2800lib-BUILDn.ko  > ~/BUILDn.dump.txt

command and compered disassembled code. Here is difference:

$ diff -up  BUILD1.dump.txt BUILD2.dump.txt 
--- BUILD1.dump.txt 2018-10-16 16:40:34.834220838 +0200
+++ BUILD2.dump.txt 2018-10-16 16:40:40.187219211 +0200
@@ -1,5 +1,5 @@
 
-/home/stasiu/rt2800lib-BUILD1.ko: file format elf32-tradlittlemips
+/home/stasiu/rt2800lib-BUILD2.ko: file format elf32-tradlittlemips
 
 
 Disassembly of section .text:
@@ -9374,7 +9374,7 @@ Disassembly of section .text:
 7f80  jalr  v0
 7f84  move  a0,s0
 7f88  lhu   v1,732(s0)
-7f8c  liv0,21392
+7f8c  liv0,25426
 7f90  bne   v1,v0,810c 

 7f94  lia2,1025
 7f98  lwv0,4(s0)

There is no difference in init_registers (which is inlined in
rt2800_enable_radio). The only difference is in some number
rt2800_clear_beacon() function.

Regards
Stanislaw


Re: [PATCH v4 4/8] rt2800: fix registers init for MT7620

2018-10-16 Thread Stanislaw Gruszka
On Tue, Oct 16, 2018 at 01:19:52PM +0200, Felix Fietkau wrote:
> > I have no idea how this could be related. But I think I found
> > somewhat reasonable explenation where the problem is.
> > I think below code :
> > 
> > if (a || b || c) {
> > CODE1();
> > } else if (c) {
> > CODE2();
> > }
> > 
> > can not be deterministic and can be compiled differently depending
> > on compiler version and used options. Sometimes it could result
> > in this 
> > 
> > if (a || b || c) {
> > CODE1();
> > }
> > 
> > and sometimes in this:
> > 
> > if (a || b) {
> > CODE1();
> > } else if (c) {
> > CODE2();
> > }
> > 
> > So that would explain the problems you see. And indeed patch
> > could cause regression on systems where second variant of
> > initalizing RT6352 registers was used.
> I don't see how that can be non-deterministic at all. The 'else if' part
> can only be hit if the first if did not match.

I meant non-deterministic during compilation process, when compiler
do or do not some optimizations or if compiler version differs.

Regards
Stanislaw


Re: [RFC v4 05/13] rtw88: mac files

2018-10-16 Thread Stanislaw Gruszka
On Sat, Oct 13, 2018 at 05:00:37PM +0800, yhchu...@realtek.com wrote:
> + buf = kmalloc(size, GFP_KERNEL);
> + memcpy(buf, data, size);

Error check and it could be replaced by kmemdup.

Regards
Stanislaw


Re: [RFC v4 00/13] rtw88: mac80211 driver for Realtek 802.11ac wireless network chips

2018-10-16 Thread Stanislaw Gruszka
On Sat, Oct 13, 2018 at 05:00:32PM +0800, yhchu...@realtek.com wrote:
> From: Yan-Hsuan Chuang 
> 
> This is a new mac80211 driver for Realtek 802.11ac wireless network chips.
> rtw88 supports 8822BE and 8822CE chips, and will be able to support
> multi-vif combinations in run-time.
> 
> For now, only PCI bus is supported, but rtw88 was originally designed
> to optionally support three buses includes USB & SDIO. USB & SDIO modules
> will soon be supported by rtw88, with configurable core module to fit
> with different bus modules in the same time.
> 
> For example, if we choose 8822BE and 8822CU, only PCI & USB modules will
> be selected, built, loaded into kernel. This is one of the major
> difference from rtlwifi, which can only support specific combinations.
> 
> Another difference from rtlwifi is that rtw88 is designed to support
> the latest Realtek 802.11ac wireless network chips like 8822B and
> 8822C series. Compared to the earlier chips supported by rtlwifi like
> the 802.11n 8192EE chipset or 802.11ac 8821AE/8812AE chips, newer ICs
> have different MAC & PHY settings, such as new multi-port feature for the
> MAC layer design and Jaguar2/Jaguar3 PHY layer IPs.
> 
> Multi-Port feature is also supported under rtw88's software architecture.
> rtlwifi can only support one vif in the same time, most because of the
> hardware limitations for early chips, hence the original design of it
> also restricts the usage of multi-vif support, so latest chipset seems not
> take advantages from its new MAC engine.
> 
> However, rtw88 can run multiple vifs concurrently by holding them on
> hardware ports provided by MAC engine, hence can easily start different
> roles on a single device.
> 
> Based on the reasons mentioned before, we implemented rtw88. It had many
> authors, they are listed here alphabetically:
> 
> Ping-Ke Shih 
> Tzu-En Huang 
> Yan-Hsuan Chuang 

For the series:
Reviewed-by: Stanislaw Gruszka 


Re: [RFC v4 06/13] rtw88: fw and efuse files

2018-10-16 Thread Stanislaw Gruszka
On Sat, Oct 13, 2018 at 05:00:38PM +0800, yhchu...@realtek.com wrote:
> +rtw_beacon_get(struct ieee80211_hw *hw, struct ieee80211_vif *vif)
> +{
> + struct sk_buff *skb_new;
> +
> + if (vif->type != NL80211_IFTYPE_AP &&
> + vif->type != NL80211_IFTYPE_ADHOC &&
> + !ieee80211_vif_is_mesh(vif)) {
> + skb_new = alloc_skb(1, GFP_KERNEL);
> + skb_put(skb_new, 1);

Error check.

Thanks
Stanislaw


Re: [PATCH v4 4/8] rt2800: fix registers init for MT7620

2018-10-16 Thread Stanislaw Gruszka
On Fri, Oct 12, 2018 at 12:48:07PM +0200, Tom Psyborg wrote:
> chip version support exist in daniel's tree since a long time ago. so
> don't disable registers initialization but try to upstream his
> changes.

Where is this patch ? I can not find it.

Thanks
Stanislaw


Re: [PATCH v4 4/8] rt2800: fix registers init for MT7620

2018-10-16 Thread Stanislaw Gruszka
On Fri, Oct 12, 2018 at 02:41:41PM +0200, Tom Psyborg wrote:
> On 12/10/2018, Stanislaw Gruszka  wrote:
> > On Fri, Oct 12, 2018 at 02:20:07PM +0200, Tom Psyborg wrote:
> >> > On upstream tree where this patch is intended
> >> > additional registers where never programmed as proper branch
> >> > were never used, because of additional check in RT5390 branch.
> >> >
> >>
> >> on my hardware additional registers were programmed in regardless of
> >> redundant check. that why i opened whole thread on forum since i
> >> couldn't understand how's that happening
> >
> > I don't understand how that possible either.
> 
> i'd assume because device use external lna

I have no idea how this could be related. But I think I found
somewhat reasonable explenation where the problem is.
I think below code :

if (a || b || c) {
CODE1();
} else if (c) {
CODE2();
}

can not be deterministic and can be compiled differently depending
on compiler version and used options. Sometimes it could result
in this 

if (a || b || c) {
CODE1();
}

and sometimes in this:

if (a || b) {
CODE1();
} else if (c) {
CODE2();
}

So that would explain the problems you see. And indeed patch
could cause regression on systems where second variant of
initalizing RT6352 registers was used.

Thanks
Stanislaw







Re: [PATCH v4 4/8] rt2800: fix registers init for MT7620

2018-10-16 Thread Stanislaw Gruszka
On Sat, Oct 13, 2018 at 12:46:54PM +0300, Kalle Valo wrote:
> No '#if 0', please. If the code is not needed you can remove it, it's
> available from git history anyway if it's needed later.

Plase drop this patch, other patches from the set can be applied
without it.

Thanks
Stanislaw


[PATCH] mt76x0: do not perform MCU calibration for MT7630

2018-10-16 Thread Stanislaw Gruszka
Driver works better for MT7630 without MCU calibration, which
looks like it can hangs the firmware. Vendor driver do not
perform it for MT7630 as well.

Signed-off-by: Stanislaw Gruszka 
---
This is on top of:
https://marc.info/?l=linux-wireless=153960591116586=2

 drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0.h | 5 +
 drivers/net/wireless/mediatek/mt76/mt76x0/phy.c| 3 +++
 2 files changed, 8 insertions(+)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0.h 
b/drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0.h
index 17ad3fa0858b..33475788bc26 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0.h
@@ -37,6 +37,11 @@ static inline bool is_mt7610e(struct mt76x02_dev *dev)
return false;
 }
 
+static inline bool is_mt7630(struct mt76x02_dev *dev)
+{
+   return mt76_chip(>mt76) == 0x7630;
+}
+
 /* Init */
 struct mt76x02_dev *
 mt76x0_alloc_device(struct device *pdev,
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c 
b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
index dbb92586b6e1..37e1ead1dc85 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
@@ -500,6 +500,9 @@ void mt76x0_phy_calibrate(struct mt76x02_dev *dev, bool 
power_on)
struct ieee80211_channel *chan = dev->mt76.chandef.chan;
u32 val, tx_alc, reg_val;
 
+   if (is_mt7630(dev))
+   return;
+
if (power_on) {
mt76x02_mcu_calibrate(dev, MCU_CAL_R, 0, false);
mt76x02_mcu_calibrate(dev, MCU_CAL_VCO, chan->hw_value,
-- 
1.9.3



Re: [PATCH] mt76x0: phy: unify calibration between mt76x0u and mt76x0e

2018-10-16 Thread Stanislaw Gruszka
On Mon, Oct 15, 2018 at 02:18:05PM +0200, Lorenzo Bianconi wrote:
> Align phy calibration logic between mt76x0u and mt76x0e drivers
> This patch improves connection stability with low SNR
> 
> Signed-off-by: Lorenzo Bianconi 

Tested-by: Stanislaw Gruszka 


Re: [PATCH 04/13] mt76x0: pci: introduce mt76x0_phy_calirate routine

2018-10-12 Thread Stanislaw Gruszka
On Fri, Oct 12, 2018 at 12:16:20PM +0200, Lorenzo Bianconi wrote:
> Add mt76x0_phy_calirate routine in order to perform
> phy calibration for mt76x0e devices.

> @@ -671,9 +713,14 @@ int mt76x0_phy_set_channel(struct mt76x02_dev *dev,
>   /* Vendor driver don't do it */
>   /* mt76x0_phy_set_tx_power(dev, channel, rf_bw_band); */
>  
> - mt76x0_vco_cal(dev, channel);
> - if (scan)
> - mt76x02_mcu_calibrate(dev, MCU_CAL_RXDCOC, 1, false);
> + if (mt76_is_usb(dev)) {
> + mt76x0_vco_cal(dev, channel);
> + if (scan)
> + mt76x02_mcu_calibrate(dev, MCU_CAL_RXDCOC, 1,
> +   false);
> + } else {
> + mt76x0_phy_calibrate(dev, false);
> + }

Why this should be diffrent for USB and PCI ? RF calibration seems
not to be realted to bus type, so perhaps this should be based on
mt76xx_rev() check?

Thanks
Stanislaw 


Re: [PATCH v4 4/8] rt2800: fix registers init for MT7620

2018-10-12 Thread Stanislaw Gruszka
On Fri, Oct 12, 2018 at 02:20:07PM +0200, Tom Psyborg wrote:
> > On upstream tree where this patch is intended
> > additional registers where never programmed as proper branch
> > were never used, because of additional check in RT5390 branch.
> >
> 
> on my hardware additional registers were programmed in regardless of
> redundant check. that why i opened whole thread on forum since i
> couldn't understand how's that happening

I don't understand how that possible either.

> > Patch does only change TX_SW_CFG* regs values for RT6352.
> >
> 
> i'd still prefer that we include CONFIG_RT2800SOC, and if required
> move rest of the registers to that check, because at least on my
> hardware driver would still recognize chip as RT5390 despite the
> RT6352 defines

As I pointed before you should add additional printk's and provide
dmesg to make us see what is going on.

Thanks
Stanislaw


Re: [PATCH v4 4/8] rt2800: fix registers init for MT7620

2018-10-12 Thread Stanislaw Gruszka
Please stop top-posting.

On Fri, Oct 12, 2018 at 01:51:00PM +0200, Tom Psyborg wrote:
> it will cause regression on other devices

How exactly ? On upstream tree where this patch is intended
additional registers where never programmed as proper branch 
were never used, because of additional check in RT5390 branch.

Patch does only change TX_SW_CFG* regs values for RT6352.

Thanks
Stanislaw


Re: [PATCH v4 6/8] rt2800: enable TX_PIN_CFG_RFRX_EN only for MT7620

2018-10-12 Thread Stanislaw Gruszka
On Fri, Oct 12, 2018 at 12:52:13PM +0200, Tom Psyborg wrote:
> is there some specific reason to read TX_PIN_CFG register on RT6352,
> rather than just null it before programming in tx values like in other
> chips?

I don't remember the details, but Daniel explained that tere are 
some bits in the TX_PIN_CFG register that have to be preserved
for RT6352.

Regards
Stanislaw


Re: [PATCH v4 4/8] rt2800: fix registers init for MT7620

2018-10-12 Thread Stanislaw Gruszka
On Fri, Oct 12, 2018 at 12:48:07PM +0200, Tom Psyborg wrote:
> chip version support exist in daniel's tree since a long time ago. so
> don't disable registers initialization but try to upstream his
> changes.

I do not see reason for for blocking this change because some other
changes are not unstreamed yet. When chip version support will
be unstreamed, the register initialization will be unblocked.

Regards.
Stanislaw


[PATCH v4 8/8] rt2800: comment and simplify AGC init for RT6352

2018-10-12 Thread Stanislaw Gruszka
We do not need separate lines for calculating register values.
Also add comment that value is different than in vendor driver.

Suggested-by: Daniel Golle 
Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c 
b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index ba7470897f3c..29b08d63e95b 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -3986,9 +3986,12 @@ static void rt2800_config_channel(struct rt2x00_dev 
*rt2x00dev,
rt2800_bbp_write(rt2x00dev, 195, 141);
rt2800_bbp_write(rt2x00dev, 196, reg);
 
-   /* AGC init */
-   reg = rf->channel <= 14 ? 0x1c : 0x24;
-   reg += 2 * rt2x00dev->lna_gain;
+   /* AGC init.
+* Despite the vendor driver using different values here for
+* RT6352 chip, we use 0x1c for now. This may have to be changed
+* once TSSI got implemented.
+*/
+   reg = (rf->channel <= 14 ? 0x1c : 0x24) + 2*rt2x00dev->lna_gain;
rt2800_bbp_write_with_rx_chain(rt2x00dev, 66, reg);
 
rt2800_iq_calibrate(rt2x00dev, rf->channel);
-- 
2.7.5



[PATCH v4 3/8] rt2x00: update TX_SW_CFG2 value

2018-10-12 Thread Stanislaw Gruszka
From: Tomislav Požega 

Use default value of TX_SW_CFG2 register that is in charge
of LNA timings. Works for somewhat higher RX throughput.

Signed-off-by: Tomislav Požega 
---
 drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c 
b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 3a04eaef8511..daf20d7424ac 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -5465,7 +5465,7 @@ static int rt2800_init_registers(struct rt2x00_dev 
*rt2x00dev)
} else if (rt2x00_rt(rt2x00dev, RT6352)) {
rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x0401);
rt2800_register_write(rt2x00dev, TX_SW_CFG1, 0x000C);
-   rt2800_register_write(rt2x00dev, TX_SW_CFG2, 0x);
+   rt2800_register_write(rt2x00dev, TX_SW_CFG2, 0x000C0408);
rt2800_register_write(rt2x00dev, MIMO_PS_CFG, 0x0002);
rt2800_register_write(rt2x00dev, TX_PIN_CFG, 0x00150F0F);
rt2800_register_write(rt2x00dev, TX_ALC_VGA3, 0x06060606);
-- 
2.7.5



[PATCH v4 6/8] rt2800: enable TX_PIN_CFG_RFRX_EN only for MT7620

2018-10-12 Thread Stanislaw Gruszka
The TX_PIN_CFG_RFRX_EN bit was not set on other devices than MT7620,
restore old behavaviour since setting this bit maight not be
correct for older devices.

Fixes: 41977e86c984 ("rt2x00: add support for MT7620")
Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c 
b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index bf0d12c5b2db..d0af0d9d2550 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -3856,10 +3856,12 @@ static void rt2800_config_channel(struct rt2x00_dev 
*rt2x00dev,
if (rt2x00_rt(rt2x00dev, RT3572))
rt2800_rfcsr_write(rt2x00dev, 8, 0);
 
-   if (rt2x00_rt(rt2x00dev, RT6352))
+   if (rt2x00_rt(rt2x00dev, RT6352)) {
tx_pin = rt2800_register_read(rt2x00dev, TX_PIN_CFG);
-   else
+   rt2x00_set_field32(_pin, TX_PIN_CFG_RFRX_EN, 1);
+   } else {
tx_pin = 0;
+   }
 
switch (rt2x00dev->default_ant.tx_chain_num) {
case 3:
@@ -3914,7 +3916,6 @@ static void rt2800_config_channel(struct rt2x00_dev 
*rt2x00dev,
 
rt2x00_set_field32(_pin, TX_PIN_CFG_RFTR_EN, 1);
rt2x00_set_field32(_pin, TX_PIN_CFG_TRSW_EN, 1);
-   rt2x00_set_field32(_pin, TX_PIN_CFG_RFRX_EN, 1); /* mt7620 */
 
rt2800_register_write(rt2x00dev, TX_PIN_CFG, tx_pin);
 
-- 
2.7.5



[PATCH v4 2/8] rt2x00: remove confusing AGC register

2018-10-12 Thread Stanislaw Gruszka
From: Tomislav Požega 

Register 66 was causing issues on RT6352 if set to the same value as
in MTK driver. With 1c reg value device was working fine in both HT20
and HT40 modes.

Signed-off-by: Tomislav Požega 
Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c 
b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 1a2bf6c49b82..3a04eaef8511 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -3981,11 +3981,7 @@ static void rt2800_config_channel(struct rt2x00_dev 
*rt2x00dev,
rt2800_bbp_write(rt2x00dev, 196, reg);
 
/* AGC init */
-   if (rt2x00_rt(rt2x00dev, RT6352))
-   reg = 0x04;
-   else
-   reg = rf->channel <= 14 ? 0x1c : 0x24;
-
+   reg = rf->channel <= 14 ? 0x1c : 0x24;
reg += 2 * rt2x00dev->lna_gain;
rt2800_bbp_write_with_rx_chain(rt2x00dev, 66, reg);
 
-- 
2.7.5



[PATCH v4 7/8] rt2800: remove unneeded RT6352 check

2018-10-12 Thread Stanislaw Gruszka
Remove rt2x00_rt(rt2x00dev, RT6352)) check from
rt2800_config_channel_rf53xx() which is not called for RT6352 devices.

Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c 
b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index d0af0d9d2550..ba7470897f3c 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -3037,8 +3037,7 @@ static void rt2800_config_channel_rf53xx(struct 
rt2x00_dev *rt2x00dev,
rt2800_rfcsr_write(rt2x00dev, 59,
   r59_nonbt_rev[idx]);
} else if (rt2x00_rt(rt2x00dev, RT5390) ||
-  rt2x00_rt(rt2x00dev, RT5392) ||
-  rt2x00_rt(rt2x00dev, RT6352)) {
+  rt2x00_rt(rt2x00dev, RT5392)) {
static const char r59_non_bt[] = {0x8f, 0x8f,
0x8f, 0x8f, 0x8f, 0x8f, 0x8f, 0x8d,
0x8a, 0x88, 0x88, 0x87, 0x87, 0x86};
-- 
2.7.5



[PATCH v4 5/8] rt2800: enable TX_PIN_CFG_LNA_PE_ bits per band

2018-10-12 Thread Stanislaw Gruszka
Do not enable TX_PIN_CFG_LNA_PE_A* bits for 2.4GHz band and
vice versa TX_PIN_CFG_LNA_PE_G* bits for 5GHz.

Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c 
b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 16d6d99b1d44..bf0d12c5b2db 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -3891,18 +3891,24 @@ static void rt2800_config_channel(struct rt2x00_dev 
*rt2x00dev,
switch (rt2x00dev->default_ant.rx_chain_num) {
case 3:
/* Turn on tertiary LNAs */
-   rt2x00_set_field32(_pin, TX_PIN_CFG_LNA_PE_A2_EN, 1);
-   rt2x00_set_field32(_pin, TX_PIN_CFG_LNA_PE_G2_EN, 1);
+   rt2x00_set_field32(_pin, TX_PIN_CFG_LNA_PE_A2_EN,
+  rf->channel > 14);
+   rt2x00_set_field32(_pin, TX_PIN_CFG_LNA_PE_G2_EN,
+  rf->channel <= 14);
/* fall-through */
case 2:
/* Turn on secondary LNAs */
-   rt2x00_set_field32(_pin, TX_PIN_CFG_LNA_PE_A1_EN, 1);
-   rt2x00_set_field32(_pin, TX_PIN_CFG_LNA_PE_G1_EN, 1);
+   rt2x00_set_field32(_pin, TX_PIN_CFG_LNA_PE_A1_EN,
+  rf->channel > 14);
+   rt2x00_set_field32(_pin, TX_PIN_CFG_LNA_PE_G1_EN,
+  rf->channel <= 14);
/* fall-through */
case 1:
/* Turn on primary LNAs */
-   rt2x00_set_field32(_pin, TX_PIN_CFG_LNA_PE_A0_EN, 1);
-   rt2x00_set_field32(_pin, TX_PIN_CFG_LNA_PE_G0_EN, 1);
+   rt2x00_set_field32(_pin, TX_PIN_CFG_LNA_PE_A0_EN,
+  rf->channel > 14);
+   rt2x00_set_field32(_pin, TX_PIN_CFG_LNA_PE_G0_EN,
+  rf->channel <= 14);
break;
}
 
-- 
2.7.5



[PATCH v4 1/8] rt2x00: remove unneeded check

2018-10-12 Thread Stanislaw Gruszka
From: Tomislav Požega 

Remove band check from rf53xx channel config routine since all chips
using it are single band.

Signed-off-by: Tomislav Požega 
Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 103 -
 1 file changed, 50 insertions(+), 53 deletions(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c 
b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 9e7b8933d30c..1a2bf6c49b82 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -2963,6 +2963,7 @@ static void rt2800_config_channel_rf53xx(struct 
rt2x00_dev *rt2x00dev,
 struct rf_channel *rf,
 struct channel_info *info)
 {
+   int idx = rf->channel-1;
u8 rfcsr;
 
rt2800_rfcsr_write(rt2x00dev, 8, rf->rf1);
@@ -3001,60 +3002,56 @@ static void rt2800_config_channel_rf53xx(struct 
rt2x00_dev *rt2x00dev,
 
rt2800_freq_cal_mode1(rt2x00dev);
 
-   if (rf->channel <= 14) {
-   int idx = rf->channel-1;
-
-   if (rt2x00_has_cap_bt_coexist(rt2x00dev)) {
-   if (rt2x00_rt_rev_gte(rt2x00dev, RT5390, REV_RT5390F)) {
-   /* r55/r59 value array of channel 1~14 */
-   static const char r55_bt_rev[] = {0x83, 0x83,
-   0x83, 0x73, 0x73, 0x63, 0x53, 0x53,
-   0x53, 0x43, 0x43, 0x43, 0x43, 0x43};
-   static const char r59_bt_rev[] = {0x0e, 0x0e,
-   0x0e, 0x0e, 0x0e, 0x0b, 0x0a, 0x09,
-   0x07, 0x07, 0x07, 0x07, 0x07, 0x07};
-
-   rt2800_rfcsr_write(rt2x00dev, 55,
-  r55_bt_rev[idx]);
-   rt2800_rfcsr_write(rt2x00dev, 59,
-  r59_bt_rev[idx]);
-   } else {
-   static const char r59_bt[] = {0x8b, 0x8b, 0x8b,
-   0x8b, 0x8b, 0x8b, 0x8b, 0x8a, 0x89,
-   0x88, 0x88, 0x86, 0x85, 0x84};
-
-   rt2800_rfcsr_write(rt2x00dev, 59, r59_bt[idx]);
-   }
+   if (rt2x00_has_cap_bt_coexist(rt2x00dev)) {
+   if (rt2x00_rt_rev_gte(rt2x00dev, RT5390, REV_RT5390F)) {
+   /* r55/r59 value array of channel 1~14 */
+   static const char r55_bt_rev[] = {0x83, 0x83,
+   0x83, 0x73, 0x73, 0x63, 0x53, 0x53,
+   0x53, 0x43, 0x43, 0x43, 0x43, 0x43};
+   static const char r59_bt_rev[] = {0x0e, 0x0e,
+   0x0e, 0x0e, 0x0e, 0x0b, 0x0a, 0x09,
+   0x07, 0x07, 0x07, 0x07, 0x07, 0x07};
+
+   rt2800_rfcsr_write(rt2x00dev, 55,
+  r55_bt_rev[idx]);
+   rt2800_rfcsr_write(rt2x00dev, 59,
+  r59_bt_rev[idx]);
} else {
-   if (rt2x00_rt_rev_gte(rt2x00dev, RT5390, REV_RT5390F)) {
-   static const char r55_nonbt_rev[] = {0x23, 0x23,
-   0x23, 0x23, 0x13, 0x13, 0x03, 0x03,
-   0x03, 0x03, 0x03, 0x03, 0x03, 0x03};
-   static const char r59_nonbt_rev[] = {0x07, 0x07,
-   0x07, 0x07, 0x07, 0x07, 0x07, 0x07,
-   0x07, 0x07, 0x06, 0x05, 0x04, 0x04};
-
-   rt2800_rfcsr_write(rt2x00dev, 55,
-  r55_nonbt_rev[idx]);
-   rt2800_rfcsr_write(rt2x00dev, 59,
-  r59_nonbt_rev[idx]);
-   } else if (rt2x00_rt(rt2x00dev, RT5390) ||
-  rt2x00_rt(rt2x00dev, RT5392) ||
-  rt2x00_rt(rt2x00dev, RT6352)) {
-   static const char r59_non_bt[] = {0x8f, 0x8f,
-   0x8f, 0x8f, 0x8f, 0x8f, 0x8f, 0x8d,
-   0x8a, 0x88, 0x88, 0x87, 0x87, 0x86};
-
-   rt2800_rfcsr_write(rt2x00dev, 59,
-  r59_non_bt[idx]);
-   } else if (rt2x00_rt(rt2x00dev, RT5350)) {
-   static const char r59_non_bt[] = {0x0b, 0x0b,
-   0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0a,
-   0x0a, 0

[PATCH v4 0/8] rt2800: register programing tweaks and clean ups

2018-10-12 Thread Stanislaw Gruszka
v3 -> v4:
- do not program addition registers for MT7620
- fix RT6362 typo

v2 -> v3:
- fix wrongly applied hunk during rebase
- add SoB

Stanislaw Gruszka (5):
  rt2800: fix registers init for MT7620
  rt2800: enable TX_PIN_CFG_LNA_PE_ bits per band
  rt2800: enable TX_PIN_CFG_RFRX_EN only for MT7620
  rt2800: remove unneeded RT6352 check
  rt2800: comment and simplify AGC init for RT6352

Tomislav Požega (3):
  rt2x00: remove unneeded check
  rt2x00: remove confusing AGC register
  rt2x00: update TX_SW_CFG2 value

 drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 150 +
 1 file changed, 78 insertions(+), 72 deletions(-)

-- 
2.7.5



[PATCH v4 4/8] rt2800: fix registers init for MT7620

2018-10-12 Thread Stanislaw Gruszka
There is duplicated 'if (rt2x00_rt(rt2x00dev, RT6352))' entry that
causes we do not perform register initialization for RT6352 (MT7620
SOCs) in correct branch. Fix this and disable registers initialization
that is specific to particular MT7620 revision.

Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c 
b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index daf20d7424ac..16d6d99b1d44 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -5451,8 +5451,7 @@ static int rt2800_init_registers(struct rt2x00_dev 
*rt2x00dev)
  0x);
}
} else if (rt2x00_rt(rt2x00dev, RT5390) ||
-  rt2x00_rt(rt2x00dev, RT5392) ||
-  rt2x00_rt(rt2x00dev, RT6352)) {
+  rt2x00_rt(rt2x00dev, RT5392)) {
rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x0404);
rt2800_register_write(rt2x00dev, TX_SW_CFG1, 0x00080606);
rt2800_register_write(rt2x00dev, TX_SW_CFG2, 0x);
@@ -5466,6 +5465,10 @@ static int rt2800_init_registers(struct rt2x00_dev 
*rt2x00dev)
rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x0401);
rt2800_register_write(rt2x00dev, TX_SW_CFG1, 0x000C);
rt2800_register_write(rt2x00dev, TX_SW_CFG2, 0x000C0408);
+   /* TODO add chip version support and init registers
+* according to the version.
+*/
+#if 0
rt2800_register_write(rt2x00dev, MIMO_PS_CFG, 0x0002);
rt2800_register_write(rt2x00dev, TX_PIN_CFG, 0x00150F0F);
rt2800_register_write(rt2x00dev, TX_ALC_VGA3, 0x06060606);
@@ -5480,6 +5483,7 @@ static int rt2800_init_registers(struct rt2x00_dev 
*rt2x00dev)
reg = rt2800_register_read(rt2x00dev, TX_ALC_CFG_1);
rt2x00_set_field32(, TX_ALC_CFG_1_ROS_BUSY_EN, 0);
rt2800_register_write(rt2x00dev, TX_ALC_CFG_1, reg);
+#endif
} else {
rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x);
rt2800_register_write(rt2x00dev, TX_SW_CFG1, 0x00080606);
-- 
2.7.5



Re: [PATCH v3 4/4] rt2800: fix registers init for MT7620

2018-10-12 Thread Stanislaw Gruszka
On Thu, Oct 11, 2018 at 02:39:25PM +0200, Tom Psyborg wrote:
> so this is RX test where I assume your 7265 card is sending data. is
> that HT20 or HT40 mode and do you get regression on TX too?
> 
> can you try same case 2 test but with registers set to:
> 
> TX_SW_CFG0, 0x0401
> TX_SW_CFG1, 0x000C
> TX_SW_CFG2, 0x (or 0x000C0408)
> 
> did you ever notice any tx power difference between nexx fw and openwrt fw?

Changing only TX_SW_CFG* does not make any diffrence on my router,
but this patch also start to configure other registers i.e.
MIMO_PS_CFG and that coused performance regression. I'll repost
without additional register programming.

Thanks
Stanislaw


Re: [PATCH 0/4] rt2800: more register programing tweaks

2018-10-11 Thread Stanislaw Gruszka
On Wed, Oct 10, 2018 at 05:46:16PM +0200, Stanislaw Gruszka wrote:
> This is on top of previous post:
> https://marc.info/?l=linux-wireless=153908617400582=2
> 
> Stanislaw Gruszka (4):
>   rt2800: enable TX_PIN_CFG_LNA_PE_ bits per band
>   rt2800: enable TX_PIN_CFG_RFRX_EN only for MT7620
>   rt2800: remove unneeded RT6352 check
>   rt2800: comment and simplify AGC init for RT6352
> 
>  drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 37 
> --
>  1 file changed, 23 insertions(+), 14 deletions(-)

and drop this one as well.

Thanks
Stanislaw


Re: [PATCH v3 1/4] rt2x00: remove unneeded check

2018-10-11 Thread Stanislaw Gruszka
Kalle, plese drop this set it has to be reworked.

Thanks
Stanislaw


Re: [PATCH v3 4/4] rt2800: fix registers init for MT7620

2018-10-11 Thread Stanislaw Gruszka
On Wed, Oct 10, 2018 at 10:03:12PM +0200, Tom Psyborg wrote:
> ok, that is strange. do you see any performance differences without
> TX_SW_CFG regs? iperf test is a good pointer.
> 
> this was a problem on xiaomi mini with old DD trunk builds on 4.4
> kernel and LEDE builds from last year. i ain't got no chance to try
> this on 18.06. which device you tried this on? if ipa/ilna it might
> make no difference

No diffrence for me. I have nexx wt3020 8M.

However I notice this set couse performance regression for me. 
When connecting to iwl 7265 . Without the set I have:

root@LEDE:~# iperf3 -c 192.168.10.243
Connecting to host 192.168.10.243, port 5201
[  5] local 192.168.10.1 port 59304 connected to 192.168.10.243 port 5201
[ ID] Interval   Transfer Bitrate Retr  Cwnd
[  5]   0.00-1.00   sec  5.37 MBytes  44.9 Mbits/sec0279 KBytes   
[  5]   1.00-2.00   sec  5.80 MBytes  48.8 Mbits/sec0494 KBytes   
[  5]   2.00-3.00   sec  6.03 MBytes  50.5 Mbits/sec0513 KBytes   
[  5]   3.00-4.01   sec  5.90 MBytes  49.2 Mbits/sec0513 KBytes   
[  5]   4.01-5.01   sec  5.90 MBytes  49.5 Mbits/sec0515 KBytes   
[  5]   5.01-6.00   sec  5.78 MBytes  48.9 Mbits/sec0515 KBytes   
[  5]   6.00-7.00   sec  5.66 MBytes  47.4 Mbits/sec0515 KBytes   
[  5]   7.00-8.00   sec  6.03 MBytes  50.6 Mbits/sec0515 KBytes   
[  5]   8.00-9.00   sec  6.09 MBytes  50.9 Mbits/sec0515 KBytes   
[  5]   9.00-10.00  sec  5.72 MBytes  48.2 Mbits/sec0515 KBytes   
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bitrate Retr
[  5]   0.00-10.00  sec  58.3 MBytes  48.9 Mbits/sec0 sender
[  5]   0.00-10.00  sec  58.3 MBytes  48.9 Mbits/sec  receiver

With the set I have:

root@LEDE:~# iperf3  -c 192.168.10.243
Connecting to host 192.168.10.243, port 5201
[  5] local 192.168.10.1 port 45824 connected to 192.168.10.243 port 5201
[ ID] Interval   Transfer Bitrate Retr  Cwnd
[  5]   0.00-1.00   sec  3.78 MBytes  31.7 Mbits/sec0197 KBytes
[  5]   1.00-2.00   sec  3.71 MBytes  31.0 Mbits/sec0369 KBytes
[  5]   2.00-3.00   sec  3.51 MBytes  29.5 Mbits/sec0484 KBytes
[  5]   3.00-4.00   sec  3.36 MBytes  28.1 Mbits/sec0519 KBytes
[  5]   4.00-5.00   sec  4.10 MBytes  34.4 Mbits/sec0519 KBytes
[  5]   5.00-6.00   sec  3.73 MBytes  31.2 Mbits/sec0519 KBytes
[  5]   6.00-7.00   sec  4.29 MBytes  36.0 Mbits/sec0519 KBytes
[  5]   7.00-8.00   sec  4.16 MBytes  34.9 Mbits/sec0519 KBytes
[  5]   8.00-9.00   sec  4.35 MBytes  36.5 Mbits/sec0519 KBytes
[  5]   9.00-10.00  sec  4.41 MBytes  37.0 Mbits/sec0519 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bitrate Retr
[  5]   0.00-10.00  sec  39.4 MBytes  33.0 Mbits/sec0 sender
[  5]   0.00-10.00  sec  39.4 MBytes  33.0 Mbits/sec  receiver


Stanislaw



[PATCH 4/4] rt2800: comment and simplify AGC init for RT6352

2018-10-10 Thread Stanislaw Gruszka
We do not need separate lines for calculating register values.
Also add comment that value is different than in vendor driver.

Suggested-by: Daniel Golle 
Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c 
b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index a2cdd3a5034a..7b6effaa0740 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -3986,9 +3986,12 @@ static void rt2800_config_channel(struct rt2x00_dev 
*rt2x00dev,
rt2800_bbp_write(rt2x00dev, 195, 141);
rt2800_bbp_write(rt2x00dev, 196, reg);
 
-   /* AGC init */
-   reg = rf->channel <= 14 ? 0x1c : 0x24;
-   reg += 2 * rt2x00dev->lna_gain;
+   /* AGC init.
+* Despite the vendor driver using different values here for
+* RT6362 chip, we use 0x1c for now. This may have to be changed
+* once TSSI got implemented.
+*/
+   reg = (rf->channel <= 14 ? 0x1c : 0x24) + 2*rt2x00dev->lna_gain;
rt2800_bbp_write_with_rx_chain(rt2x00dev, 66, reg);
 
rt2800_iq_calibrate(rt2x00dev, rf->channel);
-- 
2.7.5



[PATCH 1/4] rt2800: enable TX_PIN_CFG_LNA_PE_ bits per band

2018-10-10 Thread Stanislaw Gruszka
Do not enable TX_PIN_CFG_LNA_PE_A* bits for 2.4GHz band and
vice versa TX_PIN_CFG_LNA_PE_G* bits for 5GHz.

Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c 
b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 170e7c87f7bc..44b94120053b 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -3891,18 +3891,24 @@ static void rt2800_config_channel(struct rt2x00_dev 
*rt2x00dev,
switch (rt2x00dev->default_ant.rx_chain_num) {
case 3:
/* Turn on tertiary LNAs */
-   rt2x00_set_field32(_pin, TX_PIN_CFG_LNA_PE_A2_EN, 1);
-   rt2x00_set_field32(_pin, TX_PIN_CFG_LNA_PE_G2_EN, 1);
+   rt2x00_set_field32(_pin, TX_PIN_CFG_LNA_PE_A2_EN,
+  rf->channel > 14);
+   rt2x00_set_field32(_pin, TX_PIN_CFG_LNA_PE_G2_EN,
+  rf->channel <= 14);
/* fall-through */
case 2:
/* Turn on secondary LNAs */
-   rt2x00_set_field32(_pin, TX_PIN_CFG_LNA_PE_A1_EN, 1);
-   rt2x00_set_field32(_pin, TX_PIN_CFG_LNA_PE_G1_EN, 1);
+   rt2x00_set_field32(_pin, TX_PIN_CFG_LNA_PE_A1_EN,
+  rf->channel > 14);
+   rt2x00_set_field32(_pin, TX_PIN_CFG_LNA_PE_G1_EN,
+  rf->channel <= 14);
/* fall-through */
case 1:
/* Turn on primary LNAs */
-   rt2x00_set_field32(_pin, TX_PIN_CFG_LNA_PE_A0_EN, 1);
-   rt2x00_set_field32(_pin, TX_PIN_CFG_LNA_PE_G0_EN, 1);
+   rt2x00_set_field32(_pin, TX_PIN_CFG_LNA_PE_A0_EN,
+  rf->channel > 14);
+   rt2x00_set_field32(_pin, TX_PIN_CFG_LNA_PE_G0_EN,
+  rf->channel <= 14);
break;
}
 
-- 
2.7.5



[PATCH 2/4] rt2800: enable TX_PIN_CFG_RFRX_EN only for MT7620

2018-10-10 Thread Stanislaw Gruszka
The TX_PIN_CFG_RFRX_EN bit was not set on other devices than MT7620,
restore old behavaviour since setting this bit maight not be
correct for older devices.

Fixes: 41977e86c984 ("rt2x00: add support for MT7620")
Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c 
b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 44b94120053b..acbd9d4a8a3a 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -3856,10 +3856,12 @@ static void rt2800_config_channel(struct rt2x00_dev 
*rt2x00dev,
if (rt2x00_rt(rt2x00dev, RT3572))
rt2800_rfcsr_write(rt2x00dev, 8, 0);
 
-   if (rt2x00_rt(rt2x00dev, RT6352))
+   if (rt2x00_rt(rt2x00dev, RT6352)) {
tx_pin = rt2800_register_read(rt2x00dev, TX_PIN_CFG);
-   else
+   rt2x00_set_field32(_pin, TX_PIN_CFG_RFRX_EN, 1);
+   } else {
tx_pin = 0;
+   }
 
switch (rt2x00dev->default_ant.tx_chain_num) {
case 3:
@@ -3914,7 +3916,6 @@ static void rt2800_config_channel(struct rt2x00_dev 
*rt2x00dev,
 
rt2x00_set_field32(_pin, TX_PIN_CFG_RFTR_EN, 1);
rt2x00_set_field32(_pin, TX_PIN_CFG_TRSW_EN, 1);
-   rt2x00_set_field32(_pin, TX_PIN_CFG_RFRX_EN, 1); /* mt7620 */
 
rt2800_register_write(rt2x00dev, TX_PIN_CFG, tx_pin);
 
-- 
2.7.5



[PATCH 0/4] rt2800: more register programing tweaks

2018-10-10 Thread Stanislaw Gruszka
This is on top of previous post:
https://marc.info/?l=linux-wireless=153908617400582=2

Stanislaw Gruszka (4):
  rt2800: enable TX_PIN_CFG_LNA_PE_ bits per band
  rt2800: enable TX_PIN_CFG_RFRX_EN only for MT7620
  rt2800: remove unneeded RT6352 check
  rt2800: comment and simplify AGC init for RT6352

 drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 37 --
 1 file changed, 23 insertions(+), 14 deletions(-)

-- 
2.7.5



[PATCH 3/4] rt2800: remove unneeded RT6352 check

2018-10-10 Thread Stanislaw Gruszka
Remove rt2x00_rt(rt2x00dev, RT6352)) check from
rt2800_config_channel_rf53xx() which is not called for RT6352 devices.

Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c 
b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index acbd9d4a8a3a..a2cdd3a5034a 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -3037,8 +3037,7 @@ static void rt2800_config_channel_rf53xx(struct 
rt2x00_dev *rt2x00dev,
rt2800_rfcsr_write(rt2x00dev, 59,
   r59_nonbt_rev[idx]);
} else if (rt2x00_rt(rt2x00dev, RT5390) ||
-  rt2x00_rt(rt2x00dev, RT5392) ||
-  rt2x00_rt(rt2x00dev, RT6352)) {
+  rt2x00_rt(rt2x00dev, RT5392)) {
static const char r59_non_bt[] = {0x8f, 0x8f,
0x8f, 0x8f, 0x8f, 0x8f, 0x8f, 0x8d,
0x8a, 0x88, 0x88, 0x87, 0x87, 0x86};
-- 
2.7.5



Re: [PATCH v3 4/4] rt2800: fix registers init for MT7620

2018-10-10 Thread Stanislaw Gruszka
On Wed, Oct 10, 2018 at 04:11:12PM +0200, Tom Psyborg wrote:
> case 1:
> 
>   } else if (rt2x00_rt(rt2x00dev, RT5390) ||
>  rt2x00_rt(rt2x00dev, RT5392)) {
>   rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x0404);
>   rt2800_register_write(rt2x00dev, TX_SW_CFG1, 0x00080606);
>   rt2800_register_write(rt2x00dev, TX_SW_CFG2, 0x);
>   } else if (rt2x00_rt(rt2x00dev, RT5592)) {
>   rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x0404);
>   rt2800_register_write(rt2x00dev, TX_SW_CFG1, 0x);
>   rt2800_register_write(rt2x00dev, TX_SW_CFG2, 0x);
>   } else if (rt2x00_rt(rt2x00dev, RT5350)) {
>   rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x0404);
>   } else if (rt2x00_rt(rt2x00dev, RT6352)) {
>   rt2800_register_write(rt2x00dev, MIMO_PS_CFG, 0x0002);
>   rt2800_register_write(rt2x00dev, TX_PIN_CFG, 0x00150F0F);
>   rt2800_register_write(rt2x00dev, TX_ALC_VGA3, 0x06060606);
>   rt2800_register_write(rt2x00dev, TX0_BB_GAIN_ATTEN, 0x0);
>   rt2800_register_write(rt2x00dev, TX1_BB_GAIN_ATTEN, 0x0);
>   rt2800_register_write(rt2x00dev, TX0_RF_GAIN_ATTEN, 0x6C6C666C);
>   rt2800_register_write(rt2x00dev, TX1_RF_GAIN_ATTEN, 0x6C6C666C);
> 
> does your 6352 wifi work?
> 
> case 2:
> 
>   } else if (rt2x00_rt(rt2x00dev, RT5390) ||
>  rt2x00_rt(rt2x00dev, RT5392)) {
>   } else if (rt2x00_rt(rt2x00dev, RT5592)) {
>   rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x0404);
>   rt2800_register_write(rt2x00dev, TX_SW_CFG1, 0x);
>   rt2800_register_write(rt2x00dev, TX_SW_CFG2, 0x);
>   } else if (rt2x00_rt(rt2x00dev, RT5350)) {
>   rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x0404);
>   } else if (rt2x00_rt(rt2x00dev, RT6352)) {
>   rt2800_register_write(rt2x00dev, MIMO_PS_CFG, 0x0002);
>   rt2800_register_write(rt2x00dev, TX_PIN_CFG, 0x00150F0F);
>   rt2800_register_write(rt2x00dev, TX_ALC_VGA3, 0x06060606);
>   rt2800_register_write(rt2x00dev, TX0_BB_GAIN_ATTEN, 0x0);
>   rt2800_register_write(rt2x00dev, TX1_BB_GAIN_ATTEN, 0x0);
>   rt2800_register_write(rt2x00dev, TX0_RF_GAIN_ATTEN, 0x6C6C666C);
>   rt2800_register_write(rt2x00dev, TX1_RF_GAIN_ATTEN, 0x6C6C666C);
> 
> does your 6352 wifi still work?

I checked 'case 2' (on my 'rt2x00' branch on top of 'openwrt-18.06'):

https://github.com/sgruszka/openwrt/commit/8abecc22605bd0221022673a3671201256cff72b

wifi still does work on my MT7620 router with above change and print
is correct.

If it does not work for you, we have to figure this out. Maybe there are
extra patches that broke things or there are some race conditions when
setting "rt =" . Hard to tell. Perhaps you could provide dmesg 
from router where is does not work ?

Thanks
Stanislaw


  1   2   3   4   5   6   7   8   >