Re: [PATCH V4] ssb: Implement virtual SPROM

[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 address. The
>> solution is to initialize the address to a known, workable value. Thus,
>> the device will work without any further code. For an address that is
>> preserved across reloads or reboots, a set of udev routines has been
>> prepared that detect the special address and assign a random value that
>> is preserved in a second udev rule file. The random address should be
>> unique except for the case where a given box has more than one of these
>> cards. This case is handles by adding the DEVPATH to the recognition
>> rules.
>>
>> Signed-off-by: Larry Finger 
> 
> This I assume does not do anything for the idiot vendor who ships thousands 
> of bt dongles all with 11:11:11:11:11:11 set as the mac address?  I got 
> stung with 2 of those things.

Sending a duplicated address is bad enough, but making it be a broadcast address
is particularly bad. On the other hand, the udev technique used here could be
employed to do a unique MAC address assignment for these devices. Do you still
have them?

Larry

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

[PATCH V4] ssb: Implement virtual SPROM

[Larry Finger]

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 address. The
solution is to initialize the address to a known, workable value. Thus,
the device will work without any further code. For an address that is
preserved across reloads or reboots, a set of udev routines has been
prepared that detect the special address and assign a random value that
is preserved in a second udev rule file. The random address should be
unique except for the case where a given box has more than one of these
cards. This case is handles by adding the DEVPATH to the recognition rules.

Signed-off-by: Larry Finger 
---

John,

It has been a long path, but this solution satisfies all the criticisms
that have been posted.

I suspect it is a little to invasive for 2.6.34. In addition, it fixes
a bug, but not a regression. As to introducing a regression, that could
only happen if ssb_is_sprom_available() returns false for some device
that does have an SPROM.

Larry
---

V2 - make virtual SPROM loading asynchronous.
V3 - eliminate the need for a special external utility
   - set for unique MAC address even if a box has more than one of these
 devices
V4 - handle the requirements without any "firmware" routines.

Index: wireless-testing/drivers/ssb/pci.c
===
--- wireless-testing.orig/drivers/ssb/pci.c
+++ wireless-testing/drivers/ssb/pci.c
@@ -613,6 +613,67 @@ static int sprom_extract(struct ssb_bus
return 0;
 }
 
+static void ssb_get_vsprom(struct ssb_sprom *sprom)
+{
+   /* Get values that would have been extracted from SPROM.
+* If sprom_extract_r8() is changed, this section must be
+* changed as well. For any device with 5GHz capability,
+* some variables will have to be changed.
+*/
+   sprom->revision = 8;
+   sprom->boardflags_lo = 0x0A01;
+   sprom->boardflags_hi = 0x0006;
+   sprom->boardflags2_lo = 0x;
+   sprom->boardflags2_hi = 0x;
+   sprom->ant_available_a = 0x00;
+   sprom->ant_available_bg = 0x03;
+   sprom->maxpwr_bg = 0x4A;
+   sprom->itssi_bg = 0x3E;
+   sprom->maxpwr_a = 0xFF;
+   sprom->itssi_a = 0xFF;
+   sprom->maxpwr_ah = 0xFF;
+   sprom->maxpwr_al = 0xFF;
+   sprom->gpio0 = 0x83;
+   sprom->gpio1 = 0xFF;
+   sprom->gpio2 = 0xFF;
+   sprom->gpio3 = 0xFF;
+   sprom->tri2g = 0x6C;
+   sprom->tri5g = 0x00;
+   sprom->tri5gl = 0xFF;
+   sprom->tri5gh = 0xFF;
+   sprom->rxpo2g = 0xFA;
+   sprom->rxpo5g = 0xFF;
+   sprom->rssismf2g = 0x0F;
+   sprom->rssismc2g = 0x00;
+   sprom->rssisav2g = 0x00;
+   sprom->bxa2g = 0x00;
+   sprom->rssismf5g = 0x0F;
+   sprom->rssismc5g = 0x0F;
+   sprom->rssisav5g = 0x07;
+   sprom->bxa5g = 0x03;
+   sprom->pa0b0 = 0x1a57;
+   sprom->pa0b1 = 0xF98A;
+   sprom->pa0b2 = 0xFE91;
+   sprom->pa1b0 = 0x;
+   sprom->pa1b1 = 0x;
+   sprom->pa1b2 = 0x;
+   sprom->pa1lob0 = 0x;
+   sprom->pa1lob1 = 0x;
+   sprom->pa1lob2 = 0x;
+   sprom->pa1hib0 = 0x;
+   sprom->pa1hib1 = 0x;
+   sprom->pa1hib2 = 0x;
+   sprom->cck2gpo = 0x;
+   sprom->ofdm2gpo = 0x0002;
+   sprom->ofdm5glpo = 0x;
+   sprom->ofdm5gpo = 0x;
+   sprom->ofdm5ghpo = 0x;
+   /* assign a dummy, but usable, MAC address */
+   memset(sprom->il0mac, 0x82, 6);
+   memset(sprom->et0mac, 0xFF, 6);
+   memset(sprom->et1mac, 0xFF, 6);
+}
+
 static int ssb_pci_sprom_get(struct ssb_bus *bus,
 struct ssb_sprom *sprom)
 {
@@ -621,8 +682,9 @@ static int ssb_pci_sprom_get(struct ssb_
u16 *buf;
 
if (!ssb_is_sprom_available(bus)) {
-   ssb_printk(KERN_ERR PFX "No SPROM available!\n");
-   return -ENODEV;
+   /* This device has no SPROM. Get values from a real SPROM */
+   ssb_get_vsprom(sprom);
+   return 0;
}
 
buf = kcalloc(SSB_SPROMSIZE_WORDS_R123, sizeof(u16), GFP_KERNEL);
Index: wireless-testing/drivers/net/wireless/b43/main.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/main.c
+++ wireless-testing/drivers/net/wireless/b43/main.c
@@ -4395,6 +4395,7 @@ static int b43_op_add_interface(struct i
struct b43_wl *wl = hw_to_b43_wl(hw);
struct b43_wldev *dev;
int err = -EOPNOTSUPP;
+   u8 test_addr[] = {0x82, 0x82, 0x82, 0x82, 0x82, 0x82};
 
/* TODO: allow WDS/AP devices to coexist */
 
@@ -4417,6 +4418,19 @@ static int b

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

[Larry Finger]

On 03/24/2010 02:21 PM, Michael Buesch wrote:
> On Wednesday 24 March 2010 15:16:03 Larry Finger wrote:
>> I have modified ssb to supply a MAC address of 80:80:80:80:80:80, rather than
> 
> What about also setting the local-assignment bit for this temporary address?
> 
>> The one remaining problem is that the interface has already been renamed 
>> before
>> 60-persistent-b43-mac.rules is processed. In my case, the interface is 
>> wlan13,
>> not wlan0. After I manually modified 60-..., then the new address is applied.
>> I'm still working on this problem.
> 
> Well, udev scripts are processed in alphabetical order. Can't you simply run
> the persistent mac rules before the persistent ifname rules?

I finally figured out the problem I was having. The address attribute was not
being changed by the "ifconfig" call that changed the hardware address. The fix
is to create a new environment when the hardware address and lock out the rule
generation process when that value is detected. The new code for
/lib/udev/rules.d/65-persistent-b43-mac-generator.rules is as follows (Note:
These files are line-wrapped here.):

#===
#
# Rules file to assign a unique, permanent address to BCM43XX devices without
# an SPROM.
#
# Copyright (c) 2010 by Calvin Walton 
# Copyright (c) 2010 by Larry Finger 

# skip this code if action is not add, i.e. change or remove

ACTION!="add", GOTO="persistent_b43_mac_generator_end"

# Use the value of the MAC_CHANGED environment variable to see if the address
# has already been changed.

ENV{MAC_CHANGED}=="yes", GOTO="persistent_b43_mac_generator_end"

# Call script to get a random address - if this device previously encountered,
# the address will already have been changed.

SUBSYSTEM=="net", ATTR{address}=="82:82:82:82:82:82",
IMPORT{program}="write_persistent_b43_mac"

# Apply the new hardware address returned by the script

SUBSYSTEM=="net", ATTR{address}=="82:82:82:82:82:82", RUN+="/sbin/ifconfig
$env{INTERFACE} hw ether $env{MACADDRESS_NEW}"

LABEL="persistent_b43_mac_generator_end"
#===

The code for /lib/udev/write_persistent_b43_mac is as follows:

#=======
#!/bin/bash

# Script to Generate a random MAC address for a BCM43XX device without
# an SPROM.
#
# Copyright (c) 2010 by Calvin Walton 
# Copyright (c) 2010 by Larry Finger 

# Use /dev/urandom to generate the last 5 bytes of the address.
# Make the first byte 2 to avoid generating a multicast address and to set
#  the locally administered address bit.

MACADDRESS=$(/bin/dd if=/dev/urandom bs=1 count=5 2>/dev/null | /usr/bin/od -tx1
| /usr/bin/head -1 | \
/usr/bin/cut -d' ' -f2- | /usr/bin/awk '{ print "02:"$1":"$2":"$3":"$4":"$5 }')

# Define the output rules file
RULES_FILE='/etc/udev/rules.d/60-persistent-b43-mac.rules'

. /lib/udev/rule_generator.functions

# Prevent concurrent processes from modifying the file at the same time.
lock_rules_file

# Check if the rules file is writeable.
choose_rules_file

# The rule should apply for all wlan devices -s some other wireless driver might
# be loaded first - change wlanNN to wlan*
GEN_PATH=$(echo $DEVPATH | /usr/bin/sed s/wlan[0-9]*/wlan*/)

# Output new rule
echo "SUBSYSTEM==\"net\", DEVPATH==\"$GEN_PATH\",
ATTR{address}==\"82:82:82:82:82:82\", ENV{MAC_CHANGED}=\"yes\",
RUN+=\"/sbin/ifconfig \$env{INTERFACE} hw ether $MACADDRESS\"" >> $RULES_FILE

# Report the new address back to the caller who will set the address for this
new interface
echo "MACADDRESS_NEW=$MACADDRESS"

unlock_rules_file

exit 0
#===

Is there a location to put a tar file containing the script and rules files?

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[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 :)
> 
> --- /lib/udev/rules.d/65-persistent-b43-mac-generator.rules
> 
> ACTION!="add" GOTO="persistent_b43_mac_generator_end"
> 
> SUBSYSTEM=="net", DRIVERS=="b43", ATTR{address}=="ff:ff:ff:ff:ff:ff", 
> IMPORT{program}="write_persistent_b43_mac"
> 
> SUBSYSTEM=="net", ENV{MACADDRESS_NEW}=="?*", RUN+="ifconfig $env{INTERFACE} 
> hw ether $env{MACADDRESS_NEW}"
> 
> LABEL="persistent_b43_mac_generator_end"
> 
> --- /lib/udev/write_persistent_b43_mac (chmod +x)
> 
> #!/bin/bash
> 
> # This mac address generation function could be replaced with something better
> MACADDRESS=$(dd if=/dev/urandom bs=1 count=6 2>/dev/null | od -tx1 | head -1 
> | cut -d' ' -f2- | awk '{ print $1":"$2":"$3":"$4":"$5":"$6 }')
> 
> RULES_FILE='/etc/udev/rules.d/60-persistent-b43-mac.rules'
> 
> . /lib64/udev/rule_generator.functions
> 
> lock_rules_file
> 
> choose_rules_file
> 
> echo "DEVPATH==\"$DEVPATH\", DRIVERS==\"b43\", 
> ATTR{address}==\"ff:ff:ff:ff:ff:ff\", RUN+=\"ifconfig $INTERFACE hw ether 
> $MACADDRESS\"" >> $RULES_FILE
> 
> echo "MACADDRESS_NEW=$MACADDRESS"
> 
> unlock_rules_file
> 
> ---
> 
> A new file "/etc/udev/rules.d/60-persistent-b43-mac.rules" will be
> created, which will contain the the saved mac address and bypass the
> generating script on future boots.
> 
> This should probably be run by the udev maintainers, but is a start,
> anyways.

Thanks for the really good start.

The above routines have a minor problem in that using a random value for the
first byte of the MAC address runs the risk of having the multicast bit set. By
fixing the first one to a multiple of 4, that problem is avoided.

A second minor problem is that the full path must be given for all standard
utilities, otherwise they are assumed to be in /lib/udev. Thus all references to
"ifconfig" were replaced by "/sbin/ifconfig". I hope all distros put ifconfig in
/sbin.

I have modified ssb to supply a MAC address of 80:80:80:80:80:80, rather than
FF:FF:FF:FF:FF:FF. This way the interface can come up even though the new udev
routines are not available. When b43 detects that address, it will log a message
describing why the udev routines are needed, and how to obtain them.

The one remaining problem is that the interface has already been renamed before
60-persistent-b43-mac.rules is processed. In my case, the interface is wlan13,
not wlan0. After I manually modified 60-..., then the new address is applied.
I'm still working on this problem.

Thanks again for the help.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[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 Vista
> 3) Boot Parted Magic from a USB drive
> 4) Start the network in Parted Magic, ask it to use wireless, and then
> attempt to connect to my normal SSID, which at this point sees the
> SSID, but cannot connect due to an apparent DHCP lease error
> 5) Start the network in Parted Magic again, which this time fails with
> a generic error and does not show any SSID's (starting it a second
> time is necessary to reproduce the problem)
> 6) Reboot
> 7) Resume Vista
> 8) At this point, Vista loses connectivity to the wireless network
> 9) Reboot Vista
> 10) Vista still cannot see any wireless networks
> 11) Shutdown
> 12) Remove power cord and battery and wait a bit
> 13) Boot Vista, and it now works and sees the network
> 
> As you just eluded to, it seems that the power-down and battery
> removal is necessary
> What do you think is the culprit here?

You should never hibernate one OS and run a different one. That is a
prescription for disaster. Although there is nothing in the BCM4312 that can be
changed, Vista could set a given state in the BIOS that is destroyed by booting
Linux. Fortunately, this info seems to be in volatile memory, thus the power off
and battery removal fixes it.

