On Thu, 2014-12-18 at 21:42 +0100, Arend van Spriel wrote:
> + u8 ext_features[(NUM_NL80211_EXT_FEATURES / 8) + 1];
Should probably use DIV_ROUND_UP() here.
> +static inline bool
> +wiphy_ext_feature_isset(struct wiphy *wiphy,
> + enum nl80211_ext_feature_index ftidx)
> +
On 12/19/14 10:18, Johannes Berg wrote:
On Thu, 2014-12-18 at 21:42 +0100, Arend van Spriel wrote:
+ u8 ext_features[(NUM_NL80211_EXT_FEATURES / 8) + 1];
Should probably use DIV_ROUND_UP() here.
Will do.
+static inline bool
+wiphy_ext_feature_isset(struct wiphy *wiphy,
+
Hi,
is the code open? From where could I clone it?
Cheers
--
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
On 12/19/14 10:43, Arend van Spriel wrote:
On 12/19/14 10:18, Johannes Berg wrote:
On Thu, 2014-12-18 at 21:42 +0100, Arend van Spriel wrote:
+u8 ext_features[(NUM_NL80211_EXT_FEATURES / 8) + 1];
Should probably use DIV_ROUND_UP() here.
Will do.
Looking at this again I wonder if it w
On Fri, 2014-12-19 at 10:59 +0100, Arend van Spriel wrote:
> Looking at this again I wonder if it would be of value to have this as
> NL80211_EXT_FEATURES_ATTR_LEN in nl80211.h so user-space can check the
> nla_len() against it and detect API in-compatibility. Just can not use
> DIV_ROUND_UP()
On 12/19/14 11:05, Johannes Berg wrote:
On Fri, 2014-12-19 at 10:59 +0100, Arend van Spriel wrote:
Looking at this again I wonder if it would be of value to have this as
NL80211_EXT_FEATURES_ATTR_LEN in nl80211.h so user-space can check the
nla_len() against it and detect API in-compatibility.
> + * @rx_qos_msdu: QoS-MSDUs received from this station (per TID)
> + * @rx_nonqos_msdu: non-QoS-MSDUs received from this station
> + * @tx_qos_msdu: QoS-MSDUs sent to this station (per TID)
> + * @tx_nonqos_msdu: non-QoS-MSDUs sent to this station
Well, come to think of it, it looks like we'll
On 12/18/2014 05:21 PM, Helmut Schaa wrote:
> Hi,
>
> [...]
>
> So, every channel has a CAC time of 60 seconds.
>
> Checking version 1.7.2 of the ETSI regulation indicates that we might
> need some modifications to cfg80211:
>
> From [1] page 79:
>
> "NOTE 1: For channels whose nominal bandwid
On 19 December 2014 at 12:27, Zefir Kurtisi wrote:
> On 12/18/2014 05:21 PM, Helmut Schaa wrote:
>> Hi,
>>
>> [...]
>>
>> So, every channel has a CAC time of 60 seconds.
>>
>> Checking version 1.7.2 of the ETSI regulation indicates that we might
>> need some modifications to cfg80211:
>>
>> From [
On Fri, Dec 19, 2014 at 1:28 PM, Janusz Dziedzic
wrote:
> On 19 December 2014 at 12:27, Zefir Kurtisi wrote:
>> On 12/18/2014 05:21 PM, Helmut Schaa wrote:
>>> Hi,
>>>
>>> [...]
>>>
>>> So, every channel has a CAC time of 60 seconds.
>>>
>>> Checking version 1.7.2 of the ETSI regulation indicates
Hi Zefir,
On Fri, Dec 19, 2014 at 12:27 PM, Zefir Kurtisi
wrote:
> On 12/18/2014 05:21 PM, Helmut Schaa wrote:
>> Hi,
>>
>> [...]
>>
>> So, every channel has a CAC time of 60 seconds.
>>
>> Checking version 1.7.2 of the ETSI regulation indicates that we might
>> need some modifications to cfg8021
Bartosz Markowski writes:
> From: Michal Kazior
>
> This event is delivered to host by firmware if it
> supports beacon templates only.
>
> Signed-off-by: Michal Kazior
If you submit something, even written by someone else, you have to add
your Signed-off-by line. Otherwise I cannot take these
Bartosz Markowski writes:
> From: Michal Kazior
>
> New firmware revisions support beacon and probe
> response templates instead. This means SWBA events
> are no longer delivered for these firmware
> revisions.
>
> Signed-off-by: Michal Kazior
[...]
> + ret = ath10k_mac_setup_bcn_p2p_ie(a
On 12/19/2014 02:19 PM, Helmut Schaa wrote:
> Hi Zefir,
>
> On Fri, Dec 19, 2014 at 12:27 PM, Zefir Kurtisi
> wrote:
>>
>> Hello Helmut,
>>
>> just forget about those aka 'weather channels' that require a pracitcally
>> impossible to achieve radar detection probability rate (99.99% during CAC,
>
From: Johannes Berg
The base for the current statistics is pretty mixed up, support
exporting RX/TX statistics for MSDUs per TID. This (currently)
covers received MSDUs, transmitted MSDUs and retries/failures
thereof.
Doing it per TID for MSDUs makes more sense than say only per AC
because it's
From: Johannes Berg
Implement the new counters cfg80211 can now advertise to userspace.
The TX code is in the sequence number handler, which is a bit odd,
but that place already knows the TID and frame type, so it was
easiest and least impact there.
Change-Id: Iccc7774119092a5497c6ea98ea9a570661
From: Johannes Berg
Per-rate/per-station statistics can be desirable to have but they're
quite expensive (keeping the four counters for each rate would take
close to 4k of memory per station only for VHT MCSes for a moderately
capable VHT chip (with 2 spatial streams and 80MHz support) so it's
no
On Wed, 2014-12-17 at 13:38 +0100, Felix Fietkau wrote:
> On minstrel_ht, the size of the per-sta struct is almost 18k, making it
> an order-3 allocation.
> A few fields inside the per-rate statistics are bigger than they need to
> be. This patch reduces the size enough to cut down the per-sta stru
Hello
I am seeing this error message quite often in syslog. Was wondering if
it is something I can fix. Not sure if related, but the laptop drops
off the established wifi at this location (that problem happens ever
few days).
Could the -33 be replaced with an error string? I wonder what -33 is,
p
19 matches
Mail list logo
