Re: [linuxwifi] [PATCH] fix iwlwifi on old cards in v4.19 was Re: 4.19-rc[23] iwlwifi: BUG in swiotlb
On 10/6/18 5:44 PM, Randy Dunlap wrote: > On 9/16/18 3:12 AM, Grumbach, Emmanuel wrote: >>> >>> >>> .max_tfd_queue_size was ommited for old cards, leading to oops in swiotlb. >>> >>> Signed-off-by: Pavel Machek >>> >> >> I picked it up in our tree with minor commit message fixes. >> I also added the Fixes tag for stable. >> >> Thanks! > > Hi, > Are we going to see this fix in 4.19? hopefully. Sorry, I see it now. thanks, -- ~Randy
Re: [PATCH] rtlwifi: rtl8821ae: add in a missing break in switch statement
On 10/6/18 5:03 PM, Joe Perches wrote:
On Sat, 2018-10-06 at 17:00 -0500, Larry Finger wrote:
On 10/6/18 3:17 PM, Joe Perches wrote:
On Sat, 2018-10-06 at 15:05 -0500, Larry Finger wrote:
On 10/6/18 2:30 PM, Kalle Valo wrote:
Colin King writes:
From: Colin Ian King
The switch case RATR_INX_WIRELESS_MC has a missing break, this seems
to be unintentional as the setting of variable ret gets overwritten
when the case falls through to the following RATR_INX_WIRELESS_AC_5N
case. Fix this by adding in the missing break.
Detected by CoverityScan, CID#1167237 ("Missing break in switch")
Fixes: 3c05bedb5fef ("Staging: rtl8812ae: Add Realtek 8821 PCI WIFI driver")
Signed-off-by: Colin Ian King
---
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 1 +
Is the fixes line correct? This patch is not for staging.
No, the correct fixes commit is 21e4b0726dc67 (" rtlwifi: rtl8821ae: Move driver
from staging to regular tree").
This driver was initially placed in staging as it was needed for a special
project, which is the commit that Colin used. As the patch subject states, the
driver was later moved to the regular wireless tree.
That break is required, thus ACKed-by: Larry Finger
Why not remove this entirely and use the generic routine in
drivers/net/wireless/realtek/rtlwifi/base.c?
Is there a real difference?
I did not see any difference other than the removal of a bunch of magic numbers
and better formatting.
Me neither.
Colin,
Do you want to push the new patch removing the duplicate routine from rtl8821ae?
Larry
Re: [linuxwifi] [PATCH] fix iwlwifi on old cards in v4.19 was Re: 4.19-rc[23] iwlwifi: BUG in swiotlb
On 9/16/18 3:12 AM, Grumbach, Emmanuel wrote: >> >> >> .max_tfd_queue_size was ommited for old cards, leading to oops in swiotlb. >> >> Signed-off-by: Pavel Machek >> > > I picked it up in our tree with minor commit message fixes. > I also added the Fixes tag for stable. > > Thanks! Hi, Are we going to see this fix in 4.19? hopefully. thanks, -- ~Randy
[PATCH v2] libertas: return errno from lbs_add_card()
This makes the error handling somewhat cleaner -- lbs_add_card() does no
logner throw away the errno and lets its callers propagate it.
Signed-off-by: Lubomir Rintel
---
Changes since v1:
- Address SPI & USB build failures
drivers/net/wireless/marvell/libertas/if_cs.c | 4 ++--
drivers/net/wireless/marvell/libertas/if_sdio.c | 4 ++--
drivers/net/wireless/marvell/libertas/if_spi.c | 4 ++--
drivers/net/wireless/marvell/libertas/if_usb.c | 5 -
drivers/net/wireless/marvell/libertas/main.c| 17 ++---
5 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/marvell/libertas/if_cs.c
b/drivers/net/wireless/marvell/libertas/if_cs.c
index 7d88223f890b..cebf03c6a622 100644
--- a/drivers/net/wireless/marvell/libertas/if_cs.c
+++ b/drivers/net/wireless/marvell/libertas/if_cs.c
@@ -900,8 +900,8 @@ static int if_cs_probe(struct pcmcia_device *p_dev)
/* Make this card known to the libertas driver */
priv = lbs_add_card(card, &p_dev->dev);
- if (!priv) {
- ret = -ENOMEM;
+ if (IS_ERR(priv)) {
+ ret = PTR_ERR(priv);
goto out2;
}
diff --git a/drivers/net/wireless/marvell/libertas/if_sdio.c
b/drivers/net/wireless/marvell/libertas/if_sdio.c
index 43743c26c071..2fd54a0aeb5a 100644
--- a/drivers/net/wireless/marvell/libertas/if_sdio.c
+++ b/drivers/net/wireless/marvell/libertas/if_sdio.c
@@ -1206,8 +1206,8 @@ static int if_sdio_probe(struct sdio_func *func,
priv = lbs_add_card(card, &func->dev);
- if (!priv) {
- ret = -ENOMEM;
+ if (IS_ERR(priv)) {
+ ret = PTR_ERR(priv);
goto free;
}
diff --git a/drivers/net/wireless/marvell/libertas/if_spi.c
b/drivers/net/wireless/marvell/libertas/if_spi.c
index e9aec6cb1105..504d6e096476 100644
--- a/drivers/net/wireless/marvell/libertas/if_spi.c
+++ b/drivers/net/wireless/marvell/libertas/if_spi.c
@@ -1146,8 +1146,8 @@ static int if_spi_probe(struct spi_device *spi)
* This will call alloc_etherdev.
*/
priv = lbs_add_card(card, &spi->dev);
- if (!priv) {
- err = -ENOMEM;
+ if (IS_ERR(priv)) {
+ err = PTR_ERR(priv);
goto free_card;
}
card->priv = priv;
diff --git a/drivers/net/wireless/marvell/libertas/if_usb.c
b/drivers/net/wireless/marvell/libertas/if_usb.c
index c67a8e7be310..5fee555a3d60 100644
--- a/drivers/net/wireless/marvell/libertas/if_usb.c
+++ b/drivers/net/wireless/marvell/libertas/if_usb.c
@@ -254,8 +254,11 @@ static int if_usb_probe(struct usb_interface *intf,
goto dealloc;
}
- if (!(priv = lbs_add_card(cardp, &intf->dev)))
+ priv = lbs_add_card(cardp, &intf->dev);
+ if (IS_ERR(priv)) {
+ r = PTR_ERR(priv);
goto err_add_card;
+ }
cardp->priv = priv;
diff --git a/drivers/net/wireless/marvell/libertas/main.c
b/drivers/net/wireless/marvell/libertas/main.c
index f22e1c220cba..f7db60bc7c7f 100644
--- a/drivers/net/wireless/marvell/libertas/main.c
+++ b/drivers/net/wireless/marvell/libertas/main.c
@@ -907,25 +907,29 @@ struct lbs_private *lbs_add_card(void *card, struct
device *dmdev)
struct net_device *dev;
struct wireless_dev *wdev;
struct lbs_private *priv = NULL;
+ int err;
/* Allocate an Ethernet device and register it */
wdev = lbs_cfg_alloc(dmdev);
if (IS_ERR(wdev)) {
+ err = PTR_ERR(wdev);
pr_err("cfg80211 init failed\n");
- goto done;
+ goto err_cfg;
}
wdev->iftype = NL80211_IFTYPE_STATION;
priv = wdev_priv(wdev);
priv->wdev = wdev;
- if (lbs_init_adapter(priv)) {
+ err = lbs_init_adapter(priv);
+ if (err) {
pr_err("failed to initialize adapter structure\n");
goto err_wdev;
}
dev = alloc_netdev(0, "wlan%d", NET_NAME_UNKNOWN, ether_setup);
if (!dev) {
+ err = -ENOMEM;
dev_err(dmdev, "no memory for network device instance\n");
goto err_adapter;
}
@@ -949,6 +953,7 @@ struct lbs_private *lbs_add_card(void *card, struct device
*dmdev)
init_waitqueue_head(&priv->waitq);
priv->main_thread = kthread_run(lbs_thread, dev, "lbs_main");
if (IS_ERR(priv->main_thread)) {
+ err = PTR_ERR(priv->main_thread);
lbs_deb_thread("Error creating main thread.\n");
goto err_ndev;
}
@@ -961,7 +966,7 @@ struct lbs_private *lbs_add_card(void *card, struct device
*dmdev)
priv->wol_gap = 20;
priv->ehs_remove_supported = true;
- goto done;
+ return priv;
err_ndev:
free_netdev(dev);
@@ -972,10 +977,8 @@ struct lbs_private *lbs_add_card(void *card, struct device
*dmdev)
err_wdev:
lbs_cfg_fre
Re: [PATCH] rtlwifi: rtl8821ae: add in a missing break in switch statement
On Sat, 2018-10-06 at 17:00 -0500, Larry Finger wrote:
> On 10/6/18 3:17 PM, Joe Perches wrote:
> > On Sat, 2018-10-06 at 15:05 -0500, Larry Finger wrote:
> > > On 10/6/18 2:30 PM, Kalle Valo wrote:
> > > > Colin King writes:
> > > >
> > > > > From: Colin Ian King
> > > > >
> > > > > The switch case RATR_INX_WIRELESS_MC has a missing break, this seems
> > > > > to be unintentional as the setting of variable ret gets overwritten
> > > > > when the case falls through to the following RATR_INX_WIRELESS_AC_5N
> > > > > case. Fix this by adding in the missing break.
> > > > >
> > > > > Detected by CoverityScan, CID#1167237 ("Missing break in switch")
> > > > >
> > > > > Fixes: 3c05bedb5fef ("Staging: rtl8812ae: Add Realtek 8821 PCI WIFI
> > > > > driver")
> > > > > Signed-off-by: Colin Ian King
> > > > > ---
> > > > >drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 1 +
> > > >
> > > > Is the fixes line correct? This patch is not for staging.
> > >
> > > No, the correct fixes commit is 21e4b0726dc67 (" rtlwifi: rtl8821ae: Move
> > > driver
> > > from staging to regular tree").
> > >
> > > This driver was initially placed in staging as it was needed for a special
> > > project, which is the commit that Colin used. As the patch subject
> > > states, the
> > > driver was later moved to the regular wireless tree.
> > >
> > > That break is required, thus ACKed-by: Larry Finger
> > >
> >
> > Why not remove this entirely and use the generic routine in
> > drivers/net/wireless/realtek/rtlwifi/base.c?
> >
> > Is there a real difference?
>
> I did not see any difference other than the removal of a bunch of magic
> numbers
> and better formatting.
Me neither.
Re: [PATCH] rtlwifi: rtl8821ae: add in a missing break in switch statement
On 10/6/18 3:17 PM, Joe Perches wrote:
On Sat, 2018-10-06 at 15:05 -0500, Larry Finger wrote:
On 10/6/18 2:30 PM, Kalle Valo wrote:
Colin King writes:
From: Colin Ian King
The switch case RATR_INX_WIRELESS_MC has a missing break, this seems
to be unintentional as the setting of variable ret gets overwritten
when the case falls through to the following RATR_INX_WIRELESS_AC_5N
case. Fix this by adding in the missing break.
Detected by CoverityScan, CID#1167237 ("Missing break in switch")
Fixes: 3c05bedb5fef ("Staging: rtl8812ae: Add Realtek 8821 PCI WIFI driver")
Signed-off-by: Colin Ian King
---
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 1 +
Is the fixes line correct? This patch is not for staging.
No, the correct fixes commit is 21e4b0726dc67 (" rtlwifi: rtl8821ae: Move driver
from staging to regular tree").
This driver was initially placed in staging as it was needed for a special
project, which is the commit that Colin used. As the patch subject states, the
driver was later moved to the regular wireless tree.
That break is required, thus ACKed-by: Larry Finger
Why not remove this entirely and use the generic routine in
drivers/net/wireless/realtek/rtlwifi/base.c?
Is there a real difference?
I did not see any difference other than the removal of a bunch of magic numbers
and better formatting.
Larry
Re: [PATCH] rtlwifi: rtl8821ae: add in a missing break in switch statement
On Sat, 2018-10-06 at 15:05 -0500, Larry Finger wrote:
> On 10/6/18 2:30 PM, Kalle Valo wrote:
> > Colin King writes:
> >
> > > From: Colin Ian King
> > >
> > > The switch case RATR_INX_WIRELESS_MC has a missing break, this seems
> > > to be unintentional as the setting of variable ret gets overwritten
> > > when the case falls through to the following RATR_INX_WIRELESS_AC_5N
> > > case. Fix this by adding in the missing break.
> > >
> > > Detected by CoverityScan, CID#1167237 ("Missing break in switch")
> > >
> > > Fixes: 3c05bedb5fef ("Staging: rtl8812ae: Add Realtek 8821 PCI WIFI
> > > driver")
> > > Signed-off-by: Colin Ian King
> > > ---
> > > drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 1 +
> >
> > Is the fixes line correct? This patch is not for staging.
>
> No, the correct fixes commit is 21e4b0726dc67 (" rtlwifi: rtl8821ae: Move
> driver
> from staging to regular tree").
>
> This driver was initially placed in staging as it was needed for a special
> project, which is the commit that Colin used. As the patch subject states,
> the
> driver was later moved to the regular wireless tree.
>
> That break is required, thus ACKed-by: Larry Finger
>
Why not remove this entirely and use the generic routine in
drivers/net/wireless/realtek/rtlwifi/base.c?
Is there a real difference?
[PATCH] libertas: don't set URB_ZERO_PACKET on IN USB transfer
The USB core gets rightfully upset:
usb 1-1: BOGUS urb flags, 240 --> 200
WARNING: CPU: 0 PID: 60 at drivers/usb/core/urb.c:503
usb_submit_urb+0x2f8/0x3ed
Modules linked in:
CPU: 0 PID: 60 Comm: kworker/0:3 Not tainted 4.19.0-rc6-00319-g5206d00a45c7
#39
Hardware name: OLPC XO/XO, BIOS OLPC Ver 1.00.01 06/11/2014
Workqueue: events request_firmware_work_func
EIP: usb_submit_urb+0x2f8/0x3ed
Code: 75 06 8b 8f 80 00 00 00 8d 47 78 89 4d e4 89 55 e8 e8 35 1c f6 ff 8b 55
e8 56 52 8b 4d e4 51 50 68 e3 ce c7 c0 e8 ed 18 c6 ff <0f> 0b 83 c4 14 80 7d ef
01 74 0a 80 7d ef 03 0f 85 b8 00 00 00 8b
EAX: 0025 EBX: ce7d4980 ECX: EDX: 0001
ESI: 0200 EDI: ce7d8800 EBP: ce7f5ea8 ESP: ce7f5e70
DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 EFLAGS: 00210292
CR0: 80050033 CR2: CR3: 00e8 CR4: 0090
Call Trace:
? if_usb_fw_timeo+0x64/0x64
__if_usb_submit_rx_urb+0x85/0xe6
? if_usb_fw_timeo+0x64/0x64
if_usb_submit_rx_urb_fwload+0xd/0xf
if_usb_prog_firmware+0xc0/0x3db
? _request_firmware+0x54/0x47b
? _request_firmware+0x89/0x47b
? if_usb_probe+0x412/0x412
lbs_fw_loaded+0x55/0xa6
? debug_smp_processor_id+0x12/0x14
helper_firmware_cb+0x3c/0x3f
request_firmware_work_func+0x37/0x6f
process_one_work+0x164/0x25a
worker_thread+0x1c4/0x284
kthread+0xec/0xf1
? cancel_delayed_work_sync+0xf/0xf
? kthread_create_on_node+0x1a/0x1a
ret_from_fork+0x2e/0x38
---[ end trace 3ef1e3b2dd53852f ]---
Cc: sta...@vger.kernel.org
Signed-off-by: Lubomir Rintel
---
drivers/net/wireless/marvell/libertas/if_usb.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wireless/marvell/libertas/if_usb.c
b/drivers/net/wireless/marvell/libertas/if_usb.c
index 5fee555a3d60..220dcdee8d2b 100644
--- a/drivers/net/wireless/marvell/libertas/if_usb.c
+++ b/drivers/net/wireless/marvell/libertas/if_usb.c
@@ -459,8 +459,6 @@ static int __if_usb_submit_rx_urb(struct if_usb_card *cardp,
MRVDRV_ETH_RX_PACKET_BUFFER_SIZE, callbackfn,
cardp);
- cardp->rx_urb->transfer_flags |= URB_ZERO_PACKET;
-
lbs_deb_usb2(&cardp->udev->dev, "Pointer for rx_urb %p\n",
cardp->rx_urb);
if ((ret = usb_submit_urb(cardp->rx_urb, GFP_ATOMIC))) {
lbs_deb_usbd(&cardp->udev->dev, "Submit Rx URB failed: %d\n",
ret);
--
2.19.0
Re: [PATCH] rtlwifi: rtl8821ae: add in a missing break in switch statement
On 10/6/18 2:30 PM, Kalle Valo wrote:
Colin King writes:
From: Colin Ian King
The switch case RATR_INX_WIRELESS_MC has a missing break, this seems
to be unintentional as the setting of variable ret gets overwritten
when the case falls through to the following RATR_INX_WIRELESS_AC_5N
case. Fix this by adding in the missing break.
Detected by CoverityScan, CID#1167237 ("Missing break in switch")
Fixes: 3c05bedb5fef ("Staging: rtl8812ae: Add Realtek 8821 PCI WIFI driver")
Signed-off-by: Colin Ian King
---
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 1 +
Is the fixes line correct? This patch is not for staging.
No, the correct fixes commit is 21e4b0726dc67 (" rtlwifi: rtl8821ae: Move driver
from staging to regular tree").
This driver was initially placed in staging as it was needed for a special
project, which is the commit that Colin used. As the patch subject states, the
driver was later moved to the regular wireless tree.
That break is required, thus ACKed-by: Larry Finger
thanks,
Larry
Re: [PATCH] rtlwifi: rtl8821ae: add in a missing break in switch statement
Colin King writes:
> From: Colin Ian King
>
> The switch case RATR_INX_WIRELESS_MC has a missing break, this seems
> to be unintentional as the setting of variable ret gets overwritten
> when the case falls through to the following RATR_INX_WIRELESS_AC_5N
> case. Fix this by adding in the missing break.
>
> Detected by CoverityScan, CID#1167237 ("Missing break in switch")
>
> Fixes: 3c05bedb5fef ("Staging: rtl8812ae: Add Realtek 8821 PCI WIFI driver")
> Signed-off-by: Colin Ian King
> ---
> drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 1 +
Is the fixes line correct? This patch is not for staging.
--
Kalle Valo
[PATCH] rtlwifi: rtl8821ae: add in a missing break in switch statement
From: Colin Ian King
The switch case RATR_INX_WIRELESS_MC has a missing break, this seems
to be unintentional as the setting of variable ret gets overwritten
when the case falls through to the following RATR_INX_WIRELESS_AC_5N
case. Fix this by adding in the missing break.
Detected by CoverityScan, CID#1167237 ("Missing break in switch")
Fixes: 3c05bedb5fef ("Staging: rtl8812ae: Add Realtek 8821 PCI WIFI driver")
Signed-off-by: Colin Ian King
---
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
index 317c1b3101da..8af49c1c99db 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
@@ -3448,6 +3448,7 @@ static u8 _rtl8821ae_mrate_idx_to_arfr_id(
ret = 6;
else
ret = 7;
+ break;
case RATR_INX_WIRELESS_AC_5N:
if (rtlphy->rf_type == RF_1T1R)
ret = 10;
--
2.17.1
Re: [PATCH 9/9] mac80211: rc80211_minstrel: remove variance / stddev calculation
On Sat, Oct 6, 2018 at 11:18 AM Felix Fietkau wrote:
>
> On 2018-10-06 19:59, Dave Taht wrote:
> > On Sat, Oct 6, 2018 at 10:37 AM Felix Fietkau wrote:
> >>
> >> When there are few packets (e.g. for sampling attempts), the exponentially
> >> weighted variance is usually vastly overestimated, making the resulting
> >> data
> >> essentially useless. As far as I know, there has not been any practical use
> >> for this, so let's not waste any cycles on it.
> >>
> >> Signed-off-by: Felix Fietkau
> >> ---
> >> net/mac80211/rc80211_minstrel.c| 6 -
> >> net/mac80211/rc80211_minstrel.h| 26 +-
> >> net/mac80211/rc80211_minstrel_debugfs.c| 14
> >> net/mac80211/rc80211_minstrel_ht_debugfs.c | 14
> >> 4 files changed, 9 insertions(+), 51 deletions(-)
> >>
> >> diff --git a/net/mac80211/rc80211_minstrel.c
> >> b/net/mac80211/rc80211_minstrel.c
> >> index dead57ba9eac..a34e9c2ca626 100644
> >> --- a/net/mac80211/rc80211_minstrel.c
> >> +++ b/net/mac80211/rc80211_minstrel.c
> >> @@ -167,12 +167,6 @@ minstrel_calc_rate_stats(struct minstrel_rate_stats
> >> *mrs)
> >> if (unlikely(!mrs->att_hist)) {
> >> mrs->prob_ewma = cur_prob;
> >> } else {
> >> - /* update exponential weighted moving variance */
> >> - mrs->prob_ewmv = minstrel_ewmv(mrs->prob_ewmv,
> >> - cur_prob,
> >> - mrs->prob_ewma,
> >> - EWMA_LEVEL);
> >> -
> >> /*update exponential weighted moving avarage */
> >> mrs->prob_ewma = minstrel_ewma(mrs->prob_ewma,
> >>cur_prob,
> >> diff --git a/net/mac80211/rc80211_minstrel.h
> >> b/net/mac80211/rc80211_minstrel.h
> >> index 54b2b2c3e10a..23ec953e3a24 100644
> >> --- a/net/mac80211/rc80211_minstrel.h
> >> +++ b/net/mac80211/rc80211_minstrel.h
> >> @@ -35,19 +35,6 @@ minstrel_ewma(int old, int new, int weight)
> >> return old + incr;
> >> }
> >>
> >> -/*
> >> - * Perform EWMV (Exponentially Weighted Moving Variance) calculation
> >> - */
> >
> > I worry about this one. where are you getting your proof from?
> I've done quite a few measurements myself to see if this can be usable
> for further rate control improvements or for the upcoming TPC work.
> The data this generates simply fluctuates wildly and incoherently based
> on the sampling behavior, making it completely useless.
> Together with Thomas (who introduced this code), I tried a few times to
> fix this, but couldn't find any way to make it coherent and usable.
>
> Thomas and I both agreed that it's better to just remove it until
> somebody has a better idea what to do.
>
> Also, this was only used for debugfs statistics, not for any actual rate
> control behavior.
OK, thanks. I'm totally delighted to see this patchset otherwise.
> - Felix
--
Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740
Re: [PATCH 9/9] mac80211: rc80211_minstrel: remove variance / stddev calculation
On 2018-10-06 19:59, Dave Taht wrote:
> On Sat, Oct 6, 2018 at 10:37 AM Felix Fietkau wrote:
>>
>> When there are few packets (e.g. for sampling attempts), the exponentially
>> weighted variance is usually vastly overestimated, making the resulting data
>> essentially useless. As far as I know, there has not been any practical use
>> for this, so let's not waste any cycles on it.
>>
>> Signed-off-by: Felix Fietkau
>> ---
>> net/mac80211/rc80211_minstrel.c| 6 -
>> net/mac80211/rc80211_minstrel.h| 26 +-
>> net/mac80211/rc80211_minstrel_debugfs.c| 14
>> net/mac80211/rc80211_minstrel_ht_debugfs.c | 14
>> 4 files changed, 9 insertions(+), 51 deletions(-)
>>
>> diff --git a/net/mac80211/rc80211_minstrel.c
>> b/net/mac80211/rc80211_minstrel.c
>> index dead57ba9eac..a34e9c2ca626 100644
>> --- a/net/mac80211/rc80211_minstrel.c
>> +++ b/net/mac80211/rc80211_minstrel.c
>> @@ -167,12 +167,6 @@ minstrel_calc_rate_stats(struct minstrel_rate_stats
>> *mrs)
>> if (unlikely(!mrs->att_hist)) {
>> mrs->prob_ewma = cur_prob;
>> } else {
>> - /* update exponential weighted moving variance */
>> - mrs->prob_ewmv = minstrel_ewmv(mrs->prob_ewmv,
>> - cur_prob,
>> - mrs->prob_ewma,
>> - EWMA_LEVEL);
>> -
>> /*update exponential weighted moving avarage */
>> mrs->prob_ewma = minstrel_ewma(mrs->prob_ewma,
>>cur_prob,
>> diff --git a/net/mac80211/rc80211_minstrel.h
>> b/net/mac80211/rc80211_minstrel.h
>> index 54b2b2c3e10a..23ec953e3a24 100644
>> --- a/net/mac80211/rc80211_minstrel.h
>> +++ b/net/mac80211/rc80211_minstrel.h
>> @@ -35,19 +35,6 @@ minstrel_ewma(int old, int new, int weight)
>> return old + incr;
>> }
>>
>> -/*
>> - * Perform EWMV (Exponentially Weighted Moving Variance) calculation
>> - */
>
> I worry about this one. where are you getting your proof from?
I've done quite a few measurements myself to see if this can be usable
for further rate control improvements or for the upcoming TPC work.
The data this generates simply fluctuates wildly and incoherently based
on the sampling behavior, making it completely useless.
Together with Thomas (who introduced this code), I tried a few times to
fix this, but couldn't find any way to make it coherent and usable.
Thomas and I both agreed that it's better to just remove it until
somebody has a better idea what to do.
Also, this was only used for debugfs statistics, not for any actual rate
control behavior.
- Felix
Re: [PATCH 9/9] mac80211: rc80211_minstrel: remove variance / stddev calculation
On Sat, Oct 6, 2018 at 10:37 AM Felix Fietkau wrote:
>
> When there are few packets (e.g. for sampling attempts), the exponentially
> weighted variance is usually vastly overestimated, making the resulting data
> essentially useless. As far as I know, there has not been any practical use
> for this, so let's not waste any cycles on it.
>
> Signed-off-by: Felix Fietkau
> ---
> net/mac80211/rc80211_minstrel.c| 6 -
> net/mac80211/rc80211_minstrel.h| 26 +-
> net/mac80211/rc80211_minstrel_debugfs.c| 14
> net/mac80211/rc80211_minstrel_ht_debugfs.c | 14
> 4 files changed, 9 insertions(+), 51 deletions(-)
>
> diff --git a/net/mac80211/rc80211_minstrel.c b/net/mac80211/rc80211_minstrel.c
> index dead57ba9eac..a34e9c2ca626 100644
> --- a/net/mac80211/rc80211_minstrel.c
> +++ b/net/mac80211/rc80211_minstrel.c
> @@ -167,12 +167,6 @@ minstrel_calc_rate_stats(struct minstrel_rate_stats *mrs)
> if (unlikely(!mrs->att_hist)) {
> mrs->prob_ewma = cur_prob;
> } else {
> - /* update exponential weighted moving variance */
> - mrs->prob_ewmv = minstrel_ewmv(mrs->prob_ewmv,
> - cur_prob,
> - mrs->prob_ewma,
> - EWMA_LEVEL);
> -
> /*update exponential weighted moving avarage */
> mrs->prob_ewma = minstrel_ewma(mrs->prob_ewma,
>cur_prob,
> diff --git a/net/mac80211/rc80211_minstrel.h b/net/mac80211/rc80211_minstrel.h
> index 54b2b2c3e10a..23ec953e3a24 100644
> --- a/net/mac80211/rc80211_minstrel.h
> +++ b/net/mac80211/rc80211_minstrel.h
> @@ -35,19 +35,6 @@ minstrel_ewma(int old, int new, int weight)
> return old + incr;
> }
>
> -/*
> - * Perform EWMV (Exponentially Weighted Moving Variance) calculation
> - */
I worry about this one. where are you getting your proof from?
> -static inline int
> -minstrel_ewmv(int old_ewmv, int cur_prob, int prob_ewma, int weight)
> -{
> - int diff, incr;
> -
> - diff = cur_prob - prob_ewma;
> - incr = (EWMA_DIV - weight) * diff / EWMA_DIV;
> - return weight * (old_ewmv + MINSTREL_TRUNC(diff * incr)) / EWMA_DIV;
> -}
> -
> struct minstrel_rate_stats {
> /* current / last sampling period attempts/success counters */
> u16 attempts, last_attempts;
> @@ -56,11 +43,8 @@ struct minstrel_rate_stats {
> /* total attempts/success counters */
> u32 att_hist, succ_hist;
>
> - /* statistis of packet delivery probability
> -* prob_ewma - exponential weighted moving average of prob
> -* prob_ewmsd - exp. weighted moving standard deviation of prob */
> + /* prob_ewma - exponential weighted moving average of prob */
> u16 prob_ewma;
> - u16 prob_ewmv;
>
> /* maximum retry counts */
> u8 retry_count;
> @@ -140,14 +124,6 @@ struct minstrel_debugfs_info {
> char buf[];
> };
>
> -/* Get EWMSD (Exponentially Weighted Moving Standard Deviation) * 10 */
> -static inline int
> -minstrel_get_ewmsd10(struct minstrel_rate_stats *mrs)
> -{
> - unsigned int ewmv = mrs->prob_ewmv;
> - return int_sqrt(MINSTREL_TRUNC(ewmv * 1000 * 1000));
> -}
> -
> extern const struct rate_control_ops mac80211_minstrel;
> void minstrel_add_sta_debugfs(void *priv, void *priv_sta, struct dentry
> *dir);
>
> diff --git a/net/mac80211/rc80211_minstrel_debugfs.c
> b/net/mac80211/rc80211_minstrel_debugfs.c
> index 698a668b5316..c8afd85b51a0 100644
> --- a/net/mac80211/rc80211_minstrel_debugfs.c
> +++ b/net/mac80211/rc80211_minstrel_debugfs.c
> @@ -70,14 +70,13 @@ minstrel_stats_open(struct inode *inode, struct file
> *file)
> p = ms->buf;
> p += sprintf(p, "\n");
> p += sprintf(p,
> -"best __rate_
> statisticslast___sum-of\n");
> +"best __rate_statistics___
> last___sum-of\n");
> p += sprintf(p,
> -"rate [name idx airtime max_tp] [avg(tp) avg(prob)
> sd(prob)] [retry|suc|att] [#success | #attempts]\n");
> +"rate [name idx airtime max_tp] [avg(tp) avg(prob)]
> [retry|suc|att] [#success | #attempts]\n");
>
> for (i = 0; i < mi->n_rates; i++) {
> struct minstrel_rate *mr = &mi->r[i];
> struct minstrel_rate_stats *mrs = &mi->r[i].stats;
> - unsigned int prob_ewmsd;
>
> *(p++) = (i == mi->max_tp_rate[0]) ? 'A' : ' ';
> *(p++) = (i == mi->max_tp_rate[1]) ? 'B' : ' ';
> @@ -93,15 +92,13 @@ minstrel_stats_open(struct inode *inode, struct fi
[PATCH 9/9] mac80211: rc80211_minstrel: remove variance / stddev calculation
When there are few packets (e.g. for sampling attempts), the exponentially
weighted variance is usually vastly overestimated, making the resulting data
essentially useless. As far as I know, there has not been any practical use
for this, so let's not waste any cycles on it.
Signed-off-by: Felix Fietkau
---
net/mac80211/rc80211_minstrel.c| 6 -
net/mac80211/rc80211_minstrel.h| 26 +-
net/mac80211/rc80211_minstrel_debugfs.c| 14
net/mac80211/rc80211_minstrel_ht_debugfs.c | 14
4 files changed, 9 insertions(+), 51 deletions(-)
diff --git a/net/mac80211/rc80211_minstrel.c b/net/mac80211/rc80211_minstrel.c
index dead57ba9eac..a34e9c2ca626 100644
--- a/net/mac80211/rc80211_minstrel.c
+++ b/net/mac80211/rc80211_minstrel.c
@@ -167,12 +167,6 @@ minstrel_calc_rate_stats(struct minstrel_rate_stats *mrs)
if (unlikely(!mrs->att_hist)) {
mrs->prob_ewma = cur_prob;
} else {
- /* update exponential weighted moving variance */
- mrs->prob_ewmv = minstrel_ewmv(mrs->prob_ewmv,
- cur_prob,
- mrs->prob_ewma,
- EWMA_LEVEL);
-
/*update exponential weighted moving avarage */
mrs->prob_ewma = minstrel_ewma(mrs->prob_ewma,
cur_prob,
diff --git a/net/mac80211/rc80211_minstrel.h b/net/mac80211/rc80211_minstrel.h
index 54b2b2c3e10a..23ec953e3a24 100644
--- a/net/mac80211/rc80211_minstrel.h
+++ b/net/mac80211/rc80211_minstrel.h
@@ -35,19 +35,6 @@ minstrel_ewma(int old, int new, int weight)
return old + incr;
}
-/*
- * Perform EWMV (Exponentially Weighted Moving Variance) calculation
- */
-static inline int
-minstrel_ewmv(int old_ewmv, int cur_prob, int prob_ewma, int weight)
-{
- int diff, incr;
-
- diff = cur_prob - prob_ewma;
- incr = (EWMA_DIV - weight) * diff / EWMA_DIV;
- return weight * (old_ewmv + MINSTREL_TRUNC(diff * incr)) / EWMA_DIV;
-}
-
struct minstrel_rate_stats {
/* current / last sampling period attempts/success counters */
u16 attempts, last_attempts;
@@ -56,11 +43,8 @@ struct minstrel_rate_stats {
/* total attempts/success counters */
u32 att_hist, succ_hist;
- /* statistis of packet delivery probability
-* prob_ewma - exponential weighted moving average of prob
-* prob_ewmsd - exp. weighted moving standard deviation of prob */
+ /* prob_ewma - exponential weighted moving average of prob */
u16 prob_ewma;
- u16 prob_ewmv;
/* maximum retry counts */
u8 retry_count;
@@ -140,14 +124,6 @@ struct minstrel_debugfs_info {
char buf[];
};
-/* Get EWMSD (Exponentially Weighted Moving Standard Deviation) * 10 */
-static inline int
-minstrel_get_ewmsd10(struct minstrel_rate_stats *mrs)
-{
- unsigned int ewmv = mrs->prob_ewmv;
- return int_sqrt(MINSTREL_TRUNC(ewmv * 1000 * 1000));
-}
-
extern const struct rate_control_ops mac80211_minstrel;
void minstrel_add_sta_debugfs(void *priv, void *priv_sta, struct dentry *dir);
diff --git a/net/mac80211/rc80211_minstrel_debugfs.c
b/net/mac80211/rc80211_minstrel_debugfs.c
index 698a668b5316..c8afd85b51a0 100644
--- a/net/mac80211/rc80211_minstrel_debugfs.c
+++ b/net/mac80211/rc80211_minstrel_debugfs.c
@@ -70,14 +70,13 @@ minstrel_stats_open(struct inode *inode, struct file *file)
p = ms->buf;
p += sprintf(p, "\n");
p += sprintf(p,
-"best __rate_
statisticslast___sum-of\n");
+"best __rate_statistics___
last___sum-of\n");
p += sprintf(p,
-"rate [name idx airtime max_tp] [avg(tp) avg(prob)
sd(prob)] [retry|suc|att] [#success | #attempts]\n");
+"rate [name idx airtime max_tp] [avg(tp) avg(prob)]
[retry|suc|att] [#success | #attempts]\n");
for (i = 0; i < mi->n_rates; i++) {
struct minstrel_rate *mr = &mi->r[i];
struct minstrel_rate_stats *mrs = &mi->r[i].stats;
- unsigned int prob_ewmsd;
*(p++) = (i == mi->max_tp_rate[0]) ? 'A' : ' ';
*(p++) = (i == mi->max_tp_rate[1]) ? 'B' : ' ';
@@ -93,15 +92,13 @@ minstrel_stats_open(struct inode *inode, struct file *file)
tp_max = minstrel_get_tp_avg(mr, MINSTREL_FRAC(100,100));
tp_avg = minstrel_get_tp_avg(mr, mrs->prob_ewma);
eprob = MINSTREL_TRUNC(mrs->prob_ewma * 1000);
- prob_ewmsd = minstrel_get_ewmsd10(mrs);
- p += sprintf(p, "%4u.%1u%4u.%1u %3
[PATCH 4/9] mac80211: minstrel: reduce minstrel_mcs_groups size
By storing a shift value for all duration values of a group, we can
reduce precision by a neglegible amount to make it fit into a u16 value.
This improves cache footprint and reduces size:
Before:
textdata bss dec hex filename
10024 116 0 10140279c rc80211_minstrel_ht.o
After:
textdata bss dec hex filename
9368 116 09484250c rc80211_minstrel_ht.o
Signed-off-by: Felix Fietkau
---
net/mac80211/rc80211_minstrel_ht.c | 153 +++--
net/mac80211/rc80211_minstrel_ht.h | 7 +-
net/mac80211/rc80211_minstrel_ht_debugfs.c | 11 +-
3 files changed, 93 insertions(+), 78 deletions(-)
diff --git a/net/mac80211/rc80211_minstrel_ht.c
b/net/mac80211/rc80211_minstrel_ht.c
index 0aec00990d1e..38e17ed20d41 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -52,22 +52,23 @@
_streams - 1
/* MCS rate information for an MCS group */
-#define MCS_GROUP(_streams, _sgi, _ht40) \
+#define MCS_GROUP(_streams, _sgi, _ht40, _s) \
[GROUP_IDX(_streams, _sgi, _ht40)] = { \
.streams = _streams,\
+ .shift = _s,\
.flags =\
IEEE80211_TX_RC_MCS | \
(_sgi ? IEEE80211_TX_RC_SHORT_GI : 0) | \
(_ht40 ? IEEE80211_TX_RC_40_MHZ_WIDTH : 0), \
.duration = { \
- MCS_DURATION(_streams, _sgi, _ht40 ? 54 : 26), \
- MCS_DURATION(_streams, _sgi, _ht40 ? 108 : 52), \
- MCS_DURATION(_streams, _sgi, _ht40 ? 162 : 78), \
- MCS_DURATION(_streams, _sgi, _ht40 ? 216 : 104),\
- MCS_DURATION(_streams, _sgi, _ht40 ? 324 : 156),\
- MCS_DURATION(_streams, _sgi, _ht40 ? 432 : 208),\
- MCS_DURATION(_streams, _sgi, _ht40 ? 486 : 234),\
- MCS_DURATION(_streams, _sgi, _ht40 ? 540 : 260) \
+ MCS_DURATION(_streams, _sgi, _ht40 ? 54 : 26) >> _s,\
+ MCS_DURATION(_streams, _sgi, _ht40 ? 108 : 52) >> _s, \
+ MCS_DURATION(_streams, _sgi, _ht40 ? 162 : 78) >> _s, \
+ MCS_DURATION(_streams, _sgi, _ht40 ? 216 : 104) >> _s, \
+ MCS_DURATION(_streams, _sgi, _ht40 ? 324 : 156) >> _s, \
+ MCS_DURATION(_streams, _sgi, _ht40 ? 432 : 208) >> _s, \
+ MCS_DURATION(_streams, _sgi, _ht40 ? 486 : 234) >> _s, \
+ MCS_DURATION(_streams, _sgi, _ht40 ? 540 : 260) >> _s \
} \
}
@@ -80,9 +81,10 @@
#define BW2VBPS(_bw, r3, r2, r1) \
(_bw == BW_80 ? r3 : _bw == BW_40 ? r2 : r1)
-#define VHT_GROUP(_streams, _sgi, _bw) \
+#define VHT_GROUP(_streams, _sgi, _bw, _s) \
[VHT_GROUP_IDX(_streams, _sgi, _bw)] = {\
.streams = _streams,\
+ .shift = _s,\
.flags =\
IEEE80211_TX_RC_VHT_MCS | \
(_sgi ? IEEE80211_TX_RC_SHORT_GI : 0) | \
@@ -90,25 +92,25 @@
_bw == BW_40 ? IEEE80211_TX_RC_40_MHZ_WIDTH : 0), \
.duration = { \
MCS_DURATION(_streams, _sgi,\
-BW2VBPS(_bw, 117, 54, 26)), \
+BW2VBPS(_bw, 117, 54, 26)) >> _s, \
MCS_DURATION(_streams, _sgi,\
-BW2VBPS(_bw, 234, 108, 52)), \
+BW2VBPS(_bw, 234, 108, 52)) >> _s, \
MCS_DURATION(_streams, _sgi,\
-BW2VBPS(_bw, 351, 162, 78)), \
+BW2VBPS(_bw, 351, 162, 78)) >> _s, \
MCS_DURATION(_streams, _sgi,\
-BW2VBPS(_bw, 468, 216, 104)), \
+BW2VBPS(_bw, 468, 216, 104)) >> _s, \
MCS_DURATION(_streams, _sgi,\
-BW2VBPS(_bw, 702, 324, 156)), \
+BW2VBPS(_bw, 702, 324, 156)) >>
[PATCH 3/9] mac80211: minstrel: merge with minstrel_ht, always enable VHT support
Legacy-only devices are not very common and the overhead of the extra
code for HT and VHT rates is not big enough to justify all those extra
lines of code to make it optional.
Signed-off-by: Felix Fietkau
---
net/mac80211/Kconfig | 17 +--
net/mac80211/Makefile | 11 +-
net/mac80211/main.c| 7 -
net/mac80211/rate.h| 13 --
net/mac80211/rc80211_minstrel.c| 152 -
net/mac80211/rc80211_minstrel.h| 2 -
net/mac80211/rc80211_minstrel_debugfs.c| 42 --
net/mac80211/rc80211_minstrel_ht.c | 91 ++--
net/mac80211/rc80211_minstrel_ht.h | 8 --
net/mac80211/rc80211_minstrel_ht_debugfs.c | 16 +++
10 files changed, 101 insertions(+), 258 deletions(-)
diff --git a/net/mac80211/Kconfig b/net/mac80211/Kconfig
index 76e30f4797fb..f869e35d0974 100644
--- a/net/mac80211/Kconfig
+++ b/net/mac80211/Kconfig
@@ -27,20 +27,6 @@ config MAC80211_RC_MINSTREL
---help---
This option enables the 'minstrel' TX rate control algorithm
-config MAC80211_RC_MINSTREL_HT
- bool "Minstrel 802.11n support" if EXPERT
- depends on MAC80211_RC_MINSTREL
- default y
- ---help---
- This option enables the 'minstrel_ht' TX rate control algorithm
-
-config MAC80211_RC_MINSTREL_VHT
- bool "Minstrel 802.11ac support" if EXPERT
- depends on MAC80211_RC_MINSTREL_HT
- default n
- ---help---
- This option enables VHT in the 'minstrel_ht' TX rate control algorithm
-
choice
prompt "Default rate control algorithm"
depends on MAC80211_HAS_RC
@@ -62,8 +48,7 @@ endchoice
config MAC80211_RC_DEFAULT
string
- default "minstrel_ht" if MAC80211_RC_DEFAULT_MINSTREL &&
MAC80211_RC_MINSTREL_HT
- default "minstrel" if MAC80211_RC_DEFAULT_MINSTREL
+ default "minstrel_ht" if MAC80211_RC_DEFAULT_MINSTREL
default ""
endif
diff --git a/net/mac80211/Makefile b/net/mac80211/Makefile
index bb707789ef2b..4f03ebe732fa 100644
--- a/net/mac80211/Makefile
+++ b/net/mac80211/Makefile
@@ -53,13 +53,14 @@ mac80211-$(CONFIG_PM) += pm.o
CFLAGS_trace.o := -I$(src)
-rc80211_minstrel-y := rc80211_minstrel.o
-rc80211_minstrel-$(CONFIG_MAC80211_DEBUGFS) += rc80211_minstrel_debugfs.o
+rc80211_minstrel-y := \
+ rc80211_minstrel.o \
+ rc80211_minstrel_ht.o
-rc80211_minstrel_ht-y := rc80211_minstrel_ht.o
-rc80211_minstrel_ht-$(CONFIG_MAC80211_DEBUGFS) += rc80211_minstrel_ht_debugfs.o
+rc80211_minstrel-$(CONFIG_MAC80211_DEBUGFS) += \
+ rc80211_minstrel_debugfs.o \
+ rc80211_minstrel_ht_debugfs.o
mac80211-$(CONFIG_MAC80211_RC_MINSTREL) += $(rc80211_minstrel-y)
-mac80211-$(CONFIG_MAC80211_RC_MINSTREL_HT) += $(rc80211_minstrel_ht-y)
ccflags-y += -DDEBUG
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index e6375d035355..83e71e6b2ebe 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -1375,18 +1375,12 @@ static int __init ieee80211_init(void)
if (ret)
return ret;
- ret = rc80211_minstrel_ht_init();
- if (ret)
- goto err_minstrel;
-
ret = ieee80211_iface_init();
if (ret)
goto err_netdev;
return 0;
err_netdev:
- rc80211_minstrel_ht_exit();
- err_minstrel:
rc80211_minstrel_exit();
return ret;
@@ -1394,7 +1388,6 @@ static int __init ieee80211_init(void)
static void __exit ieee80211_exit(void)
{
- rc80211_minstrel_ht_exit();
rc80211_minstrel_exit();
ieee80211s_stop();
diff --git a/net/mac80211/rate.h b/net/mac80211/rate.h
index 8212bfeb71d6..d59198191a79 100644
--- a/net/mac80211/rate.h
+++ b/net/mac80211/rate.h
@@ -95,18 +95,5 @@ static inline void rc80211_minstrel_exit(void)
}
#endif
-#ifdef CONFIG_MAC80211_RC_MINSTREL_HT
-int rc80211_minstrel_ht_init(void);
-void rc80211_minstrel_ht_exit(void);
-#else
-static inline int rc80211_minstrel_ht_init(void)
-{
- return 0;
-}
-static inline void rc80211_minstrel_ht_exit(void)
-{
-}
-#endif
-
#endif /* IEEE80211_RATE_H */
diff --git a/net/mac80211/rc80211_minstrel.c b/net/mac80211/rc80211_minstrel.c
index eac61242238a..dead57ba9eac 100644
--- a/net/mac80211/rc80211_minstrel.c
+++ b/net/mac80211/rc80211_minstrel.c
@@ -572,138 +572,6 @@ minstrel_rate_init(void *priv, struct
ieee80211_supported_band *sband,
minstrel_update_rates(mp, mi);
}
-static void *
-minstrel_alloc_sta(void *priv, struct ieee80211_sta *sta, gfp_t gfp)
-{
- struct ieee80211_supported_band *sband;
- struct minstrel_sta_info *mi;
- struct minstrel_priv *mp = priv;
- struct ieee80211_hw *hw = mp->hw;
- int max_rates = 0;
- int i;
-
- mi = kzalloc(sizeof(struct minstrel_sta_info), gfp);
- if (!mi)
- return NULL;
-
- for (i = 0; i < NUM_NL80211_BANDS; i++) {
- sband = hw->wiphy->
[PATCH 6/9] mac80211: minstrel: fix CCK rate group streams value
Fixes a harmless underflow issue when CCK rates are actively being used
Signed-off-by: Felix Fietkau
---
net/mac80211/rc80211_minstrel_ht.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/rc80211_minstrel_ht.c
b/net/mac80211/rc80211_minstrel_ht.c
index 118ffe7f88c4..6cc28ca5d4a6 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -131,7 +131,7 @@
#define CCK_GROUP(_s) \
[MINSTREL_CCK_GROUP] = {\
- .streams = 0, \
+ .streams = 1, \
.flags = 0, \
.shift = _s,\
.duration = { \
--
2.17.0
[PATCH 2/9] mac80211: minstrel: remove unnecessary debugfs cleanup code
debugfs entries are cleaned up by debugfs_remove_recursive already.
Signed-off-by: Felix Fietkau
---
net/mac80211/rc80211_minstrel.c| 8 ++--
net/mac80211/rc80211_minstrel.h| 7 ---
net/mac80211/rc80211_minstrel_debugfs.c| 18 +++---
net/mac80211/rc80211_minstrel_ht.c | 1 -
net/mac80211/rc80211_minstrel_ht.h | 5 -
net/mac80211/rc80211_minstrel_ht_debugfs.c | 17 -
6 files changed, 9 insertions(+), 47 deletions(-)
diff --git a/net/mac80211/rc80211_minstrel.c b/net/mac80211/rc80211_minstrel.c
index fc6134c01a76..eac61242238a 100644
--- a/net/mac80211/rc80211_minstrel.c
+++ b/net/mac80211/rc80211_minstrel.c
@@ -689,8 +689,8 @@ minstrel_alloc(struct ieee80211_hw *hw, struct dentry
*debugfsdir)
#ifdef CONFIG_MAC80211_DEBUGFS
mp->fixed_rate_idx = (u32) -1;
- mp->dbg_fixed_rate = debugfs_create_u32("fixed_rate_idx",
- 0666, debugfsdir, &mp->fixed_rate_idx);
+ debugfs_create_u32("fixed_rate_idx", 0666, debugfsdir,
+ &mp->fixed_rate_idx);
#endif
minstrel_init_cck_rates(mp);
@@ -701,9 +701,6 @@ minstrel_alloc(struct ieee80211_hw *hw, struct dentry
*debugfsdir)
static void
minstrel_free(void *priv)
{
-#ifdef CONFIG_MAC80211_DEBUGFS
- debugfs_remove(((struct minstrel_priv *)priv)->dbg_fixed_rate);
-#endif
kfree(priv);
}
@@ -735,7 +732,6 @@ const struct rate_control_ops mac80211_minstrel = {
.free_sta = minstrel_free_sta,
#ifdef CONFIG_MAC80211_DEBUGFS
.add_sta_debugfs = minstrel_add_sta_debugfs,
- .remove_sta_debugfs = minstrel_remove_sta_debugfs,
#endif
.get_expected_throughput = minstrel_get_expected_throughput,
};
diff --git a/net/mac80211/rc80211_minstrel.h b/net/mac80211/rc80211_minstrel.h
index be6c3f35f48b..6abe8bf603e2 100644
--- a/net/mac80211/rc80211_minstrel.h
+++ b/net/mac80211/rc80211_minstrel.h
@@ -109,11 +109,6 @@ struct minstrel_sta_info {
/* sampling table */
u8 *sample_table;
-
-#ifdef CONFIG_MAC80211_DEBUGFS
- struct dentry *dbg_stats;
- struct dentry *dbg_stats_csv;
-#endif
};
struct minstrel_priv {
@@ -137,7 +132,6 @@ struct minstrel_priv {
* - setting will be applied on next update
*/
u32 fixed_rate_idx;
- struct dentry *dbg_fixed_rate;
#endif
};
@@ -156,7 +150,6 @@ minstrel_get_ewmsd10(struct minstrel_rate_stats *mrs)
extern const struct rate_control_ops mac80211_minstrel;
void minstrel_add_sta_debugfs(void *priv, void *priv_sta, struct dentry *dir);
-void minstrel_remove_sta_debugfs(void *priv, void *priv_sta);
/* Recalculate success probabilities and counters for a given rate using EWMA
*/
void minstrel_calc_rate_stats(struct minstrel_rate_stats *mrs);
diff --git a/net/mac80211/rc80211_minstrel_debugfs.c
b/net/mac80211/rc80211_minstrel_debugfs.c
index 9ad7d63d3e5b..2e7266b81b19 100644
--- a/net/mac80211/rc80211_minstrel_debugfs.c
+++ b/net/mac80211/rc80211_minstrel_debugfs.c
@@ -214,19 +214,7 @@ minstrel_add_sta_debugfs(void *priv, void *priv_sta,
struct dentry *dir)
{
struct minstrel_sta_info *mi = priv_sta;
- mi->dbg_stats = debugfs_create_file("rc_stats", 0444, dir, mi,
- &minstrel_stat_fops);
-
- mi->dbg_stats_csv = debugfs_create_file("rc_stats_csv", 0444, dir, mi,
- &minstrel_stat_csv_fops);
-}
-
-void
-minstrel_remove_sta_debugfs(void *priv, void *priv_sta)
-{
- struct minstrel_sta_info *mi = priv_sta;
-
- debugfs_remove(mi->dbg_stats);
-
- debugfs_remove(mi->dbg_stats_csv);
+ debugfs_create_file("rc_stats", 0444, dir, mi, &minstrel_stat_fops);
+ debugfs_create_file("rc_stats_csv", 0444, dir, mi,
+ &minstrel_stat_csv_fops);
}
diff --git a/net/mac80211/rc80211_minstrel_ht.c
b/net/mac80211/rc80211_minstrel_ht.c
index 16d1ac30978d..818552ba61d0 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -1391,7 +1391,6 @@ static const struct rate_control_ops mac80211_minstrel_ht
= {
.free = minstrel_ht_free,
#ifdef CONFIG_MAC80211_DEBUGFS
.add_sta_debugfs = minstrel_ht_add_sta_debugfs,
- .remove_sta_debugfs = minstrel_ht_remove_sta_debugfs,
#endif
.get_expected_throughput = minstrel_ht_get_expected_throughput,
};
diff --git a/net/mac80211/rc80211_minstrel_ht.h
b/net/mac80211/rc80211_minstrel_ht.h
index de1646c42e82..50f2a8d004c4 100644
--- a/net/mac80211/rc80211_minstrel_ht.h
+++ b/net/mac80211/rc80211_minstrel_ht.h
@@ -110,17 +110,12 @@ struct minstrel_ht_sta_priv {
struct minstrel_ht_sta ht;
struct minstrel_sta_info legacy;
};
-#ifdef CONFIG_MAC80211_DEBUGFS
- struct dentry *dbg_stats;
- struct dentry *dbg_stats_csv;
-#endif
void *ratelist;
void *sample_table;
bool is_ht;
}
[PATCH 5/9] mac80211: minstrel: fix using short preamble CCK rates on HT clients
mi->supported[MINSTREL_CCK_GROUP] needs to be updated
short preamble rates need to be marked as supported regardless of
whether it's currently enabled. Its state can change at any time without
a rate_update call.
Fixes: 782dda00ab8e ("mac80211: minstrel_ht: move short preamble check out of
get_rate")
Signed-off-by: Felix Fietkau
---
net/mac80211/rc80211_minstrel_ht.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/net/mac80211/rc80211_minstrel_ht.c
b/net/mac80211/rc80211_minstrel_ht.c
index 38e17ed20d41..118ffe7f88c4 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -1135,7 +1135,6 @@ minstrel_ht_update_caps(void *priv, struct
ieee80211_supported_band *sband,
struct ieee80211_mcs_info *mcs = &sta->ht_cap.mcs;
u16 ht_cap = sta->ht_cap.cap;
struct ieee80211_sta_vht_cap *vht_cap = &sta->vht_cap;
- struct sta_info *sinfo = container_of(sta, struct sta_info, sta);
int use_vht;
int n_supported = 0;
int ack_dur;
@@ -1265,8 +1264,7 @@ minstrel_ht_update_caps(void *priv, struct
ieee80211_supported_band *sband,
if (!n_supported)
goto use_legacy;
- if (test_sta_flag(sinfo, WLAN_STA_SHORT_PREAMBLE))
- mi->cck_supported_short |= mi->cck_supported_short << 4;
+ mi->supported[MINSTREL_CCK_GROUP] |= mi->cck_supported_short << 4;
/* create an initial rate table with the lowest supported rates */
minstrel_ht_update_stats(mp, mi);
--
2.17.0
[PATCH 7/9] mac80211: minstrel: fix sampling/reporting of CCK rates in HT mode
Long/short preamble selection cannot be sampled separately, since it
depends on the BSS state. Because of that, sampling attempts to
currently not used preamble modes are not counted in the statistics,
which leads to CCK rates being sampled too often.
Fix statistics accounting for long/short preamble by increasing the
index where necessary.
Fix excessive CCK rate sampling by dropping unsupported sample attempts.
This improves throughput on 2.4 GHz channels
Signed-off-by: Felix Fietkau
---
net/mac80211/rc80211_minstrel_ht.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/rc80211_minstrel_ht.c
b/net/mac80211/rc80211_minstrel_ht.c
index 6cc28ca5d4a6..fdcb4e9b4560 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -281,7 +281,8 @@ minstrel_ht_get_stats(struct minstrel_priv *mp, struct
minstrel_ht_sta *mi,
break;
/* short preamble */
- if (!(mi->supported[group] & BIT(idx)))
+ if ((mi->supported[group] & BIT(idx + 4)) &&
+ (rate->flags & IEEE80211_TX_RC_USE_SHORT_PREAMBLE))
idx += 4;
}
return &mi->groups[group].rates[idx];
@@ -1080,18 +1081,23 @@ minstrel_ht_get_rate(void *priv, struct ieee80211_sta
*sta, void *priv_sta,
return;
sample_group = &minstrel_mcs_groups[sample_idx / MCS_GROUP_RATES];
+ sample_idx %= MCS_GROUP_RATES;
+
+ if (sample_group == &minstrel_mcs_groups[MINSTREL_CCK_GROUP] &&
+ (sample_idx >= 4) != txrc->short_preamble)
+ return;
+
info->flags |= IEEE80211_TX_CTL_RATE_CTRL_PROBE;
rate->count = 1;
- if (sample_idx / MCS_GROUP_RATES == MINSTREL_CCK_GROUP) {
+ if (sample_group == &minstrel_mcs_groups[MINSTREL_CCK_GROUP]) {
int idx = sample_idx % ARRAY_SIZE(mp->cck_rates);
rate->idx = mp->cck_rates[idx];
} else if (sample_group->flags & IEEE80211_TX_RC_VHT_MCS) {
ieee80211_rate_set_vht(rate, sample_idx % MCS_GROUP_RATES,
sample_group->streams);
} else {
- rate->idx = sample_idx % MCS_GROUP_RATES +
- (sample_group->streams - 1) * 8;
+ rate->idx = sample_idx + (sample_group->streams - 1) * 8;
}
rate->flags = sample_group->flags;
--
2.17.0
[PATCH 1/9] mac80211: minstrel: Enable STBC and LDPC for VHT Rates
From: Chaitanya T K
If peer support reception of STBC and LDPC, enable them for better
performance.
Signed-off-by: Chaitanya TK
Signed-off-by: Felix Fietkau
---
include/linux/ieee80211.h | 1 +
net/mac80211/rc80211_minstrel_ht.c | 23 +++
2 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index c4809ad8ab46..0ef67f837ae1 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -1670,6 +1670,7 @@ struct ieee80211_mu_edca_param_set {
#define IEEE80211_VHT_CAP_RXSTBC_3 0x0300
#define IEEE80211_VHT_CAP_RXSTBC_4 0x0400
#define IEEE80211_VHT_CAP_RXSTBC_MASK 0x0700
+#define IEEE80211_VHT_CAP_RXSTBC_SHIFT 8
#define IEEE80211_VHT_CAP_SU_BEAMFORMER_CAPABLE
0x0800
#define IEEE80211_VHT_CAP_SU_BEAMFORMEE_CAPABLE
0x1000
#define IEEE80211_VHT_CAP_BEAMFORMEE_STS_SHIFT 13
diff --git a/net/mac80211/rc80211_minstrel_ht.c
b/net/mac80211/rc80211_minstrel_ht.c
index 67ebdeaffbbc..16d1ac30978d 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -1130,7 +1130,7 @@ minstrel_ht_update_caps(void *priv, struct
ieee80211_supported_band *sband,
struct minstrel_ht_sta_priv *msp = priv_sta;
struct minstrel_ht_sta *mi = &msp->ht;
struct ieee80211_mcs_info *mcs = &sta->ht_cap.mcs;
- u16 sta_cap = sta->ht_cap.cap;
+ u16 ht_cap = sta->ht_cap.cap;
struct ieee80211_sta_vht_cap *vht_cap = &sta->vht_cap;
struct sta_info *sinfo = container_of(sta, struct sta_info, sta);
int use_vht;
@@ -1138,6 +1138,7 @@ minstrel_ht_update_caps(void *priv, struct
ieee80211_supported_band *sband,
int ack_dur;
int stbc;
int i;
+ bool ldpc;
/* fall back to the old minstrel for legacy stations */
if (!sta->ht_cap.ht_supported)
@@ -1175,16 +1176,22 @@ minstrel_ht_update_caps(void *priv, struct
ieee80211_supported_band *sband,
}
mi->sample_tries = 4;
- /* TODO tx_flags for vht - ATM the RC API is not fine-grained enough */
if (!use_vht) {
- stbc = (sta_cap & IEEE80211_HT_CAP_RX_STBC) >>
+ stbc = (ht_cap & IEEE80211_HT_CAP_RX_STBC) >>
IEEE80211_HT_CAP_RX_STBC_SHIFT;
- mi->tx_flags |= stbc << IEEE80211_TX_CTL_STBC_SHIFT;
- if (sta_cap & IEEE80211_HT_CAP_LDPC_CODING)
- mi->tx_flags |= IEEE80211_TX_CTL_LDPC;
+ ldpc = ht_cap & IEEE80211_HT_CAP_LDPC_CODING;
+ } else {
+ stbc = (vht_cap->cap & IEEE80211_VHT_CAP_RXSTBC_MASK) >>
+ IEEE80211_VHT_CAP_RXSTBC_SHIFT;
+
+ ldpc = vht_cap->cap & IEEE80211_VHT_CAP_RXLDPC;
}
+ mi->tx_flags |= stbc << IEEE80211_TX_CTL_STBC_SHIFT;
+ if (ldpc)
+ mi->tx_flags |= IEEE80211_TX_CTL_LDPC;
+
for (i = 0; i < ARRAY_SIZE(mi->groups); i++) {
u32 gflags = minstrel_mcs_groups[i].flags;
int bw, nss;
@@ -1197,10 +1204,10 @@ minstrel_ht_update_caps(void *priv, struct
ieee80211_supported_band *sband,
if (gflags & IEEE80211_TX_RC_SHORT_GI) {
if (gflags & IEEE80211_TX_RC_40_MHZ_WIDTH) {
- if (!(sta_cap & IEEE80211_HT_CAP_SGI_40))
+ if (!(ht_cap & IEEE80211_HT_CAP_SGI_40))
continue;
} else {
- if (!(sta_cap & IEEE80211_HT_CAP_SGI_20))
+ if (!(ht_cap & IEEE80211_HT_CAP_SGI_20))
continue;
}
}
--
2.17.0
[PATCH 8/9] mac80211: minstrel: do not sample rates 3 times slower than max_prob_rate
These rates are highly unlikely to be used quickly, even if the link deteriorates rapidly. This improves throughput in cases where CCK rates are not reliable enough to be skipped entirely during sampling. Sampling these rates regularly can cost a lot of airtime. Signed-off-by: Felix Fietkau --- net/mac80211/rc80211_minstrel_ht.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c index fdcb4e9b4560..f466ec37d161 100644 --- a/net/mac80211/rc80211_minstrel_ht.c +++ b/net/mac80211/rc80211_minstrel_ht.c @@ -1004,10 +1004,13 @@ minstrel_get_sample_rate(struct minstrel_priv *mp, struct minstrel_ht_sta *mi) return -1; /* -* Do not sample if the probability is already higher than 95% -* to avoid wasting airtime. +* Do not sample if the probability is already higher than 95%, +* or if the rate is 3 times slower than the current max probability +* rate, to avoid wasting airtime. */ - if (mrs->prob_ewma > MINSTREL_FRAC(95, 100)) + sample_dur = minstrel_get_duration(sample_idx); + if (mrs->prob_ewma > MINSTREL_FRAC(95, 100) || + minstrel_get_duration(mi->max_prob_rate) * 3 < sample_dur) return -1; /* @@ -1017,7 +1020,6 @@ minstrel_get_sample_rate(struct minstrel_priv *mp, struct minstrel_ht_sta *mi) cur_max_tp_streams = minstrel_mcs_groups[tp_rate1 / MCS_GROUP_RATES].streams; - sample_dur = minstrel_get_duration(sample_idx); if (sample_dur >= minstrel_get_duration(tp_rate2) && (cur_max_tp_streams - 1 < minstrel_mcs_groups[sample_group].streams || -- 2.17.0
[PATCH] wireless-regdb: remove dependency to python attr
Commit 8607edfdb6568 ("wireless-regdb: Parse wmm rule data") introduced
a dependency to the python module attr which is not included by default
in all python installations. Replace the code with manually coding the
constructor instead of using attr. This makes the code also work on
systems without attr.
I would like to avoid an additional dependency in OpenWrt where we
compile the regulatory database inside of the build system.
Signed-off-by: Hauke Mehrtens
---
dbparse.py | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/dbparse.py b/dbparse.py
index 5fe752b..993f757 100755
--- a/dbparse.py
+++ b/dbparse.py
@@ -5,7 +5,6 @@ from functools import total_ordering
import sys, math
from math import ceil, log
from collections import defaultdict, OrderedDict
-import attr
# must match enum nl80211_reg_rule_flags
@@ -32,16 +31,17 @@ dfs_regions = {
@total_ordering
-@attr.s(frozen=True, cmp=False)
class WmmRule(object):
-vo_c = attr.ib()
-vi_c = attr.ib()
-be_c = attr.ib()
-bk_c = attr.ib()
-vo_ap = attr.ib()
-vi_ap = attr.ib()
-be_ap = attr.ib()
-bk_ap = attr.ib()
+
+def __init__(self, vo_c, vi_c, be_c, bk_c, vo_ap, vi_ap, be_ap, bk_ap):
+self.vo_c = vo_c
+self.vi_c = vi_c
+self.be_c = be_c
+self.bk_c = bk_c
+self.vo_ap = vo_ap
+self.vi_ap = vi_ap
+self.be_ap = be_ap
+self.bk_ap = bk_ap
def _as_tuple(self):
return (self.vo_c, self.vi_c, self.be_c, self.bk_c,
--
2.11.0
Re: [PATCH] wil6210: fix debugfs_simple_attr.cocci warnings
Julia Lawall writes: > On Sat, 6 Oct 2018, Kalle Valo wrote: > >> Julia Lawall writes: >> >> > On Fri, 5 Oct 2018, Kalle Valo wrote: >> > >> >> YueHaibing writes: >> >> >> >> > Use DEFINE_DEBUGFS_ATTRIBUTE rather than DEFINE_SIMPLE_ATTRIBUTE >> >> > for debugfs files. >> >> > >> >> > Semantic patch information: >> >> > Rationale: DEFINE_SIMPLE_ATTRIBUTE + debugfs_create_file() >> >> > imposes some significant overhead as compared to >> >> > DEFINE_DEBUGFS_ATTRIBUTE + debugfs_create_file_unsafe(). >> >> > >> >> > Generated by: scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci >> >> >> >> Just out of curiosity, what kind of overhead are we talking about here? >> > >> > The log message on the commit introducing the semantic patch says the >> > following: >> > >> > In order to protect against file removal races, debugfs files created >> > via >> > debugfs_create_file() now get wrapped by a struct file_operations at >> > their >> > opening. >> > >> > If the original struct file_operations are known to be safe against >> > removal >> > races by themselves already, the proxy creation may be bypassed by >> > creating >> > the files through debugfs_create_file_unsafe(). >> > >> > In order to help debugfs users who use the common >> > DEFINE_SIMPLE_ATTRIBUTE() + debugfs_create_file() >> > idiom to transition to removal safe struct file_operations, the helper >> > macro DEFINE_DEBUGFS_ATTRIBUTE() has been introduced. >> > >> > Thus, the preferred strategy is to use >> > DEFINE_DEBUGFS_ATTRIBUTE() + debugfs_create_file_unsafe() >> > now. >> >> I admit that I didn't have time to investigate this is detail but I'm >> still not understanding where is that "significant overhead" coming from >> and how big of overhead are we talking about? I guess it has something >> to do with full_proxy_open() vs open_proxy_open()? >> >> Not that I'm against this patch, just curious when I see someone >> claiming "significant overhead" which is not obvious for me. > > The message with the semantic patch doesn't really talk about significant > overhead. Maybe YueHaibing can discuss with the person who proposed the > semantic patch what the actual issue is, and when the proposed change is > actually applicable. Actually commit 5103068eaca2 mentions "significant overhead": --- /dev/null +++ b/scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci @@ -0,0 +1,67 @@ +/// Use DEFINE_DEBUGFS_ATTRIBUTE rather than DEFINE_SIMPLE_ATTRIBUTE +/// for debugfs files. +/// +//# Rationale: DEFINE_SIMPLE_ATTRIBUTE + debugfs_create_file() +//# imposes some significant overhead as compared to +//# DEFINE_DEBUGFS_ATTRIBUTE + debugfs_create_file_unsafe(). But I'll anyway apply this patch as I don't see anything wrong with it. I was just trying to learn where this overhead is :) -- Kalle Valo
Re: [RFC 00/19] wilc: added driver for wilc module
Ajay Singh writes: > This patch set contains the driver files from 'driver/staging/wilc1000'. > Renamed the driver from 'wilc1000' to 'wilc' to have generic name, as > the same driver will be used by other wilc family members. I'm worried that the name 'wilc' is just too generic, I liked the original name wilc1000 much more. Quite often when we have a new generation of wireless devices there's also a new driver, so in the long run I'm worried that a generic name like 'wilc' could be a source of confusion. I think it's much smaller problem if 'wilc1000' (the driver) also supports wilc3000 (the device), people are already used to that. And if there's ever a need for a new driver, you can call it 'wilc4000' or whatever. For example, I think good driver names are like 'mt76' or 'rtw88' (currently under review). -- Kalle Valo
Re: [RFC v2 06/12] rtw88: fw and efuse files
Stanislaw Gruszka writes:
> On Wed, Oct 03, 2018 at 04:02:22PM +0800, yhchu...@realtek.com wrote:
>
>> +void rtw_add_rsvd_page(struct rtw_dev *rtwdev, enum rtw_rsvd_packet_type
>> type,
>> + bool txdesc)
>> +{
>> +struct rtw_rsvd_page *rsvd_pkt;
>> +
>> +list_for_each_entry(rsvd_pkt, &rtwdev->rsvd_page_list, list) {
>> +if (rsvd_pkt->type == type)
>> +return;
>> +}
>> +
>> +rsvd_pkt = kmalloc(sizeof(*rsvd_pkt),
>> + in_interrupt() ? GFP_ATOMIC : GFP_KERNEL);
>
> It's never called from interrupt. You have to check kmalloc output value.
My recommendation is to always avoid in_interrupt().
--
Kalle Valo
Re: [RFC v2 04/12] rtw88: trx files
Tony Chuang writes: >> > + pkt_info->bmc = bmc; >> > + pkt_info->sec_type = sec_type; >> > + pkt_info->tx_pkt_size = skb->len; >> > + pkt_info->offset = chip->tx_pkt_desc_sz; >> > + pkt_info->qsel = skb->priority; >> >> Shouldn't be qsel somehow mapped from skb->priority ? > > Firmware handles it. What if meaning of skb->priority changes in the future? I don't think it's safe to provide kernel internal values to firmware, you should do some kind of mapping in the driver. -- Kalle Valo
Re: [RFC v2 03/12] rtw88: hci files
Tony Chuang writes: >> > + } >> > + >> > + info = IEEE80211_SKB_CB(skb); >> > + ieee80211_tx_info_clear_status(info); >> > + info->flags |= IEEE80211_TX_STAT_ACK; >> > + ieee80211_tx_status_irqsafe(hw, skb); >> >> Always report ACK ? > > The ACK report is for mac80211 stack, it looks abnormal at the first glance. > But we can only do this for every data frame because there is no ack report > unless the driver ask the firmware to give one. > Ask for every data frame is resource consuming. I don't remember how mac80211 wants to handle the cases when the hardware doesn't provide ack status, but lying that to mac80211 sounds like a bad idea to me. Anyone have any suggestions how this should be handled? At the minimum add a proper comment explaining why you are lying to mac80211. -- Kalle Valo
Re: [PATCH] wil6210: fix debugfs_simple_attr.cocci warnings
On Sat, 6 Oct 2018, Kalle Valo wrote: > Julia Lawall writes: > > > On Fri, 5 Oct 2018, Kalle Valo wrote: > > > >> YueHaibing writes: > >> > >> > Use DEFINE_DEBUGFS_ATTRIBUTE rather than DEFINE_SIMPLE_ATTRIBUTE > >> > for debugfs files. > >> > > >> > Semantic patch information: > >> > Rationale: DEFINE_SIMPLE_ATTRIBUTE + debugfs_create_file() > >> > imposes some significant overhead as compared to > >> > DEFINE_DEBUGFS_ATTRIBUTE + debugfs_create_file_unsafe(). > >> > > >> > Generated by: scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci > >> > >> Just out of curiosity, what kind of overhead are we talking about here? > > > > The log message on the commit introducing the semantic patch says the > > following: > > > > In order to protect against file removal races, debugfs files created > > via > > debugfs_create_file() now get wrapped by a struct file_operations at > > their > > opening. > > > > If the original struct file_operations are known to be safe against > > removal > > races by themselves already, the proxy creation may be bypassed by > > creating > > the files through debugfs_create_file_unsafe(). > > > > In order to help debugfs users who use the common > > DEFINE_SIMPLE_ATTRIBUTE() + debugfs_create_file() > > idiom to transition to removal safe struct file_operations, the helper > > macro DEFINE_DEBUGFS_ATTRIBUTE() has been introduced. > > > > Thus, the preferred strategy is to use > > DEFINE_DEBUGFS_ATTRIBUTE() + debugfs_create_file_unsafe() > > now. > > I admit that I didn't have time to investigate this is detail but I'm > still not understanding where is that "significant overhead" coming from > and how big of overhead are we talking about? I guess it has something > to do with full_proxy_open() vs open_proxy_open()? > > Not that I'm against this patch, just curious when I see someone > claiming "significant overhead" which is not obvious for me. The message with the semantic patch doesn't really talk about significant overhead. Maybe YueHaibing can discuss with the person who proposed the semantic patch what the actual issue is, and when the proposed change is actually applicable. julia > > -- > Kalle Valo >
Re: [PATCH 01/12] rtwlan: main files
Larry Finger writes: > On 10/4/18 8:42 AM, Stanislaw Gruszka wrote: >> On Thu, Oct 04, 2018 at 03:39:55PM +0300, Kalle Valo wrote: > Can we put the configuration file in the firmware directory? > Should we package them into binary files? Or just put the raw data. > > We can test the performance for it. After we got the result, we > will make a decision > about it. And if we decide to put them in the firmware directory, > will send a patch. > For now, I think we can just leave them in the .c. Yes, you could put the configuration files in the firmware directory. I would put them in binary form, not as text files. That way the size would be smaller, and it would not be possible to alter them, particularly if the binary file is checksummed. It would likely be OK if only the agc table was stored in this way. That would take away about half of the lines in the 8822b table file. >>> >>> So what's the worry here? The lines of source code, binary size or what? >>> >>> .../net/wireless/realtek/rtw88/rtw8822b_table.c| 20783 >>> +++ >>> >>> Looking at the diffstat rtw8822b_table.c seems to be 20 kLOC, IMHO it's >>> not that bad as it's just data. But of course I might be missing >>> something as I haven't checked patches yet. >> >> My concern was it's plenty of redundant data, for example: >> >> 0x81C, 0xFF03, >> 0x81C, 0xFE03, >> 0x81C, 0xFD020003, >> 0x81C, 0xFC040003, >> 0x81C, 0xFB060003, >> 0x81C, 0xFA080003, >> 0x81C, 0xF90A0003, >> 0x81C, 0xF80C0003, >> 0x81C, 0xF70E0003, >> 0x81C, 0xF613, >> >> Approx 1 lines like this, braked by lines like this >> >> 0x9012, 0x, 0x4000, 0x, >> >> in more or less regular way. >> >> Not big deal, but perhaps this could be coded in much more compact way. > > What should be the tradeoff between large tables of redundant data and > complicated generation and interpretation? I think this table should > be converted to binary in its present form and added to the > "firmware", the way that is done for b43. That way the source is > smaller, and the loading will be only a bit more time consuming. But separating the data from the driver creates another set of problems. For example, what if the data is dependent on the driver changes? Then we need to think about backwards compatibility etc, which creates more work us. I prefer simple solutions, less work and less problems :) -- Kalle Valo
Re: [PATCH 01/12] rtwlan: main files
Stanislaw Gruszka writes: > On Thu, Oct 04, 2018 at 03:39:55PM +0300, Kalle Valo wrote: >> >> Can we put the configuration file in the firmware directory? >> >> Should we package them into binary files? Or just put the raw data. >> >> >> >> We can test the performance for it. After we got the result, we >> >> will make a decision >> >> about it. And if we decide to put them in the firmware directory, >> >> will send a patch. >> >> For now, I think we can just leave them in the .c. >> > >> > Yes, you could put the configuration files in the firmware directory. >> > I would put them in binary form, not as text files. That way the size >> > would be smaller, and it would not be possible to alter them, >> > particularly if the binary file is checksummed. >> > >> > It would likely be OK if only the agc table was stored in this way. >> > That would take away about half of the lines in the 8822b table file. >> >> So what's the worry here? The lines of source code, binary size or what? >> >> .../net/wireless/realtek/rtw88/rtw8822b_table.c| 20783 >> +++ >> >> Looking at the diffstat rtw8822b_table.c seems to be 20 kLOC, IMHO it's >> not that bad as it's just data. But of course I might be missing >> something as I haven't checked patches yet. > > My concern was it's plenty of redundant data, for example: > > 0x81C, 0xFF03, > 0x81C, 0xFE03, > 0x81C, 0xFD020003, > 0x81C, 0xFC040003, > 0x81C, 0xFB060003, > 0x81C, 0xFA080003, > 0x81C, 0xF90A0003, > 0x81C, 0xF80C0003, > 0x81C, 0xF70E0003, > 0x81C, 0xF613, > > Approx 1 lines like this, braked by lines like this > > 0x9012, 0x, 0x4000, 0x, > > in more or less regular way. > > Not big deal, but perhaps this could be coded in much more compact way. Sure, making it more compact makes sense to me. But I don't see that as a strict requirement, that could be done also after the driver is accepted. Do note that I haven't reviewed the driver yet so I reserve the right to change my opinion :) -- Kalle Valo
Re: [PATCH] wil6210: fix debugfs_simple_attr.cocci warnings
Julia Lawall writes: > On Fri, 5 Oct 2018, Kalle Valo wrote: > >> YueHaibing writes: >> >> > Use DEFINE_DEBUGFS_ATTRIBUTE rather than DEFINE_SIMPLE_ATTRIBUTE >> > for debugfs files. >> > >> > Semantic patch information: >> > Rationale: DEFINE_SIMPLE_ATTRIBUTE + debugfs_create_file() >> > imposes some significant overhead as compared to >> > DEFINE_DEBUGFS_ATTRIBUTE + debugfs_create_file_unsafe(). >> > >> > Generated by: scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci >> >> Just out of curiosity, what kind of overhead are we talking about here? > > The log message on the commit introducing the semantic patch says the > following: > > In order to protect against file removal races, debugfs files created via > debugfs_create_file() now get wrapped by a struct file_operations at their > opening. > > If the original struct file_operations are known to be safe against > removal > races by themselves already, the proxy creation may be bypassed by > creating > the files through debugfs_create_file_unsafe(). > > In order to help debugfs users who use the common > DEFINE_SIMPLE_ATTRIBUTE() + debugfs_create_file() > idiom to transition to removal safe struct file_operations, the helper > macro DEFINE_DEBUGFS_ATTRIBUTE() has been introduced. > > Thus, the preferred strategy is to use > DEFINE_DEBUGFS_ATTRIBUTE() + debugfs_create_file_unsafe() > now. I admit that I didn't have time to investigate this is detail but I'm still not understanding where is that "significant overhead" coming from and how big of overhead are we talking about? I guess it has something to do with full_proxy_open() vs open_proxy_open()? Not that I'm against this patch, just curious when I see someone claiming "significant overhead" which is not obvious for me. -- Kalle Valo
Re: [PATCH net-next v3] wireless-drivers: rtnetlink wifi simulation device
Cody Schuffelen writes: > Thanks for the comments! I will work on incorporating the suggested > changes. Few important remarks: 1. Do not EVER submit HTML mails, mailing lists will automatically reject them. So your mail didn't reach the lists and I only got it because I was in the Cc field. 2. Do not top post, it's really annoying: https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#do_not_top_post_and_edit_your_quotes 3. Reply to the review comments you get, even if you agree with them. By not replying you give an impression that you are ignoring the review comments. -- Kalle Valo
Re: [PATCH net-next v3] wireless-drivers: rtnetlink wifi simulation device
Cody Schuffelen writes: > This device takes over an existing network device and produces a > new one that appears like a wireless connection, returning enough canned > responses to nl80211 to satisfy a standard connection manager. If > necessary, it can also be set up one step removed from an existing > network device, such as through a vlan/80211Q or macvlan connection to > not disrupt the existing network interface. > > To use it to wrap a bare ethernet connection: > > ip link add link eth0 name wlan0 type virt_wifi > > You may have to rename or otherwise hide the eth0 from your connection > manager, as the original network link will become unusuable and only > the wireless wrapper will be functional. This can also be combined with > vlan or macvlan links on top of eth0 to share the network between > distinct links, but that requires support outside the machine for > accepting vlan-tagged packets or packets from multiple MAC addresses. > > This is being used for Google's Remote Android Virtual Device project, > which runs Android devices in virtual machines. The standard network > interfaces provided inside the virtual machines are all ethernet. > However, Android is not interested in ethernet devices and would rather > connect to a wireless interface. This patch allows the virtual machine > guest to treat one of its network connections as wireless rather than > ethernet, satisfying Android's network connection requirements. > > We believe this is a generally useful driver for simulating wireless > network connections in other environments where a wireless connection is > desired by some userspace process but is not available. > > This is distinct from other testing efforts such as mac80211_hwsim by > being a cfg80211 device instead of mac80211 device, allowing straight > pass-through on the data plane instead of forcing packaging of ethernet > data into mac80211 frames. > > Signed-off-by: A. Cody Schuffelen > Acked-by: Alistair Strachan > Acked-by: Greg Hartman > --- > First version: https://lkml.org/lkml/2018/7/27/947 > First review: > https://lore.kernel.org/lkml/1535460343.5895.56.ca...@sipsolutions.net/ > Second version: > https://lore.kernel.org/lkml/20180926194324.71290-1-schuffe...@google.com/ > Second review: https://www.lkml.org/lkml/2018/9/27/228 > Second review: https://www.lkml.org/lkml/2018/9/27/229 > Second review: https://www.lkml.org/lkml/2018/9/27/669 > > Thanks for all the comments on v2! I believe I've addressed all of them > here. I've also added changes to react better to the netdev going down, > canceling ongoing scans and rejecting wifi network connection requests. > > I wasn't completely clear on whether I should change the title (net-next > to mac80211-next) so I left it as is for v3 to try to keep the patchwork > series together. I already said in v2 that you should not mark this for net-next as this goes to mac80211-next (if it gets accepted), now you are just unnecessarily confusing people. -- Kalle Valo
Re: [RFC 00/12] rtwlan: mac80211 driver for Realtek 802.11ac wireless network chips
Tony Chuang writes: >> -Original Message- >> From: Kalle Valo [mailto:kv...@codeaurora.org] >> Sent: Monday, September 24, 2018 7:05 PM >> To: Stanislaw Gruszka >> Cc: Tony Chuang; larry.fin...@lwfinger.net; linux-wireless@vger.kernel.org; >> Pkshih; Andy Huang >> Subject: Re: [RFC 00/12] rtwlan: mac80211 driver for Realtek 802.11ac >> wireless network chips >> >> Stanislaw Gruszka writes: >> >> > On Fri, Sep 21, 2018 at 02:03:55PM +0800, yhchu...@realtek.com wrote: >> >> From: Yan-Hsuan Chuang >> >> >> >> This is a new mac80211 driver for Realtek 802.11ac wireless network chips. >> >> rtwlan supports 8822BE and 8822CE chips, and will be able to support >> >> multi-vif combinations in run-time. >> >> >> >> For now, only PCI bus is supported, but rtwlan was originally designed >> >> to optionally support three buses includes USB & SDIO. USB & SDIO >> modules >> >> will soon be supported by rtwlan, with configurable core module to fit >> >> with different bus modules in the same time. >> >> >> >> For example, if we choose 8822BE and 8822CU, only PCI & USB modules >> will >> >> be selected, built, loaded into kernel. This is one of the major >> >> difference from rtlwifi, which can only support specific combinations. >> >> >> >> Another difference from rtlwifi is that rtwlan is designed to support >> >> the latest Realtek 802.11ac wireless network chips like 8822B and >> >> 8822C series. Compared to the earlier chips supported by rtlwifi like >> >> the 802.11n 8192EE chipset or 802.11ac 8821AE/8812AE chips, newer ICs >> >> have different MAC & PHY settings, such as new multi-port feature for the >> >> MAC layer design and Jaguar2/Jaguar3 PHY layer IPs. >> >> >> >> Multi-Port feature is also supported under rtwlan's software architecture. >> >> rtlwifi can only support one vif in the same time, most because of the >> >> hardware limitations for early chips, hence the original design of it >> >> also restricts the usage of multi-vif support, so latest chipset seems not >> >> take advantages from its new MAC engine. >> >> >> >> However, rtwlan can run multiple vifs concurrently by holding them on >> >> hardware ports provided by MAC engine, so we can easily start different >> >> roles on a single device. >> >> >> >> Based on the reasons mentioned before, we implemented rtwlan. It had >> many >> >> authors, they are listed here alphabetically: >> >> >> >> Ping-Ke Shih >> >> Tzu-En Huang >> >> Yan-Hsuan Chuang >> > >> > I didn't do detailed review, but my general impression is very very >> > positive. New driver looks great! >> >> I also did a quick 10 min look at the driver and indeed in general it >> looks good. >> >> > Just 2 generic remarks: >> > - please add MAINTAINERS file entry >> > - please post a patch or request to remove staging/rtlwifi driver >> > since this one is replace for it (8822BE PCI-ID is the same) >> >> Something I noticed: >> >> o Magic numbers (BIT(1) etc) in quite a few places. >> >> o Personally not really fond of "#ifdef LITTLE_ENDIAN" usage, but I >> guess we can live with that? >> >> o To me the name "rtwlan" sounds confusing when one compares it with >> "rtlwifi". And how would the possible next generation 11ax driver be >> then called? As a good example I really like the driver name mt76, >> could this one have something similar to make it more descriptive? >> >> I also pushed this to the pending branch on wireless-drivers-next so >> that kbuild bot can extensively test it. > > Yes, we will add MAINTAINER files entry after this driver. > got accepted into the kernel, or should we include the entry in this patch? Please update the MAINTAINERS file in this patchset, just in a separate patch. I can them apply it at the same time as the driver (once it's ready). -- Kalle Valo
Re: [RFC v5 01/12] ath10k: add struct ath10k_bus_params
Erik Stromdahl writes: > On 9/6/18 6:16 PM, Kalle Valo wrote: >> Erik Stromdahl wrote: >> >>> This struct is used as argument to ath10k_core_register in order to >>> make it easier to add more bus parameters in the future. >>> >>> Signed-off-by: Erik Stromdahl >>> Signed-off-by: Kalle Valo >> >> 12 patches applied to ath-next branch of ath.git, thanks. >> >> c0d8d565787c ath10k: add struct ath10k_bus_params >> 7c2dd6154fc2 ath10k: add device type enum to ath10k_bus_params >> 367c899f622c ath10k: add bus type check in ath10k_init_hw_params >> 9faaa14387fb ath10k: use hw_params.num_peers for num_tids in TLV init >> 4875e0b52085 ath10k: add per target config of max_num_peers >> e66d5361127a ath10k: DMA related fixes for high latency devices >> 852d1bf86a5b ath10k: add HTT TX HL ops >> d4e7f553eec3 ath10k: add HTT RX HL ops >> 4daacc950d4d ath10k: htt: RX ring config HL support >> a2097d6444c3 ath10k: htt: High latency TX support >> f88d49345040 ath10k: htt: High latency RX support >> 37f62c0d5822 ath10k: wmi: disable softirq's while calling ieee80211_rx >> > > I am afraid that one of the patches in this series causes a regression > for PCI devices :( > > The patch is: > > 4875e0b52085 ath10k: add per target config of max_num_peers > > With this patch I got an error during driver load. > Reverting the patch solved the problem. > > I discovered this yesterday when I was setting up a test AP with an > ath10k pcie device. > I thought it would be a good idea to use my own tree just to make sure > it works with PCI, and apparently it didn't work. > I did some bisecting and the patch mentioned above turned out to be the > culprit. > I have not looked into why it fails yet (I think it is related to a > bad num_peers value in the ath10k_hw_params_list array), > I just noticed that reverting the patch solved the problem > > I was actually planning on submitting a v6 series with this patch > removed, but you were faster. Yeah, sorry about this. I noticed you marked the patchset as RFC but as they looked so good I decided to take them anyway :) But thanks for the quick fixes which I have applied and I think everything is good now, right? -- Kalle Valo
Re: pull request: mt76 2018-10-05 v2
Felix Fietkau writes: > here's the fixed version of the previous pull request. I've dropped > the broken patch from the previous round. > > - Felix > > The following changes since commit e1c02eb16a9c742178874a7d1a08d300981715fb: > > qtnfmac: implement dump_station support for STA mode (2018-10-05 14:01:44 > +0300) > > are available in the Git repository at: > > https://github.com/nbd168/wireless tags/mt76-for-kvalo-2018-10-05 > > for you to fetch changes up to 9b43960b899c71c758209a58c7e8d7d6e481e272: > > mt76: move irq handler in mt76x02-lib moudle (2018-10-05 20:05:46 +0200) > > > mt76 patches for 4.20 > > * unify code between mt76x0, mt76x2 > * mt76x0 fixes > * another fix for rx buffer allocation regression on usb > * move mt76x2 source files to mt76x2 folder > * more work on mt76x0e support > > This compiled without problems, thanks for the quick update. Pulled. -- Kalle Valo
Re: pull request: mt76 2018-10-05
> > Felix Fietkau writes: > > > Here's another large batch of mt76 code cleanup / deduplication / fixes > > > > - Felix > > > > The following changes since commit e1c02eb16a9c742178874a7d1a08d300981715fb: > > > > qtnfmac: implement dump_station support for STA mode (2018-10-05 14:01:44 > > +0300) > > > > are available in the Git repository at: > > > > https://github.com/nbd168/wireless tags/mt76-for-kvalo-2018-10-05 > > > > for you to fetch changes up to 06ac97c2e58c7b32bf950ac53976c4260687d386: > > > > mt76x0: pci: report firmware version using ethtool (2018-10-05 20:05:46 > > +0200) > > > > > > mt76 patches for 4.20 > > > > * unify code between mt76x0, mt76x2 > > * mt76x0 fixes > > * another fix for rx buffer allocation regression on usb > > * move mt76x2 source files to mt76x2 folder > > * more work on mt76x0e support > > > > > > I have to drop this as it doesn't build for me: > > drivers/net/wireless/mediatek/mt76/mt76x0/pci_mcu.c: In function > 'mt76x0e_load_firmware': > drivers/net/wireless/mediatek/mt76/mt76x0/pci_mcu.c:119:28: error: passing > argument 1 of 'mt76x02_set_ethtool_fwver' from incompatible pointer type > [-Werror=incompatible-pointer-types] > mt76x02_set_ethtool_fwver(dev, hdr); > ^~~ > In file included from drivers/net/wireless/mediatek/mt76/mt76x0/mcu.h:18:0, > from drivers/net/wireless/mediatek/mt76/mt76x0/pci_mcu.c:20: > drivers/net/wireless/mediatek/mt76/mt76x0/../mt76x02_mcu.h:108:6: note: > expected 'struct mt76_dev *' but argument is of type 'struct mt76x02_dev *' > void mt76x02_set_ethtool_fwver(struct mt76_dev *dev, > ^ > cc1: some warnings being treated as errors > scripts/Makefile.build:305: recipe for target > 'drivers/net/wireless/mediatek/mt76/mt76x0/pci_mcu.o' failed > > -- > Kalle Valo Hi Kalle, I guess we can just drop this patch since it is based on 'use mt76x02_dev instead of mt76_dev as reference' series, sent just as RFC for the moment. I will resend this patch on top of other series. Sorry for the noise Regards, Lorenzo -- UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp; umount; make clean; sleep
pull request: mt76 2018-10-05 v2
Hi Kalle, here's the fixed version of the previous pull request. I've dropped the broken patch from the previous round. - Felix The following changes since commit e1c02eb16a9c742178874a7d1a08d300981715fb: qtnfmac: implement dump_station support for STA mode (2018-10-05 14:01:44 +0300) are available in the Git repository at: https://github.com/nbd168/wireless tags/mt76-for-kvalo-2018-10-05 for you to fetch changes up to 9b43960b899c71c758209a58c7e8d7d6e481e272: mt76: move irq handler in mt76x02-lib moudle (2018-10-05 20:05:46 +0200) mt76 patches for 4.20 * unify code between mt76x0, mt76x2 * mt76x0 fixes * another fix for rx buffer allocation regression on usb * move mt76x2 source files to mt76x2 folder * more work on mt76x0e support Colin Ian King (1): mt76: fix header guard macro define names Lorenzo Bianconi (30): mt76x0: pci: add mt76x0e_cleanup routine mt76x2: move mt76x2 source files to mt76x2 folder mt76: usb: fix hw initialization sequence mt76x0: usb: stop cal/mac workqueues at hw stop mt76: move mt76x02_tx_get_max_txpwr_adj in mt76x02_util.c mt76: add get_tx_txpwr_adj function pointer to mt76_driver_ops mt76: move mt76x02_mac_write_txwi in mt76x02-lib module mt76: usb: use mt76x02u_tx_prepare_skb to fill txwi mt76x0: init: remove unnecessary configurations mt76: move mt76x02_phy_get_min_avg_rssi in mt76x02_phy.c mt76: move mt76x02_rx_get_sta and mt76x02_rx_get_sta_wcid in mt76x02_util.h mt76x0: mac: use sta ewma estimation for rssi tracking mt76x0: remove unused variable in mt76x0_dev mt76x0: remove hw_atomic_mutex mutex in mt76x0_dev mt76x2: move mt76x2_dev in mt76x02_util.h mt76x0: merge mt76x0_dev in mt76x02_dev mt76: move mt76x02_mac_process_rx in mt76x02-lib module mt76: unify rxwi parsing between mt76x2 and mt76x0 drivers mt76: move mt76x02_tx in mt76x02-lib module mt76: move txrx shared routines in mt76x02_txrx.c mt76: rename mt76x02_util.h in mt76x02.h mt76x2: remove leftover function declatarions mt76: move tpc routines in mt76x02-lib module mt76: move mt76x02_tx_prepare_skb in mt76x02_txrx.c mt76: usb: move mt76x02u_tx_complete_skb in mt76x02_usb_core.c mt76: move mt76x02_mac_poll_tx_status in mt76x02-lib moudle mt76: move mt76x02_tx_complete in mt76x02-lib module mt76: use mt76x02_dev instead of mt76_dev in mt76x02_mmio.c mt76: move tx_tasklet management in mt76x02-lib moudle mt76: move irq handler in mt76x02-lib moudle Stanislaw Gruszka (1): mt76: fix frag length allocation for usb drivers/net/wireless/mediatek/mt76/Kconfig | 43 +- drivers/net/wireless/mediatek/mt76/Makefile| 26 ++--- drivers/net/wireless/mediatek/mt76/mt76.h | 6 +- drivers/net/wireless/mediatek/mt76/mt76x0/Kconfig | 20 +++ drivers/net/wireless/mediatek/mt76/mt76x0/Makefile | 2 +- drivers/net/wireless/mediatek/mt76/mt76x0/debugfs.c| 4 +- drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c | 28 - drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.h | 18 ++ drivers/net/wireless/mediatek/mt76/mt76x0/init.c | 50 ++-- drivers/net/wireless/mediatek/mt76/mt76x0/initvals.h | 3 +- drivers/net/wireless/mediatek/mt76/mt76x0/mac.c| 82 +++--- drivers/net/wireless/mediatek/mt76/mt76x0/mac.h| 20 --- drivers/net/wireless/mediatek/mt76/mt76x0/main.c | 19 +++--- drivers/net/wireless/mediatek/mt76/mt76x0/mcu.h| 8 +-- drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0.h | 135 +++--- drivers/net/wireless/mediatek/mt76/mt76x0/pci.c| 44 +- drivers/net/wireless/mediatek/mt76/mt76x0/pci_mcu.c| 4 +- drivers/net/wireless/mediatek/mt76/mt76x0/phy.c| 112 +-- drivers/net/wireless/mediatek/mt76/mt76x0/trace.h | 1 - drivers/net/wireless/mediatek/mt76/mt76x0/tx.c | 101 drivers/net/wireless/mediatek/mt76/mt76x0/usb.c| 68 +- drivers/net/wireless/mediatek/mt76/mt76x0/usb_mcu.c| 6 +- drivers/net/wireless/mediatek/mt76/mt76x02.h | 208 +
Re: [PATCH 0/5] mt76x0: phy/rf fixups for PCIe
On 2018-10-04 12:04, Stanislaw Gruszka wrote: > Changes since RFC: > - regbase on top of mt76x02_dev change > - add patch to choose single reg RF access via mt76_is_usb() Merged, thanks. - Felix
Re: [PATCH 2/5] mt76x0: correct RF access via RF_CSR regiser.
On 2018-10-06 10:25, Lorenzo Bianconi wrote: >> >> PCIe version don't use MCU for RF regsisters access. We need >> to correct RF CSR method to support up to 127 RF registers. >> >> Signed-off-by: Stanislaw Gruszka >> --- >> drivers/net/wireless/mediatek/mt76/mt76x0/phy.c | 6 ++ >> drivers/net/wireless/mediatek/mt76/mt76x02_regs.h | 4 ++-- >> 2 files changed, 4 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c >> b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c >> index cbbfd5193d9c..da4569f00794 100644 >> --- a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c >> +++ b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c >> @@ -37,7 +37,7 @@ >> bank = MT_RF_BANK(offset); >> reg = MT_RF_REG(offset); >> >> - if (WARN_ON_ONCE(reg > 64) || WARN_ON_ONCE(bank) > 8) >> + if (WARN_ON_ONCE(reg > 127) || WARN_ON_ONCE(bank) > 8) > > I guess there is a typo here, it should be: > > if (WARN_ON_ONCE(reg > 127) || WARN_ON_ONCE(bank > 8)) It's not a regression, since that part is the same as before the patch. Feel free to send a separate fix. - Felix
Re: pull-request: iwlwifi-next 2018-10-06
Luca Coelho writes: > This is the third batch of patches intended for v4.20. This includes > the last 2 patchsets I sent. Usual development work, including some > improvements in the HE radiotap stuff, a new FW version support and > other small improvements and fixes. More details about the contents in > the tag description. > > I have sent this out before and kbuildbot reported success. > > Please let me know if there are any issues. > > Cheers, > Luca. > > > The following changes since commit e1c02eb16a9c742178874a7d1a08d300981715fb: > > qtnfmac: implement dump_station support for STA mode (2018-10-05 14:01:44 > +0300) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git > tags/iwlwifi-next-for-kalle-2018-10-06 > > for you to fetch changes up to ea7cb8293874f8d9cf36c9e5387e2247f15373dc: > > iwlwifi: dbg: make trigger functions type agnostic (2018-10-06 10:25:55 > +0300) > > > Third set of iwlwifi patches for 4.20 > > * Fix for a race condition that caused the FW to crash; > * HE radiotap cleanup and improvements; > * Reorder channel optimization for scans; > * Bumped the FW API version supported after the last API change for > this release; > * Debugging improvements; > * A few bug fixes; > * Some cleanups in preparation for a new implementation; > * Other small improvements, cleanups and fixes. > > Pulled, thanks. -- Kalle Valo
Re: pull request: mt76 2018-10-05
Felix Fietkau writes: > Here's another large batch of mt76 code cleanup / deduplication / fixes > > - Felix > > The following changes since commit e1c02eb16a9c742178874a7d1a08d300981715fb: > > qtnfmac: implement dump_station support for STA mode (2018-10-05 14:01:44 > +0300) > > are available in the Git repository at: > > https://github.com/nbd168/wireless tags/mt76-for-kvalo-2018-10-05 > > for you to fetch changes up to 06ac97c2e58c7b32bf950ac53976c4260687d386: > > mt76x0: pci: report firmware version using ethtool (2018-10-05 20:05:46 > +0200) > > > mt76 patches for 4.20 > > * unify code between mt76x0, mt76x2 > * mt76x0 fixes > * another fix for rx buffer allocation regression on usb > * move mt76x2 source files to mt76x2 folder > * more work on mt76x0e support > > I have to drop this as it doesn't build for me: drivers/net/wireless/mediatek/mt76/mt76x0/pci_mcu.c: In function 'mt76x0e_load_firmware': drivers/net/wireless/mediatek/mt76/mt76x0/pci_mcu.c:119:28: error: passing argument 1 of 'mt76x02_set_ethtool_fwver' from incompatible pointer type [-Werror=incompatible-pointer-types] mt76x02_set_ethtool_fwver(dev, hdr); ^~~ In file included from drivers/net/wireless/mediatek/mt76/mt76x0/mcu.h:18:0, from drivers/net/wireless/mediatek/mt76/mt76x0/pci_mcu.c:20: drivers/net/wireless/mediatek/mt76/mt76x0/../mt76x02_mcu.h:108:6: note: expected 'struct mt76_dev *' but argument is of type 'struct mt76x02_dev *' void mt76x02_set_ethtool_fwver(struct mt76_dev *dev, ^ cc1: some warnings being treated as errors scripts/Makefile.build:305: recipe for target 'drivers/net/wireless/mediatek/mt76/mt76x0/pci_mcu.o' failed -- Kalle Valo
Re: [PATCH 2/5] mt76x0: correct RF access via RF_CSR regiser.
>
> PCIe version don't use MCU for RF regsisters access. We need
> to correct RF CSR method to support up to 127 RF registers.
>
> Signed-off-by: Stanislaw Gruszka
> ---
> drivers/net/wireless/mediatek/mt76/mt76x0/phy.c | 6 ++
> drivers/net/wireless/mediatek/mt76/mt76x02_regs.h | 4 ++--
> 2 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
> b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
> index cbbfd5193d9c..da4569f00794 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
> @@ -37,7 +37,7 @@
> bank = MT_RF_BANK(offset);
> reg = MT_RF_REG(offset);
>
> - if (WARN_ON_ONCE(reg > 64) || WARN_ON_ONCE(bank) > 8)
> + if (WARN_ON_ONCE(reg > 127) || WARN_ON_ONCE(bank) > 8)
I guess there is a typo here, it should be:
if (WARN_ON_ONCE(reg > 127) || WARN_ON_ONCE(bank > 8))
> return -EINVAL;
>
> mutex_lock(&dev->phy_mutex);
> @@ -76,7 +76,7 @@ static int mt76x0_rf_csr_rr(struct mt76x02_dev *dev, u32
> offset)
> bank = MT_RF_BANK(offset);
> reg = MT_RF_REG(offset);
>
> - if (WARN_ON_ONCE(reg > 64) || WARN_ON_ONCE(bank) > 8)
> + if (WARN_ON_ONCE(reg > 127) || WARN_ON_ONCE(bank) > 8)
same as above
Regards,
Lorenzo
> return -EINVAL;
>
> mutex_lock(&dev->phy_mutex);
> @@ -119,7 +119,6 @@ static int mt76x0_rf_csr_rr(struct mt76x02_dev *dev, u32
> offset)
>
> return mt76_wr_rp(dev, MT_MCU_MEMMAP_RF, &pair, 1);
> } else {
> - WARN_ON_ONCE(1);
> return mt76x0_rf_csr_wr(dev, offset, val);
> }
> }
> @@ -138,7 +137,6 @@ static int mt76x0_rf_csr_rr(struct mt76x02_dev *dev, u32
> offset)
> ret = mt76_rd_rp(dev, MT_MCU_MEMMAP_RF, &pair, 1);
> val = pair.value;
> } else {
> - WARN_ON_ONCE(1);
> ret = val = mt76x0_rf_csr_rr(dev, offset);
> }
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_regs.h
> b/drivers/net/wireless/mediatek/mt76/mt76x02_regs.h
> index 24d1e6d747dd..f7de77d09d28 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt76x02_regs.h
> +++ b/drivers/net/wireless/mediatek/mt76/mt76x02_regs.h
> @@ -205,8 +205,8 @@
> #define MT_TXQ_STA 0x0434
> #defineMT_RF_CSR_CFG 0x0500
> #define MT_RF_CSR_CFG_DATA GENMASK(7, 0)
> -#define MT_RF_CSR_CFG_REG_ID GENMASK(13, 8)
> -#define MT_RF_CSR_CFG_REG_BANK GENMASK(17, 14)
> +#define MT_RF_CSR_CFG_REG_ID GENMASK(14, 8)
> +#define MT_RF_CSR_CFG_REG_BANK GENMASK(17, 15)
> #define MT_RF_CSR_CFG_WR BIT(30)
> #define MT_RF_CSR_CFG_KICK BIT(31)
>
> --
> 1.9.3
>
pull-request: iwlwifi-next 2018-10-06
Hi Kalle, This is the third batch of patches intended for v4.20. This includes the last 2 patchsets I sent. Usual development work, including some improvements in the HE radiotap stuff, a new FW version support and other small improvements and fixes. More details about the contents in the tag description. I have sent this out before and kbuildbot reported success. Please let me know if there are any issues. Cheers, Luca. The following changes since commit e1c02eb16a9c742178874a7d1a08d300981715fb: qtnfmac: implement dump_station support for STA mode (2018-10-05 14:01:44 +0300) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git tags/iwlwifi-next-for-kalle-2018-10-06 for you to fetch changes up to ea7cb8293874f8d9cf36c9e5387e2247f15373dc: iwlwifi: dbg: make trigger functions type agnostic (2018-10-06 10:25:55 +0300) Third set of iwlwifi patches for 4.20 * Fix for a race condition that caused the FW to crash; * HE radiotap cleanup and improvements; * Reorder channel optimization for scans; * Bumped the FW API version supported after the last API change for this release; * Debugging improvements; * A few bug fixes; * Some cleanups in preparation for a new implementation; * Other small improvements, cleanups and fixes. Ayala Beker (1): iwlwifi: mvm: allow channel reorder optimization during scan Emmanuel Grumbach (1): iwlwifi: mvm: clear HW_RESTART_REQUESTED when stopping the interface Haim Dreyfuss (1): iwlwifi: mvm Support new MCC update response Johannes Berg (16): iwlwifi: mvm: remove unnecessary overload variable iwlwifi: mvm: minor cleanups to HE radiotap code iwlwifi: mvm: put HE SIG-B symbols/users data correctly iwlwifi: mvm: pull some he_phy_data decoding into a separate function iwlwifi: mvm: clean up HE radiotap RU allocation parsing iwlwifi: mvm: move HE-MU LTF_NUM parsing to he_phy_data parsing iwlwifi: mvm: add TXOP to HE radiotap data iwlwifi: mvm: add LDPC-XSYM to HE radiotap data iwlwifi: mvm: add more information to HE radiotap iwlwifi: mvm: set max TX/RX A-MPDU subframes to HE limit iwlwifi: pcie gen2: check iwl_pcie_gen2_set_tb() return value iwlwifi: add fall through comment iwlwifi: pcie: check iwl_pcie_txq_build_tfd() return value iwlwifi: bump firmware API version for 9000 and 22000 series devices iwlwifi: mvm: decode HE information for MU (without ext info) iwlwifi: mvm: show more HE radiotap data for TB PPDUs Luca Coelho (1): iwlwifi: mvm: check for n_profiles validity in EWRD ACPI Naftali Goldstein (1): iwlwifi: nvm: get num of hw addresses from firmware Sara Sharon (8): iwlwifi: dbg: move debug data to a struct iwlwifi: dbg: refactor dump code to improve readability iwlwifi: dbg: split iwl_fw_error_dump to two functions iwlwifi: dbg: dump memory in a helper function iwlwifi: dbg: group trigger condition to helper function iwlwifi: dbg: make iwl_fw_dbg_no_trig_window trigger agnostic iwlwifi: dbg: decrement occurrences for all triggers iwlwifi: dbg: make trigger functions type agnostic Shahar S Matityahu (3): iwlwifi: add dump collection in case alive flow fails iwlwifi: runtime: add send host command op to firmware runtime op struct iwlwifi: add debugfs to send host command Shaul Triebitz (1): iwlwifi: pcie: avoid empty free RB queue Yisheng Xie (1): iwlwifi: mvm: use match_string() helper drivers/net/wireless/intel/iwlwifi/cfg/22000.c | 2 +- drivers/net/wireless/intel/iwlwifi/cfg/9000.c | 2 +- drivers/net/wireless/intel/iwlwifi/fw/api/nvm-reg.h | 81 +--- drivers/net/wireless/intel/iwlwifi/fw/api/rx.h | 8 +- drivers/net/wireless/intel/iwlwifi/fw/api/scan.h| 5 +- drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 411 -- drivers/net/wireless/intel/iwlwifi/fw/dbg.h | 45 --- drivers/net/wireless/intel/iwlwifi/fw/debugfs.c | 64 drivers/net/wireless/intel/iwlwifi/fw/error-dump.h | 2 + drivers/net/wireless/intel/iwlwifi/fw/file.h| 7 +- drivers/net/wireless/intel/iwlwifi/fw/img.h | 41 ++ drivers/net/wireless/intel/iwlwifi/fw/runtime.h | 2 + drivers/net/wireless/intel/iwlwifi/iwl-drv.c| 77 +-- drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 10 ++- drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 4 +- drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c| 13 +--- drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 12 ++- drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 12 +-- drivers/net/w
Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg
On Wed 12 Sep 08:08 PDT 2018, Arnd Bergmann wrote:
[..]
> diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c
> index a76b963a7e50..02aefb2b2d47 100644
> --- a/drivers/rpmsg/rpmsg_char.c
> +++ b/drivers/rpmsg/rpmsg_char.c
> @@ -285,7 +285,7 @@ static const struct file_operations rpmsg_eptdev_fops = {
> .write = rpmsg_eptdev_write,
> .poll = rpmsg_eptdev_poll,
> .unlocked_ioctl = rpmsg_eptdev_ioctl,
> - .compat_ioctl = rpmsg_eptdev_ioctl,
> + .compat_ioctl = generic_compat_ioctl_ptrarg,
> };
>
> static ssize_t name_show(struct device *dev, struct device_attribute *attr,
> @@ -446,7 +446,7 @@ static const struct file_operations rpmsg_ctrldev_fops = {
> .open = rpmsg_ctrldev_open,
> .release = rpmsg_ctrldev_release,
> .unlocked_ioctl = rpmsg_ctrldev_ioctl,
> - .compat_ioctl = rpmsg_ctrldev_ioctl,
> + .compat_ioctl = generic_compat_ioctl_ptrarg,
> };
>
For rpmsg part
Acked-by: Bjorn Andersson
Regards,
Bjorn