You might look at the BIOS settings to see if there is a "Wake On LAN" option
for the wireless. It should be off.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[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 done that. A power-down including
removal of the battery should completely put the device in the original 
condition.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[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 Parted Magic 4.9 from a USB flash drive, which uses the
> 2.6.32 linux kernel.
> I started up networking in Parted Magic and asked it to configure the
> wireless driver.
> 
> At first it found my normal SSID and I asked it to try to connect, but
> it failed.  I thought this was just a transient issue specific to
> Parted Magic and/or linux.
> 
> So I booted bank into Vista, only to see that although Vista reports
> everything as being fine with the card, no wireless networks are ever
> detected.  I have verified that the wireless networks that I expect
> indeed exist and are in range (the machine has not moved).
> 
> Is it possible that the b43 driver somehow corrupted the firmware/ROM
> of my card such that it does not function correctly?  Can I fix this?
> There is a DMA error (also shown below in context): b43-phy0 ERROR:
> Fatal DMA error: 0x0400, 0x, 0x, 0x,
> 0x, 0x

No, b43 did not corrupt your firmware. The firmware is not contained in
non-volatile memory. With a power-down, it goes away. There is an EEPROM
containing some initial values, but changing that requires specific actions
through the sysfs, and does not happen accidentally. The wl and Windows drivers
have the firmware embedded in the driver. For copyright reasons, we cannot do
that, which is why there is external firmware.

Your DMA error is a known problem with 14e4:4315 devices with Netbooks and some
other systems with Intel processors and a Phoenix BIOS. Again, we have no fix.
With a 2.6.33 kernel, the system will seamlessly switch to PIO mode when the
fatal DMA error occurs.

Larry

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: Works wonderfully except at Barnes and Nobles.

[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 even at one site where there were >14 APs.
> FWIW it kept working flawlessly through dozens of suspend/resumes,
> something the eth0 driver couldn't do. Thanks for a robust and useful
> product!

Good to hear.

> I did notice that the system log had a very large number of entries like
> the following that coincided with the out of range usage. This isn't a
> question, just an observation that might perhaps be useful. It didn't
> seem to be a problem (this on a very recent Fedora C10).
> 
> Mar  2 23:19:56 host10 kernel: b43-phy0 ERROR: PHY transmission error
> Mar  2 23:19:56 host10 kernel: b43-phy0 ERROR: PHY transmission error
> Mar  2 23:19:56 host10 kernel: b43-phy0 ERROR: PHY transmission error

We don't know why the firmware is generating these errors. In general, they are
harmless.

> However, I do have a question - maybe this isn't the right list to ask, but
> not sure which one would be. We tried a Barnes and Noble store which
> had "free" WiFi access, but I couldn't get it to associate with the AP at
> all. This is one of those setups where it forces your initial browser
> access
> to an agreement page. I suppose this might have worked with Windows
> and subsequently the B43 device might have been able to associate. Can
> anyone explain why this didn't work, or a way to make it work?

You don't say what distro you are using, nor what kernel. It has been a while
since I connected to an AP using that method, but it worked with openSUSE 11.2
and what was probably a 2.6.32 kernel. With the KDE flavor of NetworkManager's
applet, I created a connection to the AP, then used the applet to connect to it.
Once associated and an IP was obtained with DHCP, I launched the browser, and up
came the sign-in page. This was at a Starbucks where the service was not free,
so I did go any further. Internet access was not that important at the time.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

[PATCH V3] ssb: Implement virtual SPROM

[Larry Finger]

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 address. The
solution is to use a file in /lib/firmware/ssb, which has some "random"
information generated by /bin/dbus-uuidgen. This file is loaded using the
asynchronous firmware facility and a MAC address is generated from those
data. To prevent multiple devices in a single box from having the same
MAC address, the last two digits are replaced by the bus numbers of the
device.

Signed-off-by: Larry Finger 
---

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 loading asynchronous.
V3 - eliminate the need for a special external utility
   - set for unique MAC address even if a box has more than one of these
 devices

Index: wireless-testing/drivers/ssb/pci.c
===
--- wireless-testing.orig/drivers/ssb/pci.c
+++ wireless-testing/drivers/ssb/pci.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "ssb_private.h"
 
@@ -613,6 +614,120 @@ static int sprom_extract(struct ssb_bus
return 0;
 }
 
+static void ssb_vsprom_load_failed(void)
+{
+   printk(KERN_ERR "ssb: The BCM43XX device does not have an "
+   "SPROM built in. Use the command\n");
+   printk(KERN_ERR " 'mkdir -p /lib/firmware/ssb ; /bin/dbus-uuidgen"
+   " > /lib/firmware/ssb/mac_addr'\n");
+   printk(KERN_ERR " to generate the required file.\n");
+}
+
+static inline u8 ascii_to_bin(u8 input)
+{
+   /* return the binary value of the ASCII char in the low nibble */
+   return (input <= 0x39) ? input & 0xF : (input - 0x27) & 0xF;
+}
+
+static void ssb_get_vsprom(const struct firmware *fw, void *context)
+{
+   /* Second part of asynchronous firmware load */
+   int i;
+   struct ssb_bus *bus = context;
+   struct ssb_sprom *sprom = &bus->sprom;
+   u8 buf2[8];
+   char *name;
+
+   if (!fw) {
+   ssb_vsprom_load_failed();
+   return;
+   }
+   /* Get values extracted from SPROM. If sprom_extract_r8() is changed,
+* this section must be changed as well. For any device with 5GHz
+* capability, some variables will have to be changed.
+*/
+   sprom->revision = 8;
+   sprom->boardflags_lo = 0x0A01;
+   sprom->boardflags_hi = 0x0006;
+   sprom->boardflags2_lo = 0x;
+   sprom->boardflags2_hi = 0x;
+   sprom->ant_available_a = 0x00;
+   sprom->ant_available_bg = 0x03;
+   sprom->maxpwr_bg = 0x4A;
+   sprom->itssi_bg = 0x3E;
+   sprom->maxpwr_a = 0xFF;
+   sprom->itssi_a = 0xFF;
+   sprom->maxpwr_ah = 0xFF;
+   sprom->maxpwr_al = 0xFF;
+   sprom->gpio0 = 0x83;
+   sprom->gpio1 = 0xFF;
+   sprom->gpio2 = 0xFF;
+   sprom->gpio3 = 0xFF;
+   sprom->tri2g = 0x6C;
+   sprom->tri5g = 0x00;
+   sprom->tri5gl = 0xFF;
+   sprom->tri5gh = 0xFF;
+   sprom->rxpo2g = 0xFA;
+   sprom->rxpo5g = 0xFF;
+   sprom->rssismf2g = 0x0F;
+   sprom->rssismc2g = 0x00;
+   sprom->rssisav2g = 0x00;
+   sprom->bxa2g = 0x00;
+   sprom->rssismf5g = 0x0F;
+   sprom->rssismc5g = 0x0F;
+   sprom->rssisav5g = 0x07;
+   sprom->bxa5g = 0x03;
+   sprom->pa0b0 = 0x1a57;
+   sprom->pa0b1 = 0xF98A;
+   sprom->pa0b2 = 0xFE91;
+   sprom->pa1b0 = 0x;
+   sprom->pa1b1 = 0x;
+   sprom->pa1b2 = 0x;
+   sprom->pa1lob0 = 0x;
+   sprom->pa1lob1 = 0x;
+   sprom->pa1lob2 = 0x;
+   sprom->pa1hib0 = 0x;
+   sprom->pa1hib1 = 0x;
+   sprom->pa1hib2 = 0x;
+   sprom->cck2gpo = 0x;
+   sprom->ofdm2gpo = 0x0002;
+   sprom->ofdm5glpo = 0x;
+   sprom->ofdm5gpo = 0x;
+   sprom->ofdm5ghpo = 0x;
+   memset(sprom->et0mac, 0xFF, 6);
+   memset(sprom->et1mac, 0xFF, 6);
+
+   if (fw->size != 33) {
+   printk(KERN_ERR "ssb: The MAC address file has the wrong"
+  " size\n");
+   goto out;
+   }
+   /* Input MAC address data in ASCII - get low nibble in binary */
+   for (i = 0 ; i < 8; i++) {
+   u8 tmp = ascii_to_bin(fw->data[2 * i]);
+   u8 tmp1 = ascii_to_bin(fw->data[2 * i + 1]);
+   buf2[i] = tmp << 4 | tmp1;
+   }
+   /* make su

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

[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 through the standard ioctl calls.
> Just like how ifconfig and ip can do.

Will someone please write me udev rule(s) that do the following:

1. Detect a MAC address of FF:FF:FF:FF:FF:FF
2. If this is the first time for this bus address, then generate a random MAC
address with the bus address encoded in it.
3. Preserve the address for future reloads
4. Load the saved address into the device.
5. Do the above with only standard external commands - no new programs

My skills with udev are not up to the task.

I now have code running that uses the firmware load facility to read a
file created by /bin/dbus-uuidgen to create a MAC address that will satisfy the
requirements. If the file is needed but not available, then the user is prompted
with the commands needed to create it.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[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 reads the file, then
modifies it using the bus address.

I think this process would create a persistent MAC address that is unique within
the box, with a small probability of being duplicated on another machine.

Larry

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[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
> for any of these devices. And even if you could reorder the devices on the 
> bus or whatever.
> What would happen? The card would get a new MAC address. That's all. That's 
> acceptable.
> 
> The kernel would (for example) just set the mac address to all-ones. Udev 
> would
> notice this (invalid) mac address and reassign a new persistent one to the 
> device. It then
> stores the address on the harddisk.

What ensures that this persistent name would be unique?

> In fact, if we implement a mechanism in the kernel, we have _exactly_ the 
> same problem.
> However, currently Larry's patches just ignore that problem and assume that 
> there's only
> one card in the system anyway.

As I said in a posting a few minutes ago, that problem is solved.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[Larry Finger]

On 03/22/2010 01:28 AM, Calvin Walton wrote:
> 
> I'm curious, how would this firmware-loading scheme deal with having
> multiple cards of this type installed? This seems like an unusual
> situation, but it looks like this patch will cause all of the cards to
> start up with the same MAC address due to the fixed filename.

I have a workaround for this problem based on the bus address of the device.

> Instead of using a firmware file to load in the MAC address, might it be
> possible to move the persistent MAC setting to a simple udev rule which
> generates a persistent MAC address, saves it, then sets it each boot
> using a command like "ip link set wlan0 address XX:XX:XX:XX:XX:XX" ?
> 
> This would remove the need to have this "fake" firmware file available
> at boot, provided that the driver can handle leaving the address
> unconfigured until userspace gets around to setting it. As well, it
> could be written to work with multiple cards easily, saving a different
> MAC for each.

Does anyone have any suggestions on what characteristic could be used to
generate a unique MAC address for a box in a udev rule? Unless someone proposes
a workable solution, I will push V3 of my patch with the bus address change
noted above.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[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, this presents
>>> a problem in the generation of a unique, reproducible MAC address. The
>>> solution has been to create a utility that generates a virtual SPROM
>>> image with a random MAC address. This image is stored in the firmware
>>> area, and loaded using the asyncronous firmware load facility.
>>
>> I'm curious, how would this firmware-loading scheme deal with having
>> multiple cards of this type installed? This seems like an unusual
>> situation, but it looks like this patch will cause all of the cards to
>> start up with the same MAC address due to the fixed filename.
>>
>> Instead of using a firmware file to load in the MAC address, might it be
>> possible to move the persistent MAC setting to a simple udev rule which
>> generates a persistent MAC address, saves it, then sets it each boot
>> using a command like "ip link set wlan0 address XX:XX:XX:XX:XX:XX" ?
>>
>> This would remove the need to have this "fake" firmware file available
>> at boot, provided that the driver can handle leaving the address
>> unconfigured until userspace gets around to setting it. As well, it
>> could be written to work with multiple cards easily, saving a different
>> MAC for each.
>>
>> Some thoughts for your consideration,
>>
> 
> I think this actually is a very good idea.
> This way we could live without a user-supplied sprom image, which I would 
> _really_
> prefer. 

Avoiding the use of a new user-space program would be desirable, but I cannot
think of any way that a udev rule could distinguish one card from another. If we
had any unique features such as a serial number, then we wouldn't need user
space at all. Any suggestions?

Larry


___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

[PATCH V2] ssb: Implement virtual SPROM on disk

[Larry Finger]

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 address. The
solution has been to create a utility that generates a virtual SPROM
image 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 
---

Michael,

I think this patch eliminates the need for the fallback sprom code; however,
I have not touched that facility yet.

Larry
---
V2 - make virstual SPROM loading asynchronous.

Index: wireless-testing/drivers/ssb/pci.c
===
--- wireless-testing.orig/drivers/ssb/pci.c
+++ wireless-testing/drivers/ssb/pci.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "ssb_private.h"
 
@@ -613,6 +614,53 @@ static int sprom_extract(struct ssb_bus
return 0;
 }
 
+static void ssb_vsprom_load_failed(void)
+{
+   printk(KERN_ERR "ssb: The BCM43XX device does not have an "
+  "SPROM built in, and the virtual SPROM file is not"
+  " available.\n");
+   printk(KERN_ERR "ssb: Please go to "
+  "http://wireless.kernel.org/en/users/Drivers/b43 "
+  "and download the utility to create the file.\n");
+}
+
+static void ssb_get_vsprom(const struct firmware *fw, void *context)
+{
+   /* Second part of asynchronous firmware load */
+   int i;
+   u16 *buf;
+   size_t size = SSB_SPROMSIZE_WORDS_R4;
+   struct ssb_bus *bus = context;
+
+   if (!fw) {
+   ssb_vsprom_load_failed();
+   return;
+   }
+   buf = kcalloc(size, sizeof(u16), GFP_KERNEL);
+   if (!buf) {
+   printk(KERN_ERR "ssb: no memory for virtual sprom\n");
+   goto out;
+   }
+   if (fw->size != size * 2) {
+   printk(KERN_ERR "ssb: The virtual SPROM file has the wrong"
+  " size\n");
+   goto out_free;
+   }
+   for (i = 0; i < size; i++)
+   buf[i] = fw->data[2 * i + 1] << 8 | fw->data[2 * i];
+   if(sprom_check_crc(buf, size)) {
+   printk(KERN_ERR "ssb: Invalid CRC for virtual SPROM\n");
+   goto out_free;
+   }
+   sprom_extract(bus, &bus->sprom, buf, size);
+   printk(KERN_DEBUG "ssb: revision %d\n", bus->sprom.revision);
+
+out_free:
+   kfree(buf);
+out:
+   release_firmware(fw);
+}
+
 static int ssb_pci_sprom_get(struct ssb_bus *bus,
 struct ssb_sprom *sprom)
 {
@@ -620,8 +668,17 @@ static int ssb_pci_sprom_get(struct ssb_
int err = -ENOMEM;
u16 *buf;
 
-   if (!ssb_is_sprom_available(bus))
-   return -ENODEV;
+   if (!ssb_is_sprom_available(bus)) {
+   /* This device has no SPROM. Try for a virtual version */
+   err = request_firmware_nowait(THIS_MODULE,
+   FW_ACTION_HOTPLUG, "ssb/vsprom_image",
+   &bus->host_pci->dev, GFP_KERNEL, bus, ssb_get_vsprom);
+   if (err) {
+   ssb_vsprom_load_failed();
+   return err;
+   }
+   return 0;
+   }
 
buf = kcalloc(SSB_SPROMSIZE_WORDS_R123, sizeof(u16), GFP_KERNEL);
if (!buf)
Index: wireless-testing/drivers/net/wireless/b43/main.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/main.c
+++ wireless-testing/drivers/net/wireless/b43/main.c
@@ -4858,7 +4858,17 @@ static int b43_one_core_attach(struct ss
 static void b43_sprom_fixup(struct ssb_bus *bus)
 {
struct pci_dev *pdev;
+   int i;
 
+   /* The sprom contents may be loaded asynchronously. Check that the
+* revision is set before proceeding */
+   for (i = 0; i < 1000; i++) {
+   if (bus->sprom.revision)
+   break;
+   msleep(1);
+   }
+   if (i == 1000)
+   printk(KERN_INFO "b43: No sprom image loaded\n");
/* boardflags workarounds */
if (bus->boardinfo.vendor == SSB_BOARDVENDOR_DELL &&
bus->chip_id == 0x4301 && bus->boardinfo.rev == 0x74)
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

[PATCH] ssb: Implement virtual SPROM on disk

[Larry Finger]

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 address. The
solution has been to create a utility that generates a virtual SPROM
image 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 
---

Michael,

I think this patch eliminates the need for the fallback sprom code; however,
I have not touched that facility yet.

Larry
---

Index: wireless-testing/drivers/ssb/pci.c
===
--- wireless-testing.orig/drivers/ssb/pci.c
+++ wireless-testing/drivers/ssb/pci.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "ssb_private.h"
 
@@ -613,6 +614,39 @@ static int sprom_extract(struct ssb_bus
return 0;
 }
 
+static int ssb_get_vsprom(struct device *dev, u16 *buf, size_t size)
+{
+   /* Use the firmware load facility to get the disk image of an SPROM */
+   const struct firmware *blob;
+   int err;
+   int i;
+
+   err = request_firmware(&blob, "ssb/vsprom_image", dev);
+   if (err) {
+   printk(KERN_ERR "ssb: The BCM43XX device does not have an "
+  "SPROM built in, and the virtual SPROM file is not"
+  " available.\n");
+   printk(KERN_ERR "ssb: Please go to "
+  "http://wireless.kernel.org/en/users/Drivers/b43 "
+  "and download the utility to create the file.\n");
+   return err;
+   }
+   if (blob->size != size * 2) {
+   printk(KERN_ERR "ssb: The virtual SPROM file has the wrong"
+  " size\n");
+   return -ENOENT;
+   }
+   for (i = 0; i < size; i++)
+   buf[i] = blob->data[2 * i + 1] << 8 | blob->data[2 * i];
+   err = sprom_check_crc(buf, size);
+   if (err) {
+   printk(KERN_ERR "ssb: Invalid CRC for virtual SPROM\n");
+   return err;
+   }
+
+   return 0;
+}
+
 static int ssb_pci_sprom_get(struct ssb_bus *bus,
 struct ssb_sprom *sprom)
 {
@@ -620,8 +654,18 @@ static int ssb_pci_sprom_get(struct ssb_
int err = -ENOMEM;
u16 *buf;
 
-   if (!ssb_is_sprom_available(bus))
-   return -ENODEV;
+   if (!ssb_is_sprom_available(bus)) {
+   buf = kcalloc(SSB_SPROMSIZE_WORDS_R4, sizeof(u16),
+ GFP_KERNEL);
+   if (!buf)
+   return -ENOMEM;
+   bus->sprom_size = SSB_SPROMSIZE_WORDS_R4;
+   if (ssb_get_vsprom(&bus->host_pci->dev, buf, bus->sprom_size)) {
+   err = -ENODEV;
+   goto out_free;
+   }
+   goto extract;
+   }
 
buf = kcalloc(SSB_SPROMSIZE_WORDS_R123, sizeof(u16), GFP_KERNEL);
if (!buf)
@@ -653,6 +697,7 @@ static int ssb_pci_sprom_get(struct ssb_
   " SPROM CRC (corrupt SPROM)\n");
}
}
+extract:
err = sprom_extract(bus, sprom, buf, bus->sprom_size);
 
 out_free:
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[Larry Finger]

Some of the new implementations of BCM43xx devices do not have a
physical SPROM on the device. The necessary data for such a device
could be embedded in the kernel; however, we have a need to supply
a unique and reproducible MAC address.

This patch implements a user-space utility that has an embedded
Rev. 8 SPROM taken from a BCM4315. A random number generator is used
to create a MAC address that should be unique. To make this address
reproducible, it is written to the firmware directory where the PCI
initialization portion of ssb can read it. This program checks for
an existing virtual SPROM, and will operwrite it only when the appropriate
switch is used when starting the program.

Signed-off-by: Larry Finger 
---

Index: sprom/vsprom/vsprom.c
===
--- /dev/null
+++ sprom/vsprom/vsprom.c
@@ -0,0 +1,344 @@
+/*
+ * virtual SPROM image writer for broadcom 43xx wireless devices
+ *
+ * This program creates an on-disk image of an SPROM for those BCM43xx
+ * devices that do not have a built-in SPROM. The image is created from
+ * one obtained from a BCM4315 with a random MAC address.
+ *
+ * Copyright (c) 2010 Larry Finger 
+ *
+ * Some routines copied from b43-fwcutter, which is
+ *
+ * Copyright (c) 2005 Martin Langer ,
+ *   2005-2007 Michael Buesch 
+ *  2005 Alex Beregszaszi
+ *  2007 Johannes Berg 
+ *
+ * Other routines from ssb_sprom, which is
+ *
+ * Copyright (c) 2006-2008 Michael Buesch 
+ * Copyright (c) 2008 Larry Finger 
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials provided
+ *with the distribution.
+ *
+ *   THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ *   WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ *   OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *   DISCLAIMED. IN NO EVENT SHALL THE CONTRIBUTORS BE LIABLE FOR ANY
+ *   DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ *   DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
+ *   GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ *   INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
+ *   WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
+ *   OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *   EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "vsprom.h"
+
+static struct cmdline_args cmdargs;
+
+uint8_t crc8(uint8_t crc, uint8_t data)
+{
+   static const uint8_t t[] = {
+   0x00, 0xF7, 0xB9, 0x4E, 0x25, 0xD2, 0x9C, 0x6B,
+   0x4A, 0xBD, 0xF3, 0x04, 0x6F, 0x98, 0xD6, 0x21,
+   0x94, 0x63, 0x2D, 0xDA, 0xB1, 0x46, 0x08, 0xFF,
+   0xDE, 0x29, 0x67, 0x90, 0xFB, 0x0C, 0x42, 0xB5,
+   0x7F, 0x88, 0xC6, 0x31, 0x5A, 0xAD, 0xE3, 0x14,
+   0x35, 0xC2, 0x8C, 0x7B, 0x10, 0xE7, 0xA9, 0x5E,
+   0xEB, 0x1C, 0x52, 0xA5, 0xCE, 0x39, 0x77, 0x80,
+   0xA1, 0x56, 0x18, 0xEF, 0x84, 0x73, 0x3D, 0xCA,
+   0xFE, 0x09, 0x47, 0xB0, 0xDB, 0x2C, 0x62, 0x95,
+   0xB4, 0x43, 0x0D, 0xFA, 0x91, 0x66, 0x28, 0xDF,
+   0x6A, 0x9D, 0xD3, 0x24, 0x4F, 0xB8, 0xF6, 0x01,
+   0x20, 0xD7, 0x99, 0x6E, 0x05, 0xF2, 0xBC, 0x4B,
+   0x81, 0x76, 0x38, 0xCF, 0xA4, 0x53, 0x1D, 0xEA,
+   0xCB, 0x3C, 0x72, 0x85, 0xEE, 0x19, 0x57, 0xA0,
+   0x15, 0xE2, 0xAC, 0x5B, 0x30, 0xC7, 0x89, 0x7E,
+   0x5F, 0xA8, 0xE6, 0x11, 0x7A, 0x8D, 0xC3, 0x34,
+   0xAB, 0x5C, 0x12, 0xE5, 0x8E, 0x79, 0x37, 0xC0,
+   0xE1, 0x16, 0x58, 0xAF, 0xC4, 0x33, 0x7D, 0x8A,
+   0x3F, 0xC8, 0x86, 0x71, 0x1A, 0xED, 0xA3, 0x54,
+   0x75, 0x82, 0xCC, 0x3B, 0x50, 0xA7, 0xE9, 0x1E,
+   0xD4, 0x23, 0x6D, 0x9A, 0xF1, 0x06, 0x48, 0xBF,
+   0x9E, 0x69, 0x27, 0xD0, 0xBB, 0x4C, 0x02, 0xF5,
+   0x40, 0xB7, 0xF9, 0x0E, 0x65, 0x92, 0xDC, 0x2B,
+   0x0A, 0xFD, 0xB3, 0x44, 0x2F, 0xD8, 0x96, 0x61,
+   0x55, 0xA2, 0xEC, 0x1B, 0x70, 0x87, 0xC9, 0x3E,
+   0x1F, 0xE8, 0xA6, 0x51, 0x3A, 0xCD, 0x83, 0x74,
+   0xC1, 0x36, 0x78, 0x8F, 0xE4, 0x13, 0x5D, 0xAA,
+   0x8B, 0x7C, 0x32, 0xC5, 0xAE, 0x59, 0x17, 0xE0,
+   0x2A, 0xDD, 0x93, 0x64, 0x

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

[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, 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 incorporate 
>>>> the
>>>> data except for the need to have a unique, reproducible MAC.
>>>
>>> Where does the data usually come from in these devices?
>>
>> It comes from the SPROM, which is missing in the devices in question. 
>> Broadcrap
>> wanted to save a few pennies.
> 
> Right, but they have to support getting the data somehow on for example
> windows even if there's no sprom. Do we know where it comes from then?

In the Linux driver and likely in the Windows driver, the SPROM data is read
from the SPROM and encoded into a set of tagged strings. After that, the actual
SPROM is ignored. I have not completed the RE on this area, but it looks as if
they have a set of "canned" data that is copied into the area. How they handle a
MAC is not yet understood.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[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 loading mechanism of the kernel
> for loading the blob into the kernel.

It has nothing to do with firmware, but the existing fwcutter has all the parts
to generate files in the firmware directory, which is a good place to put this
virtual SPROM.
> 
>> I have chosen to implement this in
>> fwcutter rather than ssb_sprom because the ordinary user will not have 
>> access to
>> ssb_sprom;
> 
> Huh? ssb-sprom is GPL software. I have no problem relicensing it under BSD or
> even something more liberal. I don't see a problem for "ordinary users" here.

It has nothing to do with the license. My distro, openSUSE, packages fwcutter
along with a script that uses wget to download the Broadcom drivers and extract
firmware for both b43 and b43legacy. The average user only has to execute that
script. Of course, the package could include both fwcutter and ssb_sprom
programs, but that would make a bigger change to the openSUSE package than just
a patch to fwcutter. I suspect that other distros use similar packages.

> Well, but that version won't do anything on the SPROM, too.

Yes, but if fwcutter were modified, it could write the virtual SPROM file.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[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 to be changed to handle some of the newer
>> devices do not have an on-board SPROM. It would be trivial to incorporate the
>> data except for the need to have a unique, reproducible MAC.
> 
> Where does the data usually come from in these devices?

It comes from the SPROM, which is missing in the devices in question. Broadcrap
wanted to save a few pennies.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[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 incorporate the
data except for the need to have a unique, reproducible MAC.

I am proposing to solve this problem using the following steps:

(1) Modify b43-fwcutter to take data from an existing SPROM, modify the MAC by
replacing the last 3 octets with random numbers, and write the resulting file to
/lib/firmware/b43. Fortunately, all affected devices seem to have Revision 8
SPROMS, which makes preparation easier. All such devices will need to use the
calibration parameters of the device from which the prototype SPROM was copied,
but that should not be a serious problem. I have chosen to implement this in
fwcutter rather than ssb_sprom because the ordinary user will not have access to
ssb_sprom; however, they do have a version of fwcutter supplied by the distro.
Unconditionally writing an additional small file to the firmware directory when
extracting firmware is small overhead and it will be transparent to the user of
whatever mechanism the distro uses. The routines needed to calculate the CRC,
etc. have been copied into fwcutter from ssb_sprom. A version of this code is
already running.

(2) Use the steps in http://bcm-v4.sipsolutions.net/802.11/IsSpromAvailable to
determine if the device has an SPROM. If not, then use the kernel's firmware
loading mechanism to get the contents of the file prepared in step 1. This file
has an 8-bit CRC, thus the validity of the file can be tested even though the
test is not very robust.

It it reasonable to keep the vendor portion of the MAC and only replace the
"serial number", or would it be better to randomize all 6 octants?

Is there a better way to load a file into the kernel?

Thanks,

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[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 unstable.
>>
>> When I load the module, a new interface wlan0 appears, but iwlist scan
>> says "Interface doesn't support scanning". Looks like the device isn't
>> properly initialized.
> 
> The issue was that CRDA is not yet in Debian, and thus the kernel
> needs to have CONFIG_WIRELESS_OLD_REGULATORY=y. With this setting, the
> interface can scan. There should be a clearer error message about this.

I feel that Debian should get their act together. The old regulatory method was
left in the kernel for several cycles so that the distros could adapt. Only
Debian failed to do so.

> However, the interface doesn't work. Most prominent error is:
> Mar 15 18:27:12 feather kernel: [  505.012549] b43-phy0 ERROR: PHY 
> transmission error
> (this is with he chip forced to PIO).

Are there lots of PHY Transmission errors, os just a few? We have never
understood why these errors occur in the firmware. What version are you using?

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Even worse problems with BCM4312 on Netbooks

[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 the logging console, but it does not seem to be a kernel panic - flashing
CAP and NUM lock leds do not seem to happen.

One other thing - this freeze occurs even if the firmware is not available.

The kernel in question is 2.6.33, but there is also a report of problems with a
2.6.30 kernel. I'm not sure if that one has the LP PHY code backported, or not.
John might know.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[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 
---

John,

This fixes a build error in wireless-testing - "git describe" lists
it as v2.6.34-rc1-47014-g33b6b57.

Larry
---
 
Index: wireless-testing/drivers/ssb/driver_chipcommon.c
===
--- wireless-testing.orig/drivers/ssb/driver_chipcommon.c
+++ wireless-testing/drivers/ssb/driver_chipcommon.c
@@ -370,6 +370,7 @@ u32 ssb_chipco_gpio_control(struct ssb_c
 {
return chipco_write32_masked(cc, SSB_CHIPCO_GPIOCTL, mask, value);
 }
+EXPORT_SYMBOL(ssb_chipco_gpio_control);
 
 u32 ssb_chipco_gpio_intmask(struct ssb_chipcommon *cc, u32 mask, u32 value)
 {
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[Larry Finger]

On 03/06/2010 04:07 AM, Marc Haber wrote:
> Hi,
> 
> On Fri, Mar 05, 2010 at 05:54:24PM +, Chris Vine wrote:
>> You can get the Ideapad to work by forcing use of the PIO however.
> 
> How exactly do I do this? I remember trying by adding some options to
> /etc/modprobe.d/b43, but the module didn't seem to understand this. I
> don't have the ideapad at hand at the moment, so I cannot look, but I
> can try tonight.

Unless you are getting the DMA error, choosing PIO will not help. If you are
getting that error, it will say so in the dmesg output. In addition, it will
tell you exactly what to do. Note: In the 2.6.34 code, the interface will
automatically switch to PIO mode when a fatal DMA error occurs.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[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.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[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
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[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/bugreport.cgi?bug=536502).

I'm not an expert on the regulatory stuff, but if you do not have a list of
allowed frequencies listed as I posted, then I think that none are allowed.

There was compatibility code kept in the kernel for several cycles so that even
the slowest distros could get prepared. Perhaps the devs underestimated Debian.

Your best approach is to go to
http://linuxwireless.org/en/developers/Regulatory/CRDA, get and build a copy.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[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 module, a new interface wlan0 appears, but iwlist scan
>> says "Interface doesn't support scanning". Looks like the device isn't
>> properly initialized.
>>
> Silly question, but did you try to "up" (ifconfig wlan0 up) the
> interface before scanning?
> My b43 won't allow scanning either unless it is upped. i don't know if
> this behavior is intended (poke to the list) but it's not quite a problem.

If you control the device with NetworkManager, it will bring it up. If you are
controlling it manually, then either an explicit ifup is required, or it is set
implicitly in the control file. That is distro dependent. For openSUSE, that
file is /etc/sysconfig/network/ifcfg-wlan0 where there is a line that says

STARTMODE='XX', where XX is auto, ifplugd, manual, or off.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[Larry Finger]

On 03/04/2010 11:54 AM, Marc Haber wrote:
> 
> What is this CRDA business? May I be missing something?

CRDA is the user-space implementation of the regulatory database.

You should see the allowed frequencies in this form:

cfg80211: Calling CRDA to update world regulatory domain
cfg80211: World regulatory domain updated:
 (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
 (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm)
 (2457000 KHz - 2482000 KHz @ 2 KHz), (300 mBi, 2000 mBm)
 (2474000 KHz - 2494000 KHz @ 2 KHz), (300 mBi, 2000 mBm)
 (517 KHz - 525 KHz @ 4 KHz), (300 mBi, 2000 mBm)
 (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 2000 mBm)

If not, then you need to install the crda package, or whatever Debian calls it.

Of course, for the BCM4312, you only need the 2.4 GHz band.

I had not tested it for a while, but the wl driver built for me on 2.6.33. There
were some warnings, but nothing serious.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[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 specs, 
> probably).

I have nearly finished the update on the code section of the specs page at
http://bcm-v4.sipsolutions.net/PCI-E. The part that is not done involves the
sections that read an address from the SPROM and perform operations on that 
address.

I found that the chip common registers are mapped at 12K for newer cores on
PCIe. This explains the 0x3XXX addresses. Similarly, the PCIe registers are
mapped at 8K - the 0x2XXX addresses. The SPROM is shadowed at 4K or 0x1XXX.

Larry

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[Larry Finger]

On 03/03/2010 06:47 PM, Gábor Stefanik wrote:
> On Thu, Mar 4, 2010 at 1:30 AM, Larry Finger  
> 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 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 specs, 
>>> probably).
>>
>> I have nearly finished the update on the code section of the specs page at
>> http://bcm-v4.sipsolutions.net/PCI-E. The part that is not done involves the
>> sections that read an address from the SPROM and perform operations on that 
>> address.
>>
>> I found that the chip common registers
> 
> Do you mean the ChipCommon registers or the Backplane common registers?

Definitely, it is the chipcommon registers.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[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 of 0xcbb to offset 0x618
> is also missing - I seem to remember that this change has been tried
> already, to no avail; but it may be a prerequisite of the real fix.
> 2. Just before the SPROM readout, we are missing a "Set 0x8000 in
> MMIO offset 0x280a". This looks curiously like "PCI-E Miscellaneous
> Configuration", from http://bcm-v4.sipsolutions.net/PCI-E - and
> indeed, the value read out from 0x280a is identical to offset 0xa in
> my SPROM. So, the right thing to do here is probably "Switch to the
> PCIE core, set 0x8000 in MIMO offset 0x80a (or maybe 0x1000a?), switch
> back to ChipCommon". I don't know what core is active during this
> write, as mmiotrace doesn't catch pci_read/write_config_dword calls.
> Larry, do you know a way to monitor PCI config space access in a way
> that can be matched (e.g. using timestamps) to the MMIO trace?

The printk's I sent yesterday can have timing info, but the timestamps would not
be exactly coordinated - printk values seem to be generated when logged, not
when requested.

> 3. Right after the SPROM is read, wl writes zeros to MMIO offsets
> 0x58 and 0x5c (32-bit), then does the PMU setup. These are not valid
> registers for ChipCommon and PCIE, but for 802.11, they fall directly
> into the DMA area! So, if these writes happened with the 802.11 core
> active, they are probably significant.

That sounds promising. I think I found the section, which will have the
following specs:

 1. If the Chip Common revision >= 20
  a. Save the current core index
  a. Set core to chip common
  a. Write 0 to GPIO Pullup (register 0x58)
  a. Write 0 to GPIO Pulldown (register 0x5C)
  a. Restore the original core
 1. If PMU Control Enabled
  a. Init the PMU
  ...

A quick look ar the code suggests this should go into ssb_chipcommon_init() just
after the return for not having a chip common. In addition, chip common will
already be selected, thus that part can be skipped.


> I second Larry's question: where are the specs for the PMU init code?

>From what Michael replied, they do not exist in a public place other that the
reference code for embedded systems. I have started them - there is now a PMU
Init page and I'll fill them in as I can. If you have a specific routine, let me
know.

Larry


___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[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
>>>> -In ssb_pmu_init, replace 0x4325 with 0x4312.
>>>
>>> Uh, wait a second. Do _all_ cards that show the behavior have a PMU on the 
>>> SSB?
>>> If so, you should really make sure the PMU setup is correct. If the PMU
>>> cuts power to the device at inappropriate times, it sure does result in DMA 
>>> errors (and
>>> silent MMIO errors).
>>
>> Yes, all of the LP PHY 14e4:4315 devices have a PMU. Mine shows "Found rev 1 
>> PMU
>> (capabilities 0x02A62F01)". As I recall, at least one of the problem devices
>> shows the same capabilities.
> 
> *HINT HINT HINT* ;)
> Please make sure the PMU code really is correct.

Where are the specs that were used to write the original code? I cannot find
them in either the V3 or V4 pages.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[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 a PMU on the 
> SSB?
> If so, you should really make sure the PMU setup is correct. If the PMU
> cuts power to the device at inappropriate times, it sure does result in DMA 
> errors (and
> silent MMIO errors).

Yes, all of the LP PHY 14e4:4315 devices have a PMU. Mine shows "Found rev 1 PMU
(capabilities 0x02A62F01)". As I recall, at least one of the problem devices
shows the same capabilities.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[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.
> 
> Well, it is not only undocumented, it's also far beyond the address space.
> SSB core address space goes from 0-0xFFF. And (more important!) the PCI 
> address
> space for MMIO is only 8k wide (I think there also are 4k devices).
> Are you really sure your dumping is correct? I suspect a bug in your mmio
> dumping tools.
> I'd say the "undocumented" register is a completely unrelated hardware access
> in a completely different device that just happens to be mapped right after 
> ssb.

There are definite instances where the vendor driver writes beyond 0xFFF. I'm
pretty sure that some models shadow EEPROM above 0x1000. I don't know about 
0x280A.

Larry

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[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 4312 and 4325, at least according to
> the MMIO trace produced using wl. Or maybe the if-branch is the
> wrong-way around - only Larry can tell.)

The latest Broadcom driver has changed this section. The new specs should be:

 1. If the pmu revision is 1
   a. Clear bit 0x200 in the PMU control register
 1. Otherwise
   a. Set bit 0x200 in the PMU control register

> BTW does anyone know of a way to trace pci_read/write_config_dword
> calls? Mmiotrace doesn't capture these.

The attached patch will log PCI config reads/writes to the system logs.

Larry

Index: wireless-testing/drivers/pci/access.c
===
--- wireless-testing.orig/drivers/pci/access.c
+++ wireless-testing/drivers/pci/access.c
@@ -24,6 +24,8 @@ static DEFINE_SPINLOCK(pci_lock);
 #define PCI_word_BAD (pos & 1)
 #define PCI_dword_BAD (pos & 3)
 
+static void pci_bus_log_buf(char *buf);
+
 #define PCI_OP_READ(size,type,len) \
 int pci_bus_read_config_##size \
(struct pci_bus *bus, unsigned int devfn, int pos, type *value) \
@@ -31,11 +33,14 @@ int pci_bus_read_config_##size \
int res;\
unsigned long flags;\
u32 data = 0;   \
+   char buf[80];   \
if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER;   \
spin_lock_irqsave(&pci_lock, flags);\
res = bus->ops->read(bus, devfn, pos, len, &data);  \
*value = (type)data;\
spin_unlock_irqrestore(&pci_lock, flags);   \
+   sprintf(buf, "Read 0x%X from pos 0x%X\n", data, pos);   \
+   pci_bus_log_buf(buf);   \
return res; \
 }
 
@@ -45,10 +50,13 @@ int pci_bus_write_config_##size \
 {  \
int res;\
unsigned long flags;\
+   char buf[80];   \
if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER;   \
spin_lock_irqsave(&pci_lock, flags);\
res = bus->ops->write(bus, devfn, pos, len, value); \
spin_unlock_irqrestore(&pci_lock, flags);   \
+   sprintf(buf, "Wrote 0x%X to pos 0x%X\n", value, pos);   \
+   pci_bus_log_buf(buf);   \
return res; \
 }
 
@@ -427,3 +435,8 @@ void pci_unblock_user_cfg_access(struct
spin_unlock_irqrestore(&pci_lock, flags);
 }
 EXPORT_SYMBOL_GPL(pci_unblock_user_cfg_access);
+
+static void pci_bus_log_buf(char *buf)
+{
+   printk(KERN_DEBUG "%s", buf);
+}
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[Larry Finger]

Subject: Make b43 driver fall back gracefully to PIO mode after fatal DMA errors
From: Linus Torvalds 
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 user to do it, so rather than have the user 
reload the module with a new flag, just make the driver do it 
automatically. We keep the message as an indication that something is 
wrong, but now just automatically fall back to the hopefully working PIO 
case.

Signed-off-by: Linus Torvalds 
---

John,

This version will work with wireless-testing.

Larry
---

Index: wireless-testing/drivers/net/wireless/b43/Kconfig
===
--- wireless-testing.orig/drivers/net/wireless/b43/Kconfig
+++ wireless-testing/drivers/net/wireless/b43/Kconfig
@@ -3,7 +3,6 @@ config B43
depends on SSB_POSSIBLE && MAC80211 && HAS_DMA
select SSB
select FW_LOADER
-   select SSB_BLOCKIO
---help---
  b43 is a driver for the Broadcom 43xx series wireless devices.
 
@@ -79,6 +78,14 @@ config B43_SDIO
 
  If unsure, say N.
 
+#Data transfers to the device via PIO. We want it as a fallback even
+# if we can do DMA.
+config B43_PIO
+   bool
+   depends on B43
+   select SSB_BLOCKIO
+   default y
+
 config B43_NPHY
bool "Pre IEEE 802.11n support (BROKEN)"
depends on B43 && EXPERIMENTAL && BROKEN
@@ -130,4 +137,12 @@ config B43_DEBUG
  for production use.
  Only say Y, if you are debugging a problem in the b43 driver 
sourcecode.
 
-
+config B43_FORCE_PIO
+   bool "Force usage of PIO instead of DMA"
+   depends on B43 && B43_DEBUG
+   ---help---
+ This will disable DMA and always enable PIO instead.
+
+ Say N!
+ This is only for debugging the PIO engine code. You do
+ _NOT_ want to enable this.
Index: wireless-testing/drivers/net/wireless/b43/main.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/main.c
+++ wireless-testing/drivers/net/wireless/b43/main.c
@@ -107,9 +107,9 @@ int b43_modparam_verbose = B43_VERBOSITY
 module_param_named(verbose, b43_modparam_verbose, int, 0644);
 MODULE_PARM_DESC(verbose, "Log message verbosity: 0=error, 1=warn, 
2=info(default), 3=debug");
 
-static int modparam_pio;
-module_param_named(pio, modparam_pio, int, 0444);
-MODULE_PARM_DESC(pio, "enable(1) / disable(0) PIO mode");
+int b43_modparam_pio = B43_PIO_DEFAULT;
+module_param_named(pio, b43_modparam_pio, int, 0644);
+MODULE_PARM_DESC(pio, "Use PIO accesses by default: 0=DMA, 1=PIO");
 
 static const struct ssb_device_id b43_ssb_tbl[] = {
SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_80211, 5),
@@ -1804,8 +1804,9 @@ static void b43_do_interrupt_thread(stru
   dma_reason[4], dma_reason[5]);
b43err(dev->wl, "This device does not support DMA "
   "on your system. Please use PIO instead.\n");
-   b43err(dev->wl, "Unload the b43 module and reload "
-  "with 'pio=1'\n");
+   /* Fall back to PIO transfers if we get fatal DMA 
errors! */
+   dev->use_pio = 1;
+   b43_controller_restart(dev, "DMA error");
return;
}
if (merged_dma_reason & B43_DMAIRQ_NONFATALMASK) {
@@ -4357,7 +4358,7 @@ static int b43_wireless_core_init(struct
 
if ((dev->dev->bus->bustype == SSB_BUSTYPE_PCMCIA) ||
(dev->dev->bus->bustype == SSB_BUSTYPE_SDIO) ||
-   modparam_pio) {
+   dev->use_pio) {
dev->__using_pio_transfers = 1;
err = b43_pio_init(dev);
} else {
@@ -4824,6 +4825,7 @@ static int b43_one_core_attach(struct ss
if (!wldev)
goto out;
 
+   wldev->use_pio = b43_modparam_pio;
wldev->dev = dev;
wldev->wl = wl;
b43_set_status(wldev, B43_STAT_UNINIT);
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[Larry Finger]

On 02/26/2010 09:27 AM, Gábor Stefanik wrote:
> On Fri, Feb 26, 2010 at 4:13 PM,   wrote:
>> On Feb 26, 2010 9:08am, Gábor Stefanik  wrote:
>>> That's odd... the error only occurs when you stop the mmiotrace?!
>> Yes, the error only occurs when I stop the mmiotrace with b43 loaded, or if
>> I load b43 outside of an mmiotrace.
>>
>>> BTW no need to load wl and b43 on the same kernel - the effect of
>>> loading wl survives a reboot or a kexec.
>> But then I cannot get you the mmiotrace as you requested. If all you're
>> after is the mmiotrace of b43 from cold and b43 from warm with wl magic, I
>> can do that now. I don't know how helpful this will be given that b43
>> appears to work so long as an mmiotrace is being performed.
> 
> The differences will still be there in the dump, even if something
> related to mmiotrace seemingly works around the bug.
> However, the most helpful logs would be the ones produced by wl
> itself, on a cold boot.

This thread is most interesting. Thanks for keeping it on the list, even though
the OP doesn't seem to know about "Reply All".

The fact that the 4315 doesn't get the DMA errors until MMIO tracing is turned
off suggests some kind of subtle timing difference. I'll look at the Broadcom
code to see if there are some delay statements in the interrupt handling, or if
their processing does things in a different order.

Larry

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: Turn broadcom 4311 into master mode

[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 is very desirable, but reliability much more so...

The current b43 is very stable. Performance will depend on which model you have.
BCM4311's run at speeds close to 802.11g maximum. BCM4306's are not that good.
BCM4318 units are in between.

I would not use my $500 laptop to do what a $40 AP/router does just as well or
better. I wrote the article to show that it could be done, not that I planned to
set up an AP.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: Turn broadcom 4311 into master mode

[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 the guide to install the drivers and the problem persists
> (http://linuxwireless.org/en/users/Drivers/b43/devices), also tried to
> use the drivers installed from repositories of ubuntu karmic desktop,
> with and without networkmanager running
> 
> The board is running fine, I have an broadcom 4311 rev 2 and running
> the driver b43
> 
> The kernel is from ubuntu, do I need any special compilation of it?
> 
> lsmod | grep b43
> b43   136552  0
> ssb40944  1 b43
> mac80211  209912  1 b43
> cfg80211  109144  2 b43,mac80211
> led_class   5256  1 b43
> 
> The driver creates two interfaces, with iwconfig:
> (other interfaces of my computer)
> ...
> wmaster0  no wireless extensions.
> 
> wlan0 IEEE 802.11bg  ESSID:""
>  Mode:Managed  Frequency:2.412 GHz  Access Point: Not-Associated
>  Tx-Power=20 dBm
>  Retry  long limit:7   RTS thr:off   Fragment thr:off
>  Encryption key:off
>  Power Management:off
>  Link Quality:0  Signal level:0  Noise level:0
>  Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
>  Tx excessive retries:0  Invalid misc:0   Missed beacon:0
> 
> Why I get "Invalid Argument"? The argument Isn't recognized...

That is not the correct way to set master or AP mode. One way is described in
the first post in the openSYSE Wireless Forum at http://tinyurl.com/yzlp7nm. It
contains the scripts needed to implement an AP using hostapd and DHCP. The
firewall is left to you. This way will work with b43 as long as hostapd is 0.6.0
or later. Version 0.5.X will not work.

Larry

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: b43 and WPA-PSK

[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 encryption working.  The output from
> iwlist scan is here:
> 
> https://forum.openwrt.org/viewtopic.php?pid=103469#p103469
> 
> I can't configure it to use WPA-PSK or WPA-PSK2; it simply doesn't see
> encryption.  I don't have any WEP APs around so I can't test around those.
>  It connects to open APs quite well.  (I haven't tested it much as the
> open AP is one of my neighbors, and I really don't want to steal his
> broadband.)

I was hoping someone else would answer your mail, but as no one has come
forward, I will try.

I am not an expert on openWRT. I am using the version of Kamikaze with a 2.4
kernel on a WRT54GL, but the firmware is out of the box.

What I do know is that the BCM4318 does work with WPA/WPA2, although my device
is Cardbus format in an old laptop. Using Broadcom's proprietary firmware, as
you seem to be doing, the encryption/decryption is done in the hardware.

I'm a little confused on your usage of the device. As an AP, I see no need to
scan. Are you using it as a station, or as a wireless bridge? In these modes,
would not the bridging code to eth0 get in the way?

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[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 :
>>> 2010/2/20 Larry Finger :
>>>> Some of the N PHYs need a revision in the handling of the PMU.
>>>>
>>>> Signed-off-by: Larry Finger 
>>>> ---
>>>>
>>>> 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.
>>>
>>> amterial you say? ;)
>>
>> Taht's not prat of the cimmot megasse, it is olny a ntoe to Jhon.
>> Deons't mtater eevn if it is cmolpelety jmulbed up.
> 
> Geez. The patch is already in the tree anyway, with the original typo.

I may be getting old and decrepit, but it's OK if the boys just want to have fun
with me.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[Larry Finger]

Some of the N PHYs need a revision in the handling of the PMU.

Signed-off-by: Larry Finger 
---

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/driver_chipcommon_pmu.c
===
--- wireless-testing.orig/drivers/ssb/driver_chipcommon_pmu.c
+++ wireless-testing/drivers/ssb/driver_chipcommon_pmu.c
@@ -332,6 +332,12 @@ static void ssb_pmu_pll_init(struct ssb_
case 0x5354:
ssb_pmu0_pllinit_r0(cc, crystalfreq);
break;
+   case 0x4322:
+   if (cc->pmu.rev == 2) {
+   chipco_write32(cc, SSB_CHIPCO_PLLCTL_ADDR, 0x000A);
+   chipco_write32(cc, SSB_CHIPCO_PLLCTL_DATA, 0x380005C0);
+   }
+   break;
default:
ssb_printk(KERN_ERR PFX
   "ERROR: PLL init unknown for device %04X\n",
@@ -417,6 +423,7 @@ static void ssb_pmu_resources_init(struc
 
switch (bus->chip_id) {
case 0x4312:
+   case 0x4322:
/* We keep the default settings:
 * min_msk = 0xCBB
 * max_msk = 0x7
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[Larry Finger]

Some of the N PHYs need a revision in the handling of the PMU.

Signed-off-by: Larry Finger 
---

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
===
--- wireless-testing.orig/drivers/ssb/driver_chipcommon_pmu.c
+++ wireless-testing/drivers/ssb/driver_chipcommon_pmu.c
@@ -332,6 +332,12 @@ static void ssb_pmu_pll_init(struct ssb_
case 0x5354:
ssb_pmu0_pllinit_r0(cc, crystalfreq);
break;
+   case 0x4322:
+   if (cc->pmu.rev == 2) {
+   chipco_write32(cc, SSB_CHIPCO_PLLCTL_ADDR, 0x000A);
+   chipco_write32(cc, SSB_CHIPCO_PLLCTL_DATA, 0x380005C0);
+   }
+   break;
default:
ssb_printk(KERN_ERR PFX
   "ERROR: PLL init unknown for device %04X\n",
@@ -417,6 +423,7 @@ static void ssb_pmu_resources_init(struc
 
switch (bus->chip_id) {
case 0x4312:
+   case 0x4322:
/* We keep the default settings:
 * min_msk = 0xCBB
 * max_msk = 0x7
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: skb_over_panic from b43 after a few hours

[Larry Finger]

On 02/19/2010 12:47 AM, Stefan Wahren wrote:
> Hi,
> 
> it's me again. The problem still exists. I had no idea to get it better
> reproduceable. Please tell me what information do you need to fix it.
> 
> Thanks in advice.
> 
> Stefan
> 
> Stefan Wahren schrieb:
>> Hi,
>>
>> i'm using OpenWRT on an ASUS WL-500gP V2 with the built-in Broadcom
>> BCM3302. After a few hours the b43 driver crashes with a skb_over_panic
>> and i need to reboot the device. The crash happend also, if there is no
>> traffic over the wireless interface. The wireless interface is
>> configured in AP mode and the encryption psk2.
>>
>> The used kernel (Linux OpenWrt 2.6.30.10 #1 Tue Feb 2 01:15:42 CET 2010
>> mips GNU/Linux) throws the following output:
>>
>> skb_over_panic: text:80c9a8e4 len:2374 put:2374 head:80e79000
>> data:80e79040 tail:0x80e79986 end:0x80e79980 dev:
>> Kernel bug detected[#1]:
>> Cpu 0
>> $ 0   :  1000f800 0079 0001
>> $ 4   : 802880c0 271f  271f
>> $ 8   : 4000  802959b0 0001
>> $12   : 000f 8022a1d0  7ffb537b
>> $16   : 00e79040 80e79040 0928 80e9a9a0
>> $20   : 80d84c80 0019 a0df7190 80ca1518
>> $24   : 0002 80151108
>> $28   : 80ea 80ea1e60 001b 8018c2d4
>> Hi: 
>> Lo: 0077
>> epc   : 8018c2d4 skb_put+0x74/0x90
>> Not tainted
>> ra: 8018c2d4 skb_put+0x74/0x90
>> Status: 1000f803KERNEL EXL IE
>> Cause : 00800024
>> PrId  : 00029029 (Broadcom BCM3302)
>> Modules linked in: pl2303 option ftdi_sio usb_storage usbserial ohci_hcd
>> nf_nat_
>> tftp nf_conntrack_tftp nf_nat_irc nf_conntrack_irc nf_nat_ftp
>> nf_conntrack_ftp i
>> pt_MASQUERADE iptable_nat nf_nat xt_NOTRACK iptable_raw xt_state
>> nf_conntrack_ip
>> v4 nf_defrag_ipv4 nf_conntrack ehci_hcd sd_mod pppoe pppox ipt_REJECT
>> xt_TCPMSS
>>   ipt_LOG xt_multiport xt_mac xt_limit iptable_mangle
>> iptable_filter ip_tables xt_
>> tcpudp x_tables ext2 ext3 jbd tun ppp_async
>> ppp_generic slhc vfat fat b43 nls_ut
>> f8 nls_iso8859_15 nls_iso8859_1
>> nls_cp850 nls_cp437 usbcore scsi_mod nls_base ma
>> c80211 cfg80211
>> compat_firmware_class compat crc_ccitt arc4 aes_generic deflate
>> ecb cbc
>> switch_robo switch_core diag
>> Process compirq/5-b43 (pid: 812, threadinfo=80ea, task=81f19188,
>> tls=000
>>0)
>> Stack :  80c9a8e4 0946 0946 80e79000 80e79040 80e79986
>> 80e79980
>> 80266f84 80d84c80 0019 80c9a8e4 80287b88 80286170 1000f800
>> 00fe
>> 80ea1fe0 f800 80d92d2c 80284000 80ca1518 7f816db4 0001
>> 80c7f400
>> 8000 0001 fffc 802c7860 0001 fffe efff
>> 80c87420
>> 81f19188 80c8 80e9ee08 8001c63c 80ea 80ea1f18 8021db88
>> 
>> ...
>> Call Trace:
>> [<8018c2d4>] skb_put+0x74/0x90
>> [<80c9a8e4>] b43_dma_rx+0x338/0x444 [b43]
>> [<80c87420>] b43_controller_restart+0x7a0/0x974 [b43]
>>

The traceback indicates a controller restart. Does your log show any reason for
that event? That may help me understand why skb->tail is past skb->end.

Larry

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[Larry Finger]

On 02/09/2010 02:04 PM, Rafał Miłecki wrote:
> Signed-off-by: Rafał Miłecki 
> ---
>  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 a/drivers/net/wireless/b43/phy_n.c 
> b/drivers/net/wireless/b43/phy_n.c
> index 19d4f11..49256bf 100644
> --- a/drivers/net/wireless/b43/phy_n.c
> +++ b/drivers/net/wireless/b43/phy_n.c
> @@ -72,6 +72,7 @@ static void b43_nphy_rf_control_override(struct b43_wldev 
> *dev, u16 field,
>   u16 value, u8 core, bool off);
>  static void b43_nphy_rf_control_intc_override(struct b43_wldev *dev, u8 
> field,
>   u16 value, u8 core);
> +static int nphy_channel_switch(struct b43_wldev *dev, unsigned int channel);
>  
>  static inline bool b43_empty_chanspec(struct b43_chanspec *chanspec)
>  {
> @@ -172,31 +173,6 @@ static void b43_radio_2055_setup(struct b43_wldev *dev,
>   udelay(300);
>  }
>  
> -/* Tune the hardware to a new channel. */
> -static int nphy_channel_switch(struct b43_wldev *dev, unsigned int channel)
> -{
> - const struct b43_nphy_channeltab_entry *tabent;
> -
> - tabent = b43_nphy_get_chantabent(dev, channel);
> - if (!tabent)
> - return -ESRCH;
> -
> - //FIXME enable/disable band select upper20 in RXCTL
> - if (0 /*FIXME 5Ghz*/)
> - b43_radio_maskset(dev, B2055_MASTER1, 0xFF8F, 0x20);
> - else
> - b43_radio_maskset(dev, B2055_MASTER1, 0xFF8F, 0x50);
> - b43_radio_2055_setup(dev, tabent);
> - if (0 /*FIXME 5Ghz*/)
> - b43_phy_set(dev, B43_NPHY_BANDCTL, B43_NPHY_BANDCTL_5GHZ);
> - else
> - b43_phy_mask(dev, B43_NPHY_BANDCTL, ~B43_NPHY_BANDCTL_5GHZ);
> - b43_chantab_phy_upload(dev, tabent);
> - b43_nphy_tx_power_fix(dev);
> -
> - return 0;
> -}
> -
>  static void b43_radio_init2055_pre(struct b43_wldev *dev)
>  {
>   b43_phy_mask(dev, B43_NPHY_RFCTL_CMD,
> @@ -3345,6 +3321,67 @@ static void b43_nphy_chanspec_setup(struct b43_wldev 
> *dev,
>   b43_nphy_spur_workaround(dev);
>  }
>  
> +/* http://bcm-v4.sipsolutions.net/802.11/PHY/N/SetChanspec */
> +static int b43_nphy_set_chanspec(struct b43_wldev *dev,
> + struct b43_chanspec chanspec)
> +{
> + struct b43_phy_n *nphy = dev->phy.n;
> +
> + const struct b43_nphy_channeltab_entry *tabent;
> +
> + u8 tmp;
> + u8 channel = chanspec.channel;
> +
> + if (dev->phy.rev >= 3) {
> + /* TODO */
> + }
> +
> + nphy->radio_chanspec = chanspec;
> +
> + if (chanspec.b_width != nphy->b_widht)
> + ; /* TODO: BMAC BW Set (chanspec.b_width) */
> +
> + /* TODO: use defines */
> + if (chanspec.b_width == 3) {
> + if (chanspec.sideband == 2)
> + b43_phy_set(dev, B43_NPHY_RXCTL,
> + B43_NPHY_RXCTL_BSELU20);
> + else
> + b43_phy_mask(dev, B43_NPHY_RXCTL,
> + ~B43_NPHY_RXCTL_BSELU20);
> + }
> +
> + if (dev->phy.rev >= 3) {
> + tmp = (chanspec.b_freq == 1) ? 4 : 0;
> + b43_radio_maskset(dev, 0x08, 0xFFFB, tmp);
> + /* TODO: PHY Radio2056 Setup (chan_info_ptr[i]) */
> + /* TODO: N PHY Chanspec Setup (chan_info_ptr[i]) */
> + } else {
> + tabent = b43_nphy_get_chantabent(dev, channel);
> + if (!tabent)
> + return -ESRCH;
> +
> + tmp = (chanspec.b_freq == 1) ? 0x0020 : 0x0050;
> + b43_radio_maskset(dev, B2055_MASTER1, 0xFF8F, tmp);
> + b43_radio_2055_setup(dev, tabent);
> + b43_nphy_chanspec_setup(dev, tabent, chanspec);
> + }
> +
> + return 0;
> +}
> +
> +/* Tune the hardware to a new channel */
> +static int nphy_channel_switch(struct b43_wldev *dev, unsigned int channel)
> +{
> + struct b43_phy_n *nphy = dev->phy.n;
> +
> + struct b43_chanspec chanspec;
> + chanspec = nphy->radio_chanspec;
> + chanspec.channel = channel;
> +
> + return b43_nphy_set_chanspec(dev, chanspec);
> +}
> +
>  static int b43_nphy_op_allocate(struct b43_wldev *dev)
>  {
>   struct b43_phy_n *nphy;
> diff --git a/drivers/net/wireless/b43/phy_n.h 
> b/drivers/net/wireless/b43/phy_n.h
> index e7acae2..26d01fe 100644
> --- a/drivers/net/wireless/b43/phy_n.h
> +++ b/drivers/net/wireless/b43/phy_n.h
> @@ -984,6 +984,7 @@ struct b43_phy_n {
>   u16 papd_epsilon_offset[2];
>   s32 preamble_override;
>   u32 bb_mult_save;
> + u8 b_widht;

Typo here?

>   struct b43_chanspec radio_chanspec;
>  
>   bool gain_boost;

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[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).
> So I'm now at kernel version 2.6.32 and the problem is somehow
> different (still related to kill switch).
> 
> The messages in this case are more clear (on ifconfig wlan0 ):
> 
> b43legacy ssb0:0: firmware: requesting b3legacy/ucode2.fw
> b43legacy ssb0:0: firmware: requesting b3legacy/pcm4.fw
> b43legacy ssb0:0: firmware: requesting b3legacy/b0g0initvals2.fw
> b43legacy-phy0: Loading firmware version 0x127, patch level 14 (2005-04-18 
> 02:36:27)
> b43legacy-phy0: Radio hardware status changed to DISABLED
> b43legacy-phy0: Radio turned on by software
> b43legacy-phy0: The hardware RF-kill button still turns the radio physically 
> off. Press th ebutton to turn it on.
> 
> Same suggestions applies ? Or was some load-time option added in 2.6.32 ?

There is no load-time option to ignore RFKILL, and as you have read, there never
will be.

I assume that your laptop has a mini-PCI BCM4303 card. Neither of my two devices
uses that format, nor do either of mine implement the "RF silent" input, which
is on pin 13, according to

http://www.interfacebus.com/MiniPCI_Pinout_124Pin.html

You did not see any logged rfkill messages with bcm43xx as it did not examine
this input. The hardware must have honored that input and suppressed the radio
whenever it was set.

If you generate a system with the RFKILL subsystem disabled, all that will
happen is that the messages will go away, and your radio will be silently
disabled on an intermittent basis. You need to discover why that input is being
generated? There could be a failure in the motherboard circuits that generate
the signal. There could be a bug in the software that processes whatever WMI
info that your system generates. WMI (Windows Management Interface) code handles
the functions of the top row of your keyboard that are generated by a fn+FX key.

One alternative would be to alter the MB or the card so that the "RF silent"
input cannot be changed. BTW, I have no idea if it is a high or a low here that
kills the radio. I suspect that the radio will be on if the pin is floating, but
that is a guess.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[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 do I do that ? Runtime ? Compile-time ?
>>
>> It needs to be compile time to elimionate that section of b43legacy.
> 
> Thanks. Is there a repository from which I can get *only*
> bcm43xx sources and compile against kernel headers ?
> I've seen this done with debian module-assistant tool...

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.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[Larry Finger]

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 do I do that ? Runtime ? Compile-time ?

It needs to be compile time to elimionate that section of b43legacy.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[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/DISABLED" messages.
>>
>> How does the ASUS implement that switch? Some laptops have a slide switch 
>> with
>> an on/off position, while others have a push button with software keeping 
>> track
>> of the state.
> 
> I can see no slide switch, nor sign on any key suggesting
> to have that purpose. It seems my problem was already reported here:
> 
> https://lists.berlios.de/pipermail/bcm43xx-dev/2008-November/004843.html
> 
> ... but the thread has no happy end (I add the author of that post in Cc).
> 
> Jorge, have you figured it out lately  ?

You could probably avoid the problems by disabling the RFKILL and RFKILL_INPUT
options.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[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 continually get disable-enable messages:
> 
> Feb  6 20:01:21 xtops kernel: [ 4910.000194] b43legacy-phy3: Radio hardware
> status changed to ENABLED
> Feb  6 20:01:46 xtops kernel: [ 4935.000441] __ratelimit: 3 messages 
> suppressed
> Feb  6 20:01:46 xtops kernel: [ 4935.000458] b43legacy-phy3: Radio hardware
> status changed to DISABLED
> 
> Sometimes this results in a disconnection.
-- snip --
> 
> Any hint on how to further debug or fix ?
> Thanks in advance.

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/DISABLED" messages.

How does the ASUS implement that switch? Some laptops have a slide switch with
an on/off position, while others have a push button with software keeping track
of the state.

Larry

PS: Your address bcm43xx-...@berios.de is wrong. You should use just
bcm43xx-...@lists.berlios.de.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[Larry Finger]

On 02/05/2010 10:27 AM, Gábor Stefanik wrote:
> On Fri, Feb 5, 2010 at 4:24 AM, Larry Finger  
> 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 radio and chanspec magic yet.
>>> ---
>>>  drivers/net/wireless/b43/phy_lp.c |2 +-
>>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/b43/phy_lp.c 
>>> b/drivers/net/wireless/b43/phy_lp.c
>>> index 185219e..61009ee 100644
>>> --- a/drivers/net/wireless/b43/phy_lp.c
>>> +++ b/drivers/net/wireless/b43/phy_lp.c
>>> @@ -2655,8 +2655,8 @@ static int b43_lpphy_op_switch_channel(struct 
>>> b43_wldev *dev,
>>>   if (err)
>>>   return err;
>>>   lpphy_set_analog_filter(dev, new_channel);
>>> - lpphy_adjust_gain_table(dev, channel2freq_lp(new_channel));
>>>   }
>>> + lpphy_adjust_gain_table(dev, channel2freq_lp(new_channel));
>>>
>>>   lpphy->channel = new_channel;
>>>   b43_write16(dev, B43_MMIO_CHANNEL, new_channel);
>>
>> Both the lpphy_set_analog_filter() and lpphy_adjust_gain_table() calls 
>> should be
>> outside the if statement. I changed the spec a little. It used to test "radio
>> enabled", but I have found that is always true for our driver.
>>
>> Larry
>>
>>
> 
> Isn't set_analog_filter() rev0/1-specific?

The new routines are described in

http://bcm-v4.sipsolutions.net/802.11/PHY/LP/TxFilterInit

http://bcm-v4.sipsolutions.net/802.11/PHY/LP/TxDigFiltUcodeRev2

The revised routines are:

http://bcm-v4.sipsolutions.net/802.11/PHY/LP/SetChanSpecLPPHY

http://bcm-v4.sipsolutions.net/802.11/PHY/LP/PR41573

Larry

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[Larry Finger]

On 02/05/2010 12:46 PM, Gábor Stefanik wrote:
> On Fri, Feb 5, 2010 at 7:09 PM, Larry Finger  
> wrote:
>> On 02/05/2010 10:41 AM, Gábor Stefanik wrote:
>>> On Fri, Feb 5, 2010 at 4:24 AM, Larry Finger  
>>> 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 radio and chanspec magic yet.
>>>>> ---
>>>>>  drivers/net/wireless/b43/phy_lp.c |2 +-
>>>>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>>>>
>>>>> diff --git a/drivers/net/wireless/b43/phy_lp.c 
>>>>> b/drivers/net/wireless/b43/phy_lp.c
>>>>> index 185219e..61009ee 100644
>>>>> --- a/drivers/net/wireless/b43/phy_lp.c
>>>>> +++ b/drivers/net/wireless/b43/phy_lp.c
>>>>> @@ -2655,8 +2655,8 @@ static int b43_lpphy_op_switch_channel(struct 
>>>>> b43_wldev *dev,
>>>>>   if (err)
>>>>>   return err;
>>>>>   lpphy_set_analog_filter(dev, new_channel);
>>>>> - lpphy_adjust_gain_table(dev, channel2freq_lp(new_channel));
>>>>>   }
>>>>> + lpphy_adjust_gain_table(dev, channel2freq_lp(new_channel));
>>>>>
>>>>>   lpphy->channel = new_channel;
>>>>>   b43_write16(dev, B43_MMIO_CHANNEL, new_channel);
>>>>
>>>> Both the lpphy_set_analog_filter() and lpphy_adjust_gain_table() calls 
>>>> should be
>>>> outside the if statement. I changed the spec a little. It used to test 
>>>> "radio
>>>> enabled", but I have found that is always true for our driver.
>>>>
>>>> Larry
>>>>
>>>>
>>>
>>> Isn't set_analog_filter() rev0/1-specific?
>>
>> It was in the 4.174.64.19 driver that I RE'd when you wrote the LP PHY code.
>> That as changed in 5.10.56.46, which I am now doing. It will take me a while 
>> to
>> complete the new routine "LP PHY TX Filter Init" and a routine that it calls.
>>
>> Certainly, there is no hurry that these changes be made. Whenever you or 
>> Rafał
>> have time. There is no guarantee that these changes will have any effect on 
>> the
>> LP PHY operations. Hitting a moving target is not easy.
>>
>> Larry
>>
> 
> Just out of curiosity, is 5.10.56.46 available anywhere (for firmware 
> reasons)?

I'm not sure what the driver version is, but a file with 508 ucode dated 6/26/09
is found at:

http://www.linksysbycisco.com/gpl/wrt610n_v2.00.00.05_us.tar.gz

The binaries are in directory wrt610n_v2.00.00.05_us/release/src/wl/linux/. I
used Daniel Lenski's script names b43_fwcutter.py can extract the firmware from
wl_apsta.o. Included are ucode_2w20 - Rev 20 802.11 cores have an SSLPN PHY.

I'm still looking for a file with 5XX firmware that is not a huge download. This
file contains everything needed to build the firmware for a WRT610N AP and is
356 MB. If anyone knows of a smaller file, please let me know.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[Larry Finger]

On 02/05/2010 10:41 AM, Gábor Stefanik wrote:
> On Fri, Feb 5, 2010 at 4:24 AM, Larry Finger  
> 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 radio and chanspec magic yet.
>>> ---
>>>  drivers/net/wireless/b43/phy_lp.c |2 +-
>>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/b43/phy_lp.c 
>>> b/drivers/net/wireless/b43/phy_lp.c
>>> index 185219e..61009ee 100644
>>> --- a/drivers/net/wireless/b43/phy_lp.c
>>> +++ b/drivers/net/wireless/b43/phy_lp.c
>>> @@ -2655,8 +2655,8 @@ static int b43_lpphy_op_switch_channel(struct 
>>> b43_wldev *dev,
>>>   if (err)
>>>   return err;
>>>   lpphy_set_analog_filter(dev, new_channel);
>>> - lpphy_adjust_gain_table(dev, channel2freq_lp(new_channel));
>>>   }
>>> + lpphy_adjust_gain_table(dev, channel2freq_lp(new_channel));
>>>
>>>   lpphy->channel = new_channel;
>>>   b43_write16(dev, B43_MMIO_CHANNEL, new_channel);
>>
>> Both the lpphy_set_analog_filter() and lpphy_adjust_gain_table() calls 
>> should be
>> outside the if statement. I changed the spec a little. It used to test "radio
>> enabled", but I have found that is always true for our driver.
>>
>> Larry
>>
>>
> 
> Isn't set_analog_filter() rev0/1-specific?

It was in the 4.174.64.19 driver that I RE'd when you wrote the LP PHY code.
That as changed in 5.10.56.46, which I am now doing. It will take me a while to
complete the new routine "LP PHY TX Filter Init" and a routine that it calls.

Certainly, there is no hurry that these changes be made. Whenever you or Rafał
have time. There is no guarantee that these changes will have any effect on the
LP PHY operations. Hitting a moving target is not easy.

Larry





___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: b43/b43legacy driver

[Larry Finger]

On 02/05/2010 08:23 AM, David Montero wrote:
> Thanks a lot!
> Now It's working properly. GREAT!
> Yes, you were right, it was in the blacklist. See below:
> 
> monte...@latosca:~$ more /etc/modprobe.d/blacklist-local.conf
> #blacklist b43
> #blacklist wl
> 
> I have commented these lines and it works.

You should have left the blacklist on wl. It and b43 are mutually incompatible.

You are still top posting! Please stop.

A. Because it interferes with the way that people normally read and process
information.

Q. Why is top posting wrong?

Larry

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: b43/b43legacy driver

[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 prefs that mixed up?

That does not matter. The HTML version should not be on the lists! Period!!

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[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 deletions(-)
> 
> diff --git a/drivers/net/wireless/b43/phy_lp.c 
> b/drivers/net/wireless/b43/phy_lp.c
> index 185219e..61009ee 100644
> --- a/drivers/net/wireless/b43/phy_lp.c
> +++ b/drivers/net/wireless/b43/phy_lp.c
> @@ -2655,8 +2655,8 @@ static int b43_lpphy_op_switch_channel(struct b43_wldev 
> *dev,
>   if (err)
>   return err;
>   lpphy_set_analog_filter(dev, new_channel);
> - lpphy_adjust_gain_table(dev, channel2freq_lp(new_channel));
>   }
> + lpphy_adjust_gain_table(dev, channel2freq_lp(new_channel));
>  
>   lpphy->channel = new_channel;
>   b43_write16(dev, B43_MMIO_CHANNEL, new_channel);

Both the lpphy_set_analog_filter() and lpphy_adjust_gain_table() calls should be
outside the if statement. I changed the spec a little. It used to test "radio
enabled", but I have found that is always true for our driver.

Larry

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: BCM4311/02 ABG disconnects on 2.6.32

[Larry Finger]

On 02/03/2010 01:37 PM, Yuval Hager wrote:
> 
> I just upgraded to the latest firmware, but there is no change. I am not 
> having any issues with this router while running 2.6.29 on this machine, or 
> 2.6.32 on another machine (using rt2x500pci). The router is Netgear WGR614V9, 
> and the firmware is V1.2.24_37.0.35.
> Also note that this "reason 3" only occures after the first association - 
> after that it just continues with the "no probe response" I got used to.

Based on a suggestion by Michael Buesch, I am trying a new version of the patch.
Does this one work for you?

Larry

===

Index: wireless-testing/drivers/net/wireless/b43/main.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/main.c
+++ wireless-testing/drivers/net/wireless/b43/main.c
@@ -3980,6 +3980,7 @@ static int b43_wireless_core_start(struc
}

/* We are ready to run. */
+   ieee80211_wake_queues(dev->wl->hw);
b43_set_status(dev, B43_STAT_STARTED);

/* Start data flow (TX/RX). */
@@ -4387,10 +4388,6 @@ static int b43_wireless_core_init(struct
b43_upload_card_macaddress(dev);
b43_security_init(dev);

-   ieee80211_wake_queues(dev->wl->hw);
-
-   ieee80211_wake_queues(dev->wl->hw);
-
b43_set_status(dev, B43_STAT_INITIALIZED);

 out:
Index: wireless-testing/drivers/net/wireless/b43legacy/main.c
===
--- wireless-testing.orig/drivers/net/wireless/b43legacy/main.c
+++ wireless-testing/drivers/net/wireless/b43legacy/main.c
@@ -2923,6 +2923,7 @@ static int b43legacy_wireless_core_start
goto out;
}
/* We are ready to run. */
+   ieee80211_wake_queues(dev->wl->hw);
b43legacy_set_status(dev, B43legacy_STAT_STARTED);

/* Start data flow (TX/RX) */


If b43 or b43legacy are deauthenticated or disconnected, there is a
possibility that a reconnection is tried with the queues stopped in
mac80211. To prevent this, start the queues before setting
STAT_INITIALIZED.

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 
Cc: Stable[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 be
applied to 2.6.33 with the automatic backport to 2.6.32.

Larry
---

Index: wireless-testing/drivers/net/wireless/b43/main.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/main.c
+++ wireless-testing/drivers/net/wireless/b43/main.c
@@ -3980,6 +3980,7 @@ static int b43_wireless_core_start(struc
}
 
/* We are ready to run. */
+   ieee80211_wake_queues(dev->wl->hw);
b43_set_status(dev, B43_STAT_STARTED);
 
/* Start data flow (TX/RX). */
@@ -4387,10 +4388,6 @@ static int b43_wireless_core_init(struct
b43_upload_card_macaddress(dev);
b43_security_init(dev);
 
-   ieee80211_wake_queues(dev->wl->hw);
-
-   ieee80211_wake_queues(dev->wl->hw);
-
b43_set_status(dev, B43_STAT_INITIALIZED);
 
 out:
Index: wireless-testing/drivers/net/wireless/b43legacy/main.c
===
--- wireless-testing.orig/drivers/net/wireless/b43legacy/main.c
+++ wireless-testing/drivers/net/wireless/b43legacy/main.c
@@ -2923,6 +2923,7 @@ static int b43legacy_wireless_core_start
goto out;
}
/* We are ready to run. */
+   ieee80211_wake_queues(dev->wl->hw);
b43legacy_set_status(dev, B43legacy_STAT_STARTED);
 
/* Start data flow (TX/RX) */

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

[PATCH] b43/b43legacy: Wake queues in wireless_core_start

[Larry Finger]

If b43 or b43legacy are deauthenticated or disconnected, there is a
possibility that a reconnection is tried with the queues stopped in
mac80211. To prevent this, start the queues before setting
STAT_INITIALIZED.

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 
Cc: Stable[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 be
applied to 2.6.33 with the automatic backport to 2.6.32.

Larry
---

Index: wireless-testing/drivers/net/wireless/b43/main.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/main.c
+++ wireless-testing/drivers/net/wireless/b43/main.c
@@ -3980,6 +3980,7 @@ static int b43_wireless_core_start(struc
}
 
/* We are ready to run. */
+   ieee80211_wake_queues(dev->wl->hw);
b43_set_status(dev, B43_STAT_STARTED);
 
/* Start data flow (TX/RX). */
@@ -4389,8 +4390,6 @@ static int b43_wireless_core_init(struct
 
ieee80211_wake_queues(dev->wl->hw);
 
-   ieee80211_wake_queues(dev->wl->hw);
-
b43_set_status(dev, B43_STAT_INITIALIZED);
 
 out:
Index: wireless-testing/drivers/net/wireless/b43legacy/main.c
===
--- wireless-testing.orig/drivers/net/wireless/b43legacy/main.c
+++ wireless-testing/drivers/net/wireless/b43legacy/main.c
@@ -2923,6 +2923,7 @@ static int b43legacy_wireless_core_start
goto out;
}
/* We are ready to run. */
+   ieee80211_wake_queues(dev->wl->hw);
b43legacy_set_status(dev, B43legacy_STAT_STARTED);
 
/* Start data flow (TX/RX) */
@@ -3343,6 +3344,7 @@ static int b43legacy_wireless_core_init(
b43legacy_security_init(dev);
b43legacy_rng_init(wl);
 
+   ieee80211_wake_queues(dev->wl->hw);
b43legacy_set_status(dev, B43legacy_STAT_INITIALIZED);
 
b43legacy_leds_init(dev);
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: BCM4311/02 ABG disconnects on 2.6.32

[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 
> 00:22:3f:18:89:5e by local choice (reason=3)), in addition to the "no probe 
> response" I was getting previously.
> The big change in these patches is that the system is able to get over it and 
> reconnect after the disconnection. 

The short-slot patch will only affect performance; however, the patch that
restarts the queues could certainly be the one that allows the system to
reconnect and continue. The surprising part is that I sent it earlier and was
told that it did not help.

Does your AP have the latest firmware? At
http://forums.wi-fiplanet.com/showthread.php?t=6536, reason 3 is listed as "The
access point went offline, deauthenticating the client." Other explanations are
likely possible. I have not checked the IEEE802.11 documents.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: BCM4311/02 ABG disconnects on 2.6.32

[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. That is, "iwlist wlan0 scan" finds nothing.
> 
> My other details are similar to Yuval's one — I've got the latest firmware, 
> the 
> problem appeared in 2.6.32, I've tested latest git without luck. Can't help 
> too 
> much, though, because there is no unprotected network over here (from which 
> laptop disconnects immediately), and on the protected one on-line time is too 
> large: at this session the first disconnect occured after 35 hours, the 
> second - 
> after half an hour after driver reset with ifconfig wlan0 down/up, the third 
> - 
> hour and an half after reset; this is not normal because I had no disconnects 
> before 2.6.32.

I installed my BCM4311/2 device to try to duplicate your results from above. I
found a problem with performance and have posted a patch for that. I set my AP,
which is a Linksys WRT54GL V1.1 running openWRT Kamikaze r16206 firmware. I set
my network to be unencrypted as  you said that made the failure to occur more
quickly. As I write this, my device has been running for 32 hours with no
dropouts. I cannot duplicate your results.

My system is wireless-testing 2.6.33-rc5 with the two patches below. Please add
them to your system and try again.

Larry

===


Index: wireless-testing/drivers/net/wireless/b43/main.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/main.c
+++ wireless-testing/drivers/net/wireless/b43/main.c
@@ -637,10 +637,17 @@ static void b43_upload_card_macaddress(s
 static void b43_set_slot_time(struct b43_wldev *dev, u16 slot_time)
 {
/* slot_time is in usec. */
-   if (dev->phy.type != B43_PHYTYPE_G)
+   /* This test used to exit for all but a G PHY. */
+   if (b43_current_band(dev->wl) == IEEE80211_BAND_5GHZ)
return;
-   b43_write16(dev, 0x684, 510 + slot_time);
-   b43_shm_write16(dev, B43_SHM_SHARED, 0x0010, slot_time);
+   b43_write16(dev, B43_MMIO_IFSSLOT, 510 + slot_time);
+   /* Shared memory location 0x0010 is the slot time and should be
+* set to slot_time; however, this register is initially 0 and changing
+* the value adversely affects the transmit rate for BCM4311
+* devices. Until this behavior is unterstood, delete this step
+*
+* b43_shm_write16(dev, B43_SHM_SHARED, 0x0010, slot_time);
+*/
 }

 static void b43_short_slot_timing_enable(struct b43_wldev *dev)
Index: wireless-testing/drivers/net/wireless/b43/b43.h
===
--- wireless-testing.orig/drivers/net/wireless/b43/b43.h
+++ wireless-testing/drivers/net/wireless/b43/b43.h
@@ -115,6 +115,7 @@
 #define B43_MMIO_TSF_2 0x636   /* core rev < 3 only */
 #define B43_MMIO_TSF_3 0x638   /* core rev < 3 only */
 #define B43_MMIO_RNG   0x65A
+#define B43_MMIO_IFSSLOT   0x684   /* Interframe slot time */
 #define B43_MMIO_IFSCTL0x688 /* Interframe space 
control */
 #define  B43_MMIO_IFSCTL_USE_EDCF  0x0004
 #define B43_MMIO_POWERUP_DELAY 0x6A8

Index: wireless-testing/drivers/net/wireless/b43/main.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/main.c
+++ wireless-testing/drivers/net/wireless/b43/main.c
@@ -3980,6 +3980,7 @@ static int b43_wireless_core_start(struc
}

/* We are ready to run. */
+   ieee80211_wake_queues(dev->wl->hw);
b43_set_status(dev, B43_STAT_STARTED);

/* Start data flow (TX/RX). */

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

[PATCH] b43: Fix regression from commit c7ab5ef

[Larry Finger]

Commit c7ab5ef9bcd281135c21b4732c9be779585181be entitled "b43: implement
short slot and basic rate handling" reduced the transmit throughput for
my BCM4311 device from 18 Mb/s to 0.7 Mb/s. The basic rate handling
portion is OK, the problem is in the short slot handling.

Prior to this change, the short slot enable/disable routines were never
called. Experimentation showed that the critical part was changing the
value at offset 0x0010 in the shared memory. This is supposed to contain
the 802.11 Slot Time in usec, but if it is changed from its initial value
of zero, performance is destroyed. On the other hand, changing the value
in the MMIO register corresponding to the Interframe Slot Time increased
performance from 18 to 22 Mb/s. A BCM4306/3 also shows dramatic
improvement of the transmit rate from 5.3 to 19.0 Mb/s.

Other changes in the patch include removal of the magic number 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 
Cc: Stable  [Any stable version back through 2.6.28]
---

John,

Although late in the cycle, this is 2.6.33 material, and should be applied
to kernels back to and including 2.6.28.

Thanks,

Larry
---

Index: wireless-testing/drivers/net/wireless/b43/main.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/main.c
+++ wireless-testing/drivers/net/wireless/b43/main.c
@@ -637,10 +637,17 @@ static void b43_upload_card_macaddress(s
 static void b43_set_slot_time(struct b43_wldev *dev, u16 slot_time)
 {
/* slot_time is in usec. */
-   if (dev->phy.type != B43_PHYTYPE_G)
+   /* This test used to exit for all but a G PHY. */
+   if (b43_current_band(dev->wl) == IEEE80211_BAND_5GHZ)
return;
-   b43_write16(dev, 0x684, 510 + slot_time);
-   b43_shm_write16(dev, B43_SHM_SHARED, 0x0010, slot_time);
+   b43_write16(dev, B43_MMIO_IFSSLOT, 510 + slot_time);
+   /* Shared memory location 0x0010 is the slot time and should be
+* set to slot_time; however, this register is initially 0 and changing
+* the value adversely affects the transmit rate for BCM4311
+* devices. Until this behavior is unterstood, delete this step
+*
+* b43_shm_write16(dev, B43_SHM_SHARED, 0x0010, slot_time);
+*/
 }
 
 static void b43_short_slot_timing_enable(struct b43_wldev *dev)
Index: wireless-testing/drivers/net/wireless/b43/b43.h
===
--- wireless-testing.orig/drivers/net/wireless/b43/b43.h
+++ wireless-testing/drivers/net/wireless/b43/b43.h
@@ -115,6 +115,7 @@
 #define B43_MMIO_TSF_2 0x636   /* core rev < 3 only */
 #define B43_MMIO_TSF_3 0x638   /* core rev < 3 only */
 #define B43_MMIO_RNG   0x65A
+#define B43_MMIO_IFSSLOT   0x684   /* Interframe slot time */
 #define B43_MMIO_IFSCTL0x688 /* Interframe space 
control */
 #define  B43_MMIO_IFSCTL_USE_EDCF  0x0004
 #define B43_MMIO_POWERUP_DELAY 0x6A8
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[Larry Finger]

On 01/30/2010 01:18 PM, Rafał Miłecki wrote:
> Signed-off-by: Rafał Miłecki 
> ---

This one yields "Warning: trailing whitespace in line 1357 of
drivers/net/wireless/b43/phy_n.c"

Larry

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[Larry Finger]

I had planned to address the issues reported in the thread "BCM4311/02
ABG disconnects on 2.6.32"; however, when I installed my BCM4311/2 card,
I found that the transmit rate as measured using program tcpperf was
greatly reduced from what I had seen when it was last in the machine.
With bisection, mainline commit number c7ab5ef9b was the problem. This
patch was part of the 2.6.28 merge, thus this problem has existed for
some time.

The patch changes basic rate handling and implements short slot handling.
The rate handling is OK - only the short slot changes were affecting
the performance. Further investigation showed that the original code
never called the routines that enable/disable short slot treatment,
but the revised code does. From the specs, changing this parameter
involves writing new values into a location in MMIO space and one in
the shared memory. Experimentation showed that writing the new value
to shared memory was the culprit. Changing the value in MMIO space
actually helped performance in some cases.

Tests on all my G PHY devices are summarized below. My AP is a Linksys
WRT54G V5 running the latest version of standard firmware, and with
combined 802.11b/g mode enabled. Transmit tests use program tcpperf
with a fast computer in my network as the tcpperf server. It is connected
to the AP/router with a 100 Mb/s wired connection. The results for all
my devices as as follows:

 Transmit throughput in Mb/s
DeviceBefore c7ab5ef   After c7ab5ef  With this patch

BCM4306/3   unknown  5.3 19.0
BCM4318/2   unknown 18.3 18.3
BCM4311/2   18.3 0.7 22.1
BCM4312/1   N/A*12.2 12.2

* LP PHY that was not supported until 2.6.32.

I have no idea what causes some devices to be unaffected, while others
are greatly improved. Please test to see if your device is adversely
affested.

Thanks,

Larry

--- Proposed commit message below. ---

Commit c7ab5ef9bcd281135c21b4732c9be779585181be entitled "b43: implement
short slot and basic rate handling" reduced the transmit throughput for
my BCM4311 device from 18 Mb/s to 0.7 Mb/s. The basic rate handling
portion is OK, the problem is in the short slot handling.

Prior to this change, the short slot enable/disable routines were never
called. Experimentation showed that the critical part was changing the
value at offset 0x0010 in the shared memory. This is supposed to contain
the 802.11 Slot Time in usec, but if it is changed from its initial value
of zero, performance is destroyed. On the other hand, changing the value
in the MMIO register corresponding to the Interframe Slot Time increased
performance from 18 to 22 Mb/s. A BCM4306/3 also shows dramatic
improvement of the transmit rate.

Other changes in the patch include removal of the magic number 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 
Cc: Stable  [Any stable version back through 2.6.28]
---

Index: wireless-testing/drivers/net/wireless/b43/main.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/main.c
+++ wireless-testing/drivers/net/wireless/b43/main.c
@@ -637,10 +637,17 @@ static void b43_upload_card_macaddress(s
 static void b43_set_slot_time(struct b43_wldev *dev, u16 slot_time)
 {
/* slot_time is in usec. */
-   if (dev->phy.type != B43_PHYTYPE_G)
+   /* This test used to exit for all but a G PHY. */
+   if (b43_current_band(dev->wl) == IEEE80211_BAND_5GHZ)
return;
-   b43_write16(dev, 0x684, 510 + slot_time);
-   b43_shm_write16(dev, B43_SHM_SHARED, 0x0010, slot_time);
+   b43_write16(dev, B43_MMIO_IFSSLOT, 510 + slot_time);
+   /* Shared memory location 0x0010 is the slot time and should be
+* set to slot_time; however, this register is initially 0 and changing
+* the value adversely affects the transmit rate for BCM4311
+* devices. Until this behavior is unterstood, delete this step
+*
+* b43_shm_write16(dev, B43_SHM_SHARED, 0x0010, slot_time);
+*/
 }
 
 static void b43_short_slot_timing_enable(struct b43_wldev *dev)
Index: wireless-testing/drivers/net/wireless/b43/b43.h
===
--- wireless-testing.orig/drivers/net/wireless/b43/b43.h
+++ wireless-testing/drivers/net/wireless/b43/b43.h
@@ -115,6 +115,7 @@
 #define B43_MMIO_TSF_2 0x636   /* core rev < 3 only */
 #define B43_MMIO_TSF_3 0x638   /* core rev < 3 only */
 #define B43_MMIO_RNG   0x65A
+#define B43_MMIO_IFSSLOT   0x684   /* Interframe slot time */
 #define B43_MMIO_IFSCTL0x688 /* Interframe space 
control */
 #define  B43_MMIO_IFSC

Re: BCM4311/02 ABG disconnects on 2.6.32

[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 it manually. Should I 
> switch to latest wireless testing for this?

Have you tried wireless testing? If so, I don't see it in the mail messages.
There is a possibility that this problem has been fixed, but not backported.
Using wireless testing would also be helpful as then any patches that we provide
would apply without fiddling.

In the meantime, I will switch to my BCM4311 to see if it is affected. The PHY
is similar to yours, except for the 802.11a capability. It has been a while
since it was in the machine.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: BCM4311/02 ABG disconnects on 2.6.32

[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
===
--- wireless-testing.orig/drivers/net/wireless/b43/main.c
+++ wireless-testing/drivers/net/wireless/b43/main.c
@@ -3980,6 +3980,7 @@ static int b43_wireless_core_start(struc
}

/* We are ready to run. */
+   ieee80211_wake_queues(dev->wl->hw);
b43_set_status(dev, B43_STAT_STARTED);

/* Start data flow (TX/RX). */


---

Larry


___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: BCM4311/02 ABG disconnects on 2.6.32

[Larry Finger]

On 01/27/2010 09:38 AM, Rafał Miłecki wrote:
> 2010/1/27 Yuval Hager:
>> 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 says:
>>> b43-phy0: Broadcom 4311 WLAN found (core revision 13)
>>>
>>> and lspci:
>>> 02:00.0 Network controller [0280]: Broadcom Corporation BCM4312
>>>   802.11a/b/g [14e4:4312] (rev 02)
>>>
 Also, could you check a few more kernels in-between .29 and .32?
>>>
>>> I have checked the following kernels, and found they all work correctly:
>>> 2.6.29
>>> 2.6.29.6
>>> 2.6.30.4
>>> 2.6.31.9
>>>
>>> Kernels 2.6.32 and 2.6.32.2 experience the disconnection I mentioned in
>>>   the original post. Before checking 2.6.32, I have removed
>>>   /lib/firmware/b43 completely and installed the firmware based on the
>>>   detailed instructions on the web site. I also enabled
>>>   CONFIG_B43_PHY_LP=y for 2.6.32.
>>>
>>> all kernels checked are vanilla kernels, from kernel.org.
>>>
>>
>> Just a quick update on this - this still happes on latest - 2.6.32.6.
>
> Could you try to (git) bisect this problem?
>
> This will unfortunately take hours to do, but should give us commit
> that broke support for your wifi.
>
> For howto you can check http://landley.net/writing/git-quick.html
>
> Generally I think you should do something like:
>
> git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> cd linux-2.6
> git bisect bad 22763c5cf3690a681551162c15d34d935308c8d7
> git bisect good 74fca6a42863ffacaf7ba6f1936a9f228950f657
>
> You can eventually bisect on drivers/net/wireless but I'm not sure how
> to do this properly.

git start drivers/net/wireless
git good blahblah
git bad blahblah

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[Larry Finger]

In the conversion between typedef and struct, two places that needed a "struct"
were missed.

Signed-off-by: Larry Finger 
---

John,

Without these, compilation fails.

Larry
---

Index: wireless-testing/drivers/net/wireless/b43/phy_n.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/phy_n.c
+++ wireless-testing/drivers/net/wireless/b43/phy_n.c
@@ -822,7 +822,7 @@ static u16 b43_nphy_gen_load_samples(str
 {
int i;
u16 bw, len, rot, angle;
-   b43_c32 *samples;
+   struct b43_c32 *samples;
 
 
bw = (dev->phy.is_40mhz) ? 40 : 20;
@@ -840,7 +840,7 @@ static u16 b43_nphy_gen_load_samples(str
len = bw << 1;
}
 
-   samples = kzalloc(len * sizeof(b43_c32), GFP_KERNEL);
+   samples = kzalloc(len * sizeof(struct b43_c32), GFP_KERNEL);
rot = (((freq * 36) / bw) << 16) / 100;
angle = 0;
 
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[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 config options to flip/patches to
> apply.  Also, wl.o works on this laptop with the Debian 2.6.30 kernel.
> Aptitude lists the kernel version as a 2.6.32-5.

There is one other report of the DMA problem with a non-Atom CPU (I'm not sure 
about the non-ULV part.). We do not know what the wl driver does that we do 
not, 
or vice-versa. If you want to use b43, you need to build it to use PIO only. 
Choosing PIO is now available as a run-time option, but I do not think 2.6.32 
has this feature.

Debugging this problem has been most difficult as it only affects Intel CPUs 
and 
all my machines have AMD processors.

Larry



___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: Is this a known problem?

[Larry Finger]

On 01/25/2010 01:44 AM, iko...@earthlink.net wrote:
> Hi, ALL,
> I have a Dell Laptop which has a Broadcom wireless device in it.
> It is a dual-boot system with Windows XP/Gentoo.
>
> This is the result of lspci:
> 0b:00.0 Network controller: Broadcom Corporation BCM4311 802.11b/g WLAN (rev 
> 01)
>
> This is the system name:
> IgorsGentooOnNetwork buildGTK # uname -a
> Linux IgorsGentooOnNetwork 2.6.30-gentoo-r6 #5 SMP Sun Oct 4 22:43:50 PDT 
> 2009 i686 Genuine Intel(R) CPU T1350 @ 1.86GHz GenuineIntel GNU/Linux
>
> When I boot in XP everything works perfect.
> When I then boot in Gentoo then, I can't get an IP right away.
>
> Asking about it on Gentoo forum, I got a responce that I should turn off the 
> router for 30 seconds and then everything will work.
>
> The router is using the WPA2 encryption and I am using wpa_supplicant.
>
> Is this a problem with just the b43 driver or something on the lower level?
> Is this at least known problem?

No, it is not a known problem. The NM mailing list has had some traffic about 
DHCP timeouts on busy networks where the DHCP lease time is 1 day, thus the AP 
has to probe to find an unused IP, but that should not apply to you. On the 
other hand, if turning off the router does change the situation, you might try 
changing the lease time there.

I use WPA2 on my network with b43 and NetworkManager. My network does not start 
until I login, but an IP is always available within 15-20 seconds of the time 
that my desktop is ready.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[Larry Finger]

On 01/22/2010 09:01 AM, Gábor Stefanik wrote:
> 2010/1/22 Rafał Miłecki :
>> 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
> problems with Thunderbird 3 beta - not sure about the final version).

I am reading mail with Thunderbird 3.0beta4, and only patch 1/5 was
base64-encoded. The other 4 were fine.

For the record, the final version of TBird 3 cannot read my profile. I battled
with the devs for a while, but have now given up.

Larry

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: PHY Transmission error and radio turned off with b43legacy

[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 send. The interface must be down before starting hostapd.
>> If I terminate a not daemonized hostapd with CTRL+C and restart if
>> without
>> rmmod+modprobe b43legacy, no beacons are sent, too. And I cannot connect
>> the AP.
>> This happens with the bleeding-edge wireless drivers 2009-11-13.
> 
> I noticed the same on MN700 hardware running OpenWrt bleeding edge. The
> init scripts enable and disable wlan0 once before starting hostapd.
> Here, beacons are still being sent, but hostapd is unable to transmit
> any packet. When reloading b43legacy and starting hostapd manually it
> works, but only once.
> 
> The attached patch resolves the problem for me.

Daniel: Does this patch fix your problem as well?

Has this problem been reported in the kernel bugzilla? If so, what is the 
number?

How far back does this problem go? From the date of your compat-wireless
package, it seems that 2.6.32 would be affected. How about 2.6.31?

I have tested the patch on my system where it does no harm. I do not run that
system as an AP and had not seen the problem.

As soon as I have the answers to these questions, I will push the patch to
wireless testing.

Thanks for resolving this issue.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: [PATCH 3/6] b43: N-PHY: add update TX cal ladder

[Larry Finger]

On 01/14/2010 05:59 PM, Luis R. Rodriguez wrote:
> 2010/1/14 Rafał Miłecki :
>>
>> So definitely I will avoid putting just function names. However as I
>> said, I don't think I will be able to be more descriptive :/
> 
> Heh well I had to try :)

Unfortunately, there are no comments in MIPS binary code. Without them, there is
very little more than the function names available.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[Larry Finger]

On 01/13/2010 07:38 AM, Rafał Miłecki wrote:
> W dniu 13 stycznia 2010 14:31 użytkownik Larry Finger
>  napisał:
>> On 01/12/2010 01:38 PM, Rafał Miłecki wrote:
>>>
>>> Signed-off-by: Rafał Miłecki 
>>> ---
>>>
>>> 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 
>>> truncated to unsigned type
>>>
>>> That's for:
>>> b43_phy_maskset(dev, B43_NPHY_RFSEQCA, ~B43_NPHY_RFSEQCA_RXDIS, ((1 - i) << 
>>> B43_NPHY_RFSEQCA_RXDIS_SHIFT));
>>>
>>> It's inside loop i=0,1. I tried casting i on (u8) but this didn't help. Can 
>>> we leave this? Or can sb share some trick to avoid this warning?
>>
>> It is ~B43_NPHY_RFSEQCA_RXDIS, not i, that causes the warning. Change the
>> statement to
>>
>> b43_phy_maskset(dev, B43_NPHY_RFSEQCA, (u16)(~B43_NPHY_RFSEQCA_RXDIS),
>>   ((1 - i) << B43_NPHY_RFSEQCA_RXDIS_SHIFT));
> 
> Yeah, Michael already pointed that :)

For some reason, I lost my feed from linux-wireless. I found Michael's message
in the archives.

If I have not responded to any of your private messages, please send them again.
I'm not sure if the mail stoppage is general. There is no traffic from other
lists as well.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

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

[Larry Finger]

On 01/12/2010 01:38 PM, Rafał Miłecki wrote:
> 
> Signed-off-by: Rafał Miłecki 
> ---
> 
> 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 
> truncated to unsigned type
> 
> That's for:
> b43_phy_maskset(dev, B43_NPHY_RFSEQCA, ~B43_NPHY_RFSEQCA_RXDIS, ((1 - i) << 
> B43_NPHY_RFSEQCA_RXDIS_SHIFT));
> 
> It's inside loop i=0,1. I tried casting i on (u8) but this didn't help. Can 
> we leave this? Or can sb share some trick to avoid this warning?

It is ~B43_NPHY_RFSEQCA_RXDIS, not i, that causes the warning. Change the
statement to

b43_phy_maskset(dev, B43_NPHY_RFSEQCA, (u16)(~B43_NPHY_RFSEQCA_RXDIS),
   ((1 - i) << B43_NPHY_RFSEQCA_RXDIS_SHIFT));

Larry


___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

[PATCH] b43legacy: Declare all possible ucodeX.fw files

[Larry Finger]

From: Tim Gardner 

Enhance module information with the names of the firmware files
that could be used by this driver. This helps tools like Jockey to
correctly detect and/or install the firmware files relevant to
this driver.

Signed-off-by: Larry Finger 
---

John,

This is 2.6.34 material.

Larry
---

Index: wireless-testing/drivers/net/wireless/b43legacy/main.c
===
--- wireless-testing.orig/drivers/net/wireless/b43legacy/main.c
+++ wireless-testing/drivers/net/wireless/b43legacy/main.c
@@ -61,6 +61,8 @@ MODULE_AUTHOR("Michael Buesch");
 MODULE_LICENSE("GPL");
 
 MODULE_FIRMWARE(B43legacy_SUPPORTED_FIRMWARE_ID);
+MODULE_FIRMWARE("b43legacy/ucode2.fw");
+MODULE_FIRMWARE("b43legacy/ucode4.fw");
 
 #if defined(CONFIG_B43LEGACY_DMA) && defined(CONFIG_B43LEGACY_PIO)
 static int modparam_pio;
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: Impossible to associate with WPA with a LP-PHY

[Larry Finger]

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, or just WEP, there is no problem. However, when I try to
>>> connect to a AP with WPA (which works from Windows, and also with the wl
>>> driver), it fails to associate. wpa_cli shows me this messages repeatedly:
>>> <2>Trying to associate with 00:18:84:15:d3:3e (SSID='MyPlace9' freq=2412
>>> MHz)
>>> <2>Authentication with 00:18:84:15:d3:3e timed out.
>>>
>>> There doesn't seem to be any interesting error message in dmesg.
>>> I've just tried with Linus'git head, and it's the same result. The
>>> firmware loaded is noted as 478.104 in dmesg.
>>>
>>> What can I do to try to debug this?
>>
>> The problem is not general. I use b43 with a 4315 device with WPA or WPA2
>> without difficulty.
>>
>> Are you using NetworkManager? If so, look at /var/log/NetworkManager. If not,
>> then you need to start wpa_supplicant separately with the -ddd option.
> I'm using Mandriva's network manager (which is basically just a frontend
> to wpa_supplicant). However, now that I try just with wpa_supplicant, it
> works fine!
> 
> I'll investigate a bit further, it's probably a bug in the frontend.

I don't use Mandriva, but the version of NetworkManager distributed with
openSUSE has had problems in the past.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: [PATCH 2/6] b43: N-PHY: add RSSI functions: poll and set 2055 vcm

[Larry Finger]

On 01/10/2010 04:32 PM, Michael Buesch wrote:
> On Sunday 10 January 2010 23:13:20 Rafał Miłecki wrote:
>> +buf[0] += (s8)(((s[0] & 0x3F) << 2) >> 2);
>> +buf[1] += (s8)s[0] >> 8) & 0x3F) << 2) >> 2);
>> +buf[2] += (s8)(((s[1] & 0x3F) << 2) >> 2);
>> +buf[3] += (s8)s[1] >> 8) & 0x3F) << 2) >> 2);
> 
> I suggest buf[3] += (s8)s[1] >> 8) & 0x3F) << 2) >> 2) << 2) >> 2) << 2) 
> >> 2) << 2) >> 2) << 2) >> 2) << 2) >> 2) << 2) >> 2)
> ;)
> No, seriously, why shift left and then shift right? Is this a translation 
> error?
> I _guess_ it's some mistranslation of the sign extension going on.
> Or alternatively a compiler going insane on sign extension.
> 
> The question is: Do we want these integers to be signextended or not?
> 
> What we currently do is this:
> buf[3] += (s8)((s[1] >> 8) & 0x3F);
> 
> which will always result in a positive 8bit integer, as far as I can see.
> Which smells fishy.

Yes, my fault. The specs are now corrected so that these statements are

((s8)((s[1] >> 8) & 0x3F) << 2) >> 2

I think that is right.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: [PATCH 2/6] b43: N-PHY: add RSSI functions: poll and set 2055 vcm

[Larry Finger]

On 01/10/2010 04:32 PM, Michael Buesch wrote:
> On Sunday 10 January 2010 23:13:20 Rafał Miłecki wrote:
>> +buf[0] += (s8)(((s[0] & 0x3F) << 2) >> 2);
>> +buf[1] += (s8)s[0] >> 8) & 0x3F) << 2) >> 2);
>> +buf[2] += (s8)(((s[1] & 0x3F) << 2) >> 2);
>> +buf[3] += (s8)s[1] >> 8) & 0x3F) << 2) >> 2);
> 
> I suggest buf[3] += (s8)s[1] >> 8) & 0x3F) << 2) >> 2) << 2) >> 2) << 2) 
> >> 2) << 2) >> 2) << 2) >> 2) << 2) >> 2) << 2) >> 2)
> ;)
> No, seriously, why shift left and then shift right? Is this a translation 
> error?
> I _guess_ it's some mistranslation of the sign extension going on.
> Or alternatively a compiler going insane on sign extension.
> 
> The question is: Do we want these integers to be signextended or not?
> 
> What we currently do is this:
> buf[3] += (s8)((s[1] >> 8) & 0x3F);
> 
> which will always result in a positive 8bit integer, as far as I can see.
> Which smells fishy.

