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
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 :)
---
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
-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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
() 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
.
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
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
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.
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
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
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
===
---
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
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
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
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
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
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
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
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 napisał:
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
On 01/12/2010 03:32 AM, Éric Piel wrote:
Op 11-01-10 00:56, Larry Finger schreef:
On 01/10/2010 04:51 PM, Éric Piel wrote:
Hello,
I've got a bcm43 with LP-PHY (14e4:4315, rev 01). The b43 driver seems
to work fine (since 2.6.32), excepted when WPA is used. When there is no
encryption
On 01/10/2010 04:51 PM, Éric Piel wrote:
Hello,
I've got a bcm43 with LP-PHY (14e4:4315, rev 01). The b43 driver seems
to work fine (since 2.6.32), excepted when WPA is used. When there is no
encryption, or just WEP, there is no problem. However, when I try to
connect to a AP with WPA
On 01/06/2010 09:50 AM, Michael Buesch wrote:
On Wednesday 06 January 2010 16:40:32 Rafał Miłecki wrote:
b43: N-PHY: implement b43_nphy_stay_carrier_search and it's calls
Hm, The phrase stay carrier earch doesn't make a lot of sense to me.
Is stray carrier search or something like that
On 01/06/2010 02:57 PM, Rafał Miłecki wrote:
V2: adjust to renamed function, fill index array
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
drivers/net/wireless/b43/phy_n.c | 81
Just a little nitpick to save John some work, and to keep the patches straight.
When you submit a second
On 01/06/2010 03:30 PM, Gábor Stefanik wrote:
On Wed, Jan 6, 2010 at 10:09 PM, Rafał Miłecki zaj...@gmail.com wrote:
I've decided to made LP-PHY init code review for compatibility with specs
and found some issues.
We lack some code for higher PHY revisions (up from 2/3) and for some
specific
On 01/06/2010 04:49 PM, Gábor Stefanik wrote:
2010/1/6 Rafał Miłecki zaj...@gmail.com:
W dniu 6 stycznia 2010 23:35 użytkownik Gábor Stefanik
netrolller...@gmail.com napisał:
2010/1/6 Rafał Miłecki zaj...@gmail.com:
V2: fix typo in deaf_count counting, improve b43_mac_[sr] calls,
rename
On 01/06/2010 05:17 PM, Jim Haynes wrote:
On Tue, 5 Jan 2010, Larry Finger wrote:
I have revised the wiki. You will not get the xxx15.fw files.
Thanks, now I have the xxx15.fw files
the wiki and then copy the files in /lib/firmware/b43/ to some
removable device.
After you boot the CD
On 01/05/2010 11:21 AM, Michael Buesch wrote:
Well, just do the thing that makes most sense.
In general we all agree that we should _not_ implement crap, just because
broadcom does so, if we can do better. So, in this case, if we can do a
subfunction call and that function does make sense,
On 01/05/2010 09:55 PM, Jim Haynes wrote:
I'm not sure if this is a b43 problem or a Fedora problem.
It is a problem with Broadcom.
When I get the firmware from the web site I get ucode5.fw, ucode13.fw,
ucode11.fw but no ucode15.fw(and other stuff with number 5, and 13)
I have revised
On 01/04/2010 11:14 AM, Rafał Miłecki wrote:
2010/1/4 Jim Haynes jhhay...@earthlink.net:
I've just joined the list, and most of the stuff is way over my head.
Is there a list for b43 users?
As you have noticed, this is a list for developers. The user-type questions are
generally handled in
On 01/04/2010 11:16 AM, Rafał Miłecki wrote:
Larry: could you just confirm my understanding of docs? Did you mean
chipcommon core in that N-PHY init step?
Yes, the reference is to a register in the chipcommon core.
Larry
___
Bcm43xx-dev mailing
On 01/04/2010 02:36 PM, Rafał Miłecki wrote:
I try to update
int b43_phy_initn(struct b43_wldev *dev)
to match current specs.
Currently it contains many operations/calls that I can not find in
http://bcm-v4.sipsolutions.net/802.11/PHY/Init/N
First I've just posted patch that removed
On 01/04/2010 04:34 PM, Rafał Miłecki wrote:
W dniu 4 stycznia 2010 21:36 użytkownik Rafał Miłecki
zaj...@gmail.com napisał:
Next there is a lot of code after b43_nphy_workarounds(dev); call
that I can not recognize. Let's just take some lines for example:
b43_nphy_reset_cca(dev);
Actually
On 01/02/2010 08:11 PM, Daniel Kuehn wrote:
Hi,
I am the (un)lucky owner of a Macbook of late 2009 model, which has a
Broadcom combo card (BT + WLAN sharing 3 antennas) but neither the b43
or broadcom-sta support it, I just get invalid parameters or the
interface disappears.
Is there
On 12/28/2009 09:52 AM, Andrew Benton wrote:
Sadly it does not work. Tested with the mainline kernel. The DMA errors
persist.
Shucks!!! I was hoping for a late Christmas present. Unfortunately, more coal in
my stocking.
As usual, thanks for testing.
Larry
On 12/28/2009 12:33 PM, Michael Buesch wrote:
On Monday 28 December 2009 05:49:14 Larry Finger wrote:
+tmp = ~(SSB_IMCFGLO_SERTO | SSB_IMCFGLO_REQTO_SHIFT);
This does not make any sense.
Did you mean:
+ tmp = ~(SSB_IMCFGLO_SERTO | SSB_IMCFGLO_REQTO
Michael,
There is something a little funky with this routine. If the call to
__b43_get_and_map_ringmem() fails because the memory allocated is not within the
DMA region supported by the card, there is no way for execution to reach the
section that takes action to fix the problem. As you have
Hi,
In the latest Broadcom driver, I found code that sets the timeout field of the
SSB configuration for some BCM4311 and all BCM4312 devices. Please test this
patch following a cold boot.
Thanks,
Larry
Index: wireless-testing/drivers/ssb/driver_pcicore.c
On 12/23/2009 06:01 AM, Rafał Miłecki wrote:
It's just compilation-tested as I don't own N-PHY device yet (should
receive one for Christmas). Of course I enabled N-PHY in Kconfig.
I already sent this to bcm43xx-dev but didn't get any review. Michael
told me to send it to you John and to
Hi,
I placed a number of test prints in my system trying to find where a
DMA data error might occur. In doing so, I found that 3 slots in the
DMA header cache cross a page boundary. Such a situation is allowed on
my system, but it might be forbidden on Atom processors. Please try
this really ugly
On 12/21/2009 03:47 PM, Michael Buesch wrote:
On Monday 21 December 2009 22:31:10 Larry Finger wrote:
Hi,
I placed a number of test prints in my system trying to find where a
DMA data error might occur. In doing so, I found that 3 slots in the
DMA header cache cross a page boundary
On 12/21/2009 04:11 PM, Michael Buesch wrote:
On Monday 21 December 2009 23:02:39 Larry Finger wrote:
On 12/21/2009 03:47 PM, Michael Buesch wrote:
On Monday 21 December 2009 22:31:10 Larry Finger wrote:
Hi,
I placed a number of test prints in my system trying to find where a
DMA data error
On 12/21/2009 04:18 PM, William Bourque wrote:
Larry Finger wrote:
Hi,
I placed a number of test prints in my system trying to find where a
DMA data error might occur. In doing so, I found that 3 slots in the
DMA header cache cross a page boundary. Such a situation is allowed on
my
On 12/21/2009 07:40 PM, Rafał Miłecki wrote:
It's just compilation-tested as I don't own N-PHY device yet (should
receive one for Christmas). Not sure if we even support SSB used for
N-PHY cards.
I think N PHY cards are supported by SSB. There may be some things to
be extracted from the SPROM,
On 12/20/2009 03:53 PM, Luis R. Rodriguez wrote:
I should note 0x40 starts with vendor specific PCI config space so you
cannot guarantee different PCI devices use 0x41 will be used the same
for different devices. The documentation for the ath9k PCI-E devices
used that entry for something
On 12/19/2009 11:01 PM, Larry Finger wrote:
In exploring the cause of DMA errors for BCM4312 devices on Atom
processors, other drivers that work write to PCI configuration
register 0x40. The code fragment below was found in the open-code
portion of the Broadcom hybrid wl driver. It is also
On 12/19/2009 04:11 AM, Michael Buesch wrote:
Well, if 0x40 is used as RETRY_TIMEOUT in ipw, that doesn't
mean it's the same in b43. Is the 0x40 register standardized in any way?
According to the Wikipedia article on PCI configuration space
registers, only up to 0x3F is standardized. There
On 12/19/2009 04:11 AM, Michael Buesch wrote:
And if you do a patch, don't put it into ssb. Put it into b43.
One further question about putting the patch into b43. Apparently,
register 0x40 is not preserved across a suspend/resume to disk. In all
the drivers that use this code, 0x40 is
register 0x40. The code fragment below was found in the open-code
portion of the Broadcom hybrid wl driver. It is also used in the
ipw2100 and ath9k drivers. In the latter case, it had been removed
and later restored to prevent fatal interrupt errors.
Signed-off-by: Larry Finger larry.fin
On 12/19/2009 05:11 PM, Andrew Benton wrote:
On 19/12/09 19:55, Chris Vine wrote:
I applied this to 2.6.32.2 and it didn't help with the DMA errors I am
afraid.
Chris
Same here, the patch didn't prevent the DMA errors, however, I did
notice that it only reported the error once, it
On 12/19/2009 10:15 PM, William Bourque wrote:
Larry Finger wrote:
Hi,
If possible, please test this patch starting from a cold boot. It is a
variation of something we tried earlier, but enough different to try it.
Thanks,
Larry
A little late but I just tested and I have the same
. In the latter case, it had been removed
and later restored to prevent fatal interrupt errors.
Signed-off-by: Larry Finger larry.fin...@lwfinger.net
---
John,
I think this is 2.6.34 material. By itself, it does not affect the
DMA errors in BCM4312 devices. If it is found to help in the resolution
of that long
On 12/18/2009 10:19 AM, Gábor Stefanik wrote:
Is there anything that I can try or any information that I can provide
to make it work?
BCM4322 is an N-PHY device, which is not yet supported; it will
probably be the next thing I will implement, once Larry completes the
reverse engineering
Michael,
As you may recall, I dumped writes to the PCI config space for both
b43 and the wl driver. I found that wl wrote to address 0x40. In
looking around other drivers, I found the following fragment in ipw2100:
/* We disable the RETRY_TIMEOUT register (0x41) to keep
* PCI Tx
1 - 100 of 1483 matches
Mail list logo
