linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stanislaw Gruszka <sgruszka@redhat.com>
To: Felix Fietkau <nbd@nbd.name>
Cc: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>,
	linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: [RFC/RFT 1/4] mt76x02: configure basic rates and fallback on STA mode
Date: Fri, 7 Dec 2018 14:25:01 +0100	[thread overview]
Message-ID: <20181207132501.GA3454@redhat.com> (raw)
In-Reply-To: <d89224d5-da5b-a4ac-d6a8-7d9f5cdf779d@nbd.name>

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

  reply	other threads:[~2018-12-07 13:25 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-08 14:47 [RFC/RFT 0/4] restore some old mt76x0u behaviour Stanislaw Gruszka
2018-11-08 14:47 ` [RFC/RFT 1/4] mt76x02: configure basic rates and fallback on STA mode Stanislaw Gruszka
2018-11-08 14:58   ` Lorenzo Bianconi
2018-11-08 15:52     ` Stanislaw Gruszka
2018-11-08 16:02       ` Felix Fietkau
2018-12-07 13:25         ` Stanislaw Gruszka [this message]
2018-11-08 14:47 ` [RFC/RFT 2/4] mt76x02: reserve wcid 0 for global traffic Stanislaw Gruszka
2018-11-08 15:01   ` Lorenzo Bianconi
2018-11-08 15:54     ` Stanislaw Gruszka
2018-11-08 16:05       ` Felix Fietkau
2018-11-08 14:47 ` [RFC/RFT 3/4] mt76x02: do not set protection on set_rts_threshold callback Stanislaw Gruszka
2018-11-09  9:23   ` Lorenzo Bianconi
2018-12-04 10:45     ` Stanislaw Gruszka
2018-12-04 11:50       ` Stanislaw Gruszka
2018-11-08 14:47 ` [RFC/RFT 4/4] mt76x02: set protection according to ht capabilities Stanislaw Gruszka
2018-11-09  9:29   ` Lorenzo Bianconi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181207132501.GA3454@redhat.com \
    --to=sgruszka@redhat.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=lorenzo.bianconi@redhat.com \
    --cc=nbd@nbd.name \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).