We do want sign extension of the signed 6-bit quantities into an 8-bit word. The
translation is correct. Do you know of a better way to extend the signs?

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: Impossible to associate with WPA with a LP-PHY

[Larry Finger]

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 (which works from Windows, and also with the wl
> driver), it fails to associate. wpa_cli shows me this messages repeatedly:
> <2>Trying to associate with 00:18:84:15:d3:3e (SSID='MyPlace9' freq=2412
> MHz)
> <2>Authentication with 00:18:84:15:d3:3e timed out.
> 
> There doesn't seem to be any interesting error message in dmesg.
> I've just tried with Linus'git head, and it's the same result. The
> firmware loaded is noted as 478.104 in dmesg.
> 
> What can I do to try to debug this?

The problem is not general. I use b43 with a 4315 device with WPA or WPA2
without difficulty.

Are you using NetworkManager? If so, look at /var/log/NetworkManager. If not,
then you need to start wpa_supplicant separately with the -ddd option.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: b43 on Dell i1545 laptop

[Larry Finger]

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, then copy those files to the firmware directory
>> in the
>> ramfs. Once that is done, unload and reload (with modprobe) the b43
>> driver. You
>> will now be able to access the network. If you install from the CD,
>> you will
>> need to copy those files to the hard drive.
> 
> OK, I copied all the *15.fw files to /lib/firmware/b43
> then did modprobe -r b43
>  modprobe b43
> 
> Then I tried ifconfig wlan0 up  -is that what I should have tried?
> 
> It responded with SIOCSIFFLAGS: Operation not possible due to RF-kill

