* Congratulations
From: Larry Finger @ 2009-08-27 0:26 UTC (permalink / raw)
To: Gábor Stefanik
Cc: John Linville, Michael Buesch, Mark Huijgen, Broadcom Wireless,
linux-wireless
In-Reply-To: <1251323178-7173-1-git-send-email-netrolller.3d@gmail.com>
Gábor,
Congratulations on your progress. With today's patches my BCM4312
802.11b/g card with PCI ID 14e4:4315 works - I'm using it at the
moment. I'm using WPA2 encryption and have connected to APs on
channels 1 and 11. My logs are clean.
As you noted, performance is a little weak, but I get transmits of
9-11 Mb/s and receive rates up to 18 Mb/s - eminently usable.
I certainly hope that you get the patches approved so that these
changes will be in the 2.6.32 kernel.
Once again, congratulations to you, Michael, and the others members of
the reverse engineering team. Seeing the device comes to life makes
all those hours of staring at MIPS binary code seem very worthwhile.
For those of you with N PHYs, the RE of those devices will be my next
step.
Larry
^ permalink raw reply
* Re: hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)
From: Hin-Tak Leung @ 2009-08-27 0:16 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Johannes Berg, hal, htl10, Larry Finger,
Herton Ronaldo Krzesinski, linux-wireless
In-Reply-To: <43e72e890908261645n24a040cds84f012095a40c15b@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 726 bytes --]
On Thu, Aug 27, 2009 at 12:45 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> Johannes, did kernels < 2.6.31 have /sys/class/rfkill ?
2.6.30 has /sys/class/rfkill (it is exposed by the vendor as-shipped
rfkill.ko). But I just tried something like this, and it seems to work
- the patch is simple enough and just 3 hunks - what it does:
1) 'make unload' should unload rfkill also,
2) remove the compat-wireless class renaming hunk (so it advertise
itself as 'rfkill' rather than 'rfkill_backport')
3) remove the compat-wireless input hander renaming hunk.
I am not sure what the input handle->name (3) is for, somebody care to
explain? Is there any reason why I should do something like outlined
here in the patch?
Hin-Tak
[-- Attachment #2: compat-wireless_remove_backport_naming.diff --]
[-- Type: text/x-patch, Size: 1765 bytes --]
diff --git a/compat/patches/03-rfkill.patch b/compat/patches/03-rfkill.patch
index 61eb762..368767f 100644
--- a/compat/patches/03-rfkill.patch
+++ b/compat/patches/03-rfkill.patch
@@ -34,15 +34,6 @@ just keep /dev/rfkill and not /dev/rfkill_backport.
#include <linux/sched.h>
#include "rfkill.h"
-@@ -229,7 +233,7 @@ static int rfkill_connect(struct input_h
-
- handle->dev = dev;
- handle->handler = handler;
-- handle->name = "rfkill";
-+ handle->name = "rfkill_backport";
-
- /* causes rfkill_start() to be called */
- error = input_register_handle(handle);
--- a/net/rfkill/core.c 2009-08-20 13:48:36.083267397 -0700
+++ b/net/rfkill/core.c 2009-08-20 13:48:37.051267098 -0700
@@ -26,7 +26,7 @@
@@ -81,15 +72,6 @@ just keep /dev/rfkill and not /dev/rfkill_backport.
static atomic_t rfkill_input_disabled = ATOMIC_INIT(0);
/**
-@@ -776,7 +776,7 @@
- }
-
- static struct class rfkill_class = {
-- .name = "rfkill",
-+ .name = "rfkill_backport",
- .dev_release = rfkill_release,
- .dev_attrs = rfkill_dev_attrs,
- .dev_uevent = rfkill_dev_uevent,
@@ -922,7 +922,7 @@
if (!rfkill->persistent || rfkill_epo_lock_active) {
schedule_work(&rfkill->sync_work);
diff --git a/scripts/unload.sh b/scripts/unload.sh
index 75bbfc9..0537056 100755
--- a/scripts/unload.sh
+++ b/scripts/unload.sh
@@ -25,6 +25,7 @@ MODULES="$MODULES rndis_wlan rndis_host cdc_ether usbnet"
# eeprom_93cx6 is used by rt2x00 (rt61pci, rt2500pci, rt2400pci)
# and Realtek drivers ( rtl8187, rtl8180)
MODULES="$MODULES eeprom_93cx6"
+MODULES="$MODULES rfkill"
MODULES="$MODULES lib80211_crypt_ccmp lib80211_crypt_tkip lib80211_crypt_wep"
MODULES="$MODULES mac80211 cfg80211 lib80211"
MADWIFI_MODULES="ath_pci ath_rate_sample wlan_scan_sta wlan ath_hal"
^ permalink raw reply related
* Re: hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)
From: Luis R. Rodriguez @ 2009-08-26 23:45 UTC (permalink / raw)
To: Hin-Tak Leung
Cc: Johannes Berg, hal, htl10, Larry Finger,
Herton Ronaldo Krzesinski, linux-wireless
In-Reply-To: <3ace41890908261555g339e65d1n6627cc3d1713287e@mail.gmail.com>
On Wed, Aug 26, 2009 at 3:55 PM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
> On Wed, Aug 26, 2009 at 11:28 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>> On Wed, Aug 26, 2009 at 3:11 PM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
>>> (added list hal to To:, since it has become relevant; previous
>>> exchanges of the thread on linux-wireless)
>>>
>>> On Wed, Aug 26, 2009 at 5:29 PM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
>>>> On Wed, Aug 26, 2009 at 3:34 PM, Johannes Berg<johannes@sipsolutions.net> wrote:
>>>>> On Wed, 2009-08-26 at 13:33 +0000, Hin-Tak Leung wrote:
>>>>>
>>>>>> > Or wait ... are you using compat-wireless?
>>>>>>
>>>>>> Yes, I am. I mentioned this and did wonder if the _backport/ part
>>>>>> in /sys/class is important.
>>>>>
>>>>> Sorry, didn't see.
>>>>>
>>>>> Anyway, that's pretty clearly the reason -- Luis added NETDEV_PRE_UP to
>>>>> some compat*.h but obviously the kernel won't ever call that notifier,
>>>>> so cfg80211 doesn't get a chance to reject the IFUP. No idea how to
>>>>> handle that -- it'll be working fine in a regular tree.
>>>>>
>>>>> Luis, the only way to handle that would be to manually call the PRE_UP
>>>>> notifier from mac80211's subif_open() and if that returns an error
>>>>> (warning: the calling convention is weird) return the error... that's
>>>>> weird but would work.
>>>>>
>>>>> johannes
>>>>>
>>>>
>>>> Hmm, got a bit side-tracked. But hal doesn't know the device having a
>>>> killswitch is still wrong somewhere?
>>>> (i.e. am wondering where we should advertise that ability, or how hal
>>>> works that out)
>>>>
>>>> Hin-Tak
>>>>
>>>
>>> I looked into hal and I can now say that it is certainly not
>>> compat-wireless "rfkill_backport"-aware; apparently all it does is
>>> monitoring entries under /sys/class that it knows about. I made a
>>> quick hack:
>>
>> This is wrong, we just do not need to use rfkill_backport for sysfs
>> stuff, consider sending me patch that removes that hunk for
>> compat-wireless instead and test it.
>>
>> Luis
>>
>
> Hmm, I did mention the other option - make rfkill_backport exposes its
> data structure as '/sys/class/rfkill' instead of
> '/sys/class/rfkill_backport'. Is there any reason why
> compat-wireless's rfkill_backport does not called itself 'rfkill' and
> unload and replace the old rfkill? That would be much neater, and
> userland tools like hal won't need to know anything about
> compat-wireless.
Johannes, did kernels < 2.6.31 have /sys/class/rfkill ?
Luis
^ permalink raw reply
* Re: [PATCH] rtl8187: Fix for kernel oops when unloading with LEDs enabled
From: Richard Farina @ 2009-08-26 23:11 UTC (permalink / raw)
To: Hin-Tak Leung
Cc: Larry Finger, John W Linville, Herton Ronaldo Krzesinski,
Hin-Tak Leung, linux-wireless
In-Reply-To: <3ace41890908261538s6818b56ax56cca5af18398dbc@mail.gmail.com>
Hin-Tak Leung wrote:
> On Wed, Aug 26, 2009 at 10:34 PM, Richard Farina<sidhayn@gmail.com> wrote:
>
>
>> I apologize if you thought there was an accusation here, that certainly was
>> not my intention. With all due respect assuming that I'm
>> a jerk is neither safe nor polite. In your original patch for this I find
>> the following text:
>>
>
>
>> Yes, I realize that, which is why I said the "bug is still alive" not "the
>> patch is not applied". I even went out of my way to describe how the
>> testing was different...
>>
>
> While I thought Larry's reply was a bit brief, I looked back on the
> thread and I think I am on Larry's side. All you mentioned was that
> you had a crash on unplug, and then you automatically assume that it
> is because the most recent crash-related fix (which Larry kindly made)
> did not work. You have no proof that your problem is even the same as
> what the fix tried to solve. You did not try to go back to a non-LED
> enabled compat-wireless, for example.
>
> To be honest, I think you 'went out of your way' to try to pin your
> problem on one of the developers, so that your problem is guaranteed
> to receive attention. That's not very fair...
>
> That said, I think this thread has gone on long enough - all that
> happened is that (1) you had a crash on unplug, (2) you tried to pin
> it on Larry, (3) many people has checked and verified that what Larry
> did went in, (4) we still don't know whether your crash is related to
> the LED change or not.
>
> Since we still don't know whether your crash is related to any
> LED-related change or not, this thread is not going well.
>
>
I accept your criticism. I should have been more clear. This happens
only when CONFIG_RTL8187_LEDS=y is set.
I'm not trying to "pin" the bug on Larry claiming it is his fault, I'm
merely stating that I am experiencing a problem that looks extremely
similar to what he described when he pushed the mentioned patch.
Again, I'm not trying to point my finger blaming someone, I'm trying to
help fix a problem. I am traveling for the next few days, when I get
home to my camera I hope you are all calm enough to help me troubleshoot
this bug so we can find a solution instead of accusing each other of
accusing each other.
My apologies for any perceived insults against anyone, seriously, that's
not my goal here.
-Rick
^ permalink raw reply
* Re: [PATCH] rfkill: relicense header file
From: Henrique de Moraes Holschuh @ 2009-08-26 23:10 UTC (permalink / raw)
To: Johannes Berg
Cc: John Linville, linux-wireless, Alan Jenkins,
Iñaky Pérez-González, Ivo van Doorn,
Jaswinder Singh Rajput, Michael Buesch, Tomas Winkler
In-Reply-To: <1251303197.15619.29.camel@johannes.local>
On Wed, 26 Aug 2009, Johannes Berg wrote:
> This header file is copied into userspace tools that
> need not be GPLv2 licensed, make that easier.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> Cc: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
> Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
> Cc: Iñaky Pérez-González <inaky.perez-gonzalez@intel.com>
> Cc: Ivo van Doorn <IvDoorn@gmail.com>
> Cc: Jaswinder Singh Rajput <jaswinder@kernel.org>
> Cc: John W. Linville <linville@tuxdriver.com>
> Cc: Michael Buesch <mb@bu3sch.de>
> Cc: Tomas Winkler <tomas.winkler@intel.com>
> ---
> Need ACK from everybody listed who ever touched this
> file according to git. Please?
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
> include/linux/rfkill.h | 25 +++++++++++--------------
> 1 file changed, 11 insertions(+), 14 deletions(-)
>
> --- wireless-testing.orig/include/linux/rfkill.h 2009-08-26 18:09:57.000000000 +0200
> +++ wireless-testing/include/linux/rfkill.h 2009-08-26 18:10:52.000000000 +0200
> @@ -6,20 +6,17 @@
> * Copyright (C) 2007 Dmitry Torokhov
> * Copyright 2009 Johannes Berg <johannes@sipsolutions.net>
> *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation; either version 2 of the License, or
> - * (at your option) any later version.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> - * GNU General Public License for more details.
> - *
> - * You should have received a copy of the GNU General Public License
> - * along with this program; if not, write to the
> - * Free Software Foundation, Inc.,
> - * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
> + * Permission to use, copy, modify, and/or distribute this software for any
> + * purpose with or without fee is hereby granted, provided that the above
> + * copyright notice and this permission notice appear in all copies.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> */
>
> #include <linux/types.h>
>
>
> --
> 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
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
^ permalink raw reply
* Re: hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)
From: Hin-Tak Leung @ 2009-08-26 22:55 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Johannes Berg, hal, htl10, Larry Finger,
Herton Ronaldo Krzesinski, linux-wireless
In-Reply-To: <43e72e890908261528m23b8fe78w209e305f27e68fa1@mail.gmail.com>
On Wed, Aug 26, 2009 at 11:28 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> On Wed, Aug 26, 2009 at 3:11 PM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
>> (added list hal to To:, since it has become relevant; previous
>> exchanges of the thread on linux-wireless)
>>
>> On Wed, Aug 26, 2009 at 5:29 PM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
>>> On Wed, Aug 26, 2009 at 3:34 PM, Johannes Berg<johannes@sipsolutions.net> wrote:
>>>> On Wed, 2009-08-26 at 13:33 +0000, Hin-Tak Leung wrote:
>>>>
>>>>> > Or wait ... are you using compat-wireless?
>>>>>
>>>>> Yes, I am. I mentioned this and did wonder if the _backport/ part
>>>>> in /sys/class is important.
>>>>
>>>> Sorry, didn't see.
>>>>
>>>> Anyway, that's pretty clearly the reason -- Luis added NETDEV_PRE_UP to
>>>> some compat*.h but obviously the kernel won't ever call that notifier,
>>>> so cfg80211 doesn't get a chance to reject the IFUP. No idea how to
>>>> handle that -- it'll be working fine in a regular tree.
>>>>
>>>> Luis, the only way to handle that would be to manually call the PRE_UP
>>>> notifier from mac80211's subif_open() and if that returns an error
>>>> (warning: the calling convention is weird) return the error... that's
>>>> weird but would work.
>>>>
>>>> johannes
>>>>
>>>
>>> Hmm, got a bit side-tracked. But hal doesn't know the device having a
>>> killswitch is still wrong somewhere?
>>> (i.e. am wondering where we should advertise that ability, or how hal
>>> works that out)
>>>
>>> Hin-Tak
>>>
>>
>> I looked into hal and I can now say that it is certainly not
>> compat-wireless "rfkill_backport"-aware; apparently all it does is
>> monitoring entries under /sys/class that it knows about. I made a
>> quick hack:
>
> This is wrong, we just do not need to use rfkill_backport for sysfs
> stuff, consider sending me patch that removes that hunk for
> compat-wireless instead and test it.
>
> Luis
>
Hmm, I did mention the other option - make rfkill_backport exposes its
data structure as '/sys/class/rfkill' instead of
'/sys/class/rfkill_backport'. Is there any reason why
compat-wireless's rfkill_backport does not called itself 'rfkill' and
unload and replace the old rfkill? That would be much neater, and
userland tools like hal won't need to know anything about
compat-wireless.
Hin-Tak
^ permalink raw reply
* Re: [RFC/RFT] rtl8187: Implement rfkill support
From: Luis R. Rodriguez @ 2009-08-26 22:46 UTC (permalink / raw)
To: Johannes Berg
Cc: htl10, Hin-Tak Leung, Larry Finger, Herton Ronaldo Krzesinski,
linux-wireless
In-Reply-To: <1251325824.20531.1.camel@johannes.local>
On Wed, Aug 26, 2009 at 3:30 PM, Johannes Berg<johannes@sipsolutions.net> wrote:
> On Wed, 2009-08-26 at 15:26 -0700, Luis R. Rodriguez wrote:
>
>> I was thinking of the case where someone hit rfkill between dev_open()
>> and mac80211's subif_open() but I am either not sure if this is
>> possible.
>
> Oh, but that's ok -- we'll set the interface down again very quickly
> after. Besides, you could be in subif_open() already while hitting it,
> somewhere in driver initialisation...
>
>> If there is a real value to adding it to mac80211 then we wouldn't
>> need to tug around a hunk for it on compat.
>
> I don't see any value in it.
OK -- then someone interested can add the hunk to compat.
Luis
^ permalink raw reply
* Re: [PATCH] rtl8187: Fix for kernel oops when unloading with LEDs enabled
From: Hin-Tak Leung @ 2009-08-26 22:38 UTC (permalink / raw)
To: Richard Farina
Cc: Larry Finger, John W Linville, Herton Ronaldo Krzesinski,
Hin-Tak Leung, linux-wireless
In-Reply-To: <4A95AA64.20502@gmail.com>
On Wed, Aug 26, 2009 at 10:34 PM, Richard Farina<sidhayn@gmail.com> wrote:
> I apologize if you thought there was an accusation here, that certainly was
> not my intention. With all due respect assuming that I'm
> a jerk is neither safe nor polite. In your original patch for this I find
> the following text:
> Yes, I realize that, which is why I said the "bug is still alive" not "the
> patch is not applied". I even went out of my way to describe how the
> testing was different...
While I thought Larry's reply was a bit brief, I looked back on the
thread and I think I am on Larry's side. All you mentioned was that
you had a crash on unplug, and then you automatically assume that it
is because the most recent crash-related fix (which Larry kindly made)
did not work. You have no proof that your problem is even the same as
what the fix tried to solve. You did not try to go back to a non-LED
enabled compat-wireless, for example.
To be honest, I think you 'went out of your way' to try to pin your
problem on one of the developers, so that your problem is guaranteed
to receive attention. That's not very fair...
That said, I think this thread has gone on long enough - all that
happened is that (1) you had a crash on unplug, (2) you tried to pin
it on Larry, (3) many people has checked and verified that what Larry
did went in, (4) we still don't know whether your crash is related to
the LED change or not.
Since we still don't know whether your crash is related to any
LED-related change or not, this thread is not going well.
^ permalink raw reply
* Re: [RFC/RFT] rtl8187: Implement rfkill support
From: Johannes Berg @ 2009-08-26 22:30 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: htl10, Hin-Tak Leung, Larry Finger, Herton Ronaldo Krzesinski,
linux-wireless
In-Reply-To: <43e72e890908261526g538eea56l873314e576331449@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 563 bytes --]
On Wed, 2009-08-26 at 15:26 -0700, Luis R. Rodriguez wrote:
> I was thinking of the case where someone hit rfkill between dev_open()
> and mac80211's subif_open() but I am either not sure if this is
> possible.
Oh, but that's ok -- we'll set the interface down again very quickly
after. Besides, you could be in subif_open() already while hitting it,
somewhere in driver initialisation...
> If there is a real value to adding it to mac80211 then we wouldn't
> need to tug around a hunk for it on compat.
I don't see any value in it.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)
From: Luis R. Rodriguez @ 2009-08-26 22:28 UTC (permalink / raw)
To: Hin-Tak Leung
Cc: Johannes Berg, hal, htl10, Larry Finger,
Herton Ronaldo Krzesinski, linux-wireless
In-Reply-To: <3ace41890908261511i3056c049kca82831015ff2aa0@mail.gmail.com>
On Wed, Aug 26, 2009 at 3:11 PM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
> (added list hal to To:, since it has become relevant; previous
> exchanges of the thread on linux-wireless)
>
> On Wed, Aug 26, 2009 at 5:29 PM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
>> On Wed, Aug 26, 2009 at 3:34 PM, Johannes Berg<johannes@sipsolutions.net> wrote:
>>> On Wed, 2009-08-26 at 13:33 +0000, Hin-Tak Leung wrote:
>>>
>>>> > Or wait ... are you using compat-wireless?
>>>>
>>>> Yes, I am. I mentioned this and did wonder if the _backport/ part
>>>> in /sys/class is important.
>>>
>>> Sorry, didn't see.
>>>
>>> Anyway, that's pretty clearly the reason -- Luis added NETDEV_PRE_UP to
>>> some compat*.h but obviously the kernel won't ever call that notifier,
>>> so cfg80211 doesn't get a chance to reject the IFUP. No idea how to
>>> handle that -- it'll be working fine in a regular tree.
>>>
>>> Luis, the only way to handle that would be to manually call the PRE_UP
>>> notifier from mac80211's subif_open() and if that returns an error
>>> (warning: the calling convention is weird) return the error... that's
>>> weird but would work.
>>>
>>> johannes
>>>
>>
>> Hmm, got a bit side-tracked. But hal doesn't know the device having a
>> killswitch is still wrong somewhere?
>> (i.e. am wondering where we should advertise that ability, or how hal
>> works that out)
>>
>> Hin-Tak
>>
>
> I looked into hal and I can now say that it is certainly not
> compat-wireless "rfkill_backport"-aware; apparently all it does is
> monitoring entries under /sys/class that it knows about. I made a
> quick hack:
This is wrong, we just do not need to use rfkill_backport for sysfs
stuff, consider sending me patch that removes that hunk for
compat-wireless instead and test it.
Luis
^ permalink raw reply
* Re: [RFC/RFT] rtl8187: Implement rfkill support
From: Luis R. Rodriguez @ 2009-08-26 22:26 UTC (permalink / raw)
To: Johannes Berg
Cc: htl10, Hin-Tak Leung, Larry Finger, Herton Ronaldo Krzesinski,
linux-wireless
In-Reply-To: <1251324755.20531.0.camel@johannes.local>
On Wed, Aug 26, 2009 at 3:12 PM, Johannes Berg<johannes@sipsolutions.net> wrote:
> On Wed, 2009-08-26 at 15:06 -0700, Luis R. Rodriguez wrote:
>
>> > Neat, thanks. Not sure if I'll get to this this anytime soon, but if
>> > someone is interested in it please give it a shot and send a patch.
>> > That would be nice.
>>
>> What if we *also* just do that from mac80211 as well upstream?
>
> Why?
I was thinking of the case where someone hit rfkill between dev_open()
and mac80211's subif_open() but I am either not sure if this is
possible.
> It's fine as it is, and we don't want to clutter all cfg80211
> drivers with it.
If there is a real value to adding it to mac80211 then we wouldn't
need to tug around a hunk for it on compat.
Luis
^ permalink raw reply
* Re: [RFC/RFT] rtl8187: Implement rfkill support
From: Johannes Berg @ 2009-08-26 22:12 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: htl10, Hin-Tak Leung, Larry Finger, Herton Ronaldo Krzesinski,
linux-wireless
In-Reply-To: <43e72e890908261506h6b9ec4efq2d190388663d4671@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 405 bytes --]
On Wed, 2009-08-26 at 15:06 -0700, Luis R. Rodriguez wrote:
> > Neat, thanks. Not sure if I'll get to this this anytime soon, but if
> > someone is interested in it please give it a shot and send a patch.
> > That would be nice.
>
> What if we *also* just do that from mac80211 as well upstream?
Why? It's fine as it is, and we don't want to clutter all cfg80211
drivers with it.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)
From: Hin-Tak Leung @ 2009-08-26 22:11 UTC (permalink / raw)
To: Johannes Berg, hal
Cc: htl10, Larry Finger, Herton Ronaldo Krzesinski, linux-wireless,
Luis R. Rodriguez
(added list hal to To:, since it has become relevant; previous
exchanges of the thread on linux-wireless)
On Wed, Aug 26, 2009 at 5:29 PM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
> On Wed, Aug 26, 2009 at 3:34 PM, Johannes Berg<johannes@sipsolutions.net> wrote:
>> On Wed, 2009-08-26 at 13:33 +0000, Hin-Tak Leung wrote:
>>
>>> > Or wait ... are you using compat-wireless?
>>>
>>> Yes, I am. I mentioned this and did wonder if the _backport/ part
>>> in /sys/class is important.
>>
>> Sorry, didn't see.
>>
>> Anyway, that's pretty clearly the reason -- Luis added NETDEV_PRE_UP to
>> some compat*.h but obviously the kernel won't ever call that notifier,
>> so cfg80211 doesn't get a chance to reject the IFUP. No idea how to
>> handle that -- it'll be working fine in a regular tree.
>>
>> Luis, the only way to handle that would be to manually call the PRE_UP
>> notifier from mac80211's subif_open() and if that returns an error
>> (warning: the calling convention is weird) return the error... that's
>> weird but would work.
>>
>> johannes
>>
>
> Hmm, got a bit side-tracked. But hal doesn't know the device having a
> killswitch is still wrong somewhere?
> (i.e. am wondering where we should advertise that ability, or how hal
> works that out)
>
> Hin-Tak
>
I looked into hal and I can now say that it is certainly not
compat-wireless "rfkill_backport"-aware; apparently all it does is
monitoring entries under /sys/class that it knows about. I made a
quick hack:
-----------
diff --git a/hald/linux/device.c b/hald/linux/device.c
index 2eca1ef..61e94b7 100644
--- a/hald/linux/device.c
+++ b/hald/linux/device.c
@@ -4621,7 +4621,7 @@ static DevHandler dev_handler_power_supply =
static DevHandler dev_handler_rfkill =
{
- .subsystem = "rfkill",
+ .subsystem = "rfkill_backport",
.add = rfkill_add,
.compute_udi = rfkill_compute_udi,
.refresh = rfkill_refresh,
-----------------
so that it looks for /sys/class/rfkill_backport instead of rfkill ,
and restarting hald, and lshal finally shows the killswitch. And
NetworkManager also becomes aware of the rfkill state and no longer
re-enable the device:
---------------
Aug 26 22:08:36 localhost NetworkManager: <info> HAL disappeared
.
Aug 26 22:08:43 localhost NetworkManager: <info> HAL re-appeared
Aug 26 22:08:43 localhost NetworkManager: <info> Found radio
killswitch /org/freedesktop/Hal/devices/usb_device_bda_8197_00e04c000001_if0_rfkill_phy0_wlan
Aug 26 22:09:16 localhost kernel: rtl8187: wireless radio switch turned off
Aug 26 22:09:20 localhost NetworkManager: <info> Wireless now
disabled by radio killswitch
.
Aug 26 22:13:21 localhost kernel: rtl8187: wireless radio switch turned on
Aug 26 22:13:27 localhost NetworkManager: <info> Wireless now enabled
by radio killswitch
-------------
So, to summarise, from 2.6.31 onwards, cfg80211 should enforce the
rfkill state from within the kernel no matter what hal/NM does; on
non-bleeding edge systems, hal works out rfkill states from
'/sys/class/rfkill' and let NM know. if you have a non-bleeding edge
system but want to try compat-wireless anyway, hal simply doesn't know
about rfkill_backport and NM re-enables the device when one plays with
the rfkill switch.
I guess there are two ways to go about this:
(1) make compat-wireless unload and replace the as-shipped rfkill
module completely and populate /sys/class/rfkill .
(2) make hal monitor and treat /sys/class/rfkill_backport the same way
and in addition to /sys/class/rfkill .
So I went about (2) and just duplicated the rfkill entry like this,
and it seems to work - anybody from hal wants to take this in?
--------------
diff --git a/hald/linux/device.c b/hald/linux/device.c
index 2eca1ef..feb198e 100644
--- a/hald/linux/device.c
+++ b/hald/linux/device.c
@@ -4628,6 +4628,15 @@ static DevHandler dev_handler_rfkill =
.remove = dev_remove
};
+static DevHandler dev_handler_rfkill_backport =
+{
+ .subsystem = "rfkill_backport",
+ .add = rfkill_add,
+ .compute_udi = rfkill_compute_udi,
+ .refresh = rfkill_refresh,
+ .remove = dev_remove
+};
+
static DevHandler dev_handler_scsi = {
.subsystem = "scsi",
.add = scsi_add,
@@ -4817,6 +4826,7 @@ static DevHandler *dev_handlers[] = {
&dev_handler_ps3_system_bus,
&dev_handler_pseudo,
&dev_handler_rfkill,
+ &dev_handler_rfkill_backport,
&dev_handler_scsi,
&dev_handler_scsi_generic,
&dev_handler_scsi_host,
------------------------------
^ permalink raw reply related
* Re: [RFC/RFT] rtl8187: Implement rfkill support
From: Luis R. Rodriguez @ 2009-08-26 22:06 UTC (permalink / raw)
To: Johannes Berg
Cc: htl10, Hin-Tak Leung, Larry Finger, Herton Ronaldo Krzesinski,
linux-wireless
In-Reply-To: <43e72e890908261333m1d576fdhaa16088affec5426@mail.gmail.com>
On Wed, Aug 26, 2009 at 1:33 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> On Wed, Aug 26, 2009 at 7:34 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
>> On Wed, 2009-08-26 at 13:33 +0000, Hin-Tak Leung wrote:
>>
>>> > Or wait ... are you using compat-wireless?
>>>
>>> Yes, I am. I mentioned this and did wonder if the _backport/ part
>>> in /sys/class is important.
>>
>> Sorry, didn't see.
>>
>> Anyway, that's pretty clearly the reason -- Luis added NETDEV_PRE_UP to
>> some compat*.h but obviously the kernel won't ever call that notifier,
>> so cfg80211 doesn't get a chance to reject the IFUP. No idea how to
>> handle that -- it'll be working fine in a regular tree.
>>
>> Luis, the only way to handle that would be to manually call the PRE_UP
>> notifier from mac80211's subif_open() and if that returns an error
>> (warning: the calling convention is weird) return the error... that's
>> weird but would work.
>
> Neat, thanks. Not sure if I'll get to this this anytime soon, but if
> someone is interested in it please give it a shot and send a patch.
> That would be nice.
What if we *also* just do that from mac80211 as well upstream?
Luis
^ permalink raw reply
* [PATCH v3] b43: LP-PHY: Revert to the original PHY register write routine
From: Gábor Stefanik @ 2009-08-26 21:46 UTC (permalink / raw)
To: John Linville, Michael Buesch, Larry Finger, Mark Huijgen
Cc: Broadcom Wireless, linux-wireless
After some discussion on IRC about the PHY register write change,
I am not sure anymore if this is the right thing to do.
Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
---
v3: Use 16-bit writes.
drivers/net/wireless/b43/phy_lp.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/b43/phy_lp.c b/drivers/net/wireless/b43/phy_lp.c
index 80f245c..a57c40d 100644
--- a/drivers/net/wireless/b43/phy_lp.c
+++ b/drivers/net/wireless/b43/phy_lp.c
@@ -1496,7 +1496,8 @@ static u16 b43_lpphy_op_read(struct b43_wldev *dev, u16 reg)
static void b43_lpphy_op_write(struct b43_wldev *dev, u16 reg, u16 value)
{
- b43_write32(dev, B43_MMIO_PHY_CONTROL, ((u32)value << 16) | reg);
+ b43_write16(dev, B43_MMIO_PHY_CONTROL, reg);
+ b43_write16(dev, B43_MMIO_PHY_DATA, value);
}
static void b43_lpphy_op_maskset(struct b43_wldev *dev, u16 reg, u16 mask,
--
1.5.6
^ permalink raw reply related
* [PATCH v2] b43: LP-PHY: Revert to the original PHY register write routine
From: Gábor Stefanik @ 2009-08-26 21:45 UTC (permalink / raw)
To: John Linville, Michael Buesch, Larry Finger, Mark Huijgen
Cc: Broadcom Wireless, linux-wireless
After some discussion on IRC about the PHY register write change,
I am not sure anymore if this is the right thing to do.
Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
---
v2: No more "From: root".
drivers/net/wireless/b43/phy_lp.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/b43/phy_lp.c b/drivers/net/wireless/b43/phy_lp.c
index 80f245c..a57c40d 100644
--- a/drivers/net/wireless/b43/phy_lp.c
+++ b/drivers/net/wireless/b43/phy_lp.c
@@ -1496,7 +1496,8 @@ static u16 b43_lpphy_op_read(struct b43_wldev *dev, u16 reg)
static void b43_lpphy_op_write(struct b43_wldev *dev, u16 reg, u16 value)
{
- b43_write32(dev, B43_MMIO_PHY_CONTROL, ((u32)value << 16) | reg);
+ b43_write32(dev, B43_MMIO_PHY_CONTROL, reg);
+ b43_write32(dev, B43_MMIO_PHY_DATA, value);
}
static void b43_lpphy_op_maskset(struct b43_wldev *dev, u16 reg, u16 mask,
--
1.5.6
^ permalink raw reply related
* Re: [PATCH] b43: LP-PHY: Revert to the original PHY register write routine
From: Michael Buesch @ 2009-08-26 21:44 UTC (permalink / raw)
To: Gábor Stefanik
Cc: John Linville, Larry Finger, Mark Huijgen, Broadcom Wireless,
linux-wireless
In-Reply-To: <1251322728-7034-1-git-send-email-netrolller.3d@gmail.com>
On Wednesday 26 August 2009 23:38:48 Gábor Stefanik wrote:
> From: root <root@NR3DMain.NR3D>
>
> After some discussion on IRC about the PHY register write change,
> I am not sure anymore if this is the right thing to do.
>
> Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
> ---
> drivers/net/wireless/b43/phy_lp.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/b43/phy_lp.c b/drivers/net/wireless/b43/phy_lp.c
> index 80f245c..a57c40d 100644
> --- a/drivers/net/wireless/b43/phy_lp.c
> +++ b/drivers/net/wireless/b43/phy_lp.c
> @@ -1496,7 +1496,8 @@ static u16 b43_lpphy_op_read(struct b43_wldev *dev, u16 reg)
>
> static void b43_lpphy_op_write(struct b43_wldev *dev, u16 reg, u16 value)
> {
> - b43_write32(dev, B43_MMIO_PHY_CONTROL, ((u32)value << 16) | reg);
> + b43_write32(dev, B43_MMIO_PHY_CONTROL, reg);
> + b43_write32(dev, B43_MMIO_PHY_DATA, value);
You just introduced a bug (need 16bit write).
As I said. I'm OK with it, if it works. Just submit it as separate patch in the future.
> }
>
> static void b43_lpphy_op_maskset(struct b43_wldev *dev, u16 reg, u16 mask,
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH] b43: LP-PHY: Revert to the original PHY register write routine
From: Gábor Stefanik @ 2009-08-26 21:42 UTC (permalink / raw)
To: John Linville, Michael Buesch, Larry Finger, Mark Huijgen
Cc: Broadcom Wireless, linux-wireless
In-Reply-To: <1251322728-7034-1-git-send-email-netrolller.3d@gmail.com>
2009/8/26 Gábor Stefanik <netrolller.3d@gmail.com>:
> From: root <root@NR3DMain.NR3D>
The joys of an accidental "sudo git format-patch"... :-)
>
> After some discussion on IRC about the PHY register write change,
> I am not sure anymore if this is the right thing to do.
>
> Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
> ---
> drivers/net/wireless/b43/phy_lp.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/b43/phy_lp.c b/drivers/net/wireless/b43/phy_lp.c
> index 80f245c..a57c40d 100644
> --- a/drivers/net/wireless/b43/phy_lp.c
> +++ b/drivers/net/wireless/b43/phy_lp.c
> @@ -1496,7 +1496,8 @@ static u16 b43_lpphy_op_read(struct b43_wldev *dev, u16 reg)
>
> static void b43_lpphy_op_write(struct b43_wldev *dev, u16 reg, u16 value)
> {
> - b43_write32(dev, B43_MMIO_PHY_CONTROL, ((u32)value << 16) | reg);
> + b43_write32(dev, B43_MMIO_PHY_CONTROL, reg);
> + b43_write32(dev, B43_MMIO_PHY_DATA, value);
> }
>
> static void b43_lpphy_op_maskset(struct b43_wldev *dev, u16 reg, u16 mask,
> --
> 1.5.6
>
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [PATCH] rtl8187: Fix for kernel oops when unloading with LEDs enabled
From: Richard Farina @ 2009-08-26 21:34 UTC (permalink / raw)
To: Larry Finger
Cc: John W Linville, Herton Ronaldo Krzesinski, Hin-Tak Leung,
linux-wireless
In-Reply-To: <4A94C3E9.6070409@lwfinger.net>
Larry Finger wrote:
> Richard Farina wrote:
>
>> Larry Finger wrote:
>>
>>> When rtl8187 is unloaded and CONFIG_RTL8187_LEDS is set, the kernel
>>> may oops when the module is unloaded as the workqueue for led_on was
>>> not being cancelled.
>>>
>>> This patch fixes the problem reported in
>>> http://marc.info/?l=linux-wireless&m=124742957615781&w=2.
>>>
>>> Reported-by: Gábor Stefanik <netrolller.3d@gmail.com>
>>> Signed-off-by: Larry Finger <Larry.Finger@lwfinger>
>>> ---
>>>
>>> V2 - Do not create a new workqueue.
>>>
>>> John,
>>>
>>> This patch is 2.6.31 material. To the best of my knowledge, a formal bug
>>> report was never filed; however, it was reported in the reference
>>> given above.
>>>
>>>
>>>
>> Anyone know what happened here? This bug still seems very much alive in
>> compat-wireless-2.6.31-rc7. I know the window is closed and this really
>> isn't "earthshattering" but a kernel panick is kind of "a big deal". I
>> seems like it was tested doing a proper modprobe -r but not if you just
>> unplug the usb card.
>>
>
> This kind of accusation is not the best way to get your problem solved.
>
>
I apologize if you thought there was an accusation here, that certainly
was not my intention. With all due respect assuming that I'm
a jerk is neither safe nor polite. In your original patch for this I
find the following text:
"Gábor,
I hope this version of the patch fixes your problem. On my system
I ran more than 20 rmmod/insmod cycles without a problem.
Larry"
My assumption in your testing manner was based only on what you said and the kernel panick I still experience
>> When I unplug the usb I get instadeath, very uncool. If someone can
>> teach me how to get the kernel output from a non-functional system I am
>> happy to provide whatever.
>>
>
> This patch has been in wireless testing since August 3. I have no idea
> why it wouldn't be in compat-wireless since then. In addition, I have
> unplugged/plugged my RTL8187B device many times with no problem.
>
> I just downloaded compat-wireless-2009-08-26 - it has the patch
> included. You certainly could have checked your source to determine that.
>
>
Yes, I realize that, which is why I said the "bug is still alive" not
"the patch is not applied". I even went out of my way to describe how
the testing was different...
> To get something from a system that is crashing, you should switch to
> the logging console by pressing CTRL/ALT/F10 before you do whatever it
> takes to crash it. You will not get a full dump, but hopefully, there
> will be enough of the stack visible when the panic occurs. Either copy
> down the stack list, or take a picture of the screen and post a link
> to it. FYI, you can get back to the graphical screen with CTRL/ALT/F7.
>
> If you have a wired connection in addition to the wireless one, and
> you have a second Linux host, you can also capture the dump using
> netconsole. Using this facility is not easy, so we'll go the other
> route first.
>
> When you report what info you have, please tell what architecture you
> are running (i386, x86_64, ppc,...) and whether your device is an
> RTL8187L or RTL8187B. It may not matter, but who knows.
>
>
I will attempt to reproduce and take a picture with both x86 and x86_64,
and I'll look into netconsole because that sounds very useful.
Thanks for the assistance,
Rick Farina
> Larry
>
>
>
^ permalink raw reply
* [PATCH] b43: LP-PHY: Revert to the original PHY register write routine
From: Gábor Stefanik @ 2009-08-26 21:38 UTC (permalink / raw)
To: John Linville, Michael Buesch, Larry Finger, Mark Huijgen
Cc: Broadcom Wireless, linux-wireless
From: root <root@NR3DMain.NR3D>
After some discussion on IRC about the PHY register write change,
I am not sure anymore if this is the right thing to do.
Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
---
drivers/net/wireless/b43/phy_lp.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/b43/phy_lp.c b/drivers/net/wireless/b43/phy_lp.c
index 80f245c..a57c40d 100644
--- a/drivers/net/wireless/b43/phy_lp.c
+++ b/drivers/net/wireless/b43/phy_lp.c
@@ -1496,7 +1496,8 @@ static u16 b43_lpphy_op_read(struct b43_wldev *dev, u16 reg)
static void b43_lpphy_op_write(struct b43_wldev *dev, u16 reg, u16 value)
{
- b43_write32(dev, B43_MMIO_PHY_CONTROL, ((u32)value << 16) | reg);
+ b43_write32(dev, B43_MMIO_PHY_CONTROL, reg);
+ b43_write32(dev, B43_MMIO_PHY_DATA, value);
}
static void b43_lpphy_op_maskset(struct b43_wldev *dev, u16 reg, u16 mask,
--
1.5.6
^ permalink raw reply related
* RE: [PATCH] rfkill: relicense header file
From: Winkler, Tomas @ 2009-08-26 21:36 UTC (permalink / raw)
To: Johannes Berg, John Linville
Cc: linux-wireless, Alan Jenkins, Henrique de Moraes Holschuh,
Perez-Gonzalez, Inaky, Ivo van Doorn, Jaswinder Singh Rajput,
Michael Buesch
In-Reply-To: <1251303197.15619.29.camel@johannes.local>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSm9oYW5uZXMgQmVyZyBb
bWFpbHRvOmpvaGFubmVzQHNpcHNvbHV0aW9ucy5uZXRdDQo+IFNlbnQ6IFdlZG5lc2RheSwgQXVn
dXN0IDI2LCAyMDA5IDc6MTMgUE0NCj4gVG86IEpvaG4gTGludmlsbGUNCj4gQ2M6IGxpbnV4LXdp
cmVsZXNzOyBBbGFuIEplbmtpbnM7IEhlbnJpcXVlIGRlIE1vcmFlcyBIb2xzY2h1aDsgUGVyZXot
DQo+IEdvbnphbGV6LCBJbmFreTsgSXZvIHZhbiBEb29ybjsgSmFzd2luZGVyIFNpbmdoIFJhanB1
dDsgTWljaGFlbCBCdWVzY2g7DQo+IFdpbmtsZXIsIFRvbWFzDQo+IFN1YmplY3Q6IFtQQVRDSF0g
cmZraWxsOiByZWxpY2Vuc2UgaGVhZGVyIGZpbGUNCj4gDQo+IFRoaXMgaGVhZGVyIGZpbGUgaXMg
Y29waWVkIGludG8gdXNlcnNwYWNlIHRvb2xzIHRoYXQNCj4gbmVlZCBub3QgYmUgR1BMdjIgbGlj
ZW5zZWQsIG1ha2UgdGhhdCBlYXNpZXIuDQo+IA0KPiBTaWduZWQtb2ZmLWJ5OiBKb2hhbm5lcyBC
ZXJnIDxqb2hhbm5lc0BzaXBzb2x1dGlvbnMubmV0Pg0KPiBDYzogQWxhbiBKZW5raW5zIDxhbGFu
LWplbmtpbnNAdHVmZm1haWwuY28udWs+DQo+IENjOiBIZW5yaXF1ZSBkZSBNb3JhZXMgSG9sc2No
dWggPGhtaEBobWguZW5nLmJyPg0KPiBDYzogScOxYWt5IFDDqXJlei1Hb256w6FsZXogPGluYWt5
LnBlcmV6LWdvbnphbGV6QGludGVsLmNvbT4NCj4gQ2M6IEl2byB2YW4gRG9vcm4gPEl2RG9vcm5A
Z21haWwuY29tPg0KPiBDYzogSmFzd2luZGVyIFNpbmdoIFJhanB1dCA8amFzd2luZGVyQGtlcm5l
bC5vcmc+DQo+IENjOiBKb2huIFcuIExpbnZpbGxlIDxsaW52aWxsZUB0dXhkcml2ZXIuY29tPg0K
PiBDYzogTWljaGFlbCBCdWVzY2ggPG1iQGJ1M3NjaC5kZT4NCj4gQ2M6IFRvbWFzIFdpbmtsZXIg
PHRvbWFzLndpbmtsZXJAaW50ZWwuY29tPg0KPiAtLS0NCj4gTmVlZCBBQ0sgZnJvbSBldmVyeWJv
ZHkgbGlzdGVkIHdobyBldmVyIHRvdWNoZWQgdGhpcw0KPiBmaWxlIGFjY29yZGluZyB0byBnaXQu
IFBsZWFzZT8NCj4gDQo+ICBpbmNsdWRlL2xpbnV4L3Jma2lsbC5oIHwgICAyNSArKysrKysrKysr
Ky0tLS0tLS0tLS0tLS0tDQo+ICAxIGZpbGUgY2hhbmdlZCwgMTEgaW5zZXJ0aW9ucygrKSwgMTQg
ZGVsZXRpb25zKC0pDQo+IA0KPiAtLS0gd2lyZWxlc3MtdGVzdGluZy5vcmlnL2luY2x1ZGUvbGlu
dXgvcmZraWxsLmgJMjAwOS0wOC0yNg0KPiAxODowOTo1Ny4wMDAwMDAwMDAgKzAyMDANCj4gKysr
IHdpcmVsZXNzLXRlc3RpbmcvaW5jbHVkZS9saW51eC9yZmtpbGwuaAkyMDA5LTA4LTI2DQo+IDE4
OjEwOjUyLjAwMDAwMDAwMCArMDIwMA0KPiBAQCAtNiwyMCArNiwxNyBAQA0KPiAgICogQ29weXJp
Z2h0IChDKSAyMDA3IERtaXRyeSBUb3Jva2hvdg0KPiAgICogQ29weXJpZ2h0IDIwMDkgSm9oYW5u
ZXMgQmVyZyA8am9oYW5uZXNAc2lwc29sdXRpb25zLm5ldD4NCj4gICAqDQo+IC0gKiBUaGlzIHBy
b2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1v
ZGlmeQ0KPiAtICogaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMg
TGljZW5zZSBhcyBwdWJsaXNoZWQgYnkNCj4gLSAqIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRp
b247IGVpdGhlciB2ZXJzaW9uIDIgb2YgdGhlIExpY2Vuc2UsIG9yDQo+IC0gKiAoYXQgeW91ciBv
cHRpb24pIGFueSBsYXRlciB2ZXJzaW9uLg0KPiAtICoNCj4gLSAqIFRoaXMgcHJvZ3JhbSBpcyBk
aXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLA0KPiAtICogYnV0
IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkg
b2YNCj4gLSAqIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVS
UE9TRS4gU2VlIHRoZQ0KPiAtICogR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUg
ZGV0YWlscy4NCj4gLSAqDQo+IC0gKiBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9m
IHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQ0KPiAtICogYWxvbmcgd2l0aCB0aGlzIHBy
b2dyYW07IGlmIG5vdCwgd3JpdGUgdG8gdGhlDQo+IC0gKiBGcmVlIFNvZnR3YXJlIEZvdW5kYXRp
b24sIEluYy4sDQo+IC0gKiA1OSBUZW1wbGUgUGxhY2UgLSBTdWl0ZSAzMzAsIEJvc3RvbiwgTUEg
MDIxMTEtMTMwNywgVVNBLg0KPiArICogUGVybWlzc2lvbiB0byB1c2UsIGNvcHksIG1vZGlmeSwg
YW5kL29yIGRpc3RyaWJ1dGUgdGhpcyBzb2Z0d2FyZSBmb3INCj4gYW55DQo+ICsgKiBwdXJwb3Nl
IHdpdGggb3Igd2l0aG91dCBmZWUgaXMgaGVyZWJ5IGdyYW50ZWQsIHByb3ZpZGVkIHRoYXQgdGhl
DQo+IGFib3ZlDQo+ICsgKiBjb3B5cmlnaHQgbm90aWNlIGFuZCB0aGlzIHBlcm1pc3Npb24gbm90
aWNlIGFwcGVhciBpbiBhbGwgY29waWVzLg0KPiArICoNCj4gKyAqIFRIRSBTT0ZUV0FSRSBJUyBQ
Uk9WSURFRCAiQVMgSVMiIEFORCBUSEUgQVVUSE9SIERJU0NMQUlNUyBBTEwNCj4gV0FSUkFOVElF
Uw0KPiArICogV0lUSCBSRUdBUkQgVE8gVEhJUyBTT0ZUV0FSRSBJTkNMVURJTkcgQUxMIElNUExJ
RUQgV0FSUkFOVElFUyBPRg0KPiArICogTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTLiBJTiBO
TyBFVkVOVCBTSEFMTCBUSEUgQVVUSE9SIEJFIExJQUJMRQ0KPiBGT1INCj4gKyAqIEFOWSBTUEVD
SUFMLCBESVJFQ1QsIElORElSRUNULCBPUiBDT05TRVFVRU5USUFMIERBTUFHRVMgT1IgQU5ZDQo+
IERBTUFHRVMNCj4gKyAqIFdIQVRTT0VWRVIgUkVTVUxUSU5HIEZST00gTE9TUyBPRiBVU0UsIERB
VEEgT1IgUFJPRklUUywgV0hFVEhFUiBJTg0KPiBBTg0KPiArICogQUNUSU9OIE9GIENPTlRSQUNU
LCBORUdMSUdFTkNFIE9SIE9USEVSIFRPUlRJT1VTIEFDVElPTiwgQVJJU0lORyBPVVQNCj4gT0YN
Cj4gKyAqIE9SIElOIENPTk5FQ1RJT04gV0lUSCBUSEUgVVNFIE9SIFBFUkZPUk1BTkNFIE9GIFRI
SVMgU09GVFdBUkUuDQo+ICAgKi8NCj4gDQo+ICAjaW5jbHVkZSA8bGludXgvdHlwZXMuaD4NCj4g
DQoNCg0KQWNrZWQtYnk6IFRvbWFzIFdpbmtsZXIgPHRvbWFzLndpbmtsZXJAaW50ZWwuY29tPg0K
DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0KSW50ZWwgSXNyYWVsICg3NCkgTGltaXRlZAoKVGhpcyBlLW1haWwgYW5k
IGFueSBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgbWF0ZXJpYWwgZm9yCnRo
ZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3IG9yIGRp
c3RyaWJ1dGlvbgpieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBu
b3QgdGhlIGludGVuZGVkCnJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQg
ZGVsZXRlIGFsbCBjb3BpZXMuCg==
^ permalink raw reply
* Re: [PATCH] b43: Fix and update LP-PHY code
From: Michael Buesch @ 2009-08-26 21:03 UTC (permalink / raw)
To: John W. Linville
Cc: Gábor Stefanik, Larry Finger, Mark Huijgen,
Broadcom Wireless, linux-wireless
In-Reply-To: <20090826205403.GA30119@tuxdriver.com>
On Wednesday 26 August 2009 22:54:03 John W. Linville wrote:
> On Wed, Aug 26, 2009 at 10:47:12PM +0200, Gábor Stefanik wrote:
> > 2009/8/26 Michael Buesch <mb@bu3sch.de>:
> > > And, everything in its own patch, please. I don't see a reason for
> > > patching unrelated things in one big patch.
> >
> > Well, this patch is already in wireless-testing, so doing that would
> > now involve reverting this patch, applying a version without the
> > channel change, and applying the channel change - certainly more
> > confusing than the status quo.
>
> But it is not in net-next-2.6. Please submit the patches as Michael
> requested and I'll take care of the reorganization.
You can leave it as-is. But for the future please make sure to submit
independent things in independent patches so they can be discussed
and merged independently.
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH] b43: Fix and update LP-PHY code
From: John W. Linville @ 2009-08-26 20:54 UTC (permalink / raw)
To: Gábor Stefanik
Cc: Michael Buesch, Larry Finger, Mark Huijgen, Broadcom Wireless,
linux-wireless
In-Reply-To: <69e28c910908261347u375f2f5cu74672b9f4b073738@mail.gmail.com>
On Wed, Aug 26, 2009 at 10:47:12PM +0200, Gábor Stefanik wrote:
> 2009/8/26 Michael Buesch <mb@bu3sch.de>:
> > And, everything in its own patch, please. I don't see a reason for
> > patching unrelated things in one big patch.
>
> Well, this patch is already in wireless-testing, so doing that would
> now involve reverting this patch, applying a version without the
> channel change, and applying the channel change - certainly more
> confusing than the status quo.
But it is not in net-next-2.6. Please submit the patches as Michael
requested and I'll take care of the reorganization.
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 and update LP-PHY code
From: Michael Buesch @ 2009-08-26 20:49 UTC (permalink / raw)
To: Gábor Stefanik
Cc: John Linville, Larry Finger, Mark Huijgen, Broadcom Wireless,
linux-wireless
In-Reply-To: <69e28c910908261347u375f2f5cu74672b9f4b073738@mail.gmail.com>
On Wednesday 26 August 2009 22:47:12 Gábor Stefanik wrote:
> 2009/8/26 Michael Buesch <mb@bu3sch.de>:
> > On Wednesday 26 August 2009 20:51:25 Gábor Stefanik wrote:
> >> -Fix a few nasty typos (b43_phy_* operations instead of b43_radio_*)
> >> in the channel tune routines.
> >> -Fix some typos & spec errors found by MMIO tracing.
> >> -Optimize b43_phy_write & b43_phy_mask/set/maskset to use
> >> only the minimal number of MMIO accesses. (Write is possible
> >> using a single 32-bit MMIO write, while set/mask/maskset can
> >> be done in 3 16-bit MMIOs).
> >
> > Why does it matter? PHY access is not done in any hotpath. So why
> > not prefer simple code over optimized code?
>
> This is how the MIPS/hybrid driver does it, I simply updated the code
> for parity.
I think _if_ we do it (I'm not sure if it's worth it), we should certainly
do it in a completely separate patch.
>
> >
> >> -Set the default channel back to 1, as the bug forcing us to use
> >> channel 7 is now fixed.
> >
> > And, everything in its own patch, please. I don't see a reason for
> > patching unrelated things in one big patch.
>
> Well, this patch is already in wireless-testing, so doing that would
When did I ack it?
Note that I _do_ have a life and I was not able to check mail for the past 9 hours.
So please give me an ack latency of one day, at least.
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH] b43: Fix and update LP-PHY code
From: Gábor Stefanik @ 2009-08-26 20:47 UTC (permalink / raw)
To: Michael Buesch
Cc: John Linville, Larry Finger, Mark Huijgen, Broadcom Wireless,
linux-wireless
In-Reply-To: <200908262242.50729.mb@bu3sch.de>
2009/8/26 Michael Buesch <mb@bu3sch.de>:
> On Wednesday 26 August 2009 20:51:25 Gábor Stefanik wrote:
>> -Fix a few nasty typos (b43_phy_* operations instead of b43_radio_*)
>> in the channel tune routines.
>> -Fix some typos & spec errors found by MMIO tracing.
>> -Optimize b43_phy_write & b43_phy_mask/set/maskset to use
>> only the minimal number of MMIO accesses. (Write is possible
>> using a single 32-bit MMIO write, while set/mask/maskset can
>> be done in 3 16-bit MMIOs).
>
> Why does it matter? PHY access is not done in any hotpath. So why
> not prefer simple code over optimized code?
This is how the MIPS/hybrid driver does it, I simply updated the code
for parity.
>
>> -Set the default channel back to 1, as the bug forcing us to use
>> channel 7 is now fixed.
>
> And, everything in its own patch, please. I don't see a reason for
> patching unrelated things in one big patch.
Well, this patch is already in wireless-testing, so doing that would
now involve reverting this patch, applying a version without the
channel change, and applying the channel change - certainly more
confusing than the status quo.
>
>>
>> With this, the device comes up, scans, associates, transmits,
>> receives, monitors and injects on all channels - in other words,
>> it's fully functional. Sensitivity and TX power are still sub-optimal,
>> due to the lack of calibration (that's next on my list).
>>
>> Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
>> ---
>> drivers/net/wireless/b43/phy_common.c | 27 +++++++--
>> drivers/net/wireless/b43/phy_common.h | 3 +
>> drivers/net/wireless/b43/phy_lp.c | 91 +++++++++++++++++--------------
>> drivers/net/wireless/b43/phy_lp.h | 3 +
>> drivers/net/wireless/b43/tables_lpphy.c | 79 +++++++++++++++------------
>> 5 files changed, 122 insertions(+), 81 deletions(-)
>>
>> diff --git a/drivers/net/wireless/b43/phy_common.c b/drivers/net/wireless/b43/phy_common.c
>> index 51686ec..6e704be 100644
>> --- a/drivers/net/wireless/b43/phy_common.c
>> +++ b/drivers/net/wireless/b43/phy_common.c
>> @@ -249,20 +249,35 @@ void b43_phy_copy(struct b43_wldev *dev, u16 destreg, u16 srcreg)
>>
>> void b43_phy_mask(struct b43_wldev *dev, u16 offset, u16 mask)
>> {
>> - b43_phy_write(dev, offset,
>> - b43_phy_read(dev, offset) & mask);
>> + if (dev->phy.ops->phy_maskset) {
>> + assert_mac_suspended(dev);
>> + dev->phy.ops->phy_maskset(dev, offset, mask, 0);
>> + } else {
>> + b43_phy_write(dev, offset,
>> + b43_phy_read(dev, offset) & mask);
>> + }
>> }
>>
>> void b43_phy_set(struct b43_wldev *dev, u16 offset, u16 set)
>> {
>> - b43_phy_write(dev, offset,
>> - b43_phy_read(dev, offset) | set);
>> + if (dev->phy.ops->phy_maskset) {
>> + assert_mac_suspended(dev);
>> + dev->phy.ops->phy_maskset(dev, offset, 0xFFFF, set);
>> + } else {
>> + b43_phy_write(dev, offset,
>> + b43_phy_read(dev, offset) | set);
>> + }
>> }
>>
>> void b43_phy_maskset(struct b43_wldev *dev, u16 offset, u16 mask, u16 set)
>> {
>> - b43_phy_write(dev, offset,
>> - (b43_phy_read(dev, offset) & mask) | set);
>> + if (dev->phy.ops->phy_maskset) {
>> + assert_mac_suspended(dev);
>> + dev->phy.ops->phy_maskset(dev, offset, mask, set);
>> + } else {
>> + b43_phy_write(dev, offset,
>> + (b43_phy_read(dev, offset) & mask) | set);
>> + }
>> }
>>
>> int b43_switch_channel(struct b43_wldev *dev, unsigned int new_channel)
>> diff --git a/drivers/net/wireless/b43/phy_common.h b/drivers/net/wireless/b43/phy_common.h
>> index 9f9f23c..b47a0f5 100644
>> --- a/drivers/net/wireless/b43/phy_common.h
>> +++ b/drivers/net/wireless/b43/phy_common.h
>> @@ -95,6 +95,8 @@ enum b43_txpwr_result {
>> * Must not be NULL.
>> * @phy_write: Write to a PHY register.
>> * Must not be NULL.
>> + * @phy_maskset: Maskset a PHY register, taking shortcuts.
>> + * If it is NULL, a generic algorithm is used.
>> * @radio_read: Read from a Radio register.
>> * Must not be NULL.
>> * @radio_write: Write to a Radio register.
>> @@ -154,6 +156,7 @@ struct b43_phy_operations {
>> /* Register access */
>> u16 (*phy_read)(struct b43_wldev *dev, u16 reg);
>> void (*phy_write)(struct b43_wldev *dev, u16 reg, u16 value);
>> + void (*phy_maskset)(struct b43_wldev *dev, u16 reg, u16 mask, u16 set);
>> u16 (*radio_read)(struct b43_wldev *dev, u16 reg);
>> void (*radio_write)(struct b43_wldev *dev, u16 reg, u16 value);
>>
>> diff --git a/drivers/net/wireless/b43/phy_lp.c b/drivers/net/wireless/b43/phy_lp.c
>> index 5306f2c..1a57d33 100644
>> --- a/drivers/net/wireless/b43/phy_lp.c
>> +++ b/drivers/net/wireless/b43/phy_lp.c
>> @@ -44,7 +44,7 @@ static inline u16 channel2freq_lp(u8 channel)
>> static unsigned int b43_lpphy_op_get_default_chan(struct b43_wldev *dev)
>> {
>> if (b43_current_band(dev->wl) == IEEE80211_BAND_2GHZ)
>> - return 7; //FIXME temporary - channel 1 is broken
>> + return 1;
>> return 36;
>> }
>>
>> @@ -182,8 +182,8 @@ static void lpphy_adjust_gain_table(struct b43_wldev *dev, u32 freq)
>> temp[1] = temp[0] + 0x1000;
>> temp[2] = temp[0] + 0x2000;
>>
>> - b43_lptab_write_bulk(dev, B43_LPTAB16(12, 0), 3, temp);
>> b43_lptab_write_bulk(dev, B43_LPTAB16(13, 0), 3, temp);
>> + b43_lptab_write_bulk(dev, B43_LPTAB16(12, 0), 3, temp);
>> }
>>
>> static void lpphy_table_init(struct b43_wldev *dev)
>> @@ -223,8 +223,8 @@ static void lpphy_baseband_rev0_1_init(struct b43_wldev *dev)
>> b43_phy_maskset(dev, B43_LPPHY_VERYLOWGAINDB, 0xFF00, 0x0006);
>> b43_phy_mask(dev, B43_LPPHY_RX_RADIO_CTL, 0xFFFE);
>> b43_phy_maskset(dev, B43_LPPHY_CLIPCTRTHRESH, 0xFFE0, 0x0005);
>> - b43_phy_maskset(dev, B43_LPPHY_CLIPCTRTHRESH, 0xFC10, 0x0180);
>> - b43_phy_maskset(dev, B43_LPPHY_CLIPCTRTHRESH, 0x83FF, 0x3800);
>> + b43_phy_maskset(dev, B43_LPPHY_CLIPCTRTHRESH, 0xFC1F, 0x0180);
>> + b43_phy_maskset(dev, B43_LPPHY_CLIPCTRTHRESH, 0x83FF, 0x3C00);
>> b43_phy_maskset(dev, B43_LPPHY_GAINDIRECTMISMATCH, 0xFFF0, 0x0005);
>> b43_phy_maskset(dev, B43_LPPHY_GAIN_MISMATCH_LIMIT, 0xFFC0, 0x001A);
>> b43_phy_maskset(dev, B43_LPPHY_CRS_ED_THRESH, 0xFF00, 0x00B3);
>> @@ -237,7 +237,7 @@ static void lpphy_baseband_rev0_1_init(struct b43_wldev *dev)
>> /* TODO:
>> * Set the LDO voltage to 0x0028 - FIXME: What is this?
>> * Call sb_pmu_set_ldo_voltage with 4 and the LDO voltage
>> - * as arguments
>> + * as arguments
>> * Call sb_pmu_paref_ldo_enable with argument TRUE
>> */
>> if (dev->phy.rev == 0) {
>> @@ -340,11 +340,11 @@ static void lpphy_baseband_rev0_1_init(struct b43_wldev *dev)
>> if (dev->phy.rev == 1) {
>> tmp = b43_phy_read(dev, B43_LPPHY_CLIPCTRTHRESH);
>> tmp2 = (tmp & 0x03E0) >> 5;
>> - tmp2 |= tmp << 5;
>> + tmp2 |= tmp2 << 5;
>> b43_phy_write(dev, B43_LPPHY_4C3, tmp2);
>> - tmp = b43_phy_read(dev, B43_LPPHY_OFDMSYNCTHRESH0);
>> + tmp = b43_phy_read(dev, B43_LPPHY_GAINDIRECTMISMATCH);
>> tmp2 = (tmp & 0x1F00) >> 8;
>> - tmp2 |= tmp << 5;
>> + tmp2 |= tmp2 << 5;
>> b43_phy_write(dev, B43_LPPHY_4C4, tmp2);
>> tmp = b43_phy_read(dev, B43_LPPHY_VERYLOWGAINDB);
>> tmp2 = tmp & 0x00FF;
>> @@ -761,7 +761,7 @@ static void lpphy_disable_crs(struct b43_wldev *dev, bool user)
>> b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_0, 0x3);
>> b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_VAL_0, 0xFFFB);
>> b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_0, 0x4);
>> - b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_0, 0xFFF7);
>> + b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_VAL_0, 0xFFF7);
>> b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_0, 0x8);
>> b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_VAL_0, 0x10);
>> b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_0, 0x10);
>> @@ -956,7 +956,7 @@ static void lpphy_run_ddfs(struct b43_wldev *dev, int i_on, int q_on,
>> b43_phy_maskset(dev, B43_LPPHY_AFE_DDFS, 0xFF9F, scale_idx << 5);
>> b43_phy_mask(dev, B43_LPPHY_AFE_DDFS, 0xFFFB);
>> b43_phy_set(dev, B43_LPPHY_AFE_DDFS, 0x2);
>> - b43_phy_set(dev, B43_LPPHY_AFE_DDFS, 0x20);
>> + b43_phy_set(dev, B43_LPPHY_LP_PHY_CTL, 0x20);
>> }
>>
>> static bool lpphy_rx_iq_est(struct b43_wldev *dev, u16 samples, u8 time,
>> @@ -968,7 +968,7 @@ static bool lpphy_rx_iq_est(struct b43_wldev *dev, u16 samples, u8 time,
>> b43_phy_write(dev, B43_LPPHY_IQ_NUM_SMPLS_ADDR, samples);
>> b43_phy_maskset(dev, B43_LPPHY_IQ_ENABLE_WAIT_TIME_ADDR, 0xFF00, time);
>> b43_phy_mask(dev, B43_LPPHY_IQ_ENABLE_WAIT_TIME_ADDR, 0xFEFF);
>> - b43_phy_set(dev, B43_LPPHY_IQ_ENABLE_WAIT_TIME_ADDR, 0xFDFF);
>> + b43_phy_set(dev, B43_LPPHY_IQ_ENABLE_WAIT_TIME_ADDR, 0x200);
>>
>> for (i = 0; i < 500; i++) {
>> if (!(b43_phy_read(dev,
>> @@ -1135,9 +1135,9 @@ static void lpphy_set_tx_power_control(struct b43_wldev *dev,
>> }
>> if (dev->phy.rev >= 2) {
>> if (mode == B43_LPPHY_TXPCTL_HW)
>> - b43_phy_maskset(dev, B43_PHY_OFDM(0xD0), 0xFD, 0x2);
>> + b43_phy_set(dev, B43_PHY_OFDM(0xD0), 0x2);
>> else
>> - b43_phy_maskset(dev, B43_PHY_OFDM(0xD0), 0xFD, 0);
>> + b43_phy_mask(dev, B43_PHY_OFDM(0xD0), 0xFFFD);
>> }
>> lpphy_write_tx_pctl_mode_to_hardware(dev);
>> }
>> @@ -1169,7 +1169,7 @@ static void lpphy_rev0_1_rc_calib(struct b43_wldev *dev)
>> err = b43_lpphy_op_switch_channel(dev, 7);
>> if (err) {
>> b43dbg(dev->wl,
>> - "RC calib: Failed to switch to channel 7, error = %d",
>> + "RC calib: Failed to switch to channel 7, error = %d\n",
>> err);
>> }
>> old_txg_ovr = !!(b43_phy_read(dev, B43_LPPHY_AFE_CTL_OVR) & 0x40);
>> @@ -1500,8 +1500,15 @@ static u16 b43_lpphy_op_read(struct b43_wldev *dev, u16 reg)
>>
>> static void b43_lpphy_op_write(struct b43_wldev *dev, u16 reg, u16 value)
>> {
>> + b43_write32(dev, B43_MMIO_PHY_CONTROL, ((u32)value << 16) | reg);
>> +}
>> +
>> +static void b43_lpphy_op_maskset(struct b43_wldev *dev, u16 reg, u16 mask,
>> + u16 set)
>> +{
>> b43_write16(dev, B43_MMIO_PHY_CONTROL, reg);
>> - b43_write16(dev, B43_MMIO_PHY_DATA, value);
>> + b43_write16(dev, B43_MMIO_PHY_DATA,
>> + (b43_read16(dev, B43_MMIO_PHY_DATA) & mask) | set);
>> }
>>
>> static u16 b43_lpphy_op_radio_read(struct b43_wldev *dev, u16 reg)
>> @@ -1920,8 +1927,8 @@ static void lpphy_b2062_reset_pll_bias(struct b43_wldev *dev)
>>
>> static void lpphy_b2062_vco_calib(struct b43_wldev *dev)
>> {
>> - b43_phy_write(dev, B2062_S_RFPLL_CTL21, 0x42);
>> - b43_phy_write(dev, B2062_S_RFPLL_CTL21, 0x62);
>> + b43_radio_write(dev, B2062_S_RFPLL_CTL21, 0x42);
>> + b43_radio_write(dev, B2062_S_RFPLL_CTL21, 0x62);
>> udelay(200);
>> }
>>
>> @@ -1980,7 +1987,7 @@ static int lpphy_b2062_tune(struct b43_wldev *dev,
>> tmp6 = tmp5 / tmp4;
>> tmp7 = tmp5 % tmp4;
>> b43_radio_write(dev, B2062_S_RFPLL_CTL29, tmp6 + ((2 * tmp7) / tmp4));
>> - tmp8 = b43_phy_read(dev, B2062_S_RFPLL_CTL19);
>> + tmp8 = b43_radio_read(dev, B2062_S_RFPLL_CTL19);
>> tmp9 = ((2 * tmp3 * (tmp8 + 1)) + (3 * tmp1)) / (6 * tmp1);
>> b43_radio_write(dev, B2062_S_RFPLL_CTL23, (tmp9 >> 8) + 16);
>> b43_radio_write(dev, B2062_S_RFPLL_CTL24, tmp9 & 0xFF);
>> @@ -2019,17 +2026,17 @@ static void lpphy_b2063_vco_calib(struct b43_wldev *dev)
>> {
>> u16 tmp;
>>
>> - b43_phy_mask(dev, B2063_PLL_SP1, ~0x40);
>> - tmp = b43_phy_read(dev, B2063_PLL_JTAG_CALNRST) & 0xF8;
>> - b43_phy_write(dev, B2063_PLL_JTAG_CALNRST, tmp);
>> + b43_radio_mask(dev, B2063_PLL_SP1, ~0x40);
>> + tmp = b43_radio_read(dev, B2063_PLL_JTAG_CALNRST) & 0xF8;
>> + b43_radio_write(dev, B2063_PLL_JTAG_CALNRST, tmp);
>> udelay(1);
>> - b43_phy_write(dev, B2063_PLL_JTAG_CALNRST, tmp | 0x4);
>> + b43_radio_write(dev, B2063_PLL_JTAG_CALNRST, tmp | 0x4);
>> udelay(1);
>> - b43_phy_write(dev, B2063_PLL_JTAG_CALNRST, tmp | 0x6);
>> + b43_radio_write(dev, B2063_PLL_JTAG_CALNRST, tmp | 0x6);
>> udelay(1);
>> - b43_phy_write(dev, B2063_PLL_JTAG_CALNRST, tmp | 0x7);
>> + b43_radio_write(dev, B2063_PLL_JTAG_CALNRST, tmp | 0x7);
>> udelay(300);
>> - b43_phy_set(dev, B2063_PLL_SP1, 0x40);
>> + b43_radio_set(dev, B2063_PLL_SP1, 0x40);
>> }
>>
>> static int lpphy_b2063_tune(struct b43_wldev *dev,
>> @@ -2124,31 +2131,31 @@ static int lpphy_b2063_tune(struct b43_wldev *dev,
>> scale = 0;
>> tmp5 = ((tmp4 + (tmp3 >> 1)) / tmp3) - 8;
>> }
>> - b43_phy_maskset(dev, B2063_PLL_JTAG_PLL_CP2, 0xFFC0, tmp5);
>> - b43_phy_maskset(dev, B2063_PLL_JTAG_PLL_CP2, 0xFFBF, scale << 6);
>> + b43_radio_maskset(dev, B2063_PLL_JTAG_PLL_CP2, 0xFFC0, tmp5);
>> + b43_radio_maskset(dev, B2063_PLL_JTAG_PLL_CP2, 0xFFBF, scale << 6);
>>
>> tmp6 = lpphy_qdiv_roundup(100 * val1, val3, 16);
>> tmp6 *= (tmp5 * 8) * (scale + 1);
>> if (tmp6 > 150)
>> tmp6 = 0;
>>
>> - b43_phy_maskset(dev, B2063_PLL_JTAG_PLL_CP3, 0xFFE0, tmp6);
>> - b43_phy_maskset(dev, B2063_PLL_JTAG_PLL_CP3, 0xFFDF, scale << 5);
>> + b43_radio_maskset(dev, B2063_PLL_JTAG_PLL_CP3, 0xFFE0, tmp6);
>> + b43_radio_maskset(dev, B2063_PLL_JTAG_PLL_CP3, 0xFFDF, scale << 5);
>>
>> - b43_phy_maskset(dev, B2063_PLL_JTAG_PLL_XTAL_12, 0xFFFB, 0x4);
>> + b43_radio_maskset(dev, B2063_PLL_JTAG_PLL_XTAL_12, 0xFFFB, 0x4);
>> if (crystal_freq > 26000000)
>> - b43_phy_set(dev, B2063_PLL_JTAG_PLL_XTAL_12, 0x2);
>> + b43_radio_set(dev, B2063_PLL_JTAG_PLL_XTAL_12, 0x2);
>> else
>> - b43_phy_mask(dev, B2063_PLL_JTAG_PLL_XTAL_12, 0xFD);
>> + b43_radio_mask(dev, B2063_PLL_JTAG_PLL_XTAL_12, 0xFD);
>>
>> if (val1 == 45)
>> - b43_phy_set(dev, B2063_PLL_JTAG_PLL_VCO1, 0x2);
>> + b43_radio_set(dev, B2063_PLL_JTAG_PLL_VCO1, 0x2);
>> else
>> - b43_phy_mask(dev, B2063_PLL_JTAG_PLL_VCO1, 0xFD);
>> + b43_radio_mask(dev, B2063_PLL_JTAG_PLL_VCO1, 0xFD);
>>
>> - b43_phy_set(dev, B2063_PLL_SP2, 0x3);
>> + b43_radio_set(dev, B2063_PLL_SP2, 0x3);
>> udelay(1);
>> - b43_phy_mask(dev, B2063_PLL_SP2, 0xFFFC);
>> + b43_radio_mask(dev, B2063_PLL_SP2, 0xFFFC);
>> lpphy_b2063_vco_calib(dev);
>> b43_radio_write(dev, B2063_COMM15, old_comm15);
>>
>> @@ -2158,10 +2165,9 @@ static int lpphy_b2063_tune(struct b43_wldev *dev,
>> static int b43_lpphy_op_switch_channel(struct b43_wldev *dev,
>> unsigned int new_channel)
>> {
>> + struct b43_phy_lp *lpphy = dev->phy.lp;
>> int err;
>>
>> - b43_write16(dev, B43_MMIO_CHANNEL, new_channel);
>> -
>> if (dev->phy.radio_ver == 0x2063) {
>> err = lpphy_b2063_tune(dev, new_channel);
>> if (err)
>> @@ -2174,6 +2180,9 @@ static int b43_lpphy_op_switch_channel(struct b43_wldev *dev,
>> lpphy_adjust_gain_table(dev, channel2freq_lp(new_channel));
>> }
>>
>> + lpphy->channel = new_channel;
>> + b43_write16(dev, B43_MMIO_CHANNEL, new_channel);
>> +
>> return 0;
>> }
>>
>> @@ -2185,10 +2194,9 @@ static int b43_lpphy_op_init(struct b43_wldev *dev)
>> lpphy_baseband_init(dev);
>> lpphy_radio_init(dev);
>> lpphy_calibrate_rc(dev);
>> - err = b43_lpphy_op_switch_channel(dev,
>> - b43_lpphy_op_get_default_chan(dev));
>> + err = b43_lpphy_op_switch_channel(dev, 7);
>> if (err) {
>> - b43dbg(dev->wl, "Switch to init channel failed, error = %d.\n",
>> + b43dbg(dev->wl, "Switch to channel 7 failed, error = %d.\n",
>> err);
>> }
>> lpphy_tx_pctl_init(dev);
>> @@ -2222,6 +2230,7 @@ const struct b43_phy_operations b43_phyops_lp = {
>> .init = b43_lpphy_op_init,
>> .phy_read = b43_lpphy_op_read,
>> .phy_write = b43_lpphy_op_write,
>> + .phy_maskset = b43_lpphy_op_maskset,
>> .radio_read = b43_lpphy_op_radio_read,
>> .radio_write = b43_lpphy_op_radio_write,
>> .software_rfkill = b43_lpphy_op_software_rfkill,
>> diff --git a/drivers/net/wireless/b43/phy_lp.h b/drivers/net/wireless/b43/phy_lp.h
>> index e158d1f..c3232c1 100644
>> --- a/drivers/net/wireless/b43/phy_lp.h
>> +++ b/drivers/net/wireless/b43/phy_lp.h
>> @@ -888,6 +888,9 @@ struct b43_phy_lp {
>> bool crs_usr_disable, crs_sys_disable;
>>
>> unsigned int pdiv;
>> +
>> + /* The channel we are tuned to */
>> + u8 channel;
>> };
>>
>> enum tssi_mux_mode {
>> diff --git a/drivers/net/wireless/b43/tables_lpphy.c b/drivers/net/wireless/b43/tables_lpphy.c
>> index 60d472f..c784def 100644
>> --- a/drivers/net/wireless/b43/tables_lpphy.c
>> +++ b/drivers/net/wireless/b43/tables_lpphy.c
>> @@ -624,30 +624,35 @@ u32 b43_lptab_read(struct b43_wldev *dev, u32 offset)
>> void b43_lptab_read_bulk(struct b43_wldev *dev, u32 offset,
>> unsigned int nr_elements, void *_data)
>> {
>> - u32 type, value;
>> + u32 type;
>> u8 *data = _data;
>> unsigned int i;
>>
>> type = offset & B43_LPTAB_TYPEMASK;
>> + offset &= ~B43_LPTAB_TYPEMASK;
>> + B43_WARN_ON(offset > 0xFFFF);
>> +
>> + b43_phy_write(dev, B43_LPPHY_TABLE_ADDR, offset);
>> +
>> for (i = 0; i < nr_elements; i++) {
>> - value = b43_lptab_read(dev, offset);
>> switch (type) {
>> case B43_LPTAB_8BIT:
>> - *data = value;
>> + *data = b43_phy_read(dev, B43_LPPHY_TABLEDATALO) & 0xFF;
>> data++;
>> break;
>> case B43_LPTAB_16BIT:
>> - *((u16 *)data) = value;
>> + *((u16 *)data) = b43_phy_read(dev, B43_LPPHY_TABLEDATALO);
>> data += 2;
>> break;
>> case B43_LPTAB_32BIT:
>> - *((u32 *)data) = value;
>> + *((u32 *)data) = b43_phy_read(dev, B43_LPPHY_TABLEDATAHI);
>> + *((u32 *)data) <<= 16;
>> + *((u32 *)data) |= b43_phy_read(dev, B43_LPPHY_TABLEDATALO);
>> data += 4;
>> break;
>> default:
>> B43_WARN_ON(1);
>> }
>> - offset++;
>> }
>> }
>>
>> @@ -688,26 +693,34 @@ void b43_lptab_write_bulk(struct b43_wldev *dev, u32 offset,
>> unsigned int i;
>>
>> type = offset & B43_LPTAB_TYPEMASK;
>> + offset &= ~B43_LPTAB_TYPEMASK;
>> + B43_WARN_ON(offset > 0xFFFF);
>> +
>> + b43_phy_write(dev, B43_LPPHY_TABLE_ADDR, offset);
>> +
>> for (i = 0; i < nr_elements; i++) {
>> switch (type) {
>> case B43_LPTAB_8BIT:
>> value = *data;
>> data++;
>> + B43_WARN_ON(value & ~0xFF);
>> + b43_phy_write(dev, B43_LPPHY_TABLEDATALO, value);
>> break;
>> case B43_LPTAB_16BIT:
>> value = *((u16 *)data);
>> data += 2;
>> + B43_WARN_ON(value & ~0xFFFF);
>> + b43_phy_write(dev, B43_LPPHY_TABLEDATALO, value);
>> break;
>> case B43_LPTAB_32BIT:
>> value = *((u32 *)data);
>> data += 4;
>> + b43_phy_write(dev, B43_LPPHY_TABLEDATAHI, value >> 16);
>> + b43_phy_write(dev, B43_LPPHY_TABLEDATALO, value);
>> break;
>> default:
>> B43_WARN_ON(1);
>> - value = 0;
>> }
>> - b43_lptab_write(dev, offset, value);
>> - offset++;
>> }
>> }
>>
>> @@ -777,7 +790,7 @@ static const u8 lpphy_pll_fraction_table[] = {
>> 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80,
>> };
>>
>> -static const u16 lpphy_iq_local_table[] = {
>> +static const u16 lpphy_iqlo_cal_table[] = {
>> 0x0200, 0x0300, 0x0400, 0x0600, 0x0800, 0x0b00, 0x1000, 0x1001, 0x1002,
>> 0x1003, 0x1004, 0x1005, 0x1006, 0x1007, 0x1707, 0x2007, 0x2d07, 0x4007,
>> 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
>> @@ -789,10 +802,17 @@ static const u16 lpphy_iq_local_table[] = {
>> 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
>> 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x4000, 0x0000, 0x0000,
>> 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
>> - 0x0000, 0x0000,
>> + 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
>> };
>>
>> -static const u16 lpphy_ofdm_cck_gain_table[] = {
>> +static const u16 lpphy_rev0_ofdm_cck_gain_table[] = {
>> + 0x0001, 0x0001, 0x0001, 0x0001, 0x1001, 0x2001, 0x3001, 0x4001, 0x5001,
>> + 0x6001, 0x7001, 0x7011, 0x7021, 0x2035, 0x2045, 0x2055, 0x2065, 0x2075,
>> + 0x006d, 0x007d, 0x014d, 0x015d, 0x115d, 0x035d, 0x135d, 0x055d, 0x155d,
>> + 0x0d5d, 0x1d5d, 0x2d5d, 0x555d, 0x655d, 0x755d,
>> +};
>> +
>> +static const u16 lpphy_rev1_ofdm_cck_gain_table[] = {
>> 0x5000, 0x6000, 0x7000, 0x0001, 0x1001, 0x2001, 0x3001, 0x4001, 0x5001,
>> 0x6001, 0x7001, 0x7011, 0x7021, 0x2035, 0x2045, 0x2055, 0x2065, 0x2075,
>> 0x006d, 0x007d, 0x014d, 0x015d, 0x115d, 0x035d, 0x135d, 0x055d, 0x155d,
>> @@ -2263,11 +2283,18 @@ void lpphy_rev0_1_table_init(struct b43_wldev *dev)
>> b43_lptab_write_bulk(dev, B43_LPTAB8(6, 0),
>> ARRAY_SIZE(lpphy_pll_fraction_table), lpphy_pll_fraction_table);
>> b43_lptab_write_bulk(dev, B43_LPTAB16(0, 0),
>> - ARRAY_SIZE(lpphy_iq_local_table), lpphy_iq_local_table);
>> - b43_lptab_write_bulk(dev, B43_LPTAB16(13, 0),
>> - ARRAY_SIZE(lpphy_ofdm_cck_gain_table), lpphy_ofdm_cck_gain_table);
>> - b43_lptab_write_bulk(dev, B43_LPTAB16(12, 0),
>> - ARRAY_SIZE(lpphy_ofdm_cck_gain_table), lpphy_ofdm_cck_gain_table);
>> + ARRAY_SIZE(lpphy_iqlo_cal_table), lpphy_iqlo_cal_table);
>> + if (dev->phy.rev == 0) {
>> + b43_lptab_write_bulk(dev, B43_LPTAB16(13, 0),
>> + ARRAY_SIZE(lpphy_rev0_ofdm_cck_gain_table), lpphy_rev0_ofdm_cck_gain_table);
>> + b43_lptab_write_bulk(dev, B43_LPTAB16(12, 0),
>> + ARRAY_SIZE(lpphy_rev0_ofdm_cck_gain_table), lpphy_rev0_ofdm_cck_gain_table);
>> + } else {
>> + b43_lptab_write_bulk(dev, B43_LPTAB16(13, 0),
>> + ARRAY_SIZE(lpphy_rev1_ofdm_cck_gain_table), lpphy_rev1_ofdm_cck_gain_table);
>> + b43_lptab_write_bulk(dev, B43_LPTAB16(12, 0),
>> + ARRAY_SIZE(lpphy_rev1_ofdm_cck_gain_table), lpphy_rev1_ofdm_cck_gain_table);
>> +}
>> b43_lptab_write_bulk(dev, B43_LPTAB16(15, 0),
>> ARRAY_SIZE(lpphy_gain_delta_table), lpphy_gain_delta_table);
>> b43_lptab_write_bulk(dev, B43_LPTAB32(10, 0),
>> @@ -2281,22 +2308,6 @@ void lpphy_rev2plus_table_init(struct b43_wldev *dev)
>>
>> B43_WARN_ON(dev->phy.rev < 2);
>>
>> - /*
>> - * FIXME This code follows the specs, but it looks wrong:
>> - * In each pass, it writes 4 bytes to an offset in table ID 7,
>> - * then increments the offset by 1 for the next pass. This results
>> - * in the first 3 bytes of each pass except the first one getting
>> - * written to a location that has already been zeroed in the previous
>> - * pass.
>> - * This is what the vendor driver does, but it still looks suspicious.
>> - *
>> - * This should probably suffice:
>> - *
>> - * for (i = 0; i < 704; i+=4)
>> - * b43_lptab_write(dev, B43_LPTAB32(7, i), 0)
>> - *
>> - * This should be tested once the code is functional.
>> - */
>> for (i = 0; i < 704; i++)
>> b43_lptab_write(dev, B43_LPTAB32(7, i), 0);
>>
>> @@ -2323,7 +2334,7 @@ void lpphy_rev2plus_table_init(struct b43_wldev *dev)
>> b43_lptab_write_bulk(dev, B43_LPTAB8(6, 0),
>> ARRAY_SIZE(lpphy_pll_fraction_table), lpphy_pll_fraction_table);
>> b43_lptab_write_bulk(dev, B43_LPTAB16(0, 0),
>> - ARRAY_SIZE(lpphy_iq_local_table), lpphy_iq_local_table);
>> + ARRAY_SIZE(lpphy_iqlo_cal_table), lpphy_iqlo_cal_table);
>> b43_lptab_write_bulk(dev, B43_LPTAB32(9, 0),
>> ARRAY_SIZE(lpphy_papd_eps_table), lpphy_papd_eps_table);
>> b43_lptab_write_bulk(dev, B43_LPTAB32(10, 0),
>
>
>
> --
> Greetings, Michael.
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ 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