* Re: Porting AR6K to use cfg80211
From: Luis R. Rodriguez @ 2009-09-25 21:17 UTC (permalink / raw)
To: Dave; +Cc: Matthew Ryan, linux-wireless
In-Reply-To: <43e72e890909251416g59a24d8as90f7a4d649c06914@mail.gmail.com>
On Fri, Sep 25, 2009 at 2:16 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Fri, Sep 25, 2009 at 2:06 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>> On Fri, Sep 25, 2009 at 1:57 PM, Dave <kilroyd@googlemail.com> wrote:
>>> Matthew Ryan wrote:
>>>> Michael Buesch <mb@...> writes:
>>>>> On Friday 25 September 2009 19:40:52 Matthew Ryan wrote:
>>>>>> I was curious if I could get a few expert opinions on if its possible to port
>>>>>> this driver to use mac80211, and how difficult/ what pitfalls there may be.
>>>>> The device is fullmac, so it does not require mac80211.
>>>>> I guess however, ar6k can be ported to use cfg80211.
>>>>>
>>>>
>>>> Do you know of any examples in the source tree which are fullmac, but utilize
>>>> cfg80211 that I could use as a base to get started?
>>>
>>> There are a few fullmac drivers in wireless-testing that use cfg80211. I
>>> don't think these are in the recently released 2.6.31, but are queued
>>> for 2.6.32.
>>>
>>> iwmc3200wifi and rndis_wlan are furthest along. orinoco is in the
>>> process of conversion (it uses cfg80211, but relies on the wext
>>> compatibility code for a large portion of functionality).
>>
>> Additionally you can poke at the HTC / HIF stuff I'm doing for ar9271:
>>
>> http://wireless.kernel.org/en/users/Drivers/ath9k_htc
>>
>> Granted I've removed all credit distribution stuff as ar9271 doesn't
>> use it, but it still may be easier to use that then what I had seen on
>> ar6k for HTC.
>
> Let me clarify a little more.
>
> ath9k_htc is a module which will use ath_htc and ath_hif_usb.
> ath9k_htc delcares hardware support for the 802.11n Atheros 9k family
> for devices which use HTC. The ar9271 usb device gets probed by
> ath_hif_usb. ath9k_htc is being designed as the mac80211 driver for
> ar9271 but it may be possible to just share the same ath9k_htc for all
> SoftMAC Atheros 11n HTC devices.
>
> Now, ar6k is FullMAC so an ath9k_htc per se is not needed but I'd
> expect you'd just need to implement a ar6k.c which uses cfg80211 and
> adds support for the ar6k hw famiy. You'd need to implement an
> ath_hif_sdio.c to handle the SDIO transport and this would be the
> module probing the ar6k devices over sdio. Now, sure, I don't expect
> any PCI/USB ar6k devices but still, this is the architectural approach
> I'd like to see.
Oh and I missed my main point: if the above is possible we can then
share an ath_htc.
Luis
^ permalink raw reply
* Re: Porting AR6K to use cfg80211
From: Luis R. Rodriguez @ 2009-09-25 21:16 UTC (permalink / raw)
To: Dave; +Cc: Matthew Ryan, linux-wireless
In-Reply-To: <43e72e890909251406o64417544w2fd836f820eae80e@mail.gmail.com>
On Fri, Sep 25, 2009 at 2:06 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Fri, Sep 25, 2009 at 1:57 PM, Dave <kilroyd@googlemail.com> wrote:
>> Matthew Ryan wrote:
>>> Michael Buesch <mb@...> writes:
>>>> On Friday 25 September 2009 19:40:52 Matthew Ryan wrote:
>>>>> I was curious if I could get a few expert opinions on if its possible to port
>>>>> this driver to use mac80211, and how difficult/ what pitfalls there may be.
>>>> The device is fullmac, so it does not require mac80211.
>>>> I guess however, ar6k can be ported to use cfg80211.
>>>>
>>>
>>> Do you know of any examples in the source tree which are fullmac, but utilize
>>> cfg80211 that I could use as a base to get started?
>>
>> There are a few fullmac drivers in wireless-testing that use cfg80211. I
>> don't think these are in the recently released 2.6.31, but are queued
>> for 2.6.32.
>>
>> iwmc3200wifi and rndis_wlan are furthest along. orinoco is in the
>> process of conversion (it uses cfg80211, but relies on the wext
>> compatibility code for a large portion of functionality).
>
> Additionally you can poke at the HTC / HIF stuff I'm doing for ar9271:
>
> http://wireless.kernel.org/en/users/Drivers/ath9k_htc
>
> Granted I've removed all credit distribution stuff as ar9271 doesn't
> use it, but it still may be easier to use that then what I had seen on
> ar6k for HTC.
Let me clarify a little more.
ath9k_htc is a module which will use ath_htc and ath_hif_usb.
ath9k_htc delcares hardware support for the 802.11n Atheros 9k family
for devices which use HTC. The ar9271 usb device gets probed by
ath_hif_usb. ath9k_htc is being designed as the mac80211 driver for
ar9271 but it may be possible to just share the same ath9k_htc for all
SoftMAC Atheros 11n HTC devices.
Now, ar6k is FullMAC so an ath9k_htc per se is not needed but I'd
expect you'd just need to implement a ar6k.c which uses cfg80211 and
adds support for the ar6k hw famiy. You'd need to implement an
ath_hif_sdio.c to handle the SDIO transport and this would be the
module probing the ar6k devices over sdio. Now, sure, I don't expect
any PCI/USB ar6k devices but still, this is the architectural approach
I'd like to see.
Luis
^ permalink raw reply
* Re: Porting AR6K to use cfg80211
From: Luis R. Rodriguez @ 2009-09-25 21:06 UTC (permalink / raw)
To: Dave; +Cc: Matthew Ryan, linux-wireless
In-Reply-To: <4ABD2ECE.50501@gmail.com>
On Fri, Sep 25, 2009 at 1:57 PM, Dave <kilroyd@googlemail.com> wrote:
> Matthew Ryan wrote:
>> Michael Buesch <mb@...> writes:
>>> On Friday 25 September 2009 19:40:52 Matthew Ryan wrote:
>>>> I was curious if I could get a few expert opinions on if its possible to port
>>>> this driver to use mac80211, and how difficult/ what pitfalls there may be.
>>> The device is fullmac, so it does not require mac80211.
>>> I guess however, ar6k can be ported to use cfg80211.
>>>
>>
>> Do you know of any examples in the source tree which are fullmac, but utilize
>> cfg80211 that I could use as a base to get started?
>
> There are a few fullmac drivers in wireless-testing that use cfg80211. I
> don't think these are in the recently released 2.6.31, but are queued
> for 2.6.32.
>
> iwmc3200wifi and rndis_wlan are furthest along. orinoco is in the
> process of conversion (it uses cfg80211, but relies on the wext
> compatibility code for a large portion of functionality).
Additionally you can poke at the HTC / HIF stuff I'm doing for ar9271:
http://wireless.kernel.org/en/users/Drivers/ath9k_htc
Granted I've removed all credit distribution stuff as ar9271 doesn't
use it, but it still may be easier to use that then what I had seen on
ar6k for HTC.
Luis
^ permalink raw reply
* Re: Porting AR6K to use cfg80211
From: Dave @ 2009-09-25 20:57 UTC (permalink / raw)
To: Matthew Ryan; +Cc: linux-wireless
In-Reply-To: <loom.20090925T222532-791@post.gmane.org>
Matthew Ryan wrote:
> Michael Buesch <mb@...> writes:
>> On Friday 25 September 2009 19:40:52 Matthew Ryan wrote:
>>> I was curious if I could get a few expert opinions on if its possible to port
>>> this driver to use mac80211, and how difficult/ what pitfalls there may be.
>> The device is fullmac, so it does not require mac80211.
>> I guess however, ar6k can be ported to use cfg80211.
>>
>
> Do you know of any examples in the source tree which are fullmac, but utilize
> cfg80211 that I could use as a base to get started?
There are a few fullmac drivers in wireless-testing that use cfg80211. I
don't think these are in the recently released 2.6.31, but are queued
for 2.6.32.
iwmc3200wifi and rndis_wlan are furthest along. orinoco is in the
process of conversion (it uses cfg80211, but relies on the wext
compatibility code for a large portion of functionality).
Dave.
^ permalink raw reply
* Re: Massive packet loss with ath9k, AR9280, hostapd in 802.11n mode
From: Bob Copeland @ 2009-09-25 20:52 UTC (permalink / raw)
To: Rene Mayrhofer; +Cc: linux-wireless
In-Reply-To: <200909252054.19762.rene.mayrhofer@gibraltar.at>
On Fri, Sep 25, 2009 at 2:54 PM, Rene Mayrhofer
<rene.mayrhofer@gibraltar.at> wrote:
I'll take a stab at this one, someone else can try the other ath9k-related
questions.
> 4. How do I tell CRDA to load frequency definitions for my location (AT)
> instead of the default (US)? I might be blind, stupid, or both, but using the
> slightly conflicting documentation available on various Wikis, I was unable to
> change this. I have read that some chipsets are hard-wired for one location
> and can't be changed, but couldn't find out if mine is (it was bought in
> Europe, so shouldn't be locked to US in any case). An RTFM (with an up-to-date
> pointer, preferrably for Debian/Ubuntu) in this matter would be highly
> appreciated.
"iw reg set XX", but read this first:
http://wireless.kernel.org/en/users/Drivers/ath
http://wireless.kernel.org/en/developers/Regulatory
In short, it depends on what's in your EEPROM.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: Porting AR6K to use cfg80211
From: Matthew Ryan @ 2009-09-25 20:25 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <200909252005.23746.mb@bu3sch.de>
Michael Buesch <mb@...> writes:
>
> On Friday 25 September 2009 19:40:52 Matthew Ryan wrote:
> > I was curious if I could get a few expert opinions on if its possible to port
> > this driver to use mac80211, and how difficult/ what pitfalls there may be.
>
> The device is fullmac, so it does not require mac80211.
> I guess however, ar6k can be ported to use cfg80211.
>
Do you know of any examples in the source tree which are fullmac, but utilize
cfg80211 that I could use as a base to get started?
Thanks,
Matt
^ permalink raw reply
* Re: ar9170 makes machine hang when shut down
From: Joerg Albert @ 2009-09-25 20:16 UTC (permalink / raw)
To: Malte Gell; +Cc: linux-wireless
In-Reply-To: <200909251132.18546.malte.gell@gmx.de>
On 09/25/2009 11:32 AM, Malte Gell wrote:
> My system loads ar9170:
>
> lsmod | grep ar91*
>
> ar9170 32632 0
> mac80211 237208 1 ar9170
> led_class 4028 1 ar9170
> usbcore 183280 15
> usbserial,ar9170,usbhid,uvcvideo,snd_usb_audio,snd_usb_lib,usblp,ehci_hcd,uhci_hcd,ohci_hcd,usb_storage
You are right. I had a look into the source rpm for the packets your url pointed to. The ar9170 driver inside
compat-wireless dates back to end of February 2009, at that time the driver was called ar9170, it got the "usb" prefix later.
You might try arusb_lnx (the vendor driver) from the other package (no idea how OpenSuSE handles two drivers
for the same hardware), but the best way to get support from this list would be to compile a decent
compat-wireless by your own and report bugs etc. to the list. A lot of stuff changed since February.
Regards,
Jörg.
^ permalink raw reply
* Re: Problems with WPA in mainline 2.6.31-gitX
From: Larry Finger @ 2009-09-25 19:38 UTC (permalink / raw)
To: Christian Lamparter; +Cc: Johannes Berg, John Linville, wireless
In-Reply-To: <200909252042.37881.chunkeey@googlemail.com>
Christian Lamparter wrote:
>
> it made it into 2.6.31-git16:
> "cfg80211: don't overwrite privacy setting"
> 94f85853324e02c3a32bc3101f090dc9a3f512b4
>
> but, "[PATCH] cfg80211: don't set privacy w/o key"
> is still missing.
Thanks, Christian. It turns out I do not need "don't set privacy".
With the latest pull, my system works fine.
Larry
^ permalink raw reply
* Re: [PATCH 2/2] at76c50x-usb: set firmware and hardware version in wiphy
From: Luis R. Rodriguez @ 2009-09-25 19:27 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <da94abde0909251211x347bbd30xdfe2bd05bc1e07e5@mail.gmail.com>
On Fri, Sep 25, 2009 at 12:11 PM, Kalle Valo <kalle.valo@iki.fi> wrote:
> On Thu, Sep 24, 2009 at 1:11 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>> On Thu, Sep 24, 2009 at 12:10 PM, Kalle Valo <kalle.valo@iki.fi> wrote:
>>
>>> BTW, is there an easy way to get the module name for the interface?
>>> That's also helpful information for the user.
>>
>> If you can map the interface to PCI ID then I think its possible,
>> lspci -k seems to do it.
>
> Not all drivers use PCI, we have USB, SDIO, SPI and so on.
Sure, it was just an example of a transport where this does exist, I
am hoping this doesn't use PCI specific stuff and based on a simple
strace of "strace -o foo lspci -k -s 03:00.0" I see it actually ends
up reading a /lib/modules/ file and am hoping this is what it uses to
do the mapping. But you still first need the bus ID for the netdevice,
not sure how to best to do that. I do see the sysfs ieee80211 class
maps the phy%d to the bus:
mcgrof@tux ~ $ ls -ld /sys/class/ieee80211/phy0/device
lrwxrwxrwx 1 root root 0 2009-09-25 12:25
/sys/class/ieee80211/phy0/device -> ../../../0000:03:00.0
If you can extract the bus from here and then the device:vendor id I
think you can read the /lib/modules/ map file for the driver.
Check these files out:
ls /lib/modules/2.6.31-wl/modules.*map
Luis
^ permalink raw reply
* Re: [PATCH 2/2] at76c50x-usb: set firmware and hardware version in wiphy
From: Kalle Valo @ 2009-09-25 19:11 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, Felix Bitterli
In-Reply-To: <43e72e890909241311j552ee33ata80ba24c386a316b@mail.gmail.com>
On Thu, Sep 24, 2009 at 1:11 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Thu, Sep 24, 2009 at 12:10 PM, Kalle Valo <kalle.valo@iki.fi> wrote:
>
>> BTW, is there an easy way to get the module name for the interface?
>> That's also helpful information for the user.
>
> If you can map the interface to PCI ID then I think its possible,
> lspci -k seems to do it.
Not all drivers use PCI, we have USB, SDIO, SPI and so on.
> It would be a nice addition to iw output as well IMHO.
I agree. I'm not going to work on adding the driver name right now,
but maybe in the future.
Kalle
^ permalink raw reply
* Re: [PATCH 2/2] at76c50x-usb: set firmware and hardware version in wiphy
From: Kalle Valo @ 2009-09-25 19:06 UTC (permalink / raw)
To: Joerg Albert; +Cc: linux-wireless
In-Reply-To: <4ABBE0E6.4090408@gmx.de>
On Thu, Sep 24, 2009 at 2:13 PM, Joerg Albert <jal2@gmx.de> wrote:
> On 09/24/2009 08:02 PM, Kalle Valo wrote:
>
>> + len = sizeof(wiphy->fw_version);
>> + snprintf(wiphy->fw_version, len, "%d.%d.%d-%d",
>> + priv->fw_version.major, priv->fw_version.minor,
>> + priv->fw_version.patch, priv->fw_version.build);
>> +
>> + len = sizeof(wiphy->hw_version);
>> + snprintf(wiphy->hw_version, len, "%d", priv->board_type);
>> +
>> + /* null terminate the strings in case they were truncated */
>> + wiphy->fw_version[len - 1] = '\0';
>> + wiphy->hw_version[len - 1] = '\0';
>
> This only works as long as sizeof(wiphy->fw_version) == sizeof(wiphy->hw_version) - which is currently the case.
> For sizeof(wiphy->fw_version) < sizeof(wiphy_hw_version) it overwrites memory behind wiphy->fw_version.
Good point, thanks for catching that.
> IMHO this is more robust against changes in the lengths of the char arrays:
>
> + wiphy->fw_version[sizeof(wiphy->fw_version) - 1] = '\0';
> + wiphy->hw_version[sizeof(wiphy->hw_version) - 1] = '\0';
Actually Christian pointed out that snprintf() always null terminates
the string and all this unnecessary. So I'll just remove this in v2.
Kalle
^ permalink raw reply
* Massive packet loss with ath9k, AR9280, hostapd in 802.11n mode
From: Rene Mayrhofer @ 2009-09-25 18:54 UTC (permalink / raw)
To: linux-wireless
Hi everybody,
[Please CC me in replies, I am currently not subscribed to this list.]
For quite a few weeks, I have now been trying to get an AR9280 mini-PCI card
to run as an access point, both in 802.11g and 802.11n mode.
In 802.11g mode, it seems to work for some time with multiple clients, but
then generally drops most packets (estimated >90%) after a period of a few
hours of usage. Restarting the device makes it work again.
In 802.11n mode, one client (Asus eeePC 1000 with Atheros 802.11agn chipset)
initially gets a fairly stable connection (with massive packet loss after some
period of usage), while another client (Dell Latitude XT with Broadcom
802.11ag chipset) only manages to connect with an absymal transfer rate (<2
MBit/s).
This behaviour seems to be mostly independent from WPA and encryption settings
(with the unencrypted connection being sometimes slower than the WPA2/AES
secured one), and does not change much with driver versions. My default driver
is the one included in the upstream 2.6.30.5/.7 kernel, but I have also tried
compat-wireless-2.6 in multiple versions, including 2009-09-25.
The hardware is detected as:
[ 25.714849] cfg80211: Calling CRDA for country: US
[ 27.233246] geode-aes: GEODE AES engine enabled.
[ 27.510611] AMD Geode RNG detected
[ 29.955007] phy0: Selected rate control algorithm 'ath9k_rate_control'
[ 29.957464] cfg80211: Calling CRDA for country: US
[ 29.965266] Registered led device: ath9k-phy0::radio
[ 29.965407] Registered led device: ath9k-phy0::assoc
[ 29.965540] Registered led device: ath9k-phy0::tx
[ 29.965693] Registered led device: ath9k-phy0::rx
[ 29.965744] phy0: Atheros AR9280 MAC/BB Rev:2 AR5133 RF Rev:d0:
mem=0xd0b60000, irq=9
and sits in a mini-PCI slow on an Alix2d13 boards.
hostapd is version v0.6.9 from Debian testing and configured with these
relevant options:
interface=wlan0
country_code=AT
hw_mode=g
ieee80211n=1
ht_capab=[HT40-][SHORT-GI-40]
channel=6
wpa=3
wpa_passphrase=<long string>
wpa_key_mgmt=WPA-PSK
wpa_pairwise=CCMP
rsn_pairwise=CCMP
driver=nl80211
wme_enabled=1
wme_ac_bk_cwmin=4
wme_ac_bk_cwmax=10
wme_ac_bk_aifs=7
wme_ac_bk_txop_limit=0
wme_ac_bk_acm=0
wme_ac_be_aifs=3
wme_ac_be_cwmin=4
wme_ac_be_cwmax=10
wme_ac_be_txop_limit=0
wme_ac_be_acm=0
wme_ac_vi_aifs=2
wme_ac_vi_cwmin=3
wme_ac_vi_cwmax=4
wme_ac_vi_txop_limit=94
wme_ac_vi_acm=0
wme_ac_vo_aifs=2
wme_ac_vo_cwmin=2
wme_ac_vo_cwmax=3
wme_ac_vo_txop_limit=47
wme_ac_vo_acm=0
The WME settings were taken from the OpenWRT forum and indeed improved
stability and throughput, although I can not currently quantify the
improvement.
Unfortunately, I seem to have more questions than answers:
1. Could this be an instance of the issue with massive packet loss that has
been documented previously with ath9k? Is this a known problem with AR9280?
Are there any patches floating around that are not yet in compat-wireless and
that I could try?
2. Is there anything to be done about the Broadcom client, and why is it much
more unstable than the Atheros one?
3. Why does the ath9k driver in AP mode fail to work after a few hours and
needs a restart?
4. How do I tell CRDA to load frequency definitions for my location (AT)
instead of the default (US)? I might be blind, stupid, or both, but using the
slightly conflicting documentation available on various Wikis, I was unable to
change this. I have read that some chipsets are hard-wired for one location
and can't be changed, but couldn't find out if mine is (it was bought in
Europe, so shouldn't be locked to US in any case). An RTFM (with an up-to-date
pointer, preferrably for Debian/Ubuntu) in this matter would be highly
appreciated.
5. After having set the correct location, is hw_mode=a and channel=40 actually
supposed to work? I have not, so far, managed to get this device into 802.11an
mode (which might be down to locked frequencies).
Any hints, pointers, or - even better - patches are very welcome ;-)
best regards,
Rene
^ permalink raw reply
* Re: Problems with WPA in mainline 2.6.31-gitX
From: Christian Lamparter @ 2009-09-25 18:42 UTC (permalink / raw)
To: Larry Finger; +Cc: Johannes Berg, John Linville, wireless
In-Reply-To: <4ABD0B0D.5020002@lwfinger.net>
On Friday 25 September 2009 20:25:17 Larry Finger wrote:
> Johannes and John,
>
> I found that commit bbac31f4 "cfg80211: fix SME connect" breaks WPA2
> connections. I found the problem using bisection. I verified the
> bisection by reverting the patch above. I also found that commit
> 55a00b833 "cfg80211: don't overwrite privacy setting" from
> wireless-testing fixed the issue.
>
> Is the latter patch on its way upstream? If so, I will not bother with
> posting a regression on LKML or a bugzilla report. If not, I will
> initiate the formalities to ensure that the second patch is included
> in mainline.
>
it made it into 2.6.31-git16:
"cfg80211: don't overwrite privacy setting"
94f85853324e02c3a32bc3101f090dc9a3f512b4
but, "[PATCH] cfg80211: don't set privacy w/o key"
is still missing.
Regards,
Chr
^ permalink raw reply
* Problems with WPA in mainline 2.6.31-gitX
From: Larry Finger @ 2009-09-25 18:25 UTC (permalink / raw)
To: Johannes Berg, John Linville; +Cc: wireless
Johannes and John,
I found that commit bbac31f4 "cfg80211: fix SME connect" breaks WPA2
connections. I found the problem using bisection. I verified the
bisection by reverting the patch above. I also found that commit
55a00b833 "cfg80211: don't overwrite privacy setting" from
wireless-testing fixed the issue.
Is the latter patch on its way upstream? If so, I will not bother with
posting a regression on LKML or a bugzilla report. If not, I will
initiate the formalities to ensure that the second patch is included
in mainline.
Larry
^ permalink raw reply
* Re: Porting AR6K to use cfg80211
From: Michael Buesch @ 2009-09-25 18:05 UTC (permalink / raw)
To: Matthew Ryan; +Cc: linux-wireless
In-Reply-To: <loom.20090925T193922-290@post.gmane.org>
On Friday 25 September 2009 19:40:52 Matthew Ryan wrote:
> I was curious if I could get a few expert opinions on if its possible to port
> this driver to use mac80211, and how difficult/ what pitfalls there may be.
The device is fullmac, so it does not require mac80211.
I guess however, ar6k can be ported to use cfg80211.
--
Greetings, Michael.
^ permalink raw reply
* Porting AR6K to use cfg80211
From: Matthew Ryan @ 2009-09-25 17:40 UTC (permalink / raw)
To: linux-wireless
Hi All,
I am using the Neo Freerunner(http://wiki.openmoko.org/wiki/Neo_FreeRunner)
on a project which I am trying to setup to use a wireless mesh network using
open80211s
I was able to build a custom kernel to enable the 80211_MESH capability, but
finally realised the driver that ships with the Freerunner isn't compatible
with the new stack.
The chipset is:
Accton (WLAN 802.11b/g SiP-M WM3236AQ(Flash Ver:2.0 Atheros AR6001GZ) which
uses the AR6K driver, which from what I have read doesn't use mac80211.
Unfortunately I know very little about wireless drivers.
I was curious if I could get a few expert opinions on if its possible to port
this driver to use mac80211, and how difficult/ what pitfalls there may be.
While I don't know much about wireless drivers, I do have extensive
experience porting other drivers and don't usually shy away from a challenge ;)
So, if there's any positive feedback I would give it a shot.
Thanks for your time and comments.
Matt Ryan
^ permalink raw reply
* Re: [PATCH 0/2] cfg80211: firmware and hardware version
From: Luis R. Rodriguez @ 2009-09-25 16:53 UTC (permalink / raw)
To: Kalle Valo; +Cc: John W. Linville, linux-wireless
In-Reply-To: <da94abde0909250947k5084db85vccafe0d3e74e2ecf@mail.gmail.com>
On Fri, Sep 25, 2009 at 9:47 AM, Kalle Valo <kalle.valo@iki.fi> wrote:
> On Thu, Sep 24, 2009 at 9:42 PM, John W. Linville
> <linville@tuxdriver.com> wrote:
>> On Thu, Sep 24, 2009 at 01:20:35PM -0700, Luis R. Rodriguez wrote:
>>> On Thu, Sep 24, 2009 at 11:02 AM, Kalle Valo <kalle.valo@iki.fi> wrote:
>>> > Here's my suggestion how to provide firmware and hardware version to
>>> > user space. First I was thinking adding a new nl80211 command and
>>> > it looked so ugly that I decided include the versions in struct wiphy
>>> > instead.
>>> >
>>> > Please comment.
>>>
>>> What was the conclusion on ethtool stuff again? I forgot.
>>
>> IIRC, I suggested that the cfg80211 driver API (or just the wiphy
>> data structure) could be extended for appropriate bits like this,
>> then cfg80211 could catch ethtool operations in a way similar to how
>> it catches wireless extensions now.
>
> Oh, then I misunderstood our discussion at the summit, my
> understanding was that we will use nl80211 anyway. Sorry about that.
>
> But we want to export two strings to user space (at least for now), is
> it really worth the effort to add ethtool support for such a minor
> feature? Also I have understood that ethtool is implemented only for
> ethernet drivers, I don't feel comfortable that we use ethernet driver
> interfaces with 802.11 device drivers. They are so much different that
> there isn't that much common functionality. That's why I prefer
> nl80211 over ethtool.
>
> What do people think?
So for Wake-on-Wireless I ran into the same, ethtool just did not
offer the same wake up events needed for wireless. I could have
technically used ethtool and expanded it to support wireless but it
just seemed dirty.
I agree that using ethtool seems overkill compared to the patches you posted.
Luis
^ permalink raw reply
* Re: ar9170 makes machine hang when shut down
From: Luis R. Rodriguez @ 2009-09-25 16:51 UTC (permalink / raw)
To: Malte Gell; +Cc: linux-wireless
In-Reply-To: <200909251132.18546.malte.gell@gmx.de>
On Fri, Sep 25, 2009 at 2:32 AM, Malte Gell <malte.gell@gmx.de> wrote:
>
> Joerg Albert <jal2@gmx.de> wrote
>
>> > Does it make sense to use "rmmod --force ar9170" to force removing that
>> > module before shutting down?
>>
>> Why are you sure that the hang is caused by the ar9170 driver?
>
> You are right.... I thought this way, because my machine never hung and after
> installing the USB stick it hang... But, I noticed when i disable ISDN
> subsystem, it did not hang, so maybe it is the ISDN subsystem, I will try
> further.
>
>> The vendor driver is called arusb_lnx, the new one ar9170usb
>
> Vendor driver? Does this mean, Atheros made a driver on its own? Are there
> several drivers for the same chip now?
Atheros wrote a vendor driver called otus for ar9170 devices, this was
prior to the change of focus on working upstream. Atheros then
released code and gave specs, etc to a community developer who wrote a
proper mac80211 driver for ar9170. The main focus for development
today is ar9170. I believe ar9170 does not yet have AMPDU aggregation
enabled by default so otus is still available including the stock
kernel under drivers/staging area until ar9170 matches all features
provided by otus, Read each drivers's wiki page, the section regarding
ar9170 and 11n support is very outdated, I know Chris has worked hard
on this area.
http://wireless.kernel.org/en/users/Drivers/otus
http://wireless.kernel.org/en/users/Drivers/ar9170
I have a feeling not enough people know about the wireless wiki...
Luis
^ permalink raw reply
* Re: [PATCH 0/2] cfg80211: firmware and hardware version
From: Kalle Valo @ 2009-09-25 16:47 UTC (permalink / raw)
To: John W. Linville; +Cc: Luis R. Rodriguez, linux-wireless
In-Reply-To: <20090925044258.GA2722@tuxdriver.com>
On Thu, Sep 24, 2009 at 9:42 PM, John W. Linville
<linville@tuxdriver.com> wrote:
> On Thu, Sep 24, 2009 at 01:20:35PM -0700, Luis R. Rodriguez wrote:
>> On Thu, Sep 24, 2009 at 11:02 AM, Kalle Valo <kalle.valo@iki.fi> wrote:
>> > Here's my suggestion how to provide firmware and hardware version to
>> > user space. First I was thinking adding a new nl80211 command and
>> > it looked so ugly that I decided include the versions in struct wiphy
>> > instead.
>> >
>> > Please comment.
>>
>> What was the conclusion on ethtool stuff again? I forgot.
>
> IIRC, I suggested that the cfg80211 driver API (or just the wiphy
> data structure) could be extended for appropriate bits like this,
> then cfg80211 could catch ethtool operations in a way similar to how
> it catches wireless extensions now.
Oh, then I misunderstood our discussion at the summit, my
understanding was that we will use nl80211 anyway. Sorry about that.
But we want to export two strings to user space (at least for now), is
it really worth the effort to add ethtool support for such a minor
feature? Also I have understood that ethtool is implemented only for
ethernet drivers, I don't feel comfortable that we use ethernet driver
interfaces with 802.11 device drivers. They are so much different that
there isn't that much common functionality. That's why I prefer
nl80211 over ethtool.
What do people think?
Kalle
^ permalink raw reply
* Re: [PATCH] ACPI: New driver for Lenovo SL laptops
From: Alan Jenkins @ 2009-09-25 16:20 UTC (permalink / raw)
To: Ike Panhc
Cc: linux-acpi, linux-kernel, Alexandre Rostovtsev,
linux-wireless@vger.kernel.org
In-Reply-To: <1253805163-12493-1-git-send-email-ike.pan@canonical.com>
On 9/24/09, Ike Panhc <ike.pan@canonical.com> wrote:
> lenovo-sl-laptop is a new driver that provides support for hotkeys,
> bluetooth,
> LenovoCare LEDs and fan speed on the Lenovo ThinkPad SL series laptops. The
> original author is Alexandre Rostovtsev. [1] In February 2009 Alexandre has
> posted the driver on the linux-acpi mailing list and and there was some
> feedback suggesting further modifications. [2] I would like to see Linux
> working properly on these laptops. I was encouraged to push this driver
> again
> with the modifications that where suggested in the responses to the initial
> post in order to allow me and others interested in that driver to improve it
> and hopefully get it included upstream.
>
> [1] homepage : http://github.com/tetromino/lenovo-sl-laptop/tree/master
> [2] http://patchwork.kernel.org/patch/7427/
>
> Following the suggestions when last time the origin author has posted on the
> linux-acpi mailing list. The major modification of this driver is listed
> below.
> - Remove backlight control
> - Remove procfs EC debug
> - Remove fan control function
> - Using generic debugging infrastructure
> - Support for lastest rfkill infrastructure (by Alexandre)
> - Register query function into EC for detecting hotkey event
>
> Patch against current checkout of linux-acpi 2.6.31 is below.
I have some comments on the rfkill code.
> +/*************************************************************************
> + Bluetooth, WWAN, UWB
> + *************************************************************************/
> +
> +enum {
> + /* ACPI GBDC/SBDC, GWAN/SWAN, GUWB/SUWB bits */
> + LENSL_RADIO_HWPRESENT = 0x01, /* hardware is available */
> + LENSL_RADIO_RADIOSSW = 0x02, /* radio is enabled */
> + LENSL_RADIO_RESUMECTRL = 0x04, /* state at resume: off/last state */
> +};
> +
> +typedef enum {
> + LENSL_BLUETOOTH = 0,
> + LENSL_WWAN,
> + LENSL_UWB,
> +} lensl_radio_type;
> +
> +/* pretend_blocked indicates whether we pretend that the device is
> + hardware-blocked (used primarily to prevent the device from coming
> + online when the module is loaded) */
Where do I find pretend_blocked?
> +struct lensl_radio {
> + lensl_radio_type type;
> + enum rfkill_type rfktype;
> + int present;
> + char *name;
> + char *rfkname;
> + struct rfkill *rfk;
> + int (*get_acpi)(int *);
> + int (*set_acpi)(int);
> + int *auto_enable;
> +};
> +
> +static inline int get_wlsw(int *value)
> +{
> + return lensl_acpi_int_func(hkey_handle, "WLSW", value, 0);
> +}
> +
> +static inline int get_gbdc(int *value)
> +{
> + return lensl_acpi_int_func(hkey_handle, "GBDC", value, 0);
> +}
> +
> +static inline int get_gwan(int *value)
> +{
> + return lensl_acpi_int_func(hkey_handle, "GWAN", value, 0);
> +}
> +
> +static inline int get_guwb(int *value)
> +{
> + return lensl_acpi_int_func(hkey_handle, "GUWB", value, 0);
> +}
> +
> +static inline int set_sbdc(int value)
> +{
> + return lensl_acpi_int_func(hkey_handle, "SBDC", NULL, 1, value);
> +}
> +
> +static inline int set_swan(int value)
> +{
> + return lensl_acpi_int_func(hkey_handle, "SWAN", NULL, 1, value);
> +}
> +
> +static inline int set_suwb(int value)
> +{
> + return lensl_acpi_int_func(hkey_handle, "SUWB", NULL, 1, value);
> +}
> +
> +static int lensl_radio_get(struct lensl_radio *radio, int *hw_blocked,
> + int *value)
> +{
> + int wlsw;
> +
> + *hw_blocked = 0;
> + if (!radio)
> + return -EINVAL;
> + if (!radio->present)
> + return -ENODEV;
How does this ever happen? Is this "present" bit really needed?
> + if (!get_wlsw(&wlsw) && !wlsw)
> + *hw_blocked = 1;
> + if (radio->get_acpi(value))
> + return -EIO;
> + return 0;
> +}
> +
> +static int lensl_radio_set_on(struct lensl_radio *radio, int *hw_blocked,
> + bool on)
> +{
> + int value, ret;
> + ret = lensl_radio_get(radio, hw_blocked, &value);
> + if (ret < 0)
> + return ret;
> + /* WLSW overrides radio in firmware/hardware, but there is
> + no reason to risk weird behaviour. */
> + if (*hw_blocked)
> + return ret;
> + if (on)
> + value |= LENSL_RADIO_RADIOSSW;
> + else
> + value &= ~LENSL_RADIO_RADIOSSW;
> + if (radio->set_acpi(value))
> + return -EIO;
> + return 0;
> +}
> +
> +/* Bluetooth/WWAN/UWB rfkill interface */
> +
> +static void lensl_radio_rfkill_query(struct rfkill *rfk, void *data)
> +{
> + int ret, value = 0;
> + ret = get_wlsw(&value);
> + if (ret)
> + return;
> + rfkill_set_hw_state(rfk, !value);
> +}
> +
> +static int lensl_radio_rfkill_set_block(void *data, bool blocked)
> +{
> + int ret, hw_blocked = 0;
> + ret = lensl_radio_set_on((struct lensl_radio *)data,
> + &hw_blocked, !blocked);
> + /* rfkill spec: just return 0 on hard block */
> + return ret;
> +}
> +
> +static struct rfkill_ops rfkops = {
> + NULL,
> + lensl_radio_rfkill_query,
> + lensl_radio_rfkill_set_block,
> +};
Unlike thinkpad_acpi or eeepc-laptop, I don't see any support for rfkill notifications. Can you get a notification when the hardware block changes? (I assume it's associated with a switch the user can change). If there's an ACPI notification you should be able to reverse engineer it in the time honoured way :-).
If there's no obvious notification, you should probably use polling, i.e. set .poll() as well as .query().
The third alternative is that you're like dell-laptop, you're planning to get events via the keyboard controller, and you're waiting until Matthew Garret gets the necessary hooks into the linux input stack. If that's the case you should just add a TODO comment so we know what's going on.
> +static int lensl_radio_new_rfkill(struct lensl_radio *radio,
> + struct rfkill **rfk, bool sw_blocked,
> + bool hw_blocked)
> +{
> + int res;
> +
> + *rfk = rfkill_alloc(radio->rfkname, &lensl_pdev->dev, radio->rfktype,
> + &rfkops, radio);
> + if (!*rfk) {
> + pr_err("Failed to allocate memory for rfkill class\n");
> + return -ENOMEM;
> + }
> +
> + rfkill_set_hw_state(*rfk, hw_blocked);
> + rfkill_set_sw_state(*rfk, sw_blocked);
You could do this in one call
rfkill_set_states(*rfk, sw_blocked, hw_blocked);
> +
> + res = rfkill_register(*rfk);
> + if (res < 0) {
> + pr_err("Failed to register %s rfkill switch: %d\n",
> + radio->rfkname, res);
> + rfkill_destroy(*rfk);
> + *rfk = NULL;
> + return res;
> + }
> +
> + return 0;
> +}
> +
> +/* Bluetooth/WWAN/UWB init and exit */
> +
> +static struct lensl_radio lensl_radios[3] = {
> + {
> + LENSL_BLUETOOTH,
> + RFKILL_TYPE_BLUETOOTH,
> + 0,
> + "bluetooth",
Ugh, I lose track of fields. How about using named initializers, e.g.
.name = "bluetooth",
And this first "name" field doesn't seem to be used for anything useful. Can we get rid of it please?
> + "lensl_bluetooth_sw",
> + NULL,
> + get_gbdc,
> + set_sbdc,
The getter and setter callbacks seem a bit over-engineered. Can't we just use something like
.acpi_method = "SBDC",
> + &bluetooth_auto_enable,
> + },
> + {
> + LENSL_WWAN,
> + RFKILL_TYPE_WWAN,
> + 0,
> + "WWAN",
> + "lensl_wwan_sw",
> + NULL,
> + get_gwan,
> + set_swan,
> + &wwan_auto_enable,
> + },
> + {
> + LENSL_UWB,
> + RFKILL_TYPE_UWB,
> + 0,
> + "UWB",
> + "lensl_uwb_sw",
> + NULL,
> + get_guwb,
> + set_suwb,
> + &uwb_auto_enable,
> + },
> +};
> +
> +static void radio_exit(lensl_radio_type type)
> +{
> + if (lensl_radios[type].rfk)
> + rfkill_unregister(lensl_radios[type].rfk);
> +}
> +
> +static int radio_init(lensl_radio_type type)
> +{
> + int value, res, hw_blocked = 0, sw_blocked;
> +
> + if (!hkey_handle)
> + return -ENODEV;
> + lensl_radios[type].present = 1; /* need for lensl_radio_get */
> + res = lensl_radio_get(&lensl_radios[type], &hw_blocked, &value);
> + lensl_radios[type].present = 0;
> + if (res && !hw_blocked)
> + return -EIO;
> + if (!(value & LENSL_RADIO_HWPRESENT))
> + return -ENODEV;
> + lensl_radios[type].present = 1;
> +
> + if (*lensl_radios[type].auto_enable) {
> + sw_blocked = 0;
> + value |= LENSL_RADIO_RADIOSSW;
> + lensl_radios[type].set_acpi(value);
> + } else {
> + sw_blocked = 1;
> + value &= ~LENSL_RADIO_RADIOSSW;
> + lensl_radios[type].set_acpi(value);
> + }
This is very suspicious. The rfkill core supports two possibilities here:
1) Platform preserves soft-blocked state even when power is removed. Driver calls rfkill_init_sw_state(rfk, sw_blocked) before registration. Rfkill core will respect this value (userspace may have other ideas though :-).
It sounds like your hardware could support this first case, but here's the other one for comparison -
2) Platform does not preserve soft-blocked state, or perhaps there is some problem which means we can't trust the platform. Instead, the *rfkill core* will call set_block() at registration time, with a value taken from the rfkill.default_state module parameter. The driver should not attempt to initialise the soft blocked state itself.
In either case, the driver should report the current hardware-blocked state before registration. That seems to be missing here as well.
> +
> + res = lensl_radio_new_rfkill(&lensl_radios[type],
> + &lensl_radios[type].rfk,
> + sw_blocked, hw_blocked);
> +
> + if (res) {
> + radio_exit(type);
> + return res;
> + }
> + pr_devel("Initialized %s subdriver\n", lensl_radios[type].name);
> +
> + return 0;
> +}
> +
> +/*************************************************************************
> + init/exit
> + *************************************************************************/
> +
> +static int __init lenovo_sl_laptop_init(void)
> +{
> + int ret;
> + acpi_status status;
> +
> + if (acpi_disabled)
> + return -ENODEV;
> +
> + lensl_wq = create_singlethread_workqueue(LENSL_WORKQUEUE_NAME);
> + if (!lensl_wq) {
> + pr_err("Failed to create a workqueue\n");
> + return -ENOMEM;
> + }
> +
> + hkey_handle = ec0_handle = NULL;
> + status = acpi_get_handle(NULL, LENSL_HKEY, &hkey_handle);
> + if (ACPI_FAILURE(status)) {
> + pr_err("Failed to get ACPI handle for %s\n", LENSL_HKEY);
> + return -ENODEV;
> + }
> + status = acpi_get_handle(NULL, LENSL_EC0, &ec0_handle);
> + if (ACPI_FAILURE(status)) {
> + pr_err("Failed to get ACPI handle for %s\n", LENSL_EC0);
> + return -ENODEV;
> + }
> +
> + lensl_pdev = platform_device_register_simple(LENSL_DRVR_NAME, -1,
> + NULL, 0);
> + if (IS_ERR(lensl_pdev)) {
> + ret = PTR_ERR(lensl_pdev);
> + lensl_pdev = NULL;
> + pr_err("Failed to register platform device\n");
> + return ret;
> + }
> +
> + radio_init(LENSL_BLUETOOTH);
> + radio_init(LENSL_WWAN);
> + radio_init(LENSL_UWB);
> +
> + hkey_register_notify();
> + led_init();
> + hwmon_init();
> +
> + pr_info("Loaded Lenovo ThinkPad SL Series driver\n");
> + return 0;
> +}
> +
> +static void __exit lenovo_sl_laptop_exit(void)
> +{
> + hwmon_exit();
> + led_exit();
> + hkey_unregister_notify();
> +
> + radio_exit(LENSL_UWB);
> + radio_exit(LENSL_WWAN);
> + radio_exit(LENSL_BLUETOOTH);
> +
> + if (lensl_pdev)
> + platform_device_unregister(lensl_pdev);
> + destroy_workqueue(lensl_wq);
> +
> + pr_info("Unloaded Lenovo ThinkPad SL Series driver\n");
> +}
> +
> +MODULE_ALIAS("dmi:bvnLENOVO:*:svnLENOVO*:*:pvrThinkPad SL*:rvnLENOVO:*");
> +MODULE_ALIAS("dmi:bvnLENOVO:*:svnLENOVO*:*:pvrThinkPadSL*:rvnLENOVO:*");
> +
> +module_init(lenovo_sl_laptop_init);
> +module_exit(lenovo_sl_laptop_exit);
^ permalink raw reply
* Re: Problems with "cfg80211: fix SME connect" commit
From: Hin-Tak Leung @ 2009-09-25 15:54 UTC (permalink / raw)
To: Johannes Berg; +Cc: Albert Herranz, Holger Schurig, linville, linux-wireless
In-Reply-To: <1253859759.3868.569.camel@johannes.local>
On Fri, Sep 25, 2009 at 7:22 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> Thanks for your analysis.
>
>> This seems to look like/relate to a little problem I have for the last
>> few days - lately I have authentication failure on first try and have
>> to click on NM a 2nd time for it to go through; blow away
>> compat-wireless & revert to as-shipped distro modules gives me the
>> older/smooth behavior of NM just associating without me
>> clicking/asking.
>>
>> v2.6.31-38294-ged3ac87 + 'cfg80211: don't set privacy w/o key' doesn't
>> improve my situation.
>>
>> wpa_supplicant log:
>> --------- distro modules:
>> Trying to associate with <id> (SSID='ID' freq=2437 MHz)
>> Associated with <id>
>> CTRL-EVENT-CONNECTED - Connection to <id> completed (auth) [id=0 id_str=]
>> CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
>>
>> -------- compat-wireless
>> Trying to associate with <id> (SSID='ID' freq=2437 MHz)
>> Authentication with 00:00:00:00:00:00 timed out.
>> Trying to associate with <id> (SSID='ID' freq=2437 MHz)
>> Associated with <id>
>> CTRL-EVENT-CONNECTED - Connection to <id> completed (auth) [id=0 id_str=]
>>
>> ------ dmesg distro modules
>> wlan2: direct probe to AP <id> try 1
>> wlan2 direct probe responded
>> wlan2: authenticate with AP <id>
>> wlan2: authenticated
>> wlan2: associate with AP <id>
>> wlan2: RX AssocResp from <id> (capab=0x431 status=0 aid=1)
>> wlan2: associated
>>
>> ------ compat-wireless, note the extra deauth at the beginning, and
>> all those 'try 1''s.
>> wlan2: deauthenticating by local choice (reason=3)
>> wlan2: direct probe to AP <id> (try 1)
>> wlan2 direct probe responded
>> wlan2: authenticate with AP <id> (try 1)
>> wlan2: authenticated
>> wlan2: associate with AP <id> (try 1)
>> wlan2: RX AssocResp from <id> (capab=0x431 status=0 aid=1)
>> wlan2: associated
>
> I've analysed this, and now know the reason for the extra deauth, but it
> shouldn't hurt since we never send a wireless extensions event. The
> reason is that once wpa_supplicant sets the SSID we already start to
> connect with the new changes, but then setting the BSSID might require
> restarting the process. This could be optimised, but I would prefer not
> having to.
>
> I can see a problem with the code and it trying to scan once more again
> etc. Below patch seems to help for me. However, I only once managed to
> reproduce the problem you were seeing with the authentication timeout in
> wpa_supplicant.
>
> Can you try this? The last hunk is most important, but the other stuff
> helps debugging.
Great. The extra timeout in wap_spplicant.log is gone, so it is back
to NM does it all by itself.
Here is the dmesg from this patch on top of everything else so far:
wlan2: starting authentication with _id_
wlan2: deauthenticating from _id_ by local choice (reason=3)
wlan2: starting authentication with _id_
wlan2: direct probe to AP _id_ (try 1)
wlan2: direct probe responded
wlan2: authenticate with AP _id_ (try 1)
wlan2: authenticated
wlan2: starting association with _id_
wlan2: associate with AP _id_ (try 1)
wlan2: RX AssocResp from _id_ (capab=0x431 status=0 aid=1)
wlan2: associated
There is still the extra deauth at the beginning, but I guess I can
live with it, it doesn't require user action to deal with (unlike
without this latest patch) I suppose there might be more tuning before
commit? Otherwise Tested-by:
Hmm, slightly side-tracked - was the original poster using NM on top
on wpa_supplicant, just curious?
Cheers,
Hin-Tak
^ permalink raw reply
* Re: zd1211rw on Debian not working with new kernels
From: Hin-Tak Leung @ 2009-09-25 15:07 UTC (permalink / raw)
To: Michele Alessandrini; +Cc: linux-wireless
In-Reply-To: <200909251047.46826.m.alessandrini@deit.univpm.it>
2009/9/25 Michele Alessandrini <m.alessandrini@deit.univpm.it>:
> Hi everybody,
> I have a Sitecom WL-113 USB wireless adapter, and I use Debian testing with
> zd1211rw. My wireless network uses WPA.
> The adapter is working with kernel up to 2.6.24. It is not working anymore
> with kernels 2.6.26 and 2.6.30 (these are the kernels I could test).
> From what I can see, wpa_supplicant gets a series of errors from the driver
> when it tries to associate to the network.
> Provided that the OS is exactly the same, and the only variable is which
> kernel is booted, I think it's something related to the driver (kernel 2.6.26
> is where the MAC layer has been changed) or to the interface between it and
> wpa_supplicant.
> I'm just writing to ask if this is a know issue or if someone else is getting
> similar problems.
> Thank you very much for your work
> Bye
> Michele Alessandrini, Italy
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
I am quite sure you are mistaken. Debian ships a version of the
vendor/vendor-derived driver up to 2.6.24(?) and I don't know when
they switch over. You should approach the debian people on your
problem.
^ permalink raw reply
* Re: 2.6.31-git wireless broken
From: Christian Lamparter @ 2009-09-25 14:56 UTC (permalink / raw)
To: Holger Schurig; +Cc: Hugh Dickins, linux-wireless
In-Reply-To: <200909251045.38894.hs4233@mail.mn-solutions.de>
On Friday 25 September 2009 10:45:38 Holger Schurig wrote:
> > I wonder, have there been more yet more regdom reworks since 2.6.31?
> > Would this be the stage at which regdom problems manifest? I'm not
> > running whatever-it-is daemon for setting regdom, usually just patch
> > static char *ieee80211_regdom = "EU";
> > into my kernels; but in the past have only needed that when the router
> > decides to use channel 13 or something - currently it's on channel 1.
>
> I've install crda and it works great with 2.6.31, althought I had
> to override the EEPROM, which reports bugus data:
>
> - ath_regd_sanitize(reg);
> -
> - printk(KERN_DEBUG "ath: EEPROM regdomain: 0x%0x\n", reg->current_rd);
> + reg->current_rd = CTRY_GERMANY | COUNTRY_ERD_FLAG;
>
FYI: the athinfo (from the madwifi-project) utility can be used to write a
a sane regdomain code into the EEPROM chip on most ath5k cards.
^ permalink raw reply
* Re: getting "ath5k phy0: noise floor calibration timeout"
From: Bob Copeland @ 2009-09-25 14:39 UTC (permalink / raw)
To: Holger Schurig; +Cc: Dan Williams, linux-wireless, Luis R. Rodriguez
In-Reply-To: <200909241015.06706.hs4233@mail.mn-solutions.de>
On Thu, Sep 24, 2009 at 4:15 AM, Holger Schurig
<hs4233@mail.mn-solutions.de> wrote:
> On ath5k-devel, there was a mail "[ath5k-devel] [RFC/RFT] ath5k:
> use noise calibration from madwifi hal" from Bob Copeland.
>
> Part of the patch is "- we do not complain if NF calibration
> isn't complete, instead we keep the last read value.".
Yeah, NF calibration timeout happens all the time (also in
madwifi/ath9k) so we should just silence it. At best, it indicates
a problem that the user can't do anything about; at worst, it
leads to bug reports accusing the NF calibration of wholly unrelated
things.
I really should finish testing and push that patch, real life has
just been in the way lately.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: 2.6.31-git wireless broken
From: Hugh Dickins @ 2009-09-25 14:15 UTC (permalink / raw)
To: Johannes Berg; +Cc: John W. Linville, Rafael J. Wysocki, linux-wireless
In-Reply-To: <1253868214.3868.713.camel@johannes.local>
On Fri, 25 Sep 2009, Johannes Berg wrote:
> On Fri, 2009-09-25 at 09:06 +0100, Hugh Dickins wrote:
>
> > Should be, but you're right, for whatever reason it is not running
> > with these recent kernels.
> >
> > I expect that correlates with iwconfig showing me ESSID:off/any.
>
> Well it showing you that means that nothing is even trying to connect :)
>
> > I'm thinking that (unless you've a better idea) I should do another
> > bisect for when that behaviour starts - hoping that whatever problem
> > led me to your patch, got fixed up later on, but superseded by this
> > different problem.
>
> Not sure, might be very time consuming.
That bisection, focussing on wpa_supplicant running versus ESSID:off/any
(indeed they match up), now completed on the Aspire One (I'll assume for
the moment that the laptop would show the same).
Yes, it does appear that the patch I originally pointed to introduced a
problem which later got fixed, but was enough to throw the bisection off
when I just looked for "wireless not working".
But you can't escape, you've been too busy, the guilty patch is...
a9a11622c5c742c115fad371c0397ae86dd3bb67 is first bad commit
commit a9a11622c5c742c115fad371c0397ae86dd3bb67
Author: Johannes Berg <johannes@sipsolutions.net>
Date: Mon Jul 27 12:01:53 2009 +0200
cfg80211: self-contained wext handling where possible
Finally! This is what you've all been waiting for!
This patch makes cfg80211 take care of wext emulation
_completely_ by itself, drivers that don't need things
cfg80211 doesn't do yet don't even need to be aware of
wireless extensions.
This means we can also clean up mac80211's and iwm's
Kconfig and make it possible to build them w/o wext
now!
RIP wext.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
:040000 040000 ce98d49476cd6547eabab0db90bdff31cc40104e 8ea4d1374da1fb39e1ea431cd07da96ecdccd565 M drivers
:040000 040000 23a9348f55a10a0c8278049f71be02728514fc61 de6267de96e307e41bb5aded9666c5bc1e4fe938 M net
RIP wireless - not quite what I'd been waiting for ;)
Hugh
^ 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