Hi John,
This patch series catches wireless-dev up to my
current wireless-development patchset.
Please merge this into wireless-dev.
IMPORTANT: Latest fwcutter from SVN and re-extracting the firmware is needed
after applying this.
--
___
Bcm43xx-d
On Saturday 18 August 2007 23:12:10 Frederik wrote:
> On 8/18/07, Michael Buesch <[EMAIL PROTECTED]> wrote:
> > On Saturday 18 August 2007 21:01:12 Johannes Berg wrote:
> > > On Sat, 2007-08-18 at 20:29 +0200, Frederik wrote:
> > >
> > > > b43-phy9 deb
On Saturday 18 August 2007 22:42:04 Richard Jonsson wrote:
> On Saturday 18 August 2007 22:17:22 you wrote:
> >
> > It's a bug in mac80211
>
> Ok, is it a known bug, and is there a patch? Should I bother finding it?
It's unknown how it's triggered and there is no patch.
> And finally, is this th
On Saturday 18 August 2007 22:09:22 Richard Jonsson wrote:
> Background:
> I have this problem with mac80211 based drivers, but not with softmac drivers.
> When unloading the module rmmod never quits and this message is repeated in
> dmesg:
> "unregister_netdevice: waiting for eth1 to become free.
On Saturday 18 August 2007 21:01:12 Johannes Berg wrote:
> On Sat, 2007-08-18 at 20:29 +0200, Frederik wrote:
>
> > b43-phy9 debug: Loading firmware version 351.126 (2006-07-29 05:54:02)
>
> > b43-phy9 debug: Using hardware based encryption for keyidx: 0, mac:
> > ff:ff:ff:ff:ff:ff
> > b43-phy9 d
On Friday 17 August 2007 22:55:49 Ehud Gavron wrote:
> Synopsis:
> With "everything" tree and b43, loses AP association but then
> reassociates, usually on ARP request.
How is an ARP request related to an association? That's
a different network layer.
Did you try with another AP?
--
Greetings M
On Saturday 18 August 2007 00:37:03 Larry Finger wrote:
> From: Johannes Berg <[EMAIL PROTECTED]>
>
> The auto-loading mechanism from ssb to b43 is case sensitive; however, the
> present code is generating a lower-case "a" for the BCM4311, which has an
> 802.11 core with revision 10.
>
> Signed-o
On Friday 17 August 2007 20:11:23 Larry Finger wrote:
> 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]>
Queued, thanks!
--
Greetings Michael.
__
On Friday 17 August 2007 18:12:05 Larry Finger wrote:
> Michael,
>
> Now that I have solved the module loading problem on my openSUSE 10.2
> systems, I'm nearly ready to
> push the b43legacy patch to John.
>
> Is it your plan to stay with the current firmware naming scheme, or are you
> going
On Wednesday 15 August 2007 18:12:33 Johannes Berg wrote:
> On Wed, 2007-08-15 at 11:05 -0500, Larry Finger wrote:
>
> > > alias: ssb:v4243id0812rev0A*
>
> > --- wireless-dev.orig/drivers/ssb/main.c
> > +++ wireless-dev/drivers/ssb/main.c
> > @@ -331,7 +331,7 @@ static int ssb_device_uev
On Wednesday 15 August 2007 16:48:27 Larry Finger wrote:
> Johannes Berg wrote:
> > On Wed, 2007-08-15 at 08:53 -0500, Larry Finger wrote:
> >
> >> From a test printk, I know that the init function
> >> for b43_pci_bridge_driver has been run, but I have no idea on how to debug
> >> any further.
On Wednesday 15 August 2007 14:58:09 Larry Finger wrote:
> +SSB_SPROM=`find /sys -name ssb_sprom`
> +sudo cat $SSB_SPROM > ssb_sprom_copy
> +
> +Newbie Note: In the first line, those symbols are back ticks (usually found
> +near the key, not forward ticks usually found near the (enter)
> key.
I
On Wednesday 15 August 2007 15:53:41 Larry Finger wrote:
> Michael,
>
> Using the git version of b43 that was updated last night, I am getting the
> following error for my
> BCM4311:
>
> b43-phy0 ERROR: Adjusting Local Oscillator to an uncalibrated control pair:
> rfatt=3,no-padmix bbatt=2
> b
On Wednesday 15 August 2007 01:35:54 Larry Finger wrote:
> The indentation (dependencies) are not right for B43.
>
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
Yes I know. Thanks for this.
>
> Index: wireless-dev/drivers/net/wireless/b43/Kconfig
> ==
Don't check the device status. It's checked and handled later in
the workqueue. Use proper locking in the reset callback.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev-new/drivers/net/wir
This will be added to ssb
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-12
16:38:52.000
This crashes otherwise.
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-12
20:17:01.000
This should properly autoselect the SSB options without
introducing a dependency hell.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev-new/drivers/net/wireless/b43/Kconfig
===
--- wireless-dev-new.orig/d
This makes it possible to find uses of uncalibrated LO value pairs.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev-new/drivers/net/wireless/b43/lo.c
===
--- wireless-dev-new.orig/drivers/net/wireless/b4
We must check for >=INITIALIZED
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-
(u8)0 - 1 == 255
which is wrong. Should be 0.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev-new/drivers/net/wireless/b43/dma.c
===
--- wireless-dev-new.orig/drivers/net/wireless/b43/dma.c2007
This fixes an endless loop inside of a spinlock.
This triggers if the tx_status file is read before a packet
has been transmitted.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev-new/drivers/net/wireless/b43/deb
The MLME takes care of this.
In future we probably want to change the MLME to support this
hardware feature.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev-new/drivers/net/wireless/b43/main.c
===
--- wi
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
On Tuesday 14 August 2007 19:34:08 Larry Finger wrote:
> Michael Buesch wrote:
> > Hi John,
> >
> > This patch series catches SSB up to my
> > current wireless-development patchset.
> >
> > Please merge this into wireless-dev ssb branch.
>
> I had a
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: ssb-merge-new/drivers/ssb/Kconfig
===
--- ssb-merge-new.orig/drivers/ssb/Kconfig 2007-08-14 17:05:12.0
+0200
+++ ssb-merge-new/drivers/ssb/Kconfig 2007-08
Always make sure buspower is applied, when accessing the PCI MMIO space.
Otherwise this can result in crashes.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: ssb-merge-new/drivers/ssb/main.c
===
--- ssb-merge-ne
Signed-off-by: Johannes Berg <[EMAIL PROTECTED]>
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-11 01:57:31.
From: Aurelien Jarno <[EMAIL PROTECTED]>
The patch below fixes a warning spotted a few days ago by Andrew Morton
while releasing 2.6.23-rc2-mm1.
Signed-off-by: Aurelien Jarno <[EMAIL PROTECTED]>
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: ssb-merge-new/include/li
Hi John,
This patch series catches SSB up to my
current wireless-development patchset.
Please merge this into wireless-dev ssb branch.
--
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: ssb-merge-new/drivers/ssb/Makefile
===
--- ssb-merge-new.orig/drivers/ssb/Makefile 2007-08-13 17:35:33.0
+0200
+++ ssb-merge-new/drivers/ssb/Makefile 2007
From: Aurelien Jarno <[EMAIL PROTECTED]>
The patch below adds a functions to Chip Common and PCI core drivers to
access the GPIO lines.
Signed-off-by: Aurelien Jarno <[EMAIL PROTECTED]>
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: ssb-merge-new/drivers/ssb/d
This makes the build system magic generate the appropriate
modaliases for MODULE_DEVICE_TABLE(ssb, ...)
Signed-off-by: Johannes Berg <[EMAIL PROTECTED]>
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: ssb-merge-new/include/linux/mod_d
On Monday 13 August 2007 18:00:12 Johannes Berg wrote:
> You forgot this:
>
> --- wireless-dev.orig/drivers/ssb/b43_pci_bridge.c2007-08-13
> 17:57:32.205589257 +0200
> +++ wireless-dev/drivers/ssb/b43_pci_bridge.c 2007-08-13 17:57:49.915589257
> +0200
> @@ -27,6 +27,8 @@ static const struct
The following patches for b43 apply to b43legacy as well.
http://bu3sch.de/patches/wireless-dev/20070813-1187014012/patches/024-b43-suppress-fw-probe-responses.patch
http://bu3sch.de/patches/wireless-dev/20070813-1187014012/patches/025-b43-debugfs-fix-tx-status-crash.patch
http://bu3sch.de/patches
On Monday 13 August 2007 13:55:24 Johannes Berg wrote:
> On Sun, 2007-08-12 at 20:47 +0200, Michael Buesch wrote:
> > Here are some patches that port the pci bridge
> > code of b43 to ssb. So with these patches it is
> > possible to run b43 and your yet-to-be-ported
> >
On Monday 13 August 2007 06:24:48 Otto Solares wrote:
> On Sun, Aug 12, 2007 at 09:29:33PM -0500, Larry Finger wrote:
> > Otto Solares wrote:
> > >On Sun, Aug 12, 2007 at 08:47:51PM +0200, Michael Buesch wrote:
> > >>Here are some patches that port the pci bridge
>
On Monday 13 August 2007 05:10:23 Larry Finger wrote:
> The curious part is that the A PHY values are all set, but the B/G PHY values
> have not been, even
> though this is a B/G-only device. I had been surprised earlier that the
> antenna gain was not set,
> which is why I submitted the patch
On Sunday 12 August 2007 22:39:08 Larry Finger wrote:
> Michael Buesch wrote:
> > Here are some patches that port the pci bridge
> > code of b43 to ssb. So with these patches it is
> > possible to run b43 and your yet-to-be-ported
> > b43legacy in parallel. The bridge c
Here are some patches that port the pci bridge
code of b43 to ssb. So with these patches it is
possible to run b43 and your yet-to-be-ported
b43legacy in parallel. The bridge code in ssb
would always probe the correct driver.
http://bu3sch.de/patches/wireless-dev/20070812-1186943700/
You have to
]>
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: ssb-merge/drivers/ssb/driver_pcicore.c
===
--- ssb-merge.orig/drivers/ssb/driver_pcicore.c 2007-08-10 13:30:22.0
+0200
+++ ssb-merge/drivers/ssb/driver_pcicore
This makes the verbose printk on every coreswitch dependent
on a default-off debugging variable.
Verbose coreswitch messages are only needed when debugging
strange crashes or machine check exceptions.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: ssb-merge/drivers/ssb
ssb-core is not experimental anymore.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: ssb-merge/drivers/ssb/Kconfig
===
--- ssb-merge.orig/drivers/ssb/Kconfig 2007-08-10 12:52:50.0 +0200
+++ ssb-merge/drive
Hi John,
This patch series catches ssb in wireless-dev up to my
current wireless-development patchset.
Please merge this into wireless-dev ssb branch.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bc
From: Aurelien Jarno <[EMAIL PROTECTED]>
I finally have one more patch for the SSB bus driver. I have ported the
BCM947xx code to the CFE API that is already in the kernel, and I have
seen that when the chip common driver initializes the serial port, it
breaks the CFE console (used as an early con
rol to internal.
- Add some delay between the configuration of the PCI controller
and its registration.
Signed-off-by: Aurelien Jarno <[EMAIL PROTECTED]>
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: ssb-merge/drivers/ss
On Saturday 11 August 2007 01:01:21 Michael Buesch wrote:
> Please apply these patches to the b44 branch of wireless-dev.
Of course the b43 branch ;)
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
ht
Hi John,
here's a HUGE bcm43xx patchset that updates/fixes
various things and renames bcm43xx to b43. It also
moves and renames all files.
The patch series is not attached to this mail, as it is
_really_ big.
The patches series can be downloaded here:
http://bu3sch.de/patches/wireless-dev/200708
On Friday 10 August 2007 17:35:03 Larry Finger wrote:
> Michael Buesch wrote:
> > On Friday 10 August 2007 17:02:15 Larry Finger wrote:
> >> Jory A. Pratt wrote:
> >>> Larry Finger wrote:
> >>>> What encryption method are you using?
> >>>>
On Friday 10 August 2007 17:02:15 Larry Finger wrote:
> Jory A. Pratt wrote:
> > Larry Finger wrote:
> >>
> >> What encryption method are you using?
> >>
> >> Larry
> >>
> > I use wep encryption on a WRT54G V3 with dd-wrt. I will work on it later
> > tonight and see what I can come up with.
>
> Y
On Friday 10 August 2007 14:03:31 Jory A. Pratt wrote:
> Yes I am able to reproduce it. I have done upgraded and downgraded my
> enitre toolchain. exact same problem is present on my system when I try
> my 4306 and 4318.
So, would you please debug it?
--
Greetings Michael.
On Friday 10 August 2007 04:27:33 Ehud Gavron wrote:
> I have spent eight hours on this today and I can't find a way to do a
> subset of the patches. I haven't quite given up, but I'm reaching a
> point where I could use some insight. I didn't copy the list... but
> feel free to if you think it
On Thursday 09 August 2007, Larry Finger wrote:
> Johannes Berg wrote:
> > On Thu, 2007-08-09 at 16:52 +0200, Michael Buesch wrote:
> >
> >> There will be a problem with the PCI IDs, though.
> >> We can't see from the PCI ID if that's a v4 or v5 devic
On Thursday 09 August 2007 16:46:40 Larry Finger wrote:
> Michael Buesch wrote:
>
> > Newer drivers don't contain support for wireless core ref < 5
> > anymore. So I suggest we support <5 devices with the legacy
> > driver using v3 firmware. And anything above
On Thursday 09 August 2007 16:09:53 Larry Finger wrote:
> Michael Buesch wrote:
> > It turns out that it's better to extend the device
> > support in bcm4301 due to more difficulties in reverse
> > engineering the newer bcm drivers.
> > Newer drivers don't cont
On Thursday 09 August 2007 16:21:09 Pavel Roskin wrote:
> On Thu, 2007-08-09 at 16:07 +0200, Michael Buesch wrote:
> > On Thursday 09 August 2007 16:00:47 Pavel Roskin wrote:
> > > On Thu, 2007-08-09 at 15:41 +0200, Michael Buesch wrote:
> > >
> > > >
On Thursday 09 August 2007 16:09:53 Larry Finger wrote:
> I like the idea of b43 and b43-legacy. As a "senior citizen", I'm beginning
> to dislike the adjective
> "old",
haha :P
> What time frame do you envision this change taking place?
I was planning to do it with my next patch.
Though, I s
On Thursday 09 August 2007 16:00:47 Pavel Roskin wrote:
> On Thu, 2007-08-09 at 15:41 +0200, Michael Buesch wrote:
>
> > So, that said, I want to rename all the drivers.
> > My plan was to rename "bcm43xx-mac80211" to "b43", so
> > you could probab
It turns out that it's better to extend the device
support in bcm4301 due to more difficulties in reverse
engineering the newer bcm drivers.
Newer drivers don't contain support for wireless core ref < 5
anymore. So I suggest we support <5 devices with the legacy
driver using v3 firmware. And anythi
On Thursday 09 August 2007 02:06:35 Ehud Gavron wrote:
> They were *ALL* enabled, even the modules for testing that I didn't load.
> They're still there in the built kernel... so if you want something from
> it, I can easily reboot into it and get it.
>
> From another message:
> > n IRC was sugg
On Thursday 09 August 2007 04:30:58 Larry Finger wrote:
> Ehud,
>
> I was just reviewing the complete dmesg output that you sent earlier, which I
> think was for a "bad"
> case. I use WPA encryption, which cannot be done in hardware, and I have not
> seen messages that look
WPA works fine in
On Wednesday 08 August 2007 23:26:09 Michael Buesch wrote:
> On Wednesday 08 August 2007 23:06:42 Ehud Gavron wrote:
> > It doesn't fix the problem, either with BCM43XX_MAC80211_DEBUG=y or n.
>
> What about enabling the Kernel Hacking options I suggested?
On IRC was suggeste
On Wednesday 08 August 2007 23:26:09 Michael Buesch wrote:
> On Wednesday 08 August 2007 23:06:42 Ehud Gavron wrote:
> > It doesn't fix the problem, either with BCM43XX_MAC80211_DEBUG=y or n.
>
> What about enabling the Kernel Hacking options I suggested?
On IRC was suggeste
On Wednesday 08 August 2007 23:06:42 Ehud Gavron wrote:
> It doesn't fix the problem, either with BCM43XX_MAC80211_DEBUG=y or n.
What about enabling the Kernel Hacking options I suggested?
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@
power.c is not needed anymore. Move the only function
included in power.c into main.c.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/Makefile
===
--- wireless-de
Fix uninitialized-var warnings in lo.c
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_lo.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-ma
People won't read it, but hey. Let's do our best :)
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/
To: Andrew Morton <[EMAIL PROTECTED]>
This makes the verbose printk on every coreswitch dependent
on a default-off debugging variable.
Verbose coreswitch messages are only needed when debugging
strange crashes or machine check exceptions.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED
Cleanup.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
2007-08-08
Remove our own assert() definition and use the standard kernel WARN_ON().
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
===
--- wireless-dev.orig/drive
Reorder the starting of the wireless core.
First set the "we are ready to go" status and then poke operation.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac8021
From: Pavel Roskin <[EMAIL PROTECTED]>
This can happen if CONFIG_BCM43XX_MAC80211_DEBUG is enabled, but
CONFIG_DEBUG_FS is not.
Debugging message added by Michael Buesch.
Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
I
No functional change.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
2007-08
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
On Wednesday 08 August 2007 21:56:24 Ehud Gavron wrote:
> Patch with debug on or off both fail.
>
> I'm unable to apply Michael's patch to either a virgin test or virgin
> wireless-dev tree (I rm -rf'd both and re git clone'd them)
>
> [EMAIL PROTECTED] test]# patch -p1 <
> ~gavron/bcm43xx-mac8
On Wednesday 08 August 2007 19:54:30 Larry Finger wrote:
> Ehud Gavron wrote:
> > The corrected patch shows the same results. I have a 2.6.23-rc2 kernel
> > where bcm43xx_mac80211 receives garbage.
>
> Mumble, mumble, swear words,.
>
> OK, back to the drawing board. Was this test with BCM43
On Wednesday 08 August 2007 19:46:33 Ehud Gavron wrote:
> The corrected patch shows the same results. I have a 2.6.23-rc2 kernel
> where bcm43xx_mac80211 receives garbage.
Please enable almost every option under "Kernel Hacking".
Especially those to detect memory corruption.
But also the lock de
On Wednesday 08 August 2007 18:24:14 Ehud Gavron wrote:
> [EMAIL PROTECTED] test]# git status
> # On branch master
> # Untracked files:
> # (use "git add ..." to include in what will be committed)
> #
> # arch/x86_64/vdso/vdso.lds
> nothing added to commit but untracked files present (use "
On Wednesday 08 August 2007 18:11:03 Larry Finger wrote:
> > [EMAIL PROTECTED] test]# patch -p1 < patch-2007-aug-08-lfinger.txt
> > patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
> > Hunk #1 FAILED at 1503.
> > Hunk #2 FAILED at 1512.
> > 2 out of 2 hunks FAILED -- saving rejec
On Saturday 04 August 2007 07:12:46 Brennan Ashton wrote:
> When the bcm43xx_mac80211 driver stops communicating, and needs to be
> reset (this seems to happens when coming from strong to week to strong
> signal area quickly) i have been rmmod and then modprobing it. this
Can you test if you still
On Wednesday 08 August 2007 05:27:13 Jhonie Walker wrote:
> Hello, I tried to use the tool with the drivers
> working ok, but this is what I get in the console:
> ./sprommod.sh eth0
> ./sprommod.sh: line 31: bcm43xx-sprom: command not
> found
> Could not modify SPROM data (127)
>
> I noticed that
On Wednesday 08 August 2007 08:02:29 Larry Finger wrote:
> Larry Finger wrote:
> > Pavel Roskin wrote:
> >> This can happen if CONFIG_BCM43XX_MAC80211_DEBUG is enabled, but
> >> CONFIG_DEBUG_FS is not.
> >>
> >> Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
> >> ---
> >>
> > With this patch insta
On Wednesday 08 August 2007 07:52:21 Larry Finger wrote:
> Pavel Roskin wrote:
> > This can happen if CONFIG_BCM43XX_MAC80211_DEBUG is enabled, but
> > CONFIG_DEBUG_FS is not.
> >
> > Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
> > ---
> >
> With this patch installed, and the DEBUG configurat
On Wednesday 08 August 2007 07:17:10 Pavel Roskin wrote:
> This can happen if CONFIG_BCM43XX_MAC80211_DEBUG is enabled, but
> CONFIG_DEBUG_FS is not.
>
> Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
> ---
Thanks, queued.
Larry, this might also apply to bcm4301.
> .../wireless/bcm43xx-mac8021
This removes the stackdump in the rfatt/bbatt assertion
to reduce verbosity, but it also increases the message log
level from "debug" to "error".
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/bcm
This patch makes hardware power control optional through
a module parameter, which is disabled by default.
Hardware power control is broken, so we will drive with software
based power control.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
--
John, please apply to wireless-dev.
Wit
Hi,
(bringing this topic on list again)
I got a bugreport that latest bcm43xx-mac80211 generates
corrupted frames. So when doing tcpdump on the interface
just crap would come out.
I can not reproduce this. Does someone else see this behaviour?
The commit that introduced the bug was claimed to be
On Monday 06 August 2007 23:35:48 Michael Buesch wrote:
> On Monday 06 August 2007 23:29:04 Larry Finger wrote:
> > Michael,
> >
> > I sent the wrong message under this subject before.
> >
> > This hack disabled hardware power control. With this installed and th
On Monday 06 August 2007 23:29:04 Larry Finger wrote:
> Michael,
>
> I sent the wrong message under this subject before.
>
> This hack disabled hardware power control. With this installed and the
> desired power set to 10 dBm using the previous patch, I get much, much
> better performance from bc
On Monday 06 August 2007 23:26:07 Larry Finger wrote:
> Michael Buesch wrote:
> >
> > No, why do you poke with this at all.
> > This completely breaks power adjustment from mac80211.
> > Simply don't touch bcm43xx_dev_config :)
> >
>
> The problem
On Monday 06 August 2007 22:55:30 Larry Finger wrote:
> For testing purposes, this patch adds a file named "power_level" to the
> debugfs for bcm43xx-mac80211. If this file is read, it returns the current
> setting for the "Desired power level". Writing a number between 5 and 18
> will set that val
On Monday 06 August 2007 22:36:49 Larry Finger wrote:
> Michael Buesch wrote:
> > On Monday 06 August 2007 22:22:14 Larry Finger wrote:
> >> Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80
On Monday 06 August 2007 22:22:14 Larry Finger wrote:
> Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
> ===
> --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
> +++ wireless-dev/driv
On Monday 06 August 2007, Larry Finger wrote:
> Michael Buesch wrote:
> >
> > Well, without a stacktrace you don't know who caused the error.
> > We can remove that. But I still don't know what we gain from
> > removing useful debug messages. If you
On Monday 06 August 2007, John W. Linville wrote:
> On Sat, Aug 04, 2007 at 06:47:29PM +0200, Michael Buesch wrote:
> > On Saturday 04 August 2007, Larry Finger wrote:
> > > Pavel Roskin wrote:
> > > > On Fri, 2007-08-03 at 20:46 -0500, Larry Finger wrote:
> >
On Monday 06 August 2007, Pavel Roskin wrote:
> On Sun, 2007-08-05 at 12:18 +0200, Michael Buesch wrote:
>
> > Well, it's not that easy. Current code just doesn't make any sense.
> > I do not understand how hardware power control works exactly, so I
> > ca
This will always work.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx
From: Larry Finger <[EMAIL PROTECTED]>
Fixed-by: Michael Buesch <[EMAIL PROTECTED]>
In bcm43xx-mac80211, the mechanism for decreasing the transmit rate cannot
be triggered. This may be shown by walking away from the AP with a laptop.
At some distance, communications will be lo
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
Finger <[EMAIL PROTECTED]>
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.
1301 - 1400 of 2290 matches
Mail list logo
