Re: [PATCH V4] ssb: Implement virtual SPROM

2010-03-26 Thread Larry Finger
On 03/26/2010 06:18 AM, Gene Heskett wrote: On Friday 26 March 2010, Larry Finger wrote: Some recent BCM43XX devices lack an on-board SPROM. The pertinent data from the SPROM could be included in the kernel; however, this presents a problem in the generation of a unique, reproducible MAC

Re: [PATCH V2] ssb: Implement virtual SPROM on disk

2010-03-24 Thread Larry Finger
On 03/23/2010 03:58 PM, Calvin Walton wrote: I will warn you that the following is rather untested, as I don't have any of the affected hardware (or any b43 devices at all, actually), but something along these lines should work. There's no syntax errors, at least :) ---

Re: [PATCH V2] ssb: Implement virtual SPROM on disk

2010-03-23 Thread Larry Finger
On 03/23/2010 03:52 AM, Michael Buesch wrote: On Tuesday 23 March 2010 00:45:28 Larry Finger wrote: (2) In drivers/ssb/pci.c, the firmware loading process reads the file, then modifies it using the bus address. No. You don't need firmware loading at all. udev can just set the mac address

[PATCH V3] ssb: Implement virtual SPROM

2010-03-23 Thread Larry Finger
-by: Larry Finger larry.fin...@lwfinger.net --- John, Unless someone comes up with a unique way to generate a MAC address using only udev rules, I think this is ready. I suspect it is a little to invasive for 2.6.34. In addition, it fixes a bug, but not a regression. Larry --- V2 - make virtual SPROM

Re: Works wonderfully except at Barnes and Nobles.

2010-03-23 Thread Larry Finger
On 03/22/2010 09:57 PM, Frank Middleton wrote: Had some really great experiences with your software recently, especially using a public Wifi system with really weak/out of range signals. I could still get emails even when Windows couldn't find any unencrypted APs, and it worked like a champ

Re: 14e4:4315 (Dell Wireless 1397) cannot find networks after use of b43 driver

2010-03-23 Thread Larry Finger
On 03/23/2010 02:30 PM, Chris Lopes wrote: Hi, I had a perfectly working Dell system running Windows Vista and using version 5.60.188.1 of the Broadcom windows driver (distributed by Dell) for what Windows calls the Dell Wireless 1397 WLAN Mini-Card, which is actually 14e4:4315. I booted

Re: 14e4:4315 (Dell Wireless 1397) cannot find networks after use of b43 driver

2010-03-23 Thread Larry Finger
On 03/23/2010 02:53 PM, Chris Lopes wrote: Thanks for the quick reply. So are you saying that it is impossible that the b43 driver could have somehow made my wireless card unable to detect any networks after a reboot (in either Windows or Linux)? I don't know of any way that b43 could have

Re: 14e4:4315 (Dell Wireless 1397) cannot find networks after use of b43 driver

2010-03-23 Thread Larry Finger
On 03/23/2010 03:31 PM, Chris Lopes wrote: Ok. I got my wireless card to detect networks again. I also had a theory and tried to reproduce the problem, and was successful in doing so. Here are my steps to reproduce: 1) Have Vista running and connected to a wireless network 2) Hibernate

Re: [PATCH V2] ssb: Implement virtual SPROM on disk

2010-03-22 Thread Larry Finger
On 03/22/2010 03:37 AM, Michael Buesch wrote: On Monday 22 March 2010 07:28:23 Calvin Walton wrote: Hi, On Sat, 2010-03-20 at 19:14 -0500, Larry Finger wrote: Some recent BCM43XX devices lack an on-board SPROM. The pertinent data from the SPROM could be included in the kernel; however

Re: [PATCH V2] ssb: Implement virtual SPROM on disk

2010-03-22 Thread Larry Finger
On 03/22/2010 04:55 PM, Michael Buesch wrote: I don't see a problem for udev to distinguish the cards. It can do it merely on the bus-ID. That's unique. Yeah, it might change if you change the hardware. But do we care? I say no, because you cannot actually change the hardware in real life

