* Re: [PATCH v2] b43: do not stack-allocate pio rx/tx header and tail buffers
From: Larry Finger @ 2009-10-07 18:01 UTC (permalink / raw)
To: Albert Herranz; +Cc: bcm43xx-dev, mb, linux-wireless
In-Reply-To: <4ACCC893.1010402@yahoo.es>
Albert Herranz wrote:
> Larry Finger wrote:
>> Albert Herranz wrote:
>
> b43_new_kidx_api() (defined in xmit.h) needs struct b43_wldev defined because it dereferences it.
> With this patch, struct b43_wl (defined in b43.h) needs struct b43_rxhdr_fw4 and struct b43_txhdr (defined in xmit.h).
>
> So we have b43_wldev -> b43_rxhdr_fw4, b43_txhdr -> b43_wl (at least).
>
> Moving the definition of struct b43_wl after the definition of struct b43_wldev and placing the inclusion of xmit.h between them gets rid of the generated dependencies.
>
> The patch hints too to other possible solution.
>
>> /*
>> * Include goes here to avoid a dependency problem.
>> * A better fix would be to integrate xmit.h into b43.h.
>> */
>> #include "xmit.h"
>
> Do you have any other solutions in mind?
No. I missed the hint. At first I thought there was a white-space
problem that caused b43_wl to be replaced. When that was not the case,
I posed my question.
All seems OK.
Larry
^ permalink raw reply
* Re: [.32-rc3] scheduler: iwlagn consistently high in "waiting for CPU"
From: Mike Galbraith @ 2009-10-07 18:10 UTC (permalink / raw)
To: Frans Pop
Cc: Arjan van de Ven, Linux Kernel Mailing List, Ingo Molnar,
Peter Zijlstra, linux-wireless
In-Reply-To: <200910071910.53907.elendil@planet.nl>
On Wed, 2009-10-07 at 19:10 +0200, Frans Pop wrote:
> On Tuesday 06 October 2009, Frans Pop wrote:
> > I've checked for 2.6.31.1 now and iwlagn is listed high there too when
> > the system is idle, but with normal values of 60-100 ms. And phy0 has
> > normal values of below 10 ms.
> > I've now rebooted with today's mainline git; phy0 now frequently shows
> > with values of around 100 ms too (i.e. higher than last time).
> >
> > Both still go way down as soon as the system is given work to do.
> >
> > With a 5 second sleep I was unable to get any significant latencies (I
> > started perf on a latencytop refresh and did a manual refresh as it
> > finished to see what happened during the perf run). The perf run does
> > seem to affect the latencies.
> > I've uploaded a chart for a 10s sleep during which I got latencies of
> > 101ms for iwlagn and 77ms for phy0:
> > http://people.debian.org/~fjp/tmp/kernel/.
>
> Mike privately sent me a script to try to capture the latencies with perf,
> but the perf output does not show any high latencies at all. It looks as if
> we may have found a bug in latencytop here instead.
Maybe. I have a little perturbation measurement proggy which I just
fired up to verify both perf and latencytop's numbers here. It's a dirt
simply cycle counter tool, which calibrates itself, sums perturbations
over a period of time and emit stats. Here, all three are in violent
agreement wrt how long "pert" is waiting for cpu.
-Mike
^ permalink raw reply
* Re: linux-next: Tree for October 7 (libertas build failure)
From: Dan Williams @ 2009-10-07 18:12 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, linux-wireless, linux-next, LKML, libertas-dev,
Holger Schurig
In-Reply-To: <20091007105210.409a1991.randy.dunlap@oracle.com>
On Wed, 2009-10-07 at 10:52 -0700, Randy Dunlap wrote:
> On Wed, 7 Oct 2009 17:35:17 +1100 Stephen Rothwell wrote:
>
> > Hi all,
> >
> > Changes since 20091006:
>
>
> drivers/built-in.o: In function `lbs_cfg_free':
> (.text+0x3479e0): undefined reference to `wiphy_unregister'
> drivers/built-in.o: In function `lbs_cfg_free':
> (.text+0x3479e7): undefined reference to `wiphy_free'
> drivers/built-in.o: In function `lbs_cfg_register':
> (.text+0x347a52): undefined reference to `wiphy_register'
> drivers/built-in.o: In function `lbs_cfg_alloc':
> (.text+0x347acf): undefined reference to `wiphy_new'
Holger, perhaps we need some Kconfig updates to select cfg80211?
Dan
^ permalink raw reply
* Re: [.32-rc3] scheduler: iwlagn consistently high in "waiting for CPU"
From: Frans Pop @ 2009-10-07 18:34 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Linux Kernel Mailing List, Ingo Molnar, Peter Zijlstra,
linux-wireless
In-Reply-To: <200910071910.53907.elendil@planet.nl>
On Wednesday 07 October 2009, Frans Pop wrote:
> On Tuesday 06 October 2009, Frans Pop wrote:
> > I've checked for 2.6.31.1 now and iwlagn is listed high there too when
> > the system is idle, but with normal values of 60-100 ms. And phy0 has
> > normal values of below 10 ms.
> > I've now rebooted with today's mainline git; phy0 now frequently shows
> > with values of around 100 ms too (i.e. higher than last time).
>
> Mike privately sent me a script to try to capture the latencies with
> perf, but the perf output does not show any high latencies at all. It
> looks as if we may have found a bug in latencytop here instead.
Not sure if it's relevant nor what it means, but I frequently see two lines
for iwlagn, e.g:
Scheduler: waiting for cpu 102.4 msec 99.7 %
. 3.3 msec 0.3 %
I get the same results with both latencytop 0.4 and 0.5.
^ permalink raw reply
* Bleeding Edge does not compile (was Re: Bleeding Edge b43 dated since 30 of september no longer working & today does not even compile.)
From: Riffer @ 2009-10-07 18:34 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <20091006211102.GC2911@tuxdriver.com>
Hello!
Thanks for your reply!
Besides the other failure mentioned after patching the version of 06th
there is a new problem with the one from today (7th of oct):
----
/home/riffer/bleeding/compat-wireless-2009-10-07/drivers/net/wireless/ath/ath5k/base.c:
In Funktion »ath5k_pci_suspend_compat«:
/home/riffer/bleeding/compat-wireless-2009-10-07/drivers/net/wireless/ath/ath5k/base.c:206:
Fehler: Inkompatibler Typ für Argument 1 von »ath5k_pci_suspend«
/home/riffer/bleeding/compat-wireless-2009-10-07/drivers/net/wireless/ath/ath5k/base.c:
In Funktion »ath5k_pci_resume_compat«:
/home/riffer/bleeding/compat-wireless-2009-10-07/drivers/net/wireless/ath/ath5k/base.c:224:
Fehler: Inkompatibler Typ für Argument 1 von »ath5k_pci_resume«
make[5]: ***
[/home/riffer/bleeding/compat-wireless-2009-10-07/drivers/net/wireless/ath/ath5k/base.o]
Fehler 1
make[4]: ***
[/home/riffer/bleeding/compat-wireless-2009-10-07/drivers/net/wireless/ath/ath5k]
Fehler 2
make[3]: ***
[/home/riffer/bleeding/compat-wireless-2009-10-07/drivers/net/wireless/ath]
Fehler 2
make[2]: ***
[/home/riffer/bleeding/compat-wireless-2009-10-07/drivers/net/wireless]
Fehler 2
make[1]: *** [_module_/home/riffer/bleeding/compat-wireless-2009-10-07]
Fehler 2
make[1]: Verlasse Verzeichnis
'/usr/src/linux-headers-2.6.30-02063006-generic'
make: *** [modules] Fehler 2
----
--
Best regards,
Riffer
^ permalink raw reply
* Re: [PATCH] b43: Fix locking problem when stopping rfkill polling
From: John W. Linville @ 2009-10-07 19:01 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless
In-Reply-To: <4accae5d.BgSJpcmlvg+W5PGM%Larry.Finger@lwfinger.net>
On Wed, Oct 07, 2009 at 10:06:05AM -0500, Larry Finger wrote:
> In commit 26e5ab35b4c7b1d4cb487a11084520aed9a8d05e entitled "b43: Fix PPC
> crash in rfkill polling on unload", the call to stop polling should not have
> been placed inside the wl->mutex. The result was incorrect locking messages.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
>
> John,
>
> I had not intended for the previous patch to be applied as I was waiting for
> the Bugzilla OP to test. He promised to do that today. In any case, that patch
> introduced a locking problem that needs to be fixed.
>
> Why do the one-liners cause so many problems?
>
> Larry
> ---
>
> Index: wireless-testing/drivers/net/wireless/b43/main.c
> ===================================================================
> --- wireless-testing.orig/drivers/net/wireless/b43/main.c
> +++ wireless-testing/drivers/net/wireless/b43/main.c
> @@ -4501,8 +4501,8 @@ static void b43_op_stop(struct ieee80211
>
> cancel_work_sync(&(wl->beacon_update_trigger));
>
> - mutex_lock(&wl->mutex);
> wiphy_rfkill_stop_polling(hw->wiphy);
> + mutex_lock(&wl->mutex);
> if (b43_status(dev) >= B43_STAT_STARTED) {
> dev = b43_wireless_core_stop(dev);
> if (!dev)
OK, but why do we start polling under the lock but stop polling without
the lock? Should we start polling without holding the lock too?
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
* NULL pointer deref at wext ioctl (Re: [PATCH] compat-2.6: adding ethtool.h to compat-2.6.31.h)
From: Hin-Tak Leung @ 2009-10-07 19:16 UTC (permalink / raw)
To: Luis R. Rodriguez, John W. Linville; +Cc: linux-wireless
On Wed, Oct 7, 2009 at 4:22 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Wed, Oct 7, 2009 at 10:45 AM, John W. Linville
> <linville@tuxdriver.com> wrote:
>> On Wed, Oct 07, 2009 at 01:40:04AM -0400, Luis R. Rodriguez wrote:
>>> On Tue, Oct 6, 2009 at 11:39 PM, Hin-Tak Leung <hintak.leung@gmail.com> wrote:
>>> > Between 2.6.30 and 2.6.31, linux/netdevice.h started
>>> > to include linux/ethtool.h (commit b1b67dd45a6b629eb41553856805aaa1614fbb83,
>>> > "net: factor out ethtool invocation of vlan/macvlan drivers"),
>>> > and commit 7508e486965b0af13984bc6d9da62a8d8f0dc5f9,
>>> > "cfg80211: add firmware and hardware version to wiphy", introduces
>>> > dependency of ETHTOOL_BUSINFO_LEN from linux/ethtool.h
>>> > to net/cfg80211.h .
>>>
>>> John's patch titled "cfg80211: fix compile error from missing
>>> ethtool.h" seems to address this upstream. I'll wait until he applies
>>> that to the tree.
>>
>> As Hin-Tak points-out, linux/netdevice.h is alreadying "doing the needful". :-)
>>
>> I'll just drop my patch and let this get sorted in compat-wireless.
>
> Heh ok applied, thanks.
>
> Luis
>
It is probably just a transient problem with recent activities - I had
a NULL pointer deref from loading rtl8187 of compat-wireless
v2.6.32-rc3-39563-g98c2609 -
BUG: unable to handle kernel NULL pointer dereference at 000000000000003d
IP: [<ffffffff8147822c>] wext_ioctl_dispatch+0xd9/0x180
PGD 61c2b067 PUD 6246f067 PMD 0
Oops: 0000 [#1] SMP
...
Call Trace:
[<ffffffff814783f5>] wext_handle_ioctl+0x4d/0x98
[<ffffffff813e53a5>] dev_ioctl+0x625/0x662
[<ffffffff813cfa45>] sock_ioctl+0x225/0x248
[<ffffffff811237a3>] vfs_ioctl+0x31/0xaa
[<ffffffff811e1801>] ? security_d_instantiate+0x37/0x4d
[<ffffffff81123c88>] do_vfs_ioctl+0x46c/0x4c3
[<ffffffff81123d44>] sys_ioctl+0x65/0x9c
[<ffffffff81012082>] system_call_fastpath+0x16/0x1b
I'm sure whatever changes made this happen will go away soon, so I'll
just re-try in a few days... but if anybody knows what commit causes
this (and what fixes it!), I'd like to know.
^ permalink raw reply
* Re: [PATCH] b43: Fix locking problem when stopping rfkill polling
From: Larry Finger @ 2009-10-07 19:28 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <20091007190106.GB22394@tuxdriver.com>
John W. Linville wrote:
> On Wed, Oct 07, 2009 at 10:06:05AM -0500, Larry Finger wrote:
>> In commit 26e5ab35b4c7b1d4cb487a11084520aed9a8d05e entitled "b43: Fix PPC
>> crash in rfkill polling on unload", the call to stop polling should not have
>> been placed inside the wl->mutex. The result was incorrect locking messages.
>>
>> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>> ---
>>
>> John,
>>
>> I had not intended for the previous patch to be applied as I was waiting for
>> the Bugzilla OP to test. He promised to do that today. In any case, that patch
>> introduced a locking problem that needs to be fixed.
>>
>> Why do the one-liners cause so many problems?
>>
>> Larry
>> ---
>>
>> Index: wireless-testing/drivers/net/wireless/b43/main.c
>> ===================================================================
>> --- wireless-testing.orig/drivers/net/wireless/b43/main.c
>> +++ wireless-testing/drivers/net/wireless/b43/main.c
>> @@ -4501,8 +4501,8 @@ static void b43_op_stop(struct ieee80211
>>
>> cancel_work_sync(&(wl->beacon_update_trigger));
>>
>> - mutex_lock(&wl->mutex);
>> wiphy_rfkill_stop_polling(hw->wiphy);
>> + mutex_lock(&wl->mutex);
>> if (b43_status(dev) >= B43_STAT_STARTED) {
>> dev = b43_wireless_core_stop(dev);
>> if (!dev)
>
> OK, but why do we start polling under the lock but stop polling without
> the lock? Should we start polling without holding the lock too?
I'll test that, but I suspect it doesn't matter. Of course, the reason
I put the stop under the lock was for symmetry, but then I got the
following when shutting down:
b43-phy0 debug: Removing Interface type 2
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.32-rc3-wl #225
-------------------------------------------------------
modprobe/25391 is trying to acquire lock:
(&(&rfkill->poll_work)->work){+.+...}, at: [<ffffffff81054a7f>]
__cancel_work_timer+0xd9/0x224
but task is already holding lock:
(&wl->mutex){+.+.+.}, at: [<ffffffffa02ff3d0>] b43_op_stop+0x30/0x7f
[b43]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&wl->mutex){+.+.+.}:
[<ffffffff81069790>] __lock_acquire+0x140e/0x174d
[<ffffffff81069b8b>] lock_acquire+0xbc/0xd9
[<ffffffff8128d420>] mutex_lock_nested+0x58/0x29c
[<ffffffffa03150ea>] b43_rfkill_poll+0x3a/0xfc [b43]
[<ffffffffa02c2f33>] ieee80211_rfkill_poll+0x26/0x28 [mac80211]
[<ffffffffa027c028>] cfg80211_rfkill_poll+0x14/0x16 [cfg80211]
[<ffffffffa0271081>] rfkill_poll+0x23/0x3d [rfkill]
[<ffffffff81054224>] worker_thread+0x22c/0x332
[<ffffffff81057fd8>] kthread+0x7d/0x85
[<ffffffff8100caba>] child_rip+0xa/0x20
Moving the stop ooutside the lock cured the problem.
Larry
^ permalink raw reply
* Re: NULL pointer deref at wext ioctl (Re: [PATCH] compat-2.6: adding ethtool.h to compat-2.6.31.h)
From: Hin-Tak Leung @ 2009-10-07 19:28 UTC (permalink / raw)
To: Luis R. Rodriguez, John W. Linville, Johannes Berg; +Cc: linux-wireless
In-Reply-To: <3ace41890910071216y69b8bc9la67b8f0ce5890cd8@mail.gmail.com>
On Wed, Oct 7, 2009 at 8:16 PM, Hin-Tak Leung <hintak.leung@gmail.com> wrote:
> It is probably just a transient problem with recent activities - I had
> a NULL pointer deref from loading rtl8187 of compat-wireless
> v2.6.32-rc3-39563-g98c2609 -
>
> BUG: unable to handle kernel NULL pointer dereference at 000000000000003d
> IP: [<ffffffff8147822c>] wext_ioctl_dispatch+0xd9/0x180
> PGD 61c2b067 PUD 6246f067 PMD 0
> Oops: 0000 [#1] SMP
> ...
> Call Trace:
> [<ffffffff814783f5>] wext_handle_ioctl+0x4d/0x98
> [<ffffffff813e53a5>] dev_ioctl+0x625/0x662
> [<ffffffff813cfa45>] sock_ioctl+0x225/0x248
> [<ffffffff811237a3>] vfs_ioctl+0x31/0xaa
> [<ffffffff811e1801>] ? security_d_instantiate+0x37/0x4d
> [<ffffffff81123c88>] do_vfs_ioctl+0x46c/0x4c3
> [<ffffffff81123d44>] sys_ioctl+0x65/0x9c
> [<ffffffff81012082>] system_call_fastpath+0x16/0x1b
>
> I'm sure whatever changes made this happen will go away soon, so I'll
> just re-try in a few days... but if anybody knows what commit causes
> this (and what fixes it!), I'd like to know.
>
Hiya, It looks like I last used compat-wireless successfully was on
25th (I am not saying it breaks after - I just haven't tried until
yesterday, possibly), and most of the recent changes are per-driver,
but there is a big code drop from Johannes dated 27th on 'wext:
refactor' . Changes from that or dependent changes?
^ permalink raw reply
* Re: [PATCH 7/7] ath5k: enable Power-Save Polls by setting the association ID
From: John W. Linville @ 2009-10-07 19:41 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <1254876274-1145-8-git-send-email-lrodriguez@atheros.com>
On Tue, Oct 06, 2009 at 08:44:34PM -0400, Luis R. Rodriguez wrote:
> mac80211 has long provided us the association ID. This isn't useful except
> for Power-Save polling which now gets enabled. We can now poll for our
> pending frames on the AP during power save.
>
> You can review the details of Power-Save on the wireless wiki:
>
> http://wireless.kernel.org/en/developers/Documentation/ieee80211/power-savings
>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Nice try, but how is this a fix? :-)
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
* Re: [PATCH] b43: Fix locking problem when stopping rfkill polling
From: Michael Buesch @ 2009-10-07 19:46 UTC (permalink / raw)
To: Larry Finger; +Cc: John W. Linville, linux-wireless
In-Reply-To: <4ACCEBE8.8010803@lwfinger.net>
On Wednesday 07 October 2009 21:28:40 Larry Finger wrote:
> John W. Linville wrote:
> > On Wed, Oct 07, 2009 at 10:06:05AM -0500, Larry Finger wrote:
> >> In commit 26e5ab35b4c7b1d4cb487a11084520aed9a8d05e entitled "b43: Fix PPC
> >> crash in rfkill polling on unload", the call to stop polling should not have
> >> been placed inside the wl->mutex. The result was incorrect locking messages.
> >>
> >> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> >> ---
> >>
> >> John,
> >>
> >> I had not intended for the previous patch to be applied as I was waiting for
> >> the Bugzilla OP to test. He promised to do that today. In any case, that patch
> >> introduced a locking problem that needs to be fixed.
> >>
> >> Why do the one-liners cause so many problems?
> >>
> >> Larry
> >> ---
> >>
> >> Index: wireless-testing/drivers/net/wireless/b43/main.c
> >> ===================================================================
> >> --- wireless-testing.orig/drivers/net/wireless/b43/main.c
> >> +++ wireless-testing/drivers/net/wireless/b43/main.c
> >> @@ -4501,8 +4501,8 @@ static void b43_op_stop(struct ieee80211
> >>
> >> cancel_work_sync(&(wl->beacon_update_trigger));
> >>
> >> - mutex_lock(&wl->mutex);
> >> wiphy_rfkill_stop_polling(hw->wiphy);
> >> + mutex_lock(&wl->mutex);
> >> if (b43_status(dev) >= B43_STAT_STARTED) {
> >> dev = b43_wireless_core_stop(dev);
> >> if (!dev)
> >
> > OK, but why do we start polling under the lock but stop polling without
> > the lock? Should we start polling without holding the lock too?
>
> I'll test that, but I suspect it doesn't matter. Of course, the reason
> I put the stop under the lock was for symmetry, but then I got the
> following when shutting down:
>
> b43-phy0 debug: Removing Interface type 2
>
> =======================================================
> [ INFO: possible circular locking dependency detected ]
> 2.6.32-rc3-wl #225
> -------------------------------------------------------
> modprobe/25391 is trying to acquire lock:
> (&(&rfkill->poll_work)->work){+.+...}, at: [<ffffffff81054a7f>]
> __cancel_work_timer+0xd9/0x224
>
> but task is already holding lock:
> (&wl->mutex){+.+.+.}, at: [<ffffffffa02ff3d0>] b43_op_stop+0x30/0x7f
> [b43]
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #1 (&wl->mutex){+.+.+.}:
> [<ffffffff81069790>] __lock_acquire+0x140e/0x174d
> [<ffffffff81069b8b>] lock_acquire+0xbc/0xd9
> [<ffffffff8128d420>] mutex_lock_nested+0x58/0x29c
> [<ffffffffa03150ea>] b43_rfkill_poll+0x3a/0xfc [b43]
> [<ffffffffa02c2f33>] ieee80211_rfkill_poll+0x26/0x28 [mac80211]
> [<ffffffffa027c028>] cfg80211_rfkill_poll+0x14/0x16 [cfg80211]
> [<ffffffffa0271081>] rfkill_poll+0x23/0x3d [rfkill]
> [<ffffffff81054224>] worker_thread+0x22c/0x332
> [<ffffffff81057fd8>] kthread+0x7d/0x85
> [<ffffffff8100caba>] child_rip+0xa/0x20
>
> Moving the stop ooutside the lock cured the problem.
>
Just move it right after the existing cancel_work_sync() call
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH 0/7] ath5k: few fixes for regressions
From: John W. Linville @ 2009-10-07 19:53 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <1254876274-1145-1-git-send-email-lrodriguez@atheros.com>
On Tue, Oct 06, 2009 at 08:44:27PM -0400, Luis R. Rodriguez wrote:
> I wasn't able to connect to some AP and it turned out the issue
> was a few regressions introduced in my series. It was hard to note
> as I was able to connect at work and at home, so I guess this would
> only have been seen with some specific APs. This series fixed my
> connection but since I introduced them I figured I'd throw in
> an extra patch at the end for setting the association ID.
>
> Luis R. Rodriguez (7):
> ath5k: fix regression on setting bssid mask on association
> ath5k: use ath_hw_setbssidmask() for bssid mask setting upon assoc
> ath5k: fix regression introduced upon the removal of AR5K_HIGH_ID()
> ath5k: simplify passed params to ath5k_hw_set_associd()
> ath5k: remove temporary low_id and high_id vars on
> ath5k_hw_set_associd()
> ath5k: fix regression which triggers an SME join upon assoc
> ath5k: enable Power-Save Polls by setting the association ID
>
> drivers/net/wireless/ath/ath5k/ath5k.h | 2 +-
> drivers/net/wireless/ath/ath5k/attach.c | 2 +-
> drivers/net/wireless/ath/ath5k/base.c | 13 ++++++++++---
> drivers/net/wireless/ath/ath5k/pcu.c | 30 +++++++++++++-----------------
> drivers/net/wireless/ath/ath5k/reset.c | 5 ++---
> 5 files changed, 27 insertions(+), 25 deletions(-)
Actually, none of these seem to apply against 2.6.32...did you mean
for them to go there?
I'll queue them for -next for now...
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 1/2] ath9k_hw: run the carrier leakage calibration fix for ar9271 as well
From: Luis R. Rodriguez @ 2009-10-07 20:22 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez
This is required for the ar9271 hardware as well.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/ath/ath9k/calib.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/calib.c b/drivers/net/wireless/ath/ath9k/calib.c
index f46bd05..7aa3d1d 100644
--- a/drivers/net/wireless/ath/ath9k/calib.c
+++ b/drivers/net/wireless/ath/ath9k/calib.c
@@ -1070,6 +1070,7 @@ bool ath9k_hw_calibrate(struct ath_hw *ah, struct ath9k_channel *chan,
}
EXPORT_SYMBOL(ath9k_hw_calibrate);
+/* Carrier leakage Calibration fix */
static bool ar9285_clc(struct ath_hw *ah, struct ath9k_channel *chan)
{
struct ath_common *common = ath9k_hw_common(ah);
@@ -1115,7 +1116,7 @@ bool ath9k_hw_init_cal(struct ath_hw *ah, struct ath9k_channel *chan)
{
struct ath_common *common = ath9k_hw_common(ah);
- if (AR_SREV_9285_12_OR_LATER(ah)) {
+ if (AR_SREV_9271(ah) || AR_SREV_9285_12_OR_LATER(ah)) {
if (!ar9285_clc(ah, chan))
return false;
} else {
--
1.6.0.4
^ permalink raw reply related
* [PATCH 2/2] ath9k_hw: run ath9k_hw_9271_pa_cal() initial calibration
From: Luis R. Rodriguez @ 2009-10-07 20:22 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <1254946939-4943-1-git-send-email-lrodriguez@atheros.com>
The PA calibration for ar9271 ath9k_hw_9271_pa_cal() can run during
reset or initial calibration, update the PA calibration to account
for that and initialize PA calibration variables for both conditions.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/ath/ath9k/calib.c | 25 ++++++++++++++++++-------
1 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/calib.c b/drivers/net/wireless/ath/ath9k/calib.c
index 7aa3d1d..551f880 100644
--- a/drivers/net/wireless/ath/ath9k/calib.c
+++ b/drivers/net/wireless/ath/ath9k/calib.c
@@ -813,7 +813,7 @@ static void ath9k_olc_temp_compensation(struct ath_hw *ah)
}
}
-static void ath9k_hw_9271_pa_cal(struct ath_hw *ah)
+static void ath9k_hw_9271_pa_cal(struct ath_hw *ah, bool is_reset)
{
u32 regVal;
unsigned int i;
@@ -889,10 +889,19 @@ static void ath9k_hw_9271_pa_cal(struct ath_hw *ah)
REG_WRITE(ah, 0x7834, regVal);
}
- /* Empirical offset correction */
-#if 0
- REG_RMW_FIELD(ah, AR9285_AN_RF2G6, AR9271_AN_RF2G6_OFFS, 0x20);
-#endif
+ regVal = (regVal >>20) & 0x7f;
+
+ /* Update PA cal info */
+ if ((!is_reset) && (ah->pacal_info.prev_offset == regVal)) {
+ if (ah->pacal_info.max_skipcount < MAX_PACAL_SKIPCOUNT)
+ ah->pacal_info.max_skipcount =
+ 2 * ah->pacal_info.max_skipcount;
+ ah->pacal_info.skipcount = ah->pacal_info.max_skipcount;
+ } else {
+ ah->pacal_info.max_skipcount = 1;
+ ah->pacal_info.skipcount = 0;
+ ah->pacal_info.prev_offset = regVal;
+ }
regVal = REG_READ(ah, 0x7834);
regVal |= 0x1;
@@ -1043,7 +1052,7 @@ bool ath9k_hw_calibrate(struct ath_hw *ah, struct ath9k_channel *chan,
if (longcal) {
/* Do periodic PAOffset Cal */
if (AR_SREV_9271(ah))
- ath9k_hw_9271_pa_cal(ah);
+ ath9k_hw_9271_pa_cal(ah, false);
else if (AR_SREV_9285_11_OR_LATER(ah)) {
if (!ah->pacal_info.skipcount)
ath9k_hw_9285_pa_cal(ah, false);
@@ -1152,7 +1161,9 @@ bool ath9k_hw_init_cal(struct ath_hw *ah, struct ath9k_channel *chan)
}
/* Do PA Calibration */
- if (AR_SREV_9285_11_OR_LATER(ah))
+ if (AR_SREV_9271(ah))
+ ath9k_hw_9271_pa_cal(ah, true);
+ else if (AR_SREV_9285_11_OR_LATER(ah))
ath9k_hw_9285_pa_cal(ah, true);
/* Do NF Calibration after DC offset and other calibrations */
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH 0/7] ath5k: few fixes for regressions
From: Luis R. Rodriguez @ 2009-10-07 20:23 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <20091007195321.GD22394@tuxdriver.com>
On Wed, Oct 7, 2009 at 3:53 PM, John W. Linville <linville@tuxdriver.com> wrote:
> On Tue, Oct 06, 2009 at 08:44:27PM -0400, Luis R. Rodriguez wrote:
>> I wasn't able to connect to some AP and it turned out the issue
>> was a few regressions introduced in my series. It was hard to note
>> as I was able to connect at work and at home, so I guess this would
>> only have been seen with some specific APs. This series fixed my
>> connection but since I introduced them I figured I'd throw in
>> an extra patch at the end for setting the association ID.
>>
>> Luis R. Rodriguez (7):
>> ath5k: fix regression on setting bssid mask on association
>> ath5k: use ath_hw_setbssidmask() for bssid mask setting upon assoc
>> ath5k: fix regression introduced upon the removal of AR5K_HIGH_ID()
>> ath5k: simplify passed params to ath5k_hw_set_associd()
>> ath5k: remove temporary low_id and high_id vars on
>> ath5k_hw_set_associd()
>> ath5k: fix regression which triggers an SME join upon assoc
>> ath5k: enable Power-Save Polls by setting the association ID
>>
>> drivers/net/wireless/ath/ath5k/ath5k.h | 2 +-
>> drivers/net/wireless/ath/ath5k/attach.c | 2 +-
>> drivers/net/wireless/ath/ath5k/base.c | 13 ++++++++++---
>> drivers/net/wireless/ath/ath5k/pcu.c | 30 +++++++++++++-----------------
>> drivers/net/wireless/ath/ath5k/reset.c | 5 ++---
>> 5 files changed, 27 insertions(+), 25 deletions(-)
>
> Actually, none of these seem to apply against 2.6.32...did you mean
> for them to go there?
>
> I'll queue them for -next for now...
Nope -- none of them are for 2.6.32 -- all of them are just for 2.6.33.
Luis
^ permalink raw reply
* Re: [PATCH 7/7] ath5k: enable Power-Save Polls by setting the association ID
From: Luis R. Rodriguez @ 2009-10-07 20:24 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <20091007194148.GC22394@tuxdriver.com>
On Wed, Oct 7, 2009 at 3:41 PM, John W. Linville <linville@tuxdriver.com> wrote:
> On Tue, Oct 06, 2009 at 08:44:34PM -0400, Luis R. Rodriguez wrote:
>> mac80211 has long provided us the association ID. This isn't useful except
>> for Power-Save polling which now gets enabled. We can now poll for our
>> pending frames on the AP during power save.
>>
>> You can review the details of Power-Save on the wireless wiki:
>>
>> http://wireless.kernel.org/en/developers/Documentation/ieee80211/power-savings
>>
>> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
>
> Nice try, but how is this a fix? :-)
It isn't -- by no means do I want this in for 2.6.32, sorry if I was
misleading. Its a regression as things *used* to work :) but yeah not
a regression for 2.6.32.
Luis
^ permalink raw reply
* Prism54/p54pci
From: James Grossmann @ 2009-10-07 21:00 UTC (permalink / raw)
To: linux-wireless
I have the gigafast WF728-AEX, which doesn't seem to work with the
p54pci drivers, I was previously using it with my Thinkpad T23 under
Gentoo (gentoo kernels 2.6.29 and 2.6.30), and could only use the
1.0.4.3 firmware, now, I am using it under Ubuntu 9.04
(2.6.28-15-generic kernel) on the same computer, and find that I have
to load the prism54 driver to make it work.
I noticed that you were considering this to be depricated, I hope that
you can help me to make p54pci work!
Thanks
James
^ permalink raw reply
* [PATCH] wireless: make WEXT_SPY and WEXT_PRIV select WEXT_CORE
From: John W. Linville @ 2009-10-07 21:07 UTC (permalink / raw)
To: linux-wireless
Cc: Randy Dunlap, Stephen Rothwell, linux-next, linux-kernel,
John W. Linville
In-Reply-To: <20091007105720.a2457e5b.randy.dunlap@oracle.com>
Should prevent this build error reported by Randy...
net/wireless/wext-priv.c:206: error: implicit declaration of function 'call_commit_handler'
make[3]: *** [net/wireless/wext-priv.o] Error 1
Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
net/wireless/Kconfig | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
index 614bdce..d3ecca3 100644
--- a/net/wireless/Kconfig
+++ b/net/wireless/Kconfig
@@ -12,9 +12,11 @@ config WEXT_PROC
config WEXT_SPY
bool
+ depends on WEXT_CORE
config WEXT_PRIV
bool
+ depends on WEXT_CORE
config CFG80211
tristate "cfg80211 - wireless configuration API"
--
1.6.2.5
^ permalink raw reply related
* [PATCH] orinoco: use cfg80211 ethtool ops
From: David Kilroy @ 2009-10-07 21:23 UTC (permalink / raw)
To: linux-wireless; +Cc: David Kilroy
Signed-off-by: David Kilroy <kilroyd@googlemail.com>
---
drivers/net/wireless/orinoco/hw.c | 33 +++++++++++++++++++++++--------
drivers/net/wireless/orinoco/hw.h | 3 +-
drivers/net/wireless/orinoco/main.c | 33 +++++--------------------------
drivers/net/wireless/orinoco/orinoco.h | 1 -
4 files changed, 32 insertions(+), 38 deletions(-)
diff --git a/drivers/net/wireless/orinoco/hw.c b/drivers/net/wireless/orinoco/hw.c
index 359652d..404830f 100644
--- a/drivers/net/wireless/orinoco/hw.c
+++ b/drivers/net/wireless/orinoco/hw.c
@@ -60,8 +60,15 @@ static inline fwtype_t determine_firmware_type(struct comp_id *nic_id)
/* Set priv->firmware type, determine firmware properties
* This function can be called before we have registerred with netdev,
* so all errors go out with dev_* rather than printk
+ *
+ * If non-NULL stores a firmware description in fw_name.
+ * If non-NULL stores a HW version in hw_ver
+ *
+ * These are output via generic cfg80211 ethtool support.
*/
-int determine_fw_capabilities(struct orinoco_private *priv)
+int determine_fw_capabilities(struct orinoco_private *priv,
+ char *fw_name, size_t fw_name_len,
+ u32 *hw_ver)
{
struct device *dev = priv->dev;
hermes_t *hw = &priv->hw;
@@ -85,6 +92,12 @@ int determine_fw_capabilities(struct orinoco_private *priv)
dev_info(dev, "Hardware identity %04x:%04x:%04x:%04x\n",
nic_id.id, nic_id.variant, nic_id.major, nic_id.minor);
+ if (hw_ver)
+ *hw_ver = (((nic_id.id & 0xff) << 24) |
+ ((nic_id.variant & 0xff) << 16) |
+ ((nic_id.major & 0xff) << 8) |
+ (nic_id.minor & 0xff));
+
priv->firmware_type = determine_firmware_type(&nic_id);
/* Get the firmware version */
@@ -135,8 +148,9 @@ int determine_fw_capabilities(struct orinoco_private *priv)
case FIRMWARE_TYPE_AGERE:
/* Lucent Wavelan IEEE, Lucent Orinoco, Cabletron RoamAbout,
ELSA, Melco, HP, IBM, Dell 1150, Compaq 110/210 */
- snprintf(priv->fw_name, sizeof(priv->fw_name) - 1,
- "Lucent/Agere %d.%02d", sta_id.major, sta_id.minor);
+ if (fw_name)
+ snprintf(fw_name, fw_name_len, "Lucent/Agere %d.%02d",
+ sta_id.major, sta_id.minor);
firmver = ((unsigned long)sta_id.major << 16) | sta_id.minor;
@@ -185,8 +199,8 @@ int determine_fw_capabilities(struct orinoco_private *priv)
tmp[SYMBOL_MAX_VER_LEN] = '\0';
}
- snprintf(priv->fw_name, sizeof(priv->fw_name) - 1,
- "Symbol %s", tmp);
+ if (fw_name)
+ snprintf(fw_name, fw_name_len, "Symbol %s", tmp);
priv->has_ibss = (firmver >= 0x20000);
priv->has_wep = (firmver >= 0x15012);
@@ -224,9 +238,9 @@ int determine_fw_capabilities(struct orinoco_private *priv)
* different and less well tested */
/* D-Link MAC : 00:40:05:* */
/* Addtron MAC : 00:90:D1:* */
- snprintf(priv->fw_name, sizeof(priv->fw_name) - 1,
- "Intersil %d.%d.%d", sta_id.major, sta_id.minor,
- sta_id.variant);
+ if (fw_name)
+ snprintf(fw_name, fw_name_len, "Intersil %d.%d.%d",
+ sta_id.major, sta_id.minor, sta_id.variant);
firmver = ((unsigned long)sta_id.major << 16) |
((unsigned long)sta_id.minor << 8) | sta_id.variant;
@@ -245,7 +259,8 @@ int determine_fw_capabilities(struct orinoco_private *priv)
}
break;
}
- dev_info(dev, "Firmware determined as %s\n", priv->fw_name);
+ if (fw_name)
+ dev_info(dev, "Firmware determined as %s\n", fw_name);
return 0;
}
diff --git a/drivers/net/wireless/orinoco/hw.h b/drivers/net/wireless/orinoco/hw.h
index 8df6e87..e2f7fdc 100644
--- a/drivers/net/wireless/orinoco/hw.h
+++ b/drivers/net/wireless/orinoco/hw.h
@@ -24,7 +24,8 @@
struct orinoco_private;
struct dev_addr_list;
-int determine_fw_capabilities(struct orinoco_private *priv);
+int determine_fw_capabilities(struct orinoco_private *priv, char *fw_name,
+ size_t fw_name_len, u32 *hw_ver);
int orinoco_hw_read_card_settings(struct orinoco_private *priv, u8 *dev_addr);
int orinoco_hw_allocate_fid(struct orinoco_private *priv);
int orinoco_get_bitratemode(int bitrate, int automatic);
diff --git a/drivers/net/wireless/orinoco/main.c b/drivers/net/wireless/orinoco/main.c
index 7a32bcb..c0c8ff6 100644
--- a/drivers/net/wireless/orinoco/main.c
+++ b/drivers/net/wireless/orinoco/main.c
@@ -83,7 +83,6 @@
#include <linux/device.h>
#include <linux/netdevice.h>
#include <linux/etherdevice.h>
-#include <linux/ethtool.h>
#include <linux/suspend.h>
#include <linux/if_arp.h>
#include <linux/wireless.h>
@@ -162,8 +161,6 @@ static const u8 encaps_hdr[] = {0xaa, 0xaa, 0x03, 0x00, 0x00, 0x00};
| HERMES_EV_WTERR | HERMES_EV_INFO \
| HERMES_EV_INFDROP)
-static const struct ethtool_ops orinoco_ethtool_ops;
-
/********************************************************************/
/* Data types */
/********************************************************************/
@@ -1994,7 +1991,9 @@ int orinoco_init(struct orinoco_private *priv)
goto out;
}
- err = determine_fw_capabilities(priv);
+ err = determine_fw_capabilities(priv, wiphy->fw_version,
+ sizeof(wiphy->fw_version),
+ &wiphy->hw_version);
if (err != 0) {
dev_err(dev, "Incompatible firmware, aborting\n");
goto out;
@@ -2010,7 +2009,9 @@ int orinoco_init(struct orinoco_private *priv)
priv->do_fw_download = 0;
/* Check firmware version again */
- err = determine_fw_capabilities(priv);
+ err = determine_fw_capabilities(priv, wiphy->fw_version,
+ sizeof(wiphy->fw_version),
+ &wiphy->hw_version);
if (err != 0) {
dev_err(dev, "Incompatible firmware, aborting\n");
goto out;
@@ -2212,7 +2213,6 @@ int orinoco_if_add(struct orinoco_private *priv,
dev->ieee80211_ptr = wdev;
dev->netdev_ops = &orinoco_netdev_ops;
dev->watchdog_timeo = HZ; /* 1 second timeout */
- dev->ethtool_ops = &orinoco_ethtool_ops;
dev->wireless_handlers = &orinoco_handler_def;
#ifdef WIRELESS_SPY
dev->wireless_data = &priv->wireless_data;
@@ -2348,27 +2348,6 @@ void orinoco_down(struct orinoco_private *priv)
}
EXPORT_SYMBOL(orinoco_down);
-static void orinoco_get_drvinfo(struct net_device *dev,
- struct ethtool_drvinfo *info)
-{
- struct orinoco_private *priv = ndev_priv(dev);
-
- strncpy(info->driver, DRIVER_NAME, sizeof(info->driver) - 1);
- strncpy(info->version, DRIVER_VERSION, sizeof(info->version) - 1);
- strncpy(info->fw_version, priv->fw_name, sizeof(info->fw_version) - 1);
- if (dev->dev.parent)
- strncpy(info->bus_info, dev_name(dev->dev.parent),
- sizeof(info->bus_info) - 1);
- else
- snprintf(info->bus_info, sizeof(info->bus_info) - 1,
- "PCMCIA %p", priv->hw.iobase);
-}
-
-static const struct ethtool_ops orinoco_ethtool_ops = {
- .get_drvinfo = orinoco_get_drvinfo,
- .get_link = ethtool_op_get_link,
-};
-
/********************************************************************/
/* Module initialization */
/********************************************************************/
diff --git a/drivers/net/wireless/orinoco/orinoco.h b/drivers/net/wireless/orinoco/orinoco.h
index 9ac6f1d..665ef56 100644
--- a/drivers/net/wireless/orinoco/orinoco.h
+++ b/drivers/net/wireless/orinoco/orinoco.h
@@ -93,7 +93,6 @@ struct orinoco_private {
/* Capabilities of the hardware/firmware */
fwtype_t firmware_type;
- char fw_name[32];
int ibss_port;
int nicbuf_size;
u16 channel_mask;
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] wireless: make WEXT_SPY and WEXT_PRIV select WEXT_CORE
From: Randy Dunlap @ 2009-10-07 21:55 UTC (permalink / raw)
To: John W. Linville
Cc: linux-wireless, Stephen Rothwell, linux-next, linux-kernel
In-Reply-To: <1254949672-24022-1-git-send-email-linville@tuxdriver.com>
John W. Linville wrote:
> Should prevent this build error reported by Randy...
>
> net/wireless/wext-priv.c:206: error: implicit declaration of function 'call_commit_handler'
> make[3]: *** [net/wireless/wext-priv.o] Error 1
>
> Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Sorry, it did not work for me.
linux-next-20091007/net/wireless/wext-priv.c:206: error: implicit declaration of function 'call_commit_handler'
make[3]: *** [net/wireless/wext-priv.o] Error 1
Drivers like hostap and orinoco (hermes) select WEXT_PRIV regardless
of the setting of WEXT_CORE. oh, and staging/ drivers do that also.
> @@ -12,9 +12,11 @@ config WEXT_PROC
>
> config WEXT_SPY
> bool
> + depends on WEXT_CORE
>
> config WEXT_PRIV
> bool
> + depends on WEXT_CORE
>
> config CFG80211
> tristate "cfg80211 - wireless configuration API"
^ permalink raw reply
* Re: NULL pointer deref at wext ioctl (Re: [PATCH] compat-2.6: adding ethtool.h to compat-2.6.31.h)
From: Johannes Berg @ 2009-10-07 22:01 UTC (permalink / raw)
To: Hin-Tak Leung; +Cc: Luis R. Rodriguez, John W. Linville, linux-wireless
In-Reply-To: <3ace41890910071228i786d4097w69dc7a3dfeb64afe@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1777 bytes --]
On Wed, 2009-10-07 at 20:28 +0100, Hin-Tak Leung wrote:
> On Wed, Oct 7, 2009 at 8:16 PM, Hin-Tak Leung <hintak.leung@gmail.com> wrote:
>
> > It is probably just a transient problem with recent activities - I had
> > a NULL pointer deref from loading rtl8187 of compat-wireless
> > v2.6.32-rc3-39563-g98c2609 -
> >
> > BUG: unable to handle kernel NULL pointer dereference at 000000000000003d
> > IP: [<ffffffff8147822c>] wext_ioctl_dispatch+0xd9/0x180
> > PGD 61c2b067 PUD 6246f067 PMD 0
> > Oops: 0000 [#1] SMP
> > ...
> > Call Trace:
> > [<ffffffff814783f5>] wext_handle_ioctl+0x4d/0x98
> > [<ffffffff813e53a5>] dev_ioctl+0x625/0x662
> > [<ffffffff813cfa45>] sock_ioctl+0x225/0x248
> > [<ffffffff811237a3>] vfs_ioctl+0x31/0xaa
> > [<ffffffff811e1801>] ? security_d_instantiate+0x37/0x4d
> > [<ffffffff81123c88>] do_vfs_ioctl+0x46c/0x4c3
> > [<ffffffff81123d44>] sys_ioctl+0x65/0x9c
> > [<ffffffff81012082>] system_call_fastpath+0x16/0x1b
> >
> > I'm sure whatever changes made this happen will go away soon, so I'll
> > just re-try in a few days... but if anybody knows what commit causes
> > this (and what fixes it!), I'd like to know.
> >
>
> Hiya, It looks like I last used compat-wireless successfully was on
> 25th (I am not saying it breaks after - I just haven't tried until
> yesterday, possibly), and most of the recent changes are per-driver,
> but there is a big code drop from Johannes dated 27th on 'wext:
> refactor' . Changes from that or dependent changes?
Probably -- but I don't see this problem on stock kernel and I'm not
sure what could be causing it for compat-wireless.
This will be the old copy of wext_ioctl_dispatch. It'd certainly help to
get disassembly/the source line of the oops.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] wireless: make WEXT_SPY and WEXT_PRIV select WEXT_CORE
From: Johannes Berg @ 2009-10-07 22:34 UTC (permalink / raw)
To: Randy Dunlap
Cc: John W. Linville, linux-wireless, Stephen Rothwell, linux-next,
linux-kernel
In-Reply-To: <4ACD0E5A.7060106@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 905 bytes --]
On Wed, 2009-10-07 at 14:55 -0700, Randy Dunlap wrote:
> John W. Linville wrote:
> > Should prevent this build error reported by Randy...
> >
> > net/wireless/wext-priv.c:206: error: implicit declaration of function 'call_commit_handler'
> > make[3]: *** [net/wireless/wext-priv.o] Error 1
> >
> > Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
> > Signed-off-by: John W. Linville <linville@tuxdriver.com>
>
> Sorry, it did not work for me.
> linux-next-20091007/net/wireless/wext-priv.c:206: error: implicit declaration of function 'call_commit_handler'
> make[3]: *** [net/wireless/wext-priv.o] Error 1
>
> Drivers like hostap and orinoco (hermes) select WEXT_PRIV regardless
> of the setting of WEXT_CORE. oh, and staging/ drivers do that also.
But they also select WIRELESS_EXT, which should cause WEXT_CORE to be
turned on. Is it possible that is failing?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: linux-next: Tree for October 7 (libertas build failure)
From: Johannes Berg @ 2009-10-07 22:34 UTC (permalink / raw)
To: Dan Williams
Cc: Randy Dunlap, Stephen Rothwell, linux-wireless, linux-next, LKML,
libertas-dev, Holger Schurig
In-Reply-To: <1254939120.16001.45.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 690 bytes --]
On Wed, 2009-10-07 at 11:12 -0700, Dan Williams wrote:
> > drivers/built-in.o: In function `lbs_cfg_free':
> > (.text+0x3479e0): undefined reference to `wiphy_unregister'
> > drivers/built-in.o: In function `lbs_cfg_free':
> > (.text+0x3479e7): undefined reference to `wiphy_free'
> > drivers/built-in.o: In function `lbs_cfg_register':
> > (.text+0x347a52): undefined reference to `wiphy_register'
> > drivers/built-in.o: In function `lbs_cfg_alloc':
> > (.text+0x347acf): undefined reference to `wiphy_new'
>
> Holger, perhaps we need some Kconfig updates to select cfg80211?
Depend on, please -- cfg80211 has dependencies that would otherwise be
messed up.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] b43: Fix locking problem when stopping rfkill polling
From: Johannes Berg @ 2009-10-07 22:36 UTC (permalink / raw)
To: Larry Finger; +Cc: John W. Linville, linux-wireless
In-Reply-To: <4ACCEBE8.8010803@lwfinger.net>
[-- Attachment #1: Type: text/plain, Size: 965 bytes --]
On Wed, 2009-10-07 at 14:28 -0500, Larry Finger wrote:
> > OK, but why do we start polling under the lock but stop polling without
> > the lock? Should we start polling without holding the lock too?
>
> I'll test that, but I suspect it doesn't matter. Of course, the reason
> I put the stop under the lock was for symmetry, but then I got the
> following when shutting down:
>
> b43-phy0 debug: Removing Interface type 2
>
> =======================================================
> [ INFO: possible circular locking dependency detected ]
> 2.6.32-rc3-wl #225
> -------------------------------------------------------
> modprobe/25391 is trying to acquire lock:
> (&(&rfkill->poll_work)->work){+.+...}, at: [<ffffffff81054a7f>]
> __cancel_work_timer+0xd9/0x224
This is because when stopping polling we need to cancel the work and
sync on it, but when starting it's completely async so starting can be
in any context.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] b43: Fix locking problem when stopping rfkill polling
From: Larry Finger @ 2009-10-07 22:43 UTC (permalink / raw)
To: Johannes Berg; +Cc: John W. Linville, linux-wireless
In-Reply-To: <1254955015.3713.9.camel@johannes.local>
Johannes Berg wrote:
> This is because when stopping polling we need to cancel the work and
> sync on it, but when starting it's completely async so starting can be
> in any context.
Does that mean that start could be moved outside the mutex_lock so
that the start and stop would look symmetrical in b43?
Larry
^ 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