Re: [PATCH V4] ssb: Implement virtual SPROM

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


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

2010-03-24 Thread Larry Finger
On 03/23/2010 03:58 PM, Calvin Walton wrote:
 
 I will warn you that the following is rather untested, as I don't have
 any of the affected hardware (or any b43 devices at all, actually), but
 something along these lines should work. There's no syntax errors, at
 least :)
 
 --- /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: [PATCH V2] ssb: Implement virtual SPROM on disk

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


[PATCH V3] ssb: Implement virtual SPROM

2010-03-23 Thread 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 larry.fin...@lwfinger.net
---

John,

Unless someone comes up with a unique way to generate a MAC address using
only udev rules, I think this is ready.

I suspect it is a little to invasive for 2.6.34. In addition, it fixes
a bug, but not a regression.

Larry
---

V2 - make virtual SPROM 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 linux/ssb/ssb_regs.h
 #include linux/pci.h
 #include linux/delay.h
+#include linux/firmware.h
 
 #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 sure 2 least significant bits of first byte are clear
+* These bits are multicast address and LAA bit, and
+* copy the randomized MAC address to the sprom variables
+*/
+   buf2[0] = ~(3);
+   memcpy(sprom-il0mac, buf2, 4);
+
+   /* As there may

Re: Works wonderfully except at Barnes and Nobles.

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


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

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

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

I don't know of any way that b43 could have 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

2010-03-23 Thread Larry Finger
On 03/23/2010 03:31 PM, Chris Lopes wrote:
 Ok.  I got my wireless card to detect networks again.  I also had a
 theory and tried to reproduce the problem, and was successful in doing
 so.  Here are my steps to reproduce:
 1) Have Vista running and connected to a wireless network
 2) Hibernate 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: [PATCH V2] ssb: Implement virtual SPROM on disk

2010-03-22 Thread Larry Finger
On 03/22/2010 03:37 AM, Michael Buesch wrote:
 On Monday 22 March 2010 07:28:23 Calvin Walton wrote:
 Hi,

 On Sat, 2010-03-20 at 19:14 -0500, Larry Finger wrote:
 Some recent BCM43XX devices lack an on-board SPROM. The pertinent data
 from the SPROM could be included in the kernel; however, 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


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

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

2010-03-22 Thread Larry Finger
Michael,

Would the following be sufficient?

(1) The utility /bin/dbus-uuidgen is used to create a file
/lib/firmware/ssb/mac_address. The command to create this file if it does not
exist could be added to the scripts that use fwcutter.

(2) In drivers/ssb/pci.c, the firmware loading process 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


[PATCH V2] ssb: Implement virtual SPROM on disk

2010-03-21 Thread 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 larry.fin...@lwfinger.net
---

Michael,

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

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 linux/ssb/ssb_regs.h
 #include linux/pci.h
 #include linux/delay.h
+#include linux/firmware.h
 
 #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


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

2010-03-20 Thread 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 larry.fin...@lwfinger.net
---

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 larry.fin...@lwfinger.net
+ *
+ * Some routines copied from b43-fwcutter, which is
+ *
+ * Copyright (c) 2005 Martin Langer martin-lan...@gmx.de,
+ *   2005-2007 Michael Buesch m...@bu3sch.de
+ *  2005 Alex Beregszaszi
+ *  2007 Johannes Berg johan...@sipsolutions.net
+ *
+ * Other routines from ssb_sprom, which is
+ *
+ * Copyright (c) 2006-2008 Michael Buesch m...@bu3sch.de
+ * Copyright (c) 2008 Larry Finger larry.fin...@lwfinger.net
+ *
+ *   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 stdio.h
+#include stdlib.h
+#include string.h
+#include time.h
+#include stdint.h
+#include errno.h
+#include errno.h
+#include sys/stat.h
+#include sys/types.h
+
+#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

[PATCH] ssb: Implement virtual SPROM on disk

2010-03-20 Thread 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 larry.fin...@lwfinger.net
---

Michael,

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

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 linux/ssb/ssb_regs.h
 #include linux/pci.h
 #include linux/delay.h
+#include linux/firmware.h
 
 #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: A workaround for BCM43XX devices with no on-board SPROM

2010-03-18 Thread Larry Finger
Michael,

I'm switching this discussion from the kernel Bugzilla to the lists.

As you know, but I'm restating for anyone that has not read our previous
discussions, the b43 driver needs to be changed to handle some of the newer
devices do not have an on-board SPROM. It would be trivial to 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: RFC: A workaround for BCM43XX devices with no on-board SPROM

2010-03-18 Thread Larry Finger
On 03/18/2010 03:53 PM, Johannes Berg wrote:
 On Thu, 2010-03-18 at 12:46 -0500, Larry Finger wrote:
 Michael,

 I'm switching this discussion from the kernel Bugzilla to the lists.

 As you know, but I'm restating for anyone that has not read our previous
 discussions, the b43 driver needs 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


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

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

2010-03-18 Thread Larry Finger
On 03/18/2010 04:20 PM, Johannes Berg wrote:
 On Thu, 2010-03-18 at 16:10 -0500, Larry Finger wrote:
 On 03/18/2010 03:53 PM, Johannes Berg wrote:
 On Thu, 2010-03-18 at 12:46 -0500, Larry Finger wrote:
 Michael,

 I'm switching this discussion from the kernel Bugzilla to the lists.

 As you know, 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: BCM4312 (14e4:4315) in Lenovo Ideapad S12 cannot scan with 2.6.33

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

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

2010-03-10 Thread Larry Finger
The latest changes in the N PHY core require the symbol
ssb_chipco_gpio_control to be exported.

Signed-off-by: Larry Finger larry.fin...@lwfinger.net
---

John,

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

Larry
---
 
Index: wireless-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: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!

2010-03-04 Thread Larry Finger
On 03/03/2010 06:47 PM, Gábor Stefanik wrote:
 On Thu, Mar 4, 2010 at 1:30 AM, Larry Finger larry.fin...@lwfinger.net 
 wrote:
 On 03/02/2010 03:57 PM, Michael Buesch wrote:

 A bug in the PCI-E core code is able to show such behavior, because all 
 memory
 transfers (MMIO and DMA) from the PCI 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?!?!!??!

2010-03-04 Thread Larry Finger
On 03/02/2010 03:57 PM, Michael Buesch wrote:

 A bug in the PCI-E core code is able to show such behavior, because all memory
 transfers (MMIO and DMA) from the PCI device to the wireless core are 
 translated
 by the PCI-E core.
 I think the whole PCI-E core code has to be audited (also the 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: BCM4312 (14e4:4315) in Lenovo Ideapad S12 cannot scan with 2.6.33

2010-03-04 Thread Larry Finger
On 03/04/2010 12:49 PM, William Bourque wrote:
 
 Hello
 
 Marc Haber wrote:
 Hi,

 when the broadcom-sta driver didn't compile with 2.6.33 I decided to
 give b43 a new try. I have a Lenovo Ideapad S12, which has a BCM4312
 with LP Phy (14e4:4315). I am using Debian unstable.

 When I load the 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

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

2010-03-04 Thread Larry Finger
On 03/04/2010 04:53 PM, Celejar wrote:
 
 b43 works perfectly fine with my 4318 on my Debian Sid system, without
 CRDA installed.

What kernel version is in Sid?

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


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

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

It may fail with 2.6.33.
___
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?!?!!??!

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

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

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

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

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


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

2010-02-26 Thread Larry Finger
Subject: Make b43 driver fall back gracefully to PIO mode after fatal DMA errors
From: Linus Torvalds torva...@linux-foundation.org
Date: Fri, 26 Feb 2010 10:34:27 -0800 (PST)

This makes the b43 driver just automatically fall back to PIO mode when 
DMA doesn't work.

The driver already told the 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 torva...@linux-foundation.org
---

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?!?!!??!

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


Re: Turn broadcom 4311 into master mode

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

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

2010-02-23 Thread Larry Finger
On 02/23/2010 08:43 PM, D1e6o! wrote:
 Hello, I'm getting problems to turn my laptop in master mode.
 
 When I try to change the mode I get an error:
 
 sudo iwconfig wlan0 mode master
 Error for wireless request Set Mode (8B06) :
 SET failed on device wlan0 ; Invalid argument.
 
 I followed 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: [PATCH V2] ssb: Add PCI ID 0x4322 to PMU handling

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

 Signed-off-by: Larry Finger larry.fin...@lwfinger.net
 ---

 John,

 This will be needed for some of the N PHY devices - 2.6.34
 amterial.

 Larry
 ---

 V2 - Fix typo in subject line of commit message.

 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

2010-02-20 Thread Larry Finger
Some of the N PHYs need a revision in the handling of the PMU.

Signed-off-by: Larry Finger larry.fin...@lwfinger.net
---

John,

This will be needed for some of the N PHY devices - 2.6.34 amterial.

Larry
---

V2 - Fix typo in subject line of commit message.

Index: wireless-testing/drivers/ssb/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

2010-02-19 Thread Larry Finger
Some of the N PHYs need a revision in the handling of the PMU.

Signed-off-by: Larry Finger larry.fin...@lwfinger.net
---

John,

This will be needed for some of the N PHY devices - 2.6.34 amterial.

Larry
---

Index: wireless-testing/drivers/ssb/driver_chipcommon_pmu.c
===
--- 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: [PATCH 11/11] b43: N-PHY: switch to chanspec ops

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

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

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

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

2010-02-06 Thread Larry Finger
On 02/06/2010 06:49 PM, strk wrote:
 On Sat, Feb 06, 2010 at 06:29:03PM -0600, Larry Finger wrote:
 On 02/06/2010 06:22 PM, strk wrote:
 On Sat, Feb 06, 2010 at 06:20:15PM -0600, Larry Finger wrote:

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

 How 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: b43/b43legacy driver

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

2010-02-05 Thread Larry Finger
On 02/05/2010 10:41 AM, Gábor Stefanik wrote:
 On Fri, Feb 5, 2010 at 4:24 AM, Larry Finger larry.fin...@lwfinger.net 
 wrote:
 On 02/04/2010 02:57 PM, Rafał Miłecki wrote:
 ---
 Gábor: I think you missed specs here. Could you check whole routine just 
 for
 sure, please? I don't understand whole 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: [RFC][PATCH] b43: LP-PHY: always adjust gain table on channel switch

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

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

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

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


[PATCH] b43/b43legacy: Wake queues in wireless_core_start

2010-02-03 Thread 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 larry.fin...@lwfinger.net
Cc: Stable sta...@kernel.org   [2.6.32]
---

John,

The b43 patch to wireless_core_start() seems to help a regression
between 2.6.31 and 2.6.32. Accordingly, these changes should 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

2010-02-03 Thread 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 larry.fin...@lwfinger.net
Cc: Stable sta...@kernel.org   [2.6.32]
---

John,

The b43 patch to wireless_core_start() seems to help a regression
between 2.6.31 and 2.6.32. Accordingly, these changes should 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: Fix regression from commit c7ab5ef

2010-02-02 Thread 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 larry.fin...@lwfinger.net
Cc: Stable sta...@kernel.org [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: BCM4311/02 ABG disconnects on 2.6.32

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


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

2010-01-31 Thread 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 larry.fin...@lwfinger.net
Cc: Stable sta...@kernel.org [Any stable version back through 2.6.28]
---

Index: wireless-testing/drivers/net/wireless/b43/main.c
===
--- wireless-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

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

2010-01-31 Thread Larry Finger
On 01/30/2010 01:18 PM, Rafał Miłecki wrote:
 Signed-off-by: Rafał Miłecki zaj...@gmail.com
 ---

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

Larry

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


Re: BCM4311/02 ABG disconnects on 2.6.32

2010-01-28 Thread Larry Finger
On 01/28/2010 04:42 AM, Yuval Hager wrote:

 I'll be happy to apply patches as you wish.


Does this patch make any difference?


Index: wireless-testing/drivers/net/wireless/b43/main.c
===
--- 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

2010-01-28 Thread Larry Finger
On 01/28/2010 11:16 AM, Yuval Hager wrote:
 On Thursday 28 January 2010 18:25:50 Larry Finger wrote:
 On 01/28/2010 04:42 AM, Yuval Hager wrote:
 I'll be happy to apply patches as you wish.

 Does this patch make any difference?

 
 No.
 The patch did not apply on 36dbd954, I had to apply 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

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

 I ran update-pciids successfully, now dmesg 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

2010-01-26 Thread Larry Finger
In the conversion between typedef and struct, two places that needed a struct
were missed.

Signed-off-by: Larry Finger larry.fin...@lwfinger.net
---

John,

Without these, compilation fails.

Larry
---

Index: wireless-testing/drivers/net/wireless/b43/phy_n.c
===
--- 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?!?!!??!

2010-01-25 Thread Larry Finger
On 01/25/2010 02:15 PM, Lucas Thode wrote:
 As you can tell, this processor is neither an Atom nor a ULV Core 2
 Duo.  The WLAN card is the Dell Wireless 1395 that came with the laptop
 (a Vostro 1510).  I can build a custom kernel based on the Debian kernel
 sources if need be; just tell me what 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: [PATCH 0/5] b43: more N-PHY stuff

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

2010-01-15 Thread Larry Finger
On 01/15/2010 06:12 AM, Jochen Friedrich wrote:
 Daniel Schmitt wrote:
 
 hostapd doesn't continue to work after controller is restarted.
 I also have the problem that the wlan0-interface shall not be upped with
 ifconfig wlan0 0.0.0.0 up before starting hostapd, otherwise no beacons
 will be 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/3] b43: N-PHY: add RX IQ calculation for rev 3

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


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

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

 Signed-off-by: Rafał Miłecki zaj...@gmail.com
 ---

 Uh, bigger one. This patch causes false warning:
 drivers/net/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: Impossible to associate with WPA with a LP-PHY

2010-01-12 Thread 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:
 2Trying to associate with 00:18:84:15:d3:3e (SSID='MyPlace9' freq=2412
 MHz)
 2Authentication 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: Impossible to associate with WPA with a LP-PHY

2010-01-10 Thread 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:
 2Trying to associate with 00:18:84:15:d3:3e (SSID='MyPlace9' freq=2412
 MHz)
 2Authentication 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: [PATCH 1/5] b43: N-PHY: implement b43_nphy_stay_carrier_search and it's calls

2010-01-06 Thread 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: [PATCH 2/5] b43: N-PHY: add b43_nphy_get_tx_gains (V2)

2010-01-06 Thread 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 zaj...@gmail.com
 ---
  drivers/net/wireless/b43/phy_n.c |   81

Just a little nitpick to save John some work, and to keep the patches straight.

When you submit a second (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: LP-PHY: Some fixes, notices

2010-01-06 Thread 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 zaj...@gmail.com wrote:
 I've decided to made LP-PHY init code review for compatibility with specs
 and found some issues.

 We lack some code for higher PHY revisions (up from 2/3) and for some
 specific 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 1/5] b43: N-PHY: implement b43_nphy_stay_in_carrier_search and it's calls (V2)

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

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

 snip

 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: b43 on Dell i1545 laptop

2010-01-06 Thread 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: N-PHY init: current code vs. specs

2010-01-05 Thread 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 on Dell i1545 laptop

2010-01-05 Thread 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: b43 on Dell i1545 laptop

2010-01-04 Thread Larry Finger
On 01/04/2010 11:14 AM, Rafał Miłecki wrote:
 2010/1/4 Jim Haynes jhhay...@earthlink.net:
 I've just joined the list, and most of the stuff is way over my head.
 Is there a list for b43 users?

As you have noticed, this is a list for developers. The user-type questions are
generally handled in 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: [RFC][RFH] Small fixes to N-PHY init

2010-01-04 Thread 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: N-PHY init: current code vs. specs

2010-01-04 Thread 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: N-PHY init: current code vs. specs

2010-01-04 Thread 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
 zaj...@gmail.com napisał:
 Next there is a lot of code after b43_nphy_workarounds(dev); call
 that I can not recognize. Let's just take some lines for example:
 b43_nphy_reset_cca(dev);
 
 Actually 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: The newest Macbook 13.3 wireless

2010-01-02 Thread 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


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

2009-12-28 Thread 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


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

2009-12-28 Thread 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


Problem with b43_get_and_map_ringmem()

2009-12-28 Thread 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


Fatal DMA error problem with netbook and BCM4312 - Test 3

2009-12-27 Thread 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

2009-12-23 Thread 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?= zaj...@gmail.com
 mailto:zaj...@gmail.com
 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 zaj...@gmail.com 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_CHANEST, b43_ntab_channelest);
 + ntab_upload(dev, B43_NTAB_MCS, b43_ntab_mcs);
 +
 + /* 

Fatal DMA error problem with netbook and BCM4312 - Test 2

2009-12-21 Thread Larry Finger
Hi,

I placed a number of test prints in my system trying to find where a
DMA data error might occur. In doing so, I found that 3 slots in the
DMA header cache cross a page boundary. Such a situation is allowed on
my system, but it might be forbidden on Atom processors. Please try
this really ugly hack to see if it makes any difference.

Thanks,

Larry


Index: wireless-testing/drivers/net/wireless/b43/dma.h
===
--- wireless-testing.orig/drivers/net/wireless/b43/dma.h
+++ wireless-testing/drivers/net/wireless/b43/dma.h
@@ -160,7 +160,7 @@ struct b43_dmadesc_generic {
 #define B43_DMA0_RX_FRAMEOFFSET30
 
 /* DMA engine tuning knobs */
-#define B43_TXRING_SLOTS   256
+#define B43_TXRING_SLOTS   74
 #define B43_RXRING_SLOTS   64
 #define B43_DMA0_RX_BUFFERSIZE IEEE80211_MAX_FRAME_LEN
 
___
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 2

2009-12-21 Thread Larry Finger
On 12/21/2009 03:47 PM, Michael Buesch wrote:
 On Monday 21 December 2009 22:31:10 Larry Finger wrote:
 Hi,

 I placed a number of test prints in my system trying to find where a
 DMA data error might occur. In doing so, I found that 3 slots in the
 DMA header cache cross a page boundary. Such a situation is allowed on
 my system, but it might be forbidden on Atom processors. Please try
 this really ugly hack to see if it makes any difference.
 
 First thing is that the DMA buffers are allowed to cross any boundary (and
 the header is just a buffer). The boundary requirements only apply to the
 memory holding the descriptors.

That is what we will test for the Atom. I know it doesn't matter for
my CPU, but ...

 Second thing is: How does the patch prevent a boundary crossing?

The number of slots is reduced to the point that the header cache fits
in one page, just as the RX header cache does. As I said, this is
really ugly. If this fixes the problem, then a more elegant fix will
be 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 2

2009-12-21 Thread Larry Finger
On 12/21/2009 04:11 PM, Michael Buesch wrote:
 On Monday 21 December 2009 23:02:39 Larry Finger wrote:
 On 12/21/2009 03:47 PM, Michael Buesch wrote:
 On Monday 21 December 2009 22:31:10 Larry Finger wrote:
 Hi,

 I placed a number of test prints in my system trying to find where a
 DMA data error might occur. In doing so, I found that 3 slots in the
 DMA header cache cross a page boundary. Such a situation is allowed on
 my system, but it might be forbidden on Atom processors. Please try
 this really ugly hack to see if it makes any difference.

 First thing is that the DMA buffers are allowed to cross any boundary (and
 the header is just a buffer). The boundary requirements only apply to the
 memory holding the descriptors.

 That is what we will test for the Atom. I know it doesn't matter for
 my CPU, but ...
 
 I'm pretty sure the broadcom DMA engine is not _that_ braindead.
 (It is pretty weird, but not _that_ weird).
 It would effectively mean that we'd have to bouncebuffer _every_ TX packet.

