* Re: [PATCH 00/41] rewritten rt2800 drivers
From: Luis R. Rodriguez @ 2009-11-05 21:06 UTC (permalink / raw)
To: Gertjan van Wingerde
Cc: Bartlomiej Zolnierkiewicz, linux-wireless, Ivo van Doorn,
linux-kernel, John W. Linville
In-Reply-To: <4AF33C9E.6090609@gmail.com>
On Thu, Nov 5, 2009 at 12:59 PM, Gertjan van Wingerde
<gwingerde@gmail.com> wrote:
> On 11/04/09 21:19, Gertjan van Wingerde wrote:
>> On Wed, Nov 4, 2009 at 6:31 PM, Bartlomiej Zolnierkiewicz
>> <bzolnier@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> Here is the rt2800 rewrite in the form of patches (I've trimmed cc:
>>> list considerably since I'm not sure whether most people really want
>>> to see 40+ patches in their mailboxes).
>>>
>>>
>>> There were some minor changes since yesterday:
>>>
>>> - two new patches were added at the top of tree fixing Kconfig help
>>> entries of rt2800[pci,usb] drivers to be more helpful and to prevent
>>> wasting people's time (I think that patch #1 should go to Linus'
>>> tree as soon as possible, ditto for patch #2 and net-next tree)
>>>
>>> - patch descriptions were improved for many patches
>>> (suggestion from Ingo)
>>>
>>> - rt2x00_intf_is_[pci,usb]() helpers for commonly used checks were
>>> added to "rt2x00: add support for different chipset interfaces" patch
>>> (suggestion from Ivo)
>>>
>>> - addition of separate rt2800 MAINTAINERS entry was dropped for now
>>> because it stirred needless controversies distracting people from
>>> technical issues (thanks to Julian Calaby for pointing this to me),
>>> the goal of change was to make sure that people won't bother busy
>>> rt2x00 maintainers about rt2800 tree so it is not a big deal anyway
>>>
>>>
>>> The rt2800 tree has also been updated to reflect those changes
>>> (old branch is still available as rt2800-v1 for reference):
>>>
>>> The following changes since commit fa867e7355a1bdcd9bf7d55ebe9296f5b9c4028a:
>>> Juuso Oikarinen (1):
>>> wl1271: Generalize command response reading
>>>
>>> are available in the git repository at:
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/bart/misc.git rt2800
>>>
>>> Bartlomiej Zolnierkiewicz (41):
>>> rt2800usb: make Kconfig help entry more helpful
>>> rt2800pci: make Kconfig help entry more helpful
>>> rt2800usb: fix rt2800usb_rfcsr_read()
>>> rt2800pci: fix crypto in TX frame
>>> rt2800pci: fix comment about register access
>>> rt2800pci: fix comment about IV/EIV fields
>>> rt2x00: fix rt2x00usb_register_read() comment
>>> rt2800usb: use rt2x00usb_register_multiwrite() to set key entries
>>> rt2800usb: add rt2800_register_[read,write]() wrappers
>>> rt2800pci: add rt2800_register_[read,write]() wrappers
>>> rt2800usb: add rt2800_register_multi[read,write]() wrappers
>>> rt2800pci: add rt2800_register_multi[read,write]() wrappers
>>> rt2800usb: add rt2800_regbusy_read() wrapper
>>> rt2800pci: add rt2800_regbusy_read() wrapper
>>> rt2800usb: add rt2800_bbp_[read,write]() wrappers
>>> rt2800pci: add rt2800_bbp_[read,write]() wrappers
>>> rt2800usb: add rt2800_rfcsr_[read,write]() wrappers
>>> rt2800pci: add rt2800_rfcsr_[read,write]() wrappers
>>> rt2800usb: add rt2800_rf_[read,write]() wrappers
>>> rt2800pci: add rt2800_rf_[read,write]() wrappers
>>> rt2800usb: add rt2800_mcu_request() wrapper
>>> rt2800pci: add rt2800_mcu_request() wrapper
>>> rt2x00: add driver private field to struct rt2x00_dev
>>> rt2800usb: convert to use struct rt2800_ops methods
>>> rt2800pci: convert to use struct rt2800_ops methods
>>> rt2x00: fix rt2x00usb_register_multiwrite() arguments
>>> rt2x00: fix rt2x00usb_regbusy_read() arguments
>>> rt2x00: fix rt2x00pci_register_multi[read,write]() arguments
>>> rt2800: add rt2800lib.h
>>> rt2800usb: fix comments in rt2800usb.h
>>> rt2800usb: add RXINFO_DESC_SIZE definition
>>> rt2800: fix duplication in header files
>>> rt2800: fix comments in rt2800.h
>>> rt2x00: add support for different chipset interfaces
>>> rt2800: prepare for rt2800lib addition
>>> rt2800: add rt2800lib (part one)
>>> rt2x00: remove needless ifdefs from rt2x00leds.h
>>> rt2800: add rt2800lib (part two)
>>> rt2x00: move REGISTER_BUSY_* definitions to rt2x00.h
>>> rt2800: add rt2800lib (part three)
>>> rt2800: add rt2800lib (part four)
>>>
>>> drivers/net/wireless/rt2x00/Kconfig | 16 +-
>>> drivers/net/wireless/rt2x00/Makefile | 1 +
>>> drivers/net/wireless/rt2x00/rt2800.h | 1816 ++++++++++++++++++++++++++++
>>> drivers/net/wireless/rt2x00/rt2800lib.c | 1817 ++++++++++++++++++++++++++++
>>> drivers/net/wireless/rt2x00/rt2800lib.h | 134 +++
>>> drivers/net/wireless/rt2x00/rt2800pci.c | 1908 +++---------------------------
>>> drivers/net/wireless/rt2x00/rt2800pci.h | 1780 ----------------------------
>>> drivers/net/wireless/rt2x00/rt2800usb.c | 1828 ++---------------------------
>>> drivers/net/wireless/rt2x00/rt2800usb.h | 1818 +----------------------------
>>> drivers/net/wireless/rt2x00/rt2x00.h | 43 +
>>> drivers/net/wireless/rt2x00/rt2x00leds.h | 4 -
>>> drivers/net/wireless/rt2x00/rt2x00pci.h | 24 +-
>>> drivers/net/wireless/rt2x00/rt2x00usb.c | 2 +-
>>> drivers/net/wireless/rt2x00/rt2x00usb.h | 17 +-
>>> 14 files changed, 4048 insertions(+), 7160 deletions(-)
>>> create mode 100644 drivers/net/wireless/rt2x00/rt2800.h
>>> create mode 100644 drivers/net/wireless/rt2x00/rt2800lib.c
>>> create mode 100644 drivers/net/wireless/rt2x00/rt2800lib.h
>>>
>>
>> Hi Bart,
>>
>> Many thanks for these patches.
>>
>> So far I have been able to go through the first 30 patches of the
>> series. I'll finish the other 11 tomorrow (when I'm back home and have
>> better facilities to review these more elaborate patches of the
>> series).
>> They all look fine to me, I only had a comment for patch 10.
>>
>> I've sent my ACKs for the remaining 29 I reviewed.
>>
>> I guess Ivo still has to review them as well, as, so far, he has been
>> the one of the rt2x00 project to give the final ACK for inclusion,
>> unless he indicates that he is fine with my assessments.
>>
>> ---
>> Gertjan
>> rt2x00 developer
>>
>
> OK. I have now completed my review of the remaining patches and have sent my ACKs for those.
A little summary would be nice for those who don't want to read single
line acks/nacks.
Luis
^ permalink raw reply
* Re: [PATCH 00/41] rewritten rt2800 drivers
From: Gertjan van Wingerde @ 2009-11-05 21:17 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Bartlomiej Zolnierkiewicz, linux-wireless, Ivo van Doorn,
linux-kernel, John W. Linville
In-Reply-To: <43e72e890911051306q632ad8ar833346f5a4ea60fa@mail.gmail.com>
On 11/05/09 22:06, Luis R. Rodriguez wrote:
> On Thu, Nov 5, 2009 at 12:59 PM, Gertjan van Wingerde
> <gwingerde@gmail.com> wrote:
>> On 11/04/09 21:19, Gertjan van Wingerde wrote:
>>> On Wed, Nov 4, 2009 at 6:31 PM, Bartlomiej Zolnierkiewicz
>>> <bzolnier@gmail.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Here is the rt2800 rewrite in the form of patches (I've trimmed cc:
>>>> list considerably since I'm not sure whether most people really want
>>>> to see 40+ patches in their mailboxes).
>>>>
>>>>
>>>> There were some minor changes since yesterday:
>>>>
>>>> - two new patches were added at the top of tree fixing Kconfig help
>>>> entries of rt2800[pci,usb] drivers to be more helpful and to prevent
>>>> wasting people's time (I think that patch #1 should go to Linus'
>>>> tree as soon as possible, ditto for patch #2 and net-next tree)
>>>>
>>>> - patch descriptions were improved for many patches
>>>> (suggestion from Ingo)
>>>>
>>>> - rt2x00_intf_is_[pci,usb]() helpers for commonly used checks were
>>>> added to "rt2x00: add support for different chipset interfaces" patch
>>>> (suggestion from Ivo)
>>>>
>>>> - addition of separate rt2800 MAINTAINERS entry was dropped for now
>>>> because it stirred needless controversies distracting people from
>>>> technical issues (thanks to Julian Calaby for pointing this to me),
>>>> the goal of change was to make sure that people won't bother busy
>>>> rt2x00 maintainers about rt2800 tree so it is not a big deal anyway
>>>>
>>>>
>>>> The rt2800 tree has also been updated to reflect those changes
>>>> (old branch is still available as rt2800-v1 for reference):
>>>>
>>>> The following changes since commit fa867e7355a1bdcd9bf7d55ebe9296f5b9c4028a:
>>>> Juuso Oikarinen (1):
>>>> wl1271: Generalize command response reading
>>>>
>>>> are available in the git repository at:
>>>>
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/bart/misc.git rt2800
>>>>
>>>> Bartlomiej Zolnierkiewicz (41):
>>>> rt2800usb: make Kconfig help entry more helpful
>>>> rt2800pci: make Kconfig help entry more helpful
>>>> rt2800usb: fix rt2800usb_rfcsr_read()
>>>> rt2800pci: fix crypto in TX frame
>>>> rt2800pci: fix comment about register access
>>>> rt2800pci: fix comment about IV/EIV fields
>>>> rt2x00: fix rt2x00usb_register_read() comment
>>>> rt2800usb: use rt2x00usb_register_multiwrite() to set key entries
>>>> rt2800usb: add rt2800_register_[read,write]() wrappers
>>>> rt2800pci: add rt2800_register_[read,write]() wrappers
>>>> rt2800usb: add rt2800_register_multi[read,write]() wrappers
>>>> rt2800pci: add rt2800_register_multi[read,write]() wrappers
>>>> rt2800usb: add rt2800_regbusy_read() wrapper
>>>> rt2800pci: add rt2800_regbusy_read() wrapper
>>>> rt2800usb: add rt2800_bbp_[read,write]() wrappers
>>>> rt2800pci: add rt2800_bbp_[read,write]() wrappers
>>>> rt2800usb: add rt2800_rfcsr_[read,write]() wrappers
>>>> rt2800pci: add rt2800_rfcsr_[read,write]() wrappers
>>>> rt2800usb: add rt2800_rf_[read,write]() wrappers
>>>> rt2800pci: add rt2800_rf_[read,write]() wrappers
>>>> rt2800usb: add rt2800_mcu_request() wrapper
>>>> rt2800pci: add rt2800_mcu_request() wrapper
>>>> rt2x00: add driver private field to struct rt2x00_dev
>>>> rt2800usb: convert to use struct rt2800_ops methods
>>>> rt2800pci: convert to use struct rt2800_ops methods
>>>> rt2x00: fix rt2x00usb_register_multiwrite() arguments
>>>> rt2x00: fix rt2x00usb_regbusy_read() arguments
>>>> rt2x00: fix rt2x00pci_register_multi[read,write]() arguments
>>>> rt2800: add rt2800lib.h
>>>> rt2800usb: fix comments in rt2800usb.h
>>>> rt2800usb: add RXINFO_DESC_SIZE definition
>>>> rt2800: fix duplication in header files
>>>> rt2800: fix comments in rt2800.h
>>>> rt2x00: add support for different chipset interfaces
>>>> rt2800: prepare for rt2800lib addition
>>>> rt2800: add rt2800lib (part one)
>>>> rt2x00: remove needless ifdefs from rt2x00leds.h
>>>> rt2800: add rt2800lib (part two)
>>>> rt2x00: move REGISTER_BUSY_* definitions to rt2x00.h
>>>> rt2800: add rt2800lib (part three)
>>>> rt2800: add rt2800lib (part four)
>>>>
>>>> drivers/net/wireless/rt2x00/Kconfig | 16 +-
>>>> drivers/net/wireless/rt2x00/Makefile | 1 +
>>>> drivers/net/wireless/rt2x00/rt2800.h | 1816 ++++++++++++++++++++++++++++
>>>> drivers/net/wireless/rt2x00/rt2800lib.c | 1817 ++++++++++++++++++++++++++++
>>>> drivers/net/wireless/rt2x00/rt2800lib.h | 134 +++
>>>> drivers/net/wireless/rt2x00/rt2800pci.c | 1908 +++---------------------------
>>>> drivers/net/wireless/rt2x00/rt2800pci.h | 1780 ----------------------------
>>>> drivers/net/wireless/rt2x00/rt2800usb.c | 1828 ++---------------------------
>>>> drivers/net/wireless/rt2x00/rt2800usb.h | 1818 +----------------------------
>>>> drivers/net/wireless/rt2x00/rt2x00.h | 43 +
>>>> drivers/net/wireless/rt2x00/rt2x00leds.h | 4 -
>>>> drivers/net/wireless/rt2x00/rt2x00pci.h | 24 +-
>>>> drivers/net/wireless/rt2x00/rt2x00usb.c | 2 +-
>>>> drivers/net/wireless/rt2x00/rt2x00usb.h | 17 +-
>>>> 14 files changed, 4048 insertions(+), 7160 deletions(-)
>>>> create mode 100644 drivers/net/wireless/rt2x00/rt2800.h
>>>> create mode 100644 drivers/net/wireless/rt2x00/rt2800lib.c
>>>> create mode 100644 drivers/net/wireless/rt2x00/rt2800lib.h
>>>>
>>>
>>> Hi Bart,
>>>
>>> Many thanks for these patches.
>>>
>>> So far I have been able to go through the first 30 patches of the
>>> series. I'll finish the other 11 tomorrow (when I'm back home and have
>>> better facilities to review these more elaborate patches of the
>>> series).
>>> They all look fine to me, I only had a comment for patch 10.
>>>
>>> I've sent my ACKs for the remaining 29 I reviewed.
>>>
>>> I guess Ivo still has to review them as well, as, so far, he has been
>>> the one of the rt2x00 project to give the final ACK for inclusion,
>>> unless he indicates that he is fine with my assessments.
>>>
>>> ---
>>> Gertjan
>>> rt2x00 developer
>>>
>>
>> OK. I have now completed my review of the remaining patches and have sent my ACKs for those.
>
> A little summary would be nice for those who don't want to read single
> line acks/nacks.
>
I'm sorry. In my mind the message was clear that I Acked all of the remaining patches in the series.
Apparently not :-(
So, basically, from my side all patches have been acked, with the exception of path 10 of the series (which was only a minor issue).
---
Gertjan.
^ permalink raw reply
* Re: [PATCH] Libertas: Fix issues while configuring host sleep
From: Dan Williams @ 2009-11-05 21:36 UTC (permalink / raw)
To: Bing Zhao; +Cc: libertas-dev, Amitkumar Karwar, linux-wireless
In-Reply-To: <1257383195-951-1-git-send-email-bzhao@marvell.com>
On Wed, 2009-11-04 at 17:06 -0800, Bing Zhao wrote:
> From: Amitkumar Karwar <akarwar@marvell.com>
>
> Configuration of wake-on-lan for unicast, multicast, broadcast, physical
> activity was not working. Kernel panic issue was there when user tries to
> disable WOL. Fixed them.
>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> Signed-off-by: Bing Zhao <bzhao@marvell.com>
Acked-by: Dan Williams <dcbw@redhat.com>
> ---
> drivers/net/wireless/libertas/ethtool.c | 16 +++++++++++-----
> 1 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/wireless/libertas/ethtool.c b/drivers/net/wireless/libertas/ethtool.c
> index 039b555..eeda6d7 100644
> --- a/drivers/net/wireless/libertas/ethtool.c
> +++ b/drivers/net/wireless/libertas/ethtool.c
> @@ -169,16 +169,22 @@ static int lbs_ethtool_set_wol(struct net_device *dev,
> struct lbs_private *priv = dev->ml_priv;
> uint32_t criteria = 0;
>
> - if (priv->wol_criteria == 0xffffffff && wol->wolopts)
> + if (priv->wol_criteria != 0xffffffff && wol->wolopts)
> return -EOPNOTSUPP;
>
> if (wol->wolopts & ~(WAKE_UCAST|WAKE_MCAST|WAKE_BCAST|WAKE_PHY))
> return -EOPNOTSUPP;
>
> - if (wol->wolopts & WAKE_UCAST) criteria |= EHS_WAKE_ON_UNICAST_DATA;
> - if (wol->wolopts & WAKE_MCAST) criteria |= EHS_WAKE_ON_MULTICAST_DATA;
> - if (wol->wolopts & WAKE_BCAST) criteria |= EHS_WAKE_ON_BROADCAST_DATA;
> - if (wol->wolopts & WAKE_PHY) criteria |= EHS_WAKE_ON_MAC_EVENT;
> + if (wol->wolopts & WAKE_UCAST)
> + criteria |= EHS_WAKE_ON_UNICAST_DATA;
> + if (wol->wolopts & WAKE_MCAST)
> + criteria |= EHS_WAKE_ON_MULTICAST_DATA;
> + if (wol->wolopts & WAKE_BCAST)
> + criteria |= EHS_WAKE_ON_BROADCAST_DATA;
> + if (wol->wolopts & WAKE_PHY)
> + criteria |= EHS_WAKE_ON_MAC_EVENT;
> + if (wol->wolopts == 0)
> + criteria |= EHS_REMOVE_WAKEUP;
>
> return lbs_host_sleep_cfg(priv, criteria, (struct wol_config *)NULL);
> }
^ permalink raw reply
* Re: [PATCH] rtl8187: Remove deprecated 'qual' from returned RX status
From: Larry Finger @ 2009-11-06 0:56 UTC (permalink / raw)
To: Michael Buesch
Cc: Hin-Tak Leung, John W Linville, Hin-Tak Leung,
Herton Ronaldo Krzesinski, linux-wireless
In-Reply-To: <200911052024.32608.mb@bu3sch.de>
On 11/05/2009 01:24 PM, Michael Buesch wrote:
> On Thursday 05 November 2009 20:21:39 Hin-Tak Leung wrote:
>>> + * is derived from the AGC. The arbitrary scaling constants
>>> * are chosen to make the results close to the values obtained
>>> * for a BCM4312 using b43 as the driver. The noise is ignored
>
> It's not really a good idea to take b43 for reference, because the values/scales
> are chosen pretty arbitrarily in that driver. So you basically end up
> with an arbitrary^2 value.
When I did that, b43 was the only other device that I had available.
As Hin-Tak said, one has to start somewhere. As we all know, only
relative values are significant, and the absolute value has little
meaning.
Larry
^ permalink raw reply
* ipw2100 still broken when compiled against 2.6.27.29
From: Philip A. Prindeville @ 2009-11-06 7:26 UTC (permalink / raw)
To: linux-wireless
Anyone else noticed that ipw2100 has been broken for several days when
compiled against 2.6.27.29?
CC [M] /home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless/ipw2x00/ipw2100.o
/home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless/ipw2x00/ipw2100.c: In function 'ipw2100_alloc_device':
/home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless/ipw2x00/ipw2100.c:6063: error: 'struct iw_public_data' has no member named 'ieee80211'
/home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless/ipw2x00/ipw2100.c: At top level:
/home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless/ipw2x00/ipw2100.c:8328: error: unknown field 'num_private' specified in initializer
/home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless/ipw2x00/ipw2100.c:8328: warning: initialization makes pointer from integer without a cast
/home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless/ipw2x00/ipw2100.c:8329: error: unknown field 'num_private_args' specified in initializer
/home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless/ipw2x00/ipw2100.c:8329: warning: excess elements in struct initializer
/home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless/ipw2x00/ipw2100.c:8329: warning: (near initialization for 'ipw2100_wx_handler_def')
/home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless/ipw2x00/ipw2100.c:8330: error: unknown field 'private' specified in initializer
/home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless/ipw2x00/ipw2100.c:8330: warning: excess elements in struct initializer
/home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless/ipw2x00/ipw2100.c:8330: warning: (near initialization for 'ipw2100_wx_handler_def')
/home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless/ipw2x00/ipw2100.c:8331: error: unknown field 'private_args' specified in initializer
/home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless/ipw2x00/ipw2100.c:8331: warning: excess elements in struct initializer
/home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless/ipw2x00/ipw2100.c:8331: warning: (near initialization for 'ipw2100_wx_handler_def')
make[5]: *** [/home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless/ipw2x00/ipw2100.o] Error 1
make[4]: *** [/home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless/ipw2x00] Error 2
make[3]: *** [/home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless] Error 2
make[2]: *** [_module_/home/philipp/alix/build_i586/compat-wireless-2009-11-04] Error 2
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: Pavel Machek @ 2009-11-06 7:46 UTC (permalink / raw)
To: Ivo van Doorn
Cc: Ingo Molnar, Bartlomiej Zolnierkiewicz, linux-wireless,
linux-kernel, netdev, Randy Dunlap, Luis Correia,
John W. Linville, Johannes Berg, Jarek Poplawski, Pekka Enberg,
David Miller
In-Reply-To: <200911042251.23506.IvDoorn@gmail.com>
> > Look at the diffstat of Bart's driver:
> >
> > 15 files changed, 4036 insertions(+), 7158 deletions(-)
> >
> > He reduced your 5.2 KLOC non-working driver into a 1.8 KLOC _working_
> > driver.
>
> Bullshit, read the mails again.
This was uncalled for, right?
...
> Some people actually require sleep during the night, perhaps that you don't need
> that and can hence review 41 patches which changes thousands of lines on the
> same day the patches were submitted.
If you lack time, "Really start reading my mails" sentence you used at
the start of email is *not* user-friendly way to say that.
> > And _still_ your complaint about Bart's series is that he updated the
> > MAINTAINERS entry and added an entry for rt2800? Heck _sure_ he should
> > update it, he is the one doing the hard work of trying to bring it to
> > users, trying to clean up a messy driver space, trying to turn crap into
> > gold.
>
> So if I want to focus on something different in the kernel, I just send 1 patch,
> and a second to claim the maintainership of it even though there is an active
> maintainer available?
What about listing yourself as a maintainer for a start?
> > The thing is, if you dont have the time or interest to listen to and act
> > upon review feedback, be constructive about it and fix (obvious)
> > structural problems in your rt2800 code, you should just step aside and
> > let Bart maintain what he is apparently more capable of maintaining than
> > you are.
> >
> > What you are doing here is a thinly veiled land-grab: you did a minimal
> > token driver for rt2800 that doesnt work, kept it in your private tree
> > for _1.5 years_, and the moment someone _else_ came along and did
> > something better and more functional in drivers/staging/, you discovered
> > your sudden interest for it and moved the crappy driver upstream at
> > lightning's speed (it is already in net-next AFAICS, despite negative
> > test and review feedback) - ignoring and throwing away all the work that
> > Bart has done.
>
> Get your facts straight, the bullshit level in your mail is staggering.
>
> You have no fucking clue who wrote the rt2800 driver which is in
> drivers/staging/,
Perhaps you should not be a maintainer if you can't behave yourself?
> Because a lot of people prefer looking from the sideline,
> contributing _nothing_
Given your behaviour, I'm not suprised people are not too eager to
work with you.
> As for "throwing away that work" I ACKED 10 of his patches, and said I would review
> the rest later! But like I said, apparently it is a bad habit for people to sleep during
> the night.
Read your email again. It was quite far from 'acked 10, asked for
time'. You flamed him first.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Getting random regulatory domains on boot-up with ath9k
From: Jeffrey Baker @ 2009-11-06 8:04 UTC (permalink / raw)
To: linux-wireless
I am trying to work with a card made with Atheros 9280, but I find
that I am getting essentially random regulatory domains. The very
first time I booted the system, under Linux 2.6.30, I got the country
code AT. Subsequently I got US. Then I upgraded to
compat-wireless-2009-11-06 and now I get AW (Aruba).
dmesg says:
ath: EEPROM regdomain: 0x37
ath: EEPROM indicates we should expect a direct regpair map
ath: Country alpha2 being used: AW
ath: Regpair used: 0x37
cfg80211: Calling CRDA for country: AW
Now, my understanding is that 0x37 is world roaming. The key sentence
from the docs seems to be this:
"Regulatory pair regulatory domains are mapped to the first
ISO-3166-alpha2 country."
Does that mean that AW is the first country code in the 0x37
regulatory pair group?
The result is this list of channels
5180 MHz [36] (30.0 dBm) (passive scanning, no IBSS)
5200 MHz [40] (30.0 dBm) (passive scanning, no IBSS)
5220 MHz [44] (30.0 dBm) (passive scanning, no IBSS)
5240 MHz [48] (30.0 dBm) (passive scanning, no IBSS)
5260 MHz [52] (30.0 dBm) (passive scanning, no IBSS, radar detection)
5280 MHz [56] (30.0 dBm) (passive scanning, no IBSS, radar detection)
5300 MHz [60] (30.0 dBm) (passive scanning, no IBSS, radar detection)
5320 MHz [64] (30.0 dBm) (passive scanning, no IBSS, radar detection)
5500 MHz [100] (disabled)
5520 MHz [104] (disabled)
5540 MHz [108] (disabled)
5560 MHz [112] (disabled)
5580 MHz [116] (disabled)
5600 MHz [120] (disabled)
5620 MHz [124] (disabled)
5640 MHz [128] (disabled)
5660 MHz [132] (disabled)
5680 MHz [136] (disabled)
5700 MHz [140] (disabled)
5745 MHz [149] (30.0 dBm) (passive scanning, no IBSS)
5765 MHz [153] (30.0 dBm) (passive scanning, no IBSS)
5785 MHz [157] (30.0 dBm) (passive scanning, no IBSS)
5805 MHz [161] (30.0 dBm) (passive scanning, no IBSS)
5825 MHz [165] (30.0 dBm) (passive scanning, no IBSS)
... which in summary prevents me from operating an access point in the
5GHz band at all. The perplexing thing is that I was able to use
channel 36 under kernel.org 2.6.30, so from my perspective that
software was working better than the current software does, and of
course leads me to believe that I can use software to change this card
to FCC regs instead of these frustrating "world" regs which prevent me
from running an AP.
Needless to say, I am perplexed by this behavior. The exact phy is
"Atheros AR9280 Rev:2"
-jwb
^ permalink raw reply
* Re: ipw2100 still broken when compiled against 2.6.27.29
From: Philip A. Prindeville @ 2009-11-06 8:08 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <4AF3CFA8.7010808@redfish-solutions.com>
Doing successive daily builds going backwards, it seems the first
breakage appeared 2009-10-07:
CC [M] /home/philipp/alix/build_i586/compat-wireless-2009-10-07/drivers/net/wireless/ipw2x00/ipw2100.o
LD [M] /home/philipp/alix/build_i586/compat-wireless-2009-10-07/drivers/ssb/ssb.o
CC [M] /home/philipp/alix/build_i586/compat-wireless-2009-10-07/drivers/net/wireless/ipw2x00/ipw2200.o
CC [M] /home/philipp/alix/build_i586/compat-wireless-2009-10-07/net/mac80211/agg-tx.o
CC [M] /home/philipp/alix/build_i586/compat-wireless-2009-10-07/net/rfkill/input.o
CC [M] /home/philipp/alix/build_i586/compat-wireless-2009-10-07/drivers/net/wireless/ath/ath9k/ani.o
/home/philipp/alix/build_i586/compat-wireless-2009-10-07/drivers/net/wireless/ipw2x00/ipw2100.c:8321: error: unknown field 'num_private' specified in initializer
/home/philipp/alix/build_i586/compat-wireless-2009-10-07/drivers/net/wireless/ipw2x00/ipw2100.c:8321: warning: initialization makes pointer from integer without a cast
/home/philipp/alix/build_i586/compat-wireless-2009-10-07/drivers/net/wireless/ipw2x00/ipw2100.c:8322: error: unknown field 'num_private_args' specified in initializer
/home/philipp/alix/build_i586/compat-wireless-2009-10-07/drivers/net/wireless/ipw2x00/ipw2100.c:8322: warning: excess elements in struct initializer
/home/philipp/alix/build_i586/compat-wireless-2009-10-07/drivers/net/wireless/ipw2x00/ipw2100.c:8322: warning: (near initialization for 'ipw2100_wx_handler_def')
/home/philipp/alix/build_i586/compat-wireless-2009-10-07/drivers/net/wireless/ipw2x00/ipw2100.c:8323: error: unknown field 'private' specified in initializer
/home/philipp/alix/build_i586/compat-wireless-2009-10-07/drivers/net/wireless/ipw2x00/ipw2100.c:8323: warning: excess elements in struct initializer
/home/philipp/alix/build_i586/compat-wireless-2009-10-07/drivers/net/wireless/ipw2x00/ipw2100.c:8323: warning: (near initialization for 'ipw2100_wx_handler_def')
/home/philipp/alix/build_i586/compat-wireless-2009-10-07/drivers/net/wireless/ipw2x00/ipw2100.c:8324: error: unknown field 'private_args' specified in initializer
/home/philipp/alix/build_i586/compat-wireless-2009-10-07/drivers/net/wireless/ipw2x00/ipw2100.c:8324: warning: excess elements in struct initializer
/home/philipp/alix/build_i586/compat-wireless-2009-10-07/drivers/net/wireless/ipw2x00/ipw2100.c:8324: warning: (near initialization for 'ipw2100_wx_handler_def')
make[5]: *** [/home/philipp/alix/build_i586/compat-wireless-2009-10-07/drivers/net/wireless/ipw2x00/ipw2100.o] Error 1
make[5]: *** Waiting for unfinished jobs....
Philip A. Prindeville wrote:
> Anyone else noticed that ipw2100 has been broken for several days when
> compiled against 2.6.27.29?
>
> CC [M]
> /home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless/ipw2x00/ipw2100.o
>
> /home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless/ipw2x00/ipw2100.c:
> In function 'ipw2100_alloc_device':
> /home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless/ipw2x00/ipw2100.c:6063:
> error: 'struct iw_public_data' has no member named 'ieee80211'
> /home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless/ipw2x00/ipw2100.c:
> At top level:
> /home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless/ipw2x00/ipw2100.c:8328:
> error: unknown field 'num_private' specified in initializer
> /home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless/ipw2x00/ipw2100.c:8328:
> warning: initialization makes pointer from integer without a cast
> /home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless/ipw2x00/ipw2100.c:8329:
> error: unknown field 'num_private_args' specified in initializer
> /home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless/ipw2x00/ipw2100.c:8329:
> warning: excess elements in struct initializer
> /home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless/ipw2x00/ipw2100.c:8329:
> warning: (near initialization for 'ipw2100_wx_handler_def')
> /home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless/ipw2x00/ipw2100.c:8330:
> error: unknown field 'private' specified in initializer
> /home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless/ipw2x00/ipw2100.c:8330:
> warning: excess elements in struct initializer
> /home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless/ipw2x00/ipw2100.c:8330:
> warning: (near initialization for 'ipw2100_wx_handler_def')
> /home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless/ipw2x00/ipw2100.c:8331:
> error: unknown field 'private_args' specified in initializer
> /home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless/ipw2x00/ipw2100.c:8331:
> warning: excess elements in struct initializer
> /home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless/ipw2x00/ipw2100.c:8331:
> warning: (near initialization for 'ipw2100_wx_handler_def')
> make[5]: ***
> [/home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless/ipw2x00/ipw2100.o]
> Error 1
> make[4]: ***
> [/home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless/ipw2x00]
> Error 2
> make[3]: ***
> [/home/philipp/alix/build_i586/compat-wireless-2009-11-04/drivers/net/wireless]
> Error 2
> make[2]: ***
> [_module_/home/philipp/alix/build_i586/compat-wireless-2009-11-04]
> Error 2
>
>
^ permalink raw reply
* Re: Getting random regulatory domains on boot-up with ath9k
From: Holger Schurig @ 2009-11-06 9:50 UTC (permalink / raw)
To: Jeffrey Baker; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <fd145f7d0911060004j55b06482tca088685d0626249@mail.gmail.com>
> ath: EEPROM regdomain: 0x37
> ath: EEPROM indicates we should expect a direct regpair map
> ath: Country alpha2 being used: AW
> ath: Regpair used: 0x37
> cfg80211: Calling CRDA for country: AW
I can confirm this bug on wireless-testing, v2.6.32-rc6-41576-g4408b3b
with an ath5k card:
[ 9.193118] ath: doing EEPROM country->regdmn map search
[ 9.193121] ath: country maps to regdmn code: 0x37
[ 9.193124] ath: Country alpha2 being used: DK
[ 9.193126] ath: Regpair used: 0x37
[ 9.207182] phy0: Selected rate control algorithm 'minstrel'
[ 9.207874] ath5k phy0: Atheros AR2414 chip found (MAC: 0x79, PHY: 0x45)
[ 9.208801] cfg80211: Calling CRDA for country: DK
[ 9.221773] cfg80211: Regulatory domain changed to country: DK
^ permalink raw reply
* [PATCH] mac80211: async station powersave handling
From: Johannes Berg @ 2009-11-06 10:35 UTC (permalink / raw)
To: John Linville; +Cc: Jouni Malinen, linux-wireless
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
include/net/mac80211.h | 32 ++++++++++++
net/mac80211/debugfs_sta.c | 5 +
net/mac80211/main.c | 8 +--
net/mac80211/rx.c | 86 +++++---------------------------
net/mac80211/sta_info.c | 118 ++++++++++++++++++++++++++++++++++++++++++++-
net/mac80211/sta_info.h | 23 +++++++-
net/mac80211/tx.c | 13 +++-
7 files changed, 200 insertions(+), 85 deletions(-)
--- wireless-testing.orig/net/mac80211/debugfs_sta.c 2009-11-06 11:34:24.000000000 +0100
+++ wireless-testing/net/mac80211/debugfs_sta.c 2009-11-06 11:34:30.000000000 +0100
@@ -66,10 +66,11 @@ static ssize_t sta_flags_read(struct fil
char buf[100];
struct sta_info *sta = file->private_data;
u32 staflags = get_sta_flags(sta);
- int res = scnprintf(buf, sizeof(buf), "%s%s%s%s%s%s%s%s",
+ int res = scnprintf(buf, sizeof(buf), "%s%s%s%s%s%s%s%s%s",
staflags & WLAN_STA_AUTH ? "AUTH\n" : "",
staflags & WLAN_STA_ASSOC ? "ASSOC\n" : "",
- staflags & WLAN_STA_PS ? "PS\n" : "",
+ staflags & WLAN_STA_PS_STA ? "PS (sta)\n" : "",
+ staflags & WLAN_STA_PS_DRIVER ? "PS (driver)\n" : "",
staflags & WLAN_STA_AUTHORIZED ? "AUTHORIZED\n" : "",
staflags & WLAN_STA_SHORT_PREAMBLE ? "SHORT PREAMBLE\n" : "",
staflags & WLAN_STA_WME ? "WME\n" : "",
--- wireless-testing.orig/net/mac80211/main.c 2009-11-06 11:34:25.000000000 +0100
+++ wireless-testing/net/mac80211/main.c 2009-11-06 11:34:30.000000000 +0100
@@ -385,13 +385,13 @@ static void ieee80211_handle_filtered_fr
* can be unknown, for example with different interrupt status
* bits.
*/
- if (test_sta_flags(sta, WLAN_STA_PS) &&
+ if (test_sta_flags(sta, WLAN_STA_PS_STA) &&
skb_queue_len(&sta->tx_filtered) < STA_MAX_TX_BUFFER) {
skb_queue_tail(&sta->tx_filtered, skb);
return;
}
- if (!test_sta_flags(sta, WLAN_STA_PS) &&
+ if (!test_sta_flags(sta, WLAN_STA_PS_STA) &&
!(info->flags & IEEE80211_TX_INTFL_RETRIED)) {
/* Software retry the packet once */
info->flags |= IEEE80211_TX_INTFL_RETRIED;
@@ -406,7 +406,7 @@ static void ieee80211_handle_filtered_fr
"queue_len=%d PS=%d @%lu\n",
wiphy_name(local->hw.wiphy),
skb_queue_len(&sta->tx_filtered),
- !!test_sta_flags(sta, WLAN_STA_PS), jiffies);
+ !!test_sta_flags(sta, WLAN_STA_PS_STA), jiffies);
#endif
dev_kfree_skb(skb);
}
@@ -446,7 +446,7 @@ void ieee80211_tx_status(struct ieee8021
if (sta) {
if (!(info->flags & IEEE80211_TX_STAT_ACK) &&
- test_sta_flags(sta, WLAN_STA_PS)) {
+ test_sta_flags(sta, WLAN_STA_PS_STA)) {
/*
* The STA is in power save mode, so assume
* that this TX packet failed because of that.
--- wireless-testing.orig/net/mac80211/rx.c 2009-11-06 11:34:24.000000000 +0100
+++ wireless-testing/net/mac80211/rx.c 2009-11-06 11:34:30.000000000 +0100
@@ -781,7 +781,7 @@ static void ap_sta_ps_start(struct sta_i
struct ieee80211_local *local = sdata->local;
atomic_inc(&sdata->bss->num_sta_ps);
- set_sta_flags(sta, WLAN_STA_PS);
+ set_sta_flags(sta, WLAN_STA_PS_STA);
drv_sta_notify(local, &sdata->vif, STA_NOTIFY_SLEEP, &sta->sta);
#ifdef CONFIG_MAC80211_VERBOSE_PS_DEBUG
printk(KERN_DEBUG "%s: STA %pM aid %d enters power save mode\n",
@@ -792,33 +792,25 @@ static void ap_sta_ps_start(struct sta_i
static void ap_sta_ps_end(struct sta_info *sta)
{
struct ieee80211_sub_if_data *sdata = sta->sdata;
- struct ieee80211_local *local = sdata->local;
- int sent, buffered;
atomic_dec(&sdata->bss->num_sta_ps);
- clear_sta_flags(sta, WLAN_STA_PS);
- drv_sta_notify(local, &sdata->vif, STA_NOTIFY_AWAKE, &sta->sta);
-
- if (!skb_queue_empty(&sta->ps_tx_buf))
- sta_info_clear_tim_bit(sta);
+ clear_sta_flags(sta, WLAN_STA_PS_STA);
#ifdef CONFIG_MAC80211_VERBOSE_PS_DEBUG
printk(KERN_DEBUG "%s: STA %pM aid %d exits power save mode\n",
sdata->dev->name, sta->sta.addr, sta->sta.aid);
#endif /* CONFIG_MAC80211_VERBOSE_PS_DEBUG */
- /* Send all buffered frames to the station */
- sent = ieee80211_add_pending_skbs(local, &sta->tx_filtered);
- buffered = ieee80211_add_pending_skbs(local, &sta->ps_tx_buf);
- sent += buffered;
- local->total_ps_buffered -= buffered;
-
+ if (test_sta_flags(sta, WLAN_STA_PS_DRIVER)) {
#ifdef CONFIG_MAC80211_VERBOSE_PS_DEBUG
- printk(KERN_DEBUG "%s: STA %pM aid %d sending %d filtered/%d PS frames "
- "since STA not sleeping anymore\n", sdata->dev->name,
- sta->sta.addr, sta->sta.aid, sent - buffered, buffered);
+ printk(KERN_DEBUG "%s: STA %pM aid %d driver-ps-blocked\n",
+ sdata->dev->name, sta->sta.addr, sta->sta.aid);
#endif /* CONFIG_MAC80211_VERBOSE_PS_DEBUG */
+ return;
+ }
+
+ ieee80211_sta_ps_deliver_wakeup(sta);
}
static ieee80211_rx_result debug_noinline
@@ -866,7 +858,7 @@ ieee80211_rx_h_sta_process(struct ieee80
if (!ieee80211_has_morefrags(hdr->frame_control) &&
(rx->sdata->vif.type == NL80211_IFTYPE_AP ||
rx->sdata->vif.type == NL80211_IFTYPE_AP_VLAN)) {
- if (test_sta_flags(sta, WLAN_STA_PS)) {
+ if (test_sta_flags(sta, WLAN_STA_PS_STA)) {
/*
* Ignore doze->wake transitions that are
* indicated by non-data frames, the standard
@@ -1094,9 +1086,7 @@ ieee80211_rx_h_defragment(struct ieee802
static ieee80211_rx_result debug_noinline
ieee80211_rx_h_ps_poll(struct ieee80211_rx_data *rx)
{
- struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(rx->dev);
- struct sk_buff *skb;
- int no_pending_pkts;
+ struct ieee80211_sub_if_data *sdata = rx->sdata;
__le16 fc = ((struct ieee80211_hdr *)rx->skb->data)->frame_control;
if (likely(!rx->sta || !ieee80211_is_pspoll(fc) ||
@@ -1107,56 +1097,10 @@ ieee80211_rx_h_ps_poll(struct ieee80211_
(sdata->vif.type != NL80211_IFTYPE_AP_VLAN))
return RX_DROP_UNUSABLE;
- skb = skb_dequeue(&rx->sta->tx_filtered);
- if (!skb) {
- skb = skb_dequeue(&rx->sta->ps_tx_buf);
- if (skb)
- rx->local->total_ps_buffered--;
- }
- no_pending_pkts = skb_queue_empty(&rx->sta->tx_filtered) &&
- skb_queue_empty(&rx->sta->ps_tx_buf);
-
- if (skb) {
- struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
- struct ieee80211_hdr *hdr =
- (struct ieee80211_hdr *) skb->data;
-
- /*
- * Tell TX path to send this frame even though the STA may
- * still remain is PS mode after this frame exchange.
- */
- info->flags |= IEEE80211_TX_CTL_PSPOLL_RESPONSE;
-
-#ifdef CONFIG_MAC80211_VERBOSE_PS_DEBUG
- printk(KERN_DEBUG "STA %pM aid %d: PS Poll (entries after %d)\n",
- rx->sta->sta.addr, rx->sta->sta.aid,
- skb_queue_len(&rx->sta->ps_tx_buf));
-#endif /* CONFIG_MAC80211_VERBOSE_PS_DEBUG */
-
- /* Use MoreData flag to indicate whether there are more
- * buffered frames for this STA */
- if (no_pending_pkts)
- hdr->frame_control &= cpu_to_le16(~IEEE80211_FCTL_MOREDATA);
- else
- hdr->frame_control |= cpu_to_le16(IEEE80211_FCTL_MOREDATA);
-
- ieee80211_add_pending_skb(rx->local, skb);
-
- if (no_pending_pkts)
- sta_info_clear_tim_bit(rx->sta);
-#ifdef CONFIG_MAC80211_VERBOSE_PS_DEBUG
- } else {
- /*
- * FIXME: This can be the result of a race condition between
- * us expiring a frame and the station polling for it.
- * Should we send it a null-func frame indicating we
- * have nothing buffered for it?
- */
- printk(KERN_DEBUG "%s: STA %pM sent PS Poll even "
- "though there are no buffered frames for it\n",
- rx->dev->name, rx->sta->sta.addr);
-#endif /* CONFIG_MAC80211_VERBOSE_PS_DEBUG */
- }
+ if (!test_sta_flags(rx->sta, WLAN_STA_PS_DRIVER))
+ ieee80211_sta_ps_deliver_poll_response(rx->sta);
+ else
+ set_sta_flags(rx->sta, WLAN_STA_PSPOLL);
/* Free PS Poll skb here instead of returning RX_DROP that would
* count as an dropped frame. */
--- wireless-testing.orig/net/mac80211/sta_info.c 2009-11-06 11:34:24.000000000 +0100
+++ wireless-testing/net/mac80211/sta_info.c 2009-11-06 11:34:30.000000000 +0100
@@ -173,6 +173,8 @@ void sta_info_destroy(struct sta_info *s
local = sta->local;
+ cancel_work_sync(&sta->drv_unblock_wk);
+
rate_control_remove_sta_debugfs(sta);
ieee80211_sta_debugfs_remove(sta);
@@ -278,6 +280,21 @@ static int sta_prepare_rate_control(stru
return 0;
}
+static void sta_unblock(struct work_struct *wk)
+{
+ struct sta_info *sta;
+
+ sta = container_of(wk, struct sta_info, drv_unblock_wk);
+
+ if (sta->dead)
+ return;
+
+ if (!test_sta_flags(sta, WLAN_STA_PS_STA))
+ ieee80211_sta_ps_deliver_wakeup(sta);
+ else if (test_and_clear_sta_flags(sta, WLAN_STA_PSPOLL))
+ ieee80211_sta_ps_deliver_poll_response(sta);
+}
+
struct sta_info *sta_info_alloc(struct ieee80211_sub_if_data *sdata,
u8 *addr, gfp_t gfp)
{
@@ -291,6 +308,7 @@ struct sta_info *sta_info_alloc(struct i
spin_lock_init(&sta->lock);
spin_lock_init(&sta->flaglock);
+ INIT_WORK(&sta->drv_unblock_wk, sta_unblock);
memcpy(sta->sta.addr, addr, ETH_ALEN);
sta->local = local;
@@ -493,8 +511,10 @@ static void __sta_info_unlink(struct sta
}
list_del(&(*sta)->list);
+ (*sta)->dead = true;
- if (test_and_clear_sta_flags(*sta, WLAN_STA_PS)) {
+ if (test_and_clear_sta_flags(*sta,
+ WLAN_STA_PS_STA | WLAN_STA_PS_DRIVER)) {
BUG_ON(!sdata->bss);
atomic_dec(&sdata->bss->num_sta_ps);
@@ -840,3 +860,99 @@ struct ieee80211_sta *ieee80211_find_sta
return ieee80211_find_sta_by_hw(&sdata->local->hw, addr);
}
EXPORT_SYMBOL(ieee80211_find_sta);
+
+/* powersave support code */
+void ieee80211_sta_ps_deliver_wakeup(struct sta_info *sta)
+{
+ struct ieee80211_sub_if_data *sdata = sta->sdata;
+ struct ieee80211_local *local = sdata->local;
+ int sent, buffered;
+
+ drv_sta_notify(local, &sdata->vif, STA_NOTIFY_AWAKE, &sta->sta);
+
+ if (!skb_queue_empty(&sta->ps_tx_buf))
+ sta_info_clear_tim_bit(sta);
+
+ /* Send all buffered frames to the station */
+ sent = ieee80211_add_pending_skbs(local, &sta->tx_filtered);
+ buffered = ieee80211_add_pending_skbs(local, &sta->ps_tx_buf);
+ sent += buffered;
+ local->total_ps_buffered -= buffered;
+
+#ifdef CONFIG_MAC80211_VERBOSE_PS_DEBUG
+ printk(KERN_DEBUG "%s: STA %pM aid %d sending %d filtered/%d PS frames "
+ "since STA not sleeping anymore\n", sdata->dev->name,
+ sta->sta.addr, sta->sta.aid, sent - buffered, buffered);
+#endif /* CONFIG_MAC80211_VERBOSE_PS_DEBUG */
+}
+
+void ieee80211_sta_ps_deliver_poll_response(struct sta_info *sta)
+{
+ struct ieee80211_sub_if_data *sdata = sta->sdata;
+ struct ieee80211_local *local = sdata->local;
+ struct sk_buff *skb;
+ int no_pending_pkts;
+
+ skb = skb_dequeue(&sta->tx_filtered);
+ if (!skb) {
+ skb = skb_dequeue(&sta->ps_tx_buf);
+ if (skb)
+ local->total_ps_buffered--;
+ }
+ no_pending_pkts = skb_queue_empty(&sta->tx_filtered) &&
+ skb_queue_empty(&sta->ps_tx_buf);
+
+ if (skb) {
+ struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+ struct ieee80211_hdr *hdr =
+ (struct ieee80211_hdr *) skb->data;
+
+ /*
+ * Tell TX path to send this frame even though the STA may
+ * still remain is PS mode after this frame exchange.
+ */
+ info->flags |= IEEE80211_TX_CTL_PSPOLL_RESPONSE;
+
+#ifdef CONFIG_MAC80211_VERBOSE_PS_DEBUG
+ printk(KERN_DEBUG "STA %pM aid %d: PS Poll (entries after %d)\n",
+ sta->sta.addr, sta->sta.aid,
+ skb_queue_len(&sta->ps_tx_buf));
+#endif /* CONFIG_MAC80211_VERBOSE_PS_DEBUG */
+
+ /* Use MoreData flag to indicate whether there are more
+ * buffered frames for this STA */
+ if (no_pending_pkts)
+ hdr->frame_control &= cpu_to_le16(~IEEE80211_FCTL_MOREDATA);
+ else
+ hdr->frame_control |= cpu_to_le16(IEEE80211_FCTL_MOREDATA);
+
+ ieee80211_add_pending_skb(local, skb);
+
+ if (no_pending_pkts)
+ sta_info_clear_tim_bit(sta);
+#ifdef CONFIG_MAC80211_VERBOSE_PS_DEBUG
+ } else {
+ /*
+ * FIXME: This can be the result of a race condition between
+ * us expiring a frame and the station polling for it.
+ * Should we send it a null-func frame indicating we
+ * have nothing buffered for it?
+ */
+ printk(KERN_DEBUG "%s: STA %pM sent PS Poll even "
+ "though there are no buffered frames for it\n",
+ sdata->dev->name, sta->sta.addr);
+#endif /* CONFIG_MAC80211_VERBOSE_PS_DEBUG */
+ }
+}
+
+void ieee80211_sta_block_awake(struct ieee80211_hw *hw,
+ struct ieee80211_sta *pubsta, bool block)
+{
+ struct sta_info *sta = container_of(pubsta, struct sta_info, sta);
+
+ if (block)
+ set_sta_flags(sta, WLAN_STA_PS_DRIVER);
+ else
+ ieee80211_queue_work(hw, &sta->drv_unblock_wk);
+}
+EXPORT_SYMBOL(ieee80211_sta_block_awake);
--- wireless-testing.orig/net/mac80211/sta_info.h 2009-11-06 11:34:24.000000000 +0100
+++ wireless-testing/net/mac80211/sta_info.h 2009-11-06 11:34:30.000000000 +0100
@@ -12,6 +12,7 @@
#include <linux/list.h>
#include <linux/types.h>
#include <linux/if_ether.h>
+#include <linux/workqueue.h>
#include "key.h"
/**
@@ -21,7 +22,7 @@
*
* @WLAN_STA_AUTH: Station is authenticated.
* @WLAN_STA_ASSOC: Station is associated.
- * @WLAN_STA_PS: Station is in power-save mode
+ * @WLAN_STA_PS_STA: Station is in power-save mode
* @WLAN_STA_AUTHORIZED: Station is authorized to send/receive traffic.
* This bit is always checked so needs to be enabled for all stations
* when virtual port control is not in use.
@@ -36,11 +37,16 @@
* @WLAN_STA_MFP: Management frame protection is used with this STA.
* @WLAN_STA_SUSPEND: Set/cleared during a suspend/resume cycle.
* Used to deny ADDBA requests (both TX and RX).
+ * @WLAN_STA_PS_DRIVER: driver requires keeping this station in
+ * power-save mode logically to flush frames that might still
+ * be in the queues
+ * @WLAN_STA_PSPOLL: Station sent PS-poll while driver was keeping
+ * station in power-save mode, reply when the driver unblocks.
*/
enum ieee80211_sta_info_flags {
WLAN_STA_AUTH = 1<<0,
WLAN_STA_ASSOC = 1<<1,
- WLAN_STA_PS = 1<<2,
+ WLAN_STA_PS_STA = 1<<2,
WLAN_STA_AUTHORIZED = 1<<3,
WLAN_STA_SHORT_PREAMBLE = 1<<4,
WLAN_STA_ASSOC_AP = 1<<5,
@@ -48,7 +54,9 @@ enum ieee80211_sta_info_flags {
WLAN_STA_WDS = 1<<7,
WLAN_STA_CLEAR_PS_FILT = 1<<9,
WLAN_STA_MFP = 1<<10,
- WLAN_STA_SUSPEND = 1<<11
+ WLAN_STA_SUSPEND = 1<<11,
+ WLAN_STA_PS_DRIVER = 1<<12,
+ WLAN_STA_PSPOLL = 1<<13,
};
#define STA_TID_NUM 16
@@ -216,6 +224,8 @@ struct sta_ampdu_mlme {
* @plink_timer_was_running: used by suspend/resume to restore timers
* @debugfs: debug filesystem info
* @sta: station information we share with the driver
+ * @dead: set to true when sta is unlinked
+ * @drv_unblock_wk used for driver PS unblocking
*/
struct sta_info {
/* General information, mostly static */
@@ -229,8 +239,12 @@ struct sta_info {
spinlock_t lock;
spinlock_t flaglock;
+ struct work_struct drv_unblock_wk;
+
u16 listen_interval;
+ bool dead;
+
/*
* for use by the internal lifetime management,
* see __sta_info_unlink
@@ -430,4 +444,7 @@ int sta_info_flush(struct ieee80211_loca
void ieee80211_sta_expire(struct ieee80211_sub_if_data *sdata,
unsigned long exp_time);
+void ieee80211_sta_ps_deliver_wakeup(struct sta_info *sta);
+void ieee80211_sta_ps_deliver_poll_response(struct sta_info *sta);
+
#endif /* STA_INFO_H */
--- wireless-testing.orig/net/mac80211/tx.c 2009-11-06 11:34:24.000000000 +0100
+++ wireless-testing/net/mac80211/tx.c 2009-11-06 11:34:30.000000000 +0100
@@ -374,7 +374,7 @@ ieee80211_tx_h_unicast_ps_buf(struct iee
staflags = get_sta_flags(sta);
- if (unlikely((staflags & WLAN_STA_PS) &&
+ if (unlikely((staflags & (WLAN_STA_PS_STA | WLAN_STA_PS_DRIVER)) &&
!(info->flags & IEEE80211_TX_CTL_PSPOLL_RESPONSE))) {
#ifdef CONFIG_MAC80211_VERBOSE_PS_DEBUG
printk(KERN_DEBUG "STA %pM aid %d: PS buffer (entries "
@@ -397,8 +397,13 @@ ieee80211_tx_h_unicast_ps_buf(struct iee
} else
tx->local->total_ps_buffered++;
- /* Queue frame to be sent after STA sends an PS Poll frame */
- if (skb_queue_empty(&sta->ps_tx_buf))
+ /*
+ * Queue frame to be sent after STA wakes up/polls,
+ * but don't set the TIM bit if the driver is blocking
+ * wakeup or poll response transmissions anyway.
+ */
+ if (skb_queue_empty(&sta->ps_tx_buf) &&
+ !(staflags & WLAN_STA_PS_DRIVER))
sta_info_set_tim_bit(sta);
info->control.jiffies = jiffies;
@@ -408,7 +413,7 @@ ieee80211_tx_h_unicast_ps_buf(struct iee
return TX_QUEUED;
}
#ifdef CONFIG_MAC80211_VERBOSE_PS_DEBUG
- else if (unlikely(test_sta_flags(sta, WLAN_STA_PS))) {
+ else if (unlikely(staflags & WLAN_STA_PS_STA)) {
printk(KERN_DEBUG "%s: STA %pM in PS mode, but pspoll "
"set -> send frame\n", tx->dev->name,
sta->sta.addr);
--- wireless-testing.orig/include/net/mac80211.h 2009-11-06 11:34:25.000000000 +0100
+++ wireless-testing/include/net/mac80211.h 2009-11-06 11:34:30.000000000 +0100
@@ -2151,6 +2151,38 @@ struct ieee80211_sta *ieee80211_find_sta
const u8 *addr);
/**
+ * ieee80211_sta_block_awake - block station from waking up
+ * @hw: the hardware
+ * @pubsta: the station
+ * @block: whether to block or unblock
+ *
+ * Some devices require that all frames that are on the queues
+ * for a specific station that went to sleep are flushed before
+ * a poll response or frames after the station woke up can be
+ * delivered to that it. Note that such frames must be rejected
+ * by the driver as filtered, with the appropriate status flag.
+ *
+ * This function allows implementing this mode in a race-free
+ * manner.
+ *
+ * To do this, a driver must keep track of the number of frames
+ * still enqueued for a specific station. If this number is not
+ * zero when the station goes to sleep, the driver must call
+ * this function to force mac80211 to consider the station to
+ * be asleep regardless of the station's actual state. Once the
+ * number of outstanding frames reaches zero, the driver must
+ * call this function again to unblock the station. That will
+ * cause mac80211 to be able to send ps-poll responses, and if
+ * the station queried in the meantime then frames will also
+ * be sent out as a result of this. Additionally, the driver
+ * will be notified that the station woke up some time after
+ * it is unblocked, regardless of whether the station actually
+ * woke up while blocked or not.
+ */
+void ieee80211_sta_block_awake(struct ieee80211_hw *hw,
+ struct ieee80211_sta *pubsta, bool block);
+
+/**
* ieee80211_beacon_loss - inform hardware does not receive beacons
*
* @vif: &struct ieee80211_vif pointer from &struct ieee80211_if_init_conf.
^ permalink raw reply
* Re: Getting random regulatory domains on boot-up with ath9k
From: Davide Pesavento @ 2009-11-06 11:17 UTC (permalink / raw)
To: Holger Schurig; +Cc: Jeffrey Baker, linux-wireless, Luis R. Rodriguez
In-Reply-To: <m3ws246ky4.wl%holgerschurig@gmail.com>
On Fri, Nov 6, 2009 at 10:50, Holger Schurig
<holgerschurig@googlemail.com> wrote:
>> ath: EEPROM regdomain: 0x37
>> ath: EEPROM indicates we should expect a direct regpair map
>> ath: Country alpha2 being used: AW
>> ath: Regpair used: 0x37
>> cfg80211: Calling CRDA for country: AW
>
> I can confirm this bug on wireless-testing, v2.6.32-rc6-41576-g4408b3b
> with an ath5k card:
>
Confirmed on wireless-testing v2.6.32-rc6-wl-41575-g5e68bfb with an
AR5418 card using ath9k. Also 'iw reg set <country code>' stopped
working. Last known working kernel is v2.6.32-rc5-wl-40584-g9b469da.
[ 12.573257] ath: EEPROM regdomain: 0x37
[ 12.573259] ath: EEPROM indicates we should expect a direct regpair map
[ 12.573262] ath: Country alpha2 being used: AW
[ 12.573264] ath: Regpair used: 0x37
[ 12.579608] cfg80211: Calling CRDA for country: AW
Regards,
Davide
^ permalink raw reply
* Re: Getting random regulatory domains on boot-up with ath9k
From: Holger Schurig @ 2009-11-06 12:05 UTC (permalink / raw)
To: Holger Schurig; +Cc: Jeffrey Baker, linux-wireless, Luis R. Rodriguez
In-Reply-To: <m3ws246ky4.wl%holgerschurig@gmail.com>
Hmm, maybe it's not a bug after all.
The card's eeprom just have a region, 0x37 is ETSI World. Now the
kernel looks for the first country with this region and uses this for
crda.
There have been changes to drivers/net/wireless/ath/regd_common.h
recently, so maybe on one kernel-version "DK" is the first ETSI World,
on the next "AW" is the first and on some other again some different
country.
So it's just misleading, e.g.
using first country with regdm 0x37: DK
would probably a better dmesg output.
If you however can reproduce that with the same kernel you always get
different output after each reboot, then we have a bug here.
^ permalink raw reply
* [PATCH] Wifi led does not work on Acer Aspire One D250 (ath5k driver)
From: Carlo Parata @ 2009-11-06 13:00 UTC (permalink / raw)
To: linux-wireless
With this patch, a Acer Aspire One D250 can turn on the wifi led. The array of
compatible devices in ath5k driver now includes the hardware present in this
computer, as well as the led pin and polarity.
--- ../led.c 2009-11-06 06:16:39.000000000 +0100
+++ ./drivers/net/wireless/ath/ath5k/led.c 2009-11-06 12:37:44.000000000 +0100
@@ -73,6 +73,8 @@
{ ATH_SDEVICE(PCI_VENDOR_ID_HP, 0x0137b), ATH_LED(3, 1) },
/* IBM-specific AR5212 (all others) */
{ PCI_VDEVICE(ATHEROS, PCI_DEVICE_ID_ATHEROS_AR5212_IBM), ATH_LED(0, 0) },
+ /* Acer Aspire One D250 AR5007EG */
+ { PCI_VDEVICE(ATHEROS, 0x001c), ATH_LED(3, 1) },
{ }
};
^ permalink raw reply
* Re: [PATCH] Wifi led does not work on Acer Aspire One D250 (ath5k driver)
From: Bob Copeland @ 2009-11-06 15:16 UTC (permalink / raw)
To: Carlo Parata; +Cc: linux-wireless
In-Reply-To: <loom.20091106T135746-452@post.gmane.org>
On Fri, Nov 6, 2009 at 8:00 AM, Carlo Parata <carlo_parata@hotmail.com> wrote:
> With this patch, a Acer Aspire One D250 can turn on the wifi led. The array of
> compatible devices in ath5k driver now includes the hardware present in this
> computer, as well as the led pin and polarity.
>
> --- ../led.c 2009-11-06 06:16:39.000000000 +0100
> +++ ./drivers/net/wireless/ath/ath5k/led.c 2009-11-06 12:37:44.000000000 +0100
> @@ -73,6 +73,8 @@
> { ATH_SDEVICE(PCI_VENDOR_ID_HP, 0x0137b), ATH_LED(3, 1) },
> /* IBM-specific AR5212 (all others) */
> { PCI_VDEVICE(ATHEROS, PCI_DEVICE_ID_ATHEROS_AR5212_IBM), ATH_LED(0, 0) },
> + /* Acer Aspire One D250 AR5007EG */
> + { PCI_VDEVICE(ATHEROS, 0x001c), ATH_LED(3, 1) },
No, this should be based on the subdevice instead
(there are lots of ath:001c with different LED settings).
Also, please add your email to the appropriate stanza.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [PATCH] Wifi led does not work on Acer Aspire One D250 (ath5k driver)
From: Larry Finger @ 2009-11-06 15:23 UTC (permalink / raw)
To: Bob Copeland; +Cc: Carlo Parata, linux-wireless
In-Reply-To: <b6c5339f0911060716n538268f6w1300e3400e0bd2c8@mail.gmail.com>
On 11/06/2009 09:16 AM, Bob Copeland wrote:
> On Fri, Nov 6, 2009 at 8:00 AM, Carlo Parata <carlo_parata@hotmail.com> wrote:
>> With this patch, a Acer Aspire One D250 can turn on the wifi led. The array of
>> compatible devices in ath5k driver now includes the hardware present in this
>> computer, as well as the led pin and polarity.
>>
>> --- ../led.c 2009-11-06 06:16:39.000000000 +0100
>> +++ ./drivers/net/wireless/ath/ath5k/led.c 2009-11-06 12:37:44.000000000 +0100
>> @@ -73,6 +73,8 @@
>> { ATH_SDEVICE(PCI_VENDOR_ID_HP, 0x0137b), ATH_LED(3, 1) },
>> /* IBM-specific AR5212 (all others) */
>> { PCI_VDEVICE(ATHEROS, PCI_DEVICE_ID_ATHEROS_AR5212_IBM), ATH_LED(0, 0) },
>> + /* Acer Aspire One D250 AR5007EG */
>> + { PCI_VDEVICE(ATHEROS, 0x001c), ATH_LED(3, 1) },
>
> No, this should be based on the subdevice instead
> (there are lots of ath:001c with different LED settings).
>
> Also, please add your email to the appropriate stanza.
It is more than just your E-mail address. Please see
Documents/SubmittingPatches.
^ permalink raw reply
* Re: Getting random regulatory domains on boot-up with ath9k
From: Luis R. Rodriguez @ 2009-11-06 15:53 UTC (permalink / raw)
To: Holger Schurig; +Cc: Jeffrey Baker, linux-wireless
In-Reply-To: <m3hbt7kgdb.wl%holgerschurig@gmail.com>
On Fri, Nov 6, 2009 at 4:05 AM, Holger Schurig
<holgerschurig@googlemail.com> wrote:
> Hmm, maybe it's not a bug after all.
Right.
> The card's eeprom just have a region, 0x37 is ETSI World. Now the
> kernel looks for the first country with this region and uses this for
> crda.
The atheros driver does this, that is right. This is just one way in
which the EEPROM can be programmed on Atheros cards, a way which I
hope will disappear as this obviously can confuse users.
> There have been changes to drivers/net/wireless/ath/regd_common.h
> recently, so maybe on one kernel-version "DK" is the first ETSI World,
> on the next "AW" is the first and on some other again some different
> country.
Right, this is exactly what happens.
So the search is for any alpha2 for 0x37 (ETSI1_WORLD) on the Atheros
regulatory table allCountries[]. There are a few and recently the
first alpha2 was made 'AW' as noted. Reason for searching for the
first one is all of the alpha2s that match ETSI1_WORLD all have the
same regulatory domain so the way to think about these is more of a
region code and that region code maps to a certain number of alpha2s
which all happen to have the same exact regulatory domain definitions.
This obviously can change over time but for Windows driver this
behavior is static as the driver remains static unless a change is
requested by an ODM. For Linux this is different -- we get all the
updates, and IMHO this is good but this also means this one way of
programming the EEPROM should be avoided and eventually dropped. That
will take time but I had already started poking internally for a
change.
In the meantime I've tried to document the regulatory details on the
wiki so interested users / developers can understand what is going on.
So for ETSI1_WORLD we have these mappings, in this order now on
wireless-testing (bleeding edge):
mcgrof@tux ~/wireless-testing (git::my-stuff)$ grep ETSI1_WORLD
drivers/net/wireless/ath/regd_common.h
ETSI1_WORLD = 0x37,
{ETSI1_WORLD, CTL_ETSI, CTL_ETSI},
{CTRY_ARUBA, ETSI1_WORLD, "AW"},
{CTRY_AUSTRIA, ETSI1_WORLD, "AT"},
{CTRY_BELARUS, ETSI1_WORLD, "BY"},
{CTRY_BELGIUM, ETSI1_WORLD, "BE"},
{CTRY_BOSNIA_HERZ, ETSI1_WORLD, "BA"},
{CTRY_CAMBODIA, ETSI1_WORLD, "KH"},
{CTRY_CROATIA, ETSI1_WORLD, "HR"},
{CTRY_CYPRUS, ETSI1_WORLD, "CY"},
{CTRY_DENMARK, ETSI1_WORLD, "DK"},
{CTRY_ESTONIA, ETSI1_WORLD, "EE"},
{CTRY_FINLAND, ETSI1_WORLD, "FI"},
{CTRY_FRANCE, ETSI1_WORLD, "FR"},
{CTRY_GERMANY, ETSI1_WORLD, "DE"},
{CTRY_GREECE, ETSI1_WORLD, "GR"},
{CTRY_GREENLAND, ETSI1_WORLD, "GL"},
{CTRY_HAITI, ETSI1_WORLD, "HT"},
{CTRY_HUNGARY, ETSI1_WORLD, "HU"},
{CTRY_ICELAND, ETSI1_WORLD, "IS"},
{CTRY_IRELAND, ETSI1_WORLD, "IE"},
{CTRY_ITALY, ETSI1_WORLD, "IT"},
{CTRY_LATVIA, ETSI1_WORLD, "LV"},
{CTRY_LIECHTENSTEIN, ETSI1_WORLD, "LI"},
{CTRY_LITHUANIA, ETSI1_WORLD, "LT"},
{CTRY_LUXEMBOURG, ETSI1_WORLD, "LU"},
{CTRY_MALTA, ETSI1_WORLD, "MT"},
{CTRY_NETHERLANDS, ETSI1_WORLD, "NL"},
{CTRY_NETHERLANDS_ANTILLES, ETSI1_WORLD, "AN"},
{CTRY_NORWAY, ETSI1_WORLD, "NO"},
{CTRY_POLAND, ETSI1_WORLD, "PL"},
{CTRY_PORTUGAL, ETSI1_WORLD, "PT"},
{CTRY_SERBIA_MONTENEGRO, ETSI1_WORLD, "CS"},
{CTRY_SLOVAKIA, ETSI1_WORLD, "SK"},
{CTRY_SLOVENIA, ETSI1_WORLD, "SI"},
{CTRY_SPAIN, ETSI1_WORLD, "ES"},
{CTRY_SWEDEN, ETSI1_WORLD, "SE"},
{CTRY_SWITZERLAND, ETSI1_WORLD, "CH"},
{CTRY_UNITED_KINGDOM, ETSI1_WORLD, "GB"},
The assumption of whether or not all of these alpha2s have the same
regulatory definition on db.txt from wireless-regdb may be wrong
already, not sure, but they all should be pretty close. The design of
programming an Atheros card with 0x37 would end up being to use the
same exact regulatory domain for any of these alpha2s as all of these
alpha2s would be mapped internally in the driver to static regulatory
domain definition. In that case the regulatory domain would never
change, the user would not be informed of the alpha2 at all and its
just used. For Linux the alpha2 regulatory database has been moved to
userspace and although countries (alpah2s) can have the same exact
regulatory domain they do not -- they are just split up.
> So it's just misleading, e.g.
>
> using first country with regdm 0x37: DK
>
> would probably a better dmesg output.
Agreed, maybe better:
ath: region code found 0x37, fist country in region: DK
That or print all the alpha2s in the region. But as I also had
suggested before we could also check the currently set alpha2 on
cfg80211 by the user and if it happens to match an alpha2 in the
region ask CRDA for that alpha2's regulatory domain.
Luis
^ permalink raw reply
* Re: [PATCH] Wifi led does not work on Acer Aspire One D250 (ath5k driver)
From: Carlo Parata @ 2009-11-06 15:54 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <loom.20091106T135746-452@post.gmane.org>
Carlo Parata <carlo_parata@...> writes:
>
> With this patch, a Acer Aspire One D250 can turn on the wifi led. The array of
> compatible devices in ath5k driver now includes the hardware present in this
> computer, as well as the led pin and polarity.
>
> --- ../led.c 2009-11-06 06:16:39.000000000 +0100
> +++ ./drivers/net/wireless/ath/ath5k/led.c 2009-11-06 12:37:44.000000000 +0100
> @@ -73,6 +73,8 @@
> { ATH_SDEVICE(PCI_VENDOR_ID_HP, 0x0137b), ATH_LED(3, 1) },
> /* IBM-specific AR5212 (all others) */
> { PCI_VDEVICE(ATHEROS, PCI_DEVICE_ID_ATHEROS_AR5212_IBM), ATH_LED(0, 0) },
> + /* Acer Aspire One D250 AR5007EG */
> + { PCI_VDEVICE(ATHEROS, 0x001c), ATH_LED(3, 1) },
> { }
> };
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@...
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
Excuse me but it is the first post for me in this mailing list.
How can I find out the subdevice of my wireless card?
The device specifications shown by Windows XP are:
PCI\VEN_168C&DEV_001C&SUBSYS_E00D105B&REV_01\4&192AC53F&0&00E0
Thanks
^ permalink raw reply
* [PATCH] SSB: fix 32 bit PCMCIA access.
From: Martin Fuzzey @ 2009-11-06 15:56 UTC (permalink / raw)
To: linux-wireless
The scan function was using 32 bit access which does not
work on 16bit CF cards.
This patch corrects this by doing two 16 bit reads like
ssb_pcmcia_read32 already does (unfortunately we don't
have a struct ssb_device to use that directly).
Signed-off-by: Martin Fuzzey <mfuzzey@gmail.com>
---
drivers/ssb/scan.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/ssb/scan.c b/drivers/ssb/scan.c
index b74212d..6721fa8 100644
--- a/drivers/ssb/scan.c
+++ b/drivers/ssb/scan.c
@@ -162,6 +162,9 @@ static u8 chipid_to_nrcores(u16 chipid)
static u32 scan_read32(struct ssb_bus *bus, u8 current_coreidx,
u16 offset)
{
+ unsigned long flags;
+ u32 lo, hi;
+
switch (bus->bustype) {
case SSB_BUSTYPE_SSB:
offset += current_coreidx * SSB_CORE_SIZE;
@@ -174,7 +177,11 @@ static u32 scan_read32(struct ssb_bus *bus, u8 current_coreidx,
offset -= 0x800;
} else
ssb_pcmcia_switch_segment(bus, 0);
- break;
+ spin_lock_irqsave(&bus->bar_lock, flags);
+ lo = readw(bus->mmio + offset);
+ hi = readw(bus->mmio + offset + 2);
+ spin_unlock_irqrestore(&bus->bar_lock, flags);
+ return lo | (hi << 16);
case SSB_BUSTYPE_SDIO:
offset += current_coreidx * SSB_CORE_SIZE;
return ssb_sdio_scan_read32(bus, offset);
^ permalink raw reply related
* Re: [PATCH] Wifi led does not work on Acer Aspire One D250 (ath5k driver)
From: Holger Schurig @ 2009-11-06 16:01 UTC (permalink / raw)
To: Carlo Parata; +Cc: linux-wireless
In-Reply-To: <loom.20091106T165330-596@post.gmane.org>
lspci -vvnn gives all the gory details :-)
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: [PATCH] Wifi led does not work on Acer Aspire One D250 (ath5k driver)
From: Bob Copeland @ 2009-11-06 16:04 UTC (permalink / raw)
To: Holger Schurig; +Cc: Carlo Parata, linux-wireless
In-Reply-To: <m3k4y3wsla.wl%holgerschurig@gmail.com>
On Fri, Nov 6, 2009 at 11:01 AM, Holger Schurig
<holgerschurig@googlemail.com> wrote:
> lspci -vvnn gives all the gory details :-)
>
Yes, also to save you some trouble it looks like this patch
should already handle your device:
http://marc.info/?l=linux-wireless&m=125739131923457
(I guess from the XP info that you have 0x105b:e00d too)
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* [rt2x00-users] rt61pci bug
From: Luis Correia @ 2009-11-06 16:04 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <880c1630911060803k32b3ee46g7cfdfec2485f311@mail.gmail.com>
Hi Tim,
On Wed, Nov 4, 2009 at 19:27, Matthijs Kooijman <matthijs@stdin.nl> wrote:
>
> > [ 1656.653963] Please file bug report to http://rt2x00.serialmonkey.com
> >
> > Is that message correct? The bug reports link at the wiki seems a bit unclear...
> Also, I just noticed that the "mailing lists" link in the first section, as
> well as the "LISTS" link in the menu bar at the top point to the old
> sourceforge lists page, which is empty.
>
> Perhaps the frontpage should be reviewed a bit?
>
> Gr.
>
> Matthijs
>
We did a ver minor change to the page, the top navbar now has LISTS
pointing to the correct list and PROJECTS is no more.
Hope this pleases most of the viewers.
However we're planning to change the bug report location, now that the
driver is present in most (if not all) major distros.
Luis Correia
rt2x00 project admin
^ permalink raw reply
* Re: [PATCH] Wifi led does not work on Acer Aspire One D250 (ath5k driver)
From: John W. Linville @ 2009-11-06 16:09 UTC (permalink / raw)
To: Carlo Parata; +Cc: linux-wireless, me
In-Reply-To: <loom.20091106T135746-452@post.gmane.org>
On Fri, Nov 06, 2009 at 01:00:02PM +0000, Carlo Parata wrote:
> With this patch, a Acer Aspire One D250 can turn on the wifi led. The array of
> compatible devices in ath5k driver now includes the hardware present in this
> computer, as well as the led pin and polarity.
>
> --- ../led.c 2009-11-06 06:16:39.000000000 +0100
> +++ ./drivers/net/wireless/ath/ath5k/led.c 2009-11-06 12:37:44.000000000 +0100
> @@ -73,6 +73,8 @@
> { ATH_SDEVICE(PCI_VENDOR_ID_HP, 0x0137b), ATH_LED(3, 1) },
> /* IBM-specific AR5212 (all others) */
> { PCI_VDEVICE(ATHEROS, PCI_DEVICE_ID_ATHEROS_AR5212_IBM), ATH_LED(0, 0) },
> + /* Acer Aspire One D250 AR5007EG */
> + { PCI_VDEVICE(ATHEROS, 0x001c), ATH_LED(3, 1) },
> { }
> };
FWIW, a similar patch earlier this week drew the following from Bob Copeand:
"... but can you by chance put a contact address in the comment? I've been
collecting them in case we one day figure out a better way to do this so it's
easy to find the people to retest."
Would you mind complying with his request? Or have I mistakend his applicability?
Thanks,
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
* b43: firmware loading problem and sleeping BUG
From: Martin Fuzzey @ 2009-11-06 16:19 UTC (permalink / raw)
To: linux-wireless
I posted a couple of days ago to the bcm43xx_dev list about problems
getting b43 to run on a
arm (MX21 SoC). That list appears to have died recently (at least
nothing added to the archives
since last month)
That problem is fixed now (and patch posted)
However I now get:
pcmcia_socket pcmcia_socket0: pccard: PCMCIA card inserted into slot 0
pcmcia 0.0: pcmcia: registering new device pcmcia0.0
ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x0D, vendor 0x4243)
ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x09, vendor 0x4243)
ssb: Core 2 found: PCI (cc 0x804, rev 0x0C, vendor 0x4243)
ssb: Core 3 found: PCMCIA (cc 0x80D, rev 0x07, vendor 0x4243)
BUG: sleeping function called from invalid context at mm/vmalloc.c:1367
in_atomic(): 1, irqs_disabled(): 128, pid: 1361, name: modprobe
2 locks held by modprobe/1361:
#0: (buses_mutex){+.+.+.}, at: [<bf03761c>] ssb_bus_register+0x48/0x1a4 [ssb]
#1: (&bus->bar_lock){......}, at: [<bf038e38>]
ssb_pcmcia_read32+0x24/0x74 [ssb]
irq event stamp: 105917
hardirqs last enabled at (105916): [<c027cf34>]
__mutex_unlock_slowpath+0x120/0x150
hardirqs last disabled at (105917): [<c027eee0>] _spin_lock_irqsave+0x20/0x60
softirqs last enabled at (105853): [<c0042f60>] irq_exit+0x50/0x64
softirqs last disabled at (105832): [<c0042f60>] irq_exit+0x50/0x64
------------[ cut here ]------------
WARNING: at kernel/lockdep.c:2465 lockdep_trace_alloc+0xac/0xec()
Modules linked in: b43(+) ssb mac80211 mxc_pcmcia
---[ end trace 7a542bbcadb0bb88 ]---
ssb: Sonics Silicon Backplane found on PCMCIA device pcmcia0.0
b43-phy0: Broadcom 4318 WLAN found (core revision 9)
b43-phy0 debug: Found PHY: Analog 3, Type 2, Revision 7
b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 8
phy0: Selected rate control algorithm 'minstrel'
Broadcom 43xx driver loaded [ Features: M, Firmware-ID: FW13 ]
And then when I do ifconfig wlan0 up:
b43 ssb0:0: firmware: requesting b43/ucode5.fw
b43 ssb0:0: firmware: requesting b43/pcm5.fw
b43 ssb0:0: firmware: requesting b43/b0g0initvals5.fw
b43 ssb0:0: firmware: requesting b43/b0g0bsinitvals5.fw
b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
b43-phy0 ERROR: Initial Values Firmware file-format error.
b43-phy0 ERROR: You must go to
http://wireless.kernel.org/en/users/Drivers/b43#devicefirmware
and download the correct firmware for this driver version. Please
carefully read all instructions on this website.
I am using firmware broadcom-wl-4.150.10.5 extracted with
b43-fwcutter-012 as described
http://wireless.kernel.org/en/users/Drivers/b43#devicefirmware
Any ideas why the versions don't match?
The firmware files are arch independant right? (since I run fwcutter
on x86 and run the kernel on ARM)
Kernel version is 2.6.32-rc5
The PCMCIA controller driver is new (I recently posted it to
linux-pcmcia and linux-arm)
Cheers,
Martin
^ permalink raw reply
* Re: Getting random regulatory domains on boot-up with ath9k
From: Luis R. Rodriguez @ 2009-11-06 16:21 UTC (permalink / raw)
To: Jeffrey Baker; +Cc: linux-wireless
In-Reply-To: <fd145f7d0911060004j55b06482tca088685d0626249@mail.gmail.com>
On Fri, Nov 6, 2009 at 12:04 AM, Jeffrey Baker <jwbaker@gmail.com> wrote:
> I am trying to work with a card made with Atheros 9280, but I find
> that I am getting essentially random regulatory domains. The very
> first time I booted the system, under Linux 2.6.30, I got the country
> code AT.
That just happened to be the first alpha2 in the countries array on
the Atheros driver's country table which mapped 0x37 to an alpha2.
Either way it could have been any of the other alpha2s that map to
0x37 as well.
> Subsequently I got US.
I would need more full logs to analyze this, but it definitely would
not be expected to have come from the ath9k code. The US happened to
be default if you have CONFIG_WIRELESS_OLD_REGULATORY and hence why
this is called OLD, it was the old regulatory implementation. You can
also get US regulatory domain request through an AP country
information element. For atheros wireless cards that are already
programmed to follow a country regulatory domain though (ie: not a
world roaming regulatory domain) the country IE would just enhance
regulatory restrictions further -- it won't enable new channels.
> Then I upgraded to
> compat-wireless-2009-11-06 and now I get AW (Aruba).
Right, AW is now the first country that maps to 0x37, this was changed
on a recent patch.
> dmesg says:
>
> ath: EEPROM regdomain: 0x37
> ath: EEPROM indicates we should expect a direct regpair map
> ath: Country alpha2 being used: AW
> ath: Regpair used: 0x37
> cfg80211: Calling CRDA for country: AW
>
> Now, my understanding is that 0x37 is world roaming.
Actually no, that is not the case. 0x37 maps to ETSI1_WORLD which also
does have the postfix WORLD it does not mean its a world roaming
regulatory domain. The _WORLD postfix just annotates to the developer
that the 2 GHz regulatory SKU is one which world roams, but this is
more of an implementation detail and has nothing to do with real world
roaming regulatory domains. Real Atheros world regulatory domains have
0x60 in them, so this would be 0x61, 0x62, etc. These *are world
roaming* regulatory domain in the sense that static world regulatory
domains have been defined statically in the ath.ko module *and*
typically this also means passive scan is preferred on certain
channels which would otherwise remain disabled in certain countries,
just as beaconing is also disabled (this is called NO-IBSS flag). Now,
cfg80211 then has world roaming enhancements which *lift* the passive
scan and no-ibss (beaconing) flag if a channel has been found though
so you happened to have a world roaming card on 5 GHz you essentially
would be able to enable IBSS or AP mode of operation if a nearby AP
was found through an initial scan.
> The key sentence
> from the docs seems to be this:
>
> "Regulatory pair regulatory domains are mapped to the first
> ISO-3166-alpha2 country."
>
> Does that mean that AW is the first country code in the 0x37
> regulatory pair group?
Now it is, before it was AT.
> The result is this list of channels
>
> 5180 MHz [36] (30.0 dBm) (passive scanning, no IBSS)
> 5200 MHz [40] (30.0 dBm) (passive scanning, no IBSS)
> 5220 MHz [44] (30.0 dBm) (passive scanning, no IBSS)
> 5240 MHz [48] (30.0 dBm) (passive scanning, no IBSS)
> 5260 MHz [52] (30.0 dBm) (passive scanning, no IBSS, radar detection)
> 5280 MHz [56] (30.0 dBm) (passive scanning, no IBSS, radar detection)
> 5300 MHz [60] (30.0 dBm) (passive scanning, no IBSS, radar detection)
> 5320 MHz [64] (30.0 dBm) (passive scanning, no IBSS, radar detection)
> 5500 MHz [100] (disabled)
> 5520 MHz [104] (disabled)
> 5540 MHz [108] (disabled)
> 5560 MHz [112] (disabled)
> 5580 MHz [116] (disabled)
> 5600 MHz [120] (disabled)
> 5620 MHz [124] (disabled)
> 5640 MHz [128] (disabled)
> 5660 MHz [132] (disabled)
> 5680 MHz [136] (disabled)
> 5700 MHz [140] (disabled)
> 5745 MHz [149] (30.0 dBm) (passive scanning, no IBSS)
> 5765 MHz [153] (30.0 dBm) (passive scanning, no IBSS)
> 5785 MHz [157] (30.0 dBm) (passive scanning, no IBSS)
> 5805 MHz [161] (30.0 dBm) (passive scanning, no IBSS)
> 5825 MHz [165] (30.0 dBm) (passive scanning, no IBSS)
>
> ... which in summary prevents me from operating an access point in the
> 5GHz band at all.
Yes, unfortunately when Atheros cards are programmed with a country
code the world roaming enhancement I described above does not apply
which would otherwise have at least enabled AP / IBSS mode of
operation if at least any of your local neighbors did have an AP on
any of the passive-scan/no-ibss channels.
But -- as it so happens "AW" has no entry on db.txt therefore making
0x37 cards stuck with non-world roaming capabilities but since CRDA
does not find any regulatory domain the card essentially *is* stuck
world roaming.
> The perplexing thing is that I was able to use
> channel 36 under kernel.org 2.6.30, so from my perspective that
> software was working better than the current software does,
You can interpret that as however you want, the real fact is just that
AT did have an entry on db.txt which does consist of at least a set of
5 GHz channels which do enable AP mode of operation:
country AT:
(2402 - 2482 @ 40), (N/A, 20)
(5170 - 5250 @ 40), (N/A, 20)
(5250 - 5330 @ 40), (N/A, 20), DFS
(5490 - 5710 @ 40), (N/A, 27), DFS
> and of
> course leads me to believe that I can use software to change this card
> to FCC regs instead of these frustrating "world" regs which prevent me
> from running an AP.
You have a few twisted statements here but let me order them up and
fix the for you:
* If you happen to have an Atheros card with a region code and that
region code maps to an alpha2 for which CRDA does not have an entry
for yet your card will remain world roaming if you did not enable
CONFIG_WIRELESS_OLD_REGULATORY as the default under the new regulatory
framework is to world roam. If you did enable
CONFIG_WIRELESS_OLD_REGULATORY though your default would be the static
US rules followed by a request to CRDA for the US regulatory domain.
* What you have found is a regression introduced by the patch titled
"ath: Updates for regulatory and country codes" and its caused by your
region code not having a mapped regulatory domain on db.txt, as AW has
no entry yet on wireless-regdb.
* The fix for the regression would be to either use an alpha2 which
does have an entry and put that first in the array *or* (my
preference) to check first the alpha2 set on cfg80211 and see if that
maps to a country allowed by your region code and if so get cfg80211
to request that regulatory domain to CRDA.
* On modern 802.11 cards you typically can somehow change the
regulatory domain one way or another:
- Reverse engineering of driver
- Reprogramming of an EEPROM
- Modifying open drivers or open regulatory databases and signing
off on these changes
Most Linux distributions today do ship a crda with RSA key support
which protect usage against a non-authored-and-trusted regulatory.bin.
You can obviosly modify and build your own crda and wireless-regdb but
this would be an act an end user does.
So one way or another user intervention is required to alter current
regulatory solutions. For Linux though the best solution *as an end
user* to enable AP mode is not to alter wireless-regdb but instead to
report your issue. In your case you have a non-trivial regression
which does indeed need to be addressed.
> Needless to say, I am perplexed by this behavior. The exact phy is
> "Atheros AR9280 Rev:2"
Thanks for the report, we'll cook up a fix and have you test it.
Luis
^ permalink raw reply
* Re: [PATCH] Wifi led does not work on Acer Aspire One D250 (ath5k driver)
From: Bob Copeland @ 2009-11-06 16:21 UTC (permalink / raw)
To: John W. Linville; +Cc: Carlo Parata, linux-wireless
In-Reply-To: <20091106160926.GA2782@tuxdriver.com>
On Fri, Nov 6, 2009 at 11:09 AM, John W. Linville
<linville@tuxdriver.com> wrote:
> "... but can you by chance put a contact address in the comment? I've been
> collecting them in case we one day figure out a better way to do this so it's
> easy to find the people to retest."
>
> Would you mind complying with his request? Or have I mistakend his applicability?
It's still applicable in the general case, but I think the new patch
is for the same HW as the earlier one posted (Carlo can confirm)
so we should be good already.
--
Bob Copeland %% www.bobcopeland.com
^ 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