* Re: [RFC] ibss: Added channel type in order to create HT IBSS
From: Benoit Papillault @ 2010-05-02 20:05 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1272817974.31265.0.camel@jlt3.sipsolutions.net>
Le 02/05/2010 18:32, Johannes Berg a écrit :
> On Sun, 2010-05-02 at 16:12 +0200, Benoit Papillault wrote:
>> When joining an IBSS, the parameters can be used to create the IBSS. As
>> such, we need to know if the user wants to create an HT IBSS or not.
>> This is accomplish by passing the channel type (ie ht20, ht40- or
>> ht40+). Default is to create a non HT IBSS.
>>
>> Signed-off-by: Benoit Papillault<benoit.papillault@free.fr>
>> ---
>> It is needed for upcoming patches regarding HT IBSS
>> ibss.c | 27 ++++++++++++++++++++++++++-
>> 1 files changed, 26 insertions(+), 1 deletions(-)
>>
>> diff --git a/ibss.c b/ibss.c
>> index 4715ac8..4003a38 100644
>> --- a/ibss.c
>> +++ b/ibss.c
>> @@ -18,6 +18,15 @@ static int join_ibss(struct nl80211_state *state,
>> {
>> char *end;
>> unsigned char abssid[6];
>> + int i;
>> + static const struct {
>> + const char *name;
>> + unsigned int val;
>> + } htmap[] = {
>> + { .name = "HT20", .val = NL80211_CHAN_HT20, },
>> + { .name = "HT40+", .val = NL80211_CHAN_HT40PLUS, },
>> + { .name = "HT40-", .val = NL80211_CHAN_HT40MINUS, },
>> + };
>
> There's code to do something like this already when setting the channel,
> please factor it out and use it in both places.
>
> johannes
>
Agreed. I did a copy/paste in the hurry, my bad.
I am going to post an update ASAP.
Regards,
Benoit
^ permalink raw reply
* Re: [RFC] ibss: Added channel type in order to create HT IBSS
From: Johannes Berg @ 2010-05-02 16:32 UTC (permalink / raw)
To: Benoit Papillault; +Cc: linux-wireless
In-Reply-To: <1272809528-11000-1-git-send-email-benoit.papillault@free.fr>
On Sun, 2010-05-02 at 16:12 +0200, Benoit Papillault wrote:
> When joining an IBSS, the parameters can be used to create the IBSS. As
> such, we need to know if the user wants to create an HT IBSS or not.
> This is accomplish by passing the channel type (ie ht20, ht40- or
> ht40+). Default is to create a non HT IBSS.
>
> Signed-off-by: Benoit Papillault <benoit.papillault@free.fr>
> ---
> It is needed for upcoming patches regarding HT IBSS
> ibss.c | 27 ++++++++++++++++++++++++++-
> 1 files changed, 26 insertions(+), 1 deletions(-)
>
> diff --git a/ibss.c b/ibss.c
> index 4715ac8..4003a38 100644
> --- a/ibss.c
> +++ b/ibss.c
> @@ -18,6 +18,15 @@ static int join_ibss(struct nl80211_state *state,
> {
> char *end;
> unsigned char abssid[6];
> + int i;
> + static const struct {
> + const char *name;
> + unsigned int val;
> + } htmap[] = {
> + { .name = "HT20", .val = NL80211_CHAN_HT20, },
> + { .name = "HT40+", .val = NL80211_CHAN_HT40PLUS, },
> + { .name = "HT40-", .val = NL80211_CHAN_HT40MINUS, },
> + };
There's code to do something like this already when setting the channel,
please factor it out and use it in both places.
johannes
^ permalink raw reply
* [RFC] ibss: Added channel type in order to create HT IBSS
From: Benoit Papillault @ 2010-05-02 14:12 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Benoit Papillault
When joining an IBSS, the parameters can be used to create the IBSS. As
such, we need to know if the user wants to create an HT IBSS or not.
This is accomplish by passing the channel type (ie ht20, ht40- or
ht40+). Default is to create a non HT IBSS.
Signed-off-by: Benoit Papillault <benoit.papillault@free.fr>
---
It is needed for upcoming patches regarding HT IBSS
ibss.c | 27 ++++++++++++++++++++++++++-
1 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/ibss.c b/ibss.c
index 4715ac8..4003a38 100644
--- a/ibss.c
+++ b/ibss.c
@@ -18,6 +18,15 @@ static int join_ibss(struct nl80211_state *state,
{
char *end;
unsigned char abssid[6];
+ int i;
+ static const struct {
+ const char *name;
+ unsigned int val;
+ } htmap[] = {
+ { .name = "HT20", .val = NL80211_CHAN_HT20, },
+ { .name = "HT40+", .val = NL80211_CHAN_HT40PLUS, },
+ { .name = "HT40-", .val = NL80211_CHAN_HT40MINUS, },
+ };
if (argc < 2)
return 1;
@@ -52,6 +61,22 @@ static int join_ibss(struct nl80211_state *state,
if (!argc)
return 0;
+ if (argc) {
+ for (i = 0; i < ARRAY_SIZE(htmap); i++) {
+ if (strcasecmp(htmap[i].name, argv[1]) == 0) {
+ NLA_PUT_U32(msg,
+ NL80211_ATTR_WIPHY_CHANNEL_TYPE,
+ htmap[i].val);
+ argv++;
+ argc--;
+ break;
+ }
+ }
+ }
+
+ if (!argc)
+ return 0;
+
if (strcmp(*argv, "key") != 0 && strcmp(*argv, "keys") != 0)
return 1;
@@ -73,7 +98,7 @@ static int leave_ibss(struct nl80211_state *state,
COMMAND(ibss, leave, NULL,
NL80211_CMD_LEAVE_IBSS, 0, CIB_NETDEV, leave_ibss,
"Leave the current IBSS cell.");
-COMMAND(ibss, join, "<SSID> <freq in MHz> [fixed-freq] [<fixed bssid>] [key d:0:abcde]",
+COMMAND(ibss, join, "<SSID> <freq in MHz> [HT20|HT40+|HT40-] [fixed-freq] [<fixed bssid>] [key d:0:abcde]",
NL80211_CMD_JOIN_IBSS, 0, CIB_NETDEV, join_ibss,
"Join the IBSS cell with the given SSID, if it doesn't exist create\n"
"it on the given frequency. When fixed frequency is requested, don't\n"
--
1.7.0.4
^ permalink raw reply related
* Re: ar9170-fw II
From: David H. Lynch Jr. @ 2010-05-02 13:47 UTC (permalink / raw)
To: Christian Lamparter, linux-wireless
In-Reply-To: <201005021452.01101.chunkeey@googlemail.com>
On 05/02/2010 08:52 AM, Christian Lamparter wrote:
>
>
>> If necessary I can measure the times myself as delta's from one
>> event to another withing the SH2.
>>
>> I have not digested the docs I have thoroughly yet but a cursory
>> review suggests a less than trivial project.
>> I have not yet found a good high resolution clock inside the ar9170
>> there are alot of clocks but they all seem to be 16bit. Probably that
>> will make things harder.
>>
> TSF timer could be used for this. (see 802.11-2007, Section 11 et seq.)
> It's a 2^64 bit timer with a 1us resolution and a accuracy _better_
> or equal to +/- 0.01%.
>
> The register address are at:
> - 0x1c3514 (low, AR9170_MAC_REG_TSF_L, read only)
> - 0x1c3518 (high, AR9170_MAC_REG_TSF_H, read only)
>
> But it comes at a small price: this timer is sometimes
> update& synchronized (802.11 11.1.3.4 and 11.1.4) in
> station or ad-hoc mode. The exact details are hidden
> inside MAC chip, but it should be possible to disable
> both by selecting the monitor mode.
>
I will have to look into that it might work.
I beleive this project is in ad-hoc mode,
but if the timer is not being altered between the transmission of a
packet and the receipt of its ACK I am fine,
the worst case would be that it is and delta T becomes artificially
smaller. One characteristic of my problem is that
almost all the error is positive delta T overly large.
>
>> I was expecting to have to make changes to the ar9170 firmware. I
>> was expecting to have to devise some means of passing that information
>> to the Linux driver and to the userspace application.
>>
> Well, then you have two more good reasons why to use carl9170:
>
> * the ar9170usb driver and ar9170 firmware don't track tx frames.
> carl9170 on the other hand does (every frame has a 8 bit "cookie").
> This feature was necessary to generate an accurate tx transmission
> feedback report for every individual frame for the driver.
>
That would be necescary in my application and I have started to work
with the carl9170 driver.
I built the toolchain compiler the firmware and I am building a
linux kernel right now.
> * carl9170 has the ability to store additional per-frame data.
> In fact, if you don't need to have a different retry rates
> you could realloc the 3 * 32 bit "rr" (as in retry rate)
> array in the carl9170_tx_superdesc and _carl9170_tx_superdesc
> struct (see wlan.h) for your purposes (storage for your time values).
>
> And if you fetched all the data, everything will be sent
> with an ordinary tx status feedback report to the application
> (add the timer fields into carl9170_tx_status and _carl9170_tx_status
> struct - see fwcmd.h)
>
I need a delta T between some fixed point during the send and some
fixed point during the ACK.
And the MAC address of the device I was sending to. The latter
already is obviously already known, I just have to tie to it.
>
> (* talked about this earlier, but you never know...
>
> carlu _tool_ already provides a low-level HW driver for userspace.
> This has the obvious advantage that you won't need to mess with
> the kernel driver and network stacks.
>
> The only work you'll have to do is: get the kernel code for
> the MAC& PHY initialization and put it into carlu.
> But the framework is already there so it's mostly copy + paste )
>
I beleive you are using DEBUGFS and that was already part of my spec.
Regardless, I am comfortable on the Linux driver side.
The closer I get to the Linux side the more comfortable I am.
Further though the actual timing of each send's delta T needs to be
as accurate and fine grained as possible,
everything else in this project is non-critical. Within reason it
is unimportant how long it takes to propigate data from the AR9170
through to userspace,
Clean and simple will take precedence over any other technical demands.
>> I would be happy to do that in some fashion that conformed to an existing
>> or future standard, but I was not anticipating a broad desire for what I am
>> doing. Variable latencies are highly undesirable in this application,
>> but the userspace application will be aggregating large amounts of
>> information, if latencies in what is measured are constrained and the
>> unit of time measurement is small enough everything will work.
>> If it comes to that we switch to different hardware, but my project
>> is bringing a concept that was demonstrated with an expensive SDR to an
>> ar9170.
>>
> It's always nice to have some "added value" for cheap and generic devices.
> e.g.: Atheros AR92xx chips can be used as among other stuff as a
> full range spectrum analyzer.
>
And my ability to get consulting work is strongly effected by the
extent I can contribute to Linux.
References, and lists of skills and qualifications on my web site
are dwarfed by
Dave Lynch, DLA Systems <dhlii@dlasys.net> appearing inside the
kernel tree.
I love this work. I love working for myself, I want to continue to
do so.
I would contribute as I can regardless, but self interest helps.
> Regards,
> Chr
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.587.7774 dhlii@dlasys.net http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: ar9170-fw II
From: Christian Lamparter @ 2010-05-02 12:52 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: Benoit Papillault, linux-wireless
In-Reply-To: <4BDD5EB3.7020802@dlasys.net>
On Sunday 02 May 2010 13:14:59 David H. Lynch Jr. wrote:
> On 05/02/2010 03:47 AM, Benoit Papillault wrote:
> > Le 01/05/2010 22:45, Christian Lamparter a écrit :
> >> On Saturday 01 May 2010 20:23:26 David H. Lynch Jr. wrote:
> >>> I think I can tell you what I am supposed add - I need to be able
> >>> to provide userspace apps with precise timing information for each
> >>> packet.
> >>> Since i am working on GPL'd code and the results are going to be
> >>> provided to third parties whatever I do is GPL'd too.
> >>
> >> if by precise timing you mean "exact mac time in TU/usecs when frame
> >> was received at the radio", then you might have a _problem_.
> >> You see, the firmware already receives fully packed frames from
> >> the MAC processor and only _forwards_ them all [as is] in
> >> one big DMA to the USB subsystem.
> >> (this is done in src/wlan.c handle_rx())
> >>
> >> So, unless the HW has a _magic_ flag to enable this capability...
> >> you are sort of screwed :-/.
> >
> > I would love this feature as well. I have a device to test if that can
> > help. I share the feeling of Christian however... but maybe your
> > documentation says something about a special flag.
> I am interested in round trip time as measured from some fixed point
> in the sending process to some fixed point in the packet acknowledgement.
> The more accurate the better. Preferably measured by events at the
> radio rather than on the linux side.
> I am interested in tx packets rather than rx packets.
ahh, well... there goes' benoit interest ;).
> If necessary I can measure the times myself as delta's from one
> event to another withing the SH2.
>
> I have not digested the docs I have thoroughly yet but a cursory
> review suggests a less than trivial project.
> I have not yet found a good high resolution clock inside the ar9170
> there are alot of clocks but they all seem to be 16bit. Probably that
> will make things harder.
TSF timer could be used for this. (see 802.11-2007, Section 11 et seq.)
It's a 2^64 bit timer with a 1us resolution and a accuracy _better_
or equal to +/- 0.01%.
The register address are at:
- 0x1c3514 (low, AR9170_MAC_REG_TSF_L, read only)
- 0x1c3518 (high, AR9170_MAC_REG_TSF_H, read only)
But it comes at a small price: this timer is sometimes
update & synchronized (802.11 11.1.3.4 and 11.1.4) in
station or ad-hoc mode. The exact details are hidden
inside MAC chip, but it should be possible to disable
both by selecting the monitor mode.
> I was expecting to have to make changes to the ar9170 firmware. I
> was expecting to have to devise some means of passing that information
> to the Linux driver and to the userspace application.
Well, then you have two more good reasons why to use carl9170:
* the ar9170usb driver and ar9170 firmware don't track tx frames.
carl9170 on the other hand does (every frame has a 8 bit "cookie").
This feature was necessary to generate an accurate tx transmission
feedback report for every individual frame for the driver.
* carl9170 has the ability to store additional per-frame data.
In fact, if you don't need to have a different retry rates
you could realloc the 3 * 32 bit "rr" (as in retry rate)
array in the carl9170_tx_superdesc and _carl9170_tx_superdesc
struct (see wlan.h) for your purposes (storage for your time values).
And if you fetched all the data, everything will be sent
with an ordinary tx status feedback report to the application
(add the timer fields into carl9170_tx_status and _carl9170_tx_status
struct - see fwcmd.h)
(* talked about this earlier, but you never know...
carlu _tool_ already provides a low-level HW driver for userspace.
This has the obvious advantage that you won't need to mess with
the kernel driver and network stacks.
The only work you'll have to do is: get the kernel code for
the MAC & PHY initialization and put it into carlu.
But the framework is already there so it's mostly copy + paste )
> I would be happy to do that in some fashion that conformed to an existing
> or future standard, but I was not anticipating a broad desire for what I am
> doing. Variable latencies are highly undesirable in this application,
> but the userspace application will be aggregating large amounts of
> information, if latencies in what is measured are constrained and the
> unit of time measurement is small enough everything will work.
> If it comes to that we switch to different hardware, but my project
> is bringing a concept that was demonstrated with an expensive SDR to an
> ar9170.
It's always nice to have some "added value" for cheap and generic devices.
e.g.: Atheros AR92xx chips can be used as among other stuff as a
full range spectrum analyzer.
Regards,
Chr
^ permalink raw reply
* Re: ar9170-fw II
From: David H. Lynch Jr. @ 2010-05-02 11:14 UTC (permalink / raw)
To: Benoit Papillault; +Cc: Christian Lamparter, linux-wireless
In-Reply-To: <4BDD2E05.40203@free.fr>
On 05/02/2010 03:47 AM, Benoit Papillault wrote:
> Le 01/05/2010 22:45, Christian Lamparter a écrit :
>> On Saturday 01 May 2010 20:23:26 David H. Lynch Jr. wrote:
>>> I think I can tell you what I am supposed add - I need to be able
>>> to provide userspace apps with precise timing information for each
>>> packet.
>>> Since i am working on GPL'd code and the results are going to be
>>> provided to third parties whatever I do is GPL'd too.
>>
>> if by precise timing you mean "exact mac time in TU/usecs when frame
>> was received at the radio", then you might have a _problem_.
>> You see, the firmware already receives fully packed frames from
>> the MAC processor and only _forwards_ them all [as is] in
>> one big DMA to the USB subsystem.
>> (this is done in src/wlan.c handle_rx())
>>
>> So, unless the HW has a _magic_ flag to enable this capability...
>> you are sort of screwed :-/.
>
> I would love this feature as well. I have a device to test if that can
> help. I share the feeling of Christian however... but maybe your
> documentation says something about a special flag.
I am interested in round trip time as measured from some fixed point
in the sending process to some fixed point in the packet acknowledgement.
The more accurate the better. Preferably measured by events at the
radio rather than on the linux side. I am interested in tx packets
rather than rx packets.
If necessary I can measure the times myself as delta's from one
event to another withing the SH2.
I have not digested the docs I have thoroughly yet but a cursory
review suggests a less than trivial project.
I have not yet found a good high resolution clock inside the ar9170
there are alot of clocks but they all seem to be 16bit. Probably that
will make things harder.
I was expecting to have to make changes to the ar9170 firmware. I
was expecting to have to devise some means of passing that information
to the Linux driver and to the userspace application. I would be happy
to do that in some fashion that conformed to an existing or future
standard, but I was not anticipating a broad desire for what I am
doing. Variable latencies are highly undesirable in this application,
but the userspace application will be aggregating large amounts of
information, if latencies in what is measured are constrained and the
unit of time measurement is small enough everything will work.
If it comes to that we switch to different hardware, but my project
is bringing a concept that was demonstrated with an expensive SDR to an
ar9170.
I am still coming up to speed on some aspects of Wireless - I am
not a complete noob, I have done ethernet drivers, and other very low
level work. I have also worked with non-802.11 wireless, and network
communications. But three days ago I had only cursory understanding of
how 802.11 works.
I already greatly appreciate your assistance.
>
> Regards,
> Benoit
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.587.7774 dhlii@dlasys.net http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: [PATCH] rtl8180: fix tx status reporting
From: Adrian Bassett @ 2010-05-02 9:02 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1272496482-12687-1-git-send-email-linville@tuxdriver.com>
John W. Linville <linville@...> writes:
>
> When reporting Tx status, indicate that only one rate was used.
> Otherwise, the rate is frozen at rate index 0 (i.e. 1Mb/s).
>
> Signed-off-by: John W. Linville <linville@...>
> ---
> drivers/net/wireless/rtl818x/rtl8180_dev.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/rtl818x/rtl8180_dev.c
b/drivers/net/wireless/rtl818x/rtl8180_dev.c
> index d84ad05..8487327 100644
> --- a/drivers/net/wireless/rtl818x/rtl8180_dev.c
> +++ b/drivers/net/wireless/rtl818x/rtl8180_dev.c
> @@ -188,6 +188,7 @@ static void rtl8180_handle_tx(struct ieee80211_hw *dev,
unsigned int prio)
> info->flags |= IEEE80211_TX_STAT_ACK;
>
> info->status.rates[0].count = (flags & 0xFF) + 1;
> + info->status.rates[1].idx = -1;
>
> ieee80211_tx_status_irqsafe(dev, skb);
> if (ring->entries - skb_queue_len(&ring->queue) == 2)
John,
I can confirm that this patch fixes the regression reported in the thread at
http://marc.info/?l=linux-wireless&m=123720659723688&w=2 so that the rtl8180
wireless driver and the minstrel rate controller now play together OK. I would
endorse the suggestion that this patch is backported to stable. Any chance of
late inclusion in 2.6.34?
Stats for info:
2.6.34-rc6-wl-00-47739-g27957c6
Rate control from /sys/kernel/debug/ieee80211/phy0/rc/name: minstrel
Stats from /sys/kernel/debug/ieee80211/phy0/stations/xx:xx:xx:xx:xx:xx/rc_stats
rate throughput ewma prob this prob this succ/attempt success attempts
P 1 0.9 98.1 100.0 0( 0) 137 142
2 1.8 95.7 100.0 0( 0) 11 11
5.5 4.8 95.7 100.0 0( 0) 11 11
11 9.1 95.7 100.0 0( 0) 11 11
6 5.4 95.9 100.0 0( 0) 18 20
9 8.0 95.2 100.0 0( 0) 14 16
12 10.5 95.3 100.0 0( 0) 13 14
18 15.5 95.2 100.0 0( 0) 21 28
24 20.3 95.4 100.0 0( 0) 65 110
t 36 24.8 81.5 100.0 0( 0) 443 600
T 48 34.7 89.0 100.0 1( 1) 5348 6735
54 17.8 41.1 25.0 0( 0) 16939 20381
Total packet count:: ideal 2794 lookaround 147
Thanks,
Adrian Bassett
^ permalink raw reply
* Re: ar9170-fw II
From: Benoit Papillault @ 2010-05-02 7:47 UTC (permalink / raw)
To: Christian Lamparter; +Cc: David H. Lynch Jr., linux-wireless
In-Reply-To: <201005012245.36589.chunkeey@googlemail.com>
Le 01/05/2010 22:45, Christian Lamparter a écrit :
> On Saturday 01 May 2010 20:23:26 David H. Lynch Jr. wrote:
>> I think I can tell you what I am supposed add - I need to be able
>> to provide userspace apps with precise timing information for each packet.
>> Since i am working on GPL'd code and the results are going to be
>> provided to third parties whatever I do is GPL'd too.
>
> if by precise timing you mean "exact mac time in TU/usecs when frame
> was received at the radio", then you might have a _problem_.
> You see, the firmware already receives fully packed frames from
> the MAC processor and only _forwards_ them all [as is] in
> one big DMA to the USB subsystem.
> (this is done in src/wlan.c handle_rx())
>
> So, unless the HW has a _magic_ flag to enable this capability...
> you are sort of screwed :-/.
I would love this feature as well. I have a device to test if that can
help. I share the feeling of Christian however... but maybe your
documentation says something about a special flag.
Regards,
Benoit
^ permalink raw reply
* Re: ar9170-fw II
From: Christian Lamparter @ 2010-05-01 20:45 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linux-wireless
In-Reply-To: <4BDC719E.3060505@dlasys.net>
On Saturday 01 May 2010 20:23:26 David H. Lynch Jr. wrote:
> On 05/01/2010 01:19 PM, Christian Lamparter wrote:
> >
> > Well, for starters the ar9170 uses a ZyDas MAC (aka ZD1221)
> > and a AR900x PHY/Radio. Therefore the phy code and registers
> > are very similar to those #definitions you can find in ath9k.
> > And for the MAC code& registers you can look into zd1211rw,
> > or look into drivers/staging/otus (original vendor driver,
> > shares some code with their windows drivers)
> >
> > AFAICT, there are no technical documents about the AR9170
> > solution available w/o signing a NDA with Atheros
> > (probably because the devices are still produced and sold in high quantities?).
> >
> Thanks;
>
> I did just discover a reasonably good 150p spec. In what I received from
> my client. If I can I will share it. I am under an NDA, but the client also
> told me that they received no cooperation from atheros.
hmm, only 150 pages? That's sounds a bit thin, as a matter of
fact I know that the ath5k docs (rf+mac+eeprom) are at least
around 300-400 pages.
Well, we'll see. But just in case, we already have a small
library of hardware docs (but most from different vendors):
http://wireless.kernel.org/en/developers/Documentation/specs
and we would welcome such an addition ;-)
> >> What is available for the ar9170 itself ?
> >> How does the firmware and the linux driver communicate?
> >> Is there an overview of the firmware - what is where ?
> >>
> > not really, apart from the headers of the original firmware
> > and vendor drivers.
> >
> > But if you really need to implement some of your 'features'
> > (what are they, if I may ask?)
>
> I think I can tell you what I am supposed add - I need to be able
> to provide userspace apps with precise timing information for each packet.
> Since i am working on GPL'd code and the results are going to be
> provided to third parties whatever I do is GPL'd too.
if by precise timing you mean "exact mac time in TU/usecs when frame
was received at the radio", then you might have a _problem_.
You see, the firmware already receives fully packed frames from
the MAC processor and only _forwards_ them all [as is] in
one big DMA to the USB subsystem.
(this is done in src/wlan.c handle_rx())
So, unless the HW has a _magic_ flag to enable this capability...
you are sort of screwed :-/.
> Why gets into the NDA.
> Right now i have an NDA with a new client and though I am
> exercising care. But they seem fairly mellow. I am probably just being
> overly cautious.
k, understood.
^ permalink raw reply
* Re: [PATCH] ssb: Implement fast powerup delay calculation
From: Gábor Stefanik @ 2010-05-01 18:43 UTC (permalink / raw)
To: Michael Buesch; +Cc: Larry Finger, John W. Linville, linux-wireless, b43-dev
In-Reply-To: <201005012040.42916.mb@bu3sch.de>
On Sat, May 1, 2010 at 8:40 PM, Michael Buesch <mb@bu3sch.de> wrote:
> On Saturday 01 May 2010 20:27:42 Larry Finger wrote:
>> OK, I changed the spec to remove the write.
>
> Uhm, I think the spec was perfecly fine.
>
> --
> Greetings, Michael.
>
Yes. The specs stated "do this during 802.11 core init", the problem
was the patch doing the write during ChipCommon init, much earlier.
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [PATCH] ssb: Implement fast powerup delay calculation
From: Michael Buesch @ 2010-05-01 18:40 UTC (permalink / raw)
To: Larry Finger
Cc: Gábor Stefanik, John W. Linville, linux-wireless, b43-dev
In-Reply-To: <4BDC729E.5060202@lwfinger.net>
On Saturday 01 May 2010 20:27:42 Larry Finger wrote:
> OK, I changed the spec to remove the write.
Uhm, I think the spec was perfecly fine.
--
Greetings, Michael.
^ permalink raw reply
* Re: Issues setting up a 5GHz 802.11N AP
From: Luis R. Rodriguez @ 2010-05-01 18:34 UTC (permalink / raw)
To: Joshua Smith; +Cc: linux-wireless
In-Reply-To: <7F414AFA-E125-40AD-A745-30AEC442B1E8@kaon.com>
On Thu, Apr 29, 2010 at 10:17 AM, Joshua Smith <jesmith@kaon.com> wrote:
> Hello! I hope this is the right mailing this for this question. If not, please redirect me as you see fit!
>
> I am trying to put together a Linux PC that can act as a 5 GHz 802.11N Access Point. I got a lot of conflicting info in my searches, so I figured I'd just buy some hardware and figure out what works.
>
> I am using this kernel:
>
> Linux vosk 2.6.27.8 #1 SMP Sun Dec 7 08:30:31 i686 Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz GenuineIntel GNU/Linux
>
> And I am using compat-wireless 2010-04-26 (complete build).
>
> So far, I have an Intel Wi-Fi Link 6300AGN:
>
> iwlagn 0000:07:00.0: Detected Intel(R) Centrino(R) Ultimate-N 6300 AGN, REV=0x74
>
> An Atheros-based Belkin N1 Wireless ExpressCard:
>
> phy1: Atheros AR5418 MAC/BB Rev:2 AR2122 RF Rev:81 mem=0xf9fa0000, irq=16
>
> And an RaLink-based Asus PCE-N13 PCI adapter:
>
> 03:00.0 Network controller: RaLink RT2860
>
> When I do 'iw list' for these three cards, I find:
>
> Intel: has 5GHz band, but does not support AP mode
> Atheros: supports AP mode, but does not show 5GHz band
> RaLink: supports AP mode, but does not show 5GHz band
>
> I think the Intel is correct. I've found many sources that say this chipset simply does not support AP/Master mode.
>
> However, both the Atheros and RaLink claim to support 300Mbps speeds, which I believe means they should have some 5Ghz channels, right?
No, if you see no 5GHz information with 'iw list' then it means your
cards do not support 5 GHz. Its a physical limitation of the actual
hardware. To support 5 GHz your card would need a 5 GHz radio, and it
simply does not come with one. For your Atheros card specifically the
output shows a AR2122 RF, this is a 2.4 GHz radio only.
Luis
^ permalink raw reply
* Re: [PATCH] ssb: Implement fast powerup delay calculation
From: Larry Finger @ 2010-05-01 18:27 UTC (permalink / raw)
To: Michael Buesch
Cc: Gábor Stefanik, John W. Linville, linux-wireless, b43-dev
In-Reply-To: <201005012015.50601.mb@bu3sch.de>
On 05/01/2010 01:15 PM, Michael Buesch wrote:
> On Saturday 01 May 2010 19:42:27 Larry Finger wrote:
>> I may have gotten the MMIO offset part wrong in the specs, but the
>> Broadcom driver definitely writes to offset 0x648 at that point.
>
> I do not think you are right.
>
> First: The write has to happen to the 802.11 core and not to the chipcommon core.
>
> Second: The code that was touched by Gábor is _very_ early in the SSB init.
> Way ahead of the wireless core init. The specs state that the delay value has to be written
> after the wireless core init is nearly done.
> We do _exactly_ that in b43.
>
> The only thing that needs to be done is to add the additional switch statement.
> No MMIO writes have to be touched.
OK, I changed the spec to remove the write.
Larry
^ permalink raw reply
* Re: ar9170-fw II
From: David H. Lynch Jr. @ 2010-05-01 18:23 UTC (permalink / raw)
To: Christian Lamparter, linux-wireless
In-Reply-To: <201005011919.32016.chunkeey@googlemail.com>
On 05/01/2010 01:19 PM, Christian Lamparter wrote:
>
> Well, for starters the ar9170 uses a ZyDas MAC (aka ZD1221)
> and a AR900x PHY/Radio. Therefore the phy code and registers
> are very similar to those #definitions you can find in ath9k.
> And for the MAC code& registers you can look into zd1211rw,
> or look into drivers/staging/otus (original vendor driver,
> shares some code with their windows drivers)
>
> AFAICT, there are no technical documents about the AR9170
> solution available w/o signing a NDA with Atheros
> (probably because the devices are still produced and sold in high quantities?).
>
Thanks;
I did just discover a reasonably good 150p spec. in what I
received from my client.
If I can I will share it. I am under an NDA, but the client
also told me that they received no cooperation from atheros.
>> What is available for the ar9170 itself ?
>> How does the firmware and the linux driver communicate?
>> Is there an overview of the firmware - what is where ?
>>
> not really, apart from the headers of the original firmware
> and vendor drivers.
>
> But if you really need to implement some of your 'features'
> (what are they, if I may ask?)
I think I can tell you what I am supposed add - I need to be able
to provide userspace apps with precise timing information for each packet.
Since i am working on GPL'd code and the results are going to be
provided to third parties whatever I do is GPL'd too.
Why gets into the NDA.
Right now i have an NDA with a new client and though I am
exercising care. But they seem fairly mellow. I am probably just being
overly cautious.
> into the firmware you could
> save some time by migrating to carl9170 code base:
> ( http://www.kernel.org/pub/linux/kernel/people/chr/carl9170/1.0.5
> + linville's wireless-testing.git )
>
The carl9170 code is the expected future of the ar9170 in Linux ?
If so that is where I want to be working.
> The advantages over the original firmware code (from a developers POV) are:
> * customizable/configurable fw
> + driver can auto detect all selected fw features
>
> * userspace testbench ( carlu ) for the usb subsystem
> (allows you to run usb stress-test, dump the device's eeprom content
> to stdout and of course: you can implement your own routines
> and test& develop without crashing the kernel)
>
> * all hardware& firmware interface definitions are all located
> in a single directory /include/shared/*.h
>
> version.h - carl9170 API/ABI version
> eeprom.h - eeprom layout
> phy.h - AR900x PHY/Radio definitions
> fwcmd.h - implemented firmware commands
> fwdesc.h - layout of the firmware descriptor (e.g. available/activated features)
> hw.h - ZD1221 MAC + (Faraday USB) definitions
> wlan.h - (part of hw.h& phy.h) contains all the information about
> tx& rx frame formats.
>
> * (tiny) printf + hexdump (obviously, you want those ;-) )
>
> * follows linux' kernel coding style :-D
>
Thanks alot.
I will look seriously at that.
While I want to keep the scope of what I am doing small, and as
narrowly confined as a I can,
it would be nice if atleast some of my work was useful beyond the
unique needs of my client.
> Regards,
> Chr
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.587.7774 dhlii@dlasys.net http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: [PATCH] ssb: Implement fast powerup delay calculation
From: Michael Buesch @ 2010-05-01 18:15 UTC (permalink / raw)
To: Larry Finger
Cc: Gábor Stefanik, John W. Linville, linux-wireless, b43-dev
In-Reply-To: <4BDC6803.9030805@lwfinger.net>
On Saturday 01 May 2010 19:42:27 Larry Finger wrote:
> I may have gotten the MMIO offset part wrong in the specs, but the
> Broadcom driver definitely writes to offset 0x648 at that point.
I do not think you are right.
First: The write has to happen to the 802.11 core and not to the chipcommon core.
Second: The code that was touched by Gábor is _very_ early in the SSB init.
Way ahead of the wireless core init. The specs state that the delay value has to be written
after the wireless core init is nearly done.
We do _exactly_ that in b43.
The only thing that needs to be done is to add the additional switch statement.
No MMIO writes have to be touched.
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH] ssb: Implement fast powerup delay calculation
From: Gábor Stefanik @ 2010-05-01 17:48 UTC (permalink / raw)
To: Larry Finger; +Cc: Michael Buesch, John W. Linville, linux-wireless, b43-dev
In-Reply-To: <4BDC6803.9030805@lwfinger.net>
On Sat, May 1, 2010 at 7:42 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 05/01/2010 12:19 PM, Michael Buesch wrote:
>> On Saturday 01 May 2010 19:13:31 Gábor Stefanik wrote:
>>> 2010/5/1 Michael Buesch <mb@bu3sch.de>:
>>>> On Saturday 01 May 2010 18:29:06 Gábor Stefanik wrote:
>>>>> + ssb_write16(cc->dev, SSB_MMIO_POWERUP_DELAY, delay);
>>>>> }
>>>>>
>>>>> void ssb_chipco_suspend(struct ssb_chipcommon *cc)
>>>>> Index: wireless-testing/include/linux/ssb/ssb_regs.h
>>>>> ===================================================================
>>>>> --- wireless-testing.orig/include/linux/ssb/ssb_regs.h
>>>>> +++ wireless-testing/include/linux/ssb/ssb_regs.h
>>>>> @@ -26,6 +26,7 @@
>>>>> #define SSB_EUART (SSB_EXTIF_BASE + 0x00800000)
>>>>> #define SSB_LED (SSB_EXTIF_BASE + 0x00900000)
>>>>>
>>>>> +#define SSB_MMIO_POWERUP_DELAY 0x06A8
>>>>
>>>> I think you are really confusing something here.
>>>> That register is a wireless core register and we already write it in b43.
>>>>
>>>> --
>>>> Greetings, Michael.
>>>>
>>>
>>> This is what I am implementing: http://bcm-v4.sipsolutions.net/802.11/Init
>>> Here, it clearly says MMIO offset.
>>
>> Yeah. Just what I said. It is an 802.11 core register.
>> We already write it in b43/main.c/b43_chip_init().
>> It is _wrong_ to write to the chipcommon at that offset.
>
> I may have gotten the MMIO offset part wrong in the specs, but the
> Broadcom driver definitely writes to offset 0x648 at that point.
>
> I know that b43 writes that location; however, it is much later in the
> startup sequence. Whether that is important is unknown at this point.
>
> The previous code resulted in a value of zero being written to the
> location in question, but the value for the 4315 is 7000.
>
> Larry
>
According to http://bcm-v4.sipsolutions.net/802.11/Init, b43 is right
- the write should go to the 802.11 core, not ChipCommon.
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [PATCH] ssb: Implement fast powerup delay calculation
From: Larry Finger @ 2010-05-01 17:42 UTC (permalink / raw)
To: Michael Buesch
Cc: Gábor Stefanik, John W. Linville, linux-wireless, b43-dev
In-Reply-To: <201005011919.42294.mb@bu3sch.de>
On 05/01/2010 12:19 PM, Michael Buesch wrote:
> On Saturday 01 May 2010 19:13:31 Gábor Stefanik wrote:
>> 2010/5/1 Michael Buesch <mb@bu3sch.de>:
>>> On Saturday 01 May 2010 18:29:06 Gábor Stefanik wrote:
>>>> + ssb_write16(cc->dev, SSB_MMIO_POWERUP_DELAY, delay);
>>>> }
>>>>
>>>> void ssb_chipco_suspend(struct ssb_chipcommon *cc)
>>>> Index: wireless-testing/include/linux/ssb/ssb_regs.h
>>>> ===================================================================
>>>> --- wireless-testing.orig/include/linux/ssb/ssb_regs.h
>>>> +++ wireless-testing/include/linux/ssb/ssb_regs.h
>>>> @@ -26,6 +26,7 @@
>>>> #define SSB_EUART (SSB_EXTIF_BASE + 0x00800000)
>>>> #define SSB_LED (SSB_EXTIF_BASE + 0x00900000)
>>>>
>>>> +#define SSB_MMIO_POWERUP_DELAY 0x06A8
>>>
>>> I think you are really confusing something here.
>>> That register is a wireless core register and we already write it in b43.
>>>
>>> --
>>> Greetings, Michael.
>>>
>>
>> This is what I am implementing: http://bcm-v4.sipsolutions.net/802.11/Init
>> Here, it clearly says MMIO offset.
>
> Yeah. Just what I said. It is an 802.11 core register.
> We already write it in b43/main.c/b43_chip_init().
> It is _wrong_ to write to the chipcommon at that offset.
I may have gotten the MMIO offset part wrong in the specs, but the
Broadcom driver definitely writes to offset 0x648 at that point.
I know that b43 writes that location; however, it is much later in the
startup sequence. Whether that is important is unknown at this point.
The previous code resulted in a value of zero being written to the
location in question, but the value for the 4315 is 7000.
Larry
^ permalink raw reply
* Re: [PATCH] ssb: Implement fast powerup delay calculation
From: Gábor Stefanik @ 2010-05-01 17:19 UTC (permalink / raw)
To: Michael Buesch; +Cc: John W. Linville, linux-wireless, b43-dev, Larry Finger
In-Reply-To: <AANLkTimXBlIETHVLapuSrkI8uTIU8JPepLWvAEq6_D4T@mail.gmail.com>
2010/5/1 Gábor Stefanik <netrolller.3d@gmail.com>:
> 2010/5/1 Michael Buesch <mb@bu3sch.de>:
>> On Saturday 01 May 2010 18:29:06 Gábor Stefanik wrote:
>>> + ssb_write16(cc->dev, SSB_MMIO_POWERUP_DELAY, delay);
>>> }
>>>
>>> void ssb_chipco_suspend(struct ssb_chipcommon *cc)
>>> Index: wireless-testing/include/linux/ssb/ssb_regs.h
>>> ===================================================================
>>> --- wireless-testing.orig/include/linux/ssb/ssb_regs.h
>>> +++ wireless-testing/include/linux/ssb/ssb_regs.h
>>> @@ -26,6 +26,7 @@
>>> #define SSB_EUART (SSB_EXTIF_BASE + 0x00800000)
>>> #define SSB_LED (SSB_EXTIF_BASE + 0x00900000)
>>>
>>> +#define SSB_MMIO_POWERUP_DELAY 0x06A8
>>
>> I think you are really confusing something here.
>> That register is a wireless core register and we already write it in b43.
>>
>> --
>> Greetings, Michael.
>>
>
> This is what I am implementing: http://bcm-v4.sipsolutions.net/802.11/Init
> Here, it clearly says MMIO offset.
>
> --
> Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
>
Sorry, now I understand. The MMIO write is unnecessary.
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [PATCH] ssb: Implement fast powerup delay calculation
From: Michael Buesch @ 2010-05-01 17:19 UTC (permalink / raw)
To: Gábor Stefanik
Cc: John W. Linville, linux-wireless, b43-dev, Larry Finger
In-Reply-To: <AANLkTimXBlIETHVLapuSrkI8uTIU8JPepLWvAEq6_D4T@mail.gmail.com>
On Saturday 01 May 2010 19:13:31 Gábor Stefanik wrote:
> 2010/5/1 Michael Buesch <mb@bu3sch.de>:
> > On Saturday 01 May 2010 18:29:06 Gábor Stefanik wrote:
> >> + ssb_write16(cc->dev, SSB_MMIO_POWERUP_DELAY, delay);
> >> }
> >>
> >> void ssb_chipco_suspend(struct ssb_chipcommon *cc)
> >> Index: wireless-testing/include/linux/ssb/ssb_regs.h
> >> ===================================================================
> >> --- wireless-testing.orig/include/linux/ssb/ssb_regs.h
> >> +++ wireless-testing/include/linux/ssb/ssb_regs.h
> >> @@ -26,6 +26,7 @@
> >> #define SSB_EUART (SSB_EXTIF_BASE + 0x00800000)
> >> #define SSB_LED (SSB_EXTIF_BASE + 0x00900000)
> >>
> >> +#define SSB_MMIO_POWERUP_DELAY 0x06A8
> >
> > I think you are really confusing something here.
> > That register is a wireless core register and we already write it in b43.
> >
> > --
> > Greetings, Michael.
> >
>
> This is what I am implementing: http://bcm-v4.sipsolutions.net/802.11/Init
> Here, it clearly says MMIO offset.
Yeah. Just what I said. It is an 802.11 core register.
We already write it in b43/main.c/b43_chip_init().
It is _wrong_ to write to the chipcommon at that offset.
--
Greetings, Michael.
^ permalink raw reply
* Re: ar9170-fw II
From: Christian Lamparter @ 2010-05-01 17:19 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linux-wireless
In-Reply-To: <4BDC001F.9050202@dlasys.net>
On Saturday 01 May 2010 12:19:11 David H. Lynch Jr. wrote:
> I have ethernet driver experience but not wifi. I have a project to
> add some features to the ar9170 that will require additions to the
> firmware. I would appreciate pointers for docs etc. to get me started.
Well, for starters the ar9170 uses a ZyDas MAC (aka ZD1221)
and a AR900x PHY/Radio. Therefore the phy code and registers
are very similar to those #definitions you can find in ath9k.
And for the MAC code & registers you can look into zd1211rw,
or look into drivers/staging/otus (original vendor driver,
shares some code with their windows drivers)
AFAICT, there are no technical documents about the AR9170
solution available w/o signing a NDA with Atheros
(probably because the devices are still produced and sold in high quantities?).
> What is available for the ar9170 itself ?
> How does the firmware and the linux driver communicate?
> Is there an overview of the firmware - what is where ?
not really, apart from the headers of the original firmware
and vendor drivers.
But if you really need to implement some of your 'features'
(what are they, if I may ask?) into the firmware you could
save some time by migrating to carl9170 code base:
( http://www.kernel.org/pub/linux/kernel/people/chr/carl9170/1.0.5
+ linville's wireless-testing.git )
The advantages over the original firmware code (from a developers POV) are:
* customizable/configurable fw
+ driver can auto detect all selected fw features
* userspace testbench ( carlu ) for the usb subsystem
(allows you to run usb stress-test, dump the device's eeprom content
to stdout and of course: you can implement your own routines
and test & develop without crashing the kernel)
* all hardware & firmware interface definitions are all located
in a single directory /include/shared/*.h
version.h - carl9170 API/ABI version
eeprom.h - eeprom layout
phy.h - AR900x PHY/Radio definitions
fwcmd.h - implemented firmware commands
fwdesc.h - layout of the firmware descriptor (e.g. available/activated features)
hw.h - ZD1221 MAC + (Faraday USB) definitions
wlan.h - (part of hw.h & phy.h) contains all the information about
tx & rx frame formats.
* (tiny) printf + hexdump (obviously, you want those ;-) )
* follows linux' kernel coding style :-D
Regards,
Chr
^ permalink raw reply
* Re: [PATCH] ssb: Implement fast powerup delay calculation
From: Gábor Stefanik @ 2010-05-01 17:13 UTC (permalink / raw)
To: Michael Buesch; +Cc: John W. Linville, linux-wireless, b43-dev, Larry Finger
In-Reply-To: <201005011907.05603.mb@bu3sch.de>
2010/5/1 Michael Buesch <mb@bu3sch.de>:
> On Saturday 01 May 2010 18:29:06 Gábor Stefanik wrote:
>> + ssb_write16(cc->dev, SSB_MMIO_POWERUP_DELAY, delay);
>> }
>>
>> void ssb_chipco_suspend(struct ssb_chipcommon *cc)
>> Index: wireless-testing/include/linux/ssb/ssb_regs.h
>> ===================================================================
>> --- wireless-testing.orig/include/linux/ssb/ssb_regs.h
>> +++ wireless-testing/include/linux/ssb/ssb_regs.h
>> @@ -26,6 +26,7 @@
>> #define SSB_EUART (SSB_EXTIF_BASE + 0x00800000)
>> #define SSB_LED (SSB_EXTIF_BASE + 0x00900000)
>>
>> +#define SSB_MMIO_POWERUP_DELAY 0x06A8
>
> I think you are really confusing something here.
> That register is a wireless core register and we already write it in b43.
>
> --
> Greetings, Michael.
>
This is what I am implementing: http://bcm-v4.sipsolutions.net/802.11/Init
Here, it clearly says MMIO offset.
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* [RFC] mac80211: radiotap vendor data
From: Johannes Berg @ 2010-05-01 17:13 UTC (permalink / raw)
To: linux-wireless
This allows drivers to add radiotap vendor data
to any received frame, which will be simply
passed into userspace and ignored by the kernel.
Can be used by drivers to convey hw-specific
information.
Note: 11n shouldn't be done there, in case somebody
got ideas!!
Note: didn't test this after the paged RX changes
---
drivers/net/wireless/mac80211_hwsim.c | 17 ++++++++++
include/net/mac80211.h | 12 +++++++
net/mac80211/rx.c | 53 ++++++++++++++++++++++++++++++----
3 files changed, 77 insertions(+), 5 deletions(-)
--- wireless-testing.orig/include/net/mac80211.h 2010-05-01 08:46:26.000000000 +0200
+++ wireless-testing/include/net/mac80211.h 2010-05-01 08:47:54.000000000 +0200
@@ -565,6 +565,13 @@ enum mac80211_rx_flags {
* @rate_idx: index of data rate into band's supported rates or MCS index if
* HT rates are use (RX_FLAG_HT)
* @flag: %RX_FLAG_*
+ * @vendor_radiotap_bitmap: radiotap vendor namespace presence bitmap
+ * @vendor_radiotap_len: radiotap vendor namespace length
+ * @vendor_radiotap_align: radiotap vendor namespace alignment. Note
+ * that the actual data must be at the start of the SKB data
+ * already.
+ * @vendor_radiotap_oui: radiotap vendor namespace OUI
+ * @vendor_radiotap_subns: radiotap vendor sub namespace
*/
struct ieee80211_rx_status {
u64 mactime;
@@ -575,6 +582,11 @@ struct ieee80211_rx_status {
int antenna;
int rate_idx;
int flag;
+ u32 vendor_radiotap_bitmap;
+ u16 vendor_radiotap_len;
+ u8 vendor_radiotap_align;
+ u8 vendor_radiotap_oui[3];
+ u8 vendor_radiotap_subns;
};
/**
--- wireless-testing.orig/net/mac80211/rx.c 2010-05-01 08:46:26.000000000 +0200
+++ wireless-testing/net/mac80211/rx.c 2010-05-01 08:47:54.000000000 +0200
@@ -37,6 +37,8 @@
static struct sk_buff *remove_monitor_info(struct ieee80211_local *local,
struct sk_buff *skb)
{
+ struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(skb);
+
if (local->hw.flags & IEEE80211_HW_RX_INCLUDES_FCS) {
if (likely(skb->len > FCS_LEN))
__pskb_trim(skb, skb->len - FCS_LEN);
@@ -48,6 +50,9 @@ static struct sk_buff *remove_monitor_in
}
}
+ if (status->vendor_radiotap_len)
+ __pskb_pull(skb, status->vendor_radiotap_len);
+
return skb;
}
@@ -69,8 +74,8 @@ static inline int should_drop_frame(stru
}
static int
-ieee80211_rx_radiotap_len(struct ieee80211_local *local,
- struct ieee80211_rx_status *status)
+ieee80211_rx_radiotap_space(struct ieee80211_local *local,
+ struct ieee80211_rx_status *status)
{
int len;
@@ -87,6 +92,21 @@ ieee80211_rx_radiotap_len(struct ieee802
if (len & 1) /* padding for RX_FLAGS if necessary */
len++;
+ if (status->vendor_radiotap_len) {
+ /* allocate extra bitmap */
+ len += 4;
+
+ if (WARN_ON(status->vendor_radiotap_align == 0))
+ status->vendor_radiotap_align = 1;
+ /* align standard part of vendor namespace */
+ len = ALIGN(len, 2);
+ /* allocate standard part of vendor namespace */
+ len += 6;
+ /* align vendor-defined part */
+ len = ALIGN(len, status->vendor_radiotap_align);
+ /* vendor-defined part is already in skb */
+ }
+
return len;
}
@@ -115,10 +135,18 @@ ieee80211_add_rx_radiotap_header(struct
(1 << IEEE80211_RADIOTAP_CHANNEL) |
(1 << IEEE80211_RADIOTAP_ANTENNA) |
(1 << IEEE80211_RADIOTAP_RX_FLAGS));
- rthdr->it_len = cpu_to_le16(rtap_len);
+ rthdr->it_len = cpu_to_le16(rtap_len + status->vendor_radiotap_len);
pos = (unsigned char *)(rthdr+1);
+ if (status->vendor_radiotap_len) {
+ rthdr->it_present |=
+ cpu_to_le32(BIT(IEEE80211_RADIOTAP_VENDOR_NAMESPACE)) |
+ cpu_to_le32(BIT(IEEE80211_RADIOTAP_EXT));
+ put_unaligned_le32(status->vendor_radiotap_bitmap, pos);
+ pos += 4;
+ }
+
/* the order of the following fields is important */
/* IEEE80211_RADIOTAP_TSFT */
@@ -190,11 +218,26 @@ ieee80211_add_rx_radiotap_header(struct
/* IEEE80211_RADIOTAP_RX_FLAGS */
/* ensure 2 byte alignment for the 2 byte field as required */
if ((pos - (u8 *)rthdr) & 1)
- pos++;
+ *pos++ = 0;
if (status->flag & RX_FLAG_FAILED_PLCP_CRC)
rx_flags |= IEEE80211_RADIOTAP_F_RX_BADPLCP;
put_unaligned_le16(rx_flags, pos);
pos += 2;
+
+ if (status->vendor_radiotap_len) {
+ /* ensure 2 byte alignment for the vendor field as required */
+ if ((pos - (u8 *)rthdr) & 1)
+ *pos++ = 0;
+ *pos++ = status->vendor_radiotap_oui[0];
+ *pos++ = status->vendor_radiotap_oui[1];
+ *pos++ = status->vendor_radiotap_oui[2];
+ *pos++ = status->vendor_radiotap_subns;
+ put_unaligned_le16(status->vendor_radiotap_len, pos);
+ pos += 2;
+ /* align the actual payload as requested */
+ while ((pos - (u8 *)rthdr) & (status->vendor_radiotap_align - 1))
+ *pos++ = 0;
+ }
}
/*
@@ -223,7 +266,7 @@ ieee80211_rx_monitor(struct ieee80211_lo
*/
/* room for the radiotap header based on driver features */
- needed_headroom = ieee80211_rx_radiotap_len(local, status);
+ needed_headroom = ieee80211_rx_radiotap_space(local, status);
if (local->hw.flags & IEEE80211_HW_RX_INCLUDES_FCS)
present_fcs_len = FCS_LEN;
--- wireless-testing.orig/drivers/net/wireless/mac80211_hwsim.c 2010-05-01 08:46:27.000000000 +0200
+++ wireless-testing/drivers/net/wireless/mac80211_hwsim.c 2010-05-01 19:04:57.000000000 +0200
@@ -484,6 +484,7 @@ static bool mac80211_hwsim_tx_frame(stru
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct ieee80211_rx_status rx_status;
+ u8 *vendor_data;
if (data->idle) {
printk(KERN_DEBUG "%s: Trying to TX when idle - reject\n",
@@ -509,6 +510,20 @@ static bool mac80211_hwsim_tx_frame(stru
secpath_reset(skb);
nf_reset(skb);
+ vendor_data = skb_push(skb, 4);
+ rx_status.vendor_radiotap_len = 4;
+ rx_status.vendor_radiotap_align = 4;
+ rx_status.vendor_radiotap_oui[0] = 0xff;
+ rx_status.vendor_radiotap_oui[1] = 0xff;
+ rx_status.vendor_radiotap_oui[2] = 0xff;
+ rx_status.vendor_radiotap_subns = 129;
+ rx_status.vendor_radiotap_bitmap = 0x1;
+
+ *vendor_data++ = 1;
+ *vendor_data++ = 2;
+ *vendor_data++ = 3;
+ *vendor_data++ = 4;
+
/* Copy skb to all enabled radios that are on the current frequency */
spin_lock(&hwsim_radio_lock);
list_for_each_entry(data2, &hwsim_radios, list) {
@@ -535,6 +550,8 @@ static bool mac80211_hwsim_tx_frame(stru
}
spin_unlock(&hwsim_radio_lock);
+ skb_pull(skb, 4);
+
return ack;
}
^ permalink raw reply
* Re: [PATCH] ssb: Implement fast powerup delay calculation
From: Michael Buesch @ 2010-05-01 17:07 UTC (permalink / raw)
To: Gábor Stefanik
Cc: John W. Linville, linux-wireless, b43-dev, Larry Finger
In-Reply-To: <4BDC56D2.5060605@gmail.com>
On Saturday 01 May 2010 18:29:06 Gábor Stefanik wrote:
> + ssb_write16(cc->dev, SSB_MMIO_POWERUP_DELAY, delay);
> }
>
> void ssb_chipco_suspend(struct ssb_chipcommon *cc)
> Index: wireless-testing/include/linux/ssb/ssb_regs.h
> ===================================================================
> --- wireless-testing.orig/include/linux/ssb/ssb_regs.h
> +++ wireless-testing/include/linux/ssb/ssb_regs.h
> @@ -26,6 +26,7 @@
> #define SSB_EUART (SSB_EXTIF_BASE + 0x00800000)
> #define SSB_LED (SSB_EXTIF_BASE + 0x00900000)
>
> +#define SSB_MMIO_POWERUP_DELAY 0x06A8
I think you are really confusing something here.
That register is a wireless core register and we already write it in b43.
--
Greetings, Michael.
^ permalink raw reply
* [PATCH] mac80211: allow controlling aggregation manually
From: Johannes Berg @ 2010-05-01 16:53 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
This allows enabling TX and disabling both TX and
RX aggregation sessions manually in debugfs. It is
very useful for debugging session initiation and
teardown problems since with this you don't have
to force a lot of traffic to get aggregation and
thus have less data to analyse.
Also, to debug mac80211 code itself, make hwsim
"support" aggregation sessions. It will still just
transfer the frame, but go through the setup and
teardown handshakes.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
Ok so I do want it in the tree... had another
situation where I needed it and don't want to
have to patch all the time.
Unless anyone objects?
drivers/net/wireless/mac80211_hwsim.c | 3 +
net/mac80211/debugfs_sta.c | 65 +++++++++++++++++++++++++++++++++-
2 files changed, 66 insertions(+), 2 deletions(-)
--- wireless-testing.orig/drivers/net/wireless/mac80211_hwsim.c 2010-05-01 08:47:54.000000000 +0200
+++ wireless-testing/drivers/net/wireless/mac80211_hwsim.c 2010-05-01 08:47:56.000000000 +0200
@@ -1317,7 +1317,8 @@ static int __init init_mac80211_hwsim(vo
hw->flags = IEEE80211_HW_MFP_CAPABLE |
IEEE80211_HW_SIGNAL_DBM |
IEEE80211_HW_SUPPORTS_STATIC_SMPS |
- IEEE80211_HW_SUPPORTS_DYNAMIC_SMPS;
+ IEEE80211_HW_SUPPORTS_DYNAMIC_SMPS |
+ IEEE80211_HW_AMPDU_AGGREGATION;
/* ask mac80211 to reserve space for magic */
hw->vif_data_size = sizeof(struct hwsim_vif_priv);
--- wireless-testing.orig/net/mac80211/debugfs_sta.c 2010-05-01 08:46:26.000000000 +0200
+++ wireless-testing/net/mac80211/debugfs_sta.c 2010-05-01 08:47:56.000000000 +0200
@@ -39,6 +39,13 @@ static const struct file_operations sta_
.open = mac80211_open_file_generic, \
}
+#define STA_OPS_RW(name) \
+static const struct file_operations sta_ ##name## _ops = { \
+ .read = sta_##name##_read, \
+ .write = sta_##name##_write, \
+ .open = mac80211_open_file_generic, \
+}
+
#define STA_FILE(name, field, format) \
STA_READ_##format(name, field) \
STA_OPS(name)
@@ -156,7 +163,63 @@ static ssize_t sta_agg_status_read(struc
return simple_read_from_buffer(userbuf, count, ppos, buf, p - buf);
}
-STA_OPS(agg_status);
+
+static ssize_t sta_agg_status_write(struct file *file, const char __user *userbuf,
+ size_t count, loff_t *ppos)
+{
+ char _buf[12], *buf = _buf;
+ struct sta_info *sta = file->private_data;
+ bool start, tx;
+ unsigned long tid;
+ int ret;
+
+ if (count > sizeof(_buf))
+ return -EINVAL;
+
+ if (copy_from_user(buf, userbuf, count))
+ return -EFAULT;
+
+ buf[sizeof(_buf) - 1] = '\0';
+
+ if (strncmp(buf, "tx ", 3) == 0) {
+ buf += 3;
+ tx = true;
+ } else if (strncmp(buf, "rx ", 3) == 0) {
+ buf += 3;
+ tx = false;
+ } else
+ return -EINVAL;
+
+ if (strncmp(buf, "start ", 6) == 0) {
+ buf += 6;
+ start = true;
+ if (!tx)
+ return -EINVAL;
+ } else if (strncmp(buf, "stop ", 5) == 0) {
+ buf += 5;
+ start = false;
+ } else
+ return -EINVAL;
+
+ tid = simple_strtoul(buf, NULL, 0);
+
+ if (tid >= STA_TID_NUM)
+ return -EINVAL;
+
+ if (tx) {
+ if (start)
+ ret = ieee80211_start_tx_ba_session(&sta->sta, tid);
+ else
+ ret = ieee80211_stop_tx_ba_session(&sta->sta, tid,
+ WLAN_BACK_RECIPIENT);
+ } else {
+ __ieee80211_stop_rx_ba_session(sta, tid, WLAN_BACK_RECIPIENT, 3);
+ ret = 0;
+ }
+
+ return ret ?: count;
+}
+STA_OPS_RW(agg_status);
static ssize_t sta_ht_capa_read(struct file *file, char __user *userbuf,
size_t count, loff_t *ppos)
^ permalink raw reply
* Re: [PATCH] ssb: Implement fast powerup delay calculation
From: Gábor Stefanik @ 2010-05-01 16:32 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, b43-dev, Michael Buesch, Larry Finger
In-Reply-To: <4BDC56D2.5060605@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 660 bytes --]
2010/5/1 Gábor Stefanik <netrolller.3d@gmail.com>:
> Implement fast powerup delay calculation, as described
> in the recently updated specs. The 4325 part is coming soon.
>
> Signed-off-by: Gábor Stefanik<netrolller.3d@gmail.com>
> ---
>
> To people experiencing DMA errors: please test this patch, it touches
> the PMU code, one of the suspected problem areas.
>
> I'm submitting this patch using Thunderbird 3; so I cannot be held liable
> if it gets damaged in transit. Blame Mozilla. :-)
Apparently the nasty space-doubling issue seen in the Tb3 beta is
still present in the final version... here is the patch as an
attachment.
--Gábor
[-- Attachment #2: ssb_fast_pwrup_delay.patch --]
[-- Type: application/octet-stream, Size: 2489 bytes --]
Implement fast powerup delay calculation, as described
in the recently updated specs. The 4325 part is coming soon.
Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
---
Index: wireless-testing/drivers/ssb/driver_chipcommon.c
===================================================================
--- wireless-testing.orig/drivers/ssb/driver_chipcommon.c
+++ wireless-testing/drivers/ssb/driver_chipcommon.c
@@ -209,7 +209,24 @@ static void chipco_powercontrol_init(str
}
}
-static void calc_fast_powerup_delay(struct ssb_chipcommon *cc)
+static u16 pmu_fast_powerup_delay(struct ssb_chipcommon *cc)
+{
+ struct ssb_bus *bus = cc->dev->bus;
+
+ switch (bus->chip_id) {
+ case 0x4312:
+ case 0x4322:
+ case 0x4328:
+ return 7000;
+ case 0x4325:
+ /* TODO: */
+ default:
+ break;
+ }
+ return 15000;
+}
+
+static u16 calc_fast_powerup_delay(struct ssb_chipcommon *cc)
{
struct ssb_bus *bus = cc->dev->bus;
int minfreq;
@@ -217,26 +234,33 @@ static void calc_fast_powerup_delay(stru
u32 pll_on_delay;
if (bus->bustype != SSB_BUSTYPE_PCI)
- return;
+ return 0;
+ if (cc->capabilities & SSB_CHIPCO_CAP_PMU)
+ return pmu_fast_powerup_delay(cc);
if (!(cc->capabilities & SSB_CHIPCO_CAP_PCTL))
- return;
+ return 0;
minfreq = chipco_pctl_clockfreqlimit(cc, 0);
pll_on_delay = chipco_read32(cc, SSB_CHIPCO_PLLONDELAY);
tmp = (((pll_on_delay + 2) * 1000000) + (minfreq - 1)) / minfreq;
SSB_WARN_ON(tmp & ~0xFFFF);
- cc->fast_pwrup_delay = tmp;
+ return tmp;
}
void ssb_chipcommon_init(struct ssb_chipcommon *cc)
{
+ u16 delay;
+
if (!cc->dev)
return; /* We don't have a ChipCommon */
ssb_pmu_init(cc);
chipco_powercontrol_init(cc);
ssb_chipco_set_clockmode(cc, SSB_CLKMODE_FAST);
- calc_fast_powerup_delay(cc);
+ delay = calc_fast_powerup_delay(cc);
+ ssb_printk(KERN_INFO PFX "fast_pwrup_delay is %d\n", delay);
+ cc->fast_pwrup_delay = delay;
+ ssb_write16(cc->dev, SSB_MMIO_POWERUP_DELAY, delay);
}
void ssb_chipco_suspend(struct ssb_chipcommon *cc)
Index: wireless-testing/include/linux/ssb/ssb_regs.h
===================================================================
--- wireless-testing.orig/include/linux/ssb/ssb_regs.h
+++ wireless-testing/include/linux/ssb/ssb_regs.h
@@ -26,6 +26,7 @@
#define SSB_EUART (SSB_EXTIF_BASE + 0x00800000)
#define SSB_LED (SSB_EXTIF_BASE + 0x00900000)
+#define SSB_MMIO_POWERUP_DELAY 0x06A8
/* Enumeration space constants */
#define SSB_CORE_SIZE 0x1000 /* Size of a core MMIO area */
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox