* Re: [PATCH] net: Adjust softirq raising in __napi_schedule
From: Johannes Berg @ 2009-10-27 7:01 UTC (permalink / raw)
To: Tilman Schmidt
Cc: Jarek Poplawski, David Miller, hidave.darkstar, linux-kernel,
tglx, linux-wireless, linux-ppp, netdev, paulus, Michael Buesch,
Oliver Hartkopp
In-Reply-To: <4AE64441.7060008@imap.cc>
[-- Attachment #1: Type: text/plain, Size: 1706 bytes --]
On Tue, 2009-10-27 at 01:52 +0100, Tilman Schmidt wrote:
> > Any code (say ISDN code) that calls netif_rx() is clearly assuming to
> > always be running in (soft)irq context, otherwise it couldn't call
> > netif_rx() unconditionally. Agree so far?
>
> Well, in fact I'm not sure. :-) All I know is that in the ISDN case, no
> such assumption is explicitly stated anywhere. (The code in question is
> called from the rcvcallb_skb() callback method which the hardware driver
> calls when data has been received, and the description of that method in
> Documentation/isdn/INTERFACE does not say anything about the context in
> which it may be called.) The relevant code in drivers/isdn/i4l/isdn_ppp.c
> is rather old, perhaps even older than softirqs and the netif_rx() /
> netif_rx_ni() split. (Bear in mind that we are talking about the old
> ISDN4Linux subsystem which initially didn't even make it into the 2.6
> series because it was considered obsolete.) It seems quite possible to me
> that just no one ever thought about that question.
Heh :)
> > So now if you change the ISDN code to call netif_rx_ni(), you've changed
> > the assumption that the ISDN code makes -- that it is running in
> > (soft)irq context. Therefore, you need to verify that this is actually a
> > correct change, which is what I tried to say.
>
> Understood. However, the fact that the local_softirq_pending message is
> appearing would seem to indicate that this assumption was wrong to
> begin with, wouldn't it?
I thought it only recently started appearing with a new driver or
something, but I may have misunderstood you. Anyway, I think that sums
up the issue from my POV.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH] ath: Updates for regulatory and country codes.
From: Vivek Natarajan @ 2009-10-27 6:02 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
Add a few new country codes and update the regulatory domain for some
countries.
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
---
drivers/net/wireless/ath/regd.h | 8 ++++++++
drivers/net/wireless/ath/regd_common.h | 32 ++++++++++++++++++++------------
2 files changed, 28 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/ath/regd.h b/drivers/net/wireless/ath/regd.h
index c1dd857..a1c3952 100644
--- a/drivers/net/wireless/ath/regd.h
+++ b/drivers/net/wireless/ath/regd.h
@@ -65,10 +65,13 @@ enum CountryCode {
CTRY_ALGERIA = 12,
CTRY_ARGENTINA = 32,
CTRY_ARMENIA = 51,
+ CTRY_ARUBA = 533,
CTRY_AUSTRALIA = 36,
CTRY_AUSTRIA = 40,
CTRY_AZERBAIJAN = 31,
CTRY_BAHRAIN = 48,
+ CTRY_BANGLADESH = 50,
+ CTRY_BARBADOS = 52,
CTRY_BELARUS = 112,
CTRY_BELGIUM = 56,
CTRY_BELIZE = 84,
@@ -77,6 +80,7 @@ enum CountryCode {
CTRY_BRAZIL = 76,
CTRY_BRUNEI_DARUSSALAM = 96,
CTRY_BULGARIA = 100,
+ CTRY_CAMBODIA = 116,
CTRY_CANADA = 124,
CTRY_CHILE = 152,
CTRY_CHINA = 156,
@@ -97,7 +101,11 @@ enum CountryCode {
CTRY_GEORGIA = 268,
CTRY_GERMANY = 276,
CTRY_GREECE = 300,
+ CTRY_GREENLAND = 304,
+ CTRY_GRENEDA = 308,
+ CTRY_GUAM = 316,
CTRY_GUATEMALA = 320,
+ CTRY_HAITI = 332,
CTRY_HONDURAS = 340,
CTRY_HONG_KONG = 344,
CTRY_HUNGARY = 348,
diff --git a/drivers/net/wireless/ath/regd_common.h b/drivers/net/wireless/ath/regd_common.h
index 9847af7..248c670 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -288,13 +288,16 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_DEFAULT, FCC1_FCCA, "CO"},
{CTRY_ALBANIA, NULL1_WORLD, "AL"},
{CTRY_ALGERIA, NULL1_WORLD, "DZ"},
- {CTRY_ARGENTINA, APL3_WORLD, "AR"},
+ {CTRY_ARGENTINA, FCC3_WORLD, "AR"},
{CTRY_ARMENIA, ETSI4_WORLD, "AM"},
+ {CTRY_ARUBA, ETSI1_WORLD, "AW"},
{CTRY_AUSTRALIA, FCC2_WORLD, "AU"},
{CTRY_AUSTRALIA2, FCC6_WORLD, "AU"},
{CTRY_AUSTRIA, ETSI1_WORLD, "AT"},
{CTRY_AZERBAIJAN, ETSI4_WORLD, "AZ"},
{CTRY_BAHRAIN, APL6_WORLD, "BH"},
+ {CTRY_BANGLADESH, NULL1_WORLD, "BD"},
+ {CTRY_BARBADOS, FCC2_WORLD, "BB"},
{CTRY_BELARUS, ETSI1_WORLD, "BY"},
{CTRY_BELGIUM, ETSI1_WORLD, "BE"},
{CTRY_BELGIUM2, ETSI4_WORLD, "BL"},
@@ -304,13 +307,14 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_BRAZIL, FCC3_WORLD, "BR"},
{CTRY_BRUNEI_DARUSSALAM, APL1_WORLD, "BN"},
{CTRY_BULGARIA, ETSI6_WORLD, "BG"},
- {CTRY_CANADA, FCC2_FCCA, "CA"},
+ {CTRY_CAMBODIA, ETSI1_WORLD, "KH"},
+ {CTRY_CANADA, FCC3_FCCA, "CA"},
{CTRY_CANADA2, FCC6_FCCA, "CA"},
{CTRY_CHILE, APL6_WORLD, "CL"},
{CTRY_CHINA, APL1_WORLD, "CN"},
{CTRY_COLOMBIA, FCC1_FCCA, "CO"},
{CTRY_COSTA_RICA, FCC1_WORLD, "CR"},
- {CTRY_CROATIA, ETSI3_WORLD, "HR"},
+ {CTRY_CROATIA, ETSI1_WORLD, "HR"},
{CTRY_CYPRUS, ETSI1_WORLD, "CY"},
{CTRY_CZECH, ETSI3_WORLD, "CZ"},
{CTRY_DENMARK, ETSI1_WORLD, "DK"},
@@ -324,18 +328,22 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_GEORGIA, ETSI4_WORLD, "GE"},
{CTRY_GERMANY, ETSI1_WORLD, "DE"},
{CTRY_GREECE, ETSI1_WORLD, "GR"},
+ {CTRY_GREENLAND, ETSI1_WORLD, "GL"},
+ {CTRY_GRENEDA, FCC3_FCCA, "GD"},
+ {CTRY_GUAM, FCC1_FCCA, "GU"},
{CTRY_GUATEMALA, FCC1_FCCA, "GT"},
+ {CTRY_HAITI, ETSI1_WORLD, "HT"},
{CTRY_HONDURAS, NULL1_WORLD, "HN"},
- {CTRY_HONG_KONG, FCC2_WORLD, "HK"},
+ {CTRY_HONG_KONG, FCC3_WORLD, "HK"},
{CTRY_HUNGARY, ETSI1_WORLD, "HU"},
{CTRY_ICELAND, ETSI1_WORLD, "IS"},
{CTRY_INDIA, APL6_WORLD, "IN"},
- {CTRY_INDONESIA, APL1_WORLD, "ID"},
+ {CTRY_INDONESIA, NULL1_WORLD, "ID"},
{CTRY_IRAN, APL1_WORLD, "IR"},
{CTRY_IRELAND, ETSI1_WORLD, "IE"},
{CTRY_ISRAEL, NULL1_WORLD, "IL"},
{CTRY_ITALY, ETSI1_WORLD, "IT"},
- {CTRY_JAMAICA, ETSI1_WORLD, "JM"},
+ {CTRY_JAMAICA, FCC3_WORLD, "JM"},
{CTRY_JAPAN, MKK1_MKKA, "JP"},
{CTRY_JAPAN1, MKK1_MKKB, "JP"},
@@ -402,7 +410,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_KOREA_ROC, APL9_WORLD, "KR"},
{CTRY_KOREA_ROC2, APL2_WORLD, "K2"},
{CTRY_KOREA_ROC3, APL9_WORLD, "K3"},
- {CTRY_KUWAIT, NULL1_WORLD, "KW"},
+ {CTRY_KUWAIT, ETSI3_WORLD, "KW"},
{CTRY_LATVIA, ETSI1_WORLD, "LV"},
{CTRY_LEBANON, NULL1_WORLD, "LB"},
{CTRY_LIECHTENSTEIN, ETSI1_WORLD, "LI"},
@@ -414,13 +422,13 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_MALTA, ETSI1_WORLD, "MT"},
{CTRY_MEXICO, FCC1_FCCA, "MX"},
{CTRY_MONACO, ETSI4_WORLD, "MC"},
- {CTRY_MOROCCO, NULL1_WORLD, "MA"},
+ {CTRY_MOROCCO, APL4_WORLD, "MA"},
{CTRY_NEPAL, APL1_WORLD, "NP"},
{CTRY_NETHERLANDS, ETSI1_WORLD, "NL"},
{CTRY_NETHERLANDS_ANTILLES, ETSI1_WORLD, "AN"},
{CTRY_NEW_ZEALAND, FCC2_ETSIC, "NZ"},
{CTRY_NORWAY, ETSI1_WORLD, "NO"},
- {CTRY_OMAN, APL6_WORLD, "OM"},
+ {CTRY_OMAN, FCC3_WORLD, "OM"},
{CTRY_PAKISTAN, NULL1_WORLD, "PK"},
{CTRY_PANAMA, FCC1_FCCA, "PA"},
{CTRY_PAPUA_NEW_GUINEA, FCC1_WORLD, "PG"},
@@ -429,7 +437,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_POLAND, ETSI1_WORLD, "PL"},
{CTRY_PORTUGAL, ETSI1_WORLD, "PT"},
{CTRY_PUERTO_RICO, FCC1_FCCA, "PR"},
- {CTRY_QATAR, NULL1_WORLD, "QA"},
+ {CTRY_QATAR, APL1_WORLD, "QA"},
{CTRY_ROMANIA, NULL1_WORLD, "RO"},
{CTRY_RUSSIA, NULL1_WORLD, "RU"},
{CTRY_SAUDI_ARABIA, NULL1_WORLD, "SA"},
@@ -445,7 +453,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_SYRIA, NULL1_WORLD, "SY"},
{CTRY_TAIWAN, APL3_FCCA, "TW"},
{CTRY_THAILAND, FCC3_WORLD, "TH"},
- {CTRY_TRINIDAD_Y_TOBAGO, ETSI4_WORLD, "TT"},
+ {CTRY_TRINIDAD_Y_TOBAGO, FCC3_WORLD, "TT"},
{CTRY_TUNISIA, ETSI3_WORLD, "TN"},
{CTRY_TURKEY, ETSI3_WORLD, "TR"},
{CTRY_UKRAINE, NULL1_WORLD, "UA"},
@@ -456,7 +464,7 @@ static struct country_code_to_enum_rd allCountries[] = {
* would need to assign new special alpha2 to CRDA db as with the world
* regdomain and use another alpha2 */
{CTRY_UNITED_STATES_FCC49, FCC4_FCCA, "PS"},
- {CTRY_URUGUAY, APL2_WORLD, "UY"},
+ {CTRY_URUGUAY, FCC3_WORLD, "UY"},
{CTRY_UZBEKISTAN, FCC3_FCCA, "UZ"},
{CTRY_VENEZUELA, APL2_ETSIC, "VE"},
{CTRY_VIET_NAM, NULL1_WORLD, "VN"},
--
1.6.5.1
^ permalink raw reply related
* Re: [PATCH] ath9k: Updates for regulatory and country codes.
From: Vivek Natarajan @ 2009-10-27 6:02 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
In-Reply-To: <20091027055731.GA6153@vivek-laptop>
On Tue, Oct 27, 2009 at 11:27 AM, Vivek Natarajan
<vivek.natraj@gmail.com> wrote:
> Add a few new country codes and update the regulatory domain for some
> countries.
>
> Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
I will change the subject line to ath instead of ath9k and send it once again.
Thanks
Vivek.
^ permalink raw reply
* [PATCH] ath9k: Updates for regulatory and country codes.
From: Vivek Natarajan @ 2009-10-27 5:57 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
Add a few new country codes and update the regulatory domain for some
countries.
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
---
drivers/net/wireless/ath/regd.h | 8 ++++++++
drivers/net/wireless/ath/regd_common.h | 32 ++++++++++++++++++++------------
2 files changed, 28 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/ath/regd.h b/drivers/net/wireless/ath/regd.h
index c1dd857..a1c3952 100644
--- a/drivers/net/wireless/ath/regd.h
+++ b/drivers/net/wireless/ath/regd.h
@@ -65,10 +65,13 @@ enum CountryCode {
CTRY_ALGERIA = 12,
CTRY_ARGENTINA = 32,
CTRY_ARMENIA = 51,
+ CTRY_ARUBA = 533,
CTRY_AUSTRALIA = 36,
CTRY_AUSTRIA = 40,
CTRY_AZERBAIJAN = 31,
CTRY_BAHRAIN = 48,
+ CTRY_BANGLADESH = 50,
+ CTRY_BARBADOS = 52,
CTRY_BELARUS = 112,
CTRY_BELGIUM = 56,
CTRY_BELIZE = 84,
@@ -77,6 +80,7 @@ enum CountryCode {
CTRY_BRAZIL = 76,
CTRY_BRUNEI_DARUSSALAM = 96,
CTRY_BULGARIA = 100,
+ CTRY_CAMBODIA = 116,
CTRY_CANADA = 124,
CTRY_CHILE = 152,
CTRY_CHINA = 156,
@@ -97,7 +101,11 @@ enum CountryCode {
CTRY_GEORGIA = 268,
CTRY_GERMANY = 276,
CTRY_GREECE = 300,
+ CTRY_GREENLAND = 304,
+ CTRY_GRENEDA = 308,
+ CTRY_GUAM = 316,
CTRY_GUATEMALA = 320,
+ CTRY_HAITI = 332,
CTRY_HONDURAS = 340,
CTRY_HONG_KONG = 344,
CTRY_HUNGARY = 348,
diff --git a/drivers/net/wireless/ath/regd_common.h b/drivers/net/wireless/ath/regd_common.h
index 9847af7..248c670 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -288,13 +288,16 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_DEFAULT, FCC1_FCCA, "CO"},
{CTRY_ALBANIA, NULL1_WORLD, "AL"},
{CTRY_ALGERIA, NULL1_WORLD, "DZ"},
- {CTRY_ARGENTINA, APL3_WORLD, "AR"},
+ {CTRY_ARGENTINA, FCC3_WORLD, "AR"},
{CTRY_ARMENIA, ETSI4_WORLD, "AM"},
+ {CTRY_ARUBA, ETSI1_WORLD, "AW"},
{CTRY_AUSTRALIA, FCC2_WORLD, "AU"},
{CTRY_AUSTRALIA2, FCC6_WORLD, "AU"},
{CTRY_AUSTRIA, ETSI1_WORLD, "AT"},
{CTRY_AZERBAIJAN, ETSI4_WORLD, "AZ"},
{CTRY_BAHRAIN, APL6_WORLD, "BH"},
+ {CTRY_BANGLADESH, NULL1_WORLD, "BD"},
+ {CTRY_BARBADOS, FCC2_WORLD, "BB"},
{CTRY_BELARUS, ETSI1_WORLD, "BY"},
{CTRY_BELGIUM, ETSI1_WORLD, "BE"},
{CTRY_BELGIUM2, ETSI4_WORLD, "BL"},
@@ -304,13 +307,14 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_BRAZIL, FCC3_WORLD, "BR"},
{CTRY_BRUNEI_DARUSSALAM, APL1_WORLD, "BN"},
{CTRY_BULGARIA, ETSI6_WORLD, "BG"},
- {CTRY_CANADA, FCC2_FCCA, "CA"},
+ {CTRY_CAMBODIA, ETSI1_WORLD, "KH"},
+ {CTRY_CANADA, FCC3_FCCA, "CA"},
{CTRY_CANADA2, FCC6_FCCA, "CA"},
{CTRY_CHILE, APL6_WORLD, "CL"},
{CTRY_CHINA, APL1_WORLD, "CN"},
{CTRY_COLOMBIA, FCC1_FCCA, "CO"},
{CTRY_COSTA_RICA, FCC1_WORLD, "CR"},
- {CTRY_CROATIA, ETSI3_WORLD, "HR"},
+ {CTRY_CROATIA, ETSI1_WORLD, "HR"},
{CTRY_CYPRUS, ETSI1_WORLD, "CY"},
{CTRY_CZECH, ETSI3_WORLD, "CZ"},
{CTRY_DENMARK, ETSI1_WORLD, "DK"},
@@ -324,18 +328,22 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_GEORGIA, ETSI4_WORLD, "GE"},
{CTRY_GERMANY, ETSI1_WORLD, "DE"},
{CTRY_GREECE, ETSI1_WORLD, "GR"},
+ {CTRY_GREENLAND, ETSI1_WORLD, "GL"},
+ {CTRY_GRENEDA, FCC3_FCCA, "GD"},
+ {CTRY_GUAM, FCC1_FCCA, "GU"},
{CTRY_GUATEMALA, FCC1_FCCA, "GT"},
+ {CTRY_HAITI, ETSI1_WORLD, "HT"},
{CTRY_HONDURAS, NULL1_WORLD, "HN"},
- {CTRY_HONG_KONG, FCC2_WORLD, "HK"},
+ {CTRY_HONG_KONG, FCC3_WORLD, "HK"},
{CTRY_HUNGARY, ETSI1_WORLD, "HU"},
{CTRY_ICELAND, ETSI1_WORLD, "IS"},
{CTRY_INDIA, APL6_WORLD, "IN"},
- {CTRY_INDONESIA, APL1_WORLD, "ID"},
+ {CTRY_INDONESIA, NULL1_WORLD, "ID"},
{CTRY_IRAN, APL1_WORLD, "IR"},
{CTRY_IRELAND, ETSI1_WORLD, "IE"},
{CTRY_ISRAEL, NULL1_WORLD, "IL"},
{CTRY_ITALY, ETSI1_WORLD, "IT"},
- {CTRY_JAMAICA, ETSI1_WORLD, "JM"},
+ {CTRY_JAMAICA, FCC3_WORLD, "JM"},
{CTRY_JAPAN, MKK1_MKKA, "JP"},
{CTRY_JAPAN1, MKK1_MKKB, "JP"},
@@ -402,7 +410,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_KOREA_ROC, APL9_WORLD, "KR"},
{CTRY_KOREA_ROC2, APL2_WORLD, "K2"},
{CTRY_KOREA_ROC3, APL9_WORLD, "K3"},
- {CTRY_KUWAIT, NULL1_WORLD, "KW"},
+ {CTRY_KUWAIT, ETSI3_WORLD, "KW"},
{CTRY_LATVIA, ETSI1_WORLD, "LV"},
{CTRY_LEBANON, NULL1_WORLD, "LB"},
{CTRY_LIECHTENSTEIN, ETSI1_WORLD, "LI"},
@@ -414,13 +422,13 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_MALTA, ETSI1_WORLD, "MT"},
{CTRY_MEXICO, FCC1_FCCA, "MX"},
{CTRY_MONACO, ETSI4_WORLD, "MC"},
- {CTRY_MOROCCO, NULL1_WORLD, "MA"},
+ {CTRY_MOROCCO, APL4_WORLD, "MA"},
{CTRY_NEPAL, APL1_WORLD, "NP"},
{CTRY_NETHERLANDS, ETSI1_WORLD, "NL"},
{CTRY_NETHERLANDS_ANTILLES, ETSI1_WORLD, "AN"},
{CTRY_NEW_ZEALAND, FCC2_ETSIC, "NZ"},
{CTRY_NORWAY, ETSI1_WORLD, "NO"},
- {CTRY_OMAN, APL6_WORLD, "OM"},
+ {CTRY_OMAN, FCC3_WORLD, "OM"},
{CTRY_PAKISTAN, NULL1_WORLD, "PK"},
{CTRY_PANAMA, FCC1_FCCA, "PA"},
{CTRY_PAPUA_NEW_GUINEA, FCC1_WORLD, "PG"},
@@ -429,7 +437,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_POLAND, ETSI1_WORLD, "PL"},
{CTRY_PORTUGAL, ETSI1_WORLD, "PT"},
{CTRY_PUERTO_RICO, FCC1_FCCA, "PR"},
- {CTRY_QATAR, NULL1_WORLD, "QA"},
+ {CTRY_QATAR, APL1_WORLD, "QA"},
{CTRY_ROMANIA, NULL1_WORLD, "RO"},
{CTRY_RUSSIA, NULL1_WORLD, "RU"},
{CTRY_SAUDI_ARABIA, NULL1_WORLD, "SA"},
@@ -445,7 +453,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_SYRIA, NULL1_WORLD, "SY"},
{CTRY_TAIWAN, APL3_FCCA, "TW"},
{CTRY_THAILAND, FCC3_WORLD, "TH"},
- {CTRY_TRINIDAD_Y_TOBAGO, ETSI4_WORLD, "TT"},
+ {CTRY_TRINIDAD_Y_TOBAGO, FCC3_WORLD, "TT"},
{CTRY_TUNISIA, ETSI3_WORLD, "TN"},
{CTRY_TURKEY, ETSI3_WORLD, "TR"},
{CTRY_UKRAINE, NULL1_WORLD, "UA"},
@@ -456,7 +464,7 @@ static struct country_code_to_enum_rd allCountries[] = {
* would need to assign new special alpha2 to CRDA db as with the world
* regdomain and use another alpha2 */
{CTRY_UNITED_STATES_FCC49, FCC4_FCCA, "PS"},
- {CTRY_URUGUAY, APL2_WORLD, "UY"},
+ {CTRY_URUGUAY, FCC3_WORLD, "UY"},
{CTRY_UZBEKISTAN, FCC3_FCCA, "UZ"},
{CTRY_VENEZUELA, APL2_ETSIC, "VE"},
{CTRY_VIET_NAM, NULL1_WORLD, "VN"},
--
1.6.5.1
^ permalink raw reply related
* Re: ath5k, too high output power?
From: Denys Fedoryschenko @ 2009-10-27 3:47 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <43e72e890910262025me2acd0ekacd9ac4224ba9386@mail.gmail.com>
On Tuesday 27 October 2009 05:25:44 Luis R. Rodriguez wrote:
>
> How do we do this for windows then?
>
You are right. I search in registry and .inf files, there is nothing vendor
specific. Most probably what is exist now - enough for laptops.
^ permalink raw reply
* Re: RECAP: indication of channel noise
From: Jouni Malinen @ 2009-10-27 3:45 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless, Johannes Berg, Felix Fietkau
In-Reply-To: <200910261442.44774.h.schurig@mn-solutions.de>
On Mon, Oct 26, 2009 at 02:42:44PM +0100, Holger Schurig wrote:
> The idea is to have one API call "do site survey", where you tell
> the driver to scan on specified/all channels to determine those
> values.
What would this command be? Just the existing scan trigger command with
a new attribute indicating that site survey is requested? In my first
use case (select best channel for an AP), I would like to combine the
normal scan (get all BSSes) and site survey (get tx/rx/idle hw counters
for each channel). Fetching the site survey data with a new command
would be fine, but trigger command should be shared.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: ath5k, too high output power?
From: Luis R. Rodriguez @ 2009-10-27 3:25 UTC (permalink / raw)
To: Denys Fedoryschenko; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <200910270518.18181.denys@visp.net.lb>
On Mon, Oct 26, 2009 at 8:18 PM, Denys Fedoryschenko <denys@visp.net.lb> wrote:
> On Tuesday 27 October 2009 05:14:27 Luis R. Rodriguez wrote:
>> ath5k and madwifi are very different.
> I know, but as i know there no way to know to which connector vendor plugged
> antenna cable.
How do we do this for windows then?
Luis
^ permalink raw reply
* Re: ath5k, too high output power?
From: Denys Fedoryschenko @ 2009-10-27 3:18 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <43e72e890910262014y77ef048do965a76ab423c2db6@mail.gmail.com>
On Tuesday 27 October 2009 05:14:27 Luis R. Rodriguez wrote:
> ath5k and madwifi are very different.
I know, but as i know there no way to know to which connector vendor plugged
antenna cable.
^ permalink raw reply
* Re: ath5k, too high output power?
From: Luis R. Rodriguez @ 2009-10-27 3:14 UTC (permalink / raw)
To: Denys Fedoryschenko; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <200910270508.29029.denys@visp.net.lb>
On Mon, Oct 26, 2009 at 8:08 PM, Denys Fedoryschenko <denys@visp.net.lb> wrote:
> On Tuesday 27 October 2009 04:59:20 Luis R. Rodriguez wrote:
>> You mean can you do antenna diversity and select this manually ? I am
>> not sure, but I doubt it, should be easy to add though.
>
> Yes, on some laptops wireless card connected really weird way. And while on
> Windows everything worked fine, on Linux signal was too weak, and some people
> thinking it is driver issue.
> I had this issue with madwifi before, and choosing antenna manually helped.
> But it was long time ago, no idea if it's useful now in ath5k. But in custom
> boards like Routerboard it is very useful.
ath5k and madwifi are very different.
Luis
^ permalink raw reply
* Re: ath5k, too high output power?
From: Denys Fedoryschenko @ 2009-10-27 3:08 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <43e72e890910261959s6490b900xebb365d288c03f@mail.gmail.com>
On Tuesday 27 October 2009 04:59:20 Luis R. Rodriguez wrote:
> You mean can you do antenna diversity and select this manually ? I am
> not sure, but I doubt it, should be easy to add though.
Yes, on some laptops wireless card connected really weird way. And while on
Windows everything worked fine, on Linux signal was too weak, and some people
thinking it is driver issue.
I had this issue with madwifi before, and choosing antenna manually helped.
But it was long time ago, no idea if it's useful now in ath5k. But in custom
boards like Routerboard it is very useful.
^ permalink raw reply
* Re: ath5k, too high output power?
From: Luis R. Rodriguez @ 2009-10-27 2:59 UTC (permalink / raw)
To: Denys Fedoryschenko; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <200910270410.24274.denys@visp.net.lb>
On Mon, Oct 26, 2009 at 7:10 PM, Denys Fedoryschenko <denys@visp.net.lb> wrote:
> On Tuesday 27 October 2009 03:38:02 Luis R. Rodriguez wrote:
>> You obviously can change the antenna on a lot of devices, sometimes
>> that is difficult due to the connectors used but you are likely to
>> find them online somewhere.
>
> I mean A or B :-) AUX or MAIN :-)
> Sorry for my ugly English.
> In madwifi, as i remember i was possible to do that or over sysctl or over
> module parameter, i dont remember exactly where.
You mean can you do antenna diversity and select this manually ? I am
not sure, but I doubt it, should be easy to add though.
Luis
^ permalink raw reply
* Re: ath5k, too high output power?
From: Denys Fedoryschenko @ 2009-10-27 2:10 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <43e72e890910261838k7986048dg4cc38634d828e98c@mail.gmail.com>
On Tuesday 27 October 2009 03:38:02 Luis R. Rodriguez wrote:
> You obviously can change the antenna on a lot of devices, sometimes
> that is difficult due to the connectors used but you are likely to
> find them online somewhere.
I mean A or B :-) AUX or MAIN :-)
Sorry for my ugly English.
In madwifi, as i remember i was possible to do that or over sysctl or over
module parameter, i dont remember exactly where.
^ permalink raw reply
* Re: ath5k, too high output power?
From: Luis R. Rodriguez @ 2009-10-27 1:38 UTC (permalink / raw)
To: Denys Fedoryschenko; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <200910270259.09787.denys@visp.net.lb>
On Mon, Oct 26, 2009 at 5:59 PM, Denys Fedoryschenko <denys@visp.net.lb> wrote:
> I have laptop with ath5k card, and just tried to run it with ath5k driver.
> I notice strange thing:
>
> lappi ~ # iw phy phy0 info
> Wiphy phy0
> Band 1:
> Frequencies:
> * 2412 MHz [1] (20.0 dBm)
> * 2417 MHz [2] (20.0 dBm)
> * 2422 MHz [3] (20.0 dBm)
>
> I guess it is too high. I am not sure it is actual value, but if it is right
> and actual value, then i am exceeding local regulations.
That value is the maximum value allowed, not your actual eirp. By
default the EEPROM's card is read and that is used for regulatory
purposes, users can however be good citizens and help regulatory
compliance further by indicating their country and if the max eirp of
the programmed EEPROM is higher than your current country it will be
lowered.
Please have a good read at:
http://wireless.kernel.org/en/developers/Regulatory
http://wireless.kernel.org/en/users/Drivers/ath
> Another thing, is it possible to change antenna output?
You obviously can change the antenna on a lot of devices, sometimes
that is difficult due to the connectors used but you are likely to
find them online somewhere.
Luis
^ permalink raw reply
* ath5k, too high output power?
From: Denys Fedoryschenko @ 2009-10-27 0:59 UTC (permalink / raw)
To: linux-wireless, ath5k-devel
I have laptop with ath5k card, and just tried to run it with ath5k driver.
I notice strange thing:
lappi ~ # iw phy phy0 info
Wiphy phy0
Band 1:
Frequencies:
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
I guess it is too high. I am not sure it is actual value, but if it is right
and actual value, then i am exceeding local regulations.
I have simple spectrum analyzer (spectran), and i can try to test actual
output power if required.
Another thing, is it possible to change antenna output?
Hardware:
01:00.0 Ethernet controller: Atheros Communications Inc. AR242x 802.11abg
Wireless PCI Express Adapter (rev 01)
Subsystem: Hewlett-Packard Company Device 137a
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 128 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at d1300000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] Message Signalled Interrupts: Mask- 64bit-
Count=1/1 Enable-
Address: 00000000 Data: 0000
Capabilities: [60] Express (v1) Legacy Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns,
L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr-
TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency
L0 <512ns, L1 <64us
ClockPM- Suprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- Retrain-
CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
DLActive- BWMgmt- ABWMgmt-
Capabilities: [90] MSI-X: Enable- Mask- TabSize=1
Vector table: BAR=0 offset=00000000
PBA: BAR=0 offset=00000000
Capabilities: [100] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO+ CmpltAbrt- UnxCmplt-
RxOF- MalfTLP- ECRC- UnsupReq- ACSVoil-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
RxOF- MalfTLP- ECRC- UnsupReq- ACSVoil-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt-
RxOF+ MalfTLP+ ECRC- UnsupReq- ACSVoil-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
NonFatalErr-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
NonFatalErr-
AERCap: First Error Pointer: 0e, GenCap+ CGenEn- ChkCap+
ChkEn-
Capabilities: [140] Virtual Channel <?>
Kernel driver in use: ath5k
Kernel modules: ath5k
^ permalink raw reply
* Re: [PATCH] net: Adjust softirq raising in __napi_schedule
From: Tilman Schmidt @ 2009-10-27 0:52 UTC (permalink / raw)
To: Johannes Berg
Cc: Jarek Poplawski, David Miller, hidave.darkstar, linux-kernel,
tglx, linux-wireless, linux-ppp, netdev, paulus, Michael Buesch,
Oliver Hartkopp
In-Reply-To: <1256547380.28230.17.camel@johannes.local>
[-- Attachment #1: Type: text/plain, Size: 2335 bytes --]
Am 26.10.2009 09:56 schrieb Johannes Berg:
> On Mon, 2009-10-26 at 10:47 +0200, Tilman Schmidt wrote:
>
>>> Basically it boils down to using netif_rx() when in (soft)irq, and
>>> netif_rx_ni() when in process context. That could just be an
>>> optimisation, but it's a very valid one.
>> Hmmm. That seems to contradict your earlier statement to me that
>> simply replacing a call to netif_rx() by one to netif_rx_ni()
>> when not in interrupt context isn't a valid solution either.
>> What am I missing?
>
> Well, I think you misunderstood me. It would be correct to do this, if
> and only if the code that calls it doesn't need the extra guarantee.
I see. Thanks for the clarification.
> Any code (say ISDN code) that calls netif_rx() is clearly assuming to
> always be running in (soft)irq context, otherwise it couldn't call
> netif_rx() unconditionally. Agree so far?
Well, in fact I'm not sure. :-) All I know is that in the ISDN case, no
such assumption is explicitly stated anywhere. (The code in question is
called from the rcvcallb_skb() callback method which the hardware driver
calls when data has been received, and the description of that method in
Documentation/isdn/INTERFACE does not say anything about the context in
which it may be called.) The relevant code in drivers/isdn/i4l/isdn_ppp.c
is rather old, perhaps even older than softirqs and the netif_rx() /
netif_rx_ni() split. (Bear in mind that we are talking about the old
ISDN4Linux subsystem which initially didn't even make it into the 2.6
series because it was considered obsolete.) It seems quite possible to me
that just no one ever thought about that question.
> So now if you change the ISDN code to call netif_rx_ni(), you've changed
> the assumption that the ISDN code makes -- that it is running in
> (soft)irq context. Therefore, you need to verify that this is actually a
> correct change, which is what I tried to say.
Understood. However, the fact that the local_softirq_pending message is
appearing would seem to indicate that this assumption was wrong to
begin with, wouldn't it?
Thanks,
Tilman
--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply
* Re: ath5k phy0: no further txbuf available, dropping packet
From: Michael Buesch @ 2009-10-26 21:34 UTC (permalink / raw)
To: Bob Copeland
Cc: dsrbecky, Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez,
linux-wireless
In-Reply-To: <200910262230.57957.mb@bu3sch.de>
On Monday 26 October 2009 22:30:55 Michael Buesch wrote:
> On Monday 26 October 2009 21:52:39 David Srbecky wrote:
> > I am getting this error as well.
>
> Ok, I looked at the code a bit and this looks strange to me.
> There's the TX status handler in base.c which basically looks like this:
>
>
> loop_over_queued_packets() {
> ret = sc->ah->ah_proc_rx_desc(sc->ah, ds, &rs);
Typo. I meant ah_proc_tx_desc()
> if (unlikely(ret == -EINPROGRESS))
> break;
> free_packet_and_return_bufferhead_to_pool();
> }
>
> So the ah_proc_rx_desc callback looks like this:
>
> ah_proc_rx_..._desc()
same here
> {
> ...
> /* No frame has been send or error */
> if (unlikely(!(tx_status->tx_status_1 & AR5K_DESC_TX_STATUS1_DONE)))
> return -EINPROGRESS;
> ...
> }
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH v2 2/4] ath9k_hw: distinguish single-chip solutions on initial probe print
From: Luis R. Rodriguez @ 2009-10-26 21:32 UTC (permalink / raw)
To: Kalle Valo
Cc: Luis Rodriguez, linville@tuxdriver.com,
linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org
In-Reply-To: <878wexhn6m.fsf@purkki.valot.fi>
On Mon, Oct 26, 2009 at 02:15:13PM -0700, Kalle Valo wrote:
> "Luis R. Rodriguez" <lrodriguez@Atheros.com> writes:
>
> >> I think you should provide the size of hw_name to this function and
> >> use snprintf() to avoid writing out of bounds.
> >
> > I was going to do this but since I know the users of it and control
> > it seemed to not matter. I'll respin with this added, better to be careful.
>
> Yeah, you never know if someone (for example a crazy Finn just after a
> refreshing sauna) comes along, changes the function a bit "to clean it
> up" and creates a subtle bug ;)
Ah yes, forgot about the crazy sauna fins, must fix now for sure.
Luis
^ permalink raw reply
* Re: ath5k phy0: no further txbuf available, dropping packet
From: Michael Buesch @ 2009-10-26 21:30 UTC (permalink / raw)
To: Bob Copeland
Cc: dsrbecky, Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez,
linux-wireless
In-Reply-To: <87f9e23c0910261352x60e17ef8ud859f91f36c43898@mail.gmail.com>
On Monday 26 October 2009 21:52:39 David Srbecky wrote:
> I am getting this error as well.
Ok, I looked at the code a bit and this looks strange to me.
There's the TX status handler in base.c which basically looks like this:
loop_over_queued_packets() {
ret = sc->ah->ah_proc_rx_desc(sc->ah, ds, &rs);
if (unlikely(ret == -EINPROGRESS))
break;
free_packet_and_return_bufferhead_to_pool();
}
So the ah_proc_rx_desc callback looks like this:
ah_proc_rx_..._desc()
{
...
/* No frame has been send or error */
if (unlikely(!(tx_status->tx_status_1 & AR5K_DESC_TX_STATUS1_DONE)))
return -EINPROGRESS;
...
}
Notice the comment and how it says "or error". So does that mean that if the
hardware produces some kind of error on one frame, the driver will stop processing any TX status
reports (because the loop always breaks early)? This would result in a buffer queue underrun,
which is reported by the printk.
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH v2 2/4] ath9k_hw: distinguish single-chip solutions on initial probe print
From: Kalle Valo @ 2009-10-26 21:15 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org,
ath9k-devel@lists.ath9k.org
In-Reply-To: <20091026204447.GA5713@tux>
"Luis R. Rodriguez" <lrodriguez@Atheros.com> writes:
>> I think you should provide the size of hw_name to this function and
>> use snprintf() to avoid writing out of bounds.
>
> I was going to do this but since I know the users of it and control
> it seemed to not matter. I'll respin with this added, better to be careful.
Yeah, you never know if someone (for example a crazy Finn just after a
refreshing sauna) comes along, changes the function a bit "to clean it
up" and creates a subtle bug ;)
--
Kalle Valo
^ permalink raw reply
* Re: ath5k: no further txbuf available, dropping packet
From: Fabio Rossi @ 2009-10-26 20:57 UTC (permalink / raw)
To: linux-wireless
Cc: Michael Buesch, Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez,
Bob Copeland
In-Reply-To: <200910231608.18676.mb@bu3sch.de>
On Friday 23 October 2009 16:08:16 Michael Buesch wrote:
> ath5k breaks in AP mode after some operation time and keeps throwing
> this message:
>
> [2096249.446071] ath5k phy0: no further txbuf available, dropping packet
>
> Driver is yesterday's compat-wireless on 2.6.31.1
I got the same message but in managed mode with the latest git wireless
testing (v2.6.32-rc5-40584-g9b469da)
^ permalink raw reply
* ath5k phy0: no further txbuf available, dropping packet
From: David Srbecky @ 2009-10-26 20:52 UTC (permalink / raw)
To: linux-wireless
I am getting this error as well.
I am using Atheros card as AP.
After a while I start getting the following message in syslog:
ath5k phy0: no further txbuf available, dropping packet
The message repeats every 10 seconds and the wireless network is no
longer usabe until hostapd is restarted.
The timing seems quite random, but on average it occurs about once per
half an hour. Transfering a lot of data over the wireless does not
seem to make it happen any sooner.
I currently have compat-wireless-2009-10-25 installed.
I am using hostap commit cca87731 (Thu Oct 22 11:17:05 2009 -0700).
[root@alix ~]# uname -a
Linux alix 2.6.30.8-64.fc11.i586 #1 SMP Fri Sep 25 04:30:19 EDT 2009
i586 i586 i386 GNU/Linux
[root@alix ~]# lspci -k | grep -A2 "Atheros"
00:0c.0 Ethernet controller: Atheros Communications Inc. AR2413
802.11bg NIC (rev 01)
Subsystem: Atheros Communications Inc. Compex Wireless 802.11
b/g MiniPCI Adapter, Rev A1 [WLM54G]
Kernel driver in use: ath5k
Kernel modules: ath5k
^ permalink raw reply
* Re: [PATCH v2 2/4] ath9k_hw: distinguish single-chip solutions on initial probe print
From: Luis R. Rodriguez @ 2009-10-26 20:44 UTC (permalink / raw)
To: Kalle Valo
Cc: Luis Rodriguez, linville@tuxdriver.com,
linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org
In-Reply-To: <87d449hp73.fsf@purkki.valot.fi>
On Mon, Oct 26, 2009 at 01:31:44PM -0700, Kalle Valo wrote:
> "Luis R. Rodriguez" <lrodriguez@atheros.com> writes:
>
> > Devices with external radios have revisions which we can count on.
> > On single chip solutions these EEPROM values for these radio revision
> > also exist but are not meaningful as the radios are embedded onto the
> > same chip. Each single-chip device evolves together as one device.
> >
> > Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> > ---
> >
> > Changes hw_name to 60 bytes.
>
> Thanks, much better now.
>
> Another minor comment, sorry that I didn't notice it earlier:
>
> > +void ath9k_hw_name(struct ath_hw *ah, char *hw_name)
> > +{
> > + /* chipsets >= AR9280 are single-chip */
> > + if (AR_SREV_9280_10_OR_LATER(ah)) {
> > + sprintf(hw_name,
> > + "Atheros single-chip AR%s Rev:%x",
> > + ath9k_hw_mac_bb_name(ah->hw_version.macVersion),
> > + ah->hw_version.macRev);
> > + }
> > + else {
> > + sprintf(hw_name,
> > + "Atheros AR%s MAC/BB Rev:%x AR%s RF Rev:%x: ",
> > + ath9k_hw_mac_bb_name(ah->hw_version.macVersion),
> > + ah->hw_version.macRev,
> > + ath9k_hw_rf_name((ah->hw_version.analog5GhzRev &
> > + AR_RADIO_SREV_MAJOR)),
> > + ah->hw_version.phyRev);
> > + }
> > +}
>
> I think you should provide the size of hw_name to this function and
> use snprintf() to avoid writing out of bounds.
I was going to do this but since I know the users of it and control
it seemed to not matter. I'll respin with this added, better to be careful.
Thanks for the review.
Luis
^ permalink raw reply
* Re: 2.6.32-rc5-git3: Reported regressions from 2.6.31
From: Michael Buesch @ 2009-10-26 20:38 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, Christian Casteyde, Johannes Berg
In-Reply-To: <200910262037.35469.mb@bu3sch.de>
On Monday 26 October 2009 20:37:33 Michael Buesch wrote:
> Ok, it just turns out this actually is a driver bug.
> Thanks to Johannes Berg for tracking it down.
>
> I think it's caused by the DMA bouncebuffer stuff that does not copy the skb->cb
> and does not adjust the "tx-info" pointer.
> I wonder why this didn't blow up easlier, because this bug is there since mac80211
> switched to using the CB.
>
> Here's a completely untested patch.
Here's a new version of the patch that also fixes queue mapping bugs:
---
drivers/net/wireless/b43/dma.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
--- wireless-testing.orig/drivers/net/wireless/b43/dma.c
+++ wireless-testing/drivers/net/wireless/b43/dma.c
@@ -1157,8 +1157,9 @@ struct b43_dmaring *parse_cookie(struct
}
static int dma_tx_fragment(struct b43_dmaring *ring,
- struct sk_buff *skb)
+ struct sk_buff **in_skb)
{
+ struct sk_buff *skb = *in_skb;
const struct b43_dma_ops *ops = ring->ops;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
u8 *header;
@@ -1224,8 +1225,14 @@ static int dma_tx_fragment(struct b43_dm
}
memcpy(skb_put(bounce_skb, skb->len), skb->data, skb->len);
+ memcpy(bounce_skb->cb, skb->cb, sizeof(skb->cb));
+ bounce_skb->dev = skb->dev;
+ skb_set_queue_mapping(bounce_skb, skb_get_queue_mapping(skb));
+ info = IEEE80211_SKB_CB(bounce_skb);
+
dev_kfree_skb_any(skb);
skb = bounce_skb;
+ *in_skb = bounce_skb;
meta->skb = skb;
meta->dmaaddr = map_descbuffer(ring, skb->data, skb->len, 1);
if (b43_dma_mapping_error(ring, meta->dmaaddr, skb->len, 1)) {
@@ -1355,7 +1362,11 @@ int b43_dma_tx(struct b43_wldev *dev, st
* static, so we don't need to store it per frame. */
ring->queue_prio = skb_get_queue_mapping(skb);
- err = dma_tx_fragment(ring, skb);
+ /* dma_tx_fragment might reallocate the skb, so invalidate pointers pointing
+ * into the skb data or cb now. */
+ hdr = NULL;
+ info = NULL;
+ err = dma_tx_fragment(ring, &skb);
if (unlikely(err == -ENOKEY)) {
/* Drop this packet, as we don't have the encryption key
* anymore and must not transmit it unencrypted. */
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH v2 2/4] ath9k_hw: distinguish single-chip solutions on initial probe print
From: Kalle Valo @ 2009-10-26 20:31 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, linux-wireless, ath9k-devel
In-Reply-To: <1256575447-4591-1-git-send-email-lrodriguez@atheros.com>
"Luis R. Rodriguez" <lrodriguez@atheros.com> writes:
> Devices with external radios have revisions which we can count on.
> On single chip solutions these EEPROM values for these radio revision
> also exist but are not meaningful as the radios are embedded onto the
> same chip. Each single-chip device evolves together as one device.
>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
>
> Changes hw_name to 60 bytes.
Thanks, much better now.
Another minor comment, sorry that I didn't notice it earlier:
> +void ath9k_hw_name(struct ath_hw *ah, char *hw_name)
> +{
> + /* chipsets >= AR9280 are single-chip */
> + if (AR_SREV_9280_10_OR_LATER(ah)) {
> + sprintf(hw_name,
> + "Atheros single-chip AR%s Rev:%x",
> + ath9k_hw_mac_bb_name(ah->hw_version.macVersion),
> + ah->hw_version.macRev);
> + }
> + else {
> + sprintf(hw_name,
> + "Atheros AR%s MAC/BB Rev:%x AR%s RF Rev:%x: ",
> + ath9k_hw_mac_bb_name(ah->hw_version.macVersion),
> + ah->hw_version.macRev,
> + ath9k_hw_rf_name((ah->hw_version.analog5GhzRev &
> + AR_RADIO_SREV_MAJOR)),
> + ah->hw_version.phyRev);
> + }
> +}
I think you should provide the size of hw_name to this function and
use snprintf() to avoid writing out of bounds.
--
Kalle Valo
^ permalink raw reply
* Re: Fwd: [Bug 300794] Installation of WiFi Cards w firmware fails
From: John W. Linville @ 2009-10-26 20:17 UTC (permalink / raw)
To: Dr. Axel Braun; +Cc: linux-wireless
In-Reply-To: <200910222246.30668.axel.braun@gmx.de>
On Thu, Oct 22, 2009 at 10:46:30PM +0200, Dr. Axel Braun wrote:
> Gents,
>
> for some reason there are uncertainties about the license of the p54 firmware
> for the prism chips, which stop the openSUSE project for the moment to ship
> the firmware.
>
> Can you clarify the license question?
>
> Thanks
> Axel
Whom are you asking?
I wish we had a clear statement from the appropriate copyright holder,
but I'm not even sure whom to ask at this point...
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ 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