This fixes a possible MMIO access while the device is still down
from a suspend cycle. MMIO accesses with the device powered down
may cause crashes on certain devices.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, please queue for 2.6.26
Index: wireless-testing/drivers/net
On Sunday 15 June 2008 20:20:27 Stefanik Gábor wrote:
On Sat, Jun 14, 2008 at 3:53 PM, Michael Buesch [EMAIL PROTECTED] wrote:
This firmware does _only_ work on wireless core revisions 5, 6, 7, 8 or 10.
There are reports of it working on rev.9 cores. Is that possible?
(Resend of previous
On Tuesday 17 June 2008 22:59:52 David Ellingsworth wrote:
I ran into this error today from a kernel I built last night based on
the latest wireless-testing branch. Correct me if I'm wrong, but it
looks to be b43legacy related. I'm a bit new to kernel debugging but
can try to provide
On Sunday 22 June 2008 18:59:59 Greg KH wrote:
On Fri, Jun 20, 2008 at 11:46:12AM +0200, Michael Buesch wrote:
This fixes a possible NULL pointer dereference in an error path of the
DMA allocation error checking code.
Signed-off-by: Michael Buesch [EMAIL PROTECTED
On Sunday 22 June 2008 22:42:32 [EMAIL PROTECTED] wrote:
Mike Mohr wrote:
Please don't misunderstand the following comments.
English _is_ my second language but I will do my best to not
misunderstand the following comments. I hope you do the same.
...
If I wanted a commercial or spam
On Monday 23 June 2008 23:37:47 Larry Finger wrote:
(1) Is this a good idea?
yes
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
On Tuesday 24 June 2008 05:26:21 Larry Finger wrote:
Ram kumar wrote:
hi,
I would like to know whether Broadcomm new wlan+Bluetooth
BCM4325 module has linux driver support.
I couldn't see any information on the website as well as in this
This fixes a clobber of the skb that was introduced by the
tx_control-cb conversion patches.
This bug causes a crash when the skb destructor is invoked. That happens
on skb_orphan or skb_kfree.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, please apply this bugfix to 2.6.27
On Wednesday 25 June 2008 05:55:25 Pavel Roskin wrote:
On Tue, 2008-06-24 at 22:07 -0500, Larry Finger wrote:
I agree that ssb-sprom should be rewritten; however, before that is
done, we need to think carefully as to what variables should be
exposed for a user. For instance, should
On Wednesday 25 June 2008 21:07:33 Dale Walsh wrote:
If the receiver has the gain reduced then the S/N ratio and the
signal level decrease logarithmically so turning it up has merit
provided that the noise level does saturate the input signal because
in most front-ends is some kind of
On Thursday 26 June 2008 03:00:58 Dale Walsh wrote:
ssb-sprom -i minipci_sprom -o minipci_new_sprom --antgbg 0x88
So you seriously think that increasing the antenna gain value
in the sprom by about 34 dBi is doing any good?
Who in their right mind would attempt a 34dbi increase?
The
On Friday 27 June 2008 10:40:39 Dale Walsh wrote:
A 1db or 2db increase in input sensitivity is probably more than
enough to improve a cards performance if it lacks it and can
compensate for design changes in poorly designed cards, a 10db
increase is essentially an increase of 1000%
On Friday 27 June 2008 19:19:41 Stefanik Gábor wrote:
On Tue, May 20, 2008 at 6:24 PM, Stefanik Gábor [EMAIL PROTECTED] wrote:
Hi all,
One day I was testing monitor-while-operating, with wlan0 as the
managed interface and rtap0 as the monitor one, and found an
interesting bug: when I am
On Tuesday 01 July 2008 09:14:15 Lorenzo Nava wrote:
Hello,
I have a PC with 2 broadcom card installed on it. Here is the details
of the cards:
BCM4306 PCI card:
[ 16.748857] ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x04,
vendor 0x4243)
[ 16.748866] ssb: Core 1 found: IEEE
On Wednesday 02 July 2008 19:16:50 Andrew Morton wrote:
I don't think we need to fix this in 2.6.26 - I doubt if anyone uses
this driver on frv - it's mainly a make allmodconfig work on FRV
thing.
I fully agree.
--
Greetings Michael.
___
Never return TX_BUSY from op_tx. It doesn't make sense to return
TX_BUSY, if we can not transmit the packet.
Drop the packet and return TX_OK.
This will fix the resume hang.
Upstream commit is
66193a7cef2239bfd1b9b96e304770facf7a49c7
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: linux
Never return TX_BUSY from op_tx. It doesn't make sense to return
TX_BUSY, if we can not transmit the packet.
Drop the packet and return TX_OK.
Upstream commit is
eb803e419ca6be06ece2e42027bb4ebd8ec09f91
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: linux-2.6.25.6/drivers/net/wireless
This fixes a possible MMIO access while the device is still down
from a suspend cycle. MMIO accesses with the device powered down
may cause crashes on certain devices.
Upstream commit is
33598cf261e393f2b3349cb55509e358014bfd1f
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: linux
On Thursday 03 July 2008 08:35:23 Kalle Valo wrote:
Michael Buesch [EMAIL PROTECTED] writes:
+drop_packet:
+ /* We can not transmit this packet. Drop it. */
+ dev_kfree_skb_any(skb);
return NETDEV_TX_OK;
So no need to call ieee80211_tx_status() in this case? I'm just
curious
On Thursday 03 July 2008 18:30:18 Felipe Maya wrote:
Hi, I have applied this patch and i tested on a wl500gpv2 (BCM5354). The
following part disable the ethernet device. If this part of the patch is
restored the device work ok.
Well, I would say your architecture is pretty broken then.
This
On Thursday 03 July 2008 22:52:35 Michael Buesch wrote:
On Thursday 03 July 2008 18:30:18 Felipe Maya wrote:
Hi, I have applied this patch and i tested on a wl500gpv2 (BCM5354). The
following part disable the ethernet device. If this part of the patch is
restored the device work ok
On embedded devices we must not route the interrupts through
the PCI core, if our host-bus is not PCI.
Reported-by: Steve Brown [EMAIL PROTECTED]
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, If still possible, please queue for 2.6.26.
Index: wireless-testing/drivers/ssb
On Tuesday 08 July 2008 17:58:58 Steve Brown wrote:
I'll post the problem to linux-mips.
Please do so. This really is a DMA API issue. It's either using the masks
incorrectly, or ot should provide a function to set the coherent mask.
SSB does use The Right (TM) API. So it should not break, in
On Tuesday 22 July 2008 18:50:42 Stefanik Gábor wrote:
b43-phy0 ERROR: PHY transmission error
b43-phy0 ERROR: PHY transmission error
.
I've noticed, that it happens, when I move my PDA (I've tested it with
ASUS 696) to the neighbour room. There is no errors when PDA is near
On Thursday 24 July 2008 19:37:14 Artem Antonov wrote:
Here is attachment with my log, if it can help debugging :)
Hm, some chars in the file seem to be corrupted.
Anyway, thanks for this.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
On Thursday 24 July 2008, Artem Antonov wrote:
Here is attachment with my log, if it can help debugging :)
Ok, can you produce more of these errors?
What I'm most interested in is this SHM offset:
SHM-08f0: 00 00 00 00 19 00 53 00 08 42 00 00 c1 00 00 00 ..S..B..
This is an experimental attempt for fixing the currently-not-so-good
TX power adjustment.
This patch rewrites the algorithms to scale better. If there's no
TX traffic, the power will be checked against the desired values
every 15 seconds (can probably be lowered to 30 or 60 seconds now).
If there
On Saturday 26 July 2008 17:26:52 Michael Buesch wrote:
This is an experimental attempt for fixing the currently-not-so-good
TX power adjustment.
Hm, is anybody going to test this, or are there really no transmission
problems left? :)
But please note that current wireless-testing tree seems
On Tuesday 29 July 2008 00:51:42 Larry Finger wrote:
Michael Buesch wrote:
On Saturday 26 July 2008 17:26:52 Michael Buesch wrote:
This is an experimental attempt for fixing the currently-not-so-good
TX power adjustment.
Hm, is anybody going to test this, or are there really
On Wednesday 30 July 2008 19:31:00 Steve Brown wrote:
Guillermo Javier Nardoni wrote:
Hi guys, once again... Me.
I'm wandering if BCM43xx actually does support for virtual AP,
What i mean for VAP is to bradcast more than one SSID being in AP mode or
AdHoc mode
For example:
On Thursday 31 July 2008 13:47:45 Stefanik Gábor wrote:
On Wed, Jul 30, 2008 at 7:49 PM, Michael Buesch [EMAIL PROTECTED] wrote:
The firmware doesn't support that, out of the box. So we return
-EOPNOTSUPP
AFAIK Broadcom cards are softmac, so why do we depend on firmware
support for multi
On Thursday 31 July 2008 17:53:10 Steve Brown wrote:
The firmware doesn't support that, out of the box. So we return
-EOPNOTSUPP
I know that I'm horribly over simplifying this issue. That
notwithstanding, I hooked up wlcompat-debug. There about 50 calls to the
Broadcom driver to set
This is the first part for the rewrite of the b43 PHY API.
This is needed in order to make development of N and LP code possible.
PLEASE TEST TEST TEST TEST TEST
Lots of testing on lots of different devices is needed to ensure this
doesn't introduce regressions due to typos.
95% of the patch
On Monday 18 August 2008 09:41:10 Holger Schurig wrote:
I know, which is one of the reasons I don't use a Debian-based
distro. I want nothing to do with one whose stated goal is to
make it so difficult to change the kernel that the users won't
do it.
Huh? I use make install
On Sunday 17 August 2008 21:26:21 Ehud Gavron wrote:
Works fine here. iperf same results as prior to patch.
b43-phy0: Broadcom 4311 WLAN found
b43-phy0 debug: Found PHY: Analog 4, Type 2, Revision 8
b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2
Thanks a lot for
On Sunday 17 August 2008 23:33:48 Larry Finger wrote:
Thomas Ilnseher wrote:
Hi,
I got an asus WL520GU (with LP PHY).
Unfortunately, even the specs on bcm-v4 are quite incomplete yet.
Is there any ETA when specs are complete, when prelimanry support is added
(offset to previous
On Tuesday 19 August 2008 08:32:27 Rafał Miłecki wrote:
Checking your git Michael at
http://bu3sch.de/gitweb?p=b43-ucode.git;a=summary
I can see last update on 2008-07-22.
Just wanted to ask about status of this open source firmware. Are you
going to develop this anymore? Is there some
On Thursday 21 August 2008 00:40:32 Larry Finger wrote:
Michael Buesch wrote:
This is the first part for the rewrite of the b43 PHY API.
This is needed in order to make development of N and LP code possible.
PLEASE TEST TEST TEST TEST TEST
Lots of testing on lots of different
On Thursday 21 August 2008 00:45:06 Larry Finger wrote:
Only rev 1 and 2 ssb SPROMs have fields named et0mac and et1mac;
however, all of the extraction routines extract pseudo data for these
fields from regions that are all 1's resulting in a hardware address
of FF:FF:FF:FF:FF:FF. This patch
On Thursday 21 August 2008 18:16:23 Sean Hodges wrote:
On Sat, 2008-08-16 at 00:29 +0200, Michael Buesch wrote:
This is the first part for the rewrite of the b43 PHY API.
This is needed in order to make development of N and LP code possible.
PLEASE TEST TEST TEST TEST TEST
Lots
This patch improves the recalculation of the TX attenuations
for improved scaling of the TX power under load.
This should improve (reduce) the time it takes the RC algorithm
to find the best transmission rate.
It should also improve the scaling of the attenuations to changed
environment (moving
On Monday 25 August 2008 21:54:18 Michael Buesch wrote:
The patch is available here:
http://bu3sch.de/patches/wireless-testing/20080825-2146/patches/004-b43-NEW-rewrite-txpower-adjusting.patch
Here's an updated version with a major bug fixed:
http://bu3sch.de/patches/wireless-testing/20080825
-off-by: Michael Buesch [EMAIL PROTECTED]
---
Due to the size, this patch is not inlined.
Please find it here:
http://bu3sch.de/patches/wireless-testing/20080827-1750/patches/003-b43-phy-ops.patch
You may notice that after this patch is applied the file phy.c will
still contain some unused code
On Wednesday 27 August 2008 19:04:04 Celejar wrote:
On Mon, 25 Aug 2008 22:27:59 +0200
Michael Buesch [EMAIL PROTECTED] wrote:
On Monday 25 August 2008 21:54:18 Michael Buesch wrote:
The patch is available here:
http://bu3sch.de/patches/wireless-testing/20080825-2146/patches/004-b43
It is valid to pass gphy-rfatt and gphy-bbatt as rfatt and bbatt
pointer arguments to the function. So we have to use memmove for the
possibly overlapping memory areas.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, since we have new policies for bugfixes and I can't prove
a lot and confuses the rate control less.
It will also reduce the time it initially takes to tune to a new TX power
value. With the old algorithm it could take about 30 to 45 seconds to settle to
a new power value. This will happen in about two to four seconds now.
Signed-off-by: Michael Buesch
This moves the remaining code from phy.c to phy_a.c
phy.c is removed.
No functional change. Just moving code and removing dead code.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
Please queue for the next merge window.
Index: wireless-testing/drivers/net/wireless/b43/phy.c
This adds read/write phyops for the LP-PHY and LP-PHY radios.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, please queue for the next merge window.
Index: wireless-testing/drivers/net/wireless/b43/phy_lp.c
On Sunday 31 August 2008 14:47:33 Stefanik Gábor wrote:
On a related note, I think we should make b43 load
wl_apsta.o/wl_apsta_mimo.o directly, and cut out the firmware in the
memory, as the cut-out firmware files are illegal to distribute,
meaning that a distro can't include a ready-to-use
On Sunday 31 August 2008 15:08:49 Stefanik Gábor wrote:
On Sun, Aug 31, 2008 at 2:55 PM, Michael Buesch [EMAIL PROTECTED] wrote:
On Sunday 31 August 2008 14:47:33 Stefanik Gábor wrote:
On a related note, I think we should make b43 load
wl_apsta.o/wl_apsta_mimo.o directly, and cut out
This splits the PHY allocation from the PHY init.
This is needed in order to properly support Analog handling.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
Please queue for the next merge window.
Index: wireless-testing/drivers/net/wireless/b43/main.c
Replace a hardcoded Analog switch (which breaks on N-PHY) by a call to
the switch_analog PHY operation.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, please queue for the next merge window.
Index: wireless-testing/drivers/net/wireless/b43/main.c
b43 had a mechanism to set default QoS parameters. Somebody
removed it, because changes in mac80211 introduced compiler
warnings for it.
A Bug was introduced. Does somebody know which patch removed that
stuff, so I don't have to dig git history?
--
Greetings Michael.
On Thursday 04 September 2008 17:05:25 Artem Antonov wrote:
possible, this patch:
http://marc.info/?l=linux-wirelessm=121610942801688w=2
http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commitdiff;h=0b57664cf2393bc1eff594ff7e5ff26533843fe6
Ok, thanks. That's it.
On Saturday 06 September 2008 07:04:36 [EMAIL PROTECTED] wrote:
+}
+if (phy-rev = 2)
b43legacy_phy_write(dev, 0x047E, 0x0078);
}
Does this even compile?
--
Greetings Michael.
___
Bcm43xx-dev mailing list
This fixes the initialization of the default QoS parameters.
This got broken by 0b57664cf2393bc1eff594ff7e5ff26533843fe6
Reported-by: Lorenzo Nava
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, please queue for the next merge window, as I'm not interested
in finding explanations
It causes compile errors on m68k and it is not needed.
Remove it.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, please queue for the next merge window.
Index: wireless-testing/drivers/net/wireless/b43/phy_g.c
On Saturday 06 September 2008 20:07:15 [EMAIL PROTECTED] wrote:
correct these issues. I did see several other ways in which the code
does not match the specs. Should that be documented in the code or
should the code be conformed to the specs even if that ends up breaking
the driver?
On Saturday 06 September 2008 20:34:02 Larry Finger wrote:
A coding error present since b43legacy was incorporated into the
kernel has prevented the driver from using the rate-setting mechanism
of mac80211. The driver has been forced to remain at a 1 Mb/s rate.
Does version3 firmware have a
On Saturday 06 September 2008 20:52:53 Larry Finger wrote:
Michael Buesch wrote:
On Saturday 06 September 2008 20:34:02 Larry Finger wrote:
A coding error present since b43legacy was incorporated into the
kernel has prevented the driver from using the rate-setting mechanism
of mac80211
On Saturday 06 September 2008 20:57:50 Johannes Berg wrote:
On Sat, 2008-09-06 at 20:55 +0200, Michael Buesch wrote:
On Saturday 06 September 2008 20:52:53 Larry Finger wrote:
Michael Buesch wrote:
On Saturday 06 September 2008 20:34:02 Larry Finger wrote:
A coding error present
[EMAIL PROTECTED]
Cc: Stable [EMAIL PROTECTED][2.6.26], [2.6.25]
Reviewed-by: Michael Buesch [EMAIL PROTECTED]
---
John,
This is a bug, not a regression. I guess under the new rules that it
is 2.6.28 material.
I wonder what the -stable rules are.
It seems really screwed
On Sunday 07 September 2008 19:58:52 Artem Antonov wrote:
Hi!
This patch fixes hardware power control init. Now it works better :)
Hardware power control cannot work, as we don't implement major parts of it.
--- linux-2.6.27/drivers/net/wireless/b43/phy_g.c 2008-09-07
20:16:35.0
On Sunday 07 September 2008 06:30:00 [EMAIL PROTECTED] wrote:
(Please inline the patch next time.)
Acked-by: Michael Buesch [EMAIL PROTECTED]
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de
On Monday 08 September 2008 07:31:55 Greg KH wrote:
On Sun, Sep 07, 2008 at 12:40:04AM +0200, Michael Buesch wrote:
On Saturday 06 September 2008 23:51:22 Larry Finger wrote:
A coding error present since b43legacy was incorporated into the
kernel has prevented the driver from using
On Wednesday 10 September 2008 00:15:14 Lorenzo Nava wrote:
Hi everybody,
I worked with the QoS parameters trying to understand why, checking
them within the firmware, they don't seems to have the correct values
even if they were set correctly by the driver.
I think that there could be
On Wednesday 10 September 2008 15:18:07 Francesco Gringoli wrote:
Hi Michael,
we are collecting every kind of material about Broadcom board, too.
Could you please point out the document with such specifications?
http://bcm-v4.sipsolutions.net/802.11/QoS
I confirm what Lorenzo wrote:
Stay on list.
I'm not going to start another private thread for this.
In general, I avoid private threads most of the time and
barely answer them. There are so many people on the list
that can answer your questions.
On Wednesday 10 September 2008 17:50:33 Francesco Gringoli wrote:
The code is
On Wednesday 10 September 2008 21:42:57 Francesco Gringoli wrote:
Hello everybody,
we found a strange behavior problem with the b43 driver. We begin
investigating this when doing some access tests with several boards:
we discovered that the Broadcom boards usually acquire the channel
On Thursday 11 September 2008 05:37:48 Larry Finger wrote:
Lorenzo Nava wrote:
I'm not a reverse engineer, so I have no chance to check the original
code to agree (or not) with you.
Ok, the mail has Johannes in Cc. I hope that he can tell me if me and
Francesco are right or not.
On Thursday 11 September 2008 01:14:29 Peter Stuge wrote:
I'm looking at buying an HP laptop which HP claims has 4311AG wifi.
I like to use .11a whenever possible and was a little sad to see that
b43 doesn't support it.
I am curious about why. Just lack of resources, or something more
On Thursday 11 September 2008 15:24:02 Larry Finger wrote:
Lorenzo Nava wrote:
This fixes the initialization of QoS parameters.
Reported-by: Lorenzo Nava, Francesco Gringoli
Signed-off-by: Francesco Gringoli [EMAIL PROTECTED]
Acked-by: Larry Finger [EMAIL PROTECTED]
---
John,
On Monday 15 September 2008 21:43:06 Larry Finger wrote:
If the system is misconfigured with CONFIG_RFKILL set but CONFIG_RFKILL_INPUT
not set, the built-in radio LEDs will not work. In the current code, no
warning
is issued.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
This is
On Tuesday 16 September 2008 15:24:12 Hendrik Sattler wrote:
Zitat von Michael Buesch [EMAIL PROTECTED]:
This is wrong. Please do something like the following:
It maybe annoying that some people don't get that but
Reading the documentation of RFKILL_INPUT, is it impossible to have
On Tuesday 16 September 2008 16:32:29 Hendrik Sattler wrote:
Zitat von Michael Buesch [EMAIL PROTECTED]:
On Tuesday 16 September 2008 15:24:12 Hendrik Sattler wrote:
Zitat von Michael Buesch [EMAIL PROTECTED]:
This is wrong. Please do something like the following:
It maybe annoying
On Tuesday 16 September 2008 16:18:34 Larry Finger wrote:
Since commit bc19d6e0b74ef03a3baf035412c95192b54dfc6f entitled
b43/b43legacy: add RFKILL_STATE_HARD_BLOCKED support, the radio LED
no longer responds to rfkill switch events.
ATM, I do not have a fix, other than reversion of this
On Tuesday 16 September 2008 21:18:27 Carlos Corbacho wrote:
On Tuesday 16 September 2008 18:08:48 Larry Finger wrote:
I agree with Michael. From what I know, the only possible reason for
having [RFKILL_STATE_HARD_BLOCKED] would be if user space could
somehow affect the state of the
On Tuesday 16 September 2008 23:09:20 Matthew Garrett wrote:
Oh, hey, I suck. This one might stand a better chance of not falling
over.
diff --git a/drivers/net/wireless/b43/rfkill.c
b/drivers/net/wireless/b43/rfkill.c
index fec5645..991e318 100644
--- a/drivers/net/wireless/b43/rfkill.c
On Wednesday 17 September 2008 00:37:29 Henrique de Moraes Holschuh wrote:
On Tue, 16 Sep 2008, Michael Buesch wrote:
But I don't know how to tell the rfkill subsystem about the states and
rfkill_force_state(). Must NOT be called from within atomic contextes,
something I haven't got around
On Wednesday 17 September 2008 16:29:31 John W. Linville wrote:
On Wed, Sep 17, 2008 at 04:26:28PM +0200, Michael Buesch wrote:
On Wednesday 17 September 2008 00:37:29 Henrique de Moraes Holschuh wrote:
On Tue, 16 Sep 2008, Michael Buesch wrote:
But I don't know how to tell the rfkill
On Wednesday 17 September 2008 17:18:22 Henrique de Moraes Holschuh wrote:
On Wed, 17 Sep 2008, Michael Buesch wrote:
On Tuesday 16 September 2008 23:09:20 Matthew Garrett wrote:
Oh, hey, I suck. This one might stand a better chance of not falling
over.
diff --git a/drivers/net
On Thursday 18 September 2008 16:24:05 Henrique de Moraes Holschuh wrote:
On Thu, 18 Sep 2008, Larry Finger wrote:
The changes below, along with Henriques patch [PATCH] rfkill: update
LEDs for all state changes, and the reversion of commit bc19d6e make
the wireless LED toggle correctly.
On Thursday 18 September 2008 18:49:01 Larry Finger wrote:
Henrique de Moraes Holschuh wrote:
The problem is in the should.
Maybe something else than b43 (like firmware) changed the radio software
rfkill bit, and it does not match what mac80211 and userland requested
anymore.
On Thursday 18 September 2008 07:07:51 Larry Finger wrote:
Index: wireless-testing/drivers/net/wireless/b43/rfkill.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/rfkill.c
+++
On Thursday 18 September 2008 15:47:42 Larry Finger wrote:
Ivo van Doorn wrote:
Is dev-phy.radio_on set when mac80211 has send an instruction
to the driver to enable the radio (start() or config() callback)
or does it represent the key state in the hardware?
If it is something coming
On Thursday 18 September 2008 16:24:52 Ivo van Doorn wrote:
On Thursday 18 September 2008, Henrique de Moraes Holschuh wrote:
On Thu, 18 Sep 2008, Ivo van Doorn wrote:
If it is something coming from mac80211, then you do not want
to send a SOFT_BLOCKED event since that will cause all
On Thursday 18 September 2008 16:48:36 Henrique de Moraes Holschuh wrote:
On Thu, 18 Sep 2008, Ivo van Doorn wrote:
On Thursday 18 September 2008, Henrique de Moraes Holschuh wrote:
On Thu, 18 Sep 2008, Larry Finger wrote:
The changes below, along with Henriques patch [PATCH] rfkill:
On Thursday 18 September 2008 19:42:28 Ivo van Doorn wrote:
On Thursday 18 September 2008, Michael Buesch wrote:
On Thursday 18 September 2008 15:47:42 Larry Finger wrote:
Ivo van Doorn wrote:
Is dev-phy.radio_on set when mac80211 has send an instruction
to the driver to enable
On Thursday 18 September 2008 19:48:27 Ivo van Doorn wrote:
Well no actually, when the radio state (software rfkill state in your words)
No, radio state is _not_ software rfkill state in my words.
It's an independent state.
The actual physical radio state is a combined state of the two sw and hw
On Thursday 18 September 2008 20:10:35 Ivo van Doorn wrote:
On Thursday 18 September 2008, Michael Buesch wrote:
On Thursday 18 September 2008 19:48:27 Ivo van Doorn wrote:
Well no actually, when the radio state (software rfkill state in your
words)
No, radio state is _not_ software
On Thursday 18 September 2008 20:23:21 Ivo van Doorn wrote:
On Thursday 18 September 2008, Michael Buesch wrote:
On Thursday 18 September 2008 20:10:35 Ivo van Doorn wrote:
On Thursday 18 September 2008, Michael Buesch wrote:
On Thursday 18 September 2008 19:48:27 Ivo van Doorn wrote
On Friday 19 September 2008 21:47:38 Larry Finger wrote:
An additional BCM4306 has been found with the Bluetooth coexistence
SPROM coding error.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
John,
These devices work with bcm43xx, but not with b43. I'll let you
decide if this is a
On Saturday 20 September 2008 23:02:55 Johannes Berg wrote:
On Sat, 2008-09-20 at 13:59 -0700, Luis R. Rodriguez wrote:
On Sat, Sep 20, 2008 at 1:51 PM, Johannes Berg
[EMAIL PROTECTED] wrote:
On Sat, 2008-09-20 at 17:44 +0200, Michael Buesch wrote:
On Friday 19 September 2008 21:47:38
On Sunday 21 September 2008 10:42:40 LÉVAI Dániel wrote:
Hi!
I have this device in a laptop:
05:00.0 Network controller: Broadcom Corporation BCM94311MCG wlan
mini-PCI (rev 01)
I'm using linux kernel 2.6.26.5 with the b43 module. I'm trying to scan
for available aps. Here is what I
On Monday 22 September 2008 05:01:37 Henrique de Moraes Holschuh wrote:
As long as the drivers based on mac80211 still know it is rfkill they're
dealing with (i.e. as long as they will know they MUST NOT emit energy from
the transmitter when they're soft-blocked),
That's the only policy that
On Friday 26 September 2008 07:10:37 Larry Finger wrote:
Yet another BCM4306 card with the Bluetooth Coexistence SPROM programming
error has been found.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
John,
Owners of these cards keep crawling out of the woodwork. This is
2.6.28
On Friday 26 September 2008 22:27:11 Aurelien Jarno wrote:
For SSB_BUSTYPE_SSB type devices, we need to initialize dma_mask using
coherent_dma_mask so that calls to dma_set_mask() succeed.
This is a hack IMO and the mips DMA API should be fixed.
However, I can live with it and you can add my
On Friday 26 September 2008 23:09:26 Aurelien Jarno wrote:
On Fri, Sep 26, 2008 at 10:49:25PM +0200, Michael Buesch wrote:
On Friday 26 September 2008 22:27:11 Aurelien Jarno wrote:
For SSB_BUSTYPE_SSB type devices, we need to initialize dma_mask using
coherent_dma_mask so that calls
On Friday 26 September 2008 23:42:01 Aurelien Jarno wrote:
Anyway, as I said I'm fine with this.
Ok. In which tree do you think it should be merged?
I do not care. Just merge it through some way that does actually work
and doesn't delay it for a couple of months.
--
Greetings Michael.
On Saturday 27 September 2008 19:55:48 Steve Brown wrote:
FWIW: Last July, I posted this patch for dma_set_mask to the linux-mips
list. It never went anywhere.
Yeah thanks. That's the correct solution, IMO.
And I don't think it can even break anything. (Could probably
uncover hidden bugs,
1201 - 1300 of 1753 matches
Mail list logo
