[PATCH 0/4] Make N-PHY support experimental

[PATCH 0/4] Make N-PHY support experimental

[Rafał Miłecki]

Finally, thanks for Larry and Francesco I got b43 working with BCM4328 chipset!

It's not perfectly stable yet, but scanning and associating to open network
works! It has to be tested, improved, there are some PHY errors from time to
time, but generally it works :)

Rafa?? Mi??ecki (4):
  b43: N-PHY: silence warnings
  b43: set TMS to work with current band width for N-PHY
  b43: fix split of N-PHY devices into supported and not (based on PHY
    rev)
  b43: rename config option for N-PHY, drop BROKEN

 drivers/net/wireless/b43/Kconfig      |   13 +++++++------
 drivers/net/wireless/b43/Makefile     |    8 ++++----
 drivers/net/wireless/b43/main.c       |   12 +++++++++---
 drivers/net/wireless/b43/phy_common.c |    9 ++++++++-
 drivers/net/wireless/b43/phy_common.h |    2 ++
 drivers/net/wireless/b43/phy_n.c      |   16 ++++++----------
 6 files changed, 36 insertions(+), 24 deletions(-)

[PATCH 0/4] Make N-PHY support experimental

[Rafał Miłecki]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 903 bytes --]

Finally, thanks for Larry and Francesco I got b43 working with BCM4328 chipset!

It's not perfectly stable yet, but scanning and associating to open network
works! It has to be tested, improved, there are some PHY errors from time to
time, but generally it works :)

Rafał Miłecki (4):
  b43: N-PHY: silence warnings
  b43: set TMS to work with current band width for N-PHY
  b43: fix split of N-PHY devices into supported and not (based on PHY
    rev)
  b43: rename config option for N-PHY, drop BROKEN

 drivers/net/wireless/b43/Kconfig      |   13 +++++++------
 drivers/net/wireless/b43/Makefile     |    8 ++++----
 drivers/net/wireless/b43/main.c       |   12 +++++++++---
 drivers/net/wireless/b43/phy_common.c |    9 ++++++++-
 drivers/net/wireless/b43/phy_common.h |    2 ++
 drivers/net/wireless/b43/phy_n.c      |   16 ++++++----------
 6 files changed, 36 insertions(+), 24 deletions(-)

[PATCH 1/4] b43: N-PHY: silence warnings

[Rafał Miłecki]

Signed-off-by: Rafa? Mi?ecki <zajec5@gmail.com>
---
 drivers/net/wireless/b43/phy_n.c |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/b43/phy_n.c b/drivers/net/wireless/b43/phy_n.c
