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 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
On Wednesday 10 October 2007 16:30:35 Dmitry Torokhov wrote:
> Hi Michael,
>
> On 9/28/07, Michael Buesch <[EMAIL PROTECTED]> wrote:
> > This removes the direct call to rfkill on an rfkill event
> > and replaces it with an input device. This way userspace is also
&
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
https://lists.berlios.de/ma
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.000
On Saturday 29 September 2007 19:14:34 David Woodhouse wrote:
> On Sat, 2007-09-29 at 19:08 +0200, Michael Buesch wrote:
> > I'm not sure what you are trying to ask.
>
> The hunks I quoted don't seem relevant to the rfkill switch. They seem
> to be related to periodic
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
https://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/
This removes the direct call to rfkill on an rfkill event
and replaces it with an input device. This way userspace is also
notified about the event.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-2.6/drivers/net/wireless/b43/K
On Friday 28 September 2007 00:17:13 Larry Finger wrote:
> Michael Buesch wrote:
> >
> > Yeah, sure. But it's not useless. The other functionality is still
> > available.
> > I'll fix that. But in a seperate patch. No need to delay this one because
> &g
On Thursday 27 September 2007 23:23:45 Ivo van Doorn wrote:
> On Thursday 27 September 2007, Michael Buesch wrote:
> > On Thursday 27 September 2007 23:12:43 Ivo van Doorn wrote:
> > > On Thursday 27 September 2007, Michael Buesch wrote:
> > > > On Thursday 27 Septemb
On Thursday 27 September 2007 23:12:43 Ivo van Doorn wrote:
> On Thursday 27 September 2007, Michael Buesch wrote:
> > On Thursday 27 September 2007 22:54:44 Ivo van Doorn wrote:
> > > Hi,
> > >
> > > > @@ -2401,8 +2401,7 @@ static void b43_periodic_every1se
On Thursday 27 September 2007 22:54:44 Ivo van Doorn wrote:
> Hi,
>
> > @@ -2401,8 +2401,7 @@ static void b43_periodic_every1sec(struc
> > radio_hw_enable = b43_is_hw_radio_enabled(dev);
> > if (unlikely(dev->radio_hw_enable != radio_hw_enable)) {
> > dev->radio_hw_enable = rad
This adds full support for the RFKILL button and
the RFKILL LED trigger.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-2.6/drivers/net/wireless/b43/Kconfig
===
--- wireless-2.6.orig/drivers/net/wirele
Drive the LEDs through the generic LED triggers.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Cc: Larry Finger <[EMAIL PROTECTED]>
Index: wireless-2.6/drivers/net/wireless/b43/Kconfig
===
--- wireless-2.6.orig
The remaining warning in phy.c will be fixed later.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
---
It seems that this patch was lost somewhere, as all patches except
this one are applied to wireless-2.6. So here comes the resend. :P
Index: wireless-2.6/drivers/net/wireless/b43
that has confused some users has been
> changed to "Radio initialized".
>
> This patch is patterned after a similar change to b43 by Michael Buesch.
>
> Signed-off-by: Larry Finger <[EMAIL PROTECT
This adds support for turning the radio off in software.
That's useful in environments, where you don't want the RF
to radiate any signals, but don't want to bring the interface down.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Cc: Larry Finger <[EMAIL PROTECTE
This message is useless. Only report state changes.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Cc: Larry Finger <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/b43/main.c
===
--- wireless-dev.orig
On Thursday 20 September 2007, Larry Finger wrote:
> Michael Buesch wrote:
> > On Wednesday 19 September 2007 19:55:59 Larry Finger wrote:
> >> Michael Buesch wrote:
> >>> Also cleanup the code a bit and remove the inline.
> >>>
> >&g
On Wednesday 19 September 2007 19:55:59 Larry Finger wrote:
> Michael Buesch wrote:
> > Also cleanup the code a bit and remove the inline.
> >
> > Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
>
> > @@ -2214,7 +2229,7 @@ static int b43_chip_init(struct b4
On a PCI bus use ioreadX() and iowriteX().
We map the I/O space with pci_iomap(), so we must use the correct
accessor functions, too.
readX() and writeX() are not guaranteed to accept the cookie returned
from pci_iomap() (though, it currently works on most architectures).
Signed-off-by: Michael
Also cleanup the code a bit and remove the inline.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/b43/main.c
===
--- wireless-dev.orig/drivers/net/wireless/b43/main.c 2007-09-19
Also cleanup the code a bit and remove the inline.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/b43/main.c
===
--- wireless-dev.orig/drivers/net/wireless/b43/main.c 2007-09-19
This fixes all Sparse warnings in SSB.
No semantics change.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/ssb/b43_pci_bridge.c
===
--- wireless-dev.orig/drivers/ssb/b43_pci_bridge.c 2007
It's not required and the txpower adjustment must not be in atomic.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/b43/debugfs.c
===
--- wireless-dev.orig/drivers/net/w
The remaining warning in phy.c will be fixed later.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/b43/pio.c
===
--- wireless-dev.orig/drivers/net/wireless/b43/pio.c2007-09-19
On Wednesday 19 September 2007 05:00:52 Larry Finger wrote:
> Commit 4cf92a3c was submitted as a fix for bug #8686 at bugzilla.kernel.org
> (http://bugzilla.kernel.org/show_bug.cgi?id=8686). Unfortunately, the fix led
> to
> a new bug, reported by Yoshifuji Hideaki, that prevented association for
On Sunday 16 September 2007 12:17:50 Marcin Kosiba wrote:
> On Sunday 16 September 2007, Michael Buesch wrote:
> > On Sunday 16 September 2007 11:26:21 Marcin Kosiba wrote:
> > > On Sunday 16 September 2007, Larry Finger wrote:
> > > > The only switch associated wi
On Sunday 16 September 2007 11:26:21 Marcin Kosiba wrote:
> On Sunday 16 September 2007, Larry Finger wrote:
> > The only switch associated with any of the BCM cards that I know about is
> > the radio-enable switch. If that is what you need, it can only be
> > controlled externally. The software ca
On Sunday 16 September 2007 02:52:11 Larry Finger wrote:
> In b43legacy, the variable gmode is always set. With a BCM4306/2,
> a variable is needed to control the execution path through the PHY
> and radio initialization, otherwise there are attempts to read from
> invalid registers. On x86 platfor
On Sunday 16 September 2007 01:26:29 Larry Finger wrote:
> Michael Buesch wrote:
> >
> > There is no such thing as "connected".
> > The bit is called "gmode". Why do you change it back to the wrong name?
> > The V3 specs are simply _wrong_. It has n
On Saturday 15 September 2007 23:22:20 Larry Finger wrote:
> In b43legacy, the variable gmode is always set. With a BCM4306/2,
> and likely a BCM4301, a variable is needed to control the execution
> path through the PHY and radio initialization, otherwise there are
> attempts to read from invalid r
On Saturday 15 September 2007 23:01:56 Larry Finger wrote:
> I have generated and tested a patch that changes back to the old 'connected'
> variable. That will
> avoid the semantics argument and match the V3 specs.
There is no such thing as "connected".
The bit is called "gmode". Why do you chang
On Saturday 15 September 2007 21:12:04 Larry Finger wrote:
> Michael Buesch wrote:
> > On Saturday 15 September 2007 20:07:22 Larry Finger wrote:
> >> Your comments may be correct; however, the fact remains that with a rev 4
> >> BCM4306, the original code
> >>
On Saturday 15 September 2007 20:07:22 Larry Finger wrote:
> Your comments may be correct; however, the fact remains that with a rev 4
> BCM4306, the original code
> generates many, many machine checks on PPC architecture, and I get reads with
> all ones on i386
> indicating that the read is inva
On Saturday 15 September 2007 19:39:34 Larry Finger wrote:
> In b43, the variable gmode merely indicates whether the given core
> has a GPHY or a BPHY. In b43legacy, this is always true; however,
> on a BCM4306/2 it must be set only when the PHY is connected to the
> ssb backplane, otherwise, reads
On Saturday 15 September 2007 14:55:38 Michael Buesch wrote:
> On Saturday 15 September 2007 14:36:14 David Woodhouse wrote:
> > On Fri, 2007-09-14 at 16:19 -0500, Larry Finger wrote:
> > > --- wireless-dev.orig/drivers/net/wireless/b43legacy/xmit.c
> > > +++ wirele
On Saturday 15 September 2007 14:36:14 David Woodhouse wrote:
> On Fri, 2007-09-14 at 16:19 -0500, Larry Finger wrote:
> > --- wireless-dev.orig/drivers/net/wireless/b43legacy/xmit.c
> > +++ wireless-dev/drivers/net/wireless/b43legacy/xmit.c
> > @@ -125,10 +125,12 @@ void b43legacy_generate_plcp_hd
On Saturday 15 September 2007 00:12:00 Larry Finger wrote:
> Pavel Roskin wrote:
> > On Fri, 2007-09-14 at 23:33 +0200, Michael Buesch wrote:
> >
> >> - macstat = le32_to_cpu(rxhdr->mac_status);
> >> + macstat = le16_to_cpu(rxhdr->mac_status);
&
On Friday 14 September 2007 23:19:36 Larry Finger wrote:
> David Woodhouse wrote:
> > On Fri, 2007-09-14 at 14:05 -0500, Larry Finger wrote:
> >> Are you using DMA or PIO? I did find some PIO endian problems, but
> >> none with DMA so far.
> >
> > I don't know -- which probably means DMA, right? I
On Friday 14 September 2007 23:22:00 Larry Finger wrote:
> Michael Buesch wrote:
> > On Friday 14 September 2007 21:05:40 Larry Finger wrote:
> >> Are you using DMA or PIO? I did find some PIO endian problems,
> >
> > Where exactly?
>
> drivers/net/wire
On Friday 14 September 2007 21:05:40 Larry Finger wrote:
> Are you using DMA or PIO? I did find some PIO endian problems,
Where exactly?
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/li
On Friday 14 September 2007 13:08:18 David Woodhouse wrote:
> On Fri, 2007-09-14 at 12:56 +0200, Michael Buesch wrote:
> > Revisions < 5 are not supported by the driver.
>
> So there's no way to use this device with v4 firmware any more?
No. That's what b43legacy is
On Friday 14 September 2007 12:49:41 David Woodhouse wrote:
> On Fri, 2007-09-14 at 12:32 +0200, David Woodhouse wrote:
> > This device is basically identical to the one I handed to John in
> > Cambridge last week. How do I force the b43 driver to bind to it?
>
> This (and copying b0g0initvals2 f
On Sunday 09 September 2007 05:23:28 Sepherosa Ziehau wrote:
> On 9/8/07, Michael Buesch <[EMAIL PROTECTED]> wrote:
> > On Saturday 08 September 2007 13:45:53 Martin Langer wrote:
> > > On Sat, Sep 08, 2007 at 03:15:17PM +0800, Sepherosa Ziehau wrote:
> > > &g
size.
A few macros were also added to simplify adding new files.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Cc: Larry Finger <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/b43/debugfs.c
===
--- wirel
On Sunday 09 September 2007 13:53:51 Michael Buesch wrote:
> Index: wireless-dev/drivers/net/wireless/b43/main.c
> ===
> --- wireless-dev.orig/drivers/net/wireless/b43/main.c 2007-09-07
> 16:36:00.0 +0200
> +
The wq must be canceled later on rmmod. It's nonfatal, if
the wq runs on a device that's not started or down. It will
handle these cases.
But syncing in wireless_core_exit() will cause a deadlock with
the restart_work. (restart work cancels itself)
Signed-off-by: Michael Buesch <[EM
size.
A few macros were also added to simplify adding new files.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Cc: Larry Finger <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/b43/debugfs.c
===
--- wirel
On Sunday 09 September 2007 07:39:43 Larry Finger wrote:
> >> wmaster0: Selected rate control algorithm 'simple'
> >> wmaster0: Failed to initialize wep
> >> bcm43xx_mac80211: probe of ssb0:3 failed with error -12
>
> I don't know what this means. Michael?
-ENOMEM
--
Greetings Michael.
___
On Saturday 08 September 2007 13:45:53 Martin Langer wrote:
> On Sat, Sep 08, 2007 at 03:15:17PM +0800, Sepherosa Ziehau wrote:
> > Hi all,
> >
> > Would you consider relicense fwcutter under BSDL? The driver in
> > DragonFlyBSD depends on the firmware files produced by fwcutter and I
> > don't w
greatly reduced.
>
> [1] http://bugzilla.kernel.org/show_bug.cgi?id=8937
>
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
This version of the patch is
Acked-by: Michael Buesch <[EMAIL PROTECTED]>
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
On Tuesday 04 September 2007, Larry Finger wrote:
> A crash upon booting that is caused by bcm43xx has been reported [1] and
> found to be due to a work queue being reinitialized while work on that
> queue is still pending. This fix modifies the shutdown of work queues and
> prevents periodic work
On Tuesday 04 September 2007, Larry Finger wrote:
> Michael Buesch wrote:
> > This adds a debugfs file to dump all microcode registers.
> > Note that the dumping is racy, as microcode continues to run
> > while we loop over each register to dump it.
> >
> > Cc
On Tuesday 04 September 2007, Larry Finger wrote:
> >> --- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_sysfs.c
> >> +++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_sysfs.c
> >> @@ -327,8 +327,9 @@ static ssize_t bcm43xx_attr_phymode_stor
> >>goto out;
> >>}
> >>
> >> -
On Tuesday 04 September 2007, Larry Finger wrote:
> A crash upon booting that is caused by bcm43xx has been reported [1] and
> found to be due to a work queue being reinitialized while work on that
> queue is still pending. This fix modifies the shutdown of work queues and
> prevents periodic work
Drop packets for which the firmware was unable to decrypt it,
as we won't be able to decrypt them with the key, too.
Cc: Johannes Berg <[EMAIL PROTECTED]>
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wi
This adds a file to dump the SHM.
Note that SHM dumping is racy, as the microcode continues to run
while we dump the SHM.
Cc: Johannes Berg <[EMAIL PROTECTED]>
Cc: Larry Finger <[EMAIL PROTECTED]>
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev/driver
This adds a debugfs file to dump all microcode registers.
Note that the dumping is racy, as microcode continues to run
while we loop over each register to dump it.
Cc: Johannes Berg <[EMAIL PROTECTED]>
Cc: Larry Finger <[EMAIL PROTECTED]>
Signed-off-by: Michael Buesch <[EMAIL PRO
This fixes clearing of the HW keys.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/b43/main.c
===
--- wireless-dev.orig/drivers/net/wireless/b43/main.c 2007-08-31
15:37:00.000
On Monday 03 September 2007, Kevin Barry wrote:
> Finally I outputted the value of sb_id_hi and it appears to be 0x.
>
> So perhaps I should just buy a new card.
Yeah.
> But perhaps I could hack the
> driver to work enough to dump the ssb_sprom and then see if that could
> be repaired?
On Monday 03 September 2007, Larry Finger wrote:
> This patch fixes a problem with work queues during shutdown. The bug
> seems to be responsible for the boot-time crashes reported in
> http://bugzilla.kernel.org/show_bug.cgi?id=8937.
>
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
> ---
>
>
On Friday 31 August 2007 19:43:16 Michael Buesch wrote:
> > @@ -4164,7 +4166,6 @@ static void bcm43xx_chip_reset(struct wo
> >
> > mutex_lock(&(bcm)->mutex);
> > if (bcm43xx_status(bcm) == BCM43xx_STAT_INITIALIZED) {
> > - bcm43xx_periodi
On Friday 31 August 2007, Larry Finger wrote:
> -void bcm43xx_periodic_tasks_delete(struct bcm43xx_private *bcm)
> -{
> - cancel_rearming_delayed_work(&bcm->periodic_work);
> -}
> -
> void bcm43xx_periodic_tasks_setup(struct bcm43xx_private *bcm)
> {
> struct delayed_work *work = &bcm
On Friday 31 August 2007, Larry Finger wrote:
> This patch fixes a problem with work queues during shutdown. The bug
> seems to be responsible for the boot-time crashes reported in
> http://bugzilla.kernel.org/show_bug.cgi?id=8937.
>
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
> ---
>
> Ind
On Thursday 30 August 2007 20:20:28 Anderson, Scott wrote:
> I just tested my BCM4311 with b43 from wireless-dev, WEP encryption, and an
> AP set for b-only
> operation. It's speed adjusted to 11 Mbs fairly quickly and yielded about 4
> Mbs uploads using iperf.
> Due to my network configuration
On Thursday 30 August 2007 19:47:50 Larry Finger wrote:
> Dr. techn. Alexander K. Seewald wrote:
> > Hi Larry,
> >
> > When resuming from suspend-to-disk, I get the following message
> > --
> > Aug 30 18:22:41 localhost kernel: b43 ssb0:0: resuming
> > Aug 30 18:22:41 localhost kernel: b43-phy0 ER
if the flag is set
then probe requests are required to be directed to the BSSID of
the AP to be answered by the microcode, but this not interesting
because we don't support probe request offload anyway.
This patch removes the IEEE80211_CONF_SSID_HIDDEN use from
both b43 drivers.
Cc: Michael
This correctly cancels all workqueues on shutdown.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Cc: Larry Finger
Index: wireless-dev-new/drivers/net/wireless/b43/main.c
===
--- wireless-dev-new.orig/drivers/net/wirele
On Monday 27 August 2007 17:00:18 Johannes Berg wrote:
> It is certainly not impossible, you can easily map the old to the new
> names and write a script that renames them, adds the header and
In theory.
In practice not. How do you reliably map the random initvalsXX naming to
the new one?
I don't
On Saturday 25 August 2007, Michael Buesch wrote:
> We must copy the MAC addresses to a local struct, as we
> don't own the original pointer from mac80211 and don't
> know how mac80211 might mess with it while we are using it.
>
> Signed-off-by: Michael Buesch <[E
We must copy the MAC addresses to a local struct, as we
don't own the original pointer from mac80211 and don't
know how mac80211 might mess with it while we are using it.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Cc: Larry Finger <[EMAIL PROTECTED]>
Index: wirele
This is a workaround that (optionally) removes the broken
optimization to only calibrate "needed" control values.
With this applied, all possible control values are always
calibrated and some runtime warnings vanish.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index:
On Friday 24 August 2007 23:30:02 Michael Buesch wrote:
> On Friday 24 August 2007 16:51:07 Larry Finger wrote:
> > From: Johannes Berg <[EMAIL PROTECTED]>
> >
> > This patch makes b43legacy include the FCS at the end of
> > received frames, useful for monitoring
On Friday 24 August 2007 16:51:07 Larry Finger wrote:
> From: Johannes Berg <[EMAIL PROTECTED]>
>
> This patch makes b43legacy include the FCS at the end of
> received frames, useful for monitoring.
Did you test this with WEP, WPA/AES and without encryption?
There was a very good reason why I cho
On Friday 24 August 2007 17:03:58 Larry Finger wrote:
> I assume that you meant b43 when you typed b32, but that error is not
> serious. It results from a
> problem with the specs. It will happen every time until the root cause is
> found. Depending on which
> BCM43xx model you have, you may al
On Thursday 23 August 2007 22:49:46 Johannes Berg wrote:
> On Tue, 2007-08-21 at 16:13 -0400, John W. Linville wrote:
>
> > > otherwise it oopses when the file can't be loaded.
> >
> > ACK...here is a patch, in case you are lazy... :-)
>
> Any reason you didn't push this fix this along with the
On Friday 24 August 2007 12:08:32 Johannes Berg wrote:
> On Fri, 2007-08-24 at 00:22 +0200, Michael Buesch wrote:
>
> > struct b43_key {
> > - void *keyconf;
> > - bool enabled;
> > + /* If keyconf is NULL, this key is disabled.
> > +* keyconf is a c
We must copy the MAC addresses to a local struct, as we
don't own the original pointer from mac80211 and don't
know how mac80211 might mess with it while we are using it.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Cc: Larry Finger <[EMAIL PROTECTED]>
Index: wirele
This adds missing stuff for new cards to pwork.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev-new/drivers/net/wireless/b43/main.c
===
--- wireless-dev-new.orig/drivers/net/wireless/b43/main.c 2007
Hopefully people can understand this better.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Cc: Larry Finger <[EMAIL PROTECTED]>
Index: wireless-dev-new/drivers/net/wireless/b43/Kconfig
===
--- wireless-dev-new.orig
Hi John,
This patch series catches wireless-dev up to my
current wireless-development patchset.
Please merge this into wireless-dev.
--
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
This fixes bugs and does a cleanup of the hwcrypto stuff.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Cc: Johannes Berg <[EMAIL PROTECTED]>
Index: wireless-dev-new/drivers/net/wireless/b43/b43.h
===
--- wireless-
This fixes crypto-RX on new firmware.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev-new/drivers/net/wireless/b43/main.c
===
--- wireless-dev-new.orig/drivers/net/wireless/b43/main.c 2007-08-23
Add a file to debugfs to extract the Local Oscillator
calibration data.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Cc: Larry Finger <[EMAIL PROTECTED]>
Index: wireless-dev-new/drivers/net/wireless/b
From: Johannes Berg <[EMAIL PROTECTED]>
For debugging it seems useful to be able to turn off
hardware encryption. With the changes I made to mac80211
that is now simple.
Signed-off-by: Johannes Berg <[EMAIL PROTECTED]>
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index
Add a return statement.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Cc: Larry Finger <[EMAIL PROTECTED]>
Index: wireless-dev-new/drivers/net/wireless/b43/main.c
===
--- wireless-dev-new.orig/drivers/net/wireles
On Thursday 23 August 2007 11:12:10 David Woodhouse wrote:
> On Sun, 2007-08-19 at 14:37 -0500, Larry Finger wrote:
> > It is recommended that you update fwcutter before these patches are
> > merged. If your version of fwcutter was obtained with subversion, a
> > simple 'svn update' in the fwcutter
On Wednesday 22 August 2007 20:08:09 Larry Finger wrote:
> John W. Linville wrote:
> > On Wed, Aug 22, 2007 at 10:25:28AM -0500, Larry Finger wrote:
> >> John W. Linville wrote:
> >>> On Sun, Aug 19, 2007 at 02:37:21PM -0500, Larry Finger wrote:
> Just in case you missed the details, the lates
On Wednesday 22 August 2007 18:33:58 Rafael J. Wysocki wrote:
> On Wednesday, 22 August 2007 11:06, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/
> >
> > - git-ixgbe.patch got dropped - git-net.patch destroyed it
> >
> > - t
On Wednesday 22 August 2007 10:10:23 Johannes Berg wrote:
> Hey,
>
> Just noticed this bit of code:
> if (dev->dev->id.revision >= 5) {
> /* Number of RCMTA address slots */
> b43_write16(dev, B43_MMIO_RCMTA_COUNT, dev->max_nr_keys - 8);
> }
>
> wit
On Tuesday 21 August 2007 22:13:36 John W. Linville wrote:
> On Tue, Aug 21, 2007 at 05:46:40PM +0200, Johannes Berg wrote:
> > On Sun, 2007-08-19 at 01:48 +0200, Michael Buesch wrote:
> >
> > > @@ -1598,8 +1601,29 @@ static int do_request_fw(struct b43_wlde
> &
On Sunday 19 August 2007 06:45:00 Larry Finger wrote:
> Using the latest set of 6 patches posted about 5 hours ago, I get the
> following locking problem with
> a BCM4311 using WPA-PSK TKIP encryption controlled by NetworkManager:
Are you sure this is caused by my patches? I don't see how that's
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev-new/drivers/net/wireless/b43/b43.h
===
--- wireless-dev-new.orig/drivers/net/wireless/b43/b43.h2007-08-18
19:05:09.0 +0200
+++ wireless-d
Use the same %-convention as file2alias does.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: ssb-merge-new/drivers/ssb/main.c
===
--- ssb-merge-new.orig/drivers/ssb/main.c 2007-08-15 18:33:50.0
+0200
+
From: Larry Finger <[EMAIL PROTECTED]>
The help text in Kconfig for b43 is updated to indicate the devices that it
does not support and to note that it can coexist with b43legacy.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Use a sane firmware file naming scheme and also move
the firmware files into a subdir.
This avoids conflicts with bcm43xx and b43legacy.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev-new/drivers/net/wireless/b43
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev-new/drivers/net/wireless/b43/Kconfig
===
--- wireless-dev-new.orig/drivers/net/wireless/b43/Kconfig 2007-08-15
15:08:39.0 +0200
+++ wireless-d
Avoid namespace pollution.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev-new/drivers/net/wireless/b43/b43.h
===
--- wireless-dev-new.orig/drivers/net/wireless/b43/b43.h2007-08-14
17:01:07.000
1201 - 1300 of 2290 matches
Mail list logo