Re: [PATCH V2] ssb: Implement virtual SPROM on disk

2010-03-22 Thread Larry Finger
Michael, Would the following be sufficient? (1) The utility /bin/dbus-uuidgen is used to create a file /lib/firmware/ssb/mac_address. The command to create this file if it does not exist could be added to the scripts that use fwcutter. (2) In drivers/ssb/pci.c, the firmware loading process

[PATCH V2] ssb: Implement virtual SPROM on disk

2010-03-21 Thread Larry Finger
with a random MAC address. This image is stored in the firmware area, and loaded using the asyncronous firmware load facility. Signed-off-by: Larry Finger larry.fin...@lwfinger.net --- Michael, I think this patch eliminates the need for the fallback sprom code; however, I have not touched that facility yet

[RFC] b43-utilities: ssb-vsprom: Add program to create on-disk, virtual SPROM

2010-03-20 Thread Larry Finger
SPROM, and will operwrite it only when the appropriate switch is used when starting the program. Signed-off-by: Larry Finger larry.fin...@lwfinger.net --- Index: sprom/vsprom/vsprom.c === --- /dev/null +++ sprom/vsprom/vsprom.c @@ -0,0

[PATCH] ssb: Implement virtual SPROM on disk

2010-03-20 Thread Larry Finger
with a random MAC address. This image is stored in the firmware area, and loaded using the asyncronous firmware load facility. Signed-off-by: Larry Finger larry.fin...@lwfinger.net --- Michael, I think this patch eliminates the need for the fallback sprom code; however, I have not touched that facility yet

RFC: A workaround for BCM43XX devices with no on-board SPROM

2010-03-18 Thread Larry Finger
Michael, I'm switching this discussion from the kernel Bugzilla to the lists. As you know, but I'm restating for anyone that has not read our previous discussions, the b43 driver needs to be changed to handle some of the newer devices do not have an on-board SPROM. It would be trivial to

Re: RFC: A workaround for BCM43XX devices with no on-board SPROM

2010-03-18 Thread Larry Finger
On 03/18/2010 03:53 PM, Johannes Berg wrote: On Thu, 2010-03-18 at 12:46 -0500, Larry Finger wrote: Michael, I'm switching this discussion from the kernel Bugzilla to the lists. As you know, but I'm restating for anyone that has not read our previous discussions, the b43 driver needs

Re: RFC: A workaround for BCM43XX devices with no on-board SPROM

2010-03-18 Thread Larry Finger
On 03/18/2010 02:31 PM, Michael Buesch wrote: On Thursday 18 March 2010 18:46:35 Larry Finger wrote: (1) Modify b43-fwcutter to take data from an existing SPROM, Why not extend the ssb-sprom tool? I don't think this has anything to do with firmware, except that we (ab)use the firmware

Re: RFC: A workaround for BCM43XX devices with no on-board SPROM

2010-03-18 Thread Larry Finger
On 03/18/2010 04:20 PM, Johannes Berg wrote: On Thu, 2010-03-18 at 16:10 -0500, Larry Finger wrote: On 03/18/2010 03:53 PM, Johannes Berg wrote: On Thu, 2010-03-18 at 12:46 -0500, Larry Finger wrote: Michael, I'm switching this discussion from the kernel Bugzilla to the lists. As you know

Re: BCM4312 (14e4:4315) in Lenovo Ideapad S12 cannot scan with 2.6.33

2010-03-15 Thread Larry Finger
On 03/15/2010 06:20 PM, Marc Haber wrote: Hi, On Thu, Mar 04, 2010 at 06:54:23PM +0100, Marc Haber wrote: when the broadcom-sta driver didn't compile with 2.6.33 I decided to give b43 a new try. I have a Lenovo Ideapad S12, which has a BCM4312 with LP Phy (14e4:4315). I am using Debian

Even worse problems with BCM4312 on Netbooks