I'm not that worried about the Broadcom implementation as I am about
the support chips on the Netbooks.

 Second thing is: How does the patch prevent a boundary crossing?

 The number of slots is reduced to the point that the header cache fits
 in one page, just as the RX header cache does. As I said, this is
 really ugly. If this fixes the problem, then a more elegant fix will
 be needed.
 
 But the allocation is not required to be aligned to the page start.
 The first header might start at offset 4000 of a page, so you cross
 the page border after the first few headers.

Here, it was slot 74 that crossed the page boundary. At 110 bytes per
every 2 slots, that works out to 4070 bytes for 0 - 73. From that, I
infer that the cache starts on a page boundary.

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 2

2009-12-21 Thread Larry Finger
On 12/21/2009 04:18 PM, William Bourque wrote:
 
 
 Larry Finger wrote:
 Hi,

 I placed a number of test prints in my system trying to find where a
 DMA data error might occur. In doing so, I found that 3 slots in the
 DMA header cache cross a page boundary. Such a situation is allowed on
 my system, but it might be forbidden on Atom processors. Please try
 this really ugly hack to see if it makes any difference.
 
 I confirm that the DMA error is still present with this patch.

Thanks for testing. The results are as Michael expected, and as I feared.

Larry


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


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

2009-12-21 Thread 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


