* Re: b43 with 14e4 gives DMA error
From: Thomas Wiecki @ 2009-11-02 13:57 UTC (permalink / raw)
To: Gábor Stefanik; +Cc: linux-wireless
In-Reply-To: <69e28c910911020326m67797910ub1df048d8dd3eb7e@mail.gmail.com>
Produces no output. I checked without the grep and it is only listed as Dell...
2009/11/2 Gábor Stefanik <netrolller.3d@gmail.com>:
> 2009/11/1 Thomas Wiecki <thomas.wiecki@googlemail.com>:
>> I did:
>>
>> service acpid stop
>> service acpi-support stop
>> (and service dell-laptop stop)
>>
>> processor was not loaded (I didn't blacklist it though).
>>
>> Still, after a minute of using the card, DMA errors occured.
>>
>> BIOS: It wouldn't tell me anything besides A11. It says to be a DELL
>> bios (do they make their own bioses or just rebrand them?).
>
> Dell is infamous for rebranding 3rd-party BIOSes; run this to find out
> if it's actually Phoenix:
> dmidecode | grep -i phoenix
>
> This should output a line on PhoenixBIOS & Phoenix AwardBIOS, but
> nothing on other BIOSes - post the exact output here to see if it's
> Phoenix or Award.
>
>>
>> 2009/11/1 Gábor Stefanik <netrolller.3d@gmail.com>:
>>> On Sun, Nov 1, 2009 at 1:51 PM, Thomas Wiecki
>>> <thomas.wiecki@googlemail.com> wrote:
>>>> 0c:00.0 Network controller [0280]: Broadcom Corporation BCM4312
>>>> 802.11b/g [14e4:4315] (rev 01)
>>>> Subsystem: Dell Device [1028:000c]
>>>> Flags: bus master, fast devsel, latency 0, IRQ 17
>>>> Memory at f1ffc000 (64-bit, non-prefetchable) [size=16K]
>>>> Capabilities: <access denied>
>>>> Kernel driver in use: wl
>>>> Kernel modules: wl, ssb
>>>>
>>>> A variable delay after loading the most recent b43 driver I get a lot
>>>> of (I hope last nights patches would have fixed the problems, but they
>>>> didn't):
>>>> [ 6895.111946] b43-phy0 ERROR: Fatal DMA error: 0x00000800,
>>>> 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000
>>>> [ 6895.111955] b43-phy0: Controller RESET (DMA error) ...
>>>> [ 6895.336490] b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
>>>> [ 6900.841372] b43-phy0: Controller restarted
>>>>
>>>> After installing the driver for the first time, I have a few minutes I
>>>> can use the wifi card, after that the DMA errors start to occur. Once
>>>> they occured after the first loading, they appear immediatly after
>>>> each loading.
>>>>
>>>> Ubuntu 9.04 (most recent) with kernel 2.6.31-14-generic
>>>>
>>>> Laptop is Dell E6500.
>>>> --
>>>> 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
>>>>
>>>
>>> Does noacpi/noapic or blacklisting module "processor" have any effect on this?
>>>
>>> Also, is this on PhoenixBIOS?
>>>
>>> --
>>> Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
>>>
>>
>
>
>
> --
> Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
>
^ permalink raw reply
* RE: [PATCH] libertas: remove internal buffers from GSPI driver
From: George Shore @ 2009-11-02 13:59 UTC (permalink / raw)
To: Andrey Yurovsky, Dan Williams; +Cc: linux-wireless, libertas-dev, sebatian
In-Reply-To: <45e8e6c40910291048g2958c086oa6b7a39dbb68258f@mail.gmail.com>
Andrey,
I've been unable to fully test the WPA2 functionality - I've not got
access to a WPA2 enabled access point - however, I have had a chance to
try the PS mode while connected to a WEP access point (something I
neglected to test first time around - my apologies :-S )
After connecting to the AP, I enabled PS mode and then tried the
following commands (in order):
* iwconfig (no arguments)
This reurned the connection information, and indicated that power
namagement had been enabled;
* iwlist wlan0 scan
This gave the following in my log:
[ 741.343474] libertas: if_spi_c2h_cmd: error: response packet too
large: 4616 bytes, but maximum is 2400
[ 741.370373] libertas: if_spi_c2h_cmd: err=-22
[ 741.396573] libertas: lbs_spi_thread: got error -22
[ 741.426908] libertas: if_spi_c2h_cmd: error: response packet too
large: 4616 bytes, but maximum is 2400
[ 741.453290] libertas: if_spi_c2h_cmd: err=-22
[ 741.466275] libertas: lbs_spi_thread: got error -22
[ 743.454090] libertas: if_spi_c2h_cmd: error: response packet too
large: 4616 bytes, but maximum is 2400
[ 743.480131] libertas: if_spi_c2h_cmd: err=-22
[ 743.505172] libertas: lbs_spi_thread: got error -22
[ 747.896416] libertas: if_spi_c2h_cmd: error: response packet too
large: 4616 bytes, but maximum is 2400
[ 747.909623] libertas: if_spi_c2h_cmd: err=-22
[ 747.934910] libertas: lbs_spi_thread: got error -22
And then returned a 'Failed to read scan data : Resource temporarily
unavailable' error.
* iwconfig wlan0 power off
After the previous command, this hung with no output on the console or
log.
* iwconfig
After displaying the 'lo' entry (with no wireless extensions) this too
hung with no output on the console or log.
I apologise for not testing this functionality of the driver, our use
case for the device doesn't include power management so I didn't test it
(to be honest, I'm not sure how our usage of the device would affect any
results wrt power management - I'm still pretty new at this whole
testing and driver development gig!)
Hope this helps, and if I can get onto a WPA2 AP I'll do some more
tests,
George.
> -----Original Message-----
> From: Andrey Yurovsky [mailto:andrey@cozybit.com]
> Sent: 29 October 2009 17:49
> To: Dan Williams
> Cc: linux-wireless@vger.kernel.org; libertas-dev@lists.infradead.org;
> sebatian@breakpoint.cc; George Shore
> Subject: Re: [PATCH] libertas: remove internal buffers from GSPI
driver
>
> On Wed, Oct 28, 2009 at 10:13 AM, Dan Williams <dcbw@redhat.com>
wrote:
> > Looks OK to me, but I don't have any of the SPI hardware so when you
get
> > a Tested-by:, let me know and I'll ack.
>
> Thanks Dan, by the way the issue with WPA2 and IEEE PS is unrelated to
> this patch (that is, I can reproduce it without the patch applied) so
> we'll need to address that separately. So at this point we have:
>
> Tested-by: George Shore <george.shore@imgtec.com>
> Signed-off-by: Andrey Yurovsky <andrey@cozybit.com>
-
This message is subject to Imagination Technologies' e-mail terms: http://www.imgtec.com/e-mail.htm
Imagination Technologies Ltd is a limited company registered in England No: 1306335
Registered Office: Imagination House, Home Park Estate, Kings Langley, Hertfordshire, WD4 8LZ.
Email to and from the company may be monitored for compliance and other administrative purposes.
-
^ permalink raw reply
* Re: b43 with 14e4 gives DMA error
From: Michael Buesch @ 2009-11-02 14:22 UTC (permalink / raw)
To: Thomas Wiecki; +Cc: Gábor Stefanik, linux-wireless
In-Reply-To: <4888b8cb0911020557m226d8bccx36da7949459369f@mail.gmail.com>
Can we have a full kernel log with b43 debugging enabled, please? (CONFIG_B43_DEBUG)
--
Greetings, Michael.
^ permalink raw reply
* Re: [RFC] ath9k: fix listening to idle requests
From: Luis R. Rodriguez @ 2009-11-02 15:30 UTC (permalink / raw)
To: Vasanth Thiagarajan
Cc: Luis Rodriguez, linux-wireless@vger.kernel.org,
ath9k-devel@lists.ath9k.org
In-Reply-To: <20091102065616.GB1989@vasanth-laptop>
On Sun, Nov 01, 2009 at 10:56:19PM -0800, Vasanth Thiagarajan wrote:
> On Sat, Oct 31, 2009 at 10:59:53AM +0530, Vasanth Thiagarajan wrote:
> > On Fri, Oct 30, 2009 at 08:08:22PM +0530, Luis Rodriguez wrote:
> > > On Thu, Oct 29, 2009 at 11:33 PM, Vasanthakumar Thiagarajan
> > > <vasanth@atheros.com> wrote:
> > > > On Fri, Oct 30, 2009 at 02:22:26AM +0530, Luis Rodriguez wrote:
> > > >> The way idle configuration detection was implemented as
> > > >> busted due to the fact that it assumed the ath9k virtual wiphy,
> > > >> the aphy, would be marked as inactive if it was not used but
> > > >> it turns out an aphy is always active if its the only wiphy
> > > >> present. We need to distinguish between aphy activity and
> > > >> idleness so we now add an idle bool for the aphy and mark
> > > >> it as such based on the passed IEEE80211_CONF_CHANGE_IDLE
> > > >> from mac80211.
> > > >>
> > > >> Previous to all_wiphys_idle would never be true when using
> > > >> only one device so we never really were using
> > > >> IEEE80211_CONF_CHANGE_IDLE -- we never turned the radio
> > > >> off or on upon IEEE80211_CONF_CHANGE_IDLE changes as radio
> > > >> changes depended on all_wiphys_idle being true either to
> > > >> turn the radio on or off. Since it was always false for
> > > >> one device this code was doing nothing.
> > > >>
> > > >> Reported-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
> > > >> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> > > >> ---
> > > >>
> > > >> Vasanth, what do you think?
> > > >
> > > > Still we will have issue when bringing up a sec wiphy while the
> > > > primary wiphy is in idle state. ath9k_start() does not brought up
> > > > the newly created wiphy interface when the state of at least one
> > > > previously created interface is in ACTIVE state. Unless already
> > > > brought up interfaces are put down we hit this situation whenever
> > > > we try to bring up a new secondary wiphy interface. So with this
> > > > patch the actual h/w will remain radio disabled state even after
> > > > a new interface is in active state. We need to bring the h/w into
> > > > active state if all old interfaces are in idle state in
> > > > ath9k_start().
> > >
> > > I don't see what prevents a secondary virtual wiphy from getting the
> > > radio started -- perhaps I'm missing something. When a virtual wiphy
> > > needs to become non-idle that'll come from the mac80211 non-idle
> > > config call and that will find that one device is non-idle and hence
> > > start it.
> >
> > mac80211 will issue config() for non-idle only when the respective
> > wiphy is already put into idle state.
>
> When testing the patch I did not see this issue. The patch works
> fine. I'll debug it further to see why the issue I was expecting
> did not show up, but now this patch looks fine.
OK thanks for testing, I'll send in patch form.
Luis
^ permalink raw reply
* Re: [PATCH 14/15] iwlwifi: add SM PS support for 6x50 series
From: Guy, Wey-Yi @ 2009-11-02 15:29 UTC (permalink / raw)
To: Johannes Berg
Cc: Chatre, Reinette, linville@tuxdriver.com,
linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net
In-Reply-To: <1257017010.3555.139.camel@johannes.local>
On Sat, 2009-10-31 at 12:23 -0700, Johannes Berg wrote:
> On Sat, 2009-10-31 at 10:44 -0700, Guy, Wey-Yi wrote:
>
> > > > ht_info->cap |= IEEE80211_HT_CAP_SGI_20;
> > > > - ht_info->cap |= (IEEE80211_HT_CAP_SM_PS &
> > > > - (WLAN_HT_CAP_SM_PS_DISABLED << 2));
> > > > + if (priv->cfg->support_sm_ps)
> > > > + ht_info->cap |= (IEEE80211_HT_CAP_SM_PS &
> > > > + (WLAN_HT_CAP_SM_PS_DYNAMIC << 2));
> > > > + else
> > > > + ht_info->cap |= (IEEE80211_HT_CAP_SM_PS &
> > > > + (WLAN_HT_CAP_SM_PS_DISABLED << 2));
> > >
> > > here we always and unconditionally advertise dynamic SM-PS mode?
> >
> > I am confuse, it is based on "priv->cfg->support_sm_ps", so it is not
> > always dynamic SM-PS mode.
>
> Right, sorry -- but here it _only_ depends on "support_sm_ps", whereas
>
> > > > + if (priv->cfg->support_sm_ps) {
> > > > + /* # Rx chains when idling and maybe trying to save power */
> > > > + switch (priv->current_ht_config.sm_ps) {
>
> Here it also depends on current_ht_config.sm_ps, which is not very
> useful. Using the AP setting is wrong, and above, assuming
> "support_sm_ps" [1] is true, this should just always fall into the
> dynamic case so the value "current_ht_config.sm_ps" isn't useful and can
> imho be removed.
Right, I already fix it and not reference to AP's setting. Thanks
>
> [1] which btw I'd have called "use_sm_ps" since all hardware supports it
> afaik
That is a good point. On the other hand, I think it will make more sense
shoice the sm_ps mode in priv->conf instead of just a boolean value of
"use" or "not" use.
I will submit another patch to fix this.
^ permalink raw reply
* Re: [PATCH] mac80211: Fix IBSS merge
From: John W. Linville @ 2009-11-02 15:36 UTC (permalink / raw)
To: Johannes Berg; +Cc: Sujith, linux-wireless
In-Reply-To: <1257151486.3555.161.camel@johannes.local>
On Mon, Nov 02, 2009 at 09:44:46AM +0100, Johannes Berg wrote:
> On Mon, 2009-11-02 at 12:33 +0530, Sujith wrote:
> > Currently, in IBSS mode, a single creator would go into
> > a loop trying to merge/scan. This happens because the IBSS timer is
> > rearmed on finishing a scan and the subsequent
> > timer invocation requests another scan immediately.
> >
> > This patch fixes this issue by checking if we have just completed
> > a scan run trying to merge with other IBSS networks.
>
> Heh, how many people do we need to fix IBSS? :)
Yeah, no kidding...I suspect that actual IBSS users are few, and a
substantial number of those are doing crazy things with it! :-)
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Discrepancy when using old version of wpa_supplicant and git version
From: Luis R. Rodriguez @ 2009-11-02 16:02 UTC (permalink / raw)
To: Andrej Podzimek
Cc: Luis R. Rodriguez, ath9k-devel@lists.ath9k.org, linux-wireless
Renaming thread and moving this particular topic to linux-wireless.
Andrej, you reported some major frequent disconnect issues with ath9k. You
noticed TX hang issue from an upgrade from 2.6.29 to 2.6.30. You indicated
that when you ping flood you get your connection back.
Your card is an AR5416 MAC/BB Rev:2 AR2122 RF Rev:81.
You noted your disconnect issues appear even with the latest compat-wireless
drivers as:
wlan0: deauthenticating from 00:23:f8:22:aa:a6 by local choice (reason=3)
wlan0: direct probe to AP 00:23:f8:22:aa:a6 (try 1)
wlan0: deauthenticating from 00:23:f8:22:aa:a6 by local choice (reason=3)
wlan0: deauthenticating from 00:23:f8:22:aa:a6 by local choice (reason=3)
wlan0: direct probe to AP 00:23:f8:22:aa:a6 (try 1)
wlan0: direct probe responded
wlan0: authenticate with AP 00:23:f8:22:aa:a6 (try 1)
wlan0: authenticated
wlan0: associate with AP 00:23:f8:22:aa:a6 (try 1)
wlan0: RX AssocResp from 00:23:f8:22:aa:a6 (capab=0x431 status=0 aid=2)
wlan0: associated
You noted you tried connecting to 4 different APs but are only sure
of the model of one of them:
* Zyxel NBG-420N. It's set to WPA2 with EAP-TLS authentication
The other three (or more) APs are enterprise-class devices that form a
big network with roaming inside a university building. Zyxel NBG-420N supports
802.11n, whereas all the other APs only support 802.11g.
I then suggested for kicks to just try the latest version of wpa_supplicant
from git -- you tried it and it seems to have resolved your random
disconnects.
Your current pending issue is what seems to be a TX hang after a period
of time. This issue is another issue which I do not want to get into
on this thread. I started this thread specifically on linux-wireless
so we can review the issue you had with an older version of wpa_supplicant.
I am curious to see what the issue was that an upgrade fixed for you.
Can you please try to re-use the old version of wpa_supplicant and while
you connect please leave a window open with:
iw event -t
If anyone has other suggestions for Andrej to test please let me know.
Luis
^ permalink raw reply
* Re: [PATCH] cfg80211: validate scan channels
From: Luis R. Rodriguez @ 2009-11-02 16:42 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, Jouni Malinen, linux-wireless
In-Reply-To: <1257165123.3555.185.camel@johannes.local>
On Mon, Nov 2, 2009 at 4:32 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> Currently it is possible to request a scan on only
> disabled channels, which could be problematic for
> some drivers. Reject such scans, and also ignore
> disabled channels that are given. This resuls in
> the scan begin/end event only including channels
> that are actually used.
>
> This makes the mac80211 check for disabled channels
> superfluous. At the same time, remove the no-IBSS
> check from mac80211 -- nothing says that we should
> not find any networks on channels that cannot be
> used for an IBSS, even when operating in IBSS mode.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Side note that this patch reminds me of.
About two days ago I noticed that if my internal card enables channel
12 as its world roaming, I connect to my AP on channel 12 (therefore
lifting the passive scan flag), and if I then connect a USB device
which disables channel 12 communication will still go on on channel 12
on the old card but the channel will still have been marked as
disabled.
I figured I'd not here that we currently can trash these types of
connections because as noted with this patch we'd disable scanning --
but we only degrade the connection, we don't do something sensible. So
when we get a chance we should force a disconnect if a channel we're
using all of a sudden becomes disabled.
Luis
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: John W. Linville @ 2009-11-02 16:46 UTC (permalink / raw)
To: Ingo Molnar
Cc: Jarek Poplawski, Johannes Berg, Bartlomiej Zolnierkiewicz,
Pekka Enberg, David Miller, linux-wireless, netdev, linux-kernel
In-Reply-To: <20091102091038.GA9044@elte.hu>
On Mon, Nov 02, 2009 at 10:10:38AM +0100, Ingo Molnar wrote:
>
> * John W. Linville <linville@tuxdriver.com> wrote:
<snip>
> > Ever since Bartlomiej decided to tear himself away from
> > drivers/staging, he has been nothing but negative -- petty, whining,
> > indignat, whatever. Just what has he done to merit any special
> > consideration here? Why should he have any sort of veto over rt2x00?
>
> I got curious, as my past experience with Bartlomiej is that he is a
> factual, reliable, knowledgable upstream driver developer interested in
> difficult pieces of code others are reluctant to touch, for whom it is
> rather atypical to get 'petty, whining, indignant'.
YMMV...
<snip>
> Bartlomiej's reply (<1255792104.3434.2.camel@johannes.local>) ignored
> the attack (gracefully) and replied to the technical portion only:
>
> | > Tell me you're kidding -- comparing 2k duplicated LOC with a driver
> | > that ships its own wifi stack?
> |
> | Why would I be?
> |
> | 1) The patch is submitted to kernel _proper_ not kernel staging so I
> | see no excuse for duplicating 2-4 KLOC and it should be fixed.
> |
> | 2) The fact that the some staging driver consists in 90% of crap
> | doesn't mean that it doesn't have some good design ideas.. (i.e.
> | abstracting chipset registers access in a discussed case)
>
> To which technical point Johannes elected not to reply. (Effectively
> conceding Bartlomiej's point as per lkml discussion rules.)
Really? "Last post wins" is the rule? I hope you are joking...
> I can understand David trusting your judgement and not wanting to get
> involved in the fine details, but having read the surrounding discussion
> i dont understand your interpretation of the events, and i dont
> understand on what basis you launched your very serious accusation, that
> he is being 'petty, whining, indignant'. Every reply from him in that
> thread is the exact opposite of that. Care to elaborate?
Despite your links, we seem to be reading different threads. I'm not
sure I can reach your conclusions even with the most generous reading
of Bartlomiej's posts and the most critical readings of _everyone_
else's.
It seems Bartlomiej has taken it personally that we don't like having
the Ralink vendor drivers in the staging tree and he has decided to be
an irritant in linux-wireless as some sort of revenge. As a bonus,
he has thrown-in some random ramblings attacking the inclusion of
Pulseaudio in Fedora and criticizing Dave's handling of the ide tree.
And worst of all he has chosen to make a big stink about whether or
not the rt2x00 family of drivers (which shares tons of code already,
BTW) is sharing enough code for his taste in drivers that are currently
under active development.
Now you have come along to defend him for whatever your reasons,
and you have chosen to act as if Bartlomiej has been ignored simply
because you don't like the responses he got. Further, you seem to
expect me to have given him some veto over a driver for which has
has contributed essentially nothing[1]. Why? Simply because he doesn't
agree with the driver maintainer's JUDGMENT CALL? Or mine? Or Dave's?
And for all his objections, he can't be bothered to offer a patch?
I can only guess as to why you are being deferential to Bartlomiej
and overlooking not only how he has treated the rest of us but also
that his technical complaint is minor. I can only ask you to consider
that maybe Bartlomiej is not so aggrieved as he claims.
John
[1] Even his bug reports and code reviews have clearly been from the
perspective of "you should just be using the staging driver".
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: John W. Linville @ 2009-11-02 17:01 UTC (permalink / raw)
To: Ingo Molnar
Cc: Johannes Berg, Jarek Poplawski, Bartlomiej Zolnierkiewicz,
Pekka Enberg, David Miller, linux-wireless, netdev, linux-kernel
In-Reply-To: <20091102100702.GA16963@elte.hu>
On Mon, Nov 02, 2009 at 11:07:02AM +0100, Ingo Molnar wrote:
>
> * Johannes Berg <johannes@sipsolutions.net> wrote:
>
> > On Mon, 2009-11-02 at 10:10 +0100, Ingo Molnar wrote:
> >
> > > So i have read the thread you and Bartlomiej referenced:
> > >
> > > http://lkml.org/lkml/2009/10/17/81
> > >
> > > ... and my understanding of that discussion is very different from
> > > yours. Here is my annotated history of the beginnings of that
> > > discussion:
> >
> > [snip]
> >
> > You shouldn't ignore all previous interaction between Bart and us --
> > which wasn't pretty: http://thread.gmane.org/gmane.linux.kernel/901892
>
> I have seen that exchange too - here's the lkml.org link for those who
> like the lkml.org format:
>
> http://lkml.org/lkml/2009/10/13/186
>
> And i can see no supporting fact here either, for the (very serious)
> accusation launched by John Linville, that Bartlomiej is 'petty,
> whining, indignant'. In my reading he is the opposite of that, even in
> this second thread you point out.
Again, you seem to be very generous to Bartlomiej and very critical of
the rest of us in your readings.
> So, no matter how much you disagree about the code and its direction,
> please either back up your assertion with specific links to a pattern of
> misbehavior or apologize for the ad-hominen attacks against Bartlomiej.
His behavior is evident in the threads you cited. How you do not
see that is a mystery.
> > Of course we were biased when he came around with that petty code
> > duplication argument, since it seemed to support only his agenda of
> > working only with the staging drivers.
>
> Why do you think that disagreeing in the past gives you the right to get
> into ad-hominens? You should concentrate on the code and on the
> technical side, not on the person making the argument.
>
> Also, why do you characterise a code duplication argument as 'petty'?
Did you actually look at the thread? Or did you simply here "code
duplication" and run with it?
> Bloat and unnecessary technical forking is the #1 enemy of Linux.
> Integrating code and infrastructure is the #1 strength of Linux.
>
> Upstream subsystems/drivers running away with their private
> implementations has its clear costs:
...which has nothing to do with the case at hand. Please do not
perpetuate this myth. If anything, your argument applies far more
to the drivers in staging that Bartlomiej has focused his attention
upon until recently.
<snip>
> [ I dont know why drivers/staging/ is even an argument here - he argued
> about the technical qualities of a new upstream driver, not about a
> staging driver. Upstream drivers are to be held to higher standards,
> _especially_ now that we can isolate not-clean-enough-yet drivers into
> drivers/staging/, without hurting users. ]
If you had been keeping-up, you would realize that Bartlomiej is upset
about our criticisms of the Ralink drivers in staging. That would seem
to be the reason he has made himself such an irritant in linux-wireless
over the past few weeks.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH] wl1271: use __dev_alloc_skb() on RX
From: Luis R. Rodriguez @ 2009-11-02 17:15 UTC (permalink / raw)
To: linville; +Cc: luciano.coelho, linux-wireless, Luis R. Rodriguez
RX is handled in a workqueue therefore allocating for GFP_ATOMIC
is overkill and not required.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Acked-by: Luciano Coelho <luciano.coelho@nokia.com>
---
drivers/net/wireless/wl12xx/wl1271_rx.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271_rx.c b/drivers/net/wireless/wl12xx/wl1271_rx.c
index 37d81ab..ca645f3 100644
--- a/drivers/net/wireless/wl12xx/wl1271_rx.c
+++ b/drivers/net/wireless/wl12xx/wl1271_rx.c
@@ -159,7 +159,7 @@ static void wl1271_rx_handle_data(struct wl1271 *wl, u32 length)
u8 *buf;
u8 beacon = 0;
- skb = dev_alloc_skb(length);
+ skb = __dev_alloc_skb(length, GFP_KERNEL);
if (!skb) {
wl1271_error("Couldn't allocate RX frame");
return;
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH] wl1271: use __dev_alloc_skb() on RX
From: Luciano Coelho @ 2009-11-02 17:16 UTC (permalink / raw)
To: ext Luis R. Rodriguez
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1257182115-31723-1-git-send-email-lrodriguez@atheros.com>
ext Luis R. Rodriguez wrote:
> RX is handled in a workqueue therefore allocating for GFP_ATOMIC
> is overkill and not required.
>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> Acked-by: Luciano Coelho <luciano.coelho@nokia.com>
> ---
Thank you very much, Luis!
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH 08/15] iwlwifi: move iwl_[un]init_drv to iwlagn
From: reinette chatre @ 2009-11-02 17:19 UTC (permalink / raw)
To: Johannes Berg
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net
In-Reply-To: <1256968603.3555.79.camel@johannes.local>
Hi Johannes,
On Fri, 2009-10-30 at 22:56 -0700, Johannes Berg wrote:
> On Fri, 2009-10-30 at 14:36 -0700, Reinette Chatre wrote:
> > From: Reinette Chatre <reinette.chatre@intel.com>
> >
> > Since iwlagn is the only user of these functions, move it to this module.
> > This results in a bit more code moving than just these functions since the
> > functions only used by them are also moved and we need to export the
> > symbols previously available to them directly.
>
> The last bit (export previously available symbols) doesn't seem to make
> sense -- if they weren't exported before then surely 3945 doesn't use
> them so they could be moved as well? Unless maybe they're used by other
> functions that _are_ used by 3945?
What happened in this patch is that I moved a function from iwlcore to
iwlagn. This function, while in iwlcore, had access to all the symbols
in iwlcore. Now that I moved the function to iwlagn I needed to make
sure all symbols needed by it was available. This resulted in me
exporting iwl_calib_free_results and iwl_init_scan_params since they are
in iwlcore and are now called by this function in iwlagn.
Reinette
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Luis Correia @ 2009-11-02 17:32 UTC (permalink / raw)
To: John W. Linville
Cc: Ingo Molnar, Johannes Berg, Jarek Poplawski,
Bartlomiej Zolnierkiewicz, Pekka Enberg, David Miller,
linux-wireless, netdev, linux-kernel
In-Reply-To: <20091102170114.GE14046@tuxdriver.com>
[huge snip]
This is going to be my last reply to this thread (even if I get to be insulted).
I'm not a coder, I'm a tester and administrator for the rt2x00 project.
I'm not happy about the current state of the rt2x00 in-kernel drivers.
I tend to agree that more could be done.
Even though I'm not a coder, I could be hipotetically responsable for
the current situation. It is my job function to motivate people to
work on the rt2x00 in-kernel drivers, but apparently I've failed here.
It's not an atitude problem, as some have suggested, it's just life.
About Bartlomiej, there is only one more thing that I'll say:
I've searched on my GMail archives and the only patch Bart has
provided so far for the rt2x00 project is this:
[PATCH] MAINTAINERS: rt2x00 list is moderated
Which, while technically correct, adds nothing to the project.
So, I will personally continue to ignore Bart's comments, regards and
rants, until he provides patches for rt2x00 that actually make the
driver better.
Luis Correia
rt2x00 project admin,
(but not writing this email as an official project statement)
^ permalink raw reply
* Re: [PATCH 08/15] iwlwifi: move iwl_[un]init_drv to iwlagn
From: Johannes Berg @ 2009-11-02 17:35 UTC (permalink / raw)
To: reinette chatre
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net
In-Reply-To: <1257182368.21134.13580.camel@rc-desk>
[-- Attachment #1: Type: text/plain, Size: 693 bytes --]
Hi Reinette,
> What happened in this patch is that I moved a function from iwlcore to
> iwlagn. This function, while in iwlcore, had access to all the symbols
> in iwlcore. Now that I moved the function to iwlagn I needed to make
> sure all symbols needed by it was available. This resulted in me
> exporting iwl_calib_free_results and iwl_init_scan_params since they are
> in iwlcore and are now called by this function in iwlagn.
Right ... but maybe iwl_uninit_drv and iwl_calib_free_results should
move to iwlagn as well? Maybe the entire iwl-calib.c file should be
linked to the iwlagn module? Anyway, I agree with moving code, but it
seems it could go further.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] mac80211: Fix IBSS merge
From: Felix Fietkau @ 2009-11-02 17:20 UTC (permalink / raw)
To: John W. Linville; +Cc: Johannes Berg, Sujith, linux-wireless
In-Reply-To: <20091102153614.GC14046@tuxdriver.com>
John W. Linville wrote:
> On Mon, Nov 02, 2009 at 09:44:46AM +0100, Johannes Berg wrote:
>> On Mon, 2009-11-02 at 12:33 +0530, Sujith wrote:
>> > Currently, in IBSS mode, a single creator would go into
>> > a loop trying to merge/scan. This happens because the IBSS timer is
>> > rearmed on finishing a scan and the subsequent
>> > timer invocation requests another scan immediately.
>> >
>> > This patch fixes this issue by checking if we have just completed
>> > a scan run trying to merge with other IBSS networks.
>>
>> Heh, how many people do we need to fix IBSS? :)
>
> Yeah, no kidding...I suspect that actual IBSS users are few, and a
> substantial number of those are doing crazy things with it! :-)
Yeah, we're doing crazy things like mesh networks of few hundred
nodes... something that 11s isn't really suitable for. :-)
- Felix
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Randy Dunlap @ 2009-11-02 17:36 UTC (permalink / raw)
To: Luis Correia
Cc: John W. Linville, Ingo Molnar, Johannes Berg, Jarek Poplawski,
Bartlomiej Zolnierkiewicz, Pekka Enberg, David Miller,
linux-wireless, netdev, linux-kernel
In-Reply-To: <efe7343f0911020932l21a570c8u9478568329d38e2c@mail.gmail.com>
Luis Correia wrote:
> [huge snip]
>
> This is going to be my last reply to this thread (even if I get to be insulted).
>
> I'm not a coder, I'm a tester and administrator for the rt2x00 project.
> I'm not happy about the current state of the rt2x00 in-kernel drivers.
> I tend to agree that more could be done.
>
> Even though I'm not a coder, I could be hipotetically responsable for
> the current situation. It is my job function to motivate people to
> work on the rt2x00 in-kernel drivers, but apparently I've failed here.
> It's not an atitude problem, as some have suggested, it's just life.
>
> About Bartlomiej, there is only one more thing that I'll say:
>
> I've searched on my GMail archives and the only patch Bart has
> provided so far for the rt2x00 project is this:
>
> [PATCH] MAINTAINERS: rt2x00 list is moderated
>
> Which, while technically correct, adds nothing to the project.
whatever. That patch still needs to be applied.
> So, I will personally continue to ignore Bart's comments, regards and
> rants, until he provides patches for rt2x00 that actually make the
> driver better.
>
> Luis Correia
> rt2x00 project admin,
> (but not writing this email as an official project statement)
--
~Randy
^ permalink raw reply
* Re: [PATCH 08/15] iwlwifi: move iwl_[un]init_drv to iwlagn
From: reinette chatre @ 2009-11-02 17:42 UTC (permalink / raw)
To: Johannes Berg
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net
In-Reply-To: <1257183329.16174.3.camel@johannes.local>
On Mon, 2009-11-02 at 09:35 -0800, Johannes Berg wrote:
> Anyway, I agree with moving code, but it
> seems it could go further.
Absolutely. I perform these cleanups as I encounter (or in this case
need) them.
Reinette
^ permalink raw reply
* Re: [PATCH] mac80211: Fix IBSS merge
From: Luis R. Rodriguez @ 2009-11-02 17:47 UTC (permalink / raw)
To: Felix Fietkau; +Cc: John W. Linville, Johannes Berg, Sujith, linux-wireless
In-Reply-To: <4AEF14E9.7060902@nbd.name>
On Mon, Nov 2, 2009 at 9:20 AM, Felix Fietkau <nbd@nbd.name> wrote:
> John W. Linville wrote:
>> On Mon, Nov 02, 2009 at 09:44:46AM +0100, Johannes Berg wrote:
>>> On Mon, 2009-11-02 at 12:33 +0530, Sujith wrote:
>>> > Currently, in IBSS mode, a single creator would go into
>>> > a loop trying to merge/scan. This happens because the IBSS timer is
>>> > rearmed on finishing a scan and the subsequent
>>> > timer invocation requests another scan immediately.
>>> >
>>> > This patch fixes this issue by checking if we have just completed
>>> > a scan run trying to merge with other IBSS networks.
>>>
>>> Heh, how many people do we need to fix IBSS? :)
>>
>> Yeah, no kidding...I suspect that actual IBSS users are few, and a
>> substantial number of those are doing crazy things with it! :-)
> Yeah, we're doing crazy things like mesh networks of few hundred
> nodes... something that 11s isn't really suitable for. :-)
Anyone know if this applies for 32?
Luis
^ permalink raw reply
* Re: linux-next: Tree for November 2 (wireless/wl1271)
From: Randy Dunlap @ 2009-11-02 18:01 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML, linux-wireless
In-Reply-To: <20091102173845.210d1c57.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20091030:
wl1271 build fails when CONFIG_INET=n.
Should this driver depend on INET?
Why does this driver, unlike all other wireless drivers,
want to use register_inetaddr_notifier()?
wl1271_main.c:(.text+0x271052): undefined reference to `unregister_inetaddr_notifier'
wl1271_main.c:(.text+0x2714d7): undefined reference to `register_inetaddr_notifier'
--
~Randy
^ permalink raw reply
* [PATCH 0/6] wl1271: some robustness improvements
From: Luciano Coelho @ 2009-11-02 18:22 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
Hi John,
Here are some more patches for the wl1271 driver. A few small issues have been fixed and some other improvements.
Cheers,
Luca.
Juuso Oikarinen (6):
wl1271: Remove excess null-data template settings
wl1271: Increase TX power value
wl1271: Check result code of commands
wl1271: Add retry implementation for PSM entries
wl1271: Correct endianness-handling of command status
wl1271: Generalize command response reading
drivers/net/wireless/wl12xx/wl1271.h | 3 +
drivers/net/wireless/wl12xx/wl1271_acx.c | 2 +-
drivers/net/wireless/wl12xx/wl1271_boot.c | 3 +-
drivers/net/wireless/wl12xx/wl1271_cmd.c | 99 ++++++++++------------------
drivers/net/wireless/wl12xx/wl1271_cmd.h | 3 +-
drivers/net/wireless/wl12xx/wl1271_conf.h | 8 ++
drivers/net/wireless/wl12xx/wl1271_event.c | 53 +++++++++++++++
drivers/net/wireless/wl12xx/wl1271_event.h | 7 ++
drivers/net/wireless/wl12xx/wl1271_init.c | 7 ++-
drivers/net/wireless/wl12xx/wl1271_main.c | 19 +++---
10 files changed, 126 insertions(+), 78 deletions(-)
^ permalink raw reply
* [PATCH 6/6] wl1271: Generalize command response reading
From: Luciano Coelho @ 2009-11-02 18:22 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Juuso Oikarinen
In-Reply-To: <1257186133-18367-1-git-send-email-luciano.coelho@nokia.com>
From: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Responses to firmware commands are read in by the command transmission
function, as part of command flow. Previously responses were read in
multiple places.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
---
drivers/net/wireless/wl12xx/wl1271_cmd.c | 67 ++++++++++++------------------
drivers/net/wireless/wl12xx/wl1271_cmd.h | 3 +-
2 files changed, 29 insertions(+), 41 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271_cmd.c b/drivers/net/wireless/wl12xx/wl1271_cmd.c
index 8acee5c..990eb01 100644
--- a/drivers/net/wireless/wl12xx/wl1271_cmd.c
+++ b/drivers/net/wireless/wl12xx/wl1271_cmd.c
@@ -42,7 +42,8 @@
* @buf: buffer containing the command, must work with dma
* @len: length of the buffer
*/
-int wl1271_cmd_send(struct wl1271 *wl, u16 id, void *buf, size_t len)
+int wl1271_cmd_send(struct wl1271 *wl, u16 id, void *buf, size_t len,
+ size_t res_len)
{
struct wl1271_cmd_header *cmd;
unsigned long timeout;
@@ -76,8 +77,9 @@ int wl1271_cmd_send(struct wl1271 *wl, u16 id, void *buf, size_t len)
}
/* read back the status code of the command */
- wl1271_spi_read(wl, wl->cmd_box_addr, cmd,
- sizeof(struct wl1271_cmd_header), false);
+ if (res_len == 0)
+ res_len = sizeof(struct wl1271_cmd_header);
+ wl1271_spi_read(wl, wl->cmd_box_addr, cmd, res_len, false);
status = le16_to_cpu(cmd->status);
if (status != CMD_STATUS_SUCCESS) {
@@ -273,7 +275,7 @@ int wl1271_cmd_join(struct wl1271 *wl)
wl->tx_security_seq_16 = 0;
wl->tx_security_seq_32 = 0;
- ret = wl1271_cmd_send(wl, CMD_START_JOIN, join, sizeof(*join));
+ ret = wl1271_cmd_send(wl, CMD_START_JOIN, join, sizeof(*join), 0);
if (ret < 0) {
wl1271_error("failed to initiate cmd join");
goto out_free;
@@ -305,30 +307,21 @@ out:
int wl1271_cmd_test(struct wl1271 *wl, void *buf, size_t buf_len, u8 answer)
{
int ret;
+ size_t res_len = 0;
wl1271_debug(DEBUG_CMD, "cmd test");
- ret = wl1271_cmd_send(wl, CMD_TEST, buf, buf_len);
+ if (answer)
+ res_len = buf_len;
+
+ ret = wl1271_cmd_send(wl, CMD_TEST, buf, buf_len, res_len);
if (ret < 0) {
wl1271_warning("TEST command failed");
return ret;
}
- if (answer) {
- struct wl1271_command *cmd_answer;
-
- /*
- * The test command got in, we can read the answer.
- * The answer would be a wl1271_command, where the
- * parameter array contains the actual answer.
- */
- wl1271_spi_read(wl, wl->cmd_box_addr, buf, buf_len, false);
-
- cmd_answer = buf;
- }
-
- return 0;
+ return ret;
}
/**
@@ -351,16 +344,10 @@ int wl1271_cmd_interrogate(struct wl1271 *wl, u16 id, void *buf, size_t len)
/* payload length, does not include any headers */
acx->len = cpu_to_le16(len - sizeof(*acx));
- ret = wl1271_cmd_send(wl, CMD_INTERROGATE, acx, sizeof(*acx));
- if (ret < 0) {
+ ret = wl1271_cmd_send(wl, CMD_INTERROGATE, acx, sizeof(*acx), len);
+ if (ret < 0)
wl1271_error("INTERROGATE command failed");
- goto out;
- }
-
- /* the interrogate command got in, we can read the answer */
- wl1271_spi_read(wl, wl->cmd_box_addr, buf, len, false);
-out:
return ret;
}
@@ -384,7 +371,7 @@ int wl1271_cmd_configure(struct wl1271 *wl, u16 id, void *buf, size_t len)
/* payload length, does not include any headers */
acx->len = cpu_to_le16(len - sizeof(*acx));
- ret = wl1271_cmd_send(wl, CMD_CONFIGURE, acx, len);
+ ret = wl1271_cmd_send(wl, CMD_CONFIGURE, acx, len, 0);
if (ret < 0) {
wl1271_warning("CONFIGURE command NOK");
return ret;
@@ -417,7 +404,7 @@ int wl1271_cmd_data_path(struct wl1271 *wl, u8 channel, bool enable)
cmd_tx = CMD_DISABLE_TX;
}
- ret = wl1271_cmd_send(wl, cmd_rx, cmd, sizeof(*cmd));
+ ret = wl1271_cmd_send(wl, cmd_rx, cmd, sizeof(*cmd), 0);
if (ret < 0) {
wl1271_error("rx %s cmd for channel %d failed",
enable ? "start" : "stop", channel);
@@ -427,7 +414,7 @@ int wl1271_cmd_data_path(struct wl1271 *wl, u8 channel, bool enable)
wl1271_debug(DEBUG_BOOT, "rx %s cmd channel %d",
enable ? "start" : "stop", channel);
- ret = wl1271_cmd_send(wl, cmd_tx, cmd, sizeof(*cmd));
+ ret = wl1271_cmd_send(wl, cmd_tx, cmd, sizeof(*cmd), 0);
if (ret < 0) {
wl1271_error("tx %s cmd for channel %d failed",
enable ? "start" : "stop", channel);
@@ -469,7 +456,7 @@ int wl1271_cmd_ps_mode(struct wl1271 *wl, u8 ps_mode)
ps_params->null_data_rate = cpu_to_le32(1); /* 1 Mbps */
ret = wl1271_cmd_send(wl, CMD_SET_PS_MODE, ps_params,
- sizeof(*ps_params));
+ sizeof(*ps_params), 0);
if (ret < 0) {
wl1271_error("cmd set_ps_mode failed");
goto out;
@@ -500,14 +487,14 @@ int wl1271_cmd_read_memory(struct wl1271 *wl, u32 addr, void *answer,
cmd->addr = cpu_to_le32(addr);
cmd->size = cpu_to_le32(len);
- ret = wl1271_cmd_send(wl, CMD_READ_MEMORY, cmd, sizeof(*cmd));
+ ret = wl1271_cmd_send(wl, CMD_READ_MEMORY, cmd, sizeof(*cmd),
+ sizeof(*cmd));
if (ret < 0) {
wl1271_error("read memory command failed: %d", ret);
goto out;
}
- /* the read command got in, we can now read the answer */
- wl1271_spi_read(wl, wl->cmd_box_addr, cmd, sizeof(*cmd), false);
+ /* the read command got in */
memcpy(answer, cmd->value, len);
out:
@@ -609,7 +596,7 @@ int wl1271_cmd_scan(struct wl1271 *wl, u8 *ssid, size_t len,
trigger->timeout = 0;
ret = wl1271_cmd_send(wl, CMD_TRIGGER_SCAN_TO, trigger,
- sizeof(*trigger));
+ sizeof(*trigger), 0);
if (ret < 0) {
wl1271_error("trigger scan to failed for hw scan");
goto out;
@@ -632,7 +619,7 @@ int wl1271_cmd_scan(struct wl1271 *wl, u8 *ssid, size_t len,
}
}
- ret = wl1271_cmd_send(wl, CMD_SCAN, params, sizeof(*params));
+ ret = wl1271_cmd_send(wl, CMD_SCAN, params, sizeof(*params), 0);
if (ret < 0) {
wl1271_error("SCAN failed");
wl->scanning = false;
@@ -670,7 +657,7 @@ int wl1271_cmd_template_set(struct wl1271 *wl, u16 template_id,
if (buf)
memcpy(cmd->template_data, buf, buf_len);
- ret = wl1271_cmd_send(wl, CMD_SET_TEMPLATE, cmd, sizeof(*cmd));
+ ret = wl1271_cmd_send(wl, CMD_SET_TEMPLATE, cmd, sizeof(*cmd), 0);
if (ret < 0) {
wl1271_warning("cmd set_template failed: %d", ret);
goto out_free;
@@ -849,7 +836,7 @@ int wl1271_cmd_set_default_wep_key(struct wl1271 *wl, u8 id)
cmd->key_action = cpu_to_le16(KEY_SET_ID);
cmd->key_type = KEY_WEP;
- ret = wl1271_cmd_send(wl, CMD_SET_KEYS, cmd, sizeof(*cmd));
+ ret = wl1271_cmd_send(wl, CMD_SET_KEYS, cmd, sizeof(*cmd), 0);
if (ret < 0) {
wl1271_warning("cmd set_default_wep_key failed: %d", ret);
goto out;
@@ -906,7 +893,7 @@ int wl1271_cmd_set_key(struct wl1271 *wl, u16 action, u8 id, u8 key_type,
wl1271_dump(DEBUG_CRYPT, "TARGET KEY: ", cmd, sizeof(*cmd));
- ret = wl1271_cmd_send(wl, CMD_SET_KEYS, cmd, sizeof(*cmd));
+ ret = wl1271_cmd_send(wl, CMD_SET_KEYS, cmd, sizeof(*cmd), 0);
if (ret < 0) {
wl1271_warning("could not set keys");
goto out;
@@ -936,7 +923,7 @@ int wl1271_cmd_disconnect(struct wl1271 *wl)
/* disconnect reason is not used in immediate disconnections */
cmd->type = DISCONNECT_IMMEDIATE;
- ret = wl1271_cmd_send(wl, CMD_DISCONNECT, cmd, sizeof(*cmd));
+ ret = wl1271_cmd_send(wl, CMD_DISCONNECT, cmd, sizeof(*cmd), 0);
if (ret < 0) {
wl1271_error("failed to send disconnect command");
goto out_free;
diff --git a/drivers/net/wireless/wl12xx/wl1271_cmd.h b/drivers/net/wireless/wl12xx/wl1271_cmd.h
index 174b820..9d7061b 100644
--- a/drivers/net/wireless/wl12xx/wl1271_cmd.h
+++ b/drivers/net/wireless/wl12xx/wl1271_cmd.h
@@ -29,7 +29,8 @@
struct acx_header;
-int wl1271_cmd_send(struct wl1271 *wl, u16 type, void *buf, size_t buf_len);
+int wl1271_cmd_send(struct wl1271 *wl, u16 id, void *buf, size_t len,
+ size_t res_len);
int wl1271_cmd_join(struct wl1271 *wl);
int wl1271_cmd_test(struct wl1271 *wl, void *buf, size_t buf_len, u8 answer);
int wl1271_cmd_interrogate(struct wl1271 *wl, u16 id, void *buf, size_t len);
--
1.5.6.5
^ permalink raw reply related
* [PATCH 5/6] wl1271: Correct endianness-handling of command status
From: Luciano Coelho @ 2009-11-02 18:22 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Juuso Oikarinen
In-Reply-To: <1257186133-18367-1-git-send-email-luciano.coelho@nokia.com>
From: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Correct the endianness-handling of the firmware command result status handling
code.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
---
drivers/net/wireless/wl12xx/wl1271_cmd.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271_cmd.c b/drivers/net/wireless/wl12xx/wl1271_cmd.c
index 46e5ea4..8acee5c 100644
--- a/drivers/net/wireless/wl12xx/wl1271_cmd.c
+++ b/drivers/net/wireless/wl12xx/wl1271_cmd.c
@@ -48,6 +48,7 @@ int wl1271_cmd_send(struct wl1271 *wl, u16 id, void *buf, size_t len)
unsigned long timeout;
u32 intr;
int ret = 0;
+ u16 status;
cmd = buf;
cmd->id = cpu_to_le16(id);
@@ -78,8 +79,9 @@ int wl1271_cmd_send(struct wl1271 *wl, u16 id, void *buf, size_t len)
wl1271_spi_read(wl, wl->cmd_box_addr, cmd,
sizeof(struct wl1271_cmd_header), false);
- if (cmd->status != CMD_STATUS_SUCCESS) {
- wl1271_error("command execute failure %d", cmd->status);
+ status = le16_to_cpu(cmd->status);
+ if (status != CMD_STATUS_SUCCESS) {
+ wl1271_error("command execute failure %d", status);
ret = -EIO;
}
--
1.5.6.5
^ permalink raw reply related
* [PATCH 4/6] wl1271: Add retry implementation for PSM entries
From: Luciano Coelho @ 2009-11-02 18:22 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Juuso Oikarinen
In-Reply-To: <1257186133-18367-1-git-send-email-luciano.coelho@nokia.com>
From: Juuso Oikarinen <juuso.oikarinen@nokia.com>
PSM entries can fail (transmitting the corresponding null-func may not
be heard by the AP.) Previously, this scenario was not detected, and
out-of-sync between STA and AP could occur.
Add retry implementation for the entries to recover from the situation.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
---
drivers/net/wireless/wl12xx/wl1271.h | 3 ++
drivers/net/wireless/wl12xx/wl1271_boot.c | 3 +-
drivers/net/wireless/wl12xx/wl1271_conf.h | 8 ++++
drivers/net/wireless/wl12xx/wl1271_event.c | 53 ++++++++++++++++++++++++++++
drivers/net/wireless/wl12xx/wl1271_event.h | 7 ++++
drivers/net/wireless/wl12xx/wl1271_main.c | 5 ++-
6 files changed, 77 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271.h b/drivers/net/wireless/wl12xx/wl1271.h
index 566f152..94359b1 100644
--- a/drivers/net/wireless/wl12xx/wl1271.h
+++ b/drivers/net/wireless/wl12xx/wl1271.h
@@ -417,6 +417,9 @@ struct wl1271 {
/* PSM mode requested */
bool psm_requested;
+ /* retry counter for PSM entries */
+ u8 psm_entry_retry;
+
/* in dBm */
int power_level;
diff --git a/drivers/net/wireless/wl12xx/wl1271_boot.c b/drivers/net/wireless/wl12xx/wl1271_boot.c
index 8678bea..b7c9645 100644
--- a/drivers/net/wireless/wl12xx/wl1271_boot.c
+++ b/drivers/net/wireless/wl12xx/wl1271_boot.c
@@ -407,7 +407,8 @@ static int wl1271_boot_run_firmware(struct wl1271 *wl)
/* unmask required mbox events */
wl->event_mask = BSS_LOSE_EVENT_ID |
- SCAN_COMPLETE_EVENT_ID;
+ SCAN_COMPLETE_EVENT_ID |
+ PS_REPORT_EVENT_ID;
ret = wl1271_event_unmask(wl);
if (ret < 0) {
diff --git a/drivers/net/wireless/wl12xx/wl1271_conf.h b/drivers/net/wireless/wl12xx/wl1271_conf.h
index 061d475..565373e 100644
--- a/drivers/net/wireless/wl12xx/wl1271_conf.h
+++ b/drivers/net/wireless/wl12xx/wl1271_conf.h
@@ -712,6 +712,14 @@ struct conf_conn_settings {
* Range 0 - 255
*/
u8 bet_max_consecutive;
+
+ /*
+ * Specifies the maximum number of times to try PSM entry if it fails
+ * (if sending the appropriate null-func message fails.)
+ *
+ * Range 0 - 255
+ */
+ u8 psm_entry_retries;
};
#define CONF_SR_ERR_TBL_MAX_VALUES 14
diff --git a/drivers/net/wireless/wl12xx/wl1271_event.c b/drivers/net/wireless/wl12xx/wl1271_event.c
index 31d396b..e135d89 100644
--- a/drivers/net/wireless/wl12xx/wl1271_event.c
+++ b/drivers/net/wireless/wl12xx/wl1271_event.c
@@ -68,6 +68,40 @@ static int wl1271_event_scan_complete(struct wl1271 *wl,
return 0;
}
+static int wl1271_event_ps_report(struct wl1271 *wl,
+ struct event_mailbox *mbox,
+ bool *beacon_loss)
+{
+ int ret = 0;
+
+ wl1271_debug(DEBUG_EVENT, "ps_status: 0x%x", mbox->ps_status);
+
+ switch (mbox->ps_status) {
+ case EVENT_ENTER_POWER_SAVE_FAIL:
+ if (wl->psm_entry_retry < wl->conf.conn.psm_entry_retries) {
+ wl->psm_entry_retry++;
+ wl1271_error("PSM entry failed, retrying %d\n",
+ wl->psm_entry_retry);
+ ret = wl1271_ps_set_mode(wl, STATION_POWER_SAVE_MODE);
+ } else {
+ wl->psm_entry_retry = 0;
+ *beacon_loss = true;
+ }
+ break;
+ case EVENT_ENTER_POWER_SAVE_SUCCESS:
+ wl->psm_entry_retry = 0;
+ break;
+ case EVENT_EXIT_POWER_SAVE_FAIL:
+ wl1271_info("PSM exit failed");
+ break;
+ case EVENT_EXIT_POWER_SAVE_SUCCESS:
+ default:
+ break;
+ }
+
+ return ret;
+}
+
static void wl1271_event_mbox_dump(struct event_mailbox *mbox)
{
wl1271_debug(DEBUG_EVENT, "MBOX DUMP:");
@@ -79,6 +113,7 @@ static int wl1271_event_process(struct wl1271 *wl, struct event_mailbox *mbox)
{
int ret;
u32 vector;
+ bool beacon_loss = false;
wl1271_event_mbox_dump(mbox);
@@ -101,7 +136,25 @@ static int wl1271_event_process(struct wl1271 *wl, struct event_mailbox *mbox)
wl1271_debug(DEBUG_EVENT, "BSS_LOSE_EVENT");
/* indicate to the stack, that beacons have been lost */
+ beacon_loss = true;
+ }
+
+ if (vector & PS_REPORT_EVENT_ID) {
+ wl1271_debug(DEBUG_EVENT, "PS_REPORT_EVENT");
+ ret = wl1271_event_ps_report(wl, mbox, &beacon_loss);
+ if (ret < 0)
+ return ret;
+ }
+
+ if (beacon_loss) {
+ /* Obviously, it's dangerous to release the mutex while
+ we are holding many of the variables in the wl struct.
+ That's why it's done last in the function, and care must
+ be taken that nothing more is done after this function
+ returns. */
+ mutex_unlock(&wl->mutex);
ieee80211_beacon_loss(wl->vif);
+ mutex_lock(&wl->mutex);
}
return 0;
diff --git a/drivers/net/wireless/wl12xx/wl1271_event.h b/drivers/net/wireless/wl12xx/wl1271_event.h
index 3ab53d3..4e3f55e 100644
--- a/drivers/net/wireless/wl12xx/wl1271_event.h
+++ b/drivers/net/wireless/wl12xx/wl1271_event.h
@@ -63,6 +63,13 @@ enum {
EVENT_MBOX_ALL_EVENT_ID = 0x7fffffff,
};
+enum {
+ EVENT_ENTER_POWER_SAVE_FAIL = 0,
+ EVENT_ENTER_POWER_SAVE_SUCCESS,
+ EVENT_EXIT_POWER_SAVE_FAIL,
+ EVENT_EXIT_POWER_SAVE_SUCCESS,
+};
+
struct event_debug_report {
u8 debug_event_id;
u8 num_params;
diff --git a/drivers/net/wireless/wl12xx/wl1271_main.c b/drivers/net/wireless/wl12xx/wl1271_main.c
index 0ae506a..d2149fc 100644
--- a/drivers/net/wireless/wl12xx/wl1271_main.c
+++ b/drivers/net/wireless/wl12xx/wl1271_main.c
@@ -222,7 +222,8 @@ static struct conf_drv_settings default_conf = {
.snr_pkt_avg_weight = 10
},
.bet_enable = CONF_BET_MODE_ENABLE,
- .bet_max_consecutive = 100
+ .bet_max_consecutive = 100,
+ .psm_entry_retries = 3
},
.init = {
.sr_err_tbl = {
@@ -973,6 +974,7 @@ static void wl1271_op_stop(struct ieee80211_hw *hw)
wl->rx_counter = 0;
wl->elp = false;
wl->psm = 0;
+ wl->psm_entry_retry = 0;
wl->tx_queue_stopped = false;
wl->power_level = WL1271_DEFAULT_POWER_LEVEL;
wl->tx_blocks_available = 0;
@@ -1822,6 +1824,7 @@ static int __devinit wl1271_probe(struct spi_device *spi)
wl->elp = false;
wl->psm = 0;
wl->psm_requested = false;
+ wl->psm_entry_retry = 0;
wl->tx_queue_stopped = false;
wl->power_level = WL1271_DEFAULT_POWER_LEVEL;
wl->basic_rate_set = WL1271_DEFAULT_BASIC_RATE_SET;
--
1.5.6.5
^ permalink raw reply related
* [PATCH 1/6] wl1271: Remove excess null-data template settings
From: Luciano Coelho @ 2009-11-02 18:22 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Juuso Oikarinen
In-Reply-To: <1257186133-18367-1-git-send-email-luciano.coelho@nokia.com>
From: Juuso Oikarinen <juuso.oikarinen@nokia.com>
The null-data template (nullfunc) is dependent on the BSSID of the
current AP only, so it needs to be updated only when the BSSID changes.
Removed excess setting of the template.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
---
drivers/net/wireless/wl12xx/wl1271_main.c | 14 +++++---------
1 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271_main.c b/drivers/net/wireless/wl12xx/wl1271_main.c
index 86132bb..0ae506a 100644
--- a/drivers/net/wireless/wl12xx/wl1271_main.c
+++ b/drivers/net/wireless/wl12xx/wl1271_main.c
@@ -1067,11 +1067,11 @@ static int wl1271_op_config_interface(struct ieee80211_hw *hw,
ret = wl1271_cmd_join(wl);
if (ret < 0)
goto out_sleep;
- }
- ret = wl1271_cmd_build_null_data(wl);
- if (ret < 0)
- goto out_sleep;
+ ret = wl1271_cmd_build_null_data(wl);
+ if (ret < 0)
+ goto out_sleep;
+ }
wl->ssid_len = conf->ssid_len;
if (wl->ssid_len)
@@ -1137,10 +1137,6 @@ static int wl1271_op_config(struct ieee80211_hw *hw, u32 changed)
wl->channel = channel;
}
- ret = wl1271_cmd_build_null_data(wl);
- if (ret < 0)
- goto out_sleep;
-
if (conf->flags & IEEE80211_CONF_PS && !wl->psm_requested) {
wl1271_info("psm enabled");
@@ -1165,7 +1161,7 @@ static int wl1271_op_config(struct ieee80211_hw *hw, u32 changed)
if (conf->power_level != wl->power_level) {
ret = wl1271_acx_tx_power(wl, conf->power_level);
if (ret < 0)
- goto out;
+ goto out_sleep;
wl->power_level = conf->power_level;
}
--
1.5.6.5
^ permalink raw reply related
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