Hi,
I've had someone ask me about japan certification for ath9k. it
apparently now requires the transmitter stop everything, beaconing
included, when it sees an interferer signal.
Apparently ath9k is also beaconing no matter what the interference is.
Has anyone else come across this?
-a
__
Hi all.
In case you wonder about the bunch of older e-mails that just came through
the list:
There were > 300 mails waiting for moderation (*), most of them because
they either were sent from non-members or were addressing too many
recipients at once. Since I don't follow ath9k-devel anymore and
Dear all,
I have a couple of questions related to the ath9k drivers.
1)
I was wondering if it is possible to purposely deactivate the ACK transmission
on a per-attempt basis.
Specifically, I would like to simulate packet errors at driver level (i.e.
software). I already looked at the methods i
On Fri, Nov 27 2015, Johannes Berg wrote:
> 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 da
Hi
I want to change MCS rate for ath9k 802.11n config.We are using ath9k driver
with debug
enabled and debugfs mounted.
Kernel config options for driver
CONFIG_ATH_COMMON=m
CONFIG_ATH_CARDS=m
CONFIG_ATH_DEBUG=y
CONFIG_ATH5K=m
# CONFIG_ATH5K_DEBUG is not set
CONFIG_ATH5K_PCI=y
CONFIG_ATH9K_HW=m
The function can return negative values in case of error.
Its result should be then tested for such case.
The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1].
[1]: http://permalink.gmane.org/gmane.linux.kernel/2046107
Signed-of
When channel context is enabled, we could be
stopping/awakening an incorrect queue.
---
drivers/net/wireless/ath/ath9k/xmit.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c
b/drivers/net/wireless/ath/ath9k/xmit.c
On Fri, Nov 27 2015, Johannes Berg wrote:
> 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 a
On Tue, Sep 15, 2015 at 01:47:32PM -0400, Steven Rostedt wrote:
> What do others think when there's a change that goes across the board
> this much? BCC OK with you, as just an FYI, I'm doing this? Or should
> just the lists be enough and if you don't see it, too bad?
Bcc sounds good to me.
(Let'
* Steven Rostedt wrote:
> But please, next time, go easy on the Cc list. Maybe just use bcc for those
> not
> on the list, stating that you BCC'd a lot of people to make sure this is
> sane,
> but didn't want to spam everyone with every reply.
Not just that, such a long Cc: list is a semi-g
Hi Matthias,
The patch is working for me, and I am using it, but I could not test
Much further since real-life radar situations are hard to produce.
Before DFS integration, combinations were less limited. I submitted
the patch as a RFC only, because I suspected the DFS people had a
hidden reason
In order to prevent accidental use of Intelligent Transportation System
band (5.9 GHz), we require system integrators to provide custom
userspace regulatory database enabling the use of the band. However,
drivers that provide their own regulatory database (such as ath9k) would
not enable that band
From: Colin Ian King
minor change, indenting is one tab out.
Signed-off-by: Colin Ian King
---
drivers/net/wireless/ath/ath9k/xmit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c
b/drivers/net/wireless/ath/ath9k/xmit.c
index 3e3dac3.
On Fri, Nov 27 2015, Johannes Berg wrote:
> On Mon, 2015-11-23 at 19:27 +0100, Michal Sojka wrote:
>
>> #define NL80211_RRF_PASSIVE_SCANNL80211_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/wireles
On Thu, Nov 26 2015, Johannes Berg wrote:
> 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 same piece of code appears at two places. Make a function from it.
Signed-off-by: Michal Sojka
---
net/wireless/reg.c | 91 ++
1 file changed, 37 insertions(+), 54 deletions(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 43b
From: Jan Kaisrlik
The patch adds support for Intelligent Transportation System (ITS-G5)
band to the ath9k driver.
Signed-off-by: Jan Kaisrlik
Cc: Michal Sojka
---
Hi all,
in this second version of the patch we removed dependency on
CFG80211_CERTIFICATION_ONUS as suggested by Johannes. We ar
some obvious stuff I forgot:
dmesg | grep ath
[1.378790] ath: EEPROM regdomain: 0x21
[1.378791] ath: EEPROM indicates we should expect a direct regpair map
[1.378793] ath: Country alpha2 being used: AU
[1.378793] ath: Regpair used: 0x21
[1.380764] ath9k :02:00.0 wlan0: set_
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 frequency range.
This problem was already fixed in commit
4edd56981c
On Tue, Sep 15, 2015 at 6:45 AM, Steven Rostedt wrote:
>
> Linus, This patch changes a lot of u32s into bools in structures.
> What's your take on that?
So in general, I'd tend to prefer "bool" to be used primarily as a
return value for functions, but I have to say, in the case of
something that
The patch adds support for Intelligent Transportation System (ITS-G5)
band to the ath9k driver. The corresponding channels are allowed only if
CONFIG_CFG80211_REG_ITSG5_BAND is set and if the user provides custom
regulatory database. In addition, the band is limited to OCB mode.
Signed-off-by: Mic
On Mon, Nov 02 2015, Jouni Malinen wrote:
> On Mon, Nov 02, 2015 at 06:33:45PM +0100, Michal Sojka wrote:
>> Can this be solved by having proper/new regulatory flags on these
>> channels that would prohibit running AP or scanning on these channels?
>
> I'm not sure that alone is sufficient, but yes
We don't want channels designated for Intelligent Transportation Systems
to be used in other modes than OCB. We therefore introduce regulatory
and channel flags that prevent scanning (for performance reasons) and
beaconing on these channels.
Although regulatory documents do not talk about which mo
When channel context is enabled, we could be
stopping/awakening an incorrect queue.
Signed-off-by: Borja Salazar
---
drivers/net/wireless/ath/ath9k/xmit.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c
b/drivers
Hi,
Let me explain the patch more thoroughly. We are testing MCC and we've
found some issues with the queues handlers, the main problem is that
when we transmit a multicast/broadcast frame, where hw_queue is 8
(CAB), we check queue status, which is 2(q), and if it is full and we
have to stop it, w
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 allows using it only for certain applications, USA
require certificatio
[fixed ath9k list address. sorry for the spam]
Hi all,
I have a pretty weird problem I've been chasing for a few weeks and
have narrowed it down, but not quite solved it. It may be caused by
bugs in aggregation-related code.
Steps:
- Set up an ath9k-based Linux AP on an ARM processor (currentl
Hi Janusz,
[auto build test ERROR on wireless-drivers-next/master]
[also build test ERROR on v4.3 next-20151112]
url:
https://github.com/0day-ci/linux/commits/Janusz-Dziedzic/ath9k-add-debug-messages-to-aggr-chanctx-funcs/20151112-212004
base:
https://git.kernel.org/pub/scm/linux/kernel/gi
Last caller of this function was removed in 3.17 in commit
97dc94f1d933c9df2c0b327066ea130c0e92083f.
Signed-off-by: Michal Sojka
---
net/wireless/core.h | 7
net/wireless/util.c | 114
2 files changed, 121 deletions(-)
diff --git a/net
This patch series is another attempt to mainline support for ITS-G5
band (5.9 GHz) designated for Intelligent Transportation Systems.
Based on the discussion with Jouni [1], this version adds the
following restrictions for using the band:
1. Custom reg db must be provided by the user.
2. CONFIG_C
Signed-off-by: Michal Sojka
---
net/wireless/reg.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 2e8d6f3..43b3e57 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1052,7 +1052,7 @@ static u32 map_regdom_flags(u
arggg, you are right, we have it the right way as a patch for openwrt,
I made a mistake generating kernel patch, will send V3
Borja Salazar
Firmware team
All information in this email is confidential
On Fri, Nov 13, 2015 at 12:19 PM, Janusz Dziedzic
wrote:
> Send again as txt.
>
>
> On 13 Novemb
On Tue, 15 Sep 2015 16:34:47 +0530
Viresh Kumar wrote:
> Hi Johannes,
>
> On 15-09-15, 12:37, Johannes Berg wrote:
> > 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 re
Fatal exception in interrupt on 4.4.0-rc1 when acting as an AP on an
amd64 box.
Exception is at: ath_calcrxfilter+0xea/0x10a
Image of the panic:
http://imgur.com/A4WJ5TI
Let me know if there's some other place you'd prefer I host that or if
more help is required to debug.
___
Hi,
Let me explain the patch more thoroughly. We are testing MCC and we've
found some issues with the queues handlers, the main problem is that when
we transmit a multicast/broadcast frame, where hw_queue is 8 (CAB), we
check queue status, which is 2(q), and if it is full and we have to stop
it, w
Hello,
On Tue, Sep 15, 2015 at 07:42:08PM +0530, Viresh Kumar wrote:
> Ah, yes. Thanks for letting me know (I just testedit as well).
>
> But will it look sane enough to set a boolean to anything apart from
> true/false or 1/0? Yes, it will always be set to 0/1 only, but still..
Let's please not
On Mon, Sep 14, 2015 at 09:21:54AM +0530, Viresh Kumar wrote:
> Long back 'bool' type used to be a typecast to 'int', but that changed
> in v2.6.19. And that is a typecast to _Bool now, which (mostly) takes
> just a byte. Anyway, the bool type is implementation defined, and better
> we don't assume
Hi Jouni,
thanks for quick reply.
On Mon, Nov 02 2015, Jouni Malinen wrote:
> On Mon, Nov 02, 2015 at 11:22:57AM +0100, Michal Sojka wrote:
>> The patch adds support for Intelligent Transportation System (ITS-G5)
>> band to the ath9k driver.
>
> NAK. This would enable use of licensed 5.9 GHz band
Hi,
Recently I used an OpenWRT router (TP-LINK WDR3500, AR9340, ATH9K) to sniff
packets, and I found that the MCS information in the radiotap header is
possible corrupted.
In theory, all A-MPDU subframes should be sent in the same bit rate
(MCS/BW/GI), since they have the same PPDU header. Howeve
On Tuesday 15 September 2015 07:34:38 Viresh Kumar wrote:
> On 14-09-15, 09:03, Greg KH wrote:
> > What ever ones you think it is relevant for :)
>
> "Relevant" is a relevant term :)
>
> So, the patch which defined the type bool as _Bool was added in v2.6.19 :)
>
> 6e2182874324 ("[PATCH] Generic
On Monday 14 September 2015 09:21:54 Viresh Kumar wrote:
> diff --git a/drivers/acpi/ec_sys.c b/drivers/acpi/ec_sys.c
> index b4c216bab22b..bea8e425a8de 100644
> --- a/drivers/acpi/ec_sys.c
> +++ b/drivers/acpi/ec_sys.c
> @@ -128,7 +128,7 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec,
> uns
On Tue, 15 Sep 2015 10:38:32 -0700
Linus Torvalds wrote:
> But that user interface issue doesn't seem to be the case here, an I
> can't say that I mind the patch. It looks fairly sane.
If Linus is fine with it, I'm fine with it too.
But please, next time, go easy on the Cc list. Maybe just use
Hi Johannes,
On 15-09-15, 12:37, Johannes Berg wrote:
> 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.
Hmm, I know the list is too long and yes its blocked for Adm
On Tue, 15 Sep 2015 14:04:59 +0530
Viresh Kumar wrote:
> diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
> index 2614a839c60d..f11e17ad7834 100644
> --- a/drivers/acpi/ec.c
> +++ b/drivers/acpi/ec.c
> @@ -1237,7 +1237,7 @@ ec_parse_device(acpi_handle handle, u32 Level, void
> *context, void *
On 15-09-15, 09:45, Steven Rostedt wrote:
> Then break up the patch.
That will cause build warnings between the patches due to prototype
mismatch. Maybe I should ignore get_maintainers for this patch and
just cc the lists :)
> Your Cc list is far too large, I would nack
> this patch just for that
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 15-09-15, 10:04, Steven Rostedt wrote:
> On Tue, 15 Sep 2015 14:04:59 +0530
> Viresh Kumar wrote:
>
> > diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
> > index 2614a839c60d..f11e17ad7834 100644
> > --- a/drivers/acpi/ec.c
> > +++ b/drivers/acpi/ec.c
> > @@ -1237,7 +1237,7 @@ ec_parse_devi
On Tue, Sep 15, 2015 at 02:04:59PM +0530, Viresh Kumar wrote:
> Long back 'bool' type used to be a typecast to 'int', but that changed
> in v2.6.19. And that is a typecast to _Bool now, which (mostly) takes
> just a byte. Anyway, the bool type is implementation defined, and better
> we don't assume
Hello all,
I've come across some strangeness when using a USB ath9k on a USB 1
interface. I'm getting the "BOGUS urb xfer, pipe 1 != type 3" errors that
have been posted and discussed already, but the cause of the errors in my
case is different than those already reported.
I did some digging to
Long back 'bool' type used to be a typecast to 'int', but that changed
in v2.6.19. And that is a typecast to _Bool now, which (mostly) takes
just a byte. Anyway, the bool type is implementation defined, and better
we don't assume its size to be 4 bytes or 1.
The problem with current code is that i
Long back 'bool' type used to be a typecast to 'int', but that changed
in v2.6.19. And that is a typecast to _Bool now, which (mostly) takes
just a byte. Anyway, the bool type is implementation defined, and better
we don't assume its size to be 4 bytes or 1.
The problem with current code is that i
On 14-09-15, 09:03, Greg KH wrote:
> What ever ones you think it is relevant for :)
"Relevant" is a relevant term :)
So, the patch which defined the type bool as _Bool was added in v2.6.19 :)
6e2182874324 ("[PATCH] Generic boolean")
So, I will try at least for v3.10+ as they are used by a lot o
On Mon, Sep 14, 2015 at 09:17:08PM +0530, Viresh Kumar wrote:
> On 14-09-15, 17:39, Arnd Bergmann wrote:
> > On Monday 14 September 2015 09:21:54 Viresh Kumar wrote:
> > > diff --git a/drivers/acpi/ec_sys.c b/drivers/acpi/ec_sys.c
> > > index b4c216bab22b..bea8e425a8de 100644
> > > --- a/drivers/ac
On 14-09-15, 17:39, Arnd Bergmann wrote:
> On Monday 14 September 2015 09:21:54 Viresh Kumar wrote:
> > diff --git a/drivers/acpi/ec_sys.c b/drivers/acpi/ec_sys.c
> > index b4c216bab22b..bea8e425a8de 100644
> > --- a/drivers/acpi/ec_sys.c
> > +++ b/drivers/acpi/ec_sys.c
> > @@ -128,7 +128,7 @@ stat
Dear all,
I have a couple of questions related to the ath9k drivers.
1)
I was wondering if it is possible to purposely deactivate the ACK transmission
on a per-attempt basis.
Specifically, I would like to simulate packet errors at driver level (i.e.
software). I already looked at the methods i
55 matches
Mail list logo