Re: [PATCH] b43legacy: Do not select HW_RANDOM

2009-03-30 Thread Michael Buesch
On Monday 30 March 2009 03:50:47 Larry Finger wrote:
 Auto-depend on HW_RANDOM, rather than selecting it.
 This way the user has the choice to enable or disable HWRNG support.
 
 Signed-off-by: Larry Finger larry.fin...@lwfinger.net
 ---
 
 John, please queue for 2.6.31.
 
 
 
 Index: wireless-testing/drivers/net/wireless/b43legacy/Kconfig
 ===
 --- wireless-testing.orig/drivers/net/wireless/b43legacy/Kconfig
 +++ wireless-testing/drivers/net/wireless/b43legacy/Kconfig
 @@ -3,7 +3,6 @@ config B43LEGACY
   depends on SSB_POSSIBLE  MAC80211  WLAN_80211  HAS_DMA
   select SSB
   select FW_LOADER
 - select HW_RANDOM
   ---help---
 b43legacy is a driver for 802.11b devices from Broadcom (BCM4301 and
 BCM4303) and early model 802.11g chips (BCM4306 Ver. 2) used in the
 @@ -51,6 +50,13 @@ config B43LEGACY_RFKILL
   depends on B43LEGACY  (RFKILL = y || RFKILL = B43LEGACY)  
 RFKILL_INPUT  (INPUT_POLLDEV = y || INPUT_POLLDEV = B43LEGACY)
   default y
  
 +# This config option automatically enables b43 HW-RNG support,
 +# if the HW-RNG core is enabled.
 +config B43legacy_HWRNG
 + bool
 + depends on B43legacy  (HW_RANDOM = y || HW_RANDOM = B43legacy)
 + default y
 +
  config B43LEGACY_DEBUG
   bool Broadcom 43xx-legacy debugging
   depends on B43LEGACY
 
 

You also need to add #ifdefs to the code, don't you?

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


Re: [PATCH V2] b43legacy: Do not select HW_RANDOM

2009-03-30 Thread Michael Buesch
On Monday 30 March 2009 17:26:16 Larry Finger wrote:
 Auto-depend on HW_RANDOM, rather than selecting it.
 This way the user has the choice to enable or disable HWRNG support.
 
 Signed-off-by: Larry Finger larry.fin...@lwfinger.net
 ---
 
 John, please queue for 2.6.31.
 
 
 
 Index: wireless-testing/drivers/net/wireless/b43legacy/Kconfig
 ===
 --- wireless-testing.orig/drivers/net/wireless/b43legacy/Kconfig
 +++ wireless-testing/drivers/net/wireless/b43legacy/Kconfig
 @@ -3,7 +3,6 @@ config B43LEGACY
   depends on SSB_POSSIBLE  MAC80211  WLAN_80211  HAS_DMA
   select SSB
   select FW_LOADER
 - select HW_RANDOM
   ---help---
 b43legacy is a driver for 802.11b devices from Broadcom (BCM4301 and
 BCM4303) and early model 802.11g chips (BCM4306 Ver. 2) used in the
 @@ -51,6 +50,13 @@ config B43LEGACY_RFKILL
   depends on B43LEGACY  (RFKILL = y || RFKILL = B43LEGACY)  
 RFKILL_INPUT  (INPUT_POLLDEV = y || INPUT_POLLDEV = B43LEGACY)
   default y
  
 +# This config option automatically enables b43 HW-RNG support,
 +# if the HW-RNG core is enabled.
 +config B43legacy_HWRNG
 + bool
 + depends on B43legacy  (HW_RANDOM = y || HW_RANDOM = B43legacy)

It seems like the symbol is B43LEGACY (uppercase).
Can you also change the new symbol to B43LEGACY_HWRNG, just for consistency with
all other symbols?

 + default y
 +


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


Re: [PATCH] b43: Refresh RX poison on buffer recycling

2009-03-30 Thread Francesco Gringoli

On Mar 28, 2009, at 12:41 AM, Michael Buesch wrote:

 The RX buffer poison needs to be refreshed, if we recycle an RX  
 buffer,
 because it might be (partially) overwritten by some DMA operations.

 Cc: sta...@kernel.org
 Cc: Francesco Gringoli francesco.gring...@ing.unibs.it
 Signed-off-by: Michael Buesch m...@bu3sch.de

 ---

 Francesco, please stresstest this on top of the other patch that  
 adds poisoning.
Hi Michael,

great work! No more crashes with the two patches. I will continue  
stress testing anyway but it seems stable.