index f78f4e9..d41da7f 100644
--- a/drivers/net/wireless/b43/phy_n.c
+++ b/drivers/net/wireless/b43/phy_n.c
@@ -258,7 +258,8 @@ static void b43_nphy_tx_power_fix(struct b43_wldev *dev)
 
 	for (i = 0; i < 2; i++) {
 		if (dev->phy.rev >= 3) {
-			/* TODO */
+			/* FIXME: support 5GHz */
+			txgain = b43_ntab_tx_gain_rev3plus_2ghz[txpi[i]];
 			radio_gain = (txgain >> 16) & 0x1FFFF;
 		} else {
 			txgain = b43_ntab_tx_gain_rev0_1_2[txpi[i]];
@@ -613,6 +614,8 @@ static void b43_nphy_rx_iq_coeffs(struct b43_wldev *dev, bool write,
 	}
 }
 
+#if 0
+/* Ready but not used anywhere */
 /* http://bcm-v4.sipsolutions.net/802.11/PHY/N/RxCalPhyCleanup */
 static void b43_nphy_rx_cal_phy_cleanup(struct b43_wldev *dev, u8 core)
 {
@@ -694,6 +697,7 @@ static void b43_nphy_rx_cal_phy_setup(struct b43_wldev *dev, u8 core)
 	b43_nphy_rf_control_intc_override(dev, 1, rxval, (core + 1));
 	b43_nphy_rf_control_intc_override(dev, 1, txval, (2 - core));
 }
+#endif
 
 /* http://bcm-v4.sipsolutions.net/802.11/PHY/N/CalcRxIqComp */
 static void b43_nphy_calc_rx_iq_comp(struct b43_wldev *dev, u8 mask)
@@ -3088,7 +3092,7 @@ static int b43_nphy_rev2_cal_rx_iq(struct b43_wldev *dev,
 	u8 rfctl[2];
 	u8 afectl_core;
 	u16 tmp[6];
-	u16 cur_hpf1, cur_hpf2, cur_lna;
+	u16 uninitialized_var(cur_hpf1), uninitialized_var(cur_hpf2), cur_lna;
 	u32 real, imag;
 	enum ieee80211_band band;
 
-- 
1.6.3.3

[PATCH 1/4] b43: N-PHY: silence warnings

[Rafał Miłecki]

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
---
 drivers/net/wireless/b43/phy_n.c |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/b43/phy_n.c b/drivers/net/wireless/b43/phy_n.c
index f78f4e9..d41da7f 100644
--- a/drivers/net/wireless/b43/phy_n.c
+++ b/drivers/net/wireless/b43/phy_n.c
@@ -258,7 +258,8 @@ static void b43_nphy_tx_power_fix(struct b43_wldev *dev)
 
 	for (i = 0; i < 2; i++) {
 		if (dev->phy.rev >= 3) {
-			/* TODO */
+			/* FIXME: support 5GHz */
+			txgain = b43_ntab_tx_gain_rev3plus_2ghz[txpi[i]];
 			radio_gain = (txgain >> 16) & 0x1FFFF;
 		} else {
 			txgain = b43_ntab_tx_gain_rev0_1_2[txpi[i]];
@@ -613,6 +614,8 @@ static void b43_nphy_rx_iq_coeffs(struct b43_wldev *dev, bool write,
 	}
 }
 
+#if 0
+/* Ready but not used anywhere */
 /* http://bcm-v4.sipsolutions.net/802.11/PHY/N/RxCalPhyCleanup */
 static void b43_nphy_rx_cal_phy_cleanup(struct b43_wldev *dev, u8 core)
 {
@@ -694,6 +697,7 @@ static void b43_nphy_rx_cal_phy_setup(struct b43_wldev *dev, u8 core)
 	b43_nphy_rf_control_intc_override(dev, 1, rxval, (core + 1));
 	b43_nphy_rf_control_intc_override(dev, 1, txval, (2 - core));
 }
+#endif
 
 /* http://bcm-v4.sipsolutions.net/802.11/PHY/N/CalcRxIqComp */
 static void b43_nphy_calc_rx_iq_comp(struct b43_wldev *dev, u8 mask)
@@ -3088,7 +3092,7 @@ static int b43_nphy_rev2_cal_rx_iq(struct b43_wldev *dev,
 	u8 rfctl[2];
 	u8 afectl_core;
 	u16 tmp[6];
-	u16 cur_hpf1, cur_hpf2, cur_lna;
+	u16 uninitialized_var(cur_hpf1), uninitialized_var(cur_hpf2), cur_lna;
 	u32 real, imag;
 	enum ieee80211_band band;
 
-- 
1.6.3.3

[PATCH 2/4] b43: set TMS to work with current band width for N-PHY

[Rafał Miłecki]

Signed-off-by: Rafa? Mi?ecki <zajec5@gmail.com>
---
 drivers/net/wireless/b43/main.c       |    6 ++++++
 drivers/net/wireless/b43/phy_common.c |    7 +++++++
 drivers/net/wireless/b43/phy_common.h |    2 ++
 drivers/net/wireless/b43/phy_n.c      |    7 -------
 4 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index fa48803..670fd7b 100644
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -1150,6 +1150,12 @@ void b43_wireless_core_reset(struct b43_wldev *dev, u32 flags)
 
 	flags |= B43_TMSLOW_PHYCLKEN;
 	flags |= B43_TMSLOW_PHYRESET;
+	if (dev->phy.type == B43_PHYTYPE_N) {
+		if (b43_channel_type_is_40mhz(dev->phy.channel_type))
+			flags |= B43_TMSLOW_PHYCLKSPEED_160MHZ;
+		else
+			flags |= B43_TMSLOW_PHYCLKSPEED_80MHZ;
+	}
 	ssb_device_enable(dev->dev, flags);
 	msleep(2);		/* Wait for the PLL to turn on. */
 
diff --git a/drivers/net/wireless/b43/phy_common.c b/drivers/net/wireless/b43/phy_common.c
index 0a91fc3..412f1b6 100644
--- a/drivers/net/wireless/b43/phy_common.c
+++ b/drivers/net/wireless/b43/phy_common.c
@@ -429,6 +429,13 @@ void b43_phyop_switch_analog_generic(struct b43_wldev *dev, bool on)
 	b43_write16(dev, B43_MMIO_PHY0, on ? 0 : 0xF4);
 }
 
+
+bool b43_channel_type_is_40mhz(enum nl80211_channel_type channel_type)
+{
+	return (channel_type == NL80211_CHAN_HT40MINUS ||
+		channel_type == NL80211_CHAN_HT40PLUS);
+}
+
 /* http://bcm-v4.sipsolutions.net/802.11/PHY/Cordic */
 struct b43_c32 b43_cordic(int theta)
 {
diff --git a/drivers/net/wireless/b43/phy_common.h b/drivers/net/wireless/b43/phy_common.h
index 2ed60e5..2401bee 100644
--- a/drivers/net/wireless/b43/phy_common.h
+++ b/drivers/net/wireless/b43/phy_common.h
@@ -436,6 +436,8 @@ int b43_phy_shm_tssi_read(struct b43_wldev *dev, u16 shm_offset);
  */
 void b43_phyop_switch_analog_generic(struct b43_wldev *dev, bool on);
 
+bool b43_channel_type_is_40mhz(enum nl80211_channel_type channel_type);
+
 struct b43_c32 b43_cordic(int theta);
 
 #endif /* LINUX_B43_PHY_COMMON_H_ */
diff --git a/drivers/net/wireless/b43/phy_n.c b/drivers/net/wireless/b43/phy_n.c
index d41da7f..3517341 100644
--- a/drivers/net/wireless/b43/phy_n.c
+++ b/drivers/net/wireless/b43/phy_n.c
@@ -88,13 +88,6 @@ static void b43_nphy_rf_control_override(struct b43_wldev *dev, u16 field,
 static void b43_nphy_rf_control_intc_override(struct b43_wldev *dev, u8 field,
 						u16 value, u8 core);
 
-static inline bool b43_channel_type_is_40mhz(
-					enum nl80211_channel_type channel_type)
-{
-	return (channel_type == NL80211_CHAN_HT40MINUS ||
-		channel_type == NL80211_CHAN_HT40PLUS);
-}
-
 void b43_nphy_set_rxantenna(struct b43_wldev *dev, int antenna)
 {//TODO
 }
-- 
1.6.3.3

[PATCH 2/4] b43: set TMS to work with current band width for N-PHY

[Rafał Miłecki]

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
---
 drivers/net/wireless/b43/main.c       |    6 ++++++
 drivers/net/wireless/b43/phy_common.c |    7 +++++++
 drivers/net/wireless/b43/phy_common.h |    2 ++
 drivers/net/wireless/b43/phy_n.c      |    7 -------
 4 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index fa48803..670fd7b 100644
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -1150,6 +1150,12 @@ void b43_wireless_core_reset(struct b43_wldev *dev, u32 flags)
 
 	flags |= B43_TMSLOW_PHYCLKEN;
 	flags |= B43_TMSLOW_PHYRESET;
+	if (dev->phy.type == B43_PHYTYPE_N) {
+		if (b43_channel_type_is_40mhz(dev->phy.channel_type))
+			flags |= B43_TMSLOW_PHYCLKSPEED_160MHZ;
+		else
+			flags |= B43_TMSLOW_PHYCLKSPEED_80MHZ;
+	}
 	ssb_device_enable(dev->dev, flags);
 	msleep(2);		/* Wait for the PLL to turn on. */
 
diff --git a/drivers/net/wireless/b43/phy_common.c b/drivers/net/wireless/b43/phy_common.c
index 0a91fc3..412f1b6 100644
--- a/drivers/net/wireless/b43/phy_common.c
+++ b/drivers/net/wireless/b43/phy_common.c
@@ -429,6 +429,13 @@ void b43_phyop_switch_analog_generic(struct b43_wldev *dev, bool on)
 	b43_write16(dev, B43_MMIO_PHY0, on ? 0 : 0xF4);
 }
 
+
+bool b43_channel_type_is_40mhz(enum nl80211_channel_type channel_type)
+{
+	return (channel_type == NL80211_CHAN_HT40MINUS ||
+		channel_type == NL80211_CHAN_HT40PLUS);
+}
+
 /* http://bcm-v4.sipsolutions.net/802.11/PHY/Cordic */
 struct b43_c32 b43_cordic(int theta)
 {
diff --git a/drivers/net/wireless/b43/phy_common.h b/drivers/net/wireless/b43/phy_common.h
index 2ed60e5..2401bee 100644
--- a/drivers/net/wireless/b43/phy_common.h
+++ b/drivers/net/wireless/b43/phy_common.h
@@ -436,6 +436,8 @@ int b43_phy_shm_tssi_read(struct b43_wldev *dev, u16 shm_offset);
  */
 void b43_phyop_switch_analog_generic(struct b43_wldev *dev, bool on);
 
+bool b43_channel_type_is_40mhz(enum nl80211_channel_type channel_type);
+
 struct b43_c32 b43_cordic(int theta);
 
 #endif /* LINUX_B43_PHY_COMMON_H_ */
diff --git a/drivers/net/wireless/b43/phy_n.c b/drivers/net/wireless/b43/phy_n.c
index d41da7f..3517341 100644
--- a/drivers/net/wireless/b43/phy_n.c
+++ b/drivers/net/wireless/b43/phy_n.c
@@ -88,13 +88,6 @@ static void b43_nphy_rf_control_override(struct b43_wldev *dev, u16 field,
 static void b43_nphy_rf_control_intc_override(struct b43_wldev *dev, u8 field,
 						u16 value, u8 core);
 
-static inline bool b43_channel_type_is_40mhz(
-					enum nl80211_channel_type channel_type)
-{
-	return (channel_type == NL80211_CHAN_HT40MINUS ||
-		channel_type == NL80211_CHAN_HT40PLUS);
-}
-
 void b43_nphy_set_rxantenna(struct b43_wldev *dev, int antenna)
 {//TODO
 }
-- 
1.6.3.3

[PATCH 2/4] b43: set TMS to work with current band width for N-PHY

[Michael Büsch]

On Tue, 2010-12-07 at 21:55 +0100, Rafa? Mi?ecki wrote: 
> Signed-off-by: Rafa? Mi?ecki <zajec5@gmail.com>
> ---
>  drivers/net/wireless/b43/main.c       |    6 ++++++
>  drivers/net/wireless/b43/phy_common.c |    7 +++++++
>  drivers/net/wireless/b43/phy_common.h |    2 ++
>  drivers/net/wireless/b43/phy_n.c      |    7 -------
>  4 files changed, 15 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
> index fa48803..670fd7b 100644
> --- a/drivers/net/wireless/b43/main.c
> +++ b/drivers/net/wireless/b43/main.c
> @@ -1150,6 +1150,12 @@ void b43_wireless_core_reset(struct b43_wldev *dev, u32 flags)
>  
>  	flags |= B43_TMSLOW_PHYCLKEN;
>  	flags |= B43_TMSLOW_PHYRESET;
> +	if (dev->phy.type == B43_PHYTYPE_N) {
> +		if (b43_channel_type_is_40mhz(dev->phy.channel_type))

Is channel_type already set at this time?

> +			flags |= B43_TMSLOW_PHYCLKSPEED_160MHZ;
> +		else
> +			flags |= B43_TMSLOW_PHYCLKSPEED_80MHZ;
> +	}


-- 
Greetings Michael.

Re: [PATCH 2/4] b43: set TMS to work with current band width for N-PHY

[Michael Büsch]

On Tue, 2010-12-07 at 21:55 +0100, Rafał Miłecki wrote: 
> Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
> ---
>  drivers/net/wireless/b43/main.c       |    6 ++++++
>  drivers/net/wireless/b43/phy_common.c |    7 +++++++
>  drivers/net/wireless/b43/phy_common.h |    2 ++
>  drivers/net/wireless/b43/phy_n.c      |    7 -------
>  4 files changed, 15 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
> index fa48803..670fd7b 100644
> --- a/drivers/net/wireless/b43/main.c
> +++ b/drivers/net/wireless/b43/main.c
> @@ -1150,6 +1150,12 @@ void b43_wireless_core_reset(struct b43_wldev *dev, u32 flags)
>  
>  	flags |= B43_TMSLOW_PHYCLKEN;
>  	flags |= B43_TMSLOW_PHYRESET;
> +	if (dev->phy.type == B43_PHYTYPE_N) {
> +		if (b43_channel_type_is_40mhz(dev->phy.channel_type))

Is channel_type already set at this time?

> +			flags |= B43_TMSLOW_PHYCLKSPEED_160MHZ;
> +		else
> +			flags |= B43_TMSLOW_PHYCLKSPEED_80MHZ;
> +	}


-- 
Greetings Michael.

[PATCH 2/4] b43: set TMS to work with current band width for N-PHY

[Rafał Miłecki]

W dniu 7 grudnia 2010 22:08 u?ytkownik Michael B?sch <mb@bu3sch.de> napisa?:
> On Tue, 2010-12-07 at 21:55 +0100, Rafa? Mi?ecki wrote:
>> Signed-off-by: Rafa? Mi?ecki <zajec5@gmail.com>
>> ---
>> ?drivers/net/wireless/b43/main.c ? ? ? | ? ?6 ++++++
>> ?drivers/net/wireless/b43/phy_common.c | ? ?7 +++++++
>> ?drivers/net/wireless/b43/phy_common.h | ? ?2 ++
>> ?drivers/net/wireless/b43/phy_n.c ? ? ?| ? ?7 -------
>> ?4 files changed, 15 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
>> index fa48803..670fd7b 100644
>> --- a/drivers/net/wireless/b43/main.c
>> +++ b/drivers/net/wireless/b43/main.c
>> @@ -1150,6 +1150,12 @@ void b43_wireless_core_reset(struct b43_wldev *dev, u32 flags)
>>
>> ? ? ? flags |= B43_TMSLOW_PHYCLKEN;
>> ? ? ? flags |= B43_TMSLOW_PHYRESET;
>> + ? ? if (dev->phy.type == B43_PHYTYPE_N) {
>> + ? ? ? ? ? ? if (b43_channel_type_is_40mhz(dev->phy.channel_type))
>
> Is channel_type already set at this time?

Yeah, that core switching seems to be a little tricky. I didn't figure
it out completely yet. We may need to fix that, or fix calls to this
function.

Thanks for reviewing!

-- 
Rafa?

Re: [PATCH 2/4] b43: set TMS to work with current band width for N-PHY

[Rafał Miłecki]

W dniu 7 grudnia 2010 22:08 użytkownik Michael Büsch <mb@bu3sch.de> napisał:
> On Tue, 2010-12-07 at 21:55 +0100, Rafał Miłecki wrote:
>> Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
>> ---
>>  drivers/net/wireless/b43/main.c       |    6 ++++++
>>  drivers/net/wireless/b43/phy_common.c |    7 +++++++
>>  drivers/net/wireless/b43/phy_common.h |    2 ++
>>  drivers/net/wireless/b43/phy_n.c      |    7 -------
>>  4 files changed, 15 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
>> index fa48803..670fd7b 100644
>> --- a/drivers/net/wireless/b43/main.c
>> +++ b/drivers/net/wireless/b43/main.c
>> @@ -1150,6 +1150,12 @@ void b43_wireless_core_reset(struct b43_wldev *dev, u32 flags)
>>
>>       flags |= B43_TMSLOW_PHYCLKEN;
>>       flags |= B43_TMSLOW_PHYRESET;
>> +     if (dev->phy.type == B43_PHYTYPE_N) {
>> +             if (b43_channel_type_is_40mhz(dev->phy.channel_type))
>
> Is channel_type already set at this time?

Yeah, that core switching seems to be a little tricky. I didn't figure
it out completely yet. We may need to fix that, or fix calls to this
function.

Thanks for reviewing!

-- 
Rafał

[PATCH 2/4] b43: set TMS to work with current band width for N-PHY

[Rafał Miłecki]

W dniu 9 grudnia 2010 15:12 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
> W dniu 7 grudnia 2010 22:08 u?ytkownik Michael B?sch <mb@bu3sch.de> napisa?:
>> On Tue, 2010-12-07 at 21:55 +0100, Rafa? Mi?ecki wrote:
>>> Signed-off-by: Rafa? Mi?ecki <zajec5@gmail.com>
>>> ---
>>> ?drivers/net/wireless/b43/main.c ? ? ? | ? ?6 ++++++
>>> ?drivers/net/wireless/b43/phy_common.c | ? ?7 +++++++
>>> ?drivers/net/wireless/b43/phy_common.h | ? ?2 ++
>>> ?drivers/net/wireless/b43/phy_n.c ? ? ?| ? ?7 -------
>>> ?4 files changed, 15 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
>>> index fa48803..670fd7b 100644
>>> --- a/drivers/net/wireless/b43/main.c
>>> +++ b/drivers/net/wireless/b43/main.c
>>> @@ -1150,6 +1150,12 @@ void b43_wireless_core_reset(struct b43_wldev *dev, u32 flags)
>>>
>>> ? ? ? flags |= B43_TMSLOW_PHYCLKEN;
>>> ? ? ? flags |= B43_TMSLOW_PHYRESET;
>>> + ? ? if (dev->phy.type == B43_PHYTYPE_N) {
>>> + ? ? ? ? ? ? if (b43_channel_type_is_40mhz(dev->phy.channel_type))
>>
>> Is channel_type already set at this time?
>
> Yeah, that core switching seems to be a little tricky. I didn't figure
> it out completely yet. We may need to fix that, or fix calls to this
> function.
>
> Thanks for reviewing!

In other words: it will work for now, but we need to fix that in
future if we want to get 40 MHz channels working.

-- 
Rafa?

Re: [PATCH 2/4] b43: set TMS to work with current band width for N-PHY

[Rafał Miłecki]

W dniu 9 grudnia 2010 15:12 użytkownik Rafał Miłecki <zajec5@gmail.com> napisał:
> W dniu 7 grudnia 2010 22:08 użytkownik Michael Büsch <mb@bu3sch.de> napisał:
>> On Tue, 2010-12-07 at 21:55 +0100, Rafał Miłecki wrote:
>>> Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
>>> ---
>>>  drivers/net/wireless/b43/main.c       |    6 ++++++
>>>  drivers/net/wireless/b43/phy_common.c |    7 +++++++
>>>  drivers/net/wireless/b43/phy_common.h |    2 ++
>>>  drivers/net/wireless/b43/phy_n.c      |    7 -------
>>>  4 files changed, 15 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
>>> index fa48803..670fd7b 100644
>>> --- a/drivers/net/wireless/b43/main.c
>>> +++ b/drivers/net/wireless/b43/main.c
>>> @@ -1150,6 +1150,12 @@ void b43_wireless_core_reset(struct b43_wldev *dev, u32 flags)
>>>
>>>       flags |= B43_TMSLOW_PHYCLKEN;
>>>       flags |= B43_TMSLOW_PHYRESET;
>>> +     if (dev->phy.type == B43_PHYTYPE_N) {
>>> +             if (b43_channel_type_is_40mhz(dev->phy.channel_type))
>>
>> Is channel_type already set at this time?
>
> Yeah, that core switching seems to be a little tricky. I didn't figure
> it out completely yet. We may need to fix that, or fix calls to this
> function.
>
> Thanks for reviewing!

In other words: it will work for now, but we need to fix that in
future if we want to get 40 MHz channels working.

-- 
Rafał

[PATCH 2/4] b43: set TMS to work with current band width for N-PHY

[Michael Büsch]

On Thu, 2010-12-09 at 15:13 +0100, Rafa? Mi?ecki wrote: 
> W dniu 9 grudnia 2010 15:12 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
> > W dniu 7 grudnia 2010 22:08 u?ytkownik Michael B?sch <mb@bu3sch.de> napisa?:
> >> On Tue, 2010-12-07 at 21:55 +0100, Rafa? Mi?ecki wrote:
> >>> Signed-off-by: Rafa? Mi?ecki <zajec5@gmail.com>
> >>> ---
> >>>  drivers/net/wireless/b43/main.c       |    6 ++++++
> >>>  drivers/net/wireless/b43/phy_common.c |    7 +++++++
> >>>  drivers/net/wireless/b43/phy_common.h |    2 ++
> >>>  drivers/net/wireless/b43/phy_n.c      |    7 -------
> >>>  4 files changed, 15 insertions(+), 7 deletions(-)
> >>>
> >>> diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
> >>> index fa48803..670fd7b 100644
> >>> --- a/drivers/net/wireless/b43/main.c
> >>> +++ b/drivers/net/wireless/b43/main.c
> >>> @@ -1150,6 +1150,12 @@ void b43_wireless_core_reset(struct b43_wldev *dev, u32 flags)
> >>>
> >>>       flags |= B43_TMSLOW_PHYCLKEN;
> >>>       flags |= B43_TMSLOW_PHYRESET;
> >>> +     if (dev->phy.type == B43_PHYTYPE_N) {
> >>> +             if (b43_channel_type_is_40mhz(dev->phy.channel_type))
> >>
> >> Is channel_type already set at this time?
> >
> > Yeah, that core switching seems to be a little tricky. I didn't figure
> > it out completely yet. We may need to fix that, or fix calls to this
> > function.
> >
> > Thanks for reviewing!
> 
> In other words: it will work for now, but we need to fix that in
> future if we want to get 40 MHz channels working.

That's exactly what I was saying. ;)
To answer my original question: No, channel_type is not set, but the
code will work for non-40mhz.

This seems a bit tricky to fix, though. Maybe we should reset the
wireless core twice. Once initially and once again after the
configuration was set. The first reset would just be to be able
to access the PHY and wireless core at all to probe it.

-- 
Greetings Michael.

Re: [PATCH 2/4] b43: set TMS to work with current band width for N-PHY

[Michael Büsch]

On Thu, 2010-12-09 at 15:13 +0100, Rafał Miłecki wrote: 
> W dniu 9 grudnia 2010 15:12 użytkownik Rafał Miłecki <zajec5@gmail.com> napisał:
> > W dniu 7 grudnia 2010 22:08 użytkownik Michael Büsch <mb@bu3sch.de> napisał:
> >> On Tue, 2010-12-07 at 21:55 +0100, Rafał Miłecki wrote:
> >>> Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
> >>> ---
> >>>  drivers/net/wireless/b43/main.c       |    6 ++++++
> >>>  drivers/net/wireless/b43/phy_common.c |    7 +++++++
> >>>  drivers/net/wireless/b43/phy_common.h |    2 ++
> >>>  drivers/net/wireless/b43/phy_n.c      |    7 -------
> >>>  4 files changed, 15 insertions(+), 7 deletions(-)
> >>>
> >>> diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
> >>> index fa48803..670fd7b 100644
> >>> --- a/drivers/net/wireless/b43/main.c
> >>> +++ b/drivers/net/wireless/b43/main.c
> >>> @@ -1150,6 +1150,12 @@ void b43_wireless_core_reset(struct b43_wldev *dev, u32 flags)
> >>>
> >>>       flags |= B43_TMSLOW_PHYCLKEN;
> >>>       flags |= B43_TMSLOW_PHYRESET;
> >>> +     if (dev->phy.type == B43_PHYTYPE_N) {
> >>> +             if (b43_channel_type_is_40mhz(dev->phy.channel_type))
> >>
> >> Is channel_type already set at this time?
> >
> > Yeah, that core switching seems to be a little tricky. I didn't figure
> > it out completely yet. We may need to fix that, or fix calls to this
> > function.
> >
> > Thanks for reviewing!
> 
> In other words: it will work for now, but we need to fix that in
> future if we want to get 40 MHz channels working.

That's exactly what I was saying. ;)
To answer my original question: No, channel_type is not set, but the
code will work for non-40mhz.

This seems a bit tricky to fix, though. Maybe we should reset the
wireless core twice. Once initially and once again after the
configuration was set. The first reset would just be to be able
to access the PHY and wireless core at all to probe it.

-- 
Greetings Michael.

[PATCH 2/4] b43: set TMS to work with current band width for N-PHY

[Rafał Miłecki]

W dniu 9 grudnia 2010 15:19 u?ytkownik Michael B?sch <mb@bu3sch.de> napisa?:
> On Thu, 2010-12-09 at 15:13 +0100, Rafa? Mi?ecki wrote:
>> W dniu 9 grudnia 2010 15:12 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
>> > W dniu 7 grudnia 2010 22:08 u?ytkownik Michael B?sch <mb@bu3sch.de> napisa?:
>> >> On Tue, 2010-12-07 at 21:55 +0100, Rafa? Mi?ecki wrote:
>> >>> Signed-off-by: Rafa? Mi?ecki <zajec5@gmail.com>
>> >>> ---
>> >>> ?drivers/net/wireless/b43/main.c ? ? ? | ? ?6 ++++++
>> >>> ?drivers/net/wireless/b43/phy_common.c | ? ?7 +++++++
>> >>> ?drivers/net/wireless/b43/phy_common.h | ? ?2 ++
>> >>> ?drivers/net/wireless/b43/phy_n.c ? ? ?| ? ?7 -------
>> >>> ?4 files changed, 15 insertions(+), 7 deletions(-)
>> >>>
>> >>> diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
>> >>> index fa48803..670fd7b 100644
>> >>> --- a/drivers/net/wireless/b43/main.c
>> >>> +++ b/drivers/net/wireless/b43/main.c
>> >>> @@ -1150,6 +1150,12 @@ void b43_wireless_core_reset(struct b43_wldev *dev, u32 flags)
>> >>>
>> >>> ? ? ? flags |= B43_TMSLOW_PHYCLKEN;
>> >>> ? ? ? flags |= B43_TMSLOW_PHYRESET;
>> >>> + ? ? if (dev->phy.type == B43_PHYTYPE_N) {
>> >>> + ? ? ? ? ? ? if (b43_channel_type_is_40mhz(dev->phy.channel_type))
>> >>
>> >> Is channel_type already set at this time?
>> >
>> > Yeah, that core switching seems to be a little tricky. I didn't figure
>> > it out completely yet. We may need to fix that, or fix calls to this
>> > function.
>> >
>> > Thanks for reviewing!
>>
>> In other words: it will work for now, but we need to fix that in
>> future if we want to get 40 MHz channels working.
>
> That's exactly what I was saying. ;)
> To answer my original question: No, channel_type is not set, but the
> code will work for non-40mhz.
>
> This seems a bit tricky to fix, though. Maybe we should reset the
> wireless core twice. Once initially and once again after the
> configuration was set. The first reset would just be to be able
> to access the PHY and wireless core at all to probe it.

Even more tricky is that we already reset code twice... At least in
b43_wireless_core_attach. Will have to redesign that a little.

-- 
Rafa?

Re: [PATCH 2/4] b43: set TMS to work with current band width for N-PHY

[Rafał Miłecki]

W dniu 9 grudnia 2010 15:19 użytkownik Michael Büsch <mb@bu3sch.de> napisał:
> On Thu, 2010-12-09 at 15:13 +0100, Rafał Miłecki wrote:
>> W dniu 9 grudnia 2010 15:12 użytkownik Rafał Miłecki <zajec5@gmail.com> napisał:
>> > W dniu 7 grudnia 2010 22:08 użytkownik Michael Büsch <mb@bu3sch.de> napisał:
>> >> On Tue, 2010-12-07 at 21:55 +0100, Rafał Miłecki wrote:
>> >>> Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
>> >>> ---
>> >>>  drivers/net/wireless/b43/main.c       |    6 ++++++
>> >>>  drivers/net/wireless/b43/phy_common.c |    7 +++++++
>> >>>  drivers/net/wireless/b43/phy_common.h |    2 ++
>> >>>  drivers/net/wireless/b43/phy_n.c      |    7 -------
>> >>>  4 files changed, 15 insertions(+), 7 deletions(-)
>> >>>
>> >>> diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
>> >>> index fa48803..670fd7b 100644
>> >>> --- a/drivers/net/wireless/b43/main.c
>> >>> +++ b/drivers/net/wireless/b43/main.c
>> >>> @@ -1150,6 +1150,12 @@ void b43_wireless_core_reset(struct b43_wldev *dev, u32 flags)
>> >>>
>> >>>       flags |= B43_TMSLOW_PHYCLKEN;
>> >>>       flags |= B43_TMSLOW_PHYRESET;
>> >>> +     if (dev->phy.type == B43_PHYTYPE_N) {
>> >>> +             if (b43_channel_type_is_40mhz(dev->phy.channel_type))
>> >>
>> >> Is channel_type already set at this time?
>> >
>> > Yeah, that core switching seems to be a little tricky. I didn't figure
>> > it out completely yet. We may need to fix that, or fix calls to this
>> > function.
>> >
>> > Thanks for reviewing!
>>
>> In other words: it will work for now, but we need to fix that in
>> future if we want to get 40 MHz channels working.
>
> That's exactly what I was saying. ;)
> To answer my original question: No, channel_type is not set, but the
> code will work for non-40mhz.
>
> This seems a bit tricky to fix, though. Maybe we should reset the
> wireless core twice. Once initially and once again after the
> configuration was set. The first reset would just be to be able
> to access the PHY and wireless core at all to probe it.

Even more tricky is that we already reset code twice... At least in
b43_wireless_core_attach. Will have to redesign that a little.

-- 
Rafał

[PATCH 2/4] b43: set TMS to work with current band width for N-PHY

[Michael Büsch]

On Thu, 2010-12-09 at 15:23 +0100, Rafa? Mi?ecki wrote: 
> W dniu 9 grudnia 2010 15:19 u?ytkownik Michael B?sch <mb@bu3sch.de> napisa?:
> > On Thu, 2010-12-09 at 15:13 +0100, Rafa? Mi?ecki wrote:
> >> W dniu 9 grudnia 2010 15:12 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
> >> > W dniu 7 grudnia 2010 22:08 u?ytkownik Michael B?sch <mb@bu3sch.de> napisa?:
> >> >> On Tue, 2010-12-07 at 21:55 +0100, Rafa? Mi?ecki wrote:
> >> >>> Signed-off-by: Rafa? Mi?ecki <zajec5@gmail.com>
> >> >>> ---
> >> >>>  drivers/net/wireless/b43/main.c       |    6 ++++++
> >> >>>  drivers/net/wireless/b43/phy_common.c |    7 +++++++
> >> >>>  drivers/net/wireless/b43/phy_common.h |    2 ++
> >> >>>  drivers/net/wireless/b43/phy_n.c      |    7 -------
> >> >>>  4 files changed, 15 insertions(+), 7 deletions(-)
> >> >>>
> >> >>> diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
> >> >>> index fa48803..670fd7b 100644
> >> >>> --- a/drivers/net/wireless/b43/main.c
> >> >>> +++ b/drivers/net/wireless/b43/main.c
> >> >>> @@ -1150,6 +1150,12 @@ void b43_wireless_core_reset(struct b43_wldev *dev, u32 flags)
> >> >>>
> >> >>>       flags |= B43_TMSLOW_PHYCLKEN;
> >> >>>       flags |= B43_TMSLOW_PHYRESET;
> >> >>> +     if (dev->phy.type == B43_PHYTYPE_N) {
> >> >>> +             if (b43_channel_type_is_40mhz(dev->phy.channel_type))
> >> >>
> >> >> Is channel_type already set at this time?
> >> >
> >> > Yeah, that core switching seems to be a little tricky. I didn't figure
> >> > it out completely yet. We may need to fix that, or fix calls to this
> >> > function.
> >> >
> >> > Thanks for reviewing!
> >>
> >> In other words: it will work for now, but we need to fix that in
> >> future if we want to get 40 MHz channels working.
> >
> > That's exactly what I was saying. ;)
> > To answer my original question: No, channel_type is not set, but the
> > code will work for non-40mhz.
> >
> > This seems a bit tricky to fix, though. Maybe we should reset the
> > wireless core twice. Once initially and once again after the
> > configuration was set. The first reset would just be to be able
> > to access the PHY and wireless core at all to probe it.
> 
> Even more tricky is that we already reset code twice... At least in
> b43_wireless_core_attach. Will have to redesign that a little.

I don't think so.
We will have to live with at least two resets.
The first is to make the device accessible, so that we can fetch
the device type and revision numbers (phy type, rev, radio type,....)
After that is done, the device is shut down completely and reinitialized
when the interface comes up with the correct parameters.
It is important that no device setup is done whatsoever at attach stage.
Doing so would also break suspend/resume.

I do not think a redesign of the init code is required.

-- 
Greetings Michael.

Re: [PATCH 2/4] b43: set TMS to work with current band width for N-PHY

[Michael Büsch]

On Thu, 2010-12-09 at 15:23 +0100, Rafał Miłecki wrote: 
> W dniu 9 grudnia 2010 15:19 użytkownik Michael Büsch <mb@bu3sch.de> napisał:
> > On Thu, 2010-12-09 at 15:13 +0100, Rafał Miłecki wrote:
> >> W dniu 9 grudnia 2010 15:12 użytkownik Rafał Miłecki <zajec5@gmail.com> napisał:
> >> > W dniu 7 grudnia 2010 22:08 użytkownik Michael Büsch <mb@bu3sch.de> napisał:
> >> >> On Tue, 2010-12-07 at 21:55 +0100, Rafał Miłecki wrote:
> >> >>> Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
> >> >>> ---
> >> >>>  drivers/net/wireless/b43/main.c       |    6 ++++++
> >> >>>  drivers/net/wireless/b43/phy_common.c |    7 +++++++
> >> >>>  drivers/net/wireless/b43/phy_common.h |    2 ++
> >> >>>  drivers/net/wireless/b43/phy_n.c      |    7 -------
> >> >>>  4 files changed, 15 insertions(+), 7 deletions(-)
> >> >>>
> >> >>> diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
> >> >>> index fa48803..670fd7b 100644
> >> >>> --- a/drivers/net/wireless/b43/main.c
> >> >>> +++ b/drivers/net/wireless/b43/main.c
> >> >>> @@ -1150,6 +1150,12 @@ void b43_wireless_core_reset(struct b43_wldev *dev, u32 flags)
> >> >>>
> >> >>>       flags |= B43_TMSLOW_PHYCLKEN;
> >> >>>       flags |= B43_TMSLOW_PHYRESET;
> >> >>> +     if (dev->phy.type == B43_PHYTYPE_N) {
> >> >>> +             if (b43_channel_type_is_40mhz(dev->phy.channel_type))
> >> >>
> >> >> Is channel_type already set at this time?
> >> >
> >> > Yeah, that core switching seems to be a little tricky. I didn't figure
> >> > it out completely yet. We may need to fix that, or fix calls to this
> >> > function.
> >> >
> >> > Thanks for reviewing!
> >>
> >> In other words: it will work for now, but we need to fix that in
> >> future if we want to get 40 MHz channels working.
> >
> > That's exactly what I was saying. ;)
> > To answer my original question: No, channel_type is not set, but the
> > code will work for non-40mhz.
> >
> > This seems a bit tricky to fix, though. Maybe we should reset the
> > wireless core twice. Once initially and once again after the
> > configuration was set. The first reset would just be to be able
> > to access the PHY and wireless core at all to probe it.
> 
> Even more tricky is that we already reset code twice... At least in
> b43_wireless_core_attach. Will have to redesign that a little.

I don't think so.
We will have to live with at least two resets.
The first is to make the device accessible, so that we can fetch
the device type and revision numbers (phy type, rev, radio type,....)
After that is done, the device is shut down completely and reinitialized
when the interface comes up with the correct parameters.
It is important that no device setup is done whatsoever at attach stage.
Doing so would also break suspend/resume.

I do not think a redesign of the init code is required.

-- 
Greetings Michael.

[PATCH 2/4] b43: set TMS to work with current band width for N-PHY

[Michael Büsch]

On Thu, 2010-12-09 at 15:23 +0100, Rafa? Mi?ecki wrote: 
> W dniu 9 grudnia 2010 15:19 u?ytkownik Michael B?sch <mb@bu3sch.de> napisa?:
> > On Thu, 2010-12-09 at 15:13 +0100, Rafa? Mi?ecki wrote:
> >> W dniu 9 grudnia 2010 15:12 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
> >> > W dniu 7 grudnia 2010 22:08 u?ytkownik Michael B?sch <mb@bu3sch.de> napisa?:
> >> >> On Tue, 2010-12-07 at 21:55 +0100, Rafa? Mi?ecki wrote:
> >> >>> Signed-off-by: Rafa? Mi?ecki <zajec5@gmail.com>
> >> >>> ---
> >> >>>  drivers/net/wireless/b43/main.c       |    6 ++++++
> >> >>>  drivers/net/wireless/b43/phy_common.c |    7 +++++++
> >> >>>  drivers/net/wireless/b43/phy_common.h |    2 ++
> >> >>>  drivers/net/wireless/b43/phy_n.c      |    7 -------
> >> >>>  4 files changed, 15 insertions(+), 7 deletions(-)
> >> >>>
> >> >>> diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
> >> >>> index fa48803..670fd7b 100644
> >> >>> --- a/drivers/net/wireless/b43/main.c
> >> >>> +++ b/drivers/net/wireless/b43/main.c
> >> >>> @@ -1150,6 +1150,12 @@ void b43_wireless_core_reset(struct b43_wldev *dev, u32 flags)
> >> >>>
> >> >>>       flags |= B43_TMSLOW_PHYCLKEN;
> >> >>>       flags |= B43_TMSLOW_PHYRESET;
> >> >>> +     if (dev->phy.type == B43_PHYTYPE_N) {
> >> >>> +             if (b43_channel_type_is_40mhz(dev->phy.channel_type))
> >> >>
> >> >> Is channel_type already set at this time?

The more I think about this, the wronger it looks to me.
Why do we care about the channel type at reset time anyway?
I guess the channel type is a parameter that can change any time on an
operating card. So just unconditionally set B43_TMSLOW_PHYCLKSPEED_80MHZ
at reset time and set the correct TMSLOW bits later when channel_type is
actually changed. That seems to be the only sane thing to do.
I guess we don't want to fully reset the device when channel_type
changes, do we?

-- 
Greetings Michael.

Re: [PATCH 2/4] b43: set TMS to work with current band width for N-PHY

[Michael Büsch]

On Thu, 2010-12-09 at 15:23 +0100, Rafał Miłecki wrote: 
> W dniu 9 grudnia 2010 15:19 użytkownik Michael Büsch <mb@bu3sch.de> napisał:
> > On Thu, 2010-12-09 at 15:13 +0100, Rafał Miłecki wrote:
> >> W dniu 9 grudnia 2010 15:12 użytkownik Rafał Miłecki <zajec5@gmail.com> napisał:
> >> > W dniu 7 grudnia 2010 22:08 użytkownik Michael Büsch <mb@bu3sch.de> napisał:
> >> >> On Tue, 2010-12-07 at 21:55 +0100, Rafał Miłecki wrote:
> >> >>> Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
> >> >>> ---
> >> >>>  drivers/net/wireless/b43/main.c       |    6 ++++++
> >> >>>  drivers/net/wireless/b43/phy_common.c |    7 +++++++
> >> >>>  drivers/net/wireless/b43/phy_common.h |    2 ++
> >> >>>  drivers/net/wireless/b43/phy_n.c      |    7 -------
> >> >>>  4 files changed, 15 insertions(+), 7 deletions(-)
> >> >>>
> >> >>> diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
> >> >>> index fa48803..670fd7b 100644
> >> >>> --- a/drivers/net/wireless/b43/main.c
> >> >>> +++ b/drivers/net/wireless/b43/main.c
> >> >>> @@ -1150,6 +1150,12 @@ void b43_wireless_core_reset(struct b43_wldev *dev, u32 flags)
> >> >>>
> >> >>>       flags |= B43_TMSLOW_PHYCLKEN;
> >> >>>       flags |= B43_TMSLOW_PHYRESET;
> >> >>> +     if (dev->phy.type == B43_PHYTYPE_N) {
> >> >>> +             if (b43_channel_type_is_40mhz(dev->phy.channel_type))
> >> >>
> >> >> Is channel_type already set at this time?

The more I think about this, the wronger it looks to me.
Why do we care about the channel type at reset time anyway?
I guess the channel type is a parameter that can change any time on an
operating card. So just unconditionally set B43_TMSLOW_PHYCLKSPEED_80MHZ
at reset time and set the correct TMSLOW bits later when channel_type is
actually changed. That seems to be the only sane thing to do.
I guess we don't want to fully reset the device when channel_type
changes, do we?

-- 
Greetings Michael.

[PATCH 3/4] b43: fix split of N-PHY devices into supported and not (based on PHY rev)

[Rafał Miłecki]

Signed-off-by: Rafa? Mi?ecki <zajec5@gmail.com>
---
 drivers/net/wireless/b43/main.c  |    2 +-
 drivers/net/wireless/b43/phy_n.c |    1 -
 2 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index 670fd7b..4d97aac 100644
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -4054,7 +4054,7 @@ static int b43_phy_versioning(struct b43_wldev *dev)
 		break;
 #ifdef CONFIG_B43_NPHY
 	case B43_PHYTYPE_N:
-		if (phy_rev > 4)
+		if (phy_rev > 2)
 			unsupported = 1;
 		break;
 #endif
diff --git a/drivers/net/wireless/b43/phy_n.c b/drivers/net/wireless/b43/phy_n.c
index 3517341..61875c8 100644
--- a/drivers/net/wireless/b43/phy_n.c
+++ b/drivers/net/wireless/b43/phy_n.c
@@ -3515,7 +3515,6 @@ int b43_phy_initn(struct b43_wldev *dev)
 	if (phy->rev >= 3)
 		b43_nphy_spur_workaround(dev);
 
-	b43err(dev->wl, "IEEE 802.11n devices are not supported, yet.\n");
 	return 0;
 }
 
-- 
1.6.3.3

[PATCH 3/4] b43: fix split of N-PHY devices into supported and not (based on PHY rev)

[Rafał Miłecki]

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
---
 drivers/net/wireless/b43/main.c  |    2 +-
 drivers/net/wireless/b43/phy_n.c |    1 -
 2 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index 670fd7b..4d97aac 100644
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -4054,7 +4054,7 @@ static int b43_phy_versioning(struct b43_wldev *dev)
 		break;
 #ifdef CONFIG_B43_NPHY
 	case B43_PHYTYPE_N:
-		if (phy_rev > 4)
+		if (phy_rev > 2)
 			unsupported = 1;
 		break;
 #endif
diff --git a/drivers/net/wireless/b43/phy_n.c b/drivers/net/wireless/b43/phy_n.c
index 3517341..61875c8 100644
--- a/drivers/net/wireless/b43/phy_n.c
+++ b/drivers/net/wireless/b43/phy_n.c
@@ -3515,7 +3515,6 @@ int b43_phy_initn(struct b43_wldev *dev)
 	if (phy->rev >= 3)
 		b43_nphy_spur_workaround(dev);
 
-	b43err(dev->wl, "IEEE 802.11n devices are not supported, yet.\n");
 	return 0;
 }
 
-- 
1.6.3.3

[PATCH 4/4] b43: rename config option for N-PHY, drop BROKEN

[Rafał Miłecki]

Signed-off-by: Rafa? Mi?ecki <zajec5@gmail.com>
---
 drivers/net/wireless/b43/Kconfig      |   13 +++++++------
 drivers/net/wireless/b43/Makefile     |    8 ++++----
 drivers/net/wireless/b43/main.c       |    4 ++--
 drivers/net/wireless/b43/phy_common.c |    2 +-
 4 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/drivers/net/wireless/b43/Kconfig b/drivers/net/wireless/b43/Kconfig
index 0a00d42..47033f6 100644
--- a/drivers/net/wireless/b43/Kconfig
+++ b/drivers/net/wireless/b43/Kconfig
@@ -86,15 +86,16 @@ config B43_PIO
 	select SSB_BLOCKIO
 	default y
 
-config B43_NPHY
-	bool "Pre IEEE 802.11n support (BROKEN)"
-	depends on B43 && EXPERIMENTAL && BROKEN
+config B43_PHY_N
+	bool "Support for 802.11n (N-PHY) devices (EXPERIMENTAL)"
+	depends on B43 && EXPERIMENTAL
 	---help---
-	  Support for the IEEE 802.11n draft.
+	  Support for the N-PHY.
 
-	  THIS IS BROKEN AND DOES NOT WORK YET.
+	  This enables support for devices with N-PHY revision up to 2.
 
-	  SAY N.
+	  Say N if you expect high stability and performance. Saying Y will not
+	  affect other devices support and may provide support for basic needs.
 
 config B43_PHY_LP
 	bool "Support for low-power (LP-PHY) devices (EXPERIMENTAL)"
diff --git a/drivers/net/wireless/b43/Makefile b/drivers/net/wireless/b43/Makefile
index 69d4af0..cef334a 100644
--- a/drivers/net/wireless/b43/Makefile
+++ b/drivers/net/wireless/b43/Makefile
@@ -1,12 +1,12 @@
 b43-y				+= main.o
 b43-y				+= tables.o
-b43-$(CONFIG_B43_NPHY)		+= tables_nphy.o
-b43-$(CONFIG_B43_NPHY)		+= radio_2055.o
-b43-$(CONFIG_B43_NPHY)		+= radio_2056.o
+b43-$(CONFIG_B43_PHY_N)		+= tables_nphy.o
+b43-$(CONFIG_B43_PHY_N)		+= radio_2055.o
+b43-$(CONFIG_B43_PHY_N)		+= radio_2056.o
 b43-y				+= phy_common.o
 b43-y				+= phy_g.o
 b43-y				+= phy_a.o
-b43-$(CONFIG_B43_NPHY)		+= phy_n.o
+b43-$(CONFIG_B43_PHY_N)		+= phy_n.o
 b43-$(CONFIG_B43_PHY_LP)	+= phy_lp.o
 b43-$(CONFIG_B43_PHY_LP)	+= tables_lpphy.o
 b43-y				+= sysfs.o
diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index 4d97aac..9ae3f61 100644
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -4052,7 +4052,7 @@ static int b43_phy_versioning(struct b43_wldev *dev)
 		if (phy_rev > 9)
 			unsupported = 1;
 		break;
-#ifdef CONFIG_B43_NPHY
+#ifdef CONFIG_B43_PHY_N
 	case B43_PHYTYPE_N:
 		if (phy_rev > 2)
 			unsupported = 1;
@@ -5097,7 +5097,7 @@ static void b43_print_driverinfo(void)
 #ifdef CONFIG_B43_PCMCIA
 	feat_pcmcia = "M";
 #endif
-#ifdef CONFIG_B43_NPHY
+#ifdef CONFIG_B43_PHY_N
 	feat_nphy = "N";
 #endif
 #ifdef CONFIG_B43_LEDS
diff --git a/drivers/net/wireless/b43/phy_common.c b/drivers/net/wireless/b43/phy_common.c
index 412f1b6..b5c5ce9 100644
--- a/drivers/net/wireless/b43/phy_common.c
+++ b/drivers/net/wireless/b43/phy_common.c
@@ -50,7 +50,7 @@ int b43_phy_allocate(struct b43_wldev *dev)
 		phy->ops = &b43_phyops_g;
 		break;
 	case B43_PHYTYPE_N:
-#ifdef CONFIG_B43_NPHY
+#ifdef CONFIG_B43_PHY_N
 		phy->ops = &b43_phyops_n;
 #endif
 		break;
-- 
1.6.3.3

[PATCH 4/4] b43: rename config option for N-PHY, drop BROKEN

[Rafał Miłecki]

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
---
 drivers/net/wireless/b43/Kconfig      |   13 +++++++------
 drivers/net/wireless/b43/Makefile     |    8 ++++----
 drivers/net/wireless/b43/main.c       |    4 ++--
 drivers/net/wireless/b43/phy_common.c |    2 +-
 4 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/drivers/net/wireless/b43/Kconfig b/drivers/net/wireless/b43/Kconfig
index 0a00d42..47033f6 100644
--- a/drivers/net/wireless/b43/Kconfig
+++ b/drivers/net/wireless/b43/Kconfig
@@ -86,15 +86,16 @@ config B43_PIO
 	select SSB_BLOCKIO
 	default y
 
-config B43_NPHY
-	bool "Pre IEEE 802.11n support (BROKEN)"
-	depends on B43 && EXPERIMENTAL && BROKEN
+config B43_PHY_N
+	bool "Support for 802.11n (N-PHY) devices (EXPERIMENTAL)"
+	depends on B43 && EXPERIMENTAL
 	---help---
-	  Support for the IEEE 802.11n draft.
+	  Support for the N-PHY.
 
-	  THIS IS BROKEN AND DOES NOT WORK YET.
+	  This enables support for devices with N-PHY revision up to 2.
 
-	  SAY N.
+	  Say N if you expect high stability and performance. Saying Y will not
+	  affect other devices support and may provide support for basic needs.
 
 config B43_PHY_LP
 	bool "Support for low-power (LP-PHY) devices (EXPERIMENTAL)"
diff --git a/drivers/net/wireless/b43/Makefile b/drivers/net/wireless/b43/Makefile
index 69d4af0..cef334a 100644
--- a/drivers/net/wireless/b43/Makefile
+++ b/drivers/net/wireless/b43/Makefile
@@ -1,12 +1,12 @@
 b43-y				+= main.o
 b43-y				+= tables.o
-b43-$(CONFIG_B43_NPHY)		+= tables_nphy.o
-b43-$(CONFIG_B43_NPHY)		+= radio_2055.o
-b43-$(CONFIG_B43_NPHY)		+= radio_2056.o
+b43-$(CONFIG_B43_PHY_N)		+= tables_nphy.o
+b43-$(CONFIG_B43_PHY_N)		+= radio_2055.o
+b43-$(CONFIG_B43_PHY_N)		+= radio_2056.o
 b43-y				+= phy_common.o
 b43-y				+= phy_g.o
 b43-y				+= phy_a.o
-b43-$(CONFIG_B43_NPHY)		+= phy_n.o
+b43-$(CONFIG_B43_PHY_N)		+= phy_n.o
 b43-$(CONFIG_B43_PHY_LP)	+= phy_lp.o
 b43-$(CONFIG_B43_PHY_LP)	+= tables_lpphy.o
 b43-y				+= sysfs.o
diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index 4d97aac..9ae3f61 100644
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -4052,7 +4052,7 @@ static int b43_phy_versioning(struct b43_wldev *dev)
 		if (phy_rev > 9)
 			unsupported = 1;
 		break;
-#ifdef CONFIG_B43_NPHY
+#ifdef CONFIG_B43_PHY_N
 	case B43_PHYTYPE_N:
 		if (phy_rev > 2)
 			unsupported = 1;
@@ -5097,7 +5097,7 @@ static void b43_print_driverinfo(void)
 #ifdef CONFIG_B43_PCMCIA
 	feat_pcmcia = "M";
 #endif
-#ifdef CONFIG_B43_NPHY
+#ifdef CONFIG_B43_PHY_N
 	feat_nphy = "N";
 #endif
 #ifdef CONFIG_B43_LEDS
diff --git a/drivers/net/wireless/b43/phy_common.c b/drivers/net/wireless/b43/phy_common.c
index 412f1b6..b5c5ce9 100644
--- a/drivers/net/wireless/b43/phy_common.c
+++ b/drivers/net/wireless/b43/phy_common.c
@@ -50,7 +50,7 @@ int b43_phy_allocate(struct b43_wldev *dev)
 		phy->ops = &b43_phyops_g;
 		break;
 	case B43_PHYTYPE_N:
-#ifdef CONFIG_B43_NPHY
+#ifdef CONFIG_B43_PHY_N
 		phy->ops = &b43_phyops_n;
 #endif
 		break;
-- 
1.6.3.3

[PATCH 0/4] Make N-PHY support experimental

[Johannes Berg]

On Tue, 2010-12-07 at 21:55 +0100, Rafa? Mi?ecki wrote:
> Finally, thanks for Larry and Francesco I got b43 working with BCM4328 chipset!
> 
> It's not perfectly stable yet, but scanning and associating to open network
> works! It has to be tested, improved, there are some PHY errors from time to
> time, but generally it works :)

Wow! Congrats to all involved!!

johannes

Re: [PATCH 0/4] Make N-PHY support experimental

[Johannes Berg]

On Tue, 2010-12-07 at 21:55 +0100, Rafał Miłecki wrote:
> Finally, thanks for Larry and Francesco I got b43 working with BCM4328 chipset!
> 
> It's not perfectly stable yet, but scanning and associating to open network
> works! It has to be tested, improved, there are some PHY errors from time to
> time, but generally it works :)

Wow! Congrats to all involved!!

johannes

[PATCH 0/4] Make N-PHY support experimental

[Gábor Stefanik]

2010/12/7 Rafa? Mi?ecki <zajec5@gmail.com>:
> Finally, thanks for Larry and Francesco I got b43 working with BCM4328 chipset!

Do you mean BCM4321 (14e4:4328)? BCM4328 is AFAIK handled by brcmfmac.

>
> It's not perfectly stable yet, but scanning and associating to open network
> works! It has to be tested, improved, there are some PHY errors from time to
> time, but generally it works :)
>
> Rafa? Mi?ecki (4):
> ?b43: N-PHY: silence warnings
> ?b43: set TMS to work with current band width for N-PHY
> ?b43: fix split of N-PHY devices into supported and not (based on PHY
> ? ?rev)
> ?b43: rename config option for N-PHY, drop BROKEN
>
> ?drivers/net/wireless/b43/Kconfig ? ? ?| ? 13 +++++++------
> ?drivers/net/wireless/b43/Makefile ? ? | ? ?8 ++++----
> ?drivers/net/wireless/b43/main.c ? ? ? | ? 12 +++++++++---
> ?drivers/net/wireless/b43/phy_common.c | ? ?9 ++++++++-
> ?drivers/net/wireless/b43/phy_common.h | ? ?2 ++
> ?drivers/net/wireless/b43/phy_n.c ? ? ?| ? 16 ++++++----------
> ?6 files changed, 36 insertions(+), 24 deletions(-)
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>



-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

Re: [PATCH 0/4] Make N-PHY support experimental

[Gábor Stefanik]

2010/12/7 Rafał Miłecki <zajec5@gmail.com>:
> Finally, thanks for Larry and Francesco I got b43 working with BCM4328 chipset!

Do you mean BCM4321 (14e4:4328)? BCM4328 is AFAIK handled by brcmfmac.

>
> It's not perfectly stable yet, but scanning and associating to open network
> works! It has to be tested, improved, there are some PHY errors from time to
> time, but generally it works :)
>
> Rafał Miłecki (4):
>  b43: N-PHY: silence warnings
>  b43: set TMS to work with current band width for N-PHY
>  b43: fix split of N-PHY devices into supported and not (based on PHY
>    rev)
>  b43: rename config option for N-PHY, drop BROKEN
>
>  drivers/net/wireless/b43/Kconfig      |   13 +++++++------
>  drivers/net/wireless/b43/Makefile     |    8 ++++----
>  drivers/net/wireless/b43/main.c       |   12 +++++++++---
>  drivers/net/wireless/b43/phy_common.c |    9 ++++++++-
>  drivers/net/wireless/b43/phy_common.h |    2 ++
>  drivers/net/wireless/b43/phy_n.c      |   16 ++++++----------
>  6 files changed, 36 insertions(+), 24 deletions(-)
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

[PATCH 0/4] Make N-PHY support experimental

[Larry Finger]

On 12/07/2010 04:57 PM, G?bor Stefanik wrote:
> 2010/12/7 Rafa? Mi?ecki <zajec5@gmail.com>:
>> Finally, thanks for Larry and Francesco I got b43 working with BCM4328 chipset!
> 
> Do you mean BCM4321 (14e4:4328)? BCM4328 is AFAIK handled by brcmfmac.
> 
>>
>> It's not perfectly stable yet, but scanning and associating to open network
>> works! It has to be tested, improved, there are some PHY errors from time to
>> time, but generally it works :)

With my device:

04:00.0 Network controller [0280]: Broadcom Corporation BCM4321 802.11a/b/g/n
[14e4:4328] (rev 03)
        Subsystem: Hewlett-Packard Company BCM4321 802.11a/b/g/n Wireless LAN
Controller [103c:1366]
        Kernel driver in use: b43-pci-bridge

Excerpt of log:

[ 1184.780924] b43-pci-bridge 0000:04:00.0: PCI INT A -> Link[LK4E] -> GSI 20
(level, low) -> IRQ 20
[ 1184.780945] b43-pci-bridge 0000:04:00.0: setting latency timer to 64
[ 1184.800166] ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x13, vendor 0x4243)
[ 1184.800176] ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0C, vendor 0x4243)
[ 1184.800184] ssb: Core 2 found: PCI-E (cc 0x820, rev 0x04, vendor 0x4243)
[ 1184.800192] ssb: Core 3 found: PCI (cc 0x804, rev 0x0D, vendor 0x4243)
[ 1184.800200] ssb: Core 4 found: USB 1.1 Host (cc 0x817, rev 0x04, vendor 0x4243)
[ 1184.820062] ssb: Switching to ChipCommon core, index 0
[ 1184.820202] ssb: chipcommon status is 0x0
[ 1184.820211] ssb: SPROM offset is 0x1000
[ 1184.828653] ssb: SPROM revision 5 detected.
[ 1184.848037] ssb: Switching to PCI-E core, index 2
[ 1184.848659] ssb: Sonics Silicon Backplane found on PCI device 0000:04:00.0
[ 1184.897825] b43-phy0: Broadcom 4321 WLAN found (core revision 12)
[ 1184.916062] ssb: Switching to IEEE 802.11 core, index 1
[ 1184.940038] b43-phy0 debug: Found PHY: Analog 5, Type 4, Revision 2
[ 1184.940064] b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2055, Revision 4
[ 1184.975224] Registered led device: b43-phy0::tx
[ 1184.978455] Registered led device: b43-phy0::rx
[ 1184.980387] Registered led device: b43-phy0::radio
[ 1185.256050] b43-phy0: Loading firmware version 508.1107 (2009-06-26 19:16:02)
[ 1185.256059] ssb: Switching to ChipCommon core, index 0
[ 1185.256123] ssb: Switching to IEEE 802.11 core, index 1
[ 1185.332045] b43-phy0 debug: Chip initialized
[ 1185.333522] b43-phy0 debug: 64-bit DMA initialized
[ 1185.333570] b43-phy0 debug: QoS enabled
[ 1185.353497] b43-phy0 debug: Wireless interface started
[ 1185.353512] b43-phy0 debug: Adding Interface type 2
[ 1188.041790] b43-phy0 debug: Using hardware based encryption for keyidx: 0,
mac: c0:3f:0e:be:2b:45
[ 1191.134922] b43-phy0 debug: Disabling hardware based encryption for keyidx:
0, mac: c0:3f:0e:be:2b:45
[ 1192.823490] b43-phy0 debug: Using hardware based encryption for keyidx: 0,
mac: ff:ff:ff:ff:ff:ff
[ 1192.824306] b43-phy0 debug: Using hardware based encryption for keyidx: 1,
mac: ff:ff:ff:ff:ff:ff
[ 1192.824630] b43-phy0 debug: Using hardware based encryption for keyidx: 2,
mac: ff:ff:ff:ff:ff:ff
[ 1192.824989] b43-phy0 debug: Using hardware based encryption for keyidx: 3,
mac: ff:ff:ff:ff:ff:ff
[ 1194.896063] b43-phy0 ERROR: PHY transmission error

It connects and authenticates with WEP, but not with WPA2. It appears to be
limited to CCK rates. Setting a rate above 11Mb/s results in complete failure.

Transmit rate is 4.6 Mb/s at 11M. All in all, not bad for first life.

Larry

Re: [PATCH 0/4] Make N-PHY support experimental

[Larry Finger]

On 12/07/2010 04:57 PM, Gábor Stefanik wrote:
> 2010/12/7 Rafał Miłecki <zajec5@gmail.com>:
>> Finally, thanks for Larry and Francesco I got b43 working with BCM4328 chipset!
> 
> Do you mean BCM4321 (14e4:4328)? BCM4328 is AFAIK handled by brcmfmac.
> 
>>
>> It's not perfectly stable yet, but scanning and associating to open network
>> works! It has to be tested, improved, there are some PHY errors from time to
>> time, but generally it works :)

With my device:

04:00.0 Network controller [0280]: Broadcom Corporation BCM4321 802.11a/b/g/n
[14e4:4328] (rev 03)
        Subsystem: Hewlett-Packard Company BCM4321 802.11a/b/g/n Wireless LAN
Controller [103c:1366]
        Kernel driver in use: b43-pci-bridge

Excerpt of log:

[ 1184.780924] b43-pci-bridge 0000:04:00.0: PCI INT A -> Link[LK4E] -> GSI 20
(level, low) -> IRQ 20
[ 1184.780945] b43-pci-bridge 0000:04:00.0: setting latency timer to 64
[ 1184.800166] ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x13, vendor 0x4243)
[ 1184.800176] ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0C, vendor 0x4243)
[ 1184.800184] ssb: Core 2 found: PCI-E (cc 0x820, rev 0x04, vendor 0x4243)
[ 1184.800192] ssb: Core 3 found: PCI (cc 0x804, rev 0x0D, vendor 0x4243)
[ 1184.800200] ssb: Core 4 found: USB 1.1 Host (cc 0x817, rev 0x04, vendor 0x4243)
[ 1184.820062] ssb: Switching to ChipCommon core, index 0
[ 1184.820202] ssb: chipcommon status is 0x0
[ 1184.820211] ssb: SPROM offset is 0x1000
[ 1184.828653] ssb: SPROM revision 5 detected.
[ 1184.848037] ssb: Switching to PCI-E core, index 2
[ 1184.848659] ssb: Sonics Silicon Backplane found on PCI device 0000:04:00.0
[ 1184.897825] b43-phy0: Broadcom 4321 WLAN found (core revision 12)
[ 1184.916062] ssb: Switching to IEEE 802.11 core, index 1
[ 1184.940038] b43-phy0 debug: Found PHY: Analog 5, Type 4, Revision 2
[ 1184.940064] b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2055, Revision 4
[ 1184.975224] Registered led device: b43-phy0::tx
[ 1184.978455] Registered led device: b43-phy0::rx
[ 1184.980387] Registered led device: b43-phy0::radio
[ 1185.256050] b43-phy0: Loading firmware version 508.1107 (2009-06-26 19:16:02)
[ 1185.256059] ssb: Switching to ChipCommon core, index 0
[ 1185.256123] ssb: Switching to IEEE 802.11 core, index 1
[ 1185.332045] b43-phy0 debug: Chip initialized
[ 1185.333522] b43-phy0 debug: 64-bit DMA initialized
[ 1185.333570] b43-phy0 debug: QoS enabled
[ 1185.353497] b43-phy0 debug: Wireless interface started
[ 1185.353512] b43-phy0 debug: Adding Interface type 2
[ 1188.041790] b43-phy0 debug: Using hardware based encryption for keyidx: 0,
mac: c0:3f:0e:be:2b:45
[ 1191.134922] b43-phy0 debug: Disabling hardware based encryption for keyidx:
0, mac: c0:3f:0e:be:2b:45
[ 1192.823490] b43-phy0 debug: Using hardware based encryption for keyidx: 0,
mac: ff:ff:ff:ff:ff:ff
[ 1192.824306] b43-phy0 debug: Using hardware based encryption for keyidx: 1,
mac: ff:ff:ff:ff:ff:ff
[ 1192.824630] b43-phy0 debug: Using hardware based encryption for keyidx: 2,
mac: ff:ff:ff:ff:ff:ff
[ 1192.824989] b43-phy0 debug: Using hardware based encryption for keyidx: 3,
mac: ff:ff:ff:ff:ff:ff
[ 1194.896063] b43-phy0 ERROR: PHY transmission error

It connects and authenticates with WEP, but not with WPA2. It appears to be
limited to CCK rates. Setting a rate above 11Mb/s results in complete failure.

Transmit rate is 4.6 Mb/s at 11M. All in all, not bad for first life.

Larry

[PATCH 0/4] Make N-PHY support experimental

[Larry Finger]

I have a bit more info regarding the problem with WPA2 encryption on an N PHY.
As shown in the NetworkManager log attached, Authentication is successful, but
DHCP fails. Either the transmit data is improperly encrypted, or the decryption
fails. I will use wireshark to sort that out. Note: Using software encryption
makes no difference.

Larry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: nm.log
Type: text/x-log
Size: 19096 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20101207/801beb3a/attachment.bin>

Re: [PATCH 0/4] Make N-PHY support experimental

[Larry Finger]

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

I have a bit more info regarding the problem with WPA2 encryption on an N PHY.
As shown in the NetworkManager log attached, Authentication is successful, but
DHCP fails. Either the transmit data is improperly encrypted, or the decryption
fails. I will use wireshark to sort that out. Note: Using software encryption
makes no difference.

Larry


[-- Attachment #2: nm.log --]
[-- Type: text/x-log, Size: 19096 bytes --]

Dec  7 21:13:37 larrylap NetworkManager: <info>  (wlan5): device state change: 8 -> 3 (reason 0)
Dec  7 21:13:37 larrylap NetworkManager: <info>  (wlan5): deactivating device (reason: 0).
Dec  7 21:13:37 larrylap NetworkManager: <info>  (wlan5): canceled DHCP transaction, dhcp client pid 5982
Dec  7 21:13:37 larrylap NetworkManager: <WARN>  check_one_route(): (wlan5) error -34 returned from rtnl_route_del(): Sucess#012
Dec  7 21:13:37 larrylap NetworkManager: <debug> [1291778017.386964] run_netconfig(): Spawning '/sbin/netconfig modify --service NetworkManager'
Dec  7 21:13:37 larrylap NetworkManager: <debug> [1291778017.403700] write_to_netconfig(): Writing to netconfig: INTERFACE='wlan5'#012
Dec  7 21:13:37 larrylap NetworkManager: <info>  Clearing nscd hosts cache.
Dec  7 21:13:37 larrylap NetworkManager: <info>  Activation (wlan5) starting connection 'lwfdjf_rad'
Dec  7 21:13:37 larrylap NetworkManager: <info>  (wlan5): device state change: 3 -> 4 (reason 0)
Dec  7 21:13:37 larrylap NetworkManager: <info>  Activation (wlan5) Stage 1 of 5 (Device Prepare) scheduled...
Dec  7 21:13:37 larrylap NetworkManager: <info>  Activation (wlan5) Stage 1 of 5 (Device Prepare) started...
Dec  7 21:13:37 larrylap NetworkManager: <info>  Activation (wlan5) Stage 2 of 5 (Device Configure) scheduled...
Dec  7 21:13:37 larrylap NetworkManager: <info>  Activation (wlan5) Stage 1 of 5 (Device Prepare) complete.
Dec  7 21:13:37 larrylap NetworkManager: <info>  (wlan5): supplicant connection state:  completed -> disconnected
Dec  7 21:13:37 larrylap NetworkManager: <info>  Activation (wlan5) Stage 2 of 5 (Device Configure) starting...
Dec  7 21:13:37 larrylap NetworkManager: <info>  (wlan5): device state change: 4 -> 5 (reason 0)
Dec  7 21:13:37 larrylap NetworkManager: <info>  Activation (wlan5/wireless): connection 'lwfdjf_rad' has security, and secrets exist.  No new secrets needed
.
Dec  7 21:13:37 larrylap NetworkManager: <info>  Config: added 'ssid' value 'lwfdjf_rad'
Dec  7 21:13:37 larrylap NetworkManager: <info>  Config: added 'scan_ssid' value '1'
Dec  7 21:13:37 larrylap NetworkManager: <info>  Config: added 'key_mgmt' value 'WPA-PSK'
Dec  7 21:13:37 larrylap NetworkManager: <info>  Config: added 'psk' value '<omitted>'
Dec  7 21:13:37 larrylap NetworkManager: <info>  Activation (wlan5) Stage 2 of 5 (Device Configure) complete.
Dec  7 21:13:37 larrylap NetworkManager: <info>  Config: set interface ap_scan to 1
Dec  7 21:13:37 larrylap NetworkManager: <info>  (wlan5): supplicant connection state:  disconnected -> scanning
Dec  7 21:13:37 larrylap nm-dispatcher.action: Script '/etc/NetworkManager/dispatcher.d/autofs' exited with error status 1.
Dec  7 21:13:38 larrylap NetworkManager: <info>  (wlan5): supplicant connection state:  scanning -> associating
Dec  7 21:13:38 larrylap NetworkManager: <info>  (wlan5): supplicant connection state:  associating -> associated
Dec  7 21:13:38 larrylap NetworkManager: <info>  (wlan5): supplicant connection state:  associated -> 4-way handshake
Dec  7 21:13:38 larrylap NetworkManager: <info>  (wlan5): supplicant connection state:  4-way handshake -> group handshake
Dec  7 21:13:38 larrylap NetworkManager: <info>  (wlan5): supplicant connection state:  group handshake -> completed
Dec  7 21:13:38 larrylap NetworkManager: <info>  Activation (wlan5/wireless) Stage 2 of 5 (Device Configure) successful.  Connected to wireless network 'lwfdjf_rad'.
Dec  7 21:13:38 larrylap NetworkManager: <info>  Activation (wlan5) Stage 3 of 5 (IP Configure Start) scheduled.
Dec  7 21:13:38 larrylap NetworkManager: <info>  Activation (wlan5) Stage 3 of 5 (IP Configure Start) started...
Dec  7 21:13:38 larrylap NetworkManager: <info>  (wlan5): device state change: 5 -> 7 (reason 0)
Dec  7 21:13:38 larrylap NetworkManager: <info>  Activation (wlan5) Beginning DHCP transaction (timeout in 45 seconds)
Dec  7 21:13:38 larrylap NetworkManager: <info>  dhclient started with pid 7150
Dec  7 21:13:38 larrylap NetworkManager: <info>  Activation (wlan5) Stage 4 of 5 (IP6 Configure Get) scheduled...
Dec  7 21:13:38 larrylap NetworkManager: <info>  Activation (wlan5) Stage 3 of 5 (IP Configure Start) complete.
Dec  7 21:13:38 larrylap NetworkManager: <info>  Activation (wlan5) Stage 4 of 5 (IP6 Configure Get) started...
Dec  7 21:13:38 larrylap NetworkManager: <info>  Activation (wlan5) Stage 4 of 5 (IP6 Configure Get) complete.
Dec  7 21:13:38 larrylap NetworkManager: <info>  DHCP: device wlan5 state changed normal exit -> preinit
Dec  7 21:14:19 larrylap NetworkManager: <info>  (wlan5): device state change: 7 -> 3 (reason 0)
Dec  7 21:14:19 larrylap NetworkManager: <info>  (wlan5): deactivating device (reason: 0).
Dec  7 21:14:19 larrylap NetworkManager: <info>  (wlan5): canceled DHCP transaction, dhcp client pid 7150
Dec  7 21:14:19 larrylap NetworkManager: <info>  Activation (wlan5) starting connection 'Larry_wep'
Dec  7 21:14:19 larrylap NetworkManager: <info>  (wlan5): device state change: 3 -> 4 (reason 0)
Dec  7 21:14:19 larrylap NetworkManager: <info>  Activation (wlan5) Stage 1 of 5 (Device Prepare) scheduled...
Dec  7 21:14:19 larrylap NetworkManager: <info>  Activation (wlan5) Stage 1 of 5 (Device Prepare) started...
Dec  7 21:14:19 larrylap NetworkManager: <info>  Activation (wlan5) Stage 2 of 5 (Device Configure) scheduled...
Dec  7 21:14:19 larrylap NetworkManager: <info>  Activation (wlan5) Stage 1 of 5 (Device Prepare) complete.
Dec  7 21:14:19 larrylap NetworkManager: <info>  Activation (wlan5) Stage 2 of 5 (Device Configure) starting...
Dec  7 21:14:19 larrylap NetworkManager: <info>  (wlan5): device state change: 4 -> 5 (reason 0)
Dec  7 21:14:19 larrylap NetworkManager: <info>  Activation (wlan5/wireless): access point 'Larry_wep' has security, but secrets are required.
Dec  7 21:14:19 larrylap NetworkManager: <info>  (wlan5): device state change: 5 -> 6 (reason 0)
Dec  7 21:14:19 larrylap NetworkManager: <info>  Activation (wlan5) Stage 2 of 5 (Device Configure) complete.
Dec  7 21:14:19 larrylap NetworkManager: <info>  (wlan5): supplicant connection state:  completed -> disconnected
Dec  7 21:14:19 larrylap NetworkManager: <info>  (wlan5): device state change: 6 -> 3 (reason 38)
Dec  7 21:14:19 larrylap NetworkManager: <info>  (wlan5): deactivating device (reason: 38).
Dec  7 21:14:23 larrylap NetworkManager: <info>  Activation (wlan5) starting connection 'lwfdjf_rad'
Dec  7 21:14:23 larrylap NetworkManager: <info>  (wlan5): device state change: 3 -> 4 (reason 0)
Dec  7 21:14:23 larrylap NetworkManager: <info>  Activation (wlan5) Stage 1 of 5 (Device Prepare) scheduled...
Dec  7 21:14:23 larrylap NetworkManager: <info>  Activation (wlan5) Stage 1 of 5 (Device Prepare) started...
Dec  7 21:14:23 larrylap NetworkManager: <info>  Activation (wlan5) Stage 2 of 5 (Device Configure) scheduled...
Dec  7 21:14:23 larrylap NetworkManager: <info>  Activation (wlan5) Stage 1 of 5 (Device Prepare) complete.
Dec  7 21:14:23 larrylap NetworkManager: <info>  Activation (wlan5) Stage 2 of 5 (Device Configure) starting...
Dec  7 21:14:23 larrylap NetworkManager: <info>  (wlan5): device state change: 4 -> 5 (reason 0)
Dec  7 21:14:23 larrylap NetworkManager: <info>  Activation (wlan5/wireless): access point 'lwfdjf_rad' has security, but secrets are required.
Dec  7 21:14:23 larrylap NetworkManager: <info>  (wlan5): device state change: 5 -> 6 (reason 0)
Dec  7 21:14:23 larrylap NetworkManager: <info>  Activation (wlan5) Stage 2 of 5 (Device Configure) complete.
Dec  7 21:14:23 larrylap NetworkManager: <WARN>  secrets_update_setting(): Failed to update connection secrets: 1 802-1x
Dec  7 21:14:23 larrylap NetworkManager: <info>  Activation (wlan5) Stage 1 of 5 (Device Prepare) scheduled...
Dec  7 21:14:23 larrylap NetworkManager: <info>  Activation (wlan5) Stage 1 of 5 (Device Prepare) started...
Dec  7 21:14:23 larrylap NetworkManager: <info>  (wlan5): device state change: 6 -> 4 (reason 0)
Dec  7 21:14:23 larrylap NetworkManager: <info>  Activation (wlan5) Stage 2 of 5 (Device Configure) scheduled...
Dec  7 21:14:23 larrylap NetworkManager: <info>  Activation (wlan5) Stage 1 of 5 (Device Prepare) complete.
Dec  7 21:14:23 larrylap NetworkManager: <info>  Activation (wlan5) Stage 2 of 5 (Device Configure) starting...
Dec  7 21:14:23 larrylap NetworkManager: <info>  (wlan5): device state change: 4 -> 5 (reason 0)
Dec  7 21:14:23 larrylap NetworkManager: <info>  Activation (wlan5/wireless): connection 'lwfdjf_rad' has security, and secrets exist.  No new secrets needed.
Dec  7 21:14:23 larrylap NetworkManager: <info>  Config: added 'ssid' value 'lwfdjf_rad'
Dec  7 21:14:23 larrylap NetworkManager: <info>  Config: added 'scan_ssid' value '1'
Dec  7 21:14:23 larrylap NetworkManager: <info>  Config: added 'key_mgmt' value 'WPA-PSK'
Dec  7 21:14:23 larrylap NetworkManager: <info>  Config: added 'psk' value '<omitted>'
Dec  7 21:14:23 larrylap NetworkManager: <info>  Activation (wlan5) Stage 2 of 5 (Device Configure) complete.
Dec  7 21:14:23 larrylap NetworkManager: <info>  Config: set interface ap_scan to 1
Dec  7 21:14:23 larrylap NetworkManager: <info>  (wlan5): supplicant connection state:  disconnected -> scanning
Dec  7 21:14:24 larrylap NetworkManager: <info>  (wlan5): supplicant connection state:  scanning -> associating
Dec  7 21:14:24 larrylap NetworkManager: <info>  (wlan5): supplicant connection state:  associating -> associated
Dec  7 21:14:24 larrylap NetworkManager: <info>  (wlan5): supplicant connection state:  associated -> 4-way handshake
Dec  7 21:14:24 larrylap NetworkManager: <info>  (wlan5): supplicant connection state:  4-way handshake -> group handshake
Dec  7 21:14:24 larrylap NetworkManager: <info>  (wlan5): supplicant connection state:  group handshake -> completed
Dec  7 21:14:24 larrylap NetworkManager: <info>  Activation (wlan5/wireless) Stage 2 of 5 (Device Configure) successful.  Connected to wireless network 'lwfdjf_rad'.
Dec  7 21:14:24 larrylap NetworkManager: <info>  Activation (wlan5) Stage 3 of 5 (IP Configure Start) scheduled.
Dec  7 21:14:24 larrylap NetworkManager: <info>  Activation (wlan5) Stage 3 of 5 (IP Configure Start) started...
Dec  7 21:14:24 larrylap NetworkManager: <info>  (wlan5): device state change: 5 -> 7 (reason 0)
Dec  7 21:14:24 larrylap NetworkManager: <info>  Activation (wlan5) Beginning DHCP transaction (timeout in 45 seconds)
Dec  7 21:14:24 larrylap NetworkManager: <info>  dhclient started with pid 7177
Dec  7 21:14:24 larrylap NetworkManager: <info>  Activation (wlan5) Stage 4 of 5 (IP6 Configure Get) scheduled...
Dec  7 21:14:24 larrylap NetworkManager: <info>  Activation (wlan5) Stage 3 of 5 (IP Configure Start) complete.
Dec  7 21:14:24 larrylap NetworkManager: <info>  Activation (wlan5) Stage 4 of 5 (IP6 Configure Get) started...
Dec  7 21:14:24 larrylap NetworkManager: <info>  Activation (wlan5) Stage 4 of 5 (IP6 Configure Get) complete.
Dec  7 21:14:24 larrylap NetworkManager: <info>  DHCP: device wlan5 state changed normal exit -> preinit
Dec  7 21:14:32 larrylap NetworkManager: <info>  (wlan5): device state change: 7 -> 3 (reason 0)
Dec  7 21:14:32 larrylap NetworkManager: <info>  (wlan5): deactivating device (reason: 0).
Dec  7 21:14:32 larrylap NetworkManager: <info>  (wlan5): canceled DHCP transaction, dhcp client pid 7177
Dec  7 21:14:32 larrylap NetworkManager: <info>  Activation (wlan5) starting connection 'Larry_wep'
Dec  7 21:14:32 larrylap NetworkManager: <info>  (wlan5): device state change: 3 -> 4 (reason 0)
Dec  7 21:14:32 larrylap NetworkManager: <info>  Activation (wlan5) Stage 1 of 5 (Device Prepare) scheduled...
Dec  7 21:14:32 larrylap NetworkManager: <info>  Activation (wlan5) Stage 1 of 5 (Device Prepare) started...
Dec  7 21:14:32 larrylap NetworkManager: <info>  Activation (wlan5) Stage 2 of 5 (Device Configure) scheduled...
Dec  7 21:14:32 larrylap NetworkManager: <info>  Activation (wlan5) Stage 1 of 5 (Device Prepare) complete.
Dec  7 21:14:32 larrylap NetworkManager: <info>  (wlan5): supplicant connection state:  completed -> disconnected
Dec  7 21:14:32 larrylap NetworkManager: <info>  Activation (wlan5) Stage 2 of 5 (Device Configure) starting...
Dec  7 21:14:32 larrylap NetworkManager: <info>  (wlan5): device state change: 4 -> 5 (reason 0)
Dec  7 21:14:32 larrylap NetworkManager: <info>  Activation (wlan5/wireless): access point 'Larry_wep' has security, but secrets are required.
Dec  7 21:14:32 larrylap NetworkManager: <info>  (wlan5): device state change: 5 -> 6 (reason 0)
Dec  7 21:14:32 larrylap NetworkManager: <info>  Activation (wlan5) Stage 2 of 5 (Device Configure) complete.
Dec  7 21:14:32 larrylap NetworkManager: <WARN>  secrets_update_setting(): Failed to update connection secrets: 1 802-1x
Dec  7 21:14:32 larrylap NetworkManager: <info>  Activation (wlan5) Stage 1 of 5 (Device Prepare) scheduled...
Dec  7 21:14:32 larrylap NetworkManager: <info>  Activation (wlan5) Stage 1 of 5 (Device Prepare) started...
Dec  7 21:14:32 larrylap NetworkManager: <info>  (wlan5): device state change: 6 -> 4 (reason 0)
Dec  7 21:14:32 larrylap NetworkManager: <info>  Activation (wlan5) Stage 2 of 5 (Device Configure) scheduled...
Dec  7 21:14:32 larrylap NetworkManager: <info>  Activation (wlan5) Stage 1 of 5 (Device Prepare) complete.
Dec  7 21:14:32 larrylap NetworkManager: <info>  Activation (wlan5) Stage 2 of 5 (Device Configure) starting...
Dec  7 21:14:32 larrylap NetworkManager: <info>  (wlan5): device state change: 4 -> 5 (reason 0)
Dec  7 21:14:32 larrylap NetworkManager: <info>  Activation (wlan5/wireless): connection 'Larry_wep' has security, and secrets exist.  No new secrets needed.
Dec  7 21:14:32 larrylap NetworkManager: <info>  Config: added 'ssid' value 'Larry_wep'
Dec  7 21:14:32 larrylap NetworkManager: <info>  Config: added 'scan_ssid' value '1'
Dec  7 21:14:32 larrylap NetworkManager: <info>  Config: added 'key_mgmt' value 'NONE'
Dec  7 21:14:32 larrylap NetworkManager: <info>  Config: added 'wep_key0' value '<omitted>'
Dec  7 21:14:32 larrylap NetworkManager: <info>  Config: added 'wep_key1' value '<omitted>'
Dec  7 21:14:32 larrylap NetworkManager: <info>  Config: added 'wep_key2' value '<omitted>'
Dec  7 21:14:32 larrylap NetworkManager: <info>  Config: added 'wep_key3' value '<omitted>'
Dec  7 21:14:32 larrylap NetworkManager: <info>  Config: added 'wep_tx_keyidx' value '0'
Dec  7 21:14:32 larrylap NetworkManager: <info>  Activation (wlan5) Stage 2 of 5 (Device Configure) complete.
Dec  7 21:14:32 larrylap NetworkManager: <info>  Config: set interface ap_scan to 1
Dec  7 21:14:32 larrylap NetworkManager: <info>  (wlan5): supplicant connection state:  disconnected -> scanning
Dec  7 21:14:34 larrylap NetworkManager: <info>  (wlan5): supplicant connection state:  scanning -> associating
Dec  7 21:14:34 larrylap NetworkManager: <info>  (wlan5): supplicant connection state:  associating -> associated
Dec  7 21:14:34 larrylap NetworkManager: <info>  (wlan5): supplicant connection state:  associated -> completed
Dec  7 21:14:34 larrylap NetworkManager: <info>  Activation (wlan5/wireless) Stage 2 of 5 (Device Configure) successful.  Connected to wireless network 'Larry_wep'.
Dec  7 21:14:34 larrylap NetworkManager: <info>  Activation (wlan5) Stage 3 of 5 (IP Configure Start) scheduled.
Dec  7 21:14:34 larrylap NetworkManager: <info>  Activation (wlan5) Stage 3 of 5 (IP Configure Start) started...
Dec  7 21:14:34 larrylap NetworkManager: <info>  (wlan5): device state change: 5 -> 7 (reason 0)
Dec  7 21:14:34 larrylap NetworkManager: <info>  Activation (wlan5) Beginning DHCP transaction (timeout in 45 seconds)
Dec  7 21:14:34 larrylap NetworkManager: <info>  dhclient started with pid 7187
Dec  7 21:14:34 larrylap NetworkManager: <info>  Activation (wlan5) Stage 4 of 5 (IP6 Configure Get) scheduled...
Dec  7 21:14:34 larrylap NetworkManager: <info>  Activation (wlan5) Stage 3 of 5 (IP Configure Start) complete.
Dec  7 21:14:34 larrylap NetworkManager: <info>  Activation (wlan5) Stage 4 of 5 (IP6 Configure Get) started...
Dec  7 21:14:34 larrylap NetworkManager: <info>  Activation (wlan5) Stage 4 of 5 (IP6 Configure Get) complete.
Dec  7 21:14:34 larrylap NetworkManager: <info>  DHCP: device wlan5 state changed normal exit -> preinit
Dec  7 21:14:38 larrylap NetworkManager: <info>  DHCP: device wlan5 state changed preinit -> reboot
Dec  7 21:14:38 larrylap NetworkManager: <info>  Activation (wlan5) Stage 4 of 5 (IP4 Configure Get) scheduled...
Dec  7 21:14:38 larrylap NetworkManager: <info>  Activation (wlan5) Stage 4 of 5 (IP4 Configure Get) started...
Dec  7 21:14:38 larrylap NetworkManager: <info>    address 192.168.3.102
Dec  7 21:14:38 larrylap NetworkManager: <info>    prefix 24 (255.255.255.0)
Dec  7 21:14:38 larrylap NetworkManager: <info>    gateway 192.168.3.1
Dec  7 21:14:38 larrylap NetworkManager: <info>    nameserver '192.168.2.1'
Dec  7 21:14:38 larrylap NetworkManager: <info>    domain name 'lan'
Dec  7 21:14:38 larrylap NetworkManager: <info>  Activation (wlan5) Stage 5 of 5 (IP Configure Commit) scheduled...
Dec  7 21:14:38 larrylap NetworkManager: <info>  Activation (wlan5) Stage 4 of 5 (IP4 Configure Get) complete.
Dec  7 21:14:38 larrylap NetworkManager: <info>  Activation (wlan5) Stage 5 of 5 (IP Configure Commit) started...
Dec  7 21:14:39 larrylap NetworkManager: <debug> [1291778079.043901] run_netconfig(): Spawning '/sbin/netconfig modify --service NetworkManager'
Dec  7 21:14:39 larrylap NetworkManager: <debug> [1291778079.056161] write_to_netconfig(): Writing to netconfig: INTERFACE='wlan5'#012
Dec  7 21:14:39 larrylap NetworkManager: <debug> [1291778079.056433] write_to_netconfig(): Writing to netconfig: DNSSEARCH='lan lan'#012
Dec  7 21:14:39 larrylap NetworkManager: <debug> [1291778079.056500] write_to_netconfig(): Writing to netconfig: DNSSERVERS='192.168.2.1'#012
Dec  7 21:14:39 larrylap NetworkManager: <info>  Clearing nscd hosts cache.
Dec  7 21:14:39 larrylap NetworkManager: <info>  (wlan5): device state change: 7 -> 8 (reason 0)
Dec  7 21:14:39 larrylap NetworkManager: <debug> [1291778079.088730] run_netconfig(): Spawning '/sbin/netconfig modify --service NetworkManager'
Dec  7 21:14:39 larrylap NetworkManager: <debug> [1291778079.119134] write_to_netconfig(): Writing to netconfig: INTERFACE='wlan5'#012
Dec  7 21:14:39 larrylap NetworkManager: <debug> [1291778079.119375] write_to_netconfig(): Writing to netconfig: DNSSEARCH='lan lan'#012
Dec  7 21:14:39 larrylap NetworkManager: <debug> [1291778079.119435] write_to_netconfig(): Writing to netconfig: DNSSERVERS='192.168.2.1'#012
Dec  7 21:14:39 larrylap NetworkManager: <info>  Clearing nscd hosts cache.
Dec  7 21:14:39 larrylap NetworkManager: <info>  Policy set 'Larry_wep' (wlan5) as default for routing and DNS.
Dec  7 21:14:39 larrylap NetworkManager: <info>  Activation (wlan5) successful, device activated.
Dec  7 21:14:39 larrylap NetworkManager: <info>  Activation (wlan5) Stage 5 of 5 (IP Configure Commit) complete.
Dec  7 21:14:39 larrylap nm-dispatcher.action: Script '/etc/NetworkManager/dispatcher.d/autofs' exited with error status 1.

[PATCH 0/4] Make N-PHY support experimental

[Rafał Miłecki]

2010/12/8 Larry Finger <Larry.Finger@lwfinger.net>:
> I have a bit more info regarding the problem with WPA2 encryption on an N PHY.
> As shown in the NetworkManager log attached, Authentication is successful, but
> DHCP fails. Either the transmit data is improperly encrypted, or the decryption
> fails. I will use wireshark to sort that out. Note: Using software encryption
> makes no difference.

Hm, I expected software encryption to work, that's weird. I don't
really have nice access to my development machine, so some tests would
be great.

-- 
Rafa?

Re: [PATCH 0/4] Make N-PHY support experimental

[Rafał Miłecki]

2010/12/8 Larry Finger <Larry.Finger@lwfinger.net>:
> I have a bit more info regarding the problem with WPA2 encryption on an N PHY.
> As shown in the NetworkManager log attached, Authentication is successful, but
> DHCP fails. Either the transmit data is improperly encrypted, or the decryption
> fails. I will use wireshark to sort that out. Note: Using software encryption
> makes no difference.

Hm, I expected software encryption to work, that's weird. I don't
really have nice access to my development machine, so some tests would
be great.

-- 
Rafał

[PATCH 0/4] Make N-PHY support experimental

[Larry Finger]

On 12/09/2010 08:11 AM, Rafa? Mi?ecki wrote:
> 2010/12/8 Larry Finger <Larry.Finger@lwfinger.net>:
>> I have a bit more info regarding the problem with WPA2 encryption on an N PHY.
>> As shown in the NetworkManager log attached, Authentication is successful, but
>> DHCP fails. Either the transmit data is improperly encrypted, or the decryption
>> fails. I will use wireshark to sort that out. Note: Using software encryption
>> makes no difference.
> 
> Hm, I expected software encryption to work, that's weird. I don't
> really have nice access to my development machine, so some tests would
> be great.

Actually, when I got wireshark all setup on my netbook and tried again, WPA2
worked with hardware encryption. I'm not sure what the problem was the first time.

I still have no idea why OFDM rates are failing. Any thoughts?

My device lists the following:

Network controller [0280]: Broadcom Corporation BCM4321 802.11a/b/g/n
[14e4:4328] (rev 03)
ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x13, vendor 0x4243)
ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0C, vendor 0x4243)
ssb: Core 2 found: PCI-E (cc 0x820, rev 0x04, vendor 0x4243)
ssb: Core 3 found: PCI (cc 0x804, rev 0x0D, vendor 0x4243)
ssb: Core 4 found: USB 1.1 Host (cc 0x817, rev 0x04, vendor 0x4243)

It has a rev 2 PHY, and a rev 4 0x2055 radio.

I am willing to buy a higher PHY rev device for testing. Any idea what is in a
4324A-BRCM1036? See
http://cgi.ebay.com/Broadcom-Mini-PCI-e-802-11-a-b-g-n-Wireless-Card-/190477425068?pt=LH_DefaultDomain_0&hash=item2c5956d9ac.

Larry

Re: [PATCH 0/4] Make N-PHY support experimental

[Larry Finger]

On 12/09/2010 08:11 AM, Rafał Miłecki wrote:
> 2010/12/8 Larry Finger <Larry.Finger@lwfinger.net>:
>> I have a bit more info regarding the problem with WPA2 encryption on an N PHY.
>> As shown in the NetworkManager log attached, Authentication is successful, but
>> DHCP fails. Either the transmit data is improperly encrypted, or the decryption
>> fails. I will use wireshark to sort that out. Note: Using software encryption
>> makes no difference.
> 
> Hm, I expected software encryption to work, that's weird. I don't
> really have nice access to my development machine, so some tests would
> be great.

Actually, when I got wireshark all setup on my netbook and tried again, WPA2
worked with hardware encryption. I'm not sure what the problem was the first time.

I still have no idea why OFDM rates are failing. Any thoughts?

My device lists the following:

Network controller [0280]: Broadcom Corporation BCM4321 802.11a/b/g/n
[14e4:4328] (rev 03)
ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x13, vendor 0x4243)
ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0C, vendor 0x4243)
ssb: Core 2 found: PCI-E (cc 0x820, rev 0x04, vendor 0x4243)
ssb: Core 3 found: PCI (cc 0x804, rev 0x0D, vendor 0x4243)
ssb: Core 4 found: USB 1.1 Host (cc 0x817, rev 0x04, vendor 0x4243)

It has a rev 2 PHY, and a rev 4 0x2055 radio.

I am willing to buy a higher PHY rev device for testing. Any idea what is in a
4324A-BRCM1036? See
http://cgi.ebay.com/Broadcom-Mini-PCI-e-802-11-a-b-g-n-Wireless-Card-/190477425068?pt=LH_DefaultDomain_0&hash=item2c5956d9ac.

Larry

[PATCH 0/4] Make N-PHY support experimental

[Johannes Berg]

On Thu, 2010-12-09 at 09:20 -0600, Larry Finger wrote:

> It has a rev 2 PHY, and a rev 4 0x2055 radio.
> 
> I am willing to buy a higher PHY rev device for testing. Any idea what is in a
> 4324A-BRCM1036?

It says BCM94322 on the image, and if that's any indication, I have a
4322 with pci ID 14e4:432b (but it's an Apple build):

b43-phy0: Broadcom 4322 WLAN found (core revision 16)
b43-phy0 debug: Found PHY: Analog 8, Type 4, Revision 4
b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2056, Revision 3

johannes

Re: [PATCH 0/4] Make N-PHY support experimental

[Johannes Berg]

On Thu, 2010-12-09 at 09:20 -0600, Larry Finger wrote:

> It has a rev 2 PHY, and a rev 4 0x2055 radio.
> 
> I am willing to buy a higher PHY rev device for testing. Any idea what is in a
> 4324A-BRCM1036?

It says BCM94322 on the image, and if that's any indication, I have a
4322 with pci ID 14e4:432b (but it's an Apple build):

b43-phy0: Broadcom 4322 WLAN found (core revision 16)
b43-phy0 debug: Found PHY: Analog 8, Type 4, Revision 4
b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2056, Revision 3

johannes

[PATCH 0/4] Make N-PHY support experimental

[Rafał Miłecki]

2010/12/9 Johannes Berg <johannes@sipsolutions.net>:
> On Thu, 2010-12-09 at 09:20 -0600, Larry Finger wrote:
>
>> It has a rev 2 PHY, and a rev 4 0x2055 radio.
>>
>> I am willing to buy a higher PHY rev device for testing. Any idea what is in a
>> 4324A-BRCM1036?
>
> It says BCM94322 on the image, and if that's any indication, I have a
> 4322 with pci ID 14e4:432b (but it's an Apple build):
>
> b43-phy0: Broadcom 4322 WLAN found (core revision 16)
> b43-phy0 debug: Found PHY: Analog 8, Type 4, Revision 4
> b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2056, Revision 3

I actually asked for some hardware donations on my blog and in news on
polish portal, but didn't receive any serious offer.

Johannes: is there any chance you could put this card in some machine
I could get ssh access to? Or is that some daily-user-card or you
don't really have free machine? Of course I don't need that now, first
we have to make PHY 2 support more complete. But maybe after
Christmas/new year I could focus on that.

-- 
Rafa?

Re: [PATCH 0/4] Make N-PHY support experimental

[Rafał Miłecki]

2010/12/9 Johannes Berg <johannes@sipsolutions.net>:
> On Thu, 2010-12-09 at 09:20 -0600, Larry Finger wrote:
>
>> It has a rev 2 PHY, and a rev 4 0x2055 radio.
>>
>> I am willing to buy a higher PHY rev device for testing. Any idea what is in a
>> 4324A-BRCM1036?
>
> It says BCM94322 on the image, and if that's any indication, I have a
> 4322 with pci ID 14e4:432b (but it's an Apple build):
>
> b43-phy0: Broadcom 4322 WLAN found (core revision 16)
> b43-phy0 debug: Found PHY: Analog 8, Type 4, Revision 4
> b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2056, Revision 3

I actually asked for some hardware donations on my blog and in news on
polish portal, but didn't receive any serious offer.

Johannes: is there any chance you could put this card in some machine
I could get ssh access to? Or is that some daily-user-card or you
don't really have free machine? Of course I don't need that now, first
we have to make PHY 2 support more complete. But maybe after
Christmas/new year I could focus on that.

-- 
Rafał

[PATCH 0/4] Make N-PHY support experimental

[Johannes Berg]

On Thu, 2010-12-09 at 16:28 +0100, Rafa? Mi?ecki wrote:

> I actually asked for some hardware donations on my blog and in news on
> polish portal, but didn't receive any serious offer.

There probably are still money donations left to buy some ... ?

> Johannes: is there any chance you could put this card in some machine
> I could get ssh access to? Or is that some daily-user-card or you
> don't really have free machine? Of course I don't need that now, first
> we have to make PHY 2 support more complete. But maybe after
> Christmas/new year I could focus on that.

I can't, unless I magically get a new laptop -- this card is built into
my macbook that I use all the time. I'd have a mostly-free machine, and
I don't use the card, but it's not a replacable part.

johannes

Re: [PATCH 0/4] Make N-PHY support experimental

[Johannes Berg]

On Thu, 2010-12-09 at 16:28 +0100, Rafał Miłecki wrote:

> I actually asked for some hardware donations on my blog and in news on
> polish portal, but didn't receive any serious offer.

There probably are still money donations left to buy some ... ?

> Johannes: is there any chance you could put this card in some machine
> I could get ssh access to? Or is that some daily-user-card or you
> don't really have free machine? Of course I don't need that now, first
> we have to make PHY 2 support more complete. But maybe after
> Christmas/new year I could focus on that.

I can't, unless I magically get a new laptop -- this card is built into
my macbook that I use all the time. I'd have a mostly-free machine, and
I don't use the card, but it's not a replacable part.

johannes

[PATCH 0/4] Make N-PHY support experimental

[Rafał Miłecki]

2010/12/9 Johannes Berg <johannes@sipsolutions.net>:
> On Thu, 2010-12-09 at 16:28 +0100, Rafa? Mi?ecki wrote:
>> I actually asked for some hardware donations on my blog and in news on
>> polish portal, but didn't receive any serious offer.
>
> There probably are still money donations left to buy some ... ?

The problem I was afraid of was recognizing PHY revision without
buying a card, just from looking at photos. It seems however, that
will be the only solution.


>> Johannes: is there any chance you could put this card in some machine
>> I could get ssh access to? Or is that some daily-user-card or you
>> don't really have free machine? Of course I don't need that now, first
>> we have to make PHY 2 support more complete. But maybe after
>> Christmas/new year I could focus on that.
>
> I can't, unless I magically get a new laptop -- this card is built into
> my macbook that I use all the time. I'd have a mostly-free machine, and
> I don't use the card, but it's not a replacable part.

OK, I'll just think about buying some card :)

-- 
Rafa?

Re: [PATCH 0/4] Make N-PHY support experimental

[Rafał Miłecki]

2010/12/9 Johannes Berg <johannes@sipsolutions.net>:
> On Thu, 2010-12-09 at 16:28 +0100, Rafał Miłecki wrote:
>> I actually asked for some hardware donations on my blog and in news on
>> polish portal, but didn't receive any serious offer.
>
> There probably are still money donations left to buy some ... ?

The problem I was afraid of was recognizing PHY revision without
buying a card, just from looking at photos. It seems however, that
will be the only solution.


>> Johannes: is there any chance you could put this card in some machine
>> I could get ssh access to? Or is that some daily-user-card or you
>> don't really have free machine? Of course I don't need that now, first
>> we have to make PHY 2 support more complete. But maybe after
>> Christmas/new year I could focus on that.
>
> I can't, unless I magically get a new laptop -- this card is built into
> my macbook that I use all the time. I'd have a mostly-free machine, and
> I don't use the card, but it's not a replacable part.

OK, I'll just think about buying some card :)

-- 
Rafał

[PATCH 0/4] Make N-PHY support experimental

[Larry Finger]

On 12/09/2010 09:37 AM, Rafa? Mi?ecki wrote:
> 2010/12/9 Johannes Berg <johannes@sipsolutions.net>:
>> On Thu, 2010-12-09 at 16:28 +0100, Rafa? Mi?ecki wrote:
>>> I actually asked for some hardware donations on my blog and in news on
>>> polish portal, but didn't receive any serious offer.
>>
>> There probably are still money donations left to buy some ... ?
> 
> The problem I was afraid of was recognizing PHY revision without
> buying a card, just from looking at photos. It seems however, that
> will be the only solution.
> 
> 
>>> Johannes: is there any chance you could put this card in some machine
>>> I could get ssh access to? Or is that some daily-user-card or you
>>> don't really have free machine? Of course I don't need that now, first
>>> we have to make PHY 2 support more complete. But maybe after
>>> Christmas/new year I could focus on that.
>>
>> I can't, unless I magically get a new laptop -- this card is built into
>> my macbook that I use all the time. I'd have a mostly-free machine, and
>> I don't use the card, but it's not a replacable part.
> 
> OK, I'll just think about buying some card :)

I sent a question to the seller of the card I mentioned earlier asking them to
tell me the PCI IDs and explaining why I needed to know. If they answer, we will
at least know if it is a 14e4:432b. If so, then it certainly will have a PHY rev
> 2. At that price, I'm willing to buy it myself, but there should be money
available to get things for Rafa?. Who has those funds? I think the last time I
got something though the donations, it was Stefano, but that was a long time ago.

Rafa?: If I get a rev > 2 card, you can certainly ssh into my computer for
testing, or I can do the runs here and send you the dumps.

Larry


Larry

Re: [PATCH 0/4] Make N-PHY support experimental

[Larry Finger]

On 12/09/2010 09:37 AM, Rafał Miłecki wrote:
> 2010/12/9 Johannes Berg <johannes@sipsolutions.net>:
>> On Thu, 2010-12-09 at 16:28 +0100, Rafał Miłecki wrote:
>>> I actually asked for some hardware donations on my blog and in news on
>>> polish portal, but didn't receive any serious offer.
>>
>> There probably are still money donations left to buy some ... ?
> 
> The problem I was afraid of was recognizing PHY revision without
> buying a card, just from looking at photos. It seems however, that
> will be the only solution.
> 
> 
>>> Johannes: is there any chance you could put this card in some machine
>>> I could get ssh access to? Or is that some daily-user-card or you
>>> don't really have free machine? Of course I don't need that now, first
>>> we have to make PHY 2 support more complete. But maybe after
>>> Christmas/new year I could focus on that.
>>
>> I can't, unless I magically get a new laptop -- this card is built into
>> my macbook that I use all the time. I'd have a mostly-free machine, and
>> I don't use the card, but it's not a replacable part.
> 
> OK, I'll just think about buying some card :)

I sent a question to the seller of the card I mentioned earlier asking them to
tell me the PCI IDs and explaining why I needed to know. If they answer, we will
at least know if it is a 14e4:432b. If so, then it certainly will have a PHY rev
> 2. At that price, I'm willing to buy it myself, but there should be money
available to get things for Rafał. Who has those funds? I think the last time I
got something though the donations, it was Stefano, but that was a long time ago.

Rafał: If I get a rev > 2 card, you can certainly ssh into my computer for
testing, or I can do the runs here and send you the dumps.

Larry


Larry

[PATCH 0/4] Make N-PHY support experimental

[Jon Saul]

On 12/09/2010 10:03 AM, Larry Finger wrote:
> I sent a question to the seller of the card I mentioned earlier asking them to
> tell me the PCI IDs and explaining why I needed to know. If they answer, we will
> at least know if it is a 14e4:432b. If so, then it certainly will have a PHY rev
>> 2. At that price, I'm willing to buy it myself, but there should be money
> available to get things for Rafa?. Who has those funds? I think the last time I
> got something though the donations, it was Stefano, but that was a long time ago.
>
> Rafa?: If I get a rev > 2 card, you can certainly ssh into my computer for
> testing, or I can do the runs here and send you the dumps.
>
> Larry
I have a 14e4:432b card and am willing to help any way I can.

-- 
0x00

Re: [PATCH 0/4] Make N-PHY support experimental

[Jon Saul]

On 12/09/2010 10:03 AM, Larry Finger wrote:
> I sent a question to the seller of the card I mentioned earlier asking them to
> tell me the PCI IDs and explaining why I needed to know. If they answer, we will
> at least know if it is a 14e4:432b. If so, then it certainly will have a PHY rev
>> 2. At that price, I'm willing to buy it myself, but there should be money
> available to get things for Rafał. Who has those funds? I think the last time I
> got something though the donations, it was Stefano, but that was a long time ago.
>
> Rafał: If I get a rev > 2 card, you can certainly ssh into my computer for
> testing, or I can do the runs here and send you the dumps.
>
> Larry
I have a 14e4:432b card and am willing to help any way I can.

-- 
0x00

[PATCH 0/4] Make N-PHY support experimental

[Larry Finger]

On 12/09/2010 09:52 PM, Jon Saul wrote:
> On 12/09/2010 10:03 AM, Larry Finger wrote:
>> I sent a question to the seller of the card I mentioned earlier asking them to
>> tell me the PCI IDs and explaining why I needed to know. If they answer, we will
>> at least know if it is a 14e4:432b. If so, then it certainly will have a PHY rev
>>> 2. At that price, I'm willing to buy it myself, but there should be money
>> available to get things for Rafa?. Who has those funds? I think the last time I
>> got something though the donations, it was Stefano, but that was a long time ago.
>>
>> Rafa?: If I get a rev > 2 card, you can certainly ssh into my computer for
>> testing, or I can do the runs here and send you the dumps.
>>
>> Larry
> I have a 14e4:432b card and am willing to help any way I can.

Thanks for the offer. I bought one that should have those ID values on Ebay
today. If it is not a 432b, or some other N PHY with rev > 2, I have the right
to return it. The seller did not know the IDs. In that case, I will contact you
to see what we can arrange.

Larry

Re: [PATCH 0/4] Make N-PHY support experimental

[Larry Finger]

On 12/09/2010 09:52 PM, Jon Saul wrote:
> On 12/09/2010 10:03 AM, Larry Finger wrote:
>> I sent a question to the seller of the card I mentioned earlier asking them to
>> tell me the PCI IDs and explaining why I needed to know. If they answer, we will
>> at least know if it is a 14e4:432b. If so, then it certainly will have a PHY rev
>>> 2. At that price, I'm willing to buy it myself, but there should be money
>> available to get things for Rafał. Who has those funds? I think the last time I
>> got something though the donations, it was Stefano, but that was a long time ago.
>>
>> Rafał: If I get a rev > 2 card, you can certainly ssh into my computer for
>> testing, or I can do the runs here and send you the dumps.
>>
>> Larry
> I have a 14e4:432b card and am willing to help any way I can.

Thanks for the offer. I bought one that should have those ID values on Ebay
today. If it is not a 432b, or some other N PHY with rev > 2, I have the right
to return it. The seller did not know the IDs. In that case, I will contact you
to see what we can arrange.

Larry

[PATCH 0/4] Make N-PHY support experimental

[Rafał Miłecki]

2010/12/9 Larry Finger <Larry.Finger@lwfinger.net>:
> I am willing to buy a higher PHY rev device for testing. Any idea what is in a
> 4324A-BRCM1036? See
> http://cgi.ebay.com/Broadcom-Mini-PCI-e-802-11-a-b-g-n-Wireless-Card-/190477425068?pt=LH_DefaultDomain_0&hash=item2c5956d9ac.

Shipping to: United States

:(

-- 
Rafa?

Re: [PATCH 0/4] Make N-PHY support experimental

[Rafał Miłecki]

2010/12/9 Larry Finger <Larry.Finger@lwfinger.net>:
> I am willing to buy a higher PHY rev device for testing. Any idea what is in a
> 4324A-BRCM1036? See
> http://cgi.ebay.com/Broadcom-Mini-PCI-e-802-11-a-b-g-n-Wireless-Card-/190477425068?pt=LH_DefaultDomain_0&hash=item2c5956d9ac.

Shipping to: United States

:(

-- 
Rafał

b43 N PHY status report

[Larry Finger]

Rafa?,

The N PHY driver is remarkably stable. So far, my link has been up for nearly 16
hours under normal conditions - I have not yet tried any stress tests. Other
than the PHY errors that you noted, my link has only reported 2 other unusual
events. I have had 3 "Deauthentication for reason 3" from which it recovered in
one try. Also logged are 9 instances of "RX: Packet size underrun (2)/Packet
dropped" events. Again, these caused no problems.

Larry

b43 N PHY status report

[Larry Finger]

Rafał,

The N PHY driver is remarkably stable. So far, my link has been up for nearly 16
hours under normal conditions - I have not yet tried any stress tests. Other
than the PHY errors that you noted, my link has only reported 2 other unusual
events. I have had 3 "Deauthentication for reason 3" from which it recovered in
one try. Also logged are 9 instances of "RX: Packet size underrun (2)/Packet
dropped" events. Again, these caused no problems.

Larry

b43 N PHY status report

[Peter Stuge]

Larry Finger wrote:
> The N PHY driver is remarkably stable.

Are there some N PHY MiniPCI cards? (Not Express.)


//Peter

b43 N PHY status report

[Larry Finger]

On 12/10/2010 10:57 AM, Peter Stuge wrote:
> Larry Finger wrote:
>> The N PHY driver is remarkably stable.
> 
> Are there some N PHY MiniPCI cards? (Not Express.)

On Ebay, Mini PCIe is the only format shown for 802.11n devices. There is one
listing in which a picture of the card is not shown, but I am not aware of any
other format.

Larry

b43 N PHY status report

[Peter Stuge]

Larry Finger wrote:
> > Are there some N PHY MiniPCI cards? (Not Express.)
> 
> On Ebay, Mini PCIe is the only format shown for 802.11n devices.
> There is one listing in which a picture of the card is not shown,
> but I am not aware of any other format.

There are reference designs:

http://www.broadcom.com/products/Wireless-LAN/802.11-Wireless-LAN-Solutions/BCM94321MP
http://www.broadcom.com/products/Wireless-LAN/802.11-Wireless-LAN-Solutions/BCM94322MP

..so hopefully also some cards in a corner of the world..

Auction from November:

http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=270634152387
http://cgi.ebay.co.uk/ws/eBayISAPI.dll?VISuperSize&item=270634152387

The silkscreen says 2008 so maybe some more can still be found,
although Google doesn't find any.


//Peter

b43 N PHY status report

[Peter Stuge]

Peter Stuge wrote:
> Auction from November:
> 
> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=270634152387

Make that
http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=270634152387


> http://cgi.ebay.co.uk/ws/eBayISAPI.dll?VISuperSize&item=270634152387

and
http://i.ebayimg.com/16/!B2kGntQBGk~$(KGrHqR,!iIE)qvw8QW3BMjCQu1iiw~~_3.JPG


//Peter

b43 N PHY status report

[Rafał Miłecki]

2010/12/10 Peter Stuge <peter@stuge.se>:
> Peter Stuge wrote:
>> Auction from November:
>>
>> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=270634152387
>
> Make that
> http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=270634152387
>
>
>> http://cgi.ebay.co.uk/ws/eBayISAPI.dll?VISuperSize&item=270634152387
>
> and
> http://i.ebayimg.com/16/!B2kGntQBGk~$(KGrHqR,!iIE)qvw8QW3BMjCQu1iiw~~_3.JPG

I've got a mail from user who unmounted his wireless card from Asus
WL-500W. This card is MiniPCI (not express!) and from all the specs I
can see this router is 802.11n. Also, this card has 3 antennas
connectors. One weird thing is that this card is labeled as BCM4312...

I asked for renting this card, it would be nice to test b43 to support
such a card as well.

-- 
Rafa?

b43 N PHY status report

[Larry Finger]

On 12/13/2010 11:00 AM, Rafa? Mi?ecki wrote:
> 
> I've got a mail from user who unmounted his wireless card from Asus
> WL-500W. This card is MiniPCI (not express!) and from all the specs I
> can see this router is 802.11n. Also, this card has 3 antennas
> connectors. One weird thing is that this card is labeled as BCM4312...
> 
> I asked for renting this card, it would be nice to test b43 to support
> such a card as well.

Ebay has the MiniPCI card from an Asus WL-500W for a "buy now" price of $34.99
US. The photo clearly shows the Broadcom logo on a chip.

Who is in charge of the funds that were donated to the b43 project? This item
should be purchased for Rafal.

Larry

b43 N PHY status report

[Rafał Miłecki]

W dniu 13 grudnia 2010 18:41 u?ytkownik Larry Finger
<Larry.Finger@lwfinger.net> napisa?:
> On 12/13/2010 11:00 AM, Rafa? Mi?ecki wrote:
>>
>> I've got a mail from user who unmounted his wireless card from Asus
>> WL-500W. This card is MiniPCI (not express!) and from all the specs I
>> can see this router is 802.11n. Also, this card has 3 antennas
>> connectors. One weird thing is that this card is labeled as BCM4312...
>>
>> I asked for renting this card, it would be nice to test b43 to support
>> such a card as well.
>
> Ebay has the MiniPCI card from an Asus WL-500W for a "buy now" price of $34.99
> US. The photo clearly shows the Broadcom logo on a chip.
>
> Who is in charge of the funds that were donated to the b43 project? This item
> should be purchased for Rafal.

I actually got some donations from Polish users, plus I should get
that card rented from user I mentioned a littler earlier.

The bad part is that I'll probably have to return that card after few
months. But do we need that card for long long future, how do you
think?

-- 
Rafa?

b43 N PHY status report

[Larry Finger]

On 12/13/2010 12:17 PM, Rafa? Mi?ecki wrote:
> 
> I actually got some donations from Polish users, plus I should get
> that card rented from user I mentioned a littler earlier.
> 
> The bad part is that I'll probably have to return that card after few
> months. But do we need that card for long long future, how do you
> think?

Depending on the chip model, a few months should be sufficient. If you find that
you need one longer, we should be able to find one for purchase.

Larry

b43 N PHY status report

[Peter Stuge]

Larry Finger wrote:
> Ebay has the MiniPCI card from an Asus WL-500W for a "buy now"
> price of $34.99 US.

More than one available?


//Peter

b43 N PHY status report

[Larry Finger]

On 12/13/2010 12:34 PM, Peter Stuge wrote:
> Larry Finger wrote:
>> Ebay has the MiniPCI card from an Asus WL-500W for a "buy now"
>> price of $34.99 US.
> 
> More than one available?

No, just the one card by itself. There are a number of Asus WL-500W routers
ranging from $49.99 used to $121 new. The latter are in the UK.

Larry

b43 N PHY status report

[Francesco Gringoli]

On Dec 10, 2010, at 5:57 PM, Peter Stuge wrote:

> Larry Finger wrote:
>> The N PHY driver is remarkably stable.
> 
> Are there some N PHY MiniPCI cards? (Not Express.)
I searched a lot in the past and unfortunately I never found a mini-pci card with N-PHY. Cards installed in MacBook since 2007 (and I believe also in some Lenovo notebooks) have a different connector but I don't know what it is, maybe it's just another adapter for mini-pci-e.

Would you mind reporting here if you will ever find mini-pci N-PHY?

Thanks,
-Francesco


Informativa sulla privacy: http://help.ing.unibs.it/privacy.php

b43 N PHY status report

[Francesco Gringoli]

On Dec 8, 2010, at 4:15 PM, Larry Finger wrote:

> Rafa?,
> 
> The N PHY driver is remarkably stable. So far, my link has been up for nearly 16
> hours under normal conditions - I have not yet tried any stress tests. Other
> than the PHY errors that you noted, my link has only reported 2 other unusual
> events. I have had 3 "Deauthentication for reason 3" from which it recovered in
> one try. Also logged are 9 instances of "RX: Packet size underrun (2)/Packet
> dropped" events. Again, these caused no problems.
Hi Rafa?,

I confirm Larry's feedbacks. I tried both on a 32bit and a 64bit architectures (the first is frodo), and it works. I too see only CCK packets. On 64bit arch (Atom) it works but when I try to unload the module I get this

[ 1117.516031] unregister_netdevice: waiting for wlan1 to become free. Usage count = 1

and the device is never release (by who?). I have to reboot.

I'm using two cards, one reports

[  311.439406] b43-phy0: Broadcom 4321 WLAN found (core revision 12)
[  311.480046] b43-phy0 debug: Found PHY: Analog 5, Type 4, Revision 2
[  311.480075] b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2055, Revision 4

The other (an Apple original card) reports

[   82.726931] b43-phy0: Broadcom 4321 WLAN found (core revision 11)
[   82.768030] b43-phy0 debug: Found PHY: Analog 5, Type 4, Revision 1
[   82.768062] b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2055, Revision 4

Thanks,
-Francesco


Informativa sulla privacy: http://help.ing.unibs.it/privacy.php

Re: b43 N PHY status report

[Francesco Gringoli]

On Dec 8, 2010, at 4:15 PM, Larry Finger wrote:

> Rafał,
> 
> The N PHY driver is remarkably stable. So far, my link has been up for nearly 16
> hours under normal conditions - I have not yet tried any stress tests. Other
> than the PHY errors that you noted, my link has only reported 2 other unusual
> events. I have had 3 "Deauthentication for reason 3" from which it recovered in
> one try. Also logged are 9 instances of "RX: Packet size underrun (2)/Packet
> dropped" events. Again, these caused no problems.
Hi Rafał,

I confirm Larry's feedbacks. I tried both on a 32bit and a 64bit architectures (the first is frodo), and it works. I too see only CCK packets. On 64bit arch (Atom) it works but when I try to unload the module I get this

[ 1117.516031] unregister_netdevice: waiting for wlan1 to become free. Usage count = 1

and the device is never release (by who?). I have to reboot.

I'm using two cards, one reports

[  311.439406] b43-phy0: Broadcom 4321 WLAN found (core revision 12)
[  311.480046] b43-phy0 debug: Found PHY: Analog 5, Type 4, Revision 2
[  311.480075] b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2055, Revision 4

The other (an Apple original card) reports

[   82.726931] b43-phy0: Broadcom 4321 WLAN found (core revision 11)
[   82.768030] b43-phy0 debug: Found PHY: Analog 5, Type 4, Revision 1
[   82.768062] b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2055, Revision 4

Thanks,
-Francesco


Informativa sulla privacy: http://help.ing.unibs.it/privacy.php

b43 N PHY status report

[Johannes Berg]

On Fri, 2010-12-10 at 19:30 +0100, Francesco Gringoli wrote:

> [ 1117.516031] unregister_netdevice: waiting for wlan1 to become free. Usage count = 1
> 
> and the device is never release (by who?). I have to reboot.

That's a bug in the ipv6 code, upgrade your kernel :-)

johannes

Re: b43 N PHY status report

[Johannes Berg]

On Fri, 2010-12-10 at 19:30 +0100, Francesco Gringoli wrote:

> [ 1117.516031] unregister_netdevice: waiting for wlan1 to become free. Usage count = 1
> 
> and the device is never release (by who?). I have to reboot.

That's a bug in the ipv6 code, upgrade your kernel :-)

johannes

b43 N PHY status report

[Larry Finger]

On 12/10/2010 12:47 PM, Johannes Berg wrote:
> On Fri, 2010-12-10 at 19:30 +0100, Francesco Gringoli wrote:
> 
>> [ 1117.516031] unregister_netdevice: waiting for wlan1 to become free. Usage count = 1
>>
>> and the device is never release (by who?). I have to reboot.
> 
> That's a bug in the ipv6 code, upgrade your kernel :-)

I would not have seen that as IPv6 is disabled in my kernels.

Larry

Re: b43 N PHY status report

[Larry Finger]

On 12/10/2010 12:47 PM, Johannes Berg wrote:
> On Fri, 2010-12-10 at 19:30 +0100, Francesco Gringoli wrote:
> 
>> [ 1117.516031] unregister_netdevice: waiting for wlan1 to become free. Usage count = 1
>>
>> and the device is never release (by who?). I have to reboot.
> 
> That's a bug in the ipv6 code, upgrade your kernel :-)

I would not have seen that as IPv6 is disabled in my kernels.

Larry

b43 N PHY status report

[Gábor Stefanik]

On Fri, Dec 10, 2010 at 8:02 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 12/10/2010 12:47 PM, Johannes Berg wrote:
>> On Fri, 2010-12-10 at 19:30 +0100, Francesco Gringoli wrote:
>>
>>> [ 1117.516031] unregister_netdevice: waiting for wlan1 to become free. Usage count = 1
>>>
>>> and the device is never release (by who?). I have to reboot.
>>
>> That's a bug in the ipv6 code, upgrade your kernel :-)
>
> I would not have seen that as IPv6 is disabled in my kernels.

Are you serious? Disabling ipv6 with ipv4 exhaustion expected in January?

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



-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

Re: b43 N PHY status report

[Gábor Stefanik]

On Fri, Dec 10, 2010 at 8:02 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 12/10/2010 12:47 PM, Johannes Berg wrote:
>> On Fri, 2010-12-10 at 19:30 +0100, Francesco Gringoli wrote:
>>
>>> [ 1117.516031] unregister_netdevice: waiting for wlan1 to become free. Usage count = 1
>>>
>>> and the device is never release (by who?). I have to reboot.
>>
>> That's a bug in the ipv6 code, upgrade your kernel :-)
>
> I would not have seen that as IPv6 is disabled in my kernels.

Are you serious? Disabling ipv6 with ipv4 exhaustion expected in January?

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



-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

b43 N PHY status report

[Johannes Berg]

On Fri, 2010-12-10 at 20:04 +0100, G?bor Stefanik wrote:
> On Fri, Dec 10, 2010 at 8:02 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> > On 12/10/2010 12:47 PM, Johannes Berg wrote:
> >> On Fri, 2010-12-10 at 19:30 +0100, Francesco Gringoli wrote:
> >>
> >>> [ 1117.516031] unregister_netdevice: waiting for wlan1 to become free. Usage count = 1
> >>>
> >>> and the device is never release (by who?). I have to reboot.
> >>
> >> That's a bug in the ipv6 code, upgrade your kernel :-)
> >
> > I would not have seen that as IPv6 is disabled in my kernels.
> 
> Are you serious? Disabling ipv6 with ipv4 exhaustion expected in January?

Can we stop this thread right here and go on-topic again please?

johannes

Re: b43 N PHY status report

[Johannes Berg]

On Fri, 2010-12-10 at 20:04 +0100, Gábor Stefanik wrote:
> On Fri, Dec 10, 2010 at 8:02 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> > On 12/10/2010 12:47 PM, Johannes Berg wrote:
> >> On Fri, 2010-12-10 at 19:30 +0100, Francesco Gringoli wrote:
> >>
> >>> [ 1117.516031] unregister_netdevice: waiting for wlan1 to become free. Usage count = 1
> >>>
> >>> and the device is never release (by who?). I have to reboot.
> >>
> >> That's a bug in the ipv6 code, upgrade your kernel :-)
> >
> > I would not have seen that as IPv6 is disabled in my kernels.
> 
> Are you serious? Disabling ipv6 with ipv4 exhaustion expected in January?

Can we stop this thread right here and go on-topic again please?

johannes

b43 N PHY status report

[David Woodhouse]

On Fri, 2010-12-10 at 20:08 +0100, Johannes Berg wrote:
> On Fri, 2010-12-10 at 20:04 +0100, G?bor Stefanik wrote:
> > On Fri, Dec 10, 2010 at 8:02 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> > > On 12/10/2010 12:47 PM, Johannes Berg wrote:
> > >> On Fri, 2010-12-10 at 19:30 +0100, Francesco Gringoli wrote:
> > >>
> > >>> [ 1117.516031] unregister_netdevice: waiting for wlan1 to become free. Usage count = 1
> > >>>
> > >>> and the device is never release (by who?). I have to reboot.
> > >>
> > >> That's a bug in the ipv6 code, upgrade your kernel :-)
> > >
> > > I would not have seen that as IPv6 is disabled in my kernels.
> > 
> > Are you serious? Disabling ipv6 with ipv4 exhaustion expected in January?
> 
> Can we stop this thread right here and go on-topic again please?

On-topic:

Anyone working on or testing network device drivers should be using
IPv6. IPv6 will exercise code paths and network behaviour that Legacy IP
rarely does, in particular using multicast to do neighbour discovery.
And on wireless networks when multicast will be handled differently by
the AP, that makes more difference than on wired where it's mostly the
MAC filters that get neglected.

I've seen a number of broken drivers because their authors were only
testing with Legacy IP and not IPv6.

It's not hard to set up IPv6. Larry, if you need any pointers I'd be
more than happy to help.

-- 
dwmw2

Re: b43 N PHY status report

[David Woodhouse]

On Fri, 2010-12-10 at 20:08 +0100, Johannes Berg wrote:
> On Fri, 2010-12-10 at 20:04 +0100, Gábor Stefanik wrote:
> > On Fri, Dec 10, 2010 at 8:02 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> > > On 12/10/2010 12:47 PM, Johannes Berg wrote:
> > >> On Fri, 2010-12-10 at 19:30 +0100, Francesco Gringoli wrote:
> > >>
> > >>> [ 1117.516031] unregister_netdevice: waiting for wlan1 to become free. Usage count = 1
> > >>>
> > >>> and the device is never release (by who?). I have to reboot.
> > >>
> > >> That's a bug in the ipv6 code, upgrade your kernel :-)
> > >
> > > I would not have seen that as IPv6 is disabled in my kernels.
> > 
> > Are you serious? Disabling ipv6 with ipv4 exhaustion expected in January?
> 
> Can we stop this thread right here and go on-topic again please?

On-topic:

Anyone working on or testing network device drivers should be using
IPv6. IPv6 will exercise code paths and network behaviour that Legacy IP
rarely does, in particular using multicast to do neighbour discovery.
And on wireless networks when multicast will be handled differently by
the AP, that makes more difference than on wired where it's mostly the
MAC filters that get neglected.

I've seen a number of broken drivers because their authors were only
testing with Legacy IP and not IPv6.

It's not hard to set up IPv6. Larry, if you need any pointers I'd be
more than happy to help.

-- 
dwmw2

b43 N PHY status report

[Rafał Miłecki]

2010/12/21 David Woodhouse <dwmw2@infradead.org>:
> On Fri, 2010-12-10 at 20:08 +0100, Johannes Berg wrote:
>> On Fri, 2010-12-10 at 20:04 +0100, G?bor Stefanik wrote:
>> > On Fri, Dec 10, 2010 at 8:02 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>> > > On 12/10/2010 12:47 PM, Johannes Berg wrote:
>> > >> On Fri, 2010-12-10 at 19:30 +0100, Francesco Gringoli wrote:
>> > >>
>> > >>> [ 1117.516031] unregister_netdevice: waiting for wlan1 to become free. Usage count = 1
>> > >>>
>> > >>> and the device is never release (by who?). I have to reboot.
>> > >>
>> > >> That's a bug in the ipv6 code, upgrade your kernel :-)
>> > >
>> > > I would not have seen that as IPv6 is disabled in my kernels.
>> >
>> > Are you serious? Disabling ipv6 with ipv4 exhaustion expected in January?
>>
>> Can we stop this thread right here and go on-topic again please?
>
> On-topic:
>
> Anyone working on or testing network device drivers should be using
> IPv6. IPv6 will exercise code paths and network behaviour that Legacy IP
> rarely does, in particular using multicast to do neighbour discovery.
> And on wireless networks when multicast will be handled differently by
> the AP, that makes more difference than on wired where it's mostly the
> MAC filters that get neglected.
>
> I've seen a number of broken drivers because their authors were only
> testing with Legacy IP and not IPv6.
>
> It's not hard to set up IPv6. Larry, if you need any pointers I'd be
> more than happy to help.

I've router with OpenWRT, so that probably should be possible for me
to setup IPv6. However first I want to have working basic PHY and
radio configuration.

-- 
Rafa?

Re: b43 N PHY status report

[Rafał Miłecki]

2010/12/21 David Woodhouse <dwmw2@infradead.org>:
> On Fri, 2010-12-10 at 20:08 +0100, Johannes Berg wrote:
>> On Fri, 2010-12-10 at 20:04 +0100, Gábor Stefanik wrote:
>> > On Fri, Dec 10, 2010 at 8:02 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>> > > On 12/10/2010 12:47 PM, Johannes Berg wrote:
>> > >> On Fri, 2010-12-10 at 19:30 +0100, Francesco Gringoli wrote:
>> > >>
>> > >>> [ 1117.516031] unregister_netdevice: waiting for wlan1 to become free. Usage count = 1
>> > >>>
>> > >>> and the device is never release (by who?). I have to reboot.
>> > >>
>> > >> That's a bug in the ipv6 code, upgrade your kernel :-)
>> > >
>> > > I would not have seen that as IPv6 is disabled in my kernels.
>> >
>> > Are you serious? Disabling ipv6 with ipv4 exhaustion expected in January?
>>
>> Can we stop this thread right here and go on-topic again please?
>
> On-topic:
>
> Anyone working on or testing network device drivers should be using
> IPv6. IPv6 will exercise code paths and network behaviour that Legacy IP
> rarely does, in particular using multicast to do neighbour discovery.
> And on wireless networks when multicast will be handled differently by
> the AP, that makes more difference than on wired where it's mostly the
> MAC filters that get neglected.
>
> I've seen a number of broken drivers because their authors were only
> testing with Legacy IP and not IPv6.
>
> It's not hard to set up IPv6. Larry, if you need any pointers I'd be
> more than happy to help.

I've router with OpenWRT, so that probably should be possible for me
to setup IPv6. However first I want to have working basic PHY and
radio configuration.

-- 
Rafał

b43 N PHY status report

[Larry Finger]

On 12/21/2010 03:25 AM, David Woodhouse wrote:
> 
> On-topic:
> 
> Anyone working on or testing network device drivers should be using
> IPv6. IPv6 will exercise code paths and network behaviour that Legacy IP
> rarely does, in particular using multicast to do neighbour discovery.
> And on wireless networks when multicast will be handled differently by
> the AP, that makes more difference than on wired where it's mostly the
> MAC filters that get neglected.
> 
> I've seen a number of broken drivers because their authors were only
> testing with Legacy IP and not IPv6.
> 
> It's not hard to set up IPv6. Larry, if you need any pointers I'd be
> more than happy to help.

I have no problem setting it up. I disabled it mostly to reduce the number of
modules in a kernel recompile. It doesn't make much difference on either of my
multi-core boxes, but some of the lower-powered units already take hours to build.

I take your point, and will be reenabling IPv6.

Larry

Re: b43 N PHY status report

[Larry Finger]

On 12/21/2010 03:25 AM, David Woodhouse wrote:
> 
> On-topic:
> 
> Anyone working on or testing network device drivers should be using
> IPv6. IPv6 will exercise code paths and network behaviour that Legacy IP
> rarely does, in particular using multicast to do neighbour discovery.
> And on wireless networks when multicast will be handled differently by
> the AP, that makes more difference than on wired where it's mostly the
> MAC filters that get neglected.
> 
> I've seen a number of broken drivers because their authors were only
> testing with Legacy IP and not IPv6.
> 
> It's not hard to set up IPv6. Larry, if you need any pointers I'd be
> more than happy to help.

I have no problem setting it up. I disabled it mostly to reduce the number of
modules in a kernel recompile. It doesn't make much difference on either of my
multi-core boxes, but some of the lower-powered units already take hours to build.

I take your point, and will be reenabling IPv6.

Larry

b43 N PHY status report

[Konstantinos Karantias]

It's not been so stable on my BCM4312, but it's still stable. It can keep
the connection for ~3 hours here.

2010/12/8 Larry Finger <Larry.Finger@lwfinger.net>

> Rafa?,
>
> The N PHY driver is remarkably stable. So far, my link has been up for
> nearly 16
> hours under normal conditions - I have not yet tried any stress tests.
> Other
> than the PHY errors that you noted, my link has only reported 2 other
> unusual
> events. I have had 3 "Deauthentication for reason 3" from which it
> recovered in
> one try. Also logged are 9 instances of "RX: Packet size underrun
> (2)/Packet
> dropped" events. Again, these caused no problems.
>
> Larry
>
>
>
>
> _______________________________________________
> b43-dev mailing list
> b43-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/b43-dev
>



-- 
Blog: http://www.gtklocker.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20101210/6a7db86e/attachment.html>

b43 N PHY status report

[Larry Finger]

On 12/10/2010 12:53 PM, Konstantinos Karantias wrote:
> It's not been so stable on my BCM4312, but it's still stable. It can
> keep the connection for ~3 hours here.

Your BCM4312 probably has an LP PHY. We were reporting on the N PHY devices.

I have 2 LP PHY units - both stay connected although one of them gets "cookie
out of order" errors on occasion. Please report the exact details for your device.

Larry

Re: b43 N PHY status report

[Larry Finger]

On 12/10/2010 12:53 PM, Konstantinos Karantias wrote:
> It's not been so stable on my BCM4312, but it's still stable. It can
> keep the connection for ~3 hours here.

Your BCM4312 probably has an LP PHY. We were reporting on the N PHY devices.

I have 2 LP PHY units - both stay connected although one of them gets "cookie
out of order" errors on occasion. Please report the exact details for your device.

Larry

[PATCH 0/4] Make N-PHY support experimental

[Rafał Miłecki]

W dniu 7 grudnia 2010 23:57 u?ytkownik G?bor Stefanik
<netrolller.3d@gmail.com> napisa?:
> 2010/12/7 Rafa? Mi?ecki <zajec5@gmail.com>:
>> Finally, thanks for Larry and Francesco I got b43 working with BCM4328 chipset!
>
> Do you mean BCM4321 (14e4:4328)? BCM4328 is AFAIK handled by brcmfmac.

Yeah, I removed following hack some time ago:
-       } else if (bus->chip_id == 0x4321) {
-               /* the BCM4328 has a chipid == 0x4321 and a rev 4 SPROM */
and got lost what is my chipset. You're right.


-- 
Rafa?

Re: [PATCH 0/4] Make N-PHY support experimental

[Rafał Miłecki]

W dniu 7 grudnia 2010 23:57 użytkownik Gábor Stefanik
<netrolller.3d@gmail.com> napisał:
> 2010/12/7 Rafał Miłecki <zajec5@gmail.com>:
>> Finally, thanks for Larry and Francesco I got b43 working with BCM4328 chipset!
>
> Do you mean BCM4321 (14e4:4328)? BCM4328 is AFAIK handled by brcmfmac.

Yeah, I removed following hack some time ago:
-       } else if (bus->chip_id == 0x4321) {
-               /* the BCM4328 has a chipid == 0x4321 and a rev 4 SPROM */
and got lost what is my chipset. You're right.


-- 
Rafał