On Wednesday 12 December 2007 19:50:11 Michael Buesch wrote:
This patch fixes the transmission problems introduced by
commit f04b3787bbce4567e28069a9ec97dcd804626ac7
I'm not sure if the dummy read is really required.
The old code does it. I think it can't hurt and can possibly
fix some
-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/b43/wa.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/wa.c 2007-12-11
01:08:40.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/wa.c
On Wednesday 12 December 2007 23:48:10 Robert Allerstorfer wrote:
Before starting wpa_supplicant:
[EMAIL PROTECTED] ~]# dmesg | egrep 'b43|ssb|wlan0|wmaster0'
ssb: SPROM revision 1 detected.
ssb: Sonics Silicon Backplane found on PCI device 0001:10:12.0
b43-phy0: Broadcom 4306 WLAN found
On Tuesday 11 December 2007 02:14:05 Brennan Ashton wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=412861
I downloaded the source for 2.6.23.8-63.fc8.src.rpm the package that
things started to stop working at, and could not find any part of this
patch applied, so at least for that bug it
problems (hardware bugs or whatever. Who knows).
Please test this.
NOT-signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/b43/wa.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/wa.c
Here are the antenna related fixes for the sprom.
--
Greetings Michael.
Index: wireless-2.6/drivers/ssb/pci.c
===
--- wireless-2.6.orig/drivers/ssb/pci.c 2007-12-09 21:35:20.0 +0100
+++ wireless-2.6/drivers/ssb/pci.c
On Monday 10 December 2007 18:08:12 Larry Finger wrote:
Ivo and Dmitry,
I have finally figured out why the b43 rfkill LED handling routine works on
some systems, and not on
others. It works as long as rfkill-input is built-in, or if the module is
loaded, but this module is
not
On Monday 10 December 2007 18:17:38 Michael Buesch wrote:
On Monday 10 December 2007 18:08:12 Larry Finger wrote:
Ivo and Dmitry,
I have finally figured out why the b43 rfkill LED handling routine works on
some systems, and not on
others. It works as long as rfkill-input is built
On Monday 10 December 2007 18:23:21 Larry Finger wrote:
This version of the rfkill switch patch is pretty straight forward. Please
comment on the dropping of wl-mutex before rfkill initialization. This is
the only way I could avoid the circular locking without a much earlier
rfkill
On Sunday 09 December 2007 09:01:26 John H. wrote:
no, i stopped using ndiswrapper a while back because I wanted to use
b43, but I did not have this issue then.
But ndiswrapper doesn't use mac80211, right?
Do you see this issue with other _mac80211_ drivers?
On Dec 8, 2007 2:35 PM, Michael
On Sunday 09 December 2007 12:31:40 Michael Gerdau wrote:
Can you send me the code you have? I am going to buy various N devices.
So I want to avoid duplicating work.
Yes, sure.
I'll do a bit of cleaning up and mail it to you (either tonight or
tomorrow).
I also have a few areas where
readable and adds a few comments, so non rocket scientists are
also able to understand what this address caching is all about.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/b43/b43.h
On Sunday 09 December 2007 00:22:19 Larry Finger wrote:
Michael Buesch wrote:
Hi Larry,
Do you have the data from a SPROM revision 4? I need a copy
to fix some things.
And do you know a device which includes a rev 4 SPROM?
I'd like to buy one.
The data from a program dump
On Tuesday 04 December 2007 14:51:50 Holger Schurig wrote:
It could also be the case that the opcodes on the website aren't
opcodes to a real CPU,
Broadcom calls this a Programmable State Machine.
But what is this all about? Why do you care what type of CPU this is?
Does this matter _at_
On Tuesday 04 December 2007 18:13:01 Stefano Brivio wrote:
If you could put your efforts on writing specs for firmware operation
(i.e. not the instruction set, but what exactly does the firmware do) or
writing an open firmware based upon the info I listed above (you can do
that, there's an
On Thursday 29 November 2007 22:06:54 Stefano Brivio wrote:
Fix calc_nrssi_slope() which caused PHY TX errors on devices containing a
802.11a PHY. The code is synced to v4 specs and relevant registers are
renamed accordingly.
Signed-off-by: Stefano Brivio [EMAIL PROTECTED]
---
That
On Thursday 29 November 2007 00:48:40 Larry Finger wrote:
Index: wireless-2.6/drivers/net/wireless/b43/rfkill.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/rfkill.c
+++ wireless-2.6/drivers/net/wireless/b43/rfkill.c
@@
On Tuesday 27 November 2007 22:22:22 Larry Finger wrote:
I'm wondering who causes this deadlock. registered should be false if
we are called back from rfkill_initialize, so it should return early before
the lock.
The following code has the competing lock:
static int
On Wednesday 28 November 2007 16:05:35 Larry Finger wrote:
Michael Buesch wrote:
So it's a lock dependency between rfkill-mutex and wl-mutex?
So, now comes the question that really matters. Who is the caller
of rfkill_toggle_radio, in the case where it crashes?
Here is the full dump
On Wednesday 28 November 2007 16:38:27 Larry Finger wrote:
Since addition of the rfkill callback, the LED associated with the off/on
switch on the radio has not worked because essential data in the rfkill
structure is missing. When that problem was fixed, difficulties in circular
locking
On Wednesday 28 November 2007 17:18:53 Larry Finger wrote:
Michael Buesch wrote:
On Wednesday 28 November 2007 16:38:27 Larry Finger wrote:
Since addition of the rfkill callback, the LED associated with the off/on
switch on the radio has not worked because essential data in the rfkill
On Wednesday 28 November 2007 17:41:42 Larry Finger wrote:
Michael Buesch wrote:
I think it's a different bug. The backtrace seems corrupted.
Can you try this patch? There is some circular locking in rfkill.
I still get circular locking. The dump is
Ok.
b43 init:
mutex_lock
On Monday 26 November 2007 23:15:53 Larry Finger wrote:
Based on the code in the rtx200 directories that has a call to
input_allocate_device() that was not
present in b43, I made a modification to drivers/net/wireless/b43/rfkill.c as
follows:
Index:
On Tuesday 27 November 2007 17:03:57 Larry Finger wrote:
Since addition of the rfkill callback, the LED associated with the off
switch on the radio has not worked because essential data in the rfkill
structure was missing. This hack adds the necessary data and places direct
calls to turn the
On Tuesday 27 November 2007 17:28:33 Larry Finger wrote:
Michael Buesch wrote:
On Tuesday 27 November 2007 17:03:57 Larry Finger wrote:
This is not how led triggers work.
You are shortcutting the whole thing here. So you could as well
remove the whole rfkill and LEDs code.
It just
On Tuesday 27 November 2007 19:33:41 Larry Finger wrote:
Ivo van Doorn wrote:
Hi,
On Monday 26 November 2007 23:15:53 Larry Finger wrote:
Based on the code in the rtx200 directories that has a call to
input_allocate_device() that was not
present in b43, I made a modification to
On Tuesday 27 November 2007 21:02:47 Larry Finger wrote:
Michael,
I'm getting a little closer. The problem I discovered now is that
b43_leds_init() was being called
before b43_rfkill_init(), which prevented registration of the radio LED.
Now, the LED is flashed
on for about 1 second,
On Monday 26 November 2007 02:26:38 Larry Finger wrote:
Michael and Ivo,
I have done a little looking into the problem of the radio LED not coming on,
and have found the
following:
1. The call-back routine b43_rfkill_soft_toggle() is called once. When
called, rfkill.registered is
zero
On Monday 26 November 2007 15:38:11 Larry Finger wrote:
The BCM94311MCG rev 02 chip has an 802.11 core with revision 13 and
has not been supported until now. The changes include the following:
(1) Add the 802.11 rev 13 device to the ssb_device_id table to load b43.
(2) Add PHY revision 9 to
On Monday 26 November 2007 17:00:06 Larry Finger wrote:
static int alloc_ringmemory(struct b43_dmaring *ring)
{
struct device *dev = ring-dev-dev-dev;
+ gfp_t flags = GFP_KERNEL;
+ /* The specs call for 4K buffers for 30- and 32-bit DMA with 4K
+ * alignment and 8K
From: Johannes Berg [EMAIL PROTECTED]
Sometimes it can be useful to see the FCS, especially when
bad-FCS frames are shown. Pass the FCS to mac80211 and let
it worry about snipping it off when required.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
Signed-off-by: Michael Buesch [EMAIL PROTECTED
On Friday 23 November 2007 06:36:55 Larry Finger wrote:
Michael Buesch wrote:
partially acked.
Though, I'm not quite sure yet why you remove that
address extension bits. The specs clearly say that they _are_ there.
And it makes sense to use them, as two bytes of the address are used
From: Johannes Berg [EMAIL PROTECTED]
When monitor mode is enabled, this will make b43 read out the
full 64-bit MAC time from the chip for each received packet.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
drivers/net/wireless/b43/b43.h
On Friday 23 November 2007 12:17:26 Johannes Berg wrote:
This patch makes fwcutter support only those files we know are working
and marks the other one unsupported. To allow developers to still work
with such files, an --unsupported command line option is added that
allows one to extract
On Wednesday 21 November 2007 22:38:12 Larry Finger wrote:
The BCM94311MCG rev 02 chip has an 802.11 core with revision 13 and
has not been supported until now. The changes include the following:
(1) Add the 802.11 rev 13 device to the ssb_device_id table to load b43.
(2) Add PHY revision 9
On Wednesday 21 November 2007 00:26:48 Rafael J. Wysocki wrote:
On Tuesday, 20 of November 2007, Michael Buesch wrote:
On Monday 19 November 2007 23:57:43 Rafael J. Wysocki wrote:
Having both drivers in 2.6.24 should help find out if
there's anything which should be ironed out with b43
On Wednesday 21 November 2007 14:59:27 John W. Linville wrote:
On Wed, Nov 21, 2007 at 12:26:48AM +0100, Rafael J. Wysocki wrote:
On Tuesday, 20 of November 2007, Michael Buesch wrote:
It is known for over a year now that b43 (aka bcm43xx-mac80211) is going
to
replace bcm43xx
On Monday 19 November 2007 23:36:44 Andreas Schwab wrote:
b43 still does not work at all on ppc.
This is absolutely _wrong_.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
On Monday 19 November 2007 23:57:43 Rafael J. Wysocki wrote:
Having both drivers in 2.6.24 should help find out if
there's anything which should be ironed out with b43/b43legacy, but right
now they are already working a lot better than bcm43xx, and they are more
stable. So I couldn't find
On Tuesday 20 November 2007 05:46:28 Larry Finger wrote:
[EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=9414
[EMAIL PROTECTED] changed:
What|Removed |Added
On Tuesday 20 November 2007 15:11:07 Andreas Schwab wrote:
Michael Buesch [EMAIL PROTECTED] writes:
On Monday 19 November 2007 23:36:44 Andreas Schwab wrote:
b43 still does not work at all on ppc.
This is absolutely _wrong_.
Of course it is wrong, but apparently the only way to get
On Tuesday 20 November 2007 16:09:27 Larry Finger wrote:
Andreas Schwab wrote:
Stefano Brivio [EMAIL PROTECTED] writes:
--- drivers/net/wireless/b43/main.c.orig2007-11-20
01:12:12.186524483 +0100
+++ drivers/net/wireless/b43/main.c 2007-11-20 01:12:34.922702865 +0100
@@
On Monday 19 November 2007 17:12:17 Stefano Brivio wrote:
Remove bcm43xx. Fix some left-over URLs and ifdefs in b43 and b43legacy
drivers.
Stefano, please send the fixes for b43 and b43legacy as a seperate
patch, as they have to go into 2.6.24.
--
Greetings Michael.
On Friday 16 November 2007 07:48:23 Larry Finger wrote:
Recent changes in ssb sprom handling break compilation. These two patches
fix the problem.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
John,
These two changes should be applied to the everything branch of wireless-2.6
ASAP.
On Thursday 15 November 2007 06:55:42 Larry Finger wrote:
This patch file will enable the usage of the b43 driver with the
BCM94311MCG wlan mini-PCI (rev 02), which has not been supported.
This PCIe card uses 64-bit DMA. Most of the changes were needed
to implement this mode. It has been
On Thursday 15 November 2007 16:02:48 Larry Finger wrote:
@@ -695,11 +687,12 @@ static int dmacontroller_setup(struct b4
b43_dma_write(ring, B43_DMA32_RXRING,
(ringbase ~SSB_DMA_TRANSLATION_MASK)
|
On Sunday 11 November 2007 10:27:03 Frank Lichtenheld wrote:
On Sat, Nov 10, 2007 at 05:27:43PM +0100, Michael Buesch wrote:
On Saturday 10 November 2007 16:25:33 John W. Linville wrote:
On Sat, Nov 10, 2007 at 04:14:03PM +0100, Michael Buesch wrote:
From: Frank Lichtenheld [EMAIL
in this function
Signed-off-by: Frank Lichtenheld [EMAIL PROTECTED]
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
drivers/net/wireless/b43/debugfs.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/b43/debugfs.c
b/drivers/net/wireless/b43
On Friday 09 November 2007 23:47:37 Larry Finger wrote:
Now that the radio is controlled by rfkill, there is a potential
difficulty in helping a new user get started, as it is unlikely
that they will have setup rfkill. This patch prints a message if
the interface is started with the hardware
On Saturday 10 November 2007 16:25:33 John W. Linville wrote:
On Sat, Nov 10, 2007 at 04:14:03PM +0100, Michael Buesch wrote:
From: Frank Lichtenheld [EMAIL PROTECTED]
inititalise ret to 0 to avoid the following bogus warning:
CC [M] drivers/net/wireless/b43/debugfs.o
drivers/net
interface stopped\n);
Acked-by: Michael Buesch [EMAIL PROTECTED]
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
This fixes the lowlevel bus access routines for
PCMCIA based devices.
There are still a few issues with register access sideeffects after
this patch. This will be addressed in a later patch.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-2.6/drivers/ssb/pcmcia.c
PCMCIA needs an additional step to request the IRQ.
No need to add code to release the IRQ here, as that's done
automatically in pcmcia_disable_device().
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/b43/pcmcia.c
Fix a sparse warning about a nonstatic function.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
Note that this patch might collide with Stefano's recently
sent patches. But it should be trivial enough to fix that.
Index: wireless-2.6/drivers/net/wireless/b43legacy/main.c
Fix dependencies for built-in b43.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
I thought that I already submitted this patch, but it's not in wireless-2.6.
Maybe it was lost somewhere inbetween us or I simply forgot to send it.
Stefano, can you check if this patch is already applied
Fix the initialization for PCMCIA devices.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/b43/pcmcia.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/pcmcia.c 2007-11-04
12:45
On Tuesday 06 November 2007 20:14:11 Larry Finger wrote:
This is patch 1 of 6.
The SPROM's for various devices utilizing the Sonics Silicon Backplane come
with various revisions. The Revision 2 SPROM inherited the data layout of 1,
and
Revision 3 inherited the layout of 2. The first
On Tuesday 06 November 2007 20:17:00 Larry Finger wrote:
Patch 6 of 6.
The old, now unused, data structures and SPROM extraction routines
are removed.
Signed-off-by: Larry Finger[EMAIL PROTECTED]
---
Index: wireless-2.6/include/linux/ssb/ssb.h
On Saturday 03 November 2007 16:19:46 Larry Finger wrote:
The BCM4328 has a revision 4 SPROM. The necessary changes to handle the
layout and different size of this revision are implemented. The size of
the SPROM is now stored in the ssb_bus struct and used from that location
whenever possible.
On Monday 05 November 2007 17:03:47 Larry Finger wrote:
u8 path_data0[SPROM_PATH_DATA_SIZE];
u8 path_data1 ...
where SPROM_PATH_DATA_SIZE = 0x26. Once we see how the data are used, it may
make more sense to have
these data be u16,
or even a union so that we can have it both
On Sunday 04 November 2007 18:36:26 Stefano Brivio wrote:
On Sun, 4 Nov 2007 18:25:05 +0100
Stefano Brivio [EMAIL PROTECTED] wrote:
Signed-off-by: Stefano Brivio [EMAIL PROTECTED]
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Cc: Michael Busch [EMAIL PROTECTED] instead, sorry
before register.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
Note that this has to be ported to b43legacy.
Some volunteers? :)
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net
Fix possible buffer overrun.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
We are searching a new b43legacy maintainer.
So if someone is interested in this job, please start with porting
this easy patch to b43legacy. ;)
Index: wireless-2.6/drivers/net/wireless/b43/debugfs.c
On Tuesday 30 October 2007 02:56:51 David Ellingsworth wrote:
If that is the case, then a proper fix would be to use two locks to protect
access to the status. One for allowing read access when no one is writing,
and another for allowing exclusive write access. In such a configuration you
On Sunday 28 October 2007 11:40:21 Johannes Berg wrote:
Please compile and load rc80211_simple.
rc80211_simple is so little code, can't we just compile it into mac80211
module and make it configurable only for EMBEDDED?
Yep, great idea. Let's make this default.
I will do a patch.
--
On Sunday 28 October 2007 13:59:01 Ralf Saalmueller wrote:
Hello to the dev team and thank you very much for your work.
First I like to tell: I have the firmware installed:
/lib/firmware/b43# ls
bcm43xx needs the old firmware files in /lib/firmware/bcm43xx_*.fw
--
Greetings Michael.
built into
the mac80211 module unless EMBEDDED is enabled in which case
it can be disabled (eg. if the wanted driver requires another
rate control algorithm.)
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
Acked-by: Michael Buesch [EMAIL PROTECTED]
--
Greetings Michael
Put all access to wl-current_dev under protection of the mutex.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Cc: Larry Finger [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers
Use the limits provided by mac80211.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Cc: Larry Finger [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/main.c
Use a consistent naming scheme for the ops.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Cc: Larry Finger [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43
wl-mutex might already be locked on initialization.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/b43/rfkill.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/rfkill.c 2007-10-27
13:28
We don't need the set_key callback, as we don't do hw crypto.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: linux-2.6/drivers/net/wireless/b43legacy/main.c
===
--- linux-2.6.orig/drivers/net/wireless/b43legacy/main.c
On Sunday 28 October 2007 22:50:12 Michael Gerdau wrote:
Hi,
I have a Dell XPS M1710 which sports a BCM4328. I have it working by means
of ndiswrapper but would have rather have it supported by the b43 module.
What could I do to help here ?
Note I never wrote a linux driver and am not
already be locked on initialization. Signed-off-by: Michael Buesch
[EMAIL PROTECTED] Index:
wireless-2.6/drivers/net/wireless/b43/rfkill.c
=== ---
wireless-2.6.orig/drivers/net/wireless/b43/rfkill.c 2007-10-27
13:28
On Monday 29 October 2007 01:06:51 David Ellingsworth wrote:
- mutex_lock(wl-mutex);
+ /* When RFKILL is registered, it will call back into this callback.
+ * wl-mutex will already be locked when this happens.
+ * So first trylock. On contention check if we are in initialization.
+ *
ssb must init after PCI but before the ssb drivers.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Cc: Christian Casteyde [EMAIL PROTECTED]
Fixes-bug: #9219
Index: wireless-2.6/drivers/ssb/main.c
===
--- wireless-2.6.orig/drivers
ssb must init after PCI but before the ssb drivers.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Cc: Christian Casteyde [EMAIL PROTECTED]
Fixes-bug: #9219
Index: wireless-2.6/drivers/ssb/main.c
===
--- wireless-2.6.orig/drivers
On Saturday 27 October 2007 23:56:39 evan foss wrote:
snip
ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x11, vendor 0x4243)
ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0A, vendor 0x4243)
ssb: Core 2 found: USB 1.1 Host (cc 0x817, rev 0x03, vendor 0x4243)
ssb: Core 3 found: PCI-E (cc
On Wednesday 24 October 2007 17:50:25 Larry Finger wrote:
Although I have resigned as maintainer, I am not leaving the project
entirely. My situation is that
I will not have access to a broadband connection for 3-4 months, and will
have to rely on dial-up
over a shared line. I will be able
On Tuesday 23 October 2007 22:12:01 Daniel Fiser wrote:
Hi everybody,
please, could someone instruct me, how to install b43 driver for my
broadcom bcm4318 device? I have found at linuxwireless.org that my device
is supported by b43 driver and I was glad of it, because I needn't to use
On Monday 22 October 2007 00:27:20 Larry Finger wrote:
All WPA encryption/decryption is done in software for bcm43xx, b43, and
b43legacy drivers.
b43 will do everything but tkip in hardware.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
On Thursday 18 October 2007 21:53:22 John W. Linville wrote:
On Wed, Oct 17, 2007 at 06:34:03PM +0200, Michael Buesch wrote:
The remaining warning in phy.c will be fixed later.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is the third time I submit
On Wednesday 17 October 2007 21:48:35 Артем Антонов wrote:
Hi!
I've tried b43 driver on openwrt.
Device - ASUS WL500-gP (bcm4318)
lspci -vv output:
00:02.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g]
802.11g Wireless LAN Controller (rev 02)
Subsystem: ASUSTeK
(Please stay on-list. I won't debug bugs in private anymore.
Doing this on list tends to result in fixes a _lot_ faster, as
a lot more people are involved).
On Thursday 18 October 2007 18:23:01 Артем Антонов wrote:
I've updated b44, but it didn't solve the problem.
PCI: fixing up bridge
This fixes a sparse warning.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/main.c 2007-10-17
20:02:21.0 +0200
The remaining warning in phy.c will be fixed later.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is the third time I submit this.
Is something wrong with this patch or did you simply forget to apply it?
Index: wireless-2.6/drivers/net/wireless/b43/pio.c
When rounding a relative timeout we need to use round_jiffies_relative().
Signed-off-by: Anton Blanchard [EMAIL PROTECTED]
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index c141a26..41049a4 100644
From: Adrian Bunk [EMAIL PROTECTED]
Initialize err in drivers/net/wireless/b43legacy/main.c::b43legacy_start()
in case of returning an uninitialized value.
Signed-off-by: WANG Cong [EMAIL PROTECTED]
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
drivers/net/wireless/b43/main.c |2
On Monday 15 October 2007 11:05:26 Richard Purdie wrote:
On Sun, 2007-10-14 at 11:42 +0200, Johannes Berg wrote:
On Sat, 2007-10-13 at 17:26 +0200, Michael Buesch wrote:
I also saw this sometimes, but I have absolutely no idea how that happens.
Someone any idea?
Nope, but adding
-by: Michael Buesch [EMAIL PROTECTED]
---
drivers/ssb/Kconfig |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux/drivers/ssb/Kconfig
===
--- linux.orig/drivers/ssb/Kconfig
+++ linux/drivers/ssb/Kconfig
@@ -22,7
-by: Michael Buesch [EMAIL PROTECTED]
---
drivers/ssb/Kconfig |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux/drivers/ssb/Kconfig
===
--- linux.orig/drivers/ssb/Kconfig
+++ linux/drivers/ssb/Kconfig
@@ -22,7
.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
Acked-by: Michael Buesch [EMAIL PROTECTED]
---
drivers/ssb/main.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
Index: linux-2.6/drivers/ssb/main.c
On Saturday 13 October 2007 10:17:30 Vitaly Bordug wrote:
phy1: Failed to select rate control algorithm
phy1: Failed to initialize rate control algorithm
That's nothing b43 or ssb related.
Compile and load the rc80211_simple module.
--
Greetings Michael.
On Saturday 13 October 2007 16:14:31 Vitaly Bordug wrote:
Hello Michael,
On Sat, 13 Oct 2007 10:24:47 +0200
Michael Buesch wrote:
On Saturday 13 October 2007 10:17:30 Vitaly Bordug wrote:
phy1: Failed to select rate control algorithm
phy1: Failed to initialize rate control algorithm
On Saturday 13 October 2007 18:23:33 Christian Hoffmann wrote:
Hi all,
I tried (I think) latest b43 driver on a bcm4318. It works quite well, but on
a series of connect/reconnect I had attached stack in dmesg.
Any idea?
Chris
FYI (normal dmesg output)
b43-phy0: Broadcom 4318 WLAN
On Wednesday 10 October 2007 16:51:38 Dmitry Torokhov wrote:
I don't think that broadcom driver should depend on RFKILL_INPUT...
RFKILL_INPUT is a default link between input and rfkill layers but it
is by no means a mandatory component.
I think proper dependency should be:
On Saturday 29 September 2007 18:52:48 David Woodhouse wrote:
Does this bit belong to your other patch?
I'm not sure what you are trying to ask.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
This was missing an address operator.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/b43/leds.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/leds.c 2007-09-29
12:44:08.0
On Tuesday 02 October 2007 22:20:53 John W. Linville wrote:
I'll just roll this into the b43: LED triggers support patch.
Yep, thanks a lot.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
Implement much easier and more lightweight locking for
the periodic work.
This also removes the last big busywait loop and replaces it
by a sleeping loop.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/b43/main.c
901 - 1000 of 1753 matches
Mail list logo
