> But there is a per-descriptor TX rate table entry in the driver.
> FreeBSD uses it to implement its rate control for the intel drivers.
>
> What am I missing? :)
Not sure. But there isn't a per-descriptor table in the driver. There's
a per-station table, that *can* be used in similar ways, but
On Thu, 2016-10-27 at 09:54 +0200, Sebastian Gottschall wrote:
> all patches have a unclear license since most patches are not comming
> with any licence declaration ;-)
You should read the DCO some time. Maybe you shouldn't be sending
patches if you think so.
johannes
___
> The intel 7260 and later parts also allow user controllable rate
> control and provide transmit completion feedback, but I don't know
> whether it's enough for your needs.
Perhaps. However, existing rate control is *very* tightly coupled to
the driver, and it'd be fairly pointless to disentangl
On Mon, 2016-10-24 at 22:17 +0200, Björn Smedman wrote:
>
> Are there any cards out there that support VHT and use s/w rate
> control (Minstrel)? Just in case I run out of search space. :P
Maybe something that's usable with brcmsmac? Not sure I'd recommend
buying Broadcom NICs though at this poin
> 1. Is there anybody else out there thinking along similar lines?
I'm not aware, but that may not mean much :)
> 2. What would be the best hardware/software stack to base this work
> on?
>
> I'm thinking the best driver for rate control experimentation would
> be ath9k, right? If so then a TP-
> "The patch itself has (at least) one big problem. It is using some
> mac80211
> internals in ath_key_config_iter to make sure that the uploaded keys
> were
> actually programmed in the hardware. Without this check the keys
> could end up
> in the lower slots and thus break all connections."
The
From: Johannes Berg
The old WDS 4-addr frame support is very limited, e.g.
* no encryption is possible on such links
* it cannot support rate/HT/VHT negotiation
* management APIs are very restricted
These make the WDS legacy mode useless in practice.
All of these are resolved by the 4-addr
On Fri, 2016-04-08 at 21:27 -0400, Avery Pennarun wrote:
> > Just to be clear, this crash is only from *reading* the agg_status
> > files. I don't know if the crashiness reduces when disabling the
> > aggregation timeouts, since that's a separate bug (in which the
> > queue gets stuck and the 'pe
On Fri, 2016-04-08 at 09:01 +0200, Johannes Berg wrote:
> On Fri, 2016-04-08 at 08:56 +0200, Johannes Berg wrote:
> >
> > On Thu, 2016-04-07 at 21:32 -0400, Avery Pennarun wrote:
> >
> > >
> > >
> > > Yes. Here it is:
> >
On Fri, 2016-04-08 at 08:56 +0200, Johannes Berg wrote:
> On Thu, 2016-04-07 at 21:32 -0400, Avery Pennarun wrote:
>
> >
> > Yes. Here it is:
> > http://apenwarr.ca/tmp/mac80211-agg-status-crash.ko
> >
> Unfortunately there are no debug symbols in this file
On Thu, 2016-04-07 at 21:32 -0400, Avery Pennarun wrote:
> Yes. Here it is:
> http://apenwarr.ca/tmp/mac80211-agg-status-crash.ko
>
Unfortunately there are no debug symbols in this file, so it doesn't
help me much. I can't even seem to get objdump to disassemble it
correctly: looks like the fil
On Tue, 2016-04-05 at 19:46 -0400, Avery Pennarun wrote:
> This test was with backports-20150525 on ath9k. (We have newer
> versions in the queue, but they haven't rolled out to our customers
> yet. Anyway, earlier in this thread, I was able to trigger the race
> condition on much newer backport
Hi,
This email has far too many people Cc'ed on it - I don't think vger is
even accepting it for that reason. You should probably restrict it to
just a few lists when you resubmit.
> The problem with current code is that it reads/writes 4 bytes for a
> boolean, which will read/update 3 excess byt
On Mon, 2015-11-30 at 11:56 +0200, Jouni Malinen wrote:
> On Mon, Nov 23, 2015 at 07:27:17PM +0100, Michal Sojka wrote:
> > Regulatory rules are applied to channels as if the channel is at
> > least
> > 20 MHz wide. This is a problem when dealing with 5 and 10 MHz
> > channels
> > because side chan
On Fri, 2015-11-27 at 10:43 +0100, Michal Sojka wrote:
> What do you mean by "show"? nl80211_put_regdom() already sends regdom
> flags to userspace. Or do you mean introducing a new channel
> attribute and send it in nl80211_msg_put_channel()?
>
No, I meant keeping the flag - so that people can
On Mon, 2015-11-23 at 19:27 +0100, Michal Sojka wrote:
>
> The NL80211_RRF_USER_REGD_NEEDED flag introduced in this commit
> allows
> drivers to specify that certain band is enabled only if it is
> additionally enabled in user-supplied regulatory database. If the
> band
> is not present there, the
On Mon, 2015-11-23 at 19:27 +0100, Michal Sojka wrote:
> #define NL80211_RRF_PASSIVE_SCAN NL80211_RRF_NO_IR
> diff --git a/net/wireless/chan.c b/net/wireless/chan.c
> index 59cabc9..b1ab77a 100644
> --- a/net/wireless/chan.c
> +++ b/net/wireless/chan.c
> @@ -804,7 +804,8 @@ static bool _cfg80
On Thu, 2015-11-26 at 22:10 +0100, Michal Sojka wrote:
>
> Because in [1] Jouni said that
>
> "kernel config option + custom regdb would certainly be much
> closer to what I'd like to see from the regulatory enforcement view
> point"
>
> I also like the fact that the help text mentions the re
On Mon, 2015-11-23 at 19:27 +0100, Michal Sojka wrote:
> This option is meant for use by drivers and other subsystems to
> enable
> support for the Intelligent Transportation System (ITS-G5) band. The
> option depends on CFG80211_CERTIFICATION_ONUS as the use of this band
> is
> restricted. EU allo
On Mon, 2015-11-23 at 19:27 +0100, Michal Sojka wrote:
> Regulatory rules are applied to channels as if the channel is at
> least
> 20 MHz wide. This is a problem when dealing with 5 and 10 MHz
> channels
> because side channels of a regulatory rule get disabled even when
> they
> fall into rule's
On Mon, 2015-11-23 at 19:27 +0100, Michal Sojka wrote:
> The same piece of code appears at two places. Make a function from
> it.
>
Also applied.
johannes
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/
On Mon, 2015-11-23 at 19:27 +0100, Michal Sojka wrote:
> Last caller of this function was removed in 3.17 in commit
> 97dc94f1d933c9df2c0b327066ea130c0e92083f.
>
Heh.
I've applied the first two patches for now - will review the others in
more detail later.
johannes
__
On Mon, 2015-06-22 at 13:58 +0200, Johannes Berg wrote:
> On Mon, 2015-06-22 at 13:43 +0200, Janusz Dziedzic wrote:
> > mac80211 configure rxfilter per HW,
> > so we don't need this per channel.
>
> As I said before, I think there's value in mac80211 doing it per ch
On Mon, 2015-06-22 at 13:43 +0200, Janusz Dziedzic wrote:
> mac80211 configure rxfilter per HW,
> so we don't need this per channel.
As I said before, I think there's value in mac80211 doing it per chanctx
or even per vif, and it should be more efficient to do so.
It's tempting to do it per vif a
On Tue, 2015-06-16 at 08:30 +0200, Janusz Dziedzic wrote:
> Other fix I can image is change wpa_supplicant and add
> NL80211_SCAN_FLAG_AP to p2p_find, and set in ath9k driver
> wiphy->features |= NL80211_FEATURE_AP_SCAN;
>
> NL80211_FEATURE_AP_SCAN is not set when use_chanctx=1
>
> I am not sure
On Mon, 2014-10-20 at 21:09 +0200, Oleksij Rempel wrote:
> Hi Johannes,
>
> since this function was added by you, may be you can help here (commit
> f09603a259). ath9k_htc support max 8 STAs in AP or ADHOC mode. If more
> then 8 stations connected, driver will return error, but
> sta_info_insert_
On Tue, 2014-05-06 at 13:44 +0200, Marek Kwaczynski wrote:
> Hi Johannes,
>
> I can achieve the same result without changing radiotap header if
> durationID filed won't be updated for all injected frames. What do you
> think about it?
I think that's a terrible idea, particularly backward compatib
On Tue, 2014-05-06 at 08:32 +0200, Marek Kwaczynski wrote:
> Adds a new bit in radiotap_tx flags, which allows injections
> frames without changing durationId filed. The intention is
> a NAV update testing.
NACK.
http://www.radiotap.org/suggested-fields/TX%20flags
And since I'm tired of this, I'
On Mon, 2014-02-17 at 16:49 +0100, Rostislav Lisovy wrote:
> As you have already noticed, this is work in progress. I agree it is
> necessary to keep the code clean if I want others to read it -- I try to
> do so but it does not always go very well.
:-)
> One thing I am not sure about (mentioned
On Mon, 2014-02-17 at 14:22 +0100, Rostislav Lisovy wrote:
> Signed-off-by: Rostislav Lisovy
No description, lots of FIXMEs, lots of // comments, again a mashup of
cfg80211 and mac80211 changes ... I'll just stop looking right now.
johannes
___
ath9k-
On Mon, 2014-02-17 at 14:22 +0100, Rostislav Lisovy wrote:
> Signed-off-by: Rostislav Lisovy
Err, some text is definitely needed.
> ---
> include/net/cfg80211.h | 19 ++-
> include/net/mac80211.h | 4 +-
> include/uapi/linux/nl80211.h | 17 ++-
> net/wireless/chan.c
On Mon, 2014-01-27 at 20:02 +0100, Oleksij Rempel wrote:
> Hi Johannes,
>
> i found this bug report with your response:
> https://bugzilla.redhat.com/show_bug.cgi?id=990955
> "I don't think adding a workqueue is a good idea because that would
> significantly delay the calls in many situations."
>
On Mon, 2013-12-16 at 16:09 +0100, David Herrmann wrote:
> Thanks, I tracked down the ENETDOWN. I'm not entirely sure but I think it's:
Obviously :)
> @Oleksij, I actually have three ath9k-htc devices so I'd like to get
> this working, and the devices are really nice apart from this bug. I
> wil
On Mon, 2013-12-16 at 16:26 +0100, Oleksij Rempel wrote:
> Am 16.12.2013 16:15, schrieb Johannes Berg:
> > On Mon, 2013-12-16 at 16:09 +0100, David Herrmann wrote:
> >
> >> Thanks, I tracked down the ENETDOWN. I'm not entirely sure but I think
> >> it'
On Tue, 2013-11-19 at 16:16 +0100, Simon Wunderlich wrote:
> For 5 GHz I don't know if it's possible. For example in ath9k, you could try
> to hack ath9k_5ghz_chantable, add more channels in 5 mhz spaces and try if it
> works. The driver says here:
Not sure how I ended up on this thread, but no
On Tue, 2013-06-25 at 13:05 -0700, Thomas Pedersen wrote:
> That warning is triggered by wiphy_verify_combinations():
>
> if (WARN_ON((wiphy->interface_modes & types) !=
> types))
> return -EINVAL;
>
> But before that, the mesh iftype bit
On Fri, 2013-06-21 at 05:12 +0200, Mihai Moldovan wrote:
> * On 18.06.2013 11:25 PM, Mihai Moldovan wrote:
> > [...]
> > Looking at the kernel source (net/mac80211/tx.c), this condition is being
> > triggered:
> >
> > if (unlikely(!ieee80211_vif_is_mesh(&sdata->vif) &&
> > !is
Btw, I'm a bit confused -- are you using ath9k_htc as per the subject,
or ath9k?
if it's ath9k_htc then I don't really understand why the patch that
*fixed* it for Corey *broke* it for you?
johannes
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.
Now the subject should no longer say "mac80211:" :)
However... given that ieee80211_get_tx_rates() actually *copies* the
rates into the parameter, I guess it should do the rcu_read_lock()
internally. I guess I wasn't paying attention previously. Felix?
johannes
_
On Fri, 2013-05-24 at 12:18 +0200, Oleksij Rempel wrote:
> Signed-off-by: Oleksij Rempel
> ---
> drivers/net/wireless/ath/ath9k/init.c | 9 +++--
> drivers/net/wireless/ath/ath9k/mac.c | 5 +
> drivers/net/wireless/ath/ath9k/mac.h | 3 ++-
> 3 files changed, 14 insertions(+), 3 deletion
On Fri, 2013-05-24 at 12:05 +0200, Oleksij Rempel wrote:
> Some chips can tell us if received frame was
> encoded with STBC or not. To make this information available
> in user space we can use updated radiotap specification:
> http://www.radiotap.org/defined-fields/MCS
>
> This patch will set num
On Thu, 2013-05-23 at 16:11 +0200, Oleksij Rempel wrote:
> - *pos++ = local->hw.radiotap_mcs_details;
> +
> + /* MCS known field */
> + *pos = local->hw.radiotap_mcs_details;
> + if (stbc)
> + *pos |= IEEE80211_RADIOTAP_MCS_HAVE_S
On Thu, 2013-05-23 at 09:17 +0200, Oleksij Rempel wrote:
> revision:
> - v2. set HAVE_STBC only if it is present.
> do not set STBC flag on TX packets.
Please don't include changes *inside* the changelog. Also, an actual
commit message would be nice.
johannes
__
On Sun, 2013-05-19 at 09:38 +0200, Oleksij Rempel wrote:
> + * @RX_FLAG_STBC_MASK: STBC 2 bit bitmask. 1 - Nss=1, 2 - Nss=2, 3 - Nss=3
> + RX_FLAG_STBC_MASK = BIT(26) | BIT(27),
> @@ -258,6 +258,7 @@ ieee80211_add_rx_radiotap_header(struct ieee80211_local
> *local,
> p
On Thu, 2013-05-16 at 11:01 +0200, Oleksij Rempel wrote:
> Hallo all,
>
> so, there is no updates or critic on this topic. That mean, every thing
> is OK.
I tend to agree.
> I assume "suggested-fields/MCS extension for STBC and Ness"
> http://www.radiotap.org/suggested-fields/MCS%20extension%2
On Tue, 2013-05-07 at 15:54 +0200, Johannes Berg wrote:
> On Tue, 2013-05-07 at 09:40 +0200, Oleksij Rempel wrote:
> > Am 02.05.2013 22:44, schrieb Johannes Berg:
> > > On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote:
> > >
> > >>> With this I beli
On Tue, 2013-05-07 at 09:40 +0200, Oleksij Rempel wrote:
> Am 02.05.2013 22:44, schrieb Johannes Berg:
> > On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote:
> >
> >>> With this I believe we have everything needed to start the 3 week
> >>> comment
On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote:
> > With this I believe we have everything needed to start the 3 week
> > comment period.
Yeah, I guess there was plenty of time. I would have preferred a
separate thread, but I guess there's little enough traffic on this list
so it doesn't
On Mon, 2013-04-29 at 11:04 +0200, Wojciech Dubowik wrote:
> Add rx flag to radiotap header which tells whether
Same here, you can't just randomly add something to radiotap. Go
standardise it first.
johannes
___
ath9k-devel mailing list
ath9k-devel@lis
On Mon, 2013-04-29 at 11:33 +0200, Oleksij Rempel wrote:
> --- a/include/net/ieee80211_radiotap.h
> +++ b/include/net/ieee80211_radiotap.h
> @@ -269,6 +269,7 @@ enum ieee80211_radiotap_type {
> #define IEEE80211_RADIOTAP_MCS_HAVE_GI 0x04
> #define IEEE80211_RADIOTAP_MCS_HAVE_FMT
zOn Wed, 2013-04-24 at 21:05 +0200, Francisco Cuesta wrote:
> Hello,
>
> I was wondering where I might find on the ath9k drivers the functions
> which let the device distinguish between AP mode and mesh/adhoc one.
> Could someone enlighten me a bit?
git grep NL80211_IFTYPE_
johannes
___
On Tue, 2013-03-05 at 16:49 -0500, Corey Richardson wrote:
> On Mon, Mar 4, 2013 at 3:42 AM, Corey Richardson wrote:
> > ath9k_htc driver , AR9271 (at least according to lsusb)
> >
> > commit fd0f979a1b67f0889aea24a7c7d2a54d6706a1cf
> > Author: Johannes Berg
> >
On Mon, 2013-03-04 at 13:23 -0600, Seth Forshee wrote:
> I've been looking at power save in mac80211 over the past few days with
> an eye towards allowing multiple interface to be supported, as a result
> of comments Johannes made at [1]. It seems like adding driver callbacks
> for PS which are sp
On Wed, 2013-02-27 at 09:06 +0100, Marco Porsch wrote:
> >> struct ieee802_11_elems;
> >> struct ieee80211_mesh_sync_ops {
> >> - void (*rx_bcn_presp)(struct ieee80211_sub_if_data *sdata,
> >> -u16 stype,
> >> -struct ieee80211_mgmt
On Mon, 2013-02-25 at 11:06 +0100, Marco Porsch wrote:
> > This is strange, why bother with the else if there's a continue?
>
> I don't quite get this comment. The current logic is like this:
>
> if (unrelated cases) {
> continue;
> } else if (related and blocking) {
> allow = false;
On Wed, 2013-02-20 at 10:26 -0800, Thomas Pedersen wrote:
> On Wed, Feb 20, 2013 at 6:50 AM, Johannes Berg
> wrote:
> > On Mon, 2013-02-18 at 17:08 +0100, Marco Porsch wrote:
> >
> >> + /*
> >> + * If available, calculate the time the beacon timest
On Mon, 2013-02-18 at 17:08 +0100, Marco Porsch wrote:
> +/**
> + * ieee80211_mps_init - register callbacks for mesh powersave mode
> + *
> + * @hw: the hardware
> + * @ops: callbacks for this device
> + *
> + * called by driver on mesh interface add/remove
> + */
> +#ifdef CONFIG_MAC80211_MESH
>
On Mon, 2013-02-18 at 17:08 +0100, Marco Porsch wrote:
> + /*
> + * If available, calculate the time the beacon timestamp field was
> + * received from the rx_status->mactime field. Otherwise get the
> + * current TSF as approximation before entering rcu-read section.
> + *
On Mon, 2013-02-18 at 16:07 +0100, Marco Porsch wrote:
> > I guess you can tell I'm not in a good mood today. I think any use of
> > get_tsf() for operation is a complete waste of time, there's no way you
> > can get the timings correct. You could be preempted, and suddenly sleep
> > for a few ten
[-ilw list, it just bothers me about putting emails into quarantine]
> > I'm not really convinced this is the right thing to do. Sooner or later,
> > multi-virtual interface support will become more relevant, and then all
> > of this is completely moot because then powersave is entirely disabled
>
On Fri, 2013-02-15 at 14:48 +0100, Marco Porsch wrote:
> > I'm talking about this API:
> >
> > mesh_neighbour_update:
> > ...
> > tsf = drv_get_tsf()
> > ...
> > sync_ops->rx_bcn(..., tsf)
> >
> >
> > mesh_sync_offset_rx_bcn(..., t_r):
> > ...
> > if (have_better_timestamp)
> >
On Fri, 2013-02-15 at 14:31 +0100, Marco Porsch wrote:
> Hi,
>
> On 02/15/2013 01:46 PM, Johannes Berg wrote:
> > On Fri, 2013-02-15 at 12:40 +, ma...@cozybit.com wrote:
> >> Please check again. The comment is split in two and placed on the
> >> respective n
On Fri, 2013-02-15 at 12:40 +, ma...@cozybit.com wrote:
> Please check again. The comment is split in two and placed on the respective
> new positions.
Yeah, I see, the API is just total shit. First passing the TSF and then
calculating it to override? Why not do the calculation outside the AP
On Fri, 2013-02-15 at 12:40 +0100, Marco Porsch wrote:
> - /* The current tsf is a first approximation for the timestamp
> - * for the received beacon. Further down we try to get a
> - * better value from the rx_status->mactime field if
> - * available. Also we have to call drv
On Wed, 2013-02-13 at 19:54 +0100, Arend van Spriel wrote:
> On 02/13/2013 06:04 PM, Seth Forshee wrote:
> >> Is all this really worth it? It seems a quick fix for brcmsmac might be
> >> > to always set the powersave bit when IEEE80211_CONF_OFFCHANNEL is
> >> > enabled in the config, and then go im
On Wed, 2013-02-06 at 15:01 -0600, Seth Forshee wrote:
> The powersave configuration in struct ieee80211_conf is currently a
> binary state, either enabled or disabled. This is inadequate for
> expressing the situation during off-channel operation, when powersave is
> set at the AP to request buffe
On Mon, 2013-02-11 at 13:03 +0100, Marco Porsch wrote:
> On 02/08/2013 10:57 PM, Johannes Berg wrote:
> > On Fri, 2013-02-08 at 11:09 +0100, Marco Porsch wrote:
> >
> >>>> For mesh Awake Windows wakeup on SWBA (beacon_get_tim) and start
> >>>>
On Fri, 2013-02-08 at 11:09 +0100, Marco Porsch wrote:
> >> For mesh Awake Windows wakeup on SWBA (beacon_get_tim) and start
> >> a timer which triggers a doze call on expiry.
> >
> > That seems questionable -- drivers are not required to request each
> > beacon. I know you only want to make it wo
On Wed, 2013-02-06 at 12:48 +0100, Marco Porsch wrote:
> For mesh Awake Windows wakeup on SWBA (beacon_get_tim) and start
> a timer which triggers a doze call on expiry.
That seems questionable -- drivers are not required to request each
beacon. I know you only want to make it work on ath9k, but
On Wed, 2013-02-06 at 12:02 -0600, Seth Forshee wrote:
> > Ah, wl1251 is the weird thing that wants to be told when to wake up/go
> > to sleep, and then sends nulldata packets itself ... so when we send
> > nulldata packets *again* for off-channel, because it also uses software
> > scanning. Like
On Wed, 2013-02-06 at 11:09 -0600, Seth Forshee wrote:
> > Does it just mean "I support actually turning off the radio"? But then
> > what's the difference to supporting powersave? Can we maybe just
> > disregard wl1251, which has the stupidest powersave implementation on
> > the planet, and solve
Hi Seth,
> I've been thinking about and playing around with these ideas. I've
> implemented the CONF_PM idea, and it does end up with fewer changes, but
> I just don't think separating powersave from setting PM makes much
> sense. In the end it just seems like a kludge to fix a problem with
> Broa
On Thu, 2013-01-31 at 11:18 -0600, Seth Forshee wrote:
> > > Actually one of the last bugs I fixed before sending these was a place
> > > where I had used disabled instead of !enabled, and the frames ended up
> > > with PM set when it shouldn't have been.
> > >
> > > I agree though that the disti
On Thu, 2013-01-31 at 10:33 -0600, Seth Forshee wrote:
> On Thu, Jan 31, 2013 at 04:20:48PM +0100, Johannes Berg wrote:
> > On Tue, 2013-01-29 at 17:47 -0600, Seth Forshee wrote:
> >
> > > +static inline bool ieee80211_is_ps_disabled(struct ieee80211_conf *conf)
> &
On Tue, 2013-01-29 at 17:47 -0600, Seth Forshee wrote:
> +static inline bool ieee80211_is_ps_disabled(struct ieee80211_conf *conf)
> +static inline bool ieee80211_is_ps_enabled(struct ieee80211_conf *conf)
Huh, is that worth the confusion? It seems !enabled should be the same
as disabled, but it
On Thu, 2013-01-31 at 16:23 +0100, Marco Porsch wrote:
> On 01/31/2013 02:51 PM, Johannes Berg wrote:
> > On Wed, 2013-01-23 at 11:19 +0100, Marco Porsch wrote:
> >
> >> Expose a callback ieee80211_mps_init for drivers to register
> >> mesh powersave ops:
> &
On Wed, 2013-01-23 at 11:19 +0100, Marco Porsch wrote:
> Move the beacon handler into mesh_neighbour_update where the STA
> pointer is already available. This avoids additional overhead
> and simplifies the handler.
> The repositioning will also benefit mesh PS which uses the
> T_offset value right
On Wed, 2013-01-23 at 11:19 +0100, Marco Porsch wrote:
> Expose a callback ieee80211_mps_init for drivers to register
> mesh powersave ops:
> - hw_doze - put the radio to sleep now
> - hw_wakeup - wake the radio up for frame RX
> These ops may be extended in the future to allow drivers/HW to
> imp
On Wed, 2012-11-28 at 17:06 +, Malinen, Jouni wrote:
> >FWIW, right now our plan for iwlwifi is to only really support it with
> >the P2P Device wdev, but I'm not sure what implications that has in
> >terms of support for GAS/ANQP etc. We might have to revisit that.
>
> GAS/ANQP is pre-associ
> >Anyway, you'd suggest to use the NL80211 remain on channel command for
> >that?
>
> Yes.
>
> >Or add a new "spectral scan" nl80211 command to do a spectral scan on this
> >(or multiple) channels, and use the various functions from
> >mac80211/offchannel.c?
>
> I would rather add a flag to th
> > > That "if supported" here is pretty problematic. There's no way to know.
> > > Feature flag maybe?
>
> Hmm, I could certainly add a WIPHY_FLAG for that.
nl80211 feature flag would be better
> > > Also, there are scan flags now. However, I don't see that this should
> > > (ab)use the scan f
On Wed, 2012-11-28 at 13:35 +0100, Johannes Berg wrote:
> On Tue, 2012-11-27 at 20:01 +0100, Simon Wunderlich wrote:
> > This flag indicates that a spectrum scan is requested, if supported.
>
> That "if supported" here is pretty problematic. There's no way to know.
&
On Tue, 2012-11-27 at 20:01 +0100, Simon Wunderlich wrote:
> This flag indicates that a spectrum scan is requested, if supported.
That "if supported" here is pretty problematic. There's no way to know.
Feature flag maybe?
Also, there are scan flags now. However, I don't see that this should
(ab)u
On Tue, 2012-11-13 at 10:48 -0800, Thomas Pedersen wrote:
> Accurate RX timestamp reporting is important for proper IBSS merging,
> mesh synchronization, and MCCA scheduling. Namely, knowing where the TSF
> is recorded is needed to sync with the beacon timestamp field.
> - rx_status->flag |=
On Sun, 2012-09-30 at 21:21 +0200, Peter Senna Tschudin wrote:
> - if (!ah->config.enable_paprd);
> + if (!ah->config.enable_paprd)
> return false;
That's not an "unnecessary semicolon", it's a pretty strange bug :)
johannes
On Thu, 2012-08-09 at 03:11 +0200, Antonio Quartulli wrote:
> some drivers need to be notified in case of rates update. This callback tells
> the driver that something has been changed in the supported rates set of the
> station passed as argument and that it needs to update its internal tables
>
On Fri, 2012-07-27 at 11:35 +0200, Thomas Huehn wrote:
> Hi Johannes,
>
> Johannes Berg schrieb:
>
>
> > When you do, please remove the last two hunks from your patch that are
> > spurious indentation changes in tx.c
>
>
> When Ariks two TI driver patches
On Thu, 2012-07-26 at 22:02 +0200, Thomas Huehn wrote:
> > Better to just wait some time. I wrote up something to make it much
> > easier for you. Waiting for some internal review before sending it up.
> >
>
> Thx for helping out here, I ws allready checking into what kind of
> struct I can put
On Thu, 2012-07-26 at 18:17 +0200, Johannes Berg wrote:
> On Thu, 2012-07-26 at 18:09 +0200, Thomas Huehn wrote:
> > The pointer control.sta is removed from ieee80211_tx_info to free up
> > sufficient memory in SKB_CB on the tx-path to enable new annotations
> > per data
On Thu, 2012-07-26 at 18:09 +0200, Thomas Huehn wrote:
> The pointer control.sta is removed from ieee80211_tx_info to free up
> sufficient memory in SKB_CB on the tx-path to enable new annotations
> per data packet e.g.support of upcoming Transmit Power Control (TPC).
> Now the control.sta pointer
On Thu, 2012-07-26 at 11:27 +0200, Thomas Huehn wrote:
> (2)
> url = git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git
>
> last commit e4cbd6542efdab97ed6d38e706b7cac51c68ced7
I'm on this commit + your patch.
CC [M] drivers/net/wireless/ti/wlcore/main.o
/home/johannes/sys
On Wed, 2012-07-25 at 22:25 +0300, Luciano Coelho wrote:
> > My last PATCH included some changes at a TI driver which was adapted in
> > wireless-testing in John's tree. As I touch that many drivers I would
> > like to use your tree instead, to provide a proper PATCH that builds at
> > your tree s
On Wed, 2012-07-25 at 11:36 +0200, Johannes Berg wrote:
> On Tue, 2012-07-24 at 22:18 +0200, Thomas Huehn wrote:
> > The pointer control.sta is removed from ieee80211_tx_info to free up
> > sufficient memory in SKB_CB on the tx-path to enable new annotations
> > per data
gt; drivers is restructured to respect the chaneges.
>
> Signed-off-by: Thomas Huehn
> Signed-off-by: Alina Friedrichsen
> Signed-off-by: Felix Fietkau
> ---
> restructure this patch to respect logical API evolutions. thx to Johannes Berg
> add missing drivers that are e
On Mon, 2012-07-23 at 21:33 +0200, Thomas Huehn wrote:
> --- a/net/mac80211/ieee80211_i.h
> +++ b/net/mac80211/ieee80211_i.h
> @@ -196,6 +196,8 @@ struct ieee80211_tx_data {
> struct ieee80211_channel *channel;
>
> unsigned int flags;
> +
> + struct ieee80211_tx_control control;
> Virtual box did the job and I found 3 drivers that somehow did not
> complain in my OpenWRT build env... thx for not playing :)... v3 is out.
See, that's why I don't want to play the game -- I could've gone back
and forth with you for like a week over multiple compile failures :-)
> I used wir
On Tue, 2012-07-17 at 14:57 +0200, Thomas Huehn wrote:
> > Ok first of all, please actually compile the tree after your changes. It
> > doesn't. When it does, please fix
>
> I always do compile the compat-wireless-tree after changes I introduce,
> and it compiles without errors in the case of thi
Ok first of all, please actually compile the tree after your changes. It
doesn't. When it does, please fix
1) line length in the commit log should be < 72 chars
2) indentation in mac80211.h
3) removal of an important comment in mac80211.h that I pointed out in
previous review
> The tx-path
On Tue, 2012-06-26 at 10:54 +0530, Mohammed Shafi Shajakhan wrote:
> the user pattern needs bit more stuff, we need to convert it to our chip
> specific format(ie proper 802.11 format), previously there was
> a logic of duplicate patterns before programming to HW, where a list in
> the driver wa
On Mon, 2012-06-11 at 12:02 +0800, Matt Chen wrote:
> Hi Johannes,
>
> What is wowlan ? Does it need BIOS suuport ?
http://wireless.kernel.org/en/users/Documentation/WoWLAN
It needs platform support to leave the card powered on.
johannes
___
ath9k-de
1 - 100 of 177 matches
Mail list logo
