* Re: WLAN Regulatory Domain Germany
From: Luis R. Rodriguez @ 2010-05-20 7:03 UTC (permalink / raw)
To: Kurt Garloff; +Cc: Michael Green, David Quan, linux-wireless
In-Reply-To: <20100520064809.GC32757@tpkurt2.garloff.de>
On Wed, May 19, 2010 at 11:48 PM, Kurt Garloff <kurt@garloff.de> wrote:
> Luis,
>
> On Wed, May 19, 2010 at 03:20:24PM -0700, Luis R. Rodriguez wrote:
>> On Wed, May 19, 2010 at 10:29 AM, Kurt Garloff <kurt@garloff.de> wrote:
>> > country DE:
>> > # entries 279004 and 280006
>> > (2400 - 2483.5 @ 40), (N/A, 100 mW)
>> > # entry 303005
>> > (5150 - 5250 @ 40), (N/A, 100 mW), NO-OUTDOOR
>> > # entries 304002 and 305002
>> > (5250 - 5350 @ 40), (N/A, 100 mW), NO-OUTDOOR, DFS
>> > # entries 308002, 309001 and 310003
>> > (5470 - 5725 @ 40), (N/A, 500 mW), DFS
>> >
>> > 8<------------------------------------------------------------------------
>> >
>> > (Or in db, as displayed by iw reg get)
>> > country DE:
>> > (2400 - 2483 @ 40), (N/A, 20)
>> > (5150 - 5250 @ 40), (N/A, 20), NO-OUTDOOR
>> > (5250 - 5350 @ 40), (N/A, 20), NO-OUTDOOR, DFS
>> > (5470 - 5725 @ 40), (N/A, 27), DFS
>> >
>> > PS: I'm not subscribed, please copy responses to me.
>>
>> Thanks for the e-mail and your review, I've passed this to our
>> regulatory gods and it is now being picked at and reviewed.
>
> Thanks.
>
> Two more remarks:
> - Having looked at the framework how we handle this regulatory stuff
> in Linux these days, it looks very reasonable to me -- good job!
Thanks! Thank Johannes as well :)
> - The frequencies above (from Frequenznutzungsplan = freq. util. plan)
> are really the limits of the frequency ranges to be used, not channel
> center freqs. So if we'd have to put possible center freqs in there
> and assume 22MHz (+-11MHz) for the 2.4 GHz range, we'd need to put
> 2411 -- 2472.5 in the DB. Likewise, assuming 20MHz (+-10MHz for the
> 5GHz range, we'd specify 5160 -- 5240, 5240 -- 5340 and 5480 -- 5715),
> of, for 40MHz(+-20MHz) channels, it would be 5170 -- 5230, 5230 --
> 5330 and 5490 -- 5705. Such values are displayed with iw reg get
> for our neighbors NL, FR, ... which gave me the idea that we might
> not have the real boundaries in the db, but center freqs.
> That said, I'd think real boundaries make more sense, as channel
> widths may evolve over time ...
The db.txt rules uses the exact ranges, not the center of freq, the
bandwidth indicates the maximum bandwidth allowed. We had also revised
on linux-wireless some changes to make for future more complex
considerations. For details see:
http://wireless.kernel.org/en/developers/todo-list
Luis
^ permalink raw reply
* Re: [PATCH v2 7/7] rt2x00: Fix HT40 operation in rt2800.
From: Helmut Schaa @ 2010-05-20 6:52 UTC (permalink / raw)
To: Gertjan van Wingerde
Cc: John W. Linville, Ivo van Doorn, linux-wireless, users
In-Reply-To: <1274296671-13596-1-git-send-email-gwingerde@gmail.com>
Am Mittwoch 19 Mai 2010 schrieb Gertjan van Wingerde:
> Closer inspection of the legacy Ralink driver reveals that in case of HT40+
> or HT40- we must adjust the frequency settings that we program to the device.
> Implement the same adjustment in the rt2x00 code.
>
> With this HT40 seems to work for all devices supported by rt2800pci and
> rt2800usb.
>
> Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Yeah, that does the trick. Thanks for figuring this out.
Tested-by: Helmut Schaa <helmut.schaa@googlemail.com>
^ permalink raw reply
* Re: WLAN Regulatory Domain Germany
From: Kurt Garloff @ 2010-05-20 6:48 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Michael Green, David Quan, linux-wireless
In-Reply-To: <AANLkTilXo13Pn6n0n3mJONuUj50BImufADLveYAjX3YR@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2143 bytes --]
Luis,
On Wed, May 19, 2010 at 03:20:24PM -0700, Luis R. Rodriguez wrote:
> On Wed, May 19, 2010 at 10:29 AM, Kurt Garloff <kurt@garloff.de> wrote:
> > country DE:
> > # entries 279004 and 280006
> > (2400 - 2483.5 @ 40), (N/A, 100 mW)
> > # entry 303005
> > (5150 - 5250 @ 40), (N/A, 100 mW), NO-OUTDOOR
> > # entries 304002 and 305002
> > (5250 - 5350 @ 40), (N/A, 100 mW), NO-OUTDOOR, DFS
> > # entries 308002, 309001 and 310003
> > (5470 - 5725 @ 40), (N/A, 500 mW), DFS
> >
> > 8<------------------------------------------------------------------------
> >
> > (Or in db, as displayed by iw reg get)
> > country DE:
> > (2400 - 2483 @ 40), (N/A, 20)
> > (5150 - 5250 @ 40), (N/A, 20), NO-OUTDOOR
> > (5250 - 5350 @ 40), (N/A, 20), NO-OUTDOOR, DFS
> > (5470 - 5725 @ 40), (N/A, 27), DFS
> >
> > PS: I'm not subscribed, please copy responses to me.
>
> Thanks for the e-mail and your review, I've passed this to our
> regulatory gods and it is now being picked at and reviewed.
Thanks.
Two more remarks:
- Having looked at the framework how we handle this regulatory stuff
in Linux these days, it looks very reasonable to me -- good job!
- The frequencies above (from Frequenznutzungsplan = freq. util. plan)
are really the limits of the frequency ranges to be used, not channel
center freqs. So if we'd have to put possible center freqs in there
and assume 22MHz (+-11MHz) for the 2.4 GHz range, we'd need to put
2411 -- 2472.5 in the DB. Likewise, assuming 20MHz (+-10MHz for the
5GHz range, we'd specify 5160 -- 5240, 5240 -- 5340 and 5480 -- 5715),
of, for 40MHz(+-20MHz) channels, it would be 5170 -- 5230, 5230 --
5330 and 5490 -- 5705. Such values are displayed with iw reg get
for our neighbors NL, FR, ... which gave me the idea that we might
not have the real boundaries in the db, but center freqs.
That said, I'd think real boundaries make more sense, as channel
widths may evolve over time ...
Thanks,
--
Kurt Garloff, VP OPS Partner Engineering -- Novell Inc.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2 13/20] cfg80211: Add nl80211 antenna configuration
From: Luis R. Rodriguez @ 2010-05-20 6:43 UTC (permalink / raw)
To: Bruno Randolf, David Quan
Cc: ath5k-devel@lists.ath5k.org, linux-wireless@vger.kernel.org,
linville@tuxdriver.com
In-Reply-To: <201005201436.11667.br1@einfach.org>
On Wed, May 19, 2010 at 10:36 PM, Bruno Randolf <br1@einfach.org> wrote:
> On Thursday 20 May 2010 14:17:19 you wrote:
>> None of the legacy 802.11 drivers we support have more than 2
>> antennas, I am also not aware of any.
>
> i have heard of some solutions based on atheros chipsets with more than 2
> antennas ("pre-11n RangeMax", "large phased array switch"). please check
> internally.
I will. David, are you aware of legacy (non 802.11n) devices with more
than 2 antennas?
>> But -- I can think of using an 802.11n device in legacy
>> mode of operation using specific antennas.... so there's your example
>> of a valid case for this.
>
> thanks! :)
>
>> Legacy devices are dead. I don't know anyone in the industry making
>> them, the 1 stream 802.11n devices are cheaper today, so there is no
>> point in the market for it.
>
> that might be true from a chipset manufacturers marketing perspective - but we
> work on the linux kernel... ;)
>
> as you know there are millions of so called "legacy" chipsets out there and
> people are going to continue to use them wether your marketing declares them
> "dead" or not... i think it's worth to properly support them.
>
> also please don't forget that some people use the linux kernel not just for
> standard use cases, but for research and developing new solutions. we should
> provide the flexibility to support that, if possible.
Heh, yeah but what goes into the Linux kernel are drivers for hardware
silicon companies make. Who is making new legacy chipsets still?
>> > and we are sure we don't want to support more than 2
>> > antennas - well, we could save 6 bits... is it really worth it?
>>
>> You're right, then if you really don't mind lets think 802.11n through
>> well then.
>
> i don't mind to do that, but as i said i dont know much about 802.11n yet.
Thanks, give me some time to think about this then and get back to you.
Luis
^ permalink raw reply
* RE: [PATCH] cfg80211: Add a missing null pointer check
From: Jussi Haakana @ 2010-05-20 6:15 UTC (permalink / raw)
To: Felix Fietkau
Cc: John Linville, Johannes Berg, linux-wireless@vger.kernel.org
In-Reply-To: <4BF40A3F.2040902@openwrt.org>
On 2010-05-19 18:57 PM, Felix Fietkau wrote:
> On 2010-05-19 12:27 PM, Jussi Haakana wrote:
> > If a network interface is down while setting a channel,
> > missing null pointer check causes an oops in cfg80211_set_freq:
> >
> > # iw phy phy0 interface add ath1 type monitor
> > # iw dev ath1 set channel 3
> > Unable to handle kernel paging request for data at address 0x00000004
> > Faulting instruction address: 0xca16d778
> > Oops: Kernel access of bad area, sig: 11 [#1]
> > ...
> >
> > Signed-off-by: Jussi Haakana <Jussi.Haakana@7signal.com>
> That's exactly what I sent 4 days ago ;)
Sorry, missed that one :)
- Jussi
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2 13/20] cfg80211: Add nl80211 antenna configuration
From: Bruno Randolf @ 2010-05-20 5:36 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: ath5k-devel@lists.ath5k.org, linux-wireless@vger.kernel.org,
linville@tuxdriver.com
In-Reply-To: <AANLkTilG3c2UDEQa66PMvKysRVTt_dd-ZAS8FiDOe4Ob@mail.gmail.com>
On Thursday 20 May 2010 14:17:19 you wrote:
> None of the legacy 802.11 drivers we support have more than 2
> antennas, I am also not aware of any.
i have heard of some solutions based on atheros chipsets with more than 2
antennas ("pre-11n RangeMax", "large phased array switch"). please check
internally.
> But -- I can think of using an 802.11n device in legacy
> mode of operation using specific antennas.... so there's your example
> of a valid case for this.
thanks! :)
> Legacy devices are dead. I don't know anyone in the industry making
> them, the 1 stream 802.11n devices are cheaper today, so there is no
> point in the market for it.
that might be true from a chipset manufacturers marketing perspective - but we
work on the linux kernel... ;)
as you know there are millions of so called "legacy" chipsets out there and
people are going to continue to use them wether your marketing declares them
"dead" or not... i think it's worth to properly support them.
also please don't forget that some people use the linux kernel not just for
standard use cases, but for research and developing new solutions. we should
provide the flexibility to support that, if possible.
> > and we are sure we don't want to support more than 2
> > antennas - well, we could save 6 bits... is it really worth it?
>
> You're right, then if you really don't mind lets think 802.11n through
> well then.
i don't mind to do that, but as i said i dont know much about 802.11n yet.
bruno
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2 13/20] cfg80211: Add nl80211 antenna configuration
From: Luis R. Rodriguez @ 2010-05-20 5:17 UTC (permalink / raw)
To: Bruno Randolf
Cc: ath5k-devel@lists.ath5k.org, linux-wireless@vger.kernel.org,
linville@tuxdriver.com
In-Reply-To: <201005201121.49846.br1@einfach.org>
>> > that's not very clear. can you give me an example?
>>
>> iw dev wlan0 set_tx_antenna 4
>
> so you want to transmit on antenna 3. if the card has 3 antennas -
> why not?
None of the legacy 802.11 drivers we support have more than 2
antennas, I am also not aware of any.
>> > what if there is a 'legacy' hardware with 3 or more antennas?
>>
>> Like what?
>
> i can't find an actual real world example for that, but it thought it might be
> possible, from what i know from the atheros eeprom which seems to be prepared
> for up to 6 antennas.
That's for 802.11n, I think it'd be much cleaner to treat that
separately. But -- I can think of using an 802.11n device in legacy
mode of operation using specific antennas.... so there's your example
of a valid case for this.
>> > i don't see how "my" API is too complicated, and i think it allows for a
>> > clear configuration of these cases as well.
>> >
>> > your criticism seems to be based on the fact that it's not clear how to
>> > handle 802.11n chainmask + antenna configuration, but this is not what
>> > my patch is concerned about. let's go step by step...
>>
>> No no, that is my fault, I brought that up, I was hoping we could
>> address it but it seems that we can't as I don't have time to think
>> about this further in a unified clean API. But if its just going to be
>> legacy then I don't see why we would use a large bitmap.
>
> i wanted it to be easily extensibe for 802.11n
If we do want to address 802.11n then I say we go back to the drawing
board and really think about how antennas settings work for 802.11n
and consider chainmask settings.
> and possibly 'legacy' with more antennas in the future.
Legacy devices are dead. I don't know anyone in the industry making
them, the 1 stream 802.11n devices are cheaper today, so there is no
point in the market for it.
> if there really are not any pre-N cards with more than
> 2 antennas out there,
Yup, I think this is the case :)
> and we are sure we don't want to support more than 2
> antennas - well, we could save 6 bits... is it really worth it?
You're right, then if you really don't mind lets think 802.11n through
well then.
Luis
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2 13/20] cfg80211: Add nl80211 antenna configuration
From: Bruno Randolf @ 2010-05-20 2:21 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: ath5k-devel@lists.ath5k.org, linux-wireless@vger.kernel.org,
linville@tuxdriver.com
In-Reply-To: <AANLkTimso6hoef9IG2VtRQsHQiOVTQF-dwNZEooZTb3Y@mail.gmail.com>
On Thursday 20 May 2010 10:26:29 you wrote:
> >> > > > + * @NL80211_ATTR_ANTENNA_TX: Bitmap of antennas to use for
> >> > > > transmitting. + * @NL80211_ATTR_ANTENNA_RX: Bitmap of antennas to
> >> > > > use for receiving.
> >> > >
> >> > > This gets the job done, but that's it. The API defined allows for a
> >> > > hugely loose implementation on each driver.
> >> >
> >> > i tried to define it like this, in the commit log:
> >> > The antenna configuration is defined as a bitmap of allowed
> >> > antennas. This bitmap is 8 bit at the moment, each bit representing
> >> > one antenna. If multiple antennas are selected, the driver may use
> >> > diversity for receive and transmit.
> >> >
> >> > is this not precise enough?
> >>
> >> No, the commit log is just a placeholder of information, if you want to
> >> define API you do it through the kdoc so you can slap people when then
> >> submit patches that do not follow it. The kdoc above allows the
> >> flexibility you were looking for but that I do not think we should have
> >> since it will confuse the users who want to tune antenna settings on
> >> different drivers.
> >
> > you are talking about the place where to put the definition, not about
> > the definition itself. i agree, the definition should be in the kdoc,
> > and i'll update the patch. what's wrong with the definition itself?
>
> Why are you using a bitmask for only 3 possibly different settings?
because there are more than 3 different settings, like i mentioned at the end
of my last mail.
so, just talking about ath5k, right now we support only the 3 different
settings, you mentioned (fixed a, fixed b, default: diversity), true. other
drivers might support a different number of settings though, so just assuming
everyone follows these 3 definitions would be not enough, imho.
and it's very easy to add to ath5k:
- "RX on A, TX on B" or "RX on B, TX on A" (this makes sense if you want to
use a "big" (high dB) antenna for listening, but use a "small" (low dB)
antenna for sending within the regulatory limits).
- TX on a fixed antenna, while using RX diversity
that's why i decided for a bitmap.
> >> > > And yet for another driver it could be something completely
> >> > > different in usersepace.
> >> >
> >> > what do you think that could be, realistically, given the above
> >> > definition?
> >>
> >> Well, anything that has to do with tx / rx antennas.
> >
> > that's not very clear. can you give me an example?
>
> iw dev wlan0 set_tx_antenna 4
so you want to transmit on antenna 3. if the card has 3 antennas -
why not?
> > what if there is a 'legacy' hardware with 3 or more antennas?
>
> Like what?
i can't find an actual real world example for that, but it thought it might be
possible, from what i know from the atheros eeprom which seems to be prepared
for up to 6 antennas.
> > what if we want to configure RX on antenna 1, TX on antenna 2?
>
> Are you not using a value for TX and RX? Would that now allow for this?
there are different values for TX and RX, so it would allow for that.
> > i don't see how "my" API is too complicated, and i think it allows for a
> > clear configuration of these cases as well.
> >
> > your criticism seems to be based on the fact that it's not clear how to
> > handle 802.11n chainmask + antenna configuration, but this is not what
> > my patch is concerned about. let's go step by step...
>
> No no, that is my fault, I brought that up, I was hoping we could
> address it but it seems that we can't as I don't have time to think
> about this further in a unified clean API. But if its just going to be
> legacy then I don't see why we would use a large bitmap.
i wanted it to be easily extensibe for 802.11n and possibly 'legacy' with more
antennas in the future. if there really are not any pre-N cards with more than
2 antennas out there, and we are sure we don't want to support more than 2
antennas - well, we could save 6 bits... is it really worth it?
bruno
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2 13/20] cfg80211: Add nl80211 antenna configuration
From: Luis R. Rodriguez @ 2010-05-20 1:26 UTC (permalink / raw)
To: Bruno Randolf
Cc: ath5k-devel@lists.ath5k.org, linux-wireless@vger.kernel.org,
linville@tuxdriver.com
In-Reply-To: <201005201012.12045.br1@einfach.org>
On Wed, May 19, 2010 at 6:12 PM, Bruno Randolf <br1@einfach.org> wrote:
> On Thursday 20 May 2010 09:51:43 Luis R. Rodriguez wrote:
>> On Wed, May 19, 2010 at 05:35:40PM -0700, Bruno Randolf wrote:
>> > On Thursday 20 May 2010 02:07:25 you wrote:
>> > > On Tue, May 18, 2010 at 6:31 PM, Bruno Randolf <br1@einfach.org> wrote:
>> > > > + * @NL80211_ATTR_ANTENNA_TX: Bitmap of antennas to use for
>> > > > transmitting. + * @NL80211_ATTR_ANTENNA_RX: Bitmap of antennas to
>> > > > use for receiving.
>> > >
>> > > This gets the job done, but that's it. The API defined allows for a
>> > > hugely loose implementation on each driver.
>> >
>> > i tried to define it like this, in the commit log:
>> > The antenna configuration is defined as a bitmap of allowed antennas.
>> > This bitmap is 8 bit at the moment, each bit representing one
>> > antenna. If multiple antennas are selected, the driver may use
>> > diversity for receive and transmit.
>> >
>> > is this not precise enough?
>>
>> No, the commit log is just a placeholder of information, if you want to
>> define API you do it through the kdoc so you can slap people when then
>> submit patches that do not follow it. The kdoc above allows the flexibility
>> you were looking for but that I do not think we should have since it will
>> confuse the users who want to tune antenna settings on different drivers.
>
> you are talking about the place where to put the definition, not about the
> definition itself. i agree, the definition should be in the kdoc, and i'll
> update the patch. what's wrong with the definition itself?
Why are you using a bitmask for only 3 possibly different settings?
>> Understood, how about just defining something very basic and simple
>> for legacy based operation mode?
>
> i think my implementation is quite basic and simple ;)
Oh it is, I think it can be much simpler though.
>> > > And yet for another driver it could be something completely different
>> > > in usersepace.
>> >
>> > what do you think that could be, realistically, given the above
>> > definition?
>>
>> Well, anything that has to do with tx / rx antennas.
>
> that's not very clear. can you give me an example?
iw dev wlan0 set_tx_antenna 4
>> > > I think it would be better for us to define a static
>> > > API for all legacy cards and another for 802.11n cards, or unify them
>> > > but to be very specific about the API for antenna settings/chainmask
>> > > settings.
>> >
>> > sure. any suggestions?
>>
>> Sure how about FIXED_A, FIXED_B, DIVERSITY ?
>
> that's very ath5k centric.
>
> what if there is a 'legacy' hardware with 3 or more antennas?
Like what?
> what if we want to configure RX on antenna 1, TX on antenna 2?
Are you not using a value for TX and RX? Would that now allow for this?
> what if we want to use RX diversity but always TX on a fixed antenna?
You have this for both, RX and TX, and specify that on the kdoc (?)
> these are possible and useful configurations, which are not supported right
> now by ath5k but it's easy to add them.
>
> i don't see how "my" API is too complicated, and i think it allows for a clear
> configuration of these cases as well.
>
> your criticism seems to be based on the fact that it's not clear how to handle
> 802.11n chainmask + antenna configuration, but this is not what my patch is
> concerned about. let's go step by step...
No no, that is my fault, I brought that up, I was hoping we could
address it but it seems that we can't as I don't have time to think
about this further in a unified clean API. But if its just going to be
legacy then I don't see why we would use a large bitmap.
Luis
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2 13/20] cfg80211: Add nl80211 antenna configuration
From: Bruno Randolf @ 2010-05-20 1:12 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Luis R. Rodriguez, ath5k-devel@lists.ath5k.org,
linux-wireless@vger.kernel.org, linville@tuxdriver.com
In-Reply-To: <20100520005143.GB10702@tux>
On Thursday 20 May 2010 09:51:43 Luis R. Rodriguez wrote:
> On Wed, May 19, 2010 at 05:35:40PM -0700, Bruno Randolf wrote:
> > On Thursday 20 May 2010 02:07:25 you wrote:
> > > On Tue, May 18, 2010 at 6:31 PM, Bruno Randolf <br1@einfach.org> wrote:
> > > > + * @NL80211_ATTR_ANTENNA_TX: Bitmap of antennas to use for
> > > > transmitting. + * @NL80211_ATTR_ANTENNA_RX: Bitmap of antennas to
> > > > use for receiving.
> > >
> > > This gets the job done, but that's it. The API defined allows for a
> > > hugely loose implementation on each driver.
> >
> > i tried to define it like this, in the commit log:
> > The antenna configuration is defined as a bitmap of allowed antennas.
> > This bitmap is 8 bit at the moment, each bit representing one
> > antenna. If multiple antennas are selected, the driver may use
> > diversity for receive and transmit.
> >
> > is this not precise enough?
>
> No, the commit log is just a placeholder of information, if you want to
> define API you do it through the kdoc so you can slap people when then
> submit patches that do not follow it. The kdoc above allows the flexibility
> you were looking for but that I do not think we should have since it will
> confuse the users who want to tune antenna settings on different drivers.
you are talking about the place where to put the definition, not about the
definition itself. i agree, the definition should be in the kdoc, and i'll
update the patch. what's wrong with the definition itself?
> I'd much prefer to see a consistant API for antenna settings so that if
> they know how to do it with ath5k, then they know how to do it for b43,
> or whatever.
that's what i'm trying to achieve...
> > i am mostly concerned with what i believe is the
> > most common usecase (selecting one fixed antenna, or antenna diversity).
>
> In that case, then I recommend to restrict your patch to that case, and
> forget about a bitmask. Since lagcy just has antenna A, B, or auto, how
> about defining an API for just that?
>
> > i'd say this is 99% of all use cases.
>
> For now, yes. I'm thinking about 802.11n though and for that we can
> just wait, and use some other API once someone with more time wants
> to iron it out.
yes, i'm trying to find an API for 'legacy' (as you call it).
> > but this API would also allow us to define
> > more advanved things like 'transmit on antenna 1, receive on antenna 2".
>
> Sure.
>
> > i know that there are possibly more crazy (and very rare) configurations,
> > like use several panel antennas + omni, which can't be configured with
> > this API,
>
> How about we ignore those then on this API.
thats what i do. ;)
> > but it's hard to find a common API for all possibilities, and i think it
> > would be possible to extend the API later on for such cases.
>
> Understood, how about just defining something very basic and simple
> for legacy based operation mode?
i think my implementation is quite basic and simple ;)
> > > And yet for another driver it could be something completely different
> > > in usersepace.
> >
> > what do you think that could be, realistically, given the above
> > definition?
>
> Well, anything that has to do with tx / rx antennas.
that's not very clear. can you give me an example?
> > > I think it would be better for us to define a static
> > > API for all legacy cards and another for 802.11n cards, or unify them
> > > but to be very specific about the API for antenna settings/chainmask
> > > settings.
> >
> > sure. any suggestions?
>
> Sure how about FIXED_A, FIXED_B, DIVERSITY ?
that's very ath5k centric.
what if there is a 'legacy' hardware with 3 or more antennas?
what if we want to configure RX on antenna 1, TX on antenna 2?
what if we want to use RX diversity but always TX on a fixed antenna?
these are possible and useful configurations, which are not supported right
now by ath5k but it's easy to add them.
i don't see how "my" API is too complicated, and i think it allows for a clear
configuration of these cases as well.
your criticism seems to be based on the fact that it's not clear how to handle
802.11n chainmask + antenna configuration, but this is not what my patch is
concerned about. let's go step by step...
bruno
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2 13/20] cfg80211: Add nl80211 antenna configuration
From: Luis R. Rodriguez @ 2010-05-20 0:51 UTC (permalink / raw)
To: Bruno Randolf
Cc: Luis R. Rodriguez, ath5k-devel@lists.ath5k.org,
linux-wireless@vger.kernel.org, linville@tuxdriver.com
In-Reply-To: <201005200935.40377.br1@einfach.org>
On Wed, May 19, 2010 at 05:35:40PM -0700, Bruno Randolf wrote:
> On Thursday 20 May 2010 02:07:25 you wrote:
> > On Tue, May 18, 2010 at 6:31 PM, Bruno Randolf <br1@einfach.org> wrote:
> > > + * @NL80211_ATTR_ANTENNA_TX: Bitmap of antennas to use for transmitting.
> > > + * @NL80211_ATTR_ANTENNA_RX: Bitmap of antennas to use for receiving.
> >
> > This gets the job done, but that's it. The API defined allows for a
> > hugely loose implementation on each driver.
>
> i tried to define it like this, in the commit log:
>
> The antenna configuration is defined as a bitmap of allowed antennas. This
> bitmap is 8 bit at the moment, each bit representing one antenna. If
> multiple antennas are selected, the driver may use diversity for receive
> and transmit.
>
> is this not precise enough?
No, the commit log is just a placeholder of information, if you want to
define API you do it through the kdoc so you can slap people when then
submit patches that do not follow it. The kdoc above allows the flexibility
you were looking for but that I do not think we should have since it will
confuse the users who want to tune antenna settings on different drivers.
I'd much prefer to see a consistant API for antenna settings so that if
they know how to do it with ath5k, then they know how to do it for b43,
or whatever.
> i am mostly concerned with what i believe is the
> most common usecase (selecting one fixed antenna, or antenna diversity).
In that case, then I recommend to restrict your patch to that case, and
forget about a bitmask. Since lagcy just has antenna A, B, or auto, how
about defining an API for just that?
> i'd say this is 99% of all use cases.
For now, yes. I'm thinking about 802.11n though and for that we can
just wait, and use some other API once someone with more time wants
to iron it out.
> but this API would also allow us to define
> more advanved things like 'transmit on antenna 1, receive on antenna 2".
Sure.
> i know that there are possibly more crazy (and very rare) configurations, like
> use several panel antennas + omni, which can't be configured with this API,
How about we ignore those then on this API.
> but it's hard to find a common API for all possibilities, and i think it would
> be possible to extend the API later on for such cases.
Understood, how about just defining something very basic and simple
for legacy based operation mode?
> > And yet for another driver it could be something completely different
> > in usersepace.
>
> what do you think that could be, realistically, given the above definition?
Well, anything that has to do with tx / rx antennas.
> > I think it would be better for us to define a static
> > API for all legacy cards and another for 802.11n cards, or unify them
> > but to be very specific about the API for antenna settings/chainmask
> > settings.
>
> sure. any suggestions?
Sure how about FIXED_A, FIXED_B, DIVERSITY ?
Luis
^ permalink raw reply
* Re: [PATCH v2 13/20] cfg80211: Add nl80211 antenna configuration
From: Bruno Randolf @ 2010-05-20 0:35 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, ath5k-devel, linux-wireless
In-Reply-To: <AANLkTikgyTZptw5CGu8MFinkqlXeqEJMJixdckb89aFc@mail.gmail.com>
On Thursday 20 May 2010 02:07:25 you wrote:
> On Tue, May 18, 2010 at 6:31 PM, Bruno Randolf <br1@einfach.org> wrote:
> > + * @NL80211_ATTR_ANTENNA_TX: Bitmap of antennas to use for transmitting.
> > + * @NL80211_ATTR_ANTENNA_RX: Bitmap of antennas to use for receiving.
>
> This gets the job done, but that's it. The API defined allows for a
> hugely loose implementation on each driver.
i tried to define it like this, in the commit log:
The antenna configuration is defined as a bitmap of allowed antennas. This
bitmap is 8 bit at the moment, each bit representing one antenna. If
multiple antennas are selected, the driver may use diversity for receive
and transmit.
is this not precise enough? i am mostly concerned with what i believe is the
most common usecase (selecting one fixed antenna, or antenna diversity). i'd
say this is 99% of all use cases. but this API would also allow us to define
more advanved things like 'transmit on antenna 1, receive on antenna 2". i
know that there are possibly more crazy (and very rare) configurations, like
use several panel antennas + omni, which can't be configured with this API,
but it's hard to find a common API for all possibilities, and i think it would
be possible to extend the API later on for such cases.
> And yet for another driver it could be something completely different
> in usersepace.
what do you think that could be, realistically, given the above definition?
> I think it would be better for us to define a static
> API for all legacy cards and another for 802.11n cards, or unify them
> but to be very specific about the API for antenna settings/chainmask
> settings.
sure. any suggestions?
bruno
^ permalink raw reply
* Re: WLAN Regulatory Domain Germany
From: Luis R. Rodriguez @ 2010-05-19 22:20 UTC (permalink / raw)
To: Kurt Garloff, Michael Green, David Quan; +Cc: linux-wireless
In-Reply-To: <20100519172944.GB32757@tpkurt2.garloff.de>
On Wed, May 19, 2010 at 10:29 AM, Kurt Garloff <kurt@garloff.de> wrote:
> Hi,
>
> studying the three documents
>
> WLAN 5GHz (Vfg. 7/2010)
> http://www.bundesnetzagentur.de/cae/servlet/contentblob/38216/publicationFile/6579/WLAN5GHzVfg7_2010_28042010pdf.pdf
>
> WLAN 2.4GHz (Vfg. 89/2003)
> http://www.bundesnetzagentur.de/cae/servlet/contentblob/38214/publicationFile/2557/FundstelleId313pdf.pdf
>
> Frequenznutzungsplan
> http://www.bundesnetzagentur.de/cae/servlet/contentblob/38448/publicationFile/2659/Frequenznutzungsplan2008_Id17448pdf.pdf
>
> I think the data in db.txt is slightly inaccurate.
>
> Find below my suggested entry into db.txt.
> Suggested changes:
> * Updated references (they restructured their webserver/CMS it seems)
> * Split 5150 -- 5350 range into two
> - the first range does not require DFS
> * 5470 -- 5725 does not have a NO-OUTDOOR requirement
> - (and 500mW translates to 27db, not 26db AFAICT)
>
> Sidenote: The values include lowering txpower by a factor of 2 (3db)
> for non TPC devices -- the wording in Vfg. 7/2010 does NOT require
> this for 5150 -- 5250; so we could actually use 200mW/23db there. As
> this is out of line with the neighbour countries, I have sticked with
> the conservative value of 100mW here.
>
> What is the process for checking the correctness and getting the crda DB
> updated?
>
> 8<------------------------------------------------------------------------
>
> # Data from "Frequenznutzungsplan" (as published in April 2008), downloaded from
> # http://www.bundesnetzagentur.de/cae/servlet/contentblob/38448/publicationFile/2659/Frequenznutzungsplan2008_Id17448pdf.pdf
> # For the 5GHz range also see
> # http://www.bundesnetzagentur.de/cae/servlet/contentblob/38216/publicationFile/6579/WLAN5GHzVfg7_2010_28042010pdf.pdf
> # The values have been reduced by a factor of 2 (3db) for non TPC devcies
> # (in other words: devices with TPC can use twice the tx power of this table).
>
> country DE:
> # entries 279004 and 280006
> (2400 - 2483.5 @ 40), (N/A, 100 mW)
> # entry 303005
> (5150 - 5250 @ 40), (N/A, 100 mW), NO-OUTDOOR
> # entries 304002 and 305002
> (5250 - 5350 @ 40), (N/A, 100 mW), NO-OUTDOOR, DFS
> # entries 308002, 309001 and 310003
> (5470 - 5725 @ 40), (N/A, 500 mW), DFS
>
> 8<------------------------------------------------------------------------
>
> (Or in db, as displayed by iw reg get)
> country DE:
> (2400 - 2483 @ 40), (N/A, 20)
> (5150 - 5250 @ 40), (N/A, 20), NO-OUTDOOR
> (5250 - 5350 @ 40), (N/A, 20), NO-OUTDOOR, DFS
> (5470 - 5725 @ 40), (N/A, 27), DFS
>
> PS: I'm not subscribed, please copy responses to me.
Thanks for the e-mail and your review, I've passed this to our
regulatory gods and it is now being picked at and reviewed.
Luis
^ permalink raw reply
* Re: [Oops-report] problem with ath9k at shutdown
From: Luis R. Rodriguez @ 2010-05-19 21:35 UTC (permalink / raw)
To: Huub Reuver
Cc: John W. Linville, Luis Rodriguez, linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTikNEiWcnxmIuBoh1fLQoRUvxgX95TQXtxki55oX@mail.gmail.com>
On Wed, May 19, 2010 at 11:40:04AM -0700, Luis R. Rodriguez wrote:
> On Tue, May 18, 2010 at 9:53 AM, Luis R. Rodriguez
> <lrodriguez@atheros.com> wrote:
> > On Mon, May 17, 2010 at 10:41:40PM -0700, Huub Reuver wrote:
> >> On Mon, May 17, 2010 at 01:24:04PM -0400, John W. Linville wrote:
> >> > On Mon, May 17, 2010 at 09:55:31AM -0700, Luis R. Rodriguez wrote:
> >> > > On Mon, May 17, 2010 at 07:32:41AM -0700, John W. Linville wrote:
> >> > > > Did you try 2.6.34? I'm pretty sure we merged a fix for this...
> >> > >
> >> > > Ditto, and I think it was not related to ath9k but mac80211.
> >> > >
> >> > > Was it this maybe?
> >> > >
> >> > > commit a9f042cbe5284f34ccff15f3084477e11b39b17b
> >> > > Author: Ming Lei <tom.leiming@gmail.com>
> >> > > Date: Sun Feb 28 00:56:24 2010 +0800
> >> > >
> >> > > ath9k: fix lockdep warning when unloading module
> >> > >
> >> > > Johannes had noted:
> >> > >
> >> > > "I think the problem is that the locking for sta_notify changed, and a
> >> > > patch that was written for the new locking was backported to the old,
> >> > > irq-disabled, locking."
> >> >
> >> > Yeah, maybe that is what I was thinking about....
> >>
> >> The traces do not look similar to me, but I'm not a programmer.
> >>
> >> I have done a few tests:
> >> 2.6.32.9 not affected
> >> 2.6.32.13 affected
> >> 2.6.33.3 affected
> >> 2.6.33.4 affected
> >> 2.6.34 the problem seems to have been fixed.
> >>
> >> Sorry for my slow report and response.
> >> Thanks for your quick answer, I'll have to switch to 2.6.34 for a
> >> production kernel.
> >
> > Eh, I am not sure what happened here... this must've been a fix
> > regression as I do not recall seeing this on earlier 2.6.32.y releases.
> > Can you try an earlier 2.6.32.y?
>
> I have a fix for this, I'll post this soon, testing 2.6.33 now.
In case you are not subscribed to linux-wireless, please try:
From: Luis R. Rodriguez <lrodriguez@atheros.com>
Subject: [PATCH] Revert "ath9k: fix lockdep warning when unloading module" on stable kernels
Johannes' patch 34e8950 titled:
mac80211: allow station add/remove to sleep
changed the way mac80211 adds and removes peers. The new
sta_add() / sta_remove() callbacks allowed the driver callbacks
to sleep. Johannes also ported ath9k to use sta_add() / sta_remove()
via the patch 4ca7786 titled:
ath9k: convert to new station add/remove callbacks
but this patch forgot to address a change in locking issue which
Ming Lei eventually found on his 2.6.33-wl #12 build. The 2.6.33-wl
build includes code for the 802.11 subsystem for 2.6.34 though so did
already have the above two patches (ath9k_sta_remove() on his trace),
the 2.6.33 kernel did not however have these two patches. Ming eventually
cured his lockdep warnign via the patch a9f042c titled:
ath9k: fix lockdep warning when unloading module
This went in to 2.6.34 and although it was not marked as a stable
fix it did get trickled down and applied on both 2.6.33 and 2.6.32.
In review, the culprits:
mac80211: allow station add/remove to sleep
git describe --contains 34e895075e21be3e21e71d6317440d1ee7969ad0
v2.6.34-rc1~233^2~49^2~107
ath9k: convert to new station add/remove callbacks
git describe --contains 4ca778605cfec53d8a689f0b57babb93b030c784
v2.6.34-rc1~233^2~49^2~10
ath9k: fix lockdep warning when unloading module
This last one trickled down to 2.6.33 (OK), 2.6.33 (invalid) and 2.6.32 (invalid).
git describe --contains a9f042cbe5284f34ccff15f3084477e11b39b17b
v2.6.34-rc2~48^2~77^2~7
git describe --contains 0524bcfa80f1fffb4e1fe18a0a28900869a58a7c
v2.6.33.2~125
git describe --contains 0dcc9985f34aef3c60bffab3dfc7f7ba3748f35a
v2.6.32.11~79
The patch titled "ath9k: fix lockdep warning when unloading module"
should be reverted on both 2.6.33 and 2.6.32 as it is invalid and
actually ended up causing the following warning:
ADDRCONF(NETDEV_CHANGE): wlan31: link becomes ready
phy0: WMM queue=2 aci=0 acm=0 aifs=3 cWmin=15 cWmax=1023 txop=0
phy0: WMM queue=3 aci=1 acm=0 aifs=7 cWmin=15 cWmax=1023 txop=0
phy0: WMM queue=1 aci=2 acm=0 aifs=2 cWmin=7 cWmax=15 txop=94
phy0: WMM queue=0 aci=3 acm=0 aifs=2 cWmin=3 cWmax=7 txop=47
phy0: device now idle
------------[ cut here ]------------
WARNING: at kernel/softirq.c:143 local_bh_enable_ip+0x7b/0xa0()
Hardware name: 7660A14
Modules linked in: ath9k(-) mac80211 ath cfg80211 <whatever-bleh-etc>
Pid: 2003, comm: rmmod Not tainted 2.6.32.11 #6
Call Trace:
[<ffffffff8105d178>] warn_slowpath_common+0x78/0xb0
[<ffffffff8105d1bf>] warn_slowpath_null+0xf/0x20
[<ffffffff81063f8b>] local_bh_enable_ip+0x7b/0xa0
[<ffffffff815121e4>] _spin_unlock_bh+0x14/0x20
[<ffffffffa034aea5>] ath_tx_node_cleanup+0x185/0x1b0 [ath9k]
[<ffffffffa0345597>] ath9k_sta_notify+0x57/0xb0 [ath9k]
[<ffffffffa02ac51a>] __sta_info_unlink+0x15a/0x260 [mac80211]
[<ffffffffa02ac658>] sta_info_unlink+0x38/0x60 [mac80211]
[<ffffffffa02b3fbe>] ieee80211_set_disassoc+0x1ae/0x210 [mac80211]
[<ffffffffa02b42d9>] ieee80211_mgd_deauth+0x109/0x110 [mac80211]
[<ffffffffa02ba409>] ieee80211_deauth+0x19/0x20 [mac80211]
[<ffffffffa028160e>] __cfg80211_mlme_deauth+0xee/0x130 [cfg80211]
[<ffffffff81118540>] ? init_object+0x50/0x90
[<ffffffffa0285429>] __cfg80211_disconnect+0x159/0x1d0 [cfg80211]
[<ffffffffa027125f>] cfg80211_netdev_notifier_call+0x10f/0x450 [cfg80211]
[<ffffffff81514ca7>] notifier_call_chain+0x47/0x90
[<ffffffff8107f501>] raw_notifier_call_chain+0x11/0x20
[<ffffffff81442d66>] call_netdevice_notifiers+0x16/0x20
[<ffffffff8144352d>] dev_close+0x4d/0xa0
[<ffffffff814439a8>] rollback_registered+0x48/0x120
[<ffffffff81443a9d>] unregister_netdevice+0x1d/0x70
[<ffffffffa02b6cc4>] ieee80211_remove_interfaces+0x84/0xc0 [mac80211]
[<ffffffffa02aa072>] ieee80211_unregister_hw+0x42/0xf0 [mac80211]
[<ffffffffa0347bde>] ath_detach+0x8e/0x180 [ath9k]
[<ffffffffa0347ce1>] ath_cleanup+0x11/0x50 [ath9k]
[<ffffffffa0351a2c>] ath_pci_remove+0x1c/0x20 [ath9k]
[<ffffffff8129d712>] pci_device_remove+0x32/0x60
[<ffffffff81332373>] __device_release_driver+0x53/0xb0
[<ffffffff81332498>] driver_detach+0xc8/0xd0
[<ffffffff81331405>] bus_remove_driver+0x85/0xe0
[<ffffffff81332a5a>] driver_unregister+0x5a/0x90
[<ffffffff8129da00>] pci_unregister_driver+0x40/0xb0
[<ffffffffa03518d0>] ath_pci_exit+0x10/0x20 [ath9k]
[<ffffffffa0353cd5>] ath9k_exit+0x9/0x2a [ath9k]
[<ffffffff81092838>] sys_delete_module+0x1a8/0x270
[<ffffffff8107ebe9>] ? up_read+0x9/0x10
[<ffffffff81011f82>] system_call_fastpath+0x16/0x1b
---[ end trace fad957019ffdd40b ]---
phy0: Removed STA 00:22:6b:56:fd:e8
phy0: Destroyed STA 00:22:6b:56:fd:e8
wlan31: deauthenticating from 00:22:6b:56:fd:e8 by local choice (reason=3)
ath9k 0000:16:00.0: PCI INT A disabled
The original lockdep fixed an issue where due to the new changes
the driver was not disabling the bottom halves but it is incorrect
to do this on the older kernels since IRQs are already disabled.
Cc: Ming Lei <tom.leiming@gmail.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: John W. Linville <linville@tuxdriver.com>
---
Greg, I've tested 2.6.32.11 and 2.6.33.4 both with and without
this patch. This cures the WARNING for both. This same patch
applies to both 2.6.33.y and 2.6.33.y branches of the stable
series.
drivers/net/wireless/ath/ath9k/xmit.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index a232361..e499fb6 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2190,7 +2190,7 @@ void ath_tx_node_cleanup(struct ath_softc *sc, struct ath_node *an)
if (ATH_TXQ_SETUP(sc, i)) {
txq = &sc->tx.txq[i];
- spin_lock_bh(&txq->axq_lock);
+ spin_lock(&txq->axq_lock);
list_for_each_entry_safe(ac,
ac_tmp, &txq->axq_acq, list) {
@@ -2211,7 +2211,7 @@ void ath_tx_node_cleanup(struct ath_softc *sc, struct ath_node *an)
}
}
- spin_unlock_bh(&txq->axq_lock);
+ spin_unlock(&txq->axq_lock);
}
}
}
--
1.6.3.3
^ permalink raw reply related
* [PATCH] Revert "ath9k: fix lockdep warning when unloading module" on stable kernels
From: Luis R. Rodriguez @ 2010-05-19 21:33 UTC (permalink / raw)
To: greg, stable
Cc: linux-kernel, linux-wireless, Luis R. Rodriguez, Ming Lei,
Johannes Berg, John W. Linville
Johannes' patch 34e8950 titled:
mac80211: allow station add/remove to sleep
changed the way mac80211 adds and removes peers. The new
sta_add() / sta_remove() callbacks allowed the driver callbacks
to sleep. Johannes also ported ath9k to use sta_add() / sta_remove()
via the patch 4ca7786 titled:
ath9k: convert to new station add/remove callbacks
but this patch forgot to address a change in locking issue which
Ming Lei eventually found on his 2.6.33-wl #12 build. The 2.6.33-wl
build includes code for the 802.11 subsystem for 2.6.34 though so did
already have the above two patches (ath9k_sta_remove() on his trace),
the 2.6.33 kernel did not however have these two patches. Ming eventually
cured his lockdep warnign via the patch a9f042c titled:
ath9k: fix lockdep warning when unloading module
This went in to 2.6.34 and although it was not marked as a stable
fix it did get trickled down and applied on both 2.6.33 and 2.6.32.
In review, the culprits:
mac80211: allow station add/remove to sleep
git describe --contains 34e895075e21be3e21e71d6317440d1ee7969ad0
v2.6.34-rc1~233^2~49^2~107
ath9k: convert to new station add/remove callbacks
git describe --contains 4ca778605cfec53d8a689f0b57babb93b030c784
v2.6.34-rc1~233^2~49^2~10
ath9k: fix lockdep warning when unloading module
This last one trickled down to 2.6.33 (OK), 2.6.33 (invalid) and 2.6.32 (invalid).
git describe --contains a9f042cbe5284f34ccff15f3084477e11b39b17b
v2.6.34-rc2~48^2~77^2~7
git describe --contains 0524bcfa80f1fffb4e1fe18a0a28900869a58a7c
v2.6.33.2~125
git describe --contains 0dcc9985f34aef3c60bffab3dfc7f7ba3748f35a
v2.6.32.11~79
The patch titled "ath9k: fix lockdep warning when unloading module"
should be reverted on both 2.6.33 and 2.6.32 as it is invalid and
actually ended up causing the following warning:
ADDRCONF(NETDEV_CHANGE): wlan31: link becomes ready
phy0: WMM queue=2 aci=0 acm=0 aifs=3 cWmin=15 cWmax=1023 txop=0
phy0: WMM queue=3 aci=1 acm=0 aifs=7 cWmin=15 cWmax=1023 txop=0
phy0: WMM queue=1 aci=2 acm=0 aifs=2 cWmin=7 cWmax=15 txop=94
phy0: WMM queue=0 aci=3 acm=0 aifs=2 cWmin=3 cWmax=7 txop=47
phy0: device now idle
------------[ cut here ]------------
WARNING: at kernel/softirq.c:143 local_bh_enable_ip+0x7b/0xa0()
Hardware name: 7660A14
Modules linked in: ath9k(-) mac80211 ath cfg80211 <whatever-bleh-etc>
Pid: 2003, comm: rmmod Not tainted 2.6.32.11 #6
Call Trace:
[<ffffffff8105d178>] warn_slowpath_common+0x78/0xb0
[<ffffffff8105d1bf>] warn_slowpath_null+0xf/0x20
[<ffffffff81063f8b>] local_bh_enable_ip+0x7b/0xa0
[<ffffffff815121e4>] _spin_unlock_bh+0x14/0x20
[<ffffffffa034aea5>] ath_tx_node_cleanup+0x185/0x1b0 [ath9k]
[<ffffffffa0345597>] ath9k_sta_notify+0x57/0xb0 [ath9k]
[<ffffffffa02ac51a>] __sta_info_unlink+0x15a/0x260 [mac80211]
[<ffffffffa02ac658>] sta_info_unlink+0x38/0x60 [mac80211]
[<ffffffffa02b3fbe>] ieee80211_set_disassoc+0x1ae/0x210 [mac80211]
[<ffffffffa02b42d9>] ieee80211_mgd_deauth+0x109/0x110 [mac80211]
[<ffffffffa02ba409>] ieee80211_deauth+0x19/0x20 [mac80211]
[<ffffffffa028160e>] __cfg80211_mlme_deauth+0xee/0x130 [cfg80211]
[<ffffffff81118540>] ? init_object+0x50/0x90
[<ffffffffa0285429>] __cfg80211_disconnect+0x159/0x1d0 [cfg80211]
[<ffffffffa027125f>] cfg80211_netdev_notifier_call+0x10f/0x450 [cfg80211]
[<ffffffff81514ca7>] notifier_call_chain+0x47/0x90
[<ffffffff8107f501>] raw_notifier_call_chain+0x11/0x20
[<ffffffff81442d66>] call_netdevice_notifiers+0x16/0x20
[<ffffffff8144352d>] dev_close+0x4d/0xa0
[<ffffffff814439a8>] rollback_registered+0x48/0x120
[<ffffffff81443a9d>] unregister_netdevice+0x1d/0x70
[<ffffffffa02b6cc4>] ieee80211_remove_interfaces+0x84/0xc0 [mac80211]
[<ffffffffa02aa072>] ieee80211_unregister_hw+0x42/0xf0 [mac80211]
[<ffffffffa0347bde>] ath_detach+0x8e/0x180 [ath9k]
[<ffffffffa0347ce1>] ath_cleanup+0x11/0x50 [ath9k]
[<ffffffffa0351a2c>] ath_pci_remove+0x1c/0x20 [ath9k]
[<ffffffff8129d712>] pci_device_remove+0x32/0x60
[<ffffffff81332373>] __device_release_driver+0x53/0xb0
[<ffffffff81332498>] driver_detach+0xc8/0xd0
[<ffffffff81331405>] bus_remove_driver+0x85/0xe0
[<ffffffff81332a5a>] driver_unregister+0x5a/0x90
[<ffffffff8129da00>] pci_unregister_driver+0x40/0xb0
[<ffffffffa03518d0>] ath_pci_exit+0x10/0x20 [ath9k]
[<ffffffffa0353cd5>] ath9k_exit+0x9/0x2a [ath9k]
[<ffffffff81092838>] sys_delete_module+0x1a8/0x270
[<ffffffff8107ebe9>] ? up_read+0x9/0x10
[<ffffffff81011f82>] system_call_fastpath+0x16/0x1b
---[ end trace fad957019ffdd40b ]---
phy0: Removed STA 00:22:6b:56:fd:e8
phy0: Destroyed STA 00:22:6b:56:fd:e8
wlan31: deauthenticating from 00:22:6b:56:fd:e8 by local choice (reason=3)
ath9k 0000:16:00.0: PCI INT A disabled
The original lockdep fixed an issue where due to the new changes
the driver was not disabling the bottom halves but it is incorrect
to do this on the older kernels since IRQs are already disabled.
Cc: Ming Lei <tom.leiming@gmail.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: John W. Linville <linville@tuxdriver.com>
---
Greg, I've tested 2.6.32.11 and 2.6.33.4 both with and without
this patch. This cures the WARNING for both. This same patch
applies to both 2.6.33.y and 2.6.33.y branches of the stable
series.
drivers/net/wireless/ath/ath9k/xmit.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index a232361..e499fb6 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2190,7 +2190,7 @@ void ath_tx_node_cleanup(struct ath_softc *sc, struct ath_node *an)
if (ATH_TXQ_SETUP(sc, i)) {
txq = &sc->tx.txq[i];
- spin_lock_bh(&txq->axq_lock);
+ spin_lock(&txq->axq_lock);
list_for_each_entry_safe(ac,
ac_tmp, &txq->axq_acq, list) {
@@ -2211,7 +2211,7 @@ void ath_tx_node_cleanup(struct ath_softc *sc, struct ath_node *an)
}
}
- spin_unlock_bh(&txq->axq_lock);
+ spin_unlock(&txq->axq_lock);
}
}
}
--
1.6.3.3
^ permalink raw reply related
* [PATCH] ath9k_hw: Enable TX IQ calibration on AR9003
From: Luis R. Rodriguez @ 2010-05-19 20:45 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez
To enable it we now disable and re-enable the PHY chips
after TX IQ calibration.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/ath/ath9k/ar9003_calib.c | 10 ++++++----
drivers/net/wireless/ath/ath9k/hw.c | 6 ------
drivers/net/wireless/ath/ath9k/hw.h | 1 -
3 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_calib.c b/drivers/net/wireless/ath/ath9k/ar9003_calib.c
index 5fcafb4..15bf4e2 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_calib.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_calib.c
@@ -740,6 +740,12 @@ static bool ar9003_hw_init_cal(struct ath_hw *ah,
*/
ar9003_hw_set_chain_masks(ah, 0x7, 0x7);
+ /* Do Tx IQ Calibration */
+ ar9003_hw_tx_iq_cal(ah);
+ REG_WRITE(ah, AR_PHY_ACTIVE, AR_PHY_ACTIVE_DIS);
+ udelay(5);
+ REG_WRITE(ah, AR_PHY_ACTIVE, AR_PHY_ACTIVE_EN);
+
/* Calibrate the AGC */
REG_WRITE(ah, AR_PHY_AGC_CONTROL,
REG_READ(ah, AR_PHY_AGC_CONTROL) |
@@ -754,10 +760,6 @@ static bool ar9003_hw_init_cal(struct ath_hw *ah,
return false;
}
- /* Do Tx IQ Calibration */
- if (ah->config.tx_iq_calibration)
- ar9003_hw_tx_iq_cal(ah);
-
/* Revert chainmasks to their original values before NF cal */
ar9003_hw_set_chain_masks(ah, ah->rxchainmask, ah->txchainmask);
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 7b9779a..fe0a60b 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -392,12 +392,6 @@ static void ath9k_hw_init_config(struct ath_hw *ah)
ah->config.rx_intr_mitigation = true;
/*
- * Tx IQ Calibration (ah->config.tx_iq_calibration) is only
- * used by AR9003, but it is showing reliability issues.
- * It will take a while to fix so this is currently disabled.
- */
-
- /*
* We need this for PCI devices only (Cardbus, PCI, miniPCI)
* _and_ if on non-uniprocessor systems (Multiprocessor/HT).
* This means we use it for all AR5416 devices, and the few
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index 9124edd..ab19f4e 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -263,7 +263,6 @@ struct ath9k_ops_config {
#define AR_BASE_FREQ_5GHZ 4900
#define AR_SPUR_FEEQ_BOUND_HT40 19
#define AR_SPUR_FEEQ_BOUND_HT20 10
- bool tx_iq_calibration; /* Only available for >= AR9003 */
int spurmode;
u16 spurchans[AR_EEPROM_MODAL_SPURS][2];
u8 max_txtrig_level;
--
1.6.3.3
^ permalink raw reply related
* ath5k breaks wifi link under load (AR5007EG)
From: Vladimir Preobrazhensky @ 2010-05-19 19:32 UTC (permalink / raw)
To: linux-wireless
Hello!
I got a kind of long-lasting problem, wish it has a solution.
I have an Atheros AR5007EG adapter in my netbook (acer aspire one AOA110) and wifi router is TrendNet TEW-452BRP. Kernel uses ath5k driver to control this.
PCI ID: vendor code VEN_168C, dev code DEV_001C.
I tried several linux kernels, starting from Ubuntu 8.04 (don't remember now which verision was there) to Ubuntu 10.4 and even have tried linux 2.6.34 today.
The wifi link seems to work in general, as long as I do some lazy web browsing, chatting, IM-ing etc, that is, which imposes low network utilization.
But every time I do something that causes a substantial network load, my wifi link breaks. I mean, that happens when I watch AVI files or download some other big files from my LAN samba server, or download some big RPM from the Internet.
The Windows XP system, pre-installed here, allows to watch video over wifi for hours.
The Ubuntu 10.4 Netbook Remix system performs well on video playback, when connected over wired thernet.
Regards,
Vladimir Probrazhensky
^ permalink raw reply
* Re: [PATCH v2 7/7] rt2x00: Fix HT40 operation in rt2800.
From: Ivo Van Doorn @ 2010-05-19 19:19 UTC (permalink / raw)
To: Gertjan van Wingerde
Cc: John W. Linville, Helmut Schaa, linux-wireless, users
In-Reply-To: <1274296671-13596-1-git-send-email-gwingerde@gmail.com>
On Wed, May 19, 2010 at 9:17 PM, Gertjan van Wingerde
<gwingerde@gmail.com> wrote:
> Closer inspection of the legacy Ralink driver reveals that in case of HT40+
> or HT40- we must adjust the frequency settings that we program to the device.
> Implement the same adjustment in the rt2x00 code.
>
> With this HT40 seems to work for all devices supported by rt2800pci and
> rt2800usb.
>
> Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
^ permalink raw reply
* [PATCH v2 7/7] rt2x00: Fix HT40 operation in rt2800.
From: Gertjan van Wingerde @ 2010-05-19 19:17 UTC (permalink / raw)
To: John W. Linville
Cc: Ivo van Doorn, Helmut Schaa, linux-wireless, users,
Gertjan van Wingerde
Closer inspection of the legacy Ralink driver reveals that in case of HT40+
or HT40- we must adjust the frequency settings that we program to the device.
Implement the same adjustment in the rt2x00 code.
With this HT40 seems to work for all devices supported by rt2800pci and
rt2800usb.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
---
v2: Handled feedback from Ivo.
---
drivers/net/wireless/rt2x00/rt2800lib.c | 5 +----
drivers/net/wireless/rt2x00/rt2x00config.c | 12 ++++++++----
drivers/net/wireless/rt2x00/rt2x00ht.c | 27 +++++++++++++++++++++++++++
drivers/net/wireless/rt2x00/rt2x00lib.h | 9 +++++++++
4 files changed, 45 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index 8ffbc3c..15322f0 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -2530,11 +2530,8 @@ int rt2800_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
else
spec->ht.ht_supported = false;
- /*
- * Don't set IEEE80211_HT_CAP_SUP_WIDTH_20_40 for now as it causes
- * reception problems with HT40 capable 11n APs
- */
spec->ht.cap =
+ IEEE80211_HT_CAP_SUP_WIDTH_20_40 |
IEEE80211_HT_CAP_GRN_FLD |
IEEE80211_HT_CAP_SGI_20 |
IEEE80211_HT_CAP_SGI_40 |
diff --git a/drivers/net/wireless/rt2x00/rt2x00config.c b/drivers/net/wireless/rt2x00/rt2x00config.c
index 098315a..8dbd634 100644
--- a/drivers/net/wireless/rt2x00/rt2x00config.c
+++ b/drivers/net/wireless/rt2x00/rt2x00config.c
@@ -170,23 +170,27 @@ void rt2x00lib_config(struct rt2x00_dev *rt2x00dev,
unsigned int ieee80211_flags)
{
struct rt2x00lib_conf libconf;
+ u16 hw_value;
memset(&libconf, 0, sizeof(libconf));
libconf.conf = conf;
if (ieee80211_flags & IEEE80211_CONF_CHANGE_CHANNEL) {
- if (conf_is_ht40(conf))
+ if (conf_is_ht40(conf)) {
__set_bit(CONFIG_CHANNEL_HT40, &rt2x00dev->flags);
- else
+ hw_value = rt2x00ht_center_channel(rt2x00dev, conf);
+ } else {
__clear_bit(CONFIG_CHANNEL_HT40, &rt2x00dev->flags);
+ hw_value = conf->channel->hw_value;
+ }
memcpy(&libconf.rf,
- &rt2x00dev->spec.channels[conf->channel->hw_value],
+ &rt2x00dev->spec.channels[hw_value],
sizeof(libconf.rf));
memcpy(&libconf.channel,
- &rt2x00dev->spec.channels_info[conf->channel->hw_value],
+ &rt2x00dev->spec.channels_info[hw_value],
sizeof(libconf.channel));
}
diff --git a/drivers/net/wireless/rt2x00/rt2x00ht.c b/drivers/net/wireless/rt2x00/rt2x00ht.c
index 5a40760..588c766 100644
--- a/drivers/net/wireless/rt2x00/rt2x00ht.c
+++ b/drivers/net/wireless/rt2x00/rt2x00ht.c
@@ -84,3 +84,31 @@ void rt2x00ht_create_tx_descriptor(struct queue_entry *entry,
else
txdesc->txop = TXOP_HTTXOP;
}
+
+u16 rt2x00ht_center_channel(struct rt2x00_dev *rt2x00dev,
+ struct ieee80211_conf *conf)
+{
+ struct hw_mode_spec *spec = &rt2x00dev->spec;
+ int center_channel;
+ u16 i;
+
+ /*
+ * Initialize center channel to current channel.
+ */
+ center_channel = spec->channels[conf->channel->hw_value].channel;
+
+ /*
+ * Adjust center channel to HT40+ and HT40- operation.
+ */
+ if (conf_is_ht40_plus(conf))
+ center_channel += 2;
+ else if (conf_is_ht40_minus(conf))
+ center_channel -= (center_channel == 14) ? 1 : 2;
+
+ for (i = 0; i < spec->num_channels; i++)
+ if (spec->channels[i].channel == center_channel)
+ return i;
+
+ WARN_ON(1);
+ return conf->channel->hw_value;
+}
diff --git a/drivers/net/wireless/rt2x00/rt2x00lib.h b/drivers/net/wireless/rt2x00/rt2x00lib.h
index 822affc..ed27de1 100644
--- a/drivers/net/wireless/rt2x00/rt2x00lib.h
+++ b/drivers/net/wireless/rt2x00/rt2x00lib.h
@@ -367,12 +367,21 @@ static inline void rt2x00crypto_rx_insert_iv(struct sk_buff *skb,
void rt2x00ht_create_tx_descriptor(struct queue_entry *entry,
struct txentry_desc *txdesc,
const struct rt2x00_rate *hwrate);
+
+u16 rt2x00ht_center_channel(struct rt2x00_dev *rt2x00dev,
+ struct ieee80211_conf *conf);
#else
static inline void rt2x00ht_create_tx_descriptor(struct queue_entry *entry,
struct txentry_desc *txdesc,
const struct rt2x00_rate *hwrate)
{
}
+
+static inline u16 rt2x00ht_center_channel(struct rt2x00_dev *rt2x00dev,
+ struct ieee80211_conf *conf)
+{
+ return conf->channel->hw_value;
+}
#endif /* CONFIG_RT2X00_LIB_HT */
/*
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 7/7] rt2x00: Fix HT40 operation in rt2800.
From: Gertjan van Wingerde @ 2010-05-19 19:08 UTC (permalink / raw)
To: Ivo Van Doorn; +Cc: John W. Linville, Helmut Schaa, linux-wireless, users
In-Reply-To: <AANLkTikIaVSC6ZXjRUKD7J1rbGdf-JWCO7H4TGU5KZnx@mail.gmail.com>
On 05/19/10 20:14, Ivo Van Doorn wrote:
>> +u16 rt2x00ht_center_channel(struct rt2x00_dev *rt2x00dev,
>> + struct ieee80211_conf *conf)
>> +{
>> + struct hw_mode_spec *spec = &rt2x00dev->spec;
>> + int center_channel;
>> + u16 i;
>> +
>> + /*
>> + * Initialize center channel to current channel.
>> + */
>> + center_channel = spec->channels[conf->channel->hw_value].channel;
>> +
>> + /*
>> + * Adjust center channel to HT40+ and HT40- operation.
>> + */
>> + if (conf_is_ht40_plus(conf))
>> + center_channel += 2;
>> + else if (conf_is_ht40_minus(conf))
>> + center_channel -= (center_channel == 14) ? 1 : 2;
>> +
>> + for (i = 0; i < spec->num_channels; i++)
>> + if (spec->channels[i].channel == center_channel)
>> + return i;
>> +
>> + BUG();
>> +}
>
> This isn't worth a BUG(), perhaps a debug message or WARN(),
> I would say a debug message and retuning the hw_value.
>
Oops, yes. BUG() is a bit too much here. This is simply left-over from testing.
Personally I think WARN() should be more appropriate, as it signifies an error situation
that really should not happen, and we want to atract a bit more attention to it than a
simple debug message.
v2 is on its way.
---
Gertjan.
^ permalink raw reply
* Re: [PATCH] cfg80211: make action channel type optional
From: Pavel Roskin @ 2010-05-19 19:05 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, Jouni Malinen, linux-wireless
In-Reply-To: <1274294939.19404.4.camel@jlt3.sipsolutions.net>
On Wed, 2010-05-19 at 20:48 +0200, Johannes Berg wrote:
> On Wed, 2010-05-19 at 14:19 -0400, Pavel Roskin wrote:
> > On Wed, 2010-05-19 at 12:17 +0200, Johannes Berg wrote:
> >
> > > @@ -1168,6 +1168,7 @@ struct cfg80211_ops {
> > > int (*action)(struct wiphy *wiphy, struct net_device *dev,
> > > struct ieee80211_channel *chan,
> > > enum nl80211_channel_type channel_type,
> > > + bool channel_type_valid,
> > > const u8 *buf, size_t len, u64 *cookie);
> >
> > Would not it be easier to introduce NL80211_CHAN_UNSPECIFIED in enum
> > nl80211_channel_type?
>
> Yes, but it would change the userspace API so we can't do that.
I believe the new API would be a superset of the old API. No userspace
caller would need to be changed.
Anyway, I just wanted to be sure that a simpler solution was considered.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] cfg80211: make action channel type optional
From: Johannes Berg @ 2010-05-19 18:48 UTC (permalink / raw)
To: Pavel Roskin; +Cc: John Linville, Jouni Malinen, linux-wireless
In-Reply-To: <1274293152.8463.2.camel@mj>
On Wed, 2010-05-19 at 14:19 -0400, Pavel Roskin wrote:
> On Wed, 2010-05-19 at 12:17 +0200, Johannes Berg wrote:
>
> > @@ -1168,6 +1168,7 @@ struct cfg80211_ops {
> > int (*action)(struct wiphy *wiphy, struct net_device *dev,
> > struct ieee80211_channel *chan,
> > enum nl80211_channel_type channel_type,
> > + bool channel_type_valid,
> > const u8 *buf, size_t len, u64 *cookie);
>
> Would not it be easier to introduce NL80211_CHAN_UNSPECIFIED in enum
> nl80211_channel_type?
Yes, but it would change the userspace API so we can't do that.
johannes
^ permalink raw reply
* Re: [Oops-report] problem with ath9k at shutdown
From: Luis R. Rodriguez @ 2010-05-19 18:40 UTC (permalink / raw)
To: Huub Reuver; +Cc: John W. Linville, Luis Rodriguez, linux-wireless
In-Reply-To: <20100518165330.GC4209@tux>
On Tue, May 18, 2010 at 9:53 AM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Mon, May 17, 2010 at 10:41:40PM -0700, Huub Reuver wrote:
>> On Mon, May 17, 2010 at 01:24:04PM -0400, John W. Linville wrote:
>> > On Mon, May 17, 2010 at 09:55:31AM -0700, Luis R. Rodriguez wrote:
>> > > On Mon, May 17, 2010 at 07:32:41AM -0700, John W. Linville wrote:
>> > > > Did you try 2.6.34? I'm pretty sure we merged a fix for this...
>> > >
>> > > Ditto, and I think it was not related to ath9k but mac80211.
>> > >
>> > > Was it this maybe?
>> > >
>> > > commit a9f042cbe5284f34ccff15f3084477e11b39b17b
>> > > Author: Ming Lei <tom.leiming@gmail.com>
>> > > Date: Sun Feb 28 00:56:24 2010 +0800
>> > >
>> > > ath9k: fix lockdep warning when unloading module
>> > >
>> > > Johannes had noted:
>> > >
>> > > "I think the problem is that the locking for sta_notify changed, and a
>> > > patch that was written for the new locking was backported to the old,
>> > > irq-disabled, locking."
>> >
>> > Yeah, maybe that is what I was thinking about....
>>
>> The traces do not look similar to me, but I'm not a programmer.
>>
>> I have done a few tests:
>> 2.6.32.9 not affected
>> 2.6.32.13 affected
>> 2.6.33.3 affected
>> 2.6.33.4 affected
>> 2.6.34 the problem seems to have been fixed.
>>
>> Sorry for my slow report and response.
>> Thanks for your quick answer, I'll have to switch to 2.6.34 for a
>> production kernel.
>
> Eh, I am not sure what happened here... this must've been a fix
> regression as I do not recall seeing this on earlier 2.6.32.y releases.
> Can you try an earlier 2.6.32.y?
I have a fix for this, I'll post this soon, testing 2.6.33 now.
Luis
^ permalink raw reply
* Re: [PATCH 5/7] rt2x00: Move PCI/USB specific register initializations to rt2800{pci,usb}.
From: Gertjan van Wingerde @ 2010-05-19 18:33 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: John W. Linville, Helmut Schaa, linux-wireless, users
In-Reply-To: <201005192026.53773.IvDoorn@gmail.com>
On 05/19/10 20:26, Ivo van Doorn wrote:
> On Wednesday 19 May 2010 17:26:07 Gertjan van Wingerde wrote:
>> This prevents us having common code depend on PCI or USB specific code.
>>
>> Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
>> ---
>
> To which tree are you creating your diffs?
> This one doesn't apply to latest wireless-testing.git or rt2x00,git
>
All my patches are against wireless-next-2.6.git, as that is the tree John will use to merge patches
in.
I believe there indeed is a slight difference between that tree and wireless-testing.git
with respect to the <linux/slab.h> inclusion, causing applying errors against wireless-testing.
---
Gertjan.
^ permalink raw reply
* Re: [PATCH 5/7] rt2x00: Move PCI/USB specific register initializations to rt2800{pci,usb}.
From: Ivo van Doorn @ 2010-05-19 18:26 UTC (permalink / raw)
To: Gertjan van Wingerde
Cc: John W. Linville, Helmut Schaa, linux-wireless, users
In-Reply-To: <1274282769-19244-6-git-send-email-gwingerde@gmail.com>
On Wednesday 19 May 2010 17:26:07 Gertjan van Wingerde wrote:
> This prevents us having common code depend on PCI or USB specific code.
>
> Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
> ---
To which tree are you creating your diffs?
This one doesn't apply to latest wireless-testing.git or rt2x00,git
Ivo
^ 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