Re: [PATCH 1/4] cfg80211: rdev-ops: remove callback check from rdev_set_coalesce()
> I was in doubt to raise the question first about getting this stuff > consistent, ie. keep rdev-ops as flat as possible, but decided just > to put it out there in patch format. My bad :-) :-) > If you want the rdev-ops to be safe against (future) callers not > checking the callback, it seems you should add a check in all rdev- > ops where the callback is optional. Yeah, perhaps. I don't really mind hugely either way, but I think removing them now would mostly be unwarranted churn. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH] nl80211: Allow GET_INTERFACE dumps to be filtered
On Thu, 2016-08-11 at 13:20 -0500, Denis Kenzior wrote:
> Hi Johannes,
>
> >> Speaking of indentation, can you point me to a doc of the rules I
> >
> > >
> > > should follow?
> >
> > You've seen Documentation/CodingStyle?
>
> Of course. But that one doesn't discuss that you want your function
> parameters to be aligned to the opening '('. Is there a dialect
> document specific to linux-wireless?
Sorry. I don't think this is specific to our part of the tree, and I'm
surprised it's not in there. But I see Arend also pointed you to
checkpatch.pl, which, I might add, you shouldn't always take as
authoritative since sometimes "fixing" things for it makes the code
look worse.
> The initial conditions are that:
> cb->args[0..2] == 0.
>
> So on the first iteration we set filter_wiphy == -1 and check the
> filter attributes. If set, we modify filter_wiphy accordingly.
>
> Even if filter_wiphy is set to 0, the if statement should still never
> be entered afterwards since wp_start and if_start are incremented.
>
> Is this what you're worried about? Do you see a fault in my logic?
No, I don't see a fault in the logic. I just think it's misleading. You
make the code look like it relies on filter_wiphy != 0, but then you go
and treat filter_wiphy==0 as a valid case.
In other places, like nl80211_prepare_wdev_dump(), we add 1 to the
wiphy and subtract it again later to avoid exactly this. Perhaps you
could do the same, and rely only on filter_wiphy instead of really
relying only on wp_start/if_start.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Staging: rtl8723au: os_intfs: fixed case statement is variable issue
On Aug 11, 2016, at 23:25, Jes Sorensen wrote:
> Bing Sun writes:
>> Fixed sparse parse error:
>> Expected constant expression in case statement.
>>
>> Signed-off-by: Bing Sun
>> ---
>> drivers/staging/rtl8723au/os_dep/os_intfs.c | 11 +--
>> 1 file changed, 5 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/staging/rtl8723au/os_dep/os_intfs.c
>> b/drivers/staging/rtl8723au/os_dep/os_intfs.c
>> index b8848c2..f30d5d2 100644
>> --- a/drivers/staging/rtl8723au/os_dep/os_intfs.c
>> +++ b/drivers/staging/rtl8723au/os_dep/os_intfs.c
>> @@ -283,14 +283,13 @@ static u32 rtw_classify8021d(struct sk_buff *skb)
>> */
>> if (skb->priority >= 256 && skb->priority <= 263)
>> return skb->priority - 256;
>> -switch (skb->protocol) {
>> -case htons(ETH_P_IP):
>> +
>> +if (skb->protocol == htons(ETH_P_IP)) {
>> dscp = ip_hdr(skb)->tos & 0xfc;
>> -break;
>> -default:
>> -return 0;
>> +return dscp >> 5;
>> }
>> -return dscp >> 5;
>> +
>> +return 0;
>> }
>
> Pardon me here, but I find it really hard to see how this change is an
> improvement over the old code in any shape or form.
>
> Jes
There is no functional improvement.
But before this patch, when we do: make C=1 M=drivers/staging/rtl8723au/
An error output:
drivers/staging/rtl8723au//os_dep/os_intfs.c:287:14: error: Expected constant
expression in case statement
To avoid sparse parse error, a case statement converts to an if statement.
So we got this patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 16/16] net: wireless: realtek: rtlwifi: usb: don't print error when allocating urb fails
On 08/11/2016 04:13 PM, Wolfram Sang wrote:
kmalloc will print enough information in case of failure.
Signed-off-by: Wolfram Sang
---
drivers/net/wireless/realtek/rtlwifi/usb.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
Acked-by: Larry Finger
diff --git a/drivers/net/wireless/realtek/rtlwifi/usb.c
b/drivers/net/wireless/realtek/rtlwifi/usb.c
index 41617b7b082260..32aa5c1d070a07 100644
--- a/drivers/net/wireless/realtek/rtlwifi/usb.c
+++ b/drivers/net/wireless/realtek/rtlwifi/usb.c
@@ -739,11 +739,8 @@ static int _rtl_usb_receive(struct ieee80211_hw *hw)
for (i = 0; i < rtlusb->rx_urb_num; i++) {
err = -ENOMEM;
urb = usb_alloc_urb(0, GFP_KERNEL);
- if (!urb) {
- RT_TRACE(rtlpriv, COMP_USB, DBG_EMERG,
-"Failed to alloc URB!!\n");
+ if (!urb)
goto err_out;
- }
err = _rtl_prep_rx_urb(hw, rtlusb, urb, GFP_KERNEL);
if (err < 0) {
@@ -907,15 +904,12 @@ static void _rtl_tx_complete(struct urb *urb)
static struct urb *_rtl_usb_tx_urb_setup(struct ieee80211_hw *hw,
struct sk_buff *skb, u32 ep_num)
{
- struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_usb *rtlusb = rtl_usbdev(rtl_usbpriv(hw));
struct urb *_urb;
WARN_ON(NULL == skb);
_urb = usb_alloc_urb(0, GFP_ATOMIC);
if (!_urb) {
- RT_TRACE(rtlpriv, COMP_USB, DBG_EMERG,
-"Can't allocate URB for bulk out!\n");
kfree_skb(skb);
return NULL;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH] nl80211: Allow GET_INTERFACE dumps to be filtered
On 11-8-2016 21:05, Denis Kenzior wrote: > Hi Arend, > >> >> You can find it in checkpatch.pl [1] :-p >> > > Aha! Will use that one next time. Thanks. There is a '--strict' command line option. Not sure if this indentation one false into that category. Regards, Arend > Regards, > -Denis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/16] net: wireless: marvell: mwifiex: usb: don't print error when allocating urb fails
kmalloc will print enough information in case of failure.
Signed-off-by: Wolfram Sang
---
drivers/net/wireless/marvell/mwifiex/usb.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/usb.c
b/drivers/net/wireless/marvell/mwifiex/usb.c
index 0857575c5c39fe..3bd04f52f36988 100644
--- a/drivers/net/wireless/marvell/mwifiex/usb.c
+++ b/drivers/net/wireless/marvell/mwifiex/usb.c
@@ -657,11 +657,8 @@ static int mwifiex_usb_tx_init(struct mwifiex_adapter
*adapter)
card->tx_cmd.ep = card->tx_cmd_ep;
card->tx_cmd.urb = usb_alloc_urb(0, GFP_KERNEL);
- if (!card->tx_cmd.urb) {
- mwifiex_dbg(adapter, ERROR,
- "tx_cmd.urb allocation failed\n");
+ if (!card->tx_cmd.urb)
return -ENOMEM;
- }
for (i = 0; i < MWIFIEX_TX_DATA_PORT; i++) {
port = &card->port[i];
@@ -677,11 +674,8 @@ static int mwifiex_usb_tx_init(struct mwifiex_adapter
*adapter)
port->tx_data_list[j].ep = port->tx_data_ep;
port->tx_data_list[j].urb =
usb_alloc_urb(0, GFP_KERNEL);
- if (!port->tx_data_list[j].urb) {
- mwifiex_dbg(adapter, ERROR,
- "urb allocation failed\n");
+ if (!port->tx_data_list[j].urb)
return -ENOMEM;
- }
}
}
@@ -697,10 +691,8 @@ static int mwifiex_usb_rx_init(struct mwifiex_adapter
*adapter)
card->rx_cmd.ep = card->rx_cmd_ep;
card->rx_cmd.urb = usb_alloc_urb(0, GFP_KERNEL);
- if (!card->rx_cmd.urb) {
- mwifiex_dbg(adapter, ERROR, "rx_cmd.urb allocation failed\n");
+ if (!card->rx_cmd.urb)
return -ENOMEM;
- }
card->rx_cmd.skb = dev_alloc_skb(MWIFIEX_RX_CMD_BUF_SIZE);
if (!card->rx_cmd.skb)
@@ -714,11 +706,8 @@ static int mwifiex_usb_rx_init(struct mwifiex_adapter
*adapter)
card->rx_data_list[i].ep = card->rx_data_ep;
card->rx_data_list[i].urb = usb_alloc_urb(0, GFP_KERNEL);
- if (!card->rx_data_list[i].urb) {
- mwifiex_dbg(adapter, ERROR,
- "rx_data_list[] urb allocation failed\n");
+ if (!card->rx_data_list[i].urb)
return -1;
- }
if (mwifiex_usb_submit_rx_urb(&card->rx_data_list[i],
MWIFIEX_RX_DATA_BUF_SIZE))
return -1;
--
2.8.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/16] net: wireless: marvell: libertas_tf: if_usb: don't print error when allocating urb fails
kmalloc will print enough information in case of failure.
Signed-off-by: Wolfram Sang
---
drivers/net/wireless/marvell/libertas_tf/if_usb.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/marvell/libertas_tf/if_usb.c
b/drivers/net/wireless/marvell/libertas_tf/if_usb.c
index 799a2efe579372..e0ade40d9497d7 100644
--- a/drivers/net/wireless/marvell/libertas_tf/if_usb.c
+++ b/drivers/net/wireless/marvell/libertas_tf/if_usb.c
@@ -198,22 +198,16 @@ static int if_usb_probe(struct usb_interface *intf,
}
cardp->rx_urb = usb_alloc_urb(0, GFP_KERNEL);
- if (!cardp->rx_urb) {
- lbtf_deb_usbd(&udev->dev, "Rx URB allocation failed\n");
+ if (!cardp->rx_urb)
goto dealloc;
- }
cardp->tx_urb = usb_alloc_urb(0, GFP_KERNEL);
- if (!cardp->tx_urb) {
- lbtf_deb_usbd(&udev->dev, "Tx URB allocation failed\n");
+ if (!cardp->tx_urb)
goto dealloc;
- }
cardp->cmd_urb = usb_alloc_urb(0, GFP_KERNEL);
- if (!cardp->cmd_urb) {
- lbtf_deb_usbd(&udev->dev, "Cmd URB allocation failed\n");
+ if (!cardp->cmd_urb)
goto dealloc;
- }
cardp->ep_out_buf = kmalloc(MRVDRV_ETH_TX_PACKET_BUFFER_SIZE,
GFP_KERNEL);
--
2.8.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 16/16] net: wireless: realtek: rtlwifi: usb: don't print error when allocating urb fails
kmalloc will print enough information in case of failure.
Signed-off-by: Wolfram Sang
---
drivers/net/wireless/realtek/rtlwifi/usb.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/usb.c
b/drivers/net/wireless/realtek/rtlwifi/usb.c
index 41617b7b082260..32aa5c1d070a07 100644
--- a/drivers/net/wireless/realtek/rtlwifi/usb.c
+++ b/drivers/net/wireless/realtek/rtlwifi/usb.c
@@ -739,11 +739,8 @@ static int _rtl_usb_receive(struct ieee80211_hw *hw)
for (i = 0; i < rtlusb->rx_urb_num; i++) {
err = -ENOMEM;
urb = usb_alloc_urb(0, GFP_KERNEL);
- if (!urb) {
- RT_TRACE(rtlpriv, COMP_USB, DBG_EMERG,
-"Failed to alloc URB!!\n");
+ if (!urb)
goto err_out;
- }
err = _rtl_prep_rx_urb(hw, rtlusb, urb, GFP_KERNEL);
if (err < 0) {
@@ -907,15 +904,12 @@ static void _rtl_tx_complete(struct urb *urb)
static struct urb *_rtl_usb_tx_urb_setup(struct ieee80211_hw *hw,
struct sk_buff *skb, u32 ep_num)
{
- struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_usb *rtlusb = rtl_usbdev(rtl_usbpriv(hw));
struct urb *_urb;
WARN_ON(NULL == skb);
_urb = usb_alloc_urb(0, GFP_ATOMIC);
if (!_urb) {
- RT_TRACE(rtlpriv, COMP_USB, DBG_EMERG,
-"Can't allocate URB for bulk out!\n");
kfree_skb(skb);
return NULL;
}
--
2.8.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/16] net: wireless: intersil: orinoco: orinoco_usb: don't print error when allocating urb fails
kmalloc will print enough information in case of failure.
Signed-off-by: Wolfram Sang
---
drivers/net/wireless/intersil/orinoco/orinoco_usb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/wireless/intersil/orinoco/orinoco_usb.c
b/drivers/net/wireless/intersil/orinoco/orinoco_usb.c
index 56f109bc83945d..bca6935a94db9a 100644
--- a/drivers/net/wireless/intersil/orinoco/orinoco_usb.c
+++ b/drivers/net/wireless/intersil/orinoco/orinoco_usb.c
@@ -1613,10 +1613,8 @@ static int ezusb_probe(struct usb_interface *interface,
}
upriv->read_urb = usb_alloc_urb(0, GFP_KERNEL);
- if (!upriv->read_urb) {
- err("No free urbs available");
+ if (!upriv->read_urb)
goto error;
- }
if (le16_to_cpu(ep->wMaxPacketSize) != 64)
pr_warn("bulk in: wMaxPacketSize!= 64\n");
if (ep->bEndpointAddress != (2 | USB_DIR_IN))
--
2.8.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/16] net: don't print error when allocating urb fails
This per-subsystem series is part of a tree wide cleanup. usb_alloc_urb() uses kmalloc which already prints enough information on failure. So, let's simply remove those "allocation failed" messages from drivers like we did already for other -ENOMEM cases. gkh acked this approach when we talked about it at LCJ in Tokyo a few weeks ago. Wolfram Sang (16): net: can: usb: ems_usb: don't print error when allocating urb fails net: can: usb: esd_usb2: don't print error when allocating urb fails net: can: usb: gs_usb: don't print error when allocating urb fails net: can: usb: kvaser_usb: don't print error when allocating urb fails net: can: usb: peak_usb: pcan_usb_core: don't print error when allocating urb fails net: can: usb: usb_8dev: don't print error when allocating urb fails net: usb: hso: don't print error when allocating urb fails net: usb: lan78xx: don't print error when allocating urb fails net: usb: usbnet: don't print error when allocating urb fails net: wimax: i2400m: usb-notif: don't print error when allocating urb fails net: wireless: ath: ar5523: ar5523: don't print error when allocating urb fails net: wireless: broadcom: brcm80211: brcmfmac: usb: don't print error when allocating urb fails net: wireless: intersil: orinoco: orinoco_usb: don't print error when allocating urb fails net: wireless: marvell: libertas_tf: if_usb: don't print error when allocating urb fails net: wireless: marvell: mwifiex: usb: don't print error when allocating urb fails net: wireless: realtek: rtlwifi: usb: don't print error when allocating urb fails drivers/net/can/usb/ems_usb.c| 9 ++--- drivers/net/can/usb/esd_usb2.c | 3 --- drivers/net/can/usb/gs_usb.c | 9 ++--- drivers/net/can/usb/kvaser_usb.c | 7 +-- drivers/net/can/usb/peak_usb/pcan_usb_core.c | 6 +- drivers/net/can/usb/usb_8dev.c | 5 + drivers/net/usb/hso.c| 20 +--- drivers/net/usb/lan78xx.c| 4 +--- drivers/net/usb/usbnet.c | 5 + drivers/net/wimax/i2400m/usb-notif.c | 1 - drivers/net/wireless/ath/ar5523/ar5523.c | 9 ++--- .../net/wireless/broadcom/brcm80211/brcmfmac/usb.c | 8 ++-- drivers/net/wireless/intersil/orinoco/orinoco_usb.c | 4 +--- drivers/net/wireless/marvell/libertas_tf/if_usb.c| 12 +++- drivers/net/wireless/marvell/mwifiex/usb.c | 19 --- drivers/net/wireless/realtek/rtlwifi/usb.c | 8 +--- 16 files changed, 27 insertions(+), 102 deletions(-) -- 2.8.1 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/16] net: wireless: ath: ar5523: ar5523: don't print error when allocating urb fails
kmalloc will print enough information in case of failure.
Signed-off-by: Wolfram Sang
---
drivers/net/wireless/ath/ar5523/ar5523.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath/ar5523/ar5523.c
b/drivers/net/wireless/ath/ar5523/ar5523.c
index 8aded24bcdf49e..7a60d2e652dad6 100644
--- a/drivers/net/wireless/ath/ar5523/ar5523.c
+++ b/drivers/net/wireless/ath/ar5523/ar5523.c
@@ -706,10 +706,8 @@ static int ar5523_alloc_rx_bufs(struct ar5523 *ar)
data->ar = ar;
data->urb = usb_alloc_urb(0, GFP_KERNEL);
- if (!data->urb) {
- ar5523_err(ar, "could not allocate rx data urb\n");
+ if (!data->urb)
goto err;
- }
list_add_tail(&data->list, &ar->rx_data_free);
atomic_inc(&ar->rx_data_free_cnt);
}
@@ -824,7 +822,6 @@ static void ar5523_tx_work_locked(struct ar5523 *ar)
urb = usb_alloc_urb(0, GFP_KERNEL);
if (!urb) {
- ar5523_err(ar, "Failed to allocate TX urb\n");
ieee80211_free_txskb(ar->hw, skb);
continue;
}
@@ -949,10 +946,8 @@ static int ar5523_alloc_tx_cmd(struct ar5523 *ar)
init_completion(&cmd->done);
cmd->urb_tx = usb_alloc_urb(0, GFP_KERNEL);
- if (!cmd->urb_tx) {
- ar5523_err(ar, "could not allocate urb\n");
+ if (!cmd->urb_tx)
return -ENOMEM;
- }
cmd->buf_tx = usb_alloc_coherent(ar->dev, AR5523_MAX_TXCMDSZ,
GFP_KERNEL,
&cmd->urb_tx->transfer_dma);
--
2.8.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/16] net: wireless: broadcom: brcm80211: brcmfmac: usb: don't print error when allocating urb fails
kmalloc will print enough information in case of failure.
Signed-off-by: Wolfram Sang
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
index 98b15a9a2779f4..fa26619a7945d9 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
@@ -1099,15 +1099,11 @@ struct brcmf_usbdev *brcmf_usb_attach(struct
brcmf_usbdev_info *devinfo,
devinfo->tx_freecount = ntxq;
devinfo->ctl_urb = usb_alloc_urb(0, GFP_ATOMIC);
- if (!devinfo->ctl_urb) {
- brcmf_err("usb_alloc_urb (ctl) failed\n");
+ if (!devinfo->ctl_urb)
goto error;
- }
devinfo->bulk_urb = usb_alloc_urb(0, GFP_ATOMIC);
- if (!devinfo->bulk_urb) {
- brcmf_err("usb_alloc_urb (bulk) failed\n");
+ if (!devinfo->bulk_urb)
goto error;
- }
return &devinfo->bus_pub;
--
2.8.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ath9k: use ieee80211_tx_status_noskb where possible
On 2016-08-11 18:05, Zefir Kurtisi wrote: > On 08/04/2016 11:49 PM, Felix Fietkau wrote: >> It removes the need for undoing the padding changes to skb->data and it >> improves performance by eliminating one tx status lookup per MPDU in the >> status path. It is also useful for preparing a follow-up fix to better >> handle powersave filtering. >> > > For me, this one introduces a regression to the statistics, e.g. > 'dot11TransmittedFragmentCount' is now accounted differently since it is not > updated from within ieee80211_tx_status_noskb(). Is this important? I guess it would be possible to make this more accurate by extending the API, but I wonder if that's worth doing just for these debugfs counters. - Felix -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] cfg80211: rdev-ops: remove callback check from rdev_set_coalesce()
On 11-8-2016 14:48, Johannes Berg wrote: > On Wed, 2016-08-10 at 12:33 +0200, Arend van Spriel wrote: >> The wrapper rdev_set_coalesce() checks whether the driver provides >> the set_coalesce callback and returns -ENOTSUPP if not. However, this >> check is already performed in nl80211_set_coalesce() resulting in >> -EOPNOTSUPP. This patch removes check from rdev wrapper function. > > What's the point though? Presumably the compiler will optimise it out, > and it seems safer to have it this way? Same for all patches in this > series. I was in doubt to raise the question first about getting this stuff consistent, ie. keep rdev-ops as flat as possible, but decided just to put it out there in patch format. My bad :-) If you want the rdev-ops to be safe against (future) callers not checking the callback, it seems you should add a check in all rdev-ops where the callback is optional. Regards, Arend -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH] nl80211: Allow GET_INTERFACE dumps to be filtered
Hi Arend, > You can find it in checkpatch.pl [1] :-p Aha! Will use that one next time. Thanks. Regards, -Denis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
default dtim period
Hi Everybody, Maybe not the correct mailinglist to ask, but I'm going to give it a shot. Any advises on the most preferred default dtim period? 2 or 3? Not every driver has the same defaults. Same question about the listen interval. 0x0258 (600 beacon intervals) sounds decent? Thanks, Reinoud. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH] nl80211: Allow GET_INTERFACE dumps to be filtered
On 11-8-2016 20:20, Denis Kenzior wrote:
> Hi Johannes,
>
>>> Speaking of indentation, can you point me to a doc of the rules I
>>> should follow?
>>
>> You've seen Documentation/CodingStyle?
>
> Of course. But that one doesn't discuss that you want your function
> parameters to be aligned to the opening '('. Is there a dialect
> document specific to linux-wireless?
You can find it in checkpatch.pl [1] :-p
Regards,
Arend
[1] http://lxr.free-electrons.com/source/scripts/checkpatch.pl#L2855
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH] nl80211: Allow GET_INTERFACE dumps to be filtered
Hi Johannes,
>> Speaking of indentation, can you point me to a doc of the rules I
should follow?
You've seen Documentation/CodingStyle?
Of course. But that one doesn't discuss that you want your function
parameters to be aligned to the opening '('. Is there a dialect
document specific to linux-wireless?
I can confirm that I sanity checked this patch. Both ATTR_WIPHY,
ATTR_WDEV and wildcard dumps seemed to produce expected results.
I think it probably works due to the other conditions?
The initial conditions are that:
cb->args[0..2] == 0.
So on the first iteration we set filter_wiphy == -1 and check the filter
attributes. If set, we modify filter_wiphy accordingly.
Even if filter_wiphy is set to 0, the if statement should still never be
entered afterwards since wp_start and if_start are incremented.
Is this what you're worried about? Do you see a fault in my logic?
Regards,
-Denis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH] nl80211: Allow GET_INTERFACE dumps to be filtered
On Thu, 2016-08-11 at 11:38 -0500, Denis Kenzior wrote: > Hi Johannes, > > On 08/11/2016 07:47 AM, Johannes Berg wrote: > > > > On Wed, 2016-08-03 at 17:02 -0500, Denis Kenzior wrote: > > > > > > > > > +static int nl80211_dump_interface_parse(struct sk_buff *skb, > > > + struct netlink_callback *cb, > > > + int *filter_wiphy) > > > > Wrong indentation :) > > Sorry :) > > Speaking of indentation, can you point me to a doc of the rules I > should follow? You've seen Documentation/CodingStyle? > I can confirm that I sanity checked this patch. Both ATTR_WIPHY, > ATTR_WDEV and wildcard dumps seemed to produce expected results. I think it probably works due to the other conditions? > I noticed you applied this patch. Is there a particular scenario > where it goes wrong or did you convince yourself it is correct? > No, that was a mistake :( I've removed it now. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH] nl80211: Allow GET_INTERFACE dumps to be filtered
Hi Johannes,
On 08/11/2016 07:47 AM, Johannes Berg wrote:
On Wed, 2016-08-03 at 17:02 -0500, Denis Kenzior wrote:
+static int nl80211_dump_interface_parse(struct sk_buff *skb,
+ struct netlink_callback *cb,
+ int *filter_wiphy)
Wrong indentation :)
Sorry :)
Speaking of indentation, can you point me to a doc of the rules I should
follow?
static int nl80211_dump_interface(struct sk_buff *skb, struct
netlink_callback *cb)
{
int wp_idx = 0;
int if_idx = 0;
int wp_start = cb->args[0];
int if_start = cb->args[1];
+ int filter_wiphy = cb->args[2];
struct cfg80211_registered_device *rdev;
struct wireless_dev *wdev;
+ if (!wp_start && !if_start && !filter_wiphy) {
This seems incorrect - you're setting
+ int ret;
+
+ filter_wiphy = -1;
+
+ ret = nl80211_dump_interface_parse(skb, cb,
&filter_wiphy);
it here, but it can take the value 0, so !filter_wiphy seems wrong?
I can confirm that I sanity checked this patch. Both ATTR_WIPHY,
ATTR_WDEV and wildcard dumps seemed to produce expected results.
I noticed you applied this patch. Is there a particular scenario where
it goes wrong or did you convince yourself it is correct?
Regards,
-Denis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/3] Improve wireless netdev detection
Hi Johannes, > Applied. I squashed 1/2 since it's kinda pointless to have a patch introducing infrastructure that's not used. I also made some minor cleanups - please check (both that it's right, and for next time) Your changes look fine to me. Thanks for taking these. Regards, -Denis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ath9k: use ieee80211_tx_status_noskb where possible
On 08/04/2016 11:49 PM, Felix Fietkau wrote: > It removes the need for undoing the padding changes to skb->data and it > improves performance by eliminating one tx status lookup per MPDU in the > status path. It is also useful for preparing a follow-up fix to better > handle powersave filtering. > For me, this one introduces a regression to the statistics, e.g. 'dot11TransmittedFragmentCount' is now accounted differently since it is not updated from within ieee80211_tx_status_noskb(). Cheers, Zefir -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5] cfg80211: Provision to allow the support for different beacon intervals
> This seems odd. Shouldn't it use cfg80211_iter_combinations()?
Yes . We should have reused cfg80211_iter_combinations. Thanks a lot for your
suggestion.
> seems we mostly moved that to mac80211, but for this case it should probably
> stay in cfg80211? Or should it?
The scope here is to know the advertised "diff_beacon_int_gcd" for the
respective matching interface combination and further validate it with the
configured one.
To address this " cfg80211_validate_beacon_int" needs to get enhanced , isn't ?
Regards,
Sunil
-Original Message-
From: Johannes Berg [mailto:johan...@sipsolutions.net]
Sent: Thursday, August 11, 2016 6:39 PM
To: Kushwaha, Purushottam
Cc: linux-wireless@vger.kernel.org; Malinen, Jouni ;
Undekari, Sunil Dutt ; Hullur Subramanyam, Amarnath
; Kumar, Deepak (QCA)
Subject: Re: [PATCH v5] cfg80211: Provision to allow the support for different
beacon intervals
> +static bool diff_beacon_interval_supported(struct wiphy *wiphy, u16
> types,
> + u32 beacon_int)
> +{
> + const struct ieee80211_iface_combination *c;
> + u16 all_types;
> + int i, j;
> +
> + for (i = 0; i < wiphy->n_iface_combinations; i++) {
> + c = &wiphy->iface_combinations[i];
> +
> + if (!c->diff_beacon_int_gcd ||
> + (beacon_int % c->diff_beacon_int_gcd))
> + continue;
> +
> + all_types = 0;
> + for (j = 0; j < c->n_limits; j++)
> + all_types |= c->limits[j].types;
> +
> + if (all_types & types)
> + return true;
> + }
> +
> + return false;
> +}
This seems odd. Shouldn't it use cfg80211_iter_combinations()? Might need some
additional helper to understand which interface types are used right now -
seems we mostly moved that to mac80211, but for this case it should probably
stay in cfg80211? Or should it?
johannes
N�r��yb�X��ǧv�^�){.n�+{��*ޕ�,�{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj"��!�i
Re: [PATCH] Staging: rtl8723au: os_intfs: fixed case statement is variable issue
Bing Sun writes:
> Fixed sparse parse error:
> Expected constant expression in case statement.
>
> Signed-off-by: Bing Sun
> ---
> drivers/staging/rtl8723au/os_dep/os_intfs.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/rtl8723au/os_dep/os_intfs.c
> b/drivers/staging/rtl8723au/os_dep/os_intfs.c
> index b8848c2..f30d5d2 100644
> --- a/drivers/staging/rtl8723au/os_dep/os_intfs.c
> +++ b/drivers/staging/rtl8723au/os_dep/os_intfs.c
> @@ -283,14 +283,13 @@ static u32 rtw_classify8021d(struct sk_buff *skb)
>*/
> if (skb->priority >= 256 && skb->priority <= 263)
> return skb->priority - 256;
> - switch (skb->protocol) {
> - case htons(ETH_P_IP):
> +
> + if (skb->protocol == htons(ETH_P_IP)) {
> dscp = ip_hdr(skb)->tos & 0xfc;
> - break;
> - default:
> - return 0;
> + return dscp >> 5;
> }
> - return dscp >> 5;
> +
> + return 0;
> }
Pardon me here, but I find it really hard to see how this change is an
improvement over the old code in any shape or form.
Jes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] mac80211: Re-structure aqm debugfs output and include CoDel drops
Currently the 'aqm' stats in mac80211 only keeps overlimit drop stats,
not CoDel stats. This moves the CoDel stats into the txqi structure to
keep them per txq in order to show them in debugfs.
In addition, the aqm debugfs output is restructured by splitting it up
into three files: One global per phy, one per netdev and one per
station, in the appropriate directories. The files are all called aqm,
and are only created if the driver supports the wake_tx_queue op (rather
than emitting an error on open as previously).
Signed-off-by: Toke Høiland-Jørgensen
---
net/mac80211/debugfs.c| 151 --
net/mac80211/debugfs_netdev.c | 37 ++-
net/mac80211/debugfs_sta.c| 45 +
net/mac80211/ieee80211_i.h| 2 +-
net/mac80211/tx.c | 4 +-
5 files changed, 110 insertions(+), 129 deletions(-)
diff --git a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
index 27e6fb9..2f14141 100644
--- a/net/mac80211/debugfs.c
+++ b/net/mac80211/debugfs.c
@@ -71,138 +71,39 @@ DEBUGFS_READONLY_FILE(wep_iv, "%#08x",
DEBUGFS_READONLY_FILE(rate_ctrl_alg, "%s",
local->rate_ctrl ? local->rate_ctrl->ops->name : "hw/driver");
-struct aqm_info {
- struct ieee80211_local *local;
- size_t size;
- size_t len;
- unsigned char buf[0];
-};
-
-#define AQM_HDR_LEN 200
-#define AQM_HW_ENTRY_LEN 40
-#define AQM_TXQ_ENTRY_LEN 110
-
-static int aqm_open(struct inode *inode, struct file *file)
+static ssize_t aqm_read(struct file *file,
+ char __user *user_buf,
+ size_t count,
+ loff_t *ppos)
{
- struct ieee80211_local *local = inode->i_private;
- struct ieee80211_sub_if_data *sdata;
- struct sta_info *sta;
- struct txq_info *txqi;
+ struct ieee80211_local *local = file->private_data;
struct fq *fq = &local->fq;
- struct aqm_info *info = NULL;
+ char buf[200];
int len = 0;
- int i;
-
- if (!local->ops->wake_tx_queue)
- return -EOPNOTSUPP;
-
- len += AQM_HDR_LEN;
- len += 6 * AQM_HW_ENTRY_LEN;
-
- rcu_read_lock();
- list_for_each_entry_rcu(sdata, &local->interfaces, list)
- len += AQM_TXQ_ENTRY_LEN;
- list_for_each_entry_rcu(sta, &local->sta_list, list)
- len += AQM_TXQ_ENTRY_LEN * ARRAY_SIZE(sta->sta.txq);
- rcu_read_unlock();
-
- info = vmalloc(len);
- if (!info)
- return -ENOMEM;
spin_lock_bh(&local->fq.lock);
rcu_read_lock();
- file->private_data = info;
- info->local = local;
- info->size = len;
- len = 0;
-
- len += scnprintf(info->buf + len, info->size - len,
-"* hw\n"
-"access name value\n"
-"R fq_flows_cnt %u\n"
-"R fq_backlog %u\n"
-"R fq_overlimit %u\n"
-"R fq_collisions %u\n"
-"RW fq_limit %u\n"
-"RW fq_quantum %u\n",
-fq->flows_cnt,
-fq->backlog,
-fq->overlimit,
-fq->collisions,
-fq->limit,
-fq->quantum);
-
- len += scnprintf(info->buf + len,
-info->size - len,
-"* vif\n"
-"ifname addr ac backlog-bytes backlog-packets flows
overlimit collisions tx-bytes tx-packets\n");
-
- list_for_each_entry_rcu(sdata, &local->interfaces, list) {
- txqi = to_txq_info(sdata->vif.txq);
- len += scnprintf(info->buf + len, info->size - len,
-"%s %pM %u %u %u %u %u %u %u %u\n",
-sdata->name,
-sdata->vif.addr,
-txqi->txq.ac,
-txqi->tin.backlog_bytes,
-txqi->tin.backlog_packets,
-txqi->tin.flows,
-txqi->tin.overlimit,
-txqi->tin.collisions,
-txqi->tin.tx_bytes,
-txqi->tin.tx_packets);
- }
-
- len += scnprintf(info->buf + len,
-info->size - len,
-"* sta\n"
-"ifname addr tid ac backlog-bytes backlog-packets
flows overlimit collisions tx-bytes tx-packets\n");
-
- list_for_each_entry_rcu(sta, &local->sta_list, list) {
- sdata = sta->sdata;
- for (i = 0; i < ARRAY_SIZE(sta->sta.txq); i++) {
- txqi = to_txq_info(sta->sta.txq[i]);
- len += scnprintf(info->buf + len, info->size - len,
-
Re: [PATCH] rt2x00usb: Fix error return code
On Thu, Aug 11, 2016 at 04:38:54PM +0200, Christophe JAILLET wrote:
> We know that 'retval = 0' because it has been tested a few lines above.
> So, if 'devm_kmalloc' fails, 0 will be returned instead of an error code.
> Return -ENOMEM instead.
>
> Fixes: 8b4c0009313f ("rt2x00usb: Use usb anchor to manage URB")
>
> Signed-off-by: Christophe JAILLET
Acked-by: Stanislaw Gruszka
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] rt2x00usb: Fix error return code
We know that 'retval = 0' because it has been tested a few lines above.
So, if 'devm_kmalloc' fails, 0 will be returned instead of an error code.
Return -ENOMEM instead.
Fixes: 8b4c0009313f ("rt2x00usb: Use usb anchor to manage URB")
Signed-off-by: Christophe JAILLET
---
drivers/net/wireless/ralink/rt2x00/rt2x00usb.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
index 7cf26c6124d1..6005e14213ca 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
@@ -831,8 +831,10 @@ int rt2x00usb_probe(struct usb_interface *usb_intf,
rt2x00dev->anchor = devm_kmalloc(&usb_dev->dev,
sizeof(struct usb_anchor),
GFP_KERNEL);
- if (!rt2x00dev->anchor)
+ if (!rt2x00dev->anchor) {
+ retval = -ENOMEM;
goto exit_free_reg;
+ }
init_usb_anchor(rt2x00dev->anchor);
return 0;
--
2.7.4
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel
antivirus Avast.
https://www.avast.com/antivirus
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Staging: rtl8723au: os_intfs: fixed case statement is variable issue
Fixed sparse parse error:
Expected constant expression in case statement.
Signed-off-by: Bing Sun
---
drivers/staging/rtl8723au/os_dep/os_intfs.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8723au/os_dep/os_intfs.c
b/drivers/staging/rtl8723au/os_dep/os_intfs.c
index b8848c2..f30d5d2 100644
--- a/drivers/staging/rtl8723au/os_dep/os_intfs.c
+++ b/drivers/staging/rtl8723au/os_dep/os_intfs.c
@@ -283,14 +283,13 @@ static u32 rtw_classify8021d(struct sk_buff *skb)
*/
if (skb->priority >= 256 && skb->priority <= 263)
return skb->priority - 256;
- switch (skb->protocol) {
- case htons(ETH_P_IP):
+
+ if (skb->protocol == htons(ETH_P_IP)) {
dscp = ip_hdr(skb)->tos & 0xfc;
- break;
- default:
- return 0;
+ return dscp >> 5;
}
- return dscp >> 5;
+
+ return 0;
}
static u16 rtw_select_queue(struct net_device *dev, struct sk_buff *skb,
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cfg80211: validate beacon interval for MESH/IBSS
On Thu, 2016-08-11 at 09:56 +, Kushwaha, Purushottam wrote: > Johannes , > While addressing this change, we could notice that the minimum > boundary for beacon interval for the case of IBSS is 1 but for Mesh > it is 10. Also this check is not done for AP/P2P GO . > Any reason why there is a discrepancy among them ? These > configurations should be aligned , I guess. > Shouldn't the minimum value be 10 ? If yes , the boundary check > should be moved to cfg80211_validate_beacon_int ? > Yeah, I've applied the patch and moved the range checks in as well. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving time
On Tue, 2016-07-19 at 08:36 -0400, Bob Copeland wrote:
> On Wed, Jul 13, 2016 at 02:45:25PM +0300, Yaniv Machani wrote:
> >
> > When a packet is received for transmission,
> > a PREQ frame is sent to resolve the appropriate path to the desired
> > destination.
> > After path was established, any sequential PREQ will be sent only
> > after
> > dot11MeshHWMPpreqMinInterval, which usually set to few seconds.
> >
> > This implementation has an impact in cases where we would like to
> > resolve the path quickly.
> > A clear example is when a peer was disconnected from us,
> > while he acted as a hop to our destination.
> > Although the path table will be cleared, the next PREQ frame will
> > be sent only after reaching the MinInterval.
> > This will cause unwanted delay, possibly of few seconds until the
> > traffic will resume.
> >
> > if (!(mpath->flags & MESH_PATH_RESOLVING))
> > - mesh_queue_preq(mpath, PREQ_Q_F_START);
> > + mesh_queue_preq(mpath, PREQ_Q_F_START, true);
>
> What about something like this here instead:
>
> if (!(mpath->flags & MESH_PATH_RESOLVING)) {
> /* force next preq to be sent without delay */
> ifmsh->last_preq = jiffies - min_preq_int_jiff(sdata) - 1;
> mesh_queue_preq(mpath, PREQ_Q_F_START);
> }
>
Yaniv, did you disagree with this for some strong reason, or were you
going to resend?
Having a smaller patch seems nicer too.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ath9k: disable RNG by default
On Thu, Aug 11, 2016 at 10:54:11AM +0800, miaoq...@codeaurora.org wrote: > On 2016-08-10 21:24, Jason Cooper wrote: > >The fact is, barring userspace expectations of /dev/hwrng, hw_random is > >the appropriate place for it. It's not a devicetree blob, mac address, > >or pci config space. Which are things we feed in once for the heck of > >it. This is a *continuous* source or questionable quality. > > > >I'm seriously considering putting this and timeriomem-rng into a > >subdirectory under hw_random/, maybe environ/. Anything in there gets > >quality=0 for default, and *doesn't* contribute to /dev/hwrng. > > > >Regardless which path we take, I think we should include 'adc' in the > >name. I've heard countless times about "Atheros cards come with an rng > >on board". :-/ > > If I understand correctly, you want to bind the ADC source to > /dev/hwrng, and then change rng-tools to set the entropy to zero in > the ioctl call ? There are two major problems with that approach, Nope. I want to leverage the hwrng framework to facilitate feeding the *kernel* entropy pools like all the other hwrngs do currently. The difference for *environmental* sources is that when userspace read()s from /dev/hwrng, they will *not* contribute. If the environmental sources are the only sources, then no /dev/hwrng should appear. > 1) We already tried once before to bind our solution to /dev/hwrng, > and got so much complaints. The conclusion was that maybe we know that > the output of /dev/hwrng does not have perfect entropy, but a normal > user does not know and will misuse it. You mentioned in > https://www.kernel.org/doc/Documentation/hw_random.txt we have > > "This data is NOT CHECKED by any > fitness tests, and could potentially be bogus (if the > hardware is faulty or has been tampered with). Data is only > output if the hardware "has-data" flag is set, but nevertheless > a security-conscious person would run fitness tests on the > data before assuming it is truly random." > > But this is not enough to convince upstream to switch to /dev/hwrng. > I think the concern of users misusing the solution is a very valid > concern. Agreed. > 2) If we set the entropy to zero in rng-tools, we cannot tolerate the > load. Rng-tools is not a timer-based solution. Similar to our > solution, it is based on > /proc/sys/kernel/random/write_wakeup_threshold. If we do not increase > the entropy counter, rng-tools keep writing into the pool, and both > rng-tools and WiFi chip will be overloaded. That's why I propose a change to the hwrng framework to permit noise sources while not wiring them up to feed /dev/hwrng. timeriomem-rng should have the same problem ath9k-rng does. Basically, if it wasn't designed to be an rng, it shouldn't be wired up to /dev/hwrng. thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] cfg80211: Provision to allow the support for different beacon intervals
> +static bool diff_beacon_interval_supported(struct wiphy *wiphy, u16
> types,
> + u32 beacon_int)
> +{
> + const struct ieee80211_iface_combination *c;
> + u16 all_types;
> + int i, j;
> +
> + for (i = 0; i < wiphy->n_iface_combinations; i++) {
> + c = &wiphy->iface_combinations[i];
> +
> + if (!c->diff_beacon_int_gcd ||
> + (beacon_int % c->diff_beacon_int_gcd))
> + continue;
> +
> + all_types = 0;
> + for (j = 0; j < c->n_limits; j++)
> + all_types |= c->limits[j].types;
> +
> + if (all_types & types)
> + return true;
> + }
> +
> + return false;
> +}
This seems odd. Shouldn't it use cfg80211_iter_combinations()? Might
need some additional helper to understand which interface types are
used right now - seems we mostly moved that to mac80211, but for this
case it should probably stay in cfg80211? Or should it?
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] mac80211: mesh: set tx_info->hw_queue to the correct queue upon packet forwarding
On Mon, 2016-08-08 at 10:06 +0300, Yaniv Machani wrote: > From: Meirav Kama > > MP received data frames from another MP. Frames are forwarded > from Rx to Tx to be transmitted to a third MP. > Upon cloning the skb, the tx_info was zeroed, and the > hw_queue wasn't set correctly, causing frames to be > inserted to queue 0 (VOICE). If re-queue occurred for some > reason, frame will be inserted to correct queue 2 (BE). > In this case frames are now dequeued from 2 different queues and > sent out of order. Uh, sorry. I was so focused on the commit message and everything that I neglected to look into the code change ... :( > info->control.jiffies = jiffies; > + info->hw_queue = q; > This is incorrect. 'q' appears to be the AC here, so you need to set something like vif->hw_queue[q], afaict? Check out tx.c where this is set. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: Add protection to get_expected_throughput opcode
On Thu, 2016-08-11 at 13:38 +0300, Maxim Altshul wrote: > To protect the opcode we add a check for sta->uploaded. > Applied, with a reworded commit message - thanks johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] cfg80211: rdev-ops: remove callback check from rdev_set_coalesce()
On Wed, 2016-08-10 at 12:33 +0200, Arend van Spriel wrote: > The wrapper rdev_set_coalesce() checks whether the driver provides > the set_coalesce callback and returns -ENOTSUPP if not. However, this > check is already performed in nl80211_set_coalesce() resulting in > -EOPNOTSUPP. This patch removes check from rdev wrapper function. What's the point though? Presumably the compiler will optimise it out, and it seems safer to have it this way? Same for all patches in this series. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH] nl80211: Allow GET_INTERFACE dumps to be filtered
On Wed, 2016-08-03 at 17:02 -0500, Denis Kenzior wrote:
>
> +static int nl80211_dump_interface_parse(struct sk_buff *skb,
> + struct netlink_callback *cb,
> + int *filter_wiphy)
Wrong indentation :)
> static int nl80211_dump_interface(struct sk_buff *skb, struct
> netlink_callback *cb)
> {
> int wp_idx = 0;
> int if_idx = 0;
> int wp_start = cb->args[0];
> int if_start = cb->args[1];
> + int filter_wiphy = cb->args[2];
> struct cfg80211_registered_device *rdev;
> struct wireless_dev *wdev;
>
> + if (!wp_start && !if_start && !filter_wiphy) {
This seems incorrect - you're setting
> + int ret;
> +
> + filter_wiphy = -1;
> +
> + ret = nl80211_dump_interface_parse(skb, cb,
> &filter_wiphy);
it here, but it can take the value 0, so !filter_wiphy seems wrong?
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/3] Improve wireless netdev detection
On Wed, 2016-08-03 at 16:58 -0500, Denis Kenzior wrote: > The current mechanism to detect hot-plug / unplug of wireless devices > is > somewhat arcane. One has to listen to NEW_WIPHY/DEL_WIPHY events > over > nl80211 as well as RTM_NEWLINK / RTM_DELLINK events over rtnl, then > somehow find a correlation between these events. This involves > userspace > sending GET_INTERFACE or GET_WIPHY commands to the kernel, which > incurs > additional roundtrips. > Applied. I squashed 1/2 since it's kinda pointless to have a patch introducing infrastructure that's not used. I also made some minor cleanups - please check (both that it's right, and for next time) johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: Keep CoDel stats per txq, export them in debugfs.
Johannes Berg writes:
>> @@ -137,18 +137,20 @@ static int aqm_open(struct inode *inode, struct
>> file *file)
>> len += scnprintf(info->buf + len,
>> info->size - len,
>> "* vif\n"
>> - "ifname addr ac backlog-bytes backlog-
>> packets flows overlimit collisions tx-bytes tx-packets\n");
>> + "ifname addr ac backlog-bytes backlog-
>> packets flows drops marks overlimit collisions tx-bytes tx-
>> packets\n");
>
> It seems to me that you have to change the buffer length to take this
> into account?
Haven't run into issues with running out of buffer space in my testing.
But yeah, guess that could become an issue.
>> list_for_each_entry_rcu(sdata, &local->interfaces, list) {
>> txqi = to_txq_info(sdata->vif.txq);
>> len += scnprintf(info->buf + len, info->size - len,
>> - "%s %pM %u %u %u %u %u %u %u %u\n",
>> + "%s %pM %u %u %u %u %u %u %u %u %u
>> %u\n",
>> sdata->name,
>
> Why is it this way anyway? It'd seem nicer to move the content of this
> into the per-netdev subdirectories, and then it becomes a lot simpler
> code too (yes, at the expense of some userspace, but still)
Yeah, makes sense. Can do a larger reorg moving things into the
per-netdev and per-station directories instead.
>> txqi->txq.ac,
>> txqi->tin.backlog_bytes,
>> txqi->tin.backlog_packets,
>> txqi->tin.flows,
>> + txqi->cstats.drop_count,
>> + txqi->cstats.ecn_mark,
>> txqi->tin.overlimit,
>> txqi->tin.collisions,
>> txqi->tin.tx_bytes,
>
> Do you really want to add these in the middle? Seems that if you add
> them at the end, you at least have *some* way of keeping this working
> with older versions?
Well I though they should be logically grouped with overlimits, and was
counting on no one actually parsing these yet. Guess if the information
is moved that becomes moot.
Will re-send; thanks for the feedback :)
-Toke
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with mwifiex_pcie firmware activation
Hi
On Thu, Aug 11, 2016 at 10:21:58AM +, Amitkumar Karwar wrote:
> > -Original Message-
> > From: Stanislaw Gruszka [mailto:sgrus...@redhat.com]
> > Sent: Thursday, August 11, 2016 2:31 PM
> > To: Amitkumar Karwar
> > Cc: Nishant Sarmukadam; linux-wireless@vger.kernel.org
> > Subject: Re: Problems with mwifiex_pcie firmware activation
> >
> > On Thu, Jun 23, 2016 at 02:09:52PM +0200, Stanislaw Gruszka wrote:
> > > On Thu, Jun 16, 2016 at 01:53:15PM +0200, Stanislaw Gruszka wrote:
> > > > On Wed, Jun 15, 2016 at 01:47:53PM +, Amitkumar Karwar wrote:
> > > > > Could you please share complete dmesg log for failure and
> > successful cases?
> > > >
> > > > Dmesg from failure case is in attachment. I loose access to system
> > > > where device initalize, I'll provide missed dmesg when I get back
> > > > the access.
> > >
> > > Have the access now, dmesg is in attachment.
> >
> > Any news here ?
>
> Do you have below patch included? It increases poll count which may help in
> your case.
> https://patchwork.kernel.org/patch/7973951/
Yes, I have that patch.
To clarify the issue: reverting above patch seems to helps with the
problem. That what I basically did on first of my systems with mwifiex,
that did not work similarly like second one. However I did not revert
the patch but just comment out check_winner_status:
@@ -755,7 +755,7 @@ int mwifiex_dnld_fw(struct mwifiex_adapter *adapter,
}
/* check if we are the winner for downloading FW */
- if (adapter->if_ops.check_winner_status) {
+ if (false) {
adapter->winner = 0;
ret = adapter->if_ops.check_winner_status(adapter);
After running modified kernel once, the problem was gone on
unmodified kernel! I suppose that once new firmware was uploaded to
the device it somehow modify it (change it's internal firmware?) and make
check_winner_status() works correctly. This is strange, but I can not
find any other explanation and don't see any other changes in the
first system that makes mwifiex suddenly work.
I could be wrong, but I suppose somebody who use pre 4.6 kernel (without
the above patch committed as: 2fd5c6ed0b4fbf3c2d9314a24c82862ce5254d42
"mwifiex: firmware download enhancements") with new enough mwifiex
firmware, will not see the problem even after kernel update. But if
somebody install 4.6 or newer kernel on pristine hardware, the device
will not work.
Thanks
Stanislaw
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: Keep CoDel stats per txq, export them in debugfs.
> @@ -137,18 +137,20 @@ static int aqm_open(struct inode *inode, struct
> file *file)
> len += scnprintf(info->buf + len,
> info->size - len,
> "* vif\n"
> - "ifname addr ac backlog-bytes backlog-
> packets flows overlimit collisions tx-bytes tx-packets\n");
> + "ifname addr ac backlog-bytes backlog-
> packets flows drops marks overlimit collisions tx-bytes tx-
> packets\n");
It seems to me that you have to change the buffer length to take this
into account?
> list_for_each_entry_rcu(sdata, &local->interfaces, list) {
> txqi = to_txq_info(sdata->vif.txq);
> len += scnprintf(info->buf + len, info->size - len,
> - "%s %pM %u %u %u %u %u %u %u %u\n",
> + "%s %pM %u %u %u %u %u %u %u %u %u
> %u\n",
> sdata->name,
Why is it this way anyway? It'd seem nicer to move the content of this
into the per-netdev subdirectories, and then it becomes a lot simpler
code too (yes, at the expense of some userspace, but still)
> sdata->vif.addr,
This is also kinda pointless since it's easy to get elsewhere.
> txqi->txq.ac,
> txqi->tin.backlog_bytes,
> txqi->tin.backlog_packets,
> txqi->tin.flows,
> + txqi->cstats.drop_count,
> + txqi->cstats.ecn_mark,
> txqi->tin.overlimit,
> txqi->tin.collisions,
> txqi->tin.tx_bytes,
Do you really want to add these in the middle? Seems that if you add
them at the end, you at least have *some* way of keeping this working
with older versions?
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: remove skb header offset mangling in ieee80211_build_hdr
On Wed, 2016-07-13 at 11:00 +0200, Felix Fietkau wrote: > Since the code only touches the MAC headers, the offsets to the > network/transport headers remain the same throughout this function. > Remove pointless pieces of code that try to 'preserve' them. > Applied, thanks. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5] cfg80211: Provision to allow the support for different beacon intervals
This commit provides a mechanism for the host drivers to advertise the
support for different beacon intervals among the respective interface
combinations in a group, through diff_beacon_int_gcd (u32).
The configured BI for a specific interface must be a multiple of this
value and also the active beaconing interfaces (along with the current
one) must match with the interface combinations in a group that advertise
the support for different beacon interval.
Signed-off-by: Purushottam Kushwaha
---
include/net/cfg80211.h | 4
include/uapi/linux/nl80211.h | 8 ++--
net/wireless/core.h | 2 +-
net/wireless/nl80211.c | 13 ++---
net/wireless/util.c | 39 +--
5 files changed, 58 insertions(+), 8 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 9c23f4d3..a0c635a 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2939,6 +2939,8 @@ struct ieee80211_iface_limit {
* only in special cases.
* @radar_detect_widths: bitmap of channel widths supported for radar detection
* @radar_detect_regions: bitmap of regions supported for radar detection
+ * @diff_beacon_int_gcd: This interface combination supports different beacon
+ * intervals in multiple of GCD value.
*
* With this structure the driver can describe which interface
* combinations it supports concurrently.
@@ -2970,6 +2972,7 @@ struct ieee80211_iface_limit {
* .n_limits = ARRAY_SIZE(limits2),
* .max_interfaces = 8,
* .num_different_channels = 1,
+ * .diff_beacon_int_gcd = 100,
* };
*
*
@@ -2997,6 +3000,7 @@ struct ieee80211_iface_combination {
bool beacon_int_infra_match;
u8 radar_detect_widths;
u8 radar_detect_regions;
+ u32 diff_beacon_int_gcd;
};
struct ieee80211_txrx_stypes {
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 2206941..369e403 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -4203,6 +4203,9 @@ enum nl80211_iface_limit_attrs {
* of supported channel widths for radar detection.
* @NL80211_IFACE_COMB_RADAR_DETECT_REGIONS: u32 attribute containing the
bitmap
* of supported regulatory regions for radar detection.
+ * @NL80211_IFACE_COMB_DIFF_BI_GCD: u32 attribute specifying the GCD of
+ * different beacon intervals supported by all the interface combinations
+ * in this group (not present if all beacon interval must match).
* @NUM_NL80211_IFACE_COMB: number of attributes
* @MAX_NL80211_IFACE_COMB: highest attribute number
*
@@ -4210,8 +4213,8 @@ enum nl80211_iface_limit_attrs {
* limits = [ #{STA} <= 1, #{AP} <= 1 ], matching BI, channels = 1, max = 2
* => allows an AP and a STA that must match BIs
*
- * numbers = [ #{AP, P2P-GO} <= 8 ], channels = 1, max = 8
- * => allows 8 of AP/GO
+ * numbers = [ #{AP, P2P-GO} <= 8 ], diff BI gcd, channels = 1, max = 8,
+ * => allows 8 of AP/GO that can beacon at multiple of gcd intervals
*
* numbers = [ #{STA} <= 2 ], channels = 2, max = 2
* => allows two STAs on different channels
@@ -4237,6 +4240,7 @@ enum nl80211_if_combination_attrs {
NL80211_IFACE_COMB_NUM_CHANNELS,
NL80211_IFACE_COMB_RADAR_DETECT_WIDTHS,
NL80211_IFACE_COMB_RADAR_DETECT_REGIONS,
+ NL80211_IFACE_COMB_DIFF_BI_GCD,
/* keep last */
NUM_NL80211_IFACE_COMB,
diff --git a/net/wireless/core.h b/net/wireless/core.h
index eee9144..5fffe58 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -475,7 +475,7 @@ int ieee80211_get_ratemask(struct ieee80211_supported_band
*sband,
u32 *mask);
int cfg80211_validate_beacon_int(struct cfg80211_registered_device *rdev,
-u32 beacon_int);
+enum nl80211_iftype iftype, u32 beacon_int);
void cfg80211_update_iface_num(struct cfg80211_registered_device *rdev,
enum nl80211_iftype iftype, int num);
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index ddb1469..d3b757d 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1020,6 +1020,10 @@ static int nl80211_put_iface_combinations(struct wiphy
*wiphy,
nla_put_u32(msg, NL80211_IFACE_COMB_RADAR_DETECT_REGIONS,
c->radar_detect_regions)))
goto nla_put_failure;
+ if (c->diff_beacon_int_gcd &&
+ nla_put_u32(msg, NL80211_IFACE_COMB_DIFF_BI_GCD,
+ c->diff_beacon_int_gcd))
+ goto nla_put_failure;
nla_nest_end(msg, nl_combi);
}
@@ -3454,7 +3458,8 @@ static int nl80211_start_ap(struct sk_buff *skb, struct
genl_info *info)
params.dtim_period =
nla_get_u32(info->attrs[NL80211_ATTR_DTIM_PERIOD]);
- err = cfg80211_va
RE: mwifiex: PCIe8997 chip specific handling
Hi Steve, > From: Steve deRosier [mailto:deros...@gmail.com] > Sent: Thursday, August 11, 2016 2:39 AM > To: Amitkumar Karwar > Cc: Brian Norris; linux-wireless@vger.kernel.org; Cathy Luo; Nishant > Sarmukadam; linux-ker...@vger.kernel.org; Wei-Ning Huang > Subject: Re: mwifiex: PCIe8997 chip specific handling > > Hi, > > On Wed, Aug 10, 2016 at 12:07 AM, Amitkumar Karwar > wrote: > > Hi Brian, > > > >> From: Brian Norris [mailto:briannor...@chromium.org] > >> Sent: Wednesday, August 10, 2016 12:14 AM > >> To: Amitkumar Karwar > >> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam; > >> linux-ker...@vger.kernel.org > >> Subject: Re: mwifiex: PCIe8997 chip specific handling > >> > >> Hi, > >> > >> On Fri, Jul 29, 2016 at 04:08:51PM +0530, Amitkumar Karwar wrote: > >> > The patch corrects the revision id register and uses it along with > >> > magic value and chip version registers to download appropriate > >> > firmware image. > >> > > >> > PCIe8997 Z chipset variant code has been removed, as it won't be > >> > used in production. > >> > > >> > Signed-off-by: Amitkumar Karwar > >> > --- > >> > drivers/net/wireless/marvell/mwifiex/pcie.c | 35 > >> > ++--- > >> > drivers/net/wireless/marvell/mwifiex/pcie.h | 14 +--- > >> > 2 files changed, 18 insertions(+), 31 deletions(-) > >> > >> [...] > >> > >> > diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.h > >> > b/drivers/net/wireless/marvell/mwifiex/pcie.h > >> > index f6992f0..46f99ca 100644 > >> > --- a/drivers/net/wireless/marvell/mwifiex/pcie.h > >> > +++ b/drivers/net/wireless/marvell/mwifiex/pcie.h > >> > @@ -32,12 +32,9 @@ > >> > #define PCIE8897_DEFAULT_FW_NAME "mrvl/pcie8897_uapsta.bin" > >> > #define PCIE8897_A0_FW_NAME "mrvl/pcie8897_uapsta_a0.bin" > >> > #define PCIE8897_B0_FW_NAME "mrvl/pcie8897_uapsta.bin" > >> > -#define PCIE8997_DEFAULT_FW_NAME "mrvl/pcieusb8997_combo_v2.bin" > >> > -#define PCIEUART8997_FW_NAME_Z "mrvl/pcieuart8997_combo.bin" > >> > -#define PCIEUART8997_FW_NAME_V2 "mrvl/pcieuart8997_combo_v2.bin" > >> > -#define PCIEUSB8997_FW_NAME_Z "mrvl/pcieusb8997_combo.bin" > >> > -#define PCIEUSB8997_FW_NAME_V2 "mrvl/pcieusb8997_combo_v2.bin" > >> > -#define PCIE8997_DEFAULT_WIFIFW_NAME "mrvl/pcie8997_wlan.bin" > >> > +#define PCIEUART8997_FW_NAME_V4 "mrvl/pcieuart8997_combo_v4.bin" > >> > +#define PCIEUSB8997_FW_NAME_V4 "mrvl/pcieusb8997_combo_v4.bin" > >> > +#define PCIE8997_DEFAULT_WIFIFW_NAME "mrvl/pcie8997_wlan_v4.bin" > >> > >> Why do version bumps require firmware renames? Is this just to make > >> sure you don't load the new firmware on old chip revs that you don't > >> plan to support for production (i.e., only early revs like the _Z > >> you're dropping)? This doesn't seems like a good long-term solution, > >> at least once you start getting this silicon out in the wild. At some > >> point, I'd expect to see a stable file name. > >> > >> Brian > >> > > > > We haven't yet submitted any firmware image upstream for 8997 chipset. > > pcieuart8997_combo_v4.bin/pcieusb8997_combo_v4.bin would be our > firmware candidate for upstream submission. The filename would remain > same hereafter. > > > > pcie*8997_combo_v2.bin had support only for A0 chipset > > pcie*8997_combo_v3.bin was our internal development version which had > > support for A1 chipset pcie*8997_combo_v4.bin has support for both A0 > and A1 chipsets and this is the version that shall be released to > customers/upstream from now on. > > > > Seems to me then it should just be named pcie*8997_wlan.bin. A version > number shouldn't be part of the file name in this case. Having to update > the driver for a firmware name change is silly. Most wireless drivers > have different names for different hardware/chip revs and/or an > incompatible API change. Most distributions would typically only carry > a single instance of the firmware for a particular chip. > Speaking for the ones I work with, I usually keep the original filename > intact (with a version number) and make a symlink to it with the name > the driver expects. eg: > > fw-4.bin -> fw_v3.4.0.94.bin > fw_v3.2.0.144.bin > fw_v3.4.0.94.bin > > That way I can keep track of the version in my filesystem, but I'm not > hacking the driver every couple of weeks. And we do issue new firmware > every few weeks. I can't imagine asking our customers to keep updating > the driver for each firmware enhancement. > > IMHO changing the driver to rename the firmwares on new versions seems > both inconvenient to people using it, and extra non-useful commit noise. > Thanks. I agree with you. We have also maintained single instance/name for all our chipsets for last few years. We do release new firmware periodically for these chipsets, but firmware name always remains the same. root@pe-lt949:/linux-firmware/mrvl# ls pcie8897_uapsta.bin sd8688_helper.bin sd8797_uapsta.bin sd8897_uapsta.bin usb8797_uapsta.bin sd8688.bin sd8787_uapsta.bin sd8887_ua
RE: Problems with mwifiex_pcie firmware activation
Hi Stanislaw, > -Original Message- > From: Stanislaw Gruszka [mailto:sgrus...@redhat.com] > Sent: Thursday, August 11, 2016 2:31 PM > To: Amitkumar Karwar > Cc: Nishant Sarmukadam; linux-wireless@vger.kernel.org > Subject: Re: Problems with mwifiex_pcie firmware activation > > On Thu, Jun 23, 2016 at 02:09:52PM +0200, Stanislaw Gruszka wrote: > > On Thu, Jun 16, 2016 at 01:53:15PM +0200, Stanislaw Gruszka wrote: > > > On Wed, Jun 15, 2016 at 01:47:53PM +, Amitkumar Karwar wrote: > > > > Could you please share complete dmesg log for failure and > successful cases? > > > > > > Dmesg from failure case is in attachment. I loose access to system > > > where device initalize, I'll provide missed dmesg when I get back > > > the access. > > > > Have the access now, dmesg is in attachment. > > Any news here ? Do you have below patch included? It increases poll count which may help in your case. https://patchwork.kernel.org/patch/7973951/ Regards, Amitkumar -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mac80211: Add protection to get_expected_throughput opcode
To protect the opcode we add a check for sta->uploaded.
This is done to prevent a situation where the function gets
called from userspace for example, before sta is uploaded
to driver, causing a crash.
Also, change headers to comply with the change, wherever the
function was called.
Signed-off-by: Maxim Altshul
---
net/mac80211/driver-ops.h | 8
net/mac80211/sta_info.c | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index 1f75195..ec4a690 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -1075,13 +1075,13 @@ static inline void drv_leave_ibss(struct
ieee80211_local *local,
}
static inline u32 drv_get_expected_throughput(struct ieee80211_local *local,
- struct ieee80211_sta *sta)
+ struct sta_info *sta)
{
u32 ret = 0;
- trace_drv_get_expected_throughput(sta);
- if (local->ops->get_expected_throughput)
- ret = local->ops->get_expected_throughput(&local->hw, sta);
+ trace_drv_get_expected_throughput(&sta->sta);
+ if (local->ops->get_expected_throughput && sta->uploaded)
+ ret = local->ops->get_expected_throughput(&local->hw,
&sta->sta);
trace_drv_return_u32(local, ret);
return ret;
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 8860c6c..6624577 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -2108,7 +2108,7 @@ u32 sta_get_expected_throughput(struct sta_info *sta)
if (ref && ref->ops->get_expected_throughput)
thr = ref->ops->get_expected_throughput(sta->rate_ctrl_priv);
else
- thr = drv_get_expected_throughput(local, &sta->sta);
+ thr = drv_get_expected_throughput(local, sta);
return thr;
}
--
2.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add protection to get_expected_throughput opcode
The patch is done with respect to the patch that was applied: [PATCH v3] mac80211: mesh: Add support for HW RC implementation 1. Patch adds protection as we discussed 2. Patch changes the function call that is made in the mesh patch to comply with the change. Maxim Altshul (1): mac80211: Add protection to get_expected_throughput opcode net/mac80211/driver-ops.h | 8 net/mac80211/sta_info.c | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) -- 2.9.0 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] cfg80211: validate beacon interval for MESH/IBSS
Johannes ,
While addressing this change, we could notice that the minimum boundary for
beacon interval for the case of IBSS is 1 but for Mesh it is 10. Also this
check is not done for AP/P2P GO .
Any reason why there is a discrepancy among them ? These configurations should
be aligned , I guess.
Shouldn't the minimum value be 10 ? If yes , the boundary check should be moved
to cfg80211_validate_beacon_int ?
Thanks,
Purushottam
-Original Message-
From: Kushwaha, Purushottam
Sent: Thursday, August 11, 2016 3:14 PM
To: johan...@sipsolutions.net
Cc: linux-wireless@vger.kernel.org; Malinen, Jouni ;
Undekari, Sunil Dutt ; Kalikot Veetil, Mahesh Kumar
; Hullur Subramanyam, Amarnath
; Kumar, Deepak (QCA) ;
Kushwaha, Purushottam
Subject: [PATCH] cfg80211: validate beacon interval for MESH/IBSS
Beacon interval validation was missing for MESH / IBSS join.
This commit addresses the same.
Signed-off-by: Purushottam Kushwaha
---
net/wireless/nl80211.c | 8
1 file changed, 8 insertions(+)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c index
f02653a..ddb1469 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -7780,6 +7780,10 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct
genl_info *info)
return -EINVAL;
}
+ err = cfg80211_validate_beacon_int(rdev, ibss.beacon_interval);
+ if (err)
+ return err;
+
if (!rdev->ops->join_ibss)
return -EOPNOTSUPP;
@@ -9255,6 +9259,10 @@ static int nl80211_join_mesh(struct sk_buff *skb, struct
genl_info *info)
if (setup.beacon_interval < 10 ||
setup.beacon_interval > 1)
return -EINVAL;
+
+ err = cfg80211_validate_beacon_int(rdev, setup.beacon_interval);
+ if (err)
+ return err;
}
if (info->attrs[NL80211_ATTR_DTIM_PERIOD]) {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cfg80211: validate beacon interval for MESH/IBSS
Beacon interval validation was missing for MESH / IBSS join.
This commit addresses the same.
Signed-off-by: Purushottam Kushwaha
---
net/wireless/nl80211.c | 8
1 file changed, 8 insertions(+)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index f02653a..ddb1469 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -7780,6 +7780,10 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct
genl_info *info)
return -EINVAL;
}
+ err = cfg80211_validate_beacon_int(rdev, ibss.beacon_interval);
+ if (err)
+ return err;
+
if (!rdev->ops->join_ibss)
return -EOPNOTSUPP;
@@ -9255,6 +9259,10 @@ static int nl80211_join_mesh(struct sk_buff *skb, struct
genl_info *info)
if (setup.beacon_interval < 10 ||
setup.beacon_interval > 1)
return -EINVAL;
+
+ err = cfg80211_validate_beacon_int(rdev, setup.beacon_interval);
+ if (err)
+ return err;
}
if (info->attrs[NL80211_ATTR_DTIM_PERIOD]) {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with mwifiex_pcie firmware activation
On Thu, Jun 23, 2016 at 02:09:52PM +0200, Stanislaw Gruszka wrote: > On Thu, Jun 16, 2016 at 01:53:15PM +0200, Stanislaw Gruszka wrote: > > On Wed, Jun 15, 2016 at 01:47:53PM +, Amitkumar Karwar wrote: > > > Could you please share complete dmesg log for failure and successful > > > cases? > > > > Dmesg from failure case is in attachment. I loose access to system > > where device initalize, I'll provide missed dmesg when I get back > > the access. > > Have the access now, dmesg is in attachment. Any news here ? Stanislaw -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] mac80211: mesh: Add support for HW RC implementation
On Mon, 2016-07-11 at 17:15 +0300, Maxim Altshul wrote: > Mesh HWMP module will be able to rely on the HW > RC algorithm if it exists, for path metric calculations. > > This allows the metric calculation mechanism to calculate > a correct metric, based on PER and last TX rate both via > HW RC algorithm if it exists or via parameters collected > by the SW. > Applied. I decided to put the fix for the sta->uploaded thing into mac80211-next, since there's no driver affected by it now, so please base that patch on this one, if necessary. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pull-request: mac80211 2016-08-05
On Fri, 2016-08-05 at 14:32 +0200, Johannes Berg wrote: > Hi Dave, > > Here's a first set of fixes for the current cycle. See the tag > message > for more information. > > I'll probably have a follow-up fix for the real problem in mac80211 > that caused the crash later, but for now we have this patch and it > makes sense and fixes the crash, even if the behaviour isn't quite > right (afaict.) > Just FYI, I'm going to "defer" the fix for the wrong behaviour to mac80211-next since no driver is affected by it. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