Re: [PATCH] b43: Clear PCI configuration reg. 0x41 to avoid interference with C3 processor state

2009-12-20 Thread Larry Finger
On 12/20/2009 03:53 PM, Luis R. Rodriguez wrote:
 I should note 0x40 starts with vendor specific PCI config space so you
 cannot guarantee different PCI devices use 0x41 will be used the same
 for different devices. The documentation for the ath9k PCI-E devices
 used that entry for something completely different but what I did not
 do is try to very and ensure PCI devices do not use it it for the
 same. I am told though that although this is PCI vendor space some
 devices may still use similar private PCI config spaces on different
 devices which just follows a practice. At this point we now have not
 only b43, ipw and ath9k follow this but also prism54 and I think p54
 uses this. I'll note I *highly* doubt this is used for the same thing
 on all these devices and was just code copied from other Linux
 drivers. In the case of Atheros Linux drivers I know it was copied
 form Intel drivers, which is why I started questioning it all.

 Anyway, if it helps, that's great :) but it cannot be concluded its
 all for the same thing unless you have proper documentation as this is
 in PCI vendor space which *can* vary depending on device and vendor.
 
 Larry, does this actually fix something or is this code purely speculative?

I got on this idea because I logged all PCI configuration read/write
values and discovered that the Broadcom wl driver did a read/write on
this location. A later examination of the open-source part of that
driver showed that they copied it from ipw2100. If anyone knows the
layout of the private area of the configuration space, they should;
however, they may be just propagating the code as you say.

This change does not fix the DMA error problem with Atom processors in
Netbooks. We have had one report of DMA errors in a Core Duo system -
AFAIK, the only non-Atom processor with the problem. That user has not
tested this patch.

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


Re: [PATCH] b43: Clear PCI configuration reg. 0x41 to avoid interference with C3 processor state

2009-12-20 Thread Larry Finger
On 12/19/2009 11:01 PM, Larry Finger wrote:
 In exploring the cause of DMA errors for BCM4312 devices on Atom
 processors, other drivers that work write to PCI configuration
 register 0x40. The code fragment below was found in the open-code
 portion of the Broadcom hybrid wl driver. It is also used in the
 ipw2100 and ath9k drivers. In the latter case, it had been removed
 and later restored to prevent fatal interrupt errors.
 
 Signed-off-by: Larry Finger larry.fin...@lwfinger.net
 ---
 
 John,
 
 I think this is 2.6.34 material. By itself, it does not affect the
 DMA errors in BCM4312 devices. If it is found to help in the resolution
 of that long-standing problem, I will request a change in the status.
 
 Larry
 ---

John,

Please consider this patch retracted. If I actually find that it helps
some system, I'll resubmit it then.

Larry

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


Re: PCI config register 0x40

2009-12-19 Thread Larry Finger
On 12/19/2009 04:11 AM, Michael Buesch wrote:
 
 Well, if 0x40 is used as RETRY_TIMEOUT in ipw, that doesn't
 mean it's the same in b43. Is the 0x40 register standardized in any way?

