* Re: iwl3945: Error sending REPLY_{RXON|SCAN_CMD|TX_PWR_TABLE_CMD} time out after 500ms
From: Sedat Dilek @ 2010-04-26 16:31 UTC (permalink / raw)
To: reinette chatre; +Cc: wireless, John Linville, Berg, Johannes
In-Reply-To: <1272298097.4381.8765.camel@rchatre-DESK>
I tested both .34-git4 kernels half a day and this was the only
problem I saw in the my system-logs.
BTW, the WLAN connection did not crash as described in the initial
bug-report (logs see [1]).
At that time, I had to coldstart my machine - this was not the case
last weekend while testing.
- Sedat -
[1] http://files.iniza.org/BUG_iwl3945_20100417/logs/
On Mon, Apr 26, 2010 at 6:08 PM, reinette chatre
<reinette.chatre@intel.com> wrote:
> On Mon, 2010-04-26 at 01:20 -0700, Sedat Dilek wrote:
>> I had only one issue with
>> linux-image-2.6.34-rc4-115-gdc57da3_2.6.34-rc4-115-gdc57da3.20100424~iniza.1_i386.deb
>> kernel:
>>
>> ...
>> /var/log/syslog.1-Apr 25 13:33:11 seduxbox wpa_supplicant[1732]: WPA:
>> Group rekeying completed with 00:04:0e:e4:00:3d [GTK=CCMP]
>> /var/log/syslog.1:Apr 25 13:59:56 seduxbox kernel: [59184.500070] No
>> probe response from AP 00:04:0e:e4:00:3d after 500ms, disconnecting.
>> /var/log/syslog.1-Apr 25 13:59:56 seduxbox kernel: [59184.505044]
>> cfg80211: Calling CRDA to update world regulatory domain
>> /var/log/syslog.1-Apr 25 13:59:56 seduxbox wpa_supplicant[1732]:
>> CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
>> /var/log/syslog.1-Apr 25 13:59:57 seduxbox kernel: [59185.717331]
>> cfg80211: World regulatory domain updated:
>> /var/log/syslog.1-Apr 25 13:59:57 seduxbox kernel: [59185.717337]
>> (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
>> /var/log/syslog.1-Apr 25 13:59:57 seduxbox kernel: [59185.717343]
>> (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>> /var/log/syslog.1-Apr 25 13:59:57 seduxbox kernel: [59185.717349]
>> (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
>> /var/log/syslog.1-Apr 25 13:59:57 seduxbox kernel: [59185.717355]
>> (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
>> /var/log/syslog.1-Apr 25 13:59:57 seduxbox kernel: [59185.717361]
>> (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>> /var/log/syslog.1-Apr 25 13:59:57 seduxbox kernel: [59185.717367]
>> (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>> /var/log/syslog.1-Apr 25 13:59:59 seduxbox wpa_supplicant[1732]:
>> Trying to associate with 00:04:0e:e4:00:3d
>> (SSID='g00gle-street-knows-my-SSID-and-where-I-live' freq=2442 MHz)
>> /var/log/syslog.1-Apr 25 13:59:59 seduxbox kernel: [59187.753888]
>> wlan0: authenticate with 00:04:0e:e4:00:3d (try 1)
>> /var/log/syslog.1-Apr 25 13:59:59 seduxbox kernel: [59187.755614]
>> wlan0: authenticated
>> /var/log/syslog.1-Apr 25 13:59:59 seduxbox kernel: [59187.755649]
>> wlan0: associate with 00:04:0e:e4:00:3d (try 1)
>> /var/log/syslog.1-Apr 25 13:59:59 seduxbox kernel: [59187.760216]
>> wlan0: RX AssocResp from 00:04:0e:e4:00:3d (capab=0x411 status=0
>> aid=1)
>> /var/log/syslog.1-Apr 25 13:59:59 seduxbox kernel: [59187.760221]
>> wlan0: associated
>> /var/log/syslog.1-Apr 25 13:59:59 seduxbox wpa_supplicant[1732]:
>> Associated with 00:04:0e:e4:00:3d
>> /var/log/syslog.1-Apr 25 13:59:59 seduxbox wpa_supplicant[1732]: WPA:
>> Key negotiation completed with 00:04:0e:e4:00:3d [PTK=CCMP GTK=CCMP]
>> /var/log/syslog.1-Apr 25 13:59:59 seduxbox wpa_supplicant[1732]:
>> CTRL-EVENT-CONNECTED - Connection to 00:04:0e:e4:00:3d completed
>> (reauth) [id=0 id_str=]
>> ...
>
> Sorry ... but could you please point out what the issue is above? I do
> see that at one point the station's testing of AP communication
> fails ... but that can happen for many reasons and does not indicate a
> bug. Was there some other logs that pointed out an issue during this
> time?
>
> Reinette
>
>
>
^ permalink raw reply
* Re: iwl3945: Error sending REPLY_{RXON|SCAN_CMD|TX_PWR_TABLE_CMD} time out after 500ms
From: reinette chatre @ 2010-04-26 16:08 UTC (permalink / raw)
To: sedat.dilek@gmail.com; +Cc: wireless, John Linville, Berg, Johannes
In-Reply-To: <m2s2d0a357f1004260120z30d8b3a3i2792cfa4bc390dcc@mail.gmail.com>
On Mon, 2010-04-26 at 01:20 -0700, Sedat Dilek wrote:
> I had only one issue with
> linux-image-2.6.34-rc4-115-gdc57da3_2.6.34-rc4-115-gdc57da3.20100424~iniza.1_i386.deb
> kernel:
>
> ...
> /var/log/syslog.1-Apr 25 13:33:11 seduxbox wpa_supplicant[1732]: WPA:
> Group rekeying completed with 00:04:0e:e4:00:3d [GTK=CCMP]
> /var/log/syslog.1:Apr 25 13:59:56 seduxbox kernel: [59184.500070] No
> probe response from AP 00:04:0e:e4:00:3d after 500ms, disconnecting.
> /var/log/syslog.1-Apr 25 13:59:56 seduxbox kernel: [59184.505044]
> cfg80211: Calling CRDA to update world regulatory domain
> /var/log/syslog.1-Apr 25 13:59:56 seduxbox wpa_supplicant[1732]:
> CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
> /var/log/syslog.1-Apr 25 13:59:57 seduxbox kernel: [59185.717331]
> cfg80211: World regulatory domain updated:
> /var/log/syslog.1-Apr 25 13:59:57 seduxbox kernel: [59185.717337]
> (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> /var/log/syslog.1-Apr 25 13:59:57 seduxbox kernel: [59185.717343]
> (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> /var/log/syslog.1-Apr 25 13:59:57 seduxbox kernel: [59185.717349]
> (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> /var/log/syslog.1-Apr 25 13:59:57 seduxbox kernel: [59185.717355]
> (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> /var/log/syslog.1-Apr 25 13:59:57 seduxbox kernel: [59185.717361]
> (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> /var/log/syslog.1-Apr 25 13:59:57 seduxbox kernel: [59185.717367]
> (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> /var/log/syslog.1-Apr 25 13:59:59 seduxbox wpa_supplicant[1732]:
> Trying to associate with 00:04:0e:e4:00:3d
> (SSID='g00gle-street-knows-my-SSID-and-where-I-live' freq=2442 MHz)
> /var/log/syslog.1-Apr 25 13:59:59 seduxbox kernel: [59187.753888]
> wlan0: authenticate with 00:04:0e:e4:00:3d (try 1)
> /var/log/syslog.1-Apr 25 13:59:59 seduxbox kernel: [59187.755614]
> wlan0: authenticated
> /var/log/syslog.1-Apr 25 13:59:59 seduxbox kernel: [59187.755649]
> wlan0: associate with 00:04:0e:e4:00:3d (try 1)
> /var/log/syslog.1-Apr 25 13:59:59 seduxbox kernel: [59187.760216]
> wlan0: RX AssocResp from 00:04:0e:e4:00:3d (capab=0x411 status=0
> aid=1)
> /var/log/syslog.1-Apr 25 13:59:59 seduxbox kernel: [59187.760221]
> wlan0: associated
> /var/log/syslog.1-Apr 25 13:59:59 seduxbox wpa_supplicant[1732]:
> Associated with 00:04:0e:e4:00:3d
> /var/log/syslog.1-Apr 25 13:59:59 seduxbox wpa_supplicant[1732]: WPA:
> Key negotiation completed with 00:04:0e:e4:00:3d [PTK=CCMP GTK=CCMP]
> /var/log/syslog.1-Apr 25 13:59:59 seduxbox wpa_supplicant[1732]:
> CTRL-EVENT-CONNECTED - Connection to 00:04:0e:e4:00:3d completed
> (reauth) [id=0 id_str=]
> ...
Sorry ... but could you please point out what the issue is above? I do
see that at one point the station's testing of AP communication
fails ... but that can happen for many reasons and does not indicate a
bug. Was there some other logs that pointed out an issue during this
time?
Reinette
^ permalink raw reply
* Re: wl1251_sdio PSM
From: GNUtoo @ 2010-04-26 12:36 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1272235632.2349.28.camel@gnutoo-desktop>
On Mon, 2010-04-26 at 00:47 +0200, GNUtoo wrote:
> > I changed added | IEEE80211_HW_SUPPORTS_PS in:
> > wl->hw->flags = IEEE80211_HW_SIGNAL_DBM |
> > IEEE80211_HW_NOISE_DBM;
> >
> > Denis.
> that was the wrong fix.
> The good fix(many thanks to chr_ in #linux-wireless) was to try
> compat-wireless,which bringed many more power saving features according
> to him.
>
> Denis.
Unfortunately it didn't work as expected:
# ping router
PING router (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: seq=0 ttl=64 time=7.995 ms
64 bytes from 192.168.1.1: seq=1 ttl=64 time=5.707 ms
64 bytes from 192.168.1.1: seq=2 ttl=64 time=5.005 ms
64 bytes from 192.168.1.1: seq=3 ttl=64 time=4.730 ms
64 bytes from 192.168.1.1: seq=4 ttl=64 time=13.703 ms
64 bytes from 192.168.1.1: seq=5 ttl=64 time=13.092 ms
64 bytes from 192.168.1.1: seq=6 ttl=64 time=12.513 ms
64 bytes from 192.168.1.1: seq=7 ttl=64 time=11.811 ms
64 bytes from 192.168.1.1: seq=8 ttl=64 time=11.200 ms
64 bytes from 192.168.1.1: seq=9 ttl=64 time=10.101 ms
64 bytes from 192.168.1.1: seq=10 ttl=64 time=9.400 ms
64 bytes from 192.168.1.1: seq=11 ttl=64 time=8.697 ms
64 bytes from 192.168.1.1: seq=12 ttl=64 time=8.088 ms
64 bytes from 192.168.1.1: seq=13 ttl=64 time=7.416 ms
64 bytes from 192.168.1.1: seq=14 ttl=64 time=6.775 ms
64 bytes from 192.168.1.1: seq=15 ttl=64 time=6.164 ms
64 bytes from 192.168.1.1: seq=16 ttl=64 time=5.494 ms
64 bytes from 192.168.1.1: seq=17 ttl=64 time=4.852 ms
64 bytes from 192.168.1.1: seq=18 ttl=64 time=4.364 ms
64 bytes from 192.168.1.1: seq=19 ttl=64 time=3.418 ms
64 bytes from 192.168.1.1: seq=20 ttl=64 time=2.777 ms
64 bytes from 192.168.1.1: seq=21 ttl=64 time=12.024 ms
64 bytes from 192.168.1.1: seq=22 ttl=64 time=11.414 ms
64 bytes from 192.168.1.1: seq=23 ttl=64 time=10.193 ms
64 bytes from 192.168.1.1: seq=24 ttl=64 time=9.552 ms
64 bytes from 192.168.1.1: seq=25 ttl=64 time=8.911 ms
64 bytes from 192.168.1.1: seq=26 ttl=64 time=8.240 ms
64 bytes from 192.168.1.1: seq=27 ttl=64 time=7.812 ms
64 bytes from 192.168.1.1: seq=28 ttl=64 time=6.958 ms
64 bytes from 192.168.1.1: seq=29 ttl=64 time=6.317 ms
64 bytes from 192.168.1.1: seq=30 ttl=64 time=5.707 ms
64 bytes from 192.168.1.1: seq=31 ttl=64 time=4.944 ms
64 bytes from 192.168.1.1: seq=32 ttl=64 time=4.303 ms
64 bytes from 192.168.1.1: seq=33 ttl=64 time=2194.366 ms
64 bytes from 192.168.1.1: seq=34 ttl=64 time=1193.634 ms
64 bytes from 192.168.1.1: seq=35 ttl=64 time=193.421 ms
64 bytes from 192.168.1.1: seq=38 ttl=64 time=760.559 ms
64 bytes from 192.168.1.1: seq=39 ttl=64 time=784.851 ms
the power_save feature was activated with iw, just before the
64 bytes from 192.168.1.1: seq=33 ttl=64 time=2194.366 ms
line
then after 5 lines of ping it stopped displaying the pings.
Denis.
^ permalink raw reply
* Re: [RFC PATCHv3 1/2] mac80211: Determine dynamic PS timeout based on ps-qos network latency
From: Johannes Berg @ 2010-04-26 12:30 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1272284587.6205.10424.camel@wimaxnb.nmp.nokia.com>
On Mon, 2010-04-26 at 15:23 +0300, Juuso Oikarinen wrote:
> Heh, I could in turn say that you think too little about power
> consumption :) This particular thing, dynamic ps timer, has a *huge*
> effect on the total power consumption just because it's so frequent.
Heh :)
> I'm basically open for any means to tell cfg80211 that it should
> sacrifice service quality in the name of saving as much power as it can
> (apart from shutting the thing down :). Can you give me a hint on what
> you would consider an acceptable way to do this?
Well personally I'm happy with this approach.
I just fear that at one point, somebody will tweak the algorithm, and
you will have deeply ingrained assumptions about where the cutoff points
are in your userland software, which will cause all kinds of grief.
johannes
^ permalink raw reply
* Re: [RFC PATCHv3 1/2] mac80211: Determine dynamic PS timeout based on ps-qos network latency
From: Juuso Oikarinen @ 2010-04-26 12:23 UTC (permalink / raw)
To: ext Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1272283911.3619.29.camel@jlt3.sipsolutions.net>
On Mon, 2010-04-26 at 14:11 +0200, ext Johannes Berg wrote:
> On Mon, 2010-04-26 at 15:04 +0300, Juuso Oikarinen wrote:
>
> > > Well I would argue that if the user requires a certain network latency,
> > > that should take precedence. The user is unlikely to be thinking in
> > > terms of "I want my battery to last that long"; rather they want to last
> > > it as long as possible given their quality of service demand
> > > constraints?
> >
> > Well, this is not entirely correct. In the situation I'm thinking about,
> > the user (the user space network manager is acting on behalf of him)
> > thinks exactly on the lines of "I want my battery to last that long, or
> > longer." The device is in the users pocket, WLAN associated. He does not
> > care about latency at all, so the network manager sets a large enough
> > latency value that allows the WLAN subsystem to sacrifice all latency to
> > just reduce power consumption.
>
> But in that case you also don't care about latency, obviously. So you
> can just say "don't care about latency", and get all the power savings
> that are possible in such a situation.
Well throw me a bone here! :)
That is essentially what I try to accomplish here! There just currently
isn't a way to say that to cfg80211. You can't say "I don't care about
latency, save as much power as you can."
> Basically there's a trade-off here between power consumption and
> latency. I'm arguing that one should control latency, and power
> consumption follows "best effort", but you seem to also be arguing that
> in some situations one should control power consumption, and latency
> gets bad.
>
> > > > The ps_timeout could be calculated based on the latency too, I guess.
> > > > I'm just not aware of any simple formula to do this.
> > >
> > > But you did just base it on that?
> >
> > Yeah, sorry, I intended to say "based on beacon interval and latency."
>
> Which might actually make sense, because if for instance required
> latency >> beacon interval, there's not much gain from dynamic power
> saving timeouts.
>
> > > It just seems to me that you're putting the power consumption
> > > requirements after the quality of service demands, which would seem
> > > wrong?
> >
> > I'm sorry, I don't understand this statement (literally). To argue
> > anyway: I'm thinking I'm binding power consumption requirements together
> > with QoS demands. :)
>
> Yeah, but I have a feeling you're thinking about power consumption too
> much. I understand that is a goal, but shouldn't the goal be stated as
> "provide the lowest power consumption under the latency QoS
> constraints"?
Heh, I could in turn say that you think too little about power
consumption :) This particular thing, dynamic ps timer, has a *huge*
effect on the total power consumption just because it's so frequent.
I'm basically open for any means to tell cfg80211 that it should
sacrifice service quality in the name of saving as much power as it can
(apart from shutting the thing down :). Can you give me a hint on what
you would consider an acceptable way to do this?
-Juuso
> johannes
>
^ permalink raw reply
* Re: [WIP] p54pci: fix resume p54 cardbus
From: Hans de Goede @ 2010-04-26 12:22 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless
In-Reply-To: <201004261412.47831.chunkeey@googlemail.com>
Hi,
On 04/26/2010 02:12 PM, Christian Lamparter wrote:
> On Monday 26 April 2010 11:38:06 Hans de Goede wrote:
>> On 04/25/2010 03:25 PM, Christian Lamparter wrote:
>>> This patch tries to fix the resume freeze, which is described in
>>> https://bugzilla.redhat.com/show_bug.cgi?id=583623
>>>
>>> Unlike (normal) PCI cards, cardbus cards are easily removable.
>>> Therefore, the user might replace/remove the card while
>>> the system is suspended. The pcmcia subsystem takes special
>>> precautions to deal with such cases and un- and rebinds
>>> all devices on the pci-bridge during the resume process.
>>>
>>> But here's the catch: p54pci uses request_firmware
>>> which blocks until the filesystem is available.
>>> This deadlocks, because the filesystem won't
>>> be initialized until all pci devices are ready again.
>>
>> p54pci uses request_firmware only from its probe function,
>> which does not get called during a suspend resume AFAIK.
>>
>> And if the card was inserted during a suspend / resume. I would
>> not expect its driver to get loaded until the resume has completed
>> and udev runs again.
>
> no, all 2.6.34-rcX-wl kernels - I tried - refused to resume if
> a p54pci was present in the cardslot. The culprit was found to be:
>
> commit 88b060d6c03fcb9e4d2018b4349954c4242a5c7f
> Author: Dominik Brodowski<linux@dominikbrodowski.net>
> Date: Sat Jan 2 14:14:23 2010 +0100
>
> pcmcia: improve check for same card in slot after resume
>
> During a suspend/resume cycle, an user may change the card in the
> PCMCIA/CardBus slot. The pcmcia_core can at least look at the
> socket state to check whether it is the same.
>
> For PCMCIA devices, move the detection and handling of such a
> change to ds.c.
>
> --> For CardBus devices, the PCI hotplug interface doesn't offer a "rescan"
> facility which also _removes_ devices no longer to be found behind a
> bridge. Therefore, remove and re-add all devices unconditionally.
>
>> Hmm, I think while typing this message I just understood what you're
>> trying to fix. The problem could occur when the driver is already loaded
>> (for some reason), but not yet bound to the device as the card got
>> inserted during suspend. Does the probe function get called during
>> resume then ?
>
> yes, due to "pcmcia: improve check for same card in slot after resume"
> the p54p_probe function is now always called during resume. And as
> you know this deadlocks, unless the firmware is included into the
> kernel.
>
>> This would seem like a driver core bug to me. It should not start
>> binding drivers to "new" devices, until the resume is completed IMHO.
> Well, the commit author does have a point.
>
> what if I replace my Netgear WG511 with different Netgear WG511
> (or even SMC W2835V2) while the system is suspendend?
> All cards are fullmac p54pci, but they are not the same HW.
>
Unbinding / rebinding the driver sounds like a really big hammer
to me though. Maybe drivers need a new re-scan hook or some such.
> On the other hand, this patch breaks basically any cardbus
> device driver which needs firmware and doesn't use the asynchronus
> request interface. Also, (in case of mac80211) the unbind/bind
> procedure resets mac80211/driver/etc.. to their uninitialized states
> (and changes a few things, e.g.: phyX ids and friends).
> This could very well confuse the userspace, because after the
> resume all configurations are gone...
>
Yeah, this sounds like a case of the cure being worse then the disease
(as we say in the Netherlands).
>> Note that the problem which I'm mostly seeing with suspend resume,
>> is that the card fails shortly after resume. It seems to be come up
>> and I can send / receive some packets and then it fails. The changes
>> you're making to resume where you're actually calling pci enable
>> on the device, and re-doing some pci config space settings might help
>> here (I'm currently unloading the driver before suspend and reloading
>> it after resume and then things work fine).
> hm, can't say much about that... But, I have a (mini)pci system,
> which hopefully won't unbind/rebind the devices upon resume.
>
I've taking a look at this on my to do list, and some parts of your WIP
patch look like a good candidate for initial testing. I must say this is
rather low on my todo though as the remove module before suspend / reinsert
after resume fix works and my to do list is rather full.
Regards,
Hans
^ permalink raw reply
* Re: [WIP] p54pci: fix resume p54 cardbus
From: Christian Lamparter @ 2010-04-26 12:12 UTC (permalink / raw)
To: Hans de Goede; +Cc: linux-wireless
In-Reply-To: <4BD55EFE.3080009@redhat.com>
On Monday 26 April 2010 11:38:06 Hans de Goede wrote:
> On 04/25/2010 03:25 PM, Christian Lamparter wrote:
> > This patch tries to fix the resume freeze, which is described in
> > https://bugzilla.redhat.com/show_bug.cgi?id=583623
> >
> > Unlike (normal) PCI cards, cardbus cards are easily removable.
> > Therefore, the user might replace/remove the card while
> > the system is suspended. The pcmcia subsystem takes special
> > precautions to deal with such cases and un- and rebinds
> > all devices on the pci-bridge during the resume process.
> >
> > But here's the catch: p54pci uses request_firmware
> > which blocks until the filesystem is available.
> > This deadlocks, because the filesystem won't
> > be initialized until all pci devices are ready again.
>
> p54pci uses request_firmware only from its probe function,
> which does not get called during a suspend resume AFAIK.
>
> And if the card was inserted during a suspend / resume. I would
> not expect its driver to get loaded until the resume has completed
> and udev runs again.
no, all 2.6.34-rcX-wl kernels - I tried - refused to resume if
a p54pci was present in the cardslot. The culprit was found to be:
commit 88b060d6c03fcb9e4d2018b4349954c4242a5c7f
Author: Dominik Brodowski <linux@dominikbrodowski.net>
Date: Sat Jan 2 14:14:23 2010 +0100
pcmcia: improve check for same card in slot after resume
During a suspend/resume cycle, an user may change the card in the
PCMCIA/CardBus slot. The pcmcia_core can at least look at the
socket state to check whether it is the same.
For PCMCIA devices, move the detection and handling of such a
change to ds.c.
--> For CardBus devices, the PCI hotplug interface doesn't offer a "rescan"
facility which also _removes_ devices no longer to be found behind a
bridge. Therefore, remove and re-add all devices unconditionally.
> Hmm, I think while typing this message I just understood what you're
> trying to fix. The problem could occur when the driver is already loaded
> (for some reason), but not yet bound to the device as the card got
> inserted during suspend. Does the probe function get called during
> resume then ?
yes, due to "pcmcia: improve check for same card in slot after resume"
the p54p_probe function is now always called during resume. And as
you know this deadlocks, unless the firmware is included into the
kernel.
> This would seem like a driver core bug to me. It should not start
> binding drivers to "new" devices, until the resume is completed IMHO.
Well, the commit author does have a point.
what if I replace my Netgear WG511 with different Netgear WG511
(or even SMC W2835V2) while the system is suspendend?
All cards are fullmac p54pci, but they are not the same HW.
On the other hand, this patch breaks basically any cardbus
device driver which needs firmware and doesn't use the asynchronus
request interface. Also, (in case of mac80211) the unbind/bind
procedure resets mac80211/driver/etc.. to their uninitialized states
(and changes a few things, e.g.: phyX ids and friends).
This could very well confuse the userspace, because after the
resume all configurations are gone...
> Note that the problem which I'm mostly seeing with suspend resume,
> is that the card fails shortly after resume. It seems to be come up
> and I can send / receive some packets and then it fails. The changes
> you're making to resume where you're actually calling pci enable
> on the device, and re-doing some pci config space settings might help
> here (I'm currently unloading the driver before suspend and reloading
> it after resume and then things work fine).
hm, can't say much about that... But, I have a (mini)pci system,
which hopefully won't unbind/rebind the devices upon resume.
> The one actual lockup I experienced in combination with suspend / resume
> was before the other p54pci bug we've working on together was fixed,
> as the driver was unstable at that time in general, so I'm not overly
> worried about that one lockup.
Ok, understood.
Regards,
Chr
^ permalink raw reply
* Re: [RFC PATCHv3 1/2] mac80211: Determine dynamic PS timeout based on ps-qos network latency
From: Johannes Berg @ 2010-04-26 12:11 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1272283483.6205.10416.camel@wimaxnb.nmp.nokia.com>
On Mon, 2010-04-26 at 15:04 +0300, Juuso Oikarinen wrote:
> > Well I would argue that if the user requires a certain network latency,
> > that should take precedence. The user is unlikely to be thinking in
> > terms of "I want my battery to last that long"; rather they want to last
> > it as long as possible given their quality of service demand
> > constraints?
>
> Well, this is not entirely correct. In the situation I'm thinking about,
> the user (the user space network manager is acting on behalf of him)
> thinks exactly on the lines of "I want my battery to last that long, or
> longer." The device is in the users pocket, WLAN associated. He does not
> care about latency at all, so the network manager sets a large enough
> latency value that allows the WLAN subsystem to sacrifice all latency to
> just reduce power consumption.
But in that case you also don't care about latency, obviously. So you
can just say "don't care about latency", and get all the power savings
that are possible in such a situation.
Basically there's a trade-off here between power consumption and
latency. I'm arguing that one should control latency, and power
consumption follows "best effort", but you seem to also be arguing that
in some situations one should control power consumption, and latency
gets bad.
> > > The ps_timeout could be calculated based on the latency too, I guess.
> > > I'm just not aware of any simple formula to do this.
> >
> > But you did just base it on that?
>
> Yeah, sorry, I intended to say "based on beacon interval and latency."
Which might actually make sense, because if for instance required
latency >> beacon interval, there's not much gain from dynamic power
saving timeouts.
> > It just seems to me that you're putting the power consumption
> > requirements after the quality of service demands, which would seem
> > wrong?
>
> I'm sorry, I don't understand this statement (literally). To argue
> anyway: I'm thinking I'm binding power consumption requirements together
> with QoS demands. :)
Yeah, but I have a feeling you're thinking about power consumption too
much. I understand that is a goal, but shouldn't the goal be stated as
"provide the lowest power consumption under the latency QoS
constraints"?
johannes
^ permalink raw reply
* Re: [RFC PATCHv3 1/2] mac80211: Determine dynamic PS timeout based on ps-qos network latency
From: Juuso Oikarinen @ 2010-04-26 12:04 UTC (permalink / raw)
To: ext Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1272282845.3619.25.camel@jlt3.sipsolutions.net>
On Mon, 2010-04-26 at 13:54 +0200, ext Johannes Berg wrote:
> On Thu, 2010-04-22 at 12:29 +0300, Juuso Oikarinen wrote:
>
> > > Still I think you should say why you need to actually tune the PS
> > > timeout value directly? I can't see how your high-level design says "set
> > > dynamic PS timeout to 100ms" rather than "make sure that while the user
> > > is operating the device, there's no delay of more than 50ms" or
> > > something like that?
> >
> > You're partly right asking this. The high-level design obviously does
> > not know about dynamic PS timeouts. It seems you're mainly looking at
> > this from the angle of the network latency itself - i.e. network
> > performance. My primary angle currently is power consumption.
> >
> > IMHO both angles are correct. The if the user sets a tight
> > network-latency requirement, the value can be used to tune things so
> > that the requirement can be met. If they set a loose requirement, it can
> > be used as a signal to do more aggressive power saving, which often
> > means reduced latency.
>
> Well I would argue that if the user requires a certain network latency,
> that should take precedence. The user is unlikely to be thinking in
> terms of "I want my battery to last that long"; rather they want to last
> it as long as possible given their quality of service demand
> constraints?
Well, this is not entirely correct. In the situation I'm thinking about,
the user (the user space network manager is acting on behalf of him)
thinks exactly on the lines of "I want my battery to last that long, or
longer." The device is in the users pocket, WLAN associated. He does not
care about latency at all, so the network manager sets a large enough
latency value that allows the WLAN subsystem to sacrifice all latency to
just reduce power consumption.
>
> > While the mechanism I'm proposing here is rather crude, it does save
> > power when the user-space loosens their latency requirement. The values
> > chosen for the dynamic ps-timeout bear no direct relation to user space
> > requirements. They are simply values that we have found to give decent
> > results in typical AP configurations.
> >
> > The ps_timeout could be calculated based on the latency too, I guess.
> > I'm just not aware of any simple formula to do this.
>
> But you did just base it on that?
Yeah, sorry, I intended to say "based on beacon interval and latency."
> It just seems to me that you're putting the power consumption
> requirements after the quality of service demands, which would seem
> wrong?
I'm sorry, I don't understand this statement (literally). To argue
anyway: I'm thinking I'm binding power consumption requirements together
with QoS demands. :)
-Juuso
> johannes
>
^ permalink raw reply
* [PATCH] rt2x00: rt2800lib: Fix rx path on SoC devices
From: Helmut Schaa @ 2010-04-26 11:48 UTC (permalink / raw)
To: John Linville; +Cc: Ivo van Doorn, Gertjan van Wingerde, linux-wireless
Restore the rfcsr initialization for RT305x SoC devices which was removed
by "rt2x00: Finish rt3070 support in rt2800 register initialization.".
This fixes the rx path on SoC devices.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
---
drivers/net/wireless/rt2x00/rt2800lib.c | 34 ++++++++++++++++++++++++++++++-
1 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index 2648f31..1358d9a 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -1703,7 +1703,8 @@ int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
if (!rt2x00_rt(rt2x00dev, RT3070) &&
!rt2x00_rt(rt2x00dev, RT3071) &&
!rt2x00_rt(rt2x00dev, RT3090) &&
- !rt2x00_rt(rt2x00dev, RT3390))
+ !rt2x00_rt(rt2x00dev, RT3390) &&
+ !(rt2x00_is_soc(rt2x00dev) && rt2x00_rt(rt2x00dev, RT2872)))
return 0;
/*
@@ -1771,6 +1772,37 @@ int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
rt2800_rfcsr_write(rt2x00dev, 29, 0x8f);
rt2800_rfcsr_write(rt2x00dev, 30, 0x20);
rt2800_rfcsr_write(rt2x00dev, 31, 0x0f);
+ } else if (rt2x00_rt(rt2x00dev, RT2872)) {
+ rt2800_rfcsr_write(rt2x00dev, 0, 0x50);
+ rt2800_rfcsr_write(rt2x00dev, 1, 0x01);
+ rt2800_rfcsr_write(rt2x00dev, 2, 0xf7);
+ rt2800_rfcsr_write(rt2x00dev, 3, 0x75);
+ rt2800_rfcsr_write(rt2x00dev, 4, 0x40);
+ rt2800_rfcsr_write(rt2x00dev, 5, 0x03);
+ rt2800_rfcsr_write(rt2x00dev, 6, 0x02);
+ rt2800_rfcsr_write(rt2x00dev, 7, 0x50);
+ rt2800_rfcsr_write(rt2x00dev, 8, 0x39);
+ rt2800_rfcsr_write(rt2x00dev, 9, 0x0f);
+ rt2800_rfcsr_write(rt2x00dev, 10, 0x60);
+ rt2800_rfcsr_write(rt2x00dev, 11, 0x21);
+ rt2800_rfcsr_write(rt2x00dev, 12, 0x75);
+ rt2800_rfcsr_write(rt2x00dev, 13, 0x75);
+ rt2800_rfcsr_write(rt2x00dev, 14, 0x90);
+ rt2800_rfcsr_write(rt2x00dev, 15, 0x58);
+ rt2800_rfcsr_write(rt2x00dev, 16, 0xb3);
+ rt2800_rfcsr_write(rt2x00dev, 17, 0x92);
+ rt2800_rfcsr_write(rt2x00dev, 18, 0x2c);
+ rt2800_rfcsr_write(rt2x00dev, 19, 0x02);
+ rt2800_rfcsr_write(rt2x00dev, 20, 0xba);
+ rt2800_rfcsr_write(rt2x00dev, 21, 0xdb);
+ rt2800_rfcsr_write(rt2x00dev, 22, 0x00);
+ rt2800_rfcsr_write(rt2x00dev, 23, 0x31);
+ rt2800_rfcsr_write(rt2x00dev, 24, 0x08);
+ rt2800_rfcsr_write(rt2x00dev, 25, 0x01);
+ rt2800_rfcsr_write(rt2x00dev, 26, 0x25);
+ rt2800_rfcsr_write(rt2x00dev, 27, 0x23);
+ rt2800_rfcsr_write(rt2x00dev, 28, 0x13);
+ rt2800_rfcsr_write(rt2x00dev, 29, 0x83);
}
if (rt2x00_rt_rev_lt(rt2x00dev, RT3070, REV_RT3070F)) {
--
1.6.4.2
^ permalink raw reply related
* Re: [RFC PATCHv3 1/2] mac80211: Determine dynamic PS timeout based on ps-qos network latency
From: Johannes Berg @ 2010-04-26 11:54 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1271928576.6205.8919.camel@wimaxnb.nmp.nokia.com>
On Thu, 2010-04-22 at 12:29 +0300, Juuso Oikarinen wrote:
> > Still I think you should say why you need to actually tune the PS
> > timeout value directly? I can't see how your high-level design says "set
> > dynamic PS timeout to 100ms" rather than "make sure that while the user
> > is operating the device, there's no delay of more than 50ms" or
> > something like that?
>
> You're partly right asking this. The high-level design obviously does
> not know about dynamic PS timeouts. It seems you're mainly looking at
> this from the angle of the network latency itself - i.e. network
> performance. My primary angle currently is power consumption.
>
> IMHO both angles are correct. The if the user sets a tight
> network-latency requirement, the value can be used to tune things so
> that the requirement can be met. If they set a loose requirement, it can
> be used as a signal to do more aggressive power saving, which often
> means reduced latency.
Well I would argue that if the user requires a certain network latency,
that should take precedence. The user is unlikely to be thinking in
terms of "I want my battery to last that long"; rather they want to last
it as long as possible given their quality of service demand
constraints?
> While the mechanism I'm proposing here is rather crude, it does save
> power when the user-space loosens their latency requirement. The values
> chosen for the dynamic ps-timeout bear no direct relation to user space
> requirements. They are simply values that we have found to give decent
> results in typical AP configurations.
>
> The ps_timeout could be calculated based on the latency too, I guess.
> I'm just not aware of any simple formula to do this.
But you did just base it on that?
It just seems to me that you're putting the power consumption
requirements after the quality of service demands, which would seem
wrong?
johannes
^ permalink raw reply
* [PATCH] rt2x00: rt2800lib: Remove redundant check for RT2872
From: Helmut Schaa @ 2010-04-26 11:50 UTC (permalink / raw)
To: John Linville; +Cc: Ivo van Doorn, Gertjan van Wingerde, linux-wireless
Remove redundant check for RT2872.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
---
drivers/net/wireless/rt2x00/rt2800lib.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index 1358d9a..b30d59c 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -2018,7 +2018,6 @@ int rt2800_validate_eeprom(struct rt2x00_dev *rt2x00dev)
EEPROM(rt2x00dev, "Antenna: 0x%04x\n", word);
} else if (rt2x00_rt(rt2x00dev, RT2860) ||
rt2x00_rt(rt2x00dev, RT2870) ||
- rt2x00_rt(rt2x00dev, RT2872) ||
rt2x00_rt(rt2x00dev, RT2872)) {
/*
* There is a max of 2 RX streams for RT28x0 series
--
1.6.4.2
^ permalink raw reply related
* Re: [PATCH 6/9] rt2x00: Finish rt3070 support in rt2800 register initialization.
From: Helmut Schaa @ 2010-04-26 11:12 UTC (permalink / raw)
To: Antonio Quartulli
Cc: Gertjan van Wingerde, John W. Linville, Ivo van Doorn,
linux-wireless, users, Luis Correia
In-Reply-To: <201004261302.14682.helmut.schaa@googlemail.com>
Am Montag 26 April 2010 schrieb Helmut Schaa:
> Am Sonntag 11 April 2010 schrieb Gertjan van Wingerde:
> > rt2x00 had preliminary support for RT3070 based devices, but the support was
> > incomplete.
> > Update the RT3070 register initialization to be similar to the latest Ralink
> > vendor driver.
> >
> > With this patch my rt3070 based devices start showing a sign of life.
>
> Gertjan, this patch breaks rx on my 305x SoC device. See inline comments for
> more details.
Antonio, did that patch also break rx on your PCI device with rt2872?
If not I'm going to enable this code only on SOC devices.
Thanks,
Helmut
> [...]
>
> > @@ -1643,18 +1653,12 @@ int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
> > {
> > u8 rfcsr;
> > u8 bbp;
> > + u32 reg;
> > + u16 eeprom;
> >
> > - if (rt2x00_is_usb(rt2x00dev) &&
> > - !rt2x00_rt_rev(rt2x00dev, RT3070, REV_RT3070E))
> > + if (!rt2x00_rt(rt2x00dev, RT3070))
> > return 0;
> >
> > - if (rt2x00_is_pci(rt2x00dev) || rt2x00_is_soc(rt2x00dev)) {
> > - if (!rt2x00_rf(rt2x00dev, RF3020) &&
> > - !rt2x00_rf(rt2x00dev, RF3021) &&
> > - !rt2x00_rf(rt2x00dev, RF3022))
> > - return 0;
> > - }
>
> Any reason why you've removed this part? The following code was executed on
> pci and soc devices when they had an 3020, 3021 or 3022 rf.
>
> > /*
> > * Init RF calibration.
> > */
> > @@ -1665,13 +1669,13 @@ int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
> > rt2x00_set_field8(&rfcsr, RFCSR30_RF_CALIBRATION, 0);
> > rt2800_rfcsr_write(rt2x00dev, 30, rfcsr);
> >
> > - if (rt2x00_is_usb(rt2x00dev)) {
> > + if (rt2x00_rt(rt2x00dev, RT3070)) {
> > rt2800_rfcsr_write(rt2x00dev, 4, 0x40);
> > rt2800_rfcsr_write(rt2x00dev, 5, 0x03);
> > rt2800_rfcsr_write(rt2x00dev, 6, 0x02);
> > rt2800_rfcsr_write(rt2x00dev, 7, 0x70);
> > rt2800_rfcsr_write(rt2x00dev, 9, 0x0f);
> > - rt2800_rfcsr_write(rt2x00dev, 10, 0x71);
> > + rt2800_rfcsr_write(rt2x00dev, 10, 0x41);
> > rt2800_rfcsr_write(rt2x00dev, 11, 0x21);
> > rt2800_rfcsr_write(rt2x00dev, 12, 0x7b);
> > rt2800_rfcsr_write(rt2x00dev, 14, 0x90);
> > @@ -1684,48 +1688,25 @@ int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
> > rt2800_rfcsr_write(rt2x00dev, 21, 0xdb);
> > rt2800_rfcsr_write(rt2x00dev, 24, 0x16);
> > rt2800_rfcsr_write(rt2x00dev, 25, 0x01);
> > - rt2800_rfcsr_write(rt2x00dev, 27, 0x03);
> > rt2800_rfcsr_write(rt2x00dev, 29, 0x1f);
> > - } else if (rt2x00_is_pci(rt2x00dev) || rt2x00_is_soc(rt2x00dev)) {
> > - rt2800_rfcsr_write(rt2x00dev, 0, 0x50);
> > - rt2800_rfcsr_write(rt2x00dev, 1, 0x01);
> > - rt2800_rfcsr_write(rt2x00dev, 2, 0xf7);
> > - rt2800_rfcsr_write(rt2x00dev, 3, 0x75);
> > - rt2800_rfcsr_write(rt2x00dev, 4, 0x40);
> > - rt2800_rfcsr_write(rt2x00dev, 5, 0x03);
> > - rt2800_rfcsr_write(rt2x00dev, 6, 0x02);
> > - rt2800_rfcsr_write(rt2x00dev, 7, 0x50);
> > - rt2800_rfcsr_write(rt2x00dev, 8, 0x39);
> > - rt2800_rfcsr_write(rt2x00dev, 9, 0x0f);
> > - rt2800_rfcsr_write(rt2x00dev, 10, 0x60);
> > - rt2800_rfcsr_write(rt2x00dev, 11, 0x21);
> > - rt2800_rfcsr_write(rt2x00dev, 12, 0x75);
> > - rt2800_rfcsr_write(rt2x00dev, 13, 0x75);
> > - rt2800_rfcsr_write(rt2x00dev, 14, 0x90);
> > - rt2800_rfcsr_write(rt2x00dev, 15, 0x58);
> > - rt2800_rfcsr_write(rt2x00dev, 16, 0xb3);
> > - rt2800_rfcsr_write(rt2x00dev, 17, 0x92);
> > - rt2800_rfcsr_write(rt2x00dev, 18, 0x2c);
> > - rt2800_rfcsr_write(rt2x00dev, 19, 0x02);
> > - rt2800_rfcsr_write(rt2x00dev, 20, 0xba);
> > - rt2800_rfcsr_write(rt2x00dev, 21, 0xdb);
> > - rt2800_rfcsr_write(rt2x00dev, 22, 0x00);
> > - rt2800_rfcsr_write(rt2x00dev, 23, 0x31);
> > - rt2800_rfcsr_write(rt2x00dev, 24, 0x08);
> > - rt2800_rfcsr_write(rt2x00dev, 25, 0x01);
> > - rt2800_rfcsr_write(rt2x00dev, 26, 0x25);
> > - rt2800_rfcsr_write(rt2x00dev, 27, 0x23);
> > - rt2800_rfcsr_write(rt2x00dev, 28, 0x13);
> > - rt2800_rfcsr_write(rt2x00dev, 29, 0x83);
>
> This part is actually needed for getting rx to work on the SoC devices.
>
> Should I post a patch that adds this code again and is only executed on SoC
> devices with rf3020, 3021 and 3022?
>
> Thanks,
> Helmut
>
^ permalink raw reply
* Re: [PATCH 6/9] rt2x00: Finish rt3070 support in rt2800 register initialization.
From: Helmut Schaa @ 2010-04-26 11:11 UTC (permalink / raw)
To: Antonio Quartulli
Cc: Gertjan van Wingerde, John W. Linville, Ivo van Doorn,
linux-wireless, users, Luis Correia
In-Reply-To: <201004261302.14682.helmut.schaa@googlemail.com>
Am Montag 26 April 2010 schrieb Helmut Schaa:
> Am Sonntag 11 April 2010 schrieb Gertjan van Wingerde:
> > rt2x00 had preliminary support for RT3070 based devices, but the support was
> > incomplete.
> > Update the RT3070 register initialization to be similar to the latest Ralink
> > vendor driver.
> >
> > With this patch my rt3070 based devices start showing a sign of life.
>
> Gertjan, this patch breaks rx on my 305x SoC device. See inline comments for
> more details.
Antonio, did that patch also break rx on your PCI device with rt2872?
If not this is only needed for SoC.
Thanks,
Helmut
> [...]
>
> > @@ -1643,18 +1653,12 @@ int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
> > {
> > u8 rfcsr;
> > u8 bbp;
> > + u32 reg;
> > + u16 eeprom;
> >
> > - if (rt2x00_is_usb(rt2x00dev) &&
> > - !rt2x00_rt_rev(rt2x00dev, RT3070, REV_RT3070E))
> > + if (!rt2x00_rt(rt2x00dev, RT3070))
> > return 0;
> >
> > - if (rt2x00_is_pci(rt2x00dev) || rt2x00_is_soc(rt2x00dev)) {
> > - if (!rt2x00_rf(rt2x00dev, RF3020) &&
> > - !rt2x00_rf(rt2x00dev, RF3021) &&
> > - !rt2x00_rf(rt2x00dev, RF3022))
> > - return 0;
> > - }
>
> Any reason why you've removed this part? The following code was executed on
> pci and soc devices when they had an 3020, 3021 or 3022 rf.
>
> > /*
> > * Init RF calibration.
> > */
> > @@ -1665,13 +1669,13 @@ int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
> > rt2x00_set_field8(&rfcsr, RFCSR30_RF_CALIBRATION, 0);
> > rt2800_rfcsr_write(rt2x00dev, 30, rfcsr);
> >
> > - if (rt2x00_is_usb(rt2x00dev)) {
> > + if (rt2x00_rt(rt2x00dev, RT3070)) {
> > rt2800_rfcsr_write(rt2x00dev, 4, 0x40);
> > rt2800_rfcsr_write(rt2x00dev, 5, 0x03);
> > rt2800_rfcsr_write(rt2x00dev, 6, 0x02);
> > rt2800_rfcsr_write(rt2x00dev, 7, 0x70);
> > rt2800_rfcsr_write(rt2x00dev, 9, 0x0f);
> > - rt2800_rfcsr_write(rt2x00dev, 10, 0x71);
> > + rt2800_rfcsr_write(rt2x00dev, 10, 0x41);
> > rt2800_rfcsr_write(rt2x00dev, 11, 0x21);
> > rt2800_rfcsr_write(rt2x00dev, 12, 0x7b);
> > rt2800_rfcsr_write(rt2x00dev, 14, 0x90);
> > @@ -1684,48 +1688,25 @@ int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
> > rt2800_rfcsr_write(rt2x00dev, 21, 0xdb);
> > rt2800_rfcsr_write(rt2x00dev, 24, 0x16);
> > rt2800_rfcsr_write(rt2x00dev, 25, 0x01);
> > - rt2800_rfcsr_write(rt2x00dev, 27, 0x03);
> > rt2800_rfcsr_write(rt2x00dev, 29, 0x1f);
> > - } else if (rt2x00_is_pci(rt2x00dev) || rt2x00_is_soc(rt2x00dev)) {
> > - rt2800_rfcsr_write(rt2x00dev, 0, 0x50);
> > - rt2800_rfcsr_write(rt2x00dev, 1, 0x01);
> > - rt2800_rfcsr_write(rt2x00dev, 2, 0xf7);
> > - rt2800_rfcsr_write(rt2x00dev, 3, 0x75);
> > - rt2800_rfcsr_write(rt2x00dev, 4, 0x40);
> > - rt2800_rfcsr_write(rt2x00dev, 5, 0x03);
> > - rt2800_rfcsr_write(rt2x00dev, 6, 0x02);
> > - rt2800_rfcsr_write(rt2x00dev, 7, 0x50);
> > - rt2800_rfcsr_write(rt2x00dev, 8, 0x39);
> > - rt2800_rfcsr_write(rt2x00dev, 9, 0x0f);
> > - rt2800_rfcsr_write(rt2x00dev, 10, 0x60);
> > - rt2800_rfcsr_write(rt2x00dev, 11, 0x21);
> > - rt2800_rfcsr_write(rt2x00dev, 12, 0x75);
> > - rt2800_rfcsr_write(rt2x00dev, 13, 0x75);
> > - rt2800_rfcsr_write(rt2x00dev, 14, 0x90);
> > - rt2800_rfcsr_write(rt2x00dev, 15, 0x58);
> > - rt2800_rfcsr_write(rt2x00dev, 16, 0xb3);
> > - rt2800_rfcsr_write(rt2x00dev, 17, 0x92);
> > - rt2800_rfcsr_write(rt2x00dev, 18, 0x2c);
> > - rt2800_rfcsr_write(rt2x00dev, 19, 0x02);
> > - rt2800_rfcsr_write(rt2x00dev, 20, 0xba);
> > - rt2800_rfcsr_write(rt2x00dev, 21, 0xdb);
> > - rt2800_rfcsr_write(rt2x00dev, 22, 0x00);
> > - rt2800_rfcsr_write(rt2x00dev, 23, 0x31);
> > - rt2800_rfcsr_write(rt2x00dev, 24, 0x08);
> > - rt2800_rfcsr_write(rt2x00dev, 25, 0x01);
> > - rt2800_rfcsr_write(rt2x00dev, 26, 0x25);
> > - rt2800_rfcsr_write(rt2x00dev, 27, 0x23);
> > - rt2800_rfcsr_write(rt2x00dev, 28, 0x13);
> > - rt2800_rfcsr_write(rt2x00dev, 29, 0x83);
>
> This part is actually needed for getting rx to work on the SoC devices.
>
> Should I post a patch that adds this code again and is only executed on SoC
> devices with rf3020, 3021 and 3022?
>
> Thanks,
> Helmut
>
^ permalink raw reply
* Re: [PATCH 6/9] rt2x00: Finish rt3070 support in rt2800 register initialization.
From: Helmut Schaa @ 2010-04-26 11:02 UTC (permalink / raw)
To: Gertjan van Wingerde
Cc: John W. Linville, Ivo van Doorn, linux-wireless, users,
Luis Correia
In-Reply-To: <1270989075-2267-7-git-send-email-gwingerde@gmail.com>
Am Sonntag 11 April 2010 schrieb Gertjan van Wingerde:
> rt2x00 had preliminary support for RT3070 based devices, but the support was
> incomplete.
> Update the RT3070 register initialization to be similar to the latest Ralink
> vendor driver.
>
> With this patch my rt3070 based devices start showing a sign of life.
Gertjan, this patch breaks rx on my 305x SoC device. See inline comments for
more details.
[...]
> @@ -1643,18 +1653,12 @@ int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
> {
> u8 rfcsr;
> u8 bbp;
> + u32 reg;
> + u16 eeprom;
>
> - if (rt2x00_is_usb(rt2x00dev) &&
> - !rt2x00_rt_rev(rt2x00dev, RT3070, REV_RT3070E))
> + if (!rt2x00_rt(rt2x00dev, RT3070))
> return 0;
>
> - if (rt2x00_is_pci(rt2x00dev) || rt2x00_is_soc(rt2x00dev)) {
> - if (!rt2x00_rf(rt2x00dev, RF3020) &&
> - !rt2x00_rf(rt2x00dev, RF3021) &&
> - !rt2x00_rf(rt2x00dev, RF3022))
> - return 0;
> - }
Any reason why you've removed this part? The following code was executed on
pci and soc devices when they had an 3020, 3021 or 3022 rf.
> /*
> * Init RF calibration.
> */
> @@ -1665,13 +1669,13 @@ int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
> rt2x00_set_field8(&rfcsr, RFCSR30_RF_CALIBRATION, 0);
> rt2800_rfcsr_write(rt2x00dev, 30, rfcsr);
>
> - if (rt2x00_is_usb(rt2x00dev)) {
> + if (rt2x00_rt(rt2x00dev, RT3070)) {
> rt2800_rfcsr_write(rt2x00dev, 4, 0x40);
> rt2800_rfcsr_write(rt2x00dev, 5, 0x03);
> rt2800_rfcsr_write(rt2x00dev, 6, 0x02);
> rt2800_rfcsr_write(rt2x00dev, 7, 0x70);
> rt2800_rfcsr_write(rt2x00dev, 9, 0x0f);
> - rt2800_rfcsr_write(rt2x00dev, 10, 0x71);
> + rt2800_rfcsr_write(rt2x00dev, 10, 0x41);
> rt2800_rfcsr_write(rt2x00dev, 11, 0x21);
> rt2800_rfcsr_write(rt2x00dev, 12, 0x7b);
> rt2800_rfcsr_write(rt2x00dev, 14, 0x90);
> @@ -1684,48 +1688,25 @@ int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
> rt2800_rfcsr_write(rt2x00dev, 21, 0xdb);
> rt2800_rfcsr_write(rt2x00dev, 24, 0x16);
> rt2800_rfcsr_write(rt2x00dev, 25, 0x01);
> - rt2800_rfcsr_write(rt2x00dev, 27, 0x03);
> rt2800_rfcsr_write(rt2x00dev, 29, 0x1f);
> - } else if (rt2x00_is_pci(rt2x00dev) || rt2x00_is_soc(rt2x00dev)) {
> - rt2800_rfcsr_write(rt2x00dev, 0, 0x50);
> - rt2800_rfcsr_write(rt2x00dev, 1, 0x01);
> - rt2800_rfcsr_write(rt2x00dev, 2, 0xf7);
> - rt2800_rfcsr_write(rt2x00dev, 3, 0x75);
> - rt2800_rfcsr_write(rt2x00dev, 4, 0x40);
> - rt2800_rfcsr_write(rt2x00dev, 5, 0x03);
> - rt2800_rfcsr_write(rt2x00dev, 6, 0x02);
> - rt2800_rfcsr_write(rt2x00dev, 7, 0x50);
> - rt2800_rfcsr_write(rt2x00dev, 8, 0x39);
> - rt2800_rfcsr_write(rt2x00dev, 9, 0x0f);
> - rt2800_rfcsr_write(rt2x00dev, 10, 0x60);
> - rt2800_rfcsr_write(rt2x00dev, 11, 0x21);
> - rt2800_rfcsr_write(rt2x00dev, 12, 0x75);
> - rt2800_rfcsr_write(rt2x00dev, 13, 0x75);
> - rt2800_rfcsr_write(rt2x00dev, 14, 0x90);
> - rt2800_rfcsr_write(rt2x00dev, 15, 0x58);
> - rt2800_rfcsr_write(rt2x00dev, 16, 0xb3);
> - rt2800_rfcsr_write(rt2x00dev, 17, 0x92);
> - rt2800_rfcsr_write(rt2x00dev, 18, 0x2c);
> - rt2800_rfcsr_write(rt2x00dev, 19, 0x02);
> - rt2800_rfcsr_write(rt2x00dev, 20, 0xba);
> - rt2800_rfcsr_write(rt2x00dev, 21, 0xdb);
> - rt2800_rfcsr_write(rt2x00dev, 22, 0x00);
> - rt2800_rfcsr_write(rt2x00dev, 23, 0x31);
> - rt2800_rfcsr_write(rt2x00dev, 24, 0x08);
> - rt2800_rfcsr_write(rt2x00dev, 25, 0x01);
> - rt2800_rfcsr_write(rt2x00dev, 26, 0x25);
> - rt2800_rfcsr_write(rt2x00dev, 27, 0x23);
> - rt2800_rfcsr_write(rt2x00dev, 28, 0x13);
> - rt2800_rfcsr_write(rt2x00dev, 29, 0x83);
This part is actually needed for getting rx to work on the SoC devices.
Should I post a patch that adds this code again and is only executed on SoC
devices with rf3020, 3021 and 3022?
Thanks,
Helmut
^ permalink raw reply
* Re: [RFC PATCH 1/1] mac80211: Disable cfg80211 assoc timeout warning
From: Johannes Berg @ 2010-04-26 9:53 UTC (permalink / raw)
To: Saravanan Dhanabal; +Cc: linux-wireless
In-Reply-To: <1272275367-7532-1-git-send-email-ext-saravanan.dhanabal@nokia.com>
On Mon, 2010-04-26 at 12:49 +0300, Saravanan Dhanabal wrote:
> While the association response is queued and yet to be
> processed, if the interface goes down, ieee80211_stop
> marks work queue items as IEEE80211_WORK_ABORT. This
> creates assoc timeout warnings which are actually caused
> by if down. Those warnings could be avoided, since they
> are not beacuse of association response.
>
> This patch disables assoc timeout warnings if interface is
> not running.
I don't think this is the right fix, we just debated exactly this
problem too.
The right fix would be to make mac80211 kill the association work when
deauthentication is requested. We're testing that fix right now.
johannes
> Signed-off-by: Saravanan Dhanabal <ext-saravanan.dhanabal@nokia.com>
> ---
> net/wireless/mlme.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
> index 0855f0d..a3ab86c 100644
> --- a/net/wireless/mlme.c
> +++ b/net/wireless/mlme.c
> @@ -337,7 +337,7 @@ void cfg80211_send_assoc_timeout(struct net_device *dev, const u8 *addr)
> }
> }
>
> - WARN_ON(!done);
> + WARN_ON(netif_running(dev) && !done);
>
> wdev_unlock(wdev);
> }
^ permalink raw reply
* [RFC PATCH 1/1] mac80211: Disable cfg80211 assoc timeout warning
From: Saravanan Dhanabal @ 2010-04-26 9:49 UTC (permalink / raw)
To: linux-wireless
While the association response is queued and yet to be
processed, if the interface goes down, ieee80211_stop
marks work queue items as IEEE80211_WORK_ABORT. This
creates assoc timeout warnings which are actually caused
by if down. Those warnings could be avoided, since they
are not beacuse of association response.
This patch disables assoc timeout warnings if interface is
not running.
Signed-off-by: Saravanan Dhanabal <ext-saravanan.dhanabal@nokia.com>
---
net/wireless/mlme.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
index 0855f0d..a3ab86c 100644
--- a/net/wireless/mlme.c
+++ b/net/wireless/mlme.c
@@ -337,7 +337,7 @@ void cfg80211_send_assoc_timeout(struct net_device *dev, const u8 *addr)
}
}
- WARN_ON(!done);
+ WARN_ON(netif_running(dev) && !done);
wdev_unlock(wdev);
}
--
1.7.0
^ permalink raw reply related
* Re: [WIP] p54pci: fix resume p54 cardbus
From: Hans de Goede @ 2010-04-26 9:38 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless
In-Reply-To: <201004251525.19796.chunkeey@googlemail.com>
Hi Christian,
Thanks for working on this and thanks for CC-ing me, but I don't
understand why you're making the firmware loading asynchronous...
On 04/25/2010 03:25 PM, Christian Lamparter wrote:
> This patch tries to fix the resume freeze, which is described in
> https://bugzilla.redhat.com/show_bug.cgi?id=583623
>
> Unlike (normal) PCI cards, cardbus cards are easily removable.
> Therefore, the user might replace/remove the card while
> the system is suspended. The pcmcia subsystem takes special
> precautions to deal with such cases and un- and rebinds
> all devices on the pci-bridge during the resume process.
>
> But here's the catch: p54pci uses request_firmware
> which blocks until the filesystem is available.
> This deadlocks, because the filesystem won't
> be initialized until all pci devices are ready again.
p54pci uses request_firmware only from its probe function,
which does not get called during a suspend resume AFAIK.
And if the card was inserted during a suspend / resume. I would
not expect its driver to get loaded until the resume has completed
and udev runs again.
Hmm, I think while typing this message I just understood what you're
trying to fix. The problem could occur when the driver is already loaded
(for some reason), but not yet bound to the device as the card got
inserted during suspend. Does the probe function get called during
resume then ?
This would seem like a driver core bug to me. It should not start
binding drivers to "new" devices, until the resume is completed IMHO.
Note that the problem which I'm mostly seeing with suspend resume,
is that the card fails shortly after resume. It seems to be come up
and I can send / receive some packets and then it fails. The changes
you're making to resume where you're actually calling pci enable
on the device, and re-doing some pci config space settings might help
here (I'm currently unloading the driver before suspend and reloading
it after resume and then things work fine).
The one actual lockup I experienced in combination with suspend / resume
was before the other p54pci bug we've working on together was fixed,
as the driver was unstable at that time in general, so I'm not overly
worried about that one lockup.
Regards,
Hans
> ---
> highly experimental and possibly unstable
> ---
> diff --git a/drivers/net/wireless/p54/main.c b/drivers/net/wireless/p54/main.c
> index 7bbd9d3..810197c 100644
> --- a/drivers/net/wireless/p54/main.c
> +++ b/drivers/net/wireless/p54/main.c
> @@ -603,6 +603,8 @@ int p54_register_common(struct ieee80211_hw *dev, struct device *pdev)
> return err;
> }
>
> + priv->registered = true;
> +
> #ifdef CONFIG_P54_LEDS
> err = p54_init_leds(priv);
> if (err)
> @@ -638,6 +640,9 @@ void p54_unregister_common(struct ieee80211_hw *dev)
> {
> struct p54_common *priv = dev->priv;
>
> + if (!priv->registered)
> + return;
> +
> #ifdef CONFIG_P54_LEDS
> p54_unregister_leds(priv);
> #endif /* CONFIG_P54_LEDS */
> diff --git a/drivers/net/wireless/p54/p54.h b/drivers/net/wireless/p54/p54.h
> index 43a3b2e..850e6bb 100644
> --- a/drivers/net/wireless/p54/p54.h
> +++ b/drivers/net/wireless/p54/p54.h
> @@ -172,6 +172,7 @@ struct p54_common {
> struct sk_buff_head tx_pending;
> struct sk_buff_head tx_queue;
> struct mutex conf_mutex;
> + bool registered;
>
> /* memory management (as seen by the firmware) */
> u32 rx_start;
> diff --git a/drivers/net/wireless/p54/p54pci.c b/drivers/net/wireless/p54/p54pci.c
> index c916e46..353085d 100644
> --- a/drivers/net/wireless/p54/p54pci.c
> +++ b/drivers/net/wireless/p54/p54pci.c
> @@ -50,7 +50,6 @@ static int p54p_upload_firmware(struct ieee80211_hw *dev)
> {
> struct p54p_priv *priv = dev->priv;
> __le32 reg;
> - int err;
> __le32 *data;
> u32 remains, left, device_addr;
>
> @@ -75,11 +74,7 @@ static int p54p_upload_firmware(struct ieee80211_hw *dev)
> wmb();
>
> /* wait for the firmware to reset properly */
> - mdelay(10);
> -
> - err = p54_parse_firmware(dev, priv->firmware);
> - if (err)
> - return err;
> + mdelay(50);
>
> if (priv->common.fw_interface != FW_LM86) {
> dev_err(&priv->pdev->dev, "wrong firmware, "
> @@ -360,8 +355,12 @@ static void p54p_stop(struct ieee80211_hw *dev)
> {
> struct p54p_priv *priv = dev->priv;
> struct p54p_ring_control *ring_control = priv->ring_control;
> - unsigned int i;
> struct p54p_desc *desc;
> + unsigned int i;
> +
> + mutex_lock(&priv->mutex);
> + if (!priv->started)
> + goto out_unlock;
>
> P54P_WRITE(int_enable, cpu_to_le32(0));
> P54P_READ(int_enable);
> @@ -420,6 +419,10 @@ static void p54p_stop(struct ieee80211_hw *dev)
> }
>
> memset(ring_control, 0, sizeof(*ring_control));
> + priv->started = false;
> +
> +out_unlock:
> + mutex_unlock(&priv->mutex);
> }
>
> static int p54p_open(struct ieee80211_hw *dev)
> @@ -427,19 +430,25 @@ static int p54p_open(struct ieee80211_hw *dev)
> struct p54p_priv *priv = dev->priv;
> int err;
>
> + mutex_lock(&priv->mutex);
> + if (WARN_ON(priv->started)) {
> + err = -EBUSY;
> + goto out_unlock;
> + }
> +
> init_completion(&priv->boot_comp);
> err = request_irq(priv->pdev->irq, p54p_interrupt,
> IRQF_SHARED, "p54pci", dev);
> if (err) {
> dev_err(&priv->pdev->dev, "failed to register IRQ handler\n");
> - return err;
> + goto out_unlock;
> }
>
> memset(priv->ring_control, 0, sizeof(*priv->ring_control));
> err = p54p_upload_firmware(dev);
> if (err) {
> free_irq(priv->pdev->irq, dev);
> - return err;
> + goto out_unlock;
> }
> priv->rx_idx_data = priv->tx_idx_data = 0;
> priv->rx_idx_mgmt = priv->tx_idx_mgmt = 0;
> @@ -464,10 +473,10 @@ static int p54p_open(struct ieee80211_hw *dev)
> P54P_READ(dev_int);
>
> if (!wait_for_completion_interruptible_timeout(&priv->boot_comp, HZ)) {
> - printk(KERN_ERR "%s: Cannot boot firmware!\n",
> - wiphy_name(dev->wiphy));
> + dev_err(&priv->pdev->dev, "Cannot boot firmware!");
> p54p_stop(dev);
> - return -ETIMEDOUT;
> + err = -ETIMEDOUT;
> + goto out_unlock;
> }
>
> P54P_WRITE(int_enable, cpu_to_le32(ISL38XX_INT_IDENT_UPDATE));
> @@ -480,7 +489,78 @@ static int p54p_open(struct ieee80211_hw *dev)
> wmb();
> udelay(10);
>
> - return 0;
> + priv->started = true;
> +
> +out_unlock:
> + mutex_unlock(&priv->mutex);
> + return err;
> +}
> +
> +const static char *p54p_fws[] = { "isl3886pci", "isl3886" };
> +
> +static void p54p_fw_callback(const struct firmware *fw, void *context);
> +static int p54p_request_fw(struct p54p_priv *priv)
> +{
> +
> + if (ARRAY_SIZE(p54p_fws)<= priv->fw_idx)
> + return -ENOENT;
> +
> + return request_firmware_nowait(THIS_MODULE, 1, p54p_fws[priv->fw_idx],
> + &priv->pdev->dev, GFP_KERNEL, priv,
> + p54p_fw_callback);
> +}
> +
> +static void p54p_fw_callback(const struct firmware *fw, void *context)
> +{
> + struct p54p_priv *priv = context;
> + struct ieee80211_hw *dev = pci_get_drvdata(priv->pdev);
> + int err;
> +
> + if (!fw) {
> + dev_err(&priv->pdev->dev, "Cannot find firmware (\"%s\")",
> + p54p_fws[priv->fw_idx]);
> + priv->fw_idx++;
> +
> + err = p54p_request_fw(priv);
> + if (err)
> + goto err_out;
> +
> + return;
> + }
> +
> + priv->firmware = fw;
> +
> + err = p54_parse_firmware(dev, priv->firmware);
> + if (err) {
> + dev_err(&priv->pdev->dev, "Failed to parse firmware");
> + goto err_out;
> + }
> +
> + err = p54p_open(dev);
> + if (err)
> + goto err_out;
> + err = p54_read_eeprom(dev);
> + p54p_stop(dev);
> + if (err)
> + goto err_out;
> +
> + err = p54_register_common(dev,&priv->pdev->dev);
> + if (err)
> + goto err_out;
> +
> + return;
> +
> +err_out:
> + device_release_driver(&priv->pdev->dev);
> +}
> +
> +static void p54p_init_dev(struct pci_dev *pdev)
> +{
> + pci_set_master(pdev);
> + pci_try_set_mwi(pdev);
> +
> + pci_write_config_byte(pdev, 0x40, 0);
> + pci_write_config_byte(pdev, 0x41, 0);
> }
>
> static int __devinit p54p_probe(struct pci_dev *pdev,
> @@ -518,11 +598,7 @@ static int __devinit p54p_probe(struct pci_dev *pdev,
> goto err_free_reg;
> }
>
> - pci_set_master(pdev);
> - pci_try_set_mwi(pdev);
> -
> - pci_write_config_byte(pdev, 0x40, 0);
> - pci_write_config_byte(pdev, 0x41, 0);
> + p54p_init_dev(pdev);
>
> dev = p54_init_common(sizeof(*priv));
> if (!dev) {
> @@ -556,34 +632,16 @@ static int __devinit p54p_probe(struct pci_dev *pdev,
> priv->common.tx = p54p_tx;
>
> spin_lock_init(&priv->lock);
> + mutex_init(&priv->mutex);
> tasklet_init(&priv->tasklet, p54p_tasklet, (unsigned long)dev);
>
> - err = request_firmware(&priv->firmware, "isl3886pci",
> - &priv->pdev->dev);
> - if (err) {
> - dev_err(&pdev->dev, "Cannot find firmware (isl3886pci)\n");
> - err = request_firmware(&priv->firmware, "isl3886",
> - &priv->pdev->dev);
> - if (err)
> - goto err_free_common;
> - }
> -
> - err = p54p_open(dev);
> - if (err)
> - goto err_free_common;
> - err = p54_read_eeprom(dev);
> - p54p_stop(dev);
> - if (err)
> - goto err_free_common;
> -
> - err = p54_register_common(dev,&pdev->dev);
> + err = p54p_request_fw(priv);
> if (err)
> goto err_free_common;
>
> return 0;
>
> err_free_common:
> - release_firmware(priv->firmware);
> pci_free_consistent(pdev, sizeof(*priv->ring_control),
> priv->ring_control, priv->ring_control_dma);
>
> @@ -611,6 +669,8 @@ static void __devexit p54p_remove(struct pci_dev *pdev)
>
> p54_unregister_common(dev);
> priv = dev->priv;
> + p54p_stop(dev);
> + mutex_destroy(&priv->mutex);
> release_firmware(priv->firmware);
> pci_free_consistent(pdev, sizeof(*priv->ring_control),
> priv->ring_control, priv->ring_control_dma);
> @@ -624,32 +684,48 @@ static void __devexit p54p_remove(struct pci_dev *pdev)
> static int p54p_suspend(struct pci_dev *pdev, pm_message_t state)
> {
> struct ieee80211_hw *dev = pci_get_drvdata(pdev);
> - struct p54p_priv *priv = dev->priv;
> -
> - if (priv->common.mode != NL80211_IFTYPE_UNSPECIFIED) {
> - ieee80211_stop_queues(dev);
> - p54p_stop(dev);
> - }
>
> + p54p_stop(dev);
> pci_save_state(pdev);
> - pci_set_power_state(pdev, pci_choose_state(pdev, state));
> - return 0;
> + pci_disable_device(pdev);
> + return pci_set_power_state(pdev, pci_choose_state(pdev, state));
> }
>
> static int p54p_resume(struct pci_dev *pdev)
> {
> struct ieee80211_hw *dev = pci_get_drvdata(pdev);
> struct p54p_priv *priv = dev->priv;
> + int err;
> +
> + err = pci_set_power_state(pdev, PCI_D0);
> + if (err) {
> + dev_err(&pdev->dev, "failed to power-up device");
> + return err;
> + }
>
> - pci_set_power_state(pdev, PCI_D0);
> - pci_restore_state(pdev);
> + err = pci_enable_device(pdev);
> + if (err) {
> + dev_err(&pdev->dev, "failed to reenable device");
> + return err;
> + }
> +
> + err = pci_restore_state(pdev);
> + if (err) {
> + dev_err(&pdev->dev, "failed to restore device state");
> + return err;
> + }
> +
> + p54p_init_dev(pdev);
>
> if (priv->common.mode != NL80211_IFTYPE_UNSPECIFIED) {
> - p54p_open(dev);
> - ieee80211_wake_queues(dev);
> + err = p54p_open(dev);
> + if (err) {
> + dev_err(&pdev->dev, "failed to bring up link");
> + return err;
> + }
> }
>
> - return 0;
> + return err;
> }
> #endif /* CONFIG_PM */
>
> diff --git a/drivers/net/wireless/p54/p54pci.h b/drivers/net/wireless/p54/p54pci.h
> index 9fd822f..d4a9bdc 100644
> --- a/drivers/net/wireless/p54/p54pci.h
> +++ b/drivers/net/wireless/p54/p54pci.h
> @@ -95,7 +95,10 @@ struct p54p_priv {
> struct pci_dev *pdev;
> struct p54p_csr __iomem *map;
> struct tasklet_struct tasklet;
> + unsigned int fw_idx;
> const struct firmware *firmware;
> + bool started;
> + struct mutex mutex;
> spinlock_t lock;
> struct p54p_ring_control *ring_control;
> dma_addr_t ring_control_dma;
^ permalink raw reply
* Re: [PATCH] rt2x00: fix typo in rt2800.h
From: Ivo van Doorn @ 2010-04-26 8:21 UTC (permalink / raw)
To: Helmut Schaa; +Cc: John Linville, Gertjan van Wingerde, linux-wireless
In-Reply-To: <201004261018.08830.helmut.schaa@googlemail.com>
On Monday 26 April 2010, Helmut Schaa wrote:
> Fix a typo in a comment in rt2800.h. Instead of replacing the wrong
> hexvalue (0x171c) with the correct one (0x1718) just use the appropriate
> readable define.
>
> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
> ---
> drivers/net/wireless/rt2x00/rt2800.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800.h b/drivers/net/wireless/rt2x00/rt2800.h
> index ec89372..3492825 100644
> --- a/drivers/net/wireless/rt2x00/rt2800.h
> +++ b/drivers/net/wireless/rt2x00/rt2800.h
> @@ -107,7 +107,7 @@
> /*
> * INT_SOURCE_CSR: Interrupt source register.
> * Write one to clear corresponding bit.
> - * TX_FIFO_STATUS: FIFO Statistics is full, sw should read 0x171c
> + * TX_FIFO_STATUS: FIFO Statistics is full, sw should read TX_STA_FIFO
> */
> #define INT_SOURCE_CSR 0x0200
> #define INT_SOURCE_CSR_RXDELAYINT FIELD32(0x00000001)
^ permalink raw reply
* Re: iwl3945: Error sending REPLY_{RXON|SCAN_CMD|TX_PWR_TABLE_CMD} time out after 500ms
From: Sedat Dilek @ 2010-04-26 8:20 UTC (permalink / raw)
To: reinette chatre; +Cc: wireless, John Linville, Berg, Johannes
In-Reply-To: <1271883056.4381.1743.camel@rchatre-DESK>
Hi,
last weekend I could test a bit.
On Saturday, I tested with Linux-2.6.34-git4 and some additional
iwlwifi patches.
I used wpa_supplicant was (0.6.10-2) and wext driver.
I had only one issue with
linux-image-2.6.34-rc4-115-gdc57da3_2.6.34-rc4-115-gdc57da3.20100424~iniza.1_i386.deb
kernel:
...
/var/log/syslog.1-Apr 25 13:33:11 seduxbox wpa_supplicant[1732]: WPA:
Group rekeying completed with 00:04:0e:e4:00:3d [GTK=CCMP]
/var/log/syslog.1:Apr 25 13:59:56 seduxbox kernel: [59184.500070] No
probe response from AP 00:04:0e:e4:00:3d after 500ms, disconnecting.
/var/log/syslog.1-Apr 25 13:59:56 seduxbox kernel: [59184.505044]
cfg80211: Calling CRDA to update world regulatory domain
/var/log/syslog.1-Apr 25 13:59:56 seduxbox wpa_supplicant[1732]:
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
/var/log/syslog.1-Apr 25 13:59:57 seduxbox kernel: [59185.717331]
cfg80211: World regulatory domain updated:
/var/log/syslog.1-Apr 25 13:59:57 seduxbox kernel: [59185.717337]
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
/var/log/syslog.1-Apr 25 13:59:57 seduxbox kernel: [59185.717343]
(2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
/var/log/syslog.1-Apr 25 13:59:57 seduxbox kernel: [59185.717349]
(2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
/var/log/syslog.1-Apr 25 13:59:57 seduxbox kernel: [59185.717355]
(2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
/var/log/syslog.1-Apr 25 13:59:57 seduxbox kernel: [59185.717361]
(5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
/var/log/syslog.1-Apr 25 13:59:57 seduxbox kernel: [59185.717367]
(5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
/var/log/syslog.1-Apr 25 13:59:59 seduxbox wpa_supplicant[1732]:
Trying to associate with 00:04:0e:e4:00:3d
(SSID='g00gle-street-knows-my-SSID-and-where-I-live' freq=2442 MHz)
/var/log/syslog.1-Apr 25 13:59:59 seduxbox kernel: [59187.753888]
wlan0: authenticate with 00:04:0e:e4:00:3d (try 1)
/var/log/syslog.1-Apr 25 13:59:59 seduxbox kernel: [59187.755614]
wlan0: authenticated
/var/log/syslog.1-Apr 25 13:59:59 seduxbox kernel: [59187.755649]
wlan0: associate with 00:04:0e:e4:00:3d (try 1)
/var/log/syslog.1-Apr 25 13:59:59 seduxbox kernel: [59187.760216]
wlan0: RX AssocResp from 00:04:0e:e4:00:3d (capab=0x411 status=0
aid=1)
/var/log/syslog.1-Apr 25 13:59:59 seduxbox kernel: [59187.760221]
wlan0: associated
/var/log/syslog.1-Apr 25 13:59:59 seduxbox wpa_supplicant[1732]:
Associated with 00:04:0e:e4:00:3d
/var/log/syslog.1-Apr 25 13:59:59 seduxbox wpa_supplicant[1732]: WPA:
Key negotiation completed with 00:04:0e:e4:00:3d [PTK=CCMP GTK=CCMP]
/var/log/syslog.1-Apr 25 13:59:59 seduxbox wpa_supplicant[1732]:
CTRL-EVENT-CONNECTED - Connection to 00:04:0e:e4:00:3d completed
(reauth) [id=0 id_str=]
...
With Reinette's sanity-check patch this did not happen.
Nevertheless, it is hard for me to speak from reproducibility or even success.
I have this issue on my radar...
Flash and Linux is like fist and eye - if they come together it hurts.
Kind Regards,
- Sedat -
P.S.:
$ ls -l linux-image*2.6.34*rc4*.deb
-rw-r--r-- 1 sd sd 25436128 2010-04-24 11:20
linux-image-2.6.34-rc4-115-gdc57da3_2.6.34-rc4-115-gdc57da3.20100424~iniza.1_i386.deb
-rw-r--r-- 1 sd sd 25437636 2010-04-24 21:02
linux-image-2.6.34-rc4-115-gdc57da3-test_2.6.34-rc4-115-gdc57da3-test.20100424~iniza.2_i386.deb
[linux-image-2.6.34-rc4-115-gdc57da3_2.6.34-rc4-115-gdc57da3.20100424~iniza.1_i386.deb]
wireless-2.6/0001-iwlwifi-work-around-bogus-active-chains-detection.patch
iwlwifi-fixes-for-2.6.34/1-2-iwlwifi-fix-scan-races.patch
iwlwifi-fixes-for-2.6.34/2-2-iwlwifi-correct-6000-EEPROM-regulatory-address.patch
[linux-image-2.6.34-rc4-115-gdc57da3-test_2.6.34-rc4-115-gdc57da3-test.20100424~iniza.2_i386.deb]
wireless-2.6/0001-iwlwifi-work-around-bogus-active-chains-detection.patch
iwlwifi-fixes-for-2.6.34/1-2-iwlwifi-fix-scan-races.patch
iwlwifi-fixes-for-2.6.34/2-2-iwlwifi-correct-6000-EEPROM-regulatory-address.patch
rchatre/0001-Test-Sanity-check-by-Reinette-Chatre.patch
On Wed, Apr 21, 2010 at 10:50 PM, reinette chatre
<reinette.chatre@intel.com> wrote:
> Sedat,
>
> On Wed, 2010-04-21 at 00:06 -0700, Sedat Dilek wrote:
>> >> According to Johannes (on IRC) iwl3945 doesn't use internal scans yet
>> >> (see my patch below).
>> >> Thus, I am not sure if this needs to be fixed separately for iwl3945
>> >> and if I ran into a scan race condition here.
>> >
>> > Does this patch make any difference for you?
>> >
>>
>> Speaking of my patch "iwl3945-fix-scan-races.patch" from [3]?
>> I was guessing iwl3945 has internal scans support - is that the fact?
>> Johannes told me someone is working on it.
>
> It has some support ... but nothing that currently requests an internal
> scan.
>
>> To answer your question: Not sure, but it seems not to help.
>
> Weird.
>
>> >
>> > It does. Thank you. As a sanity check, could you please try this patch?
>> >
>>
>> In general, it would be very helpful to give some comments on what
>> this offered patch is doing.
>> Not sure, if I can test it today.
>>
>
> >From your logs I see that it is right after disconnecting from AP (after
> loosing probe responses) that the problem occurs. I see that we send QOS
> commands to the device, to which it responds, but after that you start
> to get errors. I looked at when those QOS commands are sent and they are
> sent in ieee80211_set_disassoc _after_ the queues have been disabled. I
> am not sure if that is the right thing to do and wanted to check if it
> is indeed those commands that are causing the issue. The patch I asked
> you to test modified the code to not send QOS commands after queues have
> been disabled.
>
>> By the way, might help to set one of the module-options for iwl3945?
>>
>> parm: antenna:select antenna (1=Main, 2=Aux, default 0 [both]) (int)
>> parm: swcrypto:using software crypto (default 1 [software]) (int)
>> parm: debug:debug output mask (uint)
>> parm: disable_hw_scan:disable hardware scanning (default 0) (int)
>> parm: fw_restart3945:restart firmware in case of error (int)
>>
>> Especially "fw_restart3945" in my case?
>
> It should be set by default.
>
>> On which errors it is
>> restarting firmware?
>
> Firmware errors.
>
> Reinette
>
>
>
^ permalink raw reply
* [PATCH] rt2x00: fix typo in rt2800.h
From: Helmut Schaa @ 2010-04-26 8:18 UTC (permalink / raw)
To: John Linville; +Cc: Ivo van Doorn, Gertjan van Wingerde, linux-wireless
Fix a typo in a comment in rt2800.h. Instead of replacing the wrong
hexvalue (0x171c) with the correct one (0x1718) just use the appropriate
readable define.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
---
drivers/net/wireless/rt2x00/rt2800.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800.h b/drivers/net/wireless/rt2x00/rt2800.h
index ec89372..3492825 100644
--- a/drivers/net/wireless/rt2x00/rt2800.h
+++ b/drivers/net/wireless/rt2x00/rt2800.h
@@ -107,7 +107,7 @@
/*
* INT_SOURCE_CSR: Interrupt source register.
* Write one to clear corresponding bit.
- * TX_FIFO_STATUS: FIFO Statistics is full, sw should read 0x171c
+ * TX_FIFO_STATUS: FIFO Statistics is full, sw should read TX_STA_FIFO
*/
#define INT_SOURCE_CSR 0x0200
#define INT_SOURCE_CSR_RXDELAYINT FIELD32(0x00000001)
--
1.6.4.2
^ permalink raw reply related
* Re: bug report: potential ERR_PTR dereference in iwm_debugfs_init()
From: Zhu Yi @ 2010-04-26 3:22 UTC (permalink / raw)
To: Johannes Berg
Cc: Dan Carpenter, Intel Linux Wireless,
linux-wireless@vger.kernel.org
In-Reply-To: <1272024227.17055.0.camel@jlt3.sipsolutions.net>
On Fri, 2010-04-23 at 20:03 +0800, Johannes Berg wrote:
> > The bit that was problematic in this code for me is that passing
> > ERR_PTR(-ENODEV) to debugfs_create_dir() on line 447 will cause an
> oops.
> > But, as you point out, the check on line 442 is never true because
> we
> > already established that debugfs is enabled.
>
> I don't think so. See, that function will only return -ENODEV when
> debugfs is not compiled into the kernel, and in that case the argument
> to debugfs_create_dir is never used anyway.
Yes, there won't be any kernel oops anyway. But the iwm debugfs code is
a little misleading. Dan, please feel free to send a patch to clean up
this. On the error path, either NULL or ERR_PTR(-ENODEV) (no other
errno) is returned. Since all the debugfs functions are defined as no-op
if CONFIG_DEBUG_FS is not selected, maybe we only check against NULL is
enough.
Thanks,
-yi
^ permalink raw reply
* Re: wl1251_sdio PSM
From: GNUtoo @ 2010-04-25 22:47 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1272232671.2349.25.camel@gnutoo-desktop>
> I changed added | IEEE80211_HW_SUPPORTS_PS in:
> wl->hw->flags = IEEE80211_HW_SIGNAL_DBM |
> IEEE80211_HW_NOISE_DBM;
>
> Denis.
that was the wrong fix.
The good fix(many thanks to chr_ in #linux-wireless) was to try
compat-wireless,which bringed many more power saving features according
to him.
Denis.
^ permalink raw reply
* [RFC/RFT] ssb: Avoid system hang when SPROM read fails
From: Larry Finger @ 2010-04-25 22:30 UTC (permalink / raw)
To: John W Linville, Michael Buesch; +Cc: b43-dev, linux-wireless
In kernel Bugzilla #15825, the OP reports a case of intermittent reading
of the SPROM. If such reads fail, the box hangs. Thanks to careful testing
by bugzillakernelorg@lez.ath.cx has shown that the first read of the
SPROM returns 0xFFFF with the hang happening on the next read.
The source of the read failure is still under investigation; however,
this patch does avoid the system hang.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
John,
Does this patch avoid the system hang on your box?
Larry
---
===================================================================
--- wireless-testing.orig/drivers/ssb/pci.c
+++ wireless-testing/drivers/ssb/pci.c
@@ -253,6 +253,11 @@ static int sprom_do_read(struct ssb_bus
{
int i;
+ /* Check if SPROM can be read */
+ if (ioread16(bus->mmio + SSB_SPROM_BASE) == 0xFFFF) {
+ ssb_printk(KERN_ERR PFX "Unable to read SPROM\n");
+ return -ENODEV;
+ }
for (i = 0; i < bus->sprom_size; i++)
sprom[i] = ioread16(bus->mmio + SSB_SPROM_BASE + (i * 2));
@@ -625,17 +630,23 @@ static int ssb_pci_sprom_get(struct ssb_
if (!buf)
goto out;
bus->sprom_size = SSB_SPROMSIZE_WORDS_R123;
- sprom_do_read(bus, buf);
+ err = sprom_do_read(bus, buf);
+ if (err)
+ goto out_free;
err = sprom_check_crc(buf, bus->sprom_size);
if (err) {
/* try for a 440 byte SPROM - revision 4 and higher */
kfree(buf);
buf = kcalloc(SSB_SPROMSIZE_WORDS_R4, sizeof(u16),
GFP_KERNEL);
- if (!buf)
+ if (!buf) {
+ err = -ENOMEM;
goto out;
+ }
bus->sprom_size = SSB_SPROMSIZE_WORDS_R4;
- sprom_do_read(bus, buf);
+ err = sprom_do_read(bus, buf);
+ if (err)
+ goto out_free;
err = sprom_check_crc(buf, bus->sprom_size);
if (err) {
/* All CRC attempts failed.
^ permalink raw reply
* Re: wl1251_sdio PSM
From: GNUtoo @ 2010-04-25 21:57 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1272230300.2349.23.camel@gnutoo-desktop>
On Sun, 2010-04-25 at 23:18 +0200, GNUtoo wrote:
> Hi,
> We are trying to make the htc dream(also known as G1) android phone
> usable with a standard GNU(non android) userland.
>
> Inside the htcdream there is a wl1251_sdio chip.
>
> We already use the wl1251_sdio driver with a special module for
> initialization.
>
> The problem is that When the wifi is on,the battery last for about an
> hour.
>
> So we definitely need power saving features like PSM(I hope I used the
> right acronym,I'm looking for the system which makes the access point
> buffer frames for the phone and then we request the frames,other power
> saving mode are also welcome but as I understood this one is the most
> important)
>
> Grepping for psm in the driver show that there is some sort of support
> for PSM.
>
> Unfortunately the following method of activation failed:
>
> # ./iw dev wlan0 set power_save on
> command failed: Operation not supported (-95)
>
>
> # iwconfig wlan0 power period 2
> Error for wireless request "Set Power Management" (8B2C) :
> invalid argument "2".
>
> and I didn't find a psm sys node.
>
> I wonder where it has been disabled,and if I can re-enable it.
>
> I was also told that most driver have psm disabled,I don't know the
> reason tough(maybe performance,as it has a serious impact on
> performance)
>
> our (bad quality)kenrel tree can be found here(we're not yet kernel
> hackers):
iwconfig wlan0 power on now works
I wonder if it really does something tough,I will test
I changed added | IEEE80211_HW_SUPPORTS_PS in:
wl->hw->flags = IEEE80211_HW_SIGNAL_DBM |
IEEE80211_HW_NOISE_DBM;
Denis.
^ 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