Re: [PATCH RFC v5 3/4] mac80211: Add airtime accounting and scheduling to TXQs
On 2018-10-09 05:32, Toke Høiland-Jørgensen wrote:
This adds airtime accounting and scheduling to the mac80211 TXQ
scheduler. A new callback, ieee80211_sta_register_airtime(), is added
that drivers can call to report airtime usage for stations.
When airtime information is present, mac80211 will schedule TXQs
(through ieee80211_next_txq()) in a way that enforces airtime fairness
between active stations. This scheduling works the same way as the
ath9k
in-driver airtime fairness scheduling. If no airtime usage is reported
by the driver, the scheduler will default to round-robin scheduling.
For drivers that don't control TXQ scheduling in software, a new API
function, ieee80211_txq_may_transmit(), is added which the driver can
use
to check if the TXQ is eligible for transmission, or should be
throttled to
enforce fairness. Calls to this function must also be enclosed in
ieee80211_txq_schedule_{start,end}() calls to ensure proper locking.
TXQs
that are throttled by ieee802111_txq_may_transmit() will be woken up
again
by a check added to the ieee80211_wake_txqs() tasklet.
Toke,
I am observing soft lockup issues again with this new series while
running
traffic with 50 clients. I am continuing testing with earlier series
along with
snippet I shared. When driver operates in pull-mode, throttled txqs are
marked
and refilled in airtime_tasklet. This is causing major throughput drops
and
packet loss and I am suspecting the latency in replenishing deficit.
Whereas in push-mode or in ath9k model, refill happens quicker at every
packet
indication as well as tx completion.
I am planning to get rid of tasklet completely as it is only meant for
pull-mode.
It would be better to refill in may_transmit() itself.
-Rajkumar
Re: [PATCH] mac80211_hwsim: allow setting custom features/iftypes
James Prestwood writes: > The current driver hard codes various features, ext features and supported > interface types when a new radio is created. This patch adds several new > hwsim attributes so user space can specify specific features the radio should > have: > > - HWSIM_ATTR_FEATURE_SUPPORT > Bit field of nl80211_feature_flags flags > - HWSIM_ATTR_EXT_FEATURE_SUPPORT > Variable length bit field where bits map to nl80211_ext_feature_index > values. > - HWSIM_ATTR_IFTYPE_SUPPORT > Nested attribute of flags containing all supported interface types. > Each flag attribute sets support for an interface type. > > Each attribute data format matches a corresponding NL80211 attribute: > > HWSIM_ATTR_FEATURE_SUPPORT --> NL80211_ATTR_FEATURE_FLAGS > HWSIM_ATTR_EXT_FEATURE_SUPPORT --> NL80211_ATTR_EXT_FEATURES > HWSIM_ATTR_IFTYPE_SUPPORT --> NL80211_ATTR_SUPPORTED_IFTYPES Signed-off-by is missing. https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#signed-off-by_missing -- Kalle Valo
Re: [PATCH v2 1/4] rt2x00: remove unneeded check
Hi Tomislav,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on wireless-drivers-next/master]
[also build test ERROR on v4.19-rc7 next-20181009]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Stanislaw-Gruszka/rt2x00-remove-unneeded-check/20181010-012334
base:
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git
master
config: openrisc-allmodconfig (attached as .config)
compiler: or1k-linux-gcc (GCC) 6.0.0 20160327 (experimental)
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=openrisc
All errors (new ones prefixed by >>):
drivers/net/wireless/ralink/rt2x00/rt2800lib.c: In function
'rt2800_config_channel_rf3290':
drivers/net/wireless/ralink/rt2x00/rt2800lib.c:2881:6: warning: unused
variable 'idx' [-Wunused-variable]
int idx = rf->channel-1;
^~~
drivers/net/wireless/ralink/rt2x00/rt2800lib.c: In function
'rt2800_config_channel_rf53xx':
>> drivers/net/wireless/ralink/rt2x00/rt2800lib.c:3016:20: error: 'idx'
>> undeclared (first use in this function)
r55_bt_rev[idx]);
^~~
drivers/net/wireless/ralink/rt2x00/rt2800lib.c:3016:20: note: each
undeclared identifier is reported only once for each function it appears in
vim +/idx +3016 drivers/net/wireless/ralink/rt2x00/rt2800lib.c
0c9e5fb91 drivers/net/wireless/rt2x00/rt2800lib.cStanislaw Gruszka
2013-03-16 2875
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2876 static void rt2800_config_channel_rf3290(struct rt2x00_dev
*rt2x00dev,
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2877 struct ieee80211_conf
*conf,
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2878 struct rf_channel *rf,
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2879 struct channel_info *info)
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2880 {
64cc6975c drivers/net/wireless/ralink/rt2x00/rt2800lib.c Tomislav Požega
2018-10-09 @2881 int idx = rf->channel-1;
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2882 u8 rfcsr;
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2883
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2884 rt2800_rfcsr_write(rt2x00dev, 8, rf->rf1);
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2885 rt2800_rfcsr_write(rt2x00dev, 9, rf->rf3);
16d571bb0 drivers/net/wireless/ralink/rt2x00/rt2800lib.c Arnd Bergmann
2017-05-17 2886 rfcsr = rt2800_rfcsr_read(rt2x00dev, 11);
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2887 rt2x00_set_field8(, RFCSR11_R, rf->rf2);
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2888 rt2800_rfcsr_write(rt2x00dev, 11, rfcsr);
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2889
16d571bb0 drivers/net/wireless/ralink/rt2x00/rt2800lib.c Arnd Bergmann
2017-05-17 2890 rfcsr = rt2800_rfcsr_read(rt2x00dev, 49);
7573cb5b4 drivers/net/wireless/rt2x00/rt2800lib.cStanislaw Gruszka
2012-07-09 2891 if (info->default_power1 > POWER_BOUND)
7573cb5b4 drivers/net/wireless/rt2x00/rt2800lib.cStanislaw Gruszka
2012-07-09 2892 rt2x00_set_field8(, RFCSR49_TX, POWER_BOUND);
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2893 else
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2894 rt2x00_set_field8(, RFCSR49_TX,
info->default_power1);
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2895 rt2800_rfcsr_write(rt2x00dev, 49, rfcsr);
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2896
884525411 drivers/net/wireless/ralink/rt2x00/rt2800lib.c Stanislaw Gruszka
2016-12-19 2897 rt2800_freq_cal_mode1(rt2x00dev);
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2898
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2899 if (rf->channel <= 14) {
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2900 if (rf->
Inquiry 09-10-2018
Hi,friend, This is Daniel Murray and i am from Sinara Group Co.Ltd Group Co.,LTD in Russia. We are glad to know about your company from the web and we are interested in your products. Could you kindly send us your Latest catalog and price list for our trial order. Best Regards, Daniel Murray Purchasing Manager
Re: [PATCH v3 4/4] rt2800: fix registers init for MT7620
On 09/10/2018, Stanislaw Gruszka wrote:
> There is dupliceted 'if (rt2x00_rt(rt2x00dev, RT6352))' entry that couses
> we do not perform proper register initaliztion for RT6352 (MT7620 SOCs).
>
> Reported-by: Tomislav Požega
> 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 daf20d7424ac..170e7c87f7bc 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);
> --
> 2.7.5
>
>
have you got chance to test
https://github.com/psyborg55/linux/commit/24b46d482590a87553df1de0b5c8032f363cb7cf
?
using this code to determine 7620 soc
if (rt == RT5390 && rt2x00_is_soc(rt2x00dev))
rt = RT6352;
somehow did not work in rt2800_init_registers routine. i could verify
that by removing tx_sw_cfg registers from rt6352 and the wifi would
still work, unless removed them from rt5390 also
Re: [PATCH 1/5] rt2x00: set registers based on current band
On 09/10/2018, Stanislaw Gruszka wrote: > Patches 3-5 looks ok to me, I'll rebase and resend them. > > Thanks > Stanislaw > and what about patches 1-2 ? did you find any regression?
Re: [PATCH v2 1/4] rt2x00: remove unneeded check
Hi Tomislav,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on wireless-drivers-next/master]
[also build test ERROR on v4.19-rc7 next-20181009]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Stanislaw-Gruszka/rt2x00-remove-unneeded-check/20181010-012334
base:
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git
master
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/net/wireless/ralink/rt2x00/rt2800lib.c: In function
'rt2800_config_channel_rf3290':
drivers/net/wireless/ralink/rt2x00/rt2800lib.c:2881:6: warning: unused
variable 'idx' [-Wunused-variable]
int idx = rf->channel-1;
^~~
drivers/net/wireless/ralink/rt2x00/rt2800lib.c: In function
'rt2800_config_channel_rf53xx':
>> drivers/net/wireless/ralink/rt2x00/rt2800lib.c:3016:20: error: 'idx'
>> undeclared (first use in this function); did you mean 'ida'?
r55_bt_rev[idx]);
^~~
ida
drivers/net/wireless/ralink/rt2x00/rt2800lib.c:3016:20: note: each
undeclared identifier is reported only once for each function it appears in
vim +3016 drivers/net/wireless/ralink/rt2x00/rt2800lib.c
0c9e5fb91 drivers/net/wireless/rt2x00/rt2800lib.cStanislaw Gruszka
2013-03-16 2875
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2876 static void rt2800_config_channel_rf3290(struct rt2x00_dev
*rt2x00dev,
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2877 struct ieee80211_conf
*conf,
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2878 struct rf_channel *rf,
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2879 struct channel_info *info)
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2880 {
64cc6975c drivers/net/wireless/ralink/rt2x00/rt2800lib.c Tomislav Požega
2018-10-09 @2881 int idx = rf->channel-1;
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2882 u8 rfcsr;
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2883
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2884 rt2800_rfcsr_write(rt2x00dev, 8, rf->rf1);
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2885 rt2800_rfcsr_write(rt2x00dev, 9, rf->rf3);
16d571bb0 drivers/net/wireless/ralink/rt2x00/rt2800lib.c Arnd Bergmann
2017-05-17 2886 rfcsr = rt2800_rfcsr_read(rt2x00dev, 11);
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2887 rt2x00_set_field8(, RFCSR11_R, rf->rf2);
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2888 rt2800_rfcsr_write(rt2x00dev, 11, rfcsr);
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2889
16d571bb0 drivers/net/wireless/ralink/rt2x00/rt2800lib.c Arnd Bergmann
2017-05-17 2890 rfcsr = rt2800_rfcsr_read(rt2x00dev, 49);
7573cb5b4 drivers/net/wireless/rt2x00/rt2800lib.cStanislaw Gruszka
2012-07-09 2891 if (info->default_power1 > POWER_BOUND)
7573cb5b4 drivers/net/wireless/rt2x00/rt2800lib.cStanislaw Gruszka
2012-07-09 2892 rt2x00_set_field8(, RFCSR49_TX, POWER_BOUND);
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2893 else
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2894 rt2x00_set_field8(, RFCSR49_TX,
info->default_power1);
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2895 rt2800_rfcsr_write(rt2x00dev, 49, rfcsr);
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2896
884525411 drivers/net/wireless/ralink/rt2x00/rt2800lib.c Stanislaw Gruszka
2016-12-19 2897 rt2800_freq_cal_mode1(rt2x00dev);
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2898
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2899 if (rf->channel <= 14) {
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2900 if (rf->channel == 6)
a89534eda drivers/net/wireless/rt2x00/rt2800lib.cWoody Hung
2012-06-13 2901 rt2800_bb
Re: [PATCH] mac80211_hwsim: allow setting custom features/iftypes
On Tue, 2018-10-09 at 22:47 +0200, Johannes Berg wrote:
> On Tue, 2018-10-09 at 13:42 -0700, James Prestwood wrote:
>
> > > In general, I guess what would work is to be able to *restrict*
> > > the
> > > advertised features over what's currently the case, but I suspect
> > > that's not something that would be so very much useful for you
> > > (unless we
> > > also add more features to hwsim).
> >
> > Actually this would work perfectly. Just being able to
> > disable/restrict
> > features will work fine. I can change the attribute to take a mask
> > of
> > disabled/enabled features, but only features that hwsim actually
> > supports.
>
> Well I guess you really only need *disabled* ones since the default
> would remain to have all enabled, and you can't change them on the
> fly,
> only set them at radio creation, right?
Yes, disabling features is really what we needed ultimately. And
changing them on the fly is not needed.
>
> > The reason I did it this way was to follow how NL80211 packaged up
> > iftype support (NL80211_ATTR_SUPPORTED_IFTYPES).
>
> Ok, but I still think a bitmap would make more sense, back then for
> some
> reason I/we didn't (like to) do bitmaps, but these days I think it's
> the
> much better representation.
>
> > We could model this
> > after how we want the feature support, where we only allow
> > disabling/enabling features/iftypes that are already supported in
> > the
> > default configuration. So, for iftypes, my code could remain the
> > same
> > where I build up a mask of iftypes, but then AND that with a the
> > default configuration.
>
> Sort of.
>
> Yes, I think we would want to have a list/mask of *enabled*
> (extended)
> features/interface types, unlike what I said above to just have a
> mask
> of disabled features; if we do a mask of disabled ones then one
> basically has to list all current and *future ones* to have
> predictable
> output, that's not going to be feasible.
>
> So yes, we want a list of *enabled* ones.
>
> However, I think we want to reject configurations that list more
> enabled
> features than we currently support, because otherwise again you end
> up
> with unpredictability if the hwsim version changes underneath your
> tool
> or test case.
Ok, yeah this makes sense.
>
> So I think the algorithm should be:
>
> valid_features = ;
> enabled_features = nla_get_whatever(...);
>
> if (enabled_features & ~valid_features) {
> NL_SET_ERR_ATTR_MSG(...);
> return -EINVAL;
> }
>
> // use enabled_features instead of the current list later
Ok, thanks for your help/suggestions. Ill get a patch together with the
talked about changes.
>
> johannes
Re: brcmfmac with BCM4359 on arm64 (RK3399) and SDIO
Hi Franky, thank's for your help. As the BCM4359 is already supported (as PCIe device) in the brcmfmac driver, I assumed that base addresses will be correct. But having a closer look it is indeed the problematic part. I've temporary fixed the return value in brcmf_chip_tcm_rambase to the one matching the DHD's output and the SDIO errors are gone: bcmdhd (4.4): [ 15.701860] dhdsdio_write_vars: varaddr=0x23f1e8 [ 15.707024] dhdsdio_write_vars: varsize=3604 [ 15.711830] dhdsdio_write_vars: bus->dongle_ram_base=0x16 [ 15.718221] dhdsdio_write_vars: bus->ramsize=917504 [ 15.723649] dhdsdio_write_vars: bus->varsz=3601 [ 15.752063] dhdsdio_write_vars: Download, Upload and compare of NVRAM succeeded. brcmfmac (4.19): [7.773752] brcmf_sdio_download_nvram: address=0x25f1f0 [7.782824] brcmf_sdio_download_nvram: bus->ci->ramsize=917504 [7.792544] brcmf_sdio_download_nvram: varsz=3600 [7.800926] brcmf_sdio_download_nvram: bus->ci->rambase=0x18 [7.816106] brcmfmac: brcmf_sdiod_ramrw: membytes transfer failed [7.835253] brcmfmac: brcmf_sdio_verifymemory: error -84 on reading 2048 membytes at 0x0025f1f0 brcmfmac (4.19-fixedoffset): [7.625436] brcmf_sdio_download_nvram: address=0x23f1f0 [7.634582] brcmf_sdio_download_nvram: bus->ci->ramsize=917504 [7.644284] brcmf_sdio_download_nvram: varsz=3600 [7.652641] brcmf_sdio_download_nvram: bus->ci->rambase=0x16 Unfortunately I still don't get a wlan0 interface (and more important: no error message from the brcmfmac driver). I'm now trying to get brcmfmac's tracing features up and running to see where the driver got stuck. Anyways, thank you very much so far. BR Christoph On 10/9/18 8:59 PM, Franky Lin wrote: > Hi Christoph, > > On Tue, Oct 9, 2018 at 11:10 AM Christoph Müllner > wrote: >> >> Hi Arend, >> >> recently I got an SDIO module, which includes a BCM4359. >> I tried to get it up and running via the SD card interface >> on a RK3399 SoC and succeeded in doing so with >> bcmdhd.1.579.77.41.x and a vendor kernel (based on Linux 4.4). >> All that was necessary was configure BCMDHD to run with >> in-band IRQs and use a GPIO as gpio_wl_reg_on. >> >> Since I can run a mainline kernel as well, I gave it a try and >> tried brcmfmac on Linux 4.19-rc7. As the BCM4359 is not in >> the list of supported SDIO devices, but is supported USB device, >> I've created a patch (attached), which adds the support for that device. >> Additionally I've patched my DTS to include the WL_REG_ON >> pin as part of mmc-pwrseq-simple's reset-gpios and added >> a bcm4329-fmac node in the mmc node. >> >> During bootup I see messages from brcmfmac, which indicate >> that the BCM4359 has been found, but loading the nvram file >> continuously fails: >> >>> [5.993741] brcmfmac: brcmf_fw_alloc_request: using >>> brcm/brcmfmac4359-sdio for chip BCM4359/9 >>> [...] >>> [7.987167] brcmfmac: brcmf_sdiod_ramrw: membytes transfer failed >>> [8.008715] brcmfmac: brcmf_sdio_verifymemory: error -84 on reading 2048 >>> membytes at 0x0025f1f0 >>> [8.021182] brcmfmac: brcmf_sdio_download_firmware: dongle nvram file >>> download failed > > Does it always fail at nvram verification? If so please help to get > the address and varsz in brcmf_sdio_download_nvram. Also their > equivalent in bcmdhd which should be varaddr and varsize in > dhdsdio_write_vars. > > Thanks, > --Franky > >> That -84 means EILSEQ, which is the error value, which represents >> a CRC error during SDIO data exchange (returned by the function >> dw_mci_data_complete() >> in the MMC driver). >> >> To address this, I've reduced the clock speed (in several steps) to 400 kHz >> (and verified the clock signal on an oscilloscope), but the issue persists. >> I've also tried to use Linux 4.14.74, where I see the same issue. >> >> I can confirm that the MMC interface works in general (I can use an SD card >> to host my rootfs). >> >> FWIW I'm using the same exact same firmware and nvram file for the DHD driver >> and the brcmfmac. >> >> Do you have any ideas how to debug this issue? >> >> Thanks, >> Christoph >> >> >> >> -- >> Christoph Müllner >> Theobroma Systems Design und Consulting GmbH >> Seestadtstraße 27 (Aspern IQ), 1220 Wien, Austria >> Phone: +43 1 236 98 93-409, Fax: +43 1 236 98 93-9 >> http://www.theobroma-systems.com >> >> >> >>
Re: [PATCH] mac80211_hwsim: allow setting custom features/iftypes
On Tue, 2018-10-09 at 13:42 -0700, James Prestwood wrote:
> > In general, I guess what would work is to be able to *restrict* the
> > advertised features over what's currently the case, but I suspect
> > that's not something that would be so very much useful for you (unless we
> > also add more features to hwsim).
>
> Actually this would work perfectly. Just being able to disable/restrict
> features will work fine. I can change the attribute to take a mask of
> disabled/enabled features, but only features that hwsim actually
> supports.
Well I guess you really only need *disabled* ones since the default
would remain to have all enabled, and you can't change them on the fly,
only set them at radio creation, right?
> The reason I did it this way was to follow how NL80211 packaged up
> iftype support (NL80211_ATTR_SUPPORTED_IFTYPES).
Ok, but I still think a bitmap would make more sense, back then for some
reason I/we didn't (like to) do bitmaps, but these days I think it's the
much better representation.
> We could model this
> after how we want the feature support, where we only allow
> disabling/enabling features/iftypes that are already supported in the
> default configuration. So, for iftypes, my code could remain the same
> where I build up a mask of iftypes, but then AND that with a the
> default configuration.
Sort of.
Yes, I think we would want to have a list/mask of *enabled* (extended)
features/interface types, unlike what I said above to just have a mask
of disabled features; if we do a mask of disabled ones then one
basically has to list all current and *future ones* to have predictable
output, that's not going to be feasible.
So yes, we want a list of *enabled* ones.
However, I think we want to reject configurations that list more enabled
features than we currently support, because otherwise again you end up
with unpredictability if the hwsim version changes underneath your tool
or test case.
So I think the algorithm should be:
valid_features = ;
enabled_features = nla_get_whatever(...);
if (enabled_features & ~valid_features) {
NL_SET_ERR_ATTR_MSG(...);
return -EINVAL;
}
// use enabled_features instead of the current list later
johannes
Re: [PATCH] mac80211_hwsim: allow setting custom features/iftypes
On Tue, 2018-10-09 at 22:13 +0200, Johannes Berg wrote:
> On Tue, 2018-10-09 at 13:12 -0700, James Prestwood wrote:
>
> > Ok, that makes sense. The intent here was to test logic for
> > detecting
> > and handling supported driver features/iftypes, rather than
> > actually
> > using the features. But I do understand it would be strange for
> > anyone
> > trying to enable a feature, to find that all it does it set a
> > feature
> > bit (although this is exactly what we want :)).
>
> :-)
>
> In general, I guess what would work is to be able to *restrict* the
> advertised features over what's currently the case, but I suspect
> that's
> not something that would be so very much useful for you (unless we
> also
> add more features to hwsim).
Actually this would work perfectly. Just being able to disable/restrict
features will work fine. I can change the attribute to take a mask of
disabled/enabled features, but only features that hwsim actually
supports.
>
> > Would it be acceptable
> > (for now at least) if we just included the iftype piece? I can pull
> > that out into a new patch if so.
>
> As written, it doesn't make much sense, but again you could restrict
> the
> feature set? There are also the pure software feature types etc., and
> mac80211 will add those in some cases.
>
> Similar to the features though, you wouldn't want to advertise e.g.
> NAN
> over hwsim, since that requires special operations to be implemented.
>
> I guess here also I could see perhaps a way to restrict the interface
> types could be worthwhile?
>
> Though I'd do the implementation with a single u32 attribute with a
> bitmap, rather than the massive nested flags. Which, btw, you
> should've
> used the nested policy support for that I added recently in commit
> 9a659a35ba17 ("netlink: allow NLA_NESTED to specify nested policy to
> validate"), but that point is of course moot if we don't want to do a
> nested attribute :-)
The reason I did it this way was to follow how NL80211 packaged up
iftype support (NL80211_ATTR_SUPPORTED_IFTYPES). We could model this
after how we want the feature support, where we only allow
disabling/enabling features/iftypes that are already supported in the
default configuration. So, for iftypes, my code could remain the same
where I build up a mask of iftypes, but then AND that with a the
default configuration.
Thanks,
James
>
> johannes
Re: [PATCH] mac80211_hwsim: allow setting custom features/iftypes
On Tue, 2018-10-09 at 13:12 -0700, James Prestwood wrote:
> Ok, that makes sense. The intent here was to test logic for detecting
> and handling supported driver features/iftypes, rather than actually
> using the features. But I do understand it would be strange for anyone
> trying to enable a feature, to find that all it does it set a feature
> bit (although this is exactly what we want :)).
:-)
In general, I guess what would work is to be able to *restrict* the
advertised features over what's currently the case, but I suspect that's
not something that would be so very much useful for you (unless we also
add more features to hwsim).
> Would it be acceptable
> (for now at least) if we just included the iftype piece? I can pull
> that out into a new patch if so.
As written, it doesn't make much sense, but again you could restrict the
feature set? There are also the pure software feature types etc., and
mac80211 will add those in some cases.
Similar to the features though, you wouldn't want to advertise e.g. NAN
over hwsim, since that requires special operations to be implemented.
I guess here also I could see perhaps a way to restrict the interface
types could be worthwhile?
Though I'd do the implementation with a single u32 attribute with a
bitmap, rather than the massive nested flags. Which, btw, you should've
used the nested policy support for that I added recently in commit
9a659a35ba17 ("netlink: allow NLA_NESTED to specify nested policy to
validate"), but that point is of course moot if we don't want to do a
nested attribute :-)
johannes
Re: [PATCH] mac80211_hwsim: allow setting custom features/iftypes
On Tue, 2018-10-09 at 21:41 +0200, Johannes Berg wrote: > On Tue, 2018-10-09 at 10:48 -0700, James Prestwood wrote: > > The current driver hard codes various features, ext features and > > supported > > interface types when a new radio is created. This patch adds > > several new > > hwsim attributes so user space can specify specific features the > > radio should > > have: > > > > - HWSIM_ATTR_FEATURE_SUPPORT > > Bit field of nl80211_feature_flags flags > > - HWSIM_ATTR_EXT_FEATURE_SUPPORT > > Variable length bit field where bits map to > > nl80211_ext_feature_index > > values. > > - HWSIM_ATTR_IFTYPE_SUPPORT > > Nested attribute of flags containing all supported interface > > types. > > Each flag attribute sets support for an interface type. > > This seems rather wrong, most (extended) features require the > driver/device to actually *do* something. > > Let's say you enable NL80211_EXT_FEATURE_TXQS - but then nothing > actually happens when you try to configure those. Or let's say you > enable NL80211_FEATURE_TX_POWER_INSERTION but then nothing actually > happens when sending the frame... Ok, that makes sense. The intent here was to test logic for detecting and handling supported driver features/iftypes, rather than actually using the features. But I do understand it would be strange for anyone trying to enable a feature, to find that all it does it set a feature bit (although this is exactly what we want :)). Would it be acceptable (for now at least) if we just included the iftype piece? I can pull that out into a new patch if so. > > johannes
Re: [PATCH 03/19] wilc: add host_interface.h
On 10/09/2018 01:02 PM, Johannes Berg wrote: > On Tue, 2018-10-09 at 20:01 +, adham.aboza...@microchip.com wrote: >> >> Do you mean that it can also be used for probing specific networks even if >> they are broadcasting their SSID? > > Yes. > >> I think this might be a possible case if the user is trying to limit the >> scan results to a specific network. > > No. Don't do any filtering based on this. > > Basically the only thing you should do with the (list of) SSIDs is to > send a probe request containing each of them. Userspace/cfg80211 will > take care that the usual empty (wildcard) SSID is included in the list, > so don't send one with that by yourself, just iterate the list. > > If you only support sending one probe request in each scan request, then > set the max # of SSIDs supported to 1, otherwise set it to the maximum > (or a reasonable limit like 20 if it's in software). > > johannes > Thanks Johannes. It's clear now.
Re: [PATCH 03/19] wilc: add host_interface.h
On Tue, 2018-10-09 at 20:01 +, adham.aboza...@microchip.com wrote: > > Do you mean that it can also be used for probing specific networks even if > they are broadcasting their SSID? Yes. > I think this might be a possible case if the user is trying to limit the scan > results to a specific network. No. Don't do any filtering based on this. Basically the only thing you should do with the (list of) SSIDs is to send a probe request containing each of them. Userspace/cfg80211 will take care that the usual empty (wildcard) SSID is included in the list, so don't send one with that by yourself, just iterate the list. If you only support sending one probe request in each scan request, then set the max # of SSIDs supported to 1, otherwise set it to the maximum (or a reasonable limit like 20 if it's in software). johannes
Re: [PATCH 03/19] wilc: add host_interface.h
On 10/09/2018 12:14 PM, Johannes Berg wrote: > On Tue, 2018-10-09 at 18:36 +, adham.aboza...@microchip.com wrote: >> >> Johannes, is the cfg80211_scan_request.ssid used for something else >> other than specifying the hidden networks that the controller should >> scan for? > > Ahh, now I understand where you're coming from. > > Well, it's the SSID to include in the probe request(s), the most common > thing there is the 0-length wildcard, of course. > > So while it may be required for hidden networks, it's not strictly > related to that. Do you mean that it can also be used for probing specific networks even if they are broadcasting their SSID? I think this might be a possible case if the user is trying to limit the scan results to a specific network. > > johannes >
Re: [PATCH] mac80211_hwsim: allow setting custom features/iftypes
On Tue, 2018-10-09 at 10:48 -0700, James Prestwood wrote: > The current driver hard codes various features, ext features and supported > interface types when a new radio is created. This patch adds several new > hwsim attributes so user space can specify specific features the radio should > have: > > - HWSIM_ATTR_FEATURE_SUPPORT > Bit field of nl80211_feature_flags flags > - HWSIM_ATTR_EXT_FEATURE_SUPPORT > Variable length bit field where bits map to nl80211_ext_feature_index > values. > - HWSIM_ATTR_IFTYPE_SUPPORT > Nested attribute of flags containing all supported interface types. > Each flag attribute sets support for an interface type. This seems rather wrong, most (extended) features require the driver/device to actually *do* something. Let's say you enable NL80211_EXT_FEATURE_TXQS - but then nothing actually happens when you try to configure those. Or let's say you enable NL80211_FEATURE_TX_POWER_INSERTION but then nothing actually happens when sending the frame... johannes
Re: [PATCH 03/19] wilc: add host_interface.h
On Tue, 2018-10-09 at 18:36 +, adham.aboza...@microchip.com wrote: > > Johannes, is the cfg80211_scan_request.ssid used for something else > other than specifying the hidden networks that the controller should > scan for? Ahh, now I understand where you're coming from. Well, it's the SSID to include in the probe request(s), the most common thing there is the 0-length wildcard, of course. So while it may be required for hidden networks, it's not strictly related to that. johannes
Re: brcmfmac with BCM4359 on arm64 (RK3399) and SDIO
On 10/9/2018 8:10 PM, Christoph Müllner wrote: Hi Arend, recently I got an SDIO module, which includes a BCM4359. I tried to get it up and running via the SD card interface on a RK3399 SoC and succeeded in doing so with bcmdhd.1.579.77.41.x and a vendor kernel (based on Linux 4.4). All that was necessary was configure BCMDHD to run with in-band IRQs and use a GPIO as gpio_wl_reg_on. Since I can run a mainline kernel as well, I gave it a try and tried brcmfmac on Linux 4.19-rc7. As the BCM4359 is not in the list of supported SDIO devices, but is supported USB device, I've created a patch (attached), which adds the support for that device. Okay. However, I should say that there is no BCM4359 USB device. Regardless the patch looks okay. Additionally I've patched my DTS to include the WL_REG_ON pin as part of mmc-pwrseq-simple's reset-gpios and added a bcm4329-fmac node in the mmc node. During bootup I see messages from brcmfmac, which indicate that the BCM4359 has been found, but loading the nvram file continuously fails: [5.993741] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4359-sdio for chip BCM4359/9 [...] [7.987167] brcmfmac: brcmf_sdiod_ramrw: membytes transfer failed [8.008715] brcmfmac: brcmf_sdio_verifymemory: error -84 on reading 2048 membytes at 0x0025f1f0 [8.021182] brcmfmac: brcmf_sdio_download_firmware: dongle nvram file download failed That -84 means EILSEQ, which is the error value, which represents a CRC error during SDIO data exchange (returned by the function dw_mci_data_complete() in the MMC driver). Whenever I see -84 my suspicion are about power-supply for the chip. However, it may also be the mmc host driver not adhering to so-called "card busy" indication, which is in the SDIO spec. To address this, I've reduced the clock speed (in several steps) to 400 kHz (and verified the clock signal on an oscilloscope), but the issue persists. I've also tried to use Linux 4.14.74, where I see the same issue. I can confirm that the MMC interface works in general (I can use an SD card to host my rootfs). SD and SDIO are not the same thing. More importantly you have it working with bcmdhd on a vendor kernel. So start from there. FWIW I'm using the same exact same firmware and nvram file for the DHD driver and the brcmfmac. Noted. Do you have any ideas how to debug this issue? Would focus on getting logs from bcmdhd. Regards, Arend Thanks, Christoph
Re: brcmfmac with BCM4359 on arm64 (RK3399) and SDIO
Hi Christoph, On Tue, Oct 9, 2018 at 11:10 AM Christoph Müllner wrote: > > Hi Arend, > > recently I got an SDIO module, which includes a BCM4359. > I tried to get it up and running via the SD card interface > on a RK3399 SoC and succeeded in doing so with > bcmdhd.1.579.77.41.x and a vendor kernel (based on Linux 4.4). > All that was necessary was configure BCMDHD to run with > in-band IRQs and use a GPIO as gpio_wl_reg_on. > > Since I can run a mainline kernel as well, I gave it a try and > tried brcmfmac on Linux 4.19-rc7. As the BCM4359 is not in > the list of supported SDIO devices, but is supported USB device, > I've created a patch (attached), which adds the support for that device. > Additionally I've patched my DTS to include the WL_REG_ON > pin as part of mmc-pwrseq-simple's reset-gpios and added > a bcm4329-fmac node in the mmc node. > > During bootup I see messages from brcmfmac, which indicate > that the BCM4359 has been found, but loading the nvram file > continuously fails: > > > [5.993741] brcmfmac: brcmf_fw_alloc_request: using > > brcm/brcmfmac4359-sdio for chip BCM4359/9 > > [...] > > [7.987167] brcmfmac: brcmf_sdiod_ramrw: membytes transfer failed > > [8.008715] brcmfmac: brcmf_sdio_verifymemory: error -84 on reading 2048 > > membytes at 0x0025f1f0 > > [8.021182] brcmfmac: brcmf_sdio_download_firmware: dongle nvram file > > download failed Does it always fail at nvram verification? If so please help to get the address and varsz in brcmf_sdio_download_nvram. Also their equivalent in bcmdhd which should be varaddr and varsize in dhdsdio_write_vars. Thanks, --Franky > That -84 means EILSEQ, which is the error value, which represents > a CRC error during SDIO data exchange (returned by the function > dw_mci_data_complete() > in the MMC driver). > > To address this, I've reduced the clock speed (in several steps) to 400 kHz > (and verified the clock signal on an oscilloscope), but the issue persists. > I've also tried to use Linux 4.14.74, where I see the same issue. > > I can confirm that the MMC interface works in general (I can use an SD card > to host my rootfs). > > FWIW I'm using the same exact same firmware and nvram file for the DHD driver > and the brcmfmac. > > Do you have any ideas how to debug this issue? > > Thanks, > Christoph > > > > -- > Christoph Müllner > Theobroma Systems Design und Consulting GmbH > Seestadtstraße 27 (Aspern IQ), 1220 Wien, Austria > Phone: +43 1 236 98 93-409, Fax: +43 1 236 98 93-9 > http://www.theobroma-systems.com > > > >
Re: [PATCH 03/19] wilc: add host_interface.h
On 10/09/2018 05:18 AM, Ajay Singh wrote:
>
> On 10/9/2018 5:16 PM, Johannes Berg wrote:
>> On Tue, 2018-10-09 at 17:14 +0530, Ajay Singh wrote:
>>> On 10/9/2018 4:06 PM, Johannes Berg wrote:
On Tue, 2018-10-09 at 16:04 +0530, Ajay Singh wrote:
>>> +typedef void (*wilc_remain_on_chan_expired)(void *, u32);
>>> +typedef void (*wilc_remain_on_chan_ready)(void *);
> I think as per coding style the typedef for function pointer are allowed.
True, I guess, but why do you need them?
>>> Actually these function pointer are used in multiple places i.e inside
>>> the struct and also for passing as the argument for the function. So i
>>> think its better to keep them as typedef to simplify and avoid any 'line
>>> over 80 chars' checkpatch issue. But anyway if you suggest we can modify
>>> to remove these typedefs .
>> I guess that must be part of the internal bounce buffer mechanism? I
>> guess leave them for now and see what falls out.
>>
>>> +struct hidden_network {
>>>
>>> Yes, its not related to hidden SSID. Suppose cfg80211 scan is called
>>> with SSID information(active scan) then SSID info will be maintained in
>>> this structure.
>> so maybe rename this?
>>
> Yes, sure I will rename this struct.
>
> Regards,
> Ajay
>
Johannes, is the cfg80211_scan_request.ssid used for something else other than
specifying the hidden networks that the controller should scan for?
brcmfmac with BCM4359 on arm64 (RK3399) and SDIO
Hi Arend, recently I got an SDIO module, which includes a BCM4359. I tried to get it up and running via the SD card interface on a RK3399 SoC and succeeded in doing so with bcmdhd.1.579.77.41.x and a vendor kernel (based on Linux 4.4). All that was necessary was configure BCMDHD to run with in-band IRQs and use a GPIO as gpio_wl_reg_on. Since I can run a mainline kernel as well, I gave it a try and tried brcmfmac on Linux 4.19-rc7. As the BCM4359 is not in the list of supported SDIO devices, but is supported USB device, I've created a patch (attached), which adds the support for that device. Additionally I've patched my DTS to include the WL_REG_ON pin as part of mmc-pwrseq-simple's reset-gpios and added a bcm4329-fmac node in the mmc node. During bootup I see messages from brcmfmac, which indicate that the BCM4359 has been found, but loading the nvram file continuously fails: > [5.993741] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4359-sdio > for chip BCM4359/9 > [...] > [7.987167] brcmfmac: brcmf_sdiod_ramrw: membytes transfer failed > [8.008715] brcmfmac: brcmf_sdio_verifymemory: error -84 on reading 2048 > membytes at 0x0025f1f0 > [8.021182] brcmfmac: brcmf_sdio_download_firmware: dongle nvram file > download failed That -84 means EILSEQ, which is the error value, which represents a CRC error during SDIO data exchange (returned by the function dw_mci_data_complete() in the MMC driver). To address this, I've reduced the clock speed (in several steps) to 400 kHz (and verified the clock signal on an oscilloscope), but the issue persists. I've also tried to use Linux 4.14.74, where I see the same issue. I can confirm that the MMC interface works in general (I can use an SD card to host my rootfs). FWIW I'm using the same exact same firmware and nvram file for the DHD driver and the brcmfmac. Do you have any ideas how to debug this issue? Thanks, Christoph 0001-brcmfmac-Add-SDIO-support-for-BCM4359.patch Description: Binary data -- Christoph Müllner Theobroma Systems Design und Consulting GmbH Seestadtstraße 27 (Aspern IQ), 1220 Wien, Austria Phone: +43 1 236 98 93-409, Fax: +43 1 236 98 93-9 http://www.theobroma-systems.com
[PATCH] mac80211_hwsim: allow setting custom features/iftypes
The current driver hard codes various features, ext features and supported
interface types when a new radio is created. This patch adds several new
hwsim attributes so user space can specify specific features the radio should
have:
- HWSIM_ATTR_FEATURE_SUPPORT
Bit field of nl80211_feature_flags flags
- HWSIM_ATTR_EXT_FEATURE_SUPPORT
Variable length bit field where bits map to nl80211_ext_feature_index
values.
- HWSIM_ATTR_IFTYPE_SUPPORT
Nested attribute of flags containing all supported interface types.
Each flag attribute sets support for an interface type.
Each attribute data format matches a corresponding NL80211 attribute:
HWSIM_ATTR_FEATURE_SUPPORT --> NL80211_ATTR_FEATURE_FLAGS
HWSIM_ATTR_EXT_FEATURE_SUPPORT --> NL80211_ATTR_EXT_FEATURES
HWSIM_ATTR_IFTYPE_SUPPORT --> NL80211_ATTR_SUPPORTED_IFTYPES
---
drivers/net/wireless/mac80211_hwsim.c | 95 +++
drivers/net/wireless/mac80211_hwsim.h | 10 +++
2 files changed, 91 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c
b/drivers/net/wireless/mac80211_hwsim.c
index 18e819d964f1..727e61cf154c 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -641,8 +641,30 @@ static const struct nla_policy
hwsim_genl_policy[HWSIM_ATTR_MAX + 1] = {
[HWSIM_ATTR_NO_VIF] = { .type = NLA_FLAG },
[HWSIM_ATTR_FREQ] = { .type = NLA_U32 },
[HWSIM_ATTR_PERM_ADDR] = { .type = NLA_UNSPEC, .len = ETH_ALEN },
+ [HWSIM_ATTR_FEATURE_SUPPORT] = { .type = NLA_U32 },
+ [HWSIM_ATTR_EXT_FEATURE_SUPPORT] = { .type = NLA_BINARY },
+ [HWSIM_ATTR_IFTYPE_SUPPORT] = { .type = NLA_NESTED },
};
+/* policy for iftype support flags */
+static const struct nla_policy
+hwsim_iftype_support_policy[NUM_NL80211_IFTYPES] = {
+ [NL80211_IFTYPE_UNSPECIFIED] = { .type = NLA_FLAG },
+ [NL80211_IFTYPE_ADHOC] = { .type = NLA_FLAG },
+ [NL80211_IFTYPE_STATION] = { .type = NLA_FLAG },
+ [NL80211_IFTYPE_AP] = { .type = NLA_FLAG },
+ [NL80211_IFTYPE_AP_VLAN] = { .type = NLA_FLAG },
+ [NL80211_IFTYPE_WDS] = { .type = NLA_FLAG },
+ [NL80211_IFTYPE_MONITOR] = { .type = NLA_FLAG },
+ [NL80211_IFTYPE_MESH_POINT] = { .type = NLA_FLAG },
+ [NL80211_IFTYPE_P2P_CLIENT] = { .type = NLA_FLAG },
+ [NL80211_IFTYPE_P2P_GO] = { .type = NLA_FLAG },
+ [NL80211_IFTYPE_P2P_DEVICE] = { .type = NLA_FLAG },
+ [NL80211_IFTYPE_OCB] = { .type = NLA_FLAG },
+ [NL80211_IFTYPE_NAN] = { .type = NLA_FLAG },
+};
+
+
static void mac80211_hwsim_tx_frame(struct ieee80211_hw *hw,
struct sk_buff *skb,
struct ieee80211_channel *chan);
@@ -2413,6 +2435,9 @@ struct hwsim_new_radio_params {
const char *hwname;
bool no_vif;
const u8 *perm_addr;
+ u32 features;
+ u8 ext_features[DIV_ROUND_UP(NUM_NL80211_EXT_FEATURES, 8)];
+ u32 iftypes;
};
static void hwsim_mcast_config_msg(struct sk_buff *mcast_skb,
@@ -2631,12 +2656,8 @@ static int mac80211_hwsim_new_radio(struct genl_info
*info,
hw->queues = 5;
hw->offchannel_tx_hw_queue = 4;
- hw->wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
-BIT(NL80211_IFTYPE_AP) |
-BIT(NL80211_IFTYPE_P2P_CLIENT) |
-BIT(NL80211_IFTYPE_P2P_GO) |
-BIT(NL80211_IFTYPE_ADHOC) |
-BIT(NL80211_IFTYPE_MESH_POINT);
+
+ hw->wiphy->interface_modes = param->iftypes;
if (param->p2p_device)
hw->wiphy->interface_modes |= BIT(NL80211_IFTYPE_P2P_DEVICE);
@@ -2658,12 +2679,10 @@ static int mac80211_hwsim_new_radio(struct genl_info
*info,
WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL |
WIPHY_FLAG_AP_UAPSD |
WIPHY_FLAG_HAS_CHANNEL_SWITCH;
- hw->wiphy->features |= NL80211_FEATURE_ACTIVE_MONITOR |
- NL80211_FEATURE_AP_MODE_CHAN_WIDTH_CHANGE |
- NL80211_FEATURE_STATIC_SMPS |
- NL80211_FEATURE_DYNAMIC_SMPS |
- NL80211_FEATURE_SCAN_RANDOM_MAC_ADDR;
- wiphy_ext_feature_set(hw->wiphy, NL80211_EXT_FEATURE_VHT_IBSS);
+
+ hw->wiphy->features |= param->features;
+ memcpy(hw->wiphy->ext_features, param->ext_features,
+ DIV_ROUND_UP(NUM_NL80211_EXT_FEATURES, 8));
/* ask mac80211 to reserve space for magic */
hw->vif_data_size = sizeof(struct hwsim_vif_priv);
@@ -2767,8 +2786,6 @@ static int mac80211_hwsim_new_radio(struct genl_info
*info,
if (param->no_vif)
ieee80211_hw_set(hw, NO_AUTO_VIF);
- wiphy_ext_feature_set(hw->wiphy,
Re: [PATCH 12/19] wilc: add wilc_wfi_cfgoperations.c
On 10/09/2018 12:55 AM, Johannes Berg wrote: > On Tue, 2018-10-09 at 04:23 +, adham.aboza...@microchip.com wrote: >> >>> I don't know what you need the shadow stuff for, but you should remove >>> it anyway, and use the cfg80211 functionality instead. If not >>> sufficient, propose patches to improve it? >> >> The point behind using a shadow buffer was to keep the scan results >> consistent between consecutive scans, and smooth out the cases where >> an AP isn't found momentarily during scanning. >> In this implementation, APs found during scanning are added to the >> shadow list, and removed if not found again for a period of time. >> >> I'm not much in favour of this implementation neither since it >> complicates the driver's logic, but it was serving the purpose. > > You really should remove it - cfg80211 *and* wpa_s already do this if > required. > > johannes > Thanks Johannes for the tip. I did some research, and I believe you are referring to using bss_expire_age and bss_expire_count. We'll go ahead and remove that. Thanks, Adham
enquiry 09-10-2018
Hi,friend, This is Daniel Murray and i am from Sinara Group Co.Ltd Group Co.,LTD in Russia. We are glad to know about your company from the web and we are interested in your products. Could you kindly send us your Latest catalog and price list for our trial order. Best Regards, Daniel Murray Purchasing Manager
Re: [RFC v2] cfg80211: add peer measurement with FTM API
On 10/7/2018 10:58 PM, Johannes Berg wrote:
>>
>> Just curious, what's the advantage of this compared to sending the reply
>> only on
>> the socket that started the measurement?
>
> TBH, I don't really see any. Some people really wanted this for things
> like "let's do something in iw for measurements", though even that is
> not strictly necessary since you can always start listening for events
> as (before) you send off your request. It's slightly more complicated in
> terms of socket handling (as you need to be able to handle events while
> waiting for the netlink ACK message) but that's not so bad.
>
> I'm all for it, so perhaps I'll change that.
Thanks for the explanation. The send to same socket does sound more efficient.
(In our internal implementation with vendor commands we were forced
to send the results as broadcast...)
>
> In that case, it might even make sense to continue with the simple "send
> out results to userspace as we get them" approach, since the application
> that made the request will know to dedicate a socket with socket buffer
> to it, and handle it quickly, avoiding the problems with running out of
> socket buffer space and losing the "measurement complete" event (that I
> was worried about with our [Intel] original code of just multicasting
> the results).
>
Sounds good. That way you may be able to pre-allocate memory for results... In
our implementation we pre-allocated and sent results for each burst as we
received it from FW (though not sure if it works for generic measurement types).
>>> + * @lci_len: length of LCI information (if present)
>>> + * @civicloc_len: length of civic location information (if present)
>>
>> Consider naming lcr (location civic report) instead of civicloc (this is
>> what we
>> used in our QCA vendor API)
>
> Hmm. I guess we already did "civic location" in the FTM-responder side
> API, but perhaps we can change it.
>
Ok with either naming. lcr has just a small advantage since it is shorter :-)
>>> + * @rtt_avg: average of RTTs measured (must have either this or @dist_avg)
>
>> For debugging it might be useful to report the distance in each measurement,
>
> We did in fact originally report the distance unconditionally (rather
> than RTT and/or distance) but it ends up a multiplication by the speed
> of light (in air, but it was approximate enough this didn't matter), but
> I felt that such a calculation is so easy to do we may as well do it in
> iw/userspace?
>
> Unless I'm misunderstanding?
Yes as far as I remember rtt<->distance is a trivial calculation. What I meant
here, you return the average of few measurements done in a burst, and for
debugging we could return all the measurements done in the burst. For example if
there were 4 measurements per burst return the 4 distance measurements done.
[...]
>> Also, Wigig chip has multiple antennas in a single array each covering a
>> sector,
>> and WiFi may have multiple antenna arrays where one or more will be used for
>> measurement, this means we may provide low-accuracy AoA result - at minimum
>> this
>> may tell you on which side of the AP you are... Consider adding this as
>> optional
>> reporting, not critical for initial patch...
>
> Hmm. I'm not sure we have the ability to distinguish the TOA by antenna,
> but I don't know. Frankly, I'm not even sure what you'd want to add
> here? Timestamp per antenna?
>
I meant we could have an AoA value (angle in degrees or other units) which
drivers can fill up if they want. For example if the driver has 2 antennas on
both sides it can report either 90 or 270 degrees. It will be usually very low
accuracy but at least can provide some information like from which side of the
AP you are. This can certainly be added later if at all (hopefully we will have
AoA measurement with higher accuracy in the future)
>>> +/**
>>> + * struct cfg80211_pmsr_request_peer - peer data for a peer measurement
>>> request
>>> + * @addr: MAC address
>>> + * @chandef: channel to use
>>
>> For connected station, usually you will want to do the measurement on the
>> connected channel (possibly some chips will not be able to do otherwise)
>> Maybe add option to use default channel?
>
> Perhaps. It's somewhat complicated to look up in general, userspace
> generally has a decent idea, and making it optional means you end up
> with an invalid chandef?
>
> I'll take a look, perhaps just leaving all the fields 0/NULL can work
> reasonably well, but drivers would have to support it.
>
As I remember the driver/FW can easily find the connected channel for connected
station. For unconnected station we should probably force this parameter.
>>> + * @report_ap_tsf: report the associated AP's TSF
>>> + * @ftm: FTM data, see in particular @ftm.requested
>>> + */
>>> +struct cfg80211_pmsr_request_peer {
>>> + u8 addr[ETH_ALEN];
>>> + struct cfg80211_chan_def chandef;
>>> + bool report_ap_tsf;
>>> + struct {
>>> + enum nl80211_preamble preamble;
>>> +
Re: [PATCH] libertas: call into generic suspend code before turning off power
Ulf Hansson writes:
> On 8 October 2018 at 22:03, Daniel Mack wrote:
>> When powering down a SDIO connected card during suspend, make sure to call
>> into the generic lbs_suspend() function before pulling the plug. This will
>> make sure the card is successfully deregistered from the system to avoid
>> communication to the card starving out.
>>
>> Fixes: 7444a8092906 ("libertas: fix suspend and resume for SDIO connected
>> cards")
>> Signed-off-by: Daniel Mack
>
> Reviewed-by: Ulf Hansson
>
> BTW, if you need this to reach 4.19 I have already queued some other
> mmc fixes so I can take this as well, if it helps. I need and ack of
> course.
I'm not planning to send anything to 4.19 anymore and this is so simple
that hopefully it cause any conflicts with -next patches, so feel free
to do that:
Acked-by: Kalle Valo
--
Kalle Valo
Re: [PATCH v3 2/4] rt2x00: remove confusing AGC register
On Tue, Oct 09, 2018 at 03:07:15PM +0200, Daniel Golle wrote: > simply add these lines: > /* > * Despite the vendor driver using different values here, use 0x1c > * for now. This may have to be changed once TSSI got implemented > */ I will add this in sparate patch. Thanks Stanislaw
Re: [PATCH v3 2/4] rt2x00: remove confusing AGC register
On Tue, Oct 09, 2018 at 02:47:48PM +0200, Stanislaw Gruszka wrote: > Hi > > On Tue, Oct 09, 2018 at 02:27:22PM +0200, Daniel Golle wrote: > > On Tue, Oct 09, 2018 at 01:56:08PM +0200, Gruszka wrote: > > > 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. > > > > My guess is that this may change once we add proper TSSI which involes > > parts of AGC init as well. I suggest to add a comment in the code to > > reflect that. > > I don't understand what you suggest, could you be more specific ? simply add these lines: /* * Despite the vendor driver using different values here, use 0x1c * for now. This may have to be changed once TSSI got implemented */ > > > > 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; > > > > We can summerize the two lines into > > reg = 0x1c + (2 * rt2x00dev->lna_gain); > > which is also what is was before introducing support for MT7620. > > I think you mean > > reg = (rf->channel <= 14 ? 0x1c : 0x24) + 2 * rt2x00dev->lna_gain; > > to do not break 5GHz support for RT5592. I can change that in > separate patch, since this one in not technically wrong. > > Thanks > Stanislaw >
Re: [PATCH v3 2/4] rt2x00: remove confusing AGC register
Hi Stanislaw, On Tue, Oct 09, 2018 at 01:56:08PM +0200, Gruszka wrote: > 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. My guess is that this may change once we add proper TSSI which involes parts of AGC init as well. I suggest to add a comment in the code to reflect that. > > 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; We can summerize the two lines into reg = 0x1c + (2 * rt2x00dev->lna_gain); which is also what is was before introducing support for MT7620. > rt2800_bbp_write_with_rx_chain(rt2x00dev, 66, reg); Cheers Daniel
[PATCH 1/6] brcmfmac: Remove firmware-loading code duplication
brcmf_fw_request_next_item and brcmf_fw_request_done both have identical
code to complete the fw-request depending on the item-type.
This commit adds a new brcmf_fw_complete_request helper removing this code
duplication.
Signed-off-by: Hans de Goede
---
.../broadcom/brcm80211/brcmfmac/firmware.c| 62 +--
1 file changed, 31 insertions(+), 31 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
index 9095b830ae4d..784c84f0e9e7 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
@@ -504,6 +504,34 @@ static int brcmf_fw_request_nvram_done(const struct
firmware *fw, void *ctx)
return -ENOENT;
}
+static int brcmf_fw_complete_request(const struct firmware *fw,
+struct brcmf_fw *fwctx)
+{
+ struct brcmf_fw_item *cur = >req->items[fwctx->curpos];
+ int ret = 0;
+
+ brcmf_dbg(TRACE, "firmware %s %sfound\n", cur->path, fw ? "" : "not ");
+
+ switch (cur->type) {
+ case BRCMF_FW_TYPE_NVRAM:
+ ret = brcmf_fw_request_nvram_done(fw, fwctx);
+ break;
+ case BRCMF_FW_TYPE_BINARY:
+ if (fw)
+ cur->binary = fw;
+ else
+ ret = -ENOENT;
+ break;
+ default:
+ /* something fishy here so bail out early */
+ brcmf_err("unknown fw type: %d\n", cur->type);
+ release_firmware(fw);
+ ret = -EINVAL;
+ }
+
+ return (cur->flags & BRCMF_FW_REQF_OPTIONAL) ? 0 : ret;
+}
+
static int brcmf_fw_request_next_item(struct brcmf_fw *fwctx, bool async)
{
struct brcmf_fw_item *cur;
@@ -525,15 +553,7 @@ static int brcmf_fw_request_next_item(struct brcmf_fw
*fwctx, bool async)
if (ret < 0) {
brcmf_fw_request_done(NULL, fwctx);
} else if (!async && fw) {
- brcmf_dbg(TRACE, "firmware %s %sfound\n", cur->path,
- fw ? "" : "not ");
- if (cur->type == BRCMF_FW_TYPE_BINARY)
- cur->binary = fw;
- else if (cur->type == BRCMF_FW_TYPE_NVRAM)
- brcmf_fw_request_nvram_done(fw, fwctx);
- else
- release_firmware(fw);
-
+ brcmf_fw_complete_request(fw, fwctx);
return -EAGAIN;
}
return 0;
@@ -547,28 +567,8 @@ static void brcmf_fw_request_done(const struct firmware
*fw, void *ctx)
cur = >req->items[fwctx->curpos];
- brcmf_dbg(TRACE, "enter: firmware %s %sfound\n", cur->path,
- fw ? "" : "not ");
-
- if (!fw)
- ret = -ENOENT;
-
- switch (cur->type) {
- case BRCMF_FW_TYPE_NVRAM:
- ret = brcmf_fw_request_nvram_done(fw, fwctx);
- break;
- case BRCMF_FW_TYPE_BINARY:
- cur->binary = fw;
- break;
- default:
- /* something fishy here so bail out early */
- brcmf_err("unknown fw type: %d\n", cur->type);
- release_firmware(fw);
- ret = -EINVAL;
- goto fail;
- }
-
- if (ret < 0 && !(cur->flags & BRCMF_FW_REQF_OPTIONAL))
+ ret = brcmf_fw_complete_request(fw, fwctx);
+ if (ret < 0)
goto fail;
do {
--
2.19.0
[PATCH 2/6] brcmfmac: Remove recursion from firmware load error handling
Before this commit brcmf_fw_request_done would call
brcmf_fw_request_next_item to load the next item, which on an error would
call brcmf_fw_request_done, which if the error is recoverable (*) will
then continue calling brcmf_fw_request_next_item for the next item again
which on an error will call brcmf_fw_request_done again...
This does not blow up because we only have a limited number of items so
we never recurse too deep. But the recursion is still quite ugly and
frankly is giving me a headache, so lets fix this.
This commit fixes this by removing brcmf_fw_request_next_item and by
making brcmf_fw_get_firmwares and brcmf_fw_request_done directly call
firmware_request_nowait resp. firmware_request themselves.
*) brcmf_fw_request_nvram_done fallback path succeeds or
BRCMF_FW_REQF_OPTIONAL is set
Signed-off-by: Hans de Goede
---
.../broadcom/brcm80211/brcmfmac/firmware.c| 65 ++-
1 file changed, 19 insertions(+), 46 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
index 784c84f0e9e7..08aaf99fee34 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
@@ -532,33 +532,6 @@ static int brcmf_fw_complete_request(const struct firmware
*fw,
return (cur->flags & BRCMF_FW_REQF_OPTIONAL) ? 0 : ret;
}
-static int brcmf_fw_request_next_item(struct brcmf_fw *fwctx, bool async)
-{
- struct brcmf_fw_item *cur;
- const struct firmware *fw = NULL;
- int ret;
-
- cur = >req->items[fwctx->curpos];
-
- brcmf_dbg(TRACE, "%srequest for %s\n", async ? "async " : "",
- cur->path);
-
- if (async)
- ret = request_firmware_nowait(THIS_MODULE, true, cur->path,
- fwctx->dev, GFP_KERNEL, fwctx,
- brcmf_fw_request_done);
- else
- ret = request_firmware(, cur->path, fwctx->dev);
-
- if (ret < 0) {
- brcmf_fw_request_done(NULL, fwctx);
- } else if (!async && fw) {
- brcmf_fw_complete_request(fw, fwctx);
- return -EAGAIN;
- }
- return 0;
-}
-
static void brcmf_fw_request_done(const struct firmware *fw, void *ctx)
{
struct brcmf_fw *fwctx = ctx;
@@ -568,26 +541,19 @@ static void brcmf_fw_request_done(const struct firmware
*fw, void *ctx)
cur = >req->items[fwctx->curpos];
ret = brcmf_fw_complete_request(fw, fwctx);
- if (ret < 0)
- goto fail;
-
- do {
- if (++fwctx->curpos == fwctx->req->n_items) {
- ret = 0;
- goto done;
- }
- ret = brcmf_fw_request_next_item(fwctx, false);
- } while (ret == -EAGAIN);
-
- return;
+ while (ret == 0 && ++fwctx->curpos < fwctx->req->n_items) {
+ cur = >req->items[fwctx->curpos];
+ request_firmware(, cur->path, fwctx->dev);
+ ret = brcmf_fw_complete_request(fw, ctx);
+ }
-fail:
- brcmf_dbg(TRACE, "failed err=%d: dev=%s, fw=%s\n", ret,
- dev_name(fwctx->dev), cur->path);
- brcmf_fw_free_request(fwctx->req);
- fwctx->req = NULL;
-done:
+ if (ret) {
+ brcmf_dbg(TRACE, "failed err=%d: dev=%s, fw=%s\n", ret,
+ dev_name(fwctx->dev), cur->path);
+ brcmf_fw_free_request(fwctx->req);
+ fwctx->req = NULL;
+ }
fwctx->done(fwctx->dev, ret, fwctx->req);
kfree(fwctx);
}
@@ -611,7 +577,9 @@ int brcmf_fw_get_firmwares(struct device *dev, struct
brcmf_fw_request *req,
void (*fw_cb)(struct device *dev, int err,
struct brcmf_fw_request *req))
{
+ struct brcmf_fw_item *first = >items[0];
struct brcmf_fw *fwctx;
+ int ret;
brcmf_dbg(TRACE, "enter: dev=%s\n", dev_name(dev));
if (!fw_cb)
@@ -628,7 +596,12 @@ int brcmf_fw_get_firmwares(struct device *dev, struct
brcmf_fw_request *req,
fwctx->req = req;
fwctx->done = fw_cb;
- brcmf_fw_request_next_item(fwctx, true);
+ ret = request_firmware_nowait(THIS_MODULE, true, first->path,
+ fwctx->dev, GFP_KERNEL, fwctx,
+ brcmf_fw_request_done);
+ if (ret < 0)
+ brcmf_fw_request_done(NULL, fwctx);
+
return 0;
}
--
2.19.0
[PATCH 3/6] brcmfmac: Add support for first trying to get a board specific nvram file
The nvram files which some brcmfmac chips need are board-specific. To be
able to distribute these as part of linux-firmware, so that devices with
such a wifi chip will work OOTB, multiple (one per board) versions must
co-exist under /lib/firmware.
This commit adds support for callers of the brcmfmac/firmware.c code to
pass in a board_type parameter through the request structure.
If that parameter is set then the code will first try to load
chipmodel.board_type.txt before falling back to the old chipmodel.txt name.
Signed-off-by: Hans de Goede
---
.../broadcom/brcm80211/brcmfmac/firmware.c| 27 ++-
.../broadcom/brcm80211/brcmfmac/firmware.h| 1 +
2 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
index 08aaf99fee34..6755b2388fbc 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
@@ -532,6 +532,31 @@ static int brcmf_fw_complete_request(const struct firmware
*fw,
return (cur->flags & BRCMF_FW_REQF_OPTIONAL) ? 0 : ret;
}
+static int brcmf_fw_request_firmware(const struct firmware **fw,
+struct brcmf_fw *fwctx)
+{
+ struct brcmf_fw_item *cur = >req->items[fwctx->curpos];
+ int ret;
+
+ /* nvram files are board-specific, first try a board-specific path */
+ if (cur->type == BRCMF_FW_TYPE_NVRAM && fwctx->req->board_type) {
+ char alt_path[BRCMF_FW_NAME_LEN];
+
+ strlcpy(alt_path, cur->path, BRCMF_FW_NAME_LEN);
+ /* strip .txt at the end */
+ alt_path[strlen(alt_path) - 4] = 0;
+ strlcat(alt_path, ".", BRCMF_FW_NAME_LEN);
+ strlcat(alt_path, fwctx->req->board_type, BRCMF_FW_NAME_LEN);
+ strlcat(alt_path, ".txt", BRCMF_FW_NAME_LEN);
+
+ ret = request_firmware(fw, alt_path, fwctx->dev);
+ if (ret == 0)
+ return ret;
+ }
+
+ return request_firmware(fw, cur->path, fwctx->dev);
+}
+
static void brcmf_fw_request_done(const struct firmware *fw, void *ctx)
{
struct brcmf_fw *fwctx = ctx;
@@ -544,7 +569,7 @@ static void brcmf_fw_request_done(const struct firmware
*fw, void *ctx)
while (ret == 0 && ++fwctx->curpos < fwctx->req->n_items) {
cur = >req->items[fwctx->curpos];
- request_firmware(, cur->path, fwctx->dev);
+ brcmf_fw_request_firmware(, fwctx);
ret = brcmf_fw_complete_request(fw, ctx);
}
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
index 2893e56910f0..a0834be8864e 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
@@ -70,6 +70,7 @@ struct brcmf_fw_request {
u16 domain_nr;
u16 bus_nr;
u32 n_items;
+ const char *board_type;
struct brcmf_fw_item items[0];
};
--
2.19.0
[PATCH 6/6] brcmfmac: Cleanup brcmf_fw_request_done()
The "cur" variable is now only used for a debug print and we already
print the same info from brcmf_fw_complete_request(), so the debug print
does not provide any extra info and we can remove it.
Signed-off-by: Hans de Goede
---
.../net/wireless/broadcom/brcm80211/brcmfmac/firmware.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
index 6755b2388fbc..b38c4b40b235 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
@@ -560,22 +560,16 @@ static int brcmf_fw_request_firmware(const struct
firmware **fw,
static void brcmf_fw_request_done(const struct firmware *fw, void *ctx)
{
struct brcmf_fw *fwctx = ctx;
- struct brcmf_fw_item *cur;
- int ret = 0;
-
- cur = >req->items[fwctx->curpos];
+ int ret;
ret = brcmf_fw_complete_request(fw, fwctx);
while (ret == 0 && ++fwctx->curpos < fwctx->req->n_items) {
- cur = >req->items[fwctx->curpos];
brcmf_fw_request_firmware(, fwctx);
ret = brcmf_fw_complete_request(fw, ctx);
}
if (ret) {
- brcmf_dbg(TRACE, "failed err=%d: dev=%s, fw=%s\n", ret,
- dev_name(fwctx->dev), cur->path);
brcmf_fw_free_request(fwctx->req);
fwctx->req = NULL;
}
--
2.19.0
[PATCH 4/6] brcmfmac: Set board_type used for nvram file selection to machine-compatible
For of/devicetree using machines, set the board_type used for nvram file
selection to the first string listed in the top-level's node compatible
string, aka the machine-compatible as used by of_machine_is_compatible().
The board_type setting is used to load the board-specific nvram file with
a board-specific name so that we can ship files for each supported board
in linux-firmware.
Signed-off-by: Hans de Goede
---
.../net/wireless/broadcom/brcm80211/brcmfmac/common.h | 1 +
drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c | 11 ++-
.../net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 1 +
.../net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 1 +
4 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
index a34642cb4d2f..e63a273642e9 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
@@ -59,6 +59,7 @@ struct brcmf_mp_device {
booliapp;
boolignore_probe_fail;
struct brcmfmac_pd_cc *country_codes;
+ const char *board_type;
union {
struct brcmfmac_sdio_pd sdio;
} bus;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
index aee6e5937c41..84e3373289eb 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
@@ -27,11 +27,20 @@ void brcmf_of_probe(struct device *dev, enum brcmf_bus_type
bus_type,
struct brcmf_mp_device *settings)
{
struct brcmfmac_sdio_pd *sdio = >bus.sdio;
- struct device_node *np = dev->of_node;
+ struct device_node *root, *np = dev->of_node;
+ struct property *prop;
int irq;
u32 irqf;
u32 val;
+ /* Set board-type to the first string of the machine compatible prop */
+ root = of_find_node_by_path("/");
+ if (root) {
+ prop = of_find_property(root, "compatible", NULL);
+ settings->board_type = of_prop_next_string(prop, NULL);
+ of_node_put(root);
+ }
+
if (!np || bus_type != BRCMF_BUSTYPE_SDIO ||
!of_device_is_compatible(np, "brcm,bcm4329-fmac"))
return;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 4fffa6988087..b12f3e0ee69c 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -1785,6 +1785,7 @@ brcmf_pcie_prepare_fw_request(struct brcmf_pciedev_info
*devinfo)
fwreq->items[BRCMF_PCIE_FW_CODE].type = BRCMF_FW_TYPE_BINARY;
fwreq->items[BRCMF_PCIE_FW_NVRAM].type = BRCMF_FW_TYPE_NVRAM;
fwreq->items[BRCMF_PCIE_FW_NVRAM].flags = BRCMF_FW_REQF_OPTIONAL;
+ fwreq->board_type = devinfo->settings->board_type;
/* NVRAM reserves PCI domain 0 for Broadcom's SDK faked bus */
fwreq->domain_nr = pci_domain_nr(devinfo->pdev->bus) + 1;
fwreq->bus_nr = devinfo->pdev->bus->number;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index a907d7b065fa..3d117563 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -4177,6 +4177,7 @@ brcmf_sdio_prepare_fw_request(struct brcmf_sdio *bus)
fwreq->items[BRCMF_SDIO_FW_CODE].type = BRCMF_FW_TYPE_BINARY;
fwreq->items[BRCMF_SDIO_FW_NVRAM].type = BRCMF_FW_TYPE_NVRAM;
+ fwreq->board_type = bus->sdiodev->settings->board_type;
return fwreq;
}
--
2.19.0
[PATCH 5/6] brcmfmac: Set board_type from DMI on x86 based machines
For x86 based machines, set the board_type used for nvram file selection
based on the DMI sys-vendor and product-name strings.
Since on some models these strings are too generic, this commit also adds
a quirk table overriding the strings for models listed in that table.
The board_type setting is used to load the board-specific nvram file with
a board-specific name so that we can ship files for each supported board
in linux-firmware.
Signed-off-by: Hans de Goede
---
.../broadcom/brcm80211/brcmfmac/Makefile | 2 +
.../broadcom/brcm80211/brcmfmac/common.c | 3 +-
.../broadcom/brcm80211/brcmfmac/common.h | 7 ++
.../broadcom/brcm80211/brcmfmac/dmi.c | 104 ++
4 files changed, 115 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile
index 1f5a9b948abf..22fd95a736a8 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile
@@ -54,3 +54,5 @@ brcmfmac-$(CONFIG_BRCM_TRACING) += \
tracepoint.o
brcmfmac-$(CONFIG_OF) += \
of.o
+brcmfmac-$(CONFIG_DMI) += \
+ dmi.o
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
index cd3651069d0c..a4bcbd1a57ac 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
@@ -450,8 +450,9 @@ struct brcmf_mp_device *brcmf_get_module_param(struct
device *dev,
}
}
if (!found) {
- /* No platform data for this device, try OF (Open Firwmare) */
+ /* No platform data for this device, try OF and DMI data */
brcmf_of_probe(dev, bus_type, settings);
+ brcmf_dmi_probe(settings, chip, chiprev);
}
return settings;
}
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
index e63a273642e9..4ce56be90b74 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
@@ -75,4 +75,11 @@ void brcmf_release_module_param(struct brcmf_mp_device
*module_param);
/* Sets dongle media info (drv_version, mac address). */
int brcmf_c_preinit_dcmds(struct brcmf_if *ifp);
+#ifdef CONFIG_DMI
+void brcmf_dmi_probe(struct brcmf_mp_device *settings, u32 chip, u32 chiprev);
+#else
+static inline void
+brcmf_dmi_probe(struct brcmf_mp_device *settings, u32 chip, u32 chiprev) {}
+#endif
+
#endif /* BRCMFMAC_COMMON_H */
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c
new file mode 100644
index ..fadc0ec745b8
--- /dev/null
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c
@@ -0,0 +1,104 @@
+// SPDX-License-Identifier: ISC
+/*
+ * Copyright 2018 Hans de Goede
+ */
+#include
+#include
+#include "core.h"
+#include "common.h"
+#include "brcm_hw_ids.h"
+
+/* The DMI data never changes so we can use a static buf for this */
+static char dmi_board_type[128];
+
+struct brcmf_dmi_data {
+ u32 chip;
+ u32 chiprev;
+ const char *board_type;
+};
+
+/* NOTE: Please keep all entries sorted alphabetically */
+
+static const struct brcmf_dmi_data gpd_win_pocket_data = {
+ BRCM_CC_4356_CHIP_ID, 2, "gpd-win-pocket"
+};
+
+static const struct brcmf_dmi_data jumper_ezpad_mini3_data = {
+ BRCM_CC_43430_CHIP_ID, 0, "jumper-ezpad-mini3"
+};
+
+static const struct brcmf_dmi_data meegopad_t08_data = {
+ BRCM_CC_43340_CHIP_ID, 2, "meegopad-t08"
+};
+
+static const struct dmi_system_id dmi_platform_data[] = {
+ {
+ /* Match for the GPDwin which unfortunately uses somewhat
+* generic dmi strings, which is why we test for 4 strings.
+* Comparing against 23 other byt/cht boards, board_vendor
+* and board_name are unique to the GPDwin, where as only one
+* other board has the same board_serial and 3 others have
+* the same default product_name. Also the GPDwin is the
+* only device to have both board_ and product_name not set.
+*/
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"),
+ DMI_MATCH(DMI_BOARD_NAME, "Default string"),
+ DMI_MATCH(DMI_BOARD_SERIAL, "Default string"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Default string"),
+ },
+ .driver_data = (void *)_win_pocket_data,
+ },
+ {
+ /* Jumper EZpad mini3 */
+ .matches = {
+
Re: [PATCH v3 2/4] rt2x00: remove confusing AGC register
Hi On Tue, Oct 09, 2018 at 02:27:22PM +0200, Daniel Golle wrote: > On Tue, Oct 09, 2018 at 01:56:08PM +0200, Gruszka wrote: > > 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. > > My guess is that this may change once we add proper TSSI which involes > parts of AGC init as well. I suggest to add a comment in the code to > reflect that. I don't understand what you suggest, could you be more specific ? > > 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; > > We can summerize the two lines into > reg = 0x1c + (2 * rt2x00dev->lna_gain); > which is also what is was before introducing support for MT7620. I think you mean reg = (rf->channel <= 14 ? 0x1c : 0x24) + 2 * rt2x00dev->lna_gain; to do not break 5GHz support for RT5592. I can change that in separate patch, since this one in not technically wrong. Thanks Stanislaw
[PATCH RFC v5 0/4] Move TXQ scheduling and airtime fairness into mac80211
Another updated version, addressing a few issues with the previous version. - Moved the airtime deficit queue wakeup code to its own tasklet to lower overhead. - Change the tasklet to just wake a single queue on each invocation, relying to TX completion to continue transmissions. - Don't try to re-schedule TXQs of stations that are being removed. - A few cleanups and fixes. The one thing I didn't change was to add another callback that the driver can use to trigger the tasklet. Since it's now in its own tasklet, hopefully the overhead is low enough that we can just call it on every end_schedule(); and I'd rather not complicate the driver API further. Thanks to Rajkumar for testing the previous version. I thought I'd have time to test this version myself and was planning to send as a non-RFC PATCH after that, but that time didn't materialise. So I thought it was better to send another RFC version instead of everyone having to suffer from my tardiness :) -Toke --- Toke Høiland-Jørgensen (4): mac80211: Add TXQ scheduling API cfg80211: Add airtime statistics and settings mac80211: Add airtime accounting and scheduling to TXQs ath9k: Switch to mac80211 TXQ scheduling and airtime APIs drivers/net/wireless/ath/ath9k/ath9k.h | 14 -- drivers/net/wireless/ath/ath9k/debug.c |3 drivers/net/wireless/ath/ath9k/debug.h |8 - drivers/net/wireless/ath/ath9k/debug_sta.c | 54 -- drivers/net/wireless/ath/ath9k/init.c |3 drivers/net/wireless/ath/ath9k/recv.c |9 - drivers/net/wireless/ath/ath9k/xmit.c | 244 include/net/cfg80211.h | 10 + include/net/mac80211.h | 113 + include/uapi/linux/nl80211.h | 15 ++ net/mac80211/agg-tx.c |2 net/mac80211/cfg.c |3 net/mac80211/debugfs.c |3 net/mac80211/debugfs_sta.c | 51 ++ net/mac80211/driver-ops.h |9 + net/mac80211/ieee80211_i.h | 14 ++ net/mac80211/main.c| 11 + net/mac80211/sta_info.c| 54 ++ net/mac80211/sta_info.h| 13 + net/mac80211/status.c |6 + net/mac80211/tx.c | 137 net/mac80211/util.c| 75 + net/wireless/nl80211.c | 29 +++ 23 files changed, 603 insertions(+), 277 deletions(-)
[PATCH RFC v5 2/4] cfg80211: Add airtime statistics and settings
This adds TX airtime statistics to the cfg80211 station dump (to go along
with the RX info already present), and adds a new parameter to set the
airtime weight of each station. The latter allows userspace to implement
policies for different stations by varying their weights.
Signed-off-by: Toke Høiland-Jørgensen
---
include/net/cfg80211.h | 10 +-
include/uapi/linux/nl80211.h | 15 +++
net/wireless/nl80211.c | 29 +
3 files changed, 53 insertions(+), 1 deletion(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 9f3ed79c39d7..91d6fc63 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -990,6 +990,7 @@ enum station_parameters_apply_mask {
* @support_p2p_ps: information if station supports P2P PS mechanism
* @he_capa: HE capabilities of station
* @he_capa_len: the length of the HE capabilities
+ * @airtime_weight: airtime scheduler weight for this station
*/
struct station_parameters {
const u8 *supported_rates;
@@ -1019,6 +1020,7 @@ struct station_parameters {
int support_p2p_ps;
const struct ieee80211_he_cap_elem *he_capa;
u8 he_capa_len;
+ u16 airtime_weight;
};
/**
@@ -1286,6 +1288,8 @@ struct cfg80211_tid_stats {
* @rx_beacon_signal_avg: signal strength average (in dBm) for beacons received
* from this peer
* @rx_duration: aggregate PPDU duration(usecs) for all the frames from a peer
+ * @tx_duration: aggregate PPDU duration(usecs) for all the frames to a peer
+ * @airtime_weight: current airtime scheduling weight
* @pertid: per-TID statistics, see cfg80211_tid_stats, using the last
* (IEEE80211_NUM_TIDS) index for MSDUs not encapsulated in QoS-MPDUs.
* Note that this doesn't use the @filled bit, but is used if non-NULL.
@@ -1332,10 +1336,12 @@ struct station_info {
u32 expected_throughput;
- u64 rx_beacon;
+ u64 tx_duration;
u64 rx_duration;
+ u64 rx_beacon;
u8 rx_beacon_signal_avg;
struct cfg80211_tid_stats *pertid;
+ u16 airtime_weight;
s8 ack_signal;
s8 avg_ack_signal;
};
@@ -2363,6 +2369,8 @@ enum wiphy_params_flags {
WIPHY_PARAM_TXQ_QUANTUM = 1 << 8,
};
+#define IEEE80211_DEFAULT_AIRTIME_WEIGHT 256
+
/**
* struct cfg80211_pmksa - PMK Security Association
*
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index cfc94178d608..3664bdc7c8c1 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -2241,6 +2241,9 @@ enum nl80211_commands {
* association request when used with NL80211_CMD_NEW_STATION). Can be set
* only if %NL80211_STA_FLAG_WME is set.
*
+ * @NL80211_ATTR_AIRTIME_WEIGHT: Station's weight when scheduled by the airtime
+ * scheduler.
+ *
* @NUM_NL80211_ATTR: total number of nl80211_attrs available
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
@@ -2682,6 +2685,8 @@ enum nl80211_attrs {
NL80211_ATTR_HE_CAPABILITY,
+ NL80211_ATTR_AIRTIME_WEIGHT,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
@@ -3051,6 +3056,9 @@ enum nl80211_sta_bss_param {
* @NL80211_STA_INFO_PAD: attribute used for padding for 64-bit alignment
* @NL80211_STA_INFO_ACK_SIGNAL: signal strength of the last ACK frame(u8, dBm)
* @NL80211_STA_INFO_ACK_SIGNAL_AVG: avg signal strength of ACK frames (s8,
dBm)
+ * @NL80211_STA_INFO_TX_DURATION: aggregate PPDU duration for all frames
+ * sent to the station (u64, usec)
+ * @NL80211_STA_INFO_AIRTIME_WEIGHT: current airtime weight for station (u16)
* @__NL80211_STA_INFO_AFTER_LAST: internal
* @NL80211_STA_INFO_MAX: highest possible station info attribute
*/
@@ -3091,6 +3099,8 @@ enum nl80211_sta_info {
NL80211_STA_INFO_PAD,
NL80211_STA_INFO_ACK_SIGNAL,
NL80211_STA_INFO_ACK_SIGNAL_AVG,
+ NL80211_STA_INFO_TX_DURATION,
+ NL80211_STA_INFO_AIRTIME_WEIGHT,
/* keep last */
__NL80211_STA_INFO_AFTER_LAST,
@@ -5231,6 +5241,10 @@ enum nl80211_feature_flags {
* if this flag is not set. Ignoring this can leak clear text packets
and/or
* freeze the connection.
*
+ * @NL80211_EXT_FEATURE_AIRTIME_FAIRNESS: Driver supports getting airtime
+ * fairness for transmitted packets and has enabled airtime fairness
+ * scheduling.
+ *
* @NUM_NL80211_EXT_FEATURES: number of extended features.
* @MAX_NL80211_EXT_FEATURES: highest extended feature index.
*/
@@ -5269,6 +5283,7 @@ enum nl80211_ext_feature_index {
NL80211_EXT_FEATURE_SCAN_RANDOM_SN,
NL80211_EXT_FEATURE_SCAN_MIN_PREQ_CONTENT,
NL80211_EXT_FEATURE_CAN_REPLACE_PTK0,
+ NL80211_EXT_FEATURE_AIRTIME_FAIRNESS,
/* add new features before the definition below */
NUM_NL80211_EXT_FEATURES,
diff --git
[PATCH RFC v5 1/4] mac80211: Add TXQ scheduling API
This adds an API to mac80211 to handle scheduling of TXQs. The interface between driver and mac80211 for TXQ handling is changed by adding two new functions: ieee80211_next_txq(), which will return the next TXQ to schedule in the current round-robin rotation, and ieee80211_return_txq(), which the driver uses to indicate that it has finished scheduling a TXQ (which will then be put back in the scheduling rotation if it isn't empty). The driver must call ieee80211_txq_schedule_start() at the start of each scheduling session, and ieee80211_txq_schedule_end() at the end. The API then guarantees that the same TXQ is not returned twice in the same session (so a driver can loop on ieee80211_next_txq() without worrying about breaking the loop. Usage of the new API is optional, so drivers can be ported one at a time. In this patch, the actual scheduling performed by mac80211 is simple round-robin, but a subsequent commit adds airtime fairness awareness to the scheduler. Signed-off-by: Toke Høiland-Jørgensen --- include/net/mac80211.h | 61 +--- net/mac80211/agg-tx.c |2 + net/mac80211/driver-ops.h |9 ++ net/mac80211/ieee80211_i.h |9 ++ net/mac80211/main.c|5 net/mac80211/sta_info.c|2 + net/mac80211/tx.c | 59 ++- 7 files changed, 140 insertions(+), 7 deletions(-) diff --git a/include/net/mac80211.h b/include/net/mac80211.h index c4fadbafbf21..469e88a32f94 100644 --- a/include/net/mac80211.h +++ b/include/net/mac80211.h @@ -108,9 +108,15 @@ * The driver is expected to initialize its private per-queue data for stations * and interfaces in the .add_interface and .sta_add ops. * - * The driver can't access the queue directly. To dequeue a frame, it calls - * ieee80211_tx_dequeue(). Whenever mac80211 adds a new frame to a queue, it - * calls the .wake_tx_queue driver op. + * The driver can't access the queue directly. To dequeue a frame from a + * txq, it calls ieee80211_tx_dequeue(). Whenever mac80211 adds a new frame to a + * queue, it calls the .wake_tx_queue driver op. + * + * Drivers can optionally delegate responsibility for scheduling queues to + * mac80211, to take advantage of airtime fairness accounting. In this case, to + * obtain the next queue to pull frames from, the driver calls + * ieee80211_next_txq(). The driver is then expected to return the txq using + * ieee80211_return_txq(). * * For AP powersave TIM handling, the driver only needs to indicate if it has * buffered packets in the driver specific data structures by calling @@ -6045,13 +6051,60 @@ void ieee80211_unreserve_tid(struct ieee80211_sta *sta, u8 tid); * ieee80211_tx_dequeue - dequeue a packet from a software tx queue * * @hw: pointer as obtained from ieee80211_alloc_hw() - * @txq: pointer obtained from station or virtual interface + * @txq: pointer obtained from station or virtual interface, or from + * ieee80211_next_txq() * * Returns the skb if successful, %NULL if no frame was available. */ struct sk_buff *ieee80211_tx_dequeue(struct ieee80211_hw *hw, struct ieee80211_txq *txq); +/** + * ieee80211_next_txq - get next tx queue to pull packets from + * + * @hw: pointer as obtained from ieee80211_alloc_hw() + * @ac: AC number to return packets from. + * + * Should only be called between calls to ieee80211_txq_schedule_start() + * and ieee80211_txq_schedule_end(). + * Returns the next txq if successful, %NULL if no queue is eligible. If a txq + * is returned, it should be returned with ieee80211_return_txq() after the + * driver has finished scheduling it. + */ +struct ieee80211_txq *ieee80211_next_txq(struct ieee80211_hw *hw, u8 ac); + +/** + * ieee80211_return_txq - return a TXQ previously acquired by ieee80211_next_txq() + * + * @hw: pointer as obtained from ieee80211_alloc_hw() + * @txq: pointer obtained from station or virtual interface + * + * Should only be called between calls to ieee80211_txq_schedule_start() + * and ieee80211_txq_schedule_end(). + */ +void ieee80211_return_txq(struct ieee80211_hw *hw, struct ieee80211_txq *txq); + +/** + * ieee80211_txq_schedule_start - acquire locks for safe scheduling of an AC + * + * @hw: pointer as obtained from ieee80211_alloc_hw() + * @ac: AC number to acquire locks for + * + * Acquire locks needed to schedule TXQs from the given AC. Should be called + * before ieee80211_next_txq() or ieee80211_return_txq(). + */ +void ieee80211_txq_schedule_start(struct ieee80211_hw *hw, u8 ac); + +/** + * ieee80211_txq_schedule_end - release locks for safe scheduling of an AC + * + * @hw: pointer as obtained from ieee80211_alloc_hw() + * @ac: AC number to acquire locks for + * + * Release locks previously acquired by ieee80211_txq_schedule_end(). + */ +void ieee80211_txq_schedule_end(struct ieee80211_hw *hw, u8 ac); + /** * ieee80211_txq_get_depth - get pending frame/byte count
[PATCH RFC v5 3/4] mac80211: Add airtime accounting and scheduling to TXQs
This adds airtime accounting and scheduling to the mac80211 TXQ
scheduler. A new callback, ieee80211_sta_register_airtime(), is added
that drivers can call to report airtime usage for stations.
When airtime information is present, mac80211 will schedule TXQs
(through ieee80211_next_txq()) in a way that enforces airtime fairness
between active stations. This scheduling works the same way as the ath9k
in-driver airtime fairness scheduling. If no airtime usage is reported
by the driver, the scheduler will default to round-robin scheduling.
For drivers that don't control TXQ scheduling in software, a new API
function, ieee80211_txq_may_transmit(), is added which the driver can use
to check if the TXQ is eligible for transmission, or should be throttled to
enforce fairness. Calls to this function must also be enclosed in
ieee80211_txq_schedule_{start,end}() calls to ensure proper locking. TXQs
that are throttled by ieee802111_txq_may_transmit() will be woken up again
by a check added to the ieee80211_wake_txqs() tasklet.
Signed-off-by: Toke Høiland-Jørgensen
---
include/net/mac80211.h | 52 +++
net/mac80211/cfg.c |3 ++
net/mac80211/debugfs.c |3 ++
net/mac80211/debugfs_sta.c | 51 +-
net/mac80211/ieee80211_i.h |5 +++
net/mac80211/main.c|6 +++
net/mac80211/sta_info.c| 52 +--
net/mac80211/sta_info.h| 13 +++
net/mac80211/status.c |6 +++
net/mac80211/tx.c | 86 ++--
net/mac80211/util.c| 75 ++
11 files changed, 341 insertions(+), 11 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 469e88a32f94..fa10420a53ff 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -5349,6 +5349,34 @@ void ieee80211_sta_eosp(struct ieee80211_sta *pubsta);
*/
void ieee80211_send_eosp_nullfunc(struct ieee80211_sta *pubsta, int tid);
+/**
+ * ieee80211_sta_register_airtime - register airtime usage for a sta/tid
+ *
+ * Register airtime usage for a given sta on a given tid. The driver can call
+ * this function to notify mac80211 that a station used a certain amount of
+ * airtime. This information will be used by the TXQ scheduler to schedule
+ * stations in a way that ensures airtime fairness.
+ *
+ * The reported airtime should as a minimum include all time that is spent
+ * transmitting to the remote station, including overhead and padding, but not
+ * including time spent waiting for a TXOP. If the time is not reported by the
+ * hardware it can in some cases be calculated from the rate and known frame
+ * composition. When possible, the time should include any failed transmission
+ * attempts.
+ *
+ * The driver can either call this function synchronously for every packet or
+ * aggregate, or asynchronously as airtime usage information becomes available.
+ * TX and RX airtime can be reported together, or separately by setting one of
+ * them to 0.
+ *
+ * @pubsta: the station
+ * @tid: the TID to register airtime for
+ * @tx_airtime: airtime used during TX (in usec)
+ * @rx_airtime: airtime used during RX (in usec)
+ */
+void ieee80211_sta_register_airtime(struct ieee80211_sta *pubsta, u8 tid,
+ u32 tx_airtime, u32 rx_airtime);
+
/**
* ieee80211_iter_keys - iterate keys programmed into the device
* @hw: pointer obtained from ieee80211_alloc_hw()
@@ -6105,6 +6133,30 @@ void ieee80211_txq_schedule_start(struct ieee80211_hw
*hw, u8 ac);
*/
void ieee80211_txq_schedule_end(struct ieee80211_hw *hw, u8 ac);
+/**
+ * ieee80211_txq_may_transmit - check whether TXQ is allowed to transmit
+ *
+ * This function is used to check whether given txq is allowed to transmit by
+ * the airtime scheduler, and can be used by drivers to access the airtime
+ * fairness accounting without going using the scheduling order enfored by
+ * next_txq().
+ *
+ * Returns %true if the airtime scheduler thinks the TXQ should be allowed to
+ * transmit, and %false if it should be throttled. This function can also have
+ * the side effect of rotating the TXQ in the scheduler rotation, which will
+ * eventually bring the deficit to positive and allow the station to transmit
+ * again. If a TXQ is throttled, it will be marked and eventually woken up
again
+ * through drv_wake_tx_queue().
+ *
+ * If this function returns %true, the driver is expected to schedule packets
+ * for transmission, and then return the TXQ through ieee80211_return_txq().
+ *
+ * @hw: pointer as obtained from ieee80211_alloc_hw()
+ * @txq: pointer obtained from station or virtual interface
+ */
+bool ieee80211_txq_may_transmit(struct ieee80211_hw *hw,
+ struct ieee80211_txq *txq);
+
/**
* ieee80211_txq_get_depth - get pending frame/byte count of given txq
*
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index
[PATCH RFC v5 4/4] ath9k: Switch to mac80211 TXQ scheduling and airtime APIs
This moves the ath9k driver to use the mac80211 TXQ scheduling and
airtime accounting APIs, removing the corresponding state tracking
inside the driver.
Signed-off-by: Toke Høiland-Jørgensen
---
drivers/net/wireless/ath/ath9k/ath9k.h | 14 --
drivers/net/wireless/ath/ath9k/debug.c |3
drivers/net/wireless/ath/ath9k/debug.h |8 -
drivers/net/wireless/ath/ath9k/debug_sta.c | 54 --
drivers/net/wireless/ath/ath9k/init.c |3
drivers/net/wireless/ath/ath9k/recv.c |9 -
drivers/net/wireless/ath/ath9k/xmit.c | 244
7 files changed, 73 insertions(+), 262 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h
b/drivers/net/wireless/ath/ath9k/ath9k.h
index 21ba20981a80..90b56766dab1 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -112,8 +112,6 @@ int ath_descdma_setup(struct ath_softc *sc, struct
ath_descdma *dd,
#define ATH_TXFIFO_DEPTH 8
#define ATH_TX_ERROR 0x01
-#define ATH_AIRTIME_QUANTUM300 /* usec */
-
/* Stop tx traffic 1ms before the GO goes away */
#define ATH_P2P_PS_STOP_TIME 1000
@@ -246,10 +244,8 @@ struct ath_atx_tid {
s8 bar_index;
bool active;
bool clear_ps_filter;
- bool has_queued;
};
-void __ath_tx_queue_tid(struct ath_softc *sc, struct ath_atx_tid *tid);
void ath_tx_queue_tid(struct ath_softc *sc, struct ath_atx_tid *tid);
struct ath_node {
@@ -263,12 +259,9 @@ struct ath_node {
bool sleeping;
bool no_ps_filter;
- s64 airtime_deficit[IEEE80211_NUM_ACS];
- u32 airtime_rx_start;
#ifdef CONFIG_ATH9K_STATION_STATISTICS
struct ath_rx_rate_stats rx_rate_stats;
- struct ath_airtime_stats airtime_stats;
#endif
u8 key_idx[4];
@@ -986,11 +979,6 @@ void ath_ant_comb_scan(struct ath_softc *sc, struct
ath_rx_status *rs);
#define ATH9K_NUM_CHANCTX 2 /* supports 2 operating channels */
-#define AIRTIME_USE_TX BIT(0)
-#define AIRTIME_USE_RX BIT(1)
-#define AIRTIME_USE_NEW_QUEUES BIT(2)
-#define AIRTIME_ACTIVE(flags) (!!(flags & (AIRTIME_USE_TX|AIRTIME_USE_RX)))
-
struct ath_softc {
struct ieee80211_hw *hw;
struct device *dev;
@@ -1034,8 +1022,6 @@ struct ath_softc {
short nbcnvifs;
unsigned long ps_usecount;
- u16 airtime_flags; /* AIRTIME_* */
-
struct ath_rx rx;
struct ath_tx tx;
struct ath_beacon beacon;
diff --git a/drivers/net/wireless/ath/ath9k/debug.c
b/drivers/net/wireless/ath/ath9k/debug.c
index 0a6eb8a8c1ed..f928d3a07caa 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -1456,9 +1456,6 @@ int ath9k_init_debug(struct ath_hw *ah)
#endif
debugfs_create_file("tpc", 0600, sc->debug.debugfs_phy, sc, _tpc);
- debugfs_create_u16("airtime_flags", 0600,
- sc->debug.debugfs_phy, >airtime_flags);
-
debugfs_create_file("nf_override", 0600,
sc->debug.debugfs_phy, sc, _nf_override);
diff --git a/drivers/net/wireless/ath/ath9k/debug.h
b/drivers/net/wireless/ath/ath9k/debug.h
index 249f8141cd00..559d9628f280 100644
--- a/drivers/net/wireless/ath/ath9k/debug.h
+++ b/drivers/net/wireless/ath/ath9k/debug.h
@@ -319,20 +319,12 @@ ath9k_debug_sync_cause(struct ath_softc *sc, u32
sync_cause)
void ath_debug_rate_stats(struct ath_softc *sc,
struct ath_rx_status *rs,
struct sk_buff *skb);
-void ath_debug_airtime(struct ath_softc *sc,
- struct ath_node *an,
- u32 rx, u32 tx);
#else
static inline void ath_debug_rate_stats(struct ath_softc *sc,
struct ath_rx_status *rs,
struct sk_buff *skb)
{
}
-static inline void ath_debug_airtime(struct ath_softc *sc,
- struct ath_node *an,
- u32 rx, u32 tx)
-{
-}
#endif /* CONFIG_ATH9K_STATION_STATISTICS */
#endif /* DEBUG_H */
diff --git a/drivers/net/wireless/ath/ath9k/debug_sta.c
b/drivers/net/wireless/ath/ath9k/debug_sta.c
index a6f45f1bb5bb..bb6f3250aa30 100644
--- a/drivers/net/wireless/ath/ath9k/debug_sta.c
+++ b/drivers/net/wireless/ath/ath9k/debug_sta.c
@@ -242,59 +242,6 @@ static const struct file_operations fops_node_recv = {
.llseek = default_llseek,
};
-void ath_debug_airtime(struct ath_softc *sc,
- struct ath_node *an,
- u32 rx,
- u32 tx)
-{
- struct ath_airtime_stats *astats = >airtime_stats;
-
- astats->rx_airtime += rx;
- astats->tx_airtime += tx;
-}
-
-static ssize_t read_airtime(struct file *file, char __user *user_buf,
- size_t count, loff_t *ppos)
-{
- struct ath_node *an = file->private_data;
- struct ath_airtime_stats *astats;
-
Re: [PATCH v2] mt76x0: phy: fix restore phase in mt76x0_phy_recalibrate_after_assoc
On 2018-10-09 10:57, Lorenzo Bianconi wrote:
> Fix restore value configured in MT_BBP(IBI, 9) register in
> mt76x0_phy_recalibrate_after_assoc routine.
>
> Fixes: 10de7a8b4ab9 ("mt76x0: phy files")
> Signed-off-by: Lorenzo Bianconi
Merged, thanks.
- Felix
Re: [PATCH 03/19] wilc: add host_interface.h
On 10/9/2018 5:16 PM, Johannes Berg wrote:
> On Tue, 2018-10-09 at 17:14 +0530, Ajay Singh wrote:
>> On 10/9/2018 4:06 PM, Johannes Berg wrote:
>>> On Tue, 2018-10-09 at 16:04 +0530, Ajay Singh wrote:
>>>
>> +typedef void (*wilc_remain_on_chan_expired)(void *, u32);
>> +typedef void (*wilc_remain_on_chan_ready)(void *);
I think as per coding style the typedef for function pointer are allowed.
>>> True, I guess, but why do you need them?
>> Actually these function pointer are used in multiple places i.e inside
>> the struct and also for passing as the argument for the function. So i
>> think its better to keep them as typedef to simplify and avoid any 'line
>> over 80 chars' checkpatch issue. But anyway if you suggest we can modify
>> to remove these typedefs .
> I guess that must be part of the internal bounce buffer mechanism? I
> guess leave them for now and see what falls out.
>
>> +struct hidden_network {
>>
>> Yes, its not related to hidden SSID. Suppose cfg80211 scan is called
>> with SSID information(active scan) then SSID info will be maintained in
>> this structure.
> so maybe rename this?
>
Yes, sure I will rename this struct.
Regards,
Ajay
[PATCH v3 3/4] rt2x00: update TX_SW_CFG2 value
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
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
v2->v3:
- add SoB
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 v3 2/4] rt2x00: remove confusing AGC register
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 v3 4/4] rt2800: fix registers init for MT7620
There is dupliceted 'if (rt2x00_rt(rt2x00dev, RT6352))' entry that couses
we do not perform proper register initaliztion for RT6352 (MT7620 SOCs).
Reported-by: Tomislav Požega
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 daf20d7424ac..170e7c87f7bc 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);
--
2.7.5
[PATCH v3 1/4] rt2x00: remove unneeded check
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
---
v2 -> v3:
- fix wrongly applied hung during rebase
- add SoB
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,
-
Re: [PATCH 03/19] wilc: add host_interface.h
On Tue, 2018-10-09 at 17:14 +0530, Ajay Singh wrote:
> On 10/9/2018 4:06 PM, Johannes Berg wrote:
> > On Tue, 2018-10-09 at 16:04 +0530, Ajay Singh wrote:
> >
> > > > > +typedef void (*wilc_remain_on_chan_expired)(void *, u32);
> > > > > +typedef void (*wilc_remain_on_chan_ready)(void *);
> > >
> > > I think as per coding style the typedef for function pointer are allowed.
> >
> > True, I guess, but why do you need them?
>
> Actually these function pointer are used in multiple places i.e inside
> the struct and also for passing as the argument for the function. So i
> think its better to keep them as typedef to simplify and avoid any 'line
> over 80 chars' checkpatch issue. But anyway if you suggest we can modify
> to remove these typedefs .
I guess that must be part of the internal bounce buffer mechanism? I
guess leave them for now and see what falls out.
> > > > > +struct hidden_network {
> > > > >
> Yes, its not related to hidden SSID. Suppose cfg80211 scan is called
> with SSID information(active scan) then SSID info will be maintained in
> this structure.
so maybe rename this?
johannes
Re: [PATCH 03/19] wilc: add host_interface.h
On 10/9/2018 4:06 PM, Johannes Berg wrote:
> On Tue, 2018-10-09 at 16:04 +0530, Ajay Singh wrote:
>
+typedef void (*wilc_remain_on_chan_expired)(void *, u32);
+typedef void (*wilc_remain_on_chan_ready)(void *);
>> I think as per coding style the typedef for function pointer are allowed.
> True, I guess, but why do you need them?
Actually these function pointer are used in multiple places i.e inside
the struct and also for passing as the argument for the function. So i
think its better to keep them as typedef to simplify and avoid any 'line
over 80 chars' checkpatch issue. But anyway if you suggest we can modify
to remove these typedefs .
+struct rcvd_net_info {
+ u8 *buffer;
+ u32 len;
+};
+
+struct hidden_net_info {
+ u8 *ssid;
+ u8 ssid_len;
+};
+
+struct hidden_network {
+ struct hidden_net_info *net_info;
+ u8 n_ssids;
+};
>>> This seems really odd - what part doesn't cfg80211 already handle?
>> If I understood your question correctly, you meant what extra
>> functionality 'hidden_network' struct is providing.
> Pretty much. It seems like you're trying to handle hidden SSIDs in some
> way, but ... that's odd.
>
>> Actually this structure is just used to keeps list of SSID's requested
>> in cfg80211 'scan' callback which is passed to firmware. The values are
>> extracted from 'cfg80211_scan_request[struct cfg80211_ssid *ssids
>> - int n_ssids] received during scan.
> So then this has nothing to do with hidden SSID?
Yes, its not related to hidden SSID. Suppose cfg80211 scan is called
with SSID information(active scan) then SSID info will be maintained in
this structure.
Regards,
Ajay
[PATCH v2 3/4] rt2x00: update TX_SW_CFG2 value
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 463c9117ba06..3d5c78f11ee5 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 v2 2/4] rt2x00: remove confusing AGC register
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 878fbca60f40..463c9117ba06 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 v2 4/4] rt2800: fix registers init for MT7620
There is dupliceted 'if (rt2x00_rt(rt2x00dev, RT6352))' entry that couses
we do not perform proper register initaliztion for RT6352 (MT7620 SOCs).
Reported-by: Tomislav Požega
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 3d5c78f11ee5..cc96410470d6 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);
--
2.7.5
[PATCH v2 1/4] rt2x00: remove unneeded check
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
---
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..878fbca60f40 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -2878,6 +2878,7 @@ static void rt2800_config_channel_rf3290(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, 0x09, 0x08, 0x07, 0x07, 0x06};
-
-
Re: [PATCH 1/5] rt2x00: set registers based on current band
Patches 3-5 looks ok to me, I'll rebase and resend them. Thanks Stanislaw
Re: [PATCH 2/5] rt2x00: rework channel config function
On Mon, Sep 17, 2018 at 06:32:52PM +0200, Tomislav Požega wrote:
> Enable LNAs only for the current operating band. Change power
> amplifiers enabling style to the one in vco calibration routine
> and drop redundant cap_bt_coexist enable of PA0.
> - rt2x00_set_field32(_pin, TX_PIN_CFG_PA_PE_A0_EN,
> -rf->channel > 14);
> - if (rt2x00_has_cap_bt_coexist(rt2x00dev))
> + if (rt2x00dev->curr_band == NL80211_BAND_5GHZ) {
> + switch (rt2x00dev->default_ant.tx_chain_num) {
> + case 3:
> + rt2x00_set_field32(_pin, TX_PIN_CFG_PA_PE_A2_EN, 1);
> + case 2:
> + rt2x00_set_field32(_pin, TX_PIN_CFG_PA_PE_A1_EN, 1);
> + case 1:
> + rt2x00_set_field32(_pin, TX_PIN_CFG_PA_PE_A0_EN, 1);
> + break;
> + }
> + } else {
> + switch (rt2x00dev->default_ant.tx_chain_num) {
> + case 3:
> + rt2x00_set_field32(_pin, TX_PIN_CFG_PA_PE_G2_EN, 1);
> + case 2:
> + rt2x00_set_field32(_pin, TX_PIN_CFG_PA_PE_G1_EN, 1);
> + case 1:
So we never disable PA_PE_Gx_EN bits for RT6352 since tx_pin variable
is not nulifed, but read from register. I don't think this was intended.
Thanks
Stanislaw
Re: [PATCH 03/19] wilc: add host_interface.h
On Tue, 2018-10-09 at 16:04 +0530, Ajay Singh wrote:
> > > +typedef void (*wilc_remain_on_chan_expired)(void *, u32);
> > > +typedef void (*wilc_remain_on_chan_ready)(void *);
> I think as per coding style the typedef for function pointer are allowed.
True, I guess, but why do you need them?
> > > +struct rcvd_net_info {
> > > + u8 *buffer;
> > > + u32 len;
> > > +};
> > > +
> > > +struct hidden_net_info {
> > > + u8 *ssid;
> > > + u8 ssid_len;
> > > +};
> > > +
> > > +struct hidden_network {
> > > + struct hidden_net_info *net_info;
> > > + u8 n_ssids;
> > > +};
> >
> > This seems really odd - what part doesn't cfg80211 already handle?
>
> If I understood your question correctly, you meant what extra
> functionality 'hidden_network' struct is providing.
Pretty much. It seems like you're trying to handle hidden SSIDs in some
way, but ... that's odd.
> Actually this structure is just used to keeps list of SSID's requested
> in cfg80211 'scan' callback which is passed to firmware. The values are
> extracted from 'cfg80211_scan_request[struct cfg80211_ssid *ssids
> - int n_ssids] received during scan.
So then this has nothing to do with hidden SSID?
johannes
Re: [PATCH 03/19] wilc: add host_interface.h
On 10/8/2018 7:50 PM, Johannes Berg wrote:
> On Wed, 2018-09-26 at 15:55 +0530, Ajay Singh wrote:
>
>> +#include
> you include it
>
>> +#include "coreconfigurator.h"
>> +
>> +#define IDLE_MODE 0x00
>> +#define AP_MODE 0x01
>> +#define STATION_MODE0x02
>> +#define GO_MODE 0x03
>> +#define CLIENT_MODE 0x04
>> +#define ACTION 0xD0
>> +#define PROBE_REQ 0x40
>> +#define PROBE_RESP 0x50
> please use it too.
>
Ack.
>> +#define ACTION_FRM_IDX 0
>> +#define PROBE_REQ_IDX 1
>> +#define MAX_NUM_STA 9
>> +#define ACTIVE_SCAN_TIME10
>> +#define PASSIVE_SCAN_TIME 1200
>> +#define MIN_SCAN_TIME 10
>> +#define MAX_SCAN_TIME 1200
>> +#define DEFAULT_SCAN0
>> +#define USER_SCAN BIT(0)
>> +#define OBSS_PERIODIC_SCAN BIT(1)
>> +#define OBSS_ONETIME_SCAN BIT(2)
>> +#define GTK_RX_KEY_BUFF_LEN 24
>> +#define ADDKEY 0x1
>> +#define REMOVEKEY 0x2
>> +#define DEFAULTKEY 0x4
>> +#define ADDKEY_AP 0x8
>> +#define MAX_NUM_SCANNED_NETWORKS100
>> +#define MAX_NUM_SCANNED_NETWORKS_SHADOW 130
>> +#define MAX_NUM_PROBED_SSID 10
>> +#define CHANNEL_SCAN_TIME 250
>> +
>> +#define TX_MIC_KEY_LEN 8
>> +#define RX_MIC_KEY_LEN 8
>> +#define PTK_KEY_LEN 16
>> +
>> +#define TX_MIC_KEY_MSG_LEN 26
>> +#define RX_MIC_KEY_MSG_LEN 48
>> +#define PTK_KEY_MSG_LEN 39
>> +
>> +#define PMKSA_KEY_LEN 22
>> +#define ETH_ALEN6
> umm?
>
>> +#define PMKID_LEN 16
> ??
>
>> +#define WILC_MAX_NUM_PMKIDS 16
>> +#define WILC_ADD_STA_LENGTH 40
>> +#define NUM_CONCURRENT_IFC 2
>> +#define DRV_HANDLER_SIZE5
>> +#define DRV_HANDLER_MASK0x00FF
> Also this file is strangely mixing
> * 802.11 constants (that you shouldn't have anyway)
> * driver constants/structs
> * hardware/firmware-related things (at least it seems like - e.g. the
>"REMOVEKEY" constant)
>
> Please clean that up, separate the things, and pick a better
> namespace... just having "REMOVEKEY" is probably not a good idea.
>
Will work on this to clean it up.
>> +typedef void (*wilc_remain_on_chan_expired)(void *, u32);
>> +typedef void (*wilc_remain_on_chan_ready)(void *);
> Please no typedefs.
>
I think as per coding style the typedef for function pointer are allowed.
>> +struct rcvd_net_info {
>> +u8 *buffer;
>> +u32 len;
>> +};
>> +
>> +struct hidden_net_info {
>> +u8 *ssid;
>> +u8 ssid_len;
>> +};
>> +
>> +struct hidden_network {
>> +struct hidden_net_info *net_info;
>> +u8 n_ssids;
>> +};
> This seems really odd - what part doesn't cfg80211 already handle?
If I understood your question correctly, you meant what extra
functionality 'hidden_network' struct is providing.
Actually this structure is just used to keeps list of SSID's requested
in cfg80211 'scan' callback which is passed to firmware. The values are
extracted from 'cfg80211_scan_request[struct cfg80211_ssid *ssids
- int n_ssids] received during scan.
Regards,
Ajay
wireless workshop (was: Re: Announcing Netdev 0x13 conference)
Hi all, On Tue, 2018-09-18 at 08:11 -0400, Jamal Hadi Salim wrote: > On behalf of the NetDev Society, this is a formal announcement that > Netdev 0x13 conference will be held in Prague, Czech Republic. > Tentative dates are March 20-22, 2019. 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? Thanks, johannes
Re: [PATCH 02/19] wilc: add coreconfigurator.c
On Tue, 2018-10-09 at 15:12 +0530, Ajay Singh wrote:
> > > +static inline enum sub_frame_type get_sub_type(u8 *header)
> > > +{
> > > + return ((enum sub_frame_type)(header[0] & 0xFC));
> > > +}
> >
> > remove, use include/linux/ieee80211.h.
> >
>
> Did you mean to use '& IEEE80211_FCTL_STYPE' to get the frame sub type,
> instead of adding this API.
Perhaps, but I suspect you can do mostly with ieee80211_is_probe_resp()
and friends.
> > > +static inline u8 get_to_ds(u8 *header)
> > > +{
> > > + return (header[1] & 0x01);
> > > +}
> > > +
> > > +static inline u8 get_from_ds(u8 *header)
> > > +{
> > > + return ((header[1] & 0x02) >> 1);
> > > +}
> >
> > dito
> >
>
> Ack.
For this you have ieee80211_has_tods()/_fromds()/_a4() instead.
johannes
Re: [PATCH 02/19] wilc: add coreconfigurator.c
Hi,
Firstly, thanks alot for taking out time and reviewing our driver.
I will work on review comment and submit the updated code changes.
On 10/8/2018 7:46 PM, Johannes Berg wrote:
>> +static inline u16 get_beacon_period(u8 *data)
>> +{
>> +u16 bcn_per;
>> +
>> +bcn_per = data[0];
>> +bcn_per |= (data[1] << 8);
>> +
>> +return bcn_per;
>> +}
> Remove and use get_unaligned_le16().
>
Sure, I will change these to make use of get_unalinged_le16() API.
>> +static inline u32 get_beacon_timestamp_lo(u8 *data)
>> +{
>> +u32 time_stamp = 0;
>> +u32 index= MAC_HDR_LEN;
>> +
>> +time_stamp |= data[index++];
>> +time_stamp |= (data[index++] << 8);
>> +time_stamp |= (data[index++] << 16);
>> +time_stamp |= (data[index] << 24);
>> +
>> +return time_stamp;
>> +}
> get_unaligned_le32()
>
Ack.
>> +static inline u32 get_beacon_timestamp_hi(u8 *data)
>> +{
>> +u32 time_stamp = 0;
>> +u32 index= (MAC_HDR_LEN + 4);
>> +
>> +time_stamp |= data[index++];
>> +time_stamp |= (data[index++] << 8);
>> +time_stamp |= (data[index++] << 16);
>> +time_stamp |= (data[index] << 24);
>> +
>> +return time_stamp;
>> +}
> get_unaligned_le32()
>
Ack
>> +static inline enum sub_frame_type get_sub_type(u8 *header)
>> +{
>> +return ((enum sub_frame_type)(header[0] & 0xFC));
>> +}
> remove, use include/linux/ieee80211.h.
>
Did you mean to use '& IEEE80211_FCTL_STYPE' to get the frame sub type,
instead of adding this API.
>> +static inline u8 get_to_ds(u8 *header)
>> +{
>> +return (header[1] & 0x01);
>> +}
>> +
>> +static inline u8 get_from_ds(u8 *header)
>> +{
>> +return ((header[1] & 0x02) >> 1);
>> +}
> dito
>
Ack.
>> +static inline void get_address1(u8 *msa, u8 *addr)
>> +{
>> +memcpy(addr, msa + 4, 6);
>> +}
>> +
>> +static inline void get_address2(u8 *msa, u8 *addr)
>> +{
>> +memcpy(addr, msa + 10, 6);
>> +}
>> +
>> +static inline void get_address3(u8 *msa, u8 *addr)
> you probably shouldn't memcpy() here, that's expensive.
>
Got your point but currently a copy of 'network_info' is maintained for
the shadow buffer. As we have to work on removing the use of shadow
buffer so after those changes this extra memcpy can be avoided.
>> +static inline void get_bssid(u8 *data, u8 *bssid)
>> +{
>> +if (get_from_ds(data) == 1)
>> +get_address2(data, bssid);
>> +else if (get_to_ds(data) == 1)
>> +get_address1(data, bssid);
>> +else
>> +get_address3(data, bssid);
>> +}
> I just noticed we don't have this in ieee80211.h, but perhaps we should.
>
> I think you should just return a pointer though, there's no point in
> memcpy().
>
Same as above.
>> +static inline void get_ssid(u8 *data, u8 *ssid, u8 *p_ssid_len)
>> +{
>> +u8 i, j, len;
>> +
>> +len = data[TAG_PARAM_OFFSET + 1];
>> +j = TAG_PARAM_OFFSET + 2;
>> +
>> +if (len >= MAX_SSID_LEN)
>> +len = 0;
>> +
>> +for (i = 0; i < len; i++, j++)
>> +ssid[i] = data[j];
>> +
>> +ssid[len] = '\0';
> SSIDs are *NOT* strings, don't pretend they are.
>
Will check and modify to make use of ssid_len instead of using '\0' as
terminator.
>> +*p_ssid_len = len;
>> +}
> Uh, no, we have helper functions for finding elements.
>
> Again, return something, don't just fill out parameters.
>
>> +static inline u16 get_cap_info(u8 *data)
>> +{
>> +u16 cap_info = 0;
>> +u16 index= MAC_HDR_LEN;
>> +enum sub_frame_type st;
>> +
>> +st = get_sub_type(data);
>> +
>> +if (st == BEACON || st == PROBE_RSP)
>> +index += TIME_STAMP_LEN + BEACON_INTERVAL_LEN;
>> +
>> +cap_info = data[index];
>> +cap_info |= (data[index + 1] << 8);
>> +
>> +return cap_info;
>> +}
> Umm, no, ieee80211.h.
>
Ack.
>> +static inline u16 get_asoc_status(u8 *data)
>> +{
>> +u16 asoc_status;
>> +
>> +asoc_status = data[3];
>> +return (asoc_status << 8) | data[2];
>> +}
> I'll just stop here - you need to replace almost all of this file with
> ieee80211.h stuff instead.
As suggested, will modify this code to make use of ieee80211.h header.
Regards,
Ajay
[PATCH v2] mt76x0: phy: fix restore phase in mt76x0_phy_recalibrate_after_assoc
Fix restore value configured in MT_BBP(IBI, 9) register in
mt76x0_phy_recalibrate_after_assoc routine.
Fixes: 10de7a8b4ab9 ("mt76x0: phy files")
Signed-off-by: Lorenzo Bianconi
---
Changes since v1:
- use proper register name
---
drivers/net/wireless/mediatek/mt76/mt76x0/phy.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
index 99e0a91a2f99..29bc4e4623cd 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
@@ -733,9 +733,8 @@ void mt76x0_phy_recalibrate_after_assoc(struct mt76x02_dev
*dev)
mt76_wr(dev, MT_TX_ALC_CFG_0, 0);
usleep_range(500, 700);
- reg_val = mt76_rr(dev, 0x2124);
- reg_val &= 0xff7e;
- mt76_wr(dev, 0x2124, reg_val);
+ reg_val = mt76_rr(dev, MT_BBP(IBI, 9));
+ mt76_wr(dev, MT_BBP(IBI, 9), 0xff7e);
mt76x02_mcu_calibrate(dev, MCU_CAL_RXDCOC, 0, false);
@@ -746,7 +745,7 @@ void mt76x0_phy_recalibrate_after_assoc(struct mt76x02_dev
*dev)
mt76x02_mcu_calibrate(dev, MCU_CAL_RXIQ, is_5ghz, false);
mt76x02_mcu_calibrate(dev, MCU_CAL_RX_GROUP_DELAY, is_5ghz, false);
- mt76_wr(dev, 0x2124, reg_val);
+ mt76_wr(dev, MT_BBP(IBI, 9), reg_val);
mt76_wr(dev, MT_TX_ALC_CFG_0, tx_alc);
msleep(100);
--
2.17.1
[PATCH] mt76: mt76x0e: another fix for the external PA current setting
- Use the register number define instead of a magic value
- Fix inverted bit test (override needs to be applied if the bit is not set)
Fixes: 2b2cb40bcd7d ("mt76x0: pci: add hw initialization at bootstrap")
Signed-off-by: Felix Fietkau
---
drivers/net/wireless/mediatek/mt76/mt76x0/pci.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
b/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
index cc8af17dc9c7..fd2dc7efeea3 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
@@ -111,17 +111,10 @@ static int mt76x0e_register_device(struct mt76x02_dev
*dev)
u16 val;
mt76_clear(dev, MT_COEXCFG0, BIT(0));
+
val = mt76x02_eeprom_get(dev, MT_EE_NIC_CONF_0);
- if (val & MT_EE_NIC_CONF_0_PA_IO_CURRENT) {
- u32 data;
-
- /* set external PA I/O
-* current to 16mA
-*/
- data = mt76_rr(dev, 0x11c);
- data |= 0xc03;
- mt76_wr(dev, 0x11c, data);
- }
+ if (!(val & MT_EE_NIC_CONF_0_PA_IO_CURRENT))
+ mt76_set(dev, MT_XO_CTRL7, 0xc03);
}
mt76_clear(dev, 0x110, BIT(9));
--
2.17.0
Re: [PATCH] mt76x0: phy: fix restore phase in mt76x0_phy_recalibrate_after_assoc
> > I think is needed we do: > > > > reg_val = mt76_rr(dev, 0x2124); > > mt76_wr(dev, 0x2124, 0xff7e); > > > > CALIBRATE > > > > mt76_wr(dev, 0x2124, reg_val); > > > > so seems we have to restore orginal value after calibration. > > > > Referencing as MT_BBP(IBI, 9) is obviously fine. > Yes, that makes more sense. > > - Felix Ack, I will send v2 with proper register name. Regards, Lorenzo
Re: [PATCH] mt76x0: phy: fix restore phase in mt76x0_phy_recalibrate_after_assoc
On 2018-10-09 09:35, Stanislaw Gruszka wrote:
> On Mon, Oct 08, 2018 at 08:11:45PM +0200, Felix Fietkau wrote:
>> On 2018-10-08 14:40, Lorenzo Bianconi wrote:
>> > Fix restore value configured in 0x2124 register in
>> > mt76x0_phy_recalibrate_after_assoc routine.
>> >
>> > Fixes: 10de7a8b4ab9 ("mt76x0: phy files")
>> > Signed-off-by: Lorenzo Bianconi
>> > ---
>> > drivers/net/wireless/mediatek/mt76/mt76x0/phy.c | 3 +--
>> > 1 file changed, 1 insertion(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
>> > b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
>> > index 99e0a91a2f99..d18942e54048 100644
>> > --- a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
>> > +++ b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
>> > @@ -734,8 +734,7 @@ void mt76x0_phy_recalibrate_after_assoc(struct
>> > mt76x02_dev *dev)
>> >usleep_range(500, 700);
>> >
>> >reg_val = mt76_rr(dev, 0x2124);
>> > - reg_val &= 0xff7e;
>> > - mt76_wr(dev, 0x2124, reg_val);
>> > + mt76_wr(dev, 0x2124, 0xff7e);
>> I'm pretty sure you can drop the mt76_rr as well. Also, you can refer to
>> 0x2124 as MT_BBP(IBI, 9).
>
> I think is needed we do:
>
> reg_val = mt76_rr(dev, 0x2124);
> mt76_wr(dev, 0x2124, 0xff7e);
>
> CALIBRATE
>
> mt76_wr(dev, 0x2124, reg_val);
>
> so seems we have to restore orginal value after calibration.
>
> Referencing as MT_BBP(IBI, 9) is obviously fine.
Yes, that makes more sense.
- Felix
[PATCH] mac80211: avoid reflecting frames back to the client
From: Johannes Berg
I'm not really sure exactly _why_ I've been carrying a note
for what's probably _years_ to check that we don't do this,
but we clearly do reflect frames back to the station itself
if it sends such.
One way or the other, it's useless since the station doesn't
really need the AP to talk to itself, so suppress it.
While at it, clarify some of the logic by removing skb->data
references in favour of the destination address (pointer) we
already have separately.
Signed-off-by: Johannes Berg
---
net/mac80211/rx.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 96611d5dfadb..9d93d60d0635 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2425,8 +2425,9 @@ ieee80211_deliver_skb(struct ieee80211_rx_data *rx)
if (!xmit_skb)
net_info_ratelimited("%s: failed to clone
multicast frame\n",
dev->name);
- } else if (!is_multicast_ether_addr(ehdr->h_dest)) {
- dsta = sta_info_get(sdata, skb->data);
+ } else if (!is_multicast_ether_addr(ehdr->h_dest) &&
+ !ether_addr_equal(ehdr->h_dest, ehdr->h_source)) {
+ dsta = sta_info_get(sdata, ehdr->h_dest);
if (dsta) {
/*
* The destination station is associated to
@@ -4207,11 +4208,10 @@ static bool ieee80211_invoke_fast_rx(struct
ieee80211_rx_data *rx,
if (fast_rx->internal_forward) {
struct sk_buff *xmit_skb = NULL;
- bool multicast = is_multicast_ether_addr(skb->data);
-
- if (multicast) {
+ if (is_multicast_ether_addr(addrs.da)) {
xmit_skb = skb_copy(skb, GFP_ATOMIC);
- } else if (sta_info_get(rx->sdata, skb->data)) {
+ } else if (!ether_addr_equal(addrs.da, addrs.sa) &&
+ sta_info_get(rx->sdata, addrs.da)) {
xmit_skb = skb;
skb = NULL;
}
--
2.14.4
Re: [PATCH iw] iw: fix enum warnings
On Mon, 2018-10-08 at 10:51 -0700, Brian Norris wrote: > clang warns about the misuse of enums: > > reg.c:246:26: warning: implicit conversion from enumeration type 'enum > command_identify_by' to different enumeration type 'enum id_input' > [-Wenum-conversion] > err = handle_cmd(state, CIB_NONE, 2, dump_args); > ~~^~~~ > info.c:645:26: warning: implicit conversion from enumeration type 'enum > command_identify_by' to different enumeration type 'enum id_input' > [-Wenum-conversion] > err = handle_cmd(state, CIB_NONE, 2, feat_args); > ~~^~~~ Applied, thanks. johannes
Re: [PATCH 12/19] wilc: add wilc_wfi_cfgoperations.c
On Tue, 2018-10-09 at 04:23 +, adham.aboza...@microchip.com wrote: > > > I don't know what you need the shadow stuff for, but you should remove > > it anyway, and use the cfg80211 functionality instead. If not > > sufficient, propose patches to improve it? > > The point behind using a shadow buffer was to keep the scan results > consistent between consecutive scans, and smooth out the cases where > an AP isn't found momentarily during scanning. > In this implementation, APs found during scanning are added to the > shadow list, and removed if not found again for a period of time. > > I'm not much in favour of this implementation neither since it > complicates the driver's logic, but it was serving the purpose. You really should remove it - cfg80211 *and* wpa_s already do this if required. johannes
Re: [PATCH] libertas: call into generic suspend code before turning off power
On 8 October 2018 at 22:03, Daniel Mack wrote:
> When powering down a SDIO connected card during suspend, make sure to call
> into the generic lbs_suspend() function before pulling the plug. This will
> make sure the card is successfully deregistered from the system to avoid
> communication to the card starving out.
>
> Fixes: 7444a8092906 ("libertas: fix suspend and resume for SDIO connected
> cards")
> Signed-off-by: Daniel Mack
Reviewed-by: Ulf Hansson
BTW, if you need this to reach 4.19 I have already queued some other
mmc fixes so I can take this as well, if it helps. I need and ack of
course.
Kind regards
Uffe
> ---
> If possible, this should go in for 4.19.
>
> drivers/net/wireless/marvell/libertas/if_sdio.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/wireless/marvell/libertas/if_sdio.c
> b/drivers/net/wireless/marvell/libertas/if_sdio.c
> index 43743c26c071..39bf85d0ade0 100644
> --- a/drivers/net/wireless/marvell/libertas/if_sdio.c
> +++ b/drivers/net/wireless/marvell/libertas/if_sdio.c
> @@ -1317,6 +1317,10 @@ static int if_sdio_suspend(struct device *dev)
> if (priv->wol_criteria == EHS_REMOVE_WAKEUP) {
> dev_info(dev, "Suspend without wake params -- powering down
> card\n");
> if (priv->fw_ready) {
> + ret = lbs_suspend(priv);
> + if (ret)
> + return ret;
> +
> priv->power_up_on_resume = true;
> if_sdio_power_off(card);
> }
> --
> 2.17.1
>
Re: [PATCH] mt76x0: phy: fix restore phase in mt76x0_phy_recalibrate_after_assoc
On Mon, Oct 08, 2018 at 08:11:45PM +0200, Felix Fietkau wrote:
> On 2018-10-08 14:40, Lorenzo Bianconi wrote:
> > Fix restore value configured in 0x2124 register in
> > mt76x0_phy_recalibrate_after_assoc routine.
> >
> > Fixes: 10de7a8b4ab9 ("mt76x0: phy files")
> > Signed-off-by: Lorenzo Bianconi
> > ---
> > drivers/net/wireless/mediatek/mt76/mt76x0/phy.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
> > b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
> > index 99e0a91a2f99..d18942e54048 100644
> > --- a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
> > +++ b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
> > @@ -734,8 +734,7 @@ void mt76x0_phy_recalibrate_after_assoc(struct
> > mt76x02_dev *dev)
> > usleep_range(500, 700);
> >
> > reg_val = mt76_rr(dev, 0x2124);
> > - reg_val &= 0xff7e;
> > - mt76_wr(dev, 0x2124, reg_val);
> > + mt76_wr(dev, 0x2124, 0xff7e);
> I'm pretty sure you can drop the mt76_rr as well. Also, you can refer to
> 0x2124 as MT_BBP(IBI, 9).
I think is needed we do:
reg_val = mt76_rr(dev, 0x2124);
mt76_wr(dev, 0x2124, 0xff7e);
CALIBRATE
mt76_wr(dev, 0x2124, reg_val);
so seems we have to restore orginal value after calibration.
Referencing as MT_BBP(IBI, 9) is obviously fine.
Thanks
Stanislaw