According to the Wikipedia article on PCI configuration space
registers, only up to 0x3F is standardized. There is, however, an
interesting article in
http://lkml.indiana.edu/hypermail/linux/kernel/0906.3/03376.html. In
the ath9k driver, similar code was removed in a clean-up, but had to
be restored as some cards got PCI fatal interrupts. I also found a
similar fragment in the C source part of the Broadcom hybrid driver.

 And if you do a patch, don't put it into ssb. Put it into b43.

I will put it in b43 as you request.

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


Re: PCI config register 0x40

2009-12-19 Thread Larry Finger
On 12/19/2009 04:11 AM, Michael Buesch wrote:
 
 And if you do a patch, don't put it into ssb. Put it into b43.

One further question about putting the patch into b43. Apparently,
register 0x40 is not preserved across a suspend/resume to disk. In all
the drivers that use this code, 0x40 is modified in the .probe and
.resume routines. As b43 does the resume indirectly through mac80211,
an alternate location is needed. It looks to me that placing the code
in b43_wireless_core_init() would satisfy both needs. Is that correct?

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 - another test

2009-12-19 Thread Larry Finger
Hi,

If possible, please test this patch starting from a cold boot. It is a
variation of something we tried earlier, but enough different to try it.

Thanks,

Larry

In exploring the cause of DMA errors for BCM4312 devices on Atom
processors, other drivers that work write to PCI configuration
register 0x40. The code fragment below was found in the open-code
portion of the Broadcom hybrid wl driver. It is also used in the
ipw2100 and ath9k drivers. In the latter case, it had been removed
and later restored to prevent fatal interrupt errors.

Signed-off-by: Larry Finger larry.fin...@lwfinger.net
---

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
@@ -4292,6 +4292,15 @@ static int b43_wireless_core_init(struct
setup_struct_wldev_for_init(dev);
phy-ops-prepare_structs(dev);
 
+   /* We disable the RETRY_TIMEOUT register (0x41) to keep
+* PCI Tx retries from interfering with C3 CPU state
+* This code fragment found in the Broadcom hybrid wl driver
+*/
+   pci_read_config_dword(bus-host_pci, 0x40, tmp);
+   if ((tmp  0xff00) != 0)
+   pci_write_config_dword(bus-host_pci, 0x40, tmp 
+  ~(0xff00));
+
/* Enable IRQ routing to this device. */
ssb_pcicore_dev_irqvecs_enable(bus-pcicore, dev-dev);
 
___
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 - another test

2009-12-19 Thread Larry Finger
On 12/19/2009 05:11 PM, Andrew Benton wrote:
 On 19/12/09 19:55, Chris Vine wrote:

 I applied this to 2.6.32.2 and it didn't help with the DMA errors I am
 afraid.

 Chris

 
 Same here, the patch didn't prevent the DMA errors, however, I did 
 notice that it only reported the error once, it didn't keep trying to 
 reload the firmware.

The change that bails out after one fatal DMA error is a separate one.
As there is no chance of recovering, we decided not to spam the logs.

Thanks for testing. I had little expectation, but this one may be
needed in conjunction with something else. Back to the grindstone.

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 - another test

2009-12-19 Thread Larry Finger
On 12/19/2009 10:15 PM, William Bourque wrote:
 
 
 Larry Finger wrote:
 Hi,

 If possible, please test this patch starting from a cold boot. It is a
 variation of something we tried earlier, but enough different to try it.

 Thanks,

 Larry

 
 A little late but I just tested and I have the same bug.
 However, unlike Andrew, the error keep repeating as before...

He is using wireless-testing or a recent mainline kernel. That is
where the change I described is installed.

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


[PATCH] b43: Clear PCI configuration reg. 0x41 to avoid interference with C3 processor state

2009-12-19 Thread Larry Finger
In exploring the cause of DMA errors for BCM4312 devices on Atom
processors, other drivers that work write to PCI configuration
register 0x40. The code fragment below was found in the open-code
portion of the Broadcom hybrid wl driver. It is also used in the
ipw2100 and ath9k drivers. In the latter case, it had been removed
and later restored to prevent fatal interrupt errors.

Signed-off-by: Larry Finger larry.fin...@lwfinger.net
---

John,

I think this is 2.6.34 material. By itself, it does not affect the
DMA errors in BCM4312 devices. If it is found to help in the resolution
of that long-standing problem, I will request a change in the status.

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
@@ -4292,6 +4292,15 @@ static int b43_wireless_core_init(struct
setup_struct_wldev_for_init(dev);
phy-ops-prepare_structs(dev);
 
+   /* We disable the RETRY_TIMEOUT register (0x41) to keep
+* PCI Tx retries from interfering with C3 CPU state
+*/
+   if (bus-bustype == SSB_BUSTYPE_PCI) {
+   pci_read_config_dword(bus-host_pci, 0x40, tmp);
+   pci_write_config_dword(bus-host_pci, 0x40, tmp 
+  ~(0xff00));
+   }
+
/* Enable IRQ routing to this device. */
ssb_pcicore_dev_irqvecs_enable(bus-pcicore, dev-dev);
 
Index: wireless-testing/drivers/ssb/pcihost_wrapper.c
===
--- wireless-testing.orig/drivers/ssb/pcihost_wrapper.c
+++ wireless-testing/drivers/ssb/pcihost_wrapper.c
@@ -35,6 +35,7 @@ static int ssb_pcihost_resume(struct pci
 {
struct ssb_bus *ssb = pci_get_drvdata(dev);
int err;
+   u32 val;
 
pci_set_power_state(dev, 0);
err = pci_enable_device(dev);
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: ssb: ERROR: PLL init unknown for device 4322

2009-12-18 Thread Larry Finger
On 12/18/2009 10:19 AM, Gábor Stefanik wrote:

 Is there anything that I can try or any information that I can provide
 to make it work?
 
 BCM4322 is an N-PHY device, which is not yet supported; it will
 probably be the next thing I will implement, once Larry completes the
 reverse engineering for this PHY.

Besides the type 4 N PHY, I also have to do the RE for the type 6 PHY,
which is known as an SSLPN PHY (single-stream low-power N PHY). :)

To make your 4322 work now, you need to implement the Broadcom hybrid
STA wl driver. You can build that from files obtained from Broadcom,
or many distros have a pre-made package.

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


PCI config register 0x40

2009-12-18 Thread Larry Finger
Michael,

As you may recall, I dumped writes to the PCI config space for both
b43 and the wl driver. I found that wl wrote to address 0x40. In
looking around other drivers, I found the following fragment in ipw2100:

/* We disable the RETRY_TIMEOUT register (0x41) to keep
 * PCI Tx retries from interfering with C3 CPU state */
pci_read_config_dword(pci_dev, 0x40, val);
if ((val  0xff00) != 0)
pci_write_config_dword(pci_dev, 0x40, val 
   0x00ff);

There is a similar fragment in the resume routine.

This change is probably not responsible for the DMA errors in the
4315, but there still could be some affect. Do you want to prepare a
patch for ssb, or should I do it?

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


  1   2   3   4   5   6   7   8   9   10   >