On Tuesday 07 April 2009 21:37:58 Johannes Berg wrote:
On Tue, 2009-04-07 at 21:33 +0200, Michael Buesch wrote:
Well, I suppose you could register with the max and later reduce and
stop the remaining queues you're not using... Or not stop them and drop
packets on them. That's somewhat
Completely untested patch to implement firmware capabilities
and automagic QoS-disabling.
Index: wireless-testing/drivers/net/wireless/b43/b43.h
===
--- wireless-testing.orig/drivers/net/wireless/b43/b43.h2009-04-07
On Saturday 04 April 2009 10:54:01 Elimar Riesebieter wrote:
* Michael Buesch [090319 19:27 +0100]
[...]
!!! DISTRIBUTIONS !!!
Disable CONFIG_B43_DEBUG!
There is absolutely _no_ reason to enable it on a release kernel.
There were valid reasons in the past, but there are none left anymore
On Wednesday 01 April 2009 17:42:36 Larry Finger wrote:
Auto-depend on HW_RANDOM, rather than selecting it.
This way the user has the choice to enable or disable HWRNG support.
Signed-off-by: Larry Finger larry.fin...@lwfinger.net
---
John, please queue for 2.6.31.
ACK
Index:
.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
John, please queue this patch for 3.6.31.
Index: wireless-testing/drivers/net/wireless/b43/b43.h
===
--- wireless-testing.orig/drivers/net/wireless/b43/b43.h2009-04-01
00:00
On Monday 30 March 2009 03:50:47 Larry Finger wrote:
Auto-depend on HW_RANDOM, rather than selecting it.
This way the user has the choice to enable or disable HWRNG support.
Signed-off-by: Larry Finger larry.fin...@lwfinger.net
---
John, please queue for 2.6.31.
Index:
On Monday 30 March 2009 17:26:16 Larry Finger wrote:
Auto-depend on HW_RANDOM, rather than selecting it.
This way the user has the choice to enable or disable HWRNG support.
Signed-off-by: Larry Finger larry.fin...@lwfinger.net
---
John, please queue for 2.6.31.
Index:
On Monday 30 March 2009 23:35:34 Francesco Gringoli wrote:
I have one more question: the hardware seems to allow frames that are
longer than 2352 bytes. If we monitor the firmware during receiving we
get up to 0x1005 bytes long frames. When such frames arrives, the
kernel drops them as
Auto-depend on HW_RANDOM, rather than selecting it.
This way the user has the choice to enable or disable HWRNG support.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
John, please queue for the next feature release.
Index: wireless-testing/drivers/net/wireless/b43/Kconfig
in
front of
the mapping of the DMA buffer. The CPU should not touch the buffer after we
mapped it.
Cc: sta...@kernel.org
Reported-by: Francesco Gringoli francesco.gring...@ing.unibs.it
Signed-off-by: Michael Buesch m...@bu3sch.de
---
Francesco, please stresstest this.
John, please queue as bugfix
The RX buffer poison needs to be refreshed, if we recycle an RX buffer,
because it might be (partially) overwritten by some DMA operations.
Cc: sta...@kernel.org
Cc: Francesco Gringoli francesco.gring...@ing.unibs.it
Signed-off-by: Michael Buesch m...@bu3sch.de
---
Francesco, please stresstest
On Saturday 28 March 2009 00:49:12 Francesco Gringoli wrote:
On Mar 27, 2009, at 10:51 PM, Michael Buesch wrote:
This patch adds poisoning and sanity checking to the RX DMA buffers.
This is used for protection against buggy hardware/firmware that
raises
RX interrupts without doing
On Thursday 26 March 2009 20:42:29 Francesco Gringoli wrote:
I spent more time debugging this issue. I found something interesting:
when we ask the firmware to pass corrupted frames, it can happen
(actually it happens frequently if traffic is high) that the firmware
detects something was
On Sunday 22 March 2009 17:32:35 Lorenzo Nava wrote:
This patch fixes the return type of b43_plcp_get_bitrate_idx_ofdm. If
the plcp contains an error, the function return value is 255 instead
of -1, and the packet was not dropped. This causes a warning in
__ieee80211_rx function because
On Sunday 22 March 2009 17:45:58 Lorenzo Nava wrote:
Hi Michael,
what do you mean with non-mangled version?
The patch is line wrapped. Fix your email client settings.
I also noticed that most of the plcp rate errors seem due to an
incorrect padding value passed by the firmware. The plcp
On Sunday 22 March 2009 18:07:28 Lorenzo Nava wrote:
I hope it is ok.
Reported-by: Lorenzo Nava
Signed-off-by: Lorenzo Nava navalor...@gmail.com
Index: wireless-testing/drivers/net/wireless/b43/xmit.c
===
---
On Sunday 22 March 2009 19:00:38 Lorenzo Nava wrote:
Once again...
The patch still is whitespace damaged.
m...@homer:~/develop/git/wireless-testing$ patch -p1 --dry-run x.patch
patching file drivers/net/wireless/b43/xmit.c
patch: malformed patch at line 52: }
But I'll recreate the patch
of range.
Cc: sta...@kernel.org
Signed-off-by: Lorenzo Nava navalor...@gmail.com
Signed-off-by: Michael Buesch m...@bu3sch.de
---
John, please queue as a bugfix to the current kernel.
Index: wireless-testing/drivers/net/wireless/b43/xmit.c
ssb is not experimental anymore.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
John, please queue for the next feature release.
Index: wireless-testing/drivers/ssb/Kconfig
===
--- wireless-testing.orig/drivers/ssb/Kconfig
error in a mainline b43 driver.
* It does _not_ result in interrupt storms or something like that.
It will simply result in a stalled card. It can be debugged by enabling
the debugging module parameter.
Signed-off-by: Michael Buesch m...@bu3sch
---
I wonder how much placebo PHY TX error
On Thursday 19 March 2009 19:27:21 Michael Buesch wrote:
This patch adds a workaround for the issue by just enabling the interrupt
if debugging is disabled (by Kconfig or by modparam).
Of course I meant just disabling the interrupt
--
Greetings, Michael
On Thursday 19 March 2009 20:00:45 Francesco Gringoli wrote:
some time ago I begin seeing several of these errors, never seen
before on one of my host, with both proprietary and open firmwares. As
I never noticed those errors before, I wondered if they could be due
to some strange frame
On Thursday 19 March 2009 20:56:52 Francesco Gringoli wrote:
I would agree with you, but there is this bizarre issue with PHY
errors in monitoring mode that makes me thinking about what we call
PHY errors. I would say they are not only due to transmission, they
are general PHY errors,
On Monday 16 March 2009 15:53:03 Larry Finger wrote:
David Ellingsworth wrote:
I'm looking for a PCI based wireless card to add to my Linux router in
order to setup a wireless access point. I'm currently considering the
use of a b43 based card, but
On Monday 16 March 2009 16:23:51 Larry Finger wrote:
Michael Buesch wrote:
Did you check if it does actually work correctly? Especially beaconing.
There were lots of changes to b43's beaconing, which were not ported to
legacy.
I should probably look at porting those changes.
My
On Sunday 15 March 2009 22:27:13 Stefan Lippers-Hollmann wrote:
Hi
On Mittwoch, 7. Januar 2009, Jiri Slaby wrote:
On 01/07/2009 02:51 PM, Jiri Slaby wrote:
Dhaval Giani wrote:
I see this on current git. Not sure how to reproduce it, has happened on
two random occasions. At both
On Tuesday 10 March 2009 12:41:03 Kevin Wilson wrote:
Is it done in firmware ?
Yes. It's impossible to get ACK timings correct from within a kernel driver.
--
Greetings, Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
This fixes compilation, if the PCI core is disabled.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
John, I think this is only needed for the next feature release, as the patch
that broke that was only merged for next, afaik.
Index: wireless-testing/drivers/net/wireless/b43/main.c
On Tuesday 03 March 2009 14:27:30 Bo Han wrote:
Hi Michael,
After I applied the patch you provided below, the system is still frozen
after I turn on the fcsfail flag. If it is possible, could you please test
on your systems?
The patch is not supposed to fix your freezes. Please remove your
.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
John, please queue for the next feature release.
I'll probably look into the WARN_ON issue, too, but this is not too important
as weird things are expected to happen if user requests passing of bad frames.
Index: wireless-testing/drivers/net
On Saturday 28 February 2009 21:07:41 Larry Finger wrote:
One more question and i hope you don't mind, it's off topic but it's
related to my quest. I hadven't done any C programming in 10 years but when
I used to do a lot of it, if I patche a source file and ran 'make', it
figured out
On Monday 23 February 2009 03:40:01 John Mountcastle wrote:
mtcs...@sybill:~/Desktop sudo /usr/sbin/iwconfig wlan0
wlan0 IEEE 802.11bg ESSID:MBR-6d2
Mode:Managed Frequency:2.417 GHz Access Point: 00:30:44:02:76:D2
Bit Rate=1 Mb/s Tx-Power=27 dBm
On Monday 23 February 2009 07:30:13 Larry Finger wrote:
Francesco Gringoli wrote:
do you mind testing this firmware? It's not the solution, but can help
us understanding if we should follow this way. Download at
http://www.ing.unibs.it/~gringoli/fwtest.tar.gz
Before using this
On Monday 23 February 2009 12:15:54 Michael Buesch wrote:
On Monday 23 February 2009 03:40:01 John Mountcastle wrote:
mtcs...@sybill:~/Desktop sudo /usr/sbin/iwconfig wlan0
wlan0 IEEE 802.11bg ESSID:MBR-6d2
Mode:Managed Frequency:2.417 GHz Access Point:
00:30:44:02:76
warning: large integer implicitly truncated to unsigned type
Signed-off-by: Michael Buesch m...@bu3sch.de
---
Virtual fists were already shaked, so I need to hurry up to fixup my crap. :P
Index: wireless-testing/drivers/net/wireless/b43/phy_g.c
On Sunday 22 February 2009 21:45:44 John Mountcastle wrote:
Michael, configuring a new kernel was a real blast from the past. I haven't
done that in several years but I think I got it done. Funny thing, when I
booted the debug kernel, the interface was rock solid for almost an hour, not
On Saturday 21 February 2009 20:17:53 John Mountcastle wrote:
Thanks Larry, what about the part right there at the endwher it says assume
out of range when nothing has moved. It's like the receeption begins to drop
of until it can no longer support the connection.
Please turn on b43
On Friday 20 February 2009 00:09:42 Michael Buesch wrote:
This adds a compiletime assertion for a recently introduced
assumption on the slot counts.
The tx header cache handling code assumes that the TX slot count
can be divided evenly by the number of TX slots per frame.
Signed-off
This adds a compiletime assertion for a recently introduced
assumption on the slot counts.
The tx header cache handling code assumes that the TX slot count
can be divided evenly by the number of TX slots per frame.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
Coded with a brown paper bad
Do not turn off the crystal, if the boardflags tell us so.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
John, this doesn't fix known bugs. Please queue for the next feature release.
Index: wireless-testing/drivers/net/wireless/b43/main.c
Enable the PCI slow clock workaround, if we're running a PCI core rev = 10.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
John, this doesn't fix know bugs. Please queue for the next feature release.
Index: wireless-testing/drivers/net/wireless/b43/main.c
This patch converts code to use the new b43_radio_set() API.
The semantic patch that makes this change is as follows:
// smpl
@@
expression dev, addr, set;
@@
-b43_radio_write16(dev, addr, b43_radio_read16(dev, addr) | set);
+b43_radio_set(dev, addr, set);
// /smpl
Signed-off-by: Michael
Signed-off-by: Michael Buesch m...@bu3sch.de
---
Index: wireless-testing/drivers/net/wireless/b43/lo.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/lo.c 2009-02-20
19:14:48.0 +0100
+++ wireless-testing/drivers/net
This patch converts code to use the new b43_radio_mask() API.
The semantic patch that makes this change is as follows:
// smpl
@@
expression dev, addr, mask;
@@
-b43_radio_write16(dev, addr, b43_radio_read16(dev, addr) mask);
+b43_radio_mask(dev, addr, mask);
// /smpl
Signed-off-by: Michael
On Friday 20 February 2009 19:19:15 Michael Buesch wrote:
Some time ago I rejected a bunch of patches that converted the
PHY/radio register accesses to the new API. That was due to the patches
being created manually. This introduces a huge potential to add new bugs.
However
structures), but have twice
the number of TX slots available.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
Please queue for the next round of features.
Index: wireless-testing/drivers/net/wireless/b43/dma.c
===
--- wireless
This adds a compiletime assertion for a recently introduced
assumption on the slot counts.
The tx header cache handling code assumes that the TX slot count
can be divided evenly by the number of TX slots per frame.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
Please queue on top of the DMA
guess I should have. I did announce that I had finished to Michael
Buesch, who
is the only one working on converting specs to code.
Thanks very much! I'm looking forward to finally getting OpenWrt with
2.6 working on my Asus 520gu. If there's any testing I can do when
Michael starts
On Wednesday 18 February 2009 12:51:13 Francesco Gringoli wrote:
- is that correct to have status.rate_idx filled by functions
b43_plcp_get_bitrate_idx_ofdm and b43_plcp_get_bitrate_idx_cck that
compute those values reading the plcp?
Yes I think so. This seems to be the best way to do
Please read the code. There are lots of sanity checks in b43 and mac80211
that make it impossible to receive completely corrupted frames.
On Tuesday 17 February 2009 23:05:51 Bo Han wrote:
Hi,
I am interested in capturing FCS error frames using b43 driver. My hardware
information is as
On Wednesday 18 February 2009 00:07:56 Bo Han wrote:
I think I am working on the first sanity check in the driver, but still
cannot see any FCS error frames. Is setting B43_MACCTL_KEEP_BAD the only
thing we need to do for the firmware?
No. I suggest you don't touch that flag anyway and change
On Monday 16 February 2009 09:33:54 Holger Schurig wrote:
Oh wait, I think it's probably not needed to modify the
firmware. It has a knob to pass bad frames up to the driver.
It should pass these frames then.
Shouldn't the monitor mode then turn on this knob by default?
No. We're talking
On Monday 16 February 2009 10:31:34 Heinrich Schmitzberger wrote:
Hi people!
Is there a way to use the BCM4322 chip (PCI-ID 0x432B) in b/g mode
ignoring 11n functionality?
No
--
Greetings, Michael.
___
Bcm43xx-dev mailing list
This fixes the crystal frequency calculations in the b2062 init code.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
This patch depends on the SSB PMU code.
Index: wireless-testing/drivers/net/wireless/b43/phy_lp.c
On Sunday 01 February 2009 11:16:29 Michael Buesch wrote:
On Sunday 01 February 2009 02:01:24 Francesco Gringoli wrote:
Ok, this could be a problem. Will check next days how to solve. I
suppose now that the length of that report_tx_status queue is very
device dependent as mine can
On Sunday 01 February 2009 02:01:24 Francesco Gringoli wrote:
Ok, this could be a problem. Will check next days how to solve. I
suppose now that the length of that report_tx_status queue is very
device dependent as mine can grow it more than one hundred elements
and status continues to
On Sunday 01 February 2009 12:24:23 Francesco Gringoli wrote:
On Feb 1, 2009, at 11:25 AM, Michael Buesch wrote:
On Sunday 01 February 2009 11:16:29 Michael Buesch wrote:
If it's not an external condition, it could possibly also be a bit
in the TXE or something
like that. I'm
On Sunday 01 February 2009 12:25:20 Francesco Gringoli wrote:
On Feb 1, 2009, at 11:25 AM, Michael Buesch wrote:
On Sunday 01 February 2009 11:16:29 Michael Buesch wrote:
If it's not an external condition, it could possibly also be a bit
in the TXE or something
like that. I'm
On Sunday 01 February 2009 16:58:33 Larry Finger wrote:
Michael Buesch wrote:
But, why do we talk about this, actually? Do we actually know what went
wrong, yet?
Larry, did you dump a cookie of a frame that would trigger the crash? What
does the
ring memory allocation look like
On Sunday 01 February 2009 17:26:26 Francesco Gringoli wrote:
On Feb 1, 2009, at 5:19 PM, Larry Finger wrote:
The problem also exists in the 5.0 firmware. My test this morning died
within 10 minutes. This time, there were only two transmits queued.
The cookies were 0x2048 and 0x204A.
On Saturday 31 January 2009 12:20:18 Lorenzo Nava wrote:
Hmmm, I think the cookies should actually be more or less
sequential, if
QoS and PIO are not used. That's rather strange. Can you try with
original fw and
see what the cookies look like?
Yes Michael, you're right... I
This adds register definitions for the LP-PHY.
This also adds a few minor empty function bodies for the LP-init.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
I'll let you decide whether you queue this for the next feature release
or the next -rc. I lost track of what the rules
This adds code for the baseband init of LP-PHY =2.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
Index: wireless-testing/drivers/net/wireless/b43/Makefile
===
--- wireless-testing.orig/drivers/net/wireless/b43/Makefile 2009
This adds initialization code for the 2062 radio.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
Index: wireless-testing/drivers/net/wireless/b43/phy_lp.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/phy_lp.c 2009
On Saturday 31 January 2009 20:15:22 Francesco Gringoli wrote:
On Jan 31, 2009, at 7:54 AM, Larry Finger wrote:
Francesco,
I changed the dma.c code to WARN_ON rather than BUG_ON and also dump
the cookie for the erring case. Of course, the system no longer
crashes, nor even stops on
On Sunday 01 February 2009 00:35:01 Francesco Gringoli wrote:
On Jan 30, 2009, at 10:59 PM, Michael Buesch wrote:
On Friday 30 January 2009 14:22:35 Lorenzo Nava wrote:
I think that's rather unlikely, however. The DMA code is basically
unchanged
for months and especially the slot
On Sunday 01 February 2009 00:47:35 Michael Buesch wrote:
On Sunday 01 February 2009 00:35:01 Francesco Gringoli wrote:
On Jan 30, 2009, at 10:59 PM, Michael Buesch wrote:
On Friday 30 January 2009 14:22:35 Lorenzo Nava wrote:
I think that's rather unlikely, however. The DMA code
On Tuesday 27 January 2009 22:51:50 Adam Goode wrote:
Hi,
I have a new laptop with a bcm4315, pci id 14e4:4515. Any update on
support? Can I be of any assistance?
I'm working on it, however, I just bricked my device. Let's hope I can
fix it via JTAG. :)
--
Greetings, Michael.
Hi,
What's the LP-PHY progress? I'd like to get some implementation going. :)
--
Greetings, Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
On Monday 26 January 2009 16:39:53 Larry Finger wrote:
Michael Buesch wrote:
Hi,
What's the LP-PHY progress? I'd like to get some implementation going. :)
As you likely noted, I've been busy with non-BCM43xx tasks.
The decompilation of the LP routines is essentially complete
On Monday 26 January 2009 16:34:49 Larry Finger wrote:
Do you know of any reason why version 410 firmware fails on this device?
No, it works on all of my 4318 devices.
Can you suggest to try without btcoex (module parameter)?
--
Greetings, Michael.
On Monday 26 January 2009 22:53:56 Larry Finger wrote:
Michael Buesch wrote:
Thanks a lot. That's very nice. I'm interested in implementing the stuff
and I already started to implement the existing specs stuff.
I'm interested to get the Asus WL500Gv2 working, which has an LP-PHY
a net reduction in size by about 12k.
This patch also adds a printk of the wireless core revision, so people
don't have to enable SSB debugging to get the wireless core revision.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
John, please queue for the next feature push.
Index: wireless
On Sunday 25 January 2009 13:19:45 Michael Buesch wrote:
On Sunday 25 January 2009 04:45:20 Larry Finger wrote:
Francesco Gringoli wrote:
could you please be so kind to try the opensource firmware on that
4311/2 card by renaming it ucode13 and report what happens? I suggest to
try
Fix compile warning for non-debug builds:
drivers/net/wireless/b43/phy_g.c: In function ‘b43_gphy_op_recalc_txpower’:
drivers/net/wireless/b43/phy_g.c:3195: warning: unused variable ‘dbm’
Signed-off-by: Michael Buesch m...@bu3sch.de
---
Index: wireless-testing/drivers/net/wireless/b43/phy_g.c
On Friday 23 January 2009 18:36:37 Francesco Gringoli wrote:
Hello,
we have been testing the firmware for a week now and it seems stable.
I personally tested it also on a Linksys WRT54GL and it works both in
station and in AP modes. I collected the feedbacks that some of you
sent and
On Friday 23 January 2009 19:01:00 Larry Finger wrote:
The driver can certainly be coded to look for the open-source firmware
names before trying to load vendor firmware. That way there will not
be any confusion.
I already posted that, but in case you missed it:
On Friday 23 January 2009 19:50:37 Dan Williams wrote:
On Fri, 2009-01-23 at 19:08 +0100, Michael Buesch wrote:
On Friday 23 January 2009 19:01:00 Larry Finger wrote:
The driver can certainly be coded to look for the open-source firmware
names before trying to load vendor firmware
On Friday 23 January 2009 20:18:52 Francesco Gringoli wrote:
Nothing. Why do we need to have different names?
Well, I was only considering a question raised by John, we can surely
maintain these names.
I guess I missed that. What was the question?
Note that proprietary and open firmwares
On Friday 23 January 2009 20:24:47 Francesco Gringoli wrote:
On Jan 23, 2009, at 7:01 PM, Larry Finger wrote:
Francesco Gringoli wrote:
Hello,
we have been testing the firmware for a week now and it seems
stable. I
personally tested it also on a Linksys WRT54GL and it works both
On Friday 23 January 2009 20:46:45 Francesco Gringoli wrote:
-- Is using the Broadcom names for the firmware the best course of
-- action? What if the opensource firmware files were named something
-- like os-ucode5.fw, etc. and b43 were coded to check for those files
-- first? It would then
on
multiband
devices, which are not implemented yet anyway.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
John, please queue for the next feature round.
Index: wireless-testing/drivers/net/wireless/b43/main.c
===
--- wireless
On Saturday 24 January 2009 06:04:47 Larry Finger wrote:
Michael Buesch wrote:
First probe for proprietary firmware and then probe for opensource firmware.
This way around it's a win-win situation.
1) If proprietary fw is available, it will work.
2) If opensource firmware is available
On Wednesday 21 January 2009 18:29:40 Francesco Gringoli wrote:
Hello everyone,
we just made available a new opensource firmware version, download at
http://www.ing.unibs.it/openfwwf
New features:
- initvals source code added, initvals files are encoded by make process
- firmware is now
On Friday 16 January 2009 00:01:41 Francesco Gringoli wrote:
On Jan 15, 2009, at 4:59 PM, Larry Finger wrote:
Michael Buesch wrote:
Yes, please introduce a feature-bitfield at some location in SHM
that's unused
by the proprietary firmware. This bitfields would contain a bit
On Friday 16 January 2009 00:17:43 Kyle McMartin wrote:
On Thu, Jan 15, 2009 at 05:09:49PM +0100, Michael Buesch wrote:
Already implemented here:
http://bu3sch.de/patches/wireless-testing/20081227-1821/patches/008-b43-probe-open-fw.patch
I just need to fix a leak in an error path before
On Wednesday 14 January 2009 21:45:22 Johannes Berg wrote:
Initvals and new firmware version can be found at
http://www.ing.unibs.it/openfwwf
I suggest that before this is packaged, we change it so b43 can
recognise it and automatically disable qos and hwcrypto.
Yes, please introduce a
On Thursday 15 January 2009 00:22:33 Stefan Lippers-Hollmann wrote:
Is there a chance to add support for this kind of device?
I think you're on your own. Nobody else does have such a device
and remote-debugging is basically impossible for this.
--
Greetings, Michael.
On Thursday 15 January 2009 16:37:57 Michael Buesch wrote:
On Wednesday 14 January 2009 21:45:22 Johannes Berg wrote:
Initvals and new firmware version can be found at
http://www.ing.unibs.it/openfwwf
I suggest that before this is packaged, we change it so b43 can
recognise
On Thursday 15 January 2009 16:59:11 Larry Finger wrote:
Michael Buesch wrote:
Yes, please introduce a feature-bitfield at some location in SHM that's
unused
by the proprietary firmware. This bitfields would contain a bit for QoS and
a bit for hwcrypto.
Also change your firmware so
On Thursday 15 January 2009 18:59:46 Stefan Lippers-Hollmann wrote:
Hi
On Donnerstag, 15. Januar 2009, Michael Buesch wrote:
On Thursday 15 January 2009 00:22:33 Stefan Lippers-Hollmann wrote:
Is there a chance to add support for this kind of device?
I think you're on your own
On Wednesday 14 January 2009 08:15:37 YanBo wrote:
[snip]
You can add
Acked-by: Michael Buesch m...@bu3sch.de
to all of these patches, after fixing the issues Johannes reported.
Please send them directly to John afterwards and CC me.
--
Greetings, Michael
On Wednesday 14 January 2009 02:19:05 David Ellingsworth wrote:
On Tue, Jan 13, 2009 at 6:09 PM, Paul Harris p...@whotookspaz.org wrote:
Hello there,
I was wondering if it would be at all possible for the developers of b43 to
consider dual licensing the drivers, so
that users of other
On Wednesday 14 January 2009 18:43:27 Larry Finger wrote:
Lorenzo Nava wrote:
Today we have also tested a new firmware version that works with
WPA2-personal (both TKIP and CCMP) and WPA2-enterprise (EAP-TTLS)
(tested on 4306 and 4318 PCI device). If anybody was interested please
try new
On Monday 12 January 2009 16:39:49 John W. Linville wrote:
On Sat, Jan 10, 2009 at 06:37:43PM +0100, Lorenzo Nava wrote:
Hello everybody,
today I tried OpenFWWF with kernel 2.6.28 on a Siemens wifi device with
Broadcom 4306 chipset:
BCM94306 802.11g (rev 03)
PHY: Analog 2, Type 2,
On Friday 09 January 2009 02:30:56 Harvey Harrison wrote:
On Thu, 2009-01-08 at 17:28 -0800, Harvey Harrison wrote:
On Fri, 2009-01-09 at 02:11 +0100, Michael Buesch wrote:
I was doing some random tests on the b43 hardware RNG.
These are the results.
I patched the firmware
test firmware written by Michael Buesch and
useful talks with those guys (b43 developers), which we deeply
acknowledge. As we used several definition files written by Michael
for its firmware and we have prepared a source tar file that includes
them, we kindly ask Michael if this could
I was doing some random tests on the b43 hardware RNG.
These are the results.
I patched the firmware to not access the RNG register anymore.
The unpatched firmware does two things. It reads the RNG register to get random
values
and it writes 0 to the register every now and then for whatever
On Monday 29 December 2008 17:23:56 Larry Finger wrote:
Michael Buesch wrote:
Thanks, I applied this.
Is it possible, however, to have ssb_sprom --help not ask for the version?
Simply print out _all_ options that apply to all versions.
It's kind of confusing to see a question about a file
On Monday 29 December 2008 18:11:10 Larry Finger wrote:
Revise ssb-sprom to generate the help data for all versions of the device.
Signed-off-by: Larry Finger larry.fin...@lwfinger.net
Thanks.
--
Greetings, Michael.
___
Bcm43xx-dev mailing list
301 - 400 of 1753 matches
Mail list logo