2010-03-12 Thread Larry Finger
A problem with BCM4312 on Netbooks that is worse than the DMA errors has shown up in Fedora F12 systems on Acer One D250 Netbooks. See https://bugzilla.redhat.com/show_bug.cgi?id=533746. In this case, the system seems to freeze when ssb is loaded. So far, no one has managed to get any output from

[PATCH] ssb: Export ssb_chipco_gpio_control - needed by N PHY code

2010-03-10 Thread Larry Finger
The latest changes in the N PHY core require the symbol ssb_chipco_gpio_control to be exported. Signed-off-by: Larry Finger larry.fin...@lwfinger.net --- John, This fixes a build error in wireless-testing - git describe lists it as v2.6.34-rc1-47014-g33b6b57. Larry --- Index: wireless

Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!

2010-03-04 Thread Larry Finger
On 03/03/2010 06:47 PM, Gábor Stefanik wrote: On Thu, Mar 4, 2010 at 1:30 AM, Larry Finger larry.fin...@lwfinger.net wrote: On 03/02/2010 03:57 PM, Michael Buesch wrote: A bug in the PCI-E core code is able to show such behavior, because all memory transfers (MMIO and DMA) from the PCI

Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!

2010-03-04 Thread Larry Finger
On 03/02/2010 03:57 PM, Michael Buesch wrote: A bug in the PCI-E core code is able to show such behavior, because all memory transfers (MMIO and DMA) from the PCI device to the wireless core are translated by the PCI-E core. I think the whole PCI-E core code has to be audited (also the

Re: BCM4312 (14e4:4315) in Lenovo Ideapad S12 cannot scan with 2.6.33

2010-03-04 Thread Larry Finger
On 03/04/2010 12:49 PM, William Bourque wrote: Hello Marc Haber wrote: Hi, when the broadcom-sta driver didn't compile with 2.6.33 I decided to give b43 a new try. I have a Lenovo Ideapad S12, which has a BCM4312 with LP Phy (14e4:4315). I am using Debian unstable. When I load the

Re: BCM4312 (14e4:4315) in Lenovo Ideapad S12 cannot scan with 2.6.33

2010-03-04 Thread Larry Finger
On 03/04/2010 03:46 PM, Marc Haber wrote: On Thu, Mar 04, 2010 at 01:16:26PM -0600, Larry Finger wrote: CRDA is the user-space implementation of the regulatory database. What will the b43 driver do without a CRDA user-space daemon? It's not yet in Debian (see http://bugs.debian.org/cgi-bin

Re: BCM4312 (14e4:4315) in Lenovo Ideapad S12 cannot scan with 2.6.33

2010-03-04 Thread Larry Finger
On 03/04/2010 04:53 PM, Celejar wrote: b43 works perfectly fine with my 4318 on my Debian Sid system, without CRDA installed. What kernel version is in Sid? Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de

Re: BCM4312 (14e4:4315) in Lenovo Ideapad S12 cannot scan with 2.6.33

2010-03-04 Thread Larry Finger
On 03/04/2010 05:33 PM, Celejar wrote: Currently some version of 2.6.32. I should have noted that I actually usually run self-built vanilla ones (from upstream mainline), but I'm pretty sure that b43 works even when I use the Debian packaged ones from the repos. It may fail with 2.6.33.

Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!

2010-02-27 Thread Larry Finger
On 02/27/2010 09:16 AM, Michael Buesch wrote: On Friday 26 February 2010 23:03:28 Gábor Stefanik wrote: BTW there is an interesting difference in the early init between wl and b43: b43 sets bit 0x200 in core register 0x600, while wl sets 0x8000 in register 0x280a - an undocumented register.

Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!

2010-02-27 Thread Larry Finger
On 02/27/2010 09:20 AM, Michael Buesch wrote: On Saturday 27 February 2010 02:41:48 Gábor Stefanik wrote: Someone should test the following: -Open drivers/ssb/driver_chipcommon_pmu.c -In ssb_pmu_init, replace 0x4325 with 0x4312. Uh, wait a second. Do _all_ cards that show the behavior have

Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!

2010-02-27 Thread Larry Finger
On 02/27/2010 10:08 AM, Michael Buesch wrote: On Saturday 27 February 2010 17:05:41 Larry Finger wrote: On 02/27/2010 09:20 AM, Michael Buesch wrote: On Saturday 27 February 2010 02:41:48 Gábor Stefanik wrote: Someone should test the following: -Open drivers/ssb/driver_chipcommon_pmu.c

Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!

2010-02-27 Thread Larry Finger
On 02/27/2010 01:45 PM, Gábor Stefanik wrote: So, a quick status update, from what I've found yesterday: 1. We get the PMU setup wrong. Bit 0x200 is being set, despite the PMU being rev1. Also, PMU setup is done too early - at least wl reads the SPROM before setting up the PMU. A write

Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!

2010-02-26 Thread Larry Finger
On 02/26/2010 09:27 AM, Gábor Stefanik wrote: On Fri, Feb 26, 2010 at 4:13 PM, rekl...@gmail.com wrote: On Feb 26, 2010 9:08am, Gábor Stefanik netrolller...@gmail.com wrote: That's odd... the error only occurs when you stop the mmiotrace?! Yes, the error only occurs when I stop the mmiotrace

[PATCH] b43: Make driver fall back gracefully to PIO mode after fatal DMA errors

2010-02-26 Thread Larry Finger
Subject: Make b43 driver fall back gracefully to PIO mode after fatal DMA errors From: Linus Torvalds torva...@linux-foundation.org Date: Fri, 26 Feb 2010 10:34:27 -0800 (PST) This makes the b43 driver just automatically fall back to PIO mode when DMA doesn't work. The driver already told the

Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!

2010-02-26 Thread Larry Finger
On 02/26/2010 07:41 PM, Gábor Stefanik wrote: Someone should test the following: -Open drivers/ssb/driver_chipcommon_pmu.c -In ssb_pmu_init, replace 0x4325 with 0x4312. (This is not the correct way to fix this, but should be enough for a test. The correct fix would be special-casing for both

Re: Turn broadcom 4311 into master mode

2010-02-24 Thread Larry Finger
On 02/24/2010 06:22 AM, Peter Stuge wrote: Larry Finger wrote: will work with b43 as long as hostapd is 0.6.0 or later. Would you suggest using b43 when creating an access point today? I've looked into ath9k to get agn, but it is very buggy for me and Atheros remains unresponsive. 5GHz

Re: b43 and WPA-PSK

2010-02-23 Thread Larry Finger
On 02/22/2010 02:03 PM, Yan Seiner wrote: I'm trying to get the b43 driver working on a Linksys WRTSL54GS router. It's running Openwrt with the 2.6.32 kernel. The good news is that the driver picks up a lot of APs with ease, far more than the binary blob. The bad news is that I can't get

Re: Turn broadcom 4311 into master mode

2010-02-23 Thread Larry Finger
On 02/23/2010 08:43 PM, D1e6o! wrote: Hello, I'm getting problems to turn my laptop in master mode. When I try to change the mode I get an error: sudo iwconfig wlan0 mode master Error for wireless request Set Mode (8B06) : SET failed on device wlan0 ; Invalid argument. I followed

Re: [PATCH V2] ssb: Add PCI ID 0x4322 to PMU handling

2010-02-21 Thread Larry Finger
On 02/21/2010 04:55 AM, Johannes Berg wrote: On Sun, 2010-02-21 at 11:53 +0100, Gábor Stefanik wrote: 2010/2/21 Rafał Miłecki zaj...@gmail.com: 2010/2/20 Larry Finger larry.fin...@lwfinger.net: Some of the N PHYs need a revision in the handling of the PMU. Signed-off-by: Larry Finger

[PATCH V2] ssb: Add PCI ID 0x4322 to PMU handling

2010-02-20 Thread Larry Finger
Some of the N PHYs need a revision in the handling of the PMU. Signed-off-by: Larry Finger larry.fin...@lwfinger.net --- John, This will be needed for some of the N PHY devices - 2.6.34 amterial. Larry --- V2 - Fix typo in subject line of commit message. Index: wireless-testing/drivers/ssb

[PATCH] ssb: Add PCI ID 0x4322 to PHU handling

2010-02-19 Thread Larry Finger
Some of the N PHYs need a revision in the handling of the PMU. Signed-off-by: Larry Finger larry.fin...@lwfinger.net --- John, This will be needed for some of the N PHY devices - 2.6.34 amterial. Larry --- Index: wireless-testing/drivers/ssb/driver_chipcommon_pmu.c

Re: [PATCH 11/11] b43: N-PHY: switch to chanspec ops

2010-02-09 Thread Larry Finger
On 02/09/2010 02:04 PM, Rafał Miłecki wrote: Signed-off-by: Rafał Miłecki zaj...@gmail.com --- drivers/net/wireless/b43/phy_n.c | 87 +++--- drivers/net/wireless/b43/phy_n.h |1 + 2 files changed, 63 insertions(+), 25 deletions(-) diff --git

Re: b43legacy-phy3: Radio hardware status changed to XXX

2010-02-07 Thread Larry Finger
On 02/07/2010 05:57 AM, strk wrote: On Sat, Feb 06, 2010 at 06:54:44PM -0600, Larry Finger wrote: You can get the wireless-compat sources for kernel 2.6.26 and build that. Othersise, go to kernel.org and get the full sources. I opted for an upgrade first (debian lenny to debian squeeze

Re: b43legacy-phy3: Radio hardware status changed to XXX

2010-02-06 Thread Larry Finger
On 02/06/2010 01:08 PM, strk wrote: Hi everybody, my excuses in advance for asking something which was likely asked a lot more in the past. I just switched to usin b43legacy from bmcxxx (from linux 2.6.18 to linux 2.6.26) and am having some problems with the wireless card. In particular I

Re: b43legacy-phy3: Radio hardware status changed to XXX

2010-02-06 Thread Larry Finger
On 02/06/2010 03:14 PM, strk wrote: On Sat, Feb 06, 2010 at 02:43:36PM -0600, Larry Finger wrote: After bcm43xx was split into b43 and b43legacy, both were upgraded to take account of the computers radio kill switch. Changes in the hardware switch input are causing the Radio hardware ENABLED

Re: b43legacy-phy3: Radio hardware status changed to XXX

2010-02-06 Thread Larry Finger
On 02/06/2010 06:49 PM, strk wrote: On Sat, Feb 06, 2010 at 06:29:03PM -0600, Larry Finger wrote: On 02/06/2010 06:22 PM, strk wrote: On Sat, Feb 06, 2010 at 06:20:15PM -0600, Larry Finger wrote: You could probably avoid the problems by disabling the RFKILL and RFKILL_INPUT options. How

Re: b43/b43legacy driver

2010-02-05 Thread Larry Finger
On 02/05/2010 08:48 AM, Gene Heskett wrote: While I took the time to look, there is a plain text component which kmail is showing me, in Davids msgs, and to see the html, I have to specifically click on that line in the automatic mime report kmail gives me. Perhaps its one of your own

Re: [RFC][PATCH] b43: LP-PHY: always adjust gain table on channel switch

2010-02-05 Thread Larry Finger
On 02/05/2010 10:41 AM, Gábor Stefanik wrote: On Fri, Feb 5, 2010 at 4:24 AM, Larry Finger larry.fin...@lwfinger.net wrote: On 02/04/2010 02:57 PM, Rafał Miłecki wrote: --- Gábor: I think you missed specs here. Could you check whole routine just for sure, please? I don't understand whole

Re: [RFC][PATCH] b43: LP-PHY: always adjust gain table on channel switch

2010-02-05 Thread Larry Finger
On 02/05/2010 12:46 PM, Gábor Stefanik wrote: On Fri, Feb 5, 2010 at 7:09 PM, Larry Finger larry.fin...@lwfinger.net wrote: On 02/05/2010 10:41 AM, Gábor Stefanik wrote: On Fri, Feb 5, 2010 at 4:24 AM, Larry Finger larry.fin...@lwfinger.net wrote: On 02/04/2010 02:57 PM, Rafał Miłecki

Re: [RFC][PATCH] b43: LP-PHY: always adjust gain table on channel switch

2010-02-05 Thread Larry Finger
On 02/05/2010 10:27 AM, Gábor Stefanik wrote: On Fri, Feb 5, 2010 at 4:24 AM, Larry Finger larry.fin...@lwfinger.net wrote: On 02/04/2010 02:57 PM, Rafał Miłecki wrote: --- Gábor: I think you missed specs here. Could you check whole routine just for sure, please? I don't understand whole

Re: [RFC][PATCH] b43: LP-PHY: always adjust gain table on channel switch

2010-02-04 Thread Larry Finger
On 02/04/2010 02:57 PM, Rafał Miłecki wrote: --- Gábor: I think you missed specs here. Could you check whole routine just for sure, please? I don't understand whole radio and chanspec magic yet. --- drivers/net/wireless/b43/phy_lp.c |2 +- 1 files changed, 1 insertions(+), 1

Re: BCM4311/02 ABG disconnects on 2.6.32

2010-02-03 Thread Larry Finger
On 02/03/2010 11:33 AM, Yuval Hager wrote: Thank you for your efforts, I highly appreciate it. I pulled latest wireless-testing (git describe says v2.6.33-rc6-47373- g3b4936f), and applied these two patches. This time there is another type of disconnection (wlan0: deauthenticating from

[PATCH] b43/b43legacy: Wake queues in wireless_core_start

2010-02-03 Thread Larry Finger
() routine. Remove the duplicate and add similar code to b43legacy. Signed-off-by: Larry Finger larry.fin...@lwfinger.net Cc: Stable sta...@kernel.org [2.6.32] --- John, The b43 patch to wireless_core_start() seems to help a regression between 2.6.31 and 2.6.32. Accordingly, these changes should

Re: BCM4311/02 ABG disconnects on 2.6.32

2010-02-03 Thread Larry Finger
. In b43, a similar change has been in place (twice) in the wireless_core_init() routine. Remove the duplicate and add similar code to b43legacy. Signed-off-by: Larry Finger larry.fin...@lwfinger.net Cc: Stable sta...@kernel.org [2.6.32] --- John, The b43 patch to wireless_core_start() seems to help

[PATCH] b43: Fix regression from commit c7ab5ef

2010-02-02 Thread Larry Finger
for the MMIO register, and allowing the slot time to be set for any PHY operating in the 2.4 GHz band. Previously, the routine was executed only for G PHYs. Signed-off-by: Larry Finger larry.fin...@lwfinger.net Cc: Stable sta...@kernel.org [Any stable version back through 2.6.28] --- John, Although late

Re: BCM4311/02 ABG disconnects on 2.6.32

2010-02-02 Thread Larry Finger
On 01/29/2010 03:05 AM, Orivej Desh wrote: Not sure if this helps, but on my system (Network controller [0280]: Broadcom Corporation BCM4311 802.11b/g WLAN [14e4:4311] (rev 01); b43-phy0: Broadcom 4311 WLAN found (core revision 10)) network controller no longer operates after disconnect.

[RFC/RFT] b43: Fix regression from commit c7ab5ef

2010-01-31 Thread Larry Finger
was executed only for G PHYs. Signed-off-by: Larry Finger larry.fin...@lwfinger.net Cc: Stable sta...@kernel.org [Any stable version back through 2.6.28] --- Index: wireless-testing/drivers/net/wireless/b43/main.c === --- wireless

Re: [PATCH 1/5] b43: N-PHY: split RSSI selection into two per-PHY-revision functions

2010-01-31 Thread Larry Finger
On 01/30/2010 01:18 PM, Rafał Miłecki wrote: Signed-off-by: Rafał Miłecki zaj...@gmail.com --- This one yields Warning: trailing whitespace in line 1357 of drivers/net/wireless/b43/phy_n.c Larry ___ Bcm43xx-dev mailing list

Re: BCM4311/02 ABG disconnects on 2.6.32

2010-01-28 Thread Larry Finger
On 01/28/2010 04:42 AM, Yuval Hager wrote: I'll be happy to apply patches as you wish. Does this patch make any difference? Index: wireless-testing/drivers/net/wireless/b43/main.c === ---

Re: BCM4311/02 ABG disconnects on 2.6.32

2010-01-28 Thread Larry Finger
On 01/28/2010 11:16 AM, Yuval Hager wrote: On Thursday 28 January 2010 18:25:50 Larry Finger wrote: On 01/28/2010 04:42 AM, Yuval Hager wrote: I'll be happy to apply patches as you wish. Does this patch make any difference? No. The patch did not apply on 36dbd954, I had to apply

Re: BCM4311/02 ABG disconnects on 2.6.32

2010-01-27 Thread Larry Finger
On 01/27/2010 09:38 AM, Rafał Miłecki wrote: 2010/1/27 Yuval Hageryha...@yhager.com: On Sunday 27 December 2009, Yuval Hager wrote: On Saturday 26 December 2009, Gábor Stefanik wrote: Update your pci.ids file - what you have is a BCM4311/02 ABG. I ran update-pciids successfully, now dmesg

[PATCH] b43: N PHY: Fix compilation after removal of typdef b43_c32

2010-01-26 Thread Larry Finger
In the conversion between typedef and struct, two places that needed a struct were missed. Signed-off-by: Larry Finger larry.fin...@lwfinger.net --- John, Without these, compilation fails. Larry --- Index: wireless-testing/drivers/net/wireless/b43/phy_n.c

Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!

2010-01-25 Thread Larry Finger
On 01/25/2010 02:15 PM, Lucas Thode wrote: As you can tell, this processor is neither an Atom nor a ULV Core 2 Duo. The WLAN card is the Dell Wireless 1395 that came with the laptop (a Vostro 1510). I can build a custom kernel based on the Debian kernel sources if need be; just tell me what

Re: [PATCH 0/5] b43: more N-PHY stuff

2010-01-22 Thread Larry Finger
On 01/22/2010 09:01 AM, Gábor Stefanik wrote: 2010/1/22 Rafał Miłecki zaj...@gmail.com: John, I hope to have patch submission fixed, please let me know if there is anything wrong still. Nope, it is still base64-encoded. I personally use Thunderbird 2 for patch submission (had weird

Re: PHY Transmission error and radio turned off with b43legacy

2010-01-15 Thread Larry Finger
On 01/15/2010 06:12 AM, Jochen Friedrich wrote: Daniel Schmitt wrote: hostapd doesn't continue to work after controller is restarted. I also have the problem that the wlan0-interface shall not be upped with ifconfig wlan0 0.0.0.0 up before starting hostapd, otherwise no beacons will be

Re: [PATCH 3/3] b43: N-PHY: add RX IQ calculation for rev 3

2010-01-13 Thread Larry Finger
On 01/12/2010 01:38 PM, Rafał Miłecki wrote: Signed-off-by: Rafał Miłecki zaj...@gmail.com --- Uh, bigger one. This patch causes false warning: drivers/net/wireless/b43/phy_n.c: In function ‘b43_nphy_rev2_cal_rx_iq’: drivers/net/wireless/b43/phy_n.c:627: warning: large integer implicitly

Re: [PATCH 3/3] b43: N-PHY: add RX IQ calculation for rev 3

2010-01-13 Thread Larry Finger
On 01/13/2010 07:38 AM, Rafał Miłecki wrote: W dniu 13 stycznia 2010 14:31 użytkownik Larry Finger larry.fin...@lwfinger.net napi