In http://bcm-specs.sipsolutions.net/APHYSetup/noise_scale_table in the table for G PHY Rev <= 2,
offset 13 has the value 0x1402, whereas bcm43xx_ilt.c has 0x1400 for the equivalent number. Is this
a typo in the driver or on the website?
Larry
___
Bcm
On Tuesday 27 June 2006 21:33, John W. Linville wrote:
> On Tue, Jun 27, 2006 at 06:31:01PM +0200, Michael Buesch wrote:
> > On Tuesday 27 June 2006 18:12, Jeff Garzik wrote:
> > > Michael Buesch wrote:
> > > > So, I will submit a patch to lower the udelay(10) to udelay(1)
> > > > and we can close
As many people don't seem to like the locking "obfuscation"
in the bcm43xx driver, this patch removes it.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h
===
--- wireless-2
On Tue, Jun 27, 2006 at 06:31:01PM +0200, Michael Buesch wrote:
> On Tuesday 27 June 2006 18:12, Jeff Garzik wrote:
> > Michael Buesch wrote:
> > > So, I will submit a patch to lower the udelay(10) to udelay(1)
> > > and we can close the discussion? ;)
> >
> > No, that totally avoids my point. Yo
On Tuesday 27 June 2006 20:15, Matej Cepl wrote:
> Hi,
[snip]
Known issue. Please wait until we have a fix.
It will be announced here on the list.
The fix is nontrivial, so be patient, please.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-
Hi,
I have here Dell Inspiron 2200 with internal wifi card which Dell
calls "Dell Wireless 1370 Internal Wireless (802.11b/g, 54Mbps)
for Inspiron 2200" and lspci claims that it is this (lines
broken for this message of course):
02:03.0 Network controller: Broadcom Corporation BCM4318 \
Johannes Berg wrote:
On Tue, 2006-06-27 at 12:49 -0500, Larry Finger wrote:
If anyone has a better value, please let me
know. The noise value is still the one calculated from the clean-room formula. On my system, this is
roughly -65 dBm, which seems too high. I would appreciate getting any idea
On Tue, 2006-06-27 at 12:49 -0500, Larry Finger wrote:
> If anyone has a better value, please let me
> know. The noise value is still the one calculated from the clean-room
> formula. On my system, this is
> roughly -65 dBm, which seems too high. I would appreciate getting any ideas
> regarding
This patch improves the statistics returned from bcm43xx_get_wireless_stats. The signal level comes
from smoothing the rssi value returned by the firmware. The quality value is a hack derived from the
smoothed rssi value and an assumed rssi_max of -25. If anyone has a better value, please let me
On Tuesday 27 June 2006 18:12, Jeff Garzik wrote:
> Michael Buesch wrote:
> > So, I will submit a patch to lower the udelay(10) to udelay(1)
> > and we can close the discussion? ;)
>
> No, that totally avoids my point. Your "otherwise idle machine" test is
> probably nowhere near worst case in t
On Tuesday 27 June 2006 18:10, Jeff Garzik wrote:
> Michael Buesch wrote:
> > On Tuesday 27 June 2006 16:11, Jeff Garzik wrote:
> >> Overall, bcm43xx is _really really bad_ about this sort of thing. Just
> >> grepping for udelay in bcm43xx_radio.c shows some of the worst
> >> offenders. bcm43xx
Microoptimization:
This reduces the udelay in bcm43xx_mac_suspend.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43
Microoptimization:
This reduces the udelay in bcm43xx_mac_suspend.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireles
On Tuesday 27 June 2006 16:11, Jeff Garzik wrote:
> Michael Buesch wrote:
> > On Tuesday 27 June 2006 04:27, Larry Finger wrote:
> >> Jeff Garzik wrote:
> >>> John W. Linville wrote:
> +assert(bcm->mac_suspended >= 0);
> +if (bcm->mac_suspended == 0) {
> +bcm43xx_powe
Florian,
Florian Fainelli wrote:
Hi Larry,
I posted recently that I had false reported signal values from 0 to -250 dBm
which are impossible for a Wi-Fi card, so I guess there must be something
wrong with the qdbm -> mw and mw -> qdbm calculations somewhere, probably
affecting the showed res
On Tuesday 27 June 2006 16:11, Jeff Garzik wrote:
> Michael Buesch wrote:
> > On Tuesday 27 June 2006 04:27, Larry Finger wrote:
> >> Jeff Garzik wrote:
> >>> John W. Linville wrote:
> +assert(bcm->mac_suspended >= 0);
> +if (bcm->mac_suspended == 0) {
> +bcm43xx_powe
Jeff Garzik wrote:
Michael Buesch wrote:
Short: Don't touch it. Fullstop.
Long: The delay will _never_ be exhausted. Actually the for-counter
is only there to not lock up the machine, if there is a Bug in the
driver. (__much__ easier debugging).
The loop will only iterate a few times, typicall
On Tuesday 27 June 2006 15:51, Florian Fainelli wrote:
> Hi Larry,
>
> I posted recently that I had false reported signal values from 0 to -250 dBm
> which are impossible for a Wi-Fi card, so I guess there must be something
> wrong with the qdbm -> mw and mw -> qdbm calculations somewhere, proba
On Tuesday 27 June 2006 15:54, Florian Fainelli wrote:
> Hi Michael,
>
> I think a lof of people will be happy with this patch. Is it because the
> netdev guys have not released a kind of "injection stack" that you don't want
> to make this patch go upstream, or because it implies a lot of possi
Hi Michael,
I think a lof of people will be happy with this patch. Is it because the
netdev guys have not released a kind of "injection stack" that you don't want
to make this patch go upstream, or because it implies a lot of possible
hackings with this patch enabled ?
Thanks in advance for yo
Hi Larry,
I posted recently that I had false reported signal values from 0 to -250 dBm
which are impossible for a Wi-Fi card, so I guess there must be something
wrong with the qdbm -> mw and mw -> qdbm calculations somewhere, probably
affecting the showed result (I guess with iwconfig ?).
So I
On Tuesday 27 June 2006 04:27, Larry Finger wrote:
> Jeff Garzik wrote:
> > John W. Linville wrote:
> >> +assert(bcm->mac_suspended >= 0);
> >> +if (bcm->mac_suspended == 0) {
> >> +bcm43xx_power_saving_ctl_bits(bcm, -1, 1);
> >> +bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BIT
22 matches
Mail list logo