[PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Larry Finger]

The specifications for the bcm43xx driver have been modified. This patch
incorporates these changes in the code, which results in the BCM4311 and
BCM4312 working. The name of one of the PHY parameters, previously known
as "version", has been changed to "analog core version" .

Signed-off-by: Larry Finger<Larry.Finger@lwfinger.net>
---

John,

I hope this fix makes it into 2.6.21. As you have seen from the list, it is a biggie!

Larry
---

Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h
===================================================================
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx.h
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h
@@ -542,7 +542,7 @@ struct bcm43xx_lopair {
 
 struct bcm43xx_phyinfo {
 	/* Hardware Data */
-	u8 version;
+	u8 analog;
 	u8 type;
 	u8 rev;
 	u16 antenna_diversity;
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
@@ -205,8 +205,8 @@ static void bcm43xx_phy_init_pctl(struct
 	    (bcm->board_type == 0x0416))
 		return;
 
-	bcm43xx_write16(bcm, 0x03E6, bcm43xx_read16(bcm, 0x03E6) & 0xFFDF);
 	bcm43xx_phy_write(bcm, 0x0028, 0x8018);
+	bcm43xx_write16(bcm, 0x03E6, bcm43xx_read16(bcm, 0x03E6) & 0xFFDF);
 
 	if (phy->type == BCM43xx_PHYTYPE_G) {
 		if (!phy->connected)
@@ -729,19 +729,19 @@ static void bcm43xx_phy_initb5(struct bc
 	struct bcm43xx_phyinfo *phy = bcm43xx_current_phy(bcm);
 	struct bcm43xx_radioinfo *radio = bcm43xx_current_radio(bcm);
 	u16 offset;
+	u16 value;
+	u8 old_channel;
 
-	if (phy->version == 1 &&
-	    radio->version == 0x2050) {
+	if (phy->analog == 1)
 		bcm43xx_radio_write16(bcm, 0x007A,
 				      bcm43xx_radio_read16(bcm, 0x007A)
 				      | 0x0050);
-	}
 	if ((bcm->board_vendor != PCI_VENDOR_ID_BROADCOM) &&
 	    (bcm->board_type != 0x0416)) {
+		value = 0x2120;
 		for (offset = 0x00A8 ; offset < 0x00C7; offset++) {
-			bcm43xx_phy_write(bcm, offset,
-					  (bcm43xx_phy_read(bcm, offset) + 0x2020)
-					  & 0x3F3F);
+			bcm43xx_phy_write(bcm, offset, value);
+			value += 0x0202;
 		}
 	}
 	bcm43xx_phy_write(bcm, 0x0035,
@@ -776,7 +776,7 @@ static void bcm43xx_phy_initb5(struct bc
 				  bcm43xx_phy_read(bcm, BCM43xx_PHY_RADIO_BITFIELD) | (1 << 11));
 	}
 
-	if (phy->version == 1 && radio->version == 0x2050) {
+	if (phy->analog == 1) {
 		bcm43xx_phy_write(bcm, 0x0026, 0xCE00);
 		bcm43xx_phy_write(bcm, 0x0021, 0x3763);
 		bcm43xx_phy_write(bcm, 0x0022, 0x1BC3);
@@ -787,14 +787,15 @@ static void bcm43xx_phy_initb5(struct bc
 	bcm43xx_phy_write(bcm, 0x0030, 0x00C6);
 	bcm43xx_write16(bcm, 0x03EC, 0x3F22);
 
-	if (phy->version == 1 && radio->version == 0x2050)
+	if (phy->analog == 1)
 		bcm43xx_phy_write(bcm, 0x0020, 0x3E1C);
 	else
 		bcm43xx_phy_write(bcm, 0x0020, 0x301C);
 
-	if (phy->version == 0)
+	if (phy->analog == 0)
 		bcm43xx_write16(bcm, 0x03E4, 0x3000);
 
+	old_channel = radio->channel;
 	/* Force to channel 7, even if not supported. */
 	bcm43xx_radio_selectchannel(bcm, 7, 0);
 
@@ -816,11 +817,11 @@ static void bcm43xx_phy_initb5(struct bc
 
 	bcm43xx_radio_write16(bcm, 0x007A, bcm43xx_radio_read16(bcm, 0x007A) | 0x0007);
 
-	bcm43xx_radio_selectchannel(bcm, BCM43xx_RADIO_DEFAULT_CHANNEL_BG, 0);
+	bcm43xx_radio_selectchannel(bcm, old_channel, 0);
 
 	bcm43xx_phy_write(bcm, 0x0014, 0x0080);
 	bcm43xx_phy_write(bcm, 0x0032, 0x00CA);
-	bcm43xx_phy_write(bcm, 0x88A3, 0x002A);
+	bcm43xx_phy_write(bcm, 0x002A, 0x88A3);
 
 	bcm43xx_radio_set_txpower_bg(bcm, 0xFFFF, 0xFFFF, 0xFFFF);
 
@@ -933,6 +934,8 @@ static void bcm43xx_phy_initb6(struct bc
 		                  bcm43xx_phy_read(bcm, 0x0802) | 0x0100);
 		bcm43xx_phy_write(bcm, 0x042B,
 		                  bcm43xx_phy_read(bcm, 0x042B) | 0x2000);
+		bcm43xx_phy_write(bcm, 0x5B, 0x0000);
+		bcm43xx_phy_write(bcm, 0x5C, 0x0000);
 	}
 
 	/* Force to channel 7, even if not supported. */
@@ -976,10 +979,12 @@ static void bcm43xx_phy_initb6(struct bc
 			bcm43xx_radio_write16(bcm, 0x005D, 0x000D);
 	}
 	
-	if (phy->rev == 4)
-		bcm43xx_phy_write(bcm, 0x0002, (bcm43xx_phy_read(bcm, 0x0002) & 0xFFC0) | 0x0004);
-	else
+	if (phy->analog == 4){
 		bcm43xx_write16(bcm, 0x03E4, 0x0009);
+		bcm43xx_phy_write(bcm, 0x61, bcm43xx_phy_read(bcm, 0x61) & 0xFFF);
+	} else {
+		bcm43xx_phy_write(bcm, 0x0002, (bcm43xx_phy_read(bcm, 0x0002) & 0xFFC0) | 0x0004);
+	}
 	if (phy->type == BCM43xx_PHYTYPE_B) {
 		bcm43xx_write16(bcm, 0x03E6, 0x8140);
 		bcm43xx_phy_write(bcm, 0x0016, 0x0410);
@@ -1063,7 +1068,7 @@ static void bcm43xx_calc_loopback_gain(s
 	bcm43xx_phy_write(bcm, 0x005A, 0x0780);
 	bcm43xx_phy_write(bcm, 0x0059, 0xC810);
 	bcm43xx_phy_write(bcm, 0x0058, 0x000D);
-	if (phy->version == 0) {
+	if (phy->analog == 0) {
 		bcm43xx_phy_write(bcm, 0x0003, 0x0122);
 	} else {
 		bcm43xx_phy_write(bcm, 0x000A,
@@ -1225,7 +1230,7 @@ static void bcm43xx_phy_initg(struct bcm
 	}
 	if (phy->rev < 3 && phy->connected)
 		bcm43xx_phy_write(bcm, 0x047E, 0x0078);
-	if (phy->rev >= 6 && phy->rev <= 8) {
+	if (radio->revision == 8) {
 		bcm43xx_phy_write(bcm, 0x0801, bcm43xx_phy_read(bcm, 0x0801) | 0x0080);
 		bcm43xx_phy_write(bcm, 0x043E, bcm43xx_phy_read(bcm, 0x043E) | 0x0004);
 	}
@@ -1638,14 +1643,14 @@ void bcm43xx_phy_set_baseband_attenuatio
 	struct bcm43xx_phyinfo *phy = bcm43xx_current_phy(bcm);
 	u16 value;
 
-	if (phy->version == 0) {
+	if (phy->analog == 0) {
 		value = (bcm43xx_read16(bcm, 0x03E6) & 0xFFF0);
 		value |= (baseband_attenuation & 0x000F);
 		bcm43xx_write16(bcm, 0x03E6, value);
 		return;
 	}
 
-	if (phy->version > 1) {
+	if (phy->analog > 1) {
 		value = bcm43xx_phy_read(bcm, 0x0060) & ~0x003C;
 		value |= (baseband_attenuation << 2) & 0x003C;
 	} else {
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
@@ -1393,11 +1393,12 @@ u16 bcm43xx_radio_init2050(struct bcm43x
 	backup[12] = bcm43xx_read16(bcm, BCM43xx_MMIO_CHANNEL_EXT);
 
 	// Initialization
-	if (phy->version == 0) {
+	if (phy->analog == 0) {
 		bcm43xx_write16(bcm, 0x03E6, 0x0122);
 	} else {
-		if (phy->version >= 2)
-			bcm43xx_write16(bcm, 0x03E6, 0x0040);
+		if (phy->analog >= 2)
+			bcm43xx_write16(bcm, 0x0003, (bcm43xx_read16(bcm, 0x0003)
+					& 0xFFBF) | 0x0040);
 		bcm43xx_write16(bcm, BCM43xx_MMIO_CHANNEL_EXT,
 		                (bcm43xx_read16(bcm, BCM43xx_MMIO_CHANNEL_EXT) | 0x2000));
 	}
@@ -1488,7 +1489,7 @@ u16 bcm43xx_radio_init2050(struct bcm43x
 	bcm43xx_phy_write(bcm, 0x0059, backup[17]);
 	bcm43xx_phy_write(bcm, 0x0058, backup[18]);
 	bcm43xx_write16(bcm, 0x03E6, backup[11]);
-	if (phy->version != 0)
+	if (phy->analog != 0)
 		bcm43xx_write16(bcm, BCM43xx_MMIO_CHANNEL_EXT, backup[12]);
 	bcm43xx_phy_write(bcm, 0x0035, backup[10]);
 	bcm43xx_radio_selectchannel(bcm, radio->channel, 1);
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -3699,7 +3699,7 @@ static int bcm43xx_read_phyinfo(struct b
 {
 	struct bcm43xx_phyinfo *phy = bcm43xx_current_phy(bcm);
 	u16 value;
-	u8 phy_version;
+	u8 phy_analog;
 	u8 phy_type;
 	u8 phy_rev;
 	int phy_rev_ok = 1;
@@ -3707,12 +3707,12 @@ static int bcm43xx_read_phyinfo(struct b
 
 	value = bcm43xx_read16(bcm, BCM43xx_MMIO_PHY_VER);
 
-	phy_version = (value & 0xF000) >> 12;
+	phy_analog = (value & 0xF000) >> 12;
 	phy_type = (value & 0x0F00) >> 8;
 	phy_rev = (value & 0x000F);
 
 	dprintk(KERN_INFO PFX "Detected PHY: Version: %x, Type %x, Revision %x\n",
-		phy_version, phy_type, phy_rev);
+		phy_analog, phy_type, phy_rev);
 
 	switch (phy_type) {
 	case BCM43xx_PHYTYPE_A:
@@ -3755,7 +3755,7 @@ static int bcm43xx_read_phyinfo(struct b
 		       phy_rev);
 	}
 
-	phy->version = phy_version;
+	phy->analog = phy_analog;
 	phy->type = phy_type;
 	phy->rev = phy_rev;
 	if ((phy_type == BCM43xx_PHYTYPE_B) || (phy_type == BCM43xx_PHYTYPE_G)) {

[PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Larry Finger]

The specifications for the bcm43xx driver have been modified. This patch
incorporates these changes in the code, which results in the BCM4311 and
BCM4312 working. The name of one of the PHY parameters, previously known
as "version", has been changed to "analog core version" .

Signed-off-by: Larry Finger<Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
---

John,

I hope this fix makes it into 2.6.21. As you have seen from the list, it is a biggie!

Larry
---

Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h
===================================================================
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx.h
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h
@@ -542,7 +542,7 @@ struct bcm43xx_lopair {
 
 struct bcm43xx_phyinfo {
 	/* Hardware Data */
-	u8 version;
+	u8 analog;
 	u8 type;
 	u8 rev;
 	u16 antenna_diversity;
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
@@ -205,8 +205,8 @@ static void bcm43xx_phy_init_pctl(struct
 	    (bcm->board_type == 0x0416))
 		return;
 
-	bcm43xx_write16(bcm, 0x03E6, bcm43xx_read16(bcm, 0x03E6) & 0xFFDF);
 	bcm43xx_phy_write(bcm, 0x0028, 0x8018);
+	bcm43xx_write16(bcm, 0x03E6, bcm43xx_read16(bcm, 0x03E6) & 0xFFDF);
 
 	if (phy->type == BCM43xx_PHYTYPE_G) {
 		if (!phy->connected)
@@ -729,19 +729,19 @@ static void bcm43xx_phy_initb5(struct bc
 	struct bcm43xx_phyinfo *phy = bcm43xx_current_phy(bcm);
 	struct bcm43xx_radioinfo *radio = bcm43xx_current_radio(bcm);
 	u16 offset;
+	u16 value;
+	u8 old_channel;
 
-	if (phy->version == 1 &&
-	    radio->version == 0x2050) {
+	if (phy->analog == 1)
 		bcm43xx_radio_write16(bcm, 0x007A,
 				      bcm43xx_radio_read16(bcm, 0x007A)
 				      | 0x0050);
-	}
 	if ((bcm->board_vendor != PCI_VENDOR_ID_BROADCOM) &&
 	    (bcm->board_type != 0x0416)) {
+		value = 0x2120;
 		for (offset = 0x00A8 ; offset < 0x00C7; offset++) {
-			bcm43xx_phy_write(bcm, offset,
-					  (bcm43xx_phy_read(bcm, offset) + 0x2020)
-					  & 0x3F3F);
+			bcm43xx_phy_write(bcm, offset, value);
+			value += 0x0202;
 		}
 	}
 	bcm43xx_phy_write(bcm, 0x0035,
@@ -776,7 +776,7 @@ static void bcm43xx_phy_initb5(struct bc
 				  bcm43xx_phy_read(bcm, BCM43xx_PHY_RADIO_BITFIELD) | (1 << 11));
 	}
 
-	if (phy->version == 1 && radio->version == 0x2050) {
+	if (phy->analog == 1) {
 		bcm43xx_phy_write(bcm, 0x0026, 0xCE00);
 		bcm43xx_phy_write(bcm, 0x0021, 0x3763);
 		bcm43xx_phy_write(bcm, 0x0022, 0x1BC3);
@@ -787,14 +787,15 @@ static void bcm43xx_phy_initb5(struct bc
 	bcm43xx_phy_write(bcm, 0x0030, 0x00C6);
 	bcm43xx_write16(bcm, 0x03EC, 0x3F22);
 
-	if (phy->version == 1 && radio->version == 0x2050)
+	if (phy->analog == 1)
 		bcm43xx_phy_write(bcm, 0x0020, 0x3E1C);
 	else
 		bcm43xx_phy_write(bcm, 0x0020, 0x301C);
 
-	if (phy->version == 0)
+	if (phy->analog == 0)
 		bcm43xx_write16(bcm, 0x03E4, 0x3000);
 
+	old_channel = radio->channel;
 	/* Force to channel 7, even if not supported. */
 	bcm43xx_radio_selectchannel(bcm, 7, 0);
 
@@ -816,11 +817,11 @@ static void bcm43xx_phy_initb5(struct bc
 
 	bcm43xx_radio_write16(bcm, 0x007A, bcm43xx_radio_read16(bcm, 0x007A) | 0x0007);
 
-	bcm43xx_radio_selectchannel(bcm, BCM43xx_RADIO_DEFAULT_CHANNEL_BG, 0);
+	bcm43xx_radio_selectchannel(bcm, old_channel, 0);
 
 	bcm43xx_phy_write(bcm, 0x0014, 0x0080);
 	bcm43xx_phy_write(bcm, 0x0032, 0x00CA);
-	bcm43xx_phy_write(bcm, 0x88A3, 0x002A);
+	bcm43xx_phy_write(bcm, 0x002A, 0x88A3);
 
 	bcm43xx_radio_set_txpower_bg(bcm, 0xFFFF, 0xFFFF, 0xFFFF);
 
@@ -933,6 +934,8 @@ static void bcm43xx_phy_initb6(struct bc
 		                  bcm43xx_phy_read(bcm, 0x0802) | 0x0100);
 		bcm43xx_phy_write(bcm, 0x042B,
 		                  bcm43xx_phy_read(bcm, 0x042B) | 0x2000);
+		bcm43xx_phy_write(bcm, 0x5B, 0x0000);
+		bcm43xx_phy_write(bcm, 0x5C, 0x0000);
 	}
 
 	/* Force to channel 7, even if not supported. */
@@ -976,10 +979,12 @@ static void bcm43xx_phy_initb6(struct bc
 			bcm43xx_radio_write16(bcm, 0x005D, 0x000D);
 	}
 	
-	if (phy->rev == 4)
-		bcm43xx_phy_write(bcm, 0x0002, (bcm43xx_phy_read(bcm, 0x0002) & 0xFFC0) | 0x0004);
-	else
+	if (phy->analog == 4){
 		bcm43xx_write16(bcm, 0x03E4, 0x0009);
+		bcm43xx_phy_write(bcm, 0x61, bcm43xx_phy_read(bcm, 0x61) & 0xFFF);
+	} else {
+		bcm43xx_phy_write(bcm, 0x0002, (bcm43xx_phy_read(bcm, 0x0002) & 0xFFC0) | 0x0004);
+	}
 	if (phy->type == BCM43xx_PHYTYPE_B) {
 		bcm43xx_write16(bcm, 0x03E6, 0x8140);
 		bcm43xx_phy_write(bcm, 0x0016, 0x0410);
@@ -1063,7 +1068,7 @@ static void bcm43xx_calc_loopback_gain(s
 	bcm43xx_phy_write(bcm, 0x005A, 0x0780);
 	bcm43xx_phy_write(bcm, 0x0059, 0xC810);
 	bcm43xx_phy_write(bcm, 0x0058, 0x000D);
-	if (phy->version == 0) {
+	if (phy->analog == 0) {
 		bcm43xx_phy_write(bcm, 0x0003, 0x0122);
 	} else {
 		bcm43xx_phy_write(bcm, 0x000A,
@@ -1225,7 +1230,7 @@ static void bcm43xx_phy_initg(struct bcm
 	}
 	if (phy->rev < 3 && phy->connected)
 		bcm43xx_phy_write(bcm, 0x047E, 0x0078);
-	if (phy->rev >= 6 && phy->rev <= 8) {
+	if (radio->revision == 8) {
 		bcm43xx_phy_write(bcm, 0x0801, bcm43xx_phy_read(bcm, 0x0801) | 0x0080);
 		bcm43xx_phy_write(bcm, 0x043E, bcm43xx_phy_read(bcm, 0x043E) | 0x0004);
 	}
@@ -1638,14 +1643,14 @@ void bcm43xx_phy_set_baseband_attenuatio
 	struct bcm43xx_phyinfo *phy = bcm43xx_current_phy(bcm);
 	u16 value;
 
-	if (phy->version == 0) {
+	if (phy->analog == 0) {
 		value = (bcm43xx_read16(bcm, 0x03E6) & 0xFFF0);
 		value |= (baseband_attenuation & 0x000F);
 		bcm43xx_write16(bcm, 0x03E6, value);
 		return;
 	}
 
-	if (phy->version > 1) {
+	if (phy->analog > 1) {
 		value = bcm43xx_phy_read(bcm, 0x0060) & ~0x003C;
 		value |= (baseband_attenuation << 2) & 0x003C;
 	} else {
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
@@ -1393,11 +1393,12 @@ u16 bcm43xx_radio_init2050(struct bcm43x
 	backup[12] = bcm43xx_read16(bcm, BCM43xx_MMIO_CHANNEL_EXT);
 
 	// Initialization
-	if (phy->version == 0) {
+	if (phy->analog == 0) {
 		bcm43xx_write16(bcm, 0x03E6, 0x0122);
 	} else {
-		if (phy->version >= 2)
-			bcm43xx_write16(bcm, 0x03E6, 0x0040);
+		if (phy->analog >= 2)
+			bcm43xx_write16(bcm, 0x0003, (bcm43xx_read16(bcm, 0x0003)
+					& 0xFFBF) | 0x0040);
 		bcm43xx_write16(bcm, BCM43xx_MMIO_CHANNEL_EXT,
 		                (bcm43xx_read16(bcm, BCM43xx_MMIO_CHANNEL_EXT) | 0x2000));
 	}
@@ -1488,7 +1489,7 @@ u16 bcm43xx_radio_init2050(struct bcm43x
 	bcm43xx_phy_write(bcm, 0x0059, backup[17]);
 	bcm43xx_phy_write(bcm, 0x0058, backup[18]);
 	bcm43xx_write16(bcm, 0x03E6, backup[11]);
-	if (phy->version != 0)
+	if (phy->analog != 0)
 		bcm43xx_write16(bcm, BCM43xx_MMIO_CHANNEL_EXT, backup[12]);
 	bcm43xx_phy_write(bcm, 0x0035, backup[10]);
 	bcm43xx_radio_selectchannel(bcm, radio->channel, 1);
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -3699,7 +3699,7 @@ static int bcm43xx_read_phyinfo(struct b
 {
 	struct bcm43xx_phyinfo *phy = bcm43xx_current_phy(bcm);
 	u16 value;
-	u8 phy_version;
+	u8 phy_analog;
 	u8 phy_type;
 	u8 phy_rev;
 	int phy_rev_ok = 1;
@@ -3707,12 +3707,12 @@ static int bcm43xx_read_phyinfo(struct b
 
 	value = bcm43xx_read16(bcm, BCM43xx_MMIO_PHY_VER);
 
-	phy_version = (value & 0xF000) >> 12;
+	phy_analog = (value & 0xF000) >> 12;
 	phy_type = (value & 0x0F00) >> 8;
 	phy_rev = (value & 0x000F);
 
 	dprintk(KERN_INFO PFX "Detected PHY: Version: %x, Type %x, Revision %x\n",
-		phy_version, phy_type, phy_rev);
+		phy_analog, phy_type, phy_rev);
 
 	switch (phy_type) {
 	case BCM43xx_PHYTYPE_A:
@@ -3755,7 +3755,7 @@ static int bcm43xx_read_phyinfo(struct b
 		       phy_rev);
 	}
 
-	phy->version = phy_version;
+	phy->analog = phy_analog;
 	phy->type = phy_type;
 	phy->rev = phy_rev;
 	if ((phy_type == BCM43xx_PHYTYPE_B) || (phy_type == BCM43xx_PHYTYPE_G)) {

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Michael Buesch]

On Friday 09 February 2007 17:32, Larry Finger wrote:
> The specifications for the bcm43xx driver have been modified. This patch
> incorporates these changes in the code, which results in the BCM4311 and
> BCM4312 working. The name of one of the PHY parameters, previously known
> as "version", has been changed to "analog core version" .
> 
> Signed-off-by: Larry Finger<Larry.Finger@lwfinger.net>
> ---

> @@ -729,19 +729,19 @@ static void bcm43xx_phy_initb5(struct bc
>  	struct bcm43xx_phyinfo *phy = bcm43xx_current_phy(bcm);
>  	struct bcm43xx_radioinfo *radio = bcm43xx_current_radio(bcm);
>  	u16 offset;
> +	u16 value;
> +	u8 old_channel;
>  
> -	if (phy->version == 1 &&
> -	    radio->version == 0x2050) {

Why do you delete the check to radio version.
It's still there in latest specs:
http://bcm-v4.sipsolutions.net/802.11/PHY/Init/B5

> +	if (phy->analog == 1)
>  		bcm43xx_radio_write16(bcm, 0x007A,
>  				      bcm43xx_radio_read16(bcm, 0x007A)
>  				      | 0x0050);
> -	}
>  	if ((bcm->board_vendor != PCI_VENDOR_ID_BROADCOM) &&
>  	    (bcm->board_type != 0x0416)) {
> +		value = 0x2120;
>  		for (offset = 0x00A8 ; offset < 0x00C7; offset++) {
> -			bcm43xx_phy_write(bcm, offset,
> -					  (bcm43xx_phy_read(bcm, offset) + 0x2020)
> -					  & 0x3F3F);
> +			bcm43xx_phy_write(bcm, offset, value);
> +			value += 0x0202;
>  		}

I don't see how this matches specs.

>  	}
>  	bcm43xx_phy_write(bcm, 0x0035,
> @@ -776,7 +776,7 @@ static void bcm43xx_phy_initb5(struct bc
>  				  bcm43xx_phy_read(bcm, BCM43xx_PHY_RADIO_BITFIELD) | (1 << 11));
>  	}
>  
> -	if (phy->version == 1 && radio->version == 0x2050) {

Dito.

> +	if (phy->analog == 1) {
>  		bcm43xx_phy_write(bcm, 0x0026, 0xCE00);
>  		bcm43xx_phy_write(bcm, 0x0021, 0x3763);
>  		bcm43xx_phy_write(bcm, 0x0022, 0x1BC3);
> @@ -787,14 +787,15 @@ static void bcm43xx_phy_initb5(struct bc
>  	bcm43xx_phy_write(bcm, 0x0030, 0x00C6);
>  	bcm43xx_write16(bcm, 0x03EC, 0x3F22);
>  
> -	if (phy->version == 1 && radio->version == 0x2050)

Dito.

> +	if (phy->analog == 1)
>  		bcm43xx_phy_write(bcm, 0x0020, 0x3E1C);
>  	else
>  		bcm43xx_phy_write(bcm, 0x0020, 0x301C);
>  
> -	if (phy->version == 0)
> +	if (phy->analog == 0)
>  		bcm43xx_write16(bcm, 0x03E4, 0x3000);
>  
> +	old_channel = radio->channel;
>  	/* Force to channel 7, even if not supported. */
>  	bcm43xx_radio_selectchannel(bcm, 7, 0);
>  
> @@ -816,11 +817,11 @@ static void bcm43xx_phy_initb5(struct bc
>  
>  	bcm43xx_radio_write16(bcm, 0x007A, bcm43xx_radio_read16(bcm, 0x007A) | 0x0007);
>  
> -	bcm43xx_radio_selectchannel(bcm, BCM43xx_RADIO_DEFAULT_CHANNEL_BG, 0);
> +	bcm43xx_radio_selectchannel(bcm, old_channel, 0);
>  
>  	bcm43xx_phy_write(bcm, 0x0014, 0x0080);
>  	bcm43xx_phy_write(bcm, 0x0032, 0x00CA);
> -	bcm43xx_phy_write(bcm, 0x88A3, 0x002A);
> +	bcm43xx_phy_write(bcm, 0x002A, 0x88A3);

Well, this seems correct, but specs are still different. From where did you get this?


Well, I don't review the rest until you say to which specs you did the changes. ;)

-- 
Greetings Michael.

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Michael Buesch]

On Friday 09 February 2007 17:32, Larry Finger wrote:
> The specifications for the bcm43xx driver have been modified. This patch
> incorporates these changes in the code, which results in the BCM4311 and
> BCM4312 working. The name of one of the PHY parameters, previously known
> as "version", has been changed to "analog core version" .
> 
> Signed-off-by: Larry Finger<Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
> ---

> @@ -729,19 +729,19 @@ static void bcm43xx_phy_initb5(struct bc
>  	struct bcm43xx_phyinfo *phy = bcm43xx_current_phy(bcm);
>  	struct bcm43xx_radioinfo *radio = bcm43xx_current_radio(bcm);
>  	u16 offset;
> +	u16 value;
> +	u8 old_channel;
>  
> -	if (phy->version == 1 &&
> -	    radio->version == 0x2050) {

Why do you delete the check to radio version.
It's still there in latest specs:
http://bcm-v4.sipsolutions.net/802.11/PHY/Init/B5

> +	if (phy->analog == 1)
>  		bcm43xx_radio_write16(bcm, 0x007A,
>  				      bcm43xx_radio_read16(bcm, 0x007A)
>  				      | 0x0050);
> -	}
>  	if ((bcm->board_vendor != PCI_VENDOR_ID_BROADCOM) &&
>  	    (bcm->board_type != 0x0416)) {
> +		value = 0x2120;
>  		for (offset = 0x00A8 ; offset < 0x00C7; offset++) {
> -			bcm43xx_phy_write(bcm, offset,
> -					  (bcm43xx_phy_read(bcm, offset) + 0x2020)
> -					  & 0x3F3F);
> +			bcm43xx_phy_write(bcm, offset, value);
> +			value += 0x0202;
>  		}

I don't see how this matches specs.

>  	}
>  	bcm43xx_phy_write(bcm, 0x0035,
> @@ -776,7 +776,7 @@ static void bcm43xx_phy_initb5(struct bc
>  				  bcm43xx_phy_read(bcm, BCM43xx_PHY_RADIO_BITFIELD) | (1 << 11));
>  	}
>  
> -	if (phy->version == 1 && radio->version == 0x2050) {

Dito.

> +	if (phy->analog == 1) {
>  		bcm43xx_phy_write(bcm, 0x0026, 0xCE00);
>  		bcm43xx_phy_write(bcm, 0x0021, 0x3763);
>  		bcm43xx_phy_write(bcm, 0x0022, 0x1BC3);
> @@ -787,14 +787,15 @@ static void bcm43xx_phy_initb5(struct bc
>  	bcm43xx_phy_write(bcm, 0x0030, 0x00C6);
>  	bcm43xx_write16(bcm, 0x03EC, 0x3F22);
>  
> -	if (phy->version == 1 && radio->version == 0x2050)

Dito.

> +	if (phy->analog == 1)
>  		bcm43xx_phy_write(bcm, 0x0020, 0x3E1C);
>  	else
>  		bcm43xx_phy_write(bcm, 0x0020, 0x301C);
>  
> -	if (phy->version == 0)
> +	if (phy->analog == 0)
>  		bcm43xx_write16(bcm, 0x03E4, 0x3000);
>  
> +	old_channel = radio->channel;
>  	/* Force to channel 7, even if not supported. */
>  	bcm43xx_radio_selectchannel(bcm, 7, 0);
>  
> @@ -816,11 +817,11 @@ static void bcm43xx_phy_initb5(struct bc
>  
>  	bcm43xx_radio_write16(bcm, 0x007A, bcm43xx_radio_read16(bcm, 0x007A) | 0x0007);
>  
> -	bcm43xx_radio_selectchannel(bcm, BCM43xx_RADIO_DEFAULT_CHANNEL_BG, 0);
> +	bcm43xx_radio_selectchannel(bcm, old_channel, 0);
>  
>  	bcm43xx_phy_write(bcm, 0x0014, 0x0080);
>  	bcm43xx_phy_write(bcm, 0x0032, 0x00CA);
> -	bcm43xx_phy_write(bcm, 0x88A3, 0x002A);
> +	bcm43xx_phy_write(bcm, 0x002A, 0x88A3);

Well, this seems correct, but specs are still different. From where did you get this?


Well, I don't review the rest until you say to which specs you did the changes. ;)

-- 
Greetings Michael.

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Larry Finger]

Michael,

Michael Buesch wrote:
> On Friday 09 February 2007 17:32, Larry Finger wrote:
>> The specifications for the bcm43xx driver have been modified. This patch
>> incorporates these changes in the code, which results in the BCM4311 and
>> BCM4312 working. The name of one of the PHY parameters, previously known
>> as "version", has been changed to "analog core version" .
>>
>> Signed-off-by: Larry Finger<Larry.Finger@lwfinger.net>
>> ---
> 
>> @@ -729,19 +729,19 @@ static void bcm43xx_phy_initb5(struct bc
>>  	struct bcm43xx_phyinfo *phy = bcm43xx_current_phy(bcm);
>>  	struct bcm43xx_radioinfo *radio = bcm43xx_current_radio(bcm);
>>  	u16 offset;
>> +	u16 value;
>> +	u8 old_channel;
>>  
>> -	if (phy->version == 1 &&
>> -	    radio->version == 0x2050) {
> 
> Why do you delete the check to radio version.
> It's still there in latest specs:
> http://bcm-v4.sipsolutions.net/802.11/PHY/Init/B5

As I have no real understanding of the differences between V3 and V4 firmware, I only follow the V3
specs at http://bcm-specs.sipsolutions.net. My usage of the V4 specs is to checking if they can
clean a point of confusion in the V3 spec. The radio version check is eliminated at the beginning of
the phy_initb5 routine in http://bcm-specs.sipsolutions.net/B5PHY. As there are radio version checks
later in the routine, I think it was meant to be removed here.

>> +	if (phy->analog == 1)
>>  		bcm43xx_radio_write16(bcm, 0x007A,
>>  				      bcm43xx_radio_read16(bcm, 0x007A)
>>  				      | 0x0050);
>> -	}
>>  	if ((bcm->board_vendor != PCI_VENDOR_ID_BROADCOM) &&
>>  	    (bcm->board_type != 0x0416)) {
>> +		value = 0x2120;
>>  		for (offset = 0x00A8 ; offset < 0x00C7; offset++) {
>> -			bcm43xx_phy_write(bcm, offset,
>> -					  (bcm43xx_phy_read(bcm, offset) + 0x2020)
>> -					  & 0x3F3F);
>> +			bcm43xx_phy_write(bcm, offset, value);
>> +			value += 0x0202;
>>  		}
> 
> I don't see how this matches specs.

See step 2 of http://bcm-specs.sipsolutions.net/B5PHY.

>>  	}
>>  	bcm43xx_phy_write(bcm, 0x0035,
>> @@ -776,7 +776,7 @@ static void bcm43xx_phy_initb5(struct bc
>>  				  bcm43xx_phy_read(bcm, BCM43xx_PHY_RADIO_BITFIELD) | (1 << 11));
>>  	}
>>  
>> -	if (phy->version == 1 && radio->version == 0x2050) {
> 
> Dito.

Ibid Step 7.

>> +	if (phy->analog == 1) {
>>  		bcm43xx_phy_write(bcm, 0x0026, 0xCE00);
>>  		bcm43xx_phy_write(bcm, 0x0021, 0x3763);
>>  		bcm43xx_phy_write(bcm, 0x0022, 0x1BC3);
>> @@ -787,14 +787,15 @@ static void bcm43xx_phy_initb5(struct bc
>>  	bcm43xx_phy_write(bcm, 0x0030, 0x00C6);
>>  	bcm43xx_write16(bcm, 0x03EC, 0x3F22);
>>  
>> -	if (phy->version == 1 && radio->version == 0x2050)
> 
> Dito.

Step 11.

>> +	if (phy->analog == 1)
>>  		bcm43xx_phy_write(bcm, 0x0020, 0x3E1C);
>>  	else
>>  		bcm43xx_phy_write(bcm, 0x0020, 0x301C);
>>  
>> -	if (phy->version == 0)
>> +	if (phy->analog == 0)
>>  		bcm43xx_write16(bcm, 0x03E4, 0x3000);
>>  
>> +	old_channel = radio->channel;
>>  	/* Force to channel 7, even if not supported. */
>>  	bcm43xx_radio_selectchannel(bcm, 7, 0);
>>  
>> @@ -816,11 +817,11 @@ static void bcm43xx_phy_initb5(struct bc
>>  
>>  	bcm43xx_radio_write16(bcm, 0x007A, bcm43xx_radio_read16(bcm, 0x007A) | 0x0007);
>>  
>> -	bcm43xx_radio_selectchannel(bcm, BCM43xx_RADIO_DEFAULT_CHANNEL_BG, 0);
>> +	bcm43xx_radio_selectchannel(bcm, old_channel, 0);
>>  
>>  	bcm43xx_phy_write(bcm, 0x0014, 0x0080);
>>  	bcm43xx_phy_write(bcm, 0x0032, 0x00CA);
>> -	bcm43xx_phy_write(bcm, 0x88A3, 0x002A);
>> +	bcm43xx_phy_write(bcm, 0x002A, 0x88A3);
> 
> Well, this seems correct, but specs are still different. From where did you get this?

Steps 14 - 26 of http://bcm-specs.sipsolutions.net/B5PHY
> 
> 
> Well, I don't review the rest until you say to which specs you did the changes. ;)

As I said earlier, everything came from http://bcm-specs.sipsolutions.net.

Larry

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Larry Finger]

Michael,

Michael Buesch wrote:
> On Friday 09 February 2007 17:32, Larry Finger wrote:
>> The specifications for the bcm43xx driver have been modified. This patch
>> incorporates these changes in the code, which results in the BCM4311 and
>> BCM4312 working. The name of one of the PHY parameters, previously known
>> as "version", has been changed to "analog core version" .
>>
>> Signed-off-by: Larry Finger<Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
>> ---
> 
>> @@ -729,19 +729,19 @@ static void bcm43xx_phy_initb5(struct bc
>>  	struct bcm43xx_phyinfo *phy = bcm43xx_current_phy(bcm);
>>  	struct bcm43xx_radioinfo *radio = bcm43xx_current_radio(bcm);
>>  	u16 offset;
>> +	u16 value;
>> +	u8 old_channel;
>>  
>> -	if (phy->version == 1 &&
>> -	    radio->version == 0x2050) {
> 
> Why do you delete the check to radio version.
> It's still there in latest specs:
> http://bcm-v4.sipsolutions.net/802.11/PHY/Init/B5

As I have no real understanding of the differences between V3 and V4 firmware, I only follow the V3
specs at http://bcm-specs.sipsolutions.net. My usage of the V4 specs is to checking if they can
clean a point of confusion in the V3 spec. The radio version check is eliminated at the beginning of
the phy_initb5 routine in http://bcm-specs.sipsolutions.net/B5PHY. As there are radio version checks
later in the routine, I think it was meant to be removed here.

>> +	if (phy->analog == 1)
>>  		bcm43xx_radio_write16(bcm, 0x007A,
>>  				      bcm43xx_radio_read16(bcm, 0x007A)
>>  				      | 0x0050);
>> -	}
>>  	if ((bcm->board_vendor != PCI_VENDOR_ID_BROADCOM) &&
>>  	    (bcm->board_type != 0x0416)) {
>> +		value = 0x2120;
>>  		for (offset = 0x00A8 ; offset < 0x00C7; offset++) {
>> -			bcm43xx_phy_write(bcm, offset,
>> -					  (bcm43xx_phy_read(bcm, offset) + 0x2020)
>> -					  & 0x3F3F);
>> +			bcm43xx_phy_write(bcm, offset, value);
>> +			value += 0x0202;
>>  		}
> 
> I don't see how this matches specs.

See step 2 of http://bcm-specs.sipsolutions.net/B5PHY.

>>  	}
>>  	bcm43xx_phy_write(bcm, 0x0035,
>> @@ -776,7 +776,7 @@ static void bcm43xx_phy_initb5(struct bc
>>  				  bcm43xx_phy_read(bcm, BCM43xx_PHY_RADIO_BITFIELD) | (1 << 11));
>>  	}
>>  
>> -	if (phy->version == 1 && radio->version == 0x2050) {
> 
> Dito.

Ibid Step 7.

>> +	if (phy->analog == 1) {
>>  		bcm43xx_phy_write(bcm, 0x0026, 0xCE00);
>>  		bcm43xx_phy_write(bcm, 0x0021, 0x3763);
>>  		bcm43xx_phy_write(bcm, 0x0022, 0x1BC3);
>> @@ -787,14 +787,15 @@ static void bcm43xx_phy_initb5(struct bc
>>  	bcm43xx_phy_write(bcm, 0x0030, 0x00C6);
>>  	bcm43xx_write16(bcm, 0x03EC, 0x3F22);
>>  
>> -	if (phy->version == 1 && radio->version == 0x2050)
> 
> Dito.

Step 11.

>> +	if (phy->analog == 1)
>>  		bcm43xx_phy_write(bcm, 0x0020, 0x3E1C);
>>  	else
>>  		bcm43xx_phy_write(bcm, 0x0020, 0x301C);
>>  
>> -	if (phy->version == 0)
>> +	if (phy->analog == 0)
>>  		bcm43xx_write16(bcm, 0x03E4, 0x3000);
>>  
>> +	old_channel = radio->channel;
>>  	/* Force to channel 7, even if not supported. */
>>  	bcm43xx_radio_selectchannel(bcm, 7, 0);
>>  
>> @@ -816,11 +817,11 @@ static void bcm43xx_phy_initb5(struct bc
>>  
>>  	bcm43xx_radio_write16(bcm, 0x007A, bcm43xx_radio_read16(bcm, 0x007A) | 0x0007);
>>  
>> -	bcm43xx_radio_selectchannel(bcm, BCM43xx_RADIO_DEFAULT_CHANNEL_BG, 0);
>> +	bcm43xx_radio_selectchannel(bcm, old_channel, 0);
>>  
>>  	bcm43xx_phy_write(bcm, 0x0014, 0x0080);
>>  	bcm43xx_phy_write(bcm, 0x0032, 0x00CA);
>> -	bcm43xx_phy_write(bcm, 0x88A3, 0x002A);
>> +	bcm43xx_phy_write(bcm, 0x002A, 0x88A3);
> 
> Well, this seems correct, but specs are still different. From where did you get this?

Steps 14 - 26 of http://bcm-specs.sipsolutions.net/B5PHY
> 
> 
> Well, I don't review the rest until you say to which specs you did the changes. ;)

As I said earlier, everything came from http://bcm-specs.sipsolutions.net.

Larry

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Joseph Jezak]

> Well, I don't review the rest until you say to which specs you did the changes. ;)

http://bcm-specs.sipsolutions.net/B5PHY

Larry was working from the old specs, so when I updated it, I only 
updated the old specs.  I'll fix the v4 specs soon.

-Joe

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Michael Buesch]

On Friday 09 February 2007 23:22, Joseph Jezak wrote:
> > Well, I don't review the rest until you say to which specs you did the changes. ;)
> 
> http://bcm-specs.sipsolutions.net/B5PHY
> 
> Larry was working from the old specs, so when I updated it, I only 
> updated the old specs.  I'll fix the v4 specs soon.

Ah, ok. I think we should decide on which specs carry most recent information.
I think v3 specs should be considered obsolete and new information/ fixes
should go into v4. It is already too confusing where to find newest information
to a certain thing.

-- 
Greetings Michael.

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Larry Finger]

Michael Buesch wrote:
> On Friday 09 February 2007 23:22, Joseph Jezak wrote:
>>> Well, I don't review the rest until you say to which specs you did the changes. ;)
>> http://bcm-specs.sipsolutions.net/B5PHY
>>
>> Larry was working from the old specs, so when I updated it, I only 
>> updated the old specs.  I'll fix the v4 specs soon.
> 
> Ah, ok. I think we should decide on which specs carry most recent information.
> I think v3 specs should be considered obsolete and new information/ fixes
> should go into v4. It is already too confusing where to find newest information
> to a certain thing.
> 

I'll agree to that as long as there is a clear indication of any differences between V3 and V4 firmware.

Larry

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Larry Finger]

Michael Buesch wrote:
> On Friday 09 February 2007 23:22, Joseph Jezak wrote:
>>> Well, I don't review the rest until you say to which specs you did the changes. ;)
>> http://bcm-specs.sipsolutions.net/B5PHY
>>
>> Larry was working from the old specs, so when I updated it, I only 
>> updated the old specs.  I'll fix the v4 specs soon.
> 
> Ah, ok. I think we should decide on which specs carry most recent information.
> I think v3 specs should be considered obsolete and new information/ fixes
> should go into v4. It is already too confusing where to find newest information
> to a certain thing.
> 

I'll agree to that as long as there is a clear indication of any differences between V3 and V4 firmware.

Larry

-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Michael Buesch]

On Friday 09 February 2007 19:21, Larry Finger wrote:
> Michael Buesch wrote:
> > On Friday 09 February 2007 23:22, Joseph Jezak wrote:
> >>> Well, I don't review the rest until you say to which specs you did the changes. ;)
> >> http://bcm-specs.sipsolutions.net/B5PHY
> >>
> >> Larry was working from the old specs, so when I updated it, I only 
> >> updated the old specs.  I'll fix the v4 specs soon.
> > 
> > Ah, ok. I think we should decide on which specs carry most recent information.
> > I think v3 specs should be considered obsolete and new information/ fixes
> > should go into v4. It is already too confusing where to find newest information
> > to a certain thing.
> > 
> 
> I'll agree to that as long as there is a clear indication of any differences between V3 and V4 firmware.

Well, the difference between v3 and v4 is:
* The SHM API.
* v4 may include less BPHY stuff, as broadcom's v4 drivers don't include BHY anymore.

So I'd say for everything bug BPHY the v4 specs should be considered latest.

-- 
Greetings Michael.

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Joseph Jezak]

> I'll agree to that as long as there is a clear indication of any differences between V3 and V4 firmware.

That's also part of the problem.  With the v4 driver, Broadcom 
dropped support for a number of older BPHY devices (4301/4303 and 
some 4306 revisions).  Do we still want to support those?  Should I 
continue writing the specs for the uCode revision it's based on or 
should I combine them?

-Joe

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Michael Buesch]

On Friday 09 February 2007 20:05, Joseph Jezak wrote:
> > I'll agree to that as long as there is a clear indication of any differences between V3 and V4 firmware.
> 
> That's also part of the problem.  With the v4 driver, Broadcom 
> dropped support for a number of older BPHY devices (4301/4303 and 
> some 4306 revisions).  Do we still want to support those?  Should I 
> continue writing the specs for the uCode revision it's based on or 
> should I combine them?

If it's easily possible, please try to combine the old stuff
with the new v4 specs.
I think it's basically only dropped if() branches, right?

-- 
Greetings Michael.

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Michael Buesch]

On Friday 09 February 2007 20:05, Joseph Jezak wrote:
> > I'll agree to that as long as there is a clear indication of any differences between V3 and V4 firmware.
> 
> That's also part of the problem.  With the v4 driver, Broadcom 
> dropped support for a number of older BPHY devices (4301/4303 and 
> some 4306 revisions).  Do we still want to support those?  Should I 
> continue writing the specs for the uCode revision it's based on or 
> should I combine them?

If it's easily possible, please try to combine the old stuff
with the new v4 specs.
I think it's basically only dropped if() branches, right?

-- 
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Joseph Jezak]

Michael Buesch wrote:
> On Friday 09 February 2007 20:05, Joseph Jezak wrote:
>>> I'll agree to that as long as there is a clear indication of any differences between V3 and V4 firmware.
>> That's also part of the problem.  With the v4 driver, Broadcom 
>> dropped support for a number of older BPHY devices (4301/4303 and 
>> some 4306 revisions).  Do we still want to support those?  Should I 
>> continue writing the specs for the uCode revision it's based on or 
>> should I combine them?
> 
> If it's easily possible, please try to combine the old stuff
> with the new v4 specs.
> I think it's basically only dropped if() branches, right?
> 

Well, here's the problem.  There are a few places where a value is 
changed (different value written to a register).  Does this mean 
that the value is different due to the uCode changes (can't tell, no 
documentation)?  Is it applicable to all revisions (can't tell, some 
revisions are not supported in this version)?  If the revision 
number range in a check changes is that because of a difference in 
supported cards or a bug fix?

So, it's not as simple as just dropped if() branches.  I can do my 
best to combine them (I have done some of this already), but I can't 
promise that it'll be accurate for all revisions or versions of the 
chipset.

-Joe

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Michael Buesch]

On Friday 09 February 2007 20:55, Joseph Jezak wrote:
> Michael Buesch wrote:
> > On Friday 09 February 2007 20:05, Joseph Jezak wrote:
> >>> I'll agree to that as long as there is a clear indication of any differences between V3 and V4 firmware.
> >> That's also part of the problem.  With the v4 driver, Broadcom 
> >> dropped support for a number of older BPHY devices (4301/4303 and 
> >> some 4306 revisions).  Do we still want to support those?  Should I 
> >> continue writing the specs for the uCode revision it's based on or 
> >> should I combine them?
> > 
> > If it's easily possible, please try to combine the old stuff
> > with the new v4 specs.
> > I think it's basically only dropped if() branches, right?
> > 
> 
> Well, here's the problem.  There are a few places where a value is 
> changed (different value written to a register).  Does this mean 
> that the value is different due to the uCode changes (can't tell, no 
> documentation)?  Is it applicable to all revisions (can't tell, some 
> revisions are not supported in this version)?  If the revision 
> number range in a check changes is that because of a difference in 
> supported cards or a bug fix?
> 
> So, it's not as simple as just dropped if() branches.  I can do my 
> best to combine them (I have done some of this already), but I can't 
> promise that it'll be accurate for all revisions or versions of the 
> chipset.

Ok, I see.
How many of these old devices exist and who has access to them?
If we want to combine stuff, we really must test it on these devices then.

-- 
Greetings Michael.

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1313 bytes --]

On Fri, 2007-02-09 at 14:55 -0500, Joseph Jezak wrote:

> Well, here's the problem.  There are a few places where a value is 
> changed (different value written to a register).  Does this mean 
> that the value is different due to the uCode changes (can't tell, no 
> documentation)? 

From what I've seen in the ucode that question isn't really too hard to
answer: as long as it's not in the shared memory or ucode register space
the ucode can't really have an influence.

>  Is it applicable to all revisions (can't tell, some 
> revisions are not supported in this version)?  

Best bet would be to make it conditional right now and have someone test
for these cases with older hw.

> If the revision 
> number range in a check changes is that because of a difference in 
> supported cards or a bug fix?

Hmm. Same I guess, use the new check for new hw and the old check for
old hw, i.e. assume it's the former and not a bug fix (until tested
otherwise.)

I think our best bet is to treat the older hw the same as the older
driver does.

A bigger problem, IMO, is that we'd have to support all the older
microcode things which is a bit tricky since things in shm have moved a
lot... Maybe we should find a third maintainer who has access to a
couple of old cards :)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Larry Finger]

Johannes Berg wrote:
>> supported cards or a bug fix?
> 
> Hmm. Same I guess, use the new check for new hw and the old check for
> old hw, i.e. assume it's the former and not a bug fix (until tested
> otherwise.)
> 
> I think our best bet is to treat the older hw the same as the older
> driver does.
> 
> A bigger problem, IMO, is that we'd have to support all the older
> microcode things which is a bit tricky since things in shm have moved a
> lot... Maybe we should find a third maintainer who has access to a
> couple of old cards :)

I've got a pair of BCM4306 rev 2 cards. One of them is certainly available. Its LEDS don't work
anymore, but the rest is functional.

Larry

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 254 bytes --]

On Wed, 2007-02-14 at 13:13 -0600, Larry Finger wrote:

> I've got a pair of BCM4306 rev 2 cards. One of them is certainly available. Its LEDS don't work
> anymore, but the rest is functional.

Oh good. Do they actually work right now?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 653 bytes --]

On Wed, 2007-02-14 at 20:26 +0100, Johannes Berg wrote:
> On Wed, 2007-02-14 at 13:13 -0600, Larry Finger wrote:
> 
> > I've got a pair of BCM4306 rev 2 cards. One of them is certainly available. Its LEDS don't work
> > anymore, but the rest is functional.
> 
> Oh good. Do they actually work right now?

Heh, stupid question if you say they're functional :)

Anyway, I'm not quite sure how we should keep those old code paths in
there. Maybe having a different wireless driver for the older cores
would be good, maybe split bcm43xx into three drivers, one for the
PCI/SSB stuff and then two SSB drivers for old and new cores?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Michael Buesch]

On Wednesday 14 February 2007 20:27, Johannes Berg wrote:
> On Wed, 2007-02-14 at 20:26 +0100, Johannes Berg wrote:
> > On Wed, 2007-02-14 at 13:13 -0600, Larry Finger wrote:
> > 
> > > I've got a pair of BCM4306 rev 2 cards. One of them is certainly available. Its LEDS don't work
> > > anymore, but the rest is functional.
> > 
> > Oh good. Do they actually work right now?
> 
> Heh, stupid question if you say they're functional :)
> 
> Anyway, I'm not quite sure how we should keep those old code paths in
> there. Maybe having a different wireless driver for the older cores
> would be good, maybe split bcm43xx into three drivers, one for the
> PCI/SSB stuff and then two SSB drivers for old and new cores?

It's _really_ a pain to support both v3 and v4 fw in one driver.
I tried it, but it's really really hard to do. The API to the FW
is different in so many ways.
We would have to completely abstract the SharedMemory accesses.
That would mean a lot of additional code and functions (or we could
clutter the code with if{}else{} all over, which is even worse (IMO).

So, I would say we should have a seperate driver, probably also based
on d80211 for very old cards. But I don't really want to maintain
such a beast either. (I also don't have the required old HW).

-- 
Greetings Michael.

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Larry Finger]

Johannes Berg wrote:
> On Wed, 2007-02-14 at 13:13 -0600, Larry Finger wrote:
> 
>> I've got a pair of BCM4306 rev 2 cards. One of them is certainly available. Its LEDS don't work
>> anymore, but the rest is functional.
> 
> Oh good. Do they actually work right now?
> 
> johannes

With the patches I pulled yesterday, they work to 54Mbs. Performance is not as good as the 4311 or
4318 cards, but usable.

Larry

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Larry Finger]

Joe,

Joseph Jezak wrote:

> That's also part of the problem.  With the v4 driver, Broadcom dropped
> support for a number of older BPHY devices (4301/4303 and some 4306
> revisions).  Do we still want to support those?  Should I continue
> writing the specs for the uCode revision it's based on or should I
> combine them?

As my 4306 is a rev 1 and is likely a version dropped in the V4 driver, I have a special interest in
this question.

My plan is to continue to maintain bcm43xx-SoftMAC for at least the BPHY and 4306 revisions even
after d80211 becomes the in-kernel driver. Of course, I hope that we will have found the killer bugs
by that time, and that maintenance will only require following kernel API changes.

As the work will be yours, you should decide if you would rather maintain the V3 and V4 pages
separately, or denote the special requirements of each firmware flavor in a combined set of pages.

Larry

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Larry Finger]

Joe,

Joseph Jezak wrote:

> That's also part of the problem.  With the v4 driver, Broadcom dropped
> support for a number of older BPHY devices (4301/4303 and some 4306
> revisions).  Do we still want to support those?  Should I continue
> writing the specs for the uCode revision it's based on or should I
> combine them?

As my 4306 is a rev 1 and is likely a version dropped in the V4 driver, I have a special interest in
this question.

My plan is to continue to maintain bcm43xx-SoftMAC for at least the BPHY and 4306 revisions even
after d80211 becomes the in-kernel driver. Of course, I hope that we will have found the killer bugs
by that time, and that maintenance will only require following kernel API changes.

As the work will be yours, you should decide if you would rather maintain the V3 and V4 pages
separately, or denote the special requirements of each firmware flavor in a combined set of pages.

Larry
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Matthew Garrett]

On Fri, Feb 09, 2007 at 01:26:25PM -0600, Larry Finger wrote:

> My plan is to continue to maintain bcm43xx-SoftMAC for at least the BPHY and 4306 revisions even
> after d80211 becomes the in-kernel driver. Of course, I hope that we will have found the killer bugs
> by that time, and that maintenance will only require following kernel API changes.

Just to make sure I'm understanding this correctly - does the v4 
firmware drop compatibility for older cards, or is it just that Broadcom 
dropped support in the driver at the same time as the firmware changed, 
and the new firmware will still also drive the old cards?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Martin Langer]

On Fri, Feb 09, 2007 at 09:32:39PM +0000, Matthew Garrett wrote:
> On Fri, Feb 09, 2007 at 01:26:25PM -0600, Larry Finger wrote:
> 
> > My plan is to continue to maintain bcm43xx-SoftMAC for at least the BPHY and 4306 revisions even
> > after d80211 becomes the in-kernel driver. Of course, I hope that we will have found the killer bugs
> > by that time, and that maintenance will only require following kernel API changes.
> 
> Just to make sure I'm understanding this correctly - does the v4 
> firmware drop compatibility for older cards, or is it just that Broadcom 
> dropped support in the driver at the same time as the firmware changed, 
> and the new firmware will still also drive the old cards?

We can't extract bcm43xx_microcode2.fw from v4 drivers. You need this 
file for old rev2+3 0x812 cores. So we don't know what firmware we 
should load into those old cores. I think broadcom never developed a new 
v4 style firmware for their old hardware.

Martin

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Martin Langer]

On Fri, Feb 09, 2007 at 09:32:39PM +0000, Matthew Garrett wrote:
> On Fri, Feb 09, 2007 at 01:26:25PM -0600, Larry Finger wrote:
> 
> > My plan is to continue to maintain bcm43xx-SoftMAC for at least the BPHY and 4306 revisions even
> > after d80211 becomes the in-kernel driver. Of course, I hope that we will have found the killer bugs
> > by that time, and that maintenance will only require following kernel API changes.
> 
> Just to make sure I'm understanding this correctly - does the v4 
> firmware drop compatibility for older cards, or is it just that Broadcom 
> dropped support in the driver at the same time as the firmware changed, 
> and the new firmware will still also drive the old cards?

We can't extract bcm43xx_microcode2.fw from v4 drivers. You need this 
file for old rev2+3 0x812 cores. So we don't know what firmware we 
should load into those old cores. I think broadcom never developed a new 
v4 style firmware for their old hardware.

Martin


-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Michael Buesch]

On Friday 09 February 2007 22:32, Matthew Garrett wrote:
> On Fri, Feb 09, 2007 at 01:26:25PM -0600, Larry Finger wrote:
> 
> > My plan is to continue to maintain bcm43xx-SoftMAC for at least the BPHY and 4306 revisions even
> > after d80211 becomes the in-kernel driver. Of course, I hope that we will have found the killer bugs
> > by that time, and that maintenance will only require following kernel API changes.
> 
> Just to make sure I'm understanding this correctly - does the v4 
> firmware drop compatibility for older cards, or is it just that Broadcom 
> dropped support in the driver at the same time as the firmware changed, 
> and the new firmware will still also drive the old cards?

We don't know.

It's likely that old cards still work with v4 firmware, but we don't know and
it has to be tested.

Care to do so?

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Michael Buesch]

On Friday 09 February 2007 22:32, Matthew Garrett wrote:
> On Fri, Feb 09, 2007 at 01:26:25PM -0600, Larry Finger wrote:
> 
> > My plan is to continue to maintain bcm43xx-SoftMAC for at least the BPHY and 4306 revisions even
> > after d80211 becomes the in-kernel driver. Of course, I hope that we will have found the killer bugs
> > by that time, and that maintenance will only require following kernel API changes.
> 
> Just to make sure I'm understanding this correctly - does the v4 
> firmware drop compatibility for older cards, or is it just that Broadcom 
> dropped support in the driver at the same time as the firmware changed, 
> and the new firmware will still also drive the old cards?

We don't know.

It's likely that old cards still work with v4 firmware, but we don't know and
it has to be tested.

Care to do so?
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Matthew Garrett]

On Sat, Feb 10, 2007 at 06:55:50AM +0100, Michael Buesch wrote:

> We don't know.
> 
> It's likely that old cards still work with v4 firmware, but we don't know and
> it has to be tested.
> 
> Care to do so?

I'll check the revision of my 4306, but I think it's probably too new to 
be useful, unfortunately...

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Matthew Garrett]

On Sat, Feb 10, 2007 at 06:55:50AM +0100, Michael Buesch wrote:

> We don't know.
> 
> It's likely that old cards still work with v4 firmware, but we don't know and
> it has to be tested.
> 
> Care to do so?

I'll check the revision of my 4306, but I think it's probably too new to 
be useful, unfortunately...

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Gavin McCullagh]

Hi,

On Sat, 10 Feb 2007, Matthew Garrett wrote:

> On Sat, Feb 10, 2007 at 06:55:50AM +0100, Michael Buesch wrote:
> 
> > It's likely that old cards still work with v4 firmware, but we don't know and
> > it has to be tested.
> > 
> > Care to do so?
> 
> I'll check the revision of my 4306, but I think it's probably too new to 
> be useful, unfortunately...

I have a fairly old 4306 at home which I was lent by my boss and I've been
struggling to get it working for the past week or two.  What I find is that
loads of firmwares which I try with bcm43xx-fwcutter complain about the
firmware being old but then when I get a firmware which is not too old the
device registers but doesn't seem to work -- iwlist can't see any access
points and when I set the essid it doesn't associate with the AP.

Can I be helpful as a tester?

Gavin

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Gavin McCullagh]

Hi,

On Sat, 10 Feb 2007, Matthew Garrett wrote:

> On Sat, Feb 10, 2007 at 06:55:50AM +0100, Michael Buesch wrote:
> 
> > It's likely that old cards still work with v4 firmware, but we don't know and
> > it has to be tested.
> > 
> > Care to do so?
> 
> I'll check the revision of my 4306, but I think it's probably too new to 
> be useful, unfortunately...

I have a fairly old 4306 at home which I was lent by my boss and I've been
struggling to get it working for the past week or two.  What I find is that
loads of firmwares which I try with bcm43xx-fwcutter complain about the
firmware being old but then when I get a firmware which is not too old the
device registers but doesn't seem to work -- iwlist can't see any access
points and when I set the essid it doesn't associate with the AP.

Can I be helpful as a tester?

Gavin

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Joseph Jezak]

> It's likely that old cards still work with v4 firmware, but we don't know and
> it has to be tested.
> 
> Care to do so?

I'm fairly sure the reason for dropping the old cards is that the 
on-board memory which holds the firmware isn't large enough to hold 
the newer firmware.  I can't find my documentation for that at the 
moment though.  Feel free to test and I'll confirm it later if I can 
find the info.

I'd suspect it doesn't work though since they provided a different 
firmware (ucode2) in the past.

-Joe

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 240 bytes --]

On Sat, 2007-02-10 at 06:55 +0100, Michael Buesch wrote:

> It's likely that old cards still work with v4 firmware,

No, it's absolutely impossible. Rev 2/4 cores have a totally different
instruction set in the microcode.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 240 bytes --]

On Sat, 2007-02-10 at 06:55 +0100, Michael Buesch wrote:

> It's likely that old cards still work with v4 firmware,

No, it's absolutely impossible. Rev 2/4 cores have a totally different
instruction set in the microcode.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Michael Buesch]

On Wednesday 14 February 2007 14:18, Johannes Berg wrote:
> On Sat, 2007-02-10 at 06:55 +0100, Michael Buesch wrote:
> 
> > It's likely that old cards still work with v4 firmware,
> 
> No, it's absolutely impossible. Rev 2/4 cores have a totally different
> instruction set in the microcode.

Ok, I was not talking about _that_ old cards. ;)

-- 
Greetings Michael.

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 525 bytes --]

On Wed, 2007-02-14 at 22:40 +0100, Michael Buesch wrote:
> On Wednesday 14 February 2007 14:18, Johannes Berg wrote:
> > On Sat, 2007-02-10 at 06:55 +0100, Michael Buesch wrote:
> > 
> > > It's likely that old cards still work with v4 firmware,
> > 
> > No, it's absolutely impossible. Rev 2/4 cores have a totally different
> > instruction set in the microcode.
> 
> Ok, I was not talking about _that_ old cards. ;)

Are there cards where they have new microcode instruction set but no v4
firmware?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Johannes Berg]

[-- Attachment #1.1: Type: text/plain, Size: 525 bytes --]

On Wed, 2007-02-14 at 22:40 +0100, Michael Buesch wrote:
> On Wednesday 14 February 2007 14:18, Johannes Berg wrote:
> > On Sat, 2007-02-10 at 06:55 +0100, Michael Buesch wrote:
> > 
> > > It's likely that old cards still work with v4 firmware,
> > 
> > No, it's absolutely impossible. Rev 2/4 cores have a totally different
> > instruction set in the microcode.
> 
> Ok, I was not talking about _that_ old cards. ;)

Are there cards where they have new microcode instruction set but no v4
firmware?

johannes

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

[-- Attachment #2: Type: text/plain, Size: 179 bytes --]

_______________________________________________
Bcm43xx-dev mailing list
Bcm43xx-dev-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Michael Buesch]

On Thursday 15 February 2007 16:07, Johannes Berg wrote:
> On Wed, 2007-02-14 at 22:40 +0100, Michael Buesch wrote:
> > On Wednesday 14 February 2007 14:18, Johannes Berg wrote:
> > > On Sat, 2007-02-10 at 06:55 +0100, Michael Buesch wrote:
> > > 
> > > > It's likely that old cards still work with v4 firmware,
> > > 
> > > No, it's absolutely impossible. Rev 2/4 cores have a totally different
> > > instruction set in the microcode.
> > 
> > Ok, I was not talking about _that_ old cards. ;)
> 
> Are there cards where they have new microcode instruction set but no v4
> firmware?

I don't know. I guessed so. Am I wrong? That would be good :)

-- 
Greetings Michael.

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Michael Buesch]

On Thursday 15 February 2007 16:07, Johannes Berg wrote:
> On Wed, 2007-02-14 at 22:40 +0100, Michael Buesch wrote:
> > On Wednesday 14 February 2007 14:18, Johannes Berg wrote:
> > > On Sat, 2007-02-10 at 06:55 +0100, Michael Buesch wrote:
> > > 
> > > > It's likely that old cards still work with v4 firmware,
> > > 
> > > No, it's absolutely impossible. Rev 2/4 cores have a totally different
> > > instruction set in the microcode.
> > 
> > Ok, I was not talking about _that_ old cards. ;)
> 
> Are there cards where they have new microcode instruction set but no v4
> firmware?

I don't know. I guessed so. Am I wrong? That would be good :)

-- 
Greetings Michael.

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 866 bytes --]

On Thu, 2007-02-15 at 16:13 +0100, Michael Buesch wrote:
> On Thursday 15 February 2007 16:07, Johannes Berg wrote:
> > On Wed, 2007-02-14 at 22:40 +0100, Michael Buesch wrote:
> > > On Wednesday 14 February 2007 14:18, Johannes Berg wrote:
> > > > On Sat, 2007-02-10 at 06:55 +0100, Michael Buesch wrote:
> > > > 
> > > > > It's likely that old cards still work with v4 firmware,
> > > > 
> > > > No, it's absolutely impossible. Rev 2/4 cores have a totally different
> > > > instruction set in the microcode.
> > > 
> > > Ok, I was not talking about _that_ old cards. ;)
> > 
> > Are there cards where they have new microcode instruction set but no v4
> > firmware?
> 
> I don't know. I guessed so. Am I wrong? That would be good :)

I wouldn't think so since we have rev5 v4 firmware and that should be
the oldest post-rev4 right?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Johannes Berg]

[-- Attachment #1.1: Type: text/plain, Size: 866 bytes --]

On Thu, 2007-02-15 at 16:13 +0100, Michael Buesch wrote:
> On Thursday 15 February 2007 16:07, Johannes Berg wrote:
> > On Wed, 2007-02-14 at 22:40 +0100, Michael Buesch wrote:
> > > On Wednesday 14 February 2007 14:18, Johannes Berg wrote:
> > > > On Sat, 2007-02-10 at 06:55 +0100, Michael Buesch wrote:
> > > > 
> > > > > It's likely that old cards still work with v4 firmware,
> > > > 
> > > > No, it's absolutely impossible. Rev 2/4 cores have a totally different
> > > > instruction set in the microcode.
> > > 
> > > Ok, I was not talking about _that_ old cards. ;)
> > 
> > Are there cards where they have new microcode instruction set but no v4
> > firmware?
> 
> I don't know. I guessed so. Am I wrong? That would be good :)

I wouldn't think so since we have rev5 v4 firmware and that should be
the oldest post-rev4 right?

johannes

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

[-- Attachment #2: Type: text/plain, Size: 179 bytes --]

_______________________________________________
Bcm43xx-dev mailing list
Bcm43xx-dev-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Martin Langer]

On Thu, Feb 15, 2007 at 04:19:13PM +0100, Johannes Berg wrote:
> On Thu, 2007-02-15 at 16:13 +0100, Michael Buesch wrote:
> > On Thursday 15 February 2007 16:07, Johannes Berg wrote:
> > > On Wed, 2007-02-14 at 22:40 +0100, Michael Buesch wrote:
> > > > On Wednesday 14 February 2007 14:18, Johannes Berg wrote:
> > > > > On Sat, 2007-02-10 at 06:55 +0100, Michael Buesch wrote:
> > > > > 
> > > > > > It's likely that old cards still work with v4 firmware,
> > > > > 
> > > > > No, it's absolutely impossible. Rev 2/4 cores have a totally different
> > > > > instruction set in the microcode.
> > > > 
> > > > Ok, I was not talking about _that_ old cards. ;)
> > > 
> > > Are there cards where they have new microcode instruction set but no v4
> > > firmware?
> > 
> > I don't know. I guessed so. Am I wrong? That would be good :)
> 
> I wouldn't think so since we have rev5 v4 firmware and that should be
> the oldest post-rev4 right?

Yep. We have all kinds of firmware with the new instruction set. It's 
only ucode2 (old instruction set) that's missing. But the later ucode4 
which also uses the old instruction set is available in v4.
OTOH, ucode13 isn't available in v3. We can't offer one firmware version 
for all card revisions. Both are limited to a specific range of 
revisions.

v3	rev2...rev12
v4	rev4...<=rev13


Martin

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Martin Langer]

On Thu, Feb 15, 2007 at 04:19:13PM +0100, Johannes Berg wrote:
> On Thu, 2007-02-15 at 16:13 +0100, Michael Buesch wrote:
> > On Thursday 15 February 2007 16:07, Johannes Berg wrote:
> > > On Wed, 2007-02-14 at 22:40 +0100, Michael Buesch wrote:
> > > > On Wednesday 14 February 2007 14:18, Johannes Berg wrote:
> > > > > On Sat, 2007-02-10 at 06:55 +0100, Michael Buesch wrote:
> > > > > 
> > > > > > It's likely that old cards still work with v4 firmware,
> > > > > 
> > > > > No, it's absolutely impossible. Rev 2/4 cores have a totally different
> > > > > instruction set in the microcode.
> > > > 
> > > > Ok, I was not talking about _that_ old cards. ;)
> > > 
> > > Are there cards where they have new microcode instruction set but no v4
> > > firmware?
> > 
> > I don't know. I guessed so. Am I wrong? That would be good :)
> 
> I wouldn't think so since we have rev5 v4 firmware and that should be
> the oldest post-rev4 right?

Yep. We have all kinds of firmware with the new instruction set. It's 
only ucode2 (old instruction set) that's missing. But the later ucode4 
which also uses the old instruction set is available in v4.
OTOH, ucode13 isn't available in v3. We can't offer one firmware version 
for all card revisions. Both are limited to a specific range of 
revisions.

v3	rev2...rev12
v4	rev4...<=rev13


Martin

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 669 bytes --]

On Thu, 2007-02-15 at 17:51 +0100, Martin Langer wrote:

> Yep. We have all kinds of firmware with the new instruction set. It's 
> only ucode2 (old instruction set) that's missing. But the later ucode4 
> which also uses the old instruction set is available in v4.
> OTOH, ucode13 isn't available in v3. We can't offer one firmware version 
> for all card revisions. Both are limited to a specific range of 
> revisions.
> 
> v3	rev2...rev12
> v4	rev4...<=rev13

The upper limit doesn't really matter, afaict the effect of running a
rev9 instead of rev13 will just be a missing performance increase due to
bigger FIFOs not being used fully.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]

On Fri, 2007-02-09 at 21:32 +0000, Matthew Garrett wrote:
> On Fri, Feb 09, 2007 at 01:26:25PM -0600, Larry Finger wrote:
> 
> > My plan is to continue to maintain bcm43xx-SoftMAC for at least the BPHY and 4306 revisions even
> > after d80211 becomes the in-kernel driver. Of course, I hope that we will have found the killer bugs
> > by that time, and that maintenance will only require following kernel API changes.
> 
> Just to make sure I'm understanding this correctly - does the v4 
> firmware drop compatibility for older cards, or is it just that Broadcom 
> dropped support in the driver at the same time as the firmware changed, 
> and the new firmware will still also drive the old cards?

No, the older cards have a completely different MAC processor and
Broadcom hasn't bothered to create v4 firmware for it since they dropped
support for it along with creating new drivers (probably one decision
influenced the other, creating a v2 firmware is likely more work than a
v3+)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]

On Fri, 2007-02-09 at 21:32 +0000, Matthew Garrett wrote:
> On Fri, Feb 09, 2007 at 01:26:25PM -0600, Larry Finger wrote:
> 
> > My plan is to continue to maintain bcm43xx-SoftMAC for at least the BPHY and 4306 revisions even
> > after d80211 becomes the in-kernel driver. Of course, I hope that we will have found the killer bugs
> > by that time, and that maintenance will only require following kernel API changes.
> 
> Just to make sure I'm understanding this correctly - does the v4 
> firmware drop compatibility for older cards, or is it just that Broadcom 
> dropped support in the driver at the same time as the firmware changed, 
> and the new firmware will still also drive the old cards?

No, the older cards have a completely different MAC processor and
Broadcom hasn't bothered to create v4 firmware for it since they dropped
support for it along with creating new drivers (probably one decision
influenced the other, creating a v2 firmware is likely more work than a
v3+)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Michael Buesch]

On Friday 09 February 2007 17:32, Larry Finger wrote:
> The specifications for the bcm43xx driver have been modified. This patch
> incorporates these changes in the code, which results in the BCM4311 and
> BCM4312 working. The name of one of the PHY parameters, previously known
> as "version", has been changed to "analog core version" .
> 
> Signed-off-by: Larry Finger<Larry.Finger@lwfinger.net>

>  	if ((bcm->board_vendor != PCI_VENDOR_ID_BROADCOM) &&
>  	    (bcm->board_type != 0x0416)) {
> +		value = 0x2120;
>  		for (offset = 0x00A8 ; offset < 0x00C7; offset++) {
> -			bcm43xx_phy_write(bcm, offset,
> -					  (bcm43xx_phy_read(bcm, offset) + 0x2020)
> -					  & 0x3F3F);
> +			bcm43xx_phy_write(bcm, offset, value);

The specs are unclear at this point:
"Write the value to the offset"
Offset in which register type?

> @@ -933,6 +934,8 @@ static void bcm43xx_phy_initb6(struct bc
>  		                  bcm43xx_phy_read(bcm, 0x0802) | 0x0100);
>  		bcm43xx_phy_write(bcm, 0x042B,
>  		                  bcm43xx_phy_read(bcm, 0x042B) | 0x2000);
> +		bcm43xx_phy_write(bcm, 0x5B, 0x0000);
> +		bcm43xx_phy_write(bcm, 0x5C, 0x0000);
>  	}
>  
>  	/* Force to channel 7, even if not supported. */

Backup and reset old_channel later here, too.
Also, look at this:

# If the current channel is 8 or greater
   1. Set the channel to 1 
# Otherwise
   1. Set the channel to 13

> Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
> ===================================================================
> --- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
> +++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
> @@ -1393,11 +1393,12 @@ u16 bcm43xx_radio_init2050(struct bcm43x
>  	backup[12] = bcm43xx_read16(bcm, BCM43xx_MMIO_CHANNEL_EXT);
>  
>  	// Initialization
> -	if (phy->version == 0) {
> +	if (phy->analog == 0) {
>  		bcm43xx_write16(bcm, 0x03E6, 0x0122);
>  	} else {
> -		if (phy->version >= 2)
> -			bcm43xx_write16(bcm, 0x03E6, 0x0040);
> +		if (phy->analog >= 2)
> +			bcm43xx_write16(bcm, 0x0003, (bcm43xx_read16(bcm, 0x0003)
> +					& 0xFFBF) | 0x0040);

I think here is a specs bug.

>  		bcm43xx_write16(bcm, BCM43xx_MMIO_CHANNEL_EXT,
>  		                (bcm43xx_read16(bcm, BCM43xx_MMIO_CHANNEL_EXT) | 0x2000));
>  	}

-- 
Greetings Michael.

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Michael Buesch]

On Friday 09 February 2007 17:32, Larry Finger wrote:
> The specifications for the bcm43xx driver have been modified. This patch
> incorporates these changes in the code, which results in the BCM4311 and
> BCM4312 working. The name of one of the PHY parameters, previously known
> as "version", has been changed to "analog core version" .
> 
> Signed-off-by: Larry Finger<Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>

>  	if ((bcm->board_vendor != PCI_VENDOR_ID_BROADCOM) &&
>  	    (bcm->board_type != 0x0416)) {
> +		value = 0x2120;
>  		for (offset = 0x00A8 ; offset < 0x00C7; offset++) {
> -			bcm43xx_phy_write(bcm, offset,
> -					  (bcm43xx_phy_read(bcm, offset) + 0x2020)
> -					  & 0x3F3F);
> +			bcm43xx_phy_write(bcm, offset, value);

The specs are unclear at this point:
"Write the value to the offset"
Offset in which register type?

> @@ -933,6 +934,8 @@ static void bcm43xx_phy_initb6(struct bc
>  		                  bcm43xx_phy_read(bcm, 0x0802) | 0x0100);
>  		bcm43xx_phy_write(bcm, 0x042B,
>  		                  bcm43xx_phy_read(bcm, 0x042B) | 0x2000);
> +		bcm43xx_phy_write(bcm, 0x5B, 0x0000);
> +		bcm43xx_phy_write(bcm, 0x5C, 0x0000);
>  	}
>  
>  	/* Force to channel 7, even if not supported. */

Backup and reset old_channel later here, too.
Also, look at this:

# If the current channel is 8 or greater
   1. Set the channel to 1 
# Otherwise
   1. Set the channel to 13

> Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
> ===================================================================
> --- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
> +++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
> @@ -1393,11 +1393,12 @@ u16 bcm43xx_radio_init2050(struct bcm43x
>  	backup[12] = bcm43xx_read16(bcm, BCM43xx_MMIO_CHANNEL_EXT);
>  
>  	// Initialization
> -	if (phy->version == 0) {
> +	if (phy->analog == 0) {
>  		bcm43xx_write16(bcm, 0x03E6, 0x0122);
>  	} else {
> -		if (phy->version >= 2)
> -			bcm43xx_write16(bcm, 0x03E6, 0x0040);
> +		if (phy->analog >= 2)
> +			bcm43xx_write16(bcm, 0x0003, (bcm43xx_read16(bcm, 0x0003)
> +					& 0xFFBF) | 0x0040);

I think here is a specs bug.

>  		bcm43xx_write16(bcm, BCM43xx_MMIO_CHANNEL_EXT,
>  		                (bcm43xx_read16(bcm, BCM43xx_MMIO_CHANNEL_EXT) | 0x2000));
>  	}

-- 
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Joseph Jezak]

> 
> The specs are unclear at this point:
> "Write the value to the offset"
> Offset in which register type?

PHY Register.  I've clarified it in the specs, I think this was said 
before, I made it worse when I cleaned it up.

>>  	// Initialization
>> -	if (phy->version == 0) {
>> +	if (phy->analog == 0) {
>>  		bcm43xx_write16(bcm, 0x03E6, 0x0122);
>>  	} else {
>> -		if (phy->version >= 2)
>> -			bcm43xx_write16(bcm, 0x03E6, 0x0040);
>> +		if (phy->analog >= 2)
>> +			bcm43xx_write16(bcm, 0x0003, (bcm43xx_read16(bcm, 0x0003)
>> +					& 0xFFBF) | 0x0040);
> 
> I think here is a specs bug.

This is correct.  Why do you think it's a specs bug?

-Joe

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Joseph Jezak]

> 
> The specs are unclear at this point:
> "Write the value to the offset"
> Offset in which register type?

PHY Register.  I've clarified it in the specs, I think this was said 
before, I made it worse when I cleaned it up.

>>  	// Initialization
>> -	if (phy->version == 0) {
>> +	if (phy->analog == 0) {
>>  		bcm43xx_write16(bcm, 0x03E6, 0x0122);
>>  	} else {
>> -		if (phy->version >= 2)
>> -			bcm43xx_write16(bcm, 0x03E6, 0x0040);
>> +		if (phy->analog >= 2)
>> +			bcm43xx_write16(bcm, 0x0003, (bcm43xx_read16(bcm, 0x0003)
>> +					& 0xFFBF) | 0x0040);
> 
> I think here is a specs bug.

This is correct.  Why do you think it's a specs bug?

-Joe
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Michael Buesch]

On Friday 09 February 2007 20:17, Joseph Jezak wrote:
> > 
> > The specs are unclear at this point:
> > "Write the value to the offset"
> > Offset in which register type?
> 
> PHY Register.  I've clarified it in the specs, I think this was said 
> before, I made it worse when I cleaned it up.
> 
> >>  	// Initialization
> >> -	if (phy->version == 0) {
> >> +	if (phy->analog == 0) {
> >>  		bcm43xx_write16(bcm, 0x03E6, 0x0122);
> >>  	} else {
> >> -		if (phy->version >= 2)
> >> -			bcm43xx_write16(bcm, 0x03E6, 0x0040);
> >> +		if (phy->analog >= 2)
> >> +			bcm43xx_write16(bcm, 0x0003, (bcm43xx_read16(bcm, 0x0003)
> >> +					& 0xFFBF) | 0x0040);
> > 
> > I think here is a specs bug.
> 
> This is correct.  Why do you think it's a specs bug?

Because
a) The old one made more sense to me.
b) Write MMIO register 0x3? I mean. What is that?
   Could this be PHY or radio register 0x3?

-- 
Greetings Michael.

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Michael Buesch]

On Friday 09 February 2007 20:17, Joseph Jezak wrote:
> > 
> > The specs are unclear at this point:
> > "Write the value to the offset"
> > Offset in which register type?
> 
> PHY Register.  I've clarified it in the specs, I think this was said 
> before, I made it worse when I cleaned it up.
> 
> >>  	// Initialization
> >> -	if (phy->version == 0) {
> >> +	if (phy->analog == 0) {
> >>  		bcm43xx_write16(bcm, 0x03E6, 0x0122);
> >>  	} else {
> >> -		if (phy->version >= 2)
> >> -			bcm43xx_write16(bcm, 0x03E6, 0x0040);
> >> +		if (phy->analog >= 2)
> >> +			bcm43xx_write16(bcm, 0x0003, (bcm43xx_read16(bcm, 0x0003)
> >> +					& 0xFFBF) | 0x0040);
> > 
> > I think here is a specs bug.
> 
> This is correct.  Why do you think it's a specs bug?

Because
a) The old one made more sense to me.
b) Write MMIO register 0x3? I mean. What is that?
   Could this be PHY or radio register 0x3?

-- 
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Joseph Jezak]

>> This is correct.  Why do you think it's a specs bug?
> 
> Because
> a) The old one made more sense to me.
> b) Write MMIO register 0x3? I mean. What is that?
>    Could this be PHY or radio register 0x3?
> 

Apologies.  You are correct that this should be PHY Register 0x3, 
not MMIO offset 0x3.  I've corrected this in the specs.

-Joe

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Joseph Jezak]

>> This is correct.  Why do you think it's a specs bug?
> 
> Because
> a) The old one made more sense to me.
> b) Write MMIO register 0x3? I mean. What is that?
>    Could this be PHY or radio register 0x3?
> 

Apologies.  You are correct that this should be PHY Register 0x3, 
not MMIO offset 0x3.  I've corrected this in the specs.

-Joe

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Joseph Jezak]

 >  	dprintk(KERN_INFO PFX "Detected PHY: Version: %x, Type %x, 
Revision %x\n",

You should change this too, the "Version" text should read "Analog" 
instead.

-Joe

Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[Joseph Jezak]

 >  	dprintk(KERN_INFO PFX "Detected PHY: Version: %x, Type %x, 
Revision %x\n",

You should change this too, the "Version" text should read "Analog" 
instead.

-Joe
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html