That is the correct step as long as you are not using NetworkManager. Now you
need to flip your radio enable switch. If it is off, the radio is killed, i.e.
RF-kill.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: [PATCH 1/5] b43: N-PHY: implement b43_nphy_stay_in_carrier_search and it's calls (V2)

[Larry Finger]

On 01/06/2010 04:49 PM, Gábor Stefanik wrote:
> 2010/1/6 Rafał Miłecki :
>> W dniu 6 stycznia 2010 23:35 użytkownik Gábor Stefanik
>>  napisał:
>>> 2010/1/6 Rafał Miłecki :
 V2: fix typo in deaf_count counting, improve b43_mac_[sr] calls,
rename function. Thanks Michael!

 Signed-off-by: Rafał Miłecki 
 ---
  drivers/net/wireless/b43/phy_n.c |   58
 ++
  drivers/net/wireless/b43/phy_n.h |3 ++
  2 files changed, 61 insertions(+), 0 deletions(-)

 
>>>
>>> Typo in title (it's vs. its)
>>
>> My gramma is far from perfect, thanks.
> 
> I've yet to see a perfect grandmother... :-)

My wife thinks she is perfect!

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: LP-PHY: Some fixes, notices

[Larry Finger]

On 01/06/2010 03:30 PM, Gábor Stefanik wrote:
> On Wed, Jan 6, 2010 at 10:09 PM, Rafał Miłecki  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 boards. Also I've found little mistake in specs which Larry just
>> corrected.
>>
>> Gábor: could you care for this parts of LP-PHY code?
>>
>> So far I've only checked
>> lpphy_read_band_sprom(dev);
>> and
>> lpphy_baseband_init(dev);
>>
>> I check for all conditions and operations (registers, masks, values). So far
>> didn't notice anything more serious than what's exposed by patch, so good
>> work Gábor :)
>>
>>
>>
>>
>> diff --git a/drivers/net/wireless/b43/phy_lp.c
>> b/drivers/net/wireless/b43/phy_lp.c
>> index 1e318d8..43a9fcc 100644
>> --- a/drivers/net/wireless/b43/phy_lp.c
>> +++ b/drivers/net/wireless/b43/phy_lp.c
>> @@ -198,6 +198,17 @@ static void lpphy_table_init(struct b43_wldev *dev)
>>
>>lpphy_init_tx_gain_table(dev);
>>
>> +   if (dev->phy.rev >=2) {
>> +   int i;
>> +   for (i = 0; i < 128; ++i) {
> 
> Two style comments:
> 1. Declare i at the beginning of the function.
> 2. The preferred style in b43 is i++.
> 
>> +   /* TODO
>> +   Set the table offset to 576 + the loop index
>> +   Set the table data pointer to a u32 containing 127 -
>> loop index
>> +   Write the table
>> +   */
> 
> This can be implemented like this:
> b43_lptab_write(dev, B43_LPTAB32(?, 576 + i), 127 - i);
> 
> Larry, what is the correct value for the "?" (i.e. the table index)?
> Please update the specs, this is missing.

Now fixed. If the PHY Revision is >= 2, the table ID is 7, otherwise it is 0xA.
For the table in question, it should be 7.

Larry

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: [PATCH 2/5] b43: N-PHY: add b43_nphy_get_tx_gains (V2)

[Larry Finger]

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 
> ---
>  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 (or later) version of a patch, indicate the version in
the mail header as in [PATCH 2/5 V2] b43: The upstream software strips all
of that out and the commit header will be clean.

In addition, it is useful to state what is different below the --- marker. The
software also strips that part of the patch - the permanent commit message
should be devoid of the details of the review message. It is like making
sausage! Better that the details are hidden.

Larry

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: [PATCH 1/5] b43: N-PHY: implement b43_nphy_stay_carrier_search and it's calls

[Larry Finger]

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 meant?
> Not that I care much, but I'm just wondering if this is just a typo.

"stay in carrier search"

> 
>> +static void b43_nphy_write_clip_detection(struct b43_wldev *dev, u16 *vals)
> 
> We know that these values are the clip thresholds, so use a better variable 
> name, please.
> 
>> +{
>> +b43_phy_write(dev, B43_NPHY_C1_CLIP1THRES, vals[0]);
>> +b43_phy_write(dev, B43_NPHY_C2_CLIP1THRES, vals[1]);
>> +}
>> +
>> +static void b43_nphy_read_clip_detection(struct b43_wldev *dev, u16 *vals)
>> +{
>> +vals[0] = b43_phy_read(dev, B43_NPHY_C1_CLIP1THRES);
>> +vals[1] = b43_phy_read(dev, B43_NPHY_C2_CLIP1THRES);
>> +}
>> +
>> +static u16 b43_nphy_classifier(struct b43_wldev *dev, u16 mask, u16 val)
>> +{
>> +u16 tmp;
>> +bool suspended = false;
>> +
>> +if (dev->dev->id.revision == 16 && dev->mac_suspended == 0) {
> 
> Do not check for mac_suspended==0 here. b43_mac_suspended does this 
> internally.
> 
>> +b43_mac_suspend(dev);
>> +suspended = true;
>> +}
>> +
>> +tmp = b43_phy_read(dev, B43_NPHY_CLASSCTL);
>> +tmp &= (B43_NPHY_CLASSCTL_CCKEN | B43_NPHY_CLASSCTL_OFDMEN |
>> +B43_NPHY_CLASSCTL_WAITEDEN);
>> +tmp &= ~mask;
>> +tmp |= (val & mask);
>> +b43_phy_maskset(dev, B43_NPHY_CLASSCTL, 0xFFF8, tmp);
>> +
>> +if (suspended)
>> +b43_mac_enable(dev);
>> +
>> +return tmp;
>> +}
>> +
>> +static void b43_nphy_stay_carrier_search(struct b43_wldev *dev, bool enable)
>> +{
>> +struct b43_phy *phy = &dev->phy;
>> +struct b43_phy_n *nphy = phy->n;
>> +
>> +if (enable) {
>> +u16 clip[] = { 0x, 0x };
>> +if (nphy->deaf_count++ == 0) {
>> +nphy->classifier_state = b43_nphy_classifier(dev, 0, 0);
>> +b43_nphy_classifier(dev, 0x7, 0);
>> +b43_nphy_read_clip_detection(dev, nphy->clip_state);
>> +b43_nphy_write_clip_detection(dev, clip);
>> +}
>> +b43_nphy_reset_cca(dev);
>> +} else {
>> +if (--nphy->deaf_count != 0) {
> 
> If this test logic correct? The following would make more sense to me:
> 
>   if (--nphy->deaf_count == 0) {

It should be == 0. Specs match Broadcom code.


Larry

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: b43 on Dell i1545 laptop

[Larry Finger]

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 the wiki. You will not get the xxx15.fw files.

> 
> Now I guess if I did have the firmware it wants, ucode15.fw, I don't know
> how to work that in to the live CD - maybe I'd have to install it on the
> hard drive, or maybe I have to get the Fedora people to add it to the
> build.

The Fedora people do not have the right to distribute Broadcom firmware, which
is why it is not on the live CD. What you need to do is run the procedure from
the wiki and then copy the files in /lib/firmware/b43/ to some removable device.
After you boot the CD, then copy those files to the firmware directory in the
ramfs. Once that is done, unload and reload (with modprobe) the b43 driver. You
will now be able to access the network. If you install from the CD, you will
need to copy those files to the hard drive.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: N-PHY init: current code vs. specs

[Larry Finger]

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, we should do so for the
> sake of readability (I didn't look into detail, though.).
> Same goes for algorithms and stuff. If we realize that we can do better, do 
> _not_
> implement Broadcrap and instead implement a better version.

I agree with Michael that we do not need to follow Broadcrap (nice phrase);
however, as we usually have no idea of what is going on inside the chip, we do
need to read/write exactly the same registers as they do without skipping any or
touching any others.

For the record, the specs will usually follow the Broadcrap way. I did come upon
one exception recently. After quite a bit of decision making that did not touch
any registers nor change any global variables, they suddenly tested for 2.4 GHz
mode and exited if found. I moved that test to the beginning of the routine.

Larry



___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: b43 kills my kernel

[Larry Finger]

On 01/05/2010 11:18 AM, Michael Buesch wrote:
> On Monday 04 January 2010 22:51:40 Oncaphillis wrote:
>> Did any of the patches for a device without a sprom make it
>> into the 2.6.33-rc2 ?
> 
> No we decided that the patches were not acceptable and need a rewrite towards
> firmware loading mechanism.
> Nobody's currently doing that, though.

Since the previous round of tests, the reverse-engineering group has been
working on a new release of the Broadcom driver. So far, I have not looked into
how it handles firmware when there is no SPROM, but that task is on my list of
things to do.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: N-PHY init: current code vs. specs

[Larry Finger]

On 01/04/2010 04:34 PM, Rafał Miłecki wrote:
> W dniu 4 stycznia 2010 21:36 użytkownik Rafał Miłecki
>  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 specs still tell about resetting CCA, but that is done (in
> specs) without call to separated function (just part of init code):
> 29. Read PHY Register 0x01 and save in val
> 30. Write val | 0x4000 to PHY Register 0x1
> 31. Write val & 0xBFFF to PHY Register 0x1
> 
> Should I strictly follow specs (put CCA reset directly in init code)
> or should I keep b43_nphy_reset_cca function and just modify if to
> match current specs?

As long as all the register read/writes are the same, it doesn't really matter.
You get to do what you want. If you deviate from the specs, just throw in a
comment so that someone else knows what you did and why if looks different.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: N-PHY init: current code vs. specs

[Larry Finger]

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 "//TODO: Spectral
> management". I don't see anything about "spectral management" in
> specs.
> 
> 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);
> ssb_write32(dev->dev, SSB_TMSLOW, ...);
> b43_nphy_force_rf_sequence(...);
> b43_phy_read(dev, B43_NPHY_CLASSCTL); /* dummy read */
> 
> I don't see connection between that code and specs.
> 
> Michael: I guess you're author of this code (phy_n.c came from nphy.c,
> not sure how to check log for not-existing file). Could you help me
> and explain this, please?

I can answer this question. The original N PHY specs and the code generated from
them were for a driver that is now 2 versions old. The main changes are due to
later revisions of the N PHY, but there also seem to be some refactoring. To
keep it straight, I am evolving the current specs to match the latest driver
that we have available. Whenever you see code like the above that does not match
the specs, you should probably rip it out. If you have any questions, please ask
me if a given spec page is current.

I have been trying to get initn and all the routines that it calls up to date,
but this RE process is so mind-numbing that I can only work on it for so long.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: [RFC][RFH] Small fixes to N-PHY init

[Larry Finger]

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 list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: b43 on Dell i1545 laptop

[Larry Finger]

On 01/04/2010 11:14 AM, Rafał Miłecki wrote:
> 2010/1/4 Jim Haynes :
>> 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 distro forums.

>> I just got a Dell i1545 laptop and put Fedora 12 on it.  The current
>> kernel is 2.6.31.9-174.fc12.x86_64
>>
>> lspci says [14e4:4315] (rev 01)  and the b43 web page says support is
>> "in progress"  but I don't see a date for that status.

As Rafał told you, that driver is in kernel 2.6.32.

>> I installed the firmware in /lib/firmware/b43 like the web page says
>>
>> dmesg reports
>> b43-phy0: Broadcom 4312 WLAN found (core revision 15)
>> b43-phy0: ERROR: FOUND UNSUPPORTED PHY  (Analog 6, Type 5, Revision 1)
>> b43: probe of ssb0:0 failed with error -95
>>
>> Is there anything you need me to test for and report?  Or anything I can
>> do to get this working?  Or should I just wait? (I have no pressing need
>> for it to work just now)
> 
> That is LP PHY based wireless card and LP has basic support in 2.6.32
> kernel. You have .31 so it's unsupported PHY for you.
> 
> After upgrading to 2.6.32 you should hopefully get stable but still
> low performance support for your card.

As an alternative to switching to kernel 2.6.32, you could implement the
compat-wireless package. As for performance, the 4315/b43 combination receives
at a rate of about 20 Mb/s and sends at 12 Mb/s. This is not full 802.11g rate,
but quite respectable. The connection is very stable.

Larry


___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: The newest Macbook 13.3" wireless

[Larry Finger]

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 anyway I could help you guys with getting this wlan card to
> work? I could test experimental drivers or try to bash it to work or
> such, it would just be awesome if I could get it to work.
> 
> The chip PCI ID is 14e4:4353 if that helps you any, its a wireless N
> card as I have understod it, but there exist no info that either confirm
> or discard the PCI ID as a WLAN card. I havent been able to get any info
> of which card this is supposed to be from broadcoms sortiment, I cannot
> find any of the cards listen on broadcoms homepage to match with this card.

The Broadcom 5.10.56.46 that is the basis for my current reverse engineering
effort supports that card. To the best of my knowledge, it is an 802.11n
dual-band card. The coding effort to support N PHYs has just started. Of course,
it could be an SSLPN PHY and the RE for them is not yet started. In any case,
who knows when any code will be ready. Watch this mailing list for patches.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Problem with b43_get_and_map_ringmem()

[Larry Finger]

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 probably seen, this is
likely the underlying cause of the regression reported in Bugzilla No. 14844.
Testing by the OP has not been done, but it fixed the same problem here.

Fixing this will likely be a two-step process. For 2.6.33, I am proposing the
following simple patch, which is essentially what is being tested:

Index: wireless-testing/drivers/net/wireless/b43/dma.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/dma.c
+++ wireless-testing/drivers/net/wireless/b43/dma.c
@@ -439,9 +439,14 @@ static void * b43_get_and_map_ringmem(st
  dma_addr_t *dmaaddr, size_t size)
 {
void *base;
+   gfp_t flags = GFP_KERNEL;

+   if (unlikely(ring->type == B43_DMA_30BIT))
+   flags |= GFP_DMA;
+   else if (unlikely(ring->type == B43_DMA_32BIT))
+   flags |= GFP_DMA32;
base = __b43_get_and_map_ringmem(ring, dmaaddr, size,
-GFP_KERNEL);
+flags);
if (!base) {
b43err(ring->dev->wl, "Failed to allocate or map pages "
   "for DMA ringmemory\n");

Comments?

For 2.6.34, a more complete rework is probably needed.

Larry

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: Fatal DMA error problem with netbook and BCM4312 - Test 3

[Larry Finger]

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);
> 
> 
>> +tmp |= 3;
> 
> So you set SER-timeout to 3 and REQ-timeout to 0. Is that what we want?
> REQ=zero smells fishy to me, but if the broadcom code also does this, I'm OK 
> with it.

I did get that wrong. The Broadcom code does the equivalent of

tmp = tmp & ~0x77 | 3

which is what my code ended up doing by accident, but REQ is set to zero.

Are these values discussed anywhere in the open? I have not found anything
regarding the SSB configuration.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: Fatal DMA error problem with netbook and BCM4312 - Test 3

[Larry Finger]

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
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Fatal DMA error problem with netbook and BCM4312 - Test 3

[Larry Finger]

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
===
--- wireless-testing.orig/drivers/ssb/driver_pcicore.c
+++ wireless-testing/drivers/ssb/driver_pcicore.c
@@ -621,6 +621,14 @@ int ssb_pcicore_dev_irqvecs_enable(struc
tmp |= 0x40;
ssb_pcie_write(pc, 0x100, tmp);
}
+   if (bus->chip_id == 0x4312 ||
+  (bus->chip_id == 0x4311 && bus->chip_rev == 2)) {
+   tmp = ssb_read32(pdev, SSB_IMCFGLO);
+   tmp &= ~(SSB_IMCFGLO_SERTO | SSB_IMCFGLO_REQTO_SHIFT);
+   tmp |= 3;
+   ssb_write32(pdev, SSB_IMCFGLO, tmp);
+   ssb_commit_settings(bus);
+   }
}
pc->setup_done = 1;
 out:
Index: wireless-testing/drivers/ssb/driver_chipcommon_pmu.c
===
--- wireless-testing.orig/drivers/ssb/driver_chipcommon_pmu.c
+++ wireless-testing/drivers/ssb/driver_chipcommon_pmu.c
@@ -424,9 +424,9 @@ static void ssb_pmu_resources_init(struc
switch (bus->chip_id) {
case 0x4312:
/* We keep the default settings:
-* min_msk = 0xCBB
 * max_msk = 0x7
 */
+   min_msk = 0xCBB;
break;
case 0x4325:
/* Power OTP down later. */
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: [PATCH][resend with linux-wireless] b43: N-PHY: clean table init, check PHY rev

[Larry Finger]

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 linux-wireless. Is there anyone
> how could review/ack my patch?
> 
> 
> From 6800722c2fda0e302d7c759a5f2a993503b6581a Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=  >
> Date: Tue, 22 Dec 2009 02:27:21 +0100
> Subject: [PATCH] b43: N-PHY: clean table init, check PHY rev
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> Move table init to tables_nphy.c, detect newer PHY which use different init
> 
> Signed-off-by: Rafał Miłecki mailto:zaj...@gmail.com>>
> ---
> drivers/net/wireless/b43/phy_n.c   |   43 
> drivers/net/wireless/b43/tables_nphy.c |   48
> 
> drivers/net/wireless/b43/tables_nphy.h |4 ++-
> 3 files changed, 58 insertions(+), 37 deletions(-)
> 
> diff --git a/drivers/net/wireless/b43/phy_n.c
> b/drivers/net/wireless/b43/phy_n.c
> index 992318a..23cef71 100644
> --- a/drivers/net/wireless/b43/phy_n.c
> +++ b/drivers/net/wireless/b43/phy_n.c
> @@ -197,44 +197,15 @@ void b43_nphy_radio_turn_off(struct b43_wldev *dev)
> ~B43_NPHY_RFCTL_CMD_EN);
> }
> 
> -#define ntab_upload(dev, offset, data) do { \
> - unsigned int i; \
> - for (i = 0; i < (offset##_SIZE); i++) \
> - b43_ntab_write(dev, (offset) + i, (data)[i]); \
> - } while (0)
> -
> -/* Upload the N-PHY tables. */
> +/* Upload the N-PHY tables.
> + * http://bcm-v4.sipsolutions.net/802.11/PHY/N/InitTables
> + */
> static void b43_nphy_tables_init(struct b43_wldev *dev)
> {
> - /* Static tables */
> - ntab_upload(dev, B43_NTAB_FRAMESTRUCT, b43_ntab_framestruct);
> - ntab_upload(dev, B43_NTAB_FRAMELT, b43_ntab_framelookup);
> - ntab_upload(dev, B43_NTAB_TMAP, b43_ntab_tmap);
> - ntab_upload(dev, B43_NTAB_TDTRN, b43_ntab_tdtrn);
> - ntab_upload(dev, B43_NTAB_INTLEVEL, b43_ntab_intlevel);
> - ntab_upload(dev, B43_NTAB_PILOT, b43_ntab_pilot);
> - ntab_upload(dev, B43_NTAB_PILOTLT, b43_ntab_pilotlt);
> - ntab_upload(dev, B43_NTAB_TDI20A0, b43_ntab_tdi20a0);
> - ntab_upload(dev, B43_NTAB_TDI20A1, b43_ntab_tdi20a1);
> - ntab_upload(dev, B43_NTAB_TDI40A0, b43_ntab_tdi40a0);
> - ntab_upload(dev, B43_NTAB_TDI40A1, b43_ntab_tdi40a1);
> - ntab_upload(dev, B43_NTAB_BDI, b43_ntab_bdi);
> - ntab_upload(dev, B43_NTAB_CHANEST, b43_ntab_channelest);
> - ntab_upload(dev, B43_NTAB_MCS, b43_ntab_mcs);
> -
> - /* Volatile tables */
> - ntab_upload(dev, B43_NTAB_NOISEVAR10, b43_ntab_noisevar10);
> - ntab_upload(dev, B43_NTAB_NOISEVAR11, b43_ntab_noisevar11);
> - ntab_upload(dev, B43_NTAB_C0_ESTPLT, b43_ntab_estimatepowerlt0);
> - ntab_upload(dev, B43_NTAB_C1_ESTPLT, b43_ntab_estimatepowerlt1);
> - ntab_upload(dev, B43_NTAB_C0_ADJPLT, b43_ntab_adjustpower0);
> - ntab_upload(dev, B43_NTAB_C1_ADJPLT, b43_ntab_adjustpower1);
> - ntab_upload(dev, B43_NTAB_C0_GAINCTL, b43_ntab_gainctl0);
> - ntab_upload(dev, B43_NTAB_C1_GAINCTL, b43_ntab_gainctl1);
> - ntab_upload(dev, B43_NTAB_C0_IQLT, b43_ntab_iqlt0);
> - ntab_upload(dev, B43_NTAB_C1_IQLT, b43_ntab_iqlt1);
> - ntab_upload(dev, B43_NTAB_C0_LOFEEDTH, b43_ntab_loftlt0);
> - ntab_upload(dev, B43_NTAB_C1_LOFEEDTH, b43_ntab_loftlt1);
> + if (dev->phy.rev < 3)
> + b43_nphy_rev0_1_2_table_init(dev);
> + else
> + b43_nphy_rev3plus_table_init(dev);
> }
> 
> static void b43_nphy_workarounds(struct b43_wldev *dev)
> diff --git a/drivers/net/wireless/b43/tables_nphy.c
> b/drivers/net/wireless/b43/tables_nphy.c
> index 4e23363..d709555 100644
> --- a/drivers/net/wireless/b43/tables_nphy.c
> +++ b/drivers/net/wireless/b43/tables_nphy.c
> @@ -2474,3 +2474,51 @@ void b43_ntab_write(struct b43_wldev *dev, u32
> offset, u32 value)
> /* Some compiletime assertions... */
> assert_ntab_array_sizes();
> }
> +
> +#define ntab_upload(dev, offset, data) do { \
> + unsigned int i; \
> + for (i = 0; i < (offset##_SIZE); i++) \
> + b43_ntab_write(dev, (offset) + i, (data)[i]); \
> + } while (0)
> +
> +void b43_nphy_rev0_1_2_table_init(struct b43_wldev *dev)
> +{
> + /* Static tables */
> + ntab_upload(dev, B43_NTAB_FRAMESTRUCT, b43_ntab_framestruct);
> + ntab_upload(dev, B43_NTAB_FRAMELT, b43_ntab_framelookup);
> + ntab_upload(dev, B43_NTAB_TMAP, b43_ntab_tmap);
> + ntab_upload(dev, B43_NTAB_TDTRN, b43_ntab_tdtrn);
> + ntab_upload(dev, B43_NTAB_INTLEVEL, b43_ntab_intlevel);
> + ntab_upload(dev, B43_NTAB_PILOT, b43_ntab_pilot);
> + ntab_upload(dev, B43_NTAB_PILOTLT, b43_ntab_pilotlt);
> + ntab_upload(dev, B43_NTAB_TDI20A0, b43_ntab_tdi20a0);
> + ntab_upload(dev, B43_NTAB_TDI20A1, b43_ntab_tdi20a1);
> + ntab_upload(dev, B43_NTAB_TDI40A0, b43_ntab_tdi40a0);
> + ntab_upload(dev, B43_NTAB_TDI40A1, b43_ntab_tdi40a1);
> + ntab_upload(dev, B43_NTAB_BDI, b43_ntab_bdi);
> + ntab_upload(dev, B43_NTAB_

Re: [PATCH] b43: N-PHY: clean table init, check PHY rev

[Larry Finger]

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, but otherwise it should be OK.

To get N PHY stuff to compile, you need the following patch:



Index: wireless-testing/drivers/net/wireless/b43/Kconfig
===
--- wireless-testing.orig/drivers/net/wireless/b43/Kconfig
+++ wireless-testing/drivers/net/wireless/b43/Kconfig
@@ -81,7 +81,7 @@ config B43_SDIO

 config B43_NPHY
bool "Pre IEEE 802.11n support (BROKEN)"
-   depends on B43 && EXPERIMENTAL && BROKEN
+   depends on B43 && EXPERIMENTAL
---help---
  Support for the IEEE 802.11n draft.


Larry

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev