This patch adds functions to enable/disable tdls
and to configure tdls peer station for tlv based firmware.
Tdls peer uapsd and tdls channel switching are not supported.
Transmitting tdls data frames works only for ethernet
type frames, that's why data addressed to tdls sta
is in ethernet format.
Currently when TDLS station in driver goes from assoc
to authorized state it can not use rate control parameters
because rate control is not initialized yet. Some drivers
require parameters already initialized by rate control when
entering authorized state. It can be done by initializing
rate contr
From: Michal Kazior
There are a few different tx paths depending on
firmware and frame itself.
Creating a uniform decision will make it possible
to switch between different txmode easier, both
for testing and for future features as well.
Signed-off-by: Michal Kazior
Signed-off-by: Marek Puzyni
Peer type was hardcoded to default value.
For future implementation it is required
to make is configurable.
Signed-off-by: Marek Puzyniak
Signed-off-by: Marek Kwaczynski
---
drivers/net/wireless/ath/ath10k/mac.c | 17 +++--
drivers/net/wireless/ath/ath10k/wmi-ops.h | 8 +---
This patchset introduces tdls funtionality without tdls peer uapsd
and tdls channel switching. Tdls is supported by qca6174 hardware
what is indicated by firmware through supported services.
Tdls station when authorized requires some parameters that are filled in
by rate control initialization. Bec
On Wed, 2015-02-25 at 09:07 +0200, Vladimir Kondratiev wrote:
> On Monday, February 23, 2015 09:35:39 AM Johannes Berg wrote:
> > If the SKB has pages (rather than being linear, as
> > ieee80211_amsdu_to_8023s() assumes) then what Emmanuel said would
> > probably be the best approach, although it c
On Monday, February 23, 2015 09:35:39 AM Johannes Berg wrote:
> If the SKB has pages (rather than being linear, as
> ieee80211_amsdu_to_8023s() assumes) then what Emmanuel said would
> probably be the best approach, although it could be possible that would
> mess up truesize accounting and lead to
On 2015-02-25 07:14, Jouni Malinen wrote:
> On Tue, Feb 24, 2015 at 06:54:47PM +0100, Thomas Hühn wrote:
>> Currently Minstrel_HT just skips EAPOL packets for its rate sampling on
>> non-mrr chips by testing: (info->control.flags &
>> IEEE80211_TX_CTRL_PORT_CTRL_PROTO)
>
> Yeah, I noticed that w
On 6 February 2015 at 18:29, Jakub Kiciński wrote:
> Hello everyone!
>
> I put together a mac80211 driver for Mediatek MT7601U. It's partially
> based on Felix's mt76, but I'm not sure if it will make sense to merge
> the two together. MT7601U is a pretty old 1x1 bgn chip for USB dongles
> and m
2015-02-25 5:08 GMT+09:00 Johannes Berg :
> Applied, I've reworded and rewrapped the commit log - in the future
> please send commit logs with at most 72 characters per line.
Thanks. I will remember 72 characters rule.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
Hi,
I thought about doing this for rate probing with FreeBSD's sample rate
algorithm, but after actually having to use the damned thing in noisy
environments I realised that it just wasn't worth the effort to
optimise rate control selection whilst doing EAPOL frames.
If we did more useful softwar
Hi Jouni,
> Where is that mrr[3] part implemented? I did not find it when reviewing
> the design (hw->max_rates >= 3 is used, but not >= 4) and this does not
> match my experiments either when printing out all four values from
> ath9k. In every single case I observed, the last entry was unused (id
On Tue, Feb 24, 2015 at 07:49:37PM +, Grumbach, Emmanuel wrote:
> On Tue, 2015-02-24 at 12:49 -0500, Kyle McMartin wrote:
> > On Fri, Feb 06, 2015 at 09:31:52AM +, Grumbach, Emmanuel wrote:
> > > On Fri, 2015-02-06 at 04:15 -0500, Kyle McMartin wrote:
> > > > On Tue, Feb 03, 2015 at 09:39:2
On Wed, Feb 25, 2015 at 2:17 AM, Johannes Berg
wrote:
> On Wed, 2015-02-25 at 02:03 +0530, Krishna Chaitanya wrote:
>
>> Use case2: When changing from HT40-VHT80, the connection goes through
>> but it still connected as HT40 (vht_ie from cfg80211 is returned
>> null).
>>
>> Can you think of any re
On Wed, 2015-02-25 at 02:03 +0530, Krishna Chaitanya wrote:
> Use case2: When changing from HT40-VHT80, the connection goes through
> but it still connected as HT40 (vht_ie from cfg80211 is returned
> null).
>
> Can you think of any reason why the bss_list is not updated cfg80211?
> Note: iwconfi
On Tue, Feb 24, 2015 at 4:59 PM, Krishna Chaitanya
wrote:
> On Tue, Feb 24, 2015 at 4:05 PM, Johannes Berg
> wrote:
>> On Tue, 2015-02-24 at 15:58 +0530, Krishna Chaitanya wrote:
>>
>>> STA (mac80211) connects to AP in VHT-80.
>>> AP is reconfigured to 11n40 (stops beaconing for about 30secs and
-linux-kernel, +linux-wireless.
Look sane, applied. Please send to linux-wireless in the future so
patches don't get lost. There's even a script for that ... :)
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel
On Tue, 2015-02-24 at 22:42 +0900, Masashi Honma wrote:
> Both wpa_supplicant and mac80211 has inactivity timer. By default
> wpa_supplicant will be timed out in 5 minutes and mac80211's it is 30 minutes.
> If wpa_supplicant uses more long timer than mac80211, wpa_supplicant will get
> unexpected d
On Mon, 2015-02-23 at 23:38 +0800, Rohan Joyce wrote:
> Hi,
>
> The motivation for this patch is to assist using a WiiU Gamepad with Linux.
> The WiiU Gamepad is an input device that also contains an LCD touchscreen,
> speakers and a variety of sensors. The Gamepad connects to an access
> point (
On Tue, 2015-02-24 at 08:39 -0500, Bob Copeland wrote:
> Due to the checks in get_hwsim_data_ref_from_addr, wmediumd
> was only able to use the second mac address (those starting with
> 0x42). This is confusing and needlessly limiting, so allow any
> configured address.
Applied.
johannes
--
To
On Tue, 2015-02-24 at 12:49 -0500, Kyle McMartin wrote:
> On Fri, Feb 06, 2015 at 09:31:52AM +, Grumbach, Emmanuel wrote:
> > On Fri, 2015-02-06 at 04:15 -0500, Kyle McMartin wrote:
> > > On Tue, Feb 03, 2015 at 09:39:28PM +, Grumbach, Emmanuel wrote:
> > > > Hi,
> > > >
> > > > This is a
When using the wext compatibility code in cfg80211, part of the IEs
can be truncated if the passed user buffer is large enough for the
BSS but not large enough for all of the IEs. This can cause an EAP
network to show up as a PSK network.
These changes allow the scan to always return -E2BIG in th
On Tue, Feb 24, 2015 at 06:54:47PM +0100, Thomas Hühn wrote:
> Currently Minstrel_HT just skips EAPOL packets for its rate sampling on
> non-mrr chips by testing: (info->control.flags &
> IEEE80211_TX_CTRL_PORT_CTRL_PROTO)
Yeah, I noticed that when going through the implementation, but it was
in
On 24 February 2015 at 18:53, Kyle McMartin wrote:
> On Mon, Feb 16, 2015 at 11:09:47PM +0100, Rafał Miłecki wrote:
>> It isn't supposed to be run on host obviously.
>>
>> Signed-off-by: Rafał Miłecki
>
> Ah, I was working backwards and Marcel sent a patch more recently which
> fixed this and a f
Hi Jouni,
Currently Minstrel_HT just skips EAPOL packets for its rate sampling on non-mrr
chips by testing: (info->control.flags & IEEE80211_TX_CTRL_PORT_CTRL_PROTO)
On mrr hardware it uses them for probing.
But the general MRR-chain should look like this for ath5k and ath9k chips that
support
On Mon, Feb 16, 2015 at 11:09:47PM +0100, Rafał Miłecki wrote:
> It isn't supposed to be run on host obviously.
>
> Signed-off-by: Rafał Miłecki
Ah, I was working backwards and Marcel sent a patch more recently which
fixed this and a few other files.
Sorry about that -- Kyle
> ---
> brcm/brcm
On Fri, Feb 06, 2015 at 09:31:52AM +, Grumbach, Emmanuel wrote:
> On Fri, 2015-02-06 at 04:15 -0500, Kyle McMartin wrote:
> > On Tue, Feb 03, 2015 at 09:39:28PM +, Grumbach, Emmanuel wrote:
> > > Hi,
> > >
> > > This is a pull request for new firmwares for the Intel wireless devices
> > >
On Tue, Feb 24, 2015 at 2:26 AM, Jouni Malinen wrote:
> On Tue, Feb 24, 2015 at 01:29:27PM +1100, Andrew McGregor wrote:
>> Over the weekend I found a bug in minstrel-ht that might well be
>> implicated here.
>>
>> The last retransmit rate is meant to be a 'get the packet there
>> reliably' rate;
On Tue, Feb 24, 2015 at 8:25 AM, Daniel Baluta wrote:
> On Tue, Feb 24, 2015 at 6:14 PM, Greg Rose wrote:
>> I'm excited - what's NFC?
>
>
> Please don't do top posting.
My apologies - my smartphone interface rather sucks sometimes.
>
> Other than that:
>
> http://en.wikipedia.org/wiki/Near_fie
On Tue, Feb 24, 2015 at 6:14 PM, Greg Rose wrote:
> I'm excited - what's NFC?
Please don't do top posting.
Other than that:
http://en.wikipedia.org/wiki/Near_field_communication
Daniel.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to ma
I'm excited - what's NFC?
- Greg
On Tue, Feb 24, 2015 at 2:01 AM, Robert Dolca wrote:
> This patch adds support for Intel's FieldsPeak NFC solution.
> The device is enumerated with ACPI and platform init.
>
> In order to implement the driver the nci_core_conn_create was
> modified in order to re
Routine rtl_is_special_data() is supposed to identify packets that need to
use a low bit rate so that the probability of successful transmission is
high. The current version has a bug that causes all IPv6 packets to be
labelled as special, with a corresponding low rate of transmission. A
complete f
On Tue, 2015-02-24 at 06:36 -0800, Ben Greear wrote:
> We could push more and more of this to user-space and let it decide whether
> and
> how to forward or accept frames for particular radios.
Sure, no objection to that. However, just arbitrarily adding a "change
channel" call, without thinking
On 02/24/2015 06:34 AM, Johannes Berg wrote:
On Tue, 2015-02-24 at 06:28 -0800, Ben Greear wrote:
If there is no status to return, then why would user-space call back at all?
Should user-space *always* return a status even when not requested to?
I'd certainly expect so from hwsim.
I expe
On 02/24/2015 02:11 AM, Johannes Berg wrote:
On Mon, 2015-02-23 at 09:43 -0800, Ben Greear wrote:
This seems a bit strange - don't we already tag packets with the
frequency? Why would you need the channel change separately? What does
that even mean? Depending on how you use this it could enti
On Tue, 2015-02-24 at 06:28 -0800, Ben Greear wrote:
> If there is no status to return, then why would user-space call back at all?
>
> Should user-space *always* return a status even when not requested to?
I'd certainly expect so from hwsim.
johannes
--
To unsubscribe from this list: send the
On 02/24/2015 02:14 AM, Johannes Berg wrote:
On Mon, 2015-02-23 at 09:38 -0800, Ben Greear wrote:
This doesn't really seem right - essentially it means that whatever you
just gave to userspace is now completely useless?
It seems skb_orphan() could/should be put here.
I don't understand you
Both wpa_supplicant and mac80211 has inactivity timer. By default
wpa_supplicant will be timed out in 5 minutes and mac80211's it is 30 minutes.
If wpa_supplicant uses more long timer than mac80211, wpa_supplicant will get
unexpected disconnection by mac80211. This patch adds functionality of disab
Due to the checks in get_hwsim_data_ref_from_addr, wmediumd
was only able to use the second mac address (those starting with
0x42). This is confusing and needlessly limiting, so allow any
configured address.
Signed-off-by: Bob Copeland
---
v2: use mac80211_hwsim_addr_match instead which checks
Hello all.
I'm working on 5 GHz band, Microtik R52n-M card and when forcing
bitrate, it doesn't work for .11n mode executing the following comands:
- iw dev wlan0 set noack_map 0x0009
- iw dev wlan0 set bitrates ht-mcs-5 10
No error is thrown but PHY bitrate remains at 6.0 Mbit/s.
After that,
On Tue, Feb 24, 2015 at 4:05 PM, Johannes Berg
wrote:
> On Tue, 2015-02-24 at 15:58 +0530, Krishna Chaitanya wrote:
>
>> STA (mac80211) connects to AP in VHT-80.
>> AP is reconfigured to 11n40 (stops beaconing for about 30secs and then
>> starts again).
>> STA loses connection (HW_CONN_TRACK), iee
On Tue, 2015-02-24 at 11:30 +0100, Johannes Berg wrote:
> On Tue, 2015-02-24 at 11:24 +0100, Johannes Berg wrote:
> > On Thu, 2015-02-12 at 08:48 +0100, Michal Kazior wrote:
> >
> > > > Good point. I was actually thinking about it. I can try cooking a
> > > > patch unless you want to do it yoursel
On Wed, 2015-01-28 at 10:03 +0800, Junjie Mao wrote:
> nl80211_exit should be called in cfg80211_init if cfg80211_init succeeds but
> regulatory_init or create_singlethread_workqueue fails.
Applied, thanks.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
On Tue, Feb 24, 2015 at 11:33:10AM +0100, Johannes Berg wrote:
> > +config NFC_FDP
> > + tristate "Intel FDP NFC driver"
> > + depends on NFC_NCI
> > + select CRC_CCITT
> > + default n
> > + ---help---
> > + Intel FDP core driver.
> > + This is a driver based on the NCI NFC kernel
On Tue, 2015-02-24 at 15:58 +0530, Krishna Chaitanya wrote:
> STA (mac80211) connects to AP in VHT-80.
> AP is reconfigured to 11n40 (stops beaconing for about 30secs and then
> starts again).
> STA loses connection (HW_CONN_TRACK), iee80211_connection_loss is called.
> STA see's AP again and trie
I have no idea about NFC, but
> +config NFC_FDP
> + tristate "Intel FDP NFC driver"
> + depends on NFC_NCI
> + select CRC_CCITT
> + default n
> + ---help---
> + Intel FDP core driver.
> + This is a driver based on the NCI NFC kernel layers.
> +
> + To compile
On Tue, 2015-02-24 at 11:24 +0100, Johannes Berg wrote:
> On Thu, 2015-02-12 at 08:48 +0100, Michal Kazior wrote:
>
> > > Good point. I was actually thinking about it. I can try cooking a
> > > patch unless you want to do it yourself :-)
> >
> > I've taken a look into this. The most obvious place
On Tue, Feb 24, 2015 at 3:39 PM, Johannes Berg
wrote:
> On Fri, 2015-02-20 at 02:58 +0530, Krishna Chaitanya wrote:
>
>> Before that i have a basic question? Should we reset our tracking after
>> the connection is lost, in my case above the connection was lost (Config
>> change in A triggers a reb
On Tue, Feb 24, 2015 at 01:29:27PM +1100, Andrew McGregor wrote:
> Over the weekend I found a bug in minstrel-ht that might well be
> implicated here.
>
> The last retransmit rate is meant to be a 'get the packet there
> reliably' rate; minstrel-ht doesn't do that right, and can pick a
> fairly fl
On Thu, 2015-02-12 at 08:48 +0100, Michal Kazior wrote:
> > Good point. I was actually thinking about it. I can try cooking a
> > patch unless you want to do it yourself :-)
>
> I've taken a look into this. The most obvious place to add the
> timestamp for each packet would be ieee80211_tx_info (
On Mon, 2015-02-23 at 10:33 -0500, Bob Copeland wrote:
> Due to the checks in get_hwsim_data_ref_from_addr, wmediumd
> was only able to use the second mac address (those starting with
> 0x42). This is confusing and needlessly limiting, so allow any
> configured address.
>
> While at it, use ether
On Mon, 2015-02-23 at 09:38 -0800, Ben Greear wrote:
> > This doesn't really seem right - essentially it means that whatever you
> > just gave to userspace is now completely useless?
> >
> > It seems skb_orphan() could/should be put here.
>
> I don't understand your complaint, why is what I gave
On Mon, 2015-02-23 at 09:43 -0800, Ben Greear wrote:
> > This seems a bit strange - don't we already tag packets with the
> > frequency? Why would you need the channel change separately? What does
> > that even mean? Depending on how you use this it could entirely break
> > off-channel operation,
On Fri, 2015-02-20 at 02:58 +0530, Krishna Chaitanya wrote:
> Before that i have a basic question? Should we reset our tracking after
> the connection is lost, in my case above the connection was lost (Config
> change in A triggers a reboot), still mac80211 is tracking the BW changes?
Huh??
So t
On Fri, 2015-02-20 at 01:00 +0530, Krishna Chaitanya wrote:
> Hi Johannes,
>
> The BW tracking feature in mac80211 is causing connection problems and
> operating mode/bw problems when switching b/w modes and bw's in AP.
>
> For Eg. Initially if AP is operating in VHT-80MHz, and then we changed
>
This patch adds support for Intel's FieldsPeak NFC solution.
The device is enumerated with ACPI and platform init.
In order to implement the driver the nci_core_conn_create was
modified in order to report the ID of the newly created connection.
Fixed a bug that prevented to close a connection from
nci_send_cmd was exported in order to send commands to the device from
the driver. For the firmware update the driver may use nci_send_data.
Signed-off-by: Robert Dolca
---
net/nfc/nci/core.c | 1 +
net/nfc/nci/data.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/net/nfc/nci/core.c b/net
In order to communicate with the device during the setup
phase, the driver may need to initialize the device. After
the setup is done the driver should reset the device to leave
it in the same state that it was before the setup function
call.
Signed-off-by: Robert Dolca
---
include/net/nfc/nci_c
By calling __nci_request instead of nci_request allows the driver to use
the function while initializing the device (setup stage)
Signed-off-by: Robert Dolca
---
net/nfc/nci/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
index 9
If the previous nci_request (NCI reset) failed the setup function
was being called anyway. It shouldn't be called if the reset failed.
The result of the setup function is taken into consideration. If it
fails the init should fail.
Signed-off-by: Robert Dolca
---
net/nfc/nci/core.c | 4 ++--
1 f
nci_core_conn_create not has a new parameter so it can return
the ID of the new connection. Also not you can't call nci_core_conn_create
without waiting the answer for the previous call.
Signed-off-by: Robert Dolca
---
drivers/nfc/st21nfcb/st21nfcb_se.c | 2 +-
include/net/nfc/nci_core.h
This patch adds nci_request_driver and nci_req_complete_driver
as a wrapper for __nci_request. When nci_req_complete_driver is
called it also sets cmd_cnt to 1. This is done because the response is not
sent to the NFC subsystem so cmd_cnt is not decremented there.
nci_send_cmd was previously expor
I will re-send this message to ML because of delivery error.
-- Forwarded message --
From: Masashi Honma
Date: 2015-02-24 19:00 GMT+09:00
Subject: Re: [PATCH v4] mac80211: Allow 0 for
NL80211_MESHCONF_PLINK_TIMEOUT to disable STA expiration
To: Johannes Berg
Cc: "linux-wireless@v
FDP driver needs to send the firmware as regular packets
(not fragmented). That's whay the driver should have a way to
get the max packet size for a given connection.
Signed-off-by: Robert Dolca
---
include/net/nfc/nci_core.h | 1 +
net/nfc/nci/data.c | 12
2 files changed,
The device can be enumerated using ACPI using the id INT339A.
The 1st GPIO is the IRQ and the 2nd is the RESET pin.
I can be also enumerated using platform init.
Signed-off-by: Robert Dolca
---
drivers/nfc/Kconfig | 1 +
drivers/nfc/fdp/Kconfig | 22 ++
drivers/nfc/fdp
On Tue, 2015-02-17 at 16:10 -0800, Jason Abele wrote:
> From: Jason Abele
>
> There are currently 8 rules in the world_regdom, but only the first 6
> are applied due to an incorrect value for n_reg_rules. This causes
> channels 149-165 and 60GHz to be disabled.
Applied, thanks.
johannes
--
To
On Sat, 2015-02-14 at 20:52 +0100, Christian Engelmayer wrote:
> In case of NL80211_IFTYPE_MONITOR and flag MONITOR_FLAG_ACTIVE, the already
> allocated sk_buff 'msg' is not freed, when the function exits in case the
> feature is not supported. Detected by Coverity CID 1269116.
>
> Signed-off-by:
On Mon, 2015-02-09 at 18:19 +0200, Jouni Malinen wrote:
> This allows wpa_supplicant/hostapd to send a vendor command and verify
> response to that command and event.
I'm going to drop this since you're working on the wdev thing. That
might even help you with the first patch since you don't need t
On Mon, 2015-02-09 at 21:29 +0200, Luca Coelho wrote:
> From: Samuel Tan
>
> We currently add nested members of the NL80211_ATTR_SCAN_FREQUENCIES
> as NLA_U32 attributes of type NL80211_ATTR_WIPHY_FREQ in
> cfg80211_net_detect_results. However, since there can be an arbitrary number
> of
> frequ
On Sun, 2015-02-08 at 12:36 +0200, Eliad Peller wrote:
> If ieee80211_vif_use_channel() fails, we have to clear
> sdata->radar_required (which we might have just set).
>
> Failing to do it results in stale radar_required field
> which prevents starting new scan requests.
Applied, but I fixed it t
On Thu, 2015-02-05 at 08:45 -0500, Bob Copeland wrote:
> Correct two problems with the error handling when using the netlink
> forwarding API: first, the netlink skb is never freed if nla_put()
> fails; and second, genlmsg_unicast() can fail if the netlink socket
> is full. In the latter case, the
Hi,
Sorry about the late reply! I'm getting back to merging now and taking a
closer look at this issue.
> +++ b/net/wireless/nl80211.c
> @@ -5261,7 +5261,7 @@ do {
> \
> FILL_IN_MESH_PARAM_IF_SET(tb, cfg, dot11MeshAwake
> This means that this kernel change can't be pulled in without
> corresponding driver changes to call cfg80211_vendor_event_alloc()
> with a NULL for wdev. Please confirm if this is acceptable; otherwise,
> we would need to use the new wrapper defined above.
This is fine to me, there are very f
73 matches
Mail list logo