I have one more question: the hardware seems to allow frames that are  
longer than 2352 bytes. If we monitor the firmware during receiving we  
get up to 0x1005 bytes long frames. When such frames arrives, the  
kernel drops them as the The data did not fit into one descriptor  
buffer and is split over multiple buffers. I tried to increase  
B43_DMA0_RX_BUFFERSIZE up to 0x1006 but I get problems with dma and  
the driver keeps restarting the hardware forever. What is wrong with  
increasing this value above IEEE80211_MAX_FRAME_LEN?

Many thanks,
Cheers
-FG



 John, please queue as bugfix.


 Index: wireless-testing/drivers/net/wireless/b43/dma.c
 ===
 --- wireless-testing.orig/drivers/net/wireless/b43/dma.c  2009-03-27  
 23:15:36.0 +0100
 +++ wireless-testing/drivers/net/wireless/b43/dma.c   2009-03-27  
 23:30:17.0 +0100
 @@ -1503,20 +1503,16 @@ static void dma_rx(struct b43_dmaring *r
   len = le16_to_cpu(rxhdr-frame_len);
   } while (len == 0  i++  5);
   if (unlikely(len == 0)) {
 - /* recycle the descriptor buffer. */
 - sync_descbuffer_for_device(ring, meta-dmaaddr,
 -ring-rx_buffersize);
 - goto drop;
 + dmaaddr = meta-dmaaddr;
 + goto drop_recycle_buffer;
   }
   }
   if (unlikely(b43_rx_buffer_is_poisoned(ring, skb))) {
   /* Something went wrong with the DMA.
* The device did not touch the buffer and did not overwrite 
 the  
 poison. */
   b43dbg(ring-dev-wl, DMA RX: Dropping poisoned buffer.\n);
 - /* recycle the descriptor buffer. */
 - sync_descbuffer_for_device(ring, meta-dmaaddr,
 -ring-rx_buffersize);
 - goto drop;
 + dmaaddr = meta-dmaaddr;
 + goto drop_recycle_buffer;
   }
   if (unlikely(len  ring-rx_buffersize)) {
   /* The data did not fit into one descriptor buffer
 @@ -1530,6 +1526,7 @@ static void dma_rx(struct b43_dmaring *r
   while (1) {
   desc = ops-idx2desc(ring, *slot, meta);
   /* recycle the descriptor buffer. */
 + b43_poison_rx_buffer(ring, meta-skb);
   sync_descbuffer_for_device(ring, meta-dmaaddr,
  ring-rx_buffersize);
   *slot = next_slot(ring, *slot);
 @@ -1548,8 +1545,7 @@ static void dma_rx(struct b43_dmaring *r
   err = setup_rx_descbuffer(ring, desc, meta, GFP_ATOMIC);
   if (unlikely(err)) {
   b43dbg(ring-dev-wl, DMA RX: setup_rx_descbuffer() failed\n);
 - sync_descbuffer_for_device(ring, dmaaddr, ring-rx_buffersize);
 - goto drop;
 + goto drop_recycle_buffer;
   }

   unmap_descbuffer(ring, dmaaddr, ring-rx_buffersize, 0);
 @@ -1559,6 +1555,11 @@ static void dma_rx(struct b43_dmaring *r
   b43_rx(ring-dev, skb, rxhdr);
 drop:
   return;
 +
 +drop_recycle_buffer:
 + /* Poison and recycle the RX buffer. */
 + b43_poison_rx_buffer(ring, skb);
 + sync_descbuffer_for_device(ring, dmaaddr, ring-rx_buffersize);
 }

 void b43_dma_rx(struct b43_dmaring *ring)

 -- 
 Greetings, Michael.

---

Francesco Gringoli, PhD - Assistant Professor
Dept. of Electrical Engineering for Automation
University of Brescia
via Branze, 38
25123 Brescia
ITALY

Ph:  ++39.030.3715843
FAX: ++39.030.380014
WWW: http://www.ing.unibs.it/~gringoli




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


Re: [PATCH] b43: Refresh RX poison on buffer recycling

2009-03-30 Thread Michael Buesch
On Monday 30 March 2009 23:35:34 Francesco Gringoli wrote:
 I have one more question: the hardware seems to allow frames that are  
 longer than 2352 bytes. If we monitor the firmware during receiving we  
 get up to 0x1005 bytes long frames. When such frames arrives, the  
 kernel drops them as the The data did not fit into one descriptor  
 buffer and is split over multiple buffers. I tried to increase  
 B43_DMA0_RX_BUFFERSIZE up to 0x1006 but I get problems with dma and  
 the driver keeps restarting the hardware forever. What is wrong with  
 increasing this value above IEEE80211_MAX_FRAME_LEN?

Well... First thing is that I think the hardware wasn't ever
tested with frames IEEE80211_MAX_FRAME_LEN. So there might be silicon bugs.

The maximum number of bytes one descriptor can carry is 8191 bytes (not 
including
RX headers and padding. That's 30 bytes).

Third thing is that the buffer must not cross a page boundary. So that is
4096 bytes on most machines. So in practice the 4096 bytes boundary (minus 30 
bytes
for headers/padding) is upper bound for B43_DMA0_RX_BUFFERSIZE.

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


[PATCH V2] b43legacy: Do not select HW_RANDOM

2009-03-30 Thread Larry Finger
Auto-depend on HW_RANDOM, rather than selecting it.
This way the user has the choice to enable or disable HWRNG support.

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

John, please queue for 2.6.31.



Index: wireless-testing/drivers/net/wireless/b43legacy/Kconfig
===
--- wireless-testing.orig/drivers/net/wireless/b43legacy/Kconfig
+++ wireless-testing/drivers/net/wireless/b43legacy/Kconfig
@@ -3,7 +3,6 @@ config B43LEGACY
depends on SSB_POSSIBLE  MAC80211  WLAN_80211  HAS_DMA
select SSB
select FW_LOADER
-   select HW_RANDOM
---help---
  b43legacy is a driver for 802.11b devices from Broadcom (BCM4301 and
  BCM4303) and early model 802.11g chips (BCM4306 Ver. 2) used in the
@@ -51,6 +50,13 @@ config B43LEGACY_RFKILL
depends on B43LEGACY  (RFKILL = y || RFKILL = B43LEGACY)  
RFKILL_INPUT  (INPUT_POLLDEV = y || INPUT_POLLDEV = B43LEGACY)
default y
 
+# This config option automatically enables b43 HW-RNG support,
+# if the HW-RNG core is enabled.
+config B43legacy_HWRNG
+   bool
+   depends on B43legacy  (HW_RANDOM = y || HW_RANDOM = B43legacy)
+   default y
+
 config B43LEGACY_DEBUG
bool Broadcom 43xx-legacy debugging
depends on B43LEGACY
Index: wireless-testing/drivers/net/wireless/b43legacy/b43legacy.h
===
--- wireless-testing.orig/drivers/net/wireless/b43legacy/b43legacy.h
+++ wireless-testing/drivers/net/wireless/b43legacy/b43legacy.h
@@ -596,9 +596,11 @@ struct b43legacy_wl {
/* Stats about the wireless interface */
struct ieee80211_low_level_stats ieee_stats;
 
+#ifdef CONFIG_B43legacy_RNG
struct hwrng rng;
u8 rng_initialized;
char rng_name[30 + 1];
+#endif
 
/* The RF-kill button */
struct b43legacy_rfkill rfkill;
Index: wireless-testing/drivers/net/wireless/b43legacy/main.c
===
--- wireless-testing.orig/drivers/net/wireless/b43legacy/main.c
+++ wireless-testing/drivers/net/wireless/b43legacy/main.c
@@ -2394,6 +2394,7 @@ static void b43legacy_security_init(stru
  dev-max_nr_keys - 8);
 }
 
+#ifdef CONFIG_B43legacy_HWRNG
 static int b43legacy_rng_read(struct hwrng *rng, u32 *data)
 {
struct b43legacy_wl *wl = (struct b43legacy_wl *)rng-priv;
@@ -2409,17 +2410,21 @@ static int b43legacy_rng_read(struct hwr
 
return (sizeof(u16));
 }
+#endif
 
 static void b43legacy_rng_exit(struct b43legacy_wl *wl)
 {
+#ifdef CONFIG_B43legacy_HWRNG
if (wl-rng_initialized)
hwrng_unregister(wl-rng);
+#endif
 }
 
 static int b43legacy_rng_init(struct b43legacy_wl *wl)
 {
-   int err;
+   int err = 0;
 
+#ifdef CONFIG_B43legacy_HWRNG
snprintf(wl-rng_name, ARRAY_SIZE(wl-rng_name),
 %s_%s, KBUILD_MODNAME, wiphy_name(wl-hw-wiphy));
wl-rng.name = wl-rng_name;
@@ -2433,6 +2438,7 @@ static int b43legacy_rng_init(struct b43
   number generator (%d)\n, err);
}
 
+#endif
return err;
 }
 